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

Internet Engineering Task Force (IETF)                        S. Barguil
Request for Comments: 9182                      O. Gonzalez de Dios, Ed.
Category: Standards Track                                     Telefonica
ISSN: 2070-1721                                        M. Boucadair, Ed.
                                                                  Orange
                                                                L. Munoz
                                                                Vodafone
                                                               A. Aguado
                                                                   Nokia
                                                           February 2022

A YANG Network Data Model for Layer 3 VPNs

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

PDF

Аннотация

В качестве дополнения к модели услуг виртуальных частных сетей L3 (Layer 3 Virtual Private Network Service Model или L3SM), применяемой для взаимодействия между клиентами и сервис-провайдерами, этот документ задаёт модель сети L3VPN (L3VPN Network Model или L3NM), которая может служить для предоставления услуг виртуальных частных сетей L3 (Layer 3 Virtual Private Network или L3VPN) внутри сети сервис-провайдера. Эта модель обеспечивает сетецентричное представление услуг L3VPN.

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

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

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

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

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

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

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

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

1. Введение

В [RFC8299] определена модель YANG L3SM, которая может применяться для взаимодействия между клиентами и поставщиками услуг. Модель сосредоточена на описании точки зрения клиента на услуги виртуальной частной сети (Virtual Private Network или VPN) и обеспечивает абстрактное представление запрашиваемых клиентом услуг. Такой подход ограничивает применение L3SM ролью модели обслуживания клиентов (согласно [RFC8309]).

Данный документ определяет модуль YANG названный моделью сети L3VPN (L3VPN Network Model или L3NM). Модель L3NM предназначена для сетецентричного представления услуг L3 VPN. Модель может применяться для упрощения взаимодействий между организатором (оркестратором) службы и сетевым контроллером/оркестратором, позволяя включать больше сетецентрических сведений. Модель обеспечивает дополнительные возможности, такие как управление ресурсами, или служит многодоменным интерфейсом оркестровки, где должны согласовываться логические ресурсы (такие как цели или различители маршрутов).

Этот документ использует базовый модуль YANG VPN, определённый в [RFC9181].

Этот документ не отменяет [RFC8299]. Оба модуля применяются для схожих целей, но с разными областями действия и представлениями. Модуль YANG L3NM был создан на основе подхода «упрощать и расширять» (prune and extend) к послужившему базой модулю YANG из [RFC8299]. Тем не менее, L3NM не задаёт дополнений к L3SM, поскольку требуется конкретная структура для удовлетворения потребностей L3.

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

В параграфе 5.1 [RFC8969] показано, как можно использовать L3NM в архитектуре автоматизации управления сетью.

L3NM не пытается охватить все варианты развёртывания, особенно те, где связность L3VPN поддерживается путём координации разных VPN в разных базовых сетях. Более сложные варианты внедрения включают координацию разных экземпляров VPN и различных технологий для обеспечения сквозной связности VPN, решаются с помощью дополнительных модулей YANG, например, [YANG-Composed-VPN].

Модель L3NM сосредоточена на L3 VPN, основанных на BGP PE, как описано в [RFC4026], [RFC4110] и [RFC4364], а также Multicast VPN, описанных в [RFC6037] и [RFC6513].

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

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

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

Этот документ предполагает знакомство читателя с [RFC6241], [RFC7950], [RFC8299], [RFC8309], [RFC8453] и использует определённые в этих документах термины. Документ использует термин «модель сети» (network model) в соответствии с параграфом 2.1 в [RFC8969]. На диаграммах деревьев применяется нотация [RFC8340].

Ниже приведены термины, определённые в этом документе.

Layer 3 VPN Service Model (L3SM) — модель услуг L3SM

Layer 3 VPN Network Model (L3NM) — модель сети L3NM

Service orchestrator — оркестратор (организатор) услуг

Network orchestrator — сетевой оркестратор (организатор)

Network controller — сетевой контроллер

VPN node — узел VPN

VPN network access — доступ в сеть VPN

VPN site — сайт VPN

VPN service provider — поставщик услуг VPN

Service provider network — сеть сервис-провайдера

Этот документ предназначен для моделирования BGP VPN на основе PE в сети сервис-провайдера, поэтому в нем применяются термины, определённые в [RFC4026] и [RFC4176].

3. Сокращения

ACL

AS

ASM

ASN

BFD

BGP

BSR

CE

CsC

IGMP

L3NM

L3SM

L3VPN

MLD

MSDP

MVPN

NAT

OAM

OSPF

PE

PIM

QoS

RD

RP

RT

SA

SSM

VPN

VRF

4. Эталонная архитектура L3NM

На рисунке 1 показана эталонная архитектура L3NM. Рисунок является расширением архитектуры, представленной в разделе 5 [RFC8299] и разбивает поле оркестровки (orchestration) на 3 части — организация службы, организация сети и организация домена.

Хотя в некоторых развёртываниях может быть выбрана монолитная оркестровка (охватывающая службу и сеть), этот документ выступает за чёткое разделение между компонентами организации службы и сети для большей гибкости. Такое устройство соответствует эталонной архитектуре L3VPN, определённой в параграфе 1.3 [RFC4176]. Разделение основано на выделенном коммуникационном интерфейсе между компонентами и соответствующими модулями YANG, которые отражают связанную с сетью информацию. Эти сведения скрыты от клиентов.

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

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

                        +---------------+
                        |    Клиент     |
                        +-------+-------+
  Модель обслуживания клиентов  |
       (например, l3vpn-svc)    |
                        +-------+-------+
                        |  Организация  |
                        |     службы    |
                        +-------+-------+
 Модель предоставления услуги   |
           l3vpn-ntw            |
                        +-------+-------+
                        |  Организация  |
                        |      сети     |
                        +-------+-------+
     Модель конфигурации сети   |
                    +-----------+-----------+
                    |                       |
           +--------+------+       +--------+------+
           |  Организация  |       |  Организация  |
           |     домена    |       |     домена    |
           +---+-----------+       +--------+------+
Модель         |        |                   |
конфигурации   |        |                   |
устройства     |        |                   |
          +----+----+   |                   |
          |Менеджер |   |                   |
          |конфигур.|   |                   |
          +----+----+   |                   |
               |        |                   |
               | NETCONF/CLI..................
               |        |                   |
     +------------------------------------------------+
                            Сеть

NETCONF - Протокол настройки сети
CLI - командный (консольный) интерфейс

Рисунок 1. Эталонная архитектура L3NM.

Клиент может применять разные средства для запроса услуги, которая может вызывать создание экземпляра L3NM. Клиент может пользоваться L3SM или более абстрактными моделями для запроса услуг, основанных на сервисе L3VPN. Например, клиент может представить профиль обеспечения связности IP (IP Connectivity Provisioning Profile или CPP) с характеристиками запрашиваемых услуг [RFC7297], расширенных услуг VPN (VPN+) [Enhanced-VPN-Framework] или услуг сетевого слоя IETF (network slice) [Network-Slices-Framework].

Отметим, что можно использовать L3SM и L3NM в контексте модели абстракции и управления сетями TE (Abstraction and Control of TE Networks или ACTN) [RFC8453]. На рисунке 2 показан клиентский контроллер сети (Customer Network Controller или CNC), многодоменный координатор услуг (Multi-Domain Service Coordinator или MDSC), обеспечиваюший сетевой контроллер (Provisioning Network Controller или PNC) и интерфейсы, где применяется L3SM и L3NM.

        +----------------------------------+
        | Клиент                           |
        | +-----------------------------+  |
        | |             CNC             |  |
        | +-----------------------------+  |
        +----+-----------------------+-----+
             |                       |
             | L3SM                  | L3SM
             |                       |
   +---------+---------+   +---------+---------+
   | MDSC              |   |       MDSC        |
   | +---------------+ |   |    (родитель)     |
   | |  Организация  | |   +---------+---------+
   | |    службы     | |             |
   | +-------+-------+ |             | L3NM
   |         |         |             |
   |         | L3NM    |   +---------+---------+
   |         |         |   |       MDSC        |
   | +-------+-------+ |   |     (потомок)     |
   | |  Организация  | |   +---------+---------+
   | |     сети      | |             |
   | +---------------+ |             |
   +---------+---------+             |
             |                       |
             | Конфигурация сети     |
             |                       |
+------------+-------+     +---------+------------+
| Контроллер         |     |           Контроллер |
| домена             |     |               домена |
|       +---------+  |     |    +---------+       |
|       |   PNC   |  |     |    |   PNC   |       |
|       +---------+  |     |    +---------+       |
+------------+-------+     +---------+------------+
             |                       |
             |Конфигурация устройства|
             |                       |
        +----+-----+            +----+-----+
        |Устройство|            |Устройство|
        +----------+            +----------+

Рисунок 2. L3SM и L3NM в контексте ACTN.

5. Связи с другими моделями данных YANG

Модуль ietf-vpn-common [RFC9181] включает набор идентификаторов, типов и группироваок, предназначенных для использования в связанных с VPN модулях YANG независимо от уровня (например, L2, L3) и типа модуля (например, модель сети или службы), включая будущие выпуски имеющихся моделей (например, [RFC8299] или [RFC8466]). L3NM использует эти базовые типы и группировки.

Чтобы избежать дублирования данных и упростить их передачу между уровнями, когда это требуется (от уровня сервиса на сетевой и обратно), в ранних вресиях L3NM применяется много узлов данных из [RFC8299]. Тем не менее, от такого подхода отказались в пользу модуля ietf-vpn-common, поскольку исходное решение интерпретировалось как внедрение L3NM в зависимости от L3SM, а это не так. Например, сервис-провайдер может использовать L3NM для создания своих служб L3VPN без раскрытия L3SM.

Как отмечено в разделе 4, модель L3NM предназначена для управления услугами L3VPN в сети сервис-провайдера. Модуль обеспечивает сетевое представление сервиса, которое видимо лишь внутри сети провайдера и не раскрывается наружу (например, клиентам). Приведенные ниже элементы показывают интерфейсы L3NM с другими модулями YANG.

L3SM

Модули топологии сети

Модули устройств

• Управление маршрутизацией [RFC8349].
• BGP [BGP-YANG].
• PIM [PIM-YANG].
• Поддержка NAT [RFC8512].
• Поддержка QoS [QoS-YANG].
• ACL [RFC8519].

6. Пример использования модели данных L3NM

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

6.1. Корпоративные услуги L3 VPN

Корпоративные сети L3VPN являются одними из наиболее распространённых служб и модель L3NM может быть полезна для автоматизации предоставления и поддержки таких VPN. Можно создать шаблоны и пакетные процессы, в результате чего многие параметры, которые для VPN нужно создавать с нуля, можно абстрагировать на верхний уровень программно определяемой сети (Software-Defined Networking или SDN) [RFC7149] [RFC7426], но некоторая часть ручной работы сохранится.

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

6.2. Управление ресурсами нескольких доменов

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

6.3. Управление групповыми службами

Групповые услуги можно реализовать через L3VPN с использованием двойных PIM MVPN (модель draft-rosen) [RFC6037] или MVPN на основе Multiprotocol BGP (MP-BGP) [RFC6513] [RFC6514]. Оба метода поддерживаются и одинаково эффективны, главное различие состоит в том, что MVPN на основе MP-BGP не требуют настройки групповой передачи в сети сервис-провайдера. MP-BGP MVPN реализуют плоскость управления BGP внутри AS и PIM Sparse Mode [RFC7761] в качестве плоскости данных. Сведения о состоянии PIM передаются между PE с использованием той же архитектуры, которая применяется для unicast VPN.

Решение [RFC6037] имеет ограничения в таких аспектах, как возможности для транспорта, расширяемость плоскости управления, доступность, эксплуатационная согласованность, и требует поддержки состояния в магистрали. Из-за этих ограничений в качестве базовой архитектурной модели для реализации групповых услуг в L3VPN была выбрана модель MP-BGP MVPN. В этом варианте BGP служит для автоматического обнаружения PE, входящих в MVPN, а клиентская сигнализация PIM передаётся через ядро провайдера с помощью MP-BGP. Групповой трафик доставляется по путям P2MP³ LSP⁴.

7. Описание модуля YANG L3NM

Модуль L3NM (ietf-l3vpn-ntw) определён для управления L3VPN в сети сервис-провайдера и может применяться, в частности, для создания, изменения и нахождения услуг L3VPN в сети.

Полное дерево модуля можно сгенерировать с помощью pyang [PYANG]. Это дерево не показано здесь из-за большого размера (параграф 3.3 в [RFC8340]) и для удобства в документе приведены отдельные ветви.

7.1. Общая структура модуля

Модуль ietf-l3vpn-ntw использует два основных контейнера — vpn-profiles и vpn-services (Рисунок 3). Контейнер vpn-profiles используется провайдером для поддержки набора базовых профилей VPN, применяемых для одной или нескольких служб VPN (параграф 7.2). Контейнер vpn-services содержит набор служб VPN, поддерживаемых в сети сервис-провайдера. Структура данных vpn-service абстрагирует службы VPN (параграф 7.3).

   module: ietf-l3vpn-ntw
     +--rw l3vpn-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]
                          ...

Рисунок 3. Общая структура дерева L3NM.

Некоторые узлы данных связаны с семейством адресов. Для компактного представления данных, имеющих одно значение для IPv4 и IPv6, рекомендуется использовать семейство адресов двойного стека. Если узел данных представлен для двойного стека и IPv4 (или IPv6), значение для двойного стека имеет приоритет.

7.2. Профили VPN

Контейнер vpn-profiles (Рисунок 4) позволяет поставщику услуг VPN задать и поддерживать набор профилей VPN [RFC9181], применяемых для одной или нескольких служб VPN.

     +--rw l3vpn-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
           ...

Рисунок 4. Структура ветви профилей VPN.

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

external-connectivity-identifier

encryption-profile-identifier

qos-profile-identifier

bfd-profile-identifier

forwarding-profile-identifier

routing-profile-identifier

7.3. Услуги VPN

Структура данных vpn-service абстрагирует службу VPN в сети сервис-провайдера. Каждая структура vpn-service однозначно указывается vpn-id, имеющим локальную значимость (например, в контроллере сети). Ветви vpn-services показана на рисунке 5.

     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--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 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-instance-profiles
              |  ...
              +--rw underlay-transport
              |  +-- (type)?
              |     +--:(abstract)
              |     |  +--rw transport-instance-id?   string
              |     |  +--rw instance-type?           identityref
              |     +--:(protocol)
              |        +--rw protocol*                identityref
              +--rw external-connectivity
              |                   {vpn-common:external-connectivity}?
              |  +--rw (profile)?
              |     +--:(profile)
              |        +--rw profile-name?            leafref
              +--rw vpn-nodes
                 ...

Рисунок 5. Структура ветви службы VPN.

Узлы данных, показанные на рисунке 5, перечислены ниже.

vpn-id

vpn-name

vpn-description

customer-name

parent-service-id

vpn-type

vpn-service-topology

status

vpn-instance-profiles

underlay-transport

external-connectivity

vpn-node

7.4. Профили экземпляров VPN

Профили экземпляров VPN предназначены для факторизации узлов данных, используемых на многих уровнях модели. Базовые профили экземпляров VPN определяются на уровне сервиса VPN, а затем вызываются на уровне узла VPN и доступа в сеть VPN. Каждый профиль экземпляра VPN указывается profile-id. Этот идентификатор используется для одного или нескольких узлов VPN (параграф 7.5), чтобы контроллер мог идентифицировать базовые ресурсы (например, RT и RD), которые нужно настроить для данного экземпляра VRF. Ветвь vpn-instance-profiles показана на рисунке 6.

     +--rw l3vpn-ntw
        +--rw vpn-profiles
        |  ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              +--rw vpn-id                   vpn-common:vpn-id
              ...
              +--rw vpn-instance-profiles
              |  +--rw vpn-instance-profile* [profile-id]
              |     +--rw profile-id                 string
              |     +--rw role?                      identityref
              |     +--rw local-as?                  inet:as-number
              |     |      {vpn-common:rtg-bgp}?
              |     +--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 address-family* [address-family]
              |     |  +--rw address-family          identityref
              |     |  +--rw vpn-targets
              |     |  |  +--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 maximum-routes* [protocol]
              |     |     +--rw protocol          identityref
              |     |     +--rw maximum-routes?   uint32
              |     +--rw multicast {vpn-common:multicast}?
              |        ...

Рисунок 6. Структура ветви профилей экземпляров VPN.

Описания узлов данных приведены ниже.

profile-id

role

local-as

rd

directly-assigned

full-auto

no-rd

address-family

address-family

vpn-targets

maximum-routes

multicast

7.5. Узлы VPN

Абстракция vpn-node представляет набор общих правил, применяемых на данном узле сети (обычно PE) и относящихся к одной службе L3VPN. В vpn-node включён параметр для индикации узла сети, где эти правила применяются. Если ne-id указывает конкртеный PE, vpn-node, скорей всего, будет отображён на экземпляр VRF в этом узле. Однако модель позволяет указывать и абстрактный узел и в этом случае сетевой контроллер будет определять расщепление vpn-node по экземплярам VRF. Структура ветви для узла VPN показана на рисунке 7.

     +--rw l3vpn-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 local-as?                  inet:as-number
                    |       {vpn-common:rtg-bgp}?
                    +--rw router-id?                 rt-types:router-id
                    +--rw active-vpn-instance-profiles
                    |  +--rw vpn-instance-profile* [profile-id]
                    |     +--rw profile-id                 leafref
                    |     +--rw router-id* [address-family]
                    |     |  +--rw address-family    identityref
                    |     |  +--rw router-id?        inet:ip-address
                    |     +--rw local-as?            inet:as-number
                    |     |     {vpn-common:rtg-bgp}?
                    |     +--rw (rd-choice)?
                    |     |  ....
                    |     +--rw address-family* [address-family]
                    |     |  +--rw address-family          identityref
                    |     |  |  ...
                    |     |  +--rw vpn-targets
                    |     |  |  ...
                    |     |  +--rw maximum-routes* [protocol]
                    |     |     ...
                    |     +--rw multicast {vpn-common:multicast}?
                    |        ...
                    +--rw msdp {msdp}?
                    |  +--rw peer?            inet:ipv4-address
                    |  +--rw local-address?   inet:ipv4-address
                    |  +--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 groups
                    |  +--rw group* [group-id]
                    |     +--rw group-id    string
                    +--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-network-accesses
                       ...

Рисунок 7. Структура ветви узла VPN.

Узлы данных vpn-node перечислены ниже.

vpn-node-id

description

ne-id

local-as

router-id

active-vpn-instance-profiles

msdp

groups

status

vpn-network-accesses

7.6. Доступ в сеть VPN

Контейнер vpn-network-access включает набор узлов данных со сведениями относительно доступа для трафика, относящегося к конкретной сети L3VPN (Рисунок 8).

   ...
   +--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 interface-id?              string
               +--rw description?               string
               +--rw vpn-network-access-type?   identityref
               +--rw vpn-instance-profile?      leafref
               +--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 connection
               |  ...
               +--rw ip-connection
               |  ...
               +--rw routing-protocols
               |  ...
               +--rw oam
               |  ...
               +--rw security
               |  ...
               +--rw service
                  ...

Рисунок 8. Структура ветви доступа в сеть VPN.

Узлы данных контейнера vpn-network-access перечислены ниже.

id

interface-id

description

vpn-network-access-type

point-to-point

multipoint

irb

loopback

vpn-instance-profile

status

connection

ip-connection

routing-protocols

oam

security

service

7.6.1. Соединение

Контейнер connection представляет связность L2 с L3VPN для конкретного доступа в сеть VPN. Как показано на рисунке 9, контейнер connection задаёт протоколы и параметрв для включения такой связности L2. Трафик может входить в VPN с инкапсуляцией или без неё (например, VLAN, QinQ). Контейнер encapsulation задаёт применяемую инкапсуляцию L2 (при наличии) и позволяет настроить соответствующие теги.

Интерфейс, который подключается к L3VPN, указывает interface-id на уровне vpn-network-access. С точки зрения модели сети предполагается, что interface-id достаточно для идентификации этого интерфейса. Однако для некоторых реализаций и развёртываний может потребоваться настройка конкретных субинтерфейсов L2. Такие интерфейсы, связанные с L2, могут быть включены в l2-termination-point.

Если нужен туннель L2 для завершения службы в соединении CE-PE, применяется контейнер l2-tunnel-service, задающий параметры, требуемые для организации такой туннельной службы (например, VPLS⁵ или VXLAN⁶). Задан идентификатор l2-tunnel-type для указания типа туннеля L2. Контейнер может также указывать псевдопровод (параграф 6.1 в [RFC8077]).

Как указано в параграфе 7.6, l2vpn-id служит для идентификации услуги L2VPN, связанной с интегрированным интерфейсом моста и маршрутизации (Integrated Routing and Bridging или IRB).

Для реализаций, требующих внутренних мостов, в local-bridge-reference можно указать ссылку на локальный мост (это может быть локальный домен мостов).

Согласно [RFC4176], сайт представляет местоположение клиента VPN, подключённое к сети сервис-провайдера через канал CE-PE, который может иметь доступ хотя бы к одной VPN. Соединение сайта клиента с сетью провайдера является опорным (bearer) и с каждым сайтом связан список таких соединений. Опорное соединение — это соединение L2 с сайтом. Для L3NM предполагается, что опорное соединение выделено сервис-провайдером на этапе оркестровки (организации) службы. Это соединение связано с элементом сети и портом, поэтому указывается просто ссылкой bearer-reference для связывания запроса услуги (например, L3SM) и L3NM.

L3NM можно использовать для создания интерфейса агрегата каналов (Link Aggregation Group или LAG) для данной услуги L3VPN (lag-interface) [IEEE802.1AX]. Такой интерфейс LAG можно указать в ветви interface-id (параграф 7.6).

   ...
   +--rw connection
   |  +--rw encapsulation
   |  |  +--rw type?              identityref
   |  |  +--rw dot1q
   |  |  |  +--rw tag-type?   identityref
   |  |  |  +--rw cvlan-id?   uint16
   |  |  +--rw priority-tagged
   |  |  |  +--rw tag-type?   identityref
   |  |  +--rw qinq
   |  |     +--rw tag-type?   identityref
   |  |     +--rw svlan-id    uint16
   |  |     +--rw cvlan-id    uint16
   |  +--rw (l2-service)?
   |  |  +--:(l2-tunnel-service)
   |  |  |  +--rw l2-tunnel-service
   |  |  |     +--rw type?         identityref
   |  |  |     +--rw pseudowire
   |  |  |     |  +--rw vcid?      uint32
   |  |  |     |  +--rw far-end?   union
   |  |  |     +--rw vpls
   |  |  |     |  +--rw vcid?      uint32
   |  |  |     |  +--rw far-end*   union
   |  |  |     +--rw vxlan
   |  |  |        +--rw vni-id             uint32
   |  |  |        +--rw peer-mode?         identityref
   |  |  |        +--rw peer-ip-address*   inet:ip-address
   |  |  +--:(l2vpn)
   |  |     +--rw l2vpn-id?            vpn-common:vpn-id
   |  +--rw l2-termination-point?      string
   |  +--rw local-bridge-reference?    string
   |  +--rw bearer-reference?          string
   |  |       {vpn-common:bearer-reference}?
   |  +--rw lag-interface {vpn-common:lag-interface}?
   |     +--rw lag-interface-id?   string
   |     +--rw member-link-list
   |        +--rw member-link* [name]
   |           +--rw name    string
   ...

Рисунок 9. Структура ветви соединений.

7.6.2. Соединение IP

Контейнер ip-connection служит для группировки сведений о связности L3, в частности, адреса IP доступа в сеть VPN. Выделенный адрес представляет нофигурацию интерфейса PE. Отметим, что для завершения службы L3 может потребоваться отдельный адрес интерфейса L3, отличный от указанного в контейнере connection. Идентификатор такого интерфейса включается в l3-termination-point. Этот узел данных может служить, например, для передачи интерфейса домена мостов. Как показано на рисунке 10, контейнер ip-connection может содержать адреса IPv4, IPv6 или оба, если поддерживается dual-stack.

   ...
   +--rw vpn-network-accesses
      +--rw vpn-network-access* [id]
         ...
         +--rw ip-connection
         |  +--rw l3-termination-point?     string
         |  +--rw ipv4 {vpn-common:ipv4}?
         |  |  ...
         |  +--rw ipv6 {vpn-common:ipv6}?
         |     ...
         ...

Рисунок 10. Структура ветви соединений IP.

Для IPv4 и IPv6 соединение IP поддерживает 3 режима назначения адресов IP для клиентов: DHCP провайдера, ретранслятор DHCP и статическое назначение. Отметим, что для IPv6 можно использовать автоматическую настройку адресов без учёта состояния (Stateless Address Autoconfiguration или SLAAC) [RFC4862]. Для адресов IPv4 и IPv6 применяется address-allocation-type для указания режима выделения адресов IP, активируемого для данного доступа в сеть VPN. При установке для address-allocation-type значения provider-dhcp назначение DHCP может происходить локально или от внешнего сервера DHCP, в зависимости от dhcp-service-type.

