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

Internet Engineering Task Force (IETF)                        L. Iannone
Request for Comments: 9302                    Huawei Technologies France
Obsoletes: 6834                                                D. Saucez
Category: Standards Track                                          Inria
ISSN: 2070-1721                                           O. Bonaventure
                                        Universite catholique de Louvain
                                                            October 2022

Locator/ID Separation Protocol (LISP) Map-Versioning

Версии отображений протокола LISP

PDF

Аннотация

Этот документ описывает механизм версий отображений (Map-Versioning) протокола LISP¹, который позволяет указывать в пакетах отображения идентификаторов конечных точек на локаторы маршрутизации (Endpoint-ID-to-Routing-Locator или EID-RLOC), применяемые при инкапсуляции пакетов данных LISP. Этот подход основан на связывании номера версии с отображениями EID-RLOC и доставки этого номера в заголовке LISP пакетов, инкапсулированных в LISP. Версии отображений LISP особенно полезны для информирования входных (Ingress Tunnel Router или ITR) и выходных (Egress Tunnel Router или ETR) маршрутизаторов о смене версии отображения, применяемого при инкапсуляции пакетов. Механизм необязателен и не мешает не поддерживающим его реализациям, поскольку в заголовках LISP и записях отображений биты Map-Versioning можно без опаски игнорировать в маршрутизаторах ITR и ETR, не поддерживающих или не желающих использовать этот механизм.

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

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

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

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

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

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

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

Этот документ описывает механизм Map-Versioning, используемый для информирования об изменениях сопоставлений идентификаторов конечных точек с локаторами маршрутизаторов (EID-RLOC), применяемых в контексте протокола LISP [RFC9300] [RFC9301] для инкапсуляции пакетов. Механизм не препятствует работе входных (Ingress) и выходных (Egress) маршрутизаторов туннелей (xTRs), не поддерживающих или не использующих эту функциональность. Архитектура LISP описана [RFC9299] и предполагается знакомство читателя с этим вводным документом.

Этот документ отменяет [RFC6834], где была задана исходная, экспериментальная спецификация механизмов.

Базовым механизмом является связывание номера версии (Map-Version) с каждым отображением LISP EID-RLOC и доставка этого номера в связанном с LISP заголовке. При смене отображения ему назначается новый номер версии. Сменой сопоставления EID-RLOC может быть изменение набора RLOC, такое как добавление, удаление, изменение приоритета или веса одного или нескольких RLOC.

При использовании Map-Versioning пакеты данных с инкапсуляцией LISP содержат номера версий двух отображений, используемых для выбора RLOC во внешнем заголовке (RLOC источника и получателя). Эти сведения имеют два применения.

1. Map-Versioning позволяет выходному маршрутизатору туннеля (Egress Tunnel Router или ETR), принимающему пакет, знать, использует ли входной маршрутизатор туннеля (Ingress Tunnel Router или ITR) последнюю версию отображения для EID получателя. Если это не так, ETR может напрямую передать Map-Request с обновлённым отображением маршрутизатору ITR для информирования о последней версии. ETR может также запросить у ITR инициирование Map-Request для получения последнего отображения путём отправки сообщения SMR (Solicit Map-Request). Оба варианта определены в [RFC9301].

2. Map-Versioning позволяет ETR, принимающему пакет, знать, содержится ли в его EID-RLOC Map-Cache последнее отображение для EID источника. Если это не так, может быть передан Map-Request.

Вопросы развёртывания LISP Map-Versioning рассмотрены в разделе 9. Вопросы внедрения, а преимущества Map-Versioning в некоторых распространённых вариантах применения LISP описаны в Приложении A.

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

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

3. Определения терминов

В этом документе используются термины, определённые в основной спецификации LISP ([RFC9300] и [RFC9301]). Ниже определены термины, связанные с механизмом Map-Versioning. В документе применяется порядок битов big-endian (сначала старший).

Map-Version number — номер версии отображения

Null Map-Version — нулевая (пустая) версия отображения

Dest Map-Version number — номер версии отображения у получателя

Source Map-Version number — номер версии отображения у отправителя

4. Заголовок LISP и номера Map-Version

Для работы с номерами версий заголовок LISP передаёт значения Source Map-Version и Dest Map-Version. Это делается путём установки бита V в заголовке LISP, как описано в [RFC9300] и показано на рисунке 1. Разрешённые комбинации флагов с установленным (1) битом V описаны в [RFC9300]. Номера версий не требуется передавать во всех пакетах с инкапсуляцией LISP. Формат заголовка LISP при установленном флаге V показан на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K|  Source Map-Version   |   Dest Map-Version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Пример заголовка LISP при использовании Map-Versioning.

Source Map-Version number (12 битов)

Dest Map-Version number (12 битов)

5. Запись отображения и Map-Version

Чтобы приспособиться к этому механизму, записи Map Record, доставляемые в сообщениях Map-Request, Map-Reply, Map-Register должны содержать номер Map-Version. Map Record (см. [RFC9301]) приводится здесь в качестве примера на рисунке 2. Этот документ не меняет назначение сообщений Map-Request, Map-Reply, Map-Register, они по-прежнему применяются в соответствии с [RFC9301].

     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
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Пример формата Map-Record.

Map-Version Number

Этот формат пакета совместим с xTR, не поддерживающими Map-Versioning, поскольку они могут просто игнорировать биты.

Map-Server, получивший неожиданный номер Map-Version (например, старый), должен отбросить сообщение без уведомления отправителя и следует внести соответствующую запись в журнал.

6. Номер EID-RLOC Map-Version

Номер EID-RLOC Map-Version представляется 12-битовым целым числом без знака. Номер версии назначается по отображениям, что означает разные номера у отображений, изменяемых независимо. Обновление версии (т. е. создание новой) должно увеличивать номер версии по сравнению с прежним (исключением является лишь Null Map-Version, как указано в конце параграфа 6.1. Null Map-Version).

Пространство номеров версий является кольцевым, при котором половина номеров будут меньше текущего номера Map-Version, а вторая половина — больше (новее). По сути, это порядковый номер, к которому применяется арифметика, описанная в [RFC1982]. Порядок позволяет по-разному реагировать на более старые и более новые номера Map-Version с отбрасыванием старых номеров и отправке Map-Request по новым (см. 7. Работа с номерами Map-Version). Предположим, что имеется два номера V1 и V2, отличных от Null Map-Version (6.1. Null Map-Version) и заданных 12 битами. Тогда для определения порядка этих номеров должны выполняться приведённые ниже процедуры (с соблюдением их порядка).

1. V1 = V2 - номера Map-Version совпадают.

2. V2 > V1, тогда и только тогда, когда 
   V2 > V1 И (V2 - V1) <= 2^(12-1)
   ИЛИ
   V1 > V2 И (V1 - V2) > 2^(12-1)

3. V1 > V2 в остальных случаях.

Для Map-Version = 69 номера Map-Version из диапазона [70; 69 + 2048] будут больше 69, а номера из диапазона [69 + 2049; (69 + 4095) mod 4096] — меньше чем 69.

Исходный номер Map-Version для нового отображения EID-RLOC следует задавать случайным, но недопустимо устанавливать значение Null Map-Version (0x000), поскольку этот номер имеет особое значение (см. параграф 6.1). Можно задавать начальный номер Map-Version в конфигурации.

При перезагрузке ETR будет использовать сопоставления, настроенные в его базе EID-RLOC. Если эти отображения имеют номер Map-Version, они будут применяться в соответствии с описанным в этом документе механизмом. ETR недопустимо автоматически создавать и назначать номера Map-Version для отображений в базе EID-RLOC.

6.1. Null Map-Version

Значение 0x000 (0) является особым номером Map-Version, указывающим, что на деле с отображением EID-RLOC не связано номера версии. Это значение применяется в особых случаях и называется Null Map-Version.

Запись отображений с номером Null Map-Version указывает, что с отображением не связано номера Map-Version. Это означает, что пакетам с инкапсуляцией LISP, адресованным в EID-Prefix, указанный отображением, недопустимо включать номер Map-Version (бит V сброшен — 0). Если ETR получает пакет с инкапсуляцией LISP и установленным битом V, когда исходное отображение в EID-RLOC Database имеет значение Null Map-Version, пакет должен отбрасываться без уведомления отправителя.

Null Map-Version может указываться в заголовке LISP как номер версии Source Map-Version (7.2. Обработка Map-Version источника), что указывает отсутствие сведений о версии отображения на сайте источника. Это означает, что при наличии отображения EID источника в EID-RLOC Map-Cache маршрутизатору ETR недопустимо сравнивать полученное значение Null Map-Version с содержимым EID-RLOC Map-Cache (параграф 7.2).

Особый смысл значения 0 для номера Map-Version означает, что при обновлении номера Map-Version в результате изменения содержимого отображения значение 0 должно пропускаться и взамен должно устанавливаться значение 1.

7. Работа с номерами Map-Version

Основная идея использования номеров Map-Version заключается в том, что при каждом изменении отображения (например, добавлении или удалении RLOC, смене веса в соответствии с правилами организации трафика, смене приоритета) или утрате на сайте LISP доступности одного или нескольких RLOC с локальной точки зрения (например, от IGP или при смене политики), сайт LISP назначает новый номер Map-Version. Действительным считается лишь последний номер Map-Version. Обновления отображений и соответствующих номеров Map-Version должны выполняться так, чтобы самая старая версия не могла быть спутана с последней (новой) по причине использования кольцевой нумерации. Для этого могут быть приняты простые меры, такие как обновление отображений лишь при условии использования для всего активного трафика последней версии или достаточно долгое ожидание, чтобы срок действия кэшированных записей LISP истёк (ожидание в течение времени не менее TTL, определённого в [RFC9301]).

ETR, получающий пакет LISP с номером Map-Version, выполняет указанные ниже проверки.

1. Проверяет, что ITR, передавший пакет, имеет актуальное отображение в своём EID-RLOC Map-Cache для EID получателя и корректно выполняет инкапсуляцию (см. 7.1. Обработка Map-Version получателя).

2. Для двухстороннего трафика проверяется, что отображение в EID-RLOC Map-Cache локального ETR для EID источника актуально (см. 7.2. Обработка Map-Version источника).

7.1. Обработка Map-Version получателя

Когда ETR получает пакет, номер Dest Map-Version отноится к отображению EID получателя, для которого ETR является RLOC. Это отображение является частью базы данных ETR EID-RLOC. Поскольку ETR уполномочен для отображения, он будет корректировать и обновлять номер Dest Map-Version. Номер версии должен проверяться, как указано ниже.

1. Пакет приходит с номером Dest Map-Version, сохраненным в EID-RLOC Database (обычный случай). Передавший пакет ITR имеет в своём кэше EID-RLOC Map-Cache актуальное отображение, поэтому иных действий не требуется.

2. Пакет приходит с номером Dest Map-Version новее (см. 6. Номер EID-RLOC Map-Version) сохранённого в EID-RLOC Database. Поскольку ETR уполномочен для сопоставлений, что означает корректность его номера отображения, номер версии в прибывшем пакете считается недействительным и пакет должен отбрасываться без уведомления отправителя. Следует также сделать запись об этом в системном журнале.

3. Пакет приходит с номером Dest Map-Version старее (см. 6. Номер EID-RLOC Map-Version) сохранённого в EID-RLOC Database. Это означает, что у передающего пакет ITR имеется устаревшее отображение в его EID-to-RLOC Map-Cache. ETR может обычным способом обработать инкапсулированную дейтаграмму в соответствии с [RFC9300], однако передающий пакет ITR должен быть проинформирован о доступности нового отображения с учётом правил ограничения скорости, заданных в [RFC9301]. Это осуществляется отправкой сообщения Map-Request маршрутизатору ITR, как описано в [RFC9301]. Одним из свойств, добавленных номерами Map-Version, является возможность блокировать трафик, не использующий последнюю версию отображения. Это возникает в случаях, когда ITR не обновил отображение, для которого ETR является полномочным, или в некоторых вариантах атак. В соответствии с правилами ограничения частоты передачи Map-Request из [RFC9301] после 10 повторов сообщения Map-Request передаются каждые 30 секунд. Если после первых 10 попыток номер Dest Map-Version в пакетах не обновился, маршрутизатору ETR следует отбрасывать пакеты со старым номером Map-Version. Операторы могут задать исключения для этого правила, но они выходят за рамки документа.

Правило для случая 3 может быть более строгим. Если время Record TTL для предыдущего отображения уже истекло, все пакеты со старым номером Map-Version должны отбрасываться без уведомления отправителя и отправки Map-Request. Такое действие разрешается, поскольку в случае, когда отображение с новым номером версии не менялось в течение Record TTL старого отображения, все записи в EID-RLOC Map-Cache маршрутизаторов ITR должны были уже устареть. Действительно, все ITR, передающие трафик, должны уже иметь обновлённые отображения в соответствии с [RFC9301].

Наличие в пакетах с инкапсуляцией LISP номера Dest Map-Version со значением Null Map-Version является нарушением протокола (см. 6.1. Null Map-Version).

7.2. Обработка Map-Version источника

Когда ETR принимает пакет, номер Source Map-Version относится к отображению для EID источника, для которого отправивший пакет ITR является полномочным. Если у ETR есть в EID-RLOC Map-Cache запись для EID источника, должна выполняться проверка с учётом указанных ниже обстоятельств.

1. Пакет приходит с номером Source Map-Version, сохраненным в EID-RLOC Database (обычный случай). ETR имеет в своём кэше EID-RLOC Map-Cache актуальное отображение, поэтому иных действий не требуется.

2. Пакет приходит с номером Source Map-Version новее (см. 6. Номер EID-RLOC Map-Version) сохранённого в локальном EID-RLOC Map-Cache. Это означает, что EID-RLOC Map-Cache у ETR устарел и его нужно обновить. Должно передаваться сообщение Map-Request, чтобы получить новое отображение для EID и сточника, с учётом правил ограничения скорости, описанных в [RFC9301].

3. Пакет приходит с номером Source Map-Version старее (см. 6. Номер EID-RLOC Map-Version) сохранённого в локальном EID-RLOC Map-Cache. Отметим, что при наличии отображения в EID-RLOC Map-Cache это означает, что было передано явное сообщение Map-Request и получено сообщение Map-Reply из полномочного источника. В такой ситуации пакет следует просто отбросить. Операторы могут задать исключения для этого правила, но они выходят за рамки документа.

Если у ETR нет записи в EID-RLOC Map-Cache для EID источника, номер Source Map-Version должен игнорироваться (см. Приложение A.1. Map-Versioning и односторонний трафик, где приведён пример такой ситуации).

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

Этот документ основан на спецификации и операциях плоскостей данных и управления LISP. Здесь применимо обсуждение вопросов безопасности из [RFC9300] и [RFC9301]. Номера Map-Version недопустимо применять в общедоступной сети Internet и они должны использоваться лишь в доверенных, изолированных средах. Тщательный анализ безопасности LISP приведён в [RFC7835].

Злоумышленники могут попытаться инициировать большое число Map-Request простой подделкой пакетов со случайными номерами Map-Version. Частота отправки Map-Request ограничена, как указано в [RFC9301]. При использовании Map-Version можно фильтровать пакеты с недействительными номерами до отправки Map-Request, что позволит снизить влияние DoS-атак, однако этого недостаточно для практической защиты от атак DDoS.

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

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

9. Вопросы внедрения

LISP требует от ETR одного сайта поддерживать идентичные отображения для данного EID-Prefix. Для Map-Versioning не требуется дополнительных механизмов синхронизации. Ясно, что все ETR должны возвращать одинаковые сопоставления, включая один номер Map-Version, поскольку в ином случае могут возникать несоответствия, создающие добавочный трафик управления, нестабильность и сбои.

Имеется два варианта применения Map-Versioning в плане синхронизации. С одной стороны, назначение отображениям номеров версий помогает при отладке, поскольку позволяет быстро проверить согласованность сопоставлений на разных ETR по номерам Map-Version. С другой стороны, Map-Versioning можно использовать для управления трафиком в направлении ETR, анонсирующих наиболее свежее сопоставление.

Рассмотрим в качестве примера топологию, показанную на рисунке 3, где ITR A.1 в Domain A передаёт односторонний трафик в Domain B, а A.2 из Domain A обменивается в Domain B двухсторонним трафиком. В частности, ITR A.2 передаёт трафик ETR B, а ETR A.2 получает трафик от ITR B.

+-----------------+              +-----------------+
| Domain A        |              | Domain B        |
|       +---------+              |                 |
|       | ITR A.1 |---           |                 |
|       +---------+    \         +---------+       |
|                 |      ------->| ETR B   |       |
|                 |      ------->|         |       |
|       +---------+    /         |         |       |
|       | ITR A.2 |---      -----| ITR B   |       |
|       |         |       /      +---------+       |
|       | ETR A.2 |<-----        |                 |
|       +---------+              |                 |
|                 |              |                 |
+-----------------+              +-----------------+

Рисунок 3. Пример топологии.

Очевидно, что при использовании Map-Versioning оба маршрутизатора ITR A.1 и ITR A.2 из Domain A должны указывать одно значение, иначе ETR и Domain B начнёт передавать сообщения Map-Request.

Такая же проблемп может возникнуть и без Map-Versioning, например, если два ITR из Domain A будут передавать разные биты LSB. В этом случае трафик будет нарушаться, если ETR B не проверяет доступность, или ETR B начнёт передавать Map-Request для подтверждения каждого изменения доступности.

Пока LISP не предоставляет какого-либо конкретного механизма синхронизации, но предполагает, что синхронизация обеспечивается согласованной настройкой xTR. Это относится и к Map-Versioning. Если в будущем появится механизм синхронизации, Map-Versioning автоматически воспользуется им, поскольку это включено в формат Map Record, как описано в разделе 5. Запись отображения и Map-Version.

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

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

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

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

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

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., «The Locator/ID Separation Protocol (LISP)», RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., «Locator/ID Separation Protocol (LISP) Control Plane», RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

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

[RFC1982] Elz, R. and R. Bush, «Serial Number Arithmetic», RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, «Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites», RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.

[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, «Locator/ID Separation Protocol (LISP) Map-Versioning», RFC 6834, DOI 10.17487/RFC6834, January 2013, <https://www.rfc-editor.org/info/rfc6834>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, «Locator/ID Separation Protocol (LISP) Threat Analysis», RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC9299] Cabellos, A. and D. Saucez, Ed., «An Architectural Introduction to the Locator/ID Separation Protocol (LISP)», RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.

Приложение A. Преимущества и применение Map-Versioning

В последующих параграфах обсуждаются различные аспекты и вариант применения Map-Versioning. Вопросы безопасности рассмотрены в разделе 8.

A.1. Map-Versioning и односторонний трафик

При использовании Map-Versioning заголвок LISP содержит номера Map-Version для отображений источника и получателя. Может возникнуть вопрос для случая одностороннего потока, например, как показано на рисунке 4, поскольку спецификация LISP не требует от ETR наличия отображения от EID источника.

+-----------------+            +-----------------+
| Domain A        |            | Domain B        |
|       +---------+            +---------+       |
|       | ITR A   |----------->| ETR B   |       |
|       +---------+            +---------+       |
|                 |            |                 |
+-----------------+            +-----------------+

Рисунок 4. Односторонний трафик между доменами LISP.

ITR способен включить номера версий источника и получателя в заголовок LISP, поскольку номер Source Map-Version имеется в его базе данных, а номер Dest Map-Version — в кэше.

ETR проверяет лишь номер Dest Map-Version, игнорируя номер Source Map-Version, как указано в заключительном предложении параграфа 7.2. Обработка Map-Version источника.

A.2. Map-Versioning и межсетевое взаимодействие Interworking

Версии отображений совместимы с межсетевым взаимодействием LISP между сайтами с поддержкой и без поддержки LISP, как описано в [RFC6832]. Межсетевое взаимодействие LISP определяет три метода взаимодействия между сайтами с поддержкой и без поддержки LISP — Proxy-ITR, LISP-NAT, Proxy-ETR, описанные ниже для Map-Versioning.

A.2.1. Map-Versioning и Proxy-ITR

+----------+                             +-------------+
| LISP     |                             | Без LISP    |
| Domain A |                             | Domain B    |
|  +-------+        +-----------+        |             |
|  | ETR A |<-------| Proxy-ITR |<-------|             |
|  +-------+        +-----------+        |             |
|          |                             |             |
+----------+                             +-------------+

Рисунок 5. Односторонний трафик из домена без LISP в домен LISP.

Назначением Proxy-ITR (PITR) является инкапсуляция трафика с сайта без поддержки LISP для доставки пакета одному из ETR сайта LISP (Рисунок 5). Этот случай очень похож на вариант с односторонним трафиком из Приложения A.1, поэтому к нему применимы те же правила.

Основное отличие состоит в том, что у Proxy-ITR нет никакого отображения, поскольку он просто инкапсулирует пакеты с сайта без LISP и не может поэтому предоставить Source Map-Version. В этом случае Proxy-ITR будет просто указывать Null Map-Version в качестве Source Map-Version, а принимающий ETR будет игнорировать это поле.

В этом примере LISP Domain A способен проверить, использует ли PITR последнее отображение. В поле Dest Map-Version Number заголовка LISP узел Proxy-ITR будет помещать номер версии отображения, используемого для инкапсуляции, а ETR A может использовать такое значение, как указано в параграфе 7. Работа с номерами Map-Version.

A.2.2. Map-Versioning и LISP-NAT

Механизм LISP-NAT основан на трансляции адресов немаршрутизируемых EID в маршрутизируемые EID без какой либо инкапсуляции, поэтому Map-Versioning в этом случае не применяется.

A.2.3. Map-Versioning и Proxy-ETR

Назначением Proxy-ETR (PETR) является декапсуляция трафика с сайта LISP для доставки пакетов на сайт без LISP (Рисунок 6). Одной из основных причин внедрения PETR является обход проверки индивидуальной пересылки по обратному пути (Unicast Reverse Path Forwarding).

+----------+                             +-------------+
| LISP     |                             | Без LISP    |
| Domain A |                             | Domain B    |
|  +-------+        +-----------+        |             |
|  | ITR A |------->| Proxy-ETR |------->|             |
|  +-------+        +-----------+        |             |
|          |                             |             |
+----------+                             +-------------+

Рисунок 6. Односторонний трафик между из домена LISP в домен без LISP.

У Proxy-ETR нет каких-либо отображений, поскольку он просто декапсулирует пакеты от сайта LISP. В этом случае ITR может указывать значение Map-Version или Null Map-Version в качестве номера Dest Map-Version, поскольку принимающий Proxy-ETR игнорирует это поле.

При такой настройке Proxy-ETR, просматривая номер Source Map-Version Number, может проверить наличие изменений отображения EID источника. Это полезно для проверки RLOC источника. В приведённом выше примере трафик из домена LISP инкапсулируется в LISP с использованием в качестве адреса отправителя RLOC домена. Proxy-ETR может извлечь отображение, связанное с доменом LISP и проверить поступление входящих пакетов с инкапсуляцией LISP от действительного RLOC. Изменение в RLOC-Set, который может применяться для адреса источника, может быть указано номером версии, при этом Proxy-ETR способен при необходимости запросить последнее отображение, как описано в параграфе 7.2. Обработка Map-Version источника.

A.3. Отключение и отзыв RLOC

Map-Versioning можно использовать для аккуратного завершения работы или отзыва конкретного RLOC. Это достигается путём создания нового отображения с обновлением номера Map-Version, где адрес RLOC, подлежащий исключению, будет анонсирован как недоступный (через флаг R в Map Record, см. [RFC9301]) без его фактического отключения.

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

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

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      D. Farinacci
Request for Comments: 9300                                   lispers.net
Obsoletes: 6830                                                V. Fuller
Category: Standards Track                    vaf.net Internet Consulting
ISSN: 2070-1721                                                 D. Meyer
                                                               1-4-5.net
                                                                D. Lewis
                                                           Cisco Systems
                                                        A. Cabellos, Ed.
                                    Universitat Politecnica de Catalunya
                                                            October 2022

The Locator/ID Separation Protocol (LISP)

Протокол разделения локаторов и идентификаторов (LISP)

PDF

Аннотация

Этот документ описывает протокол плоскости данных для разделения локаторов и идентификаторов (Locator/ID Separation Protocol или LISP). LISP определяет два пространства имён — идентификаторы конечных точек (Endpoint Identifier или EID), указывающие конечные точки, и локаторы маршрутизации (Routing Locator или RLOC), которые указывают точки подключения к сети. При этом LISP эффективно разделяет управление и данные, что позволяет маршрутизаторам создавать наложенные сети. Маршрутизаторы с поддержкой LISP обмениваются инкапсулированными пакетами в соответствии с отображениями EID на RLOC, хранящимися в локальном кэше Map-Cache.

LISP не требует менять стеки протоколов на конечных хостах и маршрутизаторах базовых сетей и, среди прочего, поддерживает организацию трафика (Traffic Engineering или TE), многодомность и мобильность.

Этот документ отменяет RFC 6830.

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

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

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

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

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

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

Этот документ описывает LISP — протокол инкапсуляции, основанный на фундаментальной идее разделения топологического местоположения точки присоединения ксети и отождествления узла [CHIAPPA]. В результате LISP создаёт два пространства имён — идентификаторы конечных точек (EID), служащие для указания конечных хостов (например, узлов или виртуальных машин), и маршрутизируемых локаторов (RLOC), указывающих точки подключения к сети. LISP также задаёт функции для сопоставления между этими пространствами имён и инкапсуляции трафика от устройств, использующих немаршрутизируемые EID, для транспортировки через сетевую инфраструктуру, которая обеспечивает маршрутизацию и пересылку с использованием RLOC. Инкапсуляция LISP применяет динамическую форму туннелирования, где не требуется статическое обеспечение.

LISP является наложенным протоколом, отделяющим управление от данных и этот документ задаёт плоскость данных, а также способы обмена пакетами между маршрутизаторами с поддержкой LISP (туннельные маршрутизаторы) за счёт инкапсуляции. Туннельные маршрутизаторы включают кэш отображения (Map-Cache), который содержит сопоставления EID с RLOC. Map-Cache заполняется с помощью протокола плоскости управления LISP [RFC9301].

LISP не требует менять стек протоколов на хостах или базовых маршрутизаторах. Отделяя EID от RLOC, LISP поддерживает естественную организацию трафика (TE), многодомность, мобильность и иные возможности.

Разработка LISP была инициирована дискуссиями во время организованного IAB семинара Routing and Addressing в Амстердаме в октябре 2006 г. (см. [RFC4984]).

Этот документ задаёт инкапсуляцию плоскости данных LISP и другую функциональность пересылки на узлах LISP, а в [RFC9301] определена плоскость управления LISP. Рекомендации по развёртыванию LISP приведены в [RFC7215], а в [RFC6835] рассмотрены соображения по управлению сетями. В [RFC9299] описана архитектура LISP.

Этот документ отменяет RFC 6830.

1.1. Сфера применимости

Изначально протокол LISP создавался для решения проблемы расширения маршрутизации в сети Internet [RFC4984]. Хотя имеется ряд подходов к решению этой задачи, по мере разработки и совершенствования LISP было найдено и реализовано много других применений LISP. В результате устройство и разработка LISP изменились с нацеленностью на эти варианты применения. Общим свойством таких вариантов является большой набор кооперирующихся объектов, стремящихся взаимодействовать через Internet или иную крупную инфраструктуру IP, сохраняя адресацию и топологию сотрудничающих элементов отдельно от топологии, маршрутизации и адресации базовой сети и Internet.

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

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

3. Определения терминов

Address Family Identifier (AFI)

Anycast Address

Client-side

Egress Tunnel Router (ETR) — выходной маршрутизатор туннеля

EID-to-RLOC Database — база данных отображений

EID-to-RLOC Map-Cache — кэш данных отображений

EID-Prefix — префикс EID

End-System — конечная система

Endpoint ID (EID) — идентификатор конечной точки

Ingress Tunnel Router (ITR) — входной маршрутизатор туннеля

LISP Header — заголовок LISP

LISP Router — маршрутизатор LISP

LISP Site — сайт LISP

Locator-Status-Bits (LSBs) — биты статуса локатора

Proxy-ETR (PETR) — ETR-посредник

Proxy-ITR (PITR) — ITR-посредник

Recursive Tunneling — рекурсивное туннелирование

Re-encapsulating Tunneling Router (RTR) — туннельный маршрутизатор смены инкапсуляции

Route-Returnability — возвратность маршрута

Routing Locator (RLOC) — локатор маршрутизации

Server-side — серверная сторона

xTR

4. Базовый обзор

Одной из важных концепций LISP является независимость работы конечных точек от применения LISP. Адреса IP, применяемые хостами для отслеживания хостов и соединений, а также для передачи и приёма сообщений не меняются. В терминах LISP эти адреса называются идентификаторами конечных точек (EID).

Маршрутизаторы по-прежнему пересылают пакеты по IP-адресам получателей. Для пакетов с инкапсуляцией LISP эти адреса называются локаторами (RLOC). Большинство маршрутизаторов на пути между хостами также сохраняются и выполняют поиск для маршрутизации и пересылки по адресам получателей. Для маршрутизаторов между хостом-источником и ITR целевого хоста, а также между ETR целевого хоста и получателем адресом получателя служит EID. Для маршрутизаторов между ITR и ETR адресом получателя является RLOC.

Другой важной концепцией LISP является туннельный маршрутизатор (Tunnel Router). Этот маршрутизатор добавляет в начало (prepend) заголовки LISP созданных хостом пакетов и вырезает эти заголовки перед доставкой конечному получателю. Адресами IP в этих «внешних» заголовках являются локаторы RLOC. При сквозном обмене пакетами между хостами Internet маршрутизатор ITR добавляет заголовок LISP, а ETR удаляет его. ITR выполняет поиск отображения EID на RLOC для определения пути к ETR, имеющему RLOC в качестве одного из адресов IP.

Некоторые базовые правила LISP перечислены ниже.

• Конечные системы передают пакеты лишь по EID, которыми обычно служат адреса IP, назначенные хостам (другие типа EID, поддерживаемые LISP, описаны в [RFC8060]). Конечные системы не знают, что адреса являются EID, а не RLOC, и предполагают, что пакеты приходят к адресату. В системах с LISP маршрутизаторы LISP перехватывают пакеты с адресами EID и помогают доставлять их через ядро сети, где EID не маршрутизируются. Процедура отправки хостом пакетов IP не меняется.

• Маршрутизаторы LISP добавляют в начало пакета или вырезают внешние заголовки с адресами RLOC, как описано в параграфе 4.2. Порядок потока пакетов.

• RLOC всегда являются адресами IP, назначенными маршрутизаторам, которые предпочтительно привязывать к топологии провайдерских бесклассовых блоков (Classless Inter-Domain Routing или CIDR).

• Когда маршрутизатор создаёт пакеты, он может использовать в качестве адреса отправителя EID или RLOC. Выступая в качестве хоста (например, в транспортной сессии SSH, TELNET или SNMP), он может использовать EID, явно выделенный для этих целей. EID, указывающий маршрутизатор, недопустимо применять в качестве RLOC, поскольку EID маршрутизируется лишь внутри сайта. В типичной конфигурации BGP может встречаться такое «гибридное» использование EID/RLOC, где маршрутизатор может применять EID для внутренних сессий BGP (iBGP) с маршрутизаторами внутри сайта и RLOC для внешних сессий BGP (eBGP) с маршрутизаторами других сайтов.

• Предполагается, что пакеты с EID не будут доставляться «насквозь» при отсутствии отображения EID на RLOC. Ожидается, что они будут применяться для взаимодействий внутри сайта или инкапсулироваться для передачи на другие сайты.

• EID могут структурироваться (подсети) для маршрутизации внутри локальной автономной системы (Autonomous System или AS).

Дополнительный заголовок LISP могут добавлять в начало пакета маршрутизаторы TE-ITR для изменения пути доставки пакета. Возможным вариантом использования является маршрутизатор провайдера (ISP), которому нужно организовать трафик (Traffic Engineering) для пакетов, проходящих через сеть провайдера. В таких ситуациях, называемых рекурсивным туннелированием (Recursive Tunneling), транзитный ISP выступает дополнительным ITR, а применяемый им целевой RLOC для этого добавленного заголовка будет TE-ETR внутри ISP (на его внутреннем пути организации трафика) или TE-ETR у другого ISP (организация трафика между ISP при согласовании такого пути).

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

Туннельные маршрутизаторы можно достаточно свободно размещать в топологии с множеством AS. Например, ITR для определённого сквозного обмена пакетами может быть первым (first-hop) или принятым по умолчанию (default) маршрутизатором внутри сайта хоста-источника. ETR может быть последним (last-hop) маршрутизатором, напрямую соединенным с хостом-получателем. Другим примером может служить передача сайтом услуг VPN своему ISP, который будет применять в качестве ITR свой граничный маршрутизатор в точке присоединения. Для максимальной гибкости допускается смешивание туннельных маршрутизаторов на сайте, у ISP и в других местах.

4.1. Развёртывание в общедоступной сети Internet

Некоторые из описанных в документе механизмов предназначены для контролируемых, доверенных сред и небезопасны для использования в общей сети Internet. В частности, в Internet узлы xTRs

• должны сбрасывать (0) биты N, L, E, V в заголовке LISP (5.1. Формат заголовка LISP IPv4-in-IPv4);

• им недопустимо использовать LSB и Echo-Nonce (10. Доступность локатора маршрутизации) для доступности RLOC, а взамен они должны полагаться исключительно на методы плоскости управления;

• им недопустимо использовать сбор LSB и версий отображения (13. Изменение содержимого отображений EID на RLOC) для обновления отображений EID на RLOC и взамен они должны полагаться исключительно на методы плоскости управления.

4.2. Порядок потока пакетов

В этом параграфе приведён пример потока индивидуальных (unicast) пакетов, включая сведения плоскости управления, как указано в [RFC9301]. Ниже приведены условия, предполагающиеся в этом примере.

• Хост host1.abc.example.com передаёт пакеты хосту host2.xyz.example.com так же, как при отсутствии LISP.

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

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

• Передаётся Map-Request для внешнего адресата, когда получатель не найден в таблице пересылки и не соответствует заданному по умолчанию маршруту. Эти запросы передаются в базу данных отображений с помощью протокола плоскости управления LISP, описанного в [RFC9301].

• Отклики Map-Replies передаются в топологию базовой системы маршрутизации и помощью протокола плоскости управления [RFC9301].

Клиент host1.abc.example.com хочет взаимодействовать с сервером host2.xyz.example.com.

1. host1.abc.example.com хочет организовать соединение TCP с host2.xyz.example.com и выполняет поиск DNS для host2.xyz.example.com, который возвращает запись A/AAAA. Это будет EID получателя, а заданный локально адрес host1.abc.example.com служит EID отправителя. Пакеты IPv4 или IPv6 создаются и пересылаются через сайт LISP как обычные пакеты IP, пока они не почтупят на LISP ITR.

2. LISP ITR должен быть способен отобразить EID получателя на RLOC одного из ETR на сайте адресата. Это делается с помощью отправки LISP Map-Request, как описано в [RFC9301].

3. Система отображения (Mapping System) помогает переслать Map-Request соответствующему ETR. При поступлении Map-Request на один из ETR целевого сайта пакет обрабатывается как управляющее сообщение.

4. ETR просматривает EID получателя в Map-Request и сопоставляет его с префиксами в настроенной на ETR базы отображения EID-RLOC. Это список префиксов EID, которые ETR поддерживает для своего сайта. Если совпадения не найдено, Map-Request отбрасывается. В ином случае ITR возвращается LISP Map-Reply.

5. ITR принимает сообщение Map-Reply, анализирует его и сохраняет сведения об отображении из пакета в своём кэше отображений EID на RLOC (Map-Cache). Отметим, что это кэширование выполняется по запросам, а ITR поддерживает Map-Cache с учётом своих ограничений на ресурсы.

6. В последующие пакеты от host1.abc.example.com к host2.xyz.example.com маршрутизатор ITR включает заголовок LISP, используя подходящий локатор RLOC от ETR в качестве адреса получателя в заголовке LISP. Отметим, что пакет может передаваться разным ETR, которые могут быть указаны в Map-Reply, из-за политики хэширования сайта-источника или политики Locator-Set у получателя.

7. ETR получает пакеты напрямую (поскольку адресом получателя является один из его адресов IP), проверяет пригодность адреса, вырезает заголовок LISP и пересылает пакеты подключённому целевому хосту.

8. Чтобы отложить поиск сопоставления в обратном направлении ETR может создавать запись в кэше, отображающую EID источника (внутренний IP-адрес отправителя) на RLOC источника (IP-адрес отправителя из внешнего заголовка) из принятого пакета LISP. Такие записи называют отображениями сбора (glean mapping) и они включают лишь 1 RLOC для EID. Более полные сведения л дополнительных RLOC следует получать, передавая запрос LISP Map-Request для EID. Маршрутизаторы ITR и ETR могут влиять на решение, принимаемые другим при выборе RLOC.

5. Детали инкапсуляции LISP

Поскольку в начало пакета добавляются туннельные заголовки, пакет становится больше и его размер может превысить значение MTU на каком-либо канале между ITR и ETR. Для пакетов IPv4 рекомендуется не выполнять фрагментацию пакетов, поскольку они инкапсулированы ITR, а вместо этого отбрасывать такие пакеты и возвращать отправителю сообщение ICMPv4 Unreachable / Fragmentation Needed. Если требуется фрагментировать пакет, реализациям рекомендуется поддерживать одну из предложенных схем фрагментации и сборки. Две имеющихся схемы описаны в разделе 7. Обработка больших инкапсулированных пакетов.

Поскольку адреса IPv4 и IPv6 могут быть идентификаторами EID или локаторами RLOC, архитектура LISP поддерживает IPv4 EID с IPv6 RLOC (внутренний заголовок имеет формат IPv4, а внешний — IPv6) и IPv6 EID с IPv4 RLOC (внутренний заголовок IPv6 и внешний IPv4). В последующих параграфах показаны форматы пакетов для однородных вариантов (IPv4 в IPv4 и IPv6 в IPv6), но должны поддерживаться все 4 комбинации. Дополнительные типы EID определены в [RFC8060].

LISP использует инкапсуляцию UDP для передачи трафика между xTRs через Internet и разработчикам следует учитывать положения [RFC8085], особенно параграф 3.1.11, где описан контроль перегрузок для туннелей UDP. Разработчикам рекомендуется учитывать рекомендации параграфа 3.4 из [RFC8085] для контрольных сумм UDP, когда желательно защитить заголовки UDP и LISP от повреждений.

5.1. Формат заголовка LISP IPv4-in-IPv4

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |    DSCP   |ECN|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |    DSCP   |ECN|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IHL = IP-Header-Length

5.2. Формат заголовка LISP IPv6-in-IPv6

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|    DSCP   |ECN|           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|    DSCP   |ECN|           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3. Описание полей туннельного заголовка

Inner Header (IH)

Outer Header (OH)

UDP Header

UDP Checksum

UDP Length

N

L

    x 1 x x 0 x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Locator-Status-Bits                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E

V

    0 x 0 1 x x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K|  Source Map-Version   |   Dest Map-Version    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Instance ID/Locator-Status-Bits               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I

    x x x x 1 x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Instance ID                   |     LSBs      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

R

KK

LISP Nonce

LISP Locator-Status-Bits (LSBs)

При инкапсуляции маршрутизаторы ITR и PITR выполняют указанные ниже правила.

• Поле TTL (Hop Limit для IPv6) следует копировать из поля TTL во внутреннем заголовке.

• В поле DSCP (Traffic Class для IPv6) следует копировать значение поля IPv4 DSCP (Traffic Class для IPv6) из внутреннего заголовка. Рекомендации для этого даны в [RFC2983].

• Биты явного уведомления о перегрузке IPv4 (Explicit Congestion Notification или ECN) и биты 6 — 7 поля IPv6 Traffic Class требуют особой обработки для предотвращения игнорирования индикации перегрузки, как указано в [RFC6040].

При декапсуляции маршрутизаторы ETR и PETR выполняют указанные ниже правила.

• В поле внутреннего заголовка IPv4 TTL (Hop Limit для IPv6) должно копироваться значение TTL (Hop Limit) из внешнего заголовка, если значение во внешнем заголовке меньше значения во внутреннем. Отказ от такой проверки может приводит к росту TTL (Hop Limit) во внутреннем заголовке в результате цикла инкапсуляции-декапсуляции. Проверка также выполняется при начальной инкапсуляции, когда пакет приходит в ITR или PITR для сайта LISP.

• Поле IPv4 DSCP (Traffic Class для IPv6) из внешнего заголовка следует копировать во внутренний заголовок. Рекомендации для этого даны в [RFC2983].

• Биты явного уведомления о перегрузке IPv4 (Explicit Congestion Notification или ECN) и биты 6 — 7 поля IPv6 Traffic Class требуют особой обработки для предотвращения игнорирования индикации перегрузки, как указано в [RFC6040]. Отметим, что имеются реализации, копирующие поле ECN из внешнего заголовка во внутренний, хотя [RFC6040] рекомендует не делать этого. Реализациям рекомендуется следовать поведению, описанному в [RFC6040].

Отметим, что в случаях, когда ETR/PETR является также ITR/PITR и заново инкапсулирует пакеты после декапсуляции, поле TTL во внешнем заголовке в результате будет уменьшаться на 1.

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

Некоторые xTR, PETR и PITR выполняют повторную инкапсуляцию и им нужна особая обработка полей ECN. Поскольку повторная инкапсуляция состоит из декапсуляции и последующей новой инкапсуляции, биты ECN должны обрабатывать в каждой из операций, как указано выше.

Протокол плоскости данных LISP не совместим с [RFC6830] и не имеет явной поддержки будущих изменений протокола (например, явного поля версии). Однако плоскость управления LISP [RFC9301] позволяет ETR регистрировать возможности плоскости данных с помощью новых типов канонического формата адресов (LISP Canonical Address Format или LCAF) [RFC8060]. За счёт этого ITR может узнать возможности плоскости данных ETR и применять соответствующую инкапсуляцию. Спецификация новых типов и механизмов LCAF, а также их применения выходит за рамки этого документа.

6. Кэш сопоставлений EID с RLOC в LISP

ITR и PITR поддерживают кэширование по запросам в LISP EID-to-RLOC Map-Cache, куда включаются отображения EID-Prefix на Locator-Set. Кэш применяется для инкапсуляции пакетов из пространства EID в RLOC точки присоединения к сети. Когда ITR или PITR получает пакет со своего сайта LISP для внешнего адресата, выполняется поиск по максимальному соответствию с EID в Map-Cache. При успешном поиске Locator-Set из Map-Cache применяется для передачи пакета в топологическое местоположение EID. Если поиск не даёт результата ITR/PITR требуется найти отображение с помощью протокола плоскости управления LISP [RFC9301]. Пока отображение отыскивается и извлекается, ITR/PITR может отбрасывать или буферизовать пакеты. Этот документ не даёт конкретных рекомендаций для таких случаев и разработчики должны решать этот вопрос самостоятельно, обеспечивая желаемое поведение реализации LISP. После распознавания отображения оно сохраняется в локальном Map-Cache для пересылки последующих пакетов в тот же EID-Prefix.

Map-Cache — это локальный кэш отображений, записи в котором сохраняются в течение заданного срока (Time to Live). Записи могут обновляться более свежими данными, как описано в разделе 13. Изменение содержимого отображений EID на RLOC. Кроме того, Map-Cache содержит сведения о доступности EID и RLOC, а также использует механизмы сведений о доступности LISP для проверки достижимости RLOC (см. 10. Доступность локатора маршрутизации).

7. Обработка больших инкапсулированных пакетов

В этом разделе предлагаются два механизма работы с пакетами, размер которых превышает Path MTU (PMTU) между ITR и ETR.

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

Оба механизма применимы к повторной инкапсуляции и рекурсивным туннелям, поскольку действия для ITR применимы и на TE-ITR.

7.1. Решение для обработки MTU без учёта состояний

Решение без учёта состояний при обработке ITR проблем с MTU описано ниже.

1. Определяется число октетов H, добавляемых ITR во внешний заголовок перед пакетом, с учётом размера заголовков UDP и LISP.

2. Определяется число октетов L для максимального размера пакетов, которые ITR может передавать ETR без необходимости их фрагментирования на ITR и промежуточных маршрутизаторах. Сетевой администратор сайта LISP должен выбрать значение L, позволяющее избежать проблем с MTU.

3. Определяется архитектурная константа S для максимального размера пакетов (в октетах), которые ITR должен воспринимать от источника с учётом эффективного значения MTU. L = S + H.

Когда ITR получает пакет от интерфейса в сторону сайта и добавка H октетов инкапсуляции ведёт к превышению L (размер пакета от источника больше S), он решает проблему MTU, деля исходный пакет на два фрагмента одинаковых размеров, а затем добавляет в начало каждого фрагмента заголовок LISP. Размер инкапсулированных фрагментов составит (S/2 + H), что меньше оценки ITR для PMTU между ITR и соответствующим ETR.

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

Это поведение должно быть реализовано в ITR лишь для исходных пакетов со сброшенным (0) битом запрета фрагментирования. Если бит DF установлен в заголовке IP или пакет относится к протоколу IPv6, ITR будет отбрасывать пакет, если его размер превышает L (после добавления заголовка инкапсуляции) и передавать источнику сообщение ICMPv4 Unreachable/Fragmentation Needed или ICMPv6 Packet Too Big (PTB) со значением S = (L — H).

При использовании для инкапсуляции внешнего заголовка IPv4 следует устанавливать (1) в нем флаг DF, чтобы избежать сборки на маршрутизаторе ETR. Реализация может сбрасывать (0) флаг DF в таких заголовках, если имеются веские основания предполагать наличие неразрешимых проблем с PMTU между ITR и принимающим ETR.

Рекомендуется устанавливать L = 1500.Дополнительные сведения о MTU в сети и вопросах фрагментации приведены в [RFC4459].

7.2. Решение для обработки MTU с учётом состояний

Решение с учётом состояний при обработке ITR проблем с MTU описано ниже.

1. ITR сохраняет эффективное состояние MTU для каждого локатора в записи Map-Cache. Эффективным значением MTU является размер пакета, который ядро сети может доставить по пути между ITR и ETR.

2. Когда инкапсулированный в IPv4 пакет с DF = 1 превышает размер, поддерживаемый ядром сети, один из промежуточных маршрутизаторов пути передаёт ITR сообщение ICMPv4 Unreachable/Fragmentation Needed. ITR анализирует сообщение ICMP для определения локатора, на который влияет смена эффективного MTU и записывает новое значение MTU в Map-Cache.

3. Когда ITR получает из внутренней сети сайта пакет с размером больше эффективного MTU в записи Map-Cache, связанной с EID получателя пакета, ITR передаёт источнику этого пакета сообщение ICMPv4 Unreachable/Fragmentation Needed. Размер пакета, анонсируемый ITR в сообщении ICMP, составляет эффективное значение MTU за вычетом заголовка инкапсуляции LISP.

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

Следует отметить, что применение пакетов ICMP для определения PMTU, как описано в [RFC1191] и [RFC8201], может приводить к неоптимальному поведению при потере пакетов ICMP или наличии за пределами пути злоумышленников, передающих обманные пакеты ICMP. Возможные меры снижения негативного влияния включают взаимодействие ITR и ETR с тестовыми пакетами [RFC4821] [RFC8899] или сохранение на ITR больших пакетов для проверки их соответствия пакетам, указанным в сообщениях ICMP Fragmentation Needed или PTB.

8. Использование виртуализации и разделения с LISP

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

Instance ID можно передавать в пакетах с инкапсуляцией LISP. ITR, добавляющий заголовок LISP будет копировать 24-битовое значение, используемое маршрутизатором LISP для однозначного указания пространства адресов. Значение копируется в поле Instance ID заголовка LISP а для флага I устанавливается значение 1.

Когда ETR декапсулирует пакет Instance ID из заголовка LISP используется в качестве идентификатора таблицы пересылки, применяемой для поиска EID получателя.

В качестве Instance ID может служить, например, тег 802.1Q VLAN или идентификатор VPN, помещаемый в 24-битовое поле Instance ID. Применение LISP в VPN подробно рассмотрено в [LISP-VPN]. Отметим, что поле Instance ID не защищено и находящийся на пути злоумышленник может менять его и, например, разрешать взаимодействие между изолированными VLAN.

Участники развёртывания LISP должны согласовать между собой применение значений Instance ID. EID источника и получателя должны относиться к одному Instance ID.

Instance ID не следует применять с перекрывающимися адресами IPv6 EID.

9. Выбор локатора маршрутизации

Map-Cache содержит состояние, используемое ITR и PITR для инкапсуляции пакетов. Когда ITR или PITR принимает пакет с сайта LISP для внешнего адресата выполняется поиск по максимальному совпадению EID в Map-Cache (см. 6. Кэш сопоставлений EID с RLOC в LISP ). Поиск возвращает набор Locator-Set со списком RLOC, соответствующих топологическому расположению EID. С каждым RLOC в Locator-Set связан приоритет (Priority) и вес (Weight), используемые для выбора RLOC при инкапсуляции.

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

Ниже рассмотрено несколько вариантов выбора RLOC и доступные элементы управления.

• Серверная сторона возвращает 1 локатор RLOC и клиентская сторона применяет лишь его. Выбор локатора полностью принадлежит серверной стороне.

• Серверная сторона возвращает список RLOC, часть которых имеет одинаковое (лучшее) значение Priority. Клиент может использовать эти локаторы с весовыми коэффициентами, заданными на стороне сервера. В этом случае сервер контролирует набор локаторов и распределение трафика между ними. Клиентская сторона может выбрать RLOC (с приоритетом, отличным от 255) не из подмножества списка, если она решает, что это подмножество недоступно. Здесь имеется некоторое распределение управления — сервер определяет список RLOC и распределение нагрузки между ними, а клиент может использовать другие локаторы, если RLOC из списка недоступны.

• Серверная сторона устанавливает Weight=0 для списка подмножества RLOC. В этос случае клиентская сторона выбирает способ распределения трафика между элементами подмножества. Механизмы распределения трафика рассмотрены в разделе 12. Хэширование локаторов маршрутизации. Управление распределено между серверной стороной, задающей список, и клиентской стороной, определяющей распределение нагрузки. Клиент и в этом случае может использовать другие локаторы, если RLOC из предоставленного сервером списка недоступны.

• Любая из сторон (наиболее вероятно, ETR на стороне сервера) решает «собрать» RLOC. Например, если ETR серверной стороны собирает RLOC, ITR на стороне клиента возлагает на этот ETR ответственность за двухстороннюю доступность и предпочтения RLOC. ETR на стороне сервера собирает RLOC клиентского ITR, кэшируя EID источника из внутренних заголовков и RLOC источника из внешних заголовков принятых пакетов. ITR на стороне клиента контролирует возврат трафика и может, как вариант, использовать RLOC источника из внешнего заголовка, который может затем добавляться в список, используемый ETR на серверной стороне для возврата трафика. Поскольку в этом случае Priority и Weights не предоставляются, ETR на стороне сервера должен предполагать, что RLOC, применяемые ITR на стороне клиента имеют наилучшее значение Priority с Weight = 0.

  Поскольку кодирование EID-Prefix не может передаваться в пакетах данных, EID-to-RLOC Map-Cache на туннельных маршрутизаторах может стать чрезмерно большим. Со сбором связано несколько важных соображений. «Собранная» запись Map-Cache сохраняется и применяется лишь в течение рекомендованного интервала в 3 секунды, ожидая проверки, которая должна выполняться путём отправки Map-Request по EID источника (IP-адрес отправителя во внутреннем заголовке) полученного инкапсулированного пакета. Отклик на проверочный Map-Request служит для заполнения записи Map-Cache для «собранного» EID с сохранением и использованием её в течение интервала, заданного полем Time to Live в полученном Map-Reply. При сохранении проверенной записи Map-Cache сбор данных больше не выполняется для последующих пакетов с EID источника, соответствующим EID-Prefix в проверенной записи. Этот механизм «сбора» недопустимо применять через общедоступную сеть Internet и следует использовать лишь в доверенных, изолированных развёртываниях. Безопасность механизма обсуждается в разделе 16.

RLOC из сообщений EID-to-RLOC предполагаются достижимыми, если бит R [RFC9301] для записи Locator имеет значение 1. При сброшенном (0) бите R маршрутизаторам ITR и PITR недопустимо инкапсулировать в этот RLOC. Ни сведения из Map-Reply, ни данные, сохранённые в базе отображений не обеспечивают информации о достижимости RLOC. Отметим, что достижимость не является частью системы отображения и определяется с использованием одного или нескольких алгоритмов проверки доступности RLOC, описанных в следующем разделе.

10. Доступность локатора маршрутизации

В настоящее время имеется несколько механизмов плоскости данных для определения доступности RLOC. Отметим, что в [RFC9301] описаны другие механизмы, основанные на плоскости управления.

1. ETR может проверить биты LSB в заголовке LISP инкапсулированного пакета данных, принятого от ITR. Если ETR выступает также в качестве ITR и имеет трафик для возврата сайту исходного ITR, он может использовать эти сведения при выборе RLOC.

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

3. Пара ITR — ETR может использовать алгоритмы определения доступности, описанные в этом параграфе.

При определении статуса up/down для локатора путём проверки LSB из пакета данных с инкапсуляцией LISP маршрутизатор ETR будет получает от инкапсулирующего ITR актуальное состояние доступности всех ETR на сайте. Основанные на CE маршрутизаторы ITR на сайте источника могут определить достижимость друг друга, используя IGP, как указано ниже.

• При нормальных условиях каждый ITR будет анонсировать принятый по умолчанию маршрут в IGP сайта.

• При отказе ITR или восходящего канала к устройству PE для принятого по умолчанию маршрута будет возникать тайм-аут или он будет отзван.

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

Когда ITR сайта не развёрнуты на маршрутизаторах CE, IGP всё равно можно использовать для определения доступности локаторов при условии их внедрения в IGP. Обычно это делается с помощью адреса /32 (хост) на интерфейсе loopback.

RLOC, указанные в Map-Reply, имеют номера от 0 до n-1. Биты LSB в пакете с инкапсуляцией LISP нумеруются от 0 до n-1, начиная с младшего. Например, если RLOC в третьей позиции (порядковый номер 2) Map-Reply не активен, все ITR сайта будут сбрасывать этот бит (xxxx x0xx) в поле Locator-Status-Bits инкапсулируемых пакетов.

Когда xTR решает применять Locator-Status-Bits для воздействия на сведения о достижимости, он выполняет соответствующие действия. ETR, декапсулирующие пакеты, проверяют наличие изменений в поле Locator-Status-Bits. Если бит сбрасывается (переход от 1 к 0), ETR, выступающий также в качестве ITR, будет воздерживаться от инкапсуляции пакетов для RLOC, указанного как недоступный (down). Использование этого RLOC будет возобновлено лишь при возврате соответствующего бита LSB в состояние 1. Биты LSB связываются с Locator-Set по префиксам EID, поэтому когда локатор становится недоступным, бит LSB, соответствующий позиции этого локатора в списке из последнего Map-Reply, сбрасывается (0) для данного EID-Prefix.

Locator-Status-Bits недопустимо использовать через общую сеть Internet и следует применять лишь в доверенных, изолированных средах. Кроме того, Locator-Status-Bits следует сочетать с Map-Versioning [RFC9302] для предотвращения «состязания», когда биты LSB интерпретируются не для того локатора RLOC, которому они предназначены. Связанные с этим вопросы безопасности рассмотрены в разделе 16.

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

Соображения безопасности из раздела 16, относящиеся к достижимости плоскости данных, применимы и к описанным здесь механизмам определения доступности RLOC.

10.1. Алгоритм Echo-Nonce

Когда данные передаются в двух направлениях между локаторами разных сайтов, может применяться механизм плоскости данных «nonce-эхо» (nonce echoing) для определения достижимости между ITR и ETR. Если ITR хочет запросить nonce-эхо, он устанавливает флаги N и E, а также помещает 24-битовое значение [RFC4086] в заголовок LISP следующего инкапсулируемого пакета данных. Когда этот пакет приходит к ETR, инкапсулированный пакет пересылается обычным путём. Если ETR является xTR (совмещён с ITR), он затем передаёт пакет данных ITR (когда тот является xTR, совмещённым с ETR), включая в него полученное значение nonce, устанавливая бит N и сбрасывая бит E. ITR видит отражённое значение nonce и понимает, что путь между ним и ETR доступен.

ITR будет устанавливать биты E и N в каждом пакете, пока он находится в состоянии Echo-Nonce-request. Время, в течение которого ITR ожидает обработки отражённого nonce, определяющей доступность пути, является переменным и зависит от реализации.

Если ITR получает пакеты от ETR, но не видит в них отражённых nonce, находясь в состоянии Echo-Nonce-request, это говорит о недоступности пути к ETR. Это решение может быть отменено другим алгоритмом проверки доступности локаторов. После того, как ITR определит, что путь к ETR не работает, он может переключиться на другой Locator для этого EID-Prefix.

Отметим, что термины ITR и ETR здесь относительны и оба устройства должны реализовать функции ITR и ETR для работы механизма Echo-Nonce.

ITR и ETR могут одновременно оказаться в состоянии Echo-Nonce-request. Число передаваемых пакетов или время, в течение которого передаются пакеты Echo-Nonce, зависит от настроек реализации. Маршрутизатор xTR, получающий пакеты с запросом Echo-Nonce, выходит из состояния Echo-Nonce и устанавливает таймер Echo-Nonce-request-state, а по завершении его отсчёта возвращается в состояние Echo-Nonce.

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

Алгоритм Echo-Nonce является двухсторонним, т. е. если одна сторона устанавливает флаг E, а другая не включила Echo-Noncing, кодирование nonce не выполняется и запрашивающая сторона будет ошибочно считать, что локатор недоступен. ITR следует устанавливать бит E в инкапсулированных пакетах данных, когда ему известно, что на ETR включено Echo-Noncing. Это указывается флагом E в сообщении Map-Reply.

Многие реализации не анонсируют поддержку Echo-Nonce в сообщениях Map-Reply, поэтому для проверки доступности RLOC обычно применяется RLOC-Probing.

Механизм Echo-Nonce недопустимо применять в общедоступной сети Internet и он должен использоваться лишь в изолированных, доверенных средах (см. 16. Вопросы безопасности).

11. Доступность EID на сайте LISP

Сайт может быть многодомным и использовать два или более ETR. Хосты и инфраструктура сайта будут адресоваться с использованием одного или нескольких EID-Prefix, отображённых на RLOC соответствующих ETR в системе отображения. Одним из возможных вариантов отказа ETR является потеря связности с одним или несколькими EID-Prefix своего сайта. В таких случаях при отправке пакетов Map-Reply маршрутизатор ETR может сбрасывать (0) бит R, связанный с его локатором. Когда ETR служит также в качестве ITR, он может сбросить свой бит LSB в заголовке инкапсуляции данных.

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

12. Хэширование локаторов маршрутизации

Когда ETR представляет в сообщении Map-Reply отображение EID-RLOC, сохраняемое в Map-Cache запрашивающего ITR, Locator-Set для EID-Prefix может содержать разные значения Priority и Weight для каждого адреса локатора маршрутизации (Routing Locator Address). При наличии нескольких локаторов с лучшим приоритетом ITR может распределять трафик между соответствующими локаторами. Ниже приведён алгоритм, который ITR может использовать для пакета, адресованного EID, в отображении EID-RLOC.

1. Можно использовать хэш адреса отправителя и получателя или обычного квинтета (5-tuple). Обычно используемый хэш 5-tuple включает адреса отправителя и получателя, их номера портов TCP, UDP или SCTP⁴ и поле протокола IP или следующего протокола IPv6 из пакета, созданного хостом сайта LISP. Если пакет не относится к TCP, UDP, SCTP, для расчёта хэш-значения применяются лишь адреса отправителя и получателя.

2. Хэш-значение делится на число локаторов в Locator-Set для отображения EID-RLOC.

3. Остаток будет иметь значение от 0 до числа локаторов минус 1 и применяется для выбора локатора из Locator-Set.

Выбор конкретного алгоритма, применяемого ITR для распределения нагрузки, выходит за рамки этого документа и не препятствует совместимости. Порт источника следует сохранять одинаковым для всех пакетов одного потока. Отметим также, что при инкапсуляции пакетов в LISP нужно устанавливать номер порта во внешнем заголовке UDP. Выбор хэшированного значения позволяет маршрутизаторам ядра, соединенным с агрегатом каналов (Link Aggregation Group или LAG) распределять инкапсулированные пакеты между каналами LAG. В противном случае маршрутизаторы ядра будут лишь видеть один поток, поскольку в пакетах указан адрес ITR как отправителя для пакетов, исходящих от разных EID на сайте. Предлагается использовать в качестве порта источника, рассчитанное ITR хэш-значение 5-tuple из внутреннего заголовка, как указано выше. Порт отправителя следует сохранять для всех пакетов одного потока.

Многие реализации маршрутизаторов ядра применяют хэш 5-tuple для распределения нагрузки между каналами LAG. 5-tuple включает адреса и порты отправителя и получателя, когда номер протокола в пакете указывает TCP или UDP. Поэтому для инкапсуляции LISP применяется UDP. Когда внешним заголовком является IPv6, может устанавливаться также метка потока, как задано в [RFC6438]. Когда внутренним заголовком является IPv6 и метка потока отлична от 0, она может включаться в расчёт хэш-значения.

13. Изменение содержимого отображений EID на RLOC

Поскольку в архитектуре LISP для хранения и извлечения сопоставлений EID-RLOC применяется схема кэширования, ITR может получить более своевременное отображение только путём повторения запроса. ITR могут не знать о смене отображения, а ETR не отслеживают, какие ITR запрашивали отображения. Для расширяемости такой подход желательно сохранить, но разработчикам нужно предоставить ETR способ смены их отображений и информирования о такой смене сайты, взаимодействующие с сайтом ETR.

В этом разделе описаны два механизма плоскости данных для обновления отображений EID-RLOC. Кроме того, в [RFC9301] задан механизм запросов (Solicit-Map-Request или SMR).

13.1. Locator-Status-Bits

Биты состояния локаторов (LSB) могут служить для отслеживания статуса локаторов (up-down) при изменении отображений EID-RLOC. При использовании LSB в системе LISP все туннельные маршрутизаторы LISP должны реализовать возможности как ITR, так и ETR (т. е. фактически быть xTR). В этом параграфе термин xTR-источник указывает xTR, передающий LSB, а xTR-получатель — xTR, принимающий LSB. Процедура описана ниже.

1. При добавлении или удалении записи для локатора в Locator-Set xTR-источник будет сообщать об этом, передавая сообщение уровня управления SMR [RFC9301] xTR-получателю. В этот момент xTR-источнику недопустимо использовать поле LSB, если флаг L сброшен (0), поскольку сайт xTR-получателя имеет устаревшие сведения. Отправитель xTR устанавливает таймер use-LSB.

2. При получении сообщения SMR, как указано в [RFC9301], получатель xTR извлекает обновлённые отображения EID-RLOC путём отправки сообщений Map-Request.

3. По завершении отсчёта таймера use-LSB отправитель xTR снова может использовать LSB с xTR-получателем для информирования о статусе локаторов (up или down). Значение таймера use-LSB зависит от развёртывания LISP, но оно должно быть достаточно велико, чтобы xTR-получатель мог извлечь обновлённые отображения EID-RLOC. Рекомендуется устанавливать для таймера use-LSB значение 5 минут.

13.2. Версии базы данных отображений

Когда имеется односторонний поток данных между ITR и ETR, а отображения EID-RLOC на ETR меняются, нужно сообщить ITR, чтобы тот мог прекратить инкапсуляцию для удалённых локаторов и начать использовать добавленные в Locator-Set.

ETR может передать сообщения Map-Reply с номером Map-Version [RFC9302] в EID-Record. Этот номер называют Destination Map-Version Number. Маршрутизаторы ITR включают Destination Map-Version Number в пакеты, инкапсулируемые для сайта.

ITR при инкапсуляции пакетов для ETR может указать свой номер Map-Version — Source Map-Version Number.

При наличии в записях EID-Record сообщений Map-Register [RFC9301] номера Map-Version он является для Map-Server [RFC9301] хорошим способом обеспечить для всех зарегистрированных на нем ETR синхронизацию версий отображения.

Более подробно версии базы данных рассмотрены в [RFC9302].

14. Групповая передача

Адрес multicast-группы, как задано в исходной архитектуре Internet, является идентификатором группы топологически независимых хостов-получателей. Представление такого адреса не задаёт местоположения получателей и для его указания нужен протокол групповой маршрутизации и создаваемое протоколом состояние сети.

В контексте LISP групповой адрес является сразу EID и RLOC, поэтому для адреса получателя не требуется особой семантики, поскольку он указан в заголовке IP. Таким образом, групповой адрес IP, указанный во внутреннем заголовке хостом-источником, будет служить EID получателя. Внешний заголовок IP (RLOC получателя), добавляемый маршрутизатором LISP, может использовать в качестве RLOC получателя тот же групповой адрес, а также групповой или индивидуальный локатор RLOC, полученный при поиске в системе отображения или иным способом.

В качестве RLOC источника ITR использует свой адрес IP во внешнем заголовке IP, как при обмене с обычными EID. Этот адрес RLOC, как и все остальные RLOC, должен быть глобально маршрутизируемым.

Имеется два подхода к LISP-Multicast [RFC6831] — один на основе обычной multicast-маршрутизации в базовой сети без Mapping System, другой с использованием в базовой сети индивидуальной маршрутизации с поддержкой Mapping System (они описаны в [RFC6831] и [RFC8378], соответственно). Детали LISP-Multicast и взаимодействия с сайтами без поддержки LISP рассмотрены в [RFC6831] и [RFC6832], соответственно.

15. Работа маршрутизаторов

Протокол LISP разработан для аппаратной реализации, дружественной к пересылке (hardware based and forwarding friendly). Для поэтапного внедрения LISP имеется несколько методов.

• Когда ETR принимает инкапсулированный в туннель пакет, внешний адрес получателя может не быть адресом этого маршрутизатора. Это осложняет плоскости управления получение пакетов от оборудования. Проблему можно смягчить созданием специальных записей таблицы пересылки (Forwarding Information Base или FIB) для EID-Prefix адресов EID, обслуживаемых ETR (тех, для которых маршрутизатор транслирует RLOC). Эти записи FIB помечаются флагом, указывающим, что пакет следует обработать в плоскости пересылки. Логика пересылки для проверки конкретного номера протокола IP не требуется. Есть несколько подтверждённых вариантов, где не потребовалось менять имеющееся оборудование для поддержки плоскости данных LISP.

• На ITR добавление в начало нового заголовка IP состоит из добавления октетов в строку кода аутентификации сообщения (Message Authentication Code или MAC) и добавление этой строки в начало в процессе исходящей инкапсуляции. Маршрутизаторы с поддержкой туннелей GRE⁵ [RFC2784] или 6to4 [RFC3056] могут уже поддерживать это.

• Адрес источника пакета или интерфейс, на котором пакет был принят, могут служить для выбора экземпляра виртуальной маршрутизации и пересылки (Virtual Routing and Forwarding или VRF). Таблица маршрутизации VRF может служить для поиска отображений EID-RLOC.

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

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

Далее рассматриваются соображения безопасности, применимые при внедрении LISP в средах, подробных описанным в параграфе 1.1. Сфера применимости.

Предложен необязательный механизм сбора (gleaning) для прямого получения сопоставлений из пакетов с инкапсуляцией LISP. В частности, xTR может изучать отображения EID-RLOC, просматривая RLOC и EID источника в инкапсулированных пакетах и помещая найденные сопоставления в свой Map-Cache. Атакующий извне пути может подменить EID источника, чтобы направить переданный трафик на EID жертвы. Если атакующий подменит RLOC, он сможет организовать DoS-атаку перенаправляя трафик на RLOC, возможно, перегружая её.

Плоскость данных LISP задаёт несколько механизмов отслеживания доступности RLOC. В этом контексте биты статуса локаторов (LSB), присутствия nonce и Echo-Nonce в заголовке инкапсуляции LISP атакующий может изменять для организации DoS-атаки. Атакующий извне пути может подменить RLOC и или nonce маршрутизатора xTR жертвы для анонсирования ложных сведений о статусе доступности RLOC.

Примером таких атак является случай, когда размещённый вне пути злоумышленник может использовать механизм Echo-Nonce, передавая маршрутизатору ITR пакеты данных со случайным значением nonce от фиктивного RLOC маршрутизатора ETR. Отметим, что у атакующего имеется лишь небольшой интервал времени, в течение которого ему нужно угадать значение nonce, отражение которого запросил маршрутизатор ITR. Цель заключается в том, чтобы убедить ITR, что RLOC маршрутизатора ETR доступен, даже если это не так. При успешной атаке ITR будет полагаться на ложный статус доступности RLOC маршрутизатора ETR, пока RLOC-Probing не обнаружит реальный статус. Этот интервал имеет порядок десятков секунд. Такие атаки можно смягчить предотвращая подмену RLOC в сети за счёт развёртывания uRPF⁶ в соответствии с BCP 84 [RFC8704]. Для использования этой уязвимости расположенный вне пути злоумышленник должен передавать пакеты Echo-Nonce с высокой скоростью. Если ITR не запрашивает nonce, он может защитить себя от ложных сведений о доступности.

Возможна проверка uRPF для LISP. При декапсуляции ETR может проверять корректность EID и RLOC по отображению EID-RLOC в Mapping System.

Map-Versioning — это механизм плоскости данных, используемый для сигнализации xTR-партнерам о смене локального отображения EID-RLOC, чтобы партнёры xTR использовали сигнальные сообщения плоскости управления LISP для извлечения свежего сопоставления. Злоумышленник может подменить поле Map-Version в заголовке инкапсуляции LISP и вызвать избыточную сигнализацию между xTR с целью их перегрузки. Вопросы безопасности использования Map-Versioning рассмотрены в [RFC9302].

Биты LSB, механизм Echo-Nonce и Map-Versioning недопустимо применять в общедоступной сети Internet и следует использовать лишь в изолированных, доверенных средах. Кроме того, LSB следует сочетать с Map-Versioning для предотвращения состязаний, когда биты LSB относятся не к тем RLOC, для которых предназначены.

Реализациям и внедрениям LISP, допускающим фрагменты внешних заголовков пакетов IPv6 с инкапсуляцией LISP в качестве средства решения вопросов MTU, следует использовать в ETR методы, предотвращающие использования этого для DoS-атак. Можно использовать ограничение числа фрагментов, ожидающих сборки в ETR, RTR, PETR, и скорости восприятия таких пакетов.

17. Вопросы управления сетью

Соображения по инструментам оперативного управления стеком протоколов LISP приведены в [RFC7052] и [RFC6835].

18. Отличия от RFC 6830

С учётом опыта реализации после публикации [RFC6830] в документ были внесены указанные ниже изменения.

• Больше не используется ограничение на число заголовков LISP, добавляемых в начало пакета. Если приложению нужно более 2 заголовков LISP, реализация может поддерживать это. Однако рекомендуется применять не более 2 заголовков LISP.

• Использованы резервные флаги в заголовке LISP для [RFC8061]. Два младших бита 3-битового поля (KK) служат идентификатором ключа, а оставшийся бит сохранён как резервный.

• Сбор в плоскости данных для создания записей Map-Cache сделана необязательной. Любым реализациям ITR, которые зависят от сборки или предполагают, что удалённый ETR выполняет сбор, следует отказаться от этого. Проблем функциональной совместимости не возникает, поскольку процедуры заполнения Map-Cache в плоскости управления являются односторонними и служат типовым методом заполнения Map-Cache.

• Большинство изменений в этом документе, которые сократили его размер, связаны с переносом сообщений и процедур плоскости управления LISP в [RFC9301].

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

В этом разделе приведены рекомендации для IANA по части регистрации значений, связанных с этой спецификацией плоскости данных LISP, в соответствии с BCP 26 [RFC8126].

19.1. Номера портов LISP UDP

Агентство IANA выделило номер порта UDP 4341 для плоскости данных LISP с показанным ниже обновлением описания этого порта в реестре.

Таблица 1.

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

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

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

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

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

[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, DOI 10.17487/RFC2983, October 2000, <https://www.rfc-editor.org/info/rfc2983>.

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

[RFC6438] Carpenter, B. and S. Amante, «Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels», RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.

[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, «The Locator/ID Separation Protocol (LISP)», RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.

[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, «The Locator/ID Separation Protocol (LISP) for Multicast Environments», RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.

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

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

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8378] Moreno, V. and D. Farinacci, «Signal-Free Locator/ID Separation Protocol (LISP) Multicast», RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>.

[RFC8704] Sriram, K., Montgomery, D., and J. Haas, «Enhanced Feasible-Path Unicast Reverse Path Forwarding», BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, <https://www.rfc-editor.org/info/rfc8704>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., «Locator/ID Separation Protocol (LISP) Control Plane», RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, «Locator/ID Separation Protocol (LISP) Map-Versioning», RFC 9302, DOI 10.17487/RFC9302, October 2022, <https://www.rfc-editor.org/info/rfc9302>.

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

[AFN] IANA, «Address Family Numbers», <http://www.iana.org/assignments/address-family-numbers>.

[CHIAPPA] Chiappa, J., «Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture», 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.

[LISP-VPN] Moreno, V. and D. Farinacci, «LISP Virtual Private Networks (VPNs)», Work in Progress, Internet-Draft, draft-ietf-lisp-vpn-10, 3 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-10>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

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

[RFC2453] Malkin, G., «RIP Version 2», STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

[RFC2677] Greene, M., Cucchiara, J., and J. Luciani, «Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)», RFC 2677, DOI 10.17487/RFC2677, August 1999, <https://www.rfc-editor.org/info/rfc2677>.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.

[RFC3056] Carpenter, B. and K. Moore, «Connection of IPv6 Domains via IPv4 Clouds», RFC 3056, DOI 10.17487/RFC3056, February 2001, <https://www.rfc-editor.org/info/rfc3056>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4459] Savola, P., «MTU and Fragmentation Issues with In-the-Network Tunneling», RFC 4459, DOI 10.17487/RFC4459, April 2006, <https://www.rfc-editor.org/info/rfc4459>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

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

[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., «Report from the IAB Workshop on Routing and Addressing», RFC 4984, DOI 10.17487/RFC4984, September 2007, <https://www.rfc-editor.org/info/rfc4984>.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, «Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites», RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.

[RFC6835] Farinacci, D. and D. Meyer, «The Locator/ID Separation Protocol Internet Groper (LIG)», RFC 6835, DOI 10.17487/RFC6835, January 2013, <https://www.rfc-editor.org/info/rfc6835>.

[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, «IPv6 and UDP Checksums for Tunneled Packets», RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.

[RFC6936] Fairhurst, G. and M. Westerlund, «Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums», RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.

[RFC7052] Schudel, G., Jain, A., and V. Moreno, «Locator/ID Separation Protocol (LISP) MIB», RFC 7052, DOI 10.17487/RFC7052, October 2013, <https://www.rfc-editor.org/info/rfc7052>.

[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, «Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations», RFC 7215, DOI 10.17487/RFC7215, April 2014, <https://www.rfc-editor.org/info/rfc7215>.

[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, «LISP Canonical Address Format (LCAF)», RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.

[RFC8061] Farinacci, D. and B. Weis, «Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality», RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>.

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

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., «Path MTU Discovery for IP version 6», STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, «Packetization Layer Path MTU Discovery for Datagram Transports», RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.

[RFC9299] Cabellos, A. and D. Saucez, Ed., «An Architectural Introduction to the Locator/ID Separation Protocol (LISP)», RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.

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

Первая благодарность Dave Oran за посеянные семена исходных идей LISP. Его консультации продолжают приносить пользу авторам LISP.

Особая признательность выражается Noel Chiappa за многолетнее подталкивание к архитектуре отделения местоположения от идентификации, а также за подробные обзоры архитектуры и документов LISP в сочетании с энтузиазмом, направленным на то, чтобы сделать LISP практичным для постепенного внедрения в Internet.

Первоначальные авторы благодарят множество людей, которые внесли свой вклад в обсуждение идей при подготовке этого предложения. Среди них Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras, Alberto Rodriguez.

Эта работа началась в исследовательской группе Routing (RRG) под эгидой IRTF. Индивидуальное представление превратилось в документ рабочей группы IETF LISP, который стал этим RFC.

Рабочая группа LISP хотела бы выразить особую благодарность Jari Arkko (Internet Area AD во время подготовки документов LISP к IESG Last Call) за его детальные обзоры и комментарии на 7 Working Group Last Call при подготовке документов в качестве Standards Track RFC.

Текущие авторы хотели бы выразить искреннюю признательность всем, кто помогал представить LISP в процессе IETF Standards Track. Среди них Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Resnick, Colin Perkins, Mirja Kühlewind, Francis Dupont, Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, John Drake. Их влад существенно улучшил архитектуру и протоколы LISP в плане безопасности, расширяемости и отказоустойчивости.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      M. Kühlewind
Request for Comments: 9308                                      Ericsson
Category: Informational                                      B. Trammell
ISSN: 2070-1721                                  Google Switzerland GmbH
                                                          September 2022

Applicability of the QUIC Transport Protocol

Применимость транспортного протокола QUIC

PDF

Аннотация

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

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

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

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

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

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

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

Новый транспортный протокол QUIC [QUIC] обеспечивает ряд расширенных функций. Хотя протокол разрабатывался для HTTP, он предоставляет возможности для более широкого круга приложений. QUIC инкапсулируется в UDP. QUIC версии 1 интегрирован с TLS 1.3 [TLS13] для шифрования всего содержимого и большей части данных управления. Версию HTTP, использующую QUIC, называют HTTP/3 [QUIC-HTTP].

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

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

2. Необходимость отката

QUIC использует UDP в качестве основы. Это позволяет реализацию в пользовательском пространстве и обеспечивает прохождение промежуточных устройств (включая NAT) без обновления имеющейся инфраструктуры.

Измерения показывают, что от 3% [Trammell16] до 5% [Swett16] сетей блокируют весь трафик UDP, при этом мало свидетельств других форм систематических недостатков UDP по сравнению с TCP [Edeline16]. Блокировка подразумевает, что все приложения, работающие на основе QUIC, должны быть готовы к отказу в соединениях через такие сети или разработаны с возможностью отката к другому транспортному протоколу. В случае HTTP таким откатом является использование TLS на основе TCP.

Спецификация транспортных служб IETF (Transport Services или TAPS) [TAPS-ARCH] описывает систему с общим API для разных протоколов. Это особенно актуально для QUIC, поскольку решает проблему отката с использованием нескольких протоколов.

В частности, нужно избегать отката к незащищённым протоколам или слабым версиям протоколов с защитой. В общем случае приложениям, реализующим откат, необходимо учитывать влияние тката на безопасность. Откат к TCP и TLS раскрывает управляющую информацию для изменения и манипуляций в сети. Кроме того, откат к TLS версии ниже 1.3, которая применяется в QUIC версии 1, может вести к существенному ослаблению криптографической защиты. Например, результаты согласования протокола [RFC7301] имеют защиту конфиденциальности лишь при использовании TLS 1.3.

Эти приложения должны работать, возможно, с нарушением функциональности при отсутствии обеспечиваемых QUIC функций в резервном (fallback) протоколе. При откате к TLS через TCP наиболее очевидным отличием является отсутствие в TCP мультиплексирования потоков, требующее реализации такого мультиплексирования на уровне приложения. Кроме того, реализации TCP и сетевые пути зачастую не поддерживают опцию TCP Fast Open (TFO) [RFC7413], позволяющую передавать содержимое в первом пакете управления для новых соединений, тогда как возобновление сессий 0-RTT в QUIC позволяет это. Отметим, что имеются свидетельства блокировки данных в SYN даже при успешном согласовании TFO (см. [PaaschNanog]). И даже при сквозной работе Fast Open опция ограничена одним пакетом согласования TLS и данных приложения, в отличие от QUIC 0-RTT.

Хотя шифрование (в данном случае TLS) неразрывно связано с QUIC, согласование TLS через TCP может быть заблокировано. Если TLS через TCP не может поддерживаться, соединение следует прерывать, а затем приложение должно подобающим способом уведомить пользователя о недоступности защищённых коммуникаций.

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

3. 0-RTT

QUIC поддерживает организацию соединений 0-RTT. Хотя такая же возможность обеспечивается в TLS 1.3 с TCP, с механизмом 0-RTT связаны свои возможности и проблемы для приложений, использующих QUIC.

Транспортный протокол, обеспечивающий организацию соединений 0-RTT, качественно отличается от протоколов без 0-RTT с точки зрения использующих протокол приложений. Стоимость закрытия соединения с последующим повторным открытием и попытки сохранить соединение открытым различаются (см. параграф 3.2. Восстановление сессий по сравнению с Keep-Alive).

Приложению нужно сознательно выбирать применение 0-RTT, поскольку с этим механизмом связан риск replay-атак. Для использующих 0-RTT прикладных протоколов требуется профиль, описывающий типы информации, которую можно передавать без опаски. Для HTTP этот профиль описан в [HTTP-REPLAY].

3.1. Replay-атаки

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

Данные приложения, переданные в пакетах 0-RTT, могут обрабатываться неоднократно при их повторном использовании (replay). Приложения должны понимать, что можно безопасно передавать в 0-RTT. Прикладные протоколы, стремящиеся применять 0-RTT, должны тщательно анализировать и описывать возможное содержимое пакетов 0-RTT (см. параграф 5.6 в [QUIC-TLS]).

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

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

Некоторые реализации и развёртывания TLS могут обеспечивать частичную и даже полную защиту от replay-атак, которая может служить для контроля рисков.

3.2. Восстановление сессий по сравнению с Keep-Alive

Поскольку QUIC инкапсулируется в UDP, использующие QUIC приложения должны иметь дело с короткими тайм-аутами бездействия сети. Развёрнутые промежуточные устройства с поддержкой состояния обычно создают состояние для потока UDP по первому переданному пакету и сохраняют его в течение периода бездействия значительно более короткого, чем для TCP. В [RFC5382] предложен период бездействия для TCP не менее 124 минуту, хотя в литературе не упоминается о широком применении этого правила. Однако короткий период ожидания для UDP чётко документирован. Согласно исследованию 2010 г. ([Hatonen10]), приложения UDP могут предполагать, что любая привязка NAT или иное состояние могут истекать после 30 секунд бездействия. В параграфе 3.5 [RFC8085] рассмотрены интервалы keep-alive для UDP и требуется минимальное значение 15 секунд с рекомендацией использовать более долгие интервалы или совсем отказаться от keep-alive.

За счёт применения идентификаторов соединений протокол QUIC более устойчив к сменам привязки NAT по тайм-ауту. Однако это помогает лишь в тех случаях, когда конечная точка сохраняет доступность по адресу, известному её партнёру и этот партнёр передаёт данные после тайм-аута.

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

Приложения QUIC могут настраивать период бездействия для контроля риска тайм-аутов. Периоды бездействия и тайм-аут простоя в сети отличаются от тайм-аута бездействия соединения, который определяется меньшим значением тайм-аута бездействия конечных точек (см. параграф 10.1 в [QUIC]). Здесь возможны три варианта.

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

• Предотвращение продолжительных интервалов бездействия.

• Восстановление сессии после долгого бездействия с применением 0-RTT, когда это уместно.

Первый вариант проще всего, но подходит лишь для определённых приложений.

Сервер или клиент в приложении QUIC могут передавать кадры PING для сохранения активности (keep-alive) соединения и состояний на пути от возникновения тайм-аута. Рекомендации по использованию keep-alive зависят от приложения в основном из-за требований к задержке и частоте сообщений. В этом случае прикладное отображение должно указывать, кто отвечает за сохранение соединения — клиент или сервер. Хотя [Hatonen10] предполагается, что 30 секунд будет достаточно для общедоступной сети Internet при наличии в пути NAT, предпочтительней большие значения, если развёртывание может выдерживать смену привязки NAT или известно, что оно размещается в контролируемой среде (например, ЦОД), для снижения загрузки сети и расчётных издержек.

Передача кадров PING с интервалом менее 30 секунд в периоды бездействия может в некоторых случаях приводить к избыточному непродуктивному трафику и неприемлемому расходу батарей в (мобильных) устройствах. Кроме того, тайм-ауты меньше 30 секунд могут затруднять обработку временных перебоев в сети, таких как перенос виртуальных машин (Virtual Machine или VM) или потеря связи в результате перемещения (см. [RFC8085], особенно параграф 3.5).

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

Компромисс между возобновлением и keep-alive следует выбирать отдельно для каждого приложения. В общем случае приложениям следует применять keep-alive лишь в ситуациях, когда непрерывность коммуникаций очень важна, например, [QUIC-HTTP] рекомендует использовать keep-alive только при наличии находящихся в обработке запросов.

4. Использование потоков

Функция мультиплексирования потоков QUIC позволяет приложениям использовать несколько потоков в одном соединении без возникновения конфликтов (блокировка head-of-line) между ними. Данные потоков передаются в кадрах и один пакет QUIC в линии может включать один или несколько кадров потоков.

Потоки могут быть односторонними или двухсторонними и инициировать их может как клиент, так и сервер. В одностороннем потоке данные может передавать лишь его инициатор.

Потоки и соединения могут передать не более 2⁶²-1 байтов в каждом направлении из-за ограничений кодирования смещений в потоке и управления потоком данных в соединении. В маловероятном на сегодняшний день случае достижения предела потребуется организовать новое соединение.

Потоки можно открывать и закрывать независимо, аккуратно или жёстко. Приложение может аккуратно закрыть исходящее направление, указав QUIC установку бита FIN в кадре STREAM. Входящее направление нельзя аккуратно закрыть без созданного партнёром FIN (как в TCP). Однако конечная точка может жёстко закрыть исходящее направление или запросить у партнёра жёсткое закрытие входящего направления, эти действия не зависят одно от другого.

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

Отображение данных приложения в потоки зависит от приложения и для HTTP/3 описано в [QUIC-HTTP]. Имеется несколько базовых принципов разработки приложений, использующих потоки.

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

• Несколько потоков обеспечивают распараллеливание. Данные могут обрабатываться независимо и может возникать блокировка head-of-line (пробка), если принудительно упорядочивать их приём данных, отправленных в разных потоках.

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

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

QUIC выделяет числовой идентификатор (stream ID) для каждого потока. Хотя взаимосвязь между этими идентификаторами и типами потоков чётко задана в QUIC версии 1, будущие спецификации могут поменять её для других версий. Реализациям QUIC следует раскрывать свойства каждого потока (инициатор, число направлений, идентификатор), а приложениям следует запрашивать эти свойства, не пытаясь вывести их из идентификатора потока.

Метод назначения идентификаторов созданным приложением потокам может зависеть от реализации транспорта, поэтому приложениям не следует предполагать, что потоку, который ещё не создан, будет назначен определённый идентификатор. Например, HTTP/3 использует идентификаторы потоков для указания уже созданных потоков и не принимает допущений относительно будущих идентификаторов и способов их назначения (раздел 6 в [QUIC-HTTP]).

4.1. Мультиплексирование потоков

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

4.2. Приоритизация

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

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

4.3. Упорядоченная и надёжная доставка

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

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

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

4.4. Блокировка управления потоком данных

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

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

Размер и частота обновлений кредита управления потоком данных могут влиять на производительность. Использующие QUIC приложения часто имеют потребителя данных, читающего данные из транспортных буферов. У некоторых реализаций могут быть независимые буферы приёма на транспортном и прикладном уровне. Потребление данных не всегда подразумевает их незамедлительную обработку, однако общим методом реализации служит расширение кредита управления потоком данных для отправителя путём отправки кадров MAX_DATA и/или MAX_STREAM_DATA по мере потребления данных. На доставку этих кадров влияет задержка в канале передачи от получателя к отправителю данных. Если кредит своевременно не расширяется, передающее приложение может быть заблокировано, фактически останавливая передачу.

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

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

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

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

Некоторые случаи блокировки можно преодолеть путём отмены затрагиваемых потоков с помощью STOP_SENDING или RESET_STREAM. Отмена некоторых потоков в некоторых протоколах может приводить к обрыву соединения.

4.5. Обязательства по ограничению числа потоков

Конечные точки QUIC отвечают за передачу совокупного предела числа потоков, которые они позволяют открыть партнёру. Исходные ограничения анонсируются в транспортных параметрах initial_max_streams_bidi и initial_max_streams_uni. По мере открытия и закрытия потоков они потребляются и совокупное значение инкрементируется. Пределы можно увеличить с помощью кадров MAX_STREAMS, но механизмов снижения нет. По достижении предельного числа потоков, дополнительные потоки создать невозможно и использующее QUIC приложение не сможет двигаться дальше. В этом случае соединения могут быть прерваны по тайм-ауту или явным закрытием, как описано в разделе 10 10.

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

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

Вместо предотвращения грубого закрытия на основе ограничения числа потоков может применяться механизм аккуратного закрытия на прикладном уровне, чтобы сообщить о намерении закрыть соединение в некоторый будущий момент. В HTTP/3 для этого применяется кадр GOAWAY, при получении которого клиент прекращает создание новых потоков, даже до достижения порога. Вместо этого клиент создаёт новое соединение, в котором будут открываться последующие потоки. Как только все потоки старого соединения будут закрыты, его можно безопасно прервать сразу или по тайм-ауту бездействия (см. 10. Завершение соединений).

5. Пакетизация и задержка

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

По умолчанию многие реализации пытаются упаковать кадры STREAM одного или нескольких потоков в каждый пакет QUIC для минимизации расхода пропускной способности и вычислительных издержек (см. раздел 13 в [QUIC]). Если для заполнения пакета недостаточно данных, реализация может подождать в течение короткого времени для оптимизации пропускной способности за счёт задержки. Эта задержка может настраиваться или устанавливаться динамически на основе наблюдаемой картины передачи данных приложением.

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

Точно так же, приложение обычно не может контролировать размер пакетов QUIC в линии. QUIC предоставляет возможность добавлять кадры PADDING для произвольного увеличения размера пакетов. Заполнение применяется в QUIC для того, чтобы передавать дейтаграммы не меньше согласованного размера (см. параграфы 8.1 и 14.1 в [QUIC]) и проверять путь после переноса соединения (см. параграф 8.2 в [QUIC]), а также для определения PMTU (Datagram Packetization Layer PMTU Discovery или DPLPMTUD, см. параграф 14.3 в [QUIC]).

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

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

QUIC рекомендует конечным точкам информировать партнёра обо всех обнаруженных ошибках. Ошибки могут возникать на транспортном и прикладном уровне. Транспортные ошибки, такие как нарушение протокола, влияют на соединение в целом. Использующее QUIC приложение может определять свои средства обнаружения и сигнализации для ошибок (см., например, раздел 8 в [QUIC-HTTP]). Ошибки приложения влияют на соединение или отдельный поток.

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

Применяющие QUIC приложения определяют своё пространство кодов, независимое от QUIC и других приложений (см., например, параграф 8.1 в [QUIC-HTTP]). Значения кодов ошибок приложения могут совпадать с кодами ошибок на уровне соединения или потока.

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

Ошибки потока ведут к прерыванию потока. Они передаются с помощью кадров STOP_SENDING или RESET_STREAM, содержащих лишь код ошибки.

7. Эффективность подтверждений

В QUIC версии 1 без расширений применяется стратегия подтверждений TCP (см. параграф 13.2 в [QUIC]), т. е. рекомендуется подтверждать каждый второй пакет. Однако для создания и обработки подтверждений QUIC расходуются ресурсы отправителя и получателя. С подтверждениями также связаны расходы на пересылку и расход пропускной способности каналов, что может влиять на производительность в некоторых типах сетей. Приложения могут повысить общую производительность, применяя иную стратегию с меньшей частотой подтверждений. В [QUIC-ACK-FREQUENCY] описано расширение для сигнализации желаемой задержки подтверждений и обсуждаются варианты его применения, а также влияние на контроль перегрузок и восстановление при ошибках.

8. Выбор порта и обнаружение конечных точек приложения

В общем случае номера портов служат для двух целей: «во-первых, они обеспечивают идентификаторы демультиплексирования для различения транспортных сессий между парой конечных точек, во-вторых, они могут указывать прикладной протокол и связанную службу, к которой подключены процессы» (раздел 3 в [RFC6335]). Допущение о возможности идентификации приложения в сети по номеру порта сегодня не так верно по причине инкапсуляции и механизмов динамического назначения портов, как отмечено в [RFC6335].

Поскольку QUIC является транспортным протоколом общего назначения, в нем не задаётся требований по использованию конкретного порта UDP. Для приложений с откатом к TCP, у которых ещё нет альтернативного сопоставления с UDP, обычно целесообразна регистрация (при необходимости) и использование порта UDP, соответствующего уже зарегистрированному для приложения порту TCP. Например, принятым по умолчанию для HTTP/3 [QUIC-HTTP] является порт UDP 443, аналогично HTTP/1.1 и HTTP/2 через TLS по протоколу TCP.

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

Приложения могут определять иной механизм обнаружения конечных точек, позволяющий использовать номера портов, отличные от принятых по умолчанию. Например, HTTP/3 (параграфы 3.2 и 3.3 в [QUIC-HTTP]) задаёт применение HTTP Alternative Services [RFC7838] для источника HTTP, чтобы анонсировать доступность эквивалентной конечной точки HTTP/3 на неком порту UDP путём использования h3 в качестве маркера согласования протокола прикладного уровня (Application-Layer Protocol Negotiation или ALPN) [RFC7301].

ALPN позволяет клиенту и серверу согласовать, какой из нескольких возможных протоколов будет применяться в данном соединении. Следовательно, на одном порту UDP может поддерживаться несколько приложений, разделяемых по маркерам ALPN. Применяющие QUIC приложения должны регистрировать маркер ALPN, используемый в согласовании TLS.

Поскольку QUIC версии 1 не определяет полностью механизм согласования, HTTP/3 требует QUIC версии 1 и определяет маркер ALPN (h3) для применения лишь с этой версией. До сих пор не выбрано единого подхода для управления использованием разных версий QUIC ни в HTTP/3, ни в общем случае. Использующие QUIC прикладные протоколы должны рассматривать управление версиями протокола QUIC. Решения для этих протоколов могут основываться на выборе, сделанном другими протоколами, такими как HTTP/3.

8.1. Выбор порта источника

Некоторые протоколы UDP уязвимы для атак с отражением, где злоумышленник способен использовать сторонний трафик для атаки на службы (denial of service). Например, приведённые ниже номера портов связаны с приложениями, уязвимыми для атак с отражением (часто из-за неверной нестройки серверов).

• 53 — DNS [RFC1034].

• 123 — NTP [RFC5905].

• 1900 — SSDP [SSDP].

• 5353 — mDNS [RFC6762].

• 11211 — memcache.

Службы могут блокировать порты источника, связанные со протоколами, уязвимыми для атак с отражением, чтобы избежать издержек на обработку большого числа пакетов. Однако такая практика оказывает негативное влияние на клиентов, не только требуя организации нового соединения, но и приводя к отказу некоторых экземпляров от применения QUIC для службы на некоторое время и откату к отличному от UDP протоколу (2. Необходимость отката).

В результате реализациям клиентов рекомендуется избегать применения портов источника, связанных с протоколами, для которых известно об уязвимости для атак с отражением. Отметим, что в соответствии с общими рекомендациями для реализации клиентов в [RFC6335], приложения будут избегать использования эфемерных портов 49152-65535. Отметим, что другие номера портов также могут применяться для отражения.

9. Перенос соединений

QUIC поддерживает перенос соединений на стороне клиента. Если меняется IP-адрес клиента, конечная точка QUIC по-прежнему связывает пакеты с имеющимся транспортным соединением по полю Destination Connection ID (11. Раскрытие информации и идентификаторы соединений) в заголовке QUIC. Это подходит для случаев, когда адрес меняется, таких как смена привязки NAT, преднамеренная смена локального интерфейса, завершение срока действия временного адреса IPv6 [RFC8981], указание сервером предпочтительного адреса (параграф 9.6 в [QUIC]).

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

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

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

В QUIC версии 1 поддерживается активный перенос лишь для клиентов. Однако серверы могут указать в процессе согласования своё предпочтение переноса соединения на другой адрес после согласования. Это может служить, например, для перехода с адреса, используемого несколькими серверами, на уникальный адрес данного экземпляра. Сервер может представить адрес IPv4 и IPv6 в транспортном параметре при согласовании TLS, а клиент может выбрать один из этих двух адресов (см. параграф 9.6 в [QUIC]).

10. Завершение соединений

Соединения QUIC прерываются одним из 3 способов: неявный тайм-аут простоя, явное незамедлительное закрытие, явный сброс без учёта состояния.

QUIC не предоставляет механизма аккуратного завершения соединений, применяющее QUIC приложение может определить свой процесс аккуратного завершения (см., например, параграф 5.2 в [QUIC-HTTP]).

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

Данные приложений, передаваемые в потоках или дейтаграммах откладывают тайм-аут бездействия QUIC. Приложения со своим механизмом keep-alive будут, таким образом, сохранять соединение QUIC. Приложения без keep-alive могут использовать механизмы транспортного уровня (см. параграф 10.1.2 в [QUIC] и 3.2. Восстановление сессий по сравнению с Keep-Alive). Однако интерфейсы QUIC для управления поведением транспорта могут различаться, что влияет на отказоустойчивость.

Незамедлительное закрытие указывается кадром CONNECTION_CLOSE (см. 6. Обработка ошибок) и приводит к немедленному закрытию всех потоков, что может влиять на приложения (см. 4.5. Обязательства по ограничению числа потоков).

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

11. Раскрытие информации и идентификаторы соединений

QUIC раскрывает в сеть некоторую информацию из нешифрованной части заголовка до организации контекста шифрования или потому, что сведения предназначены для использования в сети. Для получения дополнительной информации об управляемости QUIC см. [QUIC-MANAGEABILITY]. Протокол QUIC использует длинный заголовок, раскрывающий некоторую дополнительную информацию (версия и идентификатор соединения у источника), хотя короткий заголовок раскрывает лишь идентификатор соединения у получателя. В QUIC версии 1 длинный заголовок применяется при организации соединения, а короткий — при передаче данных в имеющемся соединении.

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

Конечная точка, выбравшая идентификатор нулевого размера, будет получать пакеты с идентификатором соединения для получателя нулевого размера. Конечной точке потребуется использовать другие сведения, такие как IP-адрес и номер порта источника и получателя. Это может означать неспособность конечной точки сопоставить дейтаграммы с соединениями, если эти значения меняются, что делает невозможной для соединения смену привязки NAT или перенос на новый путь.

11.1. Создаваемый сервером идентификатор соединения

QUIC поддерживает созданные сервером идентификаторы соединений, передаваемые клиентам при организации соединения (см. параграф 7.2 в [QUIC]). Серверам за балансировщиком нагрузки может потребоваться смена идентификатора соединения в процессе согласования, кодируя отождествление сервера или сведения о пуле балансирования нагрузки, чтобы обеспечить балансировку без поддержки состояния.

Развёртывания серверов с балансировщиками нагрузки и другой инфраструктурой маршрутизации должны гарантировать, что эта инфраструктура согласованно маршрутизирует пакеты экземпляру сервера, который имеет состояние соединения даже при смене адресов, портов или идентификатора соединения. Это может потребовать координации между серверами и инфраструктурой. Одним из методов является кодирование маршрутной информации в идентификаторе соединения. Пример этого метода представлен в [QUIC-LB].

11.2. Снижение возможности привязки путём смены идентификаторов

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

Хотя достаточно надёжные схемы генерации идентификаторов соединений смягчают проблему привязки, они не обеспечивают полной защиты. Анализ сроков действия секстетов (6-tuple — адреса отправителя и получателя, а также перенесённый Connection ID) позволяет выявить связи.

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

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

11.3. Использование серверных пакетов Retry для перенаправления

QUIC поддерживает пакеты Retry, которые сервер может передавать в ответ на пакет Initial от клиента. Сервер может указать в этом пакете новый идентификатор соединения и клиент будут передавать другой пакет Initial с выбранным сервером идентификатором. Этот механизм можно использовать для перенаправления соединения на дугой сервер, например, из соображений производительности или при поэтапном обновлении серверов пула, когда они могут применять разные версии QUIC.

В этом случае предполагается, что все серверы того или иного пула координируются с балансировщиками нагрузки, пересылающими трафик по идентификаторам соединений. Сервер может указать идентификатор соединения в пакете Retry так, что балансировщик перенаправит следующий пакет Initial другому серверу того же пула. Дополнительно балансировщик может напрямую предлагать выгрузку Retry, как описано в [QUIC-RETRY].

Подход, описанный в разделе 4 [RFC5077] для создания квитанций возобновления TLS, служит примером, который подходит также для маркером проверки. Однако настоятельно рекомендуется применять более современные криптографические алгоритмы.

12. QoS и DSCP

QUIC, как определено в [QUIC], имеет один контроллер перегрузок и обработчик восстановления. Это подразумевает, что все пакеты в соединении QUIC или, по меньшей мере, пакеты с одним квинтетом (5-tuple) {dest addr, source addr, protocol, dest port, source port}, которые имеют один код дифференцированного обслуживания (Diffserv Code Point или DSCP) [RFC2475] будут иметь близкую трактовку в сети, поскольку отклики о потерях или задержке пакетов служат вводом для контроллера перегрузок. Поэтому пакетам одного соединения следует использовать один код DSCP. В параграфе 5.1 [RFC7657] рассматривается взаимодействие Diffserv с протоколами доставки дейтаграмм [RFC7657] (в этом отношении взаимодействие с QUIC похоже на взаимодействие с SCTP).

При мультиплексировании нескольких потоков в одном соединении QUIC выбирать следует значение DSCP, связанное с наибольшим приоритетом среди мультиплексируемых потоков.

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

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

13. Согласование версии и криптографии

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

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

Реестр QUIC Versions, организованный в [QUIC], позволяет выполнять предварительную регистрацию для экспериментов. Регистрация важна для предотвращения конфликтов, в том числе с экспериментальными версиями. Экспериментальные версии не следует использовать в течение длительного времени или регистрировать постоянно, чтобы минимизировать риск взятия отпечатков (fingerprinting) по номеру версии.

14. Развёртывание новых версий

QUIC версии 1 не задаёт механизма согласования версии в базовой спецификации, но [QUIC-VERSION-NEGOTIATION] предлагает расширение, обеспечивающее совместимое согласование версии.

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

Подробности приведены в разделе 5 [QUIC-VERSION-NEGOTIATION].

15. Доставка дейтаграмм по протоколу QUIC без гарантий

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

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

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

Этот документ не требует действий IANA. Однако раздел 8 рекомендует приложениям, которые уже зарегистрировали порт TCP, но хотят задать QUIC в качестве транспорта, регистрировать порт UDP, идентичный заданному для TCP.

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

См. обсуждение вопросов безопасности в [QUIC] и [QUIC-TLS]. Соображения безопасности для базового транспортного протокола применимы и к использующим QUIC приложениям. Вопросы связывания, атак с воспроизведением (replay) и случайных значений, рассмотренные в [QUIC-TLS], следует цчитывать при развёртывании и применении QUIC.

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

Разработчикам приложений следует учитывать, что при любом откате, применяемом при невозможности использовать QUIC по причине блокировки UDP в сети, следует обеспечивать такие же свойства защиты, как в QUIC. Если это невозможно, соединению не следует позволять приложению явно выполнять откат к менее безопасному варианту (см. 2. Необходимость отката).

В [QUIC-HTTP] даны рекомендации по вопросам безопасности для HTTP. Однако такие вопросы, как кросс-протокольные атаки, анализ и заполнение трафика, перенос могут быть актуальны и для других приложений, применяющих QUIC.

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

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

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

[QUIC-INVARIANTS] Thomson, M., «Version-Independent Properties of QUIC», RFC 8999, DOI 10.17487/RFC8999, May 2021, <https://www.rfc-editor.org/info/rfc8999>.

[QUIC-TLS] 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>.

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

[Edeline16] Edeline, K., Kühlewind, M., Trammell, B., Aben, E., and B. Donnet, «Using UDP for Internet Transport Evolution», DOI 10.48550/arXiv.1612.07816, 22 December 2016, <https://arxiv.org/abs/1612.07816>.

[Hatonen10] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, «An Experimental Study of Home Gateway Characteristics», Proc. ACM IMC 2010, November 2010, <https://conferences.sigcomm.org/imc/2010/papers/p260.pdf>.

[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, «Using Early Data in HTTP», RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.

[PaaschNanog] Paasch, C., «Network support for TCP Fast Open», NANOG 67 Presentation, 13 June 2016, <https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf>.

[QUIC-ACK-FREQUENCY] Iyengar, J. and I. Swett, «QUIC Acknowledgement Frequency», Work in Progress, Internet-Draft, draft-ietf-quic-ack-frequency-02, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-02>.

[QUIC-HTTP] Bishop, M., Ed., «HTTP/3», RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.

[QUIC-LB] Duke, M., Banks, N., and C. Huitema, «QUIC-LB: Generating Routable QUIC Connection IDs», Work in Progress, Internet-Draft, draft-ietf-quic-load-balancers-14, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-14>.

[QUIC-MANAGEABILITY] Kühlewind, M. and B. Trammell, «Manageability of the QUIC Transport Protocol», RFC 9312, DOI 10.17487/RFC9312, September 2022, <https://www.rfc-editor.org/info/rfc9312>.

[QUIC-RETRY] Duke, M. and N. Banks, «QUIC Retry Offload», Work in Progress, Internet-Draft, draft-ietf-quic-retry-offload-00, 25 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-retry-offload-00>.

[QUIC-VERSION-NEGOTIATION] Schinazi, D. and E. Rescorla, «Compatible Version Negotiation for QUIC», Work in Progress, Internet-Draft, draft-ietf-quic-version-negotiation-10, 27 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation-10>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

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

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, «Transport Layer Security (TLS) Session Resumption without Server-Side State», RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.

[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, «NAT Behavioral Requirements for TCP», BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, «Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry», BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC6762] Cheshire, S. and M. Krochmal, «Multicast DNS», RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, «Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension», RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, «TCP Fast Open», RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[RFC7657] Black, D., Ed. and P. Jones, «Differentiated Services (Diffserv) and Real-Time Communication», RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC7838] Nottingham, M., McManus, P., and J. Reschke, «HTTP Alternative Services», RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.

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

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, «Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6», RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.

[RFC9218] Oku, K. and L. Pardue, «Extensible Prioritization Scheme for HTTP», RFC 9218, DOI 10.17487/RFC9218, June 2022, <https://www.rfc-editor.org/info/rfc9218>.

[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, «An Unreliable Datagram Extension to QUIC», RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/info/rfc9221>.

[SSDP] Donoho, A., Roe, B., Bodlaender, M., Gildred, J., Messer, A., Kim, Y., Fairman, B., and J. Tourzan, «UPnP Device Architecture 2.0», 17 April 2020, <https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf>.

[Swett16] Swett, I., «QUIC Deployment Experience @Google», IETF96 QUIC BoF Presentation, 20 July 2016, <https://www.ietf.org/proceedings/96/slides/slides-96-quic-3.pdf>.

[TAPS-ARCH] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and C. Perkins, «An Architecture for Transport Services», Work in Progress, Internet-Draft, draft-ietf-taps-arch-14, 27 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-14>.

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

[Trammell16] Trammell, B. and M. Kühlewind, «Internet Path Transparency Measurements using RIPE Atlas», RIPE 72 MAT Presentation, 25 May 2016, <https://ripe72.ripe.net/wp-content/uploads/presentations/86-atlas-udpdiff.pdf>.

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

Большое спасибо рецензентам Last Call — Chris Lonvick и Ines Robles.

Эта работа частично поддерживалась в рамках гранта Еврокомиссии Horizon 2020 № 688421 Measurement and Architecture for a Middleboxed Internet (MAMI) и контракта № 15.0268 с Государственным секретариатом Швейцарии по образованию, исследованиям и инновациям. Эта поддержка не предполагает одобрения (endorsement).

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

Ниже перечислены те, кто внёс существенный вклад в текст документа или предоставил отклики.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)              M. Jethanandani, Ed.
Request for Comments: 9314                           Xoriant Corporation
Updates: 9127                                             R. Rahman, Ed.
Category: Standards Track                                               
ISSN: 2070-1721                                            L. Zheng, Ed.
                                                     Huawei Technologies
                                                           S. Pallagatti
                                                                  VMware
                                                               G. Mirsky
                                                                Ericsson
                                                          September 2022

YANG Data Model for Bidirectional Forwarding Detection (BFD)

Модель данных YANG для BFD

PDF

Аннотация

Этот документ определяет модель данных YANG, которая может служить для настройки и управления двухсторонним обнаружениям пересылки (Bidirectional Forwarding Detection или BFD).

Модули YANG в этом документе соответствуют архитектуре хранилища данных управления сетью (Network Management Datastore Architecture или NMDA) (RFC 8342). Документ обновляет YANG Data Model for Bidirectional Forwarding Detection (BFD) (RFC 9127).

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

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

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

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

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

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, которая может служить для настройки и управления обнаружением двухсторонней пересылки (BFD) [RFC5880]. Протокол BFD применяется для обнаружения живучести произвольных путей между системами. Некоторые примеры путей, на которых применим протокол BFD указаны ниже.

1. Две системы, соединённые напрямую по IP. Это называется BFD через один интервал (single-hop) IP, а также BFD для IPv4 и IPv6 [RFC5881].

2. Две системы, соединённые через несколько интервалов пересылки, как описано в Bidirectional Forwarding Detection (BFD) for Multihop Paths [RFC5883].

3. Две системы, соединённые по пути с коммутацией по меткам MPLS (MPLS Label Switched Path или LSP), как описано в Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [RFC5884].

4. Две системы, соединённые через интерфейс группы агрегирования каналов (Link Aggregation Group или LAG), как описано в Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130].

5. Две системы, соединённые через псевдопровода (PW). Это называют проверкой связности виртуальных устройств (Virtual Circuit Connectivity Verification или VCCV), как описано в Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5885]. Данный вариант в документе не рассматривается.

BFD обычно не работает сам по себе. Различные протоколы управления (клиенты BFD) используют услуги BFD для своей работы, как описано в Generic Application of Bidirectional Forwarding Detection (BFD) [RFC5882]. Очевидными кандидатами на использование BFD являются протоколы, не имеющие своих сообщений hello для обнаружения отказов, например, статическая маршрутизация, протоколы маршрутизации, где сообщения hello не поддерживают обнаружение отказов за доли секунды, такие как OSPF и IS-IS.

Модули YANG в этом документе соответствуют архитектуре хранилищ NMDA [RFC8342]. Это значит, что модели данных не имеют контейнеров верхнего уровня или братских (sibling) контейнеров для данных конфигурации и рабочего состояния.

1.1. Диаграммы деревьев

В этом документе применяется графическое представление данных, определённое в [RFC8340].

2. Модель данных

Поскольку BFD применяется для определения живучести различных путей пересылки, единого ключа для идентификации сессий BFD нет. В результате модель данных BFD разделена на несколько модулей YANG, каждый из которых соответствует определённому типу путей. Например, BFD для IP с одной пересылкой имеет один модуль YANG, а BFD для MPLS — другой. Основным различием между этими модулями является способ однозначной идентификации сессий BFD для данного пути пересылки. Чтобы избежать дублирования определений BFD, базовые типы и группировки собраны в отдельном модуле.

Пределен новый протокол управления bfdv1 и создан контейнер bfd в control-plane-protocol, заданном в документе A YANG Data Model for Routing Management (NMDA Version) [RFC8349]. Этот новый контейнер bfd дополняется указанными ниже модулями YANG с конкретной информацией.

1. Модуль ietf-bfd-ip-sh (параграф 2.13) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером ip-sh для сессий BFD с одной пересылкой IP (single-hop).

2. Модуль ietf-bfd-ip-mh» (параграф 2.14) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером ip-mh для сессий BFD с несколькими пересылками IP (multihop).

3. Модуль ietf-bfd-lag» (параграф 2.15) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером lag для сессий BFD через LAG.

4. Модуль ietf-bfd-mpls» (параграф 2.16) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером mpls для сессий BFD через MPLS LSP.

BFD может работать в разном контексте, как указано ниже.

1. На уровне сетевого устройства.

2. В логический элементах сети (logical network element или LNE), как описано в YANG Model for Logical Network Elements [RFC8530].

3. В экземплярах сетей, как описано в YANG Data Model for Network Instances [RFC8529].

При использовании на уровне сетевого устройства модель данных YANG BFD применяется «как есть» (as is). При использовании модели YANG BFD в LNE или экземпляре сети эта модель дополняет имеющуюся модель маршрутизации для LNE или экземпляра сети.

2.1. Модель конфигурации

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

Клиентами BFD являются приложения, применяющие BFD для быстрого обнаружения отказов. В некоторых реализациях имеется настройка сессии BFD для клиентов BFD, например, для приложений маршрутизации, таких как OSPF, IS-IS, BGP. В других реализациях сессии BFD настраиваются на уровне BFD целиком, т. е. не по клиентам.

Основные параметры BFD, интересующие клиентов, относятся к множителям и интервалам, поскольку эти параметры влияют на время схождения у клиентов BFD при возникновении отказа. Другие параметры, например, аутентификация BFD, не зависят от требований клиентов BFD. Конфигурации BFD для всех клиентов следует быть централизованной. Однако это создаёт проблему для клиентов BFD, автоматически находящих своих партнёров. Например, в IGP адрес партнёра не настраивается, протокол IGP просто включается на интерфейсе и партнёры обнаруживаются автоматически. Таким образом, при настройке BFD для партнёра IGP оператору сначала нужно узнать адрес партнёра. При обнаружении нового партнера будет добавляться конфигурация BFD. Для предотвращения таких проблем задана группировка client-cfg-parms (параграф 2.11) для настройки BFD клиентами — это позволяет клиентами, таким как IGP, иметь конфигурацию (множитель и интервалы) для нужной сессии BFD. Например, при обнаружении нового партнёра IGP для него будет создаваться сессия BFD, а при утере партнёра IGP его сессия будет удаляться. Механизмы создания и удаления сессий BFD выходят за рамки этого документа, но обычно это выполняется с использованием API, реализованного в модуле BFD на системе. В случае клиентов BFD, создающий сессии BFD на основе своей конфигурации, параметры аутентификации (при необходимости) по-прежнему задаются в BFD.

2.1.1. Базовые параметры конфигурации BFD

Ниже перечислены базовые параметры конфигурации BFD.

local-multiplier

desired-min-tx-interval

required-min-rx-interval

Хотя BFD [RFC5880] разрашает разные интервалы для приёма и передачи, некоторые реализации позволяют пользователю задать лишь один интервал (для приёма и передачи). Модель данных YANG BFD поддерживает оба варианта и можно выбрать min-interval, используемый для приёма и передачи, а также desired-min-tx-interval и required-min-rx-interval. Это поддерживается через группировку base-cfg-parms (2.11. Модуль для типов BFD), применяемую модулями YANG для разных путей пересылки.

Для аутентификации BFD имеется два параметра.

key-chain

meticulous

2.1.2. IP с одной пересылкой

Для одной пересылки (single-hop) IP задано дополнение в узле данных bfd, как указано в параграфе 2. Узел ip-sh содержит список сессий IP single-hop, каждая из которых однозначно указывается интерфейсом и адресом получателя. Применяются параметры конфигурации, указанные в параграфе 2.1.1. Узел ip-sh содержит также список интерфейсов и служит для задания параметров аутентификации сессий BFD, создаваемых клиентами BFD (2.1. Модель конфигурации).

[RFC5880] и [RFC5881] не задают работу функции Echo непрерывно или по запросу. Поэтому механизм для запуска и остановки функции Echo зависит от реализации и должен задаваться через дополнение, как указано ниже.

1. Конфигурация. Подходит для непрерывной функции Echo (см. Приложение A. Пример настройки функции Echo).

2. RPC. Это подходит для функции Echo, работающей по запросам.

2.1.3. IP с множеством пересылок

Для IP с несколькими пересылками (multihop) задано дополнение в узле данных bfd, как указано в параграфе 2.

По причине наличия разных путей может возникать несколько сессий multihop IP между отправителем и получателем. Набор сессий называется session-group. Клюя для session-group состоит из двух элементов.

Source address — адрес отправителя

Destination address — адрес получателя

Применяются параметры конфигурации, указанные в параграфе 2.1.1.

Этот документ также определяет следующие параметры:

tx-ttl

rx-ttl

2.1.4. Пути с коммутацией по меткам MPLS

Здесь рассматриваются пути MPLS LSP, с которых классом эквивалентности пересылки (Forwarding Equivalence Class или FEC) [RFC3031] служит адрес IP. Узел bfd (параграф 2) дополнен узлом mpls со списком сессий, однозначно указываемых префиксомIP. По причине использования разных путей может быть несколько сессий MPLS для MPLS FEC. Набор этих сессий указывается в session-group.

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

Параметры BFD для выходного узла добавляются в иерархию mpls.

2.1.5. Группы агрегирования каналов

В соответствии с Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130] конфигурация BFD для LAG включает микросессии BFD для каждого канала в составе LAG. Поскольку параметры BFD являются атрибутами LAG, им следует находиться в иерархии LAG. Однако модели данных YANG для LAG не существует, поэтому узел lag добавлен к узлу bfd (параграф 2). Конфигурация задаётся на уровне LAG, имеется список групп LAG. IP-адрес получателя в микросессии BFD задаётся для LAG и семейства адресов (IPv4 или IPv6).

2.2. Модель рабочего состояния

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

1. Фундаментальные сведения о сессии BFD, такие как локальный и удалённый дискриминаторы, способность поддерживать режим Demand (по запросу).

2. Сведения о работе сессии BFD (session-running), например, удалённый статус BFD и полученный код диагностики. Тругим примером служит фактический интервал передачи управляющих пакетов, который может отличаться от заданного желаемого минимального интервала. Другие примеры включают фактические интервалы между получаемыми пакетами управления и передаваемыми пакетами Echo.

3. Подробные сведения о сессии, например, время включения-отключения (up/down), продолжительность состояния.

Для некоторых типов путей может быть более одной сессии на виртуальный путь к адресату. Например, в IP multihop и MPLS LSP может быть несколько сессий BFD от источника к одному получателю для тестирования разных путей (ECMP). Это представляется множеством sessions в иерархии каждой группы session-group.

2.3. Уведомления

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

2.4. Операции RPC

Нет.

2.5. Иерархия верхнего уровня BFD

В узле bfd (иерархия control-plane-protocol) нет данных конфигурации — только данные рабочего состояния, включающие общую статистику сессии BFD, т. е. BFD для вех типов путей пересылки.

   module: ietf-bfd
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol:
       +--rw bfd
          +--ro summary
             +--ro number-of-sessions?              yang:gauge32
             +--ro number-of-sessions-up?           yang:gauge32
             +--ro number-of-sessions-down?         yang:gauge32
             +--ro number-of-sessions-admin-down?   yang:gauge32

2.6. Иерархия BFD IP Single-Hop

Узел ip-sh добавляется в ветвь bfd иерархии control-plane-protocol. Этот узел содержит узлы данных конфигурации и рабочего состояния для каждой сессии BFD IP single-hop.

   module: ietf-bfd-ip-sh
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw ip-sh
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw sessions
          |  +--rw session* [interface dest-addr]
          |     +--rw interface                         if:interface-ref
          |     +--rw dest-addr                         inet:ip-address
          |     +--rw source-addr?                      inet:ip-address
          |     +--rw local-multiplier?                 multiplier
          |     +--rw (interval-config-type)?
          |     |  +--:(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 demand-enabled?                   boolean
          |     |       {demand-mode}?
          |     +--rw admin-down?                       boolean
          |     +--rw authentication! {authentication}?
          |     |  +--rw key-chain?    key-chain:key-chain-ref
          |     |  +--rw meticulous?   boolean
          |     +--ro path-type?                        identityref
          |     +--ro ip-encapsulation?                 boolean
          |     +--ro local-discriminator?              discriminator
          |     +--ro remote-discriminator?             discriminator
          |     +--ro remote-multiplier?                multiplier
          |     +--ro demand-capability?                boolean
          |     |       {demand-mode}?
          |     +--ro source-port?                      inet:port-number
          |     +--ro dest-port?                        inet:port-number
          |     +--ro session-running
          |     |  +--ro session-index?                uint32
          |     |  +--ro local-state?                  state
          |     |  +--ro remote-state?                 state
          |     |  +--ro local-diagnostic?
          |     |  |       iana-bfd-types:diagnostic
          |     |  +--ro remote-diagnostic?
          |     |  |       iana-bfd-types:diagnostic
          |     |  +--ro remote-authenticated?         boolean
          |     |  +--ro remote-authentication-type?
          |     |  |       iana-bfd-types:auth-type {authentication}?
          |     |  +--ro detection-mode?               enumeration
          |     |  +--ro negotiated-tx-interval?       uint32
          |     |  +--ro negotiated-rx-interval?       uint32
          |     |  +--ro detection-time?               uint32
          |     |  +--ro echo-tx-interval-in-use?      uint32
          |     |          {echo-mode}?
          |     +--ro session-statistics
          |        +--ro create-time?
          |        |       yang:date-and-time
          |        +--ro last-down-time?
          |        |       yang:date-and-time
          |        +--ro last-up-time?
          |        |       yang:date-and-time
          |        +--ro down-count?                     yang:counter32
          |        +--ro admin-down-count?               yang:counter32
          |        +--ro receive-packet-count?           yang:counter64
          |        +--ro send-packet-count?              yang:counter64
          |        +--ro receive-invalid-packet-count?   yang:counter64
          |        +--ro send-failed-packet-count?       yang:counter64
          +--rw interfaces* [interface]
             +--rw interface         if:interface-ref
             +--rw authentication! {authentication}?
                +--rw key-chain?    key-chain:key-chain-ref
                +--rw meticulous?   boolean

     notifications:
       +---n singlehop-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro interface?                   if:interface-ref
          +--ro echo-enabled?                boolean

2.7. Иерархия BFD IP Multihop

Узел ip-mh добавлен в ветвь bfd иерархии control-plane-protocol и содержит узлы данных конфигурации и рабочего состояния для каждой сессии BFD IP multihop. В модели рабочего состояния поддерживается множество сессий BFD multihop на удалённый адрес (ECMP), ключом для них служит локальный дискриминатор.

   module: ietf-bfd-ip-mh
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw ip-mh
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw session-groups
             +--rw session-group* [source-addr dest-addr]
                +--rw source-addr                       inet:ip-address
                +--rw dest-addr                         inet:ip-address
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(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 demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--rw tx-ttl?                           bfd-types:hops
                +--rw rx-ttl                            bfd-types:hops
                +--ro sessions* []
                   +--ro path-type?              identityref
                   +--ro ip-encapsulation?       boolean
                   +--ro local-discriminator?    discriminator
                   +--ro remote-discriminator?   discriminator
                   +--ro remote-multiplier?      multiplier
                   +--ro demand-capability?      boolean {demand-mode}?
                   +--ro source-port?            inet:port-number
                   +--ro dest-port?              inet:port-number
                   +--ro session-running
                   |  +--ro session-index?                uint32
                   |  +--ro local-state?                  state
                   |  +--ro remote-state?                 state
                   |  +--ro local-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-authenticated?         boolean
                   |  +--ro remote-authentication-type?
                   |  |       iana-bfd-types:auth-type {authentication}?
                   |  +--ro detection-mode?               enumeration
                   |  +--ro negotiated-tx-interval?       uint32
                   |  +--ro negotiated-rx-interval?       uint32
                   |  +--ro detection-time?               uint32
                   |  +--ro echo-tx-interval-in-use?      uint32
                   |          {echo-mode}?
                   +--ro session-statistics
                      +--ro create-time?
                      |       yang:date-and-time
                      +--ro last-down-time?
                      |       yang:date-and-time
                      +--ro last-up-time?
                      |       yang:date-and-time
                      +--ro down-count?
                      |       yang:counter32
                      +--ro admin-down-count?
                      |       yang:counter32
                      +--ro receive-packet-count?
                      |       yang:counter64
                      +--ro send-packet-count?
                      |       yang:counter64
                      +--ro receive-invalid-packet-count?
                      |       yang:counter64
                      +--ro send-failed-packet-count?
                              yang:counter64

     notifications:
       +---n multihop-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref

2.8. Иерархия для BFD через LAG

Узел lag добавлен в ветвь bfd иерархии control-plane-protocol и содержит узлы данных конфигурации и рабочего состояния каждой сессии BFD LAG.

   module: ietf-bfd-lag
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw lag
          +--rw micro-bfd-ipv4-session-statistics
          |  +--ro summary
          |     +--ro number-of-sessions?              yang:gauge32
          |     +--ro number-of-sessions-up?           yang:gauge32
          |     +--ro number-of-sessions-down?         yang:gauge32
          |     +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw micro-bfd-ipv6-session-statistics
          |  +--ro summary
          |     +--ro number-of-sessions?              yang:gauge32
          |     +--ro number-of-sessions-up?           yang:gauge32
          |     +--ro number-of-sessions-down?         yang:gauge32
          |     +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw sessions
             +--rw session* [lag-name]
                +--rw lag-name                          if:interface-ref
                +--rw ipv4-dest-addr?
                |       inet:ipv4-address
                +--rw ipv6-dest-addr?
                |       inet:ipv6-address
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(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 demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--rw use-ipv4?                         boolean
                +--rw use-ipv6?                         boolean
                +--ro member-links* [member-link]
                   +--ro member-link       if:interface-ref
                   +--ro micro-bfd-ipv4
                   |  +--ro path-type?              identityref
                   |  +--ro ip-encapsulation?       boolean
                   |  +--ro local-discriminator?    discriminator
                   |  +--ro remote-discriminator?   discriminator
                   |  +--ro remote-multiplier?      multiplier
                   |  +--ro demand-capability?      boolean
                   |  |       {demand-mode}?
                   |  +--ro source-port?            inet:port-number
                   |  +--ro dest-port?              inet:port-number
                   |  +--ro session-running
                   |  |  +--ro session-index?                uint32
                   |  |  +--ro local-state?                  state
                   |  |  +--ro remote-state?                 state
                   |  |  +--ro local-diagnostic?
                   |  |  |       iana-bfd-types:diagnostic
                   |  |  +--ro remote-diagnostic?
                   |  |  |       iana-bfd-types:diagnostic
                   |  |  +--ro remote-authenticated?         boolean
                   |  |  +--ro remote-authentication-type?
                   |  |  |       iana-bfd-types:auth-type
                   |  |  |       {authentication}?
                   |  |  +--ro detection-mode?               enumeration
                   |  |  +--ro negotiated-tx-interval?       uint32
                   |  |  +--ro negotiated-rx-interval?       uint32
                   |  |  +--ro detection-time?               uint32
                   |  |  +--ro echo-tx-interval-in-use?      uint32
                   |  |          {echo-mode}?
                   |  +--ro session-statistics
                   |     +--ro create-time?
                   |     |       yang:date-and-time
                   |     +--ro last-down-time?
                   |     |       yang:date-and-time
                   |     +--ro last-up-time?
                   |     |       yang:date-and-time
                   |     +--ro down-count?
                   |     |       yang:counter32
                   |     +--ro admin-down-count?
                   |     |       yang:counter32
                   |     +--ro receive-packet-count?
                   |     |       yang:counter64
                   |     +--ro send-packet-count?
                   |     |       yang:counter64
                   |     +--ro receive-invalid-packet-count?
                   |     |       yang:counter64
                   |     +--ro send-failed-packet-count?
                   |             yang:counter64
                   +--ro micro-bfd-ipv6
                      +--ro path-type?              identityref
                      +--ro ip-encapsulation?       boolean
                      +--ro local-discriminator?    discriminator
                      +--ro remote-discriminator?   discriminator
                      +--ro remote-multiplier?      multiplier
                      +--ro demand-capability?      boolean
                      |       {demand-mode}?
                      +--ro source-port?            inet:port-number
                      +--ro dest-port?              inet:port-number
                      +--ro session-running
                      |  +--ro session-index?                uint32
                      |  +--ro local-state?                  state
                      |  +--ro remote-state?                 state
                      |  +--ro local-diagnostic?
                      |  |       iana-bfd-types:diagnostic
                      |  +--ro remote-diagnostic?
                      |  |       iana-bfd-types:diagnostic
                      |  +--ro remote-authenticated?         boolean
                      |  +--ro remote-authentication-type?
                      |  |       iana-bfd-types:auth-type
                      |  |       {authentication}?
                      |  +--ro detection-mode?               enumeration
                      |  +--ro negotiated-tx-interval?       uint32
                      |  +--ro negotiated-rx-interval?       uint32
                      |  +--ro detection-time?               uint32
                      |  +--ro echo-tx-interval-in-use?      uint32
                      |          {echo-mode}?
                      +--ro session-statistics
                         +--ro create-time?
                         |       yang:date-and-time
                         +--ro last-down-time?
                         |       yang:date-and-time
                         +--ro last-up-time?
                         |       yang:date-and-time
                         +--ro down-count?
                         |       yang:counter32
                         +--ro admin-down-count?
                         |       yang:counter32
                         +--ro receive-packet-count?
                         |       yang:counter64
                         +--ro send-packet-count?
                         |       yang:counter64
                         +--ro receive-invalid-packet-count?
                         |       yang:counter64
                         +--ro send-failed-packet-count?
                                 yang:counter64

     notifications:
       +---n lag-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro lag-name?                    if:interface-ref
          +--ro member-link?                 if:interface-ref

2.9. Иерархия для BFD через MPLS LSP

Узел mpls добавлен в ветвь bfd иерархии control-plane-protocol и содержит конфигурации для MPLS FEC. В модели рабочего состояния поддерживается множество сессий BFD на MPLS FEC (ECMP), ключом для них служит локальный дискриминатор. Узел mpls можно применять в сетевом устройстве (верхний уровень), а также устанавливать в LNE или экземпляре сети.

   module: ietf-bfd-mpls
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw mpls
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw egress
          |  +--rw enabled?                          boolean
          |  +--rw local-multiplier?                 multiplier
          |  +--rw (interval-config-type)?
          |  |  +--:(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 authentication! {authentication}?
          |     +--rw key-chain?    key-chain:key-chain-ref
          |     +--rw meticulous?   boolean
          +--rw session-groups
             +--rw session-group* [mpls-fec]
                +--rw mpls-fec                          inet:ip-prefix
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(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 demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--ro sessions* []
                   +--ro path-type?              identityref
                   +--ro ip-encapsulation?       boolean
                   +--ro local-discriminator?    discriminator
                   +--ro remote-discriminator?   discriminator
                   +--ro remote-multiplier?      multiplier
                   +--ro demand-capability?      boolean {demand-mode}?
                   +--ro source-port?            inet:port-number
                   +--ro dest-port?              inet:port-number
                   +--ro session-running
                   |  +--ro session-index?                uint32
                   |  +--ro local-state?                  state
                   |  +--ro remote-state?                 state
                   |  +--ro local-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-authenticated?         boolean
                   |  +--ro remote-authentication-type?
                   |  |       iana-bfd-types:auth-type {authentication}?
                   |  +--ro detection-mode?               enumeration
                   |  +--ro negotiated-tx-interval?       uint32
                   |  +--ro negotiated-rx-interval?       uint32
                   |  +--ro detection-time?               uint32
                   |  +--ro echo-tx-interval-in-use?      uint32
                   |          {echo-mode}?
                   +--ro session-statistics
                   |  +--ro create-time?
                   |  |       yang:date-and-time
                   |  +--ro last-down-time?
                   |  |       yang:date-and-time
                   |  +--ro last-up-time?
                   |  |       yang:date-and-time
                   |  +--ro down-count?
                   |  |       yang:counter32
                   |  +--ro admin-down-count?
                   |  |       yang:counter32
                   |  +--ro receive-packet-count?
                   |  |       yang:counter64
                   |  +--ro send-packet-count?
                   |  |       yang:counter64
                   |  +--ro receive-invalid-packet-count?
                   |  |       yang:counter64
                   |  +--ro send-failed-packet-count?
                   |          yang:counter64
                   +--ro mpls-dest-address?      inet:ip-address

     notifications:
       +---n mpls-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro mpls-dest-address?           inet:ip-address

2.10. Взаимодействие с другими модулями YANG

В документе Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications [RFC8532] описано, как можно расширить независимой от уровня поддержки OAM (Layer-Independent OAM Management in the Multi-Layer Environment или LIME) без организации явных соединений для поддержки BFD.

Работа модели данных BFD зависит также от параметров конфигурации, определённых в других модулях YANG.

2.10.1. Модуль ietf-interfaces

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for Interface Management [RFC8343].

/if:interfaces/if:interface/if:enabled

2.10.2. Модуль ietf-ip

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for IP Management [RFC8344].

/if:interfaces/if:interface/ip:ipv4/ip:enabled

/if:interfaces/if:interface/ip:ipv4/ip:forwarding

/if:interfaces/if:interface/ip:ipv6/ip:enabled

/if:interfaces/if:interface/ip:ipv6/ip:forwarding

2.10.3. Модуль ietf-mpls

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for MPLS Base [RFC8960].

/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/mpls:mpls-enabled

2.11. Модуль для типов BFD

Этот модуль YANG импортирует определения типов из [RFC6991] и [RFC8177], определения из [RFC5880], [RFC5881], [RFC5883], [RFC5884] и [RFC7130], а также отождествление control-plane-protocol из [RFC8349, и ссылки [RFC9127].

   <CODE BEGINS> file "ietf-bfd-types@2022-09-22.yang"
   module ietf-bfd-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types";
     prefix bfd-types;

     import iana-bfd-types {
       prefix iana-bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     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-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";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения связанных с BFD типов данных
        YANG в соответствии с RFC 5880, а также группировки, применяемые
        совместно с другими модулям YANG BFD.

        Авторские права (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 9314, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5880: Bidirectional Forwarding Detection (BFD)
        RFC 9314: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2022-09-22 {
       description
         "Этот выпуск не совместим с предыдущей версией модели.

          Здесь добавлен оператор if-feature с именем 
          client-base-cfg-parms для параметров конфигурации клиента.
          Клиенты, ожидающие использования этих параметров, должны
          убедиться, что сервер указал поддержку этого свойства,
          прежде чем полагаться на присутствие параметров.

          Изменение внесено для клиентов, которым эти параметры не
          нужны и требуется добавлять отклонение (deviate), чтобы не
          включать их.";
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD).";
     }
     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Определения свойств (функций)
      */

     feature single-minimum-interval {
       description
         "Указывает, что сервер поддерживает настройку 1 минимального
          значение для интервалов приёма и передачи.";
     }

     feature authentication {
       description
         "Указывает, что сервер поддерживает аутентификацию BFD.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD),
          Section 6.7";
     }

     feature demand-mode {
       description
         "Указывает, что сервер поддерживает режим BFD Demand.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD),
          Section 6.6";
     }

     feature echo-mode {
       description
         " Указывает, что сервер поддерживает режим BFD Echo.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD),
          Section 6.4";
     }

     feature client-base-cfg-parms {
       description
         "Разрешает моделям протоколов настраивать параметры сессии BFD
          клиентам.";
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
                    Detection (BFD).";
     }

     /*
      * Определения отождествлений (идентификаторов)
      */

     identity bfdv1 {
       base rt:control-plane-protocol;
       description
         "Протокол BFD версии 1.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }

     identity path-type {
       description
         "Базовое отождествление для типа пути BFD, указывающего тип 
          пути, по которому работает BFD.";
     }

     identity path-ip-sh {
       base path-type;
       description
         "BFD через 1 интервал пересылки IP.";
       reference
         "RFC 5881: Bidirectional Forwarding Detection (BFD)
          for IPv4 and IPv6 (Single Hop)";
     }

     identity path-ip-mh {
       base path-type;
       description
         "BFD через множество интервалов пересылки IP.";
       reference
         "RFC 5883: Bidirectional Forwarding Detection (BFD) for
          Multihop Paths";
     }

     identity path-mpls-te {
       base path-type;
       description
         "BFD через MPLS TE.";
       reference
         "RFC 5884: Bidirectional Forwarding Detection (BFD)
          for MPLS Label Switched Paths (LSPs)";
     }

     identity path-mpls-lsp {
       base path-type;
       description
         "BFD через MPLS LSP.";
       reference
         "RFC 5884: Bidirectional Forwarding Detection (BFD)
          for MPLS Label Switched Paths (LSPs)";
     }

     identity path-lag {
       base path-type;
       description
         "Micro-BFD на канале из группы LAG.";
       reference
         "RFC 7130: Bidirectional Forwarding Detection (BFD) on
          Link Aggregation Group (LAG) Interfaces";
     }

     identity encap-type {
       description
         "Базовое отождествление типа инкапсуляции BFD.";
     }

     identity encap-ip {
       base encap-type;
       description
         "BFD с инкапсуляцией IP.";
     }

     /*
      * Определения типов
      */

     typedef discriminator {
       type uint32;
       description
         "Дискриминатор BFD, описанный в RFC 5880.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)";
     }

     typedef state {
       type enumeration {
         enum adminDown {
           value 0;
           description
             "Состояние adminDown.";
         }
         enum down {
           value 1;
           description
             "Состояние Down.";
         }
         enum init {
           value 2;
           description
             "Состояние Init.";
         }
         enum up {
           value 3;
           description
             "Состояние Up.";
         }
       }
       description
         "Состояния BFD в соответствии с RFC 5880.";
     }

     typedef multiplier {
       type uint8 {
         range "1..255";
       }
       description
         "Множитель BFD, определённый в RFC 5880.";
     }

     typedef hops {
       type uint8 {
         range "1..255";
       }
       description
         "Соответствует TTL в IPv4 и Hop Limit в IPv6.";
     }

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

     grouping auth-parms {
       description
         "Параметры аутентификации BFD (параграф 6.7 в RFC 5880).";
       container authentication {
         if-feature "authentication";
         presence "Включает аутентификацию (параграф 6.7 в RFC 5880).";
         description
           "Параметры аутентификации BFD.";
         reference
           "RFC 5880: Bidirectional Forwarding Detection (BFD),
            Section 6.7";
         leaf key-chain {
           type key-chain:key-chain-ref;
           description
             "Имя key-chain в соответствии с RFC 8177.";
         }
         leaf meticulous {
           type boolean;
           description
             "Включает скрупулёзный режим (параграф 6.7 в RFC 5880).";
         }
       }
     }

     grouping base-cfg-parms {
       description
         "Группировка BFD для базовых параметров конфигурации.";
       leaf local-multiplier {
         type multiplier;
         default "3";
         description
           "Множитель, передаваемый локальной системой.";
       }
       choice interval-config-type {
         default "tx-rx-intervals";
         description
           "Два или одно значение для интервалов приёма и передачи.";
         case tx-rx-intervals {
           leaf desired-min-tx-interval {
             type uint32;
             units "microseconds";
             default "1000000";
             description
               "Желаемый минимальный интервал передачи пакетов 
                управления.";
           }
           leaf required-min-rx-interval {
             type uint32;
             units "microseconds";
             default "1000000";
             description
               "Требуемый минимальный интервал получения пакетов
                управления.";
           }
         }
         case single-interval {
           if-feature "single-minimum-interval";
           leaf min-interval {
             type uint32;
             units "microseconds";
             default "1000000";
             description
               "Желаемый минимальный интервал передачи и требуемый
                минимальный интервал получения пакетов управления.";
           }
         }
       }
     }

     grouping client-cfg-parms {
       description
         "Группировка BFD для параметров конфигурации, применяемых 
          клиентами BFD, например, IGP или MPLS.";
       leaf enabled {
         type boolean;
         default "false";
         description
           "Указывает, разрешён ли протокол BFD.";
       }
       uses base-cfg-parms {
         if-feature "client-base-cfg-parms";
       }
     }

     grouping common-cfg-parms {
       description
         "Группировка BFD для общих параметров конфигурации.";
       uses base-cfg-parms;
       leaf demand-enabled {
         if-feature "demand-mode";
         type boolean;
         default "false";
         description
           "Для включения режима Demand.";
       }
       leaf admin-down {
         type boolean;
         default "false";
         description
           "Указывает, была ли сессия BFD отключена административно.";
       }
       uses auth-parms;
     }

     grouping all-session {
       description
         "Сведения о работе сессии BFD.";
       leaf path-type {
         type identityref {
           base path-type;
         }
         config false;
         description
           "Тип пути, по которому работает BFD.";
       }
       leaf ip-encapsulation {
         type boolean;
         config false;
         description
           "Указывает, используется ли для BFD инкапсуляция IP.";
       }
       leaf local-discriminator {
         type discriminator;
         config false;
         description
           "Локальный дискриминатор.";
       }
       leaf remote-discriminator {
         type discriminator;
         config false;
         description
           "Удалённый дискриминатор.";
       }
       leaf remote-multiplier {
         type multiplier;
         config false;
         description
           "Удалённый множитель.";
       }
       leaf demand-capability {
         if-feature "demand-mode";
         type boolean;
         config false;
         description
           "Локальная поддержка режима Demand.";
       }
       leaf source-port {
         when "../ip-encapsulation = 'true'" {
           description
             "Порт-источник пригоден лишь при инкапсуляции IP.";
         }
         type inet:port-number;
         config false;
         description
           "Порт-источник UDP.";
       }
       leaf dest-port {
         when "../ip-encapsulation = 'true'" {
           description
             "Порт-получатель пригоден лишь при инкапсуляции IP.";
         }
         type inet:port-number;
         config false;
         description
           "Порт-получатель UDP.";
       }
       container session-running {
         config false;
         description
           "Информация о работе сессии BFD.";
         leaf session-index {
           type uint32;
           description
             "Индекс для однозначного указания сессий BFD.";
         }
         leaf local-state {
           type state;
           description
             "Локальное состояние.";
         }
         leaf remote-state {
           type state;
           description
             "Удалённое состояние.";
         }
         leaf local-diagnostic {
           type iana-bfd-types:diagnostic;
           description
             "Локальная диагностика.";
         }
         leaf remote-diagnostic {
           type iana-bfd-types:diagnostic;
           description
             "Удаленная диагностика.";
         }
         leaf remote-authenticated {
           type boolean;
           description
             "Указывает, аутентифицированы ли входящие пакеты 
              управления BFD.";
         }
         leaf remote-authentication-type {
           when "../remote-authenticated = 'true'" {
             description
               "Пригодно лишь при аутентифицированных входящих пакетах.";
           }
           if-feature "authentication";
           type iana-bfd-types:auth-type;
           description
             "Тип аутентификации входящих пакетов управления BFD.";
         }
         leaf detection-mode {
           type enumeration {
             enum async-with-echo {
               value 1;
               description
                 "Асинхронно с Echo.";
             }
             enum async-without-echo {
               value 2;
               description
                 "Асинхронно без Echo.";
             }
             enum demand-with-echo {
               value 3;
               description
                 "Demand с Echo.";
             }
             enum demand-without-echo {
               value 4;
               description
                 "Demand без Echo.";
             }
           }
           description
             "Режим детектирования.";
         }
         leaf negotiated-tx-interval {
           type uint32;
           units "microseconds";
           description
             "Согласованный интервал передачи.";
         }
         leaf negotiated-rx-interval {
           type uint32;
           units "microseconds";
           description
             "Согласованный интервал приёма.";
         }
         leaf detection-time {
           type uint32;
           units "microseconds";
           description
             "Время обнаружения.";
         }
         leaf echo-tx-interval-in-use {
           when "../../path-type = 'bfd-types:path-ip-sh'" {
             description
               "Echo поддерживается лишь для IP single-hop.";
           }
           if-feature "echo-mode";
           type uint32;
           units "microseconds";
           description
             "Применяемый интервал передачи Echo.";
         }
       }
       container session-statistics {
         config false;
         description
           "Статистика для сессии BFD.";
         leaf create-time {
           type yang:date-and-time;
           description
             "Дата и время создания сессии.";
         }
         leaf last-down-time {
           type yang:date-and-time;
           description
             "Дата и время последнего закрытия сессии (down).";
         }
         leaf last-up-time {
           type yang:date-and-time;
           description
             " Дата и время последнего открытия сессии (up).";
         }
         leaf down-count {
           type yang:counter32;
           description
             "Число переходов сессии в состояние down.";
         }
         leaf admin-down-count {
           type yang:counter32;
           description
             " Число переходов сессии в состояние admin-down.";
         }
         leaf receive-packet-count {
           type yang:counter64;
           description
             "Число полученных в сессии пакетов (включая непригодные).";
         }
         leaf send-packet-count {
           type yang:counter64;
           description
             "Число переданных в сессии пакетов.";
         }
         leaf receive-invalid-packet-count {
           type yang:counter64;
           description
             "Число полученных в сессии недействительных пакетов.";
         }
         leaf send-failed-packet-count {
           type yang:counter64;
           description
             "Число отказов при передаче пакетов в сессии.";
         }
       }
     }

     grouping session-statistics-summary {
       description
         "Группировка для сводной статистики сессий.";
       container summary {
         config false;
         description
           "Сводная статистика сессий BFD.";
         leaf number-of-sessions {
           type yang:gauge32;
           description
             "Число сессий BFD.";
         }
         leaf number-of-sessions-up {
           type yang:gauge32;
           description
             "Число сессий BFD в состоянии Up (в соответствии с 
              RFC 5880).";
         }
         leaf number-of-sessions-down {
           type yang:gauge32;
           description
             "Число сессий BFD в состоянии Down или Init, но не
              adminDown (в соответствии с RFC 5880).";
         }
         leaf number-of-sessions-admin-down {
           type yang:gauge32;
           description
             "Число сессий BFD в состоянии adminDown (в соответствии с 
              RFC 5880).";
         }
       }
     }

     grouping notification-parms {
       description
         "Группа описывает общие параметры, которые будут передаваться
          в уведомлениях BFD.";
       leaf local-discr {
         type discriminator;
         description
           "Локальный дискриминатор BFD.";
       }
       leaf remote-discr {
         type discriminator;
         description
           "Удалённый дискриминатор BFD.";
       }
       leaf new-state {
         type state;
         description
           "Текущее состояние BFD.";
       }
       leaf state-change-reason {
         type iana-bfd-types:diagnostic;
         description
           "Причина смены состояния BFD.";
       }
       leaf time-of-last-state-change {
         type yang:date-and-time;
         description
           "Календарное время последней смены состояния.";
       }
       leaf dest-addr {
         type inet:ip-address;
         description
           "Адрес партнёра BFD.";
       }
       leaf source-addr {
         type inet:ip-address;
         description
           "Локальный адрес BFD.";
       }
       leaf session-index {
         type uint32;
         description
           "Индекс для однозначного указания сессий BFD.";
       }
       leaf path-type {
         type identityref {
           base path-type;
         }
         description
           "Тип пути BFD.";
       }
     }
   }
   <CODE ENDS>

2.12. Модуль верхнего уровня для BFD

Этот модуль YANG импортирует и дополняет модуль /routing/control-plane-protocols/control-plane-protocol из [RFC8349]. Модуль также ссылается на [RFC5880].

   <CODE BEGINS> file "ietf-bfd@2022-09-22.yang"
   module ietf-bfd {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd";
     prefix bfd;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для параметров BFD 
        в соответствии с RFC 5880.

        Авторские права (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 9314, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5880: Bidirectional Forwarding Detection (BFD)
        RFC 9314: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2022-09-22 {
       description
         "Обновление со ссылкой на RFC 9314.";
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD).";
     }
     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol" {
       when "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" {
         description
           "Дополнение действительно лишь для экземпляра BFD
            в плоскости управления (тип bfdv1).";
       }
       description
         "Дополнение BFD.";
       container bfd {
         description
           "Контейнер верхнего уровня BFD.";
         uses bfd-types:session-statistics-summary;
       }
     }
   }
   <CODE ENDS>

2.13. Модуль BFD IP Single-Hop

Этот модуль YANG импортирует interface-ref из [RFC8343] и определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5881].

   <CODE BEGINS> file "ietf-bfd-ip-sh@2022-09-22.yang"
   module ietf-bfd-ip-sh {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh";
     prefix bfd-ip-sh;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для параметров BFD с одной
        пересылкой IP (single-hop) в соответствии с RFC 5881.

        Авторские права (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 9314, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5881: Bidirectional Forwarding Detection (BFD)
        for IPv4 and IPv6 (Single Hop)
        RFC 9314: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2022-09-22 {
       description
         "Обновление со ссылкой на RFC 9314.";
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD).";
     }
     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Дополнения
      */

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для IP single-hop.";
       container ip-sh {
         description
           "Контейнер верхнего уровня BFD IP single-hop.";
         uses bfd-types:session-statistics-summary;
         container sessions {
           description
             "Сессии BFD IP single-hop.";
           list session {
             key "interface dest-addr";
             description
               "Список сессий IP single-hop.";
             leaf interface {
               type if:interface-ref;
               description
                 "Интерфейс, на котором работает сессия BFD.";
             }
             leaf dest-addr {
               type inet:ip-address;
               description
                 "IP-адрес партнера.";
             }
             leaf source-addr {
               type inet:ip-address;
               description
                 "Локальный адрес IP.";
             }
             uses bfd-types:common-cfg-parms;
             uses bfd-types:all-session;
           }
         }
         list interfaces {
           key "interface";
           description
             "Список интерфейсов.";
           leaf interface {
             type if:interface-ref;
             description
               "Сведения BFD для данного интерфейса.";
           }
           uses bfd-types:auth-parms;
         }
       }
     }

     /*
      * Уведомления
      */

     notification singlehop-notification {
       description
         "Уведомление о смене состояния сессии BFD single-hop. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
       leaf interface {
         type if:interface-ref;
         description
           "Интерфейс, к которому относится эта сессия BFD.";
       }
       leaf echo-enabled {
         type boolean;
         description
           "Указывает, разрешены ли сообщения Echo для BFD.";
       }
     }
   }
   <CODE ENDS>

2.14. Модуль BFD IP Multihop

Этот модуль YANG импортирует определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5883].

   <CODE BEGINS> file "ietf-bfd-ip-mh@2022-09-22.yang"
   module ietf-bfd-ip-mh {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh";
     prefix bfd-ip-mh;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для BFD IP multihop
        в соответствии с RFC 5883.

        Авторские права (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 9314, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5883: Bidirectional Forwarding Detection (BFD) for
        Multihop Paths
        RFC 9314: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2022-09-22 {
       description
         "Обновление со ссылкой на RFC 9314.";
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD).";
     }
     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Дополнения
      */

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для IP multihop.";
       container ip-mh {
         description
           "Контейнер верхнего уровня BFD IP multihop.";
         uses bfd-types:session-statistics-summary;
         container session-groups {
           description
             "Группы сессий BFD IP multihop.";
           list session-group {
             key "source-addr dest-addr";
             description
               "Группа сессий BFD IP multihop (для ECMP) между одной
                парой источник - получатель. Каждая сессия имеет своё 
                поле в заголовке UDP/IP для ECMP.";
             leaf source-addr {
               type inet:ip-address;
               description
                 "Локальный адрес IP.";
             }
             leaf dest-addr {
               type inet:ip-address;
               description
                 "IP-адрес партнера.";
             }
             uses bfd-types:common-cfg-parms;
             leaf tx-ttl {
               type bfd-types:hops;
               default "255";
               description
                 "Счётчик пересылок в выходных пакетах управления BFD.";
             }
             leaf rx-ttl {
               type bfd-types:hops;
               mandatory true;
               description
                 "Минимальное разрешённое значение счётчика интервалов 
                  во входящих пакетах управления BFD. Пакеты с меньшим
                  значением отбрасываются.";
             }
             list sessions {
               config false;
               description
                 "Множество сессий BFD между источником и получателем.";
               uses bfd-types:all-session;
             }
           }
         }
       }
     }


     /*
      * Уведомление
      */

     notification multihop-notification {
       description
         "Уведомление о смене состояния сессии BFD multihop. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
     }
   }
   <CODE ENDS>

2.15. Модуль для BFD через LAG

Этот модуль YANG импортирует interface-ref из [RFC8343] и определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC7130].

   <CODE BEGINS> file "ietf-bfd-lag@2022-09-22.yang"
   module ietf-bfd-lag {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-lag";
     prefix bfd-lag;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для интерфейсов BFD через
        LAG в соответствии с RFC 7130.

        Авторские права (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 9314, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 7130: Bidirectional Forwarding Detection (BFD) on
        Link Aggregation Group (LAG) Interfaces
        RFC 9314: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2022-09-22 {
       description
         "Обновление со ссылкой на RFC 9314.";
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD).";
     }
     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Дополнения
      */

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для LAG.";
       container lag {
         description
           "Контейнер верхнего уровня для BFD через LAG.";
         container micro-bfd-ipv4-session-statistics {
           description
             "Счётчики сессий Micro-BFD IPv4.";
           uses bfd-types:session-statistics-summary;
         }
         container micro-bfd-ipv6-session-statistics {
           description
             "Счётчики сессий Micro-BFD IPv6.";
           uses bfd-types:session-statistics-summary;
         }
         container sessions {
           description
             "Сессии BFD через LAG.";
           list session {
             key "lag-name";
             description
               "Список сессий BFD через LAG.";
             leaf lag-name {
               type if:interface-ref;
               description
                 "Имя LAG.";
             }
             leaf ipv4-dest-addr {
               type inet:ipv4-address;
               description
                 "Адрес IPv4 для партнёра в сессии IPv4 micro-BFD.";
             }
             leaf ipv6-dest-addr {
               type inet:ipv6-address;
               description
                 "Адрес IPv6 для партнёра в сессии IPv6 micro-BFD.";
             }
             uses bfd-types:common-cfg-parms;
             leaf use-ipv4 {
               type boolean;
               description
                 "Использование IPv4 micro-BFD.";
             }
             leaf use-ipv6 {
               type boolean;
               description
                 "Использование IPv6 micro-BFD.";
             }
             list member-links {
               key "member-link";
               config false;
               description
                 "Micro-BFD через LAG — один член группы.";
               leaf member-link {
                 type if:interface-ref;
                 description
                   "Канал, на котором работает micro-BFD.";
               }
               container micro-bfd-ipv4 {
                 when "../../use-ipv4 = 'true'" {
                   description
                     "Требуется лишь при использовании IPv4.";
                 }
                 description
                   "Состояние сессии Micro-BFD IPv4 на канале.";
                 uses bfd-types:all-session;
               }
               container micro-bfd-ipv6 {
                 when "../../use-ipv6 = 'true'" {
                   description
                     "Требуется лишь при использовании IPv6.";
                 }
                 description
                   "Состояние сессии Micro-BFD IPv6 на канале.";
                 uses bfd-types:all-session;
               }
             }
           }
         }
       }
     }

     /*
      * Уведомление
      */

     notification lag-notification {
       description
         "Уведомление о смене состояния сессии BFD через LAG. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
       leaf lag-name {
         type if:interface-ref;
         description
           "Имя интерфейса LAG.";
       }
       leaf member-link {
         type if:interface-ref;
         description
           "Канал из группы, на котором работает BFD.";
       }
     }
   }
   <CODE ENDS>

2.16. Модуль для BFD через MPLS

Этот модуль YANG импортирует определения типов из [RFC6991], а также импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5586] и [RFC5884].

   <CODE BEGINS> file "ietf-bfd-mpls@2022-09-22.yang"
   module ietf-bfd-mpls {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls";
     prefix bfd-mpls;

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-bfd {
       prefix bfd;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для параметров BFD при
        работе через MPLS LSP в соответствии с RFC 5884.

        Авторские права (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 9314, где правовые
        аспекты приведены более полно.";
     reference
       "RFC 5884: Bidirectional Forwarding Detection (BFD)
        for MPLS Label Switched Paths (LSPs)
        RFC 9314: YANG Data Model for Bidirectional Forwarding
        Detection (BFD)";

     revision 2022-09-22 {
       description
         "Задано использование base-cfg-parms вместо client-cfg-parms,
          и добавлен флаг разрешения (enabled).";
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD).";
     }
     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     /*
      * Отождествления (идентификаторы)
      */

     identity encap-gach {
       base bfd-types:encap-type;
       description
         "BFD с инкапсуляцией G-ACh в соответствии с RFC 5586.";
       reference
         "RFC 5586: MPLS Generic Associated Channel";
     }

     identity encap-ip-gach {
       base bfd-types:encap-type;
       description
         "BFD с инкапсуляцией IP и G-ACh в соответствии с RFC 5586.";
     }

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

     grouping encap-cfg {
       description
         "Конфигурация для инкапсуляции BFD.";
       leaf encap {
         type identityref {
           base bfd-types:encap-type;
         }
         default "bfd-types:encap-ip";
         description
           "Инкапсуляция BFD.";
       }
     }

     grouping mpls-dest-address {
       description
         "Адрес получателя в соответствии с RFC 5884.";
       reference
         "RFC 5884: Bidirectional Forwarding Detection (BFD)
          for MPLS Label Switched Paths (LSPs)";
       leaf mpls-dest-address {
         type inet:ip-address;
         config false;
         description
           "Адрес получателя в соответствии с RFC 5884
            Требуется при инкапсуляции IP.";
       }
     }

     /*
      * Дополнения
      */

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd" {
       description
         "Дополнение BFD для MPLS.";
       container mpls {
         description
           "Контейнер верхнего уровня BFD MPLS.";
         uses bfd-types:session-statistics-summary;
         container egress {
           description
             "Выходная конфигурация.";
           leaf enabled {
             type boolean;
             default "false";
             description
               "Указывает, разрешена ли работа BFD через MPLS.";
           }
           uses bfd-types:base-cfg-parms;
           uses bfd-types:auth-parms;
         }
         container session-groups {
           description
             "Группы сессий BFD через MPLS.";
           list session-group {
             key "mpls-fec";
             description
               "Группа сессий BFD MPLS (для ECMP). Группа сессий для
                одного класса FEC. Каждая сессия имеет своё поле в
                заголовке UDP/IP для ECMP.";
             leaf mpls-fec {
               type inet:ip-prefix;
               description
                 "MPLS FEC.";
             }
             uses bfd-types:common-cfg-parms;
             list sessions {
               config false;
               description
                 "Сессии BFD для MPLS FEC. Локальный дискриминатор
                  уникален для каждой сессии в группе.";
               uses bfd-types:all-session;
               uses bfd-mpls:mpls-dest-address;
             }
           }
         }
       }
     }

     /*
      * Уведомление
      */

     notification mpls-notification {
       description
         "Уведомление о смене состояния сессии BFD через MPLS FEC. 
          Реализация может ограничивать частоту уведомлений, например
          при непрерывной смене состояния сессии.";
       uses bfd-types:notification-parms;
       leaf mpls-dest-address {
         type inet:ip-address;
         description
           "Адрес получателя в соответствии с RFC 5884.
            Требуется при инкапсуляции IP.";
       }
     }
   }
   <CODE ENDS>

3. Примеры моделей данных

В этом разделе представлены некоторые простые, иллюстративные примеры настройки BFD. В примерах применяется представление XML [W3C.REC-xml-20081126].

3.1. IP Single-Hop

Ниже приведён пример настройки сессии BFD IP single-hop. Для желаемого интервала передачи и требуемого интервала получения установлено значение 10 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
       <interface>
         <name>eth0</name>
         <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
           ianaift:ethernetCsmacd
         </type>
       </interface>
     </interfaces>
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
               <sessions>
                 <session>
                   <interface>eth0</interface>
                   <dest-addr>2001:db8:0:113::101</dest-addr>
                   <desired-min-tx-interval>
                     10000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     10000
                   </required-min-rx-interval>
                 </session>
               </sessions>
             </ip-sh>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

3.2. IP Multihop

Ниже приведён пример настройки сессии BFD IP multihop. Для желаемого интервала передачи и требуемого интервала получения установлено значение 150 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <ip-mh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh">
               <session-groups>
                 <session-group>
                   <source-addr>2001:db8:0:113::103</source-addr>
                   <dest-addr>2001:db8:0:114::100</dest-addr>
                   <desired-min-tx-interval>
                     150000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     150000
                   </required-min-rx-interval>
                   <rx-ttl>240</rx-ttl>
                 </session-group>
               </session-groups>
             </ip-mh>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

3.3. LAG

Ниже приведён пример конфигурации сессии BFD через LAG. Здесь интерфейс Bundle-Ether1 типа ieee8023adLag имеет желаемый интервал передачи и требуемый интервал получения 10 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
       <interface>
         <name>Bundle-Ether1</name>
         <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
           ianaift:ieee8023adLag
         </type>
       </interface>
     </interfaces>
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <lag xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-lag">
               <sessions>
                 <session>
                   <lag-name>Bundle-Ether1</lag-name>
                   <ipv6-dest-addr>2001:db8:112::16</ipv6-dest-addr>
                   <desired-min-tx-interval>
                     10000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     10000
                   </required-min-rx-interval>
                   <use-ipv6>true</use-ipv6>
                 </session>
               </sessions>
             </lag>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

3.4. MPLS

Ниже приведён пример настройки сессии BFD через MPLS LSP. Для желаемого интервала передачи и требуемого интервала получения установлено значение 250 мсек.

   <?xml version="1.0" encoding="UTF-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
       <control-plane-protocols>
         <control-plane-protocol>
           <type xmlns:bfd-types=
               "urn:ietf:params:xml:ns:yang:ietf-bfd-types">
             bfd-types:bfdv1
           </type>
           <name>name:BFD</name>
           <bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
             <mpls xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-mpls">
               <session-groups>
                 <session-group>
                   <mpls-fec>2001:db8:114::/116</mpls-fec>
                   <desired-min-tx-interval>
                     250000
                   </desired-min-tx-interval>
                   <required-min-rx-interval>
                     250000
                   </required-min-rx-interval>
                 </session-group>
               </session-groups>
             </mpls>
           </bfd>
         </control-plane-protocol>
       </control-plane-protocols>
     </routing>
   </config>

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

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

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

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

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-group

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-group

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/egress

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

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

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

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/summary

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions/session/

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/summary

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-groups/session-group/sessions

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv4-session-statistics/summary

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv4

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv6-session-statistics/summary

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv6

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/summary

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-groups/session-group/sessions

Этот документ не определяет операций RPC.

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

Этот документ регистрирует указанные ниже URI пространство имён в реестре IETF XML Registry [RFC3688].

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

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

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

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

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

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

Этот документ регистрирует указанные ниже модули YANG в реестре YANG Module Names [RFC6020].

   Name:  ietf-bfd-types
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-types
   Prefix:  bfd-types
   Reference:  RFC 9314

   Name:  ietf-bfd
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd
   Prefix:  bfd
   Reference:  RFC 9314

   Name:  ietf-bfd-ip-sh
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh
   Prefix:  bfd-ip-sh
   Reference:  RFC 9314

   Name:  ietf-bfd-ip-mh
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh
   Prefix:  bfd-ip-mh
   Reference:  RFC 9314

   Name:  ietf-bfd-lag
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-lag
   Prefix:  bfd-lag
   Reference:  RFC 9314

   Name:  ietf-bfd-mpls
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-mpls
   Prefix:  bfd-mpls
   Reference:  RFC 9314

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

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

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

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., «MPLS Generic Associated Channel», RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.

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

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

[RFC5883] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for Multihop Paths», RFC 5883, DOI 10.17487/RFC5883, June 2010, <https://www.rfc-editor.org/info/rfc5883>.

[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, «Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)», RFC 5884, DOI 10.17487/RFC5884, June 2010, <https://www.rfc-editor.org/info/rfc5884>.

[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., «Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)», RFC 5885, DOI 10.17487/RFC5885, June 2010, <https://www.rfc-editor.org/info/rfc5885>.

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

[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., «Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces», RFC 7130, DOI 10.17487/RFC7130, February 2014, <https://www.rfc-editor.org/info/rfc7130>.

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

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

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

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

[RFC8344] Bjorklund, M., «A YANG Data Model for IP Management», RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

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

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

[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, «A YANG Data Model for MPLS Base», RFC 8960, DOI 10.17487/RFC8960, December 2020, <https://www.rfc-editor.org/info/rfc8960>.

[RFC9127] Rahman, R., Ed., Zheng, L., Ed., Jethanandani, M., Ed., Pallagatti, S., and G. Mirsky, «YANG Data Model for Bidirectional Forwarding Detection (BFD)», RFC 9127, DOI 10.17487/RFC9127, October 2021, <https://www.rfc-editor.org/info/rfc9127>.

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

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.

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

[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, «YANG Data Model for Network Instances», RFC 8529, DOI 10.17487/RFC8529, March 2019, <https://www.rfc-editor.org/info/rfc8529>.

[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, «YANG Model for Logical Network Elements», RFC 8530, DOI 10.17487/RFC8530, March 2019, <https://www.rfc-editor.org/info/rfc8530>.

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

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

Приложение A. Пример настройки функции Echo

Как отмечено в параграфе 2.1.2, механизм запуска и остановки функции Echo (определён в [RFC5880] и обсуждается в [RFC5881]) зависит от реализации. В этом приложении дан пример реализации функции Echo через настройку.

   module: example-bfd-echo
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
               /bfd-ip-sh:sessions:
       +--rw echo {bfd-types:echo-mode}?
          +--rw desired-min-echo-tx-interval?    uint32
          +--rw required-min-echo-rx-interval?   uint32

A.1. Пример модуля YANG для настройки функции BFD Echo

В этом приложении приведён пример модуля YANG для настройки функции BFD Echo. Модуль импортирует и дополняет /routing/control-plane-protocols/control-plane-protocol из [RFC8349] и ссылается на [RFC5880].

   module example-bfd-echo {
     namespace "tag:example.com,2021:example-bfd-echo";
     prefix example-bfd-echo;

     import ietf-bfd-types {
       prefix bfd-types;
     }
     import ietf-bfd {
       prefix bfd;
     }
     import ietf-bfd-ip-sh {
       prefix bfd-ip-sh;
     }
     import ietf-routing {
       prefix rt;
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит пример дополнения YANG для настройки
        функции BFD Echo.

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

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

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

     revision 2021-10-21 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

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

     grouping echo-cfg-parms {
       description
         "Группировка BFD для параметров конфигурации Echo.";
       leaf desired-min-echo-tx-interval {
         type uint32;
         units "microseconds";
         default "0";
         description
           "Минимальный интервал, который локальная система будет 
            применять при отправке пакетов BFD Echo. Значение 0
            отключает функцию Echo, как указано в BFD (RFC 5880).";
       }
       leaf required-min-echo-rx-interval {
         type uint32;
         units "microseconds";
         default "0";
         description
           "Required Min Echo RX Interval, заданный в BFD (RFC 5880).";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
           + "bfd-ip-sh:sessions" {
       description
         "Дополнение для функции BFD Echo.";
       container echo {
         if-feature "bfd-types:echo-mode";
         description
           "Контейнер функции BFD Echo.";
         uses echo-cfg-parms;
       }
     }
   }

Приложение B. Обновления RFC 9127

Этот документ обновляет модуль ietf-bfd-types, определяя новое свойство client-base-cfg-parms и задавая оператор if-feature для условного включения определений таких параметров, как multiplier или desired-min-tx-interval. Оператор feature позволяет реализациям YANG для таких протоколов, как OSPF, IS-IS, PIM, BGP, поддерживать модели, где эти параметры не нужны, такие как множество сессий BFD на данном интерфейсе, и модели, требующие задания этих параметров на уровне сессии. В результате модуль BFD MPLS применяет base-cfg-parms вместо client-cfg-parms, чтобы иметь возможность безусловного включения всех параметров.

Модуль iana-bfd-types, заданный в RFC 9127, был передан для сопровождения IANA. Для обновления не требуется действий IANA.

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

Авторы признательны Nobo Akiya и Jeff Haas за поддержку этой работы. Спасибо Tom Petch за комментарии к документу. Спасибо Acee Lindem за его руководство. Спасибо Jürgen Schönwälder за важную роль в улучшении модулей YANG.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 9291                                        Orange
Category: Standards Track                       O. Gonzalez de Dios, Ed.
ISSN: 2070-1721                                               S. Barguil
                                                              Telefonica
                                                                L. Munoz
                                                                Vodafone
                                                          September 2022

A YANG Network Data Model for Layer 2 VPNs

Модель данных YANG для L2 VPN

PDF

Аннотация

Этот документ определяет сетевую модель L2VPN (L2VPN Network Model или L2NM), которая может служить для предоставления услуг виртуальных частных сетей на канальном уровне (Layer 2 Virtual Private Network или L2VPN) внутри сети (например, сети сервис-провайдера). L2NM дополняет модель сервиса L2VPN (L2VPN Service Model или L2SM), обеспечивая сетецентричное представление сервиса, который является внутренним для сервис-провайдера. Модель L2NM предназначена, в частности, для использования сетевыми контроллерами с целью получения данных конфигурации, которые будут передаваться соответствующим сетевым устройствам.

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

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

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

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

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

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

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

В [RFC8466] определена модель сервиса L2VPN (L2SM) — модель данных YANG, которую можно применять сервис-провайдерам и клиентам для заказа услуг L2VPN. Этот документ дополняет модель L2SM сетецентричным представлением сервиса — моделью L2NM.

Документ также определяет исходные версии двух поддерживаемых IANA модулей, задающих набор идентификаторов типов инкапсуляции BGP L2 (8.1. Модуль IANA для типов инкапсуляции BGP L2) и типов псевдопроводов (8.2. Модуль IANA для типов псевдопроводов). Эти типы применяются в L2NM для идентификации типов инкапсуляции L2 в зависимости от опции сигнализации, применяемой для предоставления услуг L2VPN. Это модули, поддерживаемые IANA, предназначены для повышения гибкости обработки новых типов вместо применения лишь ограниченного набора идентификаторов, определённого в самой модели L2NM. В параграфе 8.3 определён модуль YANG для управления сегментами Ethernet (Ethernet Segment или ES), которые требуются для создания виртуальных частных сетей Ethernet (Ethernet VPN или EVPN). Сссылки на сегменты Ethernet созданные с использованием этого модуля, могут включаться в модели L2NM для EVPN.

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

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

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

• Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762];

• Virtual Private Wire Service (VPWS) (параграф 3.1.1 в [RFC4664]);

• различные вариант EVPN:

  • VPWS EVPN [RFC8214];

  • PBB-EVPN (Provider Backbone Bridging Combined with Ethernet VPN) [RFC7623];

  • EVPN через MPLS [RFC7432];

  • EVPN через VXLAN [RFC8365].

Модель L2NM разработана для упрощения будущих вариантов и процедур L2 VPN (например, расширенная конфигурация, такая как отказоустойчивость псевдопровода или многосегментные псевдопровода [RFC7267]). Примеры, иллюстрирующие применение L2NM, представлены в Приложении A.

Этот документ использует модель YANG VPN, определённую в [RFC9181].

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

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

Этот документ использует терминологию из [RFC6241], [RFC7950], [RFC8466], [RFC4026], [RFC8309] и предполагает знакомство читателя с указанными документами.

В документе применяется термин «модель сети» (network model) в соответствии с определением из параграфа 2.1 в [RFC8969].

Символы, применяемые в схемах деревьев YANG, определены в [RFC8340].

Ниже приведены определения других терминов, используемых в этом документе.

Ethernet Segment (ES) — сегмент Ethernet

L2VPN Service Model (L2SM) — модель сервиса L2VPN

L2VPN Network Model (L2NM) — модель сети L2VPN

MAC-VRF

Network controller — контроллер сети

Service orchestrator — организатор (оркестратор) сервиса

Service provider network — сеть сервис-провайдера

VPN node — узел VPN

VPN network access — доступ в сеть VPN

VPN service provider — поставщик услуг VPN

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

ACL

BGP

BUM

CE

ES

ESI

EVPN

L2VPN

L2SM

L2NM

MAC

PBB

PCP

PE

QoS

RD

RT

VPLS

VPN

VPWS

VRF

4. Эталонная архитектура

На рисунке 1 показан пример использования L2NM. Напомним, что этот рисунок является расширением архитектуры, представленной в разделе 4⁵ [RFC8466] и делит оркестровку на 3 части — «Оркестровка службы», «Оркестровка сети» и «Оркестровка домена».

Как и в [RFC8466], соединение CE с PE обеспечивается через канал (bearer) с соединением L2. Канал-носитель относится в свойствам подключения ниже уровня L2, тогда как соединение указывает свойства, относящиеся к протоколу L2.

Читатель может обратиться к [RFC8309], где определены различия между «Моделью обслуживания клиентов» (Customer Service Model), «Моделью предоставления услуг» (Service Delivery Model), «Моделью конфигурации сети (Network Configuration Model) и «Моделью конфигурации устройства» (Device Configuration Model). Роли «Организации домена» (Domain Orchestration) и «Менеджера конфигурации» (Config Manager) могут играть контроллеры SDN.

                          +---------------+
                          |    Клиент     |
                          +-------+-------+
       Модель обслуживания клиента|
          например, l2vpn-svc     |
                          +-------+-------+
                          |  Оркестровка  |
                          |     службы    |
                          +-------+-------+
           Модель сети            |
        l2vpn-ntw + l2vpn-es      |
                          +-------+-------+
                          |  Оркестровка  |
                          |      сети     |
                          +-------+-------+
    Модель конфигурации сети      |
                      +-----------+-----------+
                      |                       |
             +--------+------+       +--------+------+
             |  Оркестровка  |       |  Оркестровка  |
             |     домена    |       |     домена    |
             +---+-----------+       +--------+------+
  Модель         |        |                   |
  конфигурации   |        |                   |
  устройства     |        |                   |
            +----+----+   |                   |
            |Менеджер |   |                   |
            |конфигур.|   |                   |
            +----+----+   |                   |
                 |        |                   |
                 | NETCONF/CLI..................
                 |        |                   |
               +--------------------------------+
                \             Сеть            /
                 \                           /
+----+  Канал     +----+              +----+         +----+
|CE A+ ---------- +PE A+              +PE B+ ------- +CE B|
+----+ Соединение +----+              +----+         +----+

        Сайт A                                 Сайт B

NETCONF:  Network Configuration Protocol
CLI:  Command-Line Interface

Рисунок 1. Взаимодействие L2SM и L2NM.

Клиенты могут применять разные средства запроса услуг, приводящие к созданию экземпляров L2NM. Киент может использовать L2SM или запрашивать на основе более абстрактных моделей услуги, основанные на службе L2VPN. Клиент может представить, например, профиль организации соединения IP (IP Connectivity Provisioning Profile или CPP), характеризующий запрошенные услуги [RFC7297], расширенные услуги VPN (VPN+) [VPN+-FRAMEWORK] или услуги сетевого слоя IETF (network slice) [IETF-NET-SLICES].

Отметим, что L2SM и L2NM могут применяться в контексте схемы абстрагирования и управления сетями TE (Abstraction and Control of TE Networks или ACTN) [RFC8453]. На рисунке 2 показан контроллер клиента (Customer Network Controller или CNC), координатор многодоменного сервиса (Multi-Domain Service Coordinator или MDSC) и контроллера сети обеспечения (Provisioning Network Controller или PNC).

        +----------------------------------+
        | Клиент                           |
        | +-----------------------------+  |
        | |             CNC             |  |
        | +-----------------------------+  |
        +----+-----------------------+-----+
             |                       |
             | L2SM                  | L2SM
             |                       |
   +---------+---------+   +---------+---------+
   | MDSC              |   |       MDSC        |
   | +---------------+ |   |    (родитель)     |
   | |  Организация  | |   +---------+---------+
   | |    сервиса    | |             |
   | +-------+-------+ |             | L2NM
   |         |         |             |
   |         | L2NM    |   +---------+---------+
   |         |         |   |       MDSC        |
   | +-------+-------+ |   |     (потомок)     |
   | |  Организация  | |   +---------+---------+
   | |      сети     | |             |
   | +---------------+ |             |
   +---------+---------+             |
             |                       |
             |   Конфигурация сети   |
             |                       |
+------------+-------+     +---------+------------+
| Контроллер         |     | Контроллер           |
| домена             |     | домена             |
|       +---------+  |     |    +---------+       |
|       |   PNC   |  |     |    |   PNC   |       |
|       +---------+  |     |    +---------+       |
+------------+-------+     +---------+------------+
             |                       |
             |Конфигурация устройства|
             |                       |
        +----+-----+            +----+-----+
        |Устройство|            |Устройство|
        +----------+            +----------+

Рисунок 2. L2SM и L2NM в контексте ACTN.

5. Взаимодействие с другими моделями YANG

Модуль ietf-vpn-common [RFC9181] включает набор идентификаторов, типов и группировок, которые могут применяться в связанных с VPN модулях YANG независимо от уровня (например, L2, L3) и типа модуля (например, модель сети или службы), включая будущие версии имеющихся модулей (например, [RFC8466]). В L2NM используются эти базовые типы и группировки.

L2NM также использует поддерживаемые IANA модули iana-bgp-l2-encaps (8.1. Модуль IANA для типов инкапсуляции BGP L2) и iana-pseudowire-types (8.2. Модуль IANA для типов псевдопроводов) для идентификации типов инкапсуляции L2 и псевдопроводов. Дополнительные сведения приведены в параграфах 7.5.2.1 и 7.5.2.3.

Для частного случая EVPN модель L2NM включает имя, указывающее сегмент Ethernet, созданный с помощью модуля ietf-ethernet-segment (8.3. Сегменты Ethernet). Примеры, связанные с ES, представлены в приложениях A.4 и A.5.

Как отмечено в разделе 4, L2NM применяется для управления службами L2VPN в сети сервис-провайдера. Модуль обеспечивает сетевое представление службы L2VPN. Это представление доступно лишь сервис-провайдеру и не раскрывается вовне (например, клиентам). Ниже описаны интерфейсы L2NM с другими модулями YANG.

L2SM

Модули сетевой топологии

Модули устройств

• Interfaces [RFC8343];
• BGP [BGP-YANG-MODEL];
• MPLS [RFC8960];
• Access Control Lists (ACLs) [RFC8519].

Использование L2NM для вывода специфических для устройства действий зависит от реализации.

6. Описание модуля YANG для сегмента Ethernet

Модель ietf-ethernet-segment (Рисунок 3) служит для управления набором сегментов Ethernet в контексте службы EVPN.

   module: ietf-ethernet-segment
     +--rw ethernet-segments
        +--rw ethernet-segment* [name]
           +--rw name                                 string
           +--rw esi-type?                            identityref
           +--rw (esi-choice)?
           |  +--:(directly-assigned)
           |  |  +--rw ethernet-segment-identifier?   yang:hex-string
           |  +--:(auto-assigned)
           |     +--rw esi-auto
           |        +--rw (auto-mode)?
           |        |  +--:(from-pool)
           |        |  |  +--rw esi-pool-name?                string
           |        |  +--:(full-auto)
           |        |     +--rw auto?                         empty
           |        +--ro auto-ethernet-segment-identifier?
           |                yang:hex-string
           +--rw esi-redundancy-mode?                 identityref
           +--rw df-election
           |  +--rw df-election-method?   identityref
           |  +--rw revertive?            boolean
           |  +--rw election-wait-time?   uint32
           +--rw split-horizon-filtering?             boolean
           +--rw pbb
           |  +--rw backbone-src-mac?   yang:mac-address
           +--rw member* [ne-id interface-id]
              +--rw ne-id           string
              +--rw interface-id    string

Рисунок 3. Структура дерева сегментов Ethernet.

Описания узлов данных, представленных на рисунке 3, приведены ниже.

name

esi-type

esi-type-0-operator

esi-type-1-lacp

esi-type-2-bridge

esi-type-3-mac

esi-type-4-router-id

esi-type-5-asn

Автоматически созданные значения можно извлекать с использованием auto-ethernet-segment-identifier.

esi-redundancy-mode

df-election

split-horizon-filtering

pbb

backbone-src-mac

member

7. Описание модуля YANG L2NM

Модуль L2NM (ietf-l2vpn-ntw, 8.4. L2NM) служит для управления L2VPN в сети сервис-провайдера. В частности, он позволяет создавать, изменять, удалять и отыскивать службы L2VPN в контроллере сети. Модуль предназначен для минимизации относящихся к клиенту сведений.

Полное дерево модуля создано с помощью pyang [PYANG]. Оно не включено в документ по причине слишком большого размера (параграф 3.3 в [RFC8340]) и для удобства читателей представлены фрагменты (субдеревья).

В последующих параграфах представлены некоторые узлы данных с текстовыми описаниями (например, 7.3. Услуги VPN, 7.5. Узлы VPN, 7.6. Доступ в сеть VPN). Эти описания даны не для случайных конечных пользователей, а для инженеров (сетей, систем, программ), использующих свой локальный контекст для представления и интерпретации таких сведений. Поэтому нет необходимости в тегах языка.

7.1. Общая структура модуля

Модуль ietf-l2vpn-ntw использует два основных контейнера: vpn-profiles и vpn-services (Рисунок 4).

Контейнер vpn-profiles применяется провайдером для задания и поддержки набора базовых профилей VPN для услуг VPN (7.2. Профили VPN).

Контейнер vpn-services поддерживает набор услуг L2VPN, поддерживаемых в сети сервис-провайдера. Модуль позволяет создавать новые службы L2VPN путём добавления нового экземпляра vpn-service, являющегося абстрактной структурой для службы VPN (7.3. Услуги VPN).

   module: ietf-l2vpn-ntw
     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          ...

Рисунок 4. Структура дерева L2NM.

7.2. Профили VPN

Контейнер vpn-profiles (Рисунок 5) применяется сервис-провайдером VPN для задания и поддержки набора профилей VPN [RFC9181], применяемых к одной или нескольким службам VPN.

     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  +--rw valid-provider-identifiers
        |     +--rw external-connectivity-identifier* [id]
        |     |       {external-connectivity}?
        |     |  +--rw id    string
        |     +--rw encryption-profile-identifier* [id]
        |     |  +--rw id    string
        |     +--rw qos-profile-identifier* [id]
        |     |  +--rw id    string
        |     +--rw bfd-profile-identifier* [id]
        |     |  +--rw id    string
        |     +--rw forwarding-profile-identifier* [id]
        |     |  +--rw id    string
        |     +--rw routing-profile-identifier* [id]
        |        +--rw id    string
        +--rw vpn-services
           ...

Рисунок 5. Субдерево профиля VPN.

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

external-connectivity-identifier

encryption-profile-identifier

qos-profile-identifier

bfd-profile-identifier

forwarding-profile-identifier

routing-profile-identifier

7.3. Услуги VPN

Структура данных vpn-service служит абстракцией службы L2VPN в сети сервис-провайдера. Каждая служба vpn-service однозначно указывается идентификатором vpn-id, имеющим значимость лишь в рамках сетевого контроллера. Субдерево vpn-services показано на рисунке 6.

        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw vpn-id                        vpn-common:vpn-id
              +--rw vpn-name?                     string
              +--rw vpn-description?              string
              +--rw customer-name?                string
              +--rw parent-service-id?            vpn-common:vpn-id
              +--rw vpn-type?                     identityref
              +--rw vpn-service-topology?         identityref
              +--rw bgp-ad-enabled?               boolean
              +--rw signaling-type?               identityref
              +--rw global-parameters-profiles
              |  ...
              +--rw underlay-transport
              |  +--rw (type)?
              |     +--:(abstract)
              |     |  +--rw transport-instance-id?   string
              |     |  +--rw instance-type?           identityref
              |     +--:(protocol)
              |        +--rw protocol*                identityref
              +--rw status
              |  +--rw admin-status
              |  |  +--rw status?         identityref
              |  |  +--rw last-change?   yang:date-and-time
              |  +--ro oper-status
              |     +--ro status?         identityref
              |     +--ro last-change?   yang:date-and-time
              +--rw vpn-nodes
                 ...

Рисунок 6. Субдерево служб VPN.

Ниже приведены описания узлов данных службы VPN, представленных на рисунке 6.

vpn-id

vpn-name

vpn-description

customer-name

parent-service-id

vpn-type

vpls

vpws

vpws-evpn

pbb-evpn

mpls-evpn

vxlan-evpn

vpn-service-topology

bgp-ad-enabled

signaling-type

bgp-signaling

l2vpn-bgp

evpn-bgp

ldp-signaling

l2tp-signaling

Таблица 1. Опции сигнализации для типа услуг VPN.

global-parameters-profiles

underlay-transport

status

vpn-node

7.4. Профили глобальных параметров

В global-parameters-profile определены параметры для многократного применения в одном экземпляре службы L2VPN (vpn-service). Профили глобальных параметров задаются на уровне службы VPN, активируются на уровне узла VPN, а затем активированный профиль VPN может применяться на уровне доступа в сеть VPN. Каждый профиль экземпляра VPN указывается profile-id. Некоторые узлы данных могут подстраиваться на уровне узла или доступа в сеть VPN и будут предпочтительней глобальных значений. Субдерево global-parameters-profile показано на рисунке7.

        ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw global-parameters-profiles
              |  +--rw global-parameters-profile* [profile-id]
              |     +--rw profile-id                  string
              |     +--rw (rd-choice)?
              |     |  +--:(directly-assigned)
              |     |  |  +--rw rd?
              |     |  |          rt-types:route-distinguisher
              |     |  +--:(directly-assigned-suffix)
              |     |  |  +--rw rd-suffix?            uint16
              |     |  +--:(auto-assigned)
              |     |  |  +--rw rd-auto
              |     |  |     +--rw (auto-mode)?
              |     |  |     |  +--:(from-pool)
              |     |  |     |  |  +--rw rd-pool-name?   string
              |     |  |     |  +--:(full-auto)
              |     |  |     |     +--rw auto?           empty
              |     |  |     +--ro auto-assigned-rd?
              |     |  |             rt-types:route-distinguisher
              |     |  +--:(auto-assigned-suffix)
              |     |  |  +--rw rd-auto-suffix
              |     |  |     +--rw (auto-mode)?
              |     |  |     |  +--:(from-pool)
              |     |  |     |  |  +--rw rd-pool-name?        string
              |     |  |     |  +--:(full-auto)
              |     |  |     |     +--rw auto?                empty
              |     |  |     +--ro auto-assigned-rd-suffix?   uint16
              |     |  +--:(no-rd)
              |     |     +--rw no-rd?                empty
              |     +--rw vpn-target* [id]
              |     |  +--rw id                  uint8
              |     |  +--rw route-targets* [route-target]
              |     |  |  +--rw route-target    rt-types:route-target
              |     |  +--rw route-target-type
              |     |          rt-types:route-target-type
              |     +--rw vpn-policies
              |     |  +--rw import-policy?   string
              |     |  +--rw export-policy?   string
              |     +--rw local-autonomous-system?    inet:as-number
              |     +--rw svc-mtu?                    uint32
              |     +--rw ce-vlan-preservation?       boolean
              |     +--rw ce-vlan-cos-preservation?   boolean
              |     +--rw control-word-negotiation?   boolean
              |     +--rw mac-policies
              |     |  +--rw mac-addr-limit
              |     |  |  +--rw limit-number?    uint16
              |     |  |  +--rw time-interval?   uint32
              |     |  |  +--rw action?          identityref
              |     |  +--rw mac-loop-prevention
              |     |     +--rw window?            uint32
              |     |     +--rw frequency?         uint32
              |     |     +--rw retry-timer?       uint32
              |     |     +--rw protection-type?   identityref
              |     +--rw multicast {vpn-common:multicast}?
              |        +--rw enabled?                 boolean
              |        +--rw customer-tree-flavors
              |           +--rw tree-flavor*   identityref
                       ...

Рисунок 7. Субдерево профиля глобальных параметров.

profile-id

rd

vpn-targets

local-autonomous-system

svc-mtu

ce-vlan-preservation

ce-vlan-cos-preservation

control-word-negotiation

mac-policies

mac-addr-limit

limit-number

time-interval

action

mac-loop-prevention

window

frequency

retry-timer

protection-type

multicast

7.5. Узлы VPN

Абстракция vpn-node (Рисунок 8) представляет набор правил для узла сети, относящегося к одному vpn-service. Узел vpn-node содержит vpn-network-accesses, являющиеся интерфейсами для создания VPN. Сайты клиентов подключаются к vpn-network-accesses.

     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    +--rw vpn-node-id            vpn-common:vpn-id
                    +--rw description?           string
                    +--rw ne-id?                 string
                    +--rw role?                  identityref
                    +--rw router-id?             rt-types:router-id
                    +--rw active-global-parameters-profiles
                    |  +--rw global-parameters-profile* [profile-id]
                    |     +--rw profile-id                  leafref
                    |     +--rw local-autonomous-system?
                    |     |       inet:as-number
                    |     +--rw svc-mtu?                    uint32
                    |     +--rw ce-vlan-preservation?       boolean
                    |     +--rw ce-vlan-cos-preservation?   boolean
                    |     +--rw control-word-negotiation?   boolean
                    |     +--rw mac-policies
                    |     |  +--rw mac-addr-limit
                    |     |  |  +--rw limit-number?    uint16
                    |     |  |  +--rw time-interval?   uint32
                    |     |  |  +--rw action?          identityref
                    |     |  +--rw mac-loop-prevention
                    |     |     +--rw window?            uint32
                    |     |     +--rw frequency?         uint32
                    |     |     +--rw retry-timer?       uint32
                    |     |     +--rw protection-type?   identityref
                    |     +--rw multicast {vpn-common:multicast}?
                    |        +--rw enabled?                 boolean
                    |        +--rw customer-tree-flavors
                    |           +--rw tree-flavor*   identityref
                    +--rw status
                    |  ...
                    +--rw bgp-auto-discovery
                    |  ...
                    +--rw signaling-option
                    |  ...
                    +--rw vpn-network-accesses
                       ...

Рисунок 8. Субдерево узлов VPN.

vpn-node-id

description

ne-id

role

router-id

active-global-parameters-profiles

status

bgp-auto-discovery

signaling-option

vpn-network-accesses

7.5.1. Автоматическое обнаружение BGP

Контейнер bgp-auto-discovery (Рисунок 9) включает сведения, требуемые для активизации автоматического обнаружения BGP [RFC4761][RFC6624].

     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw bgp-auto-discovery
                    |  +--rw (bgp-type)?
                    |  |  +--:(l2vpn-bgp)
                    |  |  |  +--rw vpn-id?
                    |  |  |          vpn-common:vpn-id
                    |  |  +--:(evpn-bgp)
                    |  |     +--rw evpn-type?           leafref
                    |  |     +--rw auto-rt-enable?      boolean
                    |  |     +--ro auto-route-target?
                    |  |             rt-types:route-target
                    |  +--rw (rd-choice)?
                    |  |  +--:(directly-assigned)
                    |  |  |  +--rw rd?
                    |  |  |          rt-types:route-distinguisher
                    |  |  +--:(directly-assigned-suffix)
                    |  |  |  +--rw rd-suffix?           uint16
                    |  |  +--:(auto-assigned)
                    |  |  |  +--rw rd-auto
                    |  |  |     +--rw (auto-mode)?
                    |  |  |     |  +--:(from-pool)
                    |  |  |     |  |  +--rw rd-pool-name?   string
                    |  |  |     |  +--:(full-auto)
                    |  |  |     |     +--rw auto?           empty
                    |  |  |     +--ro auto-assigned-rd?
                    |  |  |             rt-types:route-distinguisher
                    |  |  +--:(auto-assigned-suffix)
                    |  |  |  +--rw rd-auto-suffix
                    |  |  |     +--rw (auto-mode)?
                    |  |  |     |  +--:(from-pool)
                    |  |  |     |  |  +--rw rd-pool-name?        string
                    |  |  |     |  +--:(full-auto)
                    |  |  |     |     +--rw auto?                empty
                    |  |  |     +--ro auto-assigned-rd-suffix?   uint16
                    |  |  +--:(no-rd)
                    |  |     +--rw no-rd?               empty
                    |  +--rw vpn-target* [id]
                    |  |  +--rw id                   uint8
                    |  |  +--rw route-targets* [route-target]
                    |  |  |  +--rw route-target    rt-types:route-target
                    |  |  +--rw route-target-type
                    |  |          rt-types:route-target-type
                    |  +--rw vpn-policies
                    |     +--rw import-policy?   string
                    |     +--rw export-policy?   string
                    +--rw signaling-option
                    |  ...
                    +--rw vpn-network-accesses
                       ...

Рисунок 9. Субдерево автоматического обнаружения BGP.

Как отмечено в разделе 1 [RFC6624], все методы на основе BGP включают указание идентификатора VPN, служащего для унификации компонентов данной сети VPN и поддержки автоматического обнаружения, отсюда и vpn-id.

Для частного случая EVPN в L2NM поддерживается автоматических вывод RT на основе Ethernet Tag ID, заданного в параграфе 7.10.1 [RFC7432]. Поставщик услуг VPN может включить или отключить эту функцию с помощью auto-rt-enable. Заданное значение RT можно получить с использованием auto-route-target. Для всех вариантов L2VPN на основе BGP применяются другие узлы данных, такие как RD и RT. Эти узлы имеют такую же структуру, которая показана в параграфе 7.4. Профили глобальных параметров.

7.5.2. Сигнальные опции

Контейнер signaling-option (Рисунок 10) определяет набор узлов для данного протокола сигнализации, применяемого услугой L2VPN. Как указано в параграфе 7.3поддерживается несколько опций сигнализации для обмена сведениями о членстве между PE в L2VPN. Применяемый в L2VPN тип сигнализации контрлируется на уровне сервиса VPN с помощью signaling-type.

   ...
   +--rw vpn-nodes
      +--rw vpn-node* [vpn-node-id]
      ...
      +--rw signaling-option
      |  +--rw advertise-mtu?        boolean
      |  +--rw mtu-allow-mismatch?   boolean
      |  +--rw signaling-type?       leafref
      |  +--rw (signaling-option)?
      |     +--:(bgp)
      |     |  ...
      |     +--:(ldp-or-l2tp)
      |        +--rw ldp-or-l2tp
      |           ...
      |           +--rw (ldp-or-l2tp)?
      |              +--:(ldp)
      |              |  ...
      |              +--:(l2tp)
      |                 ...

Рисунок 10. Субдерево опций сигнализации.

advertise-mtu

mtu-allow-mismatch

signaling-type

bgp

ldp

l2tp

Отметим, что варианты LDP и L2TP связаны (ldp-or-l2tp), поскольку они используют общий набор параметров, подробно описанных в параграфах 7.5.2.2. LDP и 7.5.2.3. L2TP.

7.5.2.1. BGP

Структура связанных с BGP узлов данных приведена на рисунке 11.

      ...
      |  +--rw (signaling-option)?
      |     ...
      |     +--:(bgp)
      |     |  +--rw (bgp-type)?
      |     |     +--:(l2vpn-bgp)
      |     |     |  +--rw ce-range?     uint16
      |     |     |  +--rw pw-encapsulation-type?
      |     |     |  |       identityref
      |     |     |  +--rw vpls-instance
      |     |     |     +--rw vpls-edge-id?         uint16
      |     |     |     +--rw vpls-edge-id-range?   uint16
      |     |     +--:(evpn-bgp)
      |     |        +--rw evpn-type?                leafref
      |     |        +--rw service-interface-type?
      |     |        |       identityref
      |     |        +--rw evpn-policies
      |     |           +--rw mac-learning-mode?
      |     |           |       identityref
      |     |           +--rw ingress-replication?
      |     |           |       boolean
      |     |           +--rw p2mp-replication?
      |     |           |       boolean
      |     |           +--rw arp-proxy {vpn-common:ipv4}?
      |     |           |  +--rw enable?           boolean
      |     |           |  +--rw arp-suppression?
      |     |           |  |       boolean
      |     |           |  +--rw ip-mobility-threshold?
      |     |           |  |       uint16
      |     |           |  +--rw duplicate-ip-detection-interval?
      |     |           |          uint16
      |     |           +--rw nd-proxy {vpn-common:ipv6}?
      |     |           |  +--rw enable?          boolean
      |     |           |  +--rw nd-suppression?
      |     |           |  |       boolean
      |     |           |  +--rw ip-mobility-threshold?
      |     |           |  |       uint16
      |     |           |  +--rw duplicate-ip-detection-interval?
      |     |           |          uint16
      |     |           +--rw underlay-multicast?
      |     |           |       boolean
      |     |           +--rw flood-unknown-unicast-suppression?
      |     |           |       boolean
      |     |           +--rw vpws-vlan-aware?        boolean
      |     |           +--rw bum-management
      |     |           |  +--rw discard-broadcast?
      |     |           |  |       boolean
      |     |           |  +--rw discard-unknown-multicast?
      |     |           |  |       boolean
      |     |           |  +--rw discard-unknown-unicast?
      |     |           |          boolean
      |     |           +--rw pbb
      |     |              +--rw backbone-src-mac?
      |     |                      yang:mac-address
      |     +--:(ldp-or-l2tp)
      |        ...

Рисунок 11. Субдерево опции сигнализации (BGP).

Удалённым CE, имеющим право подключаться к одной VPN, следует соответствовать диапазону CE (‘ce-range’), как указано в параграфе 2.2.3 [RFC6624]. Тип pw-encapsulation-type служит для управления типом инкапсуляции псевдопровода control (раздел 3 в [RFC6624]), значение берётся из модуля IANA iana-bgp-l2-encaps (параграф 8.1).

Для конкретного случая VPLS представлен идентификатор VE ID (VPLS Edge Identifier, vpls-edge-id) и диапазон VE ID (vpls-edge-id-range) в соответствии с параграфом 3.2 в [RFC4761]. Если нужны разные VE ID (например, множество адресов, как в параграфе 3.5 [RFC4761]), эти идентификаторы настраиваются на уровне доступа VPN (signaling-option, 7.6. Доступ в сеть VPN).

Для L2VPN, связанных с EVPN, service-interface-type указывает, имеет ли служба основанный на VLAN, осведомленный о VLAN, или привязанный к VLAN интерфейс (раздел 6 в [RFC7432]). Кроме того, может быть представлен набор правил, такой как режим изучения MAC адресов (раздел 9 в [RFC7432]), входная репликация (параграф 12.1 в [RFC7432]), протокол распознавания адресов (Address Resolution Protocol или ARP) прокси обнаружения соседей (Neighbor Discovery или ND, раздел 10 в [RFC7432]), обработка широковещательных, неизвестных индивидуальных и групповых (Broadcast, Unknown Unicast, or Multicast или BUM) пакетов (раздел 12 в [RFC7432]) и т. п.

7.5.2.2. LDP

L2NM поддерживает настройку параметров, рассмотренных в разделе 6 [RFC4762]. Такие параметры включают идентификатор группы подключений (Attachment Group Identifier или AGI, он же VPLS-id), индивидуальный идентификатор подключения источника (Source Attachment Individual Identifier или SAII), список партнёров, связанных с индивидуальным идентификатором целевого подключения (Target Attachment Individual Identifier или TAII), тип и описание псевдопровода type (Рисунок 12). В отличие от BGP, поддерживаются лишь режимы Ethernet и Ethernet с тегами. AGI, SAII и TAII кодируются в соответствии с типами, заданными в параграфе 3.4 [RFC4446].

      ...
      |  +--rw (signaling-option)?
      |     ...
      |     +--:(bgp)
      |     |  ...
      |     +--:(ldp-or-l2tp)
      |        +--rw ldp-or-l2tp
      |           +--rw agi?
      |           |       rt-types:route-distinguisher
      |           +--rw saii?                      uint32
      |           +--rw remote-targets* [taii]
      |           |  +--rw taii         uint32
      |           |  +--rw peer-addr    inet:ip-address
      |           +--rw (ldp-or-l2tp)?
      |              +--:(ldp)
      |              |  +--rw t-ldp-pw-type?
      |              |  |       identityref
      |              |  +--rw pw-type?       identityref
      |              |  +--rw pw-description?      string
      |              |  +--rw mac-addr-withdraw?   boolean
      |              |  +--rw pw-peer-list*
      |              |  |       [peer-addr vc-id]
      |              |  |  +--rw peer-addr
      |              |  |  |       inet:ip-address
      |              |  |  +--rw vc-id   string
      |              |  |  +--rw pw-priority?   uint32
      |              |  +--rw qinq
      |              |     +--rw s-tag   dot1q-types:vlanid
      |              |     +--rw c-tag   dot1q-types:vlanid
      |              +--:(l2tp)
      |                 ...
      ...

Рисунок 12. Субдерево опции сигнализации (LDP).

7.5.2.3. L2TP

L2NM поддерживает настройку параметров, рассмотренных в разделе 4 [RFC4667]. Эти параметры включают Router ID для однозначного указания PE, тип псевдопровода, AGI, SAII и список партнеров, связанных с TAII (Рисунок 13). Значение pseudowire-type берётся из модуля IANA iana-pseudowire-types (8.2. Модуль IANA для типов псевдопроводов).

      ...
      |  +--rw (signaling-option)?
      |     ...
      |     +--:(bgp)
      |     |  ...
      |     +--:(ldp-or-l2tp)
      |        +--rw ldp-or-l2tp
      |           +--rw agi?
      |           |       rt-types:route-distinguisher
      |           +--rw saii?                      uint32
      |           +--rw remote-targets* [taii]
      |           |  +--rw taii         uint32
      |           |  +--rw peer-addr    inet:ip-address
      |           +--rw (ldp-or-l2tp)?
      |              +--:(ldp)
      |              |  ...
      |              +--:(l2tp)
      |                 +--rw router-id?
      |                 |       rt-types:router-id
      |                 +--rw pseudowire-type?
      |                         identityref
      ...

Рисунок 13. Субдерево опции сигнализации (L2TP).

7.6. Доступ в сеть VPN

Доступ к службе VPN представляет контейнер vpn-network-access (Рисунок 14), содержащий параметры, описывающие свеедния о доступе для трафика, относящегося к отдельной сети L2VPN. В vpn-network-access включаются такие сведения, как соединение, для которого определяется доступ, конкретные требования к службе уровня L2 и т. п.

              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          +--rw id                     vpn-common:vpn-id
                          +--rw description?              string
                          +--rw interface-id?             string
                          +--rw active-vpn-node-profile?   leafref
                          +--rw status
                          |  ...
                          +--rw connection
                          |  ...
                          +--rw (signaling-option)?
                          |  +--:(bgp)
                          |     +--rw (bgp-type)?
                          |        +--:(l2vpn-bgp)
                          |        |  +--rw ce-id?             uint16
                          |        |  +--rw remote-ce-id?      uint16
                          |        |  +--rw vpls-instance
                          |        |     +--rw vpls-edge-id?   uint16
                          |        +--:(evpn-bgp)
                          |           +--rw df-preference?     uint16
                          |           +--rw vpws-service-instance
                          |              ...
                          +--rw group* [group-id]
                          |  +--rw group-id                       string
                          |  +--rw precedence?               identityref
                          |  +--rw ethernet-segment-identifier?
                          |                              l2vpn-es:es-ref
                          +--rw ethernet-service-oam
                          |  ...
                          +--rw service
                             ...

Рисунок 14. Субдерево доступа с сеть VPN.

id

description

interface-id

active-vpn-node-profile

status

connection

signaling-option

group

ethernet-service-oam

service

7.6.1. Соединение

Контейнер connection (Рисунок 15) служит для настройки соответствующих свойств интерфейса, с которым соединён экземпляр L2VPN (например, типа инкапсуляции, интерфейсов агрегирования LAG, split-horizon). L2NM поддерживает манипуляции с тегами (например, перезапись).

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

Поддерживается ссылка на опорный канал (bearer), чтобы сохранить связь между L2SM и L2NM при использовании обеих моделей данных в одном развёртывании.

Реализации (обычно, контроллеру сети) следует обеспечивать некоторые проверки согласованности для интерфейсов LAG, поскольку вовлечённым узлам нужно предоставлять одни и те же сведения (например, LACP system-id).

L2NM наследует структуру member-link-list от L2SM (включая индикацию поддержки OAM 802.3ah [IEEE-802-3ah]).

              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          ...
                          +--rw connection
                          |  +--rw l2-termination-point?
                          |  |       string
                          |  +--rw local-bridge-reference?
                          |  |       string
                          |  +--rw bearer-reference?         string
                          |  |       {vpn-common:bearer-reference}?
                          |  +--rw encapsulation
                          |  |  +--rw encap-type?            identityref
                          |  |  +--rw dot1q
                          |  |  |  +--rw tag-type?           identityref
                          |  |  |  +--rw cvlan-id?
                          |  |  |  |       dot1q-types:vlanid
                          |  |  |  +--rw tag-operations
                          |  |  |     +--rw (op-choice)?
                          |  |  |     |  +--:(pop)
                          |  |  |     |  |  +--rw pop?         empty
                          |  |  |     |  +--:(push)
                          |  |  |     |  |  +--rw push?        empty
                          |  |  |     |  +--:(translate)
                          |  |  |     |     +--rw translate?   empty
                          |  |  |     +--rw tag-1?
                          |  |  |     |       dot1q-types:vlanid
                          |  |  |     +--rw tag-1-type?
                          |  |  |     |       dot1q-types:dot1q-tag-type
                          |  |  |     +--rw tag-2?
                          |  |  |     |       dot1q-types:vlanid
                          |  |  |     +--rw tag-2-type?
                          |  |  |             dot1q-types:dot1q-tag-type
                          |  |  +--rw priority-tagged
                          |  |  |  +--rw tag-type?   identityref
                          |  |  +--rw qinq
                          |  |     +--rw tag-type?         identityref
                          |  |     +--rw svlan-id
                          |  |     |       dot1q-types:vlanid
                          |  |     +--rw cvlan-id
                          |  |     |       dot1q-types:vlanid
                          |  |     +--rw tag-operations
                          |  |        +--rw (op-choice)?
                          |  |        |  +--:(pop)
                          |  |        |  |  +--rw pop?         uint8
                          |  |        |  +--:(push)
                          |  |        |  |  +--rw push?        empty
                          |  |        |  +--:(translate)
                          |  |        |     +--rw translate?   empty
                          |  |        +--rw tag-1?
                          |  |        |       dot1q-types:vlanid
                          |  |        +--rw tag-1-type?
                          |  |        |       dot1q-types:dot1q-tag-type
                          |  |        +--rw tag-2?
                          |  |        |       dot1q-types:vlanid
                          |  |        +--rw tag-2-type?
                          |  |                dot1q-types:dot1q-tag-type
                          |  +--rw lag-interface
                          |     |    {vpn-common:lag-interface}?
                          |     +--rw lag-interface-id?   string
                          |     +--rw lacp
                          |     |  +--rw lacp-state?         boolean
                          |     |  +--rw mode?               identityref
                          |     |  +--rw speed?              uint32
                          |     |  +--rw mini-link-num?      uint32
                          |     |  +--rw system-id?
                          |     |  |       yang:mac-address
                          |     |  +--rw admin-key?          uint16
                          |     |  +--rw system-priority?    uint16
                          |     |  +--rw member-link-list
                          |     |  |  +--rw member-link* [name]
                          |     |  |     +--rw name         string
                          |     |  |     +--rw speed?       uint32
                          |     |  |     +--rw mode?   identityref
                          |     |  |     +--rw link-mtu?    uint32
                          |     |  |     +--rw oam-802.3ah-link
                          |     |  |        |    {oam-3ah}?
                          |     |  |        +--rw enable?   boolean
                          |     |  +--rw flow-control?       boolean
                          |     |  +--rw lldp?               boolean
                          |     +--rw split-horizon
                          |        +--rw group-name?   string
                          ...

Рисунок 15. Субдерево соединения.

7.6.2. Экземпляр службы EVPN-VPWS

Контейнер vpws-service-instance представляет локальный и удалённый экземпляр службы VPWS (VPWS Service Instance или VSI) [RFC8214] и присутствует лишь при vpn-type = VPWS-EVPN. Как показано на рисунке 16, VSI могут настравиваться сервис-провайдером или создаваться автоматически. Пример использования L2NM для настройки экземпляров VPWS-EVPN приведён в приложении A.4.

   ...
   +--rw vpn-nodes
      +--rw vpn-node* [vpn-node-id]
         ...
         +--rw vpn-network-accesses
            +--rw vpn-network-access* [id]
               ...
               +--rw (signaling-option)?
               |  +--:(bgp)
               |     +--rw (bgp-type)?
               |        +--:(l2vpn-bgp)
               |        |  ...
               |        +--:(evpn-bgp)
               |           +--rw df-preference?     uint16
               |           +--rw vpws-service-instance
               |              +--rw (local-vsi-choice)?
               |              |  +--:(directly-assigned)
               |              |  |  +--rw local-vpws-service-instance?
               |              |  |          uint32
               |              |  +--:(auto-assigned)
               |              |     +--rw local-vsi-auto
               |              |        +--rw (auto-mode)?
               |              |        |  +--:(from-pool)
               |              |        |  |  +--rw vsi-pool-name?
               |              |        |  |          string
               |              |        |  +--:(full-auto)
               |              |        |     +--rw auto?      empty
               |              |        +--ro auto-local-vsi?  uint32
               |              +--rw (remote-vsi-choice)?
               |                 +--:(directly-assigned)
               |                 |  +--rw remote-vpws-service-instance?
               |                 |          uint32
               |                 +--:(auto-assigned)
               |                    +--rw remote-vsi-auto
               |                       +--rw (auto-mode)?
               |                       |  +--:(from-pool)
               |                       |  |  +--rw vsi-pool-name?
               |                       |  |          string
               |                       |  +--:(full-auto)
               |                       |     +--rw auto?       empty
               |                       +--ro auto-remote-vsi?  uint32
               ...

Рисунок 16. Субдерево экземпляра службы EVPN-VPWS.

7.6.3. Ethernet OAM

Ethernet OAM относится к [IEEE-802-1ag] и [ITU-T-Y-1731]. Как показано на рисунке 17, L2NM наследует структуру из параграфа 5.3.2.2.6 в [RFC8466] для OAM.

     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          ...
                          +--rw ethernet-service-oam
                          |  +--rw md-name?        string
                          |  +--rw md-level?       uint8
                          |  +--rw cfm-802.1-ag
                          |  |  +--rw n2-uni-c* [maid]
                          |  |  |  +--rw maid                string
                          |  |  |  +--rw mep-id?             uint32
                          |  |  |  +--rw mep-level?          uint32
                          |  |  |  +--rw mep-up-down?
                          |  |  |  |                   enumeration
                          |  |  |  +--rw remote-mep-id?      uint32
                          |  |  |  +--rw cos-for-cfm-pdus?   uint32
                          |  |  |  +--rw ccm-interval?       uint32
                          |  |  |  +--rw ccm-holdtime?       uint32
                          |  |  |  +--rw ccm-p-bits-pri?
                          |  |  |          ccm-priority-type
                          |  |  +--rw n2-uni-n* [maid]
                          |  |     +--rw maid                string
                          |  |     +--rw mep-id?             uint32
                          |  |     +--rw mep-level?          uint32
                          |  |     +--rw mep-up-down?
                          |  |     |                    enumeration
                          |  |     +--rw remote-mep-id?      uint32
                          |  |     +--rw cos-for-cfm-pdus?   uint32
                          |  |     +--rw ccm-interval?       uint32
                          |  |     +--rw ccm-holdtime?       uint32
                          |  |     +--rw ccm-p-bits-pri?
                          |  |             ccm-priority-type
                          |  +--rw y-1731* [maid]
                          |     +--rw maid               string
                          |     +--rw mep-id?            uint32
                          |     +--rw pm-type?           identityref
                          |     +--rw remote-mep-id?     uint32
                          |     +--rw message-period?    uint32
                          |     +--rw measurement-interval?   uint32
                          |     +--rw cos?        uint32
                          |     +--rw loss-measurement?      boolean
                          |     +--rw synthetic-loss-measurement?
                          |     |       boolean
                          |     +--rw delay-measurement
                          |     |  +--rw enable-dm?   boolean
                          |     |  +--rw two-way?     boolean
                          |     +--rw frame-size?     uint32
                          |     +--rw session-type?   enumeration
                          ...

Рисунок 17. Субдерево OAM.

7.6.4. Службы

Контейнер service (Рисунок 18) обеспечивает набор специфических для сервиса конфигураций, таких как QoS.

     +--rw l2vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          ...
                          +--rw service
                             +--rw mtu?            uint32
                             +--rw svc-pe-to-ce-bandwidth
                             |       {vpn-common:inbound-bw}?
                             |  ...
                             +--rw svc-ce-to-pe-bandwidth
                             |       {vpn-common:outbound-bw}?
                             |  ...
                             +--rw qos {vpn-common:qos}?
                             |  ...
                             +--rw mac-policies
                             |  ...
                             +--rw broadcast-unknown-unicast-multicast
                                ...

Рисунок 18. Субдерево службы в целом.

mtu

svc-pe-to-ce-bandwidth и svc-ce-to-pe-bandwidth

bw-per-cos

bw-per-port

bw-per-site

bw-per-service

                             +--rw service
                                ...
                                +--rw svc-pe-to-ce-bandwidth
                                |       {vpn-common:inbound-bw}?
                                |  +--rw pe-to-ce-bandwidth* [bw-type]
                                |     +--rw bw-type      identityref
                                |     +--rw (type)?
                                |        +--:(per-cos)
                                |        |  +--rw cos* [cos-id]
                                |        |     +--rw cos-id    uint8
                                |        |     +--rw cir?      uint64
                                |        |     +--rw cbs?      uint64
                                |        |     +--rw eir?      uint64
                                |        |     +--rw ebs?      uint64
                                |        |     +--rw pir?      uint64
                                |        |     +--rw pbs?      uint64
                                |        +--:(other)
                                |           +--rw cir?   uint64
                                |           +--rw cbs?   uint64
                                |           +--rw eir?   uint64
                                |           +--rw ebs?   uint64
                                |           +--rw pir?   uint64
                                |           +--rw pbs?   uint64
                                +--rw svc-ce-to-pe-bandwidth
                                |       {vpn-common:outbound-bw}?
                                |  +--rw ce-to-pe-bandwidth* [bw-type]
                                |     +--rw bw-type      identityref
                                |     +--rw (type)?
                                |        +--:(per-cos)
                                |        |  +--rw cos* [cos-id]
                                |        |     +--rw cos-id    uint8
                                |        |     +--rw cir?      uint64
                                |        |     +--rw cbs?      uint64
                                |        |     +--rw eir?      uint64
                                |        |     +--rw ebs?      uint64
                                |        |     +--rw pir?      uint64
                                |        |     +--rw pbs?      uint64
                                |        +--:(other)
                                |           +--rw cir?   uint64
                                |           +--rw cbs?   uint64
                                |           +--rw eir?   uint64
                                |           +--rw ebs?   uint64
                                |           +--rw pir?   uint64
                                |           +--rw pbs?   uint64
                                ...

Рисунок 19. Субдерево пропускной способности службы.

qos

                           +--rw service
                              ...
                              +--rw qos {vpn-common:qos}?
                              |  +--rw qos-classification-policy
                              |  |  +--rw rule* [id]
                              |  |     +--rw id                string
                              |  |     +--rw (match-type)?
                              |  |     |  +--:(match-flow)
                              |  |     |  |  +--rw match-flow
                              |  |     |  |     +--rw dscp?   inet:dscp
                              |  |     |  |     +--rw dot1q?     uint16
                              |  |     |  |     +--rw pcp?       uint8
                              |  |     |  |     +--rw src-mac-address?
                              |  |     |  |     |       yang:mac-address
                              |  |     |  |     +--rw dst-mac-address?
                              |  |     |  |     |       yang:mac-address
                              |  |     |  |     +--rw color-type?
                              |  |     |  |     |       identityref
                              |  |     |  |     +--rw any?         empty
                              |  |     |  +--:(match-application)
                              |  |     |     +--rw match-application?
                              |  |     |             identityref
                              |  |     +--rw target-class-id?     string
                              |  +--rw qos-profile
                              |     +--rw qos-profile* [profile]
                              |        +--rw profile      leafref
                              |        +--rw direction?   identityref
                              ...

Рисунок 20. Субдерево QoS.

mac-policies

                            +--rw service
                               ...
                               +--rw mac-policies
                               |  +--rw access-control-list* [name]
                               |  |  +--rw name                  string
                               |  |  +--rw src-mac-address*
                               |  |  |       yang:mac-address
                               |  |  +--rw src-mac-address-mask*
                               |  |  |       yang:mac-address
                               |  |  +--rw dst-mac-address*
                               |  |  |       yang:mac-address
                               |  |  +--rw dst-mac-address-mask*
                               |  |  |       yang:mac-address
                               |  |  +--rw action?          identityref
                               |  |  +--rw rate-limit?      decimal64
                               |  +--rw mac-loop-prevention
                               |  |  +--rw window?            uint32
                               |  |  +--rw frequency?         uint32
                               |  |  +--rw retry-timer?       uint32
                               |  |  +--rw protection-type?  identityref
                               |  +--rw mac-addr-limit
                               |     +--rw limit-number?    uint16
                               |     +--rw time-interval?   uint32
                               |     +--rw action?          identityref
                               ...

Рисунок 21. Субдерево правил MAC.

broadcast-unknown-unicast-multicast

                          +--rw service
                             ...
                             +--rw broadcast-unknown-unicast-multicast
                                +--rw multicast-site-type?
                                |       enumeration
                                +--rw multicast-gp-address-mapping* [id]
                                |  +--rw id                 uint16
                                |  +--rw vlan-id            uint32
                                |  +--rw mac-gp-address
                                |  |       yang:mac-address
                                |  +--rw port-lag-number?   uint32
                                +--rw bum-overall-rate?     uint64

Рисунок 22. Субдерево BUM.

8. Модули YANG

8.1. Модуль IANA для типов инкапсуляции BGP L2

Модуль YANG iana-bgp-l2-encaps соответствует реестру BGP Layer 2 Encapsulation Types [IANA-BGP-L2]. Модуль ссылается на [RFC3032], [RFC4446], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], [RFC5086].

   <CODE BEGINS> file "iana-bgp-l2-encaps@2022-09-20.yang"
   module iana-bgp-l2-encaps {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps";
     prefix iana-bgp-l2-encaps;

     organization
       "IANA";
     contact
       "Internet Assigned Numbers Authority

        Postal: ICANN
             12025 Waterfront Drive, Suite 300
             Los Angeles, CA  90094-2536
             United States of America
        Tel:    +1 310 301 5800
        <mailto:iana@iana.org>"; 
     description
       "Этот модуль YANG содержит набор поддерживаемых IANA типов данных
        YANG, применяемых для ссылок на типы инкапсуляции BGP L2.

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

     revision 2022-09-20 {
       description
         "Первый выпуск.";
       reference
         "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
     }

     identity bgp-l2-encaps-type {
       description
         "Базовый тип инкапсуляции BGP L2.";
       reference
         "RFC 6624: Layer 2 Virtual Private Networks Using BGP for
                    Auto-Discovery and Signaling";
     }

     identity frame-relay {
       base bgp-l2-encaps-type;
       description
         "Frame Relay.";
       reference
         "RFC 4446: IANA Allocations for Pseudowire Edge
                    to Edge Emulation (PWE3)";
     }

     identity atm-aal5 {
       base bgp-l2-encaps-type;
       description
         "Транспорт ATM AAL5 SDU VCC.";
       reference
         "RFC 4446: IANA Allocations for Pseudowire Edge
                    to Edge Emulation (PWE3)";
     }

     identity atm-cell {
       base bgp-l2-encaps-type;
       description
         "Прозрачная транспортировка ячеек ATM.";
       reference
         "RFC 4816: Pseudowire Emulation Edge-to-Edge (PWE3)
                    Asynchronous Transfer Mode (ATM) Transparent
                    Cell Transport Service";
     }

     identity ethernet-tagged-mode {
       base bgp-l2-encaps-type;
       description
         "Режим Ethernet с тегами (VLAN).";
       reference
         "RFC 4448: Encapsulation Methods for Transport of Ethernet
                    over MPLS Networks";
     }

     identity ethernet-raw-mode {
       base bgp-l2-encaps-type;
       description
         "Режим Ethernet Raw.";
       reference
         "RFC 4448: Encapsulation Methods for Transport of Ethernet
                    over MPLS Networks";
     }

     identity hdlc {
       base bgp-l2-encaps-type;
       description
         "Cisco HDLC.";
       reference
         "RFC 4618: Encapsulation Methods for Transport of
                    PPP/High-Level Data Link Control (HDLC)
                    over MPLS Networks";
     }

     identity ppp {
       base bgp-l2-encaps-type;
       description
         "PPP.";
       reference
         "RFC 4618: Encapsulation Methods for Transport of
                    PPP/High-Level Data Link Control (HDLC)
                    over MPLS Networks";
     }

     identity circuit-emulation {
       base bgp-l2-encaps-type;
       description
         "Служба эмуляции каналов (устройств) SONET/SDH.";
       reference
         "RFC 4842: Synchronous Optical Network/Synchronous Digital
                    Hierarchy (SONET/SDH) Circuit Emulation over Packet
                    (CEP)";
     }

     identity atm-to-vcc {
       base bgp-l2-encaps-type;
       description
         "Транспорт ячеек VCC ATM n-to-one.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity atm-to-vpc {
       base bgp-l2-encaps-type;
       description
         "Транспорт ячеек VPC ATM n-to-one.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity layer-2-transport {
       base bgp-l2-encaps-type;
       description
         "Транспорт IP L2.";
       reference
         "RFC 3032: MPLS Label Stack Encoding";
     }

     identity fr-port-mode {
       base bgp-l2-encaps-type;
       description
         "режим порта Frame Relay.";
       reference
         "RFC 4619: Encapsulation Methods for Transport of Frame Relay
                    over Multiprotocol Label Switching (MPLS)
                    Networks";
     }

     identity e1 {
       base bgp-l2-encaps-type;
       description
         "E1 в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity t1 {
       base bgp-l2-encaps-type;
       description
         "T1 (DS1) в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity vpls {
       base bgp-l2-encaps-type;
       description
         "VPLS.";
       reference
         "RFC 4761: Virtual Private LAN Service (VPLS)
                    Using BGP for Auto-Discovery and Signaling";
     }

     identity t3 {
       base bgp-l2-encaps-type;
       description
         "T3 (DS3) в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity structure-aware {
       base bgp-l2-encaps-type;
       description
         "Базовый сервис Nx64 кбит/с с учётом структуры.";
       reference
         "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                    Circuit Emulation Service over Packet Switched
                    Network (CESoPSN)";
     }

     identity dlci {
       base bgp-l2-encaps-type;
       description
         "Frame Relay DLCI.";
       reference
         "RFC 4619: Encapsulation Methods for Transport of Frame Relay
                    over Multiprotocol Label Switching (MPLS)
                    Networks";
     }

     identity e3 {
       base bgp-l2-encaps-type;
       description
         "E3 в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity ds1 {
       base bgp-l2-encaps-type;
       description
         "Выровненное по октетам содержимое для каналов DS1 без учёта
          структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity cas {
       base bgp-l2-encaps-type;
       description
         "E1 Nx64 кбит/с с CAS и учётом структуры.";
       reference
         "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                    Circuit Emulation Service over Packet Switched
                    Network (CESoPSN)";
     }

     identity esf {
       base bgp-l2-encaps-type;
       description
         "DS1 (ESF) Nx64 кбит/с с CAS и учётом структуры.";
       reference
         "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                    Circuit Emulation Service over Packet Switched
                    Network (CESoPSN)";
     }

     identity sf {
       base bgp-l2-encaps-type;
       description
         "DS1 (SF) Nx64 кбит/с с CAS и учётом структуры.";
       reference
         "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                    Circuit Emulation Service over Packet Switched
                    Network (CESoPSN)";
     }
   }
   <CODE ENDS>

8.2. Модуль IANA для типов псевдопроводов

Исходная версия модуля YANG iana-pseudowire-types соответствует реестру MPLS Pseudowire Types Registry [IANA-PW-TYPES]. Модуль ссылается на [MFA], [RFC2507], [RFC2508], [RFC3032], [RFC3545], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4842], [RFC4863], [RFC4901], [RFC5086], [RFC5087], [RFC5143], [RFC5795], [RFC6307].

   <CODE BEGINS> file "iana-pseudowire-types@2022-09-20.yang"
   module iana-pseudowire-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types";
     prefix iana-pw-types;

     organization
       "IANA";
     contact
       "Internet Assigned Numbers Authority

        Postal: ICANN
             12025 Waterfront Drive, Suite 300
             Los Angeles, CA  90094-2536
             United States of America
        Tel:    +1 310 301 5800
        <mailto:iana@iana.org>"; 
     description
       "Этот модуль содержит набор поддерживаемых IANA типов данных YANG
        для указания типов псевдопроводов.

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

     revision 2022-09-20 {
       description
         "Первый выпуск.";
       reference
         "RFC RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
     }

     identity iana-pw-types {
       description
         "Базовый тип инкапсуляции псевдопровода L2.";
     }

     identity frame-relay {
       base iana-pw-types;
       description
         "Frame Relay DLCI (режим Martini).";
       reference
         "RFC 4619: Encapsulation Methods for Transport of Frame Relay
                    over Multiprotocol Label Switching (MPLS)
                    Networks";
     }

     identity atm-aal5 {
       base iana-pw-types;
       description
         "Транспорт ATM AAL5 SDU VCC.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity atm-cell {
       base iana-pw-types;
       description
         "Прозрачная доставка ячеек ATM.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity ethernet-tagged-mode {
       base iana-pw-types;
       description
         "Теговый режим Ethernet (VLAN).";
       reference
         "RFC 4448: Encapsulation Methods for Transport of Ethernet
                    over MPLS Networks";
     }

     identity ethernet {
       base iana-pw-types;
       description
         "Ethernet.";
       reference
         "RFC 4448: Encapsulation Methods for Transport of Ethernet
                    over MPLS Networks";
     }

     identity hdlc {
       base iana-pw-types;
       description
         "HDLC.";
       reference
         "RFC 4618: Encapsulation Methods for Transport of
                    PPP/High-Level Data Link Control (HDLC)
                    over MPLS Networks";
     }

     identity ppp {
       base iana-pw-types;
       description
         "PPP.";
       reference
         "RFC 4618: Encapsulation Methods for Transport of
                    PPP/High-Level Data Link Control (HDLC)
                    over MPLS Networks";
     }

     identity circuit-emulation-mpls {
       base iana-pw-types;
       description
         "Инкапсуляция SONET/SDH CES через MPLS.";
       reference
         "RFC 5143: Synchronous Optical Network/Synchronous Digital
                    Hierarchy (SONET/SDH) Circuit Emulation Service over
                    MPLS (CEM) Encapsulation";
     }

     identity atm-to-vcc {
       base iana-pw-types;
       description
         "Транспорт ячеек VCC ATM n-to-one.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity atm-to-vpc {
       base iana-pw-types;
       description
         "Транспорт ячеек VPC ATM n-to-one.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity layer-2-transport {
       base iana-pw-types;
       description
         "Транспорт IP L2.";
       reference
         "RFC 3032: MPLS Label Stack Encoding";
     }

     identity atm-one-to-one-vcc {
       base iana-pw-types;
       description
         "Режим ячеек VCC ATM one-to-one.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity atm-one-to-one-vpc {
       base iana-pw-types;
       description
         "Режим ячеек VPC ATM one-to-one.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity atm-aal5-vcc {
       base iana-pw-types;
       description
         "Транспорт ATM AAL5 PDU VCC.";
       reference
         "RFC 4717: Encapsulation Methods for Transport of
                    Asynchronous Transfer Mode (ATM) over MPLS
                    Networks";
     }

     identity fr-port-mode {
       base iana-pw-types;
       description
         "Режим порта Frame-Relay.";
       reference
         "RFC 4619: Encapsulation Methods for Transport of Frame Relay
                    over Multiprotocol Label Switching (MPLS)
                    Networks";
     }

     identity circuit-emulation-packet {
       base iana-pw-types;
       description
         "Режим эмуляции каналов SONET/SDH в пакетной сети.";
       reference
         "RFC 4842: Synchronous Optical Network/Synchronous Digital
                    Hierarchy (SONET/SDH) Circuit Emulation over Packet
                    (CEP)";
     }

     identity e1 {
       base iana-pw-types;
       description
         "E1 в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity t1 {
       base iana-pw-types;
       description
         "T1 (DS1) в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity e3 {
       base iana-pw-types;
       description
         "E3 в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity t3 {
       base iana-pw-types;
       description
         "T3 (DS3) в пакетах без учёта структуры.";
       reference
         "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
                    over Packet (SAToP)";
     }

     identity ces-over-psn {
       base iana-pw-types;
       description
         "Базовый режим CESoPSN.";
       reference
         "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                    Circuit Emulation Service over Packet Switched
                    Network (CESoPSN)";
     }

     identity tdm-over-ip-aal1 {
       base iana-pw-types;
       description
         "Режим TDMoIP AAL1.";
       reference
         "RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
     }

     identity ces-over-psn-cas {
       base iana-pw-types;
       description
         "CESoPSN TDM с CAS.";
       reference
         "RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
                    Circuit Emulation Service over Packet Switched
                    Network (CESoPSN)";
     }

     identity tdm-over-ip-aal2 {
       base iana-pw-types;
       description
         "Режим TDMoIP AAL2.";
       reference
         "RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
     }

     identity dlci {
       base iana-pw-types;
       description
         "Frame Relay DLCI.";
       reference
         "RFC 4619: Encapsulation Methods for Transport of Frame Relay
                    over Multiprotocol Label Switching (MPLS)
                    Networks";
     }

     identity rohc {
       base iana-pw-types;
       description
         "Транспорт ROHC в пакетах со сжатием заголовков.";
       reference
         "RFC 5795: The RObust Header Compression (ROHC) Framework
          RFC 4901: Protocol Extensions for Header Compression over
                    MPLS";
     }

     identity ecrtp {
       base iana-pw-types;
       description
         "Транспорт ECRTP в пакетах со сжатием заголовков.";
       reference
         "RFC 3545: Enhanced Compressed RTP (CRTP) for Links with High
                    Delay, Packet Loss and Reordering
          RFC 4901: Protocol Extensions for Header Compression over
                    MPLS";
     }

     identity iphc {
       base iana-pw-types;
       description
         "Транспорт IPHC в пакетах со сжатием заголовков.";
       reference
         "RFC 2507: IP Header Compression
          RFC 4901: Protocol Extensions for Header Compression over
                    MPLS";
     }

     identity crtp {
       base iana-pw-types;
       description
         "Транспорт cRTP в пакетах со сжатием заголовков.";
       reference
         "RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial
                    Links
          RFC 4901: Protocol Extensions for Header Compression over
                    MPLS";
     }

     identity atm-vp-virtual-trunk {
       base iana-pw-types;
       description
         "Виртуальный транк ATM VP.";
       reference
         "MFA Forum: The Use of Virtual Trunks for ATM/MPLS
                     Control Plane Interworking Specification";
     }

     identity fc-port-mode {
       base iana-pw-types;
       description
         "Режим порта FC.";
       reference
         "RFC 6307: Encapsulation Methods for Transport of
                    Fibre Channel Traffic over MPLS Networks";
     }

     identity wildcard {
       base iana-pw-types;
       description
         "Шаблон.";
       reference
         "RFC 4863: Wildcard Pseudowire Type";
     }
   }
   <CODE ENDS>

8.3. Сегменты Ethernet

Модуль YANG ietf-ethernet-segment использует типы, определённые в [RFC6991].

   <CODE BEGINS> file "ietf-ethernet-segment@2022-09-20.yang"
   module ietf-ethernet-segment {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ethernet-segment";
     prefix l2vpn-es;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types (see Section 3)";
     }

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

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

        Editor:    Samier Barguil
                  <mailto:samier.barguilgiraldo.ext@telefonica.com> 

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

     description
       "Этот модуль YANG определяет модель для сегментов Ethernet.

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

     revision 2022-09-20 {
       description
         "Исходная версия.";
       reference
         "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
     }
     /* Определения типов */

     typedef es-ref {
       type leafref {
         path "/l2vpn-es:ethernet-segments/l2vpn-es:ethernet-segment"
            + "/l2vpn-es:name";
       }
       description
         "Defines a type for referencing an Ethernet segment in
          other modules.";
     }

     /* Идентификаторы (отождествления) */

     identity esi-type {
       description
         "T - тип идентификатора сегмента Ethernet (Ethernet Segment 
          Identifier или ESI) — 1-октетное поле (старший октет), 
          задающее формат оставшихся 9 октетов (значение ESI).";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
     }

     identity esi-type-0-operator {
       base esi-type;
       description
         "Произвольное 9-октетное значение ESI, поддерживаемое и
          настраиваемое оператором.";
     }

     identity esi-type-1-lacp {
       base esi-type;
       description
         "При использовании протокола объединения каналов IEEE 802.1AX 
          LACP между устройствами PE и CE этот тип ESI указывает 
          автоматически созданное значение ESI, определённое из LACP.";
       reference
         "IEEE Std 802.1AX: Link Aggregation";
     }

     identity esi-type-2-bridge {
       base esi-type;
       description
         "Значение ESI создаётся автоматически по протоколу моста L2.";
     }

     identity esi-type-3-mac {
       base esi-type;
       description
         "Значение ESI на основе MAC, которое может создаваться
          автоматически или настраиваться оператором.";
     }

     identity esi-type-4-router-id {
       base esi-type;
       description
         "Значение ESI на основе Router ID, которое может создаваться
          автоматически или настраиваться оператором.";
     }

     identity esi-type-5-asn {
       base esi-type;
       description
         "Значение ESI на основе номера AS, которое может создаваться
          автоматически или настраиваться оператором.";
     }

     identity df-election-methods {
       description
         "Базовый идентификатор метода выбора DF.";
     }

     identity default-7432 {
       base df-election-methods;
       description
         "Принятый по умолчанию метод выбора DF.

          Принятая по умолчанию процедура выбора DF с детализацией
          <ES,VLAN> для службы на основе VLAN или <ES, связка VLAN> для
          привязки к VLAN называется service carving.";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.5";
     }

     identity highest-random-weight {
       base df-election-methods;
       description
         "Метод выбора по наибольшему случайному весу (HRW).";
       reference
         "RFC 8584: Framework for Ethernet VPN Designated
                    Forwarder Election Extensibility, Section 3";
     }

     identity preference {
       base df-election-methods;
       description
         "Выбор на основе предпочтения. С PE связываются предпочтение
          при выборе DF в сегменте Ethernet (ES). Конкретный алгоритм
          выбора (например, наименьшего или наибольшего значния)
          указывается сигнализацией в плоскости управления.";
     }

     identity es-redundancy-mode {
       description
         "Базовое отождествление для режимов резервирования ES.";
     }

     identity single-active {
       base es-redundancy-mode;
       description
         "Режим Single-Active (активен один) для данного ES.";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1";
     }

     identity all-active {
       base es-redundancy-mode;
       description
         "Режим All-Active (активны все) для данного ES.";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.2";
     }

     /* Основной контейнер сегмента Ethernet */

     container ethernet-segments {
       description
         "Контейнер верхнего уровня для ESI.";
       list ethernet-segment {
         key "name";
         description
           "Список ESI.";
         leaf name {
           type string;
           description
             "Имя сегмента Ethernet (ES) для однозначного указания ES.";
         }
         leaf esi-type {
           type identityref {
             base esi-type;
           }
           default "esi-type-0-operator";
           description
             "T - тип идентификатора сегмента Ethernet (Ethernet Segment 
              Identifier или ESI) — 1-октетное поле (старший октет), 
              задающее формат оставшихся 9 октетов (значение ESI).";
           reference
             "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
         }
         choice esi-choice {
           description
             "Выбор из нескольких типов сегмента Ethernet.
              ESI типа 0: задаётся оператором напрямую.
              ESI типа 1: должен применяться автоматический режим.
              ESI типа 2: должен применяться автоматический режим.
              ESI типа 3: автоматический режим или прямое назначение.
              ESI типа 4: автоматический режим или прямое назначение.
              ESI типа 5: автоматический режим или прямое назначение.;
           case directly-assigned {
             description
               "Явное задание значения ESI.";
             leaf ethernet-segment-identifier {
               type yang:hex-string {
                 length "29";
               }
               description
                 "10-октетное значение ESI.";
             }
           }
           case auto-assigned {
             description
               "ESI назначается автоматически.";
             container esi-auto {
               description
                 "ESI назначается автоматически .";
               choice auto-mode {
                 description
                   "Режим автоматического назначения ESI с указанием или
                    без указания пула для выбора значения ESI. Сервер
                    автоматически выбирает значение auto-assigned-ESI и
                    применять его при работе.";
                 case from-pool {
                   leaf esi-pool-name {
                     type string;
                     description
                       "Автоматический выбор из пула ESI-pool-name.";
                   }
                 }
                 case full-auto {
                   leaf auto {
                     type empty;
                     description
                       "Полностью автоматическое назначение ESI.";
                   }
                 }
               }
               leaf auto-ethernet-segment-identifier {
                 type yang:hex-string {
                   length "29";
                 }
                 config false;
                 description
                   "Значение автоматически заданного ESI.";
               }
             }
           }
         }
         leaf esi-redundancy-mode {
           type identityref {
             base es-redundancy-mode;
           }
           description
             "Режим резервирования ES.";
           reference
             "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1";
         }
         container df-election {
           description
             "Контейнер верхнего уровня для свойств метода выбора DF.";
           leaf df-election-method {
             type identityref {
               base df-election-methods;
             }
             default "default-7432";
             description
               "задаёт метод выбора DF.";
             reference
               "RFC 8584: Framework for Ethernet VPN Designated
                          Forwarder Election Extensibility";
           }
           leaf revertive {
             when "derived-from-or-self(../df-election-method, "
                + "'preference')" {
               description
                 "Найденное значение применимо лишь для 
                  предпочтительного метода.";
             }
             type boolean;
             default "true";
             description
               "По умолчанию процедура выбора DF запускается при отказах
                PE в соответствии с заданными предпочтениями. Этот режим
                называется извлечением (revertive). Он может не подойти
                для некоторых случаев, например, когда оператор хочет 
                поддерживать новый DF даже при восстановлении прежнего.
                В этом случае режим называется non-revertive и его можно 
                задать, установив для листа revertive значение false.";
             reference
               "RFC 8584: Framework for Ethernet VPN Designated
                          Forwarder Election Extensibility,
                          Section 1.3.2";
           }
           leaf election-wait-time {
             type uint32;
             units "seconds";
             default "3";
             description
               "Таймер ожидания DF.";
             reference
               "RFC 8584: Framework for Ethernet VPN Designated
                          Forwarder Election Extensibility";
           }
         }
         leaf split-horizon-filtering {
           type boolean;
           description
             "Управляет фильтром расщепления горизонта (split-horizon). 
              Включается значением true.

              Для фильтрации split-horizon каждый широковещательный,
              неопознанный индивидуальный или групповой (BUM) пакет,
              исходящий не от DF PE, инкапсулируется с меткой MPLS,
              указывающей исходный сегмент ES.";
           reference
             "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3";
         }
         container pbb {
           description
             "Параметры моста магистрали провайдера (PBB).";
           reference
             "IEEE 802.1ah: Provider Backbone Bridges";
           leaf backbone-src-mac {
             type yang:mac-address;
             description
               "PE, подключённые к одному CE, должны применять общий
                адрес магистрали провайдера (B-MAC) в режиме All-Active.";
             reference
               "RFC 7623: Provider Backbone Bridging Combined with
                          Ethernet VPN (PBB-EVPN), Section 6.2.1.1";
           }
         }
         list member {
           key "ne-id interface-id";
           description
             "Список членов ES.";
           leaf ne-id {
             type string;
             description
               "Идентификатор элемента сети с настроенным ES внутри
                сети сервис-провайдера.";
           }
           leaf interface-id {
             type string;
             description
               "Идентификатор интерфейса узла.";
           }
         }
       }
     }
   }
   <CODE ENDS>

8.4. L2NM

Модуль YANG ietf-l2vpn-ntw использует типы, определённые в [RFC6991], [RFC9181], [RFC8294], [IEEE802.1Qcp].

   <CODE BEGINS> file "ietf-l2vpn-ntw@2022-09-20.yang"
   module ietf-l2vpn-ntw {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw";
     prefix l2vpn-ntw;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types, Section 4";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types, Section 3";
     }
     import ietf-vpn-common {
       prefix vpn-common;
       reference
         "RFC 9181: A Common YANG for Data Model for Layer 2
                    and Layer 3 VPNs";
     }
     import iana-bgp-l2-encaps {
       prefix iana-bgp-l2-encaps;
       reference
         "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
     }
     import iana-pseudowire-types {
       prefix iana-pw-types;
       reference
         "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
     }
     import ietf-ethernet-segment {
       prefix l2vpn-es;
       reference
         "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
     }
     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }
     import ieee802-dot1q-types {
       prefix dot1q-types;
       reference
         "IEEE Std 802.1Qcp: Bridges and Bridged Networks--
                             Amendment 30: YANG Data Model";
     }

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

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

        Editor:    Samier Barguil
                  <mailto:samier.barguilgiraldo.ext@telefonica.com> 

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

     description
       "Этот модуль YANG определяет модель сети для услуг L2 VPN.

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

     revision 2022-09-20 {
       description
         "Исходная версия.";
       reference
         "RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
     }

     /* Функции (свойства) */

     feature oam-3ah {
       description
         "Указывает поддержку OAM 802.3ah.";
       reference
         "IEEE Std 802.3ah: Media Access Control Parameters, Physical
                            Layers, and  Management Parameters for
                            Subscriber Access Networks";
     }

     /* Идентификаторы (отождествления) */

     identity evpn-service-interface-type {
       description
         "Базовый идентификатор типа интерфейса службы EVPN.";
     }

     identity vlan-based-service-interface {
       base evpn-service-interface-type;
       description
         "Интерфейс службы на основе VLAN.";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1";
     }

     identity vlan-bundle-service-interface {
       base evpn-service-interface-type;
       description
         "Интерфейс службы с группой VLAN (bundle).";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2";
     }

     identity vlan-aware-bundle-service-interface {
       base evpn-service-interface-type;
       description
         "Интерфейс групповой (bundle) службы с поддержкой VLAN.";
       reference
         "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3";
     }

     identity mapping-type {
       base vpn-common:multicast-gp-address-mapping;
       description
         "Идентификатор типа отображения multicast-группы.";
     }

     identity loop-prevention-type {
       description
         "Идентификатор предотвращения петель.";
     }

     identity shut {
       base loop-prevention-type;
       description
         "Тип защиты Shut.";
     }

     identity trap {
       base loop-prevention-type;
       description
         "Тип защиты Trap.";
     }

     identity color-type {
       description
         "Указание цветовых типов. Тип связывается с кадром службы
          для указания соответствия профилю QoS.";
     }

     identity green {
       base color-type;
       description
         "Зеленый тип - кадры, соответствующие согласованной (committed)
          в профиле пропускной способности скорости.";
     }

     identity yellow {
       base color-type;
       description
         "Желтый тип - кадры, выходящие за предел согласованной 
          в профиле пропускной способности скорости, но не превышающие
          избыточную (excess) скорость.";
     }

     identity red {
       base color-type;
       description
         "Красный тип - кадры, выходящие за пределы согласованной и
          избыточной скорости в профиле пропускной способности.";
     }

     identity t-ldp-pw-type {
       description
         "Тип псевдопровода (PW) T-LDP.";
     }

     identity vpws-type {
       base t-ldp-pw-type;
       description
         "t-ldp-pw-type для виртуального частного провода (VPWS).";
       reference
         "RFC 4664: Framework for Layer 2 Virtual Private Networks
                   (L2VPNs), Section 3.3";
     }

     identity vpls-type {
       base t-ldp-pw-type;
       description
         "t-ldp-pw-type для виртуальной частной ЛВС (VPLS).";
       reference
         "RFC 4762: Virtual Private LAN Service (VPLS) Using Label
                    Distribution Protocol (LDP) Signaling, Section 6.1";
     }
     identity hvpls {
       base t-ldp-pw-type;
       description
         "t-ldp-pw-type для иерахических частных виртуальных ЛВС 
          (H-VPLS).";
       reference
         "RFC 4762: Virtual Private LAN Service (VPLS) Using Label
                    Distribution Protocol (LDP) Signaling, Section 10";
     }

     identity lacp-mode {
       description
         "Режим LACP.";
     }

     identity lacp-active {
       base lacp-mode;
       description
         "Активный режим LACP, где автоматическое согласование скорости
          вызывается созданием соединения Ethernet с другой стороной.";
     }

     identity lacp-passive {
       base lacp-mode;
       description
         "Пассивный режим LACP, где конечная точка не инициирует 
          согласование, а лишь отвечает на пакеты LACP от другой стороны
          (например, полудуплексный или полнодуплексный режим).";
     }

     identity pm-type {
       description
         "Тип мониторинга производительности.";
     }

     identity loss {
       base pm-type;
       description
         "Мониторинг производительности путём измерения потерь.";
     }

     identity delay {
       base pm-type;
       description
         "Мониторинг производительности путём измерения задержки.";
     }

     identity mac-learning-mode {
       description
         "Режим обучения MAC.";
     }

     identity data-plane {
       base mac-learning-mode;
       description
         "MAC-адреса пользователей изучаются по широковещанию ARP.";
     }

     identity control-plane {
       base mac-learning-mode;
       description
         " MAC-адреса пользователей анонсируются через EVPN-BGP.";
     }

     identity mac-action {
       description
         "Базовое отождествление действия MAC.";
     }

     identity drop {
       base mac-action;
       description
         "Действие MAC по отбрасыванию пакета.";
     }

     identity flood {
       base mac-action;
       description
         "Действие MAC по лавинной рассылке пакета.";
     }

     identity warning {
       base mac-action;
       description
         "Действие MAC по по записи предупреждения в журнал.";
     }
     identity precedence-type {
       description
         "Тип резервирования. Служба может быть создана с основной
          или вторичной сигнализацией.";
     }

     identity primary {
       base precedence-type;
       description
         "Указывает основной доступ в VPN.";
     }

     identity secondary {
       base precedence-type;
       description
         "Указывает вторичный (резервный) доступ в VPN .";
     }

     identity ldp-pw-type {
       description
         "Указывает разрешенный тип псевдопроводов (PW) на базе LDP.";
       reference
         "RFC 4762: Virtual Private LAN Service (VPLS) Using
                    Label Distribution Protocol (LDP)
                    Signaling, Section 6.1.1";
     }

     identity ethernet {
       base ldp-pw-type;
       description
         "Тип PW Ethernet.";
     }

     identity ethernet-tagged {
       base ldp-pw-type;
       description
         "Тип PW Ethernet с тегами.";
     }

     /* Определения типов */

     typedef ccm-priority-type {
       type uint8 {
         range "0..7";
       }
       description
         "3-битовое значение приоритета в теге VLAN при его наличии в
          переданном кадре. Приоритет пропорционален значению.";
     }

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

     grouping cfm-802 {
       description
         "Группировка для атрибутов 802.1ag CFM.";
       reference
         "IEEE Std 802.1ag: Virtual Bridged Local Area Networks
                            Amendment 5: Connectivity Fault Management";
       leaf maid {
         type string;
         description
           "Идентификатор ассоциации поддержки (MAID).";
       }
       leaf mep-id {
         type uint32;
         description
           "Идентификатор конечной точки локальной группы поддержки (MEP).";
       }
       leaf mep-level {
         type uint32;
         description
           "Уровень MEP.";
       }
       leaf mep-up-down {
         type enumeration {
           enum up {
             description
               "MEP активна.";
           }
           enum down {
             description
               "MEP отключена.";
           }
         }
         default "up";
         description
           "MEP активна/отключена.";
       }
       leaf remote-mep-id {
         type uint32;
         description
           "Идентификатор удалённой MEP.";
       }
       leaf cos-for-cfm-pdus {
         type uint32;
         description
           "Класс обслуживания для CFM PDU.";
       }
       leaf ccm-interval {
         type uint32;
         units "milliseconds";
         default "10000";
         description
           "Интервал сообщений проверки непрерывности (CCM).";
       }
       leaf ccm-holdtime {
         type uint32;
         units "milliseconds";
         default "35000";
         description
           "Время удержания CCM.";
       }
       leaf ccm-p-bits-pri {
         type ccm-priority-type;
         description
           "Параметр приоритета для CCM, передаваемых MEP.";
       }
     }

     grouping y-1731 {
       description
         "Группировка для Y-1731";
       reference
         "ITU-T G.8013/Y.1731:  Operations, administration and
                                maintenance (OAM) functions and
                                mechanisms for Ethernet-based
                                networks";
       list y-1731 {
         key "maid";
         description
           "Список настроенных экземпляров Y-1731.";
         leaf maid {
           type string;
           description
             "MAID.";
         }
         leaf mep-id {
           type uint32;
           description
             "Идентификатор локальной MEP.";
         }
         leaf pm-type {
           type identityref {
             base pm-type;
           }
           default "delay";
           description
             "Типы мониторинга производительности.";
         }
         leaf remote-mep-id {
           type uint32;
           description
             "Идентификатор удаленной MEP.";
         }
         leaf message-period {
           type uint32;
           units "milliseconds";
           default "10000";
           description
             "Интервал между сообщениями OAM.";
         }
         leaf measurement-interval {
           type uint32;
           units "seconds";
           description
             "Интервал измерений для статистики.";
         }
         leaf cos {
           type uint32;
           description
             "Класс обслуживания.";
         }
         leaf loss-measurement {
           type boolean;
           default "false";
           description
             "Включено (true) или отключено (false) измерение потерь.";
         }
         leaf synthetic-loss-measurement {
           type boolean;
           default "false";
           description
             "Включено (true) или отключено (false) синтетическое 
              измерение потерь.";
         }
         container delay-measurement {
           description
             "Контейнер для измерения задержки.";
           leaf enable-dm {
             type boolean;
             default "false";
             description
              "Включено (true) или отключено (false) измерение задержки.";
           }
           leaf two-way {
             type boolean;
             default "false";
             description
               "Измерение двухсторонней (true) или односторонней (false)
                задержки.";
           }
         }
         leaf frame-size {
           type uint32;
           units "bytes";
           description
             "Указывает размер кадров.";
         }
         leaf session-type {
           type enumeration {
             enum proactive {
               description
                 "Упреждающий (проактивный) режим.";
             }
             enum on-demand {
               description
                 "Режим по запросу (On-demand).";
             }
           }
           default "on-demand";
           description
             "Указывает тип сессии.";
         }
       }
     }

     grouping parameters-profile {
       description
         "Контейнер для параметров службы.";
       leaf local-autonomous-system {
         type inet:as-number;
         description
           "Локальный номер AS (ASN).";
       }
       leaf svc-mtu {
         type uint32;
         units "bytes";
         description
           "L2 MTU для службы. Называется также максимальным 
            передаваемым блоком и максимальным размером кадра.";
       }
       leaf ce-vlan-preservation {
         type boolean;
         description
           "Сохраняет CE VLAN ID со входа на выход, т. е. тег CE VLAN в 
            выходном кадре идентичен тегу в вызвавшем его входном кадре.
            При включённой на сайте привязке all-to-one это применяется
            ка всем входным кадрам службы. При отключённой привязке 
            all-to-one представление применяется к входным кадрам службы
            с тегами CE VLAN ID от 1 до 4094.";
       }
       leaf ce-vlan-cos-preservation {
         type boolean;
         description
           "Представление CE VLAN CoS. Биты кода приоритета (PCP) в теге
            CE VLAN выходного кадра идентичны битам входного кадра,
            вызвавшего этот выходной кадр службы.";
       }
       leaf control-word-negotiation {
         type boolean;
         description
           "Включает (true) или отключает (false) слово управления.";
         reference
           "RFC 8077: Pseudowire Setup and Maintenance
                      Using the Label Distribution Protocol (LDP),
                      Section 7";
       }
       container mac-policies {
         description
           "Контейнер правил MAC.";
         container mac-addr-limit {
           description
             "Контейнер настройки предельного числа MAC-адресов.";
           leaf limit-number {
             type uint16;
             description
               "Максимальное число MAC-адресов, изучаемых от клиента, 
                для одного экземпляра службы. По умолчанию это 2, когда
                эта группировка применяется на уровне службы.";
           }
           leaf time-interval {
             type uint32;
             units "milliseconds";
             description
               "Время устаревания MAC-адреса. По умолчанию это 300, 
                когда эта группировка применяется на уровне службы.";
           }
           leaf action {
             type identityref {
               base mac-action;
             }
             description
               "Действие при достижении верхнего предела — отбрасывание,
                лавинная рассылка, запись предупреждения в журнал (без
                отбрасывания пакета). По умолчанию применяется warning,
                когда эта группировка применяется на уровне службы.";
           }
         }
         container mac-loop-prevention {
           description
             "Контейнер для предотвращения петель MAC.";
           leaf window {
             type uint32;
             units "seconds";
             description
               "Интервал времени, в течение которого события переноса MAC
                обнаруживаются и проверяются. По умолчанию установлено
                180, когда группировка применяется на уровне службы.";
           }
           leaf frequency {
             type uint32;
             description
               "Число фактов обнаружения дубликатов MAC с интервале 
                времени window с добавлением MAC-адреса в список 
                дубликатов. По умолчанию установлено значение 5,
                когда группировка применяется на уровне службы.";
           }
           leaf retry-timer {
             type uint32;
             units "seconds";
             description
               "Таймер повтора, по истечении которого MAC-адрес
                исключается из MAC-VRF.";
           }
           leaf protection-type {
             type identityref {
               base loop-prevention-type;
             }
             description
               "Тип защиты. По умолчанию применяется trap,
                когда группировка применяется на уровне службы.";
           }
         }
       }
       container multicast {
         if-feature "vpn-common:multicast";
         description
           "Контейнер групповой передачи.";
         leaf enabled {
           type boolean;
           default "false";
           description
             "Разрешает групповую передачу.";
         }
         container customer-tree-flavors {
           description
             "Тип деревьев, применяемый клиентом.";
           leaf-list tree-flavor {
             type identityref {
               base vpn-common:multicast-tree-type;
             }
             description
               "Тип multicast-дерева для использования.";
           }
         }
       }
     }

     grouping bandwidth-parameters {
       description
         "Группировка для параметров пропускной способности.";
       leaf cir {
         type uint64;
         units "bps";
         description
           "Согласованная скорость (Committed Information Rate или CIR).
            Максимальное число битов, которые порт может принять или 
            передать через интерфейс за 1 секунду.";
       }
       leaf cbs {
         type uint64;
         units "bytes";
         description
           "Согласованный размер пиков (Committed Burst Size или CBS) 
            для контроля пиков трафика. Трафик меньше заданного CIR
            накапливает кридит, пока тот не достигнет заданного CBS.";
       }
       leaf eir {
         type uint64;
         units "bps";
         description
           "Избыточная скорость (Excess Information Rate или EIR), т. е.
            доставка даров, выходящих за пределы соглашения об уровне
            обслуживания (Service Level Agreement или SLA). Трафик может
            ограничиваться значением EIR.";
       }
       leaf ebs {
         type uint64;
         units "bytes";
         description
           "Избыточный размер пиков (Excess Burst Size или EBS). 
            Пропускная способность для пиков трафика выше EBS может
            быть ограничена значением, накопленным в периоды, когда
            трафик, выделенный по правилу EIR не используется.";
       }
       leaf pir {
         type uint64;
         units "bps";
         description
           "Пиковая скорость (Peak Information Rate или PIR), т. е. 
            разрешена максимальная скорость доставки кадров. Это
            значение не превышает CIR + EIR.";
       }
       leaf pbs {
         type uint64;
         units "bytes";
         description
           "Максимальный размер пиков (Peak Burst Size или PBS).";
       }
     }

     /* Основной контейнер L2NM */

     container l2vpn-ntw {
       description
         "Контейнер для L2NM.";
       container vpn-profiles {
         description
           "Контейнер для профилей VPN.";
         uses vpn-common:vpn-profile-cfg;
       }
       container vpn-services {
         description
           "Контейнер для служб L2VPN.";
         list vpn-service {
           key "vpn-id";
           description
             "Контейнер для службы VPN.";
           uses vpn-common:vpn-description;
           leaf parent-service-id {
             type vpn-common:vpn-id;
             description
               "Указатель на родительскую службу, вызвавшую L2NM.";
           }
           leaf vpn-type {
             type identityref {
               base vpn-common:service-type;
             }
             must "not(derived-from-or-self(current(), "
                + "'vpn-common:l3vpn'))" {
               error-message "L3VPN is only applicable in L3NM.";
             }
             description
               "Тип сервиса.";
           }
           leaf vpn-service-topology {
             type identityref {
               base vpn-common:vpn-topology;
             }
             description
               "Определяет топологию сервиса (any-to-any, hub-spoke).";
           }
           leaf bgp-ad-enabled {
             type boolean;
             description
               "Указывает, включено ли автообнаружение BGP.";
           }
           leaf signaling-type {
             type identityref {
               base vpn-common:vpn-signaling-type;
             }
             description
               "Тип сигнализации VPN.";
           }
           container global-parameters-profiles {
             description
               "Контейнер для списка профилей глобальных параметров.";
             list global-parameters-profile {
               key "profile-id";
               description
                 "Список профилей глобальных параметров.";
               leaf profile-id {
                 type string;
                 description
                   "Идентификатор профиля глобальных параметров.";
               }
               uses vpn-common:route-distinguisher;
               uses vpn-common:vpn-route-targets;
               uses parameters-profile;
             }
           }
           container underlay-transport {
             description
               "Контейнер для базового транспорта.";
             uses vpn-common:underlay-transport;
           }
           uses vpn-common:service-status;
           container vpn-nodes {
             description
               "Набор узлов VPN, вовлечённых в L2NM.";
             list vpn-node {
               key "vpn-node-id";
               description
                 "Контейнер для узлов VPN.";
               leaf vpn-node-id {
                 type vpn-common:vpn-id;
                 description
                   "Идентификатор узла VPN.";
               }
               leaf description {
                 type string;
                 description
                   "Текстовое описание узла VPN.";
               }
               leaf ne-id {
                 type string;
                 description
                   "Идентификатор элемента сети, где развернут узел VPN.
                    Однозначно указывает элемент сети в административном
                    домене.";
               }
               leaf role {
                 type identityref {
                   base vpn-common:role;
                 }
                 default "vpn-common:any-to-any-role";
                 description
                   "Роль узла в VPN.";
               }
               leaf router-id {
                 type rt-types:router-id;
                 description
                   "32-битовое значение с разделением точками, служащее
                    для однозначного указания узла в AS.";
               }
               container active-global-parameters-profiles {
                 description
                   "Контейнер для списка профилей глобальных параметров.";
                 list global-parameters-profile {
                   key "profile-id";
                   description
                     "Список активных профилей глобальных параметров.";
                   leaf profile-id {
                     type leafref {
                       path "../../../../../global-parameters-profiles"
                          + "/global-parameters-profile/profile-id";
                     }
                     description
                       "Глобальный профиль, заданный на уровне службы.";
                   }
                   uses parameters-profile;
                 }
               }
               uses vpn-common:service-status;
               container bgp-auto-discovery {
                 when "../../../bgp-ad-enabled = 'true'" {
                   description
                     "Применяется лишь при включённом автообнаружении
                      BGP.";
                 }
                 description
                   "Для автоматического обнаружения применяется BGP.";
                 choice bgp-type {
                   description
                     "Выбор для типа BGP.";
                   case l2vpn-bgp {
                     description
                       "Контейнер для BGP L2VPN.";
                     leaf vpn-id {
                       type vpn-common:vpn-id;
                       description
                         "Идентификатор VPN, служащий для унификации
                          компонентов данной VPN при автообнаружении.";
                       reference
                         "RFC 6624: Layer 2 Virtual Private Networks
                                    Using BGP for Auto-Discovery and
                                    Signaling";
                     }
                   }
                   case evpn-bgp {
                     description
                       "Вариант EVPN.";
                     leaf evpn-type {
                       type leafref {
                         path "../../../../vpn-type";
                       }
                       description
                         "Тип EVPN.";
                     }
                     leaf auto-rt-enable {
                       type boolean;
                       default "false";
                       description
                         "Управляет автоматическим созданием RT 
                          на основе ASN и Ethernet Tag ID.";
                       reference
                         "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                    Section 7.10.1";
                     }
                     leaf auto-route-target {
                       when "../auto-rt-enable = 'true'" {
                         description
                           "Используется лишь при включённом auto-RD.";
                       }
                       type rt-types:route-target;
                       config false;
                       description
                         "Автоматически заданное значение RT.";
                     }
                   }
                 }
                 uses vpn-common:route-distinguisher;
                 uses vpn-common:vpn-route-targets;
               }
               container signaling-option {
                 description
                   "Контейнер для сигнализации L2VPN.";
                 leaf advertise-mtu {
                   type boolean;
                   description
                     "Управляет анонсированием MTU.";
                   reference
                     "RFC 4667: Layer 2 Virtual Private Network (L2VPN)
                                Extensions for Layer 2 Tunneling
                                Protocol (L2TP), Section 4.3";
                 }
                 leaf mtu-allow-mismatch {
                   type boolean;
                   description
                     "Значение true разрешает несоответствие MTU.";
                   reference
                     "RFC 4667: Layer 2 Virtual Private Network (L2VPN)
                                Extensions for Layer 2 Tunneling
                                Protocol (L2TP), Section 4.3";
                 }
                 leaf signaling-type {
                   type leafref {
                     path "../../../../signaling-type";
                   }
                   description
                     "Тип сигнализации VPN.";
                 }
                 choice signaling-option {
                   description
                     "Выбор для опции сигнализации.";
                   case bgp {
                     description
                       "BGP применяется как сигнальный протокол.";
                     choice bgp-type {
                       description
                         "Выбор для типа BGP.";
                       case l2vpn-bgp {
                         description
                           "Контейнер для BGP L2VPN.";
                         leaf ce-range {
                           type uint16;
                           description
                             "Задаёт число удалённых CE, с которыми это
                              устройство CE может взаимодействовать в 
                              контексте VPN.";
                           reference
                             "RFC 6624: Layer 2 Virtual Private Networks
                                        Using BGP for Auto-Discovery and
                                        Signaling";
                         }
                         leaf pw-encapsulation-type {
                           type identityref {
                             base iana-bgp-l2-encaps:bgp-l2-encaps-type;
                           }
                           description
                             "Тип инкапсуляции PW.";
                         }
                         container vpls-instance {
                           when "derived-from-or-self(../../../../"
                              + "vpn-type, 'vpn-common:vpls')" {
                             description
                               "Применимо лишь для VPLS.";
                           }
                           description
                             "Экземпляр VPLS.";
                           leaf vpls-edge-id {
                             type uint16;
                             description
                               "Идентификатор VPLS Edge (VE ID), применяемый
                                при настройке того же VE ID для PE.";
                             reference
                               "RFC 4761: Virtual Private LAN Service
                                          (VPLS) Using BGP for Auto-
                                          Discovery and Signaling,
                                          Section 3.5";
                           }
                           leaf vpls-edge-id-range {
                             type uint16;
                             description
                               "Диапазон VE ID в службе VPLS, для контроля
                                размера блока меток, анонсируемого в 
                                контексте экземпляра VPLS.";
                             reference
                               "RFC 4761: Virtual Private LAN Service
                                          (VPLS) Using BGP for Auto-
                                          Discovery and Signaling";
                           }
                         }
                       }
                       case evpn-bgp {
                         description
                           "Применяется для EVPN.";
                         leaf evpn-type {
                           type leafref {
                             path "../../bgp-auto-discovery/evpn-type";
                           }
                           description
                             "Тип EVPN.";
                         }
                         leaf service-interface-type {
                           type identityref {
                             base evpn-service-interface-type;
                           }
                           description
                             "Тип интерфейса службы EVPN.";
                         }
                         container evpn-policies {
                           description
                             "Набор правил EVPN, таких как связанные
                              с обработкой MAC-адресов.";
                           leaf mac-learning-mode {
                             type identityref {
                               base mac-learning-mode;
                             }
                             description
                               "Плоскость для анонсов MAC-адресов.";
                           }
                           leaf ingress-replication {
                             type boolean;
                             description
                               "Включает (true) или отключает (false)
                                репликацию на входе.";
                             reference
                               "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                          Section 8.3.1.1";
                           }
                           leaf p2mp-replication {
                             type boolean;
                             description
                               "Включает (true) или отключает (false)
                                репликацию P2MP";
                             reference
                               "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                          Section 8.3.1.2";
                           }
                           container arp-proxy {
                             if-feature "vpn-common:ipv4";
                             description
                               "Контейнер верхнего уровня для ARP proxy.";
                             leaf enable {
                               type boolean;
                               default "false";
                               description
                                 "Включает (true) или отключает (false)
                                  ARP proxy.";
                               reference
                                 "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                            Section 10";
                             }
                             leaf arp-suppression {
                               type boolean;
                               default "false";
                               description
                                 "Включает (true) или отключает (false)
                                  подавление ARP.";
                               reference
                                 "RFC 7432: BGP MPLS-Based Ethernet
                                            VPN";
                             }
                             leaf ip-mobility-threshold {
                               type uint16;
                               description
                                 "Для данного хоста (как определено его
                                  адресом IP) возможен переход из одного
                                  ES в другой. Порог мобильности IP
                                  задаёт число переносов IP, которые
                                  детектируются для данного IP-адреса
                                  в рамках порога обнаружения до того,
                                  как адрес IP будет сочтён дубликатом.
                                  По достижении порога обновления для
                                  адреса IP подавляются.";
                             }
                             leaf duplicate-ip-detection-interval {
                               type uint16;
                               units "seconds";
                               description
                                 "Интервал времени для обнаружения
                                  дубликатов адресов IP. В течение этого
                                  интервала допускается перемещение 
                                  хостов с дублированием адресов.";
                             }
                           }
                           container nd-proxy {
                             if-feature "vpn-common:ipv6";
                             description
                               "Контейнер верхнего уровня для ND proxy.";
                             leaf enable {
                               type boolean;
                               default "false";
                               description
                                 "Включает (true) или отключает (false)
                                  ND proxy.";
                               reference
                                 "RFC 7432: BGP MPLS-Based Ethernet VPN,
                                            Section 10";
                             }
                             leaf nd-suppression {
                               type boolean;
                               default "false";
                               description
                                 "Включает (true) или отключает (false)
                                  подавление сообщений обнаружения
                                  соседей (Neighbor Discovery или ND).
                                  Метод подавления ND служит для
                                  сокращения числа пакетов ND лавинно
                                  рассылаемых в отдельных сегментах
                                  между хостами, подключёнными к одному
                                  логическому коммутатору.";
                             }
                             leaf ip-mobility-threshold {
                               type uint16;
                               description
                                 "Данный хост (определённый его адресом
                                  IP) может перейти в другой ES.
                                  Порог мобильности IP задаёт число
                                  переносов IP, обнаруженных для данного
                                  IP-адреса в рамках порога обнаружения
                                  до того, как адрес будет сочтён
                                  дубликатом IP. По достижении порога
                                  обновления адресов IP подавляются.";
                             }
                             leaf duplicate-ip-detection-interval {
                               type uint16;
                               units "seconds";
                               description
                                 "Интервал времени для обнаружения 
                                  дубликатов IP. В течение этого
                                  интервала допускается перемещение 
                                  хостов с дублированием адресов.";
                             }
                           }
                           leaf underlay-multicast {
                             type boolean;
                             default "false";
                             description
                               "Включает (true) или отключает (false)
                                базовую групповую передачу.";
                           }
                           leaf flood-unknown-unicast-suppression {
                             type boolean;
                             default "false";
                             description
                               "Включает (true) или отключает (false)
                                подавление лавинной рассылки по
                                неизвестным индивидуальным адресам.";
                           }
                           leaf vpws-vlan-aware {
                             type boolean;
                             default "false";
                             description
                               "Включает (true) или отключает (false)
                                сервис VPWS с поддержкой VLAN для
                                экземпляра EVPN.";
                           }
                           container bum-management {
                             description
                               "Управление BUM.";
                             leaf discard-broadcast {
                               type boolean;
                               default "false";
                               description
                                 "true для отбрасывания широковещания.";
                             }
                             leaf discard-unknown-multicast {
                               type boolean;
                               default "false";
                               description
                                 "true для отбрасывания неизвестных.";
                                  multicast.";
                             }
                             leaf discard-unknown-unicast {
                               type boolean;
                               default "false";
                               description
                                 "true для отбрасывания неизвестных.";
                                  unicast.";
                             }
                           }
                           container pbb {
                             when "derived-from-or-self("
                                + "../../evpn-type, 'pbb-evpn')" {
                               description
                                 "Применимо лишь к PBB EVPN.";
                             }
                             description
                               "Контейнер параметров PBB.";
                             reference
                               "IEEE 802.1ah: Provider Backbone
                                              Bridges";
                             leaf backbone-src-mac {
                               type yang:mac-address;
                               description
                                 "Адрес B-MAC.";
                               reference
                                 "RFC 7623: Provider Backbone Bridging
                                            Combined with Ethernet VPN
                                            (PBB-EVPN), Section 8.1";
                             }
                           }
                         }
                       }
                     }
                   }
                   container ldp-or-l2tp {
                     description
                       "Контейнер для выбора PW по сигналам LDP или L2TP.";
                     leaf agi {
                       type rt-types:route-distinguisher;
                       description
                         "Идентификатор устройства подключения (VPLS-Id).";
                       reference
                         "RFC 4667: Layer 2 Virtual Private Network
                                    (L2VPN) Extensions for Layer 2
                                    Tunneling Protocol (L2TP),
                                    Section 4.3
                          RFC 4762: Virtual Private LAN Service (VPLS)
                                    Using Label Distribution Protocol
                                    (LDP) Signaling, Section 6.1.1";
                     }
                     leaf saii {
                       type uint32;
                       description
                         "Идентификатор SAII.";
                       reference
                         "RFC 4667: Layer 2 Virtual Private Network
                                    (L2VPN) Extensions for Layer 2
                                    Tunneling Protocol (L2TP),
                                    Section 3";
                     }
                     list remote-targets {
                       key "taii";
                       description
                         "Список разрешённых AII и партнёров.";
                       reference
                         "RFC 4667: Layer 2 Virtual Private Network
                                    (L2VPN) Extensions for Layer 2
                                    Tunneling Protocol (L2TP),
                                    Section 5";
                       leaf taii {
                         type uint32;
                         description
                           "Идентификатор TAI.";
                         reference
                           "RFC 4667: Layer 2 Virtual Private Network
                                      (L2VPN) Extensions for Layer 2
                                      Tunneling  Protocol (L2TP),
                                      Section 3";
                       }
                       leaf peer-addr {
                         type inet:ip-address;
                         description
                           "IP-адрес партнёрского узла пересылки.";
                       }
                     }
                     choice ldp-or-l2tp {
                       description
                         "Выбор PW с сигнализацией LDP или L2TP.";
                       case ldp {
                         description
                           "Контейнер для конфигураций T-LDP PW.";
                         leaf t-ldp-pw-type {
                           type identityref {
                             base t-ldp-pw-type;
                           }
                           description
                             "Тип T-LDP PW.";
                         }
                         leaf pw-type {
                           type identityref {
                             base ldp-pw-type;
                           }
                           description
                             "Тип инкапсуляции PW.";
                           reference
                             "RFC 4762: Virtual Private LAN Service
                                        (VPLS) Using Label Distribution
                                        Protocol (LDP) Signaling,
                                        Section 6.1.1";
                         }
                         leaf pw-description {
                           type string;
                           description
                             "Понятное человеку описание интерфейса, 
                              которое может применяться при связи
                              с удаленным партнером.";
                           reference
                             "RFC 4762: Virtual Private LAN Service
                                        (VPLS) Using Label Distribution
                                        Protocol (LDP) Signaling,
                                        Section 6.1.1";
                         }
                         leaf mac-addr-withdraw {
                           type boolean;
                           description
                             "Разрешает (true) или запрещает (false) 
                              отзыв MAC-адреса.";
                           reference
                             "RFC 4762: Virtual Private LAN Service
                                        (VPLS) Using Label Distribution
                                        Protocol (LDP) Signaling,
                                        Section 6.2";
                         }
                         list pw-peer-list {
                           key "peer-addr vc-id";
                           description
                             "Список устройств подключения (AC) и 
                              привязок PW.";
                           leaf peer-addr {
                             type inet:ip-address;
                             description
                               "IP-адрес партнёра.";
                           }
                           leaf vc-id {
                             type string;
                             description
                               "Метка VC для идентификации PW.";
                           }
                           leaf pw-priority {
                             type uint32;
                             description
                               "Указывает приоритет PW. Большее значение
                                pw-priority задаёт предпочтение PW.";
                           }
                         }
                         container qinq {
                           when "derived-from-or-self("
                              + "../t-ldp-pw-type, 'hvpls')" {
                             description
                               "Применимо лишь к T-LDP PW типа H-VPLS.";
                           }
                           description
                             "Контейнер для QinQ.";
                           leaf s-tag {
                             type dot1q-types:vlanid;
                             mandatory true;
                             description
                               "S-TAG.";
                           }
                           leaf c-tag {
                             type dot1q-types:vlanid;
                             mandatory true;
                             description
                               "C-TAG.";
                           }
                         }
                       }
                       case l2tp {
                         description
                           "Контейнер для L2TP PW.";
                         leaf router-id {
                           type rt-types:router-id;
                           description
                             "32-битовое значение с разделением точками
                              для однозначного указания узла в сети
                              сервис-провайдера.";
                           reference
                             "RFC 4667: Layer 2 Virtual Private Network
                                        (L2VPN) Extensions for Layer 2
                                        Tunneling Protocol (L2TP),
                                        Section 4.2";
                         }
                         leaf pseudowire-type {
                           type identityref {
                             base iana-pw-types:iana-pw-types;
                           }
                           description
                             "Тип инкапсуляции.";
                           reference
                             "RFC 4667: Layer 2 Virtual Private Network
                                        (L2VPN) Extensions for Layer 2
                                        Tunneling Protocol (L2TP),
                                        Section 4.2";
                         }
                       }
                     }
                   }
                 }
               }
               container vpn-network-accesses {
                 description
                   "Основной контейнер для доступа в сеть VPN.";
                 list vpn-network-access {
                   key "id";
                   description
                     "Список доступов в VPN.";
                   leaf id {
                     type vpn-common:vpn-id;
                     description
                       "Идентификатор доступа в сеть.";
                   }
                   leaf description {
                     type string;
                     description
                       "Текстовое описание доступа в сеть VPN.";
                   }
                   leaf interface-id {
                     type string;
                     description
                       "Указывает физический или логический интерфейс.";
                   }
                   leaf active-vpn-node-profile {
                     type leafref {
                       path "../../.."
                          + "/active-global-parameters-profiles"
                          + "/global-parameters-profile/profile-id";
                     }
                     description
                       "Идентификатор профиля активного экземпляра VPN.";
                   }
                   uses vpn-common:service-status;
                   container connection {
                     description
                       "Контейнер носителя (bearer) и AC.";
                     leaf l2-termination-point {
                       type string;
                       description
                         "Ссылка на локальную точку завершения L2,
                          такую как субинтерфейс L2.";
                     }
                     leaf local-bridge-reference {
                       type string;
                       description
                         "Ссылка на локальный мост, для предоставления, 
                          например, реализациям, требующим внутренний
                          мост. Это может быть локальный домен мостов.";
                     }
                     leaf bearer-reference {
                       if-feature "vpn-common:bearer-reference";
                       type string;
                       description
                         "Внутренняя ссылка сервис-провайдера для 
                          указания носителя, связанного с VPN.";
                     }
                     container encapsulation {
                       description
                         "Контейнер для инкапсуляции L2.";
                       leaf encap-type {
                         type identityref {
                           base vpn-common:encapsulation-type;
                         }
                         default "vpn-common:priority-tagged";
                         description
                           "Интерфейс с тегами. По умолчанию имеет тип
                            priority-tagged.";
                       }
                       container dot1q {
                         when "derived-from-or-self(../encap-type, "
                            + "'vpn-common:dot1q')" {
                           description
                             "Применимо лишь к интерфейсам с 
                              тегами dot1q.";
                         }
                         description
                           "Интерфейс с тегами.";
                         leaf tag-type {
                           type identityref {
                             base vpn-common:tag-type;
                           }
                           default "vpn-common:c-vlan";
                           description
                             "Тип тега. По умолчанию c-vlan.";
                         }
                         leaf cvlan-id {
                           type dot1q-types:vlanid;
                           description
                             "Идентификатор VLAN.";
                         }
                         container tag-operations {
                           description
                             "Задаёт правила манипуляция с тегами для
                              этого доступа в VPN. Это набор действий по
                              вставке, удалению или перезаписи тегов
                              VLAN 802.1Q. Эти операции указываются для
                              направления от CE к PE. По умолчанию
                              ориентация тегов симметрична, поэтому для
                              направления от PE к CE предполагаются
                              обратные операции.";
                           choice op-choice {
                             description
                               "Правила перезаписи тегов для доступа в
                                сеть VPN.";
                             leaf pop {
                               type empty;
                               description
                                 "Втолкнуть внешний тег.";
                             }
                             leaf push {
                               type empty;
                               description
                                 "Выталкивает 1 или 2 тега, заданных
                                  листьями tag-1 и tag-2. Предполагается,
                                  что в отсутствие каких-либо правил для
                                  установки PCP применяется значение 0.";
                             }
                             leaf translate {
                               type empty;
                               description
                                 "Транслирует внешний тег в 1 или 2 тега.
                                  Биты PCP сохраняются.";
                             }
                           }
                           leaf tag-1 {
                             when 'not(../pop)';
                             type dot1q-types:vlanid;
                             description
                               "Первый тег для выталкивания или 
                                трансляции, который в результате операции
                                будет использоваться как внешний.";
                           }
                           leaf tag-1-type {
                             type dot1q-types:dot1q-tag-type;
                             default "dot1q-types:s-vlan";
                             description
                               "Конкретный тип тега 802.1Q из tag-1.";
                           }
                           leaf tag-2 {
                             when '(../translate)';
                             type dot1q-types:vlanid;
                             description
                               "Второй тег для трансляции.";
                           }
                           leaf tag-2-type {
                             type dot1q-types:dot1q-tag-type;
                             default "dot1q-types:c-vlan";
                             description
                               "Конкретный тип тега 802.1Q из tag-2.";
                           }
                         }
                       }
                       container priority-tagged {
                         when "derived-from-or-self(../encap-type, "
                            + "'vpn-common:priority-tagged')" {
                           description
                             "Применимо лишь к теговым интерфейсам типа
                              priority-tagged.";
                         }
                         description
                           "Контейнер тегов приоритета.";
                         leaf tag-type {
                           type identityref {
                             base vpn-common:tag-type;
                           }
                           default "vpn-common:c-vlan";
                           description
                             "Тип тега. По умолчанию c-vlan.";
                         }
                       }
                       container qinq {
                         when "derived-from-or-self(../encap-type, "
                            + "'vpn-common:qinq')" {
                           description
                             "Применимо лишь к теговым интерфейсам типа
                              QinQ.";
                         }
                         description
                           "Includes QinQ parameters.";
                         leaf tag-type {
                           type identityref {
                             base vpn-common:tag-type;
                           }
                           default "vpn-common:s-c-vlan";
                           description
                             "Тип тега. По умолчанию s-c-vlan.";
                         }
                         leaf svlan-id {
                           type dot1q-types:vlanid;
                           mandatory true;
                           description
                             "Идентификатор S-VLAN.";
                         }
                         leaf cvlan-id {
                           type dot1q-types:vlanid;
                           mandatory true;
                           description
                             "Идентификатор C-VLAN.";
                         }
                         container tag-operations {
                           description
                             "Правила действий с тегами для доступа в VPN,
                              задающие набор операция по вставке, удалению
                              и перезаписи тегов VLAN 802.1Q. Операции 
                              указываются для направления от CE к PE. По 
                              умолчанию ориентация тегов симметрична и
                              направления от PE к CE предполагаются
                              обратные операции.";
                           choice op-choice {
                             description
                               "Правила перезаписи тегов для доступа в 
                                сеть VPN.";
                             leaf pop {
                               type uint8 {
                                 range "1|2";
                               }
                               description
                                 "Вталкивает 1 или 2 тега в зависимости 
                                  от указанного значения pop.";
                             }
                             leaf push {
                               type empty;
                               description
                                 "Выталкивает 1 или 2 тега, заданных
                                  листьями tag-1 и tag-2. Предполагается,
                                  что в отсутствие каких-либо правил для
                                  установки PCP применяется значение 0.";
                             }
                             leaf translate {
                               type uint8 {
                                 range "1|2";
                               }
                               description
                                 "Транслирует 1 или 2 внешних тега. 
                                  Биты PCP сохраняются.

                                  Поддерживаются операции:
                                  - трансляция 1 с представленным листом
                                    tag-1 - транслируется лишь внешний 
                                    тег в значение tag-1.

                                  - трансляция 2 с представленными 
                                    листьями tag-1 и tag-2 — внешний и 
                                    внутренний тег транслируются в tag-1 
                                    и tag-2, соответственно
                                    respectively.

                                  - трансляция 2 представленным листом
                                    tag-1 - внешний тег вталкивается, а
                                    внутренний транслируется в tag-1.";
                             }
                           }
                           leaf tag-1 {
                             when 'not(../pop)';
                             type dot1q-types:vlanid;
                             description
                               "Первый тег для выталкивания или 
                                трансляции. В результате операции тег
                                будет использоваться как внешний.";
                           }
                           leaf tag-1-type {
                             type dot1q-types:dot1q-tag-type;
                             default "dot1q-types:s-vlan";
                             description
                               "Конкретный тип 802.1Q для tag-1.";
                           }
                           leaf tag-2 {
                             when 'not(../pop)';
                             type dot1q-types:vlanid;
                             description
                               "Второй тег для выталкивания или 
                                трансляции.";
                           }
                           leaf tag-2-type {
                             type dot1q-types:dot1q-tag-type;
                             default "dot1q-types:c-vlan";
                             description
                               "Конкретный тип 802.1Q для tag-2.";
                           }
                         }
                       }
                     }
                     container lag-interface {
                       if-feature "vpn-common:lag-interface";
                       description
                         "Контейнер для конфигурации атрибутов 
                          интерфейса LAG.";
                       leaf lag-interface-id {
                         type string;
                         description
                           "Контейнер интерфейса LAG.";
                       }
                       container lacp {
                         description
                           "Контейнер для LACP.";
                         leaf lacp-state {
                           type boolean;
                           default "false";
                           description
                             "Управляет включением LACP.";
                         }
                         leaf mode {
                           type identityref {
                             base lacp-mode;
                           }
                           description
                             "Режим LACP.";
                         }
                         leaf speed {
                           type uint32;
                           units "mbps";
                           default "10";
                           description
                             "Скорость LACP - это нижнее принятое по
                              умолчанию значения, наследуемое из L2SM.";
                         }
                         leaf mini-link-num {
                           type uint32;
                           description
                             "Минимальное число активных каналов, 
                              для активации композитного канала.";
                         }
                         leaf system-id {
                           type yang:mac-address;
                           description
                             "System ID, используемый LACP.";
                         }
                         leaf admin-key {
                           type uint16;
                           description
                             "Значение ключа, используемое для 
                              композитного интерфейса.";
                         }
                         leaf system-priority {
                           type uint16 {
                             range "0..65535";
                           }
                           default "32768";
                           description
                             "Приоритет LACP для системы.";
                         }
                         container member-link-list {
                           description
                             "Контейнер для списка каналов (Member).";
                           list member-link {
                             key "name";
                             description
                               "Канал группы (Member link).";
                             leaf name {
                               type string;
                               description
                                 "Имя канала (Member link).";
                             }
                             leaf speed {
                               type uint32;
                               units "mbps";
                               default "10";
                               description
                                 "Скорость порта.";
                             }
                             leaf mode {
                               type identityref {
                                 base vpn-common:neg-mode;
                               }
                               description
                                 "Режим согласования.";
                             }
                             leaf link-mtu {
                               type uint32;
                               units "bytes";
                               description
                                 "Размер MTU на канале.";
                             }
                             container oam-802.3ah-link {
                               if-feature "oam-3ah";
                               description
                                 "Контейнер для OAM 802.3ah на канале.";
                               leaf enable {
                                 type boolean;
                                 default "false";
                                 description
                                   "Поддержка канала OAM 802.3ah.";
                               }
                             }
                           }
                         }
                         leaf flow-control {
                           type boolean;
                           default "false";
                           description
                             "Управление потоком данных.";
                         }
                         leaf lldp {
                           type boolean;
                           default "false";
                           description
                             "Поддержка протокола LLDP.";
                         }
                       }
                       container split-horizon {
                         description
                           "Поддержка Split Horizon включена.";
                         leaf group-name {
                           type string;
                           description
                             "Имя группы Split Horizon.";
                         }
                       }
                     }
                   }
                   choice signaling-option {
                     description
                       "Выбор опций сигнализации.";
                     case bgp {
                       description
                         "BGP в качестве сигнального протокола.";
                       choice bgp-type {
                         description
                           "Выбор типа BGP.";
                         case l2vpn-bgp {
                           description
                             "Контейнер для BGP L2VPN.";
                           leaf ce-id {
                             type uint16;
                             description
                               "Указывает CE внутри VPN.";
                             reference
                               "RFC 6624: Layer 2 Virtual Private
                                          Networks Using BGP for
                                          Auto-Discovery and Signaling";
                           }
                           leaf remote-ce-id {
                             type uint16;
                             description
                               "Идентификатор удалённого CE.";
                           }
                           container vpls-instance {
                             when "derived-from-or-self(../../../../../"
                                + "vpn-type, 'vpn-common:vpls')" {
                               description
                                 "Применим лишь для VPLS.";
                             }
                             description
                               "Экземпляр VPLS.";
                             leaf vpls-edge-id {
                               type uint16;
                               description
                                 "Идентификатор VPLS Edge (VE ID).";
                               reference
                                 "RFC 4761: Virtual Private LAN Service
                                            (VPLS) Using BGP for Auto-
                                            Discovery and Signaling,
                                            Section 3.2.1";
                             }
                           }
                         }
                         case evpn-bgp {
                           description
                             "Применяется для EVPN.";
                           leaf df-preference {
                             type uint16;
                             default "32767";
                             description
                               "2-октетное значение предпочтения PE при
                                выборе DF в ES. Применимо лишь для 
                                метода preference-based.";
                             reference
                               "RFC 8584: Framework for Ethernet VPN
                                          Designated Forwarder Election
                                          Extensibility";
                           }
                           container vpws-service-instance {
                             when "derived-from-or-self(../../../../../"
                                + "vpn-type, 'vpn-common:vpws-evpn')" {
                               description
                                 "Применим лишь для EVPN-VPWS.";
                             }
                             description
                               "Локальный и удалённый экземпляр VSI.";
                             reference
                               "RFC 8214: Virtual Private Wire Service
                                          Support in Ethernet VPN";
                             choice local-vsi-choice {
                               description
                                 "Выбор для назначения локального VSI.";
                               case directly-assigned {
                                 description
                                   "Явно заданное локальное значение VSI.";
                                 leaf local-vpws-service-instance {
                                   type uint32 {
                                     range "1..16777215";
                                   }
                                   description
                                     "Заданное локальное значение VSI.";
                                 }
                               }
                               case auto-assigned {
                                 description
                                   "Автоназначение локального VSI.";
                                 container local-vsi-auto {
                                   description
                                     "Локальный VSI задан автоматически.";
                                   choice auto-mode {
                                     description
                                       "Режим автоназначения локального
                                        VSI (с указанием или без указания
                                        пула для выбора VSI). В обоих
                                        случаях сервер будет автоматически
                                        задавать и применять VSI.";
                                     case from-pool {
                                       leaf vsi-pool-name {
                                         type string;
                                         description
                                           "Автоматическое назначение из
                                            данного пула.";
                                       }
                                     }
                                     case full-auto {
                                       leaf auto {
                                         type empty;
                                         description
                                           "Полностью автоматическое
                                            назначение локального VSI.";
                                       }
                                     }
                                   }
                                   leaf auto-local-vsi {
                                     type uint32 {
                                       range "1..16777215";
                                     }
                                     config false;
                                     description
                                       "Автоматически заданное значение
                                        локального VSI.";
                                   }
                                 }
                               }
                             }
                             choice remote-vsi-choice {
                               description
                                 "Выбор для удалённого VSI.";
                               case directly-assigned {
                                 description
                                   "Явное назначение удалённого VSI.";
                                 leaf remote-vpws-service-instance {
                                   type uint32 {
                                     range "1..16777215";
                                   }
                                   description
                                     "Значение удалённого VSI.";
                                 }
                               }
                               case auto-assigned {
                                 description
                                   "Автоназначение удалённого VSI.";
                                 container remote-vsi-auto {
                                   description
                                     "Удалённый VSI задан автоматически.";
                                   choice auto-mode {
                                     description
                                       "Режим автоназначения удаленного
                                        VSI (с указанием или без указания
                                        пула для выбора VSI). В обоих
                                        случаях сервер будет автоматически
                                        задавать и применять VSI.";
                                     case from-pool {
                                       leaf vsi-pool-name {
                                         type string;
                                         description
                                           "Автоназначение из этого пула.";
                                       }
                                     }
                                     case full-auto {
                                       leaf auto {
                                         type empty;
                                         description
                                           "Полностью автоматическое 
                                            назначение удалённого VSI.";
                                       }
                                     }
                                   }
                                   leaf auto-remote-vsi {
                                     type uint32 {
                                       range "1..16777215";
                                     }
                                     config false;
                                     description
                                       "Автоматически заданное значение
                                        удалённого VSI.";
                                   }
                                 }
                               }
                             }
                           }
                         }
                       }
                     }
                   }
                   list group {
                     key "group-id";
                     description
                       "Список group-id.";
                     leaf group-id {
                       type string;
                       description
                         "group-id группы, к относится доступ в сеть.";
                     }
                     leaf precedence {
                       type identityref {
                         base precedence-type;
                       }
                       description
                         "Задаёт избыточность транспортной сети.";
                     }
                     leaf ethernet-segment-identifier {
                       type l2vpn-es:es-ref;
                       description
                         "Ссылка на ESI, связанный с доступом в VPN.";
                     }
                   }
                   container ethernet-service-oam {
                     description
                       "Контейнер для OAM службы Ethernet.";
                     leaf md-name {
                       type string;
                       description
                         "Имя домена поддержки.";
                     }
                     leaf md-level {
                       type uint8;
                       description
                         "Уровень домена поддержки.";
                     }
                     container cfm-802.1-ag {
                       description
                         "Контейнер для конфигурации 802.1ag CFM.";
                       list n2-uni-c {
                         key "maid";
                         description
                           "Список UNI-N в UNI-C.";
                         uses cfm-802;
                       }
                       list n2-uni-n {
                         key "maid";
                         description
                           "Список UNI-N в UNI-N.";
                         uses cfm-802;
                       }
                     }
                     uses y-1731;
                   }
                   container service {
                     description
                       "Контейнер для службы.";
                     leaf mtu {
                       type uint32;
                       units "bytes";
                       description
                         "L2 MTU, называется также максимальным блоком
                          передачи или максимальным размером кадра.";
                     }
                     container svc-pe-to-ce-bandwidth {
                       if-feature "vpn-common:inbound-bw";
                       description
                         "Пропускная способность на входе с точки зрения
                          сайта клиента или на выходе с точки зрения
                          провайдера. Отметим, что в L2SM для этого
                          применяется input-bandwidth.";
                       list pe-to-ce-bandwidth {
                         key "bw-type";
                         description
                           "Список узлов данных для полосы от PE к CE.";
                         leaf bw-type {
                           type identityref {
                             base vpn-common:bw-type;
                           }
                           description
                             "Тип пропускной способности.";
                         }
                         choice type {
                           description
                             "Выбор по типу пропускной способности.";
                           case per-cos {
                             description
                               "Пропускная способность на CoS.";
                             list cos {
                               key "cos-id";
                               description
                                 "Список классов обслуживания (CoS).";
                               leaf cos-id {
                                 type uint8;
                                 description
                                   "Идентификатор CoS, указываемый DSCP
                                    или значением CE-CLAN CoS (802.1p) в
                                    кадре сервиса.";
                                 reference
                                   "IEEE Std 802.1Q: Bridges and Bridged
                                                     Networks";
                               }
                               uses bandwidth-parameters;
                             }
                           }
                           case other {
                             description
                               "Иные типы пропускной способности.";
                             uses bandwidth-parameters;
                           }
                         }
                       }
                     }
                     container svc-ce-to-pe-bandwidth {
                       if-feature "vpn-common:outbound-bw";
                       description
                         "Выходная пропускная способность с точки 
                          зрения сайта или полоса выгрузки от CE к PE.
                          Отметим, что в L2SM для этого служит
                          output-bandwidth.";
                       list ce-to-pe-bandwidth {
                         key "bw-type";
                         description
                           "Список значений полосы от CE к PE.";
                         leaf bw-type {
                           type identityref {
                             base vpn-common:bw-type;
                           }
                           description
                             "Тип пропускной способности.";
                         }
                         choice type {
                           description
                             "Выбор по типу пропускной способности.";
                           case per-cos {
                             description
                               "Пропускная способность на CoS.";
                             list cos {
                               key "cos-id";
                               description
                                 "Список классов обслуживания CoS).";
                               leaf cos-id {
                                 type uint8;
                                 description
                                   "Идентификатор CoS, указываемый DSCP
                                    или значением CE-CLAN CoS (802.1p) в
                                    кадре сервиса.";
                                 reference
                                   "IEEE Std 802.1Q: Bridges and Bridged
                                                     Networks";
                               }
                               uses bandwidth-parameters;
                             }
                           }
                           case other {
                             description
                               "Не знающие CoS типы пропускной способности.";
                             uses bandwidth-parameters;
                           }
                         }
                       }
                     }
                     container qos {
                       if-feature "vpn-common:qos";
                       description
                         "Конфигурация QoS.";
                       container qos-classification-policy {
                         description
                           "Конфигурация правил классификации трафика.";
                         list rule {
                           key "id";
                           ordered-by user;
                           description
                             "Список правил классификации.";
                           leaf id {
                             type string;
                             description
                               "Описание, идентифицирующее правило 
                                политики классификации QoS.";
                           }
                           choice match-type {
                             default "match-flow";
                             description
                               "Выбор для классификации.";
                             case match-flow {
                               container match-flow {
                                 description
                                   "Критерии соответствия потоку.";
                                 leaf dscp {
                                   type inet:dscp;
                                   description
                                     "Значение DSCP.";
                                 }
                                 leaf dot1q {
                                   type uint16;
                                   description
                                     "Сопоставление 802.1Q - тег VLAN, 
                                      добавленный в кадр.";
                                   reference
                                     "IEEE Std 802.1Q: Bridges and
                                                       Bridged
                                                       Networks";
                                 }
                                 leaf pcp {
                                   type uint8 {
                                     range "0..7";
                                   }
                                   description
                                     "Код приоритета (PCP).";
                                 }
                                 leaf src-mac-address {
                                   type yang:mac-address;
                                   description
                                     "MAC-адрес источника.";
                                 }
                                 leaf dst-mac-address {
                                   type yang:mac-address;
                                   description
                                     "MAC-адрес получателя.";
                                 }
                                 leaf color-type {
                                   type identityref {
                                     base color-type;
                                   }
                                   description
                                     "Цветовой тип.";
                                 }
                                 leaf any {
                                   type empty;
                                   description
                                     "Разрешено все.";
                                 }
                               }
                             }
                             case match-application {
                               leaf match-application {
                                 type identityref {
                                   base vpn-common:customer-application;
                                 }
                                 description
                                   "Задаёт приложение для сопоставления.";
                               }
                             }
                           }
                           leaf target-class-id {
                             type string;
                             description
                               "Указание CoS (для администратора).";
                           }
                         }
                       }
                       container qos-profile {
                         description
                           "Конфигурация профиля QoS.";
                         list qos-profile {
                           key "profile";
                           description
                             "Профиль QoS (стандартный или свой).";
                           leaf profile {
                             type leafref {
                               path "/l2vpn-ntw/vpn-profiles"
                                  + "/valid-provider-identifiers"
                                  + "/qos-profile-identifier/id";
                             }
                             description
                               "Профиль QoS для использования.";
                           }
                           leaf direction {
                             type identityref {
                               base vpn-common:qos-profile-direction;
                             }
                             default "vpn-common:both";
                             description
                               "Направление для применения профиля QoS.";
                           }
                         }
                       }
                     }
                     container mac-policies {
                       description
                         "Контейнер для связанных с MAC правил.";
                       list access-control-list {
                         key "name";
                         description
                           "Контейнер для списков ACL.";
                         leaf name {
                           type string;
                           description
                             "Имя ACL.";
                         }
                         leaf-list src-mac-address {
                           type yang:mac-address;
                           description
                             "MAC-адрес источника.";
                         }
                         leaf-list src-mac-address-mask {
                           type yang:mac-address;
                           description
                             "Маска MAC для источника.";
                         }
                         leaf-list dst-mac-address {
                           type yang:mac-address;
                           description
                             "MAC-адрес получателя.";
                         }
                         leaf-list dst-mac-address-mask {
                           type yang:mac-address;
                           description
                             "Маска MAC для получателя.";                         }
                         leaf action {
                           type identityref {
                             base mac-action;
                           }
                           default "drop";
                           description
                             "Задаёт действие для фильтра.";
                         }
                         leaf rate-limit {
                           when "derived-from-or-self(../action, "
                              + "'flood')" {
                             description
                               "Ограничение скорости применимо лишь
                                для восприятия соответствующего кадра.";
                           }
                           type decimal64 {
                             fraction-digits 2;
                           }
                           units "bytes per second";
                           description
                             "Ограничение скорости трафика.";
                         }
                       }
                       container mac-loop-prevention {
                         description
                           "Контейнер для предотвращения петель MAC.";
                         leaf window {
                           type uint32;
                           units "seconds";
                           default "180";
                           description
                             "Таймер обнаружения переноса MAC.";
                         }
                         leaf frequency {
                           type uint32;
                           default "5";
                           description
                             "Число обнаружений дублирования MAC,
                              при котором фиксируется событие и
                              адрес MAC добавляется в таблицу
                              дубликатов.";
                         }
                         leaf retry-timer {
                           type uint32;
                           units "seconds";
                           description
                             "Таймер повтора, по истечении которого
                              дубликат MAC удаляется из MAC-VRF.";
                         }
                         leaf protection-type {
                           type identityref {
                             base loop-prevention-type;
                           }
                           default "trap";
                           description
                             "Тип защиты";
                         }
                       }
                       container mac-addr-limit {
                         description
                           "Контейнер для настройки предела MAC-Addr.";
                         leaf limit-number {
                           type uint16;
                           default "2";
                           description
                             "Максимальное число MAC-адресов, узнанных
                              от клиента для 1 экземпляра службы.";
                         }
                         leaf time-interval {
                           type uint32;
                           units "milliseconds";
                           default "300";
                           description
                             "Время устаревания MAC-адреса.";
                         }
                         leaf action {
                           type identityref {
                             base mac-action;
                           }
                           default "warning";
                           description
                             "Действие при достижении верхнего предела - 
                              отбрасывание, лавинная рассылка или запись
                              предупреждения (без отбрасывания пакета).";
                         }
                       }
                     }
                     container broadcast-unknown-unicast-multicast {
                       description
                         "Контейнер для настройки BUM.";
                       leaf multicast-site-type {
                         type enumeration {
                           enum receiver-only {
                             description
                               "На сайте имеются лишь получатели.";
                           }
                           enum source-only {
                             description
                               "На сайте имеются лишь источники.";
                           }
                           enum source-receiver {
                             description
                               " На сайте имеются источники и получатели.";
                           }
                         }
                         default "source-receiver";
                         description
                           "Тип multicast-сайта.";
                       }
                       list multicast-gp-address-mapping {
                         key "id";
                         description
                           "Список отображений портов на группы.";
                         leaf id {
                           type uint16;
                           description
                             "Уникальный идентификатор отображения.";
                         }
                         leaf vlan-id {
                           type uint32;
                           mandatory true;
                           description
                             "VLAN ID для multicast-группы.";
                         }
                         leaf mac-gp-address {
                           type yang:mac-address;
                           mandatory true;
                           description
                             "MAC-адрес multicast-группы.";
                         }
                         leaf port-lag-number {
                           type uint32;
                           description
                             "Порт/LAG, относящийся к multicast-группе.";
                         }
                       }
                       leaf bum-overall-rate {
                         type uint64;
                         units "bps";
                         description
                           "Общая скорость для BUM.";
                       }
                     }
                   }
                 }
               }
             }
           }
         }
       }
     }
   }
   <CODE ENDS>

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

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

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

В модулях ietf-l2vpn-ntw и ietf-ethernet-segment определено множество узлов данных, доступных для записи/создания/удаления (т. е. по умолчанию задано config true). Эти узлы могут оказаться чувствительными или уязвимыми в некоторых сетевых средах. Операции записи (например, edit-config) и удаления для таких узлов данных без подобающей защиты и аутентификации могут оказывать негативное влияние на работу сети. Ниже указаны субдеревья и узлы данных модулей ietf-l2vpn-ntw и ietf-ethernet-segment с присущими им уязвимостями.

vpn-profiles

ethernet-segments и vpn-services

Некоторые из доступных для чтения узлов данных в модуле ietf-l2vpn-ntw могут оказаться чувствительными или уязвимыми в некоторых сетевых средах. Важно контролировать доступ к чтению (например, get, get-config, notification) таких узлов. Ниже указаны субдеревья и узлы данных модулей с присущими им уязвимостями.

customer-name и ip-connection

Модули iana-bgp-l2-encaps и iana-pseudowire-types указывают типы инкапсуляции и псевдопроводов. Эти идентификаторы предназначены для ссылок из других модулей YANG и сами по себе не раскрывают каких-либо узлов, которые доступны для записи или содержать предназначенные лишь для чтения (read-only) состояния или RPC.

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

10.1. Регистрация модулей YANG

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

   URI:  urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

   URI:  urn:ietf:params:xml:ns:yang:iana-pseudowire-types
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

   URI:  urn:ietf:params:xml:ns:yang:ietf-ethernet-segment
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

   URI:  urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

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

   name:  iana-bgp-l2-encaps
   namespace:  urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps
   maintained by IANA:  Y
   prefix:  iana-bgp-l2-encaps
   reference:  RFC 9291

   name:  iana-pseudowire-types
   namespace:  urn:ietf:params:xml:ns:yang:iana-pseudowire-types
   maintained by IANA:  Y
   prefix:  iana-pw-types
   reference:  RFC 9291

   name:  ietf-ethernet-segment
   namespace:  urn:ietf:params:xml:ns:yang:ietf-ethernet-segment
   maintained by IANA:  N
   prefix:  l2vpn-es
   reference:  RFC 9291

   name:  ietf-l2vpn-ntw
   namespace:  urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
   maintained by IANA:  N
   prefix:  l2vpn-ntw
   reference:  RFC 9291

10.2. Типы инкапсуляции BGP L2

Этот документ задаёт исходную версию поддерживаемого IANA модуля YANG iana-bgp-l2-encaps (8.1. Модуль IANA для типов инкапсуляции BGP L2). Агентство IANA добавило приведённый ниже текст в реестр YANG Module Names.

Типы инкапсуляции BGP L2 недопустимо напрямую добавлять в модуль iana-bgp-l2-encaps, они должны добавляться в реестр BGP Layer 2 Encapsulation Types [IANA-BGP-L2].

При добавлении типа инкапсуляции L2 в реестр BGP Layer 2 Encapsulation Types должен добавляться оператор identity в модуль iana-bgp-l2-encaps. Имя identity указывается символами нижнего регистра и содержит имя инкапсуляции, представленного в описании. В оператор identity следует включать указанные ниже субоператоры.

   "base":        содержит bgp-l2-encaps-type.
   "description": копия описания из реестра.
   "reference":   копия ссылки из реестра с указанием названия документа.

В модуле нет невыделенных и зарезервированных значений.

При обновлении модуля iana-bgp-l2-encaps должен добавляться оператор revision с уникальной датой выпуска, указанной перед имеющимися операторами revision.

Агентство IANA добавило в [IANA-BGP-L2] приведённый ниже текст.

При обновлении реестра должен обновляться модуль YANG iana-bgp-l2-encaps, как указано в RFC 9291.

10.3. Типы псевдопроводов

Этот документ задаёт исходную версию поддерживаемого IANA модуля YANG iana-pseudowire-types (8.2. Модуль IANA для типов псевдопроводов). Агентство IANA добавило приведённый ниже текст в реестр YANG Module Names.

Типы псевдопроводов MPLS недопустимо напрямую добавлять в модуль iana-pseudowire-types, они должны добавляться в реестр MPLS Pseudowire Types [IANA-PW-TYPES].

При добавлении псевдопровода в реестр iana-pseudowire-types должен добавляться оператор identity в модуль iana-pseudowire-types. Имя identity указывается символами нижнего регистра и содержит имя инкапсуляции, представленного в описании. В оператор identity следует включать указанные ниже субоператоры.

   "base":        содержит iana-pw-types.
   "description": копия описания из реестра.
   "reference":   копия ссылки из реестра с указанием названия документа.

В модуле нет невыделенных и зарезервированных значений.

При обновлении модуля iana-pseudowire-types должен добавляться оператор revision с уникальной датой выпуска, указанной перед имеющимися операторами revision.

Агентство IANA добавило в [IANA-PW-TYPES] приведённый ниже текст.

При обновлении реестра должен обновляться модуль YANG iana-pseudowire-types, как указано в RFC 9291.

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

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

[IANA-BGP-L2] IANA, «BGP Layer 2 Encapsulation Types», <https://www.iana.org/assignments/bgp-parameters>.

[IANA-PW-TYPES] IANA, «MPLS Pseudowire Types Registry», <http://www.iana.org/assignments/pwe3-parameters/>.

[IEEE-802-1ag] IEEE, «IEEE Standard for Local and Metropolitan Area Networks — Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management», DOI 10.1109/IEEESTD.2007.4431836, IEEE Std 802.1ag-2007, December 2007, <https://doi.org/10.1109/IEEESTD.2007.4431836>.

[IEEE802.1Qcp] IEEE, «IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks—Amendment 30: YANG Data Model», DOI 10.1109/IEEESTD.2018.8467507, IEEE Std 802.1Qcp-2018, September 2018, <https://doi.org/10.1109/IEEESTD.2018.8467507>.

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

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

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

[RFC4446] Martini, L., «IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)», BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <https://www.rfc-editor.org/info/rfc4446>.

[RFC4667] Luo, W., «Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)», RFC 4667, DOI 10.17487/RFC4667, September 2006, <https://www.rfc-editor.org/info/rfc4667>.

[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., «Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling», RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.

[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., «Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling», RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.

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

[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, «Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)», RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.

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

[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, «Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling», RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.

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

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, «BGP MPLS-Based Ethernet VPN», RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, «Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)», RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.

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

[RFC8077] Martini, L., Ed. and G. Heron, Ed., «Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)», STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.

[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, «Virtual Private Wire Service Support in Ethernet VPN», RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.

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

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

[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, «A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)», RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>.

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

[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, «A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery», RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>.

[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, «Framework for Ethernet VPN Designated Forwarder Election Extensibility», RFC 8584, DOI 10.17487/RFC8584, April 2019, <https://www.rfc-editor.org/info/rfc8584>.

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

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

[BGP-YANG-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-14, 3 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-14>.

[EVPN-PERF-DF] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and A. Sajassi, «Preference-based EVPN DF Election», Work in Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-10, 2 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-10>.

[EVPN-YANG] Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain, I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., «Yang Data Model for EVPN», Work in Progress, Internet-Draft, draft-ietf-bess-evpn-yang-07, 11 March 2019, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07>.

[IEEE-802-1ah] IEEE, «IEEE Standard for Local and metropolitan area networks — Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges», IEEE Std 801.3AH-2008, August 2008, <https://standards.ieee.org/standard/802_1ah-2008.html>.

[IEEE-802-3ah] IEEE, «IEEE Standard for Information technology— Local and metropolitan area networks— Part 3: CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks», DOI 10.1109/IEEESTD.2004.94617, IEEE Std 802.3AH-2004, September 2004, <https://doi.org/10.1109/IEEESTD.2004.94617>.

[IEEE802.1AX] IEEE, «IEEE Standard for Local and Metropolitan Area Networks—Link Aggregation», DOI 10.1109/IEEESTD.2020.9105034, IEEE Std 802.1AX-2020, May 2020, <https://doi.org/10.1109/IEEESTD.2020.9105034>.

[IEEE802.1Q] IEEE, «IEEE Standard for Local and Metropolitan Area Network—Bridges and Bridged Networks», DOI 10.1109/IEEESTD.2018.8403927, IEEE Std 802.1Q-2018, July 2018, <https://doi.org/10.1109/IEEESTD.2018.8403927>.

[IETF-NET-SLICES] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, «Framework for IETF Network Slices», Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3 August 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-14>.

[MFA] MFA Forum Technical Committee, «The Use of Virtual Trunks for ATM/MPLS Control Plane Interworking Specification», MFA Forum 9.0.0, February 2006.

[PYANG] «pyang», November 2020, <https://github.com/mbj4668/pyang>.

[RFC2507] Degermark, M., Nordgren, B., and S. Pink, «IP Header Compression», RFC 2507, DOI 10.17487/RFC2507, February 1999, <https://www.rfc-editor.org/info/rfc2507>.

[RFC2508] Casner, S. and V. Jacobson, «Compressing IP/UDP/RTP Headers for Low-Speed Serial Links», RFC 2508, DOI 10.17487/RFC2508, February 1999, <https://www.rfc-editor.org/info/rfc2508>.

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, «MPLS Label Stack Encoding», RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.

[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, «Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering», RFC 3545, DOI 10.17487/RFC3545, July 2003, <https://www.rfc-editor.org/info/rfc3545>.

[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, «Policy Quality of Service (QoS) Information Model», RFC 3644, DOI 10.17487/RFC3644, November 2003, <https://www.rfc-editor.org/info/rfc3644>.

[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, «Encapsulation Methods for Transport of Ethernet over MPLS Networks», RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.

[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., «Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)», RFC 4553, DOI 10.17487/RFC4553, June 2006, <https://www.rfc-editor.org/info/rfc4553>.

[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, «Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks», RFC 4618, DOI 10.17487/RFC4618, September 2006, <https://www.rfc-editor.org/info/rfc4618>.

[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., «Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks», RFC 4619, DOI 10.17487/RFC4619, September 2006, <https://www.rfc-editor.org/info/rfc4619>.

[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., «Framework for Layer 2 Virtual Private Networks (L2VPNs)», RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.

[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, «Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks», RFC 4717, DOI 10.17487/RFC4717, December 2006, <https://www.rfc-editor.org/info/rfc4717>.

[RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, «Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service», RFC 4816, DOI 10.17487/RFC4816, February 2007, <https://www.rfc-editor.org/info/rfc4816>.

[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, «Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)», RFC 4842, DOI 10.17487/RFC4842, April 2007, <https://www.rfc-editor.org/info/rfc4842>.

[RFC4863] Martini, L. and G. Swallow, «Wildcard Pseudowire Type», RFC 4863, DOI 10.17487/RFC4863, May 2007, <https://www.rfc-editor.org/info/rfc4863>.

[RFC4901] Ash, J., Ed., Hand, J., Ed., and A. Malis, Ed., «Protocol Extensions for Header Compression over MPLS», RFC 4901, DOI 10.17487/RFC4901, June 2007, <https://www.rfc-editor.org/info/rfc4901>.

[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, «Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)», RFC 5086, DOI 10.17487/RFC5086, December 2007, <https://www.rfc-editor.org/info/rfc5086>.

[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, «Time Division Multiplexing over IP (TDMoIP)», RFC 5087, DOI 10.17487/RFC5087, December 2007, <https://www.rfc-editor.org/info/rfc5087>.

[RFC5143] Malis, A., Brayley, J., Shirron, J., Martini, L., and S. Vogelsang, «Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation», RFC 5143, DOI 10.17487/RFC5143, February 2008, <https://www.rfc-editor.org/info/rfc5143>.

[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, «The Robust Header Compression (ROHC) Framework», RFC 5795, DOI 10.17487/RFC5795, March 2010, <https://www.rfc-editor.org/info/rfc5795>.

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

[RFC6307] Black, D., Ed., Dunbar, L., Ed., Roth, M., and R. Solomon, «Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks», RFC 6307, DOI 10.17487/RFC6307, April 2012, <https://www.rfc-editor.org/info/rfc6307>.

[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, «Requirements for Ethernet VPN (EVPN)», RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>.

[RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., «Dynamic Placement of Multi-Segment Pseudowires», RFC 7267, DOI 10.17487/RFC7267, June 2014, <https://www.rfc-editor.org/info/rfc7267>.

[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, «IP Connectivity Provisioning Profile (CPP)», RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.

[RFC7951] Lhotka, L., «JSON Encoding of Data Modeled with YANG», RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

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

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

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

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

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., «Framework for Abstraction and Control of TE Networks (ACTN)», RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.

[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, «YANG Data Model for Network Access Control Lists (ACLs)», RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/info/rfc8519>.

[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, «Handling Long Lines in Content of Internet-Drafts and RFCs», RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.

[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, «A YANG Data Model for MPLS Base», RFC 8960, DOI 10.17487/RFC8960, December 2020, <https://www.rfc-editor.org/info/rfc8960>.

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

[TE-SERVICE-MAPPING] Lee, Y., Ed., Dhody, D., Ed., Fioccola, G., Wu, Q., Ed., Ceccarelli, D., and J. Tantsura, «Traffic Engineering (TE) and Service Mapping YANG Data Model», Work in Progress, Internet-Draft, draft-ietf-teas-te-service-mapping-yang-11, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-11>.

[VPN+-FRAMEWORK] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, «A Framework for Enhanced Virtual Private Network (VPN+)», Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-11, 19 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-11>.

[YANG-SAPS] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, «A YANG Network Model for Service Attachment Points (SAPs)», Work in Progress, Internet-Draft, draft-ietf-opsawg-sap-09, 28 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sap-09>.

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

В этом приложении даны некоторые примеры, иллюстрирующие применение L2NM. В последующих параграфах представлено лишь содержимое тел сообщений в нотации JSON [RFC7951]. Для длинных строк применяются переносы, определённые в [RFC8792].

A.1. VPLS на основе BGP

В этом приложении дан пример, иллюстрирующий применение L2NM для управления VPLS на основе BGP. Рассмотрен образец службы VPLS, предоставляемой в архитектуре, показанной на рисунке 23. В соответствии с [RFC4761] предполагается, полная связность (full mesh) между всеми PE. Детали связей не рассматриваются.

                      +-----+   +--------------+   +-----+
         +----+       | PE1 |===|              |===| PE3 |       +----+
         | CE1+-------+     |   |              |   |     +-------+ CE3|
         +----+       +-----+   |              |   +-----+       +----+
                                |     Ядро     |
         +----+       +-----+   |              |   +-----+       +----+
         |CE2 +-------+     |   |              |   |     +-------+ CE4|
         +----+       | PE2 |===|              |===| PE4 |       +----+
                      +-----+   +--------------+   +-----+

Рисунок 23. Пример VPLS.

На рисунке 24 приведён пример тела сообщения для настройки экземпляра VPLS с применением L2NM и протокола BGP для автоматического обнаружения и сигнализации. Для signaling-type задано значение vpn-common:bgp-signaling’.

Здесь и далее символ \ в конце строки указывает перенос на другую строку в соответствии с RFC 8792.

   {
     "ietf-l2vpn-ntw:l2vpn-ntw": {
       "vpn-services": {
         "vpn-service": [
           {
             "vpn-id": "vpls7714825356",
             "vpn-description": "Sample BGP-based VPLS",
             "customer-name": "customer-7714825356",
             "vpn-type": "ietf-vpn-common:vpls",
             "bgp-ad-enabled": true,
             "signaling-type": "ietf-vpn-common:bgp-signaling",
             "global-parameters-profiles": {
               "global-parameters-profile": [
                 {
                   "profile-id": "simple-profile",
                   "local-autonomous-system": 65535,
                   "svc-mtu": 1518,
                   "rd-suffix": 1,
                   "vpn-target": [
                     {
                       "id": 1,
                       "route-targets": [
                         {
                           "route-target": "0:65535:1"
                         }
                       ],
                       "route-target-type": "both"
                     }
                   ]
                 }
               ]
             },
             "vpn-nodes": {
               "vpn-node": [
                 {
                   "vpn-node-id": "pe1",
                   "ne-id": "198.51.100.1",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": "1"
                   },
                   "signaling-option": {
                     "pw-encapsulation-type": "iana-bgp-l2-encaps:\
                      ethernet-tagged-mode",
                     "vpls-instance": {
                       "vpls-edge-id": 1,
                       "vpls-edge-id-range": 100
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE1",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         }
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe2",
                   "ne-id": "198.51.100.2",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": "1"
                   },
                   "signaling-option": {
                     "pw-encapsulation-type": "iana-bgp-l2-encaps:\
                      ethernet-tagged-mode",
                     "vpls-instance": {
                       "vpls-edge-id": 2,
                       "vpls-edge-id-range": 100
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE2",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         }
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe3",
                   "ne-id": "198.51.100.3",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": "1"
                   },
                   "signaling-option": {
                     "pw-encapsulation-type": "iana-bgp-l2-encaps:\
                      ethernet-tagged-mode",
                     "vpls-instance": {
                       "vpls-edge-id": 3,
                       "vpls-edge-id-range": 100
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE3",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         }
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe4",
                   "ne-id": "198.51.100.4",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": "1"
                   },
                   "signaling-option": {
                     "pw-encapsulation-type": "iana-bgp-l2-encaps:\
                      ethernet-tagged-mode",
                     "vpls-instance": {
                       "vpls-edge-id": 4,
                       "vpls-edge-id-range": 100
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE4",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         }
                       }
                     ]
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   }

Рисунок 24. Пример тела сообщения L2NM для настройки VPLS на основе BGP.

A.2. VPWS на основе BGP с сигнализацией LDP

Рассмотрим архитектуру, показанную на рисунке 25, для организации VPWS между CE1 и CE2 с использованием BGP для автоматического обнаружения и LDP для сигнализации.

                      +-----+   +--------------+   +-----+
         +----+       | PE1 |===|              |===| PE2 |       +----+
         | CE1+-------+     |   |     Ядро     |   |     +-------+ CE2|
         +----+       +-----+   +--------------+   +-----+       +----+
               Сайт 1                                      Сайт 2

Рисунок 25. Пример VPWS.

   {
     "ietf-l2vpn-ntw:l2vpn-ntw": {
       "vpn-services": {
         "vpn-service": [
           {
             "vpn-id": "vpws12345",
             "vpn-description": "Sample VPWS",
             "customer-name": "customer-12345",
             "vpn-type": "ietf-vpn-common:vpws",
             "bgp-ad-enabled": true,
             "signaling-type": "ietf-vpn-common:ldp-signaling",
             "global-parameters-profiles": {
               "global-parameters-profile": [
                 {
                   "profile-id": "simple-profile",
                   "local-autonomous-system": 65550,
                   "rd-auto": {
                     "auto": [
                       null
                     ]
                   },
                   "vpn-target": [
                     {
                       "id": 1,
                       "route-targets": [
                         {
                           "route-target": "0:65535:1"
                         }
                       ],
                       "route-target-type": "both"
                     }
                   ]
                 }
               ]
             },
             "vpn-nodes": {
               "vpn-node": [
                 {
                   "vpn-node-id": "pe1",
                   "ne-id": "2001:db8:100::1",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": "587"
                   },
                   "signaling-option": {
                     "advertise-mtu": true,
                     "ldp-or-l2tp": {
                       "saii": 1,
                       "remote-targets": [
                         {
                           "taii": 2
                         }
                       ],
                       "t-ldp-pw-type": "ethernet"
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE1",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         }
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe2",
                   "ne-id": "2001:db8:200::1",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "bgp-auto-discovery": {
                     "vpn-id": "587"
                   },
                   "signaling-option": {
                     "advertise-mtu": true,
                     "ldp-or-l2tp": {
                       "saii": 2,
                       "remote-targets": [
                         {
                           "taii": 1
                         }
                       ],
                       "t-ldp-pw-type": "ethernet"
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "5/1/1.1",
                         "interface-id": "5/1/1",
                         "description": "Interface to CE2",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         }
                       }
                     ]
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   }

Рисунок 26. Пример тела сообщения L2NM для настройки VPWS на основе BGP с сигнализацией LDP.

A.3. VPLS на основе LDP

Здесь приведён пример, иллюстрирующий использование L2NM для управления VPLS с сигнализацией LDP (Рисунок 27). Соединение между CE и PE организовано напрямую с использованием инкапсуляции Dot1q [IEEE802.1Q].

                     +----------  VPLS "1543" ----------+

                     +-----+   +--------------+   +-----+
         +----+      | PE1 |===|              |===| PE2 |       +----+
         | CE1 +-----+"450"|   |     Ядро     |   |"451"+-------+ CE2|
         +----+      +-----+   |     MPLS     |   +-----+       +----+
                               |              |
                               +--------------+

Рисунок 27. Пример топологии VPLS.

На рисунке 28 показано, как L2NM применяется для указания PE1 и PE2 использования сессии LDP между ними для организации VPLS «1543» между сторонами. Для этого создаётся 1 служба VPN, а также два узла VPN с соответствующими идентификаторами доступа в сеть VPN.

   {
     "ietf-l2vpn-ntw:l2vpn-ntw": {
       "vpn-services": {
         "vpn-service": [
           {
             "vpn-id": "450",
             "vpn-name": "CORPO-EXAMPLE",
             "vpn-description": "SEDE_CENTRO_450",
             "customer-name": "EXAMPLE",
             "vpn-type": "ietf-vpn-common:vpls",
             "vpn-service-topology": "ietf-vpn-common:hub-spoke",
             "bgp-ad-enabled": false,
             "signaling-type": "ietf-vpn-common:ldp-signaling",
             "global-parameters-profiles": {
               "global-parameters-profile": [
                 {
                   "profile-id": "simple-profile",
                   "ce-vlan-preservation": true,
                   "ce-vlan-cos-preservation": true
                 }
               ]
             },
             "vpn-nodes": {
               "vpn-node": [
                 {
                   "vpn-node-id": "450",
                   "description": "SEDE_CENTRO_450",
                   "ne-id": "2001:db8:5::1",
                   "role": "ietf-vpn-common:hub-role",
                   "status": {
                     "admin-status": {
                       "status": "ietf-vpn-common:admin-up"
                     }
                   },
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "signaling-option": {
                     "ldp-or-l2tp": {
                       "t-ldp-pw-type": "vpls-type",
                       "pw-peer-list": [
                         {
                           "peer-addr": "2001:db8:50::1",
                           "vc-id": "1543"
                         }
                       ]
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "4508671287",
                         "description": "VPN_450_SNA",
                         "interface-id": "gigabithethernet0/0/1",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "l2-termination-point": "550",
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "tag-type": "ietf-vpn-common:c-vlan",
                               "cvlan-id": 550
                             }
                           }
                         },
                         "service": {
                           "mtu": 1550,
                           "svc-pe-to-ce-bandwidth": {
                             "pe-to-ce-bandwidth": [
                               {
                                 "bw-type": "ietf-vpn-common:\
                                  bw-per-port",
                                 "cir": "20480000"
                               }
                             ]
                           },
                           "svc-ce-to-pe-bandwidth": {
                             "ce-to-pe-bandwidth": [
                               {
                                 "bw-type": "ietf-vpn-common:\
                                  bw-per-port",
                                 "cir": "20480000"
                               }
                             ]
                           },
                           "qos": {
                             "qos-profile": {
                               "qos-profile": [
                                 {
                                   "profile": "QoS_Profile_A",
                                   "direction": "ietf-vpn-common:both"
                                 }
                               ]
                             }
                           }
                         }
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "451",
                   "description": "SEDE_CHAPINERO_451",
                   "ne-id": "2001:db8:50::1",
                   "role": "ietf-vpn-common:spoke-role",
                   "status": {
                     "admin-status": {
                       "status": "ietf-vpn-common:admin-up"
                     }
                   },
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "signaling-option": {
                     "ldp-or-l2tp": {
                       "t-ldp-pw-type": "vpls-type",
                       "pw-peer-list": [
                         {
                           "peer-addr": "2001:db8:5::1",
                           "vc-id": "1543"
                         }
                       ]
                     }
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "4508671288",
                         "description": "VPN_450_SNA",
                         "interface-id": "gigabithethernet0/0/1",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "l2-termination-point": "550",
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "tag-type": "ietf-vpn-common:c-vlan",
                               "cvlan-id": 550
                             }
                           }
                         },
                         "service": {
                           "mtu": 1550,
                           "svc-pe-to-ce-bandwidth": {
                             "pe-to-ce-bandwidth": [
                               {
                                 "bw-type": "ietf-vpn-common:\
                                  bw-per-port",
                                 "cir": "20480000"
                               }
                             ]
                           },
                           "svc-ce-to-pe-bandwidth": {
                             "ce-to-pe-bandwidth": [
                               {
                                 "bw-type": "ietf-vpn-common:\
                                  bw-per-port",
                                 "cir": "20480000"
                               }
                             ]
                           },
                           "qos": {
                             "qos-profile": {
                               "qos-profile": [
                                 {
                                   "profile": "QoS_Profile_A",
                                   "direction": "ietf-vpn-common:both"
                                 }
                               ]
                             }
                           }
                         }
                       }
                     ]
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   }

Рисунок 28. Пример тела сообщения L2NM для настройки VPLS на основе LDP.

A.4. Экземпляр сервиса VPWS-EVPN

На рисунке 29 дан пример архитектуры для предоставления услуги VPWS-EVPN между CE1 и CE2. Оба CE являются многодомными. Сессии BGP поддерживаются между PE в соответствии с [RFC8214]. В экземпляре EVPN применяется режим избыточности All-Active (активны все).

                      |<-------- Экземпляр EVPN -------->|
                      |                                  |
                ESI1  V                                  V  ESI2
                |     +-----+   +--------------+   +-----+  |
         +----+ |     | PE1 |===|              |===| PE3 |  |    +----+
         |    +-------+     |   |              |   |     +-------+    |
         |    | |     +-----+   |              |   +-----+  |    |    |
         | CE1| |               |     Ядро     |            |    |CE2 |
         |    | |     +-----+   |              |   +-----+  |    |    |
         |    +-------+     |   |              |   |     +-------+    |
         +----+ |     | PE2 |===|              |===| PE4 |  |    +----+
              ^ |     +-----+   +--------------+   +-----+  |    ^
              | ESI1                                        ESI2 |
              |<------------ Эмулированная услуга -------------->|

Рисунок 29. Пример VPWS-EVPN.

Предположим сначала, что создаётся сегмент ES (Рисунок 30).

   {
     "ietf-ethernet-segment:ethernet-segments": {
       "ethernet-segment": [
         {
           "name": "esi1",
           "ethernet-segment-identifier": "00:11:11:11:11:11:11:\
            11:11:11",
           "esi-redundancy-mode": "all-active"
         },
         {
           "name": "esi2",
           "ethernet-segment-identifier": "00:22:22:22:22:22:22:\
            22:22:22",
           "esi-redundancy-mode": "all-active"
         }
       ]
     }
   }

Рисунок 30. Пример тела сообщения L2NM для настройки сегмента Ethernet.

На рисунке 31 показана упрощённая конфигурация для иллюстрации применения L2NM при настройке VPWS-EVPN.

   {
     "ietf-l2vpn-ntw:l2vpn-ntw": {
       "vpn-services": {
         "vpn-service": [
           {
             "vpn-id": "vpws15432855",
             "vpn-description": "Sample VPWS-EVPN",
             "customer-name": "customer_15432855",
             "vpn-type": "ietf-vpn-common:vpws-evpn",
             "bgp-ad-enabled": true,
             "signaling-type": "ietf-vpn-common:bgp-signaling",
             "global-parameters-profiles": {
               "global-parameters-profile": [
                 {
                   "profile-id": "simple-profile",
                   "local-autonomous-system": 65535,
                   "rd-suffix": 1,
                   "vpn-target": [
                     {
                       "id": 1,
                       "route-targets": [
                         {
                           "route-target": "0:65535:1"
                         }
                       ],
                       "route-target-type": "both"
                     }
                   ]
                 }
               ]
             },
             "vpn-nodes": {
               "vpn-node": [
                 {
                   "vpn-node-id": "pe1",
                   "ne-id": "198.51.100.1",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE1",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         },
                         "vpws-service-instance": {
                           "local-vpws-service-instance": 1111,
                           "remote-vpws-service-instance": 1112
                         },
                         "group": [
                           {
                             "group-id": "gr1",
                             "ethernet-segment-identifier": "esi1"
                           }
                         ]
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe2",
                   "ne-id": "198.51.100.2",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE1",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         },
                         "vpws-service-instance": {
                           "local-vpws-service-instance": 1111,
                           "remote-vpws-service-instance": 1112
                         },
                         "group": [
                           {
                             "group-id": "gr1",
                             "ethernet-segment-identifier": "esi1"
                           }
                         ]
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe3",
                   "ne-id": "198.51.100.3",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE2",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         },
                         "vpws-service-instance": {
                           "local-vpws-service-instance": 1112,
                           "remote-vpws-service-instance": 1111
                         },
                         "group": [
                           {
                             "group-id": "gr1",
                             "ethernet-segment-identifier": "esi2"
                           }
                         ]
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe4",
                   "ne-id": "198.51.100.4",
                   "active-global-parameters-profiles": {
                     "global-parameters-profile": [
                       {
                         "profile-id": "simple-profile"
                       }
                     ]
                   },
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE2",
                         "active-vpn-node-profile": "simple-profile",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "encapsulation": {
                             "encap-type": "ietf-vpn-common:dot1q",
                             "dot1q": {
                               "cvlan-id": 1
                             }
                           }
                         },
                         "vpws-service-instance": {
                           "local-vpws-service-instance": 1112,
                           "remote-vpws-service-instance": 1111
                         },
                         "group": [
                           {
                             "group-id": "gr1",
                             "ethernet-segment-identifier": "esi2"
                           }
                         ]
                       }
                     ]
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   }

Рисунок 31. Пример тела сообщения L2NM для настройки экземпляра VPWS-EVPN.

A.5. Автоматическое назначение ESI

Здесь приведён пример, иллюстрирующий использование L2NM для управления автоматическим назначением ESI. Услуга предоставляется с использованием архитектуры, показанной на рисунке 32.

              ES
              |     +-----+      +--------------+   +-----+
       +----+ |     | PE1 |======|              |===| PE3 |       +----+
       |    +-------+     |      |              |   |     +-------+ CE3|
       |    | |     +-----+      |              |   +-----+       +----+
       | CE1| |                  |     Core     |
       |    | |     +-----+      |              |   +-----+       +----+
       |    +-------+     |      |              |   |     +-------+ CE2|
       +----+ |     | PE2 |======|              |===| PE4 |       +----+
              |     +-----+      +--------------+   +-----+
            LACP

Рисунок 32. Пример автоматического назначения ESI.

На рисунках 33 и 34 показано применение L2NM для указания PE1 и PE2 автоматически назначать ESI, указывающий ES, применяемый с CE1. Предполагается, что протокол LACP включён и применяется тип 1 (T=0x01), как указано в разделе 5 [RFC7432]. Пример не включает деталей настройки службы EVPN и сосредоточен на управлении ESI.

   {
     "ietf-ethernet-segment:ethernet-segments": {
       "ethernet-segment": [
         {
           "name": "esi1",
           "esi-type": "esi-type-1-lacp",
           "esi-redundancy-mode": "all-active"
         }
       ]
     }
   }

Рисунок 33. Пример тела сообщения L2NM для автоматического назначения ESI.

   {
     "ietf-l2vpn-ntw:l2vpn-ntw": {
       "ietf-l2vpn-ntw:vpn-services": {
         "vpn-service": [
           {
             "vpn-id": "auto-esi-lacp",
             "vpn-description": "Sample to illustrate auto-ESI",
             "vpn-type": "ietf-vpn-common:vpws-evpn",
             "vpn-nodes": {
               "vpn-node": [
                 {
                   "vpn-node-id": "pe1",
                   "ne-id": "198.51.100.1",
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "1/1/1.1",
                         "interface-id": "1/1/1",
                         "description": "Interface to CE1",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "lag-interface": {
                             "lag-interface-id": "1",
                             "lacp": {
                               "lacp-state": true,
                               "system-id": "11:00:11:00:11:11",
                               "admin-key": 154
                             }
                           }
                         },
                         "group": [
                           {
                             "group-id": "gr1",
                             "ethernet-segment-identifier": "esi1"
                           }
                         ]
                       }
                     ]
                   }
                 },
                 {
                   "vpn-node-id": "pe2",
                   "ne-id": "198.51.100.2",
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "2/2/2.5",
                         "interface-id": "2/2/2",
                         "description": "Interface to CE1",
                         "status": {
                           "admin-status": {
                             "status": "ietf-vpn-common:admin-up"
                           }
                         },
                         "connection": {
                           "lag-interface": {
                             "lag-interface-id": "1",
                             "lacp": {
                               "lacp-state": true,
                               "system-id": "11:00:11:00:11:11",
                               "admin-key": 154
                             }
                           }
                         },
                         "group": [
                           {
                             "group-id": "gr1",
                             "ethernet-segment-identifier": "esi1"
                           }
                         ]
                       }
                     ]
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   }

Рисунок 34. Пример тела сообщения L2NM для автоматического назначения ESI.

Автоматически заданный идентификатор ESI можно найти с помощью, например, метода GET в RESTCONF. Заданное значение будет возвращено в узле данных esi-auto, как показано на рисунке 35.

   {
     "ietf-ethernet-segment:ethernet-segments": {
       "ethernet-segment": [
         {
           "name": "esi1",
           "ethernet-segment-identifier": "esi-type-1-lacp",
           "esi-auto": {
             "auto-ethernet-segment-identifier": "01:11:00:11:00:11:\
              11:9a:00:00"
           },
           "esi-redundancy-mode": "all-active"
         }
       ]
     }
   }

Рисунок 35. Пример тела сообщения L2NM для извлечения назначенного ESI.

A.6. Предпочтения доступа в VPN

В примере на рисунке 36 служба L2VPN включает два доступа в сеть VPN к сайтам одного клиента.

                +--------------+
                |VPN-NODE      |
                |           +--+-------+
                |           | NET-ACC-1| Основной
                |           |          +------------------
                |           +--+-------+
                |              |
                |           +--+-------+
                |           | NET-ACC-2| Вторичный
                |           |          +------------------
                |           +--+-------+
                |              |
                +--------------+

Рисунок 36. Пример множественного доступа в VPN.

Чтобы указать один из вариантов доступа в VPN как основной (primary), а другой — как вторичный (secondary), применяется конфигурация L2NM, фрагмент которой приведён на рисунке 37. Здесь оба варианта доступа привязаны к одному group-id, а узел precedence устанавливается в соответствии с ролью (основной или вторичный).

   {
     "ietf-l2vpn-ntw:l2vpn-ntw": {
       "vpn-services": {
         "vpn-service": [
           {
             "vpn-id": "Sample-Service",
             "vpn-nodes": {
               "vpn-node": [
                 {
                   "vpn-node-id": "VPN-NODE",
                   "vpn-network-accesses": {
                     "vpn-network-access": [
                       {
                         "id": "NET-ACC-1",
                         "connection": {
                           "bearer-reference": "br1"
                         },
                         "group": [
                           {
                             "group-id": "1",
                             "precedence": "primary"
                           }
                         ]
                       },
                       {
                         "id": "NET-ACC-2",
                         "connection": {
                           "bearer-reference": "br2"
                         },
                         "group": [
                           {
                             "group-id": "1",
                             "precedence": "secondary"
                           }
                         ]
                       }
                     ]
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   }

Рисунок 37. Пример тела сообщения для уровней приоритета доступа в сеть VPN.

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

В ходе обсуждения этой работы полезные комментарии, предложения и рецензии представили Sergio Belotti, Italo Busi, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti Morgenstern, Tom Petch, Erez Segev. Большое спасибо им.

Zhang Guiyu, Luay Jalil, Daniel King, Jichun Ma внесли свой вклад в предварительные варианты документа.

Спасибо Yingzhen Qu и Himanshu Shah за рецензии rtgdir, Ladislav Lhotka за рецензию yangdoctors, Chris Lonvick за рецензию secdir, Dale Worley за рецензию gen-art. Особая благодарность Adrian Farrel за тщательный обзор Shepherd.

Спасибо Robert Wilton за тщательный обзор AD и предложения по улучшению документа.

Спасибо Roman Danyliw, Lars Eggert, Erik Kline, Francesca Palombini, Zaheduzzaman Sarker, Éric Vyncke за рецензию IESG.

Модуль YANG для сегментов Ethernet был исходно создан в контексте модуля устройства EVPN [EVPN-YANG].

Эта работа частично поддерживалась Европейской Комиссией в рамках проекта Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow), грант № 101015857.

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

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      W. Eddy, Ed.
STD: 7                                                       MTI Systems
Request for Comments: 9293                                   August 2022
Obsoletes: 793, 879, 2873, 6093, 6429, 6528,                            
           6691                                                         
Updates: 1011, 1122, 5961                                               
Category: Standards Track                                               
ISSN: 2070-1721

Transmission Control Protocol (TCP)

Протокол управления передачей (TCP)

PDF

Аннотация

Этот документ задаёт протокол управления передачей (Transmission Control Protocol или TCP). TCP является важным протоколом транспортного уровня в стеке протоколов Internet и непрерывно развивался в течение десятилетий использования и роста сети Internet. За это время было внесено много изменений в протокол TCP, заданный RFC 793, хотя они были документированы лишь частично. В этом документе такие изменения собраны и объединены со спецификацией RFC 793. Документ отменяет RFC 793, а также RFC 879, RFC 2873, RFC 6093, RFC 6429, RFC 6528 и RFC 6691, которые частично обновляли RFC 793. Документ обновляет RFC 1011 и RFC 1122 и его следует считать заменой тем частям указанных документов, которые относятся к требованиям TCP. Документ также обновляет RFC 5961, добавляя небольшое разъяснение в обработку сброса в состоянии SYN-RECEIVED. Биты управления в заголовке TCP из RFC 793 также обновлены на основе RFC 3168.

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

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

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Назначение и область действия

В 1981 году был выпущен документ RFC 793 [16], описывающий протокол TCP и отменяющий опубликованные ранее спецификации TCP. С тех порт TCP получил широкое распространение и применяется в качестве транспортного протокола во множестве приложений Internet.

В течение нескольких десятилетий RFC 793 и ряд других документов служили основной спецификацией для TCP [49]. За это время в RFC 793 был обнаружен ряд ошибок, а также были обнаружены и устранены недостатки в защите, производительности и других аспектах. Со временем число документов с изменениями значительно выросло, но они никогда не объединялись в комплексное обновление базовой спецификации. Цель этого документа состоит в объединении всех изменений IETF Standards Track и других разъяснений к базовой функциональной спецификации TCP (RFC 793) в одну обновлённую версию спецификации.

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

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

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

2. Введение

В RFC 793 рассмотрены цели проектирования TCP и даны примеры работы, включая организацию и завершение соединений, повтор передачи пакетов и восстановление потерь.

Этот документ описывает базовую функциональность, ожидаемую от современных реализаций TCP, и заменяет спецификацию протокола в RFC 793. Здесь не повторяются и не обновляются введение и концепции из разделов 1 и 2 в RFC 793. Даны ссылки на другие документы, содержащие разъяснения теории работы, обоснования и обсуждение проектных решений. Данные документ сосредоточен исключительно на нормативном поведении протокола.

В работе [49] представлено детальное руководство по RFC, определяющим TCP и описывающим различные важные алгоритмы. Этот документ содержит разделы, посвящённые настоятельно рекомендуемым усовершенствованиям,повышающим производительность и улучшающим другие аспекты TCP сверх описанных в этом документе базовых операций. Например, реализация контроля перегрузок (такая как [8]) является требованием TCP, но это сложная тема сама по себе и не рассматривается подробно в этом документе, поскольку имеется много вариантов и возможностей, которые не влияют на базовую совместимость. Точно так же большинство современных реализаций TCP включает высокопроизводительные расширения из [47], но они не являются обязательными и не рассматриваются в этом документе. Вопросы работы TCP по нескольким путям также рассматриваются отдельно [59].

Список отличий от RFC 793 приведён в разделе 5. Отличия от RFC 793.

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

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

Каждое применение ключевых слов RFC 2119 в документе помечено ссылкой на Приложение B. Сводка требований TCP. Предложения с ключевым словом MUST содержат метку MUST-X, где X указывает числовой идентификатор требования в Приложении B. Аналогично помечаются и требования уровней SHOULD, MAY, RECOMMENDED. Требования уровня SHOULD NOT и MUST NOT помечены как SHOULD и MUST.

2.2. Основные концепции TCP

TCP обеспечивает приложениям надёжное упорядоченное обслеживание потоков байтов. Потоки байтов приложений доставляются через сеть в сегментах TCP, каждый из которых передаётся как дейтаграмма IP (Internet Protocol).

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

TCP поддерживает индивидуальную (unicast) доставку данных. Имеются anycast-приложения, способные применять TCP без изменений, хотя это связано с риском нестабильности при смене поведения пересылки на нижелижащих уровнях [46].

Протокол TCP ориентирован на (прямые) соединения, хотя, по сути, не включает возможность проверки их живучести.

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

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

Более подробное описание свойств TCP по сравнению с другими транспортными протоколами представлено в параграфе 3.1 [52]. Дополнительное описание мотивов разработки TCP и роли протокола в стеке протоколов Internet можно найти в разделе Section 2 [16] и ранних версиях спецификации TCP.

3. Функциональная спецификация

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

Сегменты TCP передаются как дейтаграммы IP. Заголовок протокола IP содержит несколько полей, включая адреса хостов источника и получателя [1] [13]. Заголовок TCP размещается вслед за заголовками IP и содержит относящиеся к TCP сведения. Такое деление позволяет использовать на хосте протоколы, отличные от TCP. В ранних реализациях стека протоколов Internet поля заголовков IP были частью TCP.

Этот документ описывает протокол TCP, использующий заголовки TCP. Формат заголовка TCP, за которым могут следовать любые пользовательские данные, показан на рисунке 1 с использованием стиля из [66].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |       |C|E|U|A|P|R|S|F|                               |
| Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
|       |       |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           [Options]                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               :
:                             Data                              :
:                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Каждая «ячейка» на рисунке соответствует 1 биту.

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

Source Port — 16 битов

Destination Port — 16 битов

Sequence Number — 32 бита

Acknowledgment Number — 32 бита

Data Offset (DOffset) — 4 бита

Reserved (Rsrvd) — 4 бита

Control bits

CWR — 1 бит

ECE — 1 бит

URG — 1 бит

ACK — 1 бит

PSH — 1 бит

RST — 1 бит

SYN — 1 бит

FIN — 1 бит

Window — 16 битов

Checksum — 16 битов

+--------+--------+--------+--------+
|           Source Address          |
+--------+--------+--------+--------+
|         Destination Address       |
+--------+--------+--------+--------+
|  zero  |  PTCL  |    TCP Length   |
+--------+--------+--------+--------+

Source Address

Destination Address

zero

PTCL

TCP Length

Urgent Pointer — 16 битов

Options — [TCP Option]; size(Options) == (DOffset-5)*32;

1. однооктетная опция;
2. октет вида опции (option-kind), октет размера опции и фактические данные (option-data) опции.

Таблица 1. Набор обязательных опций.

Data — переменный размер

3.2. Определения конкретных опций

Набор обязательных опций TCP включает End of Option List (конец списка опций), No-Operation (нет операции) иMaximum Segment Size (максимальный размер сегмента или MSS).

Формат End of Option List Option показан ниже.

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

Kind — 1 байт; Kind == 0

Формат No-Operation Option показан ниже

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

Kind — 1 байт; Kind == 1

Формат опции Maximum Segment Size Option показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       2       |     Length    |   Maximum Segment Size (MSS)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Kind — 1 байт; Kind == 2

Length — 1 байт; Length == 4

Maximum Segment Size (MSS) — 2 байта

3.2.1. Другие опции общего назначения

В других RFC определены некоторые опции общего назначения, которые рекомендуется реализовать для повышения производительности, но они не требуются с точки зрения базовой совместимости TCP. Это опции селективных подтверждений (Selective Acknowledgment или SACK) [22] [26], временных меток (Timestamp или TS) [47], масштабирования окна (Window Scale или WS) [47].

3.2.2. Экспериментальные опции TCP

Экспериментальные опции TCP заданы в [30], а в [45] описано рекомендуемое применение этих опций.

3.3. Обзор терминологии TCP

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

3.3.1. Основные переменные состояния соединений

Перед обсуждением деталей работы реализации TCP введём некоторые термины и обозначения. Для поддержки соединения TCP нужно поддерживать состояния некоторых переменных. Предполагается, что эти переменные храняться в записи соединения, называемой блоком управления передачей (Transmission Control Block или TCB). В TCB хранятся локальные и удалённые адреса IP и номера портов, уровень защиты IP, назначение (compartment) соединения (см. Приложение A.1), указательи на пользовательские буферы приёма и передачи, указатели на очередь повтора передачи и текущий сегмент, а также некоторые переменные для порядковых номеров приёма и передачи.

Таблица 2. Переменные последовательности Send.

Таблица 3. Переменные последовательности Receive.

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

     1         2          3          4
----------|----------|----------|----------
       SND.UNA    SND.NXT    SND.UNA
                            +SND.WND

1 - старые порядковые номера, которые были подтверждены
2 - порядковые номера неподтвержденных данных
3 - порядковые номера, разрешённые для новой передачи данных
4 - будущие порядковые номера, которые ещё не разрешены

Рисунок 3. Пространство номеров передачи.

Окно передачи является частью пространства номеров, помеченной 3 на рисунке 3.

Окно приёма является частью пространства номеров, помеченной 2 на рисунке 4.

    1          2          3
----------|----------|----------
       RCV.NXT    RCV.NXT
                 +RCV.WND

1 - старые порядковые номера, которые были подтверждены
2 - порядковые номера, разрешённые для нового приёма данных
3 - будущие порядковые номера, которые ещё не разрешены

Рисунок 4. Пространство номеров приема.

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

Таблица 4. Переменные из текущего сегмента.

3.3.2. Обзор конечного автомата

В процессе своего существования соединение проходит через последовательность состояний LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT и фиктивное состояние CLOSED. Состояние CLOSED фиктивно, поскольку в нем нет TCB и, следовательно, соединения.

LISTEN

SYN-SENT

SYN-RECEIVED

ESTABLISHED

FIN-WAIT-1

FIN-WAIT-2

CLOSE-WAIT

CLOSING

LAST-ACK

TIME-WAIT

CLOSED

Соединение TCP меняет состояние по событиям, которые включают пользовательские вызовы, OPEN, SEND, RECEIVE, CLOSE, ABORT, STATUS, входящие сегменты, особенно с флагами SYN, ACK, RST, FIN и тайм-ауты.

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

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

                            +---------+ ---------\      active OPEN
                            |  CLOSED |            \    -----------
                            +---------+<---------\   \   create TCB
                              |     ^              \   \  snd SYN
                 passive OPEN |     |   CLOSE        \   \
                 ------------ |     | ----------       \   \
                  create TCB  |     | delete TCB         \   \
                              V     |                      \   \
          rcv RST (note 1)  +---------+            CLOSE    |    \
       -------------------->|  LISTEN |          ---------- |     |
      /                     +---------+          delete TCB |     |
     /           rcv SYN      |     |     SEND              |     |
    /           -----------   |     |    -------            |     V
+--------+      snd SYN,ACK  /       \   snd SYN          +--------+
|        |<-----------------           ------------------>|        |
|  SYN   |                    rcv SYN                     |  SYN   |
|  RCVD  |<-----------------------------------------------|  SENT  |
|        |                  snd SYN,ACK                   |        |
|        |------------------           -------------------|        |
+--------+   rcv ACK of SYN  \       /  rcv SYN,ACK       +--------+
   |         --------------   |     |   -----------
   |                x         |     |     snd ACK
   |                          V     V
   |  CLOSE                 +---------+
   | -------                |  ESTAB  |
   | snd FIN                +---------+
   |                 CLOSE    |     |    rcv FIN
   V                -------   |     |    -------
+---------+         snd FIN  /       \   snd ACK         +---------+
|  FIN    |<----------------          ------------------>|  CLOSE  |
| WAIT-1  |------------------                            |   WAIT  |
+---------+          rcv FIN  \                          +---------+
  | rcv ACK of FIN   -------   |                          CLOSE  |
  | --------------   snd ACK   |                         ------- |
  V        x                   V                         snd FIN V
+---------+               +---------+                    +---------+
|FINWAIT-2|               | CLOSING |                    | LAST-ACK|
+---------+               +---------+                    +---------+
  |              rcv ACK of FIN |                 rcv ACK of FIN |
  |  rcv FIN     -------------- |    Timeout=2MSL -------------- |
  |  -------            x       V    ------------        x       V
   \ snd ACK              +---------+delete TCB          +---------+
     -------------------->|TIME-WAIT|------------------->| CLOSED  |
                          +---------+                    +---------+

1. Переход из состояния SYN-RECEIVED в LISTEN при получении RST является условным по наличию принятого SYN-RECEIVED после пассивного вызова OPEN.

2. На рисунке опущен переход из FIN-WAIT-1 в TIME-WAIT, если получен сегмент FIN и локальный сегмент FIN подтверждён.

3. Сегмент RST можно передать из любого состояния с соответствующим переходом в состояние TIME-WAIT (см. обоснование в [70]). Эти переходы не показаны явно, чтобы не загромождать рисунок. Точно так же не показан переход в состояние LISTEN или CLOSED при получении RST в любом состоянии.

Рисунок 5. Диаграмма состояний соединения TCP.

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

3.4. Порядковые номера

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

Важно помнить, что пространство порядковых номеров конечно, хотя и достаточно велико — от 0 до 2³² — 1. Поскольку пространство номеров конечно, все арифметические операции с порядковыми номерами должны выполняться по модулю 2³². Эта арифметика целых чисел без знака сохраняет отношения порядковых номеров при переходе от номера 2³² — 1 к 0. В компьютерной арифметике по модулю есть некоторые тонкости, поэтому при программировании нужно осторожно сравнивать значения. Символ =< означает «меньше или равно» (по модулю 2³²).

Типовые сравнения порядковых номеров, которые должна выполнять реализация TCP, включают:

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

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

3. определение того, что входящий сегментсодержит ожидаемые номера (т. е. «перекрывется» с окном приема).

В ответ на передачу данных конечная точка TCP будет получать подтверждения, для обработки которых нужно выполнять перечисленные ниже сравнения.

SND.UNA = самый старый из неподтвержденных номеров.

SND.NXT = следующий номер для передачи.

SEG.ACK = подтверждение от принимающего партнёра TCP (следующий номер, ожидаемый им).

SEG.SEQ = первый порядковый номер в сегменте.

SEG.LEN = число октетов, занимаемых данными в сегменте (с учётом SYN и FIN).

SEG.SEQ+SEG.LEN-1 = последний порядковый номер в сегменте.

Новым подтверждением (его называют приемлемым — acceptable ack) является то, для которого выполняется условие

SND.UNA < SEG.ACK =< SND.NXT

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

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

RCV.NXT = следующий номер, ожидаемый во входящем сегменте, и является ли он левым (нижним) краем окна приёма.

RCV.NXT+RCV.WND-1 = последний номер, ожидаемый во входящем сегменте, и является ли он правым (верхним) краем окна приёма.

SEG.SEQ = первый порядковый номер во входящем сегменте.

SEG.SEQ+SEG.LEN-1 = последний порядковый номер во входящем сегменте.

Считается, что сегмент является частью допустимой последовательности приёма, если

RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

или

RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

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

На деле все немного сложнее и из-за нулевых окон и сегментов нулевого размера возникают 4 случая приемлемости входящего сегмента, указанные в таблице 5.

Таблица 5. Проверка пригодности сегментов.

0

0

 SEG.SEQ = RCV.NXT

0

>0

 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

>0

0

 Не поддерживается

>0

>0

 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 
 или
 RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

Отметим, что при нулевом размере окна приёма следует принимать лишь сегменты ACK. Это позволяет реализации TCP передавать данные и принимать подтверждения (ACK), установив нулевое окно приема. Получатель TCP должен обрабатывать поля RST и URG во всех входящих сегментах даже при нулевом размере окна приема (MUST-66).

Схема нумерации применяется также для защиты некоторой управляющей информации. Это достигается за счёт неявного включения некоторых флагов управления в пространство номеров, чтобы их можно было передать повторно и повторить без путаницы (т. е. действовать будет одна и только одна копия элемента управления). Управляющая информация не передаётся физически в пространстве сегмента данных, поэтому нужно принять правила для неявного назначения номеров элементам управления. Такая защита требуется лишь для флагов SYN и FIN, которые применяются только при создании и закрытии соединений. Для нумерации считается, что SYN присутствует перед первым октетом фактических данных в сегменте, тогда как FIN считается находящимся после последнего фактического элемента данных в сегменте с соответствующим флагом. Размер сегмента (SEG.LEN) учитывает как данные, так и занимающие пространство номеров элементы управления. При наличии SYN в переменной SEG.SEQ содержится порядковый номер SYN.

3.4.1. Выбор начального порядкового номера

Соединение определяется парой сокетов и может использоваться неоднократно. Новые экземпляры соединений называют инкарнациями соединения. В связи с этим возникает проблема — как реализация TCP идентифицирует дубликаты сегментов из предыдущих инкарнаций соединения? Эта проблема становится явной, когда соединение создаётся и завершается быстро или прерывается из-за потери памяти, а затем организуется снова. Для поддержки таких ситуаций состояние TIME-WAIT ограничивает темп повторного использования соединения, а описанный ниже выбор начального порядкового номера дополнительно защищает от неоднозначности принадлежности входящего пакета соединению.

Чтобы избежать путаницы, нужно предотвратить использование новой инкарнацией сегментов прежней инкарнации, которые все ещё могут присутствовать в сети и содержать те же порядковые номера. Нужно обеспечить гарантиюэтого даже в случаях, когда конечная точка TCP теряет все сведения об использованных номерах. При создании новых соединений применяется генератор исходного порядкового номера (initial sequence number или ISN), выбирающий новое 32-битовое значение ISN. Имеются проблемы безопасности, связанные с возможностью находящегося вне пути злоумышленника предсказать или угадать значение ISN [42].

Начальные порядковые номера TCP создаются из числовой последовательности, которая монотонно возрастает до достижения максимального значения (wrap), что обычно называют «часами». Эти часы представляют собой 32-битовый счётчик, который увеличивается не реже 1 раза приблизительно каждые 4 мксек, хотя не предполагается, что счётчик работает в реальном масштабе времени или точен и его не требуется сохранять при перезагрузке. Эти часы предназначены для того, чтобы гарантировать уникальность создаваемых ISN в течение максимального срока жизни сегмента (Maximum Segment Lifetime или MSL), который много меньше цикла счётчика, чоставляющего примерно 4,55 часа. Следует отметить, что в современных сетях с высокой скоростью передачи данных, где порядковые номера могут перекрываться в течение MSL, рекомендуется применять опцию Timestamp, описанную в параграфе 3.4.3.

Реализация TCP должна применять описанный выше тип «часов» для управления выбором начальных номеров (MUST-8) и следует генерировать эти номера на основе выражения

 ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

где M — значение 4-микросекундного таймера, F() — псевдослучайная функция (pseudorandom function или PRF) параметров идентификации соединения (localip, localport, remoteip, remoteport) и секретного ключа (secretkey) (SHLD-1).F() недопустимо рассчитывать вовне (MUST-9), иначе злоумышленник все равно сможет угадать порядковые номера по ISN, использованному в другом соединении. PRF можно реализовать как криптографических хэш конкатенации параметров соединения TCP и неких секретных данных. Выбор конкретного алгоритма хэширования и поддержка данных секретного ключа рассмотрены в разделе 3 [42].

Для каждого соединения имеется порядковый номер приёма и передачи. Исходный номер для передачи (initial send sequence number или ISS) выбирается передающим партнёром TCP, и исходный номер для приёма (initial receive sequence number или IRS) определяется в процедуре организации соединения.

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

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

1. A —> BSYN — мой порядковый номер X;
2. A <— BACK — ваш порядковый номер X;
3. A <— BSYN — мой порядковый номер Y;
4. A —> BACK — ваш порядковый номер Y.

Поскольку этапы 2 и 3 можно объединить в одно сообщение, эта процедура называется 3-этапным (three-way или three message) согласованием (handshake, 3WHS).

Согласование 3WHS требуется потому, что порядковые номера не привязаны к глобальным часам в сети и реализации TCP могут применять разные механизмы выбора ISN. Получатель первого SYN не может узнать, является ли сегмент старым, если только он не помнить последний номер, использованный в соединении (это возможно не всегда), поэтому должен запросить у отправителя проверку этого SYN. Трехэтапное согласование и преимущества схемы выбора ISN по часам рассмотрены в [69].

3.4.2. Когда нужно молчать

Существует теоретическая проблема, когда данные могут быть повреждены в результате путаницы между старыми сегментами в сети и новыми сегментами после перезагрузки хоста, если применяются те же номера портов и пространство номеров. Концепция «времени тишины» (quiet time), рассматриваемая ниже, решает эту проблему и её рассмотрение включено для ситуаций, где это уместно, хотя в большинстве современных реализаций этого не требуется. Проблема была актуальной на ранних этапах развития TCP. В современной практике Internet вероятность условия возникновения ошибок пренебрежимо мала. Причинами этого являются (a) ISS и случайное использование эфемерных портов, снижающие вероятность выбора того же номера порта и порядковых номеров после перезагрузки, (b) эффективное значение MSL в Internet снижается по мере роста скорости каналов, (c) перезагрузка зачастую длится дольше MSL.

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

3.4.3. Концепция TCP Quiet Time

Хостам, по какой-либо причине потерявшим сведения о последних переданных номерах в каждом активном (не закрытом) соединении, нужно перед отправкой какого-либо сегмента TCP выжать не менее интервала MSL согласованного в системе (сети), к которой хост относится. В последующих параграфах эта спецификация разъяснена. Разработчики TCP могут нарушать ограничение на «время тишины», но возникает риск принятия некоторых старых данных как новых или отклонения новых данных как дубликатов некоторыми получателями в системе.

Конечные точки TCP «расходуют» пространство номеров при каждом формировании сегмента и размещении его в выходной очереди передающего хоста. Алгоритм обнаружения дубликатов и упорядочения в TCP основан на однозначной привязке сегментов данных к пространству номеров так, чтобы порядковые номера не проходили весь цикл из 232 значений до того, как привязанные к номерам сегменты будут доставлены и подтверждены получателем, а все дубликаты сегментов будут «слиты» из сети. Без такого допущения два разных сегмента TCP могут получить однаковые или перекрывающиеся номера, вызывающие у получателя путаницу между старыми и новыми данными. Следует помнить, что с каждым сегментом связано множество последовательных номеров, число элементов которого совпадает с числом октетов данных и флагов SYN или FIN в сегменте.

При нормальных условиях реализация TCP отслеживает следующий порядковый номер для отправки и самый старых из ожидающих подтверждения номеров, чтобы избежать ошибочного повторного использования номера до того, как первая его передача будет подтверждена. Само по себе это не гарантирует удаления из сети старых сегментов, поэтому пространство номеров выбрано достаточно большим, чтобы снизить вероятность проблем из-за блуждающих в сети старых дубликатов. При скорости 2 Мбит/с пространство из 232 порядковых номеров расходуется за 4,5 часа. Поскольку максимальный срок жизни сегмента в сети вряд ли превысит несколько десятков секунд, это считается достаточной защитой для представимых сетей даже при росте скорости передачи данных до десятков Мбит/с. При скорости 100 Мбит/с цикл расхода номеров составляет 5,4 мнут, что намного меньше, но в пределах разумного. Сегодня доступны более высокие скорости и последствия этого описаны в конце параграфа.

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

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

Предположим, например, что соединение начинается с порядкового номера S. пусть это соединение используется мало и в конечном итоге функция начального порядкового номер (ISN(t)) принимает значение S1 последнего сегмента, переданного этой конечной точкой TCP в конкретном соединении. Предположим теперь, что в этот момент хост перезагружается и создаёт новую инкарнацию соединения. В качестве начального номера выбирается S1 = ISN(t) — последний номер, использованный в прежней инкарнации соединения! Если восстановление произошло достаточно быстро, старые дубликаты с номерами около S1 могут быть получены из сети и восприняты как новые пакеты получателем в новой инкарнации соединения.

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

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

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

В высокоскоростных системах циклы порядковых номеров будет короче, чем при мегабитных скоростях, которые учтены в описанном выше базовом устройстве TCP. При скорости 1 Гбит/с цикл занимает 34 секунды, при 10 Гбит/с — 3 секунды, а при 100 Гбит/с — лишь треть секунды. В таких скоростных системах опции TCP Timestamp и защита от перехода номеров через максимум (Protection Against Wrapped Sequences или PAWS) [47] обеспечивают требуемые возможности обнаружения и отбрасывания старых дубликатов.

3.5. Организация соединения

Процедура трехэтапного согласования (three-way handshake) служит для организации соединений. Обычно процедуру инициирует один партнёр TCP, а другой отвечает. Процедура работает и в случае одновременного инициирования обоими партнёрами. В этом случае каждый партнёр TCP получает сегмент SYN без подтверждения после отправки им своего SYN. Конечно, прибытие старого дубликата SYN может создать у получателя иллюзию одновременной организации соединения. Подобающее использование сегментов сброса (reset) может устранить неоднозначность.

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

Простейший пример 3WHS показан на рисунке 6. каждая строка на рисунке пронумерована, стрелка вправо (—>) указывает прибытие сегмента TCP от партнёра A к партнёру B, а стрелка влево (<—) прибытие сегмента в обратном направлении. Многоточия (…) указывают сегменты, остающиеся в сети (задержанные). Комментарии приведены в скобках. Состояния соединения TCP показаны после отправки или прибытия сегмента, указанного в строке. Содержимое сегментов дано в сокращённой форме с указанием номера, флагов управления и поля ACK. Другие поля, такие как окно, адреса, данные для краткости не показаны на рисунках.

    Партнёр TCP A                                        Партнёр TCP B
1.  CLOSED                                               LISTEN
2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
3.  ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED
5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

Рисунок 6. Базовое 3-этапное согласования для синхронизации соединения.

В строке 2 на рисунке 6 партнёр A начинает отправку сегмента SYN, указывающего использованием порядковых номеров начиная с 100. В строке 3 партнёр B передаёт SYN и подтверждение SYN, полученного от партнёра A. Отметим, что поле подтверждения указывает, что партнёр B ожидает порядковый номер 101, подтверждая SYN с номером 100. В строке 4 партнёр A отвечает пустым сегментом с ACK для SYN от партнёра B, а в строке 5 партнёр A передаёт данные. Отметим, что номера в строках 4 и 5 совпадают, поскольку ACK не занимает пространство порядковых номеров (если это делать, придётся подтверждать ACK).

Одновременное инициирование несколько сложнее и показано на рисунке 7. Состояния каждого из партнёров TCP проходят цикл CLOSED → SYN-SENT → SYN-RECEIVED → ESTABLISHED. Реализация TCP должна поддерживать одновременные попытки организации соединения (MUST-10).

    Партнёр TCP A                                    Партнёр TCP B
1.  CLOSED                                           CLOSED
2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...
3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT
4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED
5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6.  ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7.               ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED

Рисунок 7. Одновременная синхронизация соединения.

Отметим, что реализация TCP должна отслеживать, перешло соединение в SYN-RECEIVED в результате пассивного или активного вызова OPEN (MUST-11).

Основной причиной использования трехэтапного согласования является предотвращение путаницы из-за старых дубликатов инициирования соединений. Для этого задано специальное управляющее соединение сброса (reset). Если принимающий партнёр TCP находится в несинхронизированном состоянии (SYN-SENT, SYN-RECEIVED), он возвращается в состояние LISTEN при получении приемлемого сброса. Если же партнёр TCP находится в одном из синхронизированных состояний (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), он прерывает соединение и информирует пользователя. Это описано более подробно ниже при рассмотрении полуоткрытых (half-open) соединений.

    Партнёр TCP A                                        Партнёр TCP B
1.  CLOSED                                               LISTEN
2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               ...
3.  (duplicate) ... <SEQ=90><CTL=SYN>               --> SYN-RECEIVED
4.  SYN-SENT    <-- <SEQ=300><ACK=91><CTL=SYN,ACK>  <-- SYN-RECEIVED
5.  SYN-SENT    --> <SEQ=91><CTL=RST>               --> LISTEN
6.              ... <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
7.  ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
8.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>      --> ESTABLISHED

Рисунок 8. Восстановление при старом дубликате SYN.

Простой пример восстановления от старых дубликатов показан на рисунке 8. В строке 3 старый дубликат SYN приходит партнёру B. Тот не может сказать, что это старый дубликат и отвечает нормально (строка 4). Партнёр A обнаруживает некорректность поля ACK и возвращает RST (сброс) с полем SEQ, делающим сегмент правдоподобным. Партнёр B при получении RST возвращается в состояние LISTEN. При получении в конце концов исходного SYN (строка 6) синхронизация обрабатывается нормально. Если SYN из строки 6 приходит до RST, может происходить более сложный обмен с передачей RST в обоих направлениях.

3.5.1. Полуоткрытые соединения и другие аномалии

Организованное соединение называют полуоткрытым (half-open), если один из партнёров TCP закрыл или прервал его без ведома другого партера или стороны соединения рассинхронизированы в результате отказа или перезагрузки с потерей памяти. Такие соединения автоматически сбрасываются при попытке передачи данных в любом из направлений. Однако предполагается, что такие соединения будут необычными.

Если на сайте A соединения больше нет, попытка пользователя сайта B передать данные будет приводить к получению сайтом B управляющего сообщения reset, показывающего конечной точке сайта B наличие какой-то проблемы и ожидаемый разрыв соединения.

Предположим, что пользовательские процессы A и B взаимодействуют между собой и происходит отказ или перезагрузка с потерей памяти в реализации на стороне A. В зависимости от операционной системы, поддерживающей реализацию A, вполне вероятен некий механизм восстановления при ошибках. Когда конечная точка TCP заново активизируется, процесс A, скорей всего, запустится с начала или с точки восстановления. В результате A, вероятно, вызовет OPEN для соединения или попытается использовать для него SEND, считая соединение открытым. В последнем случае он получит сообщение об ошибке connection not open (соединение не открыто) от локальной реализации TCP A. При попытке организовать соединение реализация TCP A будет передавать сегмент с флагом SYN. Это ведёт к ситуации, показанной на рисунке 9. После перезагрузки партнёра A пользователь пытается заново организовать соединение, а партнёр B считает соединение открытым.

    Партнёр TCP A                                    Партнёр TCP B
1.  (REBOOT)                              (send 300,receive 100)
2.  CLOSED                                           ESTABLISHED
3.  SYN-SENT --> <SEQ=400><CTL=SYN>              --> (??)
4.  (!!)     <-- <SEQ=300><ACK=100><CTL=ACK>     <-- ESTABLISHED
5.  SYN-SENT --> <SEQ=100><CTL=RST>              --> (Abort!!)
6.  SYN-SENT                                         CLOSED
7.  SYN-SENT --> <SEQ=400><CTL=SYN>              -->

Рисунок 9. Обнаружение полуоткрытого соединения.

Когда SYN приходит партнёру B (строка 3), тот находится в синхронизированном состоянии, но входящий сегмент не попадает в окно и в ответ на него передаётся подтверждение, указывающее следующий ожидаемый номер (ACK 100). Партнёр A видит, что этот сегмент подтверждает данные, которых он не передавал и, будучи несинхронизированным, передаёт сбров (RST), поскольку обнаруживает полуоткрытое соединение. Партнер B прерывает соединение в строке 5. Партнёр A продолжает попытку организовать соединение, используя базовое 3-этапное согласование (Рисунок 6).

Интересный вариант возникает, когда партнёр A перезагружается, а B пытается передать данные, считая соединение синхронизированным (Рисунок 10). В этом случае данные, прибывшие партнёру A от партнёра B (строка 2) не приемлемы, поскольку соединения нет, поэтому партнёр A передаёт RST. Сегмент RST приемлем для B и тот обрабатывает его, разрывая (abort) соединение.

    Партнёр TCP A                                        Партнёр TCP B
1.  (REBOOT)                                  (send 300,receive 100)
2.  (??)    <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED
3.          --> <SEQ=100><CTL=RST>                   --> (ABORT!!)

Рисунок 10. Активная сторона вызывает обнаружение полуоткрытого соединения.

На рисунке 11 показаны партнёры TCP A и B с пассивными соединениями, ожидающими SYN. Прибытие старого дубликата (строка 2) побуждает партнёра B действовать. Он возвращает SYN-ACK (сторока 3), который вызывает у партнера A генерацию RST (ACK в строке 3 не приемлем). Партнер Peer B воспринимает сброс и возвращается в состояние LISTEN.

    Партнёр TCP A                                 Партнёр TCP B
1.  LISTEN                                        LISTEN
2.       ... <SEQ=Z><CTL=SYN>                -->  SYN-RECEIVED
3.  (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK>   <--  SYN-RECEIVED
4.       --> <SEQ=Z+1><CTL=RST>              -->  (return to LISTEN!)
5.  LISTEN                                        LISTEN

Рисунок 11. Старый дубликат SYN вызывает Reset на двух пассивных сокетах.

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

3.5.2. Генерация Reset

Пользователь или приложение TCP может инициировать сброс соединения в любой момент с помощью события reset, кроме того, такие события может генерировать сам протокол при возникновении ошибок, как указано ниже. Инициировавшей сброс стороне соединения следует перейти в состояние TIME-WAIT, поскольку это обычно помогает снизить нагрузку на загруженные серверы по причинам, описанным в [70].

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

Имеется три группы состояний, описанных ниже.

1. Если соединения не существует (CLOSED), сброс передаётся в ответ на любой входящий сегмент, за исключением reset. Таким образом, сегмент SYN не соответствующий имеющемуся соединению, отвергается.

   Если во входящем сегменте установлен флаг ACK, сброс принимает порядковый номер из поля ACK в сегменте, в иных случаях сброс имеет номер 0, а в поле ACK помещается сумма порядкового номера и размера входящего сегмента. Соединение сохраняет состояние CLOSED.

2. Если соединение находится в несинхронизированном состоянии (LISTEN, SYN-SENT, SYN-RECEIVED) и входящий сегмент подтверждает что-то ещё не отправленное (содержит неприемлемое значение ACK), имеет уровень защиты или изоляции (compartment, A.1. IP Security Compartment и Precedence) не соответствуют запрошенному для соединения уровню изоляции, передаётся сброс.

   Если во входящем сегменте установлен флаг ACK, сброс принимает порядковый номер из поля ACK в сегменте, в иных случаях сброс имеет номер 0, а в поле ACK помещается сумма порядкового номера и размера входящего сегмента. Соединение сохраняет своё состояние.

3. Если соединение находится в синхронизированном состоянии (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), на любой неприемлемый сегмент (номер за пределами окна или неприемлемый номер подтверждения) должен возвращаться пустой сегмент подтверждения (без пользовательских данных) с текущим порядковым номером передачи и подтверждением, указывающим ожидаемый следующим на приёме номер, а соединение остаётся в прежнем состоянии.

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

3.5.3. Обработка Reset

В любом состоянии, кроме SYN-SENT, все сегменты сброса (RST) проверяются по полям SEQ. Сброс действителен, если его номер попадает в окно. В состоянии SYN-SENT (RST принимается в ответ на начальный SYN) сегмент RST может быть воспринят, если поле ACK подтверждает SYN.

Получатель RST сначала проверяет сегмент, затем меняет состояние. Если получатель был в состоянии LISTEN, он игнорирует сброс. Если получатель был в состоянии SYN-RECEIVED, а ранее — в LISTEN, он возвращается в состояние LISTEN, в иных случаях — прерывает соединение и переходит в состояние CLOSED. Если получатель был в любом другом состоянии, он прерывает соединение, уведомляя пользователя, и переходит в состояние CLOSED.

Реализациям TCP следует разрешать включение данных в сегмент RST (SHLD-2). Высказаны предложение по включению в RST диагностических данных, объясняющих причину RST. Для таких данных ещё нет стандарта.

3.6. Закрытие соединения

Операция CLOSE означает: «У меня больше нет данных для передачи.» Понятие закрытия полнодуплексного соединения можно толковать по-разному, поскольку может быть не очевидно, как трактовать принимающую сторону соединения. Поэтому выбрана симплексная трактовка CLOSE. Пользователь, применяющий CLOSE, может продолжать RECEIVE, пока получателю TCP не будет сказано, что удалённый партнёр также перешёл в состояние CLOSED. Таким образом, программа может инициировать несколько SEND, за которыми следует CLOSE и после этого продолжать RECEIVE, пока не будет сигнала о невозможности RECEIVE по причине перехода удалённого партнёра в состояние CLOSED. Реализация TCP будет сигнализировать пользователю о закрытии удалённого партнёра даже при отсутствии остающихся RECEIVE, поэтому пользователь может аккуратно завершить работу на своей стороне. Реализация TCP будет гарантированно доставлять все буферы SENT до перехода в состояние CLOSED, поэтому пользователю, не ожидающему данных в ответ, достаточно лишь подождать сведений о переходе соединения в состояние CLOSED, чтобы знать о доставке всех данных удалённой точке TCP. Пользователи должны продолжать считывание соединения, пока реализация TCP не укажет, что данных больше нет.

Здесь следует рассмотреть три особых случая:

1. действие пользователя, просящего реализацию TCP закрыть (CLOSE) соединение (TCP Peer A на рисунке 12);

2. передача удалённой точкой TCP сигнала управления FIN (TCP Peer B на рисунке 12);

3. оба пользователя одновременно применяют CLOSE (Рисунок 13).

Инициатива пользователя по закрытию

В этом случае сегмент FIN может быть создан и помещён в очередь исходящих сегментов. Дальнейшие SEND от пользователя реализация TCP не воспринимает и переходит в состояние FIN-WAIT-1. В этом состоянии разрешены RECEIVE. Все прежние сегменты, включая FIN будут передаваться (повторно), пока не будут подтверждены. Когда удалённый партнёр TCP подтвердил FIN и передал свой сегмент FIN, первый партнёр TCP может подтвердить (ACK) этот сегмент FIN. Отметим, что получившая FIN конечная точка TCP будет передавать ACK но не будет передавать свой сегмент FIN, пока пользователь не закрыл соединение (CLOSED).

Получение конечной точкой TCP сегмента FIN из сети

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

Одновременное закрытие соединения пользователями

Одновременный вызов CLOSE пользователями на обеих сторонах соединения вызывает обмен сегментами FIN (Рисунок 13). Когда все сегменты, предшествующие FIN обработаны и подтверждены, каждый из партнёров TCP может подтвердить (ACK) полученный сегмент FIN. При получении ACK оба будут удалять соединение.

    Партнёр TCP A                                        Партнёр TCP B
1.  ESTABLISHED                                          ESTABLISHED
2.  (Close)
    FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT
3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT
4.                                                       (Close)
    TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK
5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED
6.  (2 MSL)
    CLOSED

Рисунок 12. Последовательность нормального закрытия.

    Партнёр TCP A                                        Партнёр TCP B
1.  ESTABLISHED                                          ESTABLISHED
2.  (Close)                                              (Close)
    FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  ... FIN-WAIT-1
                <-- <SEQ=300><ACK=100><CTL=FIN,ACK>  <--
                ... <SEQ=100><ACK=300><CTL=FIN,ACK>  -->
3.  CLOSING     --> <SEQ=101><ACK=301><CTL=ACK>      ... CLOSING
                <-- <SEQ=301><ACK=101><CTL=ACK>      <--
                ... <SEQ=101><ACK=301><CTL=ACK>      -->
4.  TIME-WAIT                                            TIME-WAIT
    (2 MSL)                                              (2 MSL)
    CLOSED                                               CLOSED

Рисунок 13. Последовательность одновременного закрытия.

Соединение TCP может разрываться двумя способами: (1) нормальная последовательность закрытия TCP с применением обмена FIN (Рисунок 12) и (2) прерывание (abort) с передачей одного или нескольких сегментов RST и немедленным отбрасыванием состояния соединения. Если локальное соединение TCP закрыто удалённой точкой с помощью передачи FIN или RST, локальное приложение должно быть проинформировано о нормальном завершении или прерывании (MUST-12).

3.6.1. Полузакрытые соединения

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

Хост может реализовать полудуплексную последовательность закрытия TCP так, что вызвавшее CLOSE приложение может читать данные из соединения (MAY-1). Если такой хост получает вызов CLOSE и в соединении ещё остаются ожидающие приёма данные или новые данные получены после вызова CLOSE, реализации TCP на этом хосте следует передать RST для индикации потери данных (SHLD-3). Это рассмотрено в параграфе 2.17 [23].

Когда соединение закрывается активно, оно должно сохранять состояние TIME-WAIT в течение 2xMSL (максимальный срок жизни сегмента) (MUST-13). Однако оно может воспринять новый сегмент SYN от удалённой точки TCP для повторного открытия соединения напрямую из состояния TIME-WAIT (MAY-2)

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

2. если SYN оказывается старым дубликатом, сохраняется состояние TIME-WAIT.

При доступности опций TCP Timestamp улучшенный алгоритм [40] повышает скорость организации соединений. Этот алгоритм сокращения TIME-WAIT, основанный на опыте (Best Current Practice), следует применять, поскольку опции Timestamp используются широко и это снижает TIME-WAIT, что важно для загруженных серверов Internet (SHLD-4).

3.7. Сегментация

Термин сегментация обозначает действия TCP, выполняемые при восприятии потока байтов от передающего приложения и пакетизации этого потока абйтов в сегменты TCP. Отдельные сегменты TCP зачастую не отображаются «один к одному» в отдельные вызовы send (или записи в сокет) из приложения. Приложения могут выполнять запись на уровне сообщений в протоколе вышележащего уровня, но TCP не гарантирует сопоставления границ передаваемых и принимаемых сегментов TCP с границами буферов чтения и записи данных пользовательского приложения. В некоторых протоколах, таких как удалённый прямой доступ к памяти (Remote Direct Memory Access или RDMA) с использованием прямого размещения данных (Direct Data Placement или DDP) и маркерного кадрирования с выравниванием PDU (Marker PDU Aligned Framing или MPA) [34], возможна оптимизация производительности при доступности контроля над сопоставлением сегментов TCP и блоков данных приложенийа MPA включает конкретный механизм обнаружения и проверки взаимосвязи между сегментами TCP и структурами данных пользовательских сообщений, но этот метод специфичен для таких приложений, как RDMA. В общем случае на размер сегментов, создаваемых реализацией TCP влияет множество целей и параметров.

Цели, ведущие к отправке больших сегментов, включают:

• снижение числа находящихся в сети пакетов;

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

• снижение издержек, связанных с заголовками TCP.

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

Цели, ведущие к снижению размера сегментов, включают:

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

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

• разрешение «общей судьбы» (fate sharing) для сегментов TCP и блоков данных нижележащего уровня (например, ниже IP для каналов с ячейками или кадрами меньше IP MTU).

Для согласования этих противоречивых целей в TCP включено несколько механизмов, таких как опция максимального размера сегмента (Maximum Segment Size или MSS), Path MTU Discovery, алгоритм Nagle и поддержка IPv6 Jumbogram, которые описаны в последующих параграфах.

3.7.1. Максимальный размер сегмента (MSS)

Конечные точки TCP должны реализовать приём и передачу опции MSS (MUST-14).

Реализациям TCP следует передавать опцию MSS в каждом сегменте SYN при MSS для приёма меньше принятого по умолчанию значения 536 для IPv4 и 1220 для IPv6 (SHLD-5) и можно передавать её всегда (MAY-3).

Если опция MSS не получена при организации соединения, реализация TCP должна предполагать принятое по умолчанию значение MSS 536 (576 — 40) для IPv4 и 1220 (1280 — 60) для IPv6 (MUST-15).

Максимальный размер передаваемого конечной точкой TCP сегмента или эффективное значение MSS для передачи (effective send MSS) должно быть меньшим из значений (MUST-16) SendMSS (отражает доступный размер буфера сборки на приёмной стороне EMTU_R [19]) и наибольшим размером передачи, разрешаемым уровнем IP (EMTU_S [19])

 Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

с учётом приведённых ниже сведений.

• SendMSS — значение MSS, полученное от удалённого хоста или принятый по умолчанию размер 536 для IPv4 и 1220 для IPv6, если опция MSS не была получена.

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

• TCPhdrsize — размер фиксированного заголовка TCP и всех опций. Это 20 в (редком) случае отсутствия опций и увеличивается при добавлении опций TCP. Отметим, что некоторые опции могут включаться не во все сегменты и при передаче каждого сегмента отправителю следует корректировать значение в Eff.snd.MSS.

• IPoptionsize — размер всех опций IPv4 или заголовков расширения IPv6, связанных с соединением TCP. Отметим, что некоторые опции и заголовки расширения могут включаться не во все сегменты и при передаче каждого сегмента отправителю следует корректировать значение в Eff.snd.MSS.

Значению MSS для передачи в опции MSS следует указывать эффективное значение MTU за вычетом фиксированных заголовков IP и TCP. При игнорировании опций IP и TCP в расчёте значения опции MSS и наличии в пакете каких-либо опций IP или TCP отправитель должен соответственно сократить размер данных TCP (см. RFC 6691 [43]).

Значение MSS для передачи в опции MSS должно быть не больше MMS_R — 20, где MMS_R — максимальный размер сообщения транспортного уровня, которое может быть принято (и собрано на уровне IP) (MUST-67). TCP получает значения MMS_R и MMS_S от уровня IP (см. базовый вызов GET_MAXSIZES в параграфе 3.4 RFC 1122). Эти значения определены на основе эквивалентов IP MTU — EMTU_R и EMTU_S [19].

При использовании TCP в ситуации с переменным размером заголовков IP или TCP отправитель должен уменьшить количество данных TCP в данном пакете на число октетов в опциях IP и TCP. С этим связана историческая путаница, рассмотренная в параграфе 3.1 RFC 6691.

3.7.2. Определение Path MTU

Реализация TCP может знать MTU подключённых напрямую каналов, но очень редко имеет сведения о MTU всех путей через сеть. Для IPv4 в RFC 1122 рекомендуется применять на уровне IP по умолчанию MTU не более 576 для адресатов, не подключённых напрямую, а для IPv6 значение составляет 1280. Использование этих фиксированных значений ограничивает производительность и эффективность соединения TCP. Взамен настоятельно рекомендуется реализовать механизм определения MTU для пути (Path MTU Discovery или PMTUD) и обнаружение MTU уровня пакетизации для пути (Packetization Layer Path MTU Discovery или PLPMTUD) в TCP, чтобы сделать сегментацию более эффективной. Оба механизма PMTUD и PLPMTUD помогают TCP выбрать размер сегментов так, чтобы избежать фрагментации в пути (IPv4) или у отправителя (IPv4 и IPv6).

PMTUD для IPv4 [2] или IPv6 [14] реализуется в сочетании TCP, IP и ICMP. Механизм основан на предотвращении фрагментации у отправителя и установке флага IPv4 DF (не фрагментировать), позволяющего предотвратить фрагментацию в пути. Механизм опирается на сообщения ICMP от маршрутизаторов в пути, передаваемые, когда сегмент слишком велик для передачи через канал. Некоторые настройки реализации TCP при использовании PMTUD описаны в RFC 2923 и позволяют решить возникающие на практике проблемы [27]. PLPMTUD [31] является стандартным (Standards Track) развитием PMTUD, смягчающим требования к поддержке ICMP на пути и повышающим производительность в случаях, когда сообщения ICMP не передаются согласованно, с сохранением передачи без фрагментации. Механизмы во всех 4 упомянутых RFC рекомендуется включать в реализации TCP.

Опция TCP MSS задаёт верхнюю границу размера пакетов, которые могут быть приняты (см. [43]). Поэтому установка соишком малого значения опции MSS может влиять на способность PMTUD и PLPMTUD найти большие значения path MTU. В RFC 1191 обсуждается последствие установки в старых реализациях TCP значения TCP MSS = 536 (соответствует IPv4 MTU в 576 байтов) для нелокальных получателей вместо вывода его из MTU подключённых интерфейсов, как это рекомендуется.

3.7.3. Интерфейсы с переменным значением MTU

Эффективное значение MTU может иногда меняться, например, при использовании переменного сжатия, такого как ROHC (RObust Header Compression) [37]. Для реализации TCP заманчиво объявить наибольшее возможное значение MSS, чтобы поддерживать наиболее эффективное использование сжатых данных. К сожалению, некоторым схемам сжатия иногда требуется передавать полные заголовки (и меньше полезных данных) при ресинхронизации состояния на компрессорах и декомпрессорах конечных точек. Если использовать наибольшее значение MTU при расчёте анонсируемого значения опции MSS, повторная передача TCP может помещать ресинхронизации компрессора.

В результате при смене MTU на интерфейсе от пакета к пакету реализации TCP следует применять наименьшее значение MTU интерфейса при расчёте значения опции MSS (SHLD-6).

3.7.4. Алгоритм Nagle

Алгоритм Nagle описан в RFC 896 [17] и был рекомендован в RFC 1122 [19] для смягчения проблемы создания слишком большого числа мелких пакетов. Алгоритм реализован с большинстве современных баз кода TCP, иногда с теми или иными вариациями (см. A.3. Изменение алгоритма Nagle).

При наличии неподтвержденных данных (SND.NXT > SND.UNA) передающая конечная точка TCP буферизует все данные пользователя (независимо от бита PSH) пока остающиеся данные не будут подтверждены или конечная точка сможет передать полный сегмент TCP (Eff.snd.MSS байт).

Реализации TCP следует включать алгоритм Nagle для объединения коротких сегментов (SHLD-7). Однако у приложения должен быть способ отключить алгоритм Nagle на отдельном соединении (MUST-17). В любом случае отправка данных происходит с учётом ограничений, задаваемых алгоритмом замедленного старта [8].

Поскольку при взаимодействии алгоритма Nagle с отложенными подтверждениями могут возникать проблемы, некоторые реализации несколько изменяют алгоритм Nagle, например, как описано в Приложении A.3.

3.7.5. Джамбограммы IPv6

Для поддержки TCP с использованием IPv6 Jumbogram реализация должна быть способна передавать сегменты TCP размером больше 64 Кбайт, которые позволяет указать опция MSS. В RFC 2675 [24] указано, что значение MSS = 65535 байт считается бесконечным и применяется Path MTU Discovery [14] для определения фактического MSS.

Опцию Jumbo Payload не обязаны реализовать и понимать узлы IPv6, не поддерживающие подключение к каналам с MTU больше 65575 [24], а действующие требования к узлам IPv6 не включают поддержку Jumbogram [55].

3.8. Обмен данными

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

Отправитель данных сохраняет порядковый номер для следующей передачи в переменной SND.NXT, а старейший из неподтвержденных порядковых номеров — в переменной SND.UNA. Получатель данных хранит следующий ожидаемый номер в переменной RCV.NXT. Если все данные сразу же подтверждаются, значения этих 3 переменных совпадают.

Когда отправитель создает сегмент и передаёт его, он увеличивает значение SND.NXT. Получатель при приёме сегмента увеличивает RCV.NXT и передаёт подтверждение. При получении подтверждения отправителем, тот увеличивает SND.UNA. Степень различия этих переменных является мерой задержки в коммуникациях. Размер увеличения переменных определяется суммарным размером данных и флага SYN или FIN в сегменте. Отметим, что после достижения состояния ESTABLISHED все сегменты должны содержать данные подтверждения.

Пользовательский вызов CLOSE предполагает функцию выталкивания (push) (параграф 3.9.1. Интерфейс TCP — пользователь), как при флага FIN во входящем сегменте.

3.8.1. Тайм-аут повтора передачи

Из-за изменчивости сетей, образующих многосетевую (internetwork) систему и широкого спектра применения соединений TCP тайм-аут повтора передачи (retransmission timeout или RTO) должен задаваться динамически. Значение RTO должно рассчитываться по алгоритмам из [10], включая алгоритм Karn для выборки RTT (MUST-18).

В RFC 793 приведена процедура расчёта RTO на основе работы, упомянутой в IEN 177 [71]. Это было заменено алгоритмом, описанным в RFC 1122, который был обновлён в RFC 2988, а затем — в RFC 6298.

RFC 1122 говорит, что при повторной передаче пакета, идентичного исходному (это предполагает совпадение не только границ данных, но и полей заголовка), можно использовать то же поле IPv4 Identification (см. параграф 3.2.1.5 в RFC 1122) (MAY-4). Одно и то же поле IP Identification можно применять повторно в любом случае, поскольку оно имеет значение лишь при фрагментации дейтаграмм [44]. Реализациям TCP не следует полагаться на это поле заголовка и обычно даже взаимодействовать с ним. Это неразумный способ указания передачи и получения дубликатов.

3.8.2. Контроль перегрузок TCP

В RFC 2914 [5] разъяснена важность контроля перегрузок в Internet.

RFC 1122 требует реализовать алгоритмы Van Jacobson для контроля перегрузок — замедленный старт (slow start) и предотвращение перегрузки (congestion avoidance) вместе с экспоненциальной отсрочкой (backoff) в последовательных RTO для одного и того же сегмента. В RFC 2581 дано стандартизованное (IETF Standards Track) описание slow start и congestion avoidance, а также механизмов ускоренного повтора (fast retransmit) и быстрого восстановления (fast recovery). RFC 5681 содержит текущее описание этих алгоритмов и текущую спецификацию Standards Track с рекомендациями по контролю перегрузок в TCP. В RFC 6298 описана экспоненциальная отсрочка для значений RTO, включая сохранение отложенного значения, пока последующий сегмент с новыми данными не будет передан и подтверждён без повтора передачи.

Конечная точка TCP должна реализовать базовые алгоритмы контроля перегрузок slow start, congestion avoidance и экспоненциальной отсрочки RTO для предотвращения условий коллапса насыщения (MUST-19). В RFC 5681 и RFC 6298 описаны широко применяемые базовые алгоритмы (IETF Standards Track). Имеется много других подходящих алгоритмов, которые широко распространены. Многие реализации TCP поддерживают набор разных алгоритмов, которые можно настроить для применения на конечной точке. Такие дополнительные алгоритмы можно реализовать при условии их соответствия спецификациям TCP из IETF Standards Track, как описано в RFC 2914, RFC 5033 [7], RFC 8961 [15] (MAY-18).

Явное уведомление о перегрузке (Explicit Congestion Notification или ECN) было определено в RFC 3168 и является усовершенствованием IETF Standards Track, имеющим много преимуществ [51]. Конечной точке TCP следует реализовать ECN, как описано в RFC 3168 (SHLD-8).

3.8.3. Отказы соединений TCP

Чрезмерные повторы передачи одного сегмента конечной точкой TCP говорят о том или ином отказе на удалённом хосте или в пути через сеть. Этот отказ может быть краткосрочным или продолжительным. Описанные ниже процедуры должны применяться при обработке чрезмерных повторов передачи сегментов данных (MUST-20).

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

2. Когда число повторов передачи одного сегмента становится не меньше порога R1, передаётся рекомендация (см. параграф 3.3.1.4 в [19]) уровню IP для вызова диагностики «мертвого шлюза».

3. Когда число повторов передачи одного сегмента достигает порога R2 (> R1), соединение закрывается.

4. Приложение должно (MUST-21) быть способно устанавливать порог R2 для конкретного соединения. Например, интерактивное приложение может установить для R2 значение infinity (бесконечно), отдающее пользователю управления разрывом соединения.

5. Реализациям TCP следует информировать приложение о проблемах доставки (если это не отключено приложением, см. параграф 3.9.1.8. Асинхронные отчёты), по достижении порога R1 и до R2 (SHLD-9). Это позволит информировать пользователя, например, в программе удалённой регистрации в системе (login).

Значению R1 следует соответствовать по меньшей мере 3 повторам передачи при текущем значении RTO (SHLD-10). Для R2 следует устанавливать значение не менее 100 секунд (SHLD-11).

Попытка организации соединения TCP может приводить к отказу из-за чрезмерного повтора передачи сегмента SYN, получения сегмента RST или сообщения ICMP Port Unreachable. Повторы передачи SYN должны обрабатываться в общем порядке, приведённом выше для повторов, включая уведомление прикладного уровня. Однако значения R1 и R2 для SYN и сегментов данных могут различаться. В частности значение R2 для сегмента SYN должно быть достаточно большим, чтобы обеспечивать повтор передачи сегмента в течение по меньшей мере 3 минут (MUST-23). Приложение, естественно, может закрыть соединение (отказаться от попытки соединиться) раньше.

3.8.4. TCP Keep-Alive

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

Разработчики могут включать сообщения keep-alive в свои реализации TCP (MAY-5), хотя такая практика не является общепринятой. Некоторые реализации TCP, тем не менее, применяют механизм keep-alive для сохранения активности бездействующего соединения, передавая пробный сегмент, предназначенный для получения ответа от партнёра TCP. Такие сегменты обычно включают SEG.SEQ = SND.NXT-1 и могут содержать «сорные» октеты данных. Если сообщения keep-alive применяются, приложение должно быть способно включать и отключать их передачу для каждого соединения TCP (MUST-24) и по умолчанию сообщения должны быть отключены (MUST-25).

Пакеты keep-alive должны передаваться лишь при отсутствии данных для передачи и отсутствии принятых пакетов данных или подтверждений в течение заданного интервала (MUST-26), который должен быть настраиваемым (MUST-27) и по умолчанию должен составлять не менее 2 часов (MUST-28).

Очень важно помнить, что сегменты ACK без данных не передаются TCP с гарантией. Поэтому при реализации механизма keep-alive недопустимо рассматривать отсутствие отклика на конкретный тестовый пакет признаком «метвого» соединения (MUST-29).

Реализации следует передавать сегменты keep-alive без данных (SHLD-12), однако можно поддерживать настраиваемую передачу сегментов keep-alive с 1 октетом «сорных» данных (MAY-6) для совместимости с ошибочными реализациями TCP.

3.8.5. Обмен важными сведениями

Из-за различий в реализациях и взаимодействии с промежуточными устройствами новым приложениям не следует реализовать механизм TCP urgent (SHLD-13). Однако реализации TCP должны включать поддержку механизма срочности (MUST-30). Сведения об интерпретации некоторыми реализациями TCP указателя важности (срочности) приведены в RFC 6093 [39].

Цель механизма TCP urgent состоит в предоставлении передающему пользователю возможности стимулировать принимающего пользователя к восприятию неких важных (срочных) данных, а приёмной точке TCP — указать пользователю, когда все известные в данный момент важные данные будут получены им. Этот механизм позволяет указать в потоке данных точку, задающую конец важных данных. Всякий раз, когда эта точка опережает порядковый номер приёма (RCV.NXT) на принимающей стороне TCP, реализация TCP должна указать пользователю переход в режим срочности (urgent mode). Когда порядковый номер приёма «догоняет» указатель важности, реализация TCP должна указать пользователю переход в обычный режим. Если указатель важности меняется во время пребывания пользователя в режиме urgent, это обновление будет незаметно для пользователя.

Метод использует поле Urgent во всех передаваемых сегментах, а флаг URG указывает значимость этого поля и должен устанавливаться в сегментах, фактически содержащих указатель важности. Отсутствие флага говорит, что важных (срочных) данных в сегменте нет.

Для отправки важной информации пользователь должен передать хотя бы 1 октет. Если передающий пользователь указывает также выталкивание (push), это улучшает своевременность доставки важных данных целевому процессу. Поскольку указатель важности соответствует данным, записанным передающим приложением, значение указателя важности не может «отступить» в пространстве порядковых номеров, но получателям TCP следует быть устойчивыми к некорректному поведению указателя важности.

Реализации TCP должны поддерживать последовательности важных данных любого размера (MUST-31) [19].

Указатель важности должен содержать порядковый номер октета, следующего за важными данными (MUST-62).

Реализация TCP должна (MUST-32) асинхронно информировать уровень приложения о получении указателя важности (если ранее важных данных не было) или перемещении указателя важности вперёд. Реализация TCP должна (MUST-33) обеспечивать приложениям способ узнать объем остающихся в соединении важных данных или хотя бы определить остаются ли ещё важные данные для считывания [19].

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

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

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

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

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

Имеющиеся механизмы позволяют конечной точке TCP анонсировать большое окно, а затем анонсировать его уменьшение, не принимая так много данных. Так называемое «сокращение окна» (shrinking the window) настоятельно не рекомендуются. Принцип отказоустойчивости [19] диктует партнёрам TCP не сокращать окно самостоятельно, но быть готовыми в такому поведению партнёра TCP.

Получателю TCP не следует сокращать окно, т. е. сдвигать его правый край влево (SHLD-14). Однако передающий партнёр TCP должен быть готов к такому сокращению, которое может сделать размер доступного окна (usable window, см. 3.8.6.2.1. Алгоритм отправителя — когда передавать данные) отрицательным (MUST-34). Если это происходит, отправителю не следует передавать новых данных (SHLD-15), но следует обычным способом повторить передачу неподтвержденных данных из интервала SND.UNA — SND.UNA+SND.WND (SHLD-16). Отправитель может также повторить старые данные сверх SND.UNA+SND.WND (MAY-7), но не следует фиксировать тайм-аут соединения, если данные за пределами правого края окна не подтверждены (SHLD-17). Если окно сокращается до 0, реализация TCP должна проверять его стандартным способом, описанным в следующем параграфе (MUST-35).

3.8.6.1. Проверка нулевого окна

Передающий партнёр TCP должен регулярно отправлять хотя бы 1 октет новых данных (при наличии) или повторно передавать данные принимающему партнёру TCP даже при нулевом размере окна с целью зондирования (probe) окна. Эти повторы передачи важны для гарантии того, что при установке одним из партнёров TCP нулевого размера окна это будет надёжно сообщено другому партнёру. В других документах это называется зондированием нулевого окна (Zero-Window Probing или ZWP). Зондирование (предложенных) нулевых окон должно поддерживаться (MUST-36).

Реализация TCP может сохранять предлагаемое окно приёма закрытым неограниченно долго (MAY-8). Пока принимающий партнёр TCP продолжает передавать подтверждения в ответ на сегменты зондирования, передающий партнёр TCP должен позволять соединению оставаться открытым (MUST-37). Это позволяет TCP работать в таких ситуациях, как отсутствие бумаги в принтере, описанное в параграфе 4.2.2.17 [19]. Поведение зависит от концепций управления ресурсами в реализации, как указано в [41].

Когда сегмент приходит принимающему партнёру TCP с нулевым окном, тот должен передать подтверждение, показывающее следующий ожидаемый порядковый номер и текущее окно (0). Передающему хосту следует отправлять первую пробу (зонд) наличия нулевого окна, когда такое окно существует в течение тайм-аута повтора передачи (SHLD-29) (см. параграф 3.8.1. Тайм-аут повтора передачи), а интервал между пробами следует увеличивать экспоненциально (SHLD-30).

3.8.6.2. Предотвращение SWS

«Синдром глупого окна» (Silly Window Syndrome или SWS) — это устойчивая картина небольших пошаговых изменений окна, приводящая к крайне низкой производительности TCP. Алгоритмы предотвращения SWS приведены ниже для передающей и принимающей стороны. Более подробное рассмотрение проблемы приведено в RFC 1122. Отметим, что алгоритм Nagle и алгоритм предотвращения SWS у отправителя дополняют друг друга в повышении производительности. Алгоритм Nagle препятствует отправке крошечных сегментов, когда данные для передачи поступают мелкими порциями, а алгоритм предотвращения SWS препятствует отправке мелких сегментов, возникающих в результате небольшого расширения окна справа.

3.8.6.2.1. Алгоритм отправителя — когда передавать данные

Реализация TCP должна включать алгоритм предотвращения SWS у отправителя (MUST-38). Алгоритм Nagle из параграфа 3.7.4 позволяет объединять короткие сегменты.

Алгоритм предотвращения SWS у отправителя может оказаться сложнее, чем у получателя, поскольку отправитель не знает (напрямую) общее буферное пространство получателя (RCV.BUFF). Было обнаружено, что хорошо работает подход на основе расчёта отправителем значения Max(SND.WND), которое определяет максимальное окно передачи, наблюдавшееся до этого в соединении, и использовании этого значения как оценки RCV.BUFF. К сожалению это лишь оценка и получатель в любой момент может изменить RCV.BUFF. Чтобы избежать в результате тупиковой ситуации, требуется тайм-аут принудительной передачи данных, отменяющий алгоритм предотвращения SWS. На практике такой тайм-аут будет возникать редко.

Применимое окно определяется значением

U = SND.UNA + SND.WND - SND.NXT

т. е. предложенное окно меньше объёма переданных, но не подтверждённых данных. Если D — объем ещё не отправленных данных в очереди отправителя на передачу, рекомендуется приведённые ниже правила передачи:

1. если можно отправить сегмент максимального размера, т. е. min(D,U) >= Eff.snd.MSS;

2. если данные выталкиваются (push) и можно отправить все данные из очереди, т. е. [SND.NXT = SND.UNA], применяется PUSH и D <= U (выражение в скобках вносит алгоритм Nagle);

3. если можно отправить хотя бы часть Fs максимального окна передачи, т. е. [SND.NXT = SND.UNA] и min(D,U) >= Fs * Max(SND.WND);

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

Здесь Fs — часть, для которой рекомендуемое значение составляет 1/2. Тайм-ауту переопределения следует быть в интервале 0,1 — 1,0 секунда. Может оказаться удобные объединение этого таймера с таймером для нулевого окна (3.8.6.1. Проверка нулевого окна).

3.8.6.2.2. Алгоритм получателя — когда передавать обновление окна

Реализация TCP должна включать алгоритм предотвращения SWS у получателя (MUST-39). Этот алгоритм у получателя определяет, когда можно сдвинуть вправо правый край окна, это обычно называют обновлением окна. Алгоритм сочетается с алгоритмом отложенных подтверждений (параграф 3.8.6.3) для определения, когда сегмент ACK с текущим окном можно действительно передать получателю.

Задачей алгоритма у получателя является предотвращение сдвига правого края окна RCV.NXT+RCV.WND малыми шагами даже при получении данных из сети в мелких сегментах. Предположим, что буфер приёма имеет размер RCV.BUFF. В любой момент RCV.USER октетов из этого общего объёма могут быть связаны с данными, которые приняты и подтверждены, но ещё не считаны пользовательским процессом. При находящемся в покое соединении RCV.WND = RCV.BUFF и RCV.USER = 0.

Сохранение правого края окна неизменным при поступлении и подтверждении данных требует, чтобы получатель предлагал не все своё буферное пространство, т. е. получатель должен указать значение RCV.WND, сохраняющее сумму RCV.NXT+RCV.WND постоянной при увеличении RCV.NXT. Таким образом все буферное пространство RCV.BUFF обычно делится на 3 части, как показано ниже.

    |<------- RCV.BUFF ---------------->|
         1             2            3
----|---------|------------------|------|----
           RCV.NXT               ^
                           (фиксировано)
1 - RCV.USER - полученные, но ещё не подтверждённые данные;
2 - RCV.WND - пространство, анонсируемое отправителю;
3 - Reduction - доступное, но ещё не анонсированное пространство.

Предложенный алгоритм предотвращения SWS для получателя состоит в удержании фиксированной суммы RCV.NXT+RCV.WND, пока не будет выполнено условие

RCV.BUFF - RCV.USER — RCV.WND >= min(Fr * RCV.BUFF, Eff.snd.MSS)

где Fr — часть (рекомендуемое значение 1/2), а Eff.snd.MSS — эффективное значение MSS для соединения (см. параграф 3.7.1. Максимальный размер сегмента (MSS)). При выполнении неравенства устанавливается RCV.WND = RCV.BUFF-RCV.USER.

Отметим, что общий эффект этого алгоритма заключается в увеличении RCV.WND с приращением Eff.snd.MSS (для реалистичных буферов приёма Eff.snd.MSS < RCV.BUFF/2). Отметим также, что получатель должен использовать своё значение Eff.snd.MSS, предполагая, что оно такое же, как у отправителя.

3.8.6.3. Отложенные подтверждения — когда передавать сегмент ACK

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

Конечной точке TCP следует реализовать delayed ACK (SHLD-18), но подтверждения не следует задерживать чрезмерно и задержка должна быть меньше 0,5 сек (MUST-40). ACK следует генерировать не реже, чем для каждого второго полноразмерного сегмента или получения 2*RMSS новых данных (RMSS — значение MSS, заданное конечной точкой TCP, принимающей сегменты, которые будут подтверждаться, или принятое по умолчанию значение MSS) (SHLD-19). Чрезмерная задержка ACK может нарушать синхронизацию приема-передачи и алгоритмы «тактирования» пакетов. Более подробно отложенные подтверждения рассмотрены в параграфе 4.2 RFC 5681 [8], включая рекомендации по незамедлительному подтверждению сегментов с нарушением порядка доставки, сегментов после пропуска в порядковых номерах или внутри пропущенного интервала для ускорения восстановления при потерях.

Отметим, что имеется несколько современных подходов к снижению числа ACK, включая общую разгрузку приёма (generic receive offload или GRO) [72], сжатие и прореживание ACK [28].

3.9. Интерфейсы

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

3.9.1. Интерфейс TCP — пользователь

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

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

Описанные ниже пользовательские команды задают базовые функции, которые реализация TCP должна выполнять для поддержки взаимодействий между процессами. Реализации должны определять свой точный формат и могут обеспечивать комбинации или подмножества базовых функций в одном вызове. В частности, некоторые реализации могут захотеть автоматически создавать (OPEN) соединение при первом вызове пользователем SEND или RECEIVE.

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

1. общие сведения о соединении (например, прерывания, удалённое закрытие, привязка к неуказанному удалённому сокету);

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

3.9.1.1. Open

OPEN (local port, remote socket, active/passive [, timeout] [, Diffserv field] [, security/compartment] 
[, local IP address] [, options]) -> local connection name

Если флаг active/passive установлен для пассивного режима, это будет вызов LISTEN для входящих соединений. Пассивный вызов OPEN может указывать удалённый сокет полностью для восприятия конкретного соединения или не задавать его для восприятия любых соединений. Полностью заданный пассивный вызов можно сделать активным последующим исполнением SEND.

Блок управления передачей (TCB) создаётся и частично заполняется данными из параметров команды OPEN.

Каждый пассивный вызов OPEN создаёт новую запись для соединения в состоянии LISTEN или возвращает ошибку. Таким вызовам недопустимо оказывать влияние на созданные ранее записи соединений (MUST-41).

Поддерживающая одновременные соединения реализация TCP должна обеспечивать вызовы OPEN, функционально позволяющие приложению прослушивать (LISTEN) порт, связанный с локальным портом, находящимся в состоянии SYN-SENT или SYN-RECEIVED (MUST-42).

При активной команде OPEN конечная точка TCP сразу начинает процедуру синхронизации (создания) соединения.

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

Реализация TCP или какая-либо компонента операционной системы (ОС) будет проверять полномочия пользователя на создание соединений с заданным значением поля Diffserv или security/compartment. Отсутствие Diffserv или спецификации security/compartment при вызове OPEN указывает использование принятых по умолчанию значений. TCP будет считать входящие запросы пригодными только при точном соответствии сведений security/compartment заданным при вызове OPEN.

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

Локальное имя соединения реализация TCP возвращает пользователю и оно может служить в качестве краткого обозначения соединения, определяемого парой <локальный сокет, удалённый сокет>.

Необязательный параметр local IP address должен поддерживаться, чтобы можно было указать локальный адрес IP (MUST-43). Это позволяет приложениям выбирать локальный адрес IP на многодомных хостах. Пассивный вызов OPEN с параметром local IP address будет ждать запросы входящих соединений с этим адресом. Если параметр не задан, при пассивном вызове OPEN соединения будут ожидаться на всех адресах с последующей привязкой к использованному в запросе конкретному адресу.

При активном вызове OPEN заданный параметр local IP address будет использован при организации соединения. Если параметр не задан, хост будет выбирать подходящий локальный адрес IP (см. RFC 1122, параграф 3.3.4.2).

Если приложение на многодомном хосте не указывает локальный адрес IP при активном создании соединения TCP, реализация TCP должна запросить у уровня IP выбор локального адреса до отправки (первого) SYN (MUST-44). См. функцию GET_SRCADDR() в параграфе 3.4 RFC 1122.

В остальных случаях для этого соединения уже был принят или передан предыдущий сегмент и реализация TCP должна использовать локальный адрес из прежних сегментов (MUST-45).

Реализация TCP должна отвергать как ошибку локальный вызов OPEN с недействительным удаленным адресом IP (например, групповым или широковещательным) (MUST-46).

3.9.1.2. Send

SEND (local connection name, buffer address, byte count, URGENT flag [, PUSH flag] [, timeout])

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

Конечная точка TCP может реализовать флаг PUSH при вызове SEND (MAY-15). Если этот флаг не реализован, передающей точке TCP (1) недопустимо буферизовать данные на неопределённый срок (MUST-60) и (2) она должна установить бит PSH в последнем буферизованном сегменте (т. е. когда в очереди больше нет данных для передачи) (MUST-61). Далее в описании предполагается поддержка флага PUSH в вызовах SEND.

Если флаг PUSH установлен, приложение считает, что данные будут незамедлительно доставлены получателю, и в последнем сегменте TCP, созданном из буфера, будет установлен флаг PSH. Этот бит не является маркером записи и не зависит от границ сегмента. Передатчику следует при пакетизации данных исключать (collapse) последующие биты для отправки максимально возможного сегмента (SHLD-27).

Если флаг PUSH не установлен, данные могут объединяться с данными из последующих вызовов SEND для более эффективной передачи. Когда приложение делает серию вызовов SEND без установки флага PUSH, реализация TCP может агрегировать данные без их передачи (MAY-16). Отметим, что при использовании алгоритма Nagle реализации TCP могут буферизовать данные до передачи независимо от флага PUSH (см. параграф 3.7.4. Алгоритм Nagle).

Логически прикладная программа требует установки флага PUSH при вызове SEND всякий раз, когда ей нужно форсировать доставку данных, чтобы не возникало блокировки связи. Однако реализации TCP следует по возможности передавать сегменты максимального размера (SHLD-28) для повышения производительности (см. параграф 3.8.6.2.1. Алгоритм отправителя — когда передавать данные).

Новым приложениям не следует устанавливать флаг URGENT flag [39] из-за различий в реализациях и проблем с промежуточными устройствами (SHLD-13). Если флаг URGENT установлен, в сегментах, передаваемых получателю TCP будет задан указатель важности. Принимающий партнёр TCP будет сообщать о важности принимающему процессу, если данные, указатель важности задаёт, что предшествующие ему данные ещё не восприняты принимающим процессом. Целью флага URGENT служит для стимулирования получателя к обработке важных (срочных) данных при их получении. Число сигналов реализации TCP о важности данных не обязано совпадать с числом уведомлений принимающего пользователя о присутствии важных данных.

Если удалённый сокет не был задан при вызове OPEN, но соединение организовано (например, потому, что прослушиваемое соединение организовано в результате прибытия удалённого сегмента в локальный сокет), указанный буфер передаётся в подразумеваемый удалённый сокет. Пользователи, применяющие OPEN без указания удалённого сокета могут вызвать SEND без явного знания адреса этого сокета. Однако, если попытка вызвать SEND предшествует назначению удалённого сокета, возвращается ошибка. Пользователи могут определить статус соединения с помощью вызова STATUS. Некоторые реализации TCP могут уведомлять пользователя о привязке к незаданному сокету.

Если задан параметр timeout, он устанавливает текущий параметр тайм-аута для пользователя соединения.

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

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

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

3.9.1.3. Receive

RECEIVE (local connection name, buffer address, byte count) -> byte count, URGENT flag [, PUSH flag]

Эта команда выделяет приёмный буфер, связанный с указанным соединением. Если перед командой не было вызова OPEN или вызывающему процессу не разрешено использовать это соединение, возвращается ошибка.

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

Получатель TCP может передать принятый бит PSH прикладному уровню через флаг PUSH на интерфейсе (MAY-17), но это не требуется (см. разъяснения в RFC 1122, параграф 4.2.2.2). Далее в описании вызова RECEIVE предполагается поддержка передачи индикации PUSH.

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

При наличии важных (срочных) данных пользователь будет проинформирован сразу же по их прибытии через сигнал TCP — пользователь. Принимающему пользователю следует перейти в режим urgent. Если установлен флаг URGENT, это говорит о наличии дополнительных важных данных. Сброшенный флаг URGENT указывает, что этот вызов RECEIVE вернул все важные данные и пользователь может выйти из режима urgent. Отметим, что данные после указателя важности (обычные данные) не могут быть доставлены пользователю в одном буфере с предшествующими важными данными, пока пользователю чётко не указана граница.

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

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

3.9.1.4. Close

CLOSE (local connection name)

Эта команда закрывает указанное соединение. Если соединение не открыто или вызывающий процесс не имеет полномочий использовать соединение, возвращается ошибка. Закрытие соединения должно быть аккуратным в том смысле, что остающиеся вызовы SEND будут обработаны (переданы, включая повторы), насколько позволяет управление потоком данных. Таким образом, следует разрешать несколько вызовов SEND, за которыми следует CLOSE, и ожидать отправки получателю всех данных. Также нужно понимать, что пользователям следует продолжать обработку RECEIVE на закрываемых соединениях, поскольку удалённый партнёр может пытаться передать остаток своих данных. Таким образом, вызов CLOSE означает: «мне нечего больше передать», но не подразумевает: «я больше не принимаю». Может случиться так (если протокол приложения не продуман), что закрывающая сторона не способна справиться со всеми своими данными до возникновения тайм-аута. В таком случае CLOSE превращается в ABORT.

Пользователь может в любой момент вызвать CLOSE по своему усмотрению или по рекомендации (подсказке) реализации TCP (например, закрытие удалённой стороны, тайм-аут, недоступность получателя).

Поскольку для закрытия соединения требуется взаимодействие с удаленным партнёром TCP, процесс закрытия занимает некоторое время. Попытки заново открыть соединение до отклика партнёра TCP на команду CLOSE будут приводить к ошибкам.

Закрытие также предполагает функцию выталкивания (push).

3.9.1.5. Status

STATUS (local connection name) -> status data

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

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

3.9.1.6. Abort

ABORT (local connection name)

Эта команда вызывает прерывание всех ожидающих SEND и RECEIVE, удаление TCB и передачу специального сообщения RST удалённому партнёру TCP. В зависимости от реализации пользователь может получить индикацию прерывания для каждого остающегося вызова SEND и RECEIVE или просто подтверждение ABORT.

3.9.1.7. Flush

Некоторые реализации TCP включают вызов FLUSH, очищающий очередь передачи TCP от всех данных, которые были включены вызовами SEND, но остаются справа от текущего окна передачи. Т. е. из очереди удаляется как можно больше данных, но без потери синхронизации порядковых номеров. Вызовы FLUSH можно реализовать (MAY-14).

3.9.1.8. Асинхронные отчёты

Должен быть механизм информирования приложения о программных (soft) ошибках TCP (MUST-47). Обычно предполагается, что это предоставляемая приложением процедура ERROR_REPORT которую можно асинхронно вызвать с транспортного уровня

ERROR_REPORT(local connection name, reason, subreason)

Точное кодирование параметров причины (reason и subreason) здесь не задаётся, однако асинхронно сообщаемые приложению условия ошибок должны включать:

• получение сообщения ICMP об ошибке (см. параграф 3.9.2.2. Сообщения ICMP, где описана обработка каждого типа сообщений ICMP, поскольку для некоторых типов нужно отключать уведомление приложения);

• избыточные повторы передачи (см. параграф 3.8.3. Отказы соединений TCP);

• продвижение указателя важности (см. параграф 3.8.5. Обмен важными сведениями).

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

3.9.1.9. Установка поля дифференцированного обслуживания (IPv4 TOS или IPv6 Traffic Class)

Уровень приложения должен быть способен установить поле дифференцированного обслуживания (DiffServ) для передаваемых в соединение сегментов (MUST-48). Это поле включает 6 битов кода дифференцированного обслуживания (Differentiated Services Codepoint или DSCP). Это не требуется, но приложению следует поддерживать возможность изменить поле в процессе работы соединения (SHLD-21). Реализациям TCP следует передавать текущее значение поля без изменения на уровень IP при передаче сегментов в соединение (SHLD-22).

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

Реализация TCP может передавать полученное последним значение поля приложению (MAY-9).

3.9.2. Интерфейс TCP — нижележащий уровень

Конечная точка TCP вызывает модуль протокола нижележащего уровня для фактической передачи или приёма данных через сеть. Двумя стандартными версиями протокола Internet (IP), расположенного ниже TCP, в настоящее время являются IPv4 [1] и IPv6 [13].

Если нижележащим протоколом является IPv4, он обеспечивает аргументы для типа обслуживания (указывается в поле DiffServ) и времени жизни (TTL). TCP использует для этих параметров приведённые ниже установки

Diffserv

Time to Live (TTL)

RFC 793 задаёт 1 минуту (60 секунд) как константу для TTL, поскольку предполагается максимальный срок действия сегмента 2 минуты. Это было предназначено для явного запроса уничтожения сегмента, который не может быть доставлен системой internet в течение 1 минуты. RFC 1122 обновляет RFC 793 требованием настраиваемого поля TTL.

Поле Diffserv может меняться в процессе работы соединения (параграф 4.2.4.2 в RFC 1122), однако интерфейс с приложением может не поддерживать эту возможность и приложение не знает об отдельных сегментах TCP, поэтому в лучшем случае это поле можно установить лишь грубо. Это ограничение рассмотрено в RFC 7657 (параграфы 5.1, 5.3, 6) [50]. Обычно приложению не следует менять поле Diffserv в течение срока действия соединения (SHLD-23).

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

При передаче TCP принятых опций от уровня IP, реализация TCP должна игнорировать непонятные опции (MUST-50).

Реализация TCP может поддерживать опции Timestamp (MAY-10) и Record Route (MAY-11).

3.9.2.1. Source Routing

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

Приложение должно быть способно задать source route при активном создании соединения TCP (MUST-51) и этот маршрут должен быть предпочтительней source route, полученного в дейтаграмме (MUST-52).

При пассивном открытии соединения TCP и прибытии пакета с заполненной опцией IP Source Route (содержащей маршрут возврата), реализация TCP должна сохранять обратный маршрут и использовать его для всех сегментов, передаваемых в это соединение (MUST-53). Если позднее в сегменте приходит другой маршрут source route, следует использовать его для замены имеющегося (SHLD-24).

3.9.2.2. Сообщения ICMP

Реализации TCP должны реагировать на сообщения ICMP об ошибках, полученные от уровня IP, направляя их соединению, вызвавшему ошибку (MUST-54). Необходимые для демультиплексирования сведения можно получить из заголовка IP, содержащегося в сообщении ICMP. Это относится к ICMPv6 в дополнение к IPv4 ICMP.

В [35] обсуждаются конкретные сообщения ICMP и ICMPv6, поделенные на мягкие (soft) и жёсткие (hard) ошибки, которые могут вызывать разные отклики. Трактовка сообщений ICMP описана ниже.

Source Quench — притормозить источник

Мягкие ошибки

Жёсткие ошибки

Отметим, что в разделе 4 [35] описано широко распространённое поведение, при котором мягкие ошибки считаются жёсткими во время организации соединений.

3.9.2.3. Проверка адреса отправителя

RFC 1122 требует проверки адресов во входящих пакетах SYN.

Входящие сегменты SYN с недействительным адресом отправителя должны игнорироваться уровнем TCP или IP [(MUST-63)] (см. параграф 3.2.1.3).

Реализация TCP должна отбрасывать входящие сегменты SYN, направленные по групповому или широковещательному адресу [(MUST-57)].

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

3.10. Обработка событий

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

Действия конечной точки TCP можно считать откликами на события, которые можно разделить на 3 категории: вызовы пользователя, прибытие сегментов и тайм-ауты. В данном параграфе описывается работа конечной точки TCP для каждого из таких событий. Во многих случаях обработка зависит от текущего состояния. События приведены ниже.

Пользовательские вызовы

Прибытие сегментов

Тайм-ауты

Модель интерфейса TCP — пользователь подразумевает незамедлительный возврат из пользовательских вызовов и возможность отложенных откликов в виде событий или псевдо-прерываний. Далее причина отложенного отклика называется сигналом.

Отклики на ошибки указываются в документе символьными строками, например, команда пользователя для отсутствующего соединения возвращает ошибку error: connection not open.

Следует отметить, что в последующем обсуждении вся арифметимка порядковых номеров, номеров подтверждений, окна и т. п. использует модуль 2³² (размер пространства номеров), а знак =< обозначает «меньше или равно» (по модулю 2³²).

Естественным способом представления обработки входящих сегментов является сначала проверка порядкового номера (т. е. его попадание в пространство номеров окна приёма), затем сегменты обычно помещаются в очередь и обрабатываются в порядке роста номеров.

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

Если смена состояния соединения не указана, предполагается его сохранение.

3.10.1. Вызов OPEN

CLOSED (TCB не существует)

LISTEN

SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT

3.10.2. Вызов SEND

CLOSED (TCB не существует)

LISTEN

SYN-SENT, SYN-RECEIVED

ESTABLISHED, CLOSE-WAIT

FIN-WAIT-1, FIN-WAIT-2, CLOSING, LAST-ACK, TIME-WAIT

3.10.3. Вызов RECEIVE

CLOSED (TCB не существует)

LISTEN, SYN-SENT, SYN-RECEIVED

ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2

CLOSE-WAIT

CLOSING, LAST-ACK, TIME-WAIT

3.10.4. Вызов CLOSE

CLOSED (TCB не существует)

LISTEN

SYN-SENT

SYN-RECEIVED

ESTABLISHED

FIN-WAIT-1, FIN-WAIT-2

CLOSE-WAIT

CLOSING, LAST-ACK, TIME-WAIT

3.10.5. Вызов ABORT

CLOSED (TCB не существует)

LISTEN

SYN-SENT

SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT

CLOSING, LAST-ACK, TIME-WAIT

3.10.6. Вызов STATUS

CLOSED (TCB не существует)

LISTEN

SYN-SENT

SYN-RECEIVED

ESTABLISHED

FIN-WAIT-1

FIN-WAIT-2

CLOSE-WAIT

CLOSING

LAST-ACK

TIME-WAIT

3.10.7. Прибытие сегмента

3.10.7.1. Состояние CLOSED

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

Если бит ACK сброшен (0), используется порядковый номер 0 — <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>. При установленном (1) бите ACK передаётся <SEQ=SEG.ACK><CTL=RST>. Управление возвращается.

3.10.7.2. Состояние LISTEN

1. Проверка наличия бита RST.

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

2. Проверка наличия бита ACK.

   Любое подтверждение, прибывшее с состоянии LISTEN, является недействительным. В ответ следует передать подходящий сегмент сброса <SEQ=SEG.ACK><CTL=RST>. Возврат управления.

3. Проверка наличия бита SYN.

   При установленном флаге SYN проверяются установки безопасности и если security/compartment во входящем сегменте не совпадает с security/compartment в TCB передаётся сброс и управление возвращается <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>.

   Устанавливается RCV.NXT = SEG.SEQ+1, IRS = SEG.SEQ, все остальные элементы управления и данные следует поместить в очередь для последующей обработки. Следует выбрать значение ISS и передать сегмент SYN вида <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>.

   Устанавливается SND.NXT = ISS+1, SND.UNA = ISS. Состояние соединения меняется на SYN-RECEIVED. Отметим, что другие элементы управления и данные (в комбинации с SYN) будут обрабатываться в состоянии SYN-RECEIVED, но обработку SYN и ACK повторять не следует. Если вызов LISTEN был задан не полностью (удалённый сокет не указан целиком), следует заполнить не заданные поля.

4. Проверка других элементов управления и данных.

   Этого не должно происходить. Сегмент отбрасывается и возвращается управление. Любой другой сегмент с элементами управления или данными (без SYN) должен иметь поле ACK и, таким образом, будет отброшен при проверке ACK на этапе 2, если не будет отброшен на этапе 1 при проверке RST.

3.10.7.3. Состояние SYN-SENT

1. Проверка наличия бита ACK.

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

• • Если SEG.ACK =< ISS или SEG.ACK > SND.NXT, передаётся сброс (если нет флага RST, при котором сегмент отбрасывается с возвратом управления) <SEQ=SEG.ACK><CTL=RST> и сегмент отбрасывается с возвратом управления.

  • Если SND.UNA < SEG.ACK =< SND.NXT, проверяется пригодность ACK. Некоторые реализации TCP используют проверку SEG.ACK == SND.NXT (== вместо =<), но это не применимо, когда стек может передавать данные по SYN, так как партнёр TCP не может воспринять и подтвердить все данные по SYN.

2. Проверка наличия бита RST.

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

• • Возможная атака со сбросом вслепую описана в RFC 5961 [9]. Описанное в этом документе смягчение имеет описанную в нем конкретную применимость и не является заменой криптографической защиты (например, IPsec или TCP-AO). Реализации TCP с поддержкой описанного в RFC 5961 смягчения следует сначала проверить точное совпадение порядкового номера значению RCV.NXT и лишь потом выполнять действия следующего абзаца.

  • Если ACK был приемлем, пользователю передаётся error: connection reset, сегмент отбрасывается, устанавливается состояние CLOSED с удалением TCB и возвратом управления. В ином случае (нет ACK) сегмент просто отбрасывается с возвратом управления.

3. Проверяются установки безопасности.

   Если security/compartment в сегменте не совпадает с security/compartment в TCB, передаётся сброс:

• • При наличии в сегменте ACK передаётся <SEQ=SEG.ACK><CTL=RST>, в противном случае — <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>.

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

4. Проверка наличия бита SYN.

   Этого не должно происходить при корректно ACK или его отсутствии в сегменте без RST.

   Если бит SYN установлен и параметры security/compartment приемлемы, устанавливается RCV.NXT = SEG.SEQ+1, IRS = SEG.SEQ. Значению SND.UNA следует быть не меньше SEG.ACK (если это ACK) и все сегменты из очереди повторной передачи, подтверждённые таким путём, должны быть удалены.

   Если SND.UNA > ISS (SYN был подтверждён), соединение переходит в состояние ESTABLISHED, формируется и передаётся сегмент ACK <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>, в который можно включить данные и элементы управления из очереди. Некоторые реализации TCP подавляют передачу этого сегмента, когда принятый сегмент содержит данные, которые в любом случае создают подтверждение на последующих этапах обработки. Если в сегменте есть другие элементы управления или данные, обработка продолжается с п. 6 в параграфе 3.10.7.4, где проверяется бит URG. В ином случае управление возвращается.

   В противном случае устанавливается состояние SYN-RECEIVED, формируется и передаётся сегмент SYN,ACK <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>. Устанавливаются переменные

   SND.WND <- SEG.WND
   SND.WL1 <- SEG.SEQ
   SND.WL2 <- SEG.ACK

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

   Отметим допустимость передачи и приёма данных приложения в сегментах SYN, как отмечено выше. Исторически сложились существенные искажения и неверная интерпретация этого. Некоторые межсетевые экраны и устройства защиты считают такие сегменты подозрительными. Однако эта возможность была использована в T/TCP [21] и применяется в TCP Fast Open (TFO) [48], поэтому важна её поддержка в реализациях и сетевых устройствах.

5. Если биты SYN и RST не установлены, сегмент отбрасывается с возвратом управления.

3.10.7.4. Другие состояния

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

SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT

• Сегменты обрабатываются по порядку. Первые проверки по прибытии служат для отбрасывания старых дубликатов, а дополнительные проверки выполняются в порядке SEG.SEQ. Если содержимое сегмента пересекает границу между старой и новой частью, обрабатывается только новая.

• В общем случае обработка принятых сегментов должна быть реализована для агрегирования сегментов ACK, когда это возможно (MUST-58). Например, если конечная точка TCP обрабатывает последовательность сегментов из очереди, все они должны быть обработаны до отправки какого-либо ACK (MUST-59).

• Имеется 4 случая для проверки пригодности входыщих сегментов, показанные в таблице 6.

Таблица 6. Проверка пригодности сегмента.

0

0

 SEG.SEQ = RCV.NXT

0

>0

 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

>0

0

 not acceptable

>0

>0

 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
или
 RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

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

• Если RCV.WND = 0, сегменты не будут приемлемы, но следует воспринимать действительные ACK, URG, RST.

• Если входящий сегмент неприемлем, следует передать в ответ подтверждение (если не установлен флаг RST, когда сегмент отбрасывается с возвратом управления) вида <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>. После передачи подтверждения неприемлемый сегмент отбрасывается с возвратом управления.

• Отметим, что для состояния TIME-WAIT в [40] представлен улучшенный алгоритм обработки входящих сегментов SYN с использованием временных меток вместо описанной здесь проверки порядковых номеров. При реализации такого алгоритма описанная выше логика не применяется для входящих сегментов SYN с опцией Timestamp, принятых в состоянии TIME-WAIT.

• Далее сегменты считаются идеализированными, начинающимися с RCV.NXT и не выходящими за пределы окна. Фактические сегменты можно привести к этому допущению, отрезав выходящие за пределы окна части (включая SYN и FIN) и обрабатывая лишь оставшееся, как будто сегмент начинается с RCV.NXT. Сегменты, начинающиеся с больших порядковых номеров следует оставлять для последующей обработки (SHLD-31).

Вторым этапом служит проверка бита RST.

В разделе 3 RFC 5961 [9] описана возможная атака со сбросом вслепую и предложения по смягчению. Это не обеспечивает криптографической защиты *например, как IPsec или TCP-AO), но применимо в случае RFC 5961. Для стеков, реализующих описанную в RFC 5961 защиту, применимы три проверки, указанных ниже. В остальных случаях проверки выполняются в зависимости от состояния, как описано далее.

1. 1. При установленном бите RST и порядковым номером вне текущего окна приёма сегмент отбрасывается.

   2. Если бит RST установлен и порядковый номер точно соответствует ожидаемому (RCV.NXT), конечная точка TCP должна сбросит соединение, как описано ниже для соответствующего состояния.

   3. Если бит RST установлен и порядковый номер не соответствует ожидаемому, но попадает в текущее окно приёма, конечная точка TCP должна передать подтверждение (challenge ACK) <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>.

      После отправки challenge ACK конечные точки TCP должны отбрасывать неприемлемые сегменты и останавливать дальнейшую обработку входящих пакетов. Отметим, что в RFC 5961 и Errata ID 4772 [99] приведены дополнительные соображения по contain дросселированию (throttling) ACK в реализации.

SYN-RECEIVED

• Если соединение инициировано пассивным вызовом OPEN (т. е. перешло из состояния LISTEN), оно возвращается в состояние LISTEN и управление возвращается вызвавшему процессу без необходимости информировать пользователя. Если вызов OPEN был активным (т. е. переход из состояния SYN-SENT), соединение отвергается с передачей пользователю ошибки connection refused. Соединение переходит в состояние CLOSED с удалением TCB и возвратом управления.
  В любом случае очередь повторной передачи следует очистить.

ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT

CLOSING, LAST-ACK, TIME-WAIT

На третьем этапе проверяется безопасность.

SYN-RECEIVED

ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT

• Если security/compartment в сегменте не соответствует точно security/compartment в TCB, передаётся сброс, оставшимся вызовам RECEIVE и SEND следует получить отклики reset с очисткой всех сегментов из очереди. Пользователю следует получить незапрошенный общий сигнал connection reset. Соединение переходит в состояние CLOSED с удалением TCB и возвратом управления.

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

На четвёртом этапе проверяется бит SYN.

SYN-RECEIVED

• Если соединение инициировано пассивным вызовом OPEN, оно переходит в состояние LISTEN с возвратом управления. В ином случае выполняется обработка в соответствии с синхронизированными состояниями.

ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT

• Если установлен бит SYN, это может быть легитимная попытка нового соединения (например, для TIME-WAIT), ошибка, при которой нужно сбросить соединение или результат попытки атаки, как описано в RFC 5961 [9]. Для TIME-WAIT новое соединение может быть воспринято, если применяется опция Timestamp и метка соответствует ожиданиям (в соответствии с [40]). Для других случаев RFC 5961 предоставляет смягчение атаки, применимое в некоторых ситуациях, но имеются также варианты криптографической защиты (см. 7. Вопросы безопасности и приватности). В соответствии с рекомендациями RFC 5961 для этих синхронизированных состояний при установленном флаге SYN независимо от порядкового номера конечная точка TCP должна передать удалённому партнёру challenge ACK <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>.
• После отправки подтверждения реализация TCP должна отбросить неприемлемый сегмент и прекратить обработку. Отметим, что в RFC 5961 и Errata ID 4772 [99] приведены дополнительные замечанию по дросселированию ACK для реализации.
• Для реализаций, не следующих RFC 5961, применяется поведение, описанное в RFC 793. Если SYN попадает в окно, это является ошибкой — передаётся сброс, остающимся RECEIVE и SEND следует получить отклик reset, все сегменты из очереди следует очистить, а пользователю следует передать незапрошенный сигнал connection reset. Соединение переводится в состояние CLOSED с удалением TCB и возвратом управления. Если SYN не попадает в окно, до этого этапа дело не доходит и сегмент ACK передаётся на первом этапе проверки порядкового номера.

Пятым этапом является проверка поля ACK.

• Если бит ACK сброшен (0) сегмент отбрасывается с возвратом управления.
• Если бит ACK установлен (1),выполняются указанные ниже действия.

  • В разделе 5 RFC 5961 [9] описаны возможные атаки с внедрением вслепую и смягчение этих атак, которое можно включить в реализацию (MAY-12). Стеки TCP, реализующие RFC 5961, должны добавлять входную проверку приемлемости значения ACK, если оно находится в диапазоне (SND.UNA — MAX.SND.WND) =< SEG.ACK =< SND.NXT. Все входящие сегменты, не удовлетворяющие этому условию, должны отбрасываться с передачей ACK. Новое состояние переменной MAX.SND.WND определяется наибольшим значением размера окна, полученного локальным отправителем от его партнёра (может изменяться) или может быть жёстко закодировано максимально допустимым размером окна. Когда значение ACK приемлемо, выполняются указанные ниже проверки в зависимости от состояния.

SYN-RECEIVED

• Если SND.UNA < SEG.ACK =< SND.NXT, соединение переходит в состояние ESTABLISHED и продолжается обработка с установкой значений

  SND.WND <- SEG.WND
  SND.WL1 <- SEG.SEQ
  SND.WL2 <- SEG.ACK

• Если подтверждение сегмента не приемлемо, формируется и передаётся сегмент сброса <SEQ=SEG.ACK><CTL=RST>.

ESTABLISHED

• Если SND.UNA < SEG.ACK =< SND.NXT, устанавливается SND.UNA <- SEG.ACK. Все подтверждённый таким образом сегменты из очереди повторной передачи удаляются. Пользователям следует отправить позитивные подтверждения для буферов, которые переданы (SENT) и полностью подтверждены (т. е. буфер SEND вернул отклик ok). Если ACK является дубликатом (SEG.ACK =< SND.UNA), его можно игнорировать. Если ACK подтверждает ещё не переданное (SEG.ACK > SND.NXT), передаётся ACK и сегмент отбрасывается с возвратом управления.
• Если SND.UNA =< SEG.ACK =< SND.NXT, следует обновить окно передачи. Если (SND.WL1 < SEG.SEQ или (SND.WL1 = SEG.SEQ и SND.WL2 =< SEG.ACK)), устанавливается SND.WND <- SEG.WND, SND.WL1 <- SEG.SEQ, SND.WL2 <- SEG.ACK. Отметим, что SND.WND — это смещение от SND.UNA, SND.WL1 содержит порядковый номер последнего сегмента, использованного для обновления SND.WND, а SND.WL2 — номер подтверждения последнего сегмента, использованного для обновления SND.WND. Эта проверка предотвращает использование старых сегментов для обновления окна.

FIN-WAIT-1

FIN-WAIT-2

CLOSE-WAIT

CLOSING

LAST-ACK

TIME-WAIT

Шестым этапом является проверка бита URG.

ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2

CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT

Седьмым этаком является обработка данных (текста).

ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2

• В состоянии ESTABLISHED можно доставлять сегмент данных в пользовательский буфер RECEIVE. Данные из сегментов можно перемещать в буферы до их заполнения или до завершения сегмента. Если сегмент использован полностью (пуст) и содержит флаг PUSH, пользователь информируется о получении PUSH.
• Когда конечная точка TCP принимает на себя ответственность за доставку данных пользователю, она должна подтвердить получение данных.
• Как только конечная точка TCP приняла ответственность за данные, она продвигает RCV.NXT за полученные данные и корректирует RCV.WND должным образом в соответствии с текущей доступностью буфера. Сумму RCV.NXT и RCV.WND не следует снижать.
• Реализация TCP может передать сегмент ACK, подтверждающий RCV.NXT, когда прибывает пригодный сегмент, попадающий в окно, но не находящийся на левом краю окна (MAY-13).
• Отметим предложения по управлению окном из параграфа 3.8. Обмен данными.
• Передаётся сегмент подтверждения в форме <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>. Это подтверждение следует цеплять (piggyback) к сегменту, который будет передаваться, по возможности, без неоправданной задержки.

CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT

На восьмом этапе проверяется бит FIN.

• В состоянии CLOSED, LISTEN или SYN-SENT бит FIN не обрабатывается, поскольку нет возможности проверить SEG.SEQ. Сегмент отбрасывается с возвратом управления.

• Если бит FIN установлен, пользователю передаётся сигнал connection closing, возвращаются все ожидающие RECEIVE с тем же сообщение, значение RCV.NXT продвигается на FIN и передаётся подтверждение FIN. Отметим, что FIN предполагает PUSH для любых данных сегмента, ещё не доставленных пользователю.

SYN-RECEIVED, ESTABLISHED

FIN-WAIT-1

FIN-WAIT-2

CLOSE-WAIT

CLOSING

LAST-ACK

TIME-WAIT

Далее управление возвращается вызвавшему процессу.

3.10.8. Тайм-ауты

USER TIMEOUT

RETRANSMISSION TIMEOUT

TIME-WAIT TIMEOUT

4. Глоссарий

ACK — подтверждение

Connection — соединение

Datagram — дейтаграмма

Destination Address — адрес получателя

FIN — завершение

Flush — очистка

Fragment — фрагмент

Header — заголовок

Host — хост

Identification — идентификация

internet address — адрес internet

internet datagram — дейтаграмма internet

internet fragment — фрагмент internet

IP

IRS

ISN

ISS

left sequence — левый край

Module — модуль

MSL (Maximum Segment Lifetime)

Octet — октет

Options — опции

Packet — пакет

Port — порт

Process — процесс

PUSH — выталкивание

RCV.NXT

RCV.UP

RCV.WND

receive next sequence number

receive window — окно приёма

RST

SEG.ACK

SEG.LEN

SEG.SEQ

SEG.UP

SEG.WND

Segment — сегмент

segment acknowledgment — подтверждение сегмента

segment length — размер сегмента

segment sequence — порядковый номер сегмента

send sequence

send window — окно передачи

SND.NXT

SND.UNA

SND.UP

SND.WL1

SND.WL2

SND.WND

socket (socket number, socket address, socket identifier) — сокет (номер, идентификатор, адрес сокета)

Source Address

SYN

TCB

TCP

TOS

Type of Service — тип обслуживания

URG

urgent pointer — указатель важности

5. Отличия от RFC 793

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

Основная часть этого документа адаптирована из раздела 3 в RFC 793 (Функциональная спецификация) с попыткой максимального сохранения форматирования и макета.

В документе учтены сведения об ошибках (RFC errata), принятые или отложенные до обновления RFC 793 (Errata ID: 573 [73], 574 [74], 700 [75], 701 [76], 1283 [77], 1561 [78], 1562 [79], 1564 [80], 1571 [81], 1572 [82], 2297 [83], 2298 [84], 2748 [85], 2749 [86], 2934 [87], 3213 [88], 3300 [89], 3301 [90], 6222 [91]). Некоторые сообщения не были включены, поскольку их учли в других изменениях (Errata ID: 572 [92], 575 [93], 1565 [94], 1569 [95], 2296 [96], 3305 [97], 3602 [98]).

Внесены изменения спецификации указателя важности (срочности), описанные в RFC 1011, RFC 1122, RFC 6093. Подробное обсуждение необходимости этих изменений представлено в RFC 6093.

Обсуждение RTO в RFC 793 было обновлено ссылкой на RFC 6298. Связанный с RTO текст RFC 1122 в своё время заменил текст RFC 793, однако позднее RFC 2988 обновил RFC 1122, а сам был потом отменён RFC 6298.

В RFC 1011 [18] содержится много комментариев к RFC 793, включая некоторые изменения спецификации TCP. Они были расширены в RFC 1122, где содержится набор изменений и разъяснений к RFC 793. Влияющие на протокол нормативные элементы включены в этот документ, хотя часть исторически полезных советов по реализации и обсуждений из RFC 1122 не была включена. Настоящий документ, который сейчас является спецификацией TCP вместо RFC 793, обновляет RFC 1011 и комментарии из RFC 1011 включены здесь.

В RFC 1122 содержатся не просто требования к TCP, поэтому данный документ не может отменить RFC 1122 целиком. Он лишь обновляет RFC 1122, однако следует понимать, что это фактически отменяет все относящиеся к TCP сведения в RFC 1122.

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

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

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

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

В реестр Transmission Control Protocol (TCP) Header Flags агентство IANA внесло описанные здесь изменения.

В RFC 3168 был исходно создан этот реестр с указанием лишь заданных в RFC 3168 битов без учёта битов, описанных ранее в RFC 793 и других документах. После этого бит 7 был обновлён в RFC 8311 [54].

Столбец Bit был переименован в Bit Offset (Смещение), поскольку он указывает смещение каждого флага заголовка в 16 битовом слове заголовка TCP на рисунке 1. Биты со смещением 0-3 являются полем TCP Data Offset, а не флагами.

Агентство IANA добавило столбец Assignment Notes (замечанию к назначению).

Выделенные IANA значения представлены в таблице 7.

Таблица 7. Флаги заголовков TCP.

Реестр TCP Header Flags перенесён в субреестр реестра Transmission Control Protocol (TCP) Parameters <https://www.iana.org/assignments/tcp-parameters/>. Процедурой регистрации для реестра остаётся Standards Action, но ссылка (Reference) обновлена с указанием данного документа, а колонка Note удалена.

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

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

Для полного обеспечения конфиденциальности, защиты целостности и аутентификации соединений TCP (включая флаги управления) единственным методом сейчас является IPsec. Доступна защита целостности и контроль подлинности с помощью опции TCP Authentication (TCP-AO) [38], а предложенное расширение обеспечивает конфиденциальность содержимого сегментов. Другие методы, описанные здесь, могут обеспечить конфиденциальность или целостность для содержимого, но включают лишь часть полей заголовка (например, tcpcrypt [57]) или не защищают их совсем (например, TLS). Другие средства защиты, добавленные в TCP (например, генерация ISN, проверка порядковых номеров и пр.) способны лишь частично отражать атаки.

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

Экспериментальное расширение tcpcrypt [57] обеспечивает возможность криптографической защиты данных соединения. Аспекты метаданных потока по-прежнему видны, но поток приложения хорошо защищён. В заголовке TCP обеспечивается лишь защита указателя важности и флага FIN.

TCP Roadmap [49] включает замечания о нескольких RFC, связанных с безопасностью TCP. В этом документе объединены многие из предложенных в этих RFC улучшений, включая генерацию ISN, смягчение атак вслепую в окне, улучшение обработки мягких ошибок и пакетов ICMP. Все это подробно рассматривается в упомянутых RFC, исходно описывающих изменения, требуемые в ранних спецификациях TCP. В RFC 6093 [39] рассмотрены вопросы безопасности, относящиеся к полю указателя важности, а также рекомендуется не применять его в новых реализациях.

Поскольку TCP часто применяется для передачи больших объёмов данных, возможны атаки, злоупотребляющие логикой управления контролем перегрузок, например, атаки ACK-division. В спецификации механизмов контроля перегрузок TCP были внесены изменения для смягчения таких атак, например, подходящий поток байтов (Appropriate Byte Counting или ABC) [29].

Другие атаки нацелены на истощение ресурсов сервера TCP. Примеры включают лавинные атаки SYN [32] или расход ресурсов на неактивные соединения [41]. Операционные системы реализуют смягчение таких атак. В число распространённых средств защиты входят прокси, межсетевые экраны с учётом состояния и другие методы за пределами реализации TCP на конечном хосте.

Концепция образа протокола в линии (wire image), описанная в RFC 8546 [56], указывает, как открытые заголовки TCP раскрывают узлам на пути больше метаданных, нежели нужно для маршрутизации пакетов адресатам. Злоумышленники на пути могут использовать такие метаданные. Извлечённые из этого уроки для TCP были применены при разработке нового транспорта, такого как QUIC [60]. Кроме того, имеются соображения, частично основанные на опыте работы с TCP и расширениями протокола, которые можно применить при разработке новых транспортных расширения TCP и иного транспорта, опубликованные IETF в RFC 9065 [61], наряду с рекомендациями IAB в RFC 8558 [58] и [67].

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

Поскольку обработка сообщений ICMP также может взаимодействовать с соединениями TCP, имеются возможные атаки на основе ICMP. Они рассмотрены в RFC 5927 [100] вместе с реализованными мерами по смягчению.

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

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

[1] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

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

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

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

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

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

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

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

[9] Ramaiah, A., Stewart, R., and M. Dalal, «Improving TCP’s Robustness to Blind In-Window Attacks», RFC 5961, DOI 10.17487/RFC5961, August 2010, <https://www.rfc-editor.org/info/rfc5961>.

[10] Paxson, V., Allman, M., Chu, J., and M. Sargent, «Computing TCP’s Retransmission Timer», RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[11] Gont, F., «Deprecation of ICMP Source Quench Messages», RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.

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

[13] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[14] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., «Path MTU Discovery for IP version 6», STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[15] Allman, M., «Requirements for Time-Based Loss Detection», BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020, <https://www.rfc-editor.org/info/rfc8961>.

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

[16] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[17] Nagle, J., «Congestion Control in IP/TCP Internetworks», RFC 896, DOI 10.17487/RFC0896, January 1984, <https://www.rfc-editor.org/info/rfc896>.

[18] Reynolds, J. and J. Postel, «Official Internet protocols», RFC 1011, DOI 10.17487/RFC1011, May 1987, <https://www.rfc-editor.org/info/rfc1011>.

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

[20] Almquist, P., «Type of Service in the Internet Protocol Suite», RFC 1349, DOI 10.17487/RFC1349, July 1992, <https://www.rfc-editor.org/info/rfc1349>.

[21] Braden, R., «T/TCP — TCP Extensions for Transactions Functional Specification», RFC 1644, DOI 10.17487/RFC1644, July 1994, <https://www.rfc-editor.org/info/rfc1644>.

[22] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.

[23] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, «Known TCP Implementation Problems», RFC 2525, DOI 10.17487/RFC2525, March 1999, <https://www.rfc-editor.org/info/rfc2525>.

[24] Borman, D., Deering, S., and R. Hinden, «IPv6 Jumbograms», RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.

[25] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, «TCP Processing of the IPv4 Precedence Field», RFC 2873, DOI 10.17487/RFC2873, June 2000, <https://www.rfc-editor.org/info/rfc2873>.

[26] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, «An Extension to the Selective Acknowledgement (SACK) Option for TCP», RFC 2883, DOI 10.17487/RFC2883, July 2000, <https://www.rfc-editor.org/info/rfc2883>.

[27] Lahey, K., «TCP Problems with Path MTU Discovery», RFC 2923, DOI 10.17487/RFC2923, September 2000, <https://www.rfc-editor.org/info/rfc2923>.

[28] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, «TCP Performance Implications of Network Path Asymmetry», BCP 69, RFC 3449, DOI 10.17487/RFC3449, December 2002, <https://www.rfc-editor.org/info/rfc3449>.

[29] Allman, M., «TCP Congestion Control with Appropriate Byte Counting (ABC)», RFC 3465, DOI 10.17487/RFC3465, February 2003, <https://www.rfc-editor.org/info/rfc3465>.

[30] Fenner, B., «Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers», RFC 4727, DOI 10.17487/RFC4727, November 2006, <https://www.rfc-editor.org/info/rfc4727>.

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

[32] Eddy, W., «TCP SYN Flooding Attacks and Common Mitigations», RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.

[33] Touch, J., «Defending TCP Against Spoofing Attacks», RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>.

[34] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, «Marker PDU Aligned Framing for TCP Specification», RFC 5044, DOI 10.17487/RFC5044, October 2007, <https://www.rfc-editor.org/info/rfc5044>.

[35] Gont, F., «TCP’s Reaction to Soft Errors», RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.

[36] StJohns, M., Atkinson, R., and G. Thomas, «Common Architecture Label IPv6 Security Option (CALIPSO)», RFC 5570, DOI 10.17487/RFC5570, July 2009, <https://www.rfc-editor.org/info/rfc5570>.

[37] Sandlund, K., Pelletier, G., and L-E. Jonsson, «The Robust Header Compression (ROHC) Framework», RFC 5795, DOI 10.17487/RFC5795, March 2010, <https://www.rfc-editor.org/info/rfc5795>.

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

[39] Gont, F. and A. Yourtchenko, «On the Implementation of the TCP Urgent Mechanism», RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.

[40] Gont, F., «Reducing the TIME-WAIT State Using TCP Timestamps», BCP 159, RFC 6191, DOI 10.17487/RFC6191, April 2011, <https://www.rfc-editor.org/info/rfc6191>.

[41] Bashyam, M., Jethanandani, M., and A. Ramaiah, «TCP Sender Clarification for Persist Condition», RFC 6429, DOI 10.17487/RFC6429, December 2011, <https://www.rfc-editor.org/info/rfc6429>.

[42] Gont, F. and S. Bellovin, «Defending against Sequence Number Attacks», RFC 6528, DOI 10.17487/RFC6528, February 2012, <https://www.rfc-editor.org/info/rfc6528>.

[43] Borman, D., «TCP Options and Maximum Segment Size (MSS)», RFC 6691, DOI 10.17487/RFC6691, July 2012, <https://www.rfc-editor.org/info/rfc6691>.

[44] Touch, J., «Updated Specification of the IPv4 ID Field», RFC 6864, DOI 10.17487/RFC6864, February 2013, <https://www.rfc-editor.org/info/rfc6864>.

[45] Touch, J., «Shared Use of Experimental TCP Options», RFC 6994, DOI 10.17487/RFC6994, August 2013, <https://www.rfc-editor.org/info/rfc6994>.

[46] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, «Architectural Considerations of IP Anycast», RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.

[47] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., «TCP Extensions for High Performance», RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[48] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, «TCP Fast Open», RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[49] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, «A Roadmap for Transmission Control Protocol (TCP) Specification Documents», RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.

[50] Black, D., Ed. and P. Jones, «Differentiated Services (Diffserv) and Real-Time Communication», RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[51] Fairhurst, G. and M. Welzl, «The Benefits of Using Explicit Congestion Notification (ECN)», RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.

[52] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., «Services Provided by IETF Transport Protocols and Congestion Control Mechanisms», RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.

[53] Welzl, M., Tuexen, M., and N. Khademi, «On the Usage of Transport Features Provided by IETF Transport Protocols», RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.

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

[55] Chown, T., Loughney, J., and T. Winters, «IPv6 Node Requirements», BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.

[56] Trammell, B. and M. Kuehlewind, «The Wire Image of a Network Protocol», RFC 8546, DOI 10.17487/RFC8546, April 2019, <https://www.rfc-editor.org/info/rfc8546>.

[57] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, «Cryptographic Protection of TCP Streams (tcpcrypt)», RFC 8548, DOI 10.17487/RFC8548, May 2019, <https://www.rfc-editor.org/info/rfc8548>.

[58] Hardie, T., Ed., «Transport Protocol Path Signals», RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.

[59] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, «TCP Extensions for Multipath Operation with Multiple Addresses», RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.

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

[61] Fairhurst, G. and C. Perkins, «Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols», RFC 9065, DOI 10.17487/RFC9065, July 2021, <https://www.rfc-editor.org/info/rfc9065>.

[62] IANA, «Transmission Control Protocol (TCP) Parameters», <https://www.iana.org/assignments/tcp-parameters/>.

[63] Gont, F., «Processing of IP Security/Compartment and Precedence Information by TCP», Work in Progress, Internet-Draft, draft-gont-tcpm-tcp-seccomp-prec-00, 29 March 2012, <https://datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seccomp-prec-00>.

[64] Gont, F. and D. Borman, «On the Validation of TCP Sequence Numbers», Work in Progress, Internet-Draft, draft-gont-tcpm-tcp-seq-validation-04, 11 March 2019, <https://datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seq-validation-04>.

[65] Touch, J. and W. M. Eddy, «TCP Extended Data Offset Option», Work in Progress, Internet-Draft, draft-ietf-tcpm-tcp-edo-12, 15 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-12>.

[66] McQuistin, S., Band, V., Jacob, D., and C. Perkins, «Describing Protocol Data Units with Augmented Packet Header Diagrams», Work in Progress, Internet-Draft, draft-mcquistin-augmented-ascii-diagrams-10, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-mcquistin-augmented-ascii-diagrams-10>.

[67] Thomson, M. and T. Pauly, «Long-Term Viability of Protocol Extension Mechanisms», RFC 9170, DOI 10.17487/RFC9170, December 2021, <https://www.rfc-editor.org/info/rfc9170>.

[68] Minshall, G., «A Suggested Modification to Nagle’s Algorithm», Work in Progress, Internet-Draft, draft-minshall-nagle-01, 18 June 1999, <https://datatracker.ietf.org/doc/html/draft-minshall-nagle-01>.

[69] Dalal, Y. and C. Sunshine, «Connection Management in Transport Protocols», Computer Networks, Vol. 2, No. 6, pp. 454-473, DOI 10.1016/0376-5075(78)90053-3, December 1978, <https://doi.org/10.1016/0376-5075(78)90053-3>.

[70] Faber, T., Touch, J., and W. Yui, «The TIME-WAIT state in TCP and Its Effect on Busy Servers», Proceedings of IEEE INFOCOM, pp. 1573-1583, DOI 10.1109/INFCOM.1999.752180, March 1999, <https://doi.org/10.1109/INFCOM.1999.752180>.

[71] Postel, J., «Comments on Action Items from the January Meeting», IEN 177, March 1981, <https://www.rfc-editor.org/ien/ien177.txt>.

[72] «Segmentation Offloads», The Linux Kernel Documentation, <https://www.kernel.org/doc/html/latest/networking/segmentation-offloads.html>.

[73] RFC Errata, Erratum ID 573, RFC 793, <https://www.rfc-editor.org/errata/eid573>.

[74] RFC Errata, Erratum ID 574, RFC 793, <https://www.rfc-editor.org/errata/eid574>.

[75] RFC Errata, Erratum ID 700, RFC 793, <https://www.rfc-editor.org/errata/eid700>.

[76] RFC Errata, Erratum ID 701, RFC 793, <https://www.rfc-editor.org/errata/eid701>.

[77] RFC Errata, Erratum ID 1283, RFC 793, <https://www.rfc-editor.org/errata/eid1283>.

[78] RFC Errata, Erratum ID 1561, RFC 793, <https://www.rfc-editor.org/errata/eid1561>.

[79] RFC Errata, Erratum ID 1562, RFC 793, <https://www.rfc-editor.org/errata/eid1562>.

[80] RFC Errata, Erratum ID 1564, RFC 793, <https://www.rfc-editor.org/errata/eid1564>.

[81] RFC Errata, Erratum ID 1571, RFC 793, <https://www.rfc-editor.org/errata/eid1571>.

[82] RFC Errata, Erratum ID 1572, RFC 793, <https://www.rfc-editor.org/errata/eid1572>.

[83] RFC Errata, Erratum ID 2297, RFC 793, <https://www.rfc-editor.org/errata/eid2297>.

[84] RFC Errata, Erratum ID 2298, RFC 793, <https://www.rfc-editor.org/errata/eid2298>.

[85] RFC Errata, Erratum ID 2748, RFC 793, <https://www.rfc-editor.org/errata/eid2748>.

[86] RFC Errata, Erratum ID 2749, RFC 793, <https://www.rfc-editor.org/errata/eid2749>.

[87] RFC Errata, Erratum ID 2934, RFC 793, <https://www.rfc-editor.org/errata/eid2934>.

[88] RFC Errata, Erratum ID 3213, RFC 793, <https://www.rfc-editor.org/errata/eid3213>.

[89] RFC Errata, Erratum ID 3300, RFC 793, <https://www.rfc-editor.org/errata/eid3300>.

[90] RFC Errata, Erratum ID 3301, RFC 793, <https://www.rfc-editor.org/errata/eid3301>.

[91] RFC Errata, Erratum ID 6222, RFC 793, <https://www.rfc-editor.org/errata/eid6222>.

[92] RFC Errata, Erratum ID 572, RFC 793, <https://www.rfc-editor.org/errata/eid572>.

[93] RFC Errata, Erratum ID 575, RFC 793, <https://www.rfc-editor.org/errata/eid575>.

[94] RFC Errata, Erratum ID 1565, RFC 793, <https://www.rfc-editor.org/errata/eid1565>.

[95] RFC Errata, Erratum ID 1569, RFC 793, <https://www.rfc-editor.org/errata/eid1569>.

[96] RFC Errata, Erratum ID 2296, RFC 793, <https://www.rfc-editor.org/errata/eid2296>.

[97] RFC Errata, Erratum ID 3305, RFC 793, <https://www.rfc-editor.org/errata/eid3305>.

[98] RFC Errata, Erratum ID 3602, RFC 793, <https://www.rfc-editor.org/errata/eid3602>.

[99] RFC Errata, Erratum ID 4772, RFC 5961, <https://www.rfc-editor.org/errata/eid4772>.

[100] Gont, F., «ICMP Attacks against TCP», RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>.

Приложение A. Замечания по реализации

В этом приложении приведены дополнительные примечания и ссылки на решения по реализации TCP, которые в настоящее время не включены в RFC и не являются частью стандарта TCP. Эти элементы могли быть рассмотрены разработчиками, но ещё не включены в стандарт.

A.1. IP Security Compartment и Precedence

Спецификация IPv4 [1] включает значение предпочтений в ныне отмененное поле типа обслуживания (Type of Service или TOS). Оно было изменено в [20], а сейчас отменено определением дифференцированного обслуживания (Differentiated Services или Diffserv) [4]. установка и передача поля TOS между сетевым уровнем, реализацией TCP и приложениями устарела и заменена Diffserv в текущей спецификации TCP.

RFC 793 требует проверки изоляции и предпочтений безопасности IP во входящих сегментах TCP на предмет согласованности с соединением и запросами приложений. Каждый из этих аспектов IP устарел, но в RFC 793 не внесено соответствующих обновлений. Проблема с предпочтениями решена в [25] со статусом Standards Track, поэтому действующая спецификация TCP включает эти изменения. Однако состояние опций безопасности IP, которые могут применяться в многоуровневых системах защиты (Multi-Level Secure или MLS) не столь очевидно в IETF.

Сброс соединений при несоответствии входящий пакетов ожиданиям в части изоляции или предпочтений был сочтён возможным вектором атак [63] и обсуждались поправки к спецификации TCP для предотвращения разрыва соединений из-за несоответствия изоляции безопасности IP и кодов Diffserv.

A.1.1. Предпочтение

В Diffserv прежнее значение precedence, считается кодом селектора класса (Class Selector) и совместимые методы обработки описаны в архитектуре Diffserv. Спецификация TCP,заданная в RFC 793 и RFC 1122 включает логику, предназначенную для использования приложением наивысшего уровня предпочтения или сохранения предпочтений, согласованных для соединения. Эта логика для устаревших TOS не применима к Diffserv и её не следует включать в реализации TCP, хотя смена значений Diffserv в рамках соединения не рекомендуется. Обсуждение этих вопросов приведено в RFC 7657 (параграфы 5.1, 5.3, 6) [50].

Устаревшие правила обработки TOS в TCP предполагали двухсторонние (симметричные) значения предпочтений в соединении, а архитектура Diffserv асимметрична. Проблемы прежней логики TCP в этой части описаны в [25] и предложено игнорировать IP precedence в TCP. Поскольку RFC 2873 задаёт стандарт (Standards Track), хотя и не указывает обновление RFC 793, предполагается устойчивость текущих реализаций к этим условиям. Отметим, что применяемое для каждого направления значение поля Diffserv является частью интерфейса между TCP и сетевым уровнем, а значения могут быть заданы между TCP и приложением в обоих направлениях.

A.1.2. Системы MLS

Опция IP Security (IPSO) и изоляция, определённые в [1], пересмотрены в RFC 1038, который был отменен RFC 1108. Опция Commercial IP Security (CIPSO) определена в FIPS-188 (отозван NIST в 2015 г.) и поддерживается некоторыми производителями и операционными системами. RFC 1108 сейчас считается устаревшим (Historic), хотя RFC 791 не был обновлён с удалением опции IP Security. Для IPv6 похожая опция (Common Architecture Label IPv6 Security Option или CALIPSO) определена в [36]. RFC 793 включает логику, применяющую сведения security/compartment при трактовке сегментов TCP. Упоминания IP security/compartment в этом документе могут иметь отношение к разработкам систем многоуровневой защиты, но могут не приниматься во внимание системами, не включающими MLS, с работающим в Internet кодом (см. A.1. IP Security Compartment и Precedence). Отметим, что в RFC 5570 описаны некоторые межсетевые системы MLS, где может применяться IPSO, CIPSO или CALIPSO. В этих особых случаях разработчикам TCP следует ознакомиться с параграфом 7.3.1 RFC 5570 и выполнять рекомендации этого документа.

A.2. Проверка порядковых номеров

В некоторых случаях правила проверки порядковых номеров TCP могут препятствовать обработке полей ACK. Это может приводить к проблемам соединений, описанным в [64], где рассмотрены проблемы, возможные при одновременной организации соединений, самоподключении, одновременном закрытии и одновременном зондировании окна. В документе также описаны возможные изменения спецификации TCP для смягчения проблемы путём расширения приемлемых порядковых номеров.

При использовании TCP в Internet эти условия возникают редко, Основные операционные системы включают различные дополнительные варианты смягчения, а стандарт ещё не обновлён с учётом этого, но разработчикам следует учитывать проблемы, описанные в [64].

A.3. Изменение алгоритма Nagle

В распространённых ОС алгоритм Nagle и отложенные подтверждения реализованы и по умолчанию включены. TCP применяется во многих приложениях «запрос-отклик», где сочетание алгоритма Nagle с отложенными подтверждениями может снижать производительность приложения. В работе [68] описано изменение алгоритма Nagle , решающего эту проблему. Это изменение реализовано в основных ОС и не влияет на совместимость TCP. Кроме того, многие приложения просто отключают алгоритм Nagle, поскольку он обычно поддерживается опцией сокета. Стандарт TCP не изменён в части включения этой модификации алгоритма Nagle, но разработчики могут счесть её полезной.

A.4. Настройки Low Watermark

Некоторые реализации TCP в ядре ОС включают опции сокета, позволяющие задать число байтов в буфере, пока уровень сокета передаёт отправляемые данные TCP (SO_SNDLOWAT) или принятые — приложению (SO_RCVLOWAT).

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

Приложение B. Сводка требований TCP

Это приложение является адаптацией RFC 1122.

Отметим, что требования, связанные с PLPMTUD в таблице не приведены, но реализация PLPMTUD рекомендуется.

Таблица 8. Сводка требований TCP.

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

Этот документ в значительной части является пересмотром RFC 793, редактором которого был Jon Postel. Благодаря его превосходной работе документ просуществовал три десятилетия без пересмотра.

Andre Oppermann участвовал в редактировании первой редакции этого документа.

Авторы признательны руководителям рабочей группы IETF TCPM за помощь в подготовке этого документа: Michael Scharf, Yoshifumi Nishida, Pasi Sarolahti, Michael Tüxen.

При обсуждении этой работы в почтовой конференции TCPM, на встречах рабочей группы и обзорах в рамках направления полезные комментарии, критику и рецензии предоставили (в алфавитном порядке фамилий) Praveen Balasubramanian, David Borman, Mohamed Boucadair, Bob Briscoe, Neal Cardwell, Yuchung Cheng, Martin Duke, Francis Dupont, Ted Faber, Gorry Fairhurst, Fernando Gont, Rodney Grimes, Yi Huang, Rahul Jadhav, Markku Kojo, Mike Kosek, Juhamatti Kuusisaari, Kevin Lahey, Kevin Mason, Matt Mathis, Stephen McQuistin, Jonathan Morton, Matt Olson, Tommy Pauly, Tom Petch, Hagen Paul Pfeifer, Kyle Rose, Anthony Sabatini, Michael Scharf, Greg Skinner, Joe Touch, Michael Tüxen, Reji Varghese, Bernie Volz, Tim Wicinski, Lloyd Wood, Alex Zimmermann.

Joe Touch предоставил дополнительную помощь в прояснении описания параметров размера сегмента и рекомендации для PMTUD/PLPMTUD. Markku Kojo помог собрать воедино текст раздела по контролю перегрузок TCP.

Этот документ включает содержимое присланных замечаний об ошибках, присланных (в хронологическом порядке) Yin Shuming, Bob Braden, Morris M. Keesan, Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta Yevstifeyev, EungJun Yi, Botong Huang, Charles Deng, Merlin Buge.

Адрес автора

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

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

nmalykh@protokols.ru

Internet Research Task Force (IRTF)                         K. Matsuzono
Request for Comments: 9273                                     H. Asaeda
Category: Informational                                             NICT
ISSN: 2070-1721                                              C. Westphal
                                                                  Huawei
                                                             August 2022

Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges

Сетевое кодирование для CCNx и NDN — соображения и проблемы

PDF

Аннотация

Этот документ описывает текущие результаты исследований сетевого кодирования (Network Coding или NC) для ориентированных на содержимое сетей (Content-Centric Networking или CCNx) и сетей именованных данных (Named Data Networking или NDN) и разъясняет технические вопросы и возможные проблемы при использовании NC в CCNx/NDN. Документ является результатом работы исследовательских грапп Coding for Efficient Network Communications (NWCRG) и Information-Centric Networking (ICNRG).

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

Документ не относится к категории 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/rfc9273.

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

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

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

1. Введение

Информационно-ориентированные сети (Information-Centric Networking или ICN), в целом, ориентированные на содержимое сети (Content-Centric Networking или CCNx) [1] или сети именованных данных (Named Data Networking или NDN) [2], в частности, появились как новая парадигма коммуникаций, основанная на извлечении данных по их именам. Эта парадигма продвигает сведения о содержимом на сетевой уровень. Предполагается, что это позволит потребителям получать нужные сведения (содержимое) простым и эффективным способом из разнородных сетей, к которым они могут быть подключены. Архитектура CCNx/NDN представила новые идеи и стимулировала исследования в различных областях, таких как кэширование в сети, маршрутизация по именам, транспортировка по нескольким путям, защита содержимого. Одним из важных преимуществ запроса содержимого по именам устраняет необходимость организации соединения между клиентом и конкретным сервером, а содержимое может быть получено из нескольких источников.

Одновременно с этим в академических и промышленных кругах рос интерес к улучшению понимания фундаментальных аспектов сетевого кодирования (Network Coding или NC) для улучшения показателей пропускной способности, отказоустойчивости и снижения числа передач через соединённые сети и избыточных передач через широковещательные или многоточечные (point-to-multipoint) соединения. NC — это метод, обычно применяемый для кодирования пакетов с тем, чтобы восстановить потерянные исходные пакеты на стороне приёмника для быстрого получения желаемой информации полностью распределенным способом. Кроме того, с точки зрения безопасности, кодированием NC можно управлять с использованием практической схемы защиты, которая справляется с атаками загрязнения (pollution) [3] и может применяться для предотвращения получения злоумышленниками значимой информации [4] или защиты беспроводных видеопотоков при сохранении преимуществ NC [5] [6].

С точки зрения транспортного механизма NC можно разделить на две категории — когерентное NC и некогерентное NC [7] [8]. В когерентном NC исходный и целевой узел знают точную топологию сети и операции кодирования доступны на промежуточных узлах. Когда несколько потребителей пытаются получить одно и то же содержимое, например, видеотрансляцию в реальном времени, когерентное кодирование может обеспечить оптимальную пропускную способность за счёт передачи потока через созданные оптимальные деревья групповой передачи [9]. Однако для этого нужен полностью настраиваемый конкретный механизм маршрутизации и много вычислительных ресурсов для центральной координации. В случае некогерентного NC, где часто применяется случайное линейное кодирование (Random Linear Coding или RLC), не требуется знание топологии сети и операции кодирования на промежуточных узлах [10]. Некогерентное кодирование работает независимо и децентрализовано, поэтому обеспечивает большую гибкость.

NC объединяет пакеты с частями одного содержимого и может делать это в источнике и/или других узлах сети. Закодированные в сети пакеты не связаны с конкретным сервером, поскольку они могут объединяться внутри сети. Поскольку NC фокусируется на том, какую информацию следует кодировать в сетевом пакете, а не на конкретном хосте, где она была создана, это кодирование соответствует архитектуре уровня базовой сети CCNx/NDN. NC позволяет восстановить отсутствующие пакеты за счёт кодирования информации в нескольких пакетах. ICN взаимодействует с NC, поскольку позволяет кэшировать пакеты данных в сети. В типичной сети, использующей NC, отправитель может передать достаточно пакетов для получения исходных данных. ICN предоставляет возможность извлекать кодированные в сети пакеты напрямую из кэшей в сети, делая комбинацию ICN и NC особенно эффективной. Фактически кодирование NC уже реализовано для распространения информации (содержимого) [11] [12] [13]. Montpetit и др. Впервые предложили использовать методы NC для улучшения основных показателей производительности в ICN [14]. Хотя CCNx/NDN превосходно пользуется преимуществами NC (5. Преимущества NC и CCNx/NDN), нужно рассмотреть некоторые технические вопросы объединения NC и CCNx/NDN, связанные с уникальными свойствами CCNx/NDN (6. Технические соображения).

В этом документе рассматривается применение NC к архитектуре CCNx/NDN, приводятся технические соображения и описываются возможные проблемы для случая улучшения взаимодействий на основе CCNx/NDN с применением технологии NC. Следует подчеркнуть, что представление конкретных решений (например, методов оптимизации NC) для улучшения показателей производительности CCNx/NDN за счёт применения NC выходит за рамки документа.

Документ представляет совместные результаты и согласованное мнение исследовательских групп Coding for Efficient Network Communications (NWCRG) и Information-Centric Networking (ICNRG). Документ был прочитан и рецензирован всеми активными участниками этих групп. Он не является результатом IETF или стандартом.

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

2.1. Определения, связанные с NC

В этом параграфе приведены связанные с NC термины, определённые в RFC 8406 [15] и предложенные NWCRG.

Source Packet — исходный пакет

Repair Packet — ремонтный пакет

Encoding versus Recoding versus Decoding — кодирование, запись, декодирование

Далее определены термины, связанные с типами кодирования.

Random Linear Coding (RLC) — случайное линейное кодирование

Block Coding — блочное кодирование

Sliding Window Coding (Convolutional Coding) — кодирование со скользящим окном (свёрточное кодирование)

Fixed or Elastic Sliding Window Coding — кодирование с фиксированным или эластичным скользящим окном

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

Rank of the Linear System (Degrees of Freedom) — ранг линейной системы (число степеней свободы)

Generation (Block) — генерация (блок)

Generation Size (Block Size) — размер генерации (блока)

Coding Coefficient — коэффициент кодирования

Coding Vector — вектор кодирования

Finite Field — конечное поле

2.2. Определения, связанные с CCNx/NDN

Использованная в документе терминология, связанная с CCNx/NDN, определена в RFC 8793 [16], созданном ICNRG. Она согласуется с документами [17] [18].

3. Основы CCNx/NDN

Здесь кратко описаны основные концепции CCNx/NDN. В сети CCNx/NDN имеется два типа пакетов сетевого уровня — запросы (interest) и пакеты данных (определены в параграфе 3.4 [16]). Термин «объект содержимого» (content object), обозначающий блок данных содержимого, является синонимом пакета данных [16]. Потребитель ICN (определён в параграфе 3.2 [16]) запрашивает объект содержимого путём передачи запроса (interest) и именем данных.

После получения пересылающим элементом ICN (forwarder в соответствии с определением параграфа 3.2 в [16]) запроса interest, он выполняет ряд операций поиска. Сначала проверяется наличие искомого содержимого в кэш-хранилище, называемом хранилищем содержимого (Content Store или CS, как определено в параграфе 3.3 [16]). Если данные найдены, они отправляются запросившему и транзакция считается завершенной.

Если копии не найдено в кэше CS, выполняется поиск в таблице ожидающих запросов (Pending Interest Table или PIT, как определено в параграфе 3.3 [16]) для проверки наличия ожидающих запросов того же объекта содержимого. Если запроса не найдено, создаётся запись в таблице PIT с именем и интерфейсом, откуда получен запрос. Позднее это используется для отправки объекта содержимого, поскольку пакеты interest не включают поля источника, указывающего потребителя. Если запись для этого имени имеется в PIT, она обновляется включением входного интерфейса для этого запроса, а сам запрос отбрасывается.

После поиска в PIT выполняется поиск в таблице пересылки (Forwarding Information Base или FIB, как определено в параграфе 3.3 [16]) для выбора выходного интерфейса. FIB содержит список префиксов имён и соответствующих интерфейсов пересылки для отправки запроса в направлении узла пересылки (forwarder), владеющего копией запрошенных данных.

После извлечения копии данных она передаётся потребителям с использованием следов в записях PIT. Пересылающие узлы удаляют запись о состоянии из PIT при каждом выполнении запроса и могут сохранять данные в своих CS.

Пакеты данных содержат некие сведения для проверки целостности данных и подлинности источника, в частности, сведения о соответствии данных имени [19]. Это нужно потому, что аутентификация объекта очень важна для CCNx/NDN. Однако пересылающие узлы могут пропускать этот этак для повышения скорости обработки.

Важным аспектом CCNx/NDN является отсутствие сессии между потребителем и конкретным сервером. Фактически пересылающий узел или издатель (producer, как определено в параграфе 3.2 [16]), возвращающий объект содержимого, не знает о местоположении потребителя в сети, а тот не знает о местоположении узла, предоставившего содержимое. Теоретически это позволяет запросам interest следовать в сети по разным путям и даже по разным сетям.

4. Основы NC

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

Для простоты рассмотрим пример сквозного кодирования, где издатель и потребитель выполняют, соответственно, кодирование и декодирование элемента содержимого. Это сквозное кодирование в NC рассматривается как частный случай. Производитель делит содержимое на несколько блоков, называемых генерациями (generation). Кодирование и декодирование выполняется независимо для каждого блока (генерации). Предположим, что каждый блок содержит K исходных пакетов источника с одинаковым размером. Если размеры пакетов различаются, они дополняются нулями до большего. Для создания одного ремонтного пакета в неком блоке издатель линейно комбинирует K исходных пакетов источника, выполняя сложение и умножение с использованием вектора кодирования, содержащего K коэффициентов, которые случайно выбираются из некого конечного поля. Издатель может отвечать на запросы interest, отправляя исходные и ремонтные пакеты в поток содержимого (это называется систематическим кодированием), где ремонтные пакеты обычно применяются для восстановления потерянных исходных пакетов.

Ремонтные пакеты также можно применять для кодирования. Если пересылающие узлы знают каждый вектор кодирования и идентификатор генерации (далее generation ID) принятых ремонтных пакетов, они могут выполнить операцию кодирования (перекодирование), которая является наиболее отличительной чертой NC по сравнению с другими методами кодирования.

На стороне потребителя выполняется декодирование путём решения системы линейных уравнений, представленной векторами кодирования полученных исходных и ремонтных (возможно, лишь ремонтных) пакетов в рамках некой генерации (блока). Для получения всех исходных пакетов потребителю нужно не меньше K линейно независимых пакетов. Иными словами, потребитель должен получить хотя бы K линейно независимых пакетов данных (их называют инновационными). Поскольку приём линейно зависимого пакета данных бесполезен для декодирования, перекодированию следует создавать и представлять инновационные пакеты. Одно из основных преимуществ RLC состоит в том, что даже при конечном поле малого размера (например, q=2⁸), вероятность создания линейно зависимых пакетов пренебрежимо мала [9].

5. Преимущества NC и CCNx/NDN

Сочетание NC и CCNx/NDN может способствовать эффективному крупномасштабному распространению содержимого. По отдельности эти подходы обеспечивают похожие преимущества, такие как повышение производительности и отказоустойчивости. Различие состоит в том, что на транспортном уровне рассматривает поток содержимого как алгебраические данные, которые нужно комбинировать [7], а CCNx/NDN фокусируется на самом содержимом. Поскольку эти подходы дополняют друг друга, их сочетание было бы выгодно и естественно.

Коммуникации на основе имён в CCNx/NDN позволяют потребителям получать искомое содержимое без необходимости создавать и поддерживать сквозные каналы взаимодействия между узлами. Это облегчает использование сетевого кэширования, поиска и извлечения по нескольким путям, а также поддержку мобильности потребителей без необходимости обновлять сведения о местоположении и идентификаторе информации при переходах [1]. Кроме того, коммуникации на основе имён по своей сути поддерживают групповое взаимодействие, поскольку идентичные запросы interest объединяются пересылающими узлами.

NC может позволять транспортной системе CCNx/NDN эффективно распространять и кэшировать данные, связанные с извлечением по нескольким путям [14]. Использование извлечения по нескольким путям и кэширования в сети с помощью NC способствует не только более частому попаданию в кэш, но и повышению уровня анонимности каждого потребителя (данного потребителя может обслуживать набор возможных маршрутизаторов) [20]. Расширение осложняет злоумышленникам получение сведений о потребляемом другими содержимом, способствуя конфиденциальности кэшей. Были представлены другие варианты использования NC в CCNx/NDN, такие как распространение содержимого с кэшированием в сети [21] [22] [23], бесшовная мобильность потребителей [24] [25], малые задержки и потери при доставке видео-потоков [26]. С учётом этого следует рассмотреть интеграцию NC в CCNx/NDN.

6. Технические соображения

В этом разделе приведены соображения по использованию CCNx/NDN с NC с точки зрения сетевой архитектуры и протоколов. Документ фокусируется на NC с блочным кодированием.

6.1. Именование содержимого

Именованные объекты содержимого столь же важны в CCNx/NDN, как именованные хосты в современной сети Internet [19]. В этом параграфе представлены две возможные схемы именования.

6.1.1. Уникальные имена для пакетов NC

Каждый исходный и ремонтный пакет (далее, пакет NC) может иметь уникальное имя, как и каждый исходный объект содержимого в CCNx/NDN, а для работы PIT и CS обычно нужны уникальные имена, идентифицирующие пакеты NC. В качестве метода именования пакетов NC с учётом особенностей блочного кодирования можно использовать вектор кодирования и идентификатор генерации как часть имени объекта содержимого. Как и в [21], для идентификатора генерации g-id, размера генерации (блока) 4 и вектора кодирования (1,0,0,0) имя может иметь вид /CCNx.com/video-A/g-id/1000. Можно также применять некоторые другие идентификаторы, связанные со схемой кодирования. Например, может применяться идентификатор кодирования enc-id, задающий схему, как в /CCNx.com/video-A/enc-id/g-id/1000, определённом в FEC Framework (FECFRAME) [27]. Эта схема именования проста и может поддерживать доставку пакетов NC с такими же операциями в PIT/CS как для объектов содержимого.

При использовании схемы именования содержимого, подобной описанной здесь, запрос interest для пакета NC может иметь полное имя, включающее идентификатор генерации и вектор кодирования (/CCNx.com/video-A/g-id/1000) или только префикс имени, включающий лишь generation ID (/CCNx.com/video-A/g-id). В первом случае пересылающими просто выполняется точное сопоставление с PIT (как в CCNx/NDN). Потребитель способен указать и получить инновационный пакет, требуемый для успешного декодирования. Это может перенести генерацию вектора кодирования от пересылающего узла к потребителю.

Во втором случае требуется частичное сопоставление имени у пересылающего. Поскольку interest лишь с префиксом имени соответствует любому пакету NC с таким же префиксом, потребитель может сразу же получить пакет NC от соседнего CS (из сетевого кэша), не зная заранее векторов кодирования в кэшированных пакетах NC. Когда пакеты NC при передаче изменяются путём перекодирования в сети, выполняемого пересылающими, потребитель также может получить изменённые пакеты NC. Однако в отличие от первого случая у него может не быть достаточной свободы (см. параграф 6.2.3. Работа пересылающего). Для решения этой проблемы может потребоваться новый тип TLV в сообщениях interest для указания дополнительных сведений о кодировании, чтобы ограничить число получаемых пакетов NC. Например, это можно сделать путём задания векторов кодирования инновационных пакетов для потребителя (их называют матрицами декодирования) как в [14]. Это расширение может повлечь существенный рост размера пакетов interest, поэтому может оказаться полезным использование для векторов кодирования механизмов сжатия [28] [29]. Без таких сведений о кодировании, представляемых в interest, пересылающему придётся поддерживать записи о запросах interest, которые были выполнены ранее (см. 6.2.3. Работа пересылающего).

6.1.2. Неуникальные имена для пакетов NC

Пакет NC может иметь имя, указывающее, что это пакет NC, и переносить сведения о кодировании в поле метаданных внутри содержимого (т. е. имя включает тип данных, исходный или ремонтный пакет). Это было бы невыгодно для приложений, которым не нужно понимать содержимое пакета (payload). Из-за того, что несколько пакетов NC могут иметь одно имя, для потребителя требуется механизм получения инновационных пакетов. Как указано в параграфе 6.3. Кэширование в сети, требуется также механизм для поддержки множества инновационных пакетов в CS. Кроме того, при шифровании содержимого возникают дополнительные расчётные издержки.

6.2. Транспорт

Основанная на вытягивании (pull) функция запросов-откликов CCNx/NDN является там фундаментальным транспортным подходом — для одного запроса interest извлекается не более одного пакета данных. Это значит, что пересылающий или издатель не могут внедрить незапрошенные пакеты данных по своей инициативе. Считается важным соблюдение этого правила, поскольку нарушение 1) приведёт к атакам с отказом в обслуживании (DoS), 2) сделает непригодными имеющиеся подходы к управлению перегрузкой на основе этого правила и 3) снизит эффективность имеющихся подходов к мобильности потребителей. Таким образом, для применения NC в CCNx/NDN. Следует рассмотреть описанную ниже базовую операцию. Тем не менее, при нарушении правила указанные проблемы безопасности должны быть решены.

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

Не решён вопрос относительно возможности пересылающего выполнить перекодирование в сети для полученных транзитных пакетов данных или операции NC можно выполнять только для данных, которые соответствуют interest. В последнем случае кодирование или перекодирование выполняется для генерации пакета на лубом пересылающем узле, способном ответить на interest. Это возможно, когда каждый пакет NC имеет уникальное имя, а interest имеет полное имя. С другой стороны, если interest имеет частичное имя без сведений о векторе кодирования или несколько пакетов NC имеют одно имя, может возникнуть первый случай и перекодирование может происходить в любом месте сети, где возможно изменить полученный пакет NC и переслать его. Поскольку CCNx/NDN включает механизмы обеспечения целостности данных в процессе передачи, кодирование в сети будет вызывать сложности, связанные с обеспечением работы механизмов защиты целостности. Точно так же может быть полезно сетевое кэширование пакетов NC на пересылающих узлах, однако им потребуется тот или иной механизм для проверки пригодности пакетов NC (см. 9. Вопросы безопасности).

6.2.2. Работа потребителя

Чтобы воспользоваться преимуществами NC (возможно, связанными с кэшированием в сети), потребитель должен отправлять запросы interest, которые направляют пересылающего (или издателя) отвечать инновационными пакетами, когда они доступны. В случае, когда каждый пакет NC может иметь уникальное имя (как описано в параграфе 6.1. Именование содержимого), отправка interest с указанием уникального имени в g-id и вектора кодирования для пакета NC даёт потребителю возможность получить инновационный пакет, если такой доступен у некоторых пересылающих.

Чтобы задать точное имя пакета NC для извлечения, потребитель должен знать действительную схему именования. С практической точки зрения желательно, чтобы приложение потребителя автоматически создавало верные компоненты имени независимо от каких-либо спецификаций приложения. С этой целью приложение-потребитель может получить и указать (сослаться) манифест [17], указывающий объекты содержимого, включая пакеты NC, или использовать какой-либо спецификатор схемы кодирования как часть имени при создании компонентов имени в interest для запроса инновационных пакетов.

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

6.2.3. Работа пересылающего

Если пересылающий постоянно отвечает на входящие interest неинновационными пакетами, потребители не могут декодировать и получить исходные пакеты. Эта проблема возникает, когда 1) входящие interest для пакетов NC не задают некоторые параметры кодирования, такие как векторы кодирования для применения, и 2) у пересылающего нет достаточного числа линейно независимых пакетов NC (возможно в CS) для использования при перекодировании. В этом случае пересылающий должен определить, может ли он генерировать инновационные пакеты для пересылки на интерфейсы, с которых поступил запрос interest. Подход к решению этой задачи состоит в том, что пересылающий узел ведёт учёт interest для конкретных имён, generation ID и входных интерфейсов, чтобы записать число уже предоставленных степеней свободы [21]. Поскольку такая схема требует поддержки состояний (возможно, и таймеров) на узлах пересылки, должны учитываться вопросы расширяемости и практичности. Кроме того, потребоваться некоторые транспортные механизмы для обнаружения и восстановления потерь в сети [25][26] на узлах пересылки, а также управляемые потребителем механизмы для быстрого восстановления потерь и достижения преимуществ NC. Если пересылающий не может вернуть соответствующий инновационный пакет из локального хранилища содержимого или создать «на лету» перекодированный пакет, являющийся инновационным, важно, чтобы пересылающий не просто возвращал неинновационный пакет, а выполнял поиск пересылки в своей базе FIB и пересылал запрос interest в направлении издателя или восходящего пересылающего узла, способного обеспечить инновационный пакет. В этом контексте для эффективного и быстрого поиска инновационного пакета следует рассматривать подобающую настройку FIB и эффективную стратегию пересылки interest.

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

6.2.4. Работа издателя

Перед выполнением NC для конкретного содержимого в CCNx/NDN издатель должен обеспечить (отвечает за) разделение всего содержимого на более мелкие объекты для предотвращения фрагментации пакетов, которая может вызывать избыточную обработку и снижать пропускную способность. Размер содержимого должен соответствовать допустимому размеру пакетов, чтобы избежать фрагментирования в сети CCNx/NDN. Издатель выполняет операции кодирования для набора небольших объектов содержимого и именования для пакетов NC.

Если производитель берет на себя роль ведущего при определении применяемых векторов кодирования при генерации пакетов NC, имеется 3 общих стратегии именования и создания пакетов NC, указанные ниже.

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

2. Издатель определяет векторы кодирования и генерирует пакеты NC после получения запросов interest, задающих пакеты, которые потребитель хочет получить.

3. Схема именования для задания векторов кодирования и соответствующих пакетов NC явно представлена через манифест (например, FLIC [30]), который может быть получен потребителем и использован для выбора среди доступных векторов кодирования и соответствующих пакетов, чтобы передать соответствующие interest.

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

Общим преимуществом двух первых подходов к сквозному кодированию является то, что при добавлении издателем подписей к пакетам NC становится возможной проверка пригодности данных на всем протяжении (как в случае работы CCNx/NDN без NC). Третий подход с использованием манифеста компенсирует дополнительную задержку, вносимую необходимостью извлечения манифеста тем, что подписывается лишь манифест, а не отдельные пакеты NC.

6.2.5. Совместимость с прежними версиями

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

6.3. Кэширование в сети

Кэширование является полезным методом повышения пропускной способности и снижения задержки в разных приложениях. Сетевое кэширование в CCNx/NDN, по сути, обеспечивает поддержку на сетевом уровне и является выгодным за счёт вовлечения NC для обеспечения эффективной групповой передачи [31], извлечения данных по нескольким путям [21] [24] и быстрого восстановления потерь [26]. Однако требуется рассмотреть несколько вопросов.

Как правило ёмкость CS ограничена и политика кэширования влияет на производительность потребителя [32] [33] [34]. Поэтому для пересылающих очень важно определить, какие объекты содержимого следует кэшировать, а какие — отбрасывать. Поскольку чувствительным к задержкам приложениям часто не требуется долговременное кэширование в сети из-за ограничений, связанных с реальным масштабом времени, пересылающие должны знать о необходимости кэширования полученных объектов содержимого для сохранения объёма кэша. В CCNx это можно сделать установкой рекомендуемого времени кэширования (Recommended Cache Time или RCT) в необязательном заголовке пакета данных на стороне издателя. RCT служит рекомендацией для CS-кэша спри определении срока хранения кэшированного объекта. При RCT = 0 пересылающий считает кэширование бесполезным, а при больших значениях RCT кэшировать объекты на длительное время.

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

6.4. Беспрепятственная мобильность потребителей

Важным свойством CCNx/NDN является отсутствие сессий, позволяющее потребителю и пересылающим передавать множество запросов interest параллельно в направлении разных копий содержимого с одновременным асинхронным использованием нескольких интерфейсов. За счёт извлечения данных по нескольким путям потребитель может получить содержимое из нескольких копий, распространяемое с использованием суммарной производительности нескольких интерфейсов. Для связывания нескольких копий потребитель может воспользоваться тем или иным механизмом адаптации потокового видео [24] или контроль перегрузок для получения содержимого [35].

NC добавляет в CCNx уровень надёжности распределенным и асинхронным способом, поскольку в NC обеспечивается механизм, гарантирующий для нескольких запросов interest, переданных параллельно разным копиям содержимого, получение инновационных пакетов даже в случаях потери пакетов на некоторых путях к этим копиям. Это относится к перемещению (мобильности) потребителя [24], когда тот может получить дополнительные степени свободы с любым инновационным пакетом, если в процессе перемещения имеется хотя бы один доступный интерфейс. Стратегия пересылки interest у потребителя (возможно, и у пересылающего) будет нужна потребителю для получения инновационных пакетов с сохранением беспрепятственной мобильности.

7. Проблемы

В этом разделе представлены некоторые проблемы и направления исследования, связанные с применением NC в CCNx/NDN.

7.1. Адаптация свёрточного кодирования

К настоящему времени предложено несколько подходов к блочному кодированию, тем не менее, в CCNx/NDN до сих пор нет достаточного рассмотрения и применения свёрточного кодирования (например, со скользящим или эластичным окном). Свёрточное кодирование часто подходит для случаев, когда нужна частично или полностью гарантированная доставка непрерывного потока данных, особенно в реальном масштабе времени. Как и в [36], на основе сквозного кодирования для непрерывного потока содержимого было бы выгодно применять кодирование со скользящим окном в CCNx/NDN. В этом случае издатель должен соответствующим образом установить параметры кодирования и сообщить сведения потребителям, а те должны передавать запросы interest, дополненные информацией о состоянии приёма и декодирования данных. Поскольку CCNx/NDN применяет поэтапное (hop-by-hop) состояние пересылки, было бы целесообразно обсудить и исследовать применение свёрточного кодирования в стиле hop-by-hop и возможные преимущества. В частности, для случаев, когда сетевое перекодирование может происходить в узлах пересылки, потребуется управление окном кодирования и CS, для чего следует соответствующие возможности и практичность.

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

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

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

7.3. Безопасность

Хотя CCNx/NDN создаёт новые проблемы безопасности на сетевом уровне, отличающемся от традиционных сетей IP, такие как отравление кэша, атаки с загрязнением и DoS-атаки с использованием пакетов interest, некоторые подходы в обеспечению безопасности уже представлены [19] [38]. Применение NC в CCNx/NDN связано с двумя аспектами безопасности, которые требуется учитывать.

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

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

7.4. Расширяемость маршрутизации

В CCNx/NDN протокол маршрутизации по именам без процесса распознавания (resolution) упрощает процесс маршрутизации и сокращает общую задержку. В маршрутизации IP рост размера таблиц маршрутизации стал проблемой. Таким образом, необходимо применять схему иерархического именования, чтобы улучшить расширяемость маршрутизации за счёт агрегирования маршрутных данных.

Для реализации преимуществ NC потребителям нужно эффективно получать инновационные пакеты с применением механизмов CCNx/NDN для извлечения по нескольким путям. Это требует наличия эффективного механизма маршрутизации для подобающего заполнения таблиц FIB, а также эффективной пересылки запросов interest. Такая координация может препятствовать расширяемости маршрутизации. Будет сложно обеспечить эффективную и расширяемую маршрутизацию запросов interest для пакетов NC с одновременным упрощением процесса маршрутизации.

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

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

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

Перекодирование в сети является отличительной чертой NC. Запрашиваться и применяться (возможно, сохраняться) должны лишь действительные пакеты NC, созданные перекодированием в сети. Для решения этой задачи имеется несколько подходов. Во-первых, это проверка подписей с возможностью использования нескольких подписей. Это позволяет иметь свой уникальный ключ подписи не только исходному издателю содержимого, но и некоторым пересылающим, ответственным за перекодирование в сети. Каждый пересылающий узел группы подписывает созданный недавно пакет NC, чтобы другие узлы могли проверить данные по этой подписи. CS может проверять подписи пакетов NC перед их сохранением, чтобы не кэшировать недействительные пакеты. Во-вторых, потребители могут вносить ограничения для правил сопоставления, используя только имя запрошенных данных. Неоднозначность запросов interest можно устранить, задавая имя и идентификатор ключа (дайджест открытого ключа издателя) для сопоставления с запрошенными данными. Такое ограничение KeyId встроено в CCNx [17]. Пересылаются и хранятся в CS лишь пакеты, соответствующие interest и KeyId, что снижает возможности отравления кэша. Кроме того, в CCNx имеется правило, которому подчиняются CS, для предотвращения усиления непригодных данных. Если для interest задано ограничение KeyId, CS недопустимо отвечать на запрос, пока нет уверенности в корректности подписи соответствующего объекта содержимого. Если CS не может проверить подпись, запрос может считаться отсутствующим в кэше с пересылкой его восходящим (вышестоящим) узлам пересылки. Третьим подходом является поддержка цепочек сертификатов (возможно, без удостоверяющего центра) с использованием того или иного механизма (например, [39]) организации доверенного пути доставки. Этот подход использует механизм поэтапной аутентификации, в котором выполняется сбор сертификатов, объединённый с пересылкой, для создания цепочки сертификатов, обеспечивающей доверие к пути доставки.

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

Издатели и пересылающие должны уделять пристальное внимание DoS-атакам, нацеленным на создание высокой нагрузки операций NC с использованием запросов interest для пакетов NC. Для смягчения таких атак пересылающие узлы могут ограничивать скорость. Например, они могут отслеживать рост PIT для пакетов NC по содержимому с целью обнаружения атак и ограничения при необходимости частоты прибытия запросов interest. Если приложение NC хочет защитить запрос interest, считающийся активатором NC, для предотвращения таких атак, ему следует рассмотреть применение шифрования и явного протокола.

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

[1] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, «Networking Named Content», Proc. CoNEXT, ACM, DOI 10.1145/1658939.1658941, December 2009, <https://doi.org/10.1145/1658939.1658941>.

[2] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, «Named data networking», ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, DOI 10.1145/2656877.2656887, July 2014, <https://doi.org/10.1145/2656877.2656887>.

[3] Gkantsidis, C. and P. Rodriguez, «Cooperative Security for Network Coding File Distribution», Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2006.233, April 2006, <https://doi.org/10.1109/INFOCOM.2006.233>.

[4] Cai, N. and R. Yeung, «Secure network coding», Proc. International Symposium on Information Theory (ISIT), IEEE, DOI 10.1109/ISIT.2002.1023595, June 2002, <https://doi.org/10.1109/ISIT.2002.1023595>.

[5] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A. Toledo, «Secure Network Coding for Multi-Resolution Wireless Video Streaming», IEEE Journal of Selected Area (JSAC), vol. 28, no. 3, DOI 10.1109/JSAC.2010.100409, April 2010, <https://doi.org/10.1109/JSAC.2010.100409>.

[6] Vilea, J., Lima, L., and J. Barros, «Lightweight security for network coding», Proc. ICC, IEEE, DOI 10.48550/arXiv.0807.0610, May 2008, <https://doi.org/10.48550/arXiv.0807.0610>.

[7] Koetter, R. and M. Medard, «An Algebraic Approach to Network Coding», IEEE/ACM Transactions on Networking, vol. 11, no. 5, DOI 10.1109/TNET.2003.818197, October 2003, <https://doi.org/10.1109/TNET.2003.818197>.

[8] Vyetrenko, S., Ho, T., Effros, M., Kliewer, J., and E. Erez, «Rate regions for coherent and noncoherent multisource network error correction», Proc. International Symposium on Information Theory (ISIT), IEEE, DOI 10.1109/ISIT.2009.5206077, June 2009, <https://doi.org/10.1109/ISIT.2009.5206077>.

[9] Wu, Y., Chou, P., and K. Jain, «A comparison of network coding and tree packing», Proc. International Symposium on Information Theory (ISIT), IEEE, DOI 10.1109/ISIT.2004.1365182, June 2004, <https://doi.org/10.1109/ISIT.2004.1365182>.

[10] Ho, T., Medard, M., Koetter, R., Karger, D., Effros, M., Shi, J., and B. Leong, «A Random Linear Network Coding Approach to Multicast», IEEE Trans. on Information Theory, vol. 52, no. 10, DOI 10.1109/TIT.2006.881746, October 2006, <https://doi.org/10.1109/TIT.2006.881746>.

[11] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. Ramchandran, «Network Coding for Distributed Storage Systems», IEEE Trans. Information Theory, vol. 56, no.9, DOI 10.1109/TIT.2010.2054295, September 2010, <https://doi.org/10.1109/TIT.2010.2054295>.

[12] Gkantsidis, C. and P. Rodriguez, «Network coding for large scale content distribution», Proc. Infocom, IEEE, DOI 10.1109/INFCOM.2005.1498511, March 2005, <https://doi.org/10.1109/INFCOM.2005.1498511>.

[13] Seferoglu, H. and A. Markopoulou, «Opportunistic Network Coding for Video Streaming over Wireless», Proc. Packet Video Workshop (PV), IEEE, DOI 10.1109/PACKET.2007.4397041, November 2007, <https://doi.org/10.1109/PACKET.2007.4397041>.

[14] Montpetit, M., Westphal, C., and D. Trossen, «Network Coding Meets Information-Centric Networking: An Architectural Case for Information Dispersion Through Native Network Coding», Proc. Workshop on Emerging Name-Oriented Mobile Networking Design (NoM), ACM, DOI 10.1145/2248361.2248370, June 2012, <https://doi.org/10.1145/2248361.2248370>.

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

[16] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, «Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology», RFC 8793, DOI 10.17487/RFC8793, June 2020, <https://www.rfc-editor.org/info/rfc8793>.

[17] Mosko, M., Solis, I., and C. Wood, «Content-Centric Networking (CCNx) Semantics», RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.

[18] Mosko, M., Solis, I., and C. Wood, «Content-Centric Networking (CCNx) Messages in TLV Format», RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.

[19] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, «Information-Centric Networking (ICN) Research Challenges», RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.

[20] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. Xie, «Privacy-Aware Multipath Video Caching for Content-Centric Networks», IEEE Journal on Selected Areas in Communications (JSAC), vol. 38, no. 8, DOI 10.1109/JSAC.2016.2577321, June 2016, <https://doi.org/10.1109/JSAC.2016.2577321>.

[21] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, «NetCodCCN: a network coding approach for content-centric networks», Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2016.7524382, April 2016, <https://doi.org/10.1109/INFOCOM.2016.7524382>.

[22] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. Westphal, «An Optimal Cache Management Framework for Information-Centric Networks with Network Coding», Proc. Networking Conference, IFIP/IEEE, DOI 10.1109/IFIPNetworking.2014.6857127, June 2014, <https://doi.org/10.1109/IFIPNetworking.2014.6857127>.

[23] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. Westphal, «A Minimum Cost Cache Management Framework for Information-Centric Networks with Network Coding», Computer Networks, Elsevier, DOI 10.1016/j.comnet.2016.08.004, August 2016, <https://doi.org/10.1016/j.comnet.2016.08.004>.

[24] Ramakrishnan, A., Westphal, C., and J. Saltarin, «Adaptive Video Streaming over CCN with Network Coding for Seamless Mobility», Proc. International Symposium on Multimedia (ISM), IEEE, DOI 10.1109/ISM.2016.0054, December 2016, <https://doi.org/10.1109/ISM.2016.0054>.

[25] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, N., and X. Zeng, «Leveraging ICN In-network Control for Loss Detection and Recovery in Wireless Mobile networks», Proc. of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2984361, September 2016, <https://doi.org/10.1145/2984356.2984361>.

[26] Matsuzono, K., Asaeda, H., and T. Turletti, «Low Latency Low Loss Streaming using In-Network Coding and Caching», Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2017.8057026, May 2017, <https://doi.org/10.1109/INFOCOM.2017.8057026>.

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

[28] Thomos, N. and P. Frossard, «Toward One Symbol Network Coding Vectors», IEEE Communications Letters, vol. 16, no. 11, DOI 10.1109/LCOMM.2012.092812.121661, November 2012, <https://doi.org/10.1109/LCOMM.2012.092812.121661>.

[29] Lucani, D., Pedersen, M., Ruano, D., Sørensen, C., Heide, J., Fitzek, F., and O. Geil, «Fulcrum Network Codes: A Code for Fluid Allocation of Complexity», DOI 10.48550/arXiv.1404.6620, April 2014, <https://doi.org/10.48550/arXiv.1404.6620>.

[30] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, «File-Like ICN Collections (FLIC)», Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-03, 7 November 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>.

[31] Maddah-Ali, M. and U. Niesen, «Coding for Caching: Fundamental Limits and Practical Challenges», IEEE Communications Magazine, vol. 54, no. 8, DOI 10.1109/MCOM.2016.7537173, August 2016, <https://doi.org/10.1109/MCOM.2016.7537173>.

[32] Perino, D. and M. Varvello, «A reality check for content centric networking», Proc. SIGCOMM Workshop on Information-centric networking (ICN ’11), ACM, DOI 10.1145/2018584.2018596, August 2011, <https://doi.org/10.1145/2018584.2018596>.

[33] Podlipnig, S. and L. Böszörmenyi, «A Survey of Web Cache Replacement Strategies», Proc. ACM Computing Surveys, vol. 35, no. 4, DOI 10.1145/954339.954341, December 2003, <https://doi.org/10.1145/954339.954341>.

[34] Rossini, G. and D. Rossi, «Evaluating CCN multi-path interest forwarding strategies», Elsevier Computer Communications, vol. 36, no. 7, DOI 10.1016/j.comcom.2013.01.008, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.008>.

[35] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, «MIRCC: Multipath-aware ICN Rate-based Congestion Control», Proc. Conference on Information-Centric Networking (ICN), ACM, DOI 10.1145/2984356.2984365, September 2016, <https://doi.org/10.1145/2984356.2984365>.

[36] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and V. Roca, «On-the-Fly Erasure Coding for Real-Time Video Applications», IEEE Transactions on Multimedia, vol. 13, no. 4, DOI 10.1109/TMM.2011.2126564, August 2011, <https://doi.org/10.1109/TMM.2011.2126564>.

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

[38] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, «Information-Centric Networking: Evaluation and Security Considerations», RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.

[39] Li, R., Asaeda, H., and J. Wu, «DCAuth: Data-Centric Authentication for Secure In-Network Big-Data Retrieval», IEEE Trans. on Network Science and Engineering, vol. 7, no. 1, DOI 10.1109/TNSE.2018.2872049, September 2018, <https://doi.org/10.1109/TNSE.2018.2872049>.

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

Авторы признательны членам ICNRG и NWCRG, особенно Marie-Jose Montpetit, David Oran, Vincent Roca, Thierry Turletti за их значимые комментарии и предложения.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                      P. Fältström
Request for Comments: 9285                                        Netnod
Category: Informational                                     F. Ljunggren
ISSN: 2070-1721                                                    Kirei
                                                          D.W. van Gulik
                                                              Webweaving
                                                             August 2022

The Base45 Data Encoding

Кодирование данных Base45

PDF

Аннотация

Этот документ описывает схему кодирования Base45, основанную на схемах Base64, Base32, Base16.

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

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

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

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

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

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

QR-код применяется для представления текста в форме графического образа. В зависимости от символов текста существуют разные варианты кодирования QR, например, численный (Numeric), алфавитно-цифровой (Alphanumeric), байтовый (Byte). Даже в байтовом режиме типичный считыватель кода QR пытается интерпретировать последовательность байтов как текст в кодировке UTF-8 или ISO/IEC 8859-1. Таким образом, коды QR нельзя применять для непосредственного кодирования произвольных двоичных данных и сначала такие данные нужно преобразовать в подходящий текст. По сравнению с имеющимися схемами кодирования Base64, Base32 и Base16, описанными в [RFC4648], описанная здесь схема Base45 обеспечивает более компактный код QR.

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

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

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

3. Интерпретация кодированных данных

Кодированные данные интерпретируются в соответствии с [RFC4648], но применяется иной алфавит.

4. Кодирование Base45

Возможности сохранения двоичных данных в QR-коде ограничены. На практике двоичные данные представляются символами в соответствии с одним из режимов, определённых в стандартных кодах QR. Постейший режим называется алфавитно-цифровым (см. параграф 7.3.4 и таблицу 2 в [ISO18004]). К сожалению в режиме Alphanumeric используется 45 различных символов, что делает кодировки Base32 и Base64 неэффективными.

Применяется 45-символьное подмножество US-ASCII — 45 символов пригодны для кода QR в режиме Alphanumeric (см. параграф 7.3.4 и таблицу 2 в [ISO18004]). Base45 представляет 2 байта тремя символами, тогда как Base64 представляет 3 байта четырьмя символами.

При кодировании двух байтов [a, b] они должны интерпретироваться как число n с базой 256, т. е. как целое число без знака размером 16 битов — n = (a * 256) + b. Это число n конвертируется ы [c, d, e] с базой 45 так, что n = c + (d * 45) + (e * 45 * 45). Отметим, что порядок c, d и e выбран так, чтобы самый левых элемент [c] был наименее значимым. Для значений c, d, e выполняется поиск по таблице 1, дающий 3 строки символов. При декодировании процесс обращается.

При кодировании одного байта [a] он должен интерпретироваться как число с базой 256, т. е. как 8-битовое целое число без знака. Это число должно преобразовываться в пару чисел с базой 45 [c d] так, что a = c + (45 * d). Для значений c и d выполняется поиск по таблице 1, дающий 2 строки символов.

Строка байтов [a b c d … x y z] с произвольным содержимым и размером должна кодироваться, как описано здесь. Биты слева направо должны кодироваться в соответствии с приведённым выше описанием. При чётном числе кодируемых байтов кодированная форма имеет размер кратный 3. При нечётном числе кодируемых байтов последний (правый) байт должен кодироваться двумя символами, как указано выше.

При декодировании строк Base45 операции выполняются в обратном порядке.

4.1. Когда Base45 подходит и не подходит

Если двоичные данные предназначены для сохранения в коде QR, предлагаемым механизмом является режим Alphanumeric, использующий 11 битов на 2 символа, как указано в параграфе 7.3.4 [ISO18004]. Индикатор режима расширенной интерпретации канала (Extended Channel Interpretation или ECI) для такого кодирования имеет значение 0010.

Если данные предназначены для передачи иным транспортом, вместо Base45 следует применять соответствующее транспортное кодирование. Например, не рекомендуется сначала использовать Base45, затем кодировать результат с помощью Base64, если данные передаются по электронной почте. В таком случае следует исключить кодирование Base45 и сразу кодировать данные с посощью Base64.

4.2. Используемый в Base45 алфавит

Для режима Alphanumeric определено использование 45 символов, образующих алфавит, как показано в таблице 1.

Таблица 1. Алфавит Base45.