RFC 9938 A Framework for the Deterministic Networking (DetNet) Controller Plane

Internet Engineering Task Force (IETF)                          A. Malis
Request for Comments: 9938                                   Independent
Category: Informational                                     X. Geng, Ed.
ISSN: 2070-1721                                           M. (Guoyi)Chen
                                                                  Huawei
                                                                B. Varga
                                                                Ericsson
                                                           CJ. Bernardos
                                                                    UC3M
                                                              March 2026

A Framework for the Deterministic Networking (DetNet) Controller Plane

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

PDF

Аннотация

В этом документе приведён обзор модели плоскости контроллера детерминированной сети (Deterministic Networking или DetNet). Рассмотрены концепции и требования к плоскости контроллера DetNet, которые могут стать основой для будущей спецификации.

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

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

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

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

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

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

Детерминированная сеть (Deterministic Networking или DetNet) обеспечивает возможность передачи конкретных индивидуальных и групповых потоков данных с экстремально низкими потерями и гарантией сквозной задержки не более заданного значения. Описание основ и концепций DetNet приведено в [RFC8655].

Плоскость данных DetNet определена в документе «DetNet data plane framework» [RFC8938] и дополнительно разъяснена в DetNet MPLS [RFC8964], DetNet IP [RFC8939] и [RFC9023] [RFC9024] [RFC9025] [RFC9037] [RFC9056].

Следует отметить, что в базовой архитектуре DetNet плоскость контроллера включает компоненты, обычно рассматриваемые как отдельные плоскости управления и обслуживания (см. параграф 4.4.2 в [RFC8655]). Плоскость обслуживания (management) связана в основном с обработкой отказов, настройкой конфигурации и управлением производительностью (иногда сюда включают учёт и безопасность, см. параграф 4.2 в [RFC6632], но это выходит за рамки данного документа). Плоскость управления отвечает в основном за организацию и поддержку потоков, выделение и распространение меток MPLS, а также активную сигнализацию по основному (in-band) или отдельному (out-of-band) каналу для поддержки функций DetNet. В архитектуре DetNet все эти функции объединяются в одну плоскость контроллера. Более подробное рассмотрение агрегирования плоскостей управления и администрирования приведено в [RFC8655] и параграфе 4.4.2 [RFC7426].

Хотя документы по архитектуре и плоскости данных DetNet сосредоточены в основном на операциях плоскости данных, они включают некоторые требования и соображения в части функций, требуемых для автоматизации предоставления и мониторинга службы DetNet через плоскость контроллера DetNet (например, раздел 4 в [RFC8938]). Цель данного документа состоит в объединении таких требований и соображений в цельный документ с обсуждением использования различных архитектур DetNet Controller Plane для исполнения этих требований без детализации протокола плоскости контроллера DetNet. Протокольные решения для плоскости контроллера будут рассмотрены в последующих документах, а данный документ можно считать справочником, который следует принимать во внимание при разработке протоколов DetNet Controller Plane.

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

В других документах DetNet, включая [RFC8655], [RFC8938], [RFC9551] и [RFC9055], среди прочих вопросов рассматриваются требования к плоскости контроллера, которые для удобства собраны здесь. Требования организованы в три группы: 1) применимые в основном к плоскости управления, 2) применимые в основном к плоскости администрирования и 3) применимые к обеим плоскостям. Требования безопасности для плоскости контроллера DetNet рассмотрены в [RFC9055] и сводка этих требований приведена в параграфе 2.3. Там, где это применимо, в текст включены ссылки на документ, в котором требование было внесено.

2.1. Требования к плоскости управления DetNet

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

• Поддержка динамической организации, изменения и удаления потоков DetNet. Это может включать частично или полностью явное задание пути, резервирование пропускной способности, привязку потоков к конкретным каналам (например, каналам IEEE 802.1 TSN³), резервирование буферов и других ресурсов на узлах, задание требуемой дисциплины очередей, способность поддерживать двухсторонние потоки и другие свойства, нужные для потоков [RFC8938].

• Поддержка агрегирования и деагрегирования потоков DetNet путём динамического создания и удаления агрегатов (flow aggregate или FA), а также изменения имеющихся FA путём добавления или исключения участвующих в них потоков [RFC8938].

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

