RFC 9315 Intent-Based Networking – Concepts and Definitions

Internet Research Task Force (IRTF)                             A. Clemm
Request for Comments: 9315                                     Futurewei
Category: Informational                                     L. Ciavaglia
ISSN: 2070-1721                                                    Nokia
                                                         L. Z. Granville
                         Federal University of Rio Grande do Sul (UFRGS)
                                                             J. Tantsura
                                                               Microsoft
                                                            October 2022

Intent-Based Networking – Concepts and Definitions

Сеть на основе намерений – концепции и определения

PDF

Аннотация

Сети на основе намерений (Intent или Intent-Based) берут отрасль штурмом. Однако термины, связанные с такими сетями, часто применяются расплывчато и непоследовательно, во многих случаях перекрываясь и смешиваясь с другими концепциями (например, политика – policy). В этом документе разъяснён термин «намерение» (intent) и дан обзор связанной с ним функциональности. Цель состоит в содействии общему пониманию терминов, концепций и функциональности, которые могли бы послужить основой для дальнейших определений исследовательских и инженерных задач, а также их решения.

Документ является результатом работы группы IRTF Network Management Research Group (NMRG) и отражает согласованное мнение группы, получив множество подробных положительных отзывов от участников группы. Документ публикуется с информационными целями.

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

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

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

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

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

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

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

Оглавление

Исключено в версии HTML.

1. Введение

Этот документ является результатом работы исследовательской группы IRTF Network Management (NMRG) и отражает согласованную точку зрения RG, прошедшую рецензирование и получившую поддержку многих участников. Документ публикуется с информационными целями.

В прошлом интерес к управлению и операциям в рамках IETF был сосредоточен на характеристиках отдельных сетей и устройств. В стандартизации акцент обычно был смещён на инструменты управления, которые должны предоставляться сетевым устройствам. Ярким примером служит управление на основе SNMP [RFC3411] и более 200 MIB, заданных IETF за эти годы. Более свежие примеры включают определения моделей данных YANG [RFC7950] для таких аспектов, как настройка интерфейсов, списков управления доступом (Access Control List или ACL) и Syslog.

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

В соответствии с этим в IETF начали заниматься аспектами сквозного управления, выходящими за рамки отдельных изолированных устройств. Примеры включают задание моделей YANG для топологии сети [RFC8345] или введение моделей служб, применяемых системами оркестровки и контроллерами [RFC8309]. Большой интерес вызвало обсуждение вопросов самоуправления сетей в рабочей группе ANIMA. Такие сети движимы желанием снизить операционные расходы и упростить управление сетью в целом, что вступает в противоречие с необходимостью управлять одним устройством и одной функцией за раз. Хотя самоуправляемые сети предназначены для демонстрации свойств «самоуправления» (self-management), они по-прежнему требуют действий оператора или внешней системы для обеспечения операционных рекомендаций и сведений о целях, задачах и экземплярах служб, которые сеть должна обслуживать.

Эти входные данные и операционные рекомендации обычно называют намерениями (intent), а сеть, позволяющую операторам предоставить свои данные в форме намерений, – сетью на основе намерений (Intent-Based Network или IBN). Сеть, помогающую реализовать намерения, называют основанной на намерениях системой (Intent-Based System или IBS). Такие системы могут по разному проявлять себя, например, как контроллер, система управления, реализованная в виде приложения, которое работает на сервере или группе серверов, или набор распределенных в сети функций, совместно реализующих основанную на намерениях функциональность.

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

Такое представление стало популярным в отрасли и привело к разработке множества решений, предлагающий управление на основе намерений (Intent-Based Management), обещающее сервис-провайдерам целостное управление сетями с высоким уровнем абстракций как системой, состоящей из соединённых компонентов, а не набора независимых устройств (соединённых между собой). Такие предложения включают IBN и IBS (с полным жизненным циклом намерений), контроллеры программно управляемых сетей (Software-Defined Network или SDN), обеспечивающие единую точку управления и администрирования для сети, а также системы управления сетью и системы поддержки операций (Operations Support System или OSS).

Давно признано, что комплексные решения для управления не могут работать лишь на уровне отдельных устройств и конфигураций нижнего уровня. В этом смысле представление намерений не является совсем новым. В прошлом модель ITU-T для управления телекоммуникационной сетью (Telecommunications Management Network или TMN) представляла набор уровней управления, определяющий иерархию управления для сетевых элементов, сети, сетевых служб и бизнеса [M3010]. Операционные цели высокого уровня распространяются в модели сверху вниз. Связанная иерархия абстракций имеет решающее значение для разложения комплексного управления на отдельные области задач. Эта иерархия абстракций сопровождается информационной иерархией, которая на нижнем уровне касалась сведений, относящихся к конкретным устройствам, а на верхних уровнях включала, например, экземпляры сквозного сервиса. Аналогично концепция управления на основе правил (Policy-Based Network Management или PBNM) долгое время расхваливала возможность позволить пользователям2 управлять сетями путём задания высокоуровневых правил управления, при этом системы управления автоматически «толковали» (rendering) эти правила, т. е. переводили их в конфигурации нижнего уровня и логику управления.

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

Следует отметить, что формулировка связанных с IBN исследовательских проблем выходит за рамки документа. Однако следует признать, что сети IBN стали важной темой в сообществе исследователей. Согласно IEEE Xplore [IEEEXPLORE] по состоянию на декабрь 2021 г за 10 лет с 2012 г. было опубликовано 1138 с термином intent, из которых 411 конкретно посвящены сетям. Только за период с 2020 г. было опубликовано 316 статей о «намерениях» и 153 – о сетях на основе намерений. Кроме того, проводятся семинары, посвящённые этой теме, такие как IEEE International Workshop on Intent-Based Networking [WIN21], а также специальные выпуски журналов [IEEE-TITS21]. Обзор текущих исследований представлен в [PANG20], где среди наиболее важных исследовательских задач указаны такие вопросы, как трансляция и понимание намерений, интерфейсы и безопасность.

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

ACL

Access Control List – список управления доступом.

API

Application Programming Interface – интерфейс с прикладными программами.

IBA

Intent-Based Analytics – основанная на намерениях аналитика. Аналитика, определённая и выведенная из намерений пользователей и служащая для проверки предусмотренного состояния.

IBN

Intent-Based Network – сеть на базе намерений. Сеть, управляемая с использованием намерений.

IBS

Intent-Based System – система на базе намерений. Система, поддерживающая функции управления с помощью намерений.

Intent – намерения

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

Intent-Based Management – управление на базе намерений

Концепция управления на основе концепции намерений.

PBNM

Policy-Based Network Management – управление сетью на основе правил.

PDP

Policy Decision Point – точка принятия решений по правилам.

PEP

Policy Enforcement Point – точка применения правил (политики).

Policy – правила (политика)

Набор правил, определяющих выбор поведения системы.

Service Model – модель сервиса

Модель, представляющая услугу, которую сеть предоставляет пользователям.

SsoT

Single Source of Truth – единая точка доверия. Функциональный блок системы IBN, нормализующий намерения пользователей и служащий единым источником данных для нижележащих уровней.

Statement of Intent – заявление о намерениях

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

SvoT

Single Version of Truth – единая версия доверия.

User – пользователь

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

3. Концепции

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

3.1. Намерения и управление на их основе

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

Термин intent был впервые введён в контексте самоуправляемых сетей (Autonomic Network), где он был определён как «абстрактная политика высокого уровня, применяемая для работы сети» [RFC7575]. В соответствии с этим определением намерения являются конкретным типом политики, предоставляемым пользователем для обеспечения руководства самоуправляемой сетью, которая в остальном работает без привлечения людей. Однако, чтобы термин «намерения» не рассматривался как синоним политики, нужно чётко указать отличие намерений от иных правил.

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

Управление на основе намерений (IBM) направлено на создание сетей, которые проще поддерживать и эксплуатировать и которые требуют минимального вмешательства извне. Сети (даже самоуправляемые) не являются ясновидящими и не могут автоматически узнавать, какие операционные цели и экземпляры сетевых служб нужно поддерживать. Иными словами, они не знают намерений провайдера, придающих смысл существованию сети. Все ещё требуется указывать сетям, что собой представляют такие намерения. При этом концепция намерений не ограничивается сетями с самоуправлением, такими как сети с автономной (самоуправляемой) плоскостью управления (Autonomic Control Plane) [RFC8994], а применимы к любым сетям.

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

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

  • Функциональная абстракция от конкретной логики поддержки и управления. Пользователям не нужно заботиться даже о способах достижения целей. Указанное является желаемым результатом, при этом IBS автоматически определяет действия (например, с использованием алгоритма или применением набора правил, выведенного из намерений) для достижения результата.

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

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

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

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

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

  • Генерировать на месте данные эксплуатации, администрирования и поддержки (Operations, Administration, and Maintenance или OAM) и сетевой телеметрии для последующего автономного анализа при каждом наблюдении значительных флуктуаций задержки на пути (выход за рамки события-условия-действия без задания степени значимости и собираемых данных).

  • Направлять трафик в космической сети (Space Information Network) так, чтобы минимизировать зависимость от стратостатов, если предполагаемым получателем не является самолёт (не задан способ достижения, экстраполяция сценариев из [PANG20]).

  • Для услуги «умный город» обеспечить использование сигналами светофором выделенных и резервируемых «срезов» (slice), чтобы избежать «общей судьбы» (желаемый результат с набором ограничений и дополнительной рекомендацией без указания способа достижения, экстраполяция сценария из [GHARBAOUI21]).

Ниже приведены примеры, не являющиеся выражением намерений (на естественном языке для простоты).

  • Настроить на данном интерфейсе адрес IP (это настройка устройства и манипулирование «кнопками»).

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

  • Настроить VPN с туннелем между A и B по пути P (это настройка сервиса).

  • Запретить трафик к префиксу P1, если он не исходит от префикса P2 (правило доступа или межсетевого экрана, а не намерение).

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

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

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

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

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

Имеются другие определения намерений, такие как [TR523]. Намерения определяются там просто как декларативный интерфейс, обычно предоставляемый контроллером. Это предполагает наличие централизованной функции, преобразующей намерения в правила или инструкции нижнего уровня и организует их в сети. Хотя это и является одним из вариантов реализации, представленное здесь определение имеет более широкий охват и устремления, поскольку оно подчёркивает важность управления сетью путём задания желаемых результатов без указания конкретных шагов по их достижению. API-интерфейс контроллера, который просто обеспечивает абстракцию на уровне сети, более ограничен и не обязательно задаёт намерения. Восприятие и распознавание намерений не обязательно выполняется чрез API, основанный на вызове функций и простых взаимодействиях запрос-отклик, а может включать иные типы взаимодействия человека с машиной, такие как диалог для разъяснения и уточнения запросов.

3.2. Связанные концепции

3.2.1. Модели сервиса

Модель сервиса – это модель, представляющая услугу, обеспечиваемую пользователю сетью. В соответствии с [RFC8309] модель сервиса описывает услугу и её параметры независимым от реализации переносимым способом, который можно применять независимо от оборудования и операционной среды, где реализована услуга. Различают две категории – модель обслуживания клиентов (Customer Service Model) описывает экземпляр предоставляемой клиенту услуги, возможно требующей заказа, а модель предоставления услуги (Service Delivery Model) описывает реализацию услуги в имеющейся сетевой инфраструктуре.

Примерами могут служить услуги L3 VPN [RFC8299], Network Slice [NETWORK-SLICE] или локальный доступ в Internet. Модели сервиса представляют экземпляры служб как самостоятельные сущности. Службы имеют свои параметры, действия и жизненные циклы. Обычно экземпляр службы может быть привязан к конкретным пользователям коммуникационных услуг, которым могут быть выставлены счета за предоставляемые услуги.

Создание службы обычно включает несколько аспектов, указанных ниже.

  • Пользователь (или северная система) определяет и/или запрашивает создание экземпляра службы.

  • Выделяются ресурсы (адреса IP, номера AS, пулы VLAN или VxLAN, интерфейсы, полоса, память).

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

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

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

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

Созданные экземпляры моделей услуг отображаются на низкоуровневые модели сетей и устройств, например, экземпляры путей или конкретных конфигураций портов. Модель сервиса обычно включает также уровня служб и зависимости от нижележащих сетевых ресурсов, требуемых для предоставления услуги. Это упрощает управление, позволяя следовать зависимостям в действиях по устранению неполадок и анализу влияния, когда события в сети оцениваются с точки зрения воздействия на службы и клиентов. Службы обычно организуются и предоставляются «сверху вниз», что также упрощает отслеживание назначения сетевых ресурсов (композиция), а поиск и устранение неполадок выполняется «снизу вверх» (декомпозиция). Модели сервиса могут быть связаны с другими данными, не относящимися к сети, но обеспечивающими бизнес-контекст. Это включает сведения о клиентах (например, информация для выставления счетов), заказы услуг, каталоги служб, тарифы, договоры на обслуживание и соглашения об уровне обслуживания (Service Level Agreement или SLA), включая договорные соглашения по корректирующим действиям.

[SERVICE-MAPPING-YANG] служит примером модели данных, обеспечивающей отображение моделей обслуживания клиентов (например, L3VPN Service Model) на модели организации трафика (Traffic Engineering или TE, например, TE Tunnel или the Abstraction and Control of Traffic Engineered Networks Virtual Network).

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

3.2.2. Политика и управление сетью на её основе

Управление сетью на основе правил (PBNM) – это парадигма управления, разделяющие правила поведения системы и её функциональность. Это обещает снизить расходы на поддержку информационных и коммуникационных систем одновременно повышая гибкость и адаптивность при работе. Сегодня это лежит в основе множества архитектур и парадигм управления, включая основанные на SLA, требованиях бизнеса, самоуправляемые, адаптивные и самоподдерживающиеся [BOUTABA07]. Заинтересованным читателям рекомендуется обратиться к имеющейся литературе, включающей множество ссылок. Здесь представлен лишь краткий обзор.

В основе такого управления лежит концепция правил (политики). Имеется множество определений политики – правила, регулирующие выбор поведение системы [SLOMAN94], набор правил, применяемых для поддержки и управления сменой и поддержанием состояния одного или нескольких объектов [STRASSNER03]. Общим для большинства определений является то, что политика считается «правилом». Обычно определение правила включает событие (которое вызывает правило), набор условий (при выполнении которых происходят фактические действия) и одно или несколько выполняемых действий.

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

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

В PBNM обычно применяется выталкивание (push) – правила выталкиваются в устройства, где они разбираются и применяются. Операции выталкивания выполняет менеджер или контроллер, отвечающий за развёртывание политики в сети и отслеживание корректности работы правил. Возможна иная архитектура политики, например, управление на основе правил может включать компонент втягивания (pull) в котором решение о предпринимаемых действиях передаётся точке принятия решений (Policy Decision Point или PDP). PDP может размещаться вне управляемого устройства и обычно имеет глобальную видимость и контекст для принятия решений. Всякий раз при наблюдении устройством события, связанного с политикой, при отсутствии полного определения правила или возможности выбрать действие, устройство обращается к PDP за решением (принимаемым, например, в соответствии с условиями). Затем устройство применяет решение, полученное от PDP, исполняя политику и действуя как точка применения правил (Policy Enforcement Point или PEP). В любом случае архитектура PBNM обычно включает центральный элемент, распространяющий правила по сети или принимающий решения.

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

3.2.3. Различия между намерениями, политикой и моделями служб

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

  • Модель обслуживания является моделью данных, применяемой для описания предоставляемых клиентам экземпляров служб. Модель обслуживания зависит от низкоуровневых моделей (модули устройств и сетей) для описания сопоставления службы с базовой сетью и инфраструктурой IT. Создание экземпляра модели обслуживания требует оркестровки со стороны системы – логика организации/управления/предоставления модели обслуживания и способ её отображения на базовые ресурсы не включается в саму модель.

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

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

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

4. Принципы

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

  1. Единый источник (Single Source of Truth или SSoT) и одна версия (Single Version of Truth или SVoT) доверия. SSoT является важной частью IBS, позволяя выполнять несколько важных операций. В качестве SsoT системы служит набор проверенных выражений намерений. SsoT и записи рабочих состояний позволяют сравнивать предполагаемое/желаемое состояние с фактическим/операционным состоянием системы и определять различия между ними. SSoT и различия служат основой для корректирующих действий. Если в IBS имеются средства прогнозирования состояний, можно дополнительно разрабатывать стратегии предсказания, планирования и упреждающих действий в отношении любых тенденций расхождения с целью минимизации их влияния. Помимо предоставления средств для согласования работы системы, SSoT позволяет улучшить отслеживание для проверки, были ли и насколько хорошо выполнены исходные намерения и связанные с ними бизнес-цели для оценки влияния изменений в параметрах намерений, а также влияния и последствий происходящих в системе событий.

    Единая версия (или представление – View) доверия выводится из SSoT и может служить для выполнения таких операций, как запросы, опросы или фильтрация измеренных или полученных сопоставлением данных для создания так называемых «представлений» (view). Эти представления могут помогать пользователям IBS. Для создания заявления о намерениях как единого источника доверия система IBS должна следовать чётко заданным и хорошо документированным процессам и моделям. SSoT также называют неизменностью намерений [LENROW15].

  2. Одно касание, но не один шаг. В идеальной системе IBS пользователь в той или иной форме выражает намерения, а система выполняет все последующие операции (одно касание). Можно представить и подход «без касания» (zero-touch), если IBS имеет возможности или средства распознавания намерений в любой форме данных. Однако это не должно отвлекать от того, что достижение корректно сформированного и правильного выражения намерений не является одношаговым (one-shot) процессом. Напротив, взаимодействие между пользователем и IBS следует организовывать как итерационный процесс. В зависимости от уровня абстракции выражение намерений исходно может содержать в той или иной степени неявные части, а также неточные или неизвестные параметры и ограничения. Роль IBS заключается в разборе, понимании и уточнении намерений для достижения чётко сформированного и действительного выражения намерений, которое система может использовать для операций исполнения и подтверждения. Процесс уточнения намерений может включать комбинацию итерационных шагов, вовлекающих пользователя в проверку предложенных уточнений и уточнение некоторых параметров и переменных, которые система не может вывести или узнать самостоятельно. Кроме того, IBS потребуется разрешение конфликтов в намерениях, чтобы помочь пользователю сделать верный выбор среди вариантов, которые могут иметь разные последствия.

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

  4. Обучение. IBS – обучающаяся система. В отличие от императивных систем, таких как правила «событие-условие-действие» (Event-Condition-Action), где пользователь заранее задаёт ожидаемое поведение, в IBS пользователь лишь объявляет предполагаемое поведение системы, не указывая способов его достижения. Таким способом происходит передача рассуждений/рационализма от человека (знание предметной области) к системе. Эта передача когнитивных возможностей подразумевает наличие в IBS способов или средств обучения, рассуждения, а также представления знаний и управления ими. Способности IBS к обучению могут применяться для разных задач, таких как оптимизация разбора и уточнения намерений. Способность IBS к постоянному развитию создаёт условия для постоянного обучения и оптимизации. Другие когнитивные возможности, такие как планирование, также могут применяться в IBS для прогнозирования или предсказания будущих состояний системы и откликов на изменения намерений или условий в сети и соответствующей выработки планов по адаптации к этим изменениям при сохранении стабильности и эффективности системы, а также компромисса между стоимостью и надёжностью операций.

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

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

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

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

  • Абстракция и связанная с ней виртуализация, не зависящие от деталей реализации.

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

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

  • Встроенная поддержка, верификация и гарантии доверия.

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

