RFC 9551 Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)

Internet Engineering Task Force (IETF)                         G. Mirsky
Request for Comments: 9551                                      Ericsson
Category: Informational                                     F. Theoleyre
ISSN: 2070-1721                                                     CNRS
                                                         G. Papadopoulos
                                                          IMT Atlantique
                                                           CJ. Bernardos
                                                                    UC3M
                                                                B. Varga
                                                               J. Farkas
                                                                Ericsson
                                                              March 2024

Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)

Модель OAM для детерминированных сетей

PDF

Аннотация

Детерминированные сети (Deterministic Networking или DetNet), как указано в RFC 8655, нацелены на обеспечение ограничения сквозной задержки в сетевой инфраструктуре, включающей сегменты на основе мостов (L2) и маршрутизаторов (L3). Основной целью этого документа является описание конкретных требований к эксплуатации, администрированию и обслуживанию (Operations, Administration, and Maintenance или OAM), рекомендуемых для поддержки детерминированной сети. Документ будет использоваться в будущих работах по определению приложений и расширению протоколов OAM для детерминированных сетей. Внедрение модели OAM в DetNet позволит операторам в режиме реального времени отслеживать состояние сетевой инфраструктуры и её способность обеспечивать показатели уровня обслуживания (Service Level Objective или SLO), такие как задержки пакетов и их вариации, доля теряемых пакетов для каждого потока DetNet.

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

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

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

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

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

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

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

1. Введение

В документе по детерминированным сетям (DetNet) [RFC8655] предложено обеспечивать ограниченную сквозную задержку при работе в сетевой инфраструктуре с сегментами на основе мостов (L2) и маршрутизаторов (L3). Данная работа охватывает плоскость данных, OAM, синхронизацию часов, управление и безопасность.

Инструменты OAM очень важны для сетей IP [RFC7276]. В DetNet OAM следует обеспечивать инструментарий для обнаружения и локализации отказов, а также для управления производительностью.

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

Термин OAM в этом документе применяется в соответствии с определением [RFC6291]. В DetNet предполагается внедрение OAM для представления в реальном масштабе времени сетевой инфраструктуры и параметров SLO, например, упорядоченной доставки, задержки и её вариаций, уровня потери пакетов для каждого потока DetNet.

В этом документе рассматриваются функциональные требования к OAM для домена DetNet. Набор требований можно использовать для анализа пробелов в наборе доступных инструментов OAM с целями:

• поиска замены имеющимся инструментам;

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

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

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

DetNet OAM domain — домен DetNet OAM

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

DetNet OAM instance — экземпляр DetNet OAM

Функция мониторинга потока DetNet, обнаруживающая и/или измеряющая показатели производительности. В документе применяется также сокращённый вариант «экземпляр OAM».

Maintenance End Point (MEP) — конечная точка обслуживания

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

Maintenance Intermediate Point (MIP) — промежуточная точка обслуживания

Экземпляр OAM на пути потока DetNet в конкретном подуровне домена DetNet OAM. Активная точка MIP должна отвечать на сообщения OAM, генерируемые MEP на том же подуровне данного домена DetNet OAM.

Control and management plane — плоскость управления и обслуживания

Плоскости управления и (технического) обслуживания применяются для настройки сети и управления ею. Применительно к потоку DetNet плоскости управления и обслуживания могут быть реализованы по отдельному каналу (out of band).

Active measurement methods — активные методы измерений

Методы, изменяющие поток DetNet путём внедрения тестовых пакетов [RFC2544] (определение из [RFC7799]).

Passive measurement methods — пассивные методы измерений

Методы измерения, извлекающие информацию без изменения существующих потоков (определение из [RFC7799]).

Hybrid measurement methods — гибридные методы измерений

Комбинация активных и пассивных методов измерения (определение из [RFC7799]).

In-band OAM — внутрисетевое OAM

Активный метод реализации OAM по основному каналу (in band) в рамках отслеживаемого домена DetNet OAM на том же наборе каналов и интерфейсов, с теми же параметрами QoS и PREOF³, что и у отслеживаемого потока.

Out-of-band OAM — OAM по отдельным каналам