• Поддержка выделения и распространения [RFC8938] для плоскости данных DetNet MPLS меток S-Label, F-Label, A-Label [RFC8964]

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

• Поддержка дисциплин управления очередями, заданных в параграфе 4.5 [RFC8655] и [RFC9320], которые требуют синхронизации часов на узлах плоскости данных.

• Анонсирование статических и динамических характеристик узлов и каналов связи, таких как возможности и смежность, другим узлам сети (динамическая сигнализация) или контроллерам (централизованная модель) [RFC8938].

• Масштабирование для поддержки ожидаемого числа потоков DetNet в домене, для чего может потребоваться сигнализация и обеспечение на уровне потока [RFC8938].

• Предоставление сведений для идентификации потоков на каждом узле пути. Идентификация может зависеть от местоположения в сети и функциональности DetNet (например, на транзитных узлах и ретрансляторах) [RFC8938].

2.2. Требования к плоскости обслуживания DetNet

Основные требования к плоскости обслуживания DetNet приведены ниже.

• Мониторинг производительности потоков и узлов DetNet для обеспечения соответствия требуемым целям как в проактивном режиме, так и по запросам [RFC9551].

• Поддержка функций контроля непрерывности потоков DetNet и верификации связности [RFC9551].

• Поддержка тестирования и мониторинга функций PREOF в домене DetNet [RFC9551].

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

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

• Работа в домене сети, включающем потоки DetNet и иные потоки [RFC8655].

• Адаптация к изменениям топологии домена DetNet, таким как отказы, добавление и исключение каналов или узлов [RFC8655].

В дополнение к этому плоскости контроллера DetNet следует также выполнять вытекающие из [RFC9055] требования безопасности, которые задают модель безопасности для DetNet. Особенно важны указанные ниже требования.

Целостность и подлинность управляющих и сигнальных пакетов.

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

Защита от компрометации контроллера.

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

Безопасность системы в целом

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

Своевременная доставка сообщений плоскости управления

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

3. Архитектура плоскости управления DetNet

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

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

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

3.1. Распределенная плоскость управления и протоколы сигнализации

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

Рассмотрим в качестве примера сеть MPLS RSVP-TE [RFC3209], где конечные системы не входят в домен DetNet.

1. Узлы сети собирают данные топологии и сведения о возможностях DetNet на узлах сети по протоколу IGP⁸.

2. Входной граничный узел получает запрос на создание потока от UNI и рассчитывает один или несколько путей.

3. Входной узел передаёт сообщение PATH с явным маршрутом через RSVP-TE. После получения сообщения PATH выходной граничный узел отправляет сообщение RESV с распределяемой меткой и запросом на резервирование ресурсов.

В этом примере для протоколов IGP и RSVP-TE могут потребоваться расширения для DetNet.

3.2. Централизованная плоскость управления

В полностью централизованной модели конфигурации (например, с контроллером SDN) информация о потоке и UNI может передаваться от центрального контроллера или от других приложений через API или северный интерфейс центральному контроллеру. Настройку узлов сети для потоков DetNet выполняет контроллер с использованием такого протокола, как NETCONF [RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], или основанного на PCE центрального контроллера (PCE-based central controller или PCE-CC) [RFC8283].

Пример такой конфигурации приведён ниже.

1. Контроллер собирает данные о топологии и возможностях DetNet на узлах сети по протоколу NETCONF/YANG.

2. Контроллер получает запрос на организацию потока от UNI и находит один или несколько путей через сеть.

3. Контроллер выбирает оптимальный путь и настраивает устройства на нем для передачи потока DetNet через PCE-CC.

В этом примере для указанных выше протоколов могут потребоваться расширения для DetNet.

3.3. Гибридная плоскость управления

В гибридной модели протоколы плоскости управления и контроллер совместно обеспечивают работу служб DetNet. Здесь возможно много разных комбинаций. Ниже приведён пример совместного применения RSVP-TE и контроллера.

1. Контроллер собирает данные о топологии и возможностях узлов DetNet по протоколу IGP и/или BGP-LS (Border Gateway Protocol — Link State) [RFC9552].

2. Контроллер получает запрос на организацию потока через API и находит один или несколько путей через сеть.

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