На рисунке 11 показана структура динамического выделения адреса IPv4 (т. е. с помощью DHCP).

   ...
   +--rw ip-connection
   |  +--rw l3-termination-point?     string
   |  +--rw ipv4 {vpn-common:ipv4}?
   |  |  +--rw local-address?             inet:ipv4-address
   |  |  +--rw prefix-length?             uint8
   |  |  +--rw address-allocation-type?   identityref
   |  |  +--rw (allocation-type)?
   |  |     +--:(provider-dhcp)
   |  |     |  +--rw dhcp-service-type?   enumeration
   |  |     |  +--rw (service-type)?
   |  |     |     +--:(relay)
   |  |     |     |  +--rw server-ip-address*
   |  |     |     |          inet:ipv4-address
   |  |     |     +--:(server)
   |  |     |        +--rw (address-assign)?
   |  |     |           +--:(number)
   |  |     |           |  +--rw number-of-dynamic-address?
   |  |     |           |           uint16
   |  |     |           +--:(explicit)
   |  |     |              +--rw customer-addresses
   |  |     |                 +--rw address-pool* [pool-id]
   |  |     |                    +--rw pool-id          string
   |  |     |                    +--rw start-address
   |  |     |                    |           inet:ipv4-address
   |  |     |                    +--rw end-address?
   |  |     |                                inet:ipv4-address
   |  |     +--:(dhcp-relay)
   |  |     |  +--rw customer-dhcp-servers
   |  |     |     +--rw server-ip-address*   inet:ipv4-address
   |  |     +--:(static-addresses)
   |  |        ...
   ...

Рисунок 11. Структура ветви соединений IP (IPv4).

На рисунке 12 показана структура динамического выделения адреса IPv6 (например, DHCPv6 и/или SLAAC). Отметим, что при установке для address-allocation-type значения slaac опция Prefix Information в Router Advertisements для SLAAC будет передавать префикс IPv6, определяемый local-address и prefix-length. Например при local-address со значением 2001:db8:0:1::1 и prefix-length со значением 64 будет использован префикс IPv6 2001:db8:0:1::/64.

   ...
   +--rw ip-connection
   |  +--rw l3-termination-point?     string
   |  +--rw ipv4 {vpn-common:ipv4}?
   |  |  ...
   |  +--rw ipv6 {vpn-common:ipv6}?
   |     +--rw local-address?                 inet:ipv6-address
   |     +--rw prefix-length?                 uint8
   |     +--rw address-allocation-type?       identityref
   |     +--rw (allocation-type)?
   |        +--:(provider-dhcp)
   |        |  +--rw provider-dhcp
   |        |     +--rw dhcp-service-type?
   |        |     |       enumeration
   |        |     +--rw (service-type)?
   |        |        +--:(relay)
   |        |        |  +--rw server-ip-address*
   |        |        |          inet:ipv6-address
   |        |        +--:(server)
   |        |           +--rw (address-assign)?
   |        |              +--:(number)
   |        |              |  +--rw number-of-dynamic-address?
   |        |              |          uint16
   |        |              +--:(explicit)
   |        |                 +--rw customer-addresses
   |        |                    +--rw address-pool*  [pool-id]
   |        |                       +--rw pool-id      string
   |        |                       +--rw start-address
   |        |                       |       inet:ipv6-address
   |        |                       +--rw end-address?
   |        |                               inet:ipv6-address
   |        +--:(dhcp-relay)
   |        |  +--rw customer-dhcp-servers
   |        |     +--rw server-ip-address*
   |        |             inet:ipv6-address
   |        +--:(static-addresses)
   |           ...

Рисунок 12. Структура ветви соединений IP (IPv6).

При статической адресации (Рисунок 13) модель поддерживает назначение нескольких адресов IP в одном vpn-network-access. Для идентификации основного адреса в соединении должна быть указана ссылка primary-address с соответствующим значением address-id.

   ...
   +--rw ip-connection
   |  +--rw l3-termination-point?     string
   |  +--rw ipv4 {vpn-common:ipv4}?
   |  |  +--rw address-allocation-type?         identityref
   |  |  +--rw (allocation-type)?
   |  |     ...
   |  |     +--:(static-addresses)
   |  |        +--rw primary-address?        -> ../address/address-id
   |  |        +--rw address* [address-id]
   |  |           +--rw address-id          string
   |  |           +--rw customer-address?   inet:ipv4-address
   |  +--rw ipv6 {vpn-common:ipv6}?
   |     +--rw address-allocation-type?         identityref
   |     +--rw (allocation-type)?
   |        ...
   |        +--:(static-addresses)
   |           +--rw primary-address?     -> ../address/address-id
   |           +--rw address* [address-id]
   |              +--rw address-id          string
   |              +--rw customer-address?   inet:ipv6-address
   ...

Рисунок 13. Структура ветви соединений IP (статический режим).

7.6.3. Протоколы маршрутизации CE-PE

Поставщик услуг VPN может настроить 1 или несколько протоколов маршрутизации, связанных с конкретным vpn-network-access, для работы между PE и CE. Каждый экземпляр указывается однозначно, чтобы можно было настроить на канале несколько экземпляров одного протокола маршрутизации. Ветвь routing-protocols показана на рисунке 14.

     ...
     +--rw vpn-network-accesses
        +--rw vpn-network-access* [id]
           ...
           +--rw routing-protocols
           |  +--rw routing-protocol* [id]
           |     +--rw id   string
           |     +--rw type?               identityref
           |     +--rw routing-profiles* [id]
           |     |  +--rw id      leafref
           |     |  +--rw type?   identityref
           |     +--rw static
           |     |  ...
           |     +--rw bgp
           |     |  ...
           |     +--rw ospf
           |     |  ...
           |     +--rw isis
           |     |  ...
           |     +--rw rip
           |     |  ...
           |     +--rw vrrp
           |        ...
           +--rw security
               ...

Рисунок 14. Структура ветви маршрутизации.

Можно задать несколько экземпляров протокола маршрутизации, каждый из которых однозначно указывается значением id. Тип экземпляра маршрутизации указывает лист type. Значения этих атрибутов определены в [RFC9181] (routing-protocol-type). Настройка нескольких экземпляров протокола маршрутизации не означает автоматически наличие (с точки зрения конфигурации) параллельных экземпляров на канале PE-CE. Каждая реализация (обычно организатор сети, как показано на рисунке 1) самостоятельно выбирает подходящую конфигурацию в зависимости от базовых возможностей и рабочих рекомендаций сервис-провайдера. Например, если нужно реализовать несколько партнёров BGP, потребуется настроить несколько экземпляров BGP как часть этой модели. Однако с точки зрения конфигурации устройства это можно реализовать разными способами:

• несколько процессов BGP с одним соседом для всех процессов;

• 1 процесс BGP с несколькими соседями;

• комбинация предыдущих вариантов.

Конфигурация маршрутизации не включает правила нижнего уровня, они обрабатываются на уровне конфигурации устройств. Локальные правила сервис-провайдера (например, фильтрация) реализуются как часть конфигурации устройства, они не фиксируются в L3NM, но модель позволяет связать локальные профили с экземплярами маршрутизации (routing-profiles). Отметим, что эти профили маршрутизации могут охватывать параметры, которые глобально применяются ко всем службам L3VPN в сети сервис-провайдера, тогда как настраиваемые параметры L3VPN фиксируются средствами L3NM. Таким образом, предоставление услуги L3VPN будет основываться на создании экземпляров этих глобальных профилей маршрутизации и настройке L3NM.

7.6.3.1. Статическая маршрутизация

L3NM поддерживает конфигурации с 1 или несколькими статическими маршрутами IPv4/IPv6. Поскольку для IPv4 и IPv6 применяется одна структура, рассматривался вариант использования одного контейнера для группировки статических записей независимо от семейства адресов. Однако от этого отказались, чтобы упростить сопоставление с использованием структуры из [RFC8299]. Ветвь для статической маршрутизации показана на рисунке 15.

   ...
   +--rw routing-protocols
   |  +--rw routing-protocol* [id]
   |     ...
   |     +--rw static
   |     |  +--rw cascaded-lan-prefixes
   |     |     +--rw ipv4-lan-prefixes*
   |     |     |       [lan next-hop]
   |     |     |       {vpn-common:ipv4}?
   |     |     |  +--rw lan         inet:ipv4-prefix
   |     |     |  +--rw lan-tag?      string
   |     |     |  +--rw next-hop      union
   |     |     |  +--rw bfd-enable?   boolean
   |     |     |  +--rw metric?       uint32
   |     |     |  +--rw preference?   uint32
   |     |     |  +--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 ipv6-lan-prefixes*
   |     |             [lan next-hop]
   |     |             {vpn-common:ipv6}?
   |     |        +--rw lan         inet:ipv6-prefix
   |     |        +--rw lan-tag?      string
   |     |        +--rw next-hop      union
   |     |        +--rw bfd-enable?   boolean
   |     |        +--rw metric?       uint32
   |     |        +--rw preference?   uint32
   |     |        +--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
   ...

Рисунок 15. Структура ветви статической маршрутизации.

Узлы данных для префикса IP указаны ниже.

lan-tag

next-hop

bfd-enable

metric

preference

status

7.6.3.2. BGP

L3NM позволяет настраивать соседей BGP, включая набор параметров, которые нужно задать на уровне интерфейса для настройки службы. Контейнер bgp не предназначен для включения всех параметров BGP, это относится скорее к полной модели устройства BGP. Ветвь для маршрутизации BGP показана на рисунке 16.

   ...
   +--rw routing-protocols
   |  +--rw routing-protocol* [id]
   |     ...
   |     +--rw bgp
   |     |  +--rw description?               string
   |     |  +--rw local-as?                  inet:as-number
   |     |  +--rw peer-as                    inet:as-number
   |     |  +--rw address-family?            identityref
   |     |  +--rw local-address?             union
   |     |  +--rw neighbor*                  inet:ip-address
   |     |  +--rw multihop?                  uint8
   |     |  +--rw as-override?               boolean
   |     |  +--rw allow-own-as?              uint8
   |     |  +--rw prepend-global-as?         boolean
   |     |  +--rw send-default-route?        boolean
   |     |  +--rw site-of-origin?            rt-types:route-origin
   |     |  +--rw ipv6-site-of-origin?       rt-types:ipv6-route-origin
   |     |  +--rw redistribute-connected* [address-family]
   |     |  |  +--rw address-family    identityref
   |     |  |  +--rw enable?           boolean
   |     |  +--rw bgp-max-prefix
   |     |  |  +--rw max-prefix?          uint32
   |     |  |  +--rw warning-threshold?   decimal64
   |     |  |  +--rw violate-action?      enumeration
   |     |  |  +--rw restart-timer?       uint32
   |     |  +--rw bgp-timers
   |     |  |  +--rw keepalive?   uint16
   |     |  |  +--rw hold-time?   uint16
   |     |  +--rw authentication
   |     |  |  +--rw enable?            boolean
   |     |  |  +--rw keying-material
   |     |  |     +--rw (option)?
   |     |  |        +--:(ao)
   |     |  |        |  +--rw enable-ao?         boolean
   |     |  |        |  +--rw ao-keychain?       key-chain:key-chain-ref
   |     |  |        +--:(md5)
   |     |  |        |  +--rw md5-keychain?      key-chain:key-chain-ref
   |     |  |        +--:(explicit)
   |     |  |        |  +--rw key-id?            uint32
   |     |  |        |  +--rw key?               string
   |     |  |        |  +--rw crypto-algorithm?  identityref
   |     |  |        +--:(ipsec)
   |     |  |           +--rw sa?             string
   |     |  +--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
   ...

Рисунок 16. Структура ветви маршрутизации BGP.

Ниже приведены узлы данных контейнера. Реализации (например, организатор сети) должна вывести соответствующую конфигурацию устройства BGP.

description

local-as

peer-as

address-family

local-address

neighbor

multihop

as-override

allow-own-as

prepend-global-as

send-default-route

site-of-origin

ipv6-site-of-origin

redistribute-connected

bgp-max-prefix

max-prefix

warning-threshold

violate-action

restart-timer

bgp-timers

authentication

status

7.6.3.3. OSPF

OSPF можно настроить для работы как протокол маршрутизации в vpn-network-access (Рисунок 17).

   ...
   +--rw routing-protocols
   |  +--rw routing-protocol* [id]
   |     ...
   |     +--rw ospf
   |     |  +--rw address-family?   identityref
   |     |  +--rw area-id           yang:dotted-quad
   |     |  +--rw metric?           uint16
   |     |  +--rw sham-links  {vpn-common:rtg-ospf-sham-link}?
   |     |  |  +--rw sham-link* [target-site]
   |     |  |     +--rw target-site    string
   |     |  |     +--rw metric?        uint16
   |     |  +--rw max-lsa?          uint32
   |     |  +--rw authentication
   |     |  |  +--rw enable?            boolean
   |     |  |  +--rw keying-material
   |     |  |     +--rw (option)?
   |     |  |        +--:(auth-key-chain)
   |     |  |        |  +--rw key-chain?
   |     |  |        |          key-chain:key-chain-ref
   |     |  |        +--:(auth-key-explicit)
   |     |  |        |  +--rw key-id?      uint32
   |     |  |        |  +--rw key?         string
   |     |  |        |  +--rw crypto-algorithm?
   |     |  |        |          identityref
   |     |  |        +--:(ipsec)
   |     |  |           +--rw sa?    string
   |     |  +--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
   ...

Рисунок 17. Структура ветви маршрутизации OSPF.

address-family

area-id

metric

sham-links

max-lsa

authentication

status

7.6.3.4. IS-IS

Модель позволяет включить IS-IS [ISO10589] [RFC1195] [RFC5308] для работы на интерфейсе vpn-network-access. Ветвь IS-IS показана на рисунке 18.

   ...
   +--rw routing-protocols
   |  +--rw routing-protocol* [id]
   |     ...
   |     +--rw isis
   |     |  +--rw address-family?   identityref
   |     |  +--rw area-address      area-address
   |     |  +--rw level?            identityref
   |     |  +--rw metric?           uint16
   |     |  +--rw mode?             enumeration
   |     |  +--rw authentication
   |     |  |  +--rw enable?            boolean
   |     |  |  +--rw keying-material
   |     |  |     +--rw (option)?
   |     |  |        +--:(auth-key-chain)
   |     |  |        |  +--rw key-chain?
   |     |  |        |          key-chain:key-chain-ref
   |     |  |        +--:(auth-key-explicit)
   |     |  |           +--rw key-id?             uint32
   |     |  |           +--rw key?                string
   |     |  |           +--rw crypto-algorithm?   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
   ...

Рисунок 18. Структура ветви маршрутизации IS-IS.

Ниже перечислены узлы данных IS-IS.

address-family

area-address

level

metric

mode

authentication

status

7.6.3.5. RIP

Модель позволяет пользователю настроить RIP для работы на интерфейсе vpn-network-access (Рисунок 19).

   ...
   +--rw routing-protocols
   |  +--rw routing-protocol* [id]
   |     ...
   |     +--rw rip
   |     |  +--rw address-family?   identityref
   |     |  +--rw timers
   |     |  |  +--rw update-interval?     uint16
   |     |  |  +--rw invalid-interval?    uint16
   |     |  |  +--rw holddown-interval?   uint16
   |     |  |  +--rw flush-interval?      uint16
   |     |  +--rw default-metric?   uint8
   |     |  +--rw authentication
   |     |  |  +--rw enable?            boolean
   |     |  |  +--rw keying-material
   |     |  |     +--rw (option)?
   |     |  |        +--:(auth-key-chain)
   |     |  |        |  +--rw key-chain?
   |     |  |        |          key-chain:key-chain-ref
   |     |  |        +--:(auth-key-explicit)
   |     |  |           +--rw key?                string
   |     |  |           +--rw crypto-algorithm?   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
   ...

Рисунок 19. Структура ветви маршрутизации RIP.

Ниже перечислены узлы данных для протокола RIP.

address-family

timers

update-interval

invalid-interval

holddown-interval

flush-interval

default-metric

authentication

status

7.6.3.6. VRRP

Модель позволяет включить протокол резервирования виртуального маршрутизатора (Virtual Router Redundancy Protocol или VRRP) на интерфейсе vpn-network-access (Рисунок 20).

   ...
   +--rw routing-protocols
   |  +--rw routing-protocol* [id]
   |     ...
   |     +--rw vrrp
   |        +--rw address-family*   identityref
   |        +--rw vrrp-group?       uint8
   |        +--rw backup-peer?      inet:ip-address
   |        +--rw virtual-ip-address*   inet:ip-address
   |        +--rw priority?         uint8
   |        +--rw ping-reply?       boolean
   |        +--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
   ...

Рисунок 20. Структура ветви маршрутизации VRRP.

Ниже укаазны поддерживаемые узлы данных.

address-family

vrrp-group

backup-peer

virtual-ip-address

priority

ping-reply

status

Узел для аутентификации отсутствует, поскольку аутентификация в VRRP не поддерживается (раздел 9 в [RFC5798]).

7.6.4. OAM

Контейнер oam (Рисунок 21) задаёт механизмы OAM, используемые для доступа в сеть VPN. В текущей версии L3NM поддерживается лишь BFD.

   ...
   +--rw oam
   |  +--rw bfd {vpn-common:bfd}?
   |     +--rw session-type?               identityref
   |     +--rw desired-min-tx-interval?    uint32
   |     +--rw required-min-rx-interval?   uint32
   |     +--rw local-multiplier?           uint8
   |     +--rw holdtime?                   uint32
   |     +--rw profile?                    leafref
   |     +--rw authentication!
   |     |  +--rw key-chain?    key-chain:key-chain-ref
   |     |  +--rw meticulous?   boolean
   |     +--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
   ...

Рисунок 21. Структура ветви соединения IP (OAM)

Узлы данных для OAM перечислены ниже.

session-type

desired-min-tx-interval

required-min-rx-interval

local-multiplier

holdtime

profile

authentication

status

7.6.5. Безопасность

Контейнер security задаёт аутентификацию и шифрование, применяемые к трафика для данного доступа в сеть VPN. Как показано на рисунке 22, L3NM можно применять для непосредственного управления применяемым шифрованием (например, L2 или L3) или для вызова профиля шифрования.

        ...
        +--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 security
                          |  +--rw encryption {vpn-common:encryption}?
                          |  |  +--rw enabled?   boolean
                          |  |  +--rw layer?     enumeration
                          |  +--rw encryption-profile
                          |     +--rw (profile)?
                          |        +--:(provider-profile)
                          |        |  +--rw profile-name?        leafref
                          |        +--:(customer-profile)
                          |           +--rw customer-key-chain?
                          |                   key-chain:key-chain-ref
                          +--rw service
                              ...

Рисунок 22. Структура ветви безопасности.

7.6.6. Услуги

7.6.6.1. Обзор

Контейнер service задаёт параметры, применяемые к данному доступу в сеть VPN (Рисунок 23).

   ...
   +--rw vpn-network-accesses
      +--rw vpn-network-access* [id]
         ...
         +--rw service
            +--rw pe-to-ce-bandwidth?   uint64 {vpn-common:inbound-bw}?
            +--rw ce-to-pe-bandwidth?   uint64 {vpn-common:outbound-bw}?
            +--rw mtu?                  uint32
            +--rw qos {vpn-common:qos}?
            |  ...
            +--rw carriers-carrier
            |       {vpn-common:carriers-carrier}?
            |  +--rw signaling-type?   enumeration
            +--rw ntp
            |  +--rw broadcast?        enumeration
            |  +--rw auth-profile
            |  |  +--rw profile-id?    string
            |  +--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 multicast {vpn-common:multicast}?
               ...

Рисунок 23. Структура ветви служб.

pe-to-ce-bandwidth

ce-to-pe-bandwidth

mtu

qos

carriers-carrier

ntp

multicast

7.6.6.2. QoS

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

   ...
   +--rw qos {vpn-common:qos}?
   |  +--rw qos-classification-policy
   |  |  +--rw rule* [id]
   |  |     +--rw id             string
   |  |     +--rw (match-type)?
   |  |     |  +--:(match-flow)
   |  |     |  |  +--rw (l3)?
   |  |     |  |  |  +--:(ipv4)
   |  |     |  |  |  |  ...
   |  |     |  |  |  +--:(ipv6)
   |  |     |  |  |     ...
   |  |     |  |  +--rw (l4)?
   |  |     |  |     +--:(tcp)
   |  |     |  |     |  ...
   |  |     |  |     +--:(udp)
   |  |     |  |        ...
   |  |     |  +--:(match-application)
   |  |     |     +--rw match-application?
   |  |     |             identityref
   |  |     +--rw target-class-id?    string
   |  +--rw qos-action
   |  |  +--rw rule* [id]
   |  |     +--rw id                     string
   |  |     +--rw target-class-id?       string
   |  |     +--rw inbound-rate-limit?    decimal64
   |  |     +--rw outbound-rate-limit?   decimal64
   |  +--rw qos-profile
   |     +--rw qos-profile* [profile]
   |        +--rw profile      leafref
   |        +--rw direction?   identityref
   ...

Рисунок 24. Структура ветви QoS.

Классификация QoS может быть основана на множестве критериев, включая указанные ниже.

Layer 3

   +--rw qos {vpn-common:qos}?
   |  +--rw qos-classification-policy
   |  |  +--rw rule* [id]
   |  |     +--rw id           string
   |  |     +--rw (match-type)?
   |  |     |  +--:(match-flow)
   |  |     |  |  +--rw (l3)?
   |  |     |  |  |  +--:(ipv4)
   |  |     |  |  |  |  +--rw ipv4
   |  |     |  |  |  |     +--rw dscp?              inet:dscp
   |  |     |  |  |  |     +--rw ecn?               uint8
   |  |     |  |  |  |     +--rw length?            uint16
   |  |     |  |  |  |     +--rw ttl?               uint8
   |  |     |  |  |  |     +--rw protocol?          uint8
   |  |     |  |  |  |     +--rw ihl?               uint8
   |  |     |  |  |  |     +--rw flags?             bits
   |  |     |  |  |  |     +--rw offset?            uint16
   |  |     |  |  |  |     +--rw identification?    uint16
   |  |     |  |  |  |     +--rw (destination-network)?
   |  |     |  |  |  |     |  +--:(destination-ipv4-network)
   |  |     |  |  |  |     |     +--rw destination-ipv4-network?
   |  |     |  |  |  |     |             inet:ipv4-prefix
   |  |     |  |  |  |     +--rw (source-network)?
   |  |     |  |  |  |        +--:(source-ipv4-network)
   |  |     |  |  |  |           +--rw source-ipv4-network?
   |  |     |  |  |  |  inet:ipv4-prefix
   |  |     |  |  |  +--:(ipv6)
   |  |     |  |  |     +--rw ipv6
   |  |     |  |  |        +--rw dscp?              inet:dscp
   |  |     |  |  |        +--rw ecn?               uint8
   |  |     |  |  |        +--rw length?            uint16
   |  |     |  |  |        +--rw ttl?               uint8
   |  |     |  |  |        +--rw protocol?          uint8
   |  |     |  |  |        +--rw (destination-network)?
   |  |     |  |  |        |  +--:(destination-ipv6-network)
   |  |     |  |  |        |     +--rw destination-ipv6-network?
   |  |     |  |  |        |             inet:ipv6-prefix
   |  |     |  |  |        +--rw (source-network)?
   |  |     |  |  |        |  +--:(source-ipv6-network)
   |  |     |  |  |        |     +--rw source-ipv6-network?
   |  |     |  |  |        |             inet:ipv6-prefix
   |  |     |  |  |        +--rw flow-label?
   |  |     |  |  |                   inet:ipv6-flow-label
   ...

Рисунок 25. Структура ветви QoS (L3).