5. Функциональность IBN

Сети на основе намерений (IBN) включают широкий спектр функций, которые можно условно разделить на 2 категории.

  • Реализация намерений (Intent Fulfillment) включает функции и интерфейсы, позволяющие пользователям передать намерения в сеть и выполнить действия, требуемые для исполнения намерений. Это включает алгоритмы определения подходящего направления действий, и функции, которые со временем обучаются оптимизации результатов. Кроме того, сюда входят такие функции, как любая требуемая оркестрока (организация) координированных операций настройки конфигурации в сети и преобразования высокоуровневых абстракций в параметры и элементы управления низкого уровня.

  • Обеспечение (гарантия) намерений (Intent Assurance) включает функции и интерфейсы, позволяющие пользователям проверять и отслеживать соответствие сети заданным намерениям. Это нужно для оценки эффективности действий по исполнению намерений, обеспечения обратной связи, позволяющей со временем обучить и настроить эти функции для оптимизации результатов. Кроме того, Intent Assurance требуется для устранения «дрейфа намерений». Намерение не означает транзакцию «задать и забыть» и предполагается, что оно действует в течение некоторого времени (пока явно не указано иное). Дрейф намерений возникает в тех случаях, когда система исходно соответствовала намерениям, но позволяет своему поведению меняться со временем или подвергаться влиянию, пока намерения не перестанут выполняться или эффективность не снизится.

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

5.1. Реализация намерений

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

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

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

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

5.1.2. Трансляция намерений

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

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

5.1.3. Оркестровка намерений

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

5.2. Обеспечение намерений

Обеспечение намерений (Intent Assurance) связано с функциями, требуемые для гарантии соответствия сети, воспринятым намерениям.

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

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

5.2.2. Оценка соответствия намерений

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

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

5.2.3. Действия по обеспечению соответствия

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

5.2.4. Абстракции, агрегирование, отчёты

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

6. Жизненный цикл

Намерения имеют жизненный цикл – они возникают, могут меняться со временем и отзываться в какой-то момент. Этот жизненный цикл тесно связан с функциями взаимодействия в концепции намерений. На рисунке 1 показан жизненный цикл намерений и его основные функции. Указанные в разделе 5 функции разделены (по вертикали) на 2 функциональные плоскости, отражающие различия между исполнением и обеспечением. Каждая плоскость разделена по горизонтали на 3 части, показывающие разные точки зрения и взаимодействие с разными ролями.

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

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

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

      Пользовательское   :       Пространство            :  Пространство
      пространство       :      трансляции (IBS)         :  сетевых
                         :                               :  операций
           +----------+  :  +----------+   +-----------+ : +-----------+
Восприятие |распознав.|---> |трансляция|-->|  обучение |-->| настройка/|
           |и генерац.|     |    и     |   |планирован.|   |предоставл.|
           |намерений |<--- |уточнение |   |воспроизвед| : |           |
           +----^-----+  :  +----------+   +-----^-----+ : +-----------+
                |        :                       |       :        |
   .............|................................|................|.....
                |        :                  +----+---+   :        v
                |        :                  |проверка|   :  +----------+
                |        :                  +----^---+ <----| отслежив.|
Обеспечение +---+---+    :  +---------+    +-----+---+   :  |наблюдение|
            | отчет | <---- |абстракц.|<---| анализ  | <----|          |
            +-------+    :  +---------+    |агрегиров|   :  +----------+
                         :                 +---------+   :

Рисунок 1. Жизненный цикл намерений.


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

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

  • «Внешний» контур управления намерениями распространяется на пространство пользователя. Он включает действия пользователя и корректировку намерений на основе наблюдений и обратной связи от IBS.

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

7. Дополнительные соображения

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

Operational Intent – эксплуатационные намерения

Намерения, связанные с эксплуатационными целями оператора. Это соответствует исходному термину intent и концепциям данного документа.

Rule Intent – намерения для политики

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

Service Intent – намерения для сервиса

Синоним модели обслуживания клиентов [RFC8309].

Flow Intent – намерения для потока

Синоним цели уровня обслуживания (Service Level Objective) для данного потока.

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

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

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

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

В этом документе описаны концепции и даны определения для основанных на намерениях сетей (Intent-Based Networking). Поэтому приведённые ниже соображения безопасности сохраняют высокий уровень, т. е указаны в виде принципов, рекомендаций или требований. Более подробное рассмотрение будет приведено в документах, задающих архитектуру и функциональность.

Безопасность в IBN имеет несколько аспектов:

  • защита самой системы IBS;

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

  • выражение правил или параметров безопасности в заявлениях о намерениях.

Защита IBS нацелена на обеспечения операционной безопасности IBS за счёт внедрения механизмов защиты и применения накопленного опыта. В контексте IBN такие механизмы и методы могут включать проверку намерений, предоставление возможности работать с намерениями лишь проверенным и уполномоченным пользователям, обнаружение фальсифицированных намерений и защиту от них. Такие механизмы могут включать внедрение нескольких уровней намерений. Например, намерения, связанные с защитой сети, следует помещать на «более глубокий» уровень, который при необходимости переопределяет намерения других уровней, а сам не может быть изменён обычными операциями и требует применения защищённых операций. Следует также рассмотреть применение дополнительных механизмов, таких как компоненты разъяснений, описывающие ветвления защиты и компромиссы, которые следует учитывать.

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

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

  • управление данными;

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

  • уровни доступности ресурсов системы, защиты на путях пересылки, изоляция в функциях обработки;

  • уровни шифрования;

  • уполномоченные для выполнения операций.

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

По мере роста уровня понимания технологий IBN потребуется более тщательно анализировать вопросы безопасности.

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

[BOUTABA07] Boutaba, R. and I. Aib, “Policy-Based Management: A Historical Perspective”, Journal of Network and Systems Management (JNSM), Vol. 15, Issue 4, DOI 10.1007/s10922-007-9083-8, November 2007, <https://doi.org/10.1007/s10922-007-9083-8>.

[CLEMM20] Clemm, A., Faten Zhani, M., and R. Boutaba, “Network Management 2030: Operations and Control of Network 2030 Services”, Journal of Network and Systems Management (JNSM), Vol. 28, Issue 4, DOI 10.1007/s10922-020-09517-0, October 2020, <https://doi.org/10.1007/s10922-020-09517-0>.

[GHARBAOUI21] Gharbaoui, M., Martini, B., and P. Castoldi, “Implementation of an Intent Layer for SDN-enabled and QoS-Aware Network Slicing”, 2021 IEEE 7th International Conference on Network Softwarization (NetSoft), pp. 17-23, DOI 10.1109/NetSoft51509.2021.9492643, June 2021, <https://doi.org/10.1109/NetSoft51509.2021.9492643>.

[IEEE-TITS21] Garg, S., Guizani, M., Liang, Y-C., Granelli, F., Prasad, N., and R. R. V. Prasad, “Guest Editorial Special Issue on Intent-Based Networking for 5G-Envisioned Internet of Connected Vehicles”, IEEE Transactions on Intelligent Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017, DOI 10.1109/TITS.2021.3101259, August 2021, <https://doi.org/10.1109/TITS.2021.3101259>.

[IEEEXPLORE] IEEE, “IEEE Xplore”, <https://ieeexplore.ieee.org/>.

[LENROW15] Lenrow, D., “Intent As The Common Interface to Network Resources”, Intent Based Network Summit 2015 ONF Boulder: IntentNBI, February 2015.

[M3010] ITU-T, “Principles for a telecommunications management network”, ITU-T Recommendation M.3010, February 2000.

[NETWORK-SLICE] 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>.