4. Граничный входной узел с помощью RSVP-TE передаёт сообщение PATH с явным маршрутом. После получения PATH выходной граничный узел отправляет сообщение RESV с распространяемой меткой и запросом резервирования ресурсов.

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

4. Плоскость управления DetNet для механизмов DetNet

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

4.1. Явные пути

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

Path computation — расчёт пути

Явные пути DetNet нужны для исполнения требований соглашения об обслуживании (Service Level Agreement или SLA) приложения, которые включают пропускную способность, максимальную сквозную задержку и её максимальные вариации, максимальный уровень потерь и т. п. В распределенной системе можно использовать IGP с алгоритмом CSPF⁹ для поиска кратчайшего пути с учётом ограничений. В централизованной системе контроллер может рассчитывать пути в соответствии с требованиями DetNet на основе данных, собранных в домене DetNet.

Path establishment — организация пути

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

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

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

Resource Allocation — выделение ресурсов

Пропускная способность порта — один из базовых атрибутов сетевого устройства, который легко получить или рассчитать. В современных реализациях управления трафиком выделение ресурсов является синонимом выделения пропускной способности. Поток DetNet характеризуется спецификацией трафика, как указано в [RFC9016], включая такие атрибуты, как Interval, MaxPacketsPerInterval, MaxPayloadSize. Спецификация трафика описывает наихудшие, а не средние условия, чтобы обеспечить резервирование достаточной пропускной способности и буферной ёмкости для трафика. Однако в случае DetNet выделение ресурсов — это не только резервирование пропускной способности. Например, может потребоваться также выделение буферов и задание дисциплины очередей при пересылке. Кроме того, требуется обеспечить на узле ресурсы для выполнения функций сервисного подуровня DetNet, таких как защита и переупорядочивание с использованием PREOF.

Конфигурация устройства с дискриминацией потоков и без неё

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

4.3. Поддержка PREOF

Резервирование (избыточность) путей DetNet поддерживается с помощью функций PREOF. Поток DetNet реплицируется и передаётся по нескольким путям, чтобы избежать потери пакетов в результате отказа узлов или каналов. В общем случае имеющиеся механизмы плоскости управления, которые могут служить для (распределенной или централизованной) организации явного пути, поддерживают пути «точка-точка» (point-to-point или P2P) и многоточечные (point-to-multipoint или P2MP). PREOF требует возможности расчёта и организации набора путей (например, множества сегментов LSP¹⁰ в сети MPLS) из точек репликации пакетов в точки слияния и упорядочения. Требуется также сопоставление потоков DetNet или их номеров с сегментами явного пути. Для поддержки таких функций потребуются расширения протокола. Нужна также терминология для обозначения скоординированного набора сегментов пути (например, граф LSP для плоскости данных DetNet MPLS).

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

4.4.1. DetNet в домене MPLS

В этом документе термин «традиционная (legacy) MPLS» означает MPLS без применения маршрутизации по сегментам (Segment Routing, см. параграф 4.4.3) или транспортного профиля MPLS (Transport Profile или MPLS-TP) [RFC5960].

В традиционном домене MPLS для распространения меток, по которым пересылаются пакеты MPLS, обычно используется распределенный сигнальный протокол плоскости управления. Наиболее часто применяемыми протоколами динамической сигнализации для распространения меток являются LDP [RFC5036], RSVP-TE [RFC4875] и BGP [RFC8277] (поддержка основанных на BGP MPLS VPN L3 [RFC4384], L2 [RFC4664] и EVPN [RFC7432]). Любые из этих протоколов можно применять для распространения меток службы DetNet (Service Label или S-Label) и меток агрегирования (Aggregation Label или A-Labels) [RFC8964]. Как указано в [RFC8938], S-Label похожи на другие метки служб MPLS, таких как псевдопровода, L3 VPN и L2 VPN, и могут распространяться похожим способом, например, с помощью целевого LDP или BGP. При использовании в DetNet нужны расширения для поддержки специфичных для DetNet функций, таких как PREOF, A-Label, выделение ресурсов на узле, размещение в очереди.

4.4.2. DetNet в домене IP