Активный метод OAM, где путь через домен DetNet может топологически отличаться от пути отслеживаемого потока DetNet, а параметры QoS и/или PREOF для тестовых пакетов могут различаться.

On-path telemetry — телеметрия на пути

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

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

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

2. Роль OAM в DetNet

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

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

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

Для OAM в DetNet имеется несколько специфических задач. Присущие сети характеристики (например, задержки и потери) неотделимы от параметров обслуживания, поэтому OAM для мониторинга производительности (Performance Monitoring или PM) является очень важным аспектом DetNet. Инструменты OAM требуются для мониторинга каждого SLO без воздействия на характеристики потока DetNet. Ещё одной задачей является строгое распределение ресурсов. Используемые в OAM ресурсы должны выделяться и учитываться так, чтобы не нарушать потоки DetNet.

Рабочая группа DetNet определила два подуровня:

сервис DetNet, где предоставляются услуги DetNet (например, защита службы);

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

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

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

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

3. Эксплуатация

Функции OAM обеспечат отказоустойчивую работу DetNet при пересылке и маршрутизации.

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

3.1. Сбор информации

Сведения о состоянии сети можно собрать с помощью разных механизмов. Некоторые протоколы, такие как SNMP⁵, запрашивают обновлённые данные. Другие протоколы, например, YANG-Push [RFC8641], позволяют организовать подписку на данные, определённые моделями YANG, которые публикуются периодически или при изменении лежащих в их основе данных. В любом случае сведения собираются и передаются через плоскость контроллера DetNet.

Можно также охарактеризовать методы доставки сведений OAM путями их передачи. Например, данные OAM могут передаваться в одном канале (in band) с потоком DetNet или по отдельному пути. При передаче по тому же пути для данных телеметрии расходуются ресурсы, выделенные потоку DetNet, и в этом случае требуется тщательный анализ объёма генерируемых данных и дополнительного расхода ресурсов. В [RFC9197] определён механизм транспортировки по основному каналу, где данные телеметрии помещаются в пакеты данных, для которых собираются сведения телеметрии. Описано два способа трассировки:

• сквозная (end-to-end) от входного узла до выходного;

• поэтапная (hop-by-hop), включающая дополнительные сведения от транзитных узлов.

Примеры доставки данных телеметрии по отдельному каналу приведены в [RFC9326] и [HYBRID-TWO-STEP]. В первом случае данные телеметрии передаются каждым узлом, через который проходят пакеты данных отслеживаемого потока DetNet, в специально созданных пакетах. Во втором случае данные собираются в последовательность пакетов, проходящих по одному пути с пакетами данных потока DetNet. В обоих случаях можно избежать при передаче данных телеметрии расхода ресурсов, выделенных для домена DetNet.

3.2. Проверка непрерывности

Мониторинг непрерывности служит для проверки непрерывности пути, т. е. наличия пути доставки пакетов между MEP A и MEP B. Эта проверка обнаруживает сетевые отказы в одном направлении — от MEP, передающего тестовые пакеты, до удалённого выходного MEP. Проверка непрерывности в домене DetNet OAM контролирует подуровень пересылки DetNet, поэтому на неё не влияют функции PREOF, работающие на уровне службы DetNet ([RFC8655]).

3.3. Проверка связности

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

3.4. Трассировка маршрутов

Ping и traceroute — это повсеместно применяемые инструменты, помогающие обнаруживать и характеризовать сетевые отказы с использованием эхо-запросов и откликов, а также обнаруживать маршрутизаторы на пути. Однако для предсказуемой работы DetNet ресурсы резервируются на уровне каждого потока, поэтому в DetNet нужны инструменты трассировки пути конкретных потоков. Кроме того, трассировка может применяться для определения максимального размера передаваемого через сеть блока (Path Maximum Transmission Unit или PMTU) и обнаружения элементов PREOF для конкретного маршрута в домене DetNet.

В DetNet не предполагается использование множества равноценных путей (Equal-Cost Multipath или ECMP) [RFC8939], поэтому рассмотрение DetNet OAM в среде ECMP выходит за рамки этого документа.

3.5. Обнаружение и проверка отказов

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

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