[PANG20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, “A Survey on Intent-Driven Networks”, IEEE Access, Vol. 8, pp.22862-22873, DOI 10.1109/ACCESS.2020.2969208, January 2020, <https://doi.org/10.1109/ACCESS.2020.2969208>.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks”, STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.

[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, “Autonomic Networking: Definitions and Design Goals”, RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.

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

[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, “YANG Data Model for L3VPN Service Delivery”, RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.

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

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

[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, “An Autonomic Control Plane (ACP)”, RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.

[SERVICE-MAPPING-YANG] Lee, Y., Ed., Dhody, Dhruv., 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>.

[SLOMAN94] Sloman, M., “Policy Driven Management for Distributed Systems”, Journal of Network and Systems Management (JNSM), Vol. 2, Issue 4, pp. 333-360, December 1994.

[STRASSNER03] Strassner, J., “Policy-Based Network Management”, August 2003.

[TR523] Open Networking Foundation, “Intent NBI – Definition and Principles”, ONF TR-523, October 2016.

[WIN21] Ciavaglia, L. and E. Renault, “1st International Workshop on Intent-Based Networking”, IEEE International Conference on Network Softwarization, June 2021, <https://netsoft2021.ieee-netsoft.org/program/workshops/win-2021/>.

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

Спасибо членам исследовательской группы IRTF Network Management (NMRG) за полезные дискуссии и отклики. В частности, авторы хотели бы поблагодарить Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu Song, Peter Szilagyi, Csaba Vulkan за отклики и поддержку. Отдельная благодарность Remi Badonnel, Walter Cerroni, Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, Peter Szilagyi, Csaba Vulkan, сделавшим ещё один шаг и предоставившим рецензии.

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

Alexander Clemm
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: ludwig@clemm.org
 
Laurent Ciavaglia
Nokia
Route de Villejust
91620 Nozay
France
Email: laurent.ciavaglia@nokia.com
 
Lisandro Zambenedetti Granville
Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Gonçalves
Porto Alegre-RS
9500
Brazil
Email: granville@inf.ufrgs.br
 
Jeff Tantsura
Microsoft
Email: jefftant.ietf@gmail.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9299 An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

Internet Engineering Task Force (IETF)                       A. Cabellos
Request for Comments: 9299          Universitat Politecnica de Catalunya
Category: Informational                                   D. Saucez, Ed.
ISSN: 2070-1721                                                    Inria
                                                            October 2022

An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

Архитектурное введение в протокол LISP

PDF

Аннотация

Этот документ описывает архитектуру протокола разделения идентификаторов и локаторов (Locator/ID Separation Protocol или LISP), упрощая понимание спецификаций LISP и обеспечивая базу для обсуждения деталей протоколов LISP. Документ служит введением, а подробные сведения приведены в спецификациях RFC 9300 и RFC 9301.

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

Документ не содержит стандарта Internet и публикуется с информациоными целями.

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

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

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

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

Оглавление

Исключено в версии HTML

1. Введение

Этот документ описывает архитектуру протокола разделения идентификаторов и локаторов (LISP) [RFC9300] [RFC9301], основные механизмы работы и принципы устройства. По сути, LISP основан на хорошо известной архитектурной идее освобождения от перегрузки семантики адресов IP. Как отметил Noel Chiappa [RFC4984], в настоящее время адреса IP указывают сразу топологическое местоположение точки подключения к сети и идентификацию узлов. Однако требования узлов и маршрутизации принципиально различаются. Системам маршрутизации нужна агрегируемость адресов и их топологическая значимость, а узлам требуется идентификация, независимая от конкретного местоположения [RFC4984].

LISP создаёт два раздельных пространства имён для идентификаторов конечных точек (Endpoint Identifier или EID) и локаторов маршрутизации (Routing Locator или RLOC). Оба пространства синтаксически идентичны современным адресам IPv4 и IPv6. Однако EID служат для однозначной идентификации узлов независимо от их топологического местоположения и обычно маршрутизируются внутри домена. Локаторы RLOC назначаются топологически и обычно маршрутизируются между доменами. С помощью LISP можно логически разделить границу Internet (места подключения узлов) и ядро (где происходит междоменная маршрутизация). Маршрутизаторы с поддержкой LISP соединяют эти логические пространства. LISP поддерживает базу данных, называемую системой сопоставления (Mapping System), для хранения и извлечения сведений о сопоставлении отождествлений и местоположений. Маршрутизаторы с поддержкой LISP обмениваются пакетами через ядро Internet, инкапсулируя их в нужное место.

  • Локаторы RLOC имеют смысл лишь в базовой (underlay) сети, т. е. в ядре маршрутизации.

  • EID имеют смысл лишь в наложенной сети, которая является связующей инкапсуляцией между маршрутизаторами с поддержкой LISP.

  • На границе LISP идентификаторы EID сопоставляются с RLOC.

  • В базовой сети RLOC служат сразу локаторами и идентификаторами.

  • EID внутри сайта LISP служат идентификаторами и локаторами для других узлов этого сайта.

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

Указанные выше свойства не уникальны для LISP и присущи многим наложенным протоколам.

Исходную мотивацию разработки LISP можно найти в проблеме расширяемости маршрутизации [RFC4984], где при полном развёртывании LISP ядро Internet будет заполнено RLOC, а механизмы организации трафика (Traffic Engineering или TE) будут вынесены в систему сопоставления. В таком варианте локаторы RLOC будут квазистатическими (т. е. меняющимися редко), что делает систему маршрутизации расширяемой [Quoitin], а EID могут перемещаться свободно, «не создавая пены» в базовой системе глобальной маршрутизации. В [RFC7215] рассмотрено влияние LISP на систему глобальной маршрутизации в процессе перехода. Однако разделение местоположения и идентификации, предлагаемое LISP, подходит и для применения в других случаях, таких как TE, многодомные подключения и мобильность узлов.

В этом документе описана архитектура и основные механизмы работы LISP, а также принципы разработки. Важно отметить, что документ не задаёт и не дополняет LISP. Заинтересованным читателям следует обратиться к спецификациям LISP ([RFC9300] и [RFC9301]), а также дополнительным документам ([RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052]) для спецификации протокола и рекомендаций по развёртыванию LISP [RFC7215].

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

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

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

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

Адрес, топологически назаначаемый точке подключения к сети. Обычно маршрутизируется между доменами.

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

Поддерживающий LISP маршрутизатор, инкапсулирующий пакеты от сайта LISP в направлении ядра сети.

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

Поддерживающий LISP маршрутизатор, декапсулирующий пакеты из ядра сети в направлении сайта LISP.

xTR

Машрутизатор, реализующий функции ITR и ETR.

Map-Request

Сигнальное сообщение LISP, служащее для запроса отображения EID на RLOC.

Map-Reply

Сигнальное сообщение LISP, служащее ответом на Map-Request и содержащее нужное отображение EID на RLOC.

Map-Register

Сигнальное сообщение LISP, служащее для регистрации отображения EID на RLOC.

Map-Notify

Сигнальное сообщение LISP, передаваемое в ответ на Map-Register для подтверждения корректного получения отображения EID на RLOC.

Этот документ описывает архитектуру LISP и не вносит новых терминов. Определения используемых терминов даны в [RFC9300], [RFC9301], [RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052], [RFC7215].

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

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

3.1. Принципы устройства протокола

Архитектура LISP основана на 4 базовых принципах.

Разделение локаторов и идентификаторов

Разделение перегруженной сегодня семантики адресов IP позволяет устройствам иметь основанный на отождествлении (идентификаторе) адрес, отвязанный от топологически значимого адреса. Предоставление доступа в ядро Internet лишь топологически значимым адресам позволяет агрегировать их для поддержки расширяемости маршрутизации. Отдельным устройствам назначаются основанные на отождествлениях адреса, не применяемые для пересылки в ядре Internet.

Наложение

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

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

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

Возможность поэтапного развёртывания

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

3.2. Обзор архитектуры

LISP архитектурно отделяет ядро от периметра Internet, создавая два пространства имён – EID и RLOC. Периметр образуют сайты LISP (например, автономные системы – AS), использующие адреса EID. Идентификаторы EID – это адреса IPv4 или IPv6, однозначно указывающие конечные хосты, которые назначаются и настраиваются с использованием механизмов, существовавших на момент разработки протокола. В EID не включаются междоменные топологические данные и поэтому EID обычно маршрутизируются на периферии (внутри сайта LISP), но не в ядре. Взаимодействие сайтов LISP с сайтами и доменами без поддержки LISP в сети Internet описано в параграфе 3.5. Механизмы межсетевого взаимодействия.

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

                       /-----------------\                 ---
                       |     Система     |                  |
                       .  сопоставления  |                  |Плоскость
                      -|                 |`,                |управления
                    ,' \-----------------/  .               |
                   /                         |             ---
   ,..,           -        _,....,,          |      ,..,    |
 /     `        ,'      ,-`        `',       |    /     `   |
/        \ +-----+   ,'              `,  +-----+ /        \ |
| Простр.|-| xTR |--/   Пространство  ,--| xTR |-| Простр.| |Плоскость
|  EID   |-|     |--|       RLOC      |--|     |-|  EID   | |данных
\        / +-----+  .                 /  +-----+ \        / |
 `.    .'            `.              ,'           `.    .'  |
   `'-`                `.,        ,.'               `'-`   ---
                          ``'''``
  Сайт LISP (периметр)      Core         Сайт LISP (периметр)

Рисунок 1. Схема архитектуры LISP.


При использовании LISP ядро работает с локаторами RLOC. Локатор RLOC – это адрес IPv4 или IPv6, назначенный интерфейсу маршрутизатора ITR или ETR в сторону ядра.

База данных (обычно распределенная), которую называют системой сопоставления (Mapping System), содержит сопоставления между EID и RLOC. Такие сопоставления связывают идентификаторы устройств, подключённых к сайту LISP (EID), с набором RLOC, настроенных на поддерживающих LISP маршрутизаторах, обслуживающих сайт. Кроме того, сопоставления включают правила TE и могут быть настроены на поддержку многодомности и распределения нагрузки. Система сопоставления LISP концептуально похожа на DNS и организована как распределенная по сети база данных множества организаций. В LISP маршрутизаторы ETR регистрируют сопоставления, а ITR извлекают их.

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

Ниже (Рисунок 2) представлена упрощённая последовательность потока пакетов между парой узлов, подключённых к сайтам LISP. Отметим, что типичные маршрутизаторы с поддержкой LISP – это xTR (ITR и ETR). Клиент HostA на рисунке передаёт пакет серверу HostB.

                         /----------------\
                         |     Система    |
                         |  сопоставления |
                        .|                |-
                       ` \----------------/ `.
                     ,`                       \
                    /                          `.
                  ,'         _,..-..,,           ',
                 /         -`         `-,          \
               .'        ,'              \          `,
               `        '                 \           '
           +-----+     |                   | RLOC_B1+-----+
    HostA  |     |    |    Пространство     |-------|     |  HostB
    EID_A--|ITR_A|----|        RLOC         |       |ETR_B|--EID_B
           |     | RLOC_A1                  |-------|     |
           +-----+     |                   | RLOC_B2+-----+
                        ,                 /
                         \               /
                          `',         ,-`
                             ``''-''``

Рисунок 2. Последовательность потока пакетов в LISP.

  1. HostA извлекает EID_B для HostB, обычно запрашивая DNS и получая запись A или AAAA. Затем он создаёт пакет IP как в Internet. Пакет имеет адрес отправителя EID_A и адрес получателя EID_B.

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

  3. ITR_A при получении пакета запрашивает систему сопоставления для получения локатора ETR_B, обслуживающего EID_B сервера HostB. Для этого служит управляющее сообщение LISP, называемое Map-Request. Сообщение содержит EID_B в качестве ключа поиска. В ответ ITR_A получает другое управляющее сообщение LISP – Map-Reply. Это сообщение содержит два локатора RLOC_B1 и RLOC_B2, а также правила TE – приоритет и вес для каждого локатора. Отметим, что при необходимости Map-Reply может включать большее число локаторов. ITR_A может кэшировать сопоставления в локальном хранилище для ускорения пересылки последующих пакетов.

  4. ITR_A инкапсулирует пакет в сторону RLOC_B1 (выбирается в соответствии с приоритетом и весом в сопоставлении). Пакет имеет два заголовка IP. Внешний заголовок указывает RLOC_A1 как источник и RLOC_B1 – как получателя. Во внутреннем исходном заголовке пакета указан адрес источника EID_A и получателя EID_B. Затем ITR_A добавляет заголовок LISP. Более подробно процесс описан в параграфе 3.3.1. Инкапсуляция LISP.

  5. Инкапсулированный пакет пересылается через межсетевое ядро как обычный пакет IP, оставляя EID невидимым для ядра.

  6. При получении инкапсулированного пакета маршрутизатор ETR_B декапсулирует его и пересылает в HostB.

3.3. Плоскость данных

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

3.3.1. Инкапсуляция LISP

Маршрутизаторы ITR инкапсулируют пакеты данных в направлении ETR. Пакеты данных LISP инкапсулируются с использованием UDP (порт 4341). Порт отправителя ITR обычно выбирает с использованием хэш-значения квинтета (5-tuple) из внутреннего заголовка (для согласованности при спользовании нескольких путей, как в ECMP [RFC2992]) и игнорируется при получении. Пакеты данных LISP часто инкапсулируются в пакеты UDP с нулевой контрольной суммой [RFC6935] [RFC6936], которую нельзя проверить при получении, поскольку внутри пакета LISP имеется транспортный заголовок с проверяемой контрольной суммой. Использование нулевой контрольной суммы UDP при передаче по протоколу IPv6 для всех протоколов туннелирования, подобных LISP, регулируется заявлением о применимости из [RFC6936]. Если пакеты данных LISP инкапсулируются в пакеты UDP с ненулевой контрольной суммой, внешняя контрольная сумма проверяется при получении пакетов UDP как при обычной обработке UDP.

Пакеты с инкапсуляцией LISP включают также заголовок LISP (между внешним заголовком UDP и исходным заголовком IP). Заголовок LISP устанавливают маршрутизаторы ITR и вырезают ETR. Заголовок содержит сведения о достижимости (4.2. Достижимость RLOC) и поле Instance ID, служащее для разделения трафика разных арендаторов на сайте LISP, что позволяет применять на сайтах перекрывающуюся, но логически разделенную адресацию EID.

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

  1. Внешний заголовок IP с RLOC в качестве адресов отправителя и получателя. Этот заголовок создаёт маршрутизатор ITR и вырезает маршрутизатор ETR.

  2. Заголовок UDP (порт 4341), обычно с нулевой контрольной суммой, создаваемый ITR и вырезаемый ETR.

  3. Заголовок LISP со свойствами плоскости пересылки (такими как доступность) и полем Instance ID. Этот заголовок создаёт маршрутизатор ITR и вырезает маршрутизатор ETR.

  4. Внутренний заголовок IP с EID в качестве адресов отправителя и получателя. Этот заголовок создаёт хост-источник и он сохраняется неизменным при обработке в плоскости данных LISP на ITR и ETR.

В некоторых случаях полезна повторная инкапсуляция и/или рекурсивные туннели для выбора конкретного пути через базовую сеть, например, для предотвращения перегрузки или отказа. Туннелирование с повторной инкапсуляцией является последовательным применением туннелей LISP и выполняется при удалении декапсулятором (ETR) заголовка LISP и новой инкапсуляции (ITR) с добавлением другого заголовка. Рекурсивные туннели являются вложенными и реализуются с использованием для пакета неоднократной инкапсуляции LISP. Такие функции реализуются маршрутизаторами с реинкапсуляцией туннелей (Re-encapsulating Tunnel Router или RTR). Маршрутизатор RTR можно считать выступающим сначала в роли ETR для декапсуляции пакетов, затем – в роли ITR с инкапсуляцией пакетов для другого локатора (см. [RFC9300] и [RFC9301]).

3.3.2. Состояние пересылки LISP

В архитектуре LISP маршрутизаторы ITR сохраняют лишь сведения, достаточные для маршрутизации проходящего через них трафика. Иными словами, ITR нужно лишь извлечь из системы сопоставления LISP отображения EID-Prefix (блок EID) на RLOC, применяемые для инкапсуляции пакетов. Такие сопоставления хранятся в локальном кэше, называемом LISP Map-Cache, для последующих пакетов, направляемых в тот же EID-Prefix. Отметим, что в случае перекрытия EID-Prefix маршрутизатор ITR может получить по запросу набор сопоставлений из запрошенного EID-Prefix и более конкретных EID-Prefix (см. параграф 5.5 в [RFC9301]). Отображения включают значения TTL, устанавливаемые ETR. Дополнительные сведения об управлении Map-Cache приведены в параграфе 4.1. Поддержка кэша.

3.4. Плоскость управления

Плоскость управления LISP, заданная в [RFC9301], обеспечивает стандартный интерфейс для регистрации и запроса сопоставлений. Система сопоставления LISP – это база данных, хранящая отображения. В последующих параграфах сначала описаны сами отображения, а затем стандартный интерфейс системы сопоставления и её архитектура.

3.4.1. Сопоставления LISP

Каждое отображение включает привязки EID-Prefix к набору RLOC, а также правила TE в виде приоритета и веса для RLOC. Приоритет позволяет ETR настроить активную и резервную политику, а вес служит для распределения нагрузки (трафика) между RLOC (по потокам).

Типичное сопоставление в LISP связывает EID в форме префиксов IP с набором RLOC тоде в форме адресов IP. Адреса IPv4 и IPv6 кодируюся с использованием подходящего идентификатора семейства адресов (Address Family Identifier или AFI) [RFC8060]. Однако LISP может поддерживать более общее кодирование адресов на канонического формату LISP (LISP Canonical Address Format или LCAF) [RFC8060]. С помощью такого обобщённого синтаксиса кодирования адресов LISP стремится обеспечить гибкость имеющихся и будущих приложений. Например, LCAF позволяет поддерживать адреса MAC (Media Access Control), географические координаты, имена ASCII и задаваемые приложением данные.

3.4.2. Интерфейс системы сопоставления

LISP задаёт стандартный интерфейс между плоскостями данных и управления в [RFC9301], включающий 2 сущности.

Map-Server – сервер сопоставлений

Компонент сетевой инфраструктуры, изучающий отображения через маршрутизаторы ETR и публикующий их в системе сопоставления LISP Mapping System. Обычно Map-Server не уполномочен отвечать на запросы, поэтому он пересылает их ETR. Однако сервер может работать в режиме посредника (proxy-mode), когда ETR делегирует ему право отвечать на запросы. Это полезно при ограниченности ресурсов ETR (например, CPU или питания).

Map-Resolver – распознаватель сопоставлений

Компонент сетевой инфраструктуры, соединяющий маршрутизатор ITR с системой сопоставления путём посредничества (proxying) для запросов, а иногда и откликов.

Интерфейс определяет 4 управляющих сообщения LISP, передаваемых в дейтаграммах UDP (порт 4342).

Map-Register

Эти сообщения применяются маршрутизаторами ETR для регистрации отображений в системе сопоставления и аутентифицируются с использованием общего для ETR и Map-Server ключа.

Map-Notify

По запросу ETR это сообщение передаёт Map-Server в ответ на сообщение Map-Register для подтверждения корректного получения отображения и передачи последнего состояния Map-Server для отображения EID на RLOC. В некоторых случаях Map-Notify может передаваться для прежних RLOC, если для EID зарегистрирован новый набор RLOC.

Map-Request

Это сообщение применяется маршрутизаторами ITR или распознавателями Map-Resolver для получения сопоставления данного EID.

Map-Reply

Это сообщение передаёт Map-Server или ETR в ответ на Map-Request, указывая найденное сопоставление. Следует отметить, что Map-Reply может содержать негативный отклик, если, например, запрошенный идентификатор EID не входит в пространство LISP EID. В таких случаях ITR обычно пересылает трафик как есть (без инкапсуляции) в сеть Internet. Это определено для поддержки поэтапного развёртывания LISP.

3.4.3. Система сопоставления

LISP архитектурно разделяет плоскости управления и данных с помощью стандартного интерфейса. Интерфейс связывает плоскость данных (маршрутизаторы, отвечающие за пересылку пакетов данных) с системой сопоставления LISP (база данных, отвечающая за хранение отображений). При таком разделении плоскости данных и управления могут иметь разную архитектуру и расширяться независимо. Обычно плоскость данных оптимизируется для маршрутизации пакетов по иерархическим адресам IP. Однако требования плоскости управления могут быть иными, например, за счёт использования преимуществ LCAF система сопоставления может хранить неиерархические ключи (такие как MAC-адреса) и для её расширяемости нужен будет другой подход. Другим важным различием плоскостей данных и управления LISP является то, что за счёт локального кэширования отображений в ITR системе сопоставления не требуется работать со скоростью линии.

При выборе архитектуры системы сопоставления было рассмтрено множество механизмов создания распределенных систем – базы данных на основе графов в форме альтернативной логической топологии LISP (LISP Alternative Logical Topology или LISP-ALT) [RFC6836], иерархические базы данных в форме дерева делегированных баз данных LISP (LISP Delegated Database Tree или LISP-DDT) [RFC8111], монолитные базы данных в форме LISP Not-so-novel EID-to-RLOC Database (LISP-NERD) [RFC6837], плоские базы данных в форме распределенной хэш-таблицы LISP (LISP Distributed Hash Table или LISP-DHT) [LISP-SHDHT] [Mathy], и основанные на групповой передаче базы данных [LISP-EMACS]. Следует отметить, что в некоторых вариантах, таких как приватное развёртывание, система сопоставления может быть логически централизованной и обычно будет включать один Map-Server/Map-Resolver.

В последующих параграфах более подробно рассмотрены две из упомянутых систем сопоставления (LISP-ALT и LISP-DDT), которые были реализованы и развёрнуты.

3.4.3.1. LISP-ALT

LISP-ALT [RFC6836] была первой системой сопоставления, которая бала предложена, разработана и развёрнута в пилотной сети LISP. Она основана на распределенном наложении BGP с участием Map-Server и Map-Resolver. Узлы соединялись с партнёрами через статические туннели. Каждый вовлечённый Map-Server в топологии ALT анонсировал EID-Prefix, зарегистрированные обслуживаемыми ETR, что делало EID маршрутизируемыми в топологии ALT.

Когда маршрутизатору ITR нужно отображение, он передаёт Map-Request распознавателю Map-Resolver, который, используя топологию ALT, пересылает Map-Request в направлении Map-Server, отвечающего за сопоставление. При получении запроса Map-Server пересылает его маршрутизатору ETR, который отвечает напрямую ITR.

3.4.3.2. LISP-DDT

LISP-DDT [RFC8111] концептуально похожа на DNS – иерархический каталог, внутренняя структура которого отражает иерархическую природу адресного пространства EID. Иерархия DDT включает узлы DDT, формирующие дерево, листьями которого служат Map-Server. Наверху структууры размещается корень DDT, являющийся экземпляром узла DDT, соответствующим всему пространству адресов. Как и DNS, система DDT поддерживает множество избыточных узлов DDT и/или корней DDT. Распознаватели Map-Resolver являются клиентами иерархии DDT и могут обращаться к корню и другим узлам DDT.

                        /---------\
                        |         |
                        | DDT Root|
                        |   /0    |
                      ,.\---------/-,
                  ,-'`       |       `'.,
               -'`           |           `-
           /-------\     /-------\    /-------\
           |  DDT  |     |  DDT  |    |  DDT  |
           | Node  |     | Node  |    | Node  |  ...
           |  0/8  |     |  1/8  |    |  2/8  |
           \-------/     \-------/    \-------/
         _.                _.            . -..,,,_
       -`                -`              \        ````''--
+------------+     +------------+   +------------+ +------------+
| Map-Server |     | Map-Server |   | Map-Server | | Map-Server |
| EID-Prefix1|     | EID-Prefix2|   | EID-Prefix3| | EID-Prefix4|
+------------+     +------------+   +------------+ +------------+

Рисунок 3. Схематическое представление дерева DDT.


Префиксы и структура на рисунке 3 представлены лишь для иллюстрации.

Структура DDT на деле не индексирует EID-Prefix, индексируя взамен расширенные префиксы (Extended EID-Prefix или XEID-Prefix), которые являются просто конкатенацией нескольких полей (от старшего бита к младшему): Database-ID, Instance ID, Address Family Identifier и фактических EID-Prefix. Database-ID указывается для возможных в будущем требований повышения уровня иерархии и возможности создания нескольких отдельных деревьев баз данных.

При ответах на запрос LISP-DDT работает подобно DNS, но поддерживает лишь интерактивный поиск. Клиенты DDT (обычно Map-Resolver) создают запросы Map-Request к корневому узлу DDT, получая в ответ новое управляющее сообщение LISP – Map-Referral. Это сообщение содержит список RLOC набора узлов DDT, соответствующих настроенному делегированию XEID. Т. е. сведения в Map-Referral указывают потомка запрашиваемого узла DDT, у которого есть более конкретные сведения об интересующем префиксе XEID-Prefix. Этот процесс повторяется, пока клиент DDT не пройдёт структуру дерева (вниз) и не найдет Map-Server, обслуживающий искомый XEID. В этот момент клиент передаёт Map-Request и получает Map-Reply с сопоставлениями. Важно подчеркнуть, что клиенты DDT могут кэшировать сведения из Map-Referral, т. е. структуру DDT, чтобы сократить время извлечения сопоставлений [Jakab].

Система сопоставления DDT основана на ручной настройке, т. е. на Map-Resolver настраивается набор доступных корневых узлов DDT, а на узлах DDT – соответствующее делегирование XEID. Изменение настроек на узлах DDT требуется лишь при смене структуры дерева и настройки не зависят от динамики EID (выделения RLOC или смены правил TE).

3.5. Механизмы межсетевого взаимодействия

EID обычно идентичны адресам IPv4 или IPv6 и хранятся в системе сопоставления LISP. Однако они обычно не анонсируются в систему маршрутизации за пределами локального домена LISP. Поэтому для LISP нужен механизм межсетевого взаимодействия, позволяющий сайтам LISP взаимодействовать с сайтами, не понимающими LISP (и наоборот). Механизмы межсетевого взаимодействия LISP заданы в [RFC6832].

В LISP заданы две сущности для обеспечения межсетевого взаимодействия.

Proxy Ingress Tunnel Router (PITR) – маршрутизатор-посредник входного туннеля

PITR обеспечивают связность унаследованной сети Internet с сайтами LISP. PITR анонсируют в систему глобальной маршрутизации блоки EID-Prefix (с агрегированием при возможности) для привлечения трафика. Для каждого входящего пакета из источника вне сайта LISP (не EID) PITR использует инкапсуляцию LISP в направлении RLOC подходящего сайта LISP. Влияние PITR на размер таблицы маршрутизации зоны без принятого по умолчанию маршрута (Default-Free Zone или DFZ) в худшем случае похоже на ситуацию без применения LISP. EID-Prefix будут по возможности агрегироваться как PITR, так и системой глобальной маршрутизации.

Proxy Egress Tunnel Router (PETR) – маршрутизатор-посредник выходного туннеля

PETR обеспечивает связность сайта LISP с традиционной сетью Internet. В некоторых случаях сайты LISP не могут передавать инкапсулированные пакеты с локальным адресом EID в качестве источника в традиционную сеть Internet, например, когда краевой маршрутизатор провайдера (Provider Edge или PE) использует индивидуальную пересылку по обратному пути (Unicast Reverse Path Forwarding или uRPF) или промежуточная сеть между сайтом LISP и не понимающим LISP сайтом не поддерживает нужную версию IP (IPv4 или IPv6). В обоих PETR преодолевает такие ограничения за счёт инкапсуляции пакетов. Не существует конкретных правил распространения адресов PETR RLOC маршрутизаторам ITR.

Кроме того, LISP определяет механизмы для работы с приватными EID [RFC1918] через LISP-NAT [RFC6832]. В этом случае xTR заменяет приватное значение EID источника на маршрутизируемое. На момент написания документа продолжалась работа по прохождению через NAT, т. е. размещения xTRs за NAT с использованием немаршрутизируемых RLOC.

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

4. Механизмы работы LISP

В этом разделе описаны основные рабочие механизмы, определённые в LISP.

4.1. Поддержка кэша

Разделение плоскостей управления и данных в LISP с хранением сопоставлений в плоскости данных и использовании их для пересылки в плоскости управления требует локального кэширования в ITR для снижения сигнальных издержек (Map-Request/Map-Reply) и повышения скорости пересылки. Локальный кэш в ITR называют Map-Cache и применяют для пакетов с инкапсуляцией LISP. Map-Cache индексируется по парам (Instance ID, EID-Prefix) и содержит в основном набор RLOC со связанными правилами TE (приоритет и вес).

Для Map-Cache, как и иных случаев кэширования, нужны механизмы обеспечения когерентности, чтобы сведения оставались актуальными. LISP задает 3 основных механизма поддержки когерентности кэша.

Record Time To Live (TTL) – срок действия записи

Каждая запись сопоставления имеет поле TTL, задаваемое маршрутизатором ETR. По истечении TTL запись не может применяться ITR, пока не будет обновлена отправкой нового Map-Request.

Solicit-Map-Request (SMR) – запрос Map-Request

SMR служит явным механизмом обновеления данных сопоставления. В частности, можно передать специальный тип Map-Request по требованию ETR для запроса обновления сопоставлений. При получении сообщения SMR маршрутизатор ITR должен обновить привязки передавая Map-Request системе сопоставления. Использование SMR описано в [RFC9301].

Map-Versioning – версия сопоставления

Этот необязательный механизм добавляет в конец заголовка LISP пакетов данных номер версии отображения, используемой маршрутизатором xTR. При получении xTR пакета с инкапсуляцией LISP от удалённого xTR, можно узнать, не устарела ли локальная или удалённая версия Map-Cache. Если локальная версия устарела маршрутизатор передает Map-Request для удалённого EID, чтобы получить новое сопоставление. Если же обнаружно устаревание Map-Cache на удалённом xTR, маршрутизатор передаёт SMR для уведомления того о доступности нового сопоставления. Подробное описание процесса приведено в [RFC9302].

В некоторых случаях запись Map-Cache можно обновить заранее с помощью описанных ниже механизмов.

4.2. Достижимость RLOC

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

Locator-Status-Bits (LSBs) – биты состояния локатора

Метод LSBs является пассивным. Поле LSB передаётся в заголовках LISP пакетов данных и может устанавливаться маршрутизаторами ETR для указания активных и неактивных (up/down) RLOC сайта ETR. Эти сведения могут служить маршрутизаторам ITR подсказкой о доступности для выполнения дополнительной проверки. LSB не указывают статус доступности пути, а лишь дают подсказки о состоянии RLOC. Поэтому они не должны применяться в общедоступной сети Internet и следует связывать их с Map-Versioning для предотвращения «гонки», где LSB считаются относящимися не к тем RLOC, с которыми они связаны.

Echo-Nonce

Это пассивный метод, который может эффективно работать лишь при двухсторонних потоках данных между двумя взаимодействующими xTR. По сути, ITR добавляет в конце заголовка LISP пакетов данных случайное значение (nonce). Если путь и зондируемый локатор активны, ETR будет добавлять это же случайное значение в следующий пакет данных. Если этого не происходит, ITR может счесть локатор недоступным. При одностороннем трафике или несовпадении принимающего трафик ETR с передающим трафик назад маршрутизатором ITR нужны дополнительные механизмы. Механизм Echo-Nonce должен применяться лишь в доверенных средах, а не в общедоступной сети Internet.

RLOC-Probing – зондирование RLOC

Имеется механизм активного зондирования, когда ITR передают пробные пакеты конкретным локаторам. Это позволяет проверить как локатор, так и путь к нему. В частности, это делается путём отправки Map-Request (с некоторыми флагами) в плоскости данных (пространство RLOC) и ожидания Map-Reply, передаваемого также в плоскости данных. Активная природа RLOC-Probing обеспечивает эффективный механизм определения доступности и (в случае отказа) переключения на другой локатор. Кроме того, механизм обеспечивает полезную оценку RTT для задержек на пути, которую могут использовать другие сетевые алгоритмы.

Следует отметить, что RLOC-Probing и Echo-Nonce могут работать вместе. В частности, если nonce не возвращается, ITR не может определить на каком из направлений возник отказ. В этом случае ITR может использовать RLOC-Probing.

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

Сигналы ICMP

Базовая среда LISP – инфраструктура Internet – использует ICMP для сигналов о недоступности (среди прочего). LISP может использовать это и считать получение сообщений ICMP Network Unreachable или ICMP Host Unreachable подсказкой о возможной недоступности локатора, вызывающей дополнительную проверку.

Базовая маршрутизация

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

4.3. Синхронизация ETR

Все ETR, полномочные для конкретного EID-Prefix, должны анонсировать запрашивающим одно и то же сопоставление. Это значит, что ETR должны знать о статусе RLOC в других ETR. Это называют синхронизацией ETR.

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

4.4. Обработка MTU

Поскольку LISP инкапсулирует пакеты, протоколу приходится иметь дело с превышением размера пакетов над MTU для пути между ITR и ETR. LISP определяет два механизма.

Без учёта состояния

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

С учётом состояния

ITR отслеживают значения MTU на путях к целевым локаторам на основании пакетов ICMP Too Big от промежуточных маршрутизаторов. Маршрутизаторы ITR передают сообщения ICMP Too Big для информирования отправителей об эффективном значении MTU. Кроме того, ITR могут применять механизмы определения MTU для пути (Path MTU Discovery или PMTUD) [RFC1191] или определение MTU на уровне пакетизавции (Packetization Layer Path MTU Discovery или PLPMTUD) [RFC4821] для отслеживания MTU в направлении локаторов.

В обоих случаях при невозможности фрагментировать пакеты (IPv4 с DF=1 или IPv6) ITR отбрасывает пакет и передаёт его отправителю сообщение ICMP Too Big.

5. Мобильность

Разделение локаторов и идентификаторов в LISP подходит для целей TE, где сайты LISP могут менять свои точки присоединения к Internet (т. е. RLOC) не затрацивая конечные точки и ядро Internet. В этом контексте граничные маршрутизаторы используют функциональность xTR, а конечные точки не знают о наличии LISP. Это похоже на Network Mobility [RFC3963], однако данный режим работы не обеспечивает «бесшовной» мобильности конечных точек между разными сайтами LISP, поскольку адрес EID может не маршрутизироваться в посещенном сайте. Тем не менее, LISP можно использовать для бесшовной мобильности IP, когда LISP реализован непосредственно на конечной точке или та перемещается к подключённому xTR. Тогда каждая конечная точка является xTR, а адрес EID – это один из предоставленных сетевому стеку, используемому приложениями, тогда как RLOC берётся из посещенной сети. Это похоже на функциональность Mobile IP ([RFC5944] и [RFC6275]).

При смене устройством своего локатора RLOC маршрутизатор xTR обновляет RLOC в своём локальном сопставлении и регистрирует его на своём Map-Server, обычно с малым значением TTL (1 минута). Чтобы избежать потребности в домашнем шлюзе, ITR также указывает смену RLOC всем удаленным устройствам, имеющим текущую связь с перемещенным устройством Сочетание обоих методов обеспечивает расширяемость системы, поскольку сигнализация строго ограничена Map-Server и хостами, с которыми имеется связь. В случае перемещения EID-Prefix может быть достаточно мелким, вплоть до /32 или /128 (IPv4 и IPv6, соответственно), в зависимости от конкретного применения (например, перенос подсети или одной виртуальной машиы или мобильного узла).

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

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

LISP поддерживает доставку групповых пакетов IP, переданных из пространства EID. Требуемые изменения протоколов групповой доставки указаны в [RFC6831].

LISP может создавать состояния групповой рассылки (для приёма и передачи) как в ядре, так и на сайтах. При использовании сигнализации для создания групповой рассылки на сайтах маршрутизаторы LISP инкапсулируют сообщения PIM Join/Prune от получателя к сайтам источников как индивидуальные пакеты. В ядре маршрутизаторы ETR создают новое сообщение PIM Join/Prune, адресованное RLOC маршрутизатора ITR, обслуживающего источник. Упрощённая последовательность приведена ниже.

  1. Конечный хост, желающий присоединиться к групповому каналу передаёт отчёт IGMP. Групповые маршрутизаторы PIM на сайте LISP распространяют сообщения PIM Join/Prune (S-EID, G) в направлении ETR.

  2. Сообщение Join поступает в ETR и маршрутизатор ETR создаёт два сообщения Join. Первое является индивидуальным пакетом с инкапсуляцией LISP для исходного сообщения Join в направлении RLOC обслуживающешл источник маршрутизатора ITR. Это сообщение создаёт групповое состояние (S-EID, G) на сайте источника. Второе сообщение Join содержит в качестве адреса получателя RLOC маршрутизатора ITR, обслуживающего источник (S-RLOC, G) и создаёт состояние групповой рассылки в ядре.

  3. Групповые пакеты данных, созданные источником (S-EID, G) передаются от него к ITR. Маршрутизатор ITR инкапсулирует групповые пакеты в LISP. Внешний заголовок включает его RLOC (S-RLOC) как отправителя и исходный адрес multicast-группы (G) как получателя. Отметим, что групповые адреса являются логическими и не распознаются системой сопоставления. Затем групповые пакеты передаются через ядро в направлении принимающих ETR, которые декапсулируют пакеты и пересылают их по групповому состоянию на сайте.

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

Когда групповые источники и получатели имеются на сайтах LISP, а ядро сети между сайтами не обеспечивает поддержки групповой передачи, можно применять бессигнальный механизм для создания наложения, которое позволит передавать групповой трафик между сайтами и соединить деревья групповой рассылки на разных сайтах [RFC8378]. Регистрации с разных сайтов-получателей будут слиты в системе сопоставления для сборки списка групповой репликации, включающего все RLOC, ведущие к получателям для конкретной группы или группового канала. Список репликации для каждой конкретной групповой записи поддерживается как запись системы сопоставления LISP.

7. Варианты применения

7.1. Организация трафика

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

Отображение связывает список RLOC с EID-Prefix. Каждый локатор RLOC соответствует интерфейсу ETR (или набора ETR), способному корректно переслать трафик по EID из префикса. Для каждого RLOC в отображении указывается приоритет и вес. Приоритет служит для выбора предпочтительных для передачи пакетов RLOC (менее предпочтительные предоставляются для резервирования), а вес позволяет распределять нагрузку между RLOC с одинаковым приоритетом пропорционально заданному значению веса.

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

7.2. LISP для сосуществования с IPv6

Инкапсуляция LISP позволяет доставлять пакеты, использующие EID из данного пространства адресов (например, IPv6) в пакетах другого семейства адресов (например, IPv4). Отсутствие привязки между семействами адресов RLOC и EID делает LISP подходящим кандидатом, позволяющим, например, развернуть IPv6 через ядро без поддержки IPv6.

Например, два ЦОД, поддерживающие лишь IPv6 можно соединить через традиционную сеть IPv4 (Internet). Если граничные маршрутизаторы поддерживают LISP, передача пакетов между ЦОД выполняется без какой-либо трансляции, поскольку исходные пакеты IPv6 (в пространстве EID) LISP будет инкапсулировать и передавать в пакетах IPv4 традиционной сети Internet через IPv4 RLOC.

7.3. LISP для VPN

Обычно в одной физической инфраструктуре работает несколько виртуальных сетей. В таких ситуациях определение принадлежности пакета к виртуальной сети становится важной задачей и для этого часто применяются теги или метки. При использовании LISP пакеты можно различать по полю Instance ID. Когда ITR инкапсулирует пакет из определённой виртуальной сети (например, известной по VRF3 или VLAN), он помечает инкапсулированный пакет значением Instance ID, соответствующим виртуальной сети. Когда ETR получает пакет с Instance ID, он использует это поле для определения принадлежности пакета.

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

7.4. LISP для мобильности VM в ЦОД

Способ обеспечения бесшовной можильности виртуальных машин (VM) в ЦОД состоит в представлении опорной сети ЦОД как пространства RLOC, а подсетей с серверами, как пространство EID. Маршрутизаторы LISP помещаются на границе между магистралью и каждой подсетью серверов. При перемещении VM в другую подсеть она может (временно) сохранить прежний адрес для продолжения работы без сброса транспортных соединений. Когда xTR обнаруживает адрес источника из другой подсети, он регистрирует адрес в системе сопоставления. Для информирования других маршрутизаторов LISP о переносек виртуальной машины и её новом местоположении, чтобы избежать обходных путей через исходную подсеть, применяются такие механизмы, как сообщения Solicit-Map-Request.

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

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

Обычно плоскость данных реализуется на быстром пути маршрутизаторов для обеспечения высокоскоростной пересылки, тогда как плоскость управления реализуется на медленном пути маршрутизаторов для обеспечения гибкости. Разрыв производительности медленного и быстрого пути может составлять несколько порядков. Поэтому нужно тщательно обдумать способ уведомления плоскости управления о событиях в плоскости данных, чтобы не перегрузить медленный путь, следует также применять ограничение скорости, как указано в [RFC9300] и [RFC9301].

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

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

Сопоставления являются центральным элементом LISP и должны приниматься все меры предосторожности для предотвращения вредоносных манипуляций или использования их злоумышленниками. Использование доверенных серверов Map-Server, строго соответствующих [RFC9301], и механизмов аутентификации, предоставляемых LISP-SEC [RFC9303], снижает риск атак на целостность сопоставлений. В более критических средах могут потребоваться меры защиты. Реализация защиты для данной системы сопоставления сильно зависит от архитектуры этой системы и модели угроз, предполагаемой для развёртывания. Поэтому безопасность системы сопоставления должна рассматриваться в соответствующих документах по архитектуре Mapping System.

Как и в других механизмах туннелирования промежуточные устройства на пути между ITR (или PITR) и ETR (или PETR) должны иметь механизмы снятия инкапсуляции для корректной проверки содержимого пакетов с инкапсуляцией LISP.

Как и другие механизчы инкапсуляции и сопоставления (map-and-encap), LISP разрешает «трехстороннюю» маршрутизацию (т. е. поток пакетов проходит через разные граничные маршрутизаторы в зависимости от направления). Это означает, что у промежуточных устройств может не быть полного представления о трафике, который они инспектируют или обрабатывают. Кроме того, пакеты с инкапсуляцией LISP маршрутизируются по внешним адресам IP (RLOC) и могут быть доставлены маршрутизатору ETR, который не отвечает за EID получателя пакета, или сетевому элементу, не являющемуся ETR. Снижение риска обеспечивается применением подходящих методов фильтрации, на элементах сети, которые могут получать неожиданные пакеты с инкапсуляцией LISP.

Дополнительные сведения о влиянии LISP на безопасность приведены в [RFC7835].

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

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

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

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

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

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, “Address Allocation for Private Internets”, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC2992] Hopps, C., “Analysis of an Equal-Cost Multi-Path Algorithm”, RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.

[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol”, RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.

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

[RFC5944] Perkins, C., Ed., “IP Mobility Support for IPv4, Revised”, RFC 5944, DOI 10.17487/RFC5944, November 2010, <https://www.rfc-editor.org/info/rfc5944>.

[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, “Mobility Support in IPv6”, RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.

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

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

[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)”, RFC 6836, DOI 10.17487/RFC6836, January 2013, <https://www.rfc-editor.org/info/rfc6836>.

[RFC6837] Lear, E., “NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database”, RFC 6837, DOI 10.17487/RFC6837, January 2013, <https://www.rfc-editor.org/info/rfc6837>.

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

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

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

[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, “Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)”, RFC 8111, DOI 10.17487/RFC8111, May 2017, <https://www.rfc-editor.org/info/rfc8111>.

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

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

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

[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, “Locator/ID Separation Protocol Security (LISP-SEC)”, RFC 9303, DOI 10.17487/RFC9303, October 2022, <https://www.rfc-editor.org/info/rfc9303>.

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

[Jakab] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, “LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System”, IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343, DOI 10.1109/JSAC.2010.101011, October 2010, <https://ieeexplore.ieee.org/document/5586446>.

[LISP-EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, “EID Mappings Multicast Across Cooperating Systems for LISP”, Work in Progress, Internet-Draft, draft-curran-lisp-emacs-00, 9 November 2007, <https://www.ietf.org/archive/id/draft-curran-lisp-emacs-00.txt>.

[LISP-SHDHT] Cheng, L. and M. Sun, “LISP Single-Hop DHT Mapping Overlay”, Work in Progress, Internet-Draft, draft-cheng-lisp-shdht-04, 15 July 2013, <https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt>.

[Mathy] Mathy, L. and L. Iannone, “LISP-DHT: Towards a DHT to map identifiers onto locators”, CoNEXT ’08: Proceedings of the 2008 ACM CoNEXT Conference, ReArch ’08 — Re-Architecting the Internet, DOI 10.1145/1544012.1544073, December 2008, <https://dl.acm.org/doi/10.1145/1544012.1544073>.

[Quoitin] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, “Evaluating the Benefits of the Locator/Identifier Separation”, Proceedings of 2nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture, DOI 10.1145/1366919.1366926, August 2007, <https://dl.acm.org/doi/10.1145/1366919.1366926>.

Приложение A. История разделения идентификаторов и локаторов

Архитектура LISP для разделения местоположения и отождествления стала результатом дискуссий во время семинара IAB Routing and Addressing в Амстердаме в октябре 2006 г. [RFC4984].

Сразу после семинара спонтанно сформировалась небольшая группа единомышленников для работы над идеей, возникшей в неформальных дискуссиях на семинаре в различных почтовых конференциях. Первый документ Internet-Draft для LISP появился в январе 2007 г.

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

Протокол LISP перешёл из сферы IRTF в рабочую группу IETF в марте 2009 г. После многочисленных исправления базовые спецификации в начале 2013 г. были выпущены как RFC. Работа по расширению, совершенствованию и поиску новых применений продолжается (и несомненно будет длиться ещё долго). Рабочая группа LISP была в 2018 г. преобразована для продолжения работы над базовым протоколом LISP и создания документов Standards Track.

A.1. Старые модели LISP

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

LISP 1

Все EID появляются в обычных таблицах маршрутизации и пересылки в сети (т. е. являются «маршрутизируемыми»). Это свойство применяется для получения сопоставлений EID с RLOC в процессе начальной загрузки (bootstrapping). Пакеты передаются с EID в качестве адресата во внешнем заголовке и когда ETR видит такой пакет, он передаёт Map-Reply маршрутизатору ITR источника, давая полное сопоставление.

LISP 1.5

LISP 1.5 похож на LISP 1, но маршрутизация EID происходит в отдельной сети.

LISP 2

EID не маршрутизируются, сопоставления EID с RLOC доступны через DNS.

LISP 3

EID не маршрутизируются и их нужно искать в новой базе данных о сопоставлениях EID с RLOC (изачально это была система, использующая распределенные хэш-таблицы). Были возможны два варианта – push-системы, где все отображения распространялись всем ITR, и pull-системы, в которых ITR загружали сопоставления при необходимости.

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

Этот документ инициировал Noel Chiappa и большая часть идей представлена им. Авторы признательны за его важный вклад в работу и благодарны ему.

Спасибо также Dino Farinacci, Fabio Maino, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black.

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

Albert Cabellos
Universitat Politecnica de Catalunya
c/ Jordi Girona s/n
08034 Barcelona
Spain
Email: acabello@ac.upc.edu
 
Damien Saucez (editor)
Inria
2004 route des Lucioles – BP 93
Sophia Antipolis
France
Email: damien.saucez@inria.fr

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

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

nmalykh@protokols.ru

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

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

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

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

RFC 9318 IAB Workshop Report: Measuring Network Quality for End-Users

Internet Architecture Board (IAB)                            W. Hardaker
Request for Comments: 9318                                              
Category: Informational                                       O. Shapira
ISSN: 2070-1721                                             October 2022

IAB Workshop Report: Measuring Network Quality for End-Users

Отчёт семинара IAB по измерению качества сети для конечных пользователей

PDF

Аннотация

Семинар Measuring Network Quality for End-Users был проведён IAB в виртуальном формате 14-16 сентября 2021 г. В этом документе приведены итоги семинара, рассмотренные вопросы и некоторые предварительные выводы, принятые в конце семинара.

Документ является отчётом о работе семинара. Приведённые здесь взгляды и позиции принадлежат участникам семинара и могут не отражать позиции IAB.

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

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

Документ является результатом работы Совета по архитектуре Internet (Internet Architecture Board или IAB) и содержит сведения, которые IAB считает нужным сохранить. Документ представляет согласованный взгляд IAB. Документ был одобрен для публикации IAB и не является кандидатом в Internet Standard, см раздел 2 RFC 7841.

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

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

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

Оглавление

Исключено в версии HTML.

1. Введение

IAB время от времени организует семинары по рассмотрению долгосрочной стратегии и проблем Internet, а также по определению направления развития архитектуры Internet. Такое долгосрочное планирования IAB дополняет текущую инженерную работу IETF1.

Семинар по измерению качества сети для конечных пользователей (Measuring Network Quality for End-Users) [WORKSHOP] проводился в виртуальном режиме 14-16 сентября 2021 г. В этом отчёте приведены итоги семинара, обсуждавшиеся темы и некоторые предварительные выводы, сделанные в конце семинара.

1.1. Пространство проблем

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

В то же время некоторые аспекты взаимодействия с конечными пользователями не обрели существенного улучшения. Многие пользователи сталкиваются с задержками соединений на уровне 10-летней давности. Несмотря на значительное повышение надёжности в средах центров обработки данных (ЦОД), конечные пользователи часто сталкиваются с перебоями в обслуживании. Несмотря на алгоритмические улучшения в теории управления, по-прежнему обнаруживается, что задержки в очередях оборудования последней мили превышают совокупные транзитные задержки. Улучшения в транспорте, такие как QUIC, Multipath TCP, TCP Fast Open, в некоторых сетях ещё поддерживаются не полностью. Точно так же не получили широкого распространения усовершенствования в сфере безопасности и приватности конечных пользователей, такие как шифрование DNS для локальных распознавателей.

Одним из основных факторов отсутствия прогресса является распространённое мнение о том, что пропускная способность часто является единственным показателем качества соединений Internet. С учётом этого семинар Measuring Network Quality for End-Users был нацелен на обсуждение указанных ниже тем.

  • Какова задержка для пользователей в типичных условиях работы?

  • Насколько надёжна связь в долгосрочной перспективе?

  • Позволяют ли сети использовать широкий спектр протоколов?

  • Какие службы могут запускать клиенты сети?

  • Какие типы соединения IPv4, NAT, IPv6 предлагаются, применяются ли межсетевые экраны?

  • Какие механизмы защиты доступны для локальных служб, таких как DNS?

  • В какой степени обеспечивается приватность, конфиденциальность, целостность и подлинность пользовательских коммуникаций?

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

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

  • Какие показатели количественно определяют эти свойства и как их собрать на практике?

  • Каковы наилучшие методы интерпретации этих показателей и их включения в процесс принятия решений?

  • Как лучше всего передать эти свойства поставщикам услуг и операторам сетей?

  • Как эти показатели представить пользователям осмысленным способом?

2. Программа семинара

Семинар Measuring Network Quality for End-Users был разделен по нескольким темам (см. разделы 4 и 5):

  • вводные обзоры и доклад Vint Cerf;

  • показатели;

  • межуровневые вопросы;

  • объединительная часть;

  • выводы.

3. Представленные документы

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

  • Ahmed Aldabbagh. “Regulatory perspective on measuring network quality for end users” [Aldabbagh2021].

  • Al Morton. “Dream-Pipe or Pipe-Dream: What Do Users Want (and how can we assure it)?” [Morton2021].

  • Alexander Kozlov. “The 2021 National Internet Segment Reliability Research”.

  • Anna Brunstrom. “Measuring network quality – the MONROE experience”.

  • Bob Briscoe, Greg White, Vidhi Goel, and Koen De Schepper. “A Single Common Metric to Characterize Varying Packet Delay” [Briscoe2021].

  • Brandon Schlinker. “Internet Performance from Facebook’s Edge” [Schlinker2019].

  • Christoph Paasch, Kristen McIntyre, Randall Meyer, Stuart Cheshire, and Omer Shapira. “An end-user approach to the Internet Score” [McIntyre2021].

  • Christoph Paasch, Randall Meyer, Stuart Cheshire, and Omer Shapira. “Responsiveness under Working Conditions” [Paasch2021].

  • Dave Reed and Levi Perigo. “Measuring ISP Performance in Broadband America: A Study of Latency Under Load” [Reed2021].

  • Eve M. Schooler and Rick Taylor. “Non-traditional Network Metrics”.

  • Gino Dion. “Focusing on latency, not throughput, to provide better internet experience and network quality” [Dion2021].

  • Gregory Mirsky, Xiao Min, Gyan Mishra, and Liuyan Han. “The error performance metric in a packet-switched network” [Mirsky2021].

  • Jana Iyengar. “The Internet Exists In Its Use” [Iyengar2021].

  • Jari Arkko and Mirja Kuehlewind. “Observability is needed to improve network quality” [Arkko2021].

  • Joachim Fabini. “Network Quality from an End User Perspective” [Fabini2021].

  • Jonathan Foulkes. “Metrics helpful in assessing Internet Quality” [Foulkes2021].

  • Kalevi Kilkki and Benajamin Finley. “In Search of Lost QoS” [Kilkki2021].

  • Karthik Sundaresan, Greg White, and Steve Glennon. “Latency Measurement: What is latency and how do we measure it?”

  • Keith Winstein. “Five Observations on Measuring Network Quality for Users of Real-Time Media Applications”.

  • Ken Kerpez, Jinous Shafiei, John Cioffi, Pete Chow, and Djamel Bousaber. “Wi-Fi and Broadband Data” [Kerpez2021]

  • Kenjiro Cho. “Access Network Quality as Fitness for Purpose”.

  • Koen De Schepper, Olivier Tilmans, and Gino Dion. “Challenges and opportunities of hardware support for Low Queuing Latency without Packet Loss” [DeSchepper2021].

  • Kyle MacMillian and Nick Feamster. “Beyond Speed Test: Measuring Latency Under Load Across Different Speed Tiers” [MacMillian2021].

  • Lucas Pardue and Sreeni Tellakula. “Lower-layer performance not indicative of upper-layer success” [Pardue2021].

  • Matt Mathis. “Preliminary Longitudinal Study of Internet Responsiveness” [Mathis2021].

  • Michael Welzl. “A Case for Long-Term Statistics” [Welzl2021].

  • Mikhail Liubogoshchev. “Cross-layer Cooperation for Better Network Service” [Liubogoshchev2021].

  • Mingrui Zhang, Vidhi Goel, and Lisong Xu. “User-Perceived Latency to Measure CCAs” [Zhang2021].

  • Neil Davies and Peter Thompson. “Measuring Network Impact on Application Outcomes Using Quality Attenuation” [Davies2021].

  • Olivier Bonaventure and Francois Michel. “Packet delivery time as a tie-breaker for assessing Wi-Fi access points” [Michel2021].

  • Pedro Casas. “10 Years of Internet-QoE Measurements. Video, Cloud, Conferencing, Web and Apps. What do we Need from the Network Side?” [Casas2021].

  • Praveen Balasubramanian. “Transport Layer Statistics for Network Quality” [Balasubramanian2021].

  • Rajat Ghai. “Using TCP Connect Latency for measuring CX and Network Optimization” [Ghai2021].

  • Robin Marx and Joris Herbots. “Merge Those Metrics: Towards Holistic (Protocol) Logging” [Marx2021].

  • Sandor Laki, Szilveszter Nadas, Balazs Varga, and Luis M. Contreras. “Incentive-Based Traffic Management and QoS Measurements” [Laki2021].

  • Satadal Sengupta, Hyojoon Kim, and Jennifer Rexford. “Fine-Grained RTT Monitoring Inside the Network” [Sengupta2021].

  • Stuart Cheshire. “The Internet is a Shared Network” [Cheshire2021].

  • Toerless Eckert and Alex Clemm. “network-quality-eckert-clemm-00.4”.

  • Vijay Sivaraman, Sharat Madanapalli, and Himal Kumar. “Measuring Network Experience Meaningfully, Accurately, and Scalably” [Sivaraman2021].

  • Yaakov (J) Stein. “The Futility of QoS” [Stein2021].

4. Темы и дискуссии семинара

Программа трехдневного семинара была разбита на 4 части, каждая из которых сыграла свою роль в организации дискуссий. Семинар начался с вводных презентаций и представления пространства проблем (4.1. Введение и обзор), затем обсуждались показатели (4.2. Показатели), межуровневые вопросы (4.3. Межуровневые вопросы) и была проведена общая дискуссия (4.4. Объединительная часть). По завершении этих разделов было проведено обсуждение и сделаны выводы, принятые участниками семинара (5. Выводы).

4.1. Введение и обзор

Семинар начался с широкого обсуждения качества обслуживания (Quality of Service или QoS) и работы (Quality of Experience или QoE) пользователей в современной сети Internet. Цель вводных бесед состояла в подготовке участников семинара к описанию пространства проблем, имеющихся решений и их ограничений.

В презентациях были показаны имеющиеся измерения QoS и QoE, а также их эффективность. Обсуждалось взаимодействие между пользователями в сети, а также между разными уровнями стека протоколов OSI. Vint Cerf выступил с основным докладом, посвященным истории и важности темы.

4.1.1. Основные моменты из доклада Vint Cerf

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

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

Рассмотрим упражнение для определения желаемых свойств. Когда мы рассматриваем пространства параметров, можно отделить «желаемые» свойства от «фундаментальных», например, малую задержку. Примером от Агентства исследовательских проектов (Advanced Research Projects Agency или ARPA) служит желание знать, где находится ракета сейчас, а не где она была. Понимание управляет созданием и выбором конкретных параметров в пространстве проектирования.

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

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

IPv6 ещё не везде реализован достаточно полно. С момента начала работы в 1996 г. пройден длинный путь, но цель ещё не достигнута. В 1996 г. казалось, что внедрить IPv6 достаточно просто, но практика показала иное. В 1996 г. начался бум dot-com, когда быстро тратились большие деньги и момент не был уловлен вовремя, а рынок расширялся экспоненциально. Это следует считать предостережением.

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

Сети с множеством пересылок (multi-hop) постепенно заменяются огромными плоскими сетями с достаточной связностью между операторами, где системы разделяет 1 или 2 этапа пересылки (hop), например, Google, Facebook, Amazon. Фундаментальная архитектура Internet меняется.

4.1.2. Вступительное обсуждение

Internet является общей (shared) сетью на основе протоколов IP, использующей коммутацию пакетов для соединения множества автономных сетей. Отход Internet от технологии соммутации каналов (circuit-switching) позволил выйти за пределы любого другого устройства сети. С другой стороны, отсутствие внутрисетевого регулирования осложняет обеспечение наилучшей работы для каждого пользователя.

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

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

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

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

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

За последние 10 лет усилия Dave Taht и сообщества раздувания буферов (bufferbloat) привели к существенному обновлению алгоритмов очередей для снижения задержки под нагрузкой по сравнению с простыми очередями FIFO. К сожалению, производители домашних маршрутизаторов ещё не реализовали эти алгоритмы в основном из соображений маркетинга и стоимости. Большинство производителей домашних маршрутизаторов зависят от успорителей SoC (System on a Chip) для создания продукции с желаемой пропускной способностью. Производители SoC выбирают простейшие алгоритмы и настойчивое (aggressive) агрегирование, считая, что микросхема с более высокой пропускной способностью будет иметь гарантированный спрос. Поскольку потребителям в основном предлагается выбор из высокоскоростных устройств, допущение о том, что рост пропускной способности повышает QoS, продолжает укрепляться.

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

4.1.3. Ключевые точки

  1. Измерение пропускной способности необходимо, но само по себе недостаточно.

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

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

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

  5. Рынок содержимого Internet отличается высокой конкуренцией и многие приложения разрабатывают свой «секретный соус».

4.2. Показатели

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

4.2.1. Базовые показатели производительности

Полная потеря доступа в Internet, несомненно, является худшим случаем для пользователя. К сожалению, если перезагрузка домашнего маршрутизатора не приведёт к восстановлению связности, пользователь мало что может сделать, кроме обращения к своему поставщику услуг. Тем не менее систематический сбор показателей доступности на стороне клиента полезен и может помочь ISP пользователя в поиске и устранении проблемы, позволяя пользователю выбрать лучшего ISP. Доступность можно оценить напрямую, просто пытаясь соединиться со сторны клиента с интересующими удалёнными местами. Например, Ookla [Speedtest] использует большое число устройств Android для измерения доступности сети и сотовой сязи по всему миру. Ookla собирает данные сотен миллионов точек в день и использует их для точной оценки доступности. Другой подход состоит в выводе доступности по частоте отказов и другим тестам. Например, в [FCC_MBA] and [FCC_MBA_methodology] используются тысячи маршрутизаторов с измерительными программами, разработанными [SamKnows]. Эти маршрутизаторы выполняют множество сетевых тестов и сообщают о доступности на основе успешности тестовых соединений.

Измерение полосы (capacity) может быть полезно для конечных пользователей, но оно ещё важнее для сервис-провайдеров и разработчиков приложений. Видеопотоки с высоким разрешением требуют существенно большей полосы, чем иные типы трафика. На момент проведения семинара видеопотоки составляли 90% всего трафика Internet и приносили 95% доходов от монетизации (подписка, сборы, реклама). В результате службы потокового видео, такие как Netflix, должны постоянно справляться с быстрым изменением доступной полосы. Способность измерения доступной полосы в реальном масштабе времени усиливается за счёт алгоритмов адаптивного сжатия (adaptive bitrate или ABR) для обеспечения наилучшего взаимодействия с пользователями. Измерение совокупной потребности в полосе позволяет ISP быть готовыми к скачкам трафика. Например, в новогодние каникулы глобальный спрос на полосу возрастает в 5-7 раз по отношению к иному времени. Для конечных пользователей знание потребности в полосе может помочь при выборе тарифного плана с учётом предполагаемого использования. Однако во многих случаях у конечных пользователей имеется избыток полосы и повышение пропускной способности не нужно для них. Способность отличать пропускную способность от полезной пропускной способности (goodput) может быть полезна для определения перегрузки в сети.

При измерении качества сети задержка определяется временем прохождения пакета по сетевому пути от одного конца до другого. На момент написания отчёта пользователи во многих местах по миру имели доступ в Internet с достаточной пропускной способностью и доступностью. Для этих пользователей снижение задержки вместо повышения пропускной способности может вести к значительному росту QoE. Показателем задержки является время кругового обхода (round-trip time или RTT), обычно измеряемое в миллисекундах. Однако пользователи часто считают RTT неудобным показателем в отличие от других показателей производительности, поскольку высокое значение RTT указывает большую задержку, а пользователи обычно считают большие значения лучшими. Для решения этой проблемы в [Paasch2021] и [Mathis2021] предложен обратный показатель – число RTT в минуту (Round-trips Per Minute или RPM).

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

Измерения показывают, что быстрое изменение пропускной способности влияет на задержку. В [Foulkes2021] предпринята попытка количественной оценки частоты возникновения «нестабильности» сети (высокой задержки при очень низкой пропускной способности) при быстром изменении пропускной способности. Такие изменения могут быть вызваны отказами в инфраструктуре, но гораздо чаще связаны с событиями внутри сети, такими как изменение правил организации трафика или быстрые изменения перекрестного трафика (cross-traffic).

Представленные на семинаре данные показывают, что у 36% измеренных линий показатель пропускной способности меняется больше чем на 10% в течение для и нескольких дней. Эти различия связаны с многими переменными, включая локальные методы подключения (Wi-Fi и Ethernet), конкурирующий трафик ЛВС, загрузки и конфигурация устройства, время суток, пропускная способность локального соединения или транспорта. Эти изменения факторов осложняют измерение пропускной способности с использованием лишь устройства конечного пользователя или иного устройства оконечной сети. Маршрутизатор сети, просматривающий агрегированный трафик от нескольких устройств, обеспечивает лучшую точку измерения пропускной способности. Такой тест может учитывать весь локальный трафик и выполнить независимое тестирование пропускной способности. Однако различные факторы все равно могут ограничивать точность такого теста. Для аккуратного измерения пропускной способности нужно множество выборок.

Поскольку пользователь воспринимает Internet через приложения, сопоставление изменений пропускной способности и задержки с качеством работы пользователя может быть затруднительным. Например. web-браузеры полагаются на кэшированные версии страниц для боле быстрой загрузки и смягчения потерь связности. Кроме того, приложения социальных сетей часто полагаются на предварительную загрузку элементов «ленты». Эти методы делают базовые показатели сети менее информативными в части удовлетворения пользователей и требуют сбора данных непосредственно от приложений конечного пользователя.

Полезно отличать приложения, работающие с «фиксированным бюджетом задержки», от приложений, устойчивых к вариациям задержки. Облако игр служит примером приложения, которому нужен «фиксированный бюджет задержки», овых серверов, поскольку всплеск задержки может определять решение «выигрыш-проигрыш» для игрока. Компании, конкурирующие на прибыльном рынке облачных игр, вкладывают значительные средства в инфраструктуру, такие как создание ЦОД ближе к пользователям. Эти ЦОД подчёркивают экономическую выгоду от снижения числа всплесков задержки, превышающую связанные с этим расходы на развёртывание. С другой стороны, более стойкие к всплескам задержки приложения могут продолжать нормальную работу даже при коротких всплесках. Тем не менее, даже такие приложения могут выиграть от неизменно низкой задержки при изменении загрузки. Например, приложения «видео по запросу» (Video-on-Demand или VOD) могут достаточно хорошо работать при линейном потреблении видеопотока, но при переключении пользователем канала или прокуртке вперёд у пользователя могут возникнуть проблемы, если задержка недостаточно мала.

По мере развития приложений все большее значение приобретают их внутренние показатели. Например, приложения VOD могут оценивать QoE по зависимым от приложения показателям, таким как способность видеопроигрывателя использовать максимально возможное разрешение, определять плавность или «замораживание» изображения и т. п. Разработчики приложений могут эффективно применять эти показатели для определения приоритета будущих работ. Все популярные видео-платформы (YouTube, Instagram, Netflix и пр.) имеют схемы сбора и анализа показателей VOD. Одним из примеров является модель Scuba, применяемая в Meta [Scuba].

К сожалению внутренние показатели приложений могут быть слишком сложными для сравнительных исследований. Во-первых, разные приложения часто используют различные показатели для измерения одних и тех же явлений. Например, приложение A может измерять гладкость видео по среднему времени повторной буферизации, а приложение B может полагаться на вероятность повторной буферизации в течение 1 секунды для тех же целей. Другая проблема с внутренними показателями приложений состоит в том, что VOD является важным источником прибыли для YouTube, Facebook, Netflix, что создаёт препятствия обмену внутренними данными. Ещё одна проблема связана с вопросами приватности, связанными с внутреннеми показателями приложений, которые точно описывают действия и предпочтения конкретных пользователей.

4.2.2. Показатели применимости

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

4.2.3. Показатели пропускной способности

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

Фактическая пропускная способность сетевого соединения определяется оборудованием и линиями на пути через сеть и меняется в течение дня или нескольких дней. Исследования с линиями DSL в Северной Америке показывают, что более 30% этих линий имеют показатели пропускной способности меняющиеся более чем на 10% в течение для или нескольких дней.

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

  1. Наличие конкурирующего тарфика в ЛВС или средах WAN. В ЛВС конкурирующий трафик образует несколько устройств, использующих одно соединение с Internet. В WAN конкурирующий трафик часто возникает из несвязанных сетевых потоков, использующих общий путь через сеть.

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

  3. Активные средства управления трафиком, такие как формователи и ограничители трафика, зачастую применяемые провайдерами.

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

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

4.2.4. Показатели задержки

Сквозная задержка – это время, за которое конкретный пакет проходит путь через сеть от пользователя к адресату и обратно. Задержка состоит из нескольких частей.

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

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

  3. Задержки транспортных протоколов, отражающие время, затраченное на повтор передачи и сборку, а также время, когда транспорт был заблокирован (head-of-line blocked).

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

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

Если измерения проводятся при типичной загрузке сети, результат отражает несколько частей задержки. В отчёте такая задержка называется рабочей (working latency). В других документах применяется термин «задержка под нагрузкой» (latency under load или LUL).

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

Таблица 1.

Направление

Технология

Задержка при работе

Задержка при простое

Разность задержек

Отношение работа/простой

Нисходящее

FTTH

148

10

138

15

Нисходящее

Cable

103

13

90

8

Нисходящее

DSL

194

10

184

19

Восходящее

FTTH

207

12

195

17

Восходящее

Cable

176

27

149

6

Восходящее

DSL

686

27

659

25

Хотя исторически средства измерения задержки были сосредоточены на задержках при бездействии, в отрасли наблюдается тенденция к измерению рабочей задержки (например, в Apple [NetworkQuality]).

4.2.5. Примеры измерений

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

В [Paasch2021] представлена методика измерения рабочей задержки с точки зрения конечного пользователя. Предложенный метод постепенно добавляет сетевые потоки между пользовательским устройством и сервером, пока не возникнет «пробка» (bottleneck). Из этих измерений выводится время кругового обхода, сообщаемое конечному пользователю. Авторы решили выдавать результаты с метрикой RPM. Метод реализован в Apple macOS Monterey.

В [Mathis2021] пременена метрика RPM к результатам более 4 миллиардов тестов загрузки, которые были выполнены M-Lab в 2010-2021 гг. За это время измерительная платформа Mпретерпела несколько обновлений, что позволило команде исследователей сравнить влияние различных механизмов контроля перегрузок TCP (congestion control algorithm или CCA) на измерение сквозной задержки. Исследование показало, что применение кубического CCA ведёт к росту рабочей задержки, связанному с использованием очередей большего размера.

В [Schlinker2019] представлено масштабное исследование с попыткой сопоставить полезную пропускную способность (goodput) и QoE в большой социальной сети. Авторы проводили измерения в нескольких ЦОД из которых передавались сегменты видео заданного размера потоками большому числу конечных пользователей. Авторы применяли показатели полезной и общей пропускной способности для обнаружения перегрузки отдельных путей.

В [Reed2021] представлен анализ измерений рабочей задержки собранных по программе Measuring Broadband America (MBA) Федеральной комиссии по связи (Federal Communication Commission или FCC). FCC не включает рабочую задержку в свои годовые отчёты, но предоставляет её в файлах необработанных данных. Авторы использовали часть необработанных данных для определения важных различий между рабочими задержками у разных ISP.

В [MacMillian2021] представлен анализ измерений рабочей задержки на нескольких уровнях обслуживания. Обнаружено (неудивительно), что пользователи уровня premium сталкиваются с меньшей рабочей задержкой по сравнению с уровнем value. Данные показывают, что рабочая задержка существенно меняется на каждом уровне, одним из возможных объяснений является установка в домах разного оборудования.

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

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

4.2.6. Ключевые точки показателей

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

  1. Показатели доступности, указывающие возможность доступа пользователя в сеть.

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

  3. Показатели задержки, указывающие, может ли пользователь получить данные своевременно.

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

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

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

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

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

  3. Метрика RPM является стабильной, большие значения говорят о лучшем качестве и метрика более понятна конечномк пользователю.

  4. Связь между общей и полезной пропускной способностью может быть полезна при поиске точек насыщения не стороне клиента [Paasch2021] и сервера [Schlinker2019].

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

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

4.3. Межуровневые вопросы

В межуровневой части семинара были представлены материалы и прощли дискуссии о точно обнаружении проблемных мест. Обсуждение сосредоточилось на различиях между кабельными и беспроводными соединениями и сложности точного определения проблемных мест в случаях, когда качество зависит от множества разнотипных сегментов сети. Например, в [Kerpez2021] показано, что Wi-Fi 2,4 ГГц с ограниченной пропускной способностью чаще всего создаёт «пробки». С Wi-Fi на частоте 5 ГГц связано лишь 20% наблюдавшихся пробок.

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

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

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

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

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

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

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

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

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

  • Сопутствующий набор инструментов для анализа данных.

4.3.1. Разделение ответственности

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

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

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

  • у контролирующих поведение сетей и/или приложений субъектов может не быть доступа ко всем измеренным данным.

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

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

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

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

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

4.3.3. Вопросы измерения показателей

  • Указанные ниже показатели протокола TCP сочтены эффективными и доступными для пассивных измерений.

    • Задержка соединения TCP, измеряемая по времени SACK или ACK, а также время между повторными передачами TCP служат хорошими показателями для сквозных измерений RTT.

    • На платформах Linux структура tcp_info является фактическим стандартом для приложений, позволяющим проверить производительность сети в пространстве ядра. Однако в пользовательском пространстве эквивалентного фактического стандарта нет.

  • Протоколы QUIC и MASQUE усложняют пассивные измерения производительности.

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

    • Формат QLOG представляется наиболее подходящим для такого обмена.

4.3.4. Пути улучшения межуровневой наблюдаемости

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

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

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

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

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

На момент проведения семинара типичные домашние маршрутизаторы использовали одну очередь FIFO достаточно большого размера для амортизации издержек, связанных с заголовками нижних уровней в различных транспортных PDU. Это хорошо работало с кубическим алгоритмом контроля перегрузок, однако новые алгоритмы способны работать с гораздо меньшими очередями. Чтобы обеспечить задержки меньше 1 мсек, домашний маршрутизатор должен эффективно работать при последовательной передаче всего нескольких сегментов, а не быть оптимизированным для длительных пиков пакетов. Ещё одной конструктивной особенностью домашних маршрутизаторов является агрегирование пакетов для дополнительной амортизации издержек, связанных с заголовками нижних уровней. В частности, несколько дейтаграмм IP объединяются в один большой кадр передачи. Однако такое агрегирование может добавлять к задержке пакетов в устройстве до 10 мсек.

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

4.3.6. Ключевые точки межуровневых измерений

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

  • Выявление проблемных мест затруднено из-за измерений не множестве сегментов пути.

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

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

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

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

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

4.4. Объединительная часть

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

4.4.1. Вопросы измерений и показателей

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

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

4.4.2. Представление показателей конечного пользователя

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

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

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

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

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

4.4.3. Ключевые точки объединения

  • Некоторые предложенные показатели:

    • число круговых обходов в минуту (Round-trips Per Minute или RPM);

    • число пользователей на сеть;

    • задержка;

    • 99% задержки и пропускная способность.

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

  • Сеть с общим доступом существенно влияет на качество.

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

  • Для успешных исследований требуется лучшее финансирование.

  • Конечные пользователи лучше поймут упрощённую систему оценки или ранжирования.

5. Выводы

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

5.1. Общие заявления

  1. Пропускная способность (полоса) необходима, но не достаточна.

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

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

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

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

  6. Полезные показатели для ценности (goodness) должны фактически стимулировать ценность – хорошим показателям следует быть действенными в плане совершенствования отрасли.

  7. Снижение задержки в Internet принесёт пользу всем конечным пользователям.

5.2. Конкретные заявления о протоколах и методах

  1. Число круговых обходов в минуту (RPM) является полезным и востребованным показателем.

  2. Нужны полезные инструменты, заполняющие зазоры между тестами доступности сети, задержки и скорости.

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

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

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

  6. Новые измерения и методы QoS и QoE не должны зависеть лишь от заголовков TCP.

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

5.3. Заявления о проблемах и ответственности

  1. Измерения медианного и среднего значения задержки отвлекают от более важных измерений.

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

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

  4. Для перспективных сетей важно учитывать влияние на экологию применяемых материалов и энергии.

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

5.4. Утверждения, по которым не достигнуто согласия

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

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

  2. Измерения должны поддерживать локализацию отчётов для нахождения проблем.

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

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

  1. Заинтересованные стороны не настроены на лёгкие победы в этом направлении.

6. Последующая работа

На семинаре обсуждались вопросы будущей работы. Предложено часть работ продолжать в имеющихся рабочих группах IETF (например, IPPM, DetNet, RAW), а длительные исследования могут потребовать создания групп IRTF.

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

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

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

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

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

  • как сети с превышением трафика (oversubscribed) могут казаться находящимися под DDoS-атакой.

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

[Aldabbagh2021] Aldabbagh, A., “Regulatory perspective on measuring network quality for end-users”, September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/2021-09-07-Aldabbagh-Ofcom-presentationt-to-IAB-1v00-1.pdf>.

[Arkko2021] Arkko, J. and M. Kühlewind, “Observability is needed to improve network quality”, August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/iab-position-paper-observability.pdf>.

[Balasubramanian2021] Balasubramanian, P., “Transport Layer Statistics for Network Quality”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/transportstatsquality.pdf>.

[Briscoe2021] Briscoe, B., White, G., Goel, V., and K. De Schepper, “A Single Common Metric to Characterize Varying Packet Delay”, September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/single-delay-metric-1.pdf>.

[Casas2021] Casas, P., “10 Years of Internet-QoE Measurements Video, Cloud, Conferencing, Web and Apps. What do we need from the Network Side?”, August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/net_quality_internet_qoe_CASAS.pdf>.

[Cheshire2021] Cheshire, S., “The Internet is a Shared Network”, August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/draft-cheshire-internet-is-shared-00b.pdf>.

[Davies2021] Davies, N. and P. Thompson, “Measuring Network Impact on Application Outcomes Using Quality Attenuation”, September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/PNSol-et-al-Submission-to-Measuring-Network-Quality-for-End-Users-1.pdf>.

[DeSchepper2021] De Schepper, K., Tilmans, O., and G. Dion, “Challenges and opportunities of hardware support for Low Queuing Latency without Packet Loss”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Nokia-IAB-Measuring-Network-Quality-Low-Latency-measurement-workshop-20210802.pdf>.

[Dion2021] Dion, G., De Schepper, K., and O. Tilmans, “Focusing on latency, not throughput, to provide a better internet experience and network quality”, August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Nokia-IAB-Measuring-Network-Quality-Improving-and-focusing-on-latency-.pdf>.

[Fabini2021] Fabini, J., “Network Quality from an End User Perspective”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Fabini-IAB-NetworkQuality.txt>.

[FCC_MBA] FCC, “Measuring Broadband America”, <https://www.fcc.gov/general/measuring-broadband-america>.

[FCC_MBA_methodology] FCC, “Measuring Broadband America – Open Methodology”, <https://www.fcc.gov/general/measuring-broadband-america-open-methodology>.

[Foulkes2021] Foulkes, J., “Metrics helpful in assessing Internet Quality”, September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/IAB_Metrics_helpful_in_assessing_Internet_Quality.pdf>.

[Ghai2021] Ghai, R., “Using TCP Connect Latency for measuring CX and Network Optimization”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/xfinity-wifi-ietf-iab-v2-1.pdf>.

[Iyengar2021] Iyengar, J., “The Internet Exists In Its Use”, August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/The-Internet-Exists-In-Its-Use.pdf>.

[Kerpez2021] Shafiei, J., Kerpez, K., Cioffi, J., Chow, P., and D. Bousaber, “Wi-Fi and Broadband Data”, September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Wi-Fi-Report-ASSIA.pdf>.

[Kilkki2021] Kilkki, K. and B. Finley, “In Search of Lost QoS”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Kilkki-In-Search-of-Lost-QoS.pdf>.

[Laki2021] Nadas, S., Varga, B., Contreras, L.M., and S. Laki, “Incentive-Based Traffic Management and QoS Measurements”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/11/CamRdy-IAB_user_meas_WS_Nadas_et_al_IncentiveBasedTMwQoS.pdf>.

[Liubogoshchev2021] Liubogoshchev, M., “Cross-layer Cooperation for Better Network Service”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Cross-layer-Cooperation-for-Better-Network-Service-2.pdf>.

[MacMillian2021] MacMillian, K. and N. Feamster, “Beyond Speed Test: Measuring Latency Under Load Across Different Speed Tiers”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/2021_nqw_lul.pdf>.

[Marx2021] Marx, R. and J. Herbots, “Merge Those Metrics: Towards Holistic (Protocol) Logging”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/MergeThoseMetrics_Marx_Jul2021.pdf>.

[Mathis2021] Mathis, M., “Preliminary Longitudinal Study of Internet Responsiveness”, August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Preliminary-Longitudinal-Study-of-Internet-Responsiveness-1.pdf>.

[McIntyre2021] Paasch, C., McIntyre, K., Shapira, O., Meyer, R., and S. Cheshire, “An end-user approach to an Internet Score”, September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Internet-Score-2.pdf>.

[Michel2021] Michel, F. and O. Bonaventure, “Packet delivery time as a tie-breaker for assessing Wi-Fi access points”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/camera_ready_Packet_delivery_time_as_a_tie_breaker_for_assessing_Wi_Fi_access_points.pdf>.

[Mirsky2021] Mirsky, G., Min, X., Mishra, G., and L. Han, “The error performance metric in a packet-switched network”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/IAB-worshop-Error-performance-measurement-in-packet-switched-networks.pdf>.

[Morton2021] Morton, A. C., “Dream-Pipe or Pipe-Dream: What Do Users Want (and how can we assure it)?”, Work in Progress, Internet-Draft, draft-morton-ippm-pipe-dream-01, 6 September 2021, <https://datatracker.ietf.org/doc/html/draft-morton-ippm-pipe-dream-01>.

[NetworkQuality] Apple, “Network Quality”, <https://support.apple.com/en-gb/HT212313>.

[Paasch2021] Paasch, C., Meyer, R., Cheshire, S., and O. Shapira, “Responsiveness under Working Conditions”, Work in Progress, Internet-Draft, draft-cpaasch-ippm-responsiveness-01, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01>.

[Pardue2021] Pardue, L. and S. Tellakula, “Lower-layer performance is not indicative of upper-layer success”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Lower-layer-performance-is-not-indicative-of-upper-layer-success-20210906-00-1.pdf>.

[Reed2021] Reed, D.P. and L. Perigo, “Measuring ISP Performance in Broadband America: A Study of Latency Under Load”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Camera_Ready_-Measuring-ISP-Performance-in-Broadband-America.pdf>.

[SamKnows] “SamKnows”, <https://www.samknows.com/>.

[Schlinker2019] Schlinker, B., Cunha, I., Chiu, Y., Sundaresan, S., and E. Katz-Basset, “Internet Performance from Facebook’s Edge”, February 2019, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Internet-Performance-from-Facebooks-Edge.pdf>.

[Scuba] Abraham, L. et al., “Scuba: Diving into Data at Facebook”, <https://research.facebook.com/publications/scuba-diving-into-data-at-facebook/>.

[Sengupta2021] Sengupta, S., Kim, H., and J. Rexford, “Fine-Grained RTT Monitoring Inside the Network”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Camera_Ready__Fine-Grained_RTT_Monitoring_Inside_the_Network.pdf>.

[Sivaraman2021] Sivaraman, V., Madanapalli, S., and H. Kumar, “Measuring Network Experience Meaningfully, Accurately, and Scalably”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/CanopusPositionPaperCameraReady.pdf>.

[Speedtest] Ookla, “Speedtest”, <https://www.speedtest.net>.

[Stein2021] Stein, Y., “The Futility of QoS”, August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/QoS-futility.pdf>.

[Welzl2021] Welzl, M., “A Case for Long-Term Statistics”, February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/iab-longtermstats_cameraready.docx-1.pdf>.

[WORKSHOP] IAB, “IAB Workshop: Measuring Network Quality for End- Users, 2021”, September 2021, <https://www.iab.org/activities/workshops/network-quality>.

[Zhang2021] Zhang, M., Goel, V., and L. Xu, “User-Perceived Latency to Measure CCAs”, September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/User_Perceived_Latency-1.pdf>.

Приложение A. Программный комитет

Jari Arkko
Olivier Bonaventure
Vint Cerf
Stuart Cheshire
Sam Crowford
Nick Feamster
Jim Gettys
Toke Hoiland-Jorgensen
Geoff Huston
Cullen Jennings
Katarzyna Kosek-Szott
Mirja Kühlewind
Jason Livingood
Matt Mathis
Randall Meyer
Kathleen Nichols
Christoph Paasch
Tommy Pauly
Greg White
Keith Winstein

Приложение B. Руководители семинара

Wes Hardaker
Evgeny Khorov
Omer Shapira

Приложение C. Участники семинара

Ahmed Aldabbagh
Jari Arkko
Praveen Balasubramanian
Olivier Bonaventure
Djamel Bousaber
Bob Briscoe
Rich Brown
Anna Brunstrom
Pedro Casas
Vint Cerf
Stuart Cheshire
Kenjiro Cho
Steve Christianson
John Cioffi
Alexander Clemm
Luis M. Contreras
Sam Crawford
Neil Davies
Gino Dion
Toerless Eckert
Lars Eggert
Joachim Fabini
Gorry Fairhurst
Nick Feamster
Mat Ford
Jonathan Foulkes
Jim Gettys
Rajat Ghai
Vidhi Goel
Wes Hardaker
Joris Herbots
Geoff Huston
Toke Høiland-Jørgensen
Jana Iyengar
Cullen Jennings
Ken Kerpez
Evgeny Khorov
Kalevi Kilkki
Joon Kim
Zhenbin Li
Mikhail Liubogoshchev
Jason Livingood
Kyle MacMillan
Sharat Madanapalli
Vesna Manojlovic
Robin Marx
Matt Mathis
Jared Mauch
Kristen McIntyre
Randall Meyer
François Michel
Greg Mirsky
Cindy Morgan
Al Morton
Szilveszter Nadas
Kathleen Nichols
Lai Yi Ohlsen
Christoph Paasch
Lucas Pardue
Tommy Pauly
Levi Perigo
David Reed
Alvaro Retana
Roberto
Koen De Schepper
David Schinazi
Brandon Schlinker
Eve Schooler
Satadal Sengupta
Jinous Shafiei
Shapelez
Omer Shapira
Dan Siemon
Vijay Sivaraman
Karthik Sundaresan
Dave Taht
Rick Taylor
Bjørn Ivar Teigen
Nicolas Tessares
Peter Thompson
Balazs Varga
Bren Tully Walsh
Michael Welzl
Greg White
Russ White
Keith Winstein
Lisong Xu
Jiankang Yao
Gavin Young
Mingrui Zhang

Члены IAB на момент принятия документа для публикации

Jari Arkko
Deborah Brungard
Lars Eggert
Wes Hardaker
Cullen Jennings
Mallory Knodel
Mirja Kühlewind
Zhenbin Li
Tommy Pauly
David Schinazi
Russ White
Qin Wu
Jiankang Yao

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

Авторы признательны участникам семинара, членам IAB и программному комитету за интересные дискуссии.

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

Спасибо участникам работы над этим документом:

Erik Auerswald
Simon Leinen
Brian Trammell

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

Wes Hardaker
Email: ietf@hardakers.net
Omer Shapira
Email: omer_shapira@apple.com

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

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

nmalykh@protokols.ru

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

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

RFC 9308 Applicability of the QUIC Transport Protocol

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

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

Оглавление

Исключено в версии HTML.

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

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

Потоки и соединения могут передать не более 262-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).

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

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

Gorry Fairhurst
Ian Swett
Igor Lubashev
Lucas Pardue
Mike Bishop
Mark Nottingham
Martin Duke
Martin Thomson
Sean Turner
Tommy Pauly

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

Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
 
Brian Trammell
Google Switzerland GmbH
Gustav-Gull-Platz 1
CH-8004 Zurich
Switzerland
Email: ietf@trammell.ch

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

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

nmalykh@protokols.ru

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

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

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

RFC 9314 YANG Data Model for Bidirectional Forwarding Detection (BFD)

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.

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

Оглавление

Исключено в версии HTML.

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

Множитель времени обнаружения, как указано в BFD [RFC5880].

desired-min-tx-interval

Желаемый минимальный интервал передачи (Desired Min TX), как указано в BFD [RFC5880].

required-min-rx-interval

Требуемый минимальный интервал получения (Required Min RX), как указано в BFD [RFC5880].

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

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

key-chain

Ссылка на key-chain, как задано в YANG Data Model for Key Chains [RFC8177]. Ключи, криптоалгоритмы, сроки действия ключей и т. п. определены в модели key-chain.

meticulous

Включает скрупулёзный (meticulous) режим, заданный в BFD [RFC5880].

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 – адрес отправителя

Адрес, относящийся к локальной системе в соответствии с Bidirectional Forwarding Detection (BFD) for Multihop Paths [RFC5883].

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

Адрес, относящийся к удаленной системе в соответствии с [RFC5883].

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

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

tx-ttl

TTL в исходящих пакетах управления BFD;

rx-ttl

минимальное значение TTL во входящих пакетах управления BFD.

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

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD.

2.10.2. Модуль ietf-ip

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

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

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv4.

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

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv4.

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

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv6.

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

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv6.

2.10.3. Модуль ietf-mpls

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

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

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD.

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

Этот список задаёт сессии BFD IP single-hop. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD IP single-hop. Узлы source-addr и dest-addr могут служить для передачи пакетов BFD ничего не подозревающим адресатам. В [RFC5880] описано смягчение таких угроз для BFD. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD IP single-hop.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-group

Этот список задаёт группы сессий BFD IP multihop. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD IP multihop. Узлы source-addr и dest-addr могут служить для передачи пакетов BFD ничего не подозревающим адресатам. В [RFC5880] описано смягчение таких угроз для BFD. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD IP multihop.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions

Этот список задаёт группы сессий BFD через LAG. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD через LAG. Узлы ipv4-dest-addr и ipv6-dest-addr могут служить для передачи пакетов BFD ничего не подозревающим адресатам. В [RFC5880] описано смягчение таких угроз для BFD. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD через LAG.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-group

Этот список задаёт группы сессий BFD через MPLS. Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD через MPLS LSP. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD через MPLS LSP.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/egress

Узлы данных local-multiplier, desired-min-tx-interval, required-min-rx-interval, min-interval влияют на сессии BFD через MPLS LSP, для которых это устройство служит выходным узлом MPLS LSP. Узлы данных аутентификации key-chain и meticulous влияют на защиту сессий BFD через MPLS LSP для таких узлов.

В модулях 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

Эти сведения раскрывают число сессий BFD IP single-hop в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/sessions/session/

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IP single-hop.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/summary

Эти сведения раскрывают число сессий BFD IP multihop в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/session-groups/session-group/sessions

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IP multihop.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv4-session-statistics/summary

Эти сведения раскрывают число сессий micro-BFD IPv4 LAG в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv4

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IPv4 LAG.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/micro-bfd-ipv6-session-statistics/summary

Эти сведения раскрывают число сессий micro-BFD IPv6 LAG в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd-ipv6

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD IPv6 LAG.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/summary

Эти сведения раскрывают число сессий BFD через MPLS LSP в состояниях up, down, admin-down. Счётчики включают сессии BFD, которые пользователь не имеет права читать.

/routing/control-plane-protocols/control-plane-protocol/bfd/mpls/session-groups/session-group/sessions

Доступ к узлам local-discriminator и remote-discriminator (вместе с узлами из контейнера аутентификации) позволяет создавать фиктивные пакеты BFD через MPLS LSP.

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

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

Mahesh Jethanandani (editor)
Xoriant Corporation
1248 Reamwood Ave
Sunnyvale, CA 94089
United States of America
Email: mjethanandani@gmail.com
 
Reshad Rahman (editor)
Canada
Email: reshad@yahoo.com
 
Lianshu Zheng (editor)
Huawei Technologies
China
Email: veronique_cheng@hotmail.com
 
Santosh Pallagatti
VMware
India
Email: santosh.pallagatti@gmail.com
 
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com

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

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

nmalykh@protokols.ru

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

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

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

RFC 9291 A YANG Network Data Model for Layer 2 VPNs

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.

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

Оглавление

Исключено в версии HTML

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

Множество каналов Ethernet, используемых на стороне клиента (устройство или сеть) для подключения к одной или нескольким краевым точка провайдера (Provider Edge или PE).

L2VPN Service Model (L2SM) – модель сервиса L2VPN

Описание характеристик сервиса L2VPN, соединяющего множество сайтов, с точки зрения клиента. Модель обслуживания клиентов не содержит деталей сети сервс-провайдера. Модель сервиса L2VPN определена в [RFC8466].

L2VPN Network Model (L2NM) – модель сети L2VPN

Модель данных YANG, описывающая сервис L2VPN с точки зрения сети (сетецентричная). Модель содержит сведения о сети сервис-провайдера и может включать выделенные ресурсы. Сетевые контроллеры могут использовать модель для управления конфигурацией сервиса L2VPN в сети сервис-провайдера. Оркестратор сервиса может применять соответствующий модуль YANG для запроса услуг VPN от сетевого контроллера или раскрытия списка активных служб L2VPN. Модель L2NM можно использовать также для извлечения связанных с L2VPN данных состояния (включая OAM3).

MAC-VRF

Таблица виртуальной маршрутизации и пересылки (Virtual Routing and Forwarding или VRF) для MAC4-адреса на PE.

Network controller – контроллер сети

Функциональный элемент, отвечающий за управление сетью сервис-провайдера.

Service orchestrator – организатор (оркестратор) сервиса

Функциональный элемент, взаимодействующий с клиентом, полагающимся на L2VPN, например, L2SM. Организатор сервиса отвечает за устройства подключения CE-PE (Customer Edge to Provider Edge), выбор PE и запросы активизации услуг L2VPN от сетевого контроллера.

Service provider network – сеть сервис-провайдера

Сеть, способная предоставлять связанные с L2VPN услуги.

VPN node – узел VPN

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

VPN network access – доступ в сеть VPN

Абстракция, представляющая сетевые интерфейсы, которые связаны с данным узлом VPN. Трафик, исходящий из сети доступа VPN, относится к VPN. Устройства подключения (носители) между CE и PE завершаются в сети доступа VPN.

VPN service provider – поставщик услуг VPN

Сервис-провайдер, предоставляющий связанные с L2VPN услуги.

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

ACL

Access Control List – список управления доступом.

BGP

Border Gateway Protocol – протокол граничного шлюза (междоменной маршрутизации).

BUM

Broadcast, Unknown Unicast, or Multicast – широковещательный, неизвестный индивидуальный или групповой.

CE

Customer Edge – граница клиента.

ES

Ethernet Segment – сегмент Ethernet.

ESI

Ethernet Segment Identifier – идентификатор сегмента Ethernet.

EVPN

Ethernet VPN – виртуальная частная сеть Ethernet.

L2VPN

Layer 2 Virtual Private Network – виртуальная частная сеть канального уровня.

L2SM

L2VPN Service Model – модель сервиса L2VPN.

L2NM

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

MAC

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

PBB

Provider Backbone Bridging – магистраль провайдера на основе мостов.

PCP

Priority Code Point – код приоритета.

PE

Provider Edge – граница провайдера.

QoS

Quality of Service – качество обслуживания.

RD

Route Distinguisher – отличитель маршрута.

RT

Route Target – цель маршрута.

VPLS

Virtual Private LAN Service – служба виртуальной частной ЛВС.

VPN

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

VPWS

Virtual Private Wire Service – служба виртуального частного провода.

VRF

Virtual Routing and Forwarding – виртуальная маршрутизация и пересылка.

4. Эталонная архитектура

На рисунке 1 показан пример использования L2NM. Напомним, что этот рисунок является расширением архитектуры, представленной в разделе 45 [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

L2NM не является моделью обслуживания клиентов.
Внутреннее представление сервиса (т. е. L2NM) можно отобразить на внешнее представление, доступное клиентам, – модель службы L2VPN (L2VPN Service Model или L2SM) [RFC8466].
В L2NM можно подавать данные, запрошенные клиентами и обычно основанные на шаблоне L2SM. В частности, некоторые части модуля L2SM можно напрямую сопоставить с L2NM, тогда как другие генерируются как функция запрошенной услуги и локальный правил. Имеются локальные компоненты сервис-провайдера, не отображаемые напрямую на L2SM.
Отметим, что применение L2NM у сервис-провайдера не предполагает и не исключает экспорта услуги VPN через L2SM. Это зависит от развёртывания. Тем не менее, решение L2NM пытается максимально соответствовать функциям, поддерживаемым L2SM, для упрощения использования L2NM и L2SM при высокоавтоматизированном предоставлении и доставке услуг VPN.

Модули сетевой топологии

L2VPN включает узлы, являющиеся частью топологии, управляемой сетью сервис-провайдера. Такую топологию можно представить с помощью топологического модуля [RFC8345] или его расширения, такого как модуль YANG для точек подключения услуг (Service Attachment Point или SAP) [YANG-SAPS].

Модули устройств

L2NM не является моделью устройства.
Когда глобальная услуга VPN получена с помощью L2NM, фактическая активация и предоставление сервиса VPN включает различные модули устройств для настройки требуемых при обеспечении сервиса функций. Эти функции поддерживаются узлами VPN и могут управляться через модули YANG для устройств. Такие модули включаю, наряду с прочими:
  • 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

Имя, однозначно указывающее ES в сети сервис-провайдера. Для упрощения ссылок на ES по именам в других модулях определён тип es-ref. Этот тип определён на уровне доступа в сеть VPN L2NM для указания ES (7.6. Доступ в сеть VPN). Пример такого использования в L2NM приведён в A.4. Экземпляр сервиса VPWS-EVPN.

esi-type

Идентификатор сегмента Ethernet (Ethernet Segment Identifier или ESI), как описано в разделе 5 [RFC7432]. Значения ESI могут выдаваться автоматически с указанием или без указания пула для выбора ESI (esi-pool-name). Ниже перечислены поддерживаемые типы.

esi-type-0-operator

ESI напрямую задаёт сервис-провайдер VPN. Значение представляется в ethernet-segment-identifier.

esi-type-1-lacp

ESI создаётся автоматически протоколом LACP (IEEE 802.1AX Link Aggregation Control Protocol) [IEEE802.1AX].

esi-type-2-bridge

ESI создаётся автоматически и определяется на основе протокола мостов L2.

esi-type-3-mac

ESI создаётся на основе MAC и может задаваться автоматически или провайдером VPN.

esi-type-4-router-id

ESI создаётся автоматически или задаётся провайдером VPN на основе Router ID. Можно представлять router-id (7.5. Узлы VPN) для автоматического задания ESI при использовании этого типа.

esi-type-5-asn

ESI создаётся автоматически или задаётся провайдером VPN на основе номера автономной системы (Autonomous System или AS). Можно использовать local-autonomous-system (7.4. Профили глобальных параметров) для автоматического вывода ESI при использовании этого типа.

Автоматически созданные значения можно извлекать с использованием auto-ethernet-segment-identifier.

esi-redundancy-mode

Режим резервирования EVPN для данного ES – Single-Active (параграф 14.1.1 в [RFC7432]) или All-Active (параграф 14.1.2 в [RFC7432]).

df-election

Набор параметров для выбора назначенного узла пересылки (Designated Forwarder или DF) (параграф 8.5 в [RFC7432]). Этот узел данных может служить, например, для указания метода выбора (скажем, [RFC8584] или [EVPN-PERF-DF]). Если метод выбора не задан, применяется заданный по умолчанию (параграф 8.5 в [RFC7432]).
Как указано в параграфе 1.3.2 [RFC8584], по умолчанию принято вызывать процедуру выбора DF при отказе DF (например, сбой канала). Прежний узел DF будет восстановлен, когда станет доступным. Такой режим называется реверсивным (revertive). Поведение можно изменить установкой для листа revertive значения false.
Узел данных можно применять для настройки таймера DF Wait (election-wait-time), см. параграф 2.1 в [RFC8584].

split-horizon-filtering

Управляет активацией фильтра split-horizon для сегмента ES (параграф 8.3 в [RFC7432]).

pbb

Указывает узлы данных, специфичные для PBB [IEEE-802-1ah]:

backbone-src-mac

Связывает адрес B-MAC (Provider Backbone MAC) с ES. Это особенно полезно для многодомных All-Active ES (параграф 9.1 в [RFC7623]).

member

Список членов ES в сети сервис-провайдера.

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

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

encryption-profile-identifier

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

qos-profile-identifier

Профиль качества обслуживания (Quality of Service или QoS), указывающих набор правил для классификации, маркировки и действий (например, [RFC3644]).

bfd-profile-identifier

Профиль обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD), указывающий набор правил BFD [RFC5880], которые могут вызываться при создании службы VPN.

forwarding-profile-identifier

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

routing-profile-identifier

Профиль маршрутизации, указывающий правила маршрутизации (например, правила BGP), вызываемые при предоставлении услуг VPN.

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

Идентификатор, однозначно указывающий службу L2VPN внутри области действия L2NM.

vpn-name

Связывает имя со службой для упрощения идентификации.

vpn-description

Текстовое описание услуги, структуру которого определяет поставщик услуг VPN.

customer-name

Указывает имя клиента, заказавшего услугу.

parent-service-id

Указывает идентификатор родительской службы (например, L2SM, срез сети IETF, VPN+), вызвавшей создание услуги L2VPN. Этот идентификатор служит для упрощения сопоставления (сетевой) услуги как встроенной в сеть по номеру заказа. Контроллер может использовать это сопоставление для уточнения или заполнения некоторых полей (например, description) в зависимости от локального развёртывания.

vpn-type

Указывает тип L2VPN. Ниже приведены определённые в [RFC9181] ипы, которые можно применять для L2NM.

vpls

Виртуальные частные ЛВС (Virtual Private LAN Service VPLS) определены в [RFC4761] и [RFC4762]. Этот тип также используется для иерархических VPLS (H-VPLS) (раздел 10 в [RFC4762]).

vpws

Виртуальные частные провода (Virtual Private Wire Service или VPWS), заданные в параграфе 3.1.1 [RFC4664].

vpws-evpn

VPWS EVPN, определённые в [RFC8214].

pbb-evpn

Магистрали провайдеров на базе мостов (Provider Backbone Bridging или PBB) EVPN, заданные в [RFC7623].

mpls-evpn

EVPN на основе MPLS [RFC7432].

vxlan-evpn

EVPN на основе VXLAN [RFC8365].
Для некоторых узлов данных в L2NM тип применяется в качестве условия.

vpn-service-topology

Указывает топологию сети для службы – hub-spoke, any-to-any, custom. Эти типы заданы в [RFC9181].

bgp-ad-enabled

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

signaling-type

Сигнализация, служащая для организации псевдопроводов. Типы сигнализации взяты из [RFC9181], поддерживаемые опции указаны ниже.

bgp-signaling

L2NM поддерживает две разновидности L2VPN с сигнализацией BGP:

l2vpn-bgp

служба Multipoint VPLS с плоскостью управления BGP в соответствии с [RFC4761] и [RFC6624];

evpn-bgp

служба Multipoint VPLS с плоскостью управления BGP и дополнительными функциями и параметрами EVPN в соответствии с [RFC7432] и [RFC7209].

ldp-signaling

Multipoint VPLS с мэш-структурой псевдопроводов с сигнализацией LDP [RFC6074].

l2tp-signaling

L2NM применяет псевдопровода с сигнализацией L2TP, как описано в [RFC6074].
В таблице 1 дана сводка типов сигнализации для каждго типа услуг VPN (vpn-type). Дополнительные сведения приведены в параграфе 7.5.2. Сигнальные опции.

Таблица 1. Опции сигнализации для типа услуг VPN.

Тип VPN

Опции сигнализации

vpls

l2tp-signaling, ldp-signaling, bgp-signaling (l2vpn-bgp)

vpws

l2tp-signaling, ldp-signaling, bgp-signaling (l2vpn-bgp)

vpws-evpn

bgp-signaling (evpn-bgp)

pbb-evpn

bgp-signaling (evpn-bgp)

mpls-evpn

bgp-signaling (evpn-bgp)

vxlan-evpn

bgp-signaling (evpn-bgp)

global-parameters-profiles

Задаёт многократно применяемые параметры для одной службы L2VPN (7.4. Профили глобальных параметров).

underlay-transport

Описывает предпочтения для транспортной технологии передачи трафика службы VPN. Эти предпочтения особенно полезны в сетях с множеством доменов и типов межсетевых интерфейсов (Network-to-Network Interface или NNI). Базовый транспорт можно указать как экземпляр абстрактного транспорта (например, идентификатором экземпляра VPN+ или виртуальной сети, именем сетевого слоя – slice) или упорядоченным списком фактически разрешённых в сети протоколов. Можно использовать широкий спектр идентификаторов протоколов (или способов организации базового транспорта), указанных в [RFC9181].
Можно использовать модель, заданную в параграфе 6.3.2 [TE-SERVICE-MAPPING], если между PE нуэны специфические требования к защите и доступности.

status

Служит для отслеживания общего состояния данной службы VPN. Услугу можно создать, но не вводить в действие. Рабочее и административное состояние поддерживаются с временными метками и их можно применять в качестве триггеров для обнаружения аномалий в службе. Например, служба, объявленная на уровне сервиса как созданная, но все ещё не активная на уровне сети, указывает, что нужны действия по подготовке сети для согласования наблюдаемого состояния с ожидаемым.

vpn-node

Абстрактное представление набора профилей, применяемых к узлу сети в рамках одного vpn-service. Служба L2VPN обычно создаётся путём добавления экземпляров vpn-node в контейнер vpn-nodes.
В vpn-node содержатся узлы vpn-network-accesses, служащие интерфейсом, подключённым к VPN для приёма клиентского трафика. Поэтому сайты клиентов соединяются с vpn-network-accesses.
Поскольку это модель сети, сведения о сайтах клиентов не требуются в ней и относятся скорее к L2SM. Включение их в L2NM, например, для заполнения узлов description, зависит от реализации.
Дополнительные сведения приведены в параграфе 7.5. Узлы VPN.

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

Уникальный в контексте службы L2VPN идентификатор профиля глобальных параметров.

rd

Поддерживаются режимы назначения RD в соответствии с [RFC9181]: непосредственное (direct) назначение, автоматическое назначение из заданного пула, полностью автоматическое назначение, отсутствие назначения.
Модуль также приспособлен к развёртываниям, где поле Assigned Number в RD назначается из пула, а в поле Administrator устанавливается, например, значение Router ID, выделенное узлу VPN. Модуль поддерживает для управления полем Assigned Number режимы явного (назначения), автоматического назначения из пула и полностью автоматического назначения.

vpn-targets

Задаёт правила импорта-экспорта для службы VPN.

local-autonomous-system

Указывает номер автономной системы (Autonomous System Number или ASN), настроенный для узла VPN. ASN может служить для автоматического вывода других атрибутов, таких как RD или идентификаторы сегментов Ethernet (Ethernet Segment Identifier или ESI).

svc-mtu

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

ce-vlan-preservation

Устанавливается для сохранения идентификаторов Customer Edge VLAN (CE VLAN) от входа до выхода, т. е. тег CE VLAN в выходном кадре будет совпадать с тегом входного кадра, из которого получен данный кадр службы. Если на сайте включена привязка «все к одному» (all-to-one), сохранение применяется для всех входящих кадров службы. Если такая привязка отключена, сохранение применяется для входных (Ingress) кадров сервиса с тегами CE VLAN ID от 1 до 4094.

ce-vlan-cos-preservation

Управляет сохранением класса обслуживания CE VLAN (Class of Service или CoS). При установленном флаге биты кода приоритета (Priority Code Point или PCP) в теге CE VLAN выходных кадров идентичны тагам соответствующих входных кадров.

control-word-negotiation

Управляет согласованием слова управления (control-word). Подробности приведены в разделе 7 [RFC8077].

mac-policies

Набор правил MAC, применяемых к службе:

mac-addr-limit

Контейнер конфигурации ограничений MAC-адресов, включающий узлы:

limit-number

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

time-interval

время устаревания MAC-адреса;

action

действие при достижении предела: отбрасывание пакета, лавинная пересылка, предупреждение.

mac-loop-prevention

Контейнер для предотвращения петель MAC.

window

Интервал времени, в котором обнаруживаются и проверяются события перемещения MAC.

frequency

Число обнаружения дубликатов MAC, после которого возникает ситуация дублирования (duplicate MAC address) в интервале window и MAC-адрес добавляется в список дубликатов.

retry-timer

таймер повторого, по истечении которого дубликаты MAC-адресов исключаются из MAC-VRF.

protection-type

Задаёт тип предоствращения петель (например, shut).

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

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

description

Текстовое описание узла VPN.

ne-id

Идентификатор элемента сети, на котором развернут узел VPN.

role

Роль профиля экземпляра VPN в сети VPN [RFC9181] (например, any-to-any-role, spoke-role, hub-role).

router-id

Уникальный 32-битовый идентификатор маршрутизатора внутри AS.

active-global-parameters-profiles

Список активных профилей глобальных параметров VPN для узла VPN. Один или несколько глобальных профилей, заданных на уровне службы VPN (т. е. под l2vpn-ntw/vpn-services/vpn-service), можно активировать на уровне узла VPN и каждый из них однозначно указывается profile-id. Структура active-global-parameters-profiles использует те же узлы, которые указаны в параграфе 7.4, за исключением узлов, относящихся к RD и RT. Значения в active-global-parameters-profiles переопределяют значения, заданные на уровне службы VPN.

status

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

bgp-auto-discovery

См. 7.5.1. Автоматическое обнаружение BGP.

signaling-option

См. 7.5.2. Сигнальные опции.

vpn-network-accesses

Представляет точку, к которой подключаются сайты. В отличие от L2SM в L2NM не требуется моделировать сайт клиента и охватываются лишь точки, получающие трафик с сайта (т. е. сторона PE в соединениях PE-CE). Поэтому доступ в сеть VPN содержит сведения о связности между сетью провайдера и площадками клиента. Профили VPN (vpn-profiles) включают набор правил маршрутизации, которые могут применяться при создании службы.
Дополнительные сведения приведены в параграфе 7.6. Доступ в сеть VPN.

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 при организации псевдопровода (например, параграф 4.3 в [RFC4667], параграф 5.1 в [RFC6624] или параграф 6.1 в [RFC4762]).

mtu-allow-mismatch

Значение true разрешает несоответствие MTU для псевдопровода (см., например, параграф 4.3 в [RFC4667]).

signaling-type

Тип сигнализации, наследуемый из signaling-type, заданного на уровне службы (7.3. Услуги VPN).

bgp

Предоставляется при использовании BGP для сигнализации L2VPN (см. 7.5.2.1. BGP).

ldp

Модель поддерживает настройку параметров, описанных в разделе 6 [RFC4762] (см. 7.5.2.2. LDP).

l2tp

Модель поддерживает настройку параметров, описанных в разделе 4 [RFC4667] (см. 7.5.2.3. 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

Идентификатор доступа в VPN.

description

текстовое описание доступа в VPN.

interface-id

Интерфейс, с которым связан доступ в VPN.

active-vpn-node-profile

Указатель на активнй профиль global-parameters-profile на уровне узла VPN. Ссылка предполагает, что все связанные узлы данных будут наследоваться доступом в VPN. Однако некоторые наследуемые узлы (например, правила ACL) могут переопределяться на уровне доступа в VPN. Такие значения будут иметь больший приоритет.

status

Административное и рабочее состояние доступа в VPN.

connection

Представляет и группирует множество подключения L2, из которых приходит трафик L2VPN в конкретную сеть VPN (7.6.1. Соединение).

signaling-option

Указывает набор сигнальных опций, относящихся к данному доступу в VPN, например, CE ID (ce-id, указывающий CE внутри VPN) и удалённый CE ID, как описано в параграфе 2.2.2 [RFC6624]. Набор включает также узлы данных, которые нужны для настройки VPWS-EVPN [RFC8214] (см. 7.6.2. Экземпляр службы EVPN-VPWS).

group

Служит для группировки доступа в сети VPN путём назначения им общего идентификатора. Для выделения основного и вторичных вариантов доступа служит атрибут предпочтений. Пример использования этого контейнера для резервирования, приведён в приложении A.6. Контейнер служит также для указания канала ES путём выделения одного ESI, пример этого представлен в приложениях A.4 и A.5.

ethernet-service-oam

Сведения об OAM для службы (см. 7.6.3. Ethernet OAM).

service

Задаёт параметры сервиса (например, QoS и групповая передача), применяемые к доступу в VPN (7.6.4. Службы).

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

Задаёт L2 MTU для доступа в VPN (в байтах).

svc-pe-to-ce-bandwidth и svc-ce-to-pe-bandwidth

Задают пропускную способность для службы L2VPN. Значение svc-pe-to-ce-bandwidth указывает входную пропускную способность (от сервис-провайдера на сайт), svc-ce-to-pe-bandwidth – выходную (с сайта в сеть провайдера). Значения svc-pe-to-ce-bandwidth и svc-ce-to-pe-bandwidth могут быть представлены с использованием гарантированной (Committed Information Rate или CIR), избыточной (Excess Information Rate или EIR) или пиковой (Peak Information Rate или PIR) скорости передачи.
Как показано на рисунке 19, структура узлов данных наследуется от L2SM [RFC8466]. Ниже приведены определённые в [RFC9181] типы, которые можно использовать для указания пропускной способности.

bw-per-cos

Пропускная способность на CoS.

bw-per-port

Пропускная способность на доступ в VPN.

bw-per-site

Пропускная способность на все пути доступа в VPN, односящиеся к сайту.

bw-per-service

Пропускная способность на службу L2VPN.
                             +--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

Служит для задания набора правил QoS, применяемых к данному доступу в VPN (Рисунок 20). Классификация QoS может основываться на таких критериях, как MAC-адреса отправителя и получателя и т. п. В параграфе 5.10.2.1 [RFC8466] рассмотрена классификация 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

Список связанных с MAC правил, таких как MAC ACL. Подобно [RFC8519], сопоставление ACL может быть основано на MAC-адресах отправителя и получателя, маске MAC или их комбинации. Кадр данных, соответствующий ACL может быть отброшен, разослан лавинно или вызвать сигнал. Можно задать правила для частоты при обработке кадров, соответствующих ACL с действием flood (лавинная рассылка).
При наличии узлов mac-loop-prevention или mac-addr-limit они будут иметь предпочтение перед узлами из global-parameters-profile на уровне службы или узла VPN.
                            +--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

Этот контейнер включает набор деликатных сведений, влияющих на предоставление услуг L3VPN. Атакующий с доступом к таким узлам сможет, например, менять правила маршрутизации и QoS, а также параметры шифрования. Эти данные определены с тегами nacm:default-deny-write [RFC9181].

ethernet-segments и vpn-services

Атакующий с возможностью доступа к таким узлам может предпринять различные атаки, такие как удаление запущенных служб L2VPN или полное прерывание трафика клиента. Кроме того, злоумышленник может поменять атрибуты работающей службы (например, QoS, пропускную способность) или ES, что приведёт к некорректной работе службы и нарушению SLA. Атакующий также может попытаться создать службу L2VPN, добавить доступ в сеть и перехватить или перенаправить трафик на неуполномоченный узел. Помимо использования NACM для предотвращения несанкционированного доступа, такие действия можно обнаружить за счёт адекватного мониторинга и отслеживания изменений в конфигурации сети.

Некоторые из доступных для чтения узлов данных в модуле 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",