Layer 4

   +--rw qos {vpn-common:qos}?
   |  +--rw qos-classification-policy
   |  |  +--rw rule* [id]
   |  |     +--rw id           string
   |  |     +--rw (match-type)?
   |  |     |  +--:(match-flow)
   |  |     |  |  +--rw (l3)?
   |  |     |  |  |  ...
   |  |     |  |  +--rw (l4)?
   |  |     |  |     +--:(tcp)
   |  |     |  |     |  +--rw tcp
   |  |     |  |     |     +--rw sequence-number?          uint32
   |  |     |  |     |     +--rw acknowledgement-number?   uint32
   |  |     |  |     |     +--rw data-offset?              uint8
   |  |     |  |     |     +--rw reserved?                 uint8
   |  |     |  |     |     +--rw flags?                    bits
   |  |     |  |     |     +--rw window-size?              uint16
   |  |     |  |     |     +--rw urgent-pointer?           uint16
   |  |     |  |     |     +--rw options?                  binary
   |  |     |  |     |     +--rw (source-port)?
   |  |     |  |     |     |  +--:(source-port-range-or-operator)
   |  |     |  |     |     |     +--rw source-port-range-or-operator
   |  |     |  |     |     |        +--rw (port-range-or-operator)?
   |  |     |  |     |     |           +--:(range)
   |  |     |  |     |     |           |  +--rw lower-port
   |  |     |  |     |     |           |  |       inet:port-number
   |  |     |  |     |     |           |  +--rw upper-port
   |  |     |  |     |     |           |          inet:port-number
   |  |     |  |     |     |           +--:(operator)
   |  |     |  |     |     |              +--rw operator? operator
   |  |     |  |     |     |              +--rw port
   |  |     |  |     |     |                      inet:port-number
   |  |     |  |     |     +--rw (destination-port)?
   |  |     |  |     |        +--:(destination-port-range-or-operator)
   |  |     |  |     |          +--rw destination-port-range-or-operator
   |  |     |  |     |             +--rw (port-range-or-operator)?
   |  |     |  |     |                +--:(range)
   |  |     |  |     |                |  +--rw lower-port
   |  |     |  |     |                |  |       inet:port-number
   |  |     |  |     |                |  +--rw upper-port
   |  |     |  |     |                |          inet:port-number
   |  |     |  |     |                +--:(operator)
   |  |     |  |     |                   +--rw operator? operator
   |  |     |  |     |                   +--rw port
   |  |     |  |     |                           inet:port-number
   |  |     |  |     +--:(udp)
   |  |     |  |        +--rw udp
   |  |     |  |           +--rw length?                    uint16
   |  |     |  |           +--rw (source-port)?
   |  |     |  |           |  +--:(source-port-range-or-operator)
   |  |     |  |           |     +--rw source-port-range-or-operator
   |  |     |  |           |        +--rw (port-range-or-operator)?
   |  |     |  |           |           +--:(range)
   |  |     |  |           |           |  +--rw lower-port
   |  |     |  |           |           |  |       inet:port-number
   |  |     |  |           |           |  +--rw upper-port
   |  |     |  |           |           |          inet:port-number
   |  |     |  |           |           +--:(operator)
   |  |     |  |           |              +--rw operator?  operator
   |  |     |  |           |              +--rw port
   |  |     |  |           |                      inet:port-number
   |  |     |  |           +--rw (destination-port)?
   |  |     |  |              +--:(destination-port-range-or-operator)
   |  |     |  |                +--rw destination-port-range-or-operator
   |  |     |  |                    +--rw (port-range-or-operator)?
   |  |     |  |                       +--:(range)
   |  |     |  |                       |  +--rw lower-port
   |  |     |  |                       |  |       inet:port-number
   |  |     |  |                       |  +--rw upper-port
   |  |     |  |                       |          inet:port-number
   |  |     |  |                       +--:(operator)
   |  |     |  |                          +--rw operator?   operator
   |  |     |  |                          +--rw port
   |  |     |  |                                  inet:port-number
   ...

Рисунок 26. Структура ветви QoS (L4).

Соответствие приложения

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

Групповая передача может быть разрешена доя отдельной VPN на уровне узла VPN и доступа в сеть VPN (Рисунок 27). Некоторые узлы данных (например, max-groups на рисунке 28) могут контролироваться на разных уровнях — служба VPN, узел VPN, доступ в сеть VPN.

        ...
        +--rw vpn-services
           +--rw vpn-service* [vpn-id]
              ...
              +--rw vpn-instance-profiles
              |  +--rw vpn-instance-profile* [profile-id]
              |     ....
              |     +--rw multicast {vpn-common:multicast}?
              |        ...
              +--rw vpn-nodes
                 +--rw vpn-node* [vpn-node-id]
                    ...
                    +--rw active-vpn-instance-profiles
                    |  +--rw vpn-instance-profile* [profile-id]
                    |     ...
                    |     +--rw multicast {vpn-common:multicast}?
                    |        ...
                    +--rw vpn-network-accesses
                       +--rw vpn-network-access* [id]
                          ...
                          +--rw service
                             ...
                             +--rw multicast {vpn-common:multicast}?
                                ...

Рисунок 27. Структура ветви групповой передачи.

Связанные с групповой передачей узлы данных на уровне профиля экземпляра VPN показаны на рисунке 28.

   ...
   +--rw vpn-services
      +--rw vpn-service* [vpn-id]
         ...
         +--rw vpn-instance-profiles
         |  +--rw vpn-instance-profile* [profile-id]
         |     ....
         |     +--rw multicast {vpn-common:multicast}?
         |        +--rw tree-flavor?   identityref
         |        +--rw rp
         |        |  +--rw rp-group-mappings
         |        |  |  +--rw rp-group-mapping* [id]
         |        |  |     +--rw id                  uint16
         |        |  |     +--rw provider-managed
         |        |  |     |  +--rw enabled?                   boolean
         |        |  |     |  +--rw rp-redundancy?             boolean
         |        |  |     |  +--rw optimal-traffic-delivery?  boolean
         |        |  |     |  +--rw anycast
         |        |  |     |     +--rw local-address?    inet:ip-address
         |        |  |     |     +--rw rp-set-address*   inet:ip-address
         |        |  |     +--rw rp-address          inet:ip-address
         |        |  |     +--rw groups
         |        |  |        +--rw group* [id]
         |        |  |           +--rw id                     uint16
         |        |  |           +--rw (group-format)
         |        |  |              +--:(group-prefix)
         |        |  |              |  +--rw group-address?
         |        |  |              |          inet:ip-prefix
         |        |  |              +--:(startend)
         |        |  |                 +--rw group-start?
         |        |  |                 |       inet:ip-address
         |        |  |                 +--rw group-end?
         |        |  |                 |       inet:ip-address
         |        |  +--rw rp-discovery
         |        |     +--rw rp-discovery-type?   identityref
         |        |     +--rw bsr-candidates
         |        |        +--rw bsr-candidate-address*
         |        |        |       inet:ip-address
         |        +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
         |        |  +--rw static-group* [group-addr]
         |        |  |  +--rw group-addr
         |        |  |  |       rt-types:ipv4-multicast-group-address
         |        |  |  +--rw source-addr?
         |        |  |          rt-types:ipv4-multicast-source-address
         |        |  +--rw max-groups?     uint32
         |        |  +--rw max-entries?    uint32
         |        |  +--rw version?        identityref
         |        +--rw mld {vpn-common:mld and vpn-common:ipv6}?
         |        |  +--rw static-group* [group-addr]
         |        |  |  +--rw group-addr
         |        |  |  |       rt-types:ipv6-multicast-group-address
         |        |  |  +--rw source-addr?
         |        |  |          rt-types:ipv6-multicast-source-address
         |        |  +--rw max-groups?     uint32
         |        |  +--rw max-entries?    uint32
         |        |  +--rw version?        identityref
         |        +--rw pim {vpn-common:pim}?
         |           +--rw hello-interval?
         |           |       rt-types:timer-value-seconds16
         |           +--rw dr-priority?      uint32
              ...

Рисунок 28. Структура ветви групповой передачи (уровень профиля экземпляра VPN).

Модель поддерживает 1 тип дерева на доступ в VPN (tree- flavor): Any-Source Multicast (ASM), Source-Specific Multicast (SSM) или bidirectional.

При использовании ASM модель поддерживает настройку точек встречи (RP), которые могут быть статическими (static), bsr-rp или auto-rp. При статическом задании точек встречи их сопоставление с multicast-группой должно задаваться в контейнере rp-group-mappings. RP может быть узлом провайдера или клиента. Для клиентского RP адрес RP должен указываться в листе rp-address.

Модель поддерживает резервирование RP через лист rp-redundancy, однако детали этого выходят за рамки документа.

Когда конкретной сети VPN, применяющей ASM, нужна более оптимальная доставка трафика (например, в соответствии с [RFC8299]), можно установить optimal-traffic-delivery. При установке значения true реализация должна использовать любой механизм для более оптимальной доставки трафика клиента. Например, anycast является одним из механизмом повышения избыточности RP, обеспечивая устойчивость к отказам и более быстрое восстановление.

При настройке связанных с групповой передачей параметров на уровне узла VPN (Рисунок 29), применяется такая же структура, какая показана на рисунке 30. При задании на уровне узла VPN параметры IGMP [RFC1112] [RFC2236] [RFC3376], MLD [RFC2710] [RFC3810] и PIM [RFC7761] применяются к каждому доступу в сеть VPN этого узла VPN, если только на уровне доступа в сеть VPN не заданы конкретные узлы.

   ...
   +--rw vpn-nodes
      +--rw vpn-node* [vpn-node-id]
         ...
         +--rw active-vpn-instance-profiles
         |  +--rw vpn-instance-profile* [profile-id]
         |     ...
         |     +--rw multicast {vpn-common:multicast}?
         |        +--rw tree-flavor*   identityref
         |        +--rw rp
         |        |  ...
         |        +--rw igmp {vpn-common:igmp and vpn-common:ipv4}?
         |        |  ...
         |        +--rw mld {vpn-common:mld and vpn-common:ipv6}?
         |        |  ...
         |        +--rw pim {vpn-common:pim}?
         |           ...

Рисунок 29. Структура ветви групповой передачи (уровень узла VPN).

Связанные с групповой передачей узлы данных на уровне доступа в сеть VPN показаны на рисунке 30. Настроенные на этом уровне значения переопределяют значения, заданные на других уровнях.

   ...
   +--rw vpn-network-accesses
      +--rw vpn-network-access* [id]
         ...
         +--rw service
            ...
            +--rw multicast {vpn-common:multicast}?
               +--rw access-type?      enumeration
               +--rw address-family?   identityref
               +--rw protocol-type?    enumeration
               +--rw remote-source?    boolean
               +--rw igmp  {vpn-common:igmp}?
               |  +--rw static-group* [group-addr]
               |  |  +--rw group-addr
               |  |          rt-types:ipv4-multicast-group-address
               |  |  +--rw source-addr?
               |  |          rt-types:ipv4-multicast-source-address
               |  +--rw max-groups?          uint32
               |  +--rw max-entries?         uint32
               |  +--rw max-group-sources?   uint32
               |  +--rw version?             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 mld {vpn-common:mld}?
               |  +--rw static-group* [group-addr]
               |  |  +--rw group-addr
               |  |          rt-types:ipv6-multicast-group-address
               |  |  +--rw source-addr?
               |  |          rt-types:ipv6-multicast-source-address
               |  +--rw max-groups?          uint32
               |  +--rw max-entries?         uint32
               |  +--rw max-group-sources?   uint32
               |  +--rw version?             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 pim {vpn-common:pim}?
                  +--rw hello-interval?   rt-types:timer-value-seconds16
                  +--rw dr-priority?      uint32
                  +--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

Рисунок 30. Структура ветви групповой передачи (уровень доступа в сеть VPN).

8. Модуль YANG L3NM