3.6. Локализация и характеристики отказов

Способность локализовать сетевые дефекты и представлять их характеристики необходима для работы сети.

Локализация отказов

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

Характеристики отказа

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

3.7. Использование гибридного OAM в DetNet

Гибридные методы OAM, используемые для мониторинга производительности определены в [RFC7799] как:

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

Гибридные методы могут давать показатели, максимально близкие к результатам пассивных измерений, а пассивные методы дают результаты, наиболее близкие к фактическим условиям в сети. Даже когда гибридный метод меняет что-либо в пакете, например, значение определённого поля в инкапсуляции, результат остаётся близким к показателям пассивного метода. Одним из примеров гибридных измерений является метод чередующейся маркировки (Alternate-Marking Method или AMM), описанный в [RFC9341]. Как и все методы телеметрии пути, AMM в домене DetNet с плоскостью данных IP работает в одном канале с отслеживаемым потоком DetNet. Поскольку маркировка применяется к потоку данных, измеренные значения напрямую относятся к потоку DetNet. AMM минимизирует дополнительную нагрузку на домен DetNet, используя сбор данных на узлах и вычисление параметров производительности в сочетании (необязательно) с телеметрией по отдельному каналу для дополнительного анализа.

4. Администрирование

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

Queuing Delay — задержка в очередях

Время между помещением пакета в очередь и передачей его на слудующий узел (hop).

Buffer occupancy — занятость буферов

Число пакетов в буфере для каждого из имеющихся потоков.

По потокам

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

По путям

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

По устройствам

Обнаружение некорректной работы устройства.

4.1. Набор показателей

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

4.2. Показатели для худшего случая

DetNet стремиться обеспечить взаимодействие в реальном масштабе времени на основе гетерогенной многоузловой архитектуры. Для принятия корректных решений плоскости контроллера DetNet [RFC8655] нужны своевременные сведения о потерях и задержках пакетов по каждому потоку и на каждом интервале (hop) пути. Иными словами, усреднённой сквозной статистики недостаточно. Собранных сведений должно быть достаточно для того, чтобы система могла предсказать наихудший сценарий.

5. Обслуживание

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

цены неоптимальной работы

неоптимальное использование ресурсов (например, наличие лучшего пути);

стоимости реконфигурации

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

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

5.1. Репликация и исключение

При резервировании между парой MEP более одного пути для избыточности и сокращения ошибок передачи и коллизий может применяться репликация пакетов. Например, на рисунке 1 источник S передаёт пакеты устройствам A и B для доставки целевому узлу R.

            ===> (A) => (C) => (E) ===
          //        \\//   \\//       \\
source (S)          //\\   //\\         (R) (root)
          \\       //  \\ //  \\      //
            ===> (B) => (D) => (F) ===

Рисунок 1. Функции репликации и исключения пакетов.

5.2. Резервирование ресурсов

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

6. Требования

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

1. Должна быть возможна организация сессии DetNet OAM из MEP на узле DetNet в сторону MEP или с нисходящими MEP с узла DetNet в данном домене на конкретном подуровне DetNet.

2. Должна быть возможна организация сессии DetNet OAM с использованием любых решений в плоскости контроллера DetNet (например, централизованный контроллер).

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

4. Должны поддерживаться методы OAM для мониторинга и измерений по запросу.

5. Должны поддерживаться односторонние методы OAM — проверка непрерывности и связности, а также измерение производительности.

6. Должны поддерживаться двухсторонние потоки DetNet, но для них не требуется поддержка двухстороних методов OAM. Тестовые пакеты DetNet OAM для мониторинга и измерения производительности в двухсторонних потоках DetNet должны передаваться по основному каналу в обоих направлениях .

7. Должен поддерживаться проактивный мониторинг доступности устройств DetNet для данного потока DetNet.

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

9. Расчетные показатели производительности должны включать пропускную способность, потери пакетов, задержки и их вариации, а также могут включать другие показатели (см. [RFC6374]).

6.1. Подуровень пересылки DetNet

В DetNet OAM должны поддерживаться:

1. определение PMTU;