В этом документе термин «традиционный (legacy) IP» означает IP без применения маршрутизации по сегментам (Segment Routing, см. параграф 4.4.3). Следует отметить, что плоскость данных DetNet IP [RFC8939] проще, чем DetNet MPLS [RFC8964], и не поддерживает PREOF, поэтому требуется лишь один путь для потока или агрегата потоков. Предполагается, что возможные расширения протоколов будут ограничиваться, например, имеющимися протоколами маршрутизации IP.

4.4.3. DetNet в домене Segment Routing

Маршрутизация по сегментам [RFC8402] предлагает расширяемый подход к построению сетевых доменов, обеспечивающий явную маршрутизацию с помощью заданных отправителем маршрутов, кодируемых в заголовках пакетов, и сочетающийся с централизованным управлением для расчёта путей через сеть. Пути пересылки распространяются вместе со связанными с ними правилами по граничным узлам сети для использования в заголовках пакетов. Маршрутизация по сегментам сокращает объем сигнальной информации, связанной с распределенными протоколами сигнализации (например, RSVP-TE), а также снижает число состояний в узлах ядра по сравнению с требуемыми для традиционной маршрутизации MPLS и IP, поскольку состояния содержатся в пакетах, а не в маршрутизаторах. Это может оказаться полезным для DetNet с большим числом потоков через сеть, где в ином случае пришлось бы держать экземпляр состояния для каждого потока на каждом узле сети.

Отметим, что плоскости данных DetNet MPLS и IP, описанные в [RFC8964] и [RFC8939], разрабатывались для совместимости с обоими типами маршрутизации по сегментам: SR-MPLS (Segment Routing over MPLS) [RFC8660] и SRv6 (Segment Routing over IPv6) [RFC8754] [RFC8986].

4.5. Поддержка метаданных и инкапсуляции

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

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

5. Обзор плоскости обслуживания

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

5.1. DetNet OAM

В этом документе рассматриваются общие вопросы, связанные с OAM.

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

5.1.1.1. Активный мониторинг

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

5.1.1.2. Пассивный мониторинг

При пассивном мониторинге (например, In Situ Operations, Administration, and Maintenance (IOAM) [RFC9197]), отслеживается фактический трафик службы в рамках домена для измерения производительности без негативного влияния на сеть. Пассивный мониторинг является предпочтительным для доменов DetNet.

5.1.2. OAM для поддержки связности и контроля отказов

Детальные требования к CFM¹² в доменах DetNet IP и DetNet MPLS приведены в [RFC9551], [RFC9634] и [RFC9546].

6. Работа в нескольких доменах

При участии нескольких доменов разные функции плоскости контроллера (Controller Plane Function или CPF) будут взаимодействовать для исполнения запросов, полученных от элементов управления потоками (Flow Management Entity или FME) [RFC8655], на уровне потока, на уровне этапа пересылки (hop) в узлах DetNet для каждого отдельного потока. Добавление поддержки множества доменов может потребовать некоторой поддержки на уровне CPF. Например, CPF разных доменов (скажем, PCE) должны будут обнаруживать друг друга, а затем аутентифицироваться и согласовывать поведение на уровне этапа пересылки. Кроме того, в беспроводных доменах требуется также учитывать функции на уровне домена, обеспечивающие надёжность и доступность беспроводной связи (Reliable and Available Wireless или RAW) [RAW-ARCH], такие как точки локального восстановления (Point of Local Repair или PLR), в дополнение к PCE. В зависимости от поддержки множества доменов плоскостью приложений плоскость контроллера может быть освобождена от некоторых обязанностей (например, плоскость приложений может взять на себя распределение обязанностей между доменами).

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

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

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

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

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

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

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

[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane Framework», RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/info/rfc8938>.

[RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, «Flow and Service Information Model for Deterministic Networking (DetNet)», RFC 9016, DOI 10.17487/RFC9016, March 2021, <https://www.rfc-editor.org/info/rfc9016>.

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

[RFC9551] Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos, CJ., Varga, B., and J. Farkas, «Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)», RFC 9551, DOI 10.17487/RFC9551, March 2024, <https://www.rfc-editor.org/info/rfc9551>.

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

[RAW-ARCH] Thubert, P., Ed., «Reliable and Available Wireless Architecture», Work in Progress, Internet-Draft, draft-ietf-raw-architecture-30, 25 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-30>.

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

[RFC4384] Meyer, D., «BGP Communities for Data Collection», BCP 114, RFC 4384, DOI 10.17487/RFC4384, February 2006, <https://www.rfc-editor.org/info/rfc4384>.

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

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., «Extensions to Resource Reservation Protocol — Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)», RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., «LDP Specification», RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.