Этот модуль использует типы из [RFC6991], [RFC8343], [RFC9181] и группировки из [RFC8519], [RFC8177], [RFC8294].

   <CODE BEGINS> file "ietf-l3vpn-ntw@2022-02-14.yang"
   module ietf-l3vpn-ntw {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
     prefix l3nm;

     import ietf-vpn-common {
       prefix vpn-common;
       reference
         "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
                    VPNs";
     }
     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-key-chain {
       prefix key-chain;
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }
     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }

     organization
       "IETF OPSAWG (Operations and Management Area Working Group)";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/opsawg/> 
        WG List:  <mailto:opsawg@ietf.org> 

        Author:   Samier Barguil
                  <mailto:samier.barguilgiraldo.ext@telefonica.com> 
        Editor:   Oscar Gonzalez de Dios
                  <mailto:oscar.gonzalezdedios@telefonica.com> 
        Editor:   Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 
        Author:   Luis Angel Munoz
                  <mailto:luis-angel.munoz@vodafone.com> 
        Author:   Alejandro Aguado
                  <mailto:alejandro.aguado_martin@nokia.com>"; 
     description
       "Этот модуль YANG задаёт базовую, ориентированную на сеть модель
        для настройки L3 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 9182, где правовые
        аспекты приведены более полно.";

     revision 2022-02-14 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
     }

     /* Свойства (возможности) */

     feature msdp {
       description
         "Указывает поддержку протокола MSDP в VPN.";
       reference
         "RFC 3618: Multicast Source Discovery Protocol (MSDP)";
     }

     /* Идентификаторы */

     identity address-allocation-type {
       description
         "Базовый идентификатор типа назначения адресов на канале 
          PE-CE.";
     }

     identity provider-dhcp {
       base address-allocation-type;
       description
         "Сеть провайдера предоставляет клиенту услуги DHCP.";
     }

     identity provider-dhcp-relay {
       base address-allocation-type;
       description
         "Сеть провайдера предоставляет клиенту услуги DHCP relay.";
     }

     identity provider-dhcp-slaac {
       if-feature "vpn-common:ipv6";
       base address-allocation-type;
       description
         "Сеть провайдера предоставляет клиенту услуги DHCP и SLAAC).";
       reference
         "RFC 4862: IPv6 Stateless Address Autoconfiguration";
     }

     identity static-address {
       base address-allocation-type;
       description
         "Сеть провайдера предоставляет клиенту статический адрес IP.";
     }

     identity slaac {
       if-feature "vpn-common:ipv6";
       base address-allocation-type;
       description
         "Сеть провайдера использует IPv6 SLAAC для предоставления
          адресов клиентам.";
       reference
         "RFC 4862: IPv6 Stateless Address Autoconfiguration";
     }

     identity local-defined-next-hop {
       description
         "Базовый идентификатор для заданных локально next hop.";
     }

     identity discard {
       base local-defined-next-hop;
       description
         "Указывает отбрасывание трафика для соответствующего адресата.
          Например, это может создавать «черную дыру» (black-hole).";
     }

     identity local-link {
       base local-defined-next-hop;
       description
         "Считать трафик, адресованный в префикс заданного next-hop,
          как подключённый к локальному каналу.";
     }

     identity l2-tunnel-type {
       description
         "Базовый идентификатор для выбора туннеля L2 в доступе в VPN.";
     }

     identity pseudowire {
       base l2-tunnel-type;
       description
         "Завершение туннельного псевдопровода в доступе в VPN.";
     }

     identity vpls {
       base l2-tunnel-type;
       description
         "Завершение туннеля VPLS в доступе в VPN.";
     }

     identity vxlan {
       base l2-tunnel-type;
       description
         "Завершение туннеля VXLAN в доступе в VPN.";
     }

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

     typedef predefined-next-hop {
       type identityref {
         base local-defined-next-hop;
       }
       description
         "Предопределённый next-hop для локально созданных маршрутов.";
     }

     typedef area-address {
       type string {
         pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
       }
       description
         "Задаёт формат адреса для области.";
     }

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

     grouping vpn-instance-profile {
       description
         "Группировка для узлов данных, которые могут быть факторизованы
          на многих уровнях модели. Группировка может служить для
          определения базовых профилей на уровне сервиса VPN, которые
          будут указываться на уровне узла VPN и доступа в сеть VPN.";
       leaf local-as {
         if-feature "vpn-common:rtg-bgp";
         type inet:as-number;
         description
           "Номер AS провайдера, используемый при маршрутизации BGP.";
       }
       uses vpn-common:route-distinguisher;
       list address-family {
         key "address-family";
         description
           "Набор параметров на семейство адресов.";
         leaf address-family {
           type identityref {
             base vpn-common:address-family;
           }
           description
             "Семейство адресов (IPv4 и/или IPv6).";
         }
         container vpn-targets {
           description
             "Набор целей маршрутов для сопоставления при импорте
              и экспорте маршрутов VRF.";
           uses vpn-common:vpn-route-targets;
         }
         list maximum-routes {
           key "protocol";
           description
             "Максимальное число маршрутов для VRF.";
           leaf protocol {
             type identityref {
               base vpn-common:routing-protocol-type;
             }
             description
               "Протокол маршрутизации. Значение any может служить для
                указания пределов, применимых ко всем активным 
                протоколам.";
           }
           leaf maximum-routes {
             type uint32;
             description
               "Максимальное число префиксов, которые VRF может
                воспринять для данного семейства адресов и протокола.";
           }
         }
       }
       container multicast {
         if-feature "vpn-common:multicast";
         description
           "Глобальные параметры групповой передачи.";
         leaf tree-flavor {
           type identityref {
             base vpn-common:multicast-tree-type;
           }
           description
             "Тип используемого дерева групповой передачи.";
         }
         container rp {
           description
             "Параметры точки встречи (RP).";
           container rp-group-mappings {
             description
               "Параметры сопоставления RP с группой.";
             list rp-group-mapping {
               key "id";
               description
                 "Список сопоставлений RP с группами.";
               leaf id {
                 type uint16;
                 description
                   "Уникальный идентификатор сопоставления.";
               }
               container provider-managed {
                 description
                   "Параметры для управляемой провайдером точки RP.";
                 leaf enabled {
                   type boolean;
                   default "false";
                   description
                     "true, если RP должна быть управляемым провайдером
                      узлом, false для управляемого клиентом узла.";
                 }
                 leaf rp-redundancy {
                   type boolean;
                   default "false";
                   description
                     "true указывает, что нужен механизм резервирования
                      для RP.";
                 }
                 leaf optimal-traffic-delivery {
                   type boolean;
                   default "false";
                   description
                     "true указывает, что сервис-провайдер (SP) должен
                      гарантировать использование оптимального пути для
                      трафика. SP может использовать архитектуру
                      переключения Anycast RP или RP-tree-to-SPT 
                      (SPT - дерево кратчайшего пути).";
                 }
                 container anycast {
                   when "../rp-redundancy = 'true' and
                         ../optimal-traffic-delivery = 'true'" {
                     description
                       "Применимо лишь при активации резервирования RP и
                        доставки по оптимальному пути.";
                   }
                   description
                     "PIM Anycast-RP parameters.";
                   leaf local-address {
                     type inet:ip-address;
                     description
                       "Локальный адрес IP для PIM RP. Обычно 
                        соответствует Router ID или основному адресу.";
                   }
                   leaf-list rp-set-address {
                     type inet:ip-address;
                     description
                       "Адрес IP набора маршрутизаторов RP.";
                   }
                 }
               }
               leaf rp-address {
                 when "../provider-managed/enabled = 'false'" {
                   description
                     "Применяется для RP, не управляемой провайдером.";
                 }
                 type inet:ip-address;
                 mandatory true;
                 description
                   "Адрес RP, управляемой клиентом.";
               }
               container groups {
                 description
                   "Multicast-группы, связанные с RP.";
                 list group {
                   key "id";
                   description
                     "Список multicast-групп.";
                   leaf id {
                     type uint16;
                     description
                       "Идентификатор группы.";
                   }
                   choice group-format {
                     mandatory true;
                     description
                       "Выбор формата multicast-группы.";
                     case group-prefix {
                       leaf group-address {
                         type inet:ip-prefix;
                         description
                           "Один префикс multicast-группы.";
                       }
                     }
                     case startend {
                       leaf group-start {
                         type inet:ip-address;
                         description
                           "Первый адрес в диапазоне адресов
                            multicast-группы.";
                       }
                       leaf group-end {
                         type inet:ip-address;
                         description
                           "Последний адрес в диапазоне адресов
                            multicast-группы.";
                       }
                     }
                   }
                 }
               }
             }
           }
           container rp-discovery {
             description
               "Параметры обнаружения RP.";
             leaf rp-discovery-type {
               type identityref {
                 base vpn-common:multicast-rp-discovery-type;
               }
               default "vpn-common:static-rp";
               description
                 "Используемый тип обнаружения RP.";
             }
             container bsr-candidates {
               when "derived-from-or-self(../rp-discovery-type, "
                  + "'vpn-common:bsr-rp')" {
                 description
                   "Применяется лишь при обнаружении типа bsr-rp.";
               }
               description
                 "Контейнер для адресов кандидатов в BSR (Bootstrap
                  Router — маршрутизатор начальной загрузки) клиента.";
               leaf-list bsr-candidate-address {
                 type inet:ip-address;
                 description
                   "Адрес кандидата в BSR.";
               }
             }
           }
         }
         container igmp {
           if-feature "vpn-common:igmp and vpn-common:ipv4";
           description
             "Параметры, связанные с IGMP.";
           list static-group {
             key "group-addr";
             description
               "Статический источник/группа, связанный с сессией IGMP.";
             leaf group-addr {
               type rt-types:ipv4-multicast-group-address;
               description
                 "Адрес IPv4 для группы.";
             }
             leaf source-addr {
               type rt-types:ipv4-multicast-source-address;
               description
                 "Адрес отправителя IPv4 для группы.";
             }
           }
           leaf max-groups {
             type uint32;
             description
               "Максимальное число групп.";
           }
           leaf max-entries {
             type uint32;
             description
               "Максимальное число записей IGMP.";
           }
           leaf version {
             type identityref {
               base vpn-common:igmp-version;
             }
             default "vpn-common:igmpv2";
             description
               "Версия IGMP.";
             reference
               "RFC 1112: Host Extensions for IP Multicasting
                RFC 2236: Internet Group Management Protocol,
                          Version 2
                RFC 3376: Internet Group Management Protocol,
                          Version 3";
           }
         }
         container mld {
           if-feature "vpn-common:mld and vpn-common:ipv6";
           description
             "Связанные с MLD параметры.";
           list static-group {
             key "group-addr";
             description
               "Статический источник/группа, связанный с сессией MLD.";
             leaf group-addr {
               type rt-types:ipv6-multicast-group-address;
               description
                 "Адрес IPv6 для группы.";
             }
             leaf source-addr {
               type rt-types:ipv6-multicast-source-address;
               description
                 "Адрес источника IPv6 для группы.";
             }
           }
           leaf max-groups {
             type uint32;
             description
               "Максимальное число групп.";
           }
           leaf max-entries {
             type uint32;
             description
               "Максимальное число записей MLD.";
           }
           leaf version {
             type identityref {
               base vpn-common:mld-version;
             }
             default "vpn-common:mldv2";
             description
               "Версия протокола MLD.";
             reference
               "RFC 2710: Multicast Listener Discovery (MLD) for IPv6
                RFC 3810: Multicast Listener Discovery Version 2
                          (MLDv2) for IPv6";
           }
         }
         container pim {
           if-feature "vpn-common:pim";
           description
             "Применимо лишь с типом протокола pim.";
           leaf hello-interval {
             type rt-types:timer-value-seconds16;
             default "30";
             description
               "Интервал между сообщениями PIM Hello При infinity или
                not-set периодические сообщения Hello не передаются.";
             reference
               "RFC 7761: Protocol Independent Multicast - Sparse
                          Mode (PIM-SM): Protocol Specification
                          (Revised), Section 4.11
                RFC 8294: Common YANG Data Types for the Routing
                          Area";
           }
           leaf dr-priority {
             type uint32;
             default "1";
             description
               "Предпочтение при выборе назначенного маршрутизатора
                (Designated Router или DR). Большее значение указывает
                более высокий приоритет.";
             reference
               "RFC 7761: Protocol Independent Multicast - Sparse
                          Mode (PIM-SM): Protocol Specification
                          (Revised), Section 4.3.2";
           }
         }
       }
     }

     /* Основные блоки */
     /* l3vpn-ntw */

     container l3vpn-ntw {
       description
         "Основной контейнер для управления службами L3VPN.";
       container vpn-profiles {
         description
           "Набор профилей VPN, пригодных для указания в службе VPN.";
         uses vpn-common:vpn-profile-cfg;
       }
       container vpn-services {
         description
           "Контейнер для услуг VPN.";
         list vpn-service {
           key "vpn-id";
           description
             "List of VPN services.";
           uses vpn-common:vpn-description;
           leaf parent-service-id {
             type vpn-common:vpn-id;
             description
               "Указатель на родительскую службу, если она есть. Это
                может быть L3SM, запрос среза (slice), VPN+ и т. п.";
           }
           leaf vpn-type {
             type identityref {
               base vpn-common:service-type;
             }
             description
               "Указывает тип службы.";
           }
           leaf vpn-service-topology {
             type identityref {
               base vpn-common:vpn-topology;
             }
             default "vpn-common:any-to-any";
             description
               "Топология службы VPN.";
           }
           uses vpn-common:service-status;
           container vpn-instance-profiles {
             description
               "Контейнер для списка профилей экземпляров VPN.";
             list vpn-instance-profile {
               key "profile-id";
               description
                 "Список профилей экземпляров VPN.";
               leaf profile-id {
                 type string;
                 description
                   "Идентификатор профиля экземпляра VPN.";
               }
               leaf role {
                 type identityref {
                   base vpn-common:role;
                 }
                 default "vpn-common:any-to-any-role";
                 description
                   "Роль узла VPN в сети VPN.";
               }
               uses vpn-instance-profile;
             }
           }
           container underlay-transport {
             description
               "Контейнер для базового транспорта.";
             uses vpn-common:underlay-transport;
           }
           container external-connectivity {
             if-feature "vpn-common:external-connectivity";
             description
               "Контейнер для внешних соединений.";
             choice profile {
               description
                 "Выбор профиля для внешних соединений.";
               case profile {
                 leaf profile-name {
                   type leafref {
                     path "/l3vpn-ntw/vpn-profiles"
                        + "/valid-provider-identifiers"
                        + "/external-connectivity-identifier/id";
                   }
                   description
                     "Имя профиля от провайдера для применения на
                      уровне службы VPN.";
                 }
               }
             }
           }
           container vpn-nodes {
             description
               "Контейнер для узлов VPN.";
             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 local-as {
                 if-feature "vpn-common:rtg-bgp";
                 type inet:as-number;
                 description
                   "Номер AS у провайдера, применяемый, если клиенту
                    нужна маршрутизация BGP.";
               }
               leaf router-id {
                 type rt-types:router-id;
                 description
                   "32-битовое значение с разделением точками, служащее
                    для указания узла внутри AS. Применяется для
                    IPv4 и IPv6.";
               }
               container active-vpn-instance-profiles {
                 description
                   "Контейнер для активных профилей экземпляров VPN.";
                 list vpn-instance-profile {
                   key "profile-id";
                   description
                     "Список активных профилей экземпляров VPN.";
                   leaf profile-id {
                     type leafref {
                       path "/l3vpn-ntw/vpn-services/vpn-service"
                          + "/vpn-instance-profiles"
                          + "/vpn-instance-profile/profile-id";
                     }
                     description
                       "Активный профиль экземпляра VPN для узла.";
                   }
                   list router-id {
                     key "address-family";
                     description
                       "Router ID по семействам адресов.";
                     leaf address-family {
                       type identityref {
                         base vpn-common:address-family;
                       }
                       description
                         "Семейство адресов, к которому относится 
                          Router ID.";
                     }
                     leaf router-id {
                       type inet:ip-address;
                       description
                         "В качестве router-id может служить адрес IPv4
                          или IPv6. Это может применяться, например, для
                          настройки адреса IPv6 как Router ID, когда 
                          такая возможность поддерживается базовыми
                          маршрутизаторами. В таком случае настроенное
                          значение переопределяет базовое, заданное на
                          уровне узла VPN.";
                     }
                   }
                   uses vpn-instance-profile;
                 }
               }
               container msdp {
                 if-feature "msdp";
                 description
                   "Параметры, относящиеся к MSDP.";
                 leaf peer {
                   type inet:ipv4-address;
                   description
                     "Адрес IPv4 партнёра MSDP.";
                 }
                 leaf local-address {
                   type inet:ipv4-address;
                   description
                     "Локальный адрес IPv4, который должен настраиваться
                      на узле.";
                 }
                 uses vpn-common:service-status;
               }
               uses vpn-common:vpn-components-group;
               uses vpn-common:service-status;
               container vpn-network-accesses {
                 description
                   "Список доступов в сеть.";
                 list vpn-network-access {
                   key "id";
                   description
                     "Список доступов в сеть.";
                   leaf id {
                     type vpn-common:vpn-id;
                     description
                       "Идентификатор доступа в сеть.";
                   }
                   leaf interface-id {
                     type string;
                     description
                       "Идентификатор физического или логического
                        интерфейса. Идентификация субинтерфейсов
                        обеспечивается на уровне соединения и
                        соединения IP.";
                   }
                   leaf description {
                     type string;
                     description
                       "Текстовое описание доступа в сеть.";
                   }
                   leaf vpn-network-access-type {
                     type identityref {
                       base vpn-common:site-network-access-type;
                     }
                     default "vpn-common:point-to-point";
                     description
                       "Тип соединения, например point to point.";
                   }
                   leaf vpn-instance-profile {
                     type leafref {
                       path "/l3vpn-ntw/vpn-services/vpn-service"
                          + "/vpn-nodes/vpn-node"
                          + "/active-vpn-instance-profiles"
                          + "/vpn-instance-profile/profile-id";
                     }
                     description
                       "Идентификатор активного профиля экземпляра VPN";
                   }
                   uses vpn-common:service-status;
                   container connection {
                     description
                       "Протоколы и параметры L2, требуемые для связи
                        между PE и CE.";
                     container encapsulation {
                       description
                         "Контейнер для инкапсуляции L2.";
                       leaf type {
                         type identityref {
                           base vpn-common:encapsulation-type;
                         }
                         default "vpn-common:priority-tagged";
                         description
                           "Тип инкапсуляции. Для интерфейса с тегами
                            по умолчанию применяется priority-tagged.";
                       }
                       container dot1q {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:dot1q')" {
                           description
                             "Применяется лишь к интерфейсам с тегами
                              dot1q.";
                         }
                         description
                           "Tagged interface.";
                         leaf tag-type {
                           type identityref {
                             base vpn-common:tag-type;
                           }
                           default "vpn-common:c-vlan";
                           description
                             "Тип тега. По умолчанию c-vlan.";
                         }
                         leaf cvlan-id {
                           type uint16 {
                             range "1..4094";
                           }
                           description
                             "Идентификатор VLAN.";
                         }
                       }
                       container priority-tagged {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:priority-tagged')" {
                           description
                             "Применяется только с теговыми интерфейсами
                              типа priority-tagged.";
                         }
                         description
                           "Priority tagged.";
                         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(../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
                             "Тип тега.";
                         }
                         leaf svlan-id {
                           type uint16;
                           mandatory true;
                           description
                             "Идентификатор Service VLAN (S-VLAN).";
                         }
                         leaf cvlan-id {
                           type uint16;
                           mandatory true;
                           description
                             "Идентификатор Customer VLAN (C-VLAN).";
                         }
                       }
                     }
                     choice l2-service {
                       description
                         "Услуга связности L2 может быть предоставлена
                          указателем на L2VPN или заданием туннеля L2.";
                       container l2-tunnel-service {
                         description
                           "Определяет завершение туннеля L2. Применимо 
                            лишь при необходимости туннеля. Возможны
                            значения pseudowire, vpls, vxlan. При 
                            необходимости можно задать иные значения.";
                         leaf type {
                           type identityref {
                             base l2-tunnel-type;
                           }
                           description
                             "Вариант завершение туннеля для каждого
                              доступа в сеть VPN.";
                         }
                         container pseudowire {
                           when "derived-from-or-self(../type, "
                              + "'pseudowire')" {
                             description
                               "Применимо лишь к сервису L2 pseudowire";
                           }
                           description
                             "Параметры завершения псевдопровода.";
                           leaf vcid {
                             type uint32;
                             description
                               "Идентификатор псевдопровода (PW) или
                                виртуального устройства (VC).";
                           }
                           leaf far-end {
                             type union {
                               type uint32;
                               type inet:ip-address;
                             }
                             description
                               "Указание соседа.";
                             reference
                               "RFC 8077: Pseudowire Setup and
                                          Maintenance Using the Label
                                          Distribution Protocol
                                          (LDP), Section 6.1";
                           }
                         }
                         container vpls {
                           when "derived-from-or-self(../type, "
                              + "'vpls')" {
                             description
                               "Применимо лишь для сервиса L2 vpls.";
                           }
                           description
                             "Параметры завершения VPLS.";
                           leaf vcid {
                             type uint32;
                             description
                               "VC identifier.";
                           }
                           leaf-list far-end {
                             type union {
                               type uint32;
                               type inet:ip-address;
                             }
                             description
                               "Указание соседа.";
                           }
                         }
                         container vxlan {
                           when "derived-from-or-self(../type, "
                              + "'vxlan')" {
                             description
                               "Применимо лишь для сервиса L2 vxlan.";
                           }
                           description
                             "Параметры завершения VXLAN.";
                           leaf vni-id {
                             type uint32;
                             mandatory true;
                             description
                               "Идентификатор сети VXLAN (VNI).";
                           }
                           leaf peer-mode {
                             type identityref {
                               base vpn-common:vxlan-peer-mode;
                             }
                             default "vpn-common:static-mode";
                             description
                               "Режим доступа VXLAN. По умолчанию принят
                                партнёрский режим static-mode.";
                           }
                           leaf-list peer-ip-address {
                             type inet:ip-address;
                             description
                               "Список IP-адресов партнёра.";
                           }
                         }
                       }
                       case l2vpn {
                         leaf l2vpn-id {
                           type vpn-common:vpn-id;
                           description
                             "Служба L2VPN, связанная с интегрированным 
                              интерфейсом моста и маршрутизации (IRB).";
                         }
                       }
                     }
                     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 lag-interface {
                       if-feature "vpn-common:lag-interface";
                       description
                         "Контейнер для настройки атрибутов интерфейса 
                          объединения каналов (LAG).";
                       leaf lag-interface-id {
                         type string;
                         description
                           "Идентификатор интерфейса LAG.";
                       }
                       container member-link-list {
                         description
                           "Контейнер для элементов группы каналов.";
                         list member-link {
                           key "name";
                           description
                             "Канал из группы.";
                           leaf name {
                             type string;
                             description
                               "Имя канала из группы.";
                           }
                         }
                       }
                     }
                   }
                   container ip-connection {
                     description
                       "Параметры соединения IP.";
                     leaf l3-termination-point {
                       type string;
                       description
                         "Ссылка на локальную точку завершения L3, такую
                          как интерфейс домена мостов.";
                     }
                     container ipv4 {
                       if-feature "vpn-common:ipv4";
                       description
                         "Параметры, связанные с IPv4.";
                       leaf local-address {
                         type inet:ipv4-address;
                         description
                           "Адрес IP на интерфейсе провайдера.";
                       }
                       leaf prefix-length {
                         type uint8 {
                           range "0..32";
                         }
                         description
                           "Размер префикса подсети в битах, применяемый 
                            для локального и клиентского адреса.";
                       }
                       leaf address-allocation-type {
                         type identityref {
                           base address-allocation-type;
                         }
                         must "not(derived-from-or-self(current(), "
                            + "'slaac') or "
                            + "derived-from-or-self(current(), "
                            + "'provider-dhcp-slaac'))" {
                           error-message "SLAAC is only applicable "
                                       + "to IPv6.";
                         }
                         description
                           "Задаёт выделение адресов для сайта партнёра.
                            Если тип выделения не указан, адресация IPv4
                            не поддерживается.";
                       }
                       choice allocation-type {
                         description
                           "Выбор типа выделения адресов IPv4.";
                         case provider-dhcp {
                           description
                             "Параметры для адресов, полученных по DHCP,
                              предоставляемому оператором.";
                           leaf dhcp-service-type {
                             type enumeration {
                               enum server {
                                 description
                                   "Локальный сервер DHCP.";
                               }
                               enum relay {
                                 description
                                   "Локальный ретранслятор DHCP. Запросы
                                    передаются серверу провайдера.";
                               }
                             }
                             description
                               "Тип службы DHCP для этого доступа.";
                           }
                           choice service-type {
                             description
                               "Выбор по типу услуги DHCP.";
                             case relay {
                               description
                                 "Контейнер для списка серверов DHCP у
                                  провайдера (для dhcp-service-type
                                  relay).";
                               leaf-list server-ip-address {
                                 type inet:ipv4-address;
                                 description
                                   "Адрес IPv4 сервера DHCP у провайдера
                                    для использования локальным 
                                    ретранслятором DHCP.";
                               }
                             }
                             case server {
                               description
                                 "Выбор для назначения адресов когда
                                  разрешён локальный сервер DHCP.";
                               choice address-assign {
                                 default "number";
                                 description
                                   "Выбор способа назначения адресов 
                                    IPv4.";
                                 case number {
                                   leaf number-of-dynamic-address {
                                     type uint16;
                                     default "1";
                                     description
                                       "Число адресов IP, выделяемых
                                        клиенту для этого доступа.";
                                   }
                                 }
                                 case explicit {
                                   container customer-addresses {
                                     description
                                       "Контейнер для адресов клиента,
                                        назначаемых сервером DHCP.";
                                     list address-pool {
                                       key "pool-id";
                                       description
                                         "Описание адресов IP, 
                                          назначаемых DHCP.

                                          При наличии лишь start-address
                                          выделяется только один адрес.

                                          Когда заданы start-address и
                                          end-address выделяется весь
                                          диапазон вместе с границами.";
                                       leaf pool-id {
                                         type string;
                                         description
                                           "Идентификатор пула адресов 
                                            от start-address до
                                            end-address, включительно.";
                                       }
                                       leaf start-address {
                                         type inet:ipv4-address;
                                         mandatory true;
                                         description
                                           "Первый адрес пула.";
                                       }
                                       leaf end-address {
                                         type inet:ipv4-address;
                                         description
                                           "Последний адрес пула.";
                                       }
                                     }
                                   }
                                 }
                               }
                             }
                           }
                         }
                         case dhcp-relay {
                           description
                             "Ретранслятор DHCP от оператора";
                           container customer-dhcp-servers {
                             description
                               "Контейнер для списка клиентских
                                серверов DHCP.";
                             leaf-list server-ip-address {
                               type inet:ipv4-address;
                               description
                                 "Адрес IPv4 клиентского сервера DHCP.";
                             }
                           }
                         }
                         case static-addresses {
                           description
                             "Списки используемых адресов IPv4.";
                           leaf primary-address {
                             type leafref {
                               path "../address/address-id";
                             }
                             description
                               "Основной адрес соединения.";
                           }
                           list address {
                             key "address-id";
                             description
                               "Списки используемых адресов IPv4.";
                             leaf address-id {
                               type string;
                               description
                                 "Идентификатор статического адреса
                                  IPv4.";
                             }
                             leaf customer-address {
                               type inet:ipv4-address;
                               description
                                 "Адрес IPv4 на стороне клиента.";
                             }
                           }
                         }
                       }
                     }
                     container ipv6 {
                       if-feature "vpn-common:ipv6";
                       description
                         "Параметры, связанные с IPv6.";
                       leaf local-address {
                         type inet:ipv6-address;
                         description
                           "Адрес IPv6 на стороне провайдера.";
                       }
                       leaf prefix-length {
                         type uint8 {
                           range "0..128";
                         }
                         description
                           "Размер префикса подсети в битах для 
                            локальных и клиентских адресов.";
                       }
                       leaf address-allocation-type {
                         type identityref {
                           base address-allocation-type;
                         }
                         description
                           "Задаёт способ назначения адресов. Если
                            тип не задан, адреса IPv6 не выделяются.";
                       }
                       choice allocation-type {
                         description
                           "Выбор по типу назначения адресов IPv6.";
                         container provider-dhcp {
                           when "derived-from-or-self(../address-allo"
                              + "cation-type, 'provider-dhcp') or "
                              + "derived-from-or-self(../address-allo"
                              + "cation-type, 'provider-dhcp-slaac')" {
                             description
                               "Применимо лишь при назначении адресов
                                DHCPv6, обеспечиваемом оператором.";
                           }
                           description
                             "Параметры, относящиеся к адресам от DHCP";
                           leaf dhcp-service-type {
                             type enumeration {
                               enum server {
                                 description
                                   "Локальный сервер DHCPv6.";
                               }
                               enum relay {
                                 description
                                   "Ретранслятор DHCPv6.";
                               }
                             }
                             description
                               "Тип службы DHCPv6, включённой для этого
                                доступа.";
                           }
                           choice service-type {
                             description
                               "Выбор по типу сервиса DHCPv6.";
                             case relay {
                               leaf-list server-ip-address {
                                 type inet:ipv6-address;
                                 description
                                   "Адреса IPv6 провайдерского сервера
                                    DHCPv6.";
                               }
                             }
                             case server {
                               choice address-assign {
                                 default "number";
                                 description
                                   "Выбор назначения префиксов IPv6
                                    сервером DHCPv6.";
                                 case number {
                                   leaf number-of-dynamic-address {
                                     type uint16;
                                     default "1";
                                     description
                                       "Число префиксов IPv6, выделяемых
                                        клиенту для этого доступа.";
                                   }
                                 }
                                 case explicit {
                                   container customer-addresses {
                                     description
                                       "Контейнер для клиентских адресов 
                                        IPv6, выделенных через DHCPv6.";
                                     list address-pool {
                                       key "pool-id";
                                       description
                                         "Описывает адреса IPv6, 
                                          выделенные DHCPv6.

                                          При наличии лишь start-address
                                          выделяется только один адрес.

                                          При указании start-address и 
                                          end-address выделяется 
                                          диапазон адресов с границами.";
                                       leaf pool-id {
                                         type string;
                                         description
                                           "Идентификатор пула для блока
                                            start-address -
                                            end-address.";
                                       }
                                       leaf start-address {
                                         type inet:ipv6-address;
                                         mandatory true;
                                         description
                                           "Первый адрес пула.";
                                       }
                                       leaf end-address {
                                         type inet:ipv6-address;
                                         description
                                           "Последний адрес пула.";
                                       }
                                     }
                                   }
                                 }
                               }
                             }
                           }
                         }
                         case dhcp-relay {
                           description
                             "Ретранслятор DHCPv6 от операторома.";
                           container customer-dhcp-servers {
                             description
                               "Контейнер для списка клиентских
                                серверов DHCP.";
                             leaf-list server-ip-address {
                               type inet:ipv6-address;
                               description
                                 "Адреса IP клиентского сервера
                                  DHCPv6.";
                             }
                           }
                         }
                         case static-addresses {
                           description
                             "Связанные с IPv6 параметры для
                              статического назначения.";
                           leaf primary-address {
                             type leafref {
                               path "../address/address-id";
                             }
                             description
                               "Основной адрес соединения.";
                           }
                           list address {
                             key "address-id";
                             description
                               "Используемые адреса IPv6.";
                             leaf address-id {
                               type string;
                               description
                                 "Идентификатор адреса IPv6.";
                             }
                             leaf customer-address {
                               type inet:ipv6-address;
                               description
                                 "An IPv6 address of the customer
                                  side.";
                             }
                           }
                         }
                       }
                     }
                   }
                   container routing-protocols {
                     description
                       "Задаёт протоколы маршрутизации.";
                     list routing-protocol {
                       key "id";
                       description
                         "Список протоколов маршрутизации на канале
                          CE-PE. Список может дополняться.";
                       leaf id {
                         type string;
                         description
                           "Уникальный идентификатор протокола
                            маршрутизации.";
                       }
                       leaf type {
                         type identityref {
                           base vpn-common:routing-protocol-type;
                         }
                         description
                           "Тип протокола маршрутизации.";
                       }
                       list routing-profiles {
                         key "id";
                         description
                           "Профили маршрутизации.";
                         leaf id {
                           type leafref {
                             path "/l3vpn-ntw/vpn-profiles"
                                + "/valid-provider-identifiers"
                                + "/routing-profile-identifier/id";
                           }
                           description
                             "Профиль маршрутизации для применения.";
                         }
                         leaf type {
                           type identityref {
                             base vpn-common:ie-type;
                           }
                           description
                             "Импорт, экспорт или оба.";
                         }
                       }
                       container static {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:static-routing')" {
                           description
                             "Применимо лишь для статической
                              маршрутизации.";
                         }
                         description
                           "Настройка статической маршрутизации.";
                            routing.";
                         container cascaded-lan-prefixes {
                           description
                             "Префиксы ЛВС от клиента.";
                           list ipv4-lan-prefixes {
                             if-feature "vpn-common:ipv4";
                             key "lan next-hop";
                             description
                               "Список префиксов ЛВС для сайта.";
                             leaf lan {
                               type inet:ipv4-prefix;
                               description
                                 "Префиксы ЛВС.";
                             }
                             leaf lan-tag {
                               type string;
                               description
                                 "Внутренний тег, применяемый политикой 
                                  VPN.";
                             }
                             leaf next-hop {
                               type union {
                                 type inet:ip-address;
                                 type predefined-next-hop;
                               }
                               description
                                 "Значение next hop для статического
                                  маршрута - адрес IP или 
                                  предопределённый тип next-hop
                                  например, discard или local-link).";
                             }
                             leaf bfd-enable {
                               if-feature "vpn-common:bfd";
                               type boolean;
                               description
                                 "Управляет включением BFD.";
                             }
                             leaf metric {
                               type uint32;
                               description
                                 "Указывает метрику, связанную со
                                  статическим маршрутом.";
                             }
                             leaf preference {
                               type uint32;
                               description
                                 "Указывает предпочтение, связанное со
                                  статическим маршрутом.";
                             }
                             uses vpn-common:service-status;
                           }
                           list ipv6-lan-prefixes {
                             if-feature "vpn-common:ipv6";
                             key "lan next-hop";
                             description
                               "Список префиксов ЛВС для сайта.";
                             leaf lan {
                               type inet:ipv6-prefix;
                               description
                                 "Префиксы ЛВС.";
                             }
                             leaf lan-tag {
                               type string;
                               description
                                 "Внутренний тег для правил VPN.";
                             }
                             leaf next-hop {
                               type union {
                                 type inet:ip-address;
                                 type predefined-next-hop;
                               }
                               description
                                 "Значение next hop для статического
                                  маршрута - адрес IP или 
                                  предопределённый тип next-hop
                                  например, discard или local-link).";
                             }
                             leaf bfd-enable {
                               if-feature "vpn-common:bfd";
                               type boolean;
                               description
                                 "Управляет включением BFD.";
                             }
                             leaf metric {
                               type uint32;
                               description
                                 "Указывает метрику, связанную со
                                  статическим маршрутом.";
                             }
                             leaf preference {
                               type uint32;
                               description
                                 "Указывает предпочтение, связанное со
                                  статическим маршрутом.";
                             }
                             uses vpn-common:service-status;
                           }
                         }
                       }
                       container bgp {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:bgp-routing')" {
                           description
                             "Применимо лишь для протокола BGP.";
                         }
                         description
                           "Конфигурация, связанная с BGP.";
                         leaf description {
                           type string;
                           description
                             "Описание сессии BGP, предназначенное
                              для диагностики. Семантика описания 
                              зависит от реализации.";
                         }
                         leaf local-as {
                           type inet:as-number;
                           description
                             "Локальный номер AS (ASN), если он не
                              совпадает с ASN, заданным на уровне
                              узла VPN.";
                         }
                         leaf peer-as {
                           type inet:as-number;
                           mandatory true;
                           description
                             "ASN клиента, который запрашивает
                              маршрутизацию BGP.";
                         }
                         leaf address-family {
                           type identityref {
                             base vpn-common:address-family;
                           }
                           description
                             "Активируемые семейства адресов. Значение
                              dual-stack активирует IPv4 и IPv6.";
                         }
                         leaf local-address {
                           type union {
                             type inet:ip-address;
                             type if:interface-ref;
                           }
                           description
                             "Локальный адрес IP для использования в
                              транспортной сессии BGP. Это может быть
                              адрес IP или ссылка на интерфейс.";
                         }
                         leaf-list neighbor {
                           type inet:ip-address;
                           description
                             "IP-адреса соседа BGP. Можно указывать
                              IPv4 и IPv6, если будут созданы сессии
                              для IPv4 и IPv6.";
                         }
                         leaf multihop {
                           type uint8;
                           description
                             "Число интервалов пересылки IP (hop),
                              разрешённых между данным соседом BGP
                              и PE.";
                         }
                         leaf as-override {
                           type boolean;
                           default "false";
                           description
                             "Управляет переопределением ASN, т. е. 
                              заменой ASN, заданного в атрибуте AS_PATH
                              от клиента локальным номером ASN.";
                         }
                         leaf allow-own-as {
                           type uint8;
                           default "0";
                           description
                             "Максимальное число включений ASN 
                              провайдера в AS_PATH, при котором атрибут
                              будет отклонен.";
                         }
                         leaf prepend-global-as {
                           type boolean;
                           default "false";
                           description
                             "В некоторых случаях ASN, заданный на 
                              уровне узла VPN может отличаться от ASN,
                              настроенного на уровне доступа в сеть VPN.
                              Когда такие ASN представлены, оба 
                              помещаются в начало обновлений маршрута 
                              BGP для этого доступа. Для запрета такого
                              поведения нужно установить в
                              prepend-global-as значение false и ASN от
                              уровня узла VPN не будет включаться в
                              обновления маршрута BGP.";
                         }
                         leaf send-default-route {
                           type boolean;
                           default "false";
                           description
                             "Управляет анонсированием принятых по
                              умолчанию маршрутов партнеру.";
                         }
                         leaf site-of-origin {
                           when "../address-family = 'vpn-common:ipv4' "
                              + "or 'vpn-common:dual-stack'" {
                             description
                               "Применяется лишь при активном IPv4.";
                           }
                           type rt-types:route-origin;
                           description
                             "Атрибут Site of Origin кодируется как 
                              Route Origin Extended Community. Это
                              служит для однозначного указания набора
                              маршрутов, изученного от сайта через
                              конкретное соединение CE-PE и служащего
                              для предотвращения маршрутных петель.";
                           reference
                             "RFC 4364: BGP/MPLS IP Virtual Private
                                        Networks (VPNs), Section 7";
                         }
                         leaf ipv6-site-of-origin {
                           when "../address-family = 'vpn-common:ipv6' "
                              + "or 'vpn-common:dual-stack'" {
                             description
                               "Применяется лишь при активном IPv6.";
                           }
                           type rt-types:ipv6-route-origin;
                           description
                             "Атрибут IPv6 Site of Origin кодируется как 
                              IPv6 Route Origin Extended Community. Это
                              однозначно указывает набор маршрутов, 
                              изученный с сайта через сведения VRF.";
                           reference
                             "RFC 5701: IPv6 Address Specific BGP
                                        Extended Community
                                        Attribute";
                         }
                         list redistribute-connected {
                           key "address-family";
                           description
                             "Указывает правила (по семействам адресов) 
                              для подключённых маршрутов.";
                           leaf address-family {
                             type identityref {
                               base vpn-common:address-family;
                             }
                             description
                               "Семейство адресов.";
                           }
                           leaf enable {
                             type boolean;
                             description
                               "Разрешает распространение подключённых 
                                маршрутов.";
                           }
                         }
                         container bgp-max-prefix {
                           description
                             "Задаёт поведение при достижении 
                              максимального числа префиксов.";
                           leaf max-prefix {
                             type uint32;
                             default "5000";
                             description
                               "Максимальное число префиксов BGP, 
                                разрешённое в сессии BGP. Это позволяет
                                контролировать число полученных от
                                соседа префиксов. При достижении предела
                                выполняется действие, указанное листом
                                violate-action.";
                             reference
                               "RFC 4271: A Border Gateway Protocol 4
                                          (BGP-4), Section 8.2.2";
                           }
                           leaf warning-threshold {
                             type decimal64 {
                               fraction-digits 5;
                               range "0..100";
                             }
                             units "percent";
                             default "75";
                             description
                               "При превышении порога передаётся 
                                уведомление.";
                           }
                           leaf violate-action {
                             type enumeration {
                               enum warning {
                                 description
                                   "Партнёру передаётся предупреждение";
                               }
                               enum discard-extra-paths {
                                 description
                                   "Избыточные пути отбрасываются.";
                               }
                               enum restart {
                                 description
                                   "Сессия BGP перезапускается после
                                    заданного интервала.";
                               }
                             }
                             description
                               "Если для соседа BGP превышен порог 
                                max-prefix, выполняется действие,
                                указанное violate-action.";
                           }
                           leaf restart-timer {
                             type uint32;
                             units "seconds";
                             description
                               "Интервал времени, после которого сессия 
                                BGP организуется заново.";
                           }
                         }
                         container bgp-timers {
                           description
                             "Два таймера BGP, которые могут быть заданы 
                              при организации услуги VPN с BGP как 
                              протокола маршрутизации CE-PE.";
                           leaf keepalive {
                             type uint16 {
                               range "0..21845";
                             }
                             units "seconds";
                             default "30";
                             description
                               "Интервал передачи сообщений KEEPALIVE
                                между PE и партнёром BGP. Значение 0
                                отключает передачу KEEPALIVE. 
                                Предлагается устанавливать максимальный
                                интервал между KEEPALIVE в 1/3 интервала
                                Hold Time.";
                             reference
                               "RFC 4271: A Border Gateway Protocol 4
                                          (BGP-4), Section 4.4";
                           }
                           leaf hold-time {
                             type uint16 {
                               range "0 | 3..65535";
                             }
                             units "seconds";
                             default "90";
                             description
                               "Максимальное число секунд между приёмом 
                                последовательных сообщений KEEPALIVE и/или
                                UPDATE от партнёра. Время удержания может
                                быть 0 или не меньше 3 секунд.";
                             reference
                               "RFC 4271: A Border Gateway Protocol 4
                                          (BGP-4), Section 4.2";
                           }
                         }
                         container authentication {
                           description
                             "Контейнер для параметров аутентификации 
                              BGP между PE и CE.";
                           leaf enable {
                             type boolean;
                             default "false";
                             description
                               "Управляет применением аутентификации.";
                           }
                           container keying-material {
                             when "../enable = 'true'";
                             description
                               "Контейнер для описания защиты сессии BGP
                                между PE и CE.";
                             choice option {
                               description
                                 "Выбор вариантов аутентификации.";
                               case ao {
                                 description
                                   "Опция TCP-AO.";
                                 reference
                                   "RFC 5925: The TCP Authentication
                                              Option";
                                 leaf enable-ao {
                                   type boolean;
                                   description
                                     "Включение TCP-AO.";
                                 }
                                 leaf ao-keychain {
                                   type key-chain:key-chain-ref;
                                   description
                                     "Ссылка на цепочку ключей TCP-AO.";
                                   reference
                                     "RFC 8177: YANG Data Model for
                                                Key Chains";
                                 }
                               }
                               case md5 {
                                 description
                                   "Применение MD5 для защиты сессии.";
                                 reference
                                   "RFC 4364: BGP/MPLS IP Virtual
                                              Private Networks
                                              (VPNs), Section 13.2";
                                 leaf md5-keychain {
                                   type key-chain:key-chain-ref;
                                   description
                                     "Ссылка на цепочку ключей MD5.";
                                   reference
                                     "RFC 8177: YANG Data Model for
                                                Key Chains";
                                 }
                               }
                               case explicit {
                                 leaf key-id {
                                   type uint32;
                                   description
                                     "Идентификатор ключа.";
                                 }
                                 leaf key {
                                   type string;
                                   description
                                     "Ключ аутентификации BGP. Эта
                                      модель поддерживает лишь ключи,
                                      представимые строками ASCII.";
                                 }
                                 leaf crypto-algorithm {
                                   type identityref {
                                     base key-chain:crypto-algorithm;
                                   }
                                   description
                                     "Криптографический алгоритм, 
                                      связанный с ключом.";
                                 }
                               }
                               case ipsec {
                                 description
                                   "Ссылка на защищённую связь IKE SA.";
                                 leaf sa {
                                   type string;
                                   description
                                     "Заданное администратором имя SA.";
                                 }
                               }
                             }
                           }
                         }
                         uses vpn-common:service-status;
                       }
                       container ospf {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:ospf-routing')" {
                           description
                             "Применимо лишь с протоколом OSPF.";
                         }
                         description
                           "Конфигурация, связанная с OSPF.";
                         leaf address-family {
                           type identityref {
                             base vpn-common:address-family;
                           }
                           description
                             "Указывает активагию IPv4, IPv6 или обоих";
                         }
                         leaf area-id {
                           type yang:dotted-quad;
                           mandatory true;
                           description
                             "Area ID.";
                           reference
                             "RFC 4577: OSPF as the Provider/Customer
                                        Edge Protocol for BGP/MPLS IP
                                        Virtual Private Networks
                                        (VPNs), Section 4.2.3
                              RFC 6565: OSPFv3 as a Provider Edge to
                                        Customer Edge (PE-CE) Routing
                                        Protocol, Section 4.2";
                         }
                         leaf metric {
                           type uint16;
                           default "1";
                           description
                             "Метрика канала PE-CE, применяемая при
                              расчёте состояния маршрутизации и выборе
                              пути.";
                         }
                         container sham-links {
                           if-feature "vpn-common:rtg-ospf-sham-link";
                           description
                             "Список фиктивных (sham) каналов.";
                           reference
                             "RFC 4577: OSPF as the Provider/Customer
                                        Edge Protocol for BGP/MPLS IP
                                        Virtual Private Networks
                                        (VPNs), Section 4.2.7
                              RFC 6565: OSPFv3 as a Provider Edge to
                                        Customer Edge (PE-CE) Routing
                                        Protocol, Section 5";
                           list sham-link {
                             key "target-site";
                             description
                               "Создает sham-канал с другим сайтом.";
                             leaf target-site {
                               type string;
                               description
                                 "Целевой сайт для sham-канала, заданный
                                  идентификатором.";
                             }
                             leaf metric {
                               type uint16;
                               default "1";
                               description
                                 "Метрика sham-канала, применяемая при
                                  расчёте состояния маршрутизации и 
                                  выборе пути. По умолчанию 1.";
                               reference
                                 "RFC 4577: OSPF as the
                                            Provider/Customer Edge
                                            Protocol for BGP/MPLS IP
                                            Virtual Private Networks
                                            (VPNs), Section 4.2.7.3
                                  RFC 6565: OSPFv3 as a Provider Edge
                                            to Customer Edge (PE-CE)
                                            Routing Protocol,
                                            Section 5.2";
                             }
                           }
                         }
                         leaf max-lsa {
                           type uint32 {
                             range "1..4294967294";
                           }
                           description
                             "Максимальное число LSA, воспринимаемых
                              экземпляром OSPF.";
                         }
                         container authentication {
                           description
                             "Настройка аутентификации.";
                           leaf enable {
                             type boolean;
                             default "false";
                             description
                               "Включает и отключает аутентификацию.";
                           }
                           container keying-material {
                             when "../enable = 'true'";
                             description
                               "Контроллер для описания защиты сессии 
                                OSPF между CE и PE.";
                             choice option {
                               description
                                 "Опции аутентификации OSPF.";
                               case auth-key-chain {
                                 leaf key-chain {
                                   type key-chain:key-chain-ref;
                                   description
                                     "Имя цепочки ключей.";
                                 }
                               }
                               case auth-key-explicit {
                                 leaf key-id {
                                   type uint32;
                                   description
                                     "Идентификатор ключа.";
                                 }
                                 leaf key {
                                   type string;
                                   description
                                     "Ключ аутентификации OSPF. Эта
                                      модель поддерживает лишь ключи,
                                      представимые строками ASCII.";
                                 }
                                 leaf crypto-algorithm {
                                   type identityref {
                                     base key-chain:crypto-algorithm;
                                   }
                                   description
                                     "Криптографический алгоритм,
                                      связанный с ключом.";
                                 }
                               }
                               case ipsec {
                                 leaf sa {
                                   type string;
                                   description
                                     "Заданное администратором имя SA.";
                                   reference
                                     "RFC 4552: Authentication/
                                                Confidentiality for
                                                OSPFv3";
                                 }
                               }
                             }
                           }
                         }
                         uses vpn-common:service-status;
                       }
                       container isis {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:isis-routing')" {
                           description
                             "Применимо лишь для протокола IS-IS.";
                         }
                         description
                           "Конфигурация, связанная с IS-IS.";
                         leaf address-family {
                           type identityref {
                             base vpn-common:address-family;
                           }
                           description
                             "Активация IPv4, IPv6 или обоих.";
                         }
                         leaf area-address {
                           type area-address;
                           mandatory true;
                           description
                             "Адрес области.";
                         }
                         leaf level {
                           type identityref {
                             base vpn-common:isis-level;
                           }
                           description
                             "level-1, level-2, level-1-2.";
                           reference
                             "RFC 9181: A Common YANG Data Model for
                                        Layer 2 and Layer 3 VPNs";
                         }
                         leaf metric {
                           type uint16;
                           default "1";
                           description
                             "Метрика канала PE-CE, применяемая при
                              расчёте состояния маршрутизации и выборе
                              пути.";
                         }
                         leaf mode {
                           type enumeration {
                             enum active {
                               description
                                 "Интерфейс передаёт или принимает
                                  пакеты управления протокола IS-IS.";
                             }
                             enum passive {
                               description
                                 "Отключает передачу обновлений IS-IS
                                  через указанный интерфейс.";
                             }
                           }
                           default "active";
                           description
                             "Тип режима интерфейса IS-IS.";
                         }
                         container authentication {
                           description
                             "Настройка аутентификации.";
                           leaf enable {
                             type boolean;
                             default "false";
                             description
                               "Включает и отключает аутентификацию.";
                           }
                           container keying-material {
                             when "../enable = 'true'";
                             description
                               "Контейнер для описания защиты сессии 
                                IS-IS между CE и PE.";
                             choice option {
                               description
                                 "Опции аутентификации IS-IS.";
                               case auth-key-chain {
                                 leaf key-chain {
                                   type key-chain:key-chain-ref;
                                   description
                                     "Имя цепочки ключей.";
                                 }
                               }
                               case auth-key-explicit {
                                 leaf key-id {
                                   type uint32;
                                   description
                                     "Идентификатор ключа.";
                                 }
                                 leaf key {
                                   type string;
                                   description
                                     "Ключ аутентификации IS-IS. Эта
                                      модель поддерживает лишь ключи,
                                      представимые строками ASCII.";
                                 }
                                 leaf crypto-algorithm {
                                   type identityref {
                                     base key-chain:crypto-algorithm;
                                   }
                                   description
                                     "Криптографический алгоритм,
                                      связанный с ключом.";
                                 }
                               }
                             }
                           }
                         }
                         uses vpn-common:service-status;
                       }
                       container rip {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:rip-routing')" {
                           description
                             "Применимо лишь для протокола RIP. Для IPv4
                              предполагается протокол RIP версии 2.";
                         }
                         description
                           "Конфигурация, связанная с RIP.";
                         leaf address-family {
                           type identityref {
                             base vpn-common:address-family;
                           }
                           description
                             "Активация IPv4, IPv6 или обоих.";
                         }
                         container timers {
                           description
                             "Таймеры RIP.";
                           reference
                             "RFC 2453: RIP Version 2";
                           leaf update-interval {
                             type uint16 {
                               range "1..32767";
                             }
                             units "seconds";
                             default "30";
                             description
                               "Время обновления RIP, т. е. интервал,
                                для которого передаётся обновление RIP";
                           }
                           leaf invalid-interval {
                             type uint16 {
                               range "1..32767";
                             }
                             units "seconds";
                             default "180";
                             description
                               "Интервал, по истечение которого маршрут
                                считается недействительным, если нет
                                обновлений. Это значение по меньшей мере
                                втрое больше update-interval.";
                           }
                           leaf holddown-interval {
                             type uint16 {
                               range "1..32767";
                             }
                             units "seconds";
                             default "180";
                             description
                               "Интервал перед освобождением лучших
                                маршрутов.";
                           }
                           leaf flush-interval {
                             type uint16 {
                               range "1..32767";
                             }
                             units "seconds";
                             default "240";
                             description
                               "Таймер очистки RIP, т. е. время, которое
                                должно пройти, прежде чем маршрут будет
                                удалён из таблицы маршрутизации.";
                           }
                         }
                         leaf default-metric {
                           type uint8 {
                             range "0..16";
                           }
                           default "1";
                           description
                             "Задаёт принятую по умолчанию метрику.";
                         }
                         container authentication {
                           description
                             "Настройка аутентификации.";
                           leaf enable {
                             type boolean;
                             default "false";
                             description
                               "Включает и отключает аутентификацию.";
                           }
                           container keying-material {
                             when "../enable = 'true'";
                             description
                               "Контейнер для описания защиты сессии RIP
                                между CE и PE.";
                             choice option {
                               description
                                 "Задаёт схему аутентификации.";
                               case auth-key-chain {
                                 leaf key-chain {
                                   type key-chain:key-chain-ref;
                                   description
                                     "Имя цепочки ключей.";
                                 }
                               }
                               case auth-key-explicit {
                                 leaf key {
                                   type string;
                                   description
                                     "Ключ аутентификации RIP. Эта
                                      модель поддерживает лишь ключи,
                                      представимые строками ASCII.";
                                 }
                                 leaf crypto-algorithm {
                                   type identityref {
                                     base key-chain:crypto-algorithm;
                                   }
                                   description
                                     "Криптографический алгоритм,
                                      связанный с ключом.";
                                 }
                               }
                             }
                           }
                         }
                         uses vpn-common:service-status;
                       }
                       container vrrp {
                         when "derived-from-or-self(../type, "
                            + "'vpn-common:vrrp-routing')" {
                           description
                             "Применимо лишь для протокола VRRP.";
                         }
                         description
                           "Конфигурация, связанная с VRRP.";
                         reference
                           "RFC 5798: Virtual Router Redundancy
                                      Protocol (VRRP) Version 3 for
                                      IPv4 and IPv6";
                         leaf address-family {
                           type identityref {
                             base vpn-common:address-family;
                           }
                           description
                             "Активация IPv4, IPv6 или обоих.";
                         }
                         leaf vrrp-group {
                           type uint8 {
                             range "1..255";
                           }
                           description
                             "Идентификатор группы VRRP.";
                         }
                         leaf backup-peer {
                           type inet:ip-address;
                           description
                             "IP-адрес партнёра.";
                         }
                         leaf-list virtual-ip-address {
                           type inet:ip-address;
                           description
                             "Виртуальный IP-адрес для одной группы 
                              VRRP.";
                           reference
                             "RFC 5798: Virtual Router Redundancy
                                        Protocol (VRRP) Version 3 for
                                        IPv4 and IPv6,
                                        Sections 1.2 and 1.3";
                         }
                         leaf priority {
                           type uint8 {
                             range "1..254";
                           }
                           default "100";
                           description
                             "Локальный приоритет узла VRRP.";
                         }
                         leaf ping-reply {
                           type boolean;
                           default "false";
                           description
                             "Управляет откликами узла VRRP на ping.";
                         }
                         uses vpn-common:service-status;
                       }
                     }
                   }
                   container oam {
                     description
                       "Задаёт применяемые механизмы OAM. BFD 
                        задан как механизм обнаружения отказов,
                        но в будушем механизмы могут добавляться.";
                     container bfd {
                       if-feature "vpn-common:bfd";
                       description
                         "Контейнер для BFD.";
                       leaf session-type {
                         type identityref {
                           base vpn-common:bfd-session-type;
                         }
                         default "vpn-common:classic-bfd";
                         description
                           "Тип сессии BFD.";
                       }
                       leaf desired-min-tx-interval {
                         type uint32;
                         units "microseconds";
                         default "1000000";
                         description
                           "Минимальный интервал передачи пакетов
                            BFD Control, желаемый для оператора.";
                         reference
                           "RFC 5880: Bidirectional Forwarding
                                      Detection (BFD),
                                      Section 6.8.7";
                       }
                       leaf required-min-rx-interval {
                         type uint32;
                         units "microseconds";
                         default "1000000";
                         description
                           "Минимальный интервал приёма пакетов BFD
                            Control, который следует поддерживать PE.";
                         reference
                           "RFC 5880: Bidirectional Forwarding
                                      Detection (BFD),
                                      Section 6.8.7";
                       }
                       leaf local-multiplier {
                         type uint8 {
                           range "1..255";
                         }
                         default "3";
                         description
                           "Коэффициент обнаружения, передаваемый 
                            партнёру BFD. Интервал обнаружения для
                            принимающего партнёра BFD рассчитывается
                            путём умножения значения согласованного
                            интервала передачи на этот коэффициент.";
                         reference
                           "RFC 5880: Bidirectional Forwarding
                                      Detection (BFD),
                                      Section 6.8.7";
                       }
                       leaf holdtime {
                         type uint32;
                         units "milliseconds";
                         description
                           "Ожидаемое время удержания BFD. Клиент может
                            вносить некие фиксированные значения для
                            периода удержания, если провайдер разрешает
                            ему применять эту функцию. Без разрешения
                            провайдера значения установить нельзя.";
                         reference
                           "RFC 5880: Bidirectional Forwarding
                                      Detection (BFD),
                                      Section 6.8.18";
                       }
                       leaf profile {
                         type leafref {
                           path "/l3vpn-ntw/vpn-profiles"
                              + "/valid-provider-identifiers"
                              + "/bfd-profile-identifier/id";
                         }
                         description
                           "Общеизвестное имя профиля сервис-провайдера.
                            Провайдер может предлагать клиентам
                            некоторые профили в зависимости от желаемого
                            клиентом уровня обслуживания.";
                       }
                       container authentication {
                         presence "Разрешена аутентификация BFD";
                         description
                           "Параметры аутентификации BFD.";
                         leaf key-chain {
                           type key-chain:key-chain-ref;
                           description
                             "Имя цепочки ключей.";
                         }
                         leaf meticulous {
                           type boolean;
                           description
                             "Включает «дотошный» (meticulous) режим.";
                           reference
                             "RFC 5880: Bidirectional Forwarding
                                        Detection (BFD),
                                        Section 6.7";
                         }
                       }
                       uses vpn-common:service-status;
                     }
                   }
                   container security {
                     description
                       "Зависящие от сайта параметры безопасности.";
                     container encryption {
                       if-feature "vpn-common:encryption";
                       description
                         "Контейнер защитного шифрования CE-PE.";
                       leaf enabled {
                         type boolean;
                         default "false";
                         description
                           "Значение true задаёт использование 
                            шифрования, иначе оно отключено.";
                       }
                       leaf layer {
                         when "../enabled = 'true'" {
                           description
                             "Включается лишь при использовании 
                              шифрования.";
                         }
                         type enumeration {
                           enum layer2 {
                             description
                               "Шифрование происходит на уровне L2.";
                           }
                           enum layer3 {
                             description
                               "Шифрование происходит на уровне L3.
                                Например, может применяться IPsec, если
                                клиент запросил шифрование L3.";
                           }
                         }
                         description
                           "Уровень, на котором происходит шифрование.";
                       }
                     }
                     container encryption-profile {
                       when "../encryption/enabled = 'true'" {
                         description
                           "Уровень, где включено шифрование.";
                       }
                       description
                         "Контейнер для проифля шифрования.";
                       choice profile {
                         description
                           "Выбор профиля шифрования.";
                         case provider-profile {
                           leaf profile-name {
                             type leafref {
                               path "/l3vpn-ntw/vpn-profiles"
                                  + "/valid-provider-identifiers"
                                  + "/encryption-profile-identifier/id";
                             }
                             description
                               "Имя применяемого профиля от провайдера";
                           }
                         }
                         case customer-profile {
                           leaf customer-key-chain {
                             type key-chain:key-chain-ref;
                             description
                               "Указанная клиентом цепочка ключей.";
                           }
                         }
                       }
                     }
                   }
                   container service {
                     description
                       "Параметры службы для присоединения.";
                     leaf pe-to-ce-bandwidth {
                       if-feature "vpn-common:inbound-bw";
                       type uint64;
                       units "bps";
                       description
                         "Пропускная способность соединения на вход (от
                          SP к сайту) с точки зрения сайта клиента. В
                          L3SM для этого служит input-bandwidth.";
                     }
                     leaf ce-to-pe-bandwidth {
                       if-feature "vpn-common:outbound-bw";
                       type uint64;
                       units "bps";
                       description
                         "Пропускная способность соединения на выход (от
                          сайта клиента к SP) с точки зрения сайта 
                          клиента. В L3SM для этого служит
                          output-bandwidth.";
                     }
                     leaf mtu {
                       type uint32;
                       units "bytes";
                       description
                         "MTU на уровне службы. Для сервиса IP это будет
                          IP MTU. Если включён режим «оператор для
                          операторов» (CsC), запрашиваемое значение MTU
                          будет указывать максимальный размер пакета с
                          меткой MPLS, а не IP MTU.";
                     }
                     container qos {
                       if-feature "vpn-common:qos";
                       description
                         "Конфигурация QoS.";
                       container qos-classification-policy {
                         description
                           "Конфигурация правил классификации трафика.";
                         uses vpn-common:qos-classification-policy;
                       }
                       container qos-action {
                         description
                           "Список действий для правил QoS.";
                         list rule {
                           key "id";
                           description
                             "Список действий QoS.";
                           leaf id {
                             type string;
                             description
                               "Идентификатор правила для действия QoS";
                           }
                           leaf target-class-id {
                             type string;
                             description
                               "Указание класса обслуживания (внутреннее
                                значение для администратора).";
                           }
                           leaf inbound-rate-limit {
                             type decimal64 {
                               fraction-digits 5;
                               range "0..100";
                             }
                             units "percent";
                             description
                               "Задаёт условия и способ ограничения 
                                скорости входящего трафика для правила
                                QoS. Указывается в процентах от значения
                                input-bandwidth.";
                           }
                           leaf outbound-rate-limit {
                             type decimal64 {
                               fraction-digits 5;
                               range "0..100";
                             }
                             units "percent";
                             description
                               "Задаёт условия и способ ограничения 
                                скорости исходящего трафика для правила
                                QoS. Указывается в процентах от значения
                                output-bandwidth.";
                           }
                         }
                       }
                       container qos-profile {
                         description
                           "Конфигурация профиля QoS.";
                         list qos-profile {
                           key "profile";
                           description
                             "Профиль QoS - стандартный или
                              настраиваемый.";
                           leaf profile {
                             type leafref {
                               path "/l3vpn-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 carriers-carrier {
                       if-feature "vpn-common:carriers-carrier";
                       description
                         "Применяется, когда клиент предоставляет
                          услуги на основе MPLS, т. е. в случае CsC
                          (клиент создаёт службы MPLS, используя IP VPN
                          для передачи трафика службы).";
                       leaf signaling-type {
                         type enumeration {
                           enum ldp {
                             description
                               "Использование LDP как сигнального 
                                протокола между PE и CE. Это требует
                                также настройки протокола IGP.";
                           }
                           enum bgp {
                             description
                               "Использование BGP как сигнального
                                протокола между PE и CE. Это требует
                                также настройки BGP как протокола
                                маршрутизации.";
                             reference
                               "RFC 8277: Using BGP to Bind MPLS
                                          Labels to Address
                                          Prefixes";
                           }
                         }
                         default "bgp";
                         description
                           "Тип сигнализации MPLS.";
                       }
                     }
                     container ntp {
                       description
                         "В некоторых VPN (например, инфраструктура и 
                          управление) может потребоваться синхронизация
                          часов. Этот контейнер содержит параметры для
                          включения услуг NTP.";
                       reference
                         "RFC 5905: Network Time Protocol Version 4:
                                    Protocol and Algorithms
                                    Specification";
                       leaf broadcast {
                         type enumeration {
                           enum client {
                             description
                               "Узел VPN будет прослушивать 
                                широковещательные сообщения NTP в этом
                                доступе в сеть VPN.";
                           }
                           enum server {
                             description
                               "Узел VPN будет вести себя как 
                                широковещательный сервер.";
                           }
                         }
                         description
                           "Указывает широковещательный режим NTP для
                            использования в этом доступе в сеть VPN.";
                       }
                       container auth-profile {
                         description
                           "Указатель на локальный профиль.";
                         leaf profile-id {
                           type string;
                           description
                             "Предоставляется указатель на локальный
                              профиль аутентификации на узле VPN.";
                         }
                       }
                       uses vpn-common:service-status;
                     }
                     container multicast {
                       if-feature "vpn-common:multicast";
                       description
                         "Multicast-параметры для доступа в сеть.";
                       leaf access-type {
                         type enumeration {
                           enum receiver-only {
                             description
                               "На партнёрском имеются лишь получатели";
                           }
                           enum source-only {
                             description
                               "На партнёрском имеются лишь источники";
                           }
                           enum source-receiver {
                             description
                               "На партнёрском сайте имеются источники и
                                получатели.";
                           }
                         }
                         default "source-receiver";
                         description
                           "Тип multicast-сайта.";
                       }
                       leaf address-family {
                         type identityref {
                           base vpn-common:address-family;
                         }
                         description
                           "Указывает семейство адресов.";
                       }
                       leaf protocol-type {
                         type enumeration {
                           enum host {
                             description
                               "Хосты напрямую подключены к сети SP.
                                На хостах нужны протоколы, такие как 
                                IGMP или MLD.";
                           }
                           enum router {
                             description
                               "Хосты находятся за маршрутизатором 
                                клиента, будет применяться PIM.";
                           }
                           enum both {
                             description
                               "Часть хостов расположена за клиентским
                                маршрутизатором, другие подключены 
                                напрямую к сети SP. Нужно использовать
                                протоколы для хостов и маршрутизации.
                                Обычно применяются IGMP и PIM.";
                           }
                         }
                         default "both";
                         description
                           "Тип группового протокола для использования с
                            сайтом клиента.";
                       }
                       leaf remote-source {
                         type boolean;
                         default "false";
                         description
                           "Удалённый multicast-источник не находится в
                            одной подсети с доступом в сеть VPN. 
                            Значение true указывает, что групповой 
                            трафик от удалённого источника 
                            воспринимается.";
                       }
                       container igmp {
                         when "../protocol-type = 'host' and "
                            + "../address-family = 'vpn-common:ipv4' "
                            + "or 'vpn-common:dual-stack'";
                         if-feature "vpn-common:igmp";
                         description
                           "Связанные с IGMP параметры.";
                         list static-group {
                           key "group-addr";
                           description
                             "Статические источники/группы, связанные
                              с сессией IGMP.";
                           leaf group-addr {
                             type rt-types:ipv4-multicast-group-address;
                             description
                               "Адрес IPv4 для multicast-группы.";
                           }
                           leaf source-addr {
                             type
                               rt-types:ipv4-multicast-source-address;
                             description
                               "Адрес IPv4 для multicast-источника.";
                           }
                         }
                         leaf max-groups {
                           type uint32;
                           description
                             "Максимальное число групп.";
                         }
                         leaf max-entries {
                           type uint32;
                           description
                             "Максимальное число записей IGMP.";
                         }
                         leaf max-group-sources {
                           type uint32;
                           description
                             "Максимальное число групповых источников.";
                         }
                         leaf version {
                           type identityref {
                             base vpn-common:igmp-version;
                           }
                           default "vpn-common:igmpv2";
                           description
                             "Версия IGMP.";
                         }
                         uses vpn-common:service-status;
                       }
                       container mld {
                         when "../protocol-type = 'host' and "
                            + "../address-family = 'vpn-common:ipv6' "
                            + "or 'vpn-common:dual-stack'";
                         if-feature "vpn-common:mld";
                         description
                           "Параметры, связанные с MLD.";
                         list static-group {
                           key "group-addr";
                           description
                             "Статические источники/группы, связанные
                              с сессией MLD.";
                           leaf group-addr {
                             type rt-types:ipv6-multicast-group-address;
                             description
                               "Адрес IPv6 для multicast-группы.";
                           }
                           leaf source-addr {
                             type
                               rt-types:ipv6-multicast-source-address;
                             description
                               "Адрес IPv6 для multicast-источника.";
                           }
                         }
                         leaf max-groups {
                           type uint32;
                           description
                             "Максимальное число групп.";
                         }
                         leaf max-entries {
                           type uint32;
                           description
                             "Максимальное число записей MLD.";
                         }
                         leaf max-group-sources {
                           type uint32;
                           description
                             "Максимальное число групповых источников.";
                         }
                         leaf version {
                           type identityref {
                             base vpn-common:mld-version;
                           }
                           default "vpn-common:mldv2";
                           description
                             "Версия протокола MLD.";
                         }
                         uses vpn-common:service-status;
                       }
                       container pim {
                         when "../protocol-type = 'router'";
                         if-feature "vpn-common:pim";
                         description
                           "Применимо лишь для протокола pim.";
                         leaf hello-interval {
                           type rt-types:timer-value-seconds16;
                           default "30";
                           description
                             "Интервал между сообщениями PIM Hello.
                              Значение infinity и not-set отменяют
                              передачу периодических сообщений Hello.";
                           reference
                             "RFC 7761: Protocol Independent
                                        Multicast - Sparse Mode
                                        (PIM-SM): Protocol
                                        Specification (Revised),
                                        Section 4.11
                              RFC 8294: Common YANG Data Types for
                                        the Routing Area";
                         }
                         leaf dr-priority {
                           type uint32;
                           default "1";
                           description
                             "Предпочтение, связанное с выбором DR.
                              Большее значение даёт преимущество.";
                           reference
                             "RFC 7761: Protocol Independent
                                        Multicast - Sparse Mode
                                        (PIM-SM): Protocol
                                        Specification (Revised),
                                        Section 4.3.2";
                         }
                         uses vpn-common:service-status;
                       }
                     }
                   }
                 }
               }
             }
           }
         }
       }
     }
   }
   <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.

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