2. уведомления об удалённых отказах (Remote Defect Indication или RDI) экземпляров DetNet OAM, проверяющих непрерывность;

3. мониторинг уровней ресурсов, выделенных для конкретного потока DetNet (загрузка буферов, планирование передачи и т. п.);

4. мониторинг любого подмножества путей, которые поток DetNet проходит в домене DetNet.

6.2. Подуровень сервиса DetNet

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

В части DetNet OAM для ретрансляторов DetNet должны поддерживаться:

1. функции OAM для подуровня сервиса DetNet;

2. обнаружение ретрансляторов DetNet в сети DetNet;

3. обнаружение местоположения PREOF в домене;

4. сбор сведений, относящихся к подуровню службы DetNet (конфигурация, операции, статус), от ретрансляторов;

5. реализация функций PREOF в домене;

6. работа с плоскостью данных DetNet (MPLS и IP);

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

8. измерение показателей (например, задержки) в рамках набора сессий OAM, особенно для комплексных потоков DetNet, с помощью функций PREOF.

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

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

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

В документе приведены требования к OAM в домене DetNet и не рассматриваются какие-либо вопросы и проблемы, помимо базовых вопросов для сетей и тех проблем, связанных с DetNet, которые обсуждаются в разделе 9 [RFC9055]. Анализ вопросов безопасности OAM в разделе 6 [RFC7276] применим и к DetNet OAM, включая использование OAM для сетевой разведки.

9. Вопросы приватности

Вопросы приватности DetNet, рассмотренные в разделе 13 [RFC9055], применимы и для DetNet OAM. Если для отслеживаемых потоков DetNet применяются механизмы обеспечения приватности, тот же метод защиты приватности должен применяться в активном DetNet OAM для мониторинга потока.

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

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

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

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

[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, «Deterministic Networking Architecture», RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

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

[HYBRID-TWO-STEP] Mirsky, G., Lingqiang, W., Zhui, G., Song, H., and P. Thubert, «Hybrid Two-Step Performance Measurement Method», Work in Progress, Internet-Draft, draft-ietf-ippm-hybrid-two-step-00, 4 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-hybrid-two-step-00>.

[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.

[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, «Guidelines for the Use of the «OAM» Acronym in the IETF», BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.

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

[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, «An Overview of Operations, Administration, and Maintenance (OAM) Tools», RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.

[RFC7799] Morton, A., «Active and Passive Metrics and Methods (with Hybrid Types In-Between)», RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

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

[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: IP», RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.

[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, «Deterministic Networking (DetNet) Security Considerations», RFC 9055, DOI 10.17487/RFC9055, June 2021, <https://www.rfc-editor.org/info/rfc9055>.

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

[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, «In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting», RFC 9326, DOI 10.17487/RFC9326, November 2022, <https://www.rfc-editor.org/info/rfc9326>.

[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, «Alternate-Marking Method», RFC 9341, DOI 10.17487/RFC9341, December 2022, <https://www.rfc-editor.org/info/rfc9341>.

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

Авторы выражают свою признательность Pascal Thubert за обзор, значимые вопросы и полезные комментарии.

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

Greg Mirsky

Ericsson

Email: gregimirsky@gmail.com

Fabrice Theoleyre

CNRS

ICube Lab, Pole API

300 boulevard Sebastien Brant — CS 10413

67400 Illkirch — Strasbourg

France

Phone: +33 368 85 45 33

Email: fabrice.theoleyre@cnrs.fr

URI: https://fabrice.theoleyre.cnrs.fr/

Georgios Papadopoulos

IMT Atlantique

Office B00 — 102A

2 Rue de la Châtaigneraie

35510 Cesson-Sévigné — Rennes

France

Phone: +33 299 12 70 04

Email: georgios.papadopoulos@imt-atlantique.fr

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

28911 Leganes, Madrid

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

Balazs Varga

Ericsson

Budapest

Magyar Tudosok krt. 11.

1117

Hungary

Email: balazs.a.varga@ericsson.com

Janos Farkas

Ericsson

Budapest

Magyar Tudosok krt. 11.

1117

Hungary

Email: janos.farkas@ericsson.com

---

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

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

nmalykh@protokols.ru

---