[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., «MPLS Transport Profile Data Plane Architecture», RFC 5960, DOI 10.17487/RFC5960, August 2010, <https://www.rfc-editor.org/info/rfc5960>.

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

[RFC6632] Ersue, M., Ed. and B. Claise, «An Overview of the IETF Network Management Standards», RFC 6632, DOI 10.17487/RFC6632, June 2012, <https://www.rfc-editor.org/info/rfc6632>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, «Software-Defined Networking (SDN): Layers and Architecture Terminology», RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

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

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

[RFC8277] Rosen, E., «Using BGP to Bind MPLS Labels to Address Prefixes», RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.

[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, «An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control», RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>.

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

[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, «Segment Routing with the MPLS Data Plane», RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, «IPv6 Segment Routing Header (SRH)», RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

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

[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, «Deterministic Networking (DetNet) Data Plane: MPLS», RFC 8964, DOI 10.17487/RFC8964, January 2021, <https://www.rfc-editor.org/info/rfc8964>.

[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, «Segment Routing over IPv6 (SRv6) Network Programming», RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)», RFC 9023, DOI 10.17487/RFC9023, June 2021, <https://www.rfc-editor.org/info/rfc9023>.

[RFC9024] Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. Fedyk, «Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS», RFC 9024, DOI 10.17487/RFC9024, June 2021, <https://www.rfc-editor.org/info/rfc9024>.

[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP», RFC 9025, DOI 10.17487/RFC9025, April 2021, <https://www.rfc-editor.org/info/rfc9025>.

[RFC9037] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)», RFC 9037, DOI 10.17487/RFC9037, June 2021, <https://www.rfc-editor.org/info/rfc9037>.

[RFC9056] Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, «Deterministic Networking (DetNet) Data Plane: IP over MPLS», RFC 9056, DOI 10.17487/RFC9056, October 2021, <https://www.rfc-editor.org/info/rfc9056>.

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

[RFC9320] Finn, N., Le Boudec, J.-Y., Mohammadpour, E., Zhang, J., and B. Varga, «Deterministic Networking (DetNet) Bounded Latency», RFC 9320, DOI 10.17487/RFC9320, November 2022, <https://www.rfc-editor.org/info/rfc9320>.

[RFC9546] Mirsky, G., Chen, M., and B. Varga, «Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane», RFC 9546, DOI 10.17487/RFC9546, February 2024, <https://www.rfc-editor.org/info/rfc9546>.

[RFC9552] Talaulikar, K., Ed., «Distribution of Link-State and Traffic Engineering Information Using BGP», RFC 9552, DOI 10.17487/RFC9552, December 2023, <https://www.rfc-editor.org/info/rfc9552>.

[RFC9633] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, «Deterministic Networking (DetNet) YANG Data Model», RFC 9633, DOI 10.17487/RFC9633, October 2024, <https://www.rfc-editor.org/info/rfc9633>.

[RFC9634] Mirsky, G., Chen, M., and D. Black, «Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane», RFC 9634, DOI 10.17487/RFC9634, October 2024, <https://www.rfc-editor.org/info/rfc9634>.

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

Спасибо Jim Guichard, Donald Eastlake 3rd, Stewart Bryant за рецензии и комментарии.

Авторы признательны также Deb Cooley, Mike Bishop, Mohamed Boucadair, Gorry Fairhurst и Dave Thaler за комментарии в процессе рецензирования IESG.

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

Fengwei Qin

China Mobile

Email: qinfengwei@chinamobile.com

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

Andrew G. Malis

Independent

Email: agmalis@gmail.com

Xuesong Geng (editor)

Huawei

Email: gengxuesong@huawei.com

Mach (Guoyi)Chen

Huawei

Email: mach.chen@huawei.com

Balazs Varga

Ericsson

Email: balazs.a.varga@ericsson.com

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/

---

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

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

nmalykh@protokols.ru

---