vpn-profiles

vpn-services

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

customer-name и ip-connection

keying-material

Некоторые узлы данных (bgp, ospf, isis, rip, bfd) применяют [RFC8177] для аутентификации, поэтому модуль наследует соображения безопасности, рассмотренные в разделе 5 [RFC8177]. Кроме того, эти узлы данных поддерживают явное представление ключей строками ASCII. Использование шестнадцатеричного формата для ключей позволило бы повысить энтропию при том же числе октетов в строке ключа. Однако такой формат не включён в эту версию L3NM, поскольку не поддерживается базовыми модулями устройств (например, [RFC8695]).

Как отмечено в параграф 7.6.3, модуль поддерживает MD5 для соответствия установленной базе BGP. MD5 имеет множество слабостей, рассмотренных в разделе 2 [RFC6151] и параграфе 2.1 [RFC6952].

В [RFC8633] описан опыт, который следует учитывать в VPN, использующих NTP. Кроме того, механизм криптографической защиты NTP задан в [RFC8915].

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

Агентство IANA зарегистрировало URI в субреесте ns реестра IETF XML Registry [RFC3688]

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

Агентство IANA зарегистрировало модуль YANG в субреестре YANG Module Names [RFC6020] реестра YANG Parameters.

   Name:  ietf-l3vpn-ntw
   Maintained by IANA?  N
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
   Prefix:  l3nm
   Reference:  RFC 9182

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

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

[ISO10589] ISO, «Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)», ISO/IEC 10589:2002, 2002, <https://www.iso.org/standard/30932.html>.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.

[RFC1195] Callon, R., «Use of OSI IS-IS for routing in TCP/IP and dual environments», RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.

[RFC2080] Malkin, G. and R. Minnear, «RIPng for IPv6», RFC 2080, DOI 10.17487/RFC2080, January 1997, <https://www.rfc-editor.org/info/rfc2080>.

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

[RFC2236] Fenner, W., «Internet Group Management Protocol, Version 2», RFC 2236, DOI 10.17487/RFC2236, November 1997, <https://www.rfc-editor.org/info/rfc2236>.

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

[RFC2710] Deering, S., Fenner, W., and B. Haberman, «Multicast Listener Discovery (MLD) for IPv6», RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc-editor.org/info/rfc2710>.

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, «Internet Group Management Protocol, Version 3», RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.

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

[RFC3810] Vida, R., Ed. and L. Costa, Ed., «Multicast Listener Discovery Version 2 (MLDv2) for IPv6», RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4552] Gupta, M. and N. Melam, «Authentication/Confidentiality for OSPFv3», RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.

[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, «OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4577, DOI 10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>.

[RFC5308] Hopps, C., «Routing IPv6 with IS-IS», RFC 5308, DOI 10.17487/RFC5308, October 2008, <https://www.rfc-editor.org/info/rfc5308>.

[RFC5701] Rekhter, Y., «IPv6 Address Specific BGP Extended Community Attribute», RFC 5701, DOI 10.17487/RFC5701, November 2009, <https://www.rfc-editor.org/info/rfc5701>.

[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, «OSPFv2 HMAC-SHA Cryptographic Authentication», RFC 5709, DOI 10.17487/RFC5709, October 2009, <https://www.rfc-editor.org/info/rfc5709>.

[RFC5798] Nadas, S., Ed., «Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6», RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.

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

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

[RFC5925] Touch, J., Mankin, A., and R. Bonica, «The TCP Authentication Option», RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

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

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., «Multicast in MPLS/BGP IP VPNs», RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, «BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs», RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.

[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, «OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol», RFC 6565, DOI 10.17487/RFC6565, June 2012, <https://www.rfc-editor.org/info/rfc6565>.

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

[RFC7166] Bhatia, M., Manral, V., and A. Lindem, «Supporting Authentication Trailer for OSPFv3», RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.

[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., «Security Extension for OSPFv2 When Using Manual Key Management», RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, «Protocol Independent Multicast — Sparse Mode (PIM-SM): Protocol Specification (Revised)», STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.

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

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

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

[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, «YANG Data Model for Key Chains», RFC 8177, DOI 10.17487/RFC8177, June 2017, <https://www.rfc-editor.org/info/rfc8177>.

[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, «Common YANG Data Types for the Routing Area», RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.

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

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

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

[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] 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-12, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-12>.

[Enhanced-VPN-Framework] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, «A Framework for Enhanced Virtual Private Network (VPN+) Services», Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-09, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-09>.

[IEEE802.1AX] IEEE, «802.1AX-2020 — IEEE Standard for Local and Metropolitan Area Networks—Link Aggregation», IEEE Std 802.1AX-2020, <https://ieeexplore.ieee.org/document/9105034>.

[Network-Slices-Framework] Farrel, A., Ed., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, LM., and J. Tantsura, «Framework for IETF Network Slices», Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05>.

[PIM-YANG] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, Y., and F. Hu, «A YANG Data Model for Protocol Independent Multicast (PIM)», Work in Progress⁸, Internet-Draft, draft-ietf-pim-yang-17, 19 May 2018, <https://datatracker.ietf.org/doc/html/draft-ietf-pim-yang-17>.

[PYANG] «pyang», commit 524cf61, December 2021, <https://github.com/mbj4668/pyang>.

[QoS-YANG] Choudhary, A., Jethanandani, M., Aries, E., and I. Chen, «A YANG Data Model for Quality of Service (QoS)», Work in Progress, Internet-Draft, draft-ietf-rtgwg-qos-model-06, 8 November 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-qos-model-06>.

[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., «Multicast Source Discovery Protocol (MSDP)», RFC 3618, DOI 10.17487/RFC3618, October 2003, <https://www.rfc-editor.org/info/rfc3618>.

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

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

[RFC4110] Callon, R. and M. Suzuki, «A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)», RFC 4110, DOI 10.17487/RFC4110, July 2005, <https://www.rfc-editor.org/info/rfc4110>.

[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, «Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management», RFC 4176, DOI 10.17487/RFC4176, October 2005, <https://www.rfc-editor.org/info/rfc4176>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, «Cisco Systems’ Solution for Multicast in BGP/MPLS IP VPNs», RFC 6037, DOI 10.17487/RFC6037, October 2010, <https://www.rfc-editor.org/info/rfc6037>.

[RFC6151] Turner, S. and L. Chen, «Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms», RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.

[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, «Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide», RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>.

[RFC7149] Boucadair, M. and C. Jacquenet, «Software-Defined Networking: A Perspective from within a Service Provider Environment», RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

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

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

[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, «Seamless Bidirectional Forwarding Detection (S-BFD)», RFC 7880, DOI 10.17487/RFC7880, July 2016, <https://www.rfc-editor.org/info/rfc7880>.

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

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

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

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

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

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

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

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

[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, «A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)», RFC 8512, DOI 10.17487/RFC8512, January 2019, <https://www.rfc-editor.org/info/rfc8512>.

[RFC8633] Reilly, D., Stenn, H., and D. Sibold, «Network Time Protocol Best Current Practices», BCP 223, RFC 8633, DOI 10.17487/RFC8633, July 2019, <https://www.rfc-editor.org/info/rfc8633>.

[RFC8695] Liu, X., Sarda, P., and V. Choudhary, «A YANG Data Model for the Routing Information Protocol (RIP)», RFC 8695, DOI 10.17487/RFC8695, February 2020, <https://www.rfc-editor.org/info/rfc8695>.

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

[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, «Network Time Security for the Network Time Protocol», RFC 8915, DOI 10.17487/RFC8915, September 2020, <https://www.rfc-editor.org/info/rfc8915>.

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

[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, «IP Prefix Advertisement in Ethernet VPN (EVPN)», RFC 9136, DOI 10.17487/RFC9136, October 2021, <https://www.rfc-editor.org/info/rfc9136>.

[YANG-Composed-VPN] Even, R., Wu, B., Wu, Q., and Y. Cheng, «YANG Data Model for Composed VPN Service Delivery», Work in Progress, Internet-Draft, draft-evenwu-opsawg-yang-composed-vpn-03, 8 March 2019, <https://datatracker.ietf.org/doc/html/draft-evenwu-opsawg-yang-composed-vpn-03>.

[YANG-SAPs] Gonzalez de Dios, O., Barguil, S., Wu, Q., Boucadair, M., and V. Lopez, «A Network YANG Model for Service Attachment Points», Work in Progress, Internet-Draft, draft-ietf-opsawg-sap-00, 25 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sap-00>.

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

A.1. Предоставление 4G VPN

Сети L3VPN широко применяются для внедрения 3G/4G, стационарных и корпоративных служб главным образом потому, что в сети можно применять разные политики разделения трафика для предоставления мобильным клиентам услуг в соответствии с требованиями SLA.

+-------------+                  +------------------+
|             |                  | PE               |
|             |                  |  198.51.100.1    |
|   eNodeB    |>--------/------->|...........       |
|             |          vlan 1  |          |       |
|             |>--------/------->|......    |       |
|             |          vlan 2  |     |    |       |
|             | Прямая           |  +-------------+ |
+-------------+ маршрутизация    |  | vpn-node-id | |
                                 |  | 44          | |
                                 |  +-------------+ |
                                 |                  |
                                 +------------------+

Рисунок 31. Пример мобильного подключения.

Обычно (Рисунок 31) eNodeB (CE) напрямую подключается к маршрутизаторам доступа транспортной сети, а их логические интерфейсы (1 или несколько в зависимости от типа обслуживания) настраиваются для VPN, доставляющей пакеты в платформы ядра. В этом примере vpn-node создаётся с двумя vpn-network-accesses. Этапы организации службы L3VPN с использованием L3NM описаны ниже.

Сначала создаётся служба 4G VPN (Рисунок 32).

   POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
   Host: example.com
   Content-Type: application/yang-data+json

   {
    "ietf-l3vpn-ntw:vpn-services": {
      "vpn-service": [
        {
          "vpn-id": "4G",
          "vpn-description": "VPN to deploy 4G services",
          "customer-name": "mycustomer",
          "vpn-service-topology": "custom",
          "vpn-instance-profiles": {
            "vpn-instance-profile": [
              {
                "profile-id": "simple-profile",
                "local-as": 65550,
                "rd": "0:65550:1",
                "address-family": [
                  {
                    "address-family": "ietf-vpn-common:dual-stack",
                    "vpn-targets": {
                      "vpn-target": [
                        {
                          "id": 1,
                          "route-targets": [
                            {
                              "route-target": "0:65550:1"
                            }
                          ],
                          "route-target-type": "both"
                        }
                      ]
                    }
                  }
                ]
              }
            ]
          }
        }
      ]
    }
   }

Рисунок 32. Создание службы VPN.

Затем создаётся узел VPN (Рисунок 33). В этом примере узел VPN эквивалентен VRF на физическом устройстве (‘ne-id’=198.51.100.1). Отметим, что символы \ в конце строк на рисунках 33и 34 используются в соответствии с [RFC8792].

   POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
         vpn-services/vpn-service=4G
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-l3vpn-ntw:vpn-nodes": {
       "vpn-node": [
         {
           "vpn-node-id": "44",
           "ne-id": "198.51.100.1",
           "active-vpn-instance-profiles": {
             "vpn-instance-profile": [
               {
                 "profile-id": "simple-profile"
               }
             ]
           }
         }
       ]
     }
   }

Рисунок 33. Создание узла VPN.

Наконец, создаётся два доступа в сеть VPN с использованием одного физического порта (‘interface-id’=1/1/1). В каждом vpn-network-access имеется отдельный интерфейс VLAN (1, 2): SYNC и DATA (Рисунок 34). Эти интерфейсы разделяют трафик.

   POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
         vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
   content-type: application/yang-data+json

   {
     "ietf-l3vpn-ntw:vpn-network-accesses": {
       "vpn-network-access": [
         {
           "id": "1/1/1.1",
           "interface-id": "1/1/1",
           "description": "Интерфейс SYNC для eNODE-B",
           "vpn-network-access-type": "ietf-vpn-common:point-to-point",
           "vpn-instance-profile": "simple-profile",
           "status": {
             "admin-status": {
               "status": "ietf-vpn-common:admin-up"
             }
           },
           "connection": {
             "encapsulation": {
               "type": "ietf-vpn-common:dot1q",
               "dot1q": {
                 "cvlan-id": 1
               }
             }
           },
           "ip-connection": {
             "ipv4": {
               "local-address": "192.0.2.1",
               "prefix-length": 30,
               "address-allocation-type": "static-address",
               "static-addresses": {
                 "primary-address": "1",
                 "address": [
                   {
                     "address-id": "1",
                     "customer-address": "192.0.2.2"
                   }
                 ]
               }
             },
             "ipv6": {
               "local-address": "2001:db8::1",
               "prefix-length": 64,
               "address-allocation-type": "static-address",
               "primary-address": "1",
               "address": [
                 {
                   "address-id": "1",
                   "customer-address": "2001:db8::2"
                 }
               ]
             }
           },
           "routing-protocols": {
             "routing-protocol": [
               {
                 "id": "1",
                 "type": "ietf-vpn-common:direct"
               }
             ]
           }
         },
         {
           "id": "1/1/1.2",
           "interface-id": "1/1/1",
           "description": "Интерфейс DATA для eNODE-B",
           "vpn-network-access-type": "ietf-vpn-common:point-to-point",
           "vpn-instance-profile": "simple-profile",
           "status": {
             "admin-status": {
               "status": "ietf-vpn-common:admin-up"
             }
           },
           "connection": {
             "encapsulation": {
               "type": "ietf-vpn-common:dot1q",
               "dot1q": {
                 "cvlan-id": 2
               }
             }
           },
           "ip-connection": {
             "ipv4": {
               "local-address": "192.0.2.1",
               "prefix-length": 30,
               "address-allocation-type": "static-address",
               "static-addresses": {
                 "primary-address": "1",
                 "address": [
                   {
                     "address-id": "1",
                     "customer-address": "192.0.2.2"
                   }
                 ]
               }
             },
             "ipv6": {
               "local-address": "2001:db8::1",
               "prefix-length": 64,
               "address-allocation-type": "static-address",
               "primary-address": "1",
               "address": [
                 {
                   "address-id": "1",
                   "customer-address": "2001:db8::2"
                 }
               ]
             }
           },
           "routing-protocols": {
             "routing-protocol": [
               {
                 "id": "1",
                 "type": "ietf-vpn-common:direct"
               }
             ]
           }
         }
       ]
     }
   }

Рисунок 34. Создание доступа в сеть VPN.

A.2. Петлевой интерфейс

Пример loopback-интерфейса представлен на рисунке 35.

   {
     "ietf-l3vpn-ntw:vpn-network-accesses": {
       "vpn-network-access": [
         {
           "id": "vpn-access-loopback",
           "interface-id": "Loopback1",
           "description": "Пример loopback-интерфейса.",
           "vpn-network-access-type": "ietf-vpn-common:loopback",
           "status": {
             "admin-status": {
               "status": "ietf-vpn-common:admin-up"
             }
           },
           "ip-connection": {
             "ipv6": {
               "local-address": "2001:db8::4",
               "prefix-length": 128
             }
           }
         }
       ]
     }
   }

Рисунок 35. Доступ в сеть VPN с Loopback-интерфейсом (тело сообщения).

A.3. Переопределение параметров профиля экземпляра VPN

На рисунке 36 показан упрощённый пример предоставления на уровне службы VPN (как часть vpn-instance-profiles) информации, которая может быть переопределена сведениями, заданными на уровне узла VPN. В этом примере PE3 и PE4 наследуют параметры vpn-instance-profiles, заданные на уровне службы VPN, а PE1 и PE2 снабжены значениями maximum-routes на уровне узла VPN, которые переопределяют значения, заданные на уровне службы VPN.

   {
     "ietf-l3vpn-ntw:vpn-services": {
       "vpn-service": [
         {
           "vpn-id": "override-example",
           "vpn-service-topology": "ietf-vpn-common:hub-spoke",
           "vpn-instance-profiles": {
             "vpn-instance-profile": [
               {
                 "profile-id": "HUB",
                 "role": "ietf-vpn-common:hub-role",
                 "local-as": 64510,
                 "rd-suffix": 1001,
                 "address-family": [
                   {
                     "address-family": "ietf-vpn-common:dual-stack",
                     "maximum-routes": [
                       {
                         "protocol": "ietf-vpn-common:any",
                         "maximum-routes": 100
                       }
                     ]
                   }
                 ]
               },
               {
                 "profile-id": "SPOKE",
                 "role": "ietf-vpn-common:spoke-role",
                 "local-as": 64510,
                 "address-family": [
                   {
                     "address-family": "ietf-vpn-common:dual-stack",
                     "maximum-routes": [
                       {
                         "protocol": "ietf-vpn-common:any",
                         "maximum-routes": 1000
                       }
                     ]
                   }
                 ]
               }
             ]
           },
           "vpn-nodes": {
             "vpn-node": [
               {
                 "vpn-node-id": "PE1",
                 "ne-id": "pe1",
                 "router-id": "198.51.100.1",
                 "active-vpn-instance-profiles": {
                   "vpn-instance-profile": [
                     {
                       "profile-id": "HUB",
                       "rd": "1:198.51.100.1:1001",
                       "address-family": [
                         {
                           "address-family":
                                    "ietf-vpn-common:dual-stack",
                           "maximum-routes": [
                             {
                               "protocol": "ietf-vpn-common:any",
                               "maximum-routes": 10
                             }
                           ]
                         }
                       ]
                     }
                   ]
                 }
               },
               {
                 "vpn-node-id": "PE2",
                 "ne-id": "pe2",
                 "router-id": "198.51.100.2",
                 "active-vpn-instance-profiles": {
                   "vpn-instance-profile": [
                     {
                       "profile-id": "SPOKE",
                       "address-family": [
                         {
                           "address-family":
                                    "ietf-vpn-common:dual-stack",
                           "maximum-routes": [
                             {
                               "protocol": "ietf-vpn-common:any",
                               "maximum-routes": 100
                             }
                           ]
                         }
                       ]
                     }
                   ]
                 }
               },
               {
                 "vpn-node-id": "PE3",
                 "ne-id": "pe3",
                 "router-id": "198.51.100.3",
                 "active-vpn-instance-profiles": {
                   "vpn-instance-profile": [
                     {
                       "profile-id": "SPOKE"
                     }
                   ]
                 }
               },
               {
                 "vpn-node-id": "PE4",
                 "ne-id": "pe4",
                 "router-id": "198.51.100.4",
                 "active-vpn-instance-profiles": {
                   "vpn-instance-profile": [
                     {
                       "profile-id": "SPOKE"
                     }
                   ]
                 }
               }
             ]
           }
         }
       ]
     }
   }

Рисунок 36. Пример профиля экземпляра VPN (тело сообщения).

A.4. Пример предоставления Multicast VPN

IPTV является основным применением групповой передачи в ЛВС. В приведённом ниже примере включён разреженный режим PIM (PIM — Sparse Mode или PIM-SM) между PE и CE. PE получает групповой трафик от CE, напрямую соединённого с multicast-источником. Сигнализация между PE и CE обеспечивается с помощью BGP. Для multicast-группы статически задана точка встречи RP.

+-----------+   +------+     +------+    +-----------+
| Multicast-|---|  CE  |--/--|  PE  |----|  Backbone |
| источник  |   +------+     +------+    |   IP/MPLS |
+-----------+                            +-----------+

Рисунок 37. Пример групповой услуги L3VPN.

На рисунке 38 показано, как настроить групповую услугу L3VPN с использованием L3NM.

Сначала создаётся multicast-служба вместе с базовым профилем экземпляра VPN.

   {
     "ietf-l3vpn-ntw:vpn-services": {
       "vpn-service": [
         {
           "vpn-id": "Multicast-IPTV",
           "vpn-description": "Multicast IPTV VPN service",
           "customer-name": "a-name",
           "vpn-service-topology": "ietf-vpn-common:hub-spoke",
           "vpn-instance-profiles": {
             "vpn-instance-profile": [
               {
                 "profile-id": "multicast",
                 "role": "ietf-vpn-common:hub-role",
                 "local-as": 65536,
                 "multicast": {
                   "rp": {
                     "rp-group-mappings": {
                       "rp-group-mapping": [
                         {
                           "id": 1,
                           "rp-address": "203.0.113.17",
                           "groups": {
                             "group": [
                               {
                                 "id": 1,
                                 "group-address": "239.130.0.0/15"
                               }
                             ]
                           }
                         }
                       ]
                     },
                     "rp-discovery": {
                       "rp-discovery-type": "ietf-vpn-common:static-rp"
                     }
                   }
                 }
               }
             ]
           }
         }
       ]
     }
   }

Рисунок 38. Организация групповой службы VPN (без тела запроса).

Затем создаются узлы VPN (Рисунок 39). В этом примере узел VPN представляет VRF, настроенную на физическом устройстве.

   {
     "ietf-l3vpn-ntw:vpn-node": [
       {
         "vpn-node-id": "500003105",
         "description": "VRF-IPTV-MULTICAST",
         "ne-id": "198.51.100.10",
         "router-id": "198.51.100.10",
         "active-vpn-instance-profiles": {
           "vpn-instance-profile": [
             {
               "profile-id": "multicast",
               "rd": "65536:31050202"
             }
           ]
         }
       }
     ]
   }

Рисунок 39. Организация группового узла VPN (без тела запроса).

В заключение создаётся доступ в сеть VPN со включённой групповой передачей (Рисунок 40).

   {
     "ietf-l3vpn-ntw:vpn-network-access": {
       "id": "1/1/1",
       "description": "Connected-to-source",
       "vpn-network-access-type": "ietf-vpn-common:point-to-point",
       "vpn-instance-profile": "multicast",
       "status": {
         "admin-status": {
           "status": "ietf-vpn-common:admin-up"
         },
         "ip-connection": {
           "ipv4": {
             "local-address": "203.0.113.1",
             "prefix-length": 30,
             "address-allocation-type": "static-address",
             "static-addresses": {
               "primary-address": "1",
               "address": [
                 {
                   "address-id": "1",
                   "customer-address": "203.0.113.2"
                 }
               ]
             }
           }
         },
         "routing-protocols": {
           "routing-protocol": [
             {
               "id": "1",
               "type": "ietf-vpn-common:bgp-routing",
               "bgp": {
                 "description": "Connected to CE",
                 "peer-as": "65537",
                 "address-family": "ietf-vpn-common:ipv4",
                 "neighbor": "203.0.113.2"
               }
             }
           ]
         },
         "service": {
           "pe-to-ce-bandwidth": "100000000",
           "ce-to-pe-bandwidth": "100000000",
           "mtu": 1500,
           "multicast": {
             "access-type": "source-only",
             "address-family": "ietf-vpn-common:ipv4",
             "protocol-type": "router",
             "pim": {
               "hello-interval": 30,
               "status": {
                 "admin-status": {
                   "status": "ietf-vpn-common:admin-up"
                 }
               }
             }
           }
         }
       }
     }
   }

Рисунок 40. Организация группового доступа в сеть VPN (без тела запроса).

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

В ходе обсуждения этой работы были получены ценные замечания и рецензии от (в алфавитном порядке) Raul Arco, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg Mirsky, Tom Petch. Спасибо им за это. Спасибо Philip Eardley за обзор черновой версии документа.

Daniel King, Daniel Voyer, Luay Jalil, Stephane Litkowski внесли вклад в ранние версии документа. Большое спасибо Robert Wilton за рецензию AD. Спасибо Andrew Malis за обзор для директората маршрутизации, Rifaat Shekh-Yusef за обзор для директората безопасности, Qin Wu за рецензию opsdir и Pete Resnick за рецензию для директората genart. Спасибо Michael Scharf за обсуждение TCP-AO. Спасибо Martin Duke, Lars Eggert, Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk, Francesca Palombini, Éric Vyncke за рецензии IESG.

Эта работа частично поддерживалась в проекте Европейской комиссии H2020-ICT-2016-2 METRO-HAUL (G.A. 761727) и проекте Horizon 2020 Secured по автономному управления трафиком Tera в потоках SDN (Teraflow) (G.A. 101015857).

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

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                     L. Velvindron
Request for Comments: 9155                                 cyberstorm.mu
Updates: 5246                                                K. Moriarty
Category: Standards Track                                            CIS
ISSN: 2070-1721                                               A. Ghedini
                                                         Cloudflare Inc.
                                                           December 2021

Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2

Отмена хэш-подписей MD5 и SHA-1 в TLS 1.2 и DTLS 1.2

PDF

Аннотация

Алгоритмы MD5 и SHA-1 становятся все более уязвимыми для атак и этот документ отменяет их использование в цифровых подписях TLS 1.2 и DTLS 1.2. Однако документ не отменяет применение SHA-1 в хэшированных кодах аутентификации сообщений (Hashed Message Authentication Code или HMAC) для защиты записей. Данный документ обновляет RFC 5246.

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

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

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

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

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

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

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

1. Введение

Использование MD5 и SHA-1 для хэширования подписей в (D)TLS 1.2 задано в [RFC5246]. За прошедшее время стало ясно, что алгоритмы MD5 и SHA-1 небезопасны и подвержены атакам с конфликтами (collision attack) [Wang]. В 2011 г. в [RFC6151] были подробно рассмотрены вопросы безопасности, включая collision-атаки на MD5. В NIST официально отказались от использования SHA-1 в 2011 г. [NISTSP800-131A-R2] и запретили использование этого алгоритма для цифровых подписей в конце 2013 г., основываясь на описании атак в [Wang] и возможности подбора (brute-force attack). В 2016 г. исследователи из INRIA³ обнаружили новый класс атак на основе конфликтов «расшифровки» (transcript) для протокола TLS (и других) за счёт алгоритма эффективного поиска конфликтов в базовых хэш-конструкциях [Transcript-Collision]. В 2017 г. исследователи из Google и CWI (Centrum Wiskunde & Informatica, Amsterdam) [SHA-1-Collision] доказали практическую осуществимость collision-атак на SHA-1. Этот документ обновляет [RFC5246], указывая недопустимость использования MD5 и SHA-1 в цифровых подписях. Однако документ не отменяет использование SHA-1 с HMAC для защиты записей. Отметим, что CABF (CA/Browser Forum) также отменил SHA-1 в подписях сертификатов [CABF].

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

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

2. Алгоритмы подписи

Клиенты должны включать расширение signature_algorithms и недопустимо включать в него MD5 или SHA-1.

3. Запрос сертификата

Серверам не следует включать MD5 и SHA-1 в сообщения CertificateRequest.

4. Обмен ключами с сервером

Серверам недопустимо включать MD5 и SHA-1 в сообщения ServerKeyExchange. Если клиент получает сообщение ServerKeyExchange, указывающее MD5 или SHA-1, он должен разорвать соединение с сигналом illegal_parameter.

5. Проверка сертификата

Клиентам недопустимо включать MD5 или SHA-1 в сообщения CertificateVerify. Если сервер получает CertificateVerify с или SHA-1, он должен разорвать соединение с сигналом illegal_parameter.

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

Агентство IANA обновило реестр TLS SignatureScheme, заменив рекомендуемый статус схем подписи на основе SHA-1 на N (не рекомендуется), как указано в [RFC8447]. Обновлённые записи указаны в таблице 1.

Таблица 1.

Агентство IANA также обновило ссылки в реестрах TLS SignatureAlgorithm и TLS HashAlgorithm, указав этот документ в дополнение к RFC 5246 и RFC 8447.

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

Современные реализации (D)TLS 1.2 с откатом к SHA-1 создают проблемы. Этот документ обновляет спецификацию TLS 1.2 [RFC5246] для отмены поддержки алгоритмов цифровой подписи MD5 и SHA-1. Однако документ не отменяет применение SHA-1 в HMAC для защиты записей.

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

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

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

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

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

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

[RFC8447] Salowey, J. and S. Turner, «IANA Registry Updates for TLS and DTLS», RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

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

[CABF] CA/Browser Forum, «Ballot 118 — SHA-1 Sunset (passed)», October 2014, <https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/>.

[NISTSP800-131A-R2] Barker, E. and A. Roginsky, «Transitioning the Use of Cryptographic Algorithms and Key Lengths», NIST Special Publication 800-131A, Revision 2, DOI 10.6028/NIST.SP.800-131Ar2, March 2019, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf>.

[RFC6151] Turner, S. and L. Chen, «Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms», RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.

[SHA-1-Collision] Stevens, M., Bursztein, E., Karpman, P., Albertini, A., and Y. Markov, «The First Collision for Full SHA-1», 2017, <https://eprint.iacr.org/2017/190>.

[Transcript-Collision] Bhargavan, K. and G. Leurent, «Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH», DOI 10.14722/ndss.2016.23418, February 2016, <https://hal.inria.fr/hal-01244855/document>.

[Wang] Wang, X., Yin, Y., and H. Yu, «Finding Collisions in the Full SHA-1», DOI 10.1007/11535218_2, 2005, <https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf>.

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

Авторы благодарны Hubert Kario за помощь при подготовке предварительной версии этого документа. Спасибо также Daniel Migault, Martin Thomson, Sean Turner, Christopher Wood, David Cooper за их отклики.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                          A. Clemm
Request for Comments: 9144                                         Y. Qu
Category: Standards Track                                      Futurewei
ISSN: 2070-1721                                              J. Tantsura
                                                               Microsoft
                                                              A. Bierman
                                                               YumaWorks
                                                           December 2021

Comparison of Network Management Datastore Architecture (NMDA) Datastores

Сравнение хранилищ данных управления сетью (NMDA)

PDF

Аннотация

Этот документ определяет операцию удалённого вызова процедуры (Remote Procedure Call или RPC) для сравнения архитектуры хранилища данных управления сетью (Network Management Datastore Architecture или NMDA).

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

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

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

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

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

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

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

1. Введение

При пересмотре архитектуры NMDA [RFC8342] добавлены новые хранилища данных, поддерживающие формат YANG [RFC7950] и предоставляющие различные «точки зрения» (viewpoint) на поддерживаемые сервером данные. Новые хранилища YANG включают раздел <intended>, содержащий проверенные данные конфигурации, которые клиентское приложение планирует ввести в действие, и раздел <operational>, содержащий данные рабочего состояния (такие как статистика), а также реально применяемые данные конфигурации.

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

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

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

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

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

В этом документе вводится модель данных YANG, определяющая RPC, предназначенные для использования с протоколами NETCONF [RFC6241] и RESTCONF [RFC8040]. Эти RPC позволяют клиенту запросить у сервера сравнение двух хранилищ NMDA и отчёт о различиях между ними.

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

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

3. Обзор модели данных

Основой решения является новая операция управления <compare>, сравнивающая содержимое дерева данных в двух хранилищах. Эта операция отыскивает различия в значениях или узлах данных обоих хранилищ и возвращает найденные расхождения. Вывод имеет формат YANG Patch [RFC8072].

Модель данных YANG определяет операцию <compare> как новую процедуру RPC. Входные параметры операции указаны ниже.

source — источник

target — назначение

filter-spec — спецификация фильтра

all — все

report-origin — источник отчёта

Операция представляет на выходе один параметр, описанный ниже.

differences — различия

Модель данных определена в модуле YANG ietf-nmda-compare, структура которого показана ниже, в соответствии с обозначениями из [RFC8340].

   module: ietf-nmda-compare
     rpcs:
       +---x compare
          +---w input
          |  +---w source            identityref
          |  +---w target            identityref
          |  +---w all?              empty
          |  +---w report-origin?    empty
          |  +---w (filter-spec)?
          |     +--:(subtree-filter)
          |     |  +---w subtree-filter?
          |     +--:(xpath-filter)
          |        +---w xpath-filter?     yang:xpath1.0 {nc:xpath}?
          +--ro output
             +--ro (compare-response)?
                +--:(no-matches)
                |  +--ro no-matches?    empty
                +--:(differences)
                   +--ro differences
                      +--ro yang-patch
                         +--ro patch-id    string
                         +--ro comment?    string
                         +--ro edit* [edit-id]
                            +--ro edit-id         string
                            +--ro operation       enumeration
                            +--ro target          target-resource-offset
                            +--ro point?          target-resource-offset
                            +--ro where?          enumeration
                            +--ro value?
                            +--ro source-value?

Рисунок . Структура ietf-nmda-compare.

4. Модель данных YANG

Этот модуль YANG включает ссылки на [RFC6991], [RFC8342], [RFC8072], [RFC6241].

   <CODE BEGINS> file "ietf-nmda-compare@2021-12-10.yang"
   module ietf-nmda-compare {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare";
     prefix cmp;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-datastores {
       prefix ds;
       reference
         "RFC 8342: Network Management Datastore
          Architecture (NMDA)";
     }
     import ietf-yang-patch {
       prefix ypatch;
       reference
         "RFC 8072: YANG Patch Media Type";
     }
     import ietf-netconf {
       prefix nc;
       reference
         "RFC 6241: Network Configuration Protocol (NETCONF)";
     }

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

        Author: Alexander Clemm
                <mailto:ludwig@clemm.org> 

        Author: Yingzhen Qu
                <mailto:yqu@futurewei.com> 

        Author: Jeff Tantsura
                <mailto:jefftant.ietf@gmail.com> 

        Author: Andy Bierman
                <mailto:andy@yumaworks.com>"; 
     description
       "Модель данных YANG определяет новую операцию <compare>, которая
        может применяться для сравнения хранилищ NMDA.

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

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

     revision 2021-12-10 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9144: Comparison of Network Management Datastore
          Architecture (NMDA) Datastores";
     }

     /* RPC */
     rpc compare {
       description
         "Операция сравнения хранилищ данных NMDA.";
       input {
         leaf source {
           type identityref {
             base ds:datastore;
           }
           mandatory true;
           description
             "Хранилище-образец для сравнения.";
         }
         leaf target {
           type identityref {
             base ds:datastore;
           }
           mandatory true;
           description
             "Сравниваемое с образцом хранилище.";
         }
         leaf all {
           type empty;
           description
             "При наличии этого листа сравниваются все узлы данных
              независимо от их присутствия в 1 или обоих хранилищах.
              При отсутствии листа автоматически применяется 
              предопределённый фильтр для исключения узлов данных,
              имеющихся лишь в одном из хранилищ. В частности, если
              одно из хранилищ (source или target) содержит лишь данные
              конфигурации, а другим служит <operational>, узлы данных с 
              config false исключаются из сравнения.";
         }
         leaf report-origin {
           type empty;
           description
             "При наличии этого листа метаданные источника включаются в
              вывод RPC. При отсутствии листа метаданные источника в
              сравнении с участием <operational> опускаются.";
         }
         choice filter-spec {
           description
             "Указывает сравниваемые части хранилища данных.";
           anydata subtree-filter {
             description
               "Указывает искомые части целевого хранилища данных.";
             reference
               "RFC 6241, Section 6.";
           }
           leaf xpath-filter {
             if-feature "nc:xpath";
             type yang:xpath1.0;
             description
               "Выражение XPath, указывающее искомые части целевого
                хранилища.";
             reference
               "RFC 6991: Common YANG Data Types";
           }
         }
       }
       output {
         choice compare-response {
           description
             "Результаты сравнения.";
           leaf no-matches {
             type empty;
             description
               "Указывает, что фильтру не соответствует ничего
                и сравнение не выполняется.";
           }
           container differences {
             description
               "Список различий в формате RFC 8072 с дополнением для
                включения исходных значений, когда это применимо. При
                отсутствии узла хранилища source в хранилище target
                это может быть указано как delete или remove, поскольку
                различий нет из-за отсутствия сравнения.";
             uses ypatch:yang-patch {
               augment "yang-patch/edit" {
                 description
                   "Указывает источник исправления (patch) относительно
                    источника при сравнении в дополнение к значению
                    target, когда это применимо.";
                 anydata source-value {
                   when "../operation = 'delete'"
                      + "or ../operation = 'merge'"
                      + "or ../operation = 'move'"
                      + "or ../operation = 'replace'"
                      + "or ../operation = 'remove'";
                   description
                     "Значение anydata применяется лишь для операций 
                      delete, move, merge, replace, remove.";
                 }
                 reference
                   "RFC 8072: YANG Patch Media Type";
               }
             }
           }
         }
       }
     }
   }
   <CODE ENDS>

5. Пример

Ниже приведён пример сравнения субдерева interfaces в хранилищах <operational> и <intended>. Это субдерево содержит подмножество объектов, заданных в модели данных YANG для управления интерфейсами [RFC8343]. Для понимания приведённого примера ниже приведён фрагмент модели данных, создающий экземпляр, служащий для сравнения.

   container interfaces {
     description
       "Параметры интерфейса.";
     list interface {
       key "name";
       leaf name {
         type string;
         description
           "Имя интерфейса.";
       }
       leaf description {
         type string;
         description
           "Текстовое описание интерфейса.";
       }
       leaf enabled {
         type boolean;
         default "true";
         description
           "Заданное конфигурацией желаемое состояние интерфейса.";
       }
     }
   }

Ниже показано содержимое хранилищ <intended> и <operational> в формате XML [W3C.REC-xml-20081126].

   <!--INTENDED-->
   <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
     <interface>
       <name>eth0</name>
       <enabled>false</enabled>
       <description>ip interface</description>
     </interface>
   </interfaces>

   <!--OPERATIONAL-->
   <interfaces
       xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
     <interface or:origin="or:learned">
       <name>eth0</name>
       <enabled>true</enabled>
     </interface>
   </interfaces>

Хранилище <operational> не включает экземпляр листа description, имеющийся в <intended>, а лист enabled имеет в хранилищах разное значение (true в <operational> и false в <intended>). Лист name в обоих хранилищах совпадает. Источником экземпляров листьев в <operational> указано изучение (learned), что может помочь в понимании причины различия.

RPC запрашивает сравнение <operational> (образец) с <intended> (цель сравнения).

   <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <compare xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
         xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
       <source>ds:operational</source>
       <target>ds:intended</target>
       <report-origin/>
       <xpath-filter
           xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
         /if:interfaces
       </xpath-filter>
     </compare>
   </rpc>

Отклик RPC с найденными различиями представлен ниже.

   <rpc-reply
        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
        message-id="101">
     <differences
        xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
        xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
       <yang-patch>
         <patch-id>interface status</patch-id>3
         <comment>
           diff between operational (source) and intended (target)4
         </comment>
         <edit>
           <edit-id>1</edit-id>
           <operation>replace</operation>5
           <target>/ietf-interfaces:interface=eth0/enabled</target>
           <value>
             <if:enabled>false</if:enabled>
           </value>
           <source-value>
              <if:enabled or:origin="or:learned">true</if:enabled>
           </source-value>
         </edit>
         <edit>
           <edit-id>2</edit-id>
           <operation>create</operation>6
           <target>/ietf-interfaces:interface=eth0/description</target>
           <value>
             <if:description>ip interface</if:description>
           </value>
         </edit>
       </yang-patch>
     </differences>
   </rpc-reply>

Такой же запрос в RESTCONF (с использованием формата JSON [RFC7951]) показан ниже.

   POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json
   Accept: application/yang-data+json

   { "ietf-nmda-compare:input" : {
      "source" : "ietf-datastores:operational",
      "target" : "ietf-datastores:intended",
      "report-origin" : null,
      "xpath-filter" : "/ietf-interfaces:interfaces"
      }
   }

Запрос RESTCONF (в формате JSON) даст показанный ниже результат.

   HTTP/1.1 200 OK
   Date: Thu, 24 Jan 2019 20:56:30 GMT
   Server: example-server
   Content-Type: application/yang-data+json

   { "ietf-nmda-compare:output" : {
       "differences" : {
         "ietf-yang-patch:yang-patch" : {
           "patch-id" : "interface status",
           "comment" : "diff between intended (source) and operational",
           "edit" : [
             {
               "edit-id" : "1",
               "operation" : "replace",7
               "target" : "/ietf-interfaces:interface=eth0/enabled",
               "value" : {
                  "ietf-interfaces:interface/enabled" : "false"
               },
               "source-value" : {
                  "ietf-interfaces:interface/enabled" : "true",
                  "@ietf-interfaces:interface/enabled" : {
                    "ietf-origin:origin" : "ietf-origin:learned"
                  }
                }
             },
             {
               "edit-id" : "2",
               "operation" : "create",8
               "target" : "/ietf-interfaces:interface=eth0/description",
               "value" : {
                 "ietf-interface:interface/description" : "ip interface"
               }
             }
           ]
         }
       }
     }
   }

6. Вопросы производительности

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

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

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

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

Агентство IANA обновило URI в реестре IETF XML [RFC3688], как показано ниже.

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

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

Агентство IANA зарегистрировало новый модуль YANG в реестре YANG Module Names [RFC6020].

   name:  ietf-nmda-compare
   namespace:  urn:ietf:params:xml:ns:yang:ietf-nmda-compare
   prefix:  cmp
   reference:  RFC 9144

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

Заданный в этом документе модуль 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 и содержимого. NACM определяет доступ к серверу в целом, а также правила доступа ко всем его хранилищам. Все субдеревья, к которым запрашивающему не предоставлен доступ, пропускаются и не учитываются в сравнении.

Определённая в этом модуле YANG операция RPC <compare> может быть чувствительной или уязвимой в некоторых сетевых средах, поэтому важно контролировать доступ к этой операции. Чувствительные и уязвимые аспекты операции RPC <compare> указаны ниже.

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

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

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

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

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

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

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

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

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

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

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

[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, «YANG Patch Media Type», RFC 8072, DOI 10.17487/RFC8072, February 2017, <https://www.rfc-editor.org/info/rfc8072>.

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

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

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

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

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

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

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

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

Приложение A. Возможные в будущем расширения

В будущем возможно расширение операции <compare> разными дополнительными функциями. В частности, можно задать расширение с дополнительной функцией демпфирования, позволяющее клиентам задать минимальный интервал времени, в течение которого различия должны существовать, чтобы их следовало включать в результат. Это даст клиентам возможность отличить мимолётные различия от невнесенных изменений, которые могут привести к реальным проблемам в работе и несогласованности устройства. Для этого можно добавить входной параметр, указывающий интервал демпфирования, чтобы включать лишь долгоживущие изменения. Значение 0 или отсутствие параметра будут отключать демпфирование. Отчёты о различиях можно отложить на время демпфирования с момента получения запроса. Для реализации такой возможности сервер может запускать сравнение при вызове RPC и сохранять временный результат. Затем, по истечении периода демпфирования проверяется наличие найденных различий и сохранившиеся различия включаются в отчёт.

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

Спасибо Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka, Tim Carey, Reshad Rahman за их отклики и предложения.

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

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

nmalykh@protokols.ru

Internet Research Task Force (IRTF)                              J. Hong
Request for Comments: 9138                                        T. You
Category: Informational                                             ETRI
ISSN: 2070-1721                                                  L. Dong
                                                             C. Westphal
                                             Futurewei Technologies Inc.
                                                               B. Ohlman
                                                                Ericsson
                                                           November 2021

Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

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

PDF

Аннотация

В этом документе рассматриваются вопросы функциональности и проектирования служб распознавания имён (Name Resolution Service или NRS) в ориентированных на информацию сетях (Information-Centric Networking или ICN). Целью NRS в ICN является трансляция имени объекта в некую иную информацию, такую как местоположение (locator), другое имя и т. п. Документ является результатом исследовательской группы ICNRG¹.

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

Этот документ не содержит спецификации стандарта Internet (Standards Track) и публикуется с информационными целями.

Документ является результатом работы IRTF². IRTF публикует результаты связанных Internet исследований и разработок. Эти результаты могут не подходить для развёртывания. Данный документ представляет согласованное мнение исследовательской группы Information-Centric Networking в составе IRTF. Документы, одобренные для публикации IRSG не являются кандидатами в какие-либо стандарты Internet (см. раздел 2 в RFC 7841).

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

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

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

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

1. Введение

Сеть Internet в настоящее время основана на парадигме, ориентированной на хосты, где хосты указываются адресами IP, а взаимодействие происходит между парой хостов. Таким образом, информация в Internet сейчас идентифицируется именем хоста (или сервера), где она хранится. В отличие от ориентированных на хосты сетей основными объектами взаимодействия в ориентированной на информацию сети (ICN) являются объекты именованных данных (named data object или NDO), которые однозначно указываются независимыми от местоположения именами. Таким образом, сети ICN нацелены на эффективное распространение и извлечение объектов NDO в глобальном масштабе и эта технология была признана многообещающей архитектурой будущей сети Internet для преодоления современных ограничений Internet, в таких сферах, как расширяемость и мобильность [Ahlgren] [Xylomenos]. ICN также является кандидатом при выборе архитектуры «Internet вещей» (Internet of Things или IoT), поскольку IoT фокусируется на данных и информации [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].

Поскольку именование данных, не зависящее от их текущего местоположения (хранилища) является основной концепцией ICN, отыскание NDO с использованием независимого от местоположения имени является одной из важнейших задач при проектировании ICN. Маршрутизацию ICN можно разделить на 3 этапа [RFC7927]:

1. распознавание имени — сопоставление (и трансляция) имени содержимого с местоположением (locator) издателя содержимого или источника, способного предоставить содержимое;

2. маршрутизация запроса содержимого к местоположению этого содержимого по локатору или имени;

3. доставка содержимого запросившей его стороне.

Из отмеченных 3 этапов маршрутизации ICN в этом документе рассматривается этап 1 — распознавание имён, при котором имя содержимого транслируется в его местоположение (locator). Кроме того, докуме6нт охватывает возможные типы распознавания имён в ICN, такие как преобразование имени в другое имя, манифест или метаданные.

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

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

2. Служба распознавания имён в ICN

Служба распознавания имён (NRS) в ICN определяется как служба, обеспечивающая функцию распознавания имён для трансляции имени объекта в иные сведения, такие как местоположение, другое имя, метаданные, сведения о следующем интервале пересылки (next-hop) и т. п., которые применяются для пересылки запроса объекта. Иными словами, служба NRS может предоставляться инфраструктурой ICN, чтобы помочь потребителю получить нужные сведения (или именованный объект данных). Потребитель предоставляет NRS постоянное имя, а NRS возвращает имя или местоположение (locator), возможно в нескольких экземплярах, для получения текущего экземпляра запрошенного объекта.

Распознавание имён является важной частью маршрутизации ICN, хотя сам процесс распознавания может быть отделен от маршрутизации запросов содержимого или быть встроенным в маршрутизацию запросов содержимого как неявный процесс. Первый вариант в этом документе называется явным распознаванием (explicit name resolution), второй — маршрутизацией по именам (name-based routing).

2.1. Явное распознавание имён

NRS может использовать явное распознавание имён для возврата клиенту местоположения содержимого и базовая сеть будет использовать это местоположение в качестве идентификатора для маршрутизации запроса клиента к одному из издателей или копии содержимого. Есть несколько проектов ICN, использующих явное распознавание, например ориентированная на данные архитектура сети (Data-Oriented Network Architecture или DONA) [Koponen], PURSUIT [PURSUIT], сеть информации (Network of Information или NetInf) [SAIL], MobilityFirst [MF], IDNet [Jung] и др. Кроме того, явное распознавание имён также разрешено в плоскостях управления 5G [SA2-5GLAN].

2.2. Маршрутизация по именам

NRS может принимать подход с маршрутизацией по именам, где распознавание имен интегрировано с маршрутизацией запросов содержимого, как в сетях именованных данных и ориентированных на содержимое сетях (Named Data Networking / Content-Centric Networking или NDN/CCNx) [NDN] [CCNx].

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

2.3. Гибридный подход

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

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

2.4. Сравнение подходов к распознаванию имён

Ниже приведено сравнение нескольких аспектов явного распознавания имён и маршрутизации по именам.

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

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

• Влияние отказа узла. Узлы, вовлечённые в явное распознавание имён, имеют наложенные серверы распознавания (например, обработчики распознавания в DONA), а узлы, участвующие в маршрутизации по именам, являются маршрутизаторами, которые направляют сообщения на основе таблицы маршрутизации по именам (например, маршрутизаторы NDN). Отказ узла в системе явного распознавания может приводить к отказам некоторых запросов содержимого, которое не утратило доступности. Эта проблема не возникает при маршрутизации по именам, поскольку могут быть найдены пути обхода отказавших маршрутизаторов ICN при условии сохранения связности сети.

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

Кроме того, в распознавание имён может быть включён промежуточный шаг, а именно отображение имени на другие имена, чтобы упростить извлечение именованного содержимого через манифест [Westphal] [RFC8569]. Манифест распознаётся с помощью одного или двух описанных выше подходов и может включать дальнейшее сопоставление имён с содержимым и местоположением. Этапы распознавания имён становятся следующими — сначала транслируется имя манифеста в местоположение его копии, которая включает дополнительные имена компонентов содержимого и возможные места размещения содержимого, затем извлекается содержимое с помощью имён и/или местоположения, что может приводить к дополнительному распознаванию имён.

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

3. Функциональность NRS в ICN

В этом разделе рассматривается функциональность NRS в ICN.

3.1. Поддержка разнотипных имён

В ICN имя служит для идентификации объекта данных и привязано к нему [RFC7927]. ICN требует уникальности и постоянства имени объекта данных для обеспечения доступности объекта в некой области. Есть разные подходы к разработке схем именования ICN [Bari]. В идеале имя может включать любую форму идентификатора, плоскую или иерархическую, понятную человеку или нечитаемую.

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

В PURSUIT [PURSUIT] имена являются плоскими и для NRS определены функции встречи (rendezvous), которые реализуются набором узлов встречи (rendezvous node или RN), называемых также сетью встреч (rendezvous network или RENE). Таким образом, имя состоит из цепочки идентификаторов областей действия (scope ID), а один идентификатор встречи (rendezvous ID) маршрутизируется узлами RN в сети RENE. В результате PURSUIT отделяет распознавание имён и маршрутизацию данных. Функции NRS выполняются сетью RENE.

В MobilityFirst [MF] имена, называемые глобально уникальными идентификаторами Global Unique Identifier или GUID), выводятся из понятных человеку имён через глобальную службу именования и являются «плоскими» типизованными строками размером 160 битов со свойствами самосертификации. MobilityFirst определяет глобальную службу распознавания имён (Global Name Resolution Service или GNRS), которая преобразует GUID в сетевые адреса и отделяет распознавание имён от маршрутизации данных аналогично PURSUIT.

В NetInf [Dannewitz] информационные объекты используют имена Named Information (NI) [RFC6920], состоящие из названия органа (authority) и дайджеста (хэш содержимого). Имена NI могут быть плоскими, поскольку часть authority необязательна. Архитектура NetInf также включает систему распознавания имён (NRS), которая может служить для преобразования NI в адреса нижележащего сетевого уровня с маршрутизацией.

В NDN [NDN] и CCNx [CCNx] имена являются иерархическими и могут быть похожи на URL. Каждый компонент имени может быть любым, включая понятные человеку строки или хэш-значения. В NDN/CCNx применяется маршрутизация по именам и маршрутизатор NDN пересылает запросы, выполняя поиск по наибольшему совпадению в базе данных пересылки (Forwarding Information Base FIB) для имени содержимого, а запросы хранятся в таблице ожидающих интересов (Pending Interest Table или PIT).

3.2. Поддержка мобильности издателей

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

Однако мобильность издателей не возникает автоматически из модели пересылки ICN, как мобильность потребителей. Если издатель перемещается в другое место сети или в другой домен, который управляется другим полномочным издателем, системе управления мобильностью будет сложно обновить базу маршрутной информации (Routing Information Base или RIB) и записи FIB в маршрутизаторах ICN, указав новый путь пересылки. Поэтому для различных вариантов архитектуры ICN в литературе предлагается принять NRS для обеспечения мобильности издателей. NRS можно реализовать разными способами, такими как точки встречи (rendezvous point) и/или наложенные системы отображения.

В NDN [Zhang2] для поддержки мобильности издателей были предложены механизмы встречи (rendezvous), организующие встречи по интересам (RV) с данными, создаваемыми мобильным издателем (mobile producer или MP). Здесь можно выделить на два подхода — «погоню» за мобильным издателем и данные встречи. В случае погони за MP встреча обеспечивает службу отображения, сопоставляющую имена данных от MP с именем текущей точки подключения MP (point of attachment или PoA). Дополнительно к этому RV выступает в качестве домашнего агента для поддержки IP mobility, поскольку RV позволяет туннелировать сообщения Interest от потребителей в направлении MP в точке PoA. В части данных встречи (rendezvous data) решение включает перенос данных, создаваемых MP, в хранилище (depot) вместо пересылки сообщений Interest. Таким образом, сообщение Interest от потребителя может пересылаться в стационарное место, называемое «встречей с данными» (data rendezvous), чтобы данные возвращались оттуда или извлекались из иного места с помощью отображения. В результате RV или иные функции отображения играют роль NRS в NDN.

В [Ravindran] используются метки пересылки (forwarding label или FL) для обеспечения возможности разделить пространства имён идентификаторов (ID) и местоположений (LID) в ICN. Обычно идентификаторы ID поддерживаются приложениями, а локаторы (местоположение) — администраторами сетей, так что ID сопоставляются с разнотипными схемами имён, а LID — с сетевыми доменами или конкретными элементами сети. Таким образом, объект FL выступает локатором (LID) и обеспечивает гибкость пересылки сообщений Interest через службы сопоставления между ID и LID. Поэтому в данном проекте служба сопоставления в инфраструктуре плоскости управления может рассматриваться как NRS.

В MobilityFirst [MF] мобильность потребителей и издателей может обрабатываться в основном глобальной службой распознавания имён (global name resolution service или GNRS), которая преобразует GUID в сетевые адреса. Поэтому требуется обновлять GNRS для поддержки мобильности, когда подключенный к сети объект меняет точку подключения, что отличается от NDN/CCNx.

В NetInf [Dannewitz] мобильность обслуживается NRS очень похожим на MobilityFirst способом.

Помимо мобильности потребителей и издателей в ICN возникает задача поддержки других динамических свойств, таких как множественные подключения (multi-homing), перенос (migration) и репликация именованных ресурсов (например, содержимого, устройств, служб). Следовательно, NRS может помочь в решении и этих динамических задач.

3.3. Поддержка расширяемой системы маршрутизации

В ICN имя объекта данных служит для маршрутизации на этапе распознавания или при поиске в таблице маршрутизации. Поэтому маршрутные сведения для каждого объекта данных следует поддерживать в маршрутных базах, таких как RIB и FIB. Поскольку число объектов данных будет очень велико, размер информационных баз также будет большим [RFC7927].

Иерархические пространства имён, применяемые в архитектуре CCNx [CCNx] и NDN [NDN] снижают размер таблиц за счёт агрегирования имён и повышают возможности расширения системы маршрутизации. Плоская же система имён существенно осложняет задачи расширения системы маршрутизации. Неагрегируемые префиксы имён, внедряемые в зону без принятого по умолчанию маршрута (Default Route Free Zone или DFZ) сети ICN могут создавать более серьёзные проблемы расширяемости по сравнению с аналогичными проблемами в системе маршрутизации IP. Таким образом, NRS может играть важную роль в смягчении проблемы расширяемости независимо от типа пространство имён.

В работе [Afanasyev] для решения задачи расширяемости маршрутизации в NDN DFZ применяется хорошо известная концепция сопоставления и инкапсуляции (map-and-encap), чтобы обеспечить простое и защищённое решение по сопоставлению пространств имён. В предложенном решении map-and-encap данные, у которых префиксов имён нет в таблице пересылки DFZ, можно получить с помощью распределенной системы сопоставления NDNS, которая обеспечивает поддержку и поиск данных отображения имён на глобально маршрутизируемые префиксы, играя роль NRS.

3.4. Поддержка кэширования вне пути

Кэширование в сети считается основным компонентом архитектуры ICN. Оно может применяться для обеспечения качества обслуживания (quality-of-service или QoS) пользователей с целью снижения общего трафика, предотвращения перегрузок и атак на службы (denial-of-service или DoS), а также улучшения доступности. Кэширование можно разделить на внутрипутевое (on-path) и внешнее (off-path) в зависимости от размещения кэша относительно пути от исходного сервера к потребителю. Внешнее кэширование, которое называют также репликацией (content replication) или сохранением (content storing) содержимого, предназначено для репликации содержимого в сети с целью повышения уровня доступности независимо от местоположения по отношению к пути пересылки. Поиск кэшированных объектов вне пути является нетривиальной задачей в ICN с маршрутизацией по именам. Для поддержки внешнего кэширования реплики обычно анонсируются в систему маршрутизации по именам или в NRS.

В [Bayhan] распознавание имён (NRS) служит для поиска копий вне пути через сеть, которые могут быть недоступны для механизмов маршрутизации по именам. Такая возможность может быть полезна в автономной системе (Autonomous System или AS) для предотвращения дорогостоящего трафика между AS к внешнему содержимому, повышения эффективности использования пропускной способности для внутреннего трафика AS и снижения задержки доступа к данным для пользователей.

3.5. Поддержка безымянных объектов

В CCNx 1.0 [Mosko2] концепция Nameless Object, которые представляют собой безымянные объекты содержимого (Content Object), введена для обеспечения возможности перемещать содержимое между хранилищами реплик без переименования или повторного подписывания объектов с новым именем. К безымянным объектам можно обращаться по хэш-значению ContentObjectHash на основе алгоритма SHA-256.

Сообщения Interest будут содержать имя и ContentObjectHash — имя будет служить для маршрутизации, а ContentObjectHash — для сопоставления. Однако на обратном пути при отсутствии имени Content Object объект будет безымянным и сопоставление будет возможно лишь по ContentObjectHash. Поэтому потребителю потребуется распознавать имя и хэш через внешнюю систему, которую можно рассматривать как NRS.

3.6. Манифест поддержки

Для коллекций объектов данных, организованных в большие файлоподобные структуры [FLIC] применяются манифесты в качестве структур данных для передачи информации. Манифест может содержать хэш-дайджесты подписанных Content Object или других манифестов, так что большие объекты содержимого, представляющие крупные части данных приложения, могут быть собраны с использованием такого манифеста.

Для запроса Content Object потребителю нужно знать имя корня манифеста для получения этого манифеста. В случае файлоподобных коллекций FLIC (File-Like ICN Collection) имя манифеста может быть представлено безымянным корневым манифестом, чтобы можно было задействовать для предоставления информации потребителю внешние системы, такие как NRS.

3.7. Метаданные поддержки

При распознавании имени Content Object служба NRS может возвращать множество метаданных в дополнение к местоположению объекта. Метаданные могут включать дополнительное местоположение, поддерживаемые протоколы передачи, правила кэширования, параметры защиты, формат данных, хэш объекта и пр. Потребитель может использовать метаданные для выбора протокола передачи, механизмов защиты, выходного интерфейса и т. п. Пример такого использования метаданных даёт архитектура сетевых объектов (Networked Object или NEO) в ICN [NEO].

4. Вопросы проектирования NRS и ICN

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

4.1. Время отклика при распознавании

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

Приемлемая задержка отклика может составлять время порядка интервала кругового обхода (round-trip) между запросившим клиентом и обеспечивающим отклик сервером NRS. Хотя значения RTT могут существенно зависеть от удалённости указанных точек, следует использовать ту или иную верхнюю границу. Верхняя граница задержки отклика должна гарантироваться в некоторых приложениях, чувствительных к задержкам, например в промышленных системах или телемедицине.

Время отклика учитывает все этапы распознавания, включая возможное поэтапное (hop-by-hop) распознавание или иерархическую пересылку запроса.

4.2. Точность распознавания

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

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

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

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

4.3. Гарантии распознавания

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

4.4. Беспристрастность распознавания

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

Отдано следует отметить, что содержимое (или его издатель) может требовать от сети иного уровня QoS (см., например, [RFC9064]) и это может затрагивать NRS, поэтому в таких случаях беспристрастность может обеспечиваться в рамках одного класса обслуживания.

4.5. Расширяемость

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

Система NRS должна расширяться с ростом числа частей (имён) содержимого и следует поддерживать очень большой каталог содержимого. Трафик Internet измеряется зеттабайтами (10²¹ байт) в год. Поскольку служба NRS связана с фактическим трафиком, число имён содержимого будет расти с увеличением трафика. Размер содержимого может варьироваться от нескольких байтов до гигабайт, поэтому в NRS следует предполагать в ближайшем будущем расширение каталога до 10²¹ и более.

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

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

Системе NRS следует расширять свои возможности реагирования при росте числа запросов, которые ожидаются от таких приложений, как IoT или межмашинные взаимодействия (machine-to-machine или M2M), где запросы и обмен данными происходят часто.

4.6. Управляемость

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

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

4.7. Развёрнутая система

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

4.8. Отказоустойчивость

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

При отказе сервера NRS система NRS должна быть способна восстановить и/или возобновить записи, хранившиеся на этом сервере NRS.

4.9. Безопасность и приватность

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

4.9.1. Конфиденциальность

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

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

NRS может поддерживать механизмы запутывания (obfuscation) и/или шифрования, чтобы содержимое запросов на распознавание не было доступно сторонним лицам вне системы NRS.

Система NRS должна сохранять конфиденциальность для предотвращения несанкционированного доступа к записям сопоставления имён. Это может требоваться в средах IoT где создаётся много «деликатных» данных.

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

4.9.2. Проверка подлинности

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

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

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

4.9.3. Целостность

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

4.9.4. Отказоустойчивость и доступность

Системе NRS следует быть устойчивой к атакам на службы (denial-of-service) и другим распространенным атакам, чтобы предотвратить косвенное нарушение работы всей системы. Поэтому при отказе части системы NRS отказ следует изолировать без влияния на другие домены. Для возобновления нормальной работы службы нужны механизмы быстрого восстановления.

5. Заключение

Маршрутизация ICN может состоять из 3 этапов — распознавание имени, маршрутизация запроса содержимого и доставка содержимого. В этом документе описан этап распознавания имён, который является первым и наиболее важным для успешной маршрутизации в ICN. Сервис распознавания имён (NRS) в ICN определён как служба, обеспечивающая функцию распознавания имён для трансляции имени объекта в иную информацию, такую как местоположение (locator), иное имя, метаданные, следующий этап пересылки (next-hop) и т. п., которая может применяться для пересылки к интересующему объекту.

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

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

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

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

Рекомендации по безопасности приведены в параграфе 4.9.

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

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

[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, «Information-Centric Networking (ICN) Research Challenges», RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.

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

[Afanasyev] Afanasyev, A. et al., «SNAMP: Secure Namespace Mapping to Scale NDN Forwarding», 2015 IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.

[Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., and B. Ohlman, «A Survey of Information-Centric Networking», IEEE Communications Magazine, Vol. 50, Issue 7, DOI 10.1109/MCOM.2012.6231276, July 2012, <https://doi.org/10.1109/MCOM.2012.6231276>.

[Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, «Named data networking for IoT: An architectural perspective», European Conference on Networks and Communications (EuCNC), DOI 10.1109/EuCNC.2014.6882665, June 2014, <https://doi.org/10.1109/EuCNC.2014.6882665>.

[Amadeo2] Amadeo, M. et al., «Information-centric networking for the internet of things: challenges and opportunities», IEEE Network, Vol. 30, No. 2, DOI 10.1109/MNET.2016.7437030, March 2016, <https://doi.org/10.1109/MNET.2016.7437030>.

[Baccelli] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. Wählisch, «Information Centric Networking in the IoT: Experiments with NDN in the Wild», ACM-ICN 2014, DOI 10.1145/2660129.2660144, 2014, <https://doi.org/10.1145/2660129.2660144>.

[Bari] Bari, M.F., Chowdhury, S.R., Ahmed, R., Boutaba, R., and B. Mathieu, «A Survey of Naming and Routing in Information-Centric Networks», IEEE Communications Magazine, Vol. 50, No. 12, pp. 44-53, DOI 10.1109/MCOM.2012.6384450, December 2012, <https://doi.org/10.1109/MCOM.2012.6384450>.

[Bayhan] Bayhan, S. et al., «On Content Indexing for Off-Path Caching in Information-Centric Networks», ACM-ICN 2016, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.

[CCNx] «CICN», <https://wiki.fd.io/view/Cicn>.

[Dannewitz] Dannewitz, C. et al., «Network of Information (NetInf) — An information-centric networking architecture», Computer Communications, Vol. 36, Issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.

[FLIC] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, «File-Like ICN Collections (FLIC)», Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-03, 7 November 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>.

[ID.Zhang2] Ravindran, R., Zhang, Y., Grieco, L. A., Lindgren, A., Burke, J., Ahlgren, B., and A. Azgin, «Design Considerations for Applying ICN to IoT», Work in Progress, Internet-Draft, draft-irtf-icnrg-icniot-03, 2 May 2019, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-03>.

[Jung] Jung, H. et al., «IDNet: Beyond All-IP Network», ETRI Journal, Vol. 37, Issue 5, DOI 10.4218/etrij.15.2415.0045, October 2015, <https://doi.org/10.4218/etrij.15.2415.0045>.

[Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, K.H., Shenker, S., and I. Stoica, «A Data-Oriented (and Beyond) Network Architecture», ACM SIGCOMM 2007, pp. 181-192, DOI 10.1145/1282380.1282402, August 2007, <https://doi.org/10.1145/1282380.1282402>.

[MF] «MobilityFirst Future Internet Architecture Project Overview», <http://mobilityfirst.winlab.rutgers.edu>.

[Mosko2] Mosko, M., «Nameless Objects», IRTF ICNRG, January 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-01/materials/slides-interim-2016-icnrg-1-7.pdf>.

[NDN] «Named Data Networking», <http://www.named-data.net>.

[NEO] Eriksson, A. and A.M. Malik, «A DNS-based information-centric network architecture open to multiple protocols for transfer of data objects», 21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp. 1-8, DOI 10.1109/ICIN.2018.8401595, February 2018, <https://doi.org/10.1109/ICIN.2018.8401595>.

[NRSarch] Hong, J., You, T., and V. Kafle, «Architectural Considerations of ICN using Name Resolution Service», Work in Progress, Internet-Draft, draft-irtf-icnrg-nrsarch-considerations-06, 12 February 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-nrsarch-considerations-06>.

[PURSUIT] «FP7 PURSUIT», <https://www.fp7-pursuit.eu/>.

[Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, «A case for ICN usage in IoT environments», IEEE GLOBECOM, DOI GLOCOM.2014.7037227, December 2014, <https://doi.org/GLOCOM.2014.7037227>.

[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, «Forwarding Label support in CCN Protocol», Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02>.

[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, «Naming Things with Hashes», RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.

[RFC8569] Mosko, M., Solis, I., and C. Wood, «Content-Centric Networking (CCNx) Semantics», RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.

[RFC9064] Oran, D., «Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols», RFC 9064, DOI 10.17487/RFC9064, June 2021, <https://www.rfc-editor.org/info/rfc9064>.

[SA2-5GLAN] 3GPP, «New WID: 5GS Enhanced support of Vertical and LAN Services», TSG SA Meeting #SP-82, December 2018, <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip>.

[SAIL] «Scalable and Adaptive Internet Solutions (SAIL)», <http://www.sail-project.eu/>.

[Westphal] Westphal, C. and E. Demirors, «An IP-Based Manifest Architecture for ICN», ACM-ICN 2015, DOI 10.1145/2810156.2812614, September 2015, <https://doi.org/10.1145/2810156.2812614>.

[Xylomenos] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G. Polyzos, «A Survey of Information-Centric Networking Research», IEEE Communications Surveys and Tutorials, Vol. 16, Issue 2, DOI 10.1109/SURV.2013.070813.00063, 2014, <https://doi.org/10.1109/SURV.2013.070813.00063>.

[Zhang2] Zhang, Y. et al., «A Survey of Mobility Support in Named Data Networking», IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2016.7562050, April 2016, <https://doi.org/10.1109/INFCOMW.2016.7562050>.

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

Авторы благодарны Dave Oran, Dirk Kutscher, Ved Kafle, Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kühlewind, Colin Perkins за полезные рецензии, комментарии и улучшения для документа.

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

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

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

nmalykh@protokols.ru