RFC 8342 Network Management Datastore Architecture (NMDA)

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8342                                Tail-f Systems
Updates: 7950                                           J. Schoenwaelder
Category: Standards Track                              Jacobs University
ISSN: 2070-1721                                                P. Shafer
                                                               K. Watsen
                                                        Juniper Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2018

Архитектура хранилища данных сетевого управления NMDA

Network Management Datastore Architecture (NMDA)

PDF

Тезисы

Хранилища данных являются фундаментальной концепцией привязки моделей данных, написанных на языке моделирования YANG, к протоколам сетевого управления типа NETCONF1 и RESTCONF. Этот документ определяет архитектурную модель для хранилищ данных на основе опыта, полученного с начальными простыми моделями, которая решает вопросы, не поддерживаемые первоначальной моделью. Документ обновляет RFC 7950.

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

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

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

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

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

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

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

Оглавление

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

1. Введение

Этот документ предоставляет архитектурную модель для хранилищ данных, используемых протоколами сетевого управления типа NETCONF [RFC6241] и RESTCONF [RFC8040], а также языком моделирования данных YANG [RFC7950]. Хранилища являются фундаментальной концепцией, привязывающей модели данных сетевого управления к протоколам сетевого управления. Согласование общей архитектурной модели хранилища данных позволит создавать модели данных без привязки к конкретному протоколу сетевого управления. Эта архитектурная основа идентифицирует набор концептуальных хранилищ, но не обязывает все протоколы сетевого управления предоставлять все эти концептуальные хранилища. Архитектура не привязана к кодированию, используемому протоколами сетевого управления.

Данный документ обновляет RFC 7950 в части определения доступного дерева для некоторых вариантов контекста XPath4 (см. параграф 6.1) и контекста вызова операций ( см. параграф 6.2).

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

2. Цели

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

Исходная модель хранилищ данных требует моделирования этих данных в схеме YANG дважды — как объекты config true и config false. Соглашение, принятое в модели данных интерфейса [RFC8343] и модели данных IP [RFC8344], состоит в использовании двух раздельных ветвей с общим корнем — одна ветвь для объектов данных конфигурации, другая для объектов данных текущего состояния.

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

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

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

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

Используемые в документе термины определены ниже. Некоторые термины используют пересмотренные определения из [RFC6241] и [RFC7950] (см. также раздел 4). Эти пересмотренные определения семантически эквивалентны определениям из [RFC6241] и [RFC7950]. Предполагается, что обновленные определения из этого раздела будут применяться взамен определений [RFC6241] и [RFC7950] при пересмотре этих документов.

datastore – хранилище данных

Концептуальное место для хранения и доступа к информации. Хранилище может быть реализовано, например, в виде файла, базы данных, flash-памяти или их комбинации. Хранилище отображается на экземпляр дерева данных YANG.

schema node — узел схемы

Узел в дереве схемы. Формальное определение приведено в RFC 7950.

datastore schema — схема хранилища данны

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

configuration – конфигурация, данные конфигурации

Данные, которые нужны для перевода устройства из начального состояния в желаемое рабочее состояние. Эти данные моделируются в YANG с использованием узлов config true. Конфигурация может происходить из разных источников.

configuration datastore – хранилище конфигурации

Хранилище данных, содержащее параметры конфигурации.

running configuration datastore – хранилище рабочей конфигурации

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

candidate configuration datastore – хранилище будущей конфигурации, хранилище-кандидат

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

startup configuration datastore — хранилище стартовой конфигурации

Конфигурационное хранилище, содержащие данные, которые будут помещены в рабочее хранилище при следующей загрузке устройства. Это хранилище обозначают <startup>.

intended configuration – предполагаемая конфигурация

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

intended configuration datastore – хранилище предполагаемой конфигурации

Конфигурационное хранилище содержащее полную предполагаемую конфигурацию. Это хранилище обозначают <intended>.

configuration transformation — преобразование конфигурации

Дополнение, изменение или удаление данных конфигурации при передаче между хранилищами <running> и <intended>. Примерами конфигурационных преобразований служат удаление из конфигурации неактивных элементов и создание конфигурации из шаблона.

conventional configuration datastore – традиционное (обычное) хранилище данных конфигурации

Одно из хранилищ <running>, <startup>, <candidate> и <intended>. Эти хранилища используют общую схему и протокольные операции позволяют копировать данные между хранилищами. Термин conventional выбран в качестве общего обозначения всех таких хранилищ.

conventional configuration – конфигурация общего назначения

Конфигурационные данные, хранящиеся в любом из традиционных хранилищ.

dynamic configuration datastore – хранилище динамических данных конфигурации

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

dynamic configuration – динамическая конфигурация

Конфигурация, полученная из динамического хранилища.

learned configuration — выведенная конфигурация

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

system configuration – системная конфигурация

Конфигурация, поставляемая (обеспечиваемая) самой системой.

default configuration – принятая по умолчанию конфигурация

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

applied configuration – примененная конфигурация

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

system state – состояние системы

Дополнительные данные системы, которые не относятся к конфигурационным, это могут быть предназначенные только для чтения параметры состояния или собранная статистика. Состояние системы является временным и меняется в результате взаимодействия с внутренними компонентами или внешними системами. Состояние системы моделируется в YANG с использованием узлов config false.

operational state – рабочее состояние

Комбинация примененной конфигурации и состояния системы.

operational state datastore – хранилище рабочего состояния

Хранилище данные, содержащее полное рабочее состояние устройства. Это хранилище обозначают <operational>.

origin – источник, происхождение

Аннотация метаданных, показывающая источник элементе данных.

remnant configuration – остаточная конфигурация

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

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

client — клиент

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

server — сервер

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

notification — уведомление

Инициированное сервером сообщение, указывающее на некое событие, которое распознал сервер.

remote procedure call – вызов удаленной процедуры

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

4. Предпосылки

Протокол NETCONF [RFC6241] включает приведенные ниже определения.

datastore – хранилище данных

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

configuration datastore — хранилище конфигурации

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

Язык YANG 1.1 [RFC7950] вносит уточнения для использования NETCONF с YANG (обычное дело, но отметим, что протокол NETCONF был создан раньше YANG).

datastore

При моделировании с использованием YANG хранилеще данных реализуется в виде экземпляра дерева данных.

configuration datastore

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

[RFC6244] определяет данные операционного состояния, как показано ниже.

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

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

Опыт реализации и запросы операторов [OpState-Reqs] [OpState-Modeling] показали, что модель хранилища, разработанная изначально для NETCONF и уточненная YANG, требует расширения. В частности, были разработаны понятия предполагаемой конфигурации и примененной конфигурации.

4.1. Исходная модель хранилищ данных

На рисунке 1 показана исходная модель хранилищ данных, используемая сейчас протоколом NETCONF [RFC6241].

+-------------+                 +-----------+
| <candidate> |                 | <startup> |
|  (ct, rw)   |<---+       +--->| (ct, rw)  |
+-------------+    |       |    +-----------+
       |           |       |           |
       |         +-----------+         |
       +-------->| <running> |<--------+
                 | (ct, rw)  |
                 +-----------+
                       |
                       v
                 рабочее состояние  <--- уровень управления
                    (cf, ro)

ct = config true; cf = config false
rw = read-write; ro = read-only
прямоугольники обозначают хранилища

Рисунок 1.


Отметим, что модель на рисунке упрощена, полномочия read-only (ro) и read-write (rw) представлены с точки зрения клиента на концептуальном уровне. В NETCONF, например, поддержка хранилищ <candidate> и <startup> является не обязательной, а запись в хранилище <running> не разрешена. Кроме того, хранилище <startup> может быть изменено только путем копирования в него хранилища <running> <startup> в стандартизованной модели редактирования хранилищ NETCONF. Протокол RESTCONF не показывает таких различий и вместо этого обеспечивает универсальное хранилище с возможностью записи, которое скрывает редактирование через промежуточное хранилище <candidate> путем прямой записи в <running> или иного механизма, зависящего от реализации. RESTCONF также скрывает, как конфигурация становится постоянной. Отметим, что реализации могут иметь дополнительные хранилища, которые могут распространять изменения на <running>. NETCONF явно указывает «именованные хранилища данных» (named datastore).

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

  • Операционное состояние не было определено как хранилище данных, хотя были предложения о создании такого хранилища.

  • Операция NETCONF <get> возвращает содержимое хранилища <running> вместе с операционным состоянием. Это требует хранения данных config false и config true вразных ветвях, если данные операционного состояния по сроку жизни отличаются от конфигурационных данных, в также в тех случаях, когда конфигурация применяется не сразу или возникают проблемы с ее применением.

  • Некоторые реализации используют фирменные механизмы, которые позволяют клиентам сохранять неактивные данные в хранилище <running>. Концептуально такие данные удаляются перед проверкой пригодности конфигурации.

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

  • Некоторые операторы отмечали, что для них важно получить успешно примененую конфигурацию, которая может быть надмножеством или подможеством конфигурации в хранилище <running>.

5. Архитектурная модель хранилищ данных

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

+-------------+                 +-----------+
| <candidate> |                 | <startup> |
|  (ct, rw)   |<---+       +--->| (ct, rw)  |
+-------------+    |       |    +-----------+
       |           |       |           |
       |         +-----------+         |
       +-------->| <running> |<--------+
                 | (ct, rw)  |
                 +-----------+
                       |
                       |        // преобразования конфигурации,
                       |        // например, удаление узлов с 
                       |        // меткой "inactive", раскрытие
                       |        // шаблонов
                       v
                 +------------+
                 | <intended> | // нужна проверка на пригодность
                 | (ct, ro)   |
                 +------------+
                       |        // применение изменений; может
                       |        // от локальных факторов, например,
                       |        // отсутствие ресурсов, задержки
                       |
  хранилища            |   +-------- выведенная конфигурация
  динамической         |   +-------- конфигурация системы
  конфигурации ---+    |   +-------- конфигурация по умолчанию
                  |    |   |
                  v    v   v
               +---------------+
               | <operational> | <-- состояние сисетмы
               | (ct + cf, ro) |
               +---------------+

     ct = config true; cf = config false
     rw = read-write; ro = read-only
     прямоугольники показывают именованные хранилища

Рисунок 2.


5.1. Традиционные хранилища конфигурации

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

  • <running>

  • <candidate>

  • <startup>

  • <intended>

В будущих документах могут быть определены дополнительные хранилища.

Поток данных между хранилищами описан в разделе 5.

Конкретные протоколы могут определять явные операции копирования между хранилищами (например, NETCONF <copy-config>.

5.1.1. Хранилище стартовой конфигурации (<startup>)

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

Хранилище стартовой конфигурации может поддерживаться не всеми протоколами и реализациями.

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

5.1.2. Хранилище будущей конфигурации (<candidate>)

Хранилище будущей конфигурации <candidate> представляет собой хранилище конфигурационных данных, которыми можно манипулировать без влияния на текущую конфигурацию устройства, а затем представлять в хранилище <running>.

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

Хранилище <candidate> обычно не сохраняется при перезагрузке устройства, даже если для него используется энерго-независимая память. Если хранилище <candidate> сохраняется в такой памяти, в процессе перезагрузки оно заменяется содержимым хранилища <running>.

5.1.3. Хранилище рабочей конфигурации (<running>)

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

Хранилище <running> должно поддерживаться, если устройство настраивается с использованием традиционного хранилища конфигурации.

Если устройство не имеет отдельно хранилища <startup> и доступна энерго-независимая память, такое устройство обычно будет использовать эту память для сохранения <running> в процессе перезагрузки.

5.1.4. Хранилище предполагаемой конфигурации (<intended>)

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

Хранилище <intended> тесно связано с <running>. При записи данных в хранилище <running> сервер должен незамедлительно обновить и проверить на пригодность хранилище <intended>.

Содержимое <intended> может также обновляться независимо от <running>, если воздействие преобразований конфигурации меняется, но хранилище <intended> всегда должен быть пригодным деревом данных конфигурации, как указано в параграфе 8.1 [RFC7950].

В простых реализациях хранилища <running> и <intended> идентичны.

Содержимое <intended> также связано с подмножеством config true хранилища <operational>, поэтому клиент может определить, в какой степени предполагаемая конфигурация соответствует текущей, просто проверяя, какая часть содержимого <intended> присутствует в <operational>.

Хранилище <intended> не сохраняется при перезагрузке — его привязка к <running> делает это ненужным.

В настоящее время не определено стандартных механизмов воздействия на хранилище <intended> так, чтобы оно отличалось от <running>, но данная архитектура позволяет определить такие механизмы.

Примером такого механизма может служить поддержка маркировки неактивных узлов в хранилище <running>. Неактивные узлы не будут копироваться в хранилище <intended>. Вторым примером является поддержка шаблонов, которые могут выполнять преобразования конфигурации из <running> для записи в хранилище <intended>.

5.2. Хранилища динамической конфигурации

Модель принимает необходимость хранилищ динамической конфигурации, которые по определению не являются частью постоянной конфигурации устройства. Иногда такие хранилища называют эфемерными (ephemeral datastore), поскольку хранящаяся в них информация теряется при перезагрузке. Хранилища динамической конфигурации взаимодействуют с остальной системой через хранилище <operational>.

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

5.3. Хранилище операционного состояния (<operational>)

Хранилище операционного состояния (<operational>) открыто лишь для чтения и включает все узлы config true и config false, определенные в схеме хранилища данных. В исходной модели NETCONF модель операционного состояния содержит только узлы config false. Причиной включения узлов config true является потребность в представлении рабочих параметров без их дублирования в модели данных.

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

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

Запросы на поиск узлов из хранилища <operational> всегда возвращают используемое значение для существующих узлов, независимо от наличия в модуле YANG принятых по умолчанию значений. Если для данного узла значение не возвращено, это означает, что узел не используется устройством.

Интерпретация слов «используется системой» (in use) зависит от определения схемы и реализации устройства. Обычно функциональность, которая разрешена (включена) и работает в системе, считается используемой. И наоборот, функциональность, которая не включена и не работает считается «не используемой», поэтому ее не следует включать в <operational>.

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

Нарушаться могут только семантические ограничения. К ним относятся операторы YANG when, must, mandatory, unique, min-elements и max-elements, а также уникальность значений ключей.

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

Хранилище <operational> не сохраняется при перезагрузке устройства.

5.3.1. Остаточная конфигурация

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

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

5.3.2. Отсутствующие ресурсы

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

Типичным примером является конфигурация интерфейса, который в настоящее не присутствует. В этом случае конфигурация интерфейса остается в хранилище <intended>, но не включается в <operational>.

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

5.3.3. Контролируемые системой ресурсы

Иногда ресурсы, контролируемые системой и соответствующие данные появляются (и исчезают) в хранилище <operational> динамически. Если контролируемый системой ресурс имеет соответствующую конфигурацию в <intended> при его появлении, система попытается применить эту конфигурацию и это в конечном итоге приведет к ее появлению в хранилище <operational> (если применение пройдет успешно).

5.3.4. Аннотация метаданных источника

При передаче конфигурации в хранилище <operational> она концептуально помечается аннотацией метаданных [RFC7952]Ю указывающей источник. Источник применяет все узлы за исключением контейнеров отсутствия. Аннотация метаданных origin определена в разделе 7. Значениями служат отождествления YANG, перечисленные ниже.

  • origin — абстрактное базовое отождествление, из которого выводено другое отождествление источника.

  • intended — представляет конфигурацию из хранилища <intended>.

  • dynamic — представляет конфигурацию из хранилища динамической конфигурации.

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

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

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

  • unknown — представляет конфигурацию, для которой система не может определить источник.

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

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

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

Если для отдельного узла конфигурации соответствующий оператор description в модуле YANG указывает, что согласованное протоколом значение переписыват значение из конфигурации, в качестве источника следует указывать learned, даже при совпадении выведенного значения с указанным в конфигурации.

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

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

6. Воздействие на YANG

6.1. Контекст XPath

Этот параграф обновляет параграф 6.4.1 из RFC 7950.

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

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

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

  • Если выражение XPath определено в субоператоре оператора input внутри оператора rpc или action, доступным деревом будет экземпляр RPC или операции и все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей. Кроме того, для RPC корневой узел имеет в качестве потомка также узел, который представляет определяемую операцию RPC. Этот узел имеет в качестве потомков входные параметры операции.

  • Если выражение XPath определено в субоператоре оператора output внутри оператора rpc или action, доступным деревом будет экземпляр RPC или операции и все операционное состояние сервера. Корневой узел имеет в качестве потомков узлы верхнего уровня всех модулей. Кроме того, для RPC корневой узел имеет в качестве потомка также узел, который представляет определяемую операцию RPC. Этот узел имеет в качестве потомков выходные результаты операции.

6.2. Вызовы операций и RPC

Этот параграф обновляет параграф 7.15 из RFC 7950.

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

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

7. Модули YANG

   <CODE BEGINS> file "ietf-datastores@2018-02-14.yang"

   module ietf-datastores {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
     prefix ds;

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>

        WG List:  <mailto:netmod@ietf.org>

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de>

        Author:   Phil Shafer
                  <mailto:phil@juniper.net>

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net>

        Author:   Rob Wilton
                  <rwilton@cisco.com>";

     description
       "This YANG module defines a set of identities for identifying
        datastores.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8342
        (https://www.rfc-editor.org/info/rfc8342); see the RFC itself
        for full legal notices.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Отождествления
      */

     identity datastore {
       description
         "Abstract base identity for datastore identities.";
     }

     identity conventional {
       base datastore;
       description
         "Abstract base identity for conventional configuration
          datastores.";
     }

     identity running {
       base conventional;
       description
         "The running configuration datastore.";
     }

     identity candidate {
       base conventional;
       description
         "The candidate configuration datastore.";
     }

     identity startup {
       base conventional;
       description
         "The startup configuration datastore.";
     }

     identity intended {
       base conventional;
       description
         "The intended configuration datastore.";
     }

     identity dynamic {
       base datastore;
       description
         "Abstract base identity for dynamic configuration datastores.";
     }

     identity operational {
       base datastore;
       description
         "The operational state datastore.";
     }

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

     typedef datastore-ref {
       type identityref {
         base datastore;
       }
       description
         "A datastore identity reference.";
     }
   }

   <CODE ENDS>

   <CODE BEGINS> file "ietf-origin@2018-02-14.yang"

   module ietf-origin {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
     prefix or;

     import ietf-yang-metadata {
       prefix md;
     }

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>

        WG List:  <mailto:netmod@ietf.org>

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de>

        Author:   Phil Shafer
                  <mailto:phil@juniper.net>

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net>

        Author:   Rob Wilton
                  <rwilton@cisco.com>";

     description
       "This YANG module defines an 'origin' metadata annotation and a
        set of identities for the origin value.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8342
        (https://www.rfc-editor.org/info/rfc8342); see the RFC itself
        for full legal notices.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Отождествления
      */

     identity origin {
       description
         "Abstract base identity for the origin annotation.";
     }

     identity intended {
       base origin;
       description
         "Denotes configuration from the intended configuration
          datastore.";
     }

     identity dynamic {
       base origin;
       description
         "Denotes configuration from a dynamic configuration
          datastore.";
     }

     identity system {
       base origin;
       description
         "Denotes configuration originated by the system itself.

          Examples of system configuration include applied configuration
          for an always-existing loopback interface, or interface
          configuration that is auto-created due to the hardware
          currently present in the device.";
     }

     identity learned {
       base origin;
       description
         "Denotes configuration learned from protocol interactions with
          other devices, instead of via either the intended
          configuration datastore or any dynamic configuration
          datastore.

          Examples of protocols that provide learned configuration
          include link-layer negotiations, routing protocols, and
          DHCP.";
     }

     identity default {
       base origin;
       description
         "Denotes configuration that does not have a configured or
          learned value but has a default value in use.  Covers both
          values defined in a 'default' statement and values defined
          via an explanation in a 'description' statement.";
     }

     identity unknown {
       base origin;
       description
         "Denotes configuration for which the system cannot identify the
          origin.";
     }

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

     typedef origin-ref {
       type identityref {
         base origin;
       }
       description
         "An origin identity reference.";
     }

     /*
      * Metadata annotations
      */

     md:annotation origin {
       type origin-ref;
       description
         "The 'origin' annotation can be present on any configuration
          data node in the operational state datastore.  It specifies
          from where the node originated.  If not specified for a given
          configuration data node, then the origin is the same as the
          origin of its parent node in the data tree.  The origin for
          any top-level configuration data nodes must be specified.";
     }
   }

   <CODE ENDS>

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

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

Этот документ регистрирует два URIs в реестре IETF XML Registry [RFC3688]. В соответствии с форматом [RFC3688] были выполнены приведенные ниже регистрации.

      URI: urn:ietf:params:xml:ns:yang:ietf-datastores
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-origin
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

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

Этот документ регистрирует два модуля YANG в реестре YANG Module Names [RFC6020]. В соответствии с форматом [RFC6020] были выполнены приведенные ниже регистрации.

      name:         ietf-datastores
      namespace:    urn:ietf:params:xml:ns:yang:ietf-datastores
      prefix:       ds
      reference:    RFC 8342

      name:         ietf-origin
      namespace:    urn:ietf:params:xml:ns:yang:ietf-origin
      prefix:       or
      reference:    RFC 8342

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

В этом документе обсуждается архитектурная модель для хранилищ данных сетевого управления, используемых протоколами NETCONF/RESTCONF и языком YANG. Это не оказывает влияния на безопасность Internet.

Хотя в этом документе заданы модули YANG, эти модули определяют лишь отождествления и аннотацию метаданных. По этой причине рекомендации по безопасности YANG [YANG-SEC] не используются.

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

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

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

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

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

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

[RFC7952] Lhotka, L., «Defining and Using Metadata with YANG», RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.

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

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

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

[NETMOD-Operational] Bjorklund, M. and L. Lhotka, «Operational Data in NETCONF and YANG», Work in Progress, draft-bjorklund-netmod-operational-00, October 2012.

[OpState-Enhance] Watsen, K., Bierman, A., Bjorklund, M., and J. Schoenwaelder, «Operational State Enhancements for YANG, NETCONF, and RESTCONF», Work in Progress, draft-kwatsen-netmod-opstate-02, February 2016.

[OpState-Modeling] Shakir, R., Shaikh, A., and M. Hines, «Consistent Modeling of Operational State Data in YANG», Work in Progress, draft-openconfig-netmod-opstate-01, July 2015.

[OpState-Reqs] Watsen, K. and T. Nadeau, «Terminology and Requirements for Enhanced Handling of Operational State», Work in Progress, draft-ietf-netmod-opstate-reqs-04, January 2016.

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

[RFC6244] Shafer, P., «An Architecture for Network Management Using NETCONF and YANG», RFC 6244, DOI 10.17487/RFC6244, June 2011, <https://www.rfc-editor.org/info/rfc6244>.

[RFC8343] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8344] Bjorklund, M., «A YANG Data Model for IP Management», RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

[With-config-state] Wilton, R., «»With-config-state» Capability for NETCONF/RESTCONF», Work in Progress, draft-wilton-netmod-opstate-yang-02, December 2015.

[YANG-SEC] IETF, «YANG Security Guidelines», <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>.

Приложение A. Рекомендации по определению хранилищ

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

A.1. Определение модулей YANG, применимых для хранилища

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

A.2. Определение применимого подмножества операторов YANG

По умолчанию данные в хранилище моделируются с использованием всех операторов YANG в доступных модулях YANG. Однако возможно задание критериев, которым должны удовлетворять операторы YANG для включения в хранилище. Например, могут разрешаться только узлы config true или узлы config false, имеющие конкретное расширение YANG.

A.3. Определение способов актуализации данных

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

Например, рисунок 2 показывает хранилища динамической конфигурации, подаваемые в хранилище <operational>. Способ такой передачи определяет конкретным хранилищем динамической конфигурации. В некоторых случаях это может происходить неявно просто при попадании данных в хранилище динамической конфигурации, а в других случаях может потребоваться явное действие (например, RPC).

A.4. Определение применимых протоколов

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

A.5. Определение отождествлений YANG для хранилища

Хранилище жлджно быть определено с использованием отождествления YANG, использующего ds:datastore или одно из производных от него отождествлений. Это отождествление требуется, чтобы по по нему можно было ссылаться на хранилище в операциях протокола (например, <get-data>).

Хранилище может быть также определено с использованием в качестве базы отождествления or:origin или производного от него отождествления. Такое отождествление требуется, если хранилище взаимодействует с <operational>, чтобы по нему можно указать хранилище в атрибуте метаданных origin, определенном в разделе 7.

Примеры использования этих рекомендаций приведены в Приложении B.

Приложение B. Пример эфемерного хранилища

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

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

Свойства примера «эфемерного» хранилища

Имя

Значение

Name

ephemeral

YANG modules

all (default)

YANG nodes

all «config true» data nodes

How applied

changes automatically propagated to <operational>

Protocols

NETCONF/RESTCONF (default)

Defining YANG module

«example-ds-ephemeral»

   module example-ds-ephemeral {
     yang-version 1.1;
     namespace "urn:example:ds-ephemeral";
     prefix eph;

     import ietf-datastores {
       prefix ds;
     }
     import ietf-origin {
       prefix or;
     }

     // datastore identity
     identity ds-ephemeral {
       base ds:dynamic;
       description
         "The ephemeral dynamic configuration datastore.";
     }

     // origin identity
     identity or-ephemeral {
       base or:dynamic;
       description
         "Denotes data from the ephemeral dynamic configuration
          datastore.";
     }
   }

Приложение C. Примеры

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

Фрагменты XML [W3C.REC-xml-20081126] представлены лишь для иллюстрации.

C.1. Пример хранилища System

Ниже показан используемый в примере функциональный модуль.

   module example-system {
     yang-version 1.1;
     namespace urn:example:system;
     prefix sys;

     import ietf-inet-types {
       prefix inet;
     }

     container system {
       leaf hostname {
         type string;
       }

       list interface {
         key name;

         leaf name {
           type string;
         }

         container auto-negotiation {
           leaf enabled {
             type boolean;
             default true;
           }
           leaf speed {
             type uint32;
             units mbps;
             description
               "The advertised speed, in Mbps.";
           }
         }

         leaf speed {
           type uint32;
           units mbps;
           config false;
           description
             "The speed of the interface, in Mbps.";
         }

         list address {
           key ip;

           leaf ip {
             type inet:ip-address;
           }
           leaf prefix-length {
             type uint8;
           }
         }
       }
     }
   }

Оператор настроил имя хоста и два интерфейса и хранилище <intended> имеет вид

   <system xmlns="urn:example:system">

     <hostname>foo.example.com</hostname>

     <interface>
       <name>eth0</name>
       <auto-negotiation>
         <speed>1000</speed>
       </auto-negotiation>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface>
       <name>eth1</name>
       <address>
         <ip>2001:db8::20</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

   </system>

Система обнаружила, что аппаратная часть одного из настроенных интерфейсов (eth1) еще отсутствует, поэтому настройка данного интерфейса не была применена. После этого система получила имя хоста и дополнительный адрес IP для eth0 по протоколу DHCP. В дополнение к установке принятого по умолчанию значения для листа управления автоматическим согласованием (auto-negotiation) в системе также автоматически создан интерфейс loopback. Все упомянутое нашло отражение в хранилище <operational>. Отметим, что атрибут метаданных origin для некоторых узлов данных config true унаследован от их родителей.

   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>

C.2. Пример BGP

Рассмотрим фрагмент функционального модуля BGP

       container bgp {
         leaf local-as {
           type uint32;
         }
         leaf peer-as {
           type uint32;
         }
         list peer {
           key name;
           leaf name {
             type inet:ip-address;
           }
           leaf local-as {
             type uint32;
             description
               "... Defaults to ../local-as.";
           }
           leaf peer-as {
             type uint32;
             description
               "... Defaults to ../peer-as.";
           }
           leaf local-port {
             type inet:port;
           }
           leaf remote-port {
             type inet:port;
             default 179;
           }
           leaf state {
             config false;
             type enumeration {
               enum init;
               enum established;
               enum closing;
             }
           }
         }
       }

В этой модели оба узла bgp/peer/local-as и bgp/peer/peer-as имеют комплексные иерархические значения, позволяя пользователю задать используемые по умолчанию значения для всех партнеров в одном месте.

Модель также следует шаблону полного объединения узлов состояния (config false) и узлов конфигурации (config true). Здесь нет отдельной иерархии bgp-state и связанного с ней повтора узлов сдерживания ограничений и именования. Это делает модель более простой и удобочитаемой.

C.2.1. Хранилища данных

Каждое хранилище дает разные представления этих узлов. Хранилище <running> будет содержать конфигурацию, заданную оператором (например, один партнер BGP). Хранилище <intended> концептуально будет содержать все проверенные на пригодность данные после исключения не предназначенных для такой проверки данных и выполнения всех локальных механизмов преобразования шаблонов. Хранилище <operational> будет показывать данные из <intended>, а также все узлы config false.

C.2.2. Добавление партнера

Если уператор указал одного партнера BGP, этот партнер будет виден в обоих хранилищах <running> и <intended>. Он может также присутствовать в <candidate>, если сервер поддерживает хранилище для будущих конфигураций. Поиск партнера будет возвращать только заданные пользователем значения.

Между появлением партнера в хранилищах <running> и <intended> не должно быть задержки.

Добавим в хранилище <running> представленную ниже информацию.

     <bgp>
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
       </peer>
     </bgp>
C.2.2.1. Хранилище <operational>

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

Кроме того, хранилище <operational> будет содержать реально используемые (currently in use) значения для всех узлов. Это значит, что local-as и peer-as будут запролнены даже в том случае, когда их значения не заданы в <intended>. При отсутствии bgp/peer/local-as будет использовано значение bgp/local-as, а при отсутствии bgp/peer/peer-as — bgp/peer-as. В операционном представлении это означает, что каждый партнер будет иметь значения для своих local-as и peer-as, даже если эти значения не будут заданы явно, но будут представлены в bgp/local-as и bgp/peer-as.

Каждый из партнеров BGP имеет связанное с ним соединение TCP, использующее значения local-port и remote-port из <intended>. Если эти значения не представлены, они будут выбраны системой. После организации соединения хранилище <operational> будет содержать текущие значения для local-port и remote-port, независимо от их происхождения. Если значения выбраны системой, атрибут origin будет указывать system. Перед организацией соединения один или оба узла могут отсутствовать, поскольку система может еще не иметь их значений.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>established</state>
       </peer>
     </bgp>

C.2.3. Удаление партнера

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

Рассмотрим сценарий с удалением партнера BGP. В этом случае операционное состояние будет по-прежнему отражать наличие этого партнера до тех пор, пока не будут освобождены ресурсы закрываемого партнерского соединения. В течение переходного периода текущие значения данных будут видны в хранилище <operational> с атрибутом origin, указывающим происхождение исходных данных.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>closing</state>
       </peer>
     </bgp>

После освобождения ресурсов и закрытия соединения данные о партнере удаляются из хранилища <operational>.

C.3. Пример интерфейса

В этом параграфе используется простая модель данных интерфейса.

     container interfaces {
       list interface {
         key name;
         leaf name {
           type string;
         }
         leaf description {
           type string;
         }
         leaf mtu {
           type uint16;
         }
         leaf-list ip-address {
           type inet:ip-address;
         }
       }
     }

C.3.1. Заранее представленные интерфейсы

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

Если клиент создает интерфейс et-0/0/0, которого в этот момент нет физически, хранилище <intended> может содержать представленную ниже информацию.

     <interfaces>
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
       </interface>
     </interfaces>

Поскольку интерфейса нет, эти данные не будут присутствовать в хранилище <operational>.

При установке FRU с этим интерфейсом система обнаружит его и обработает соответствующую конфигурацию. Хранилище <operational> будет содержать данные из <intended>, а также узлы, добавленные системой типа текущего значения MTU для интерфейса.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
         <mtu or:origin="or:system">1500</mtu>
       </interface>
     </interfaces>

Если FRU удаляется, данные интерфейса исключаются из хранилища <operational>.

C.3.2. Предоставляемые системой интерфейсы

Рассмотрим систему, предоставляющую петлевой интерфейс lo0 с принятым по умолчанию адресом IPv4 127.0.0.1 и IPv6 ::1. Система будет обеспечивать конфигурацию для этого интерфейса, если для него нет данных в <intended>.

При отсутствии конфигурации для lo0 в хранилище <intended>, <operational> будет показывать предоставляемые системой данные.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface or:origin="or:system">
         <name>lo0</name>
         <ip-address>127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

Если конфигурация для lo0 имеется в <intended>, хранилище <operational> будет показывать эти данные с источником intended. Если значение ip-address не было задано, предоставленные системой значения будут иметь вид

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>lo0</name>
         <description>loopback</description>
         <ip-address or:origin="or:system">127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

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

Этот документ является результвтом многочисленных обсуждений, тянувшихся с 2010 года. Проблемы исходной модели хранилищ данных были рассмотрены в NETMOD-Operational] [With-config-state] [OpState-Reqs] [OpState-Enhance] [OpState-Modeling], а также [RFC6244]. Перечисленные ниже люди были авторами этих работ или внесли какой-либо иной вклад в создание этого документа.

Работа Juergen Schoenwaelder частично финансировалась в рамках Flamingo — проекта Network of Excellence (ICT-318488), поддерживаемого Европейской комиссией про программе Seventh Framework.

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

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Juergen Schoenwaelder

Jacobs University

Email: j.schoenwaelder@jacobs-university.de

Phil Shafer

Juniper Networks

Email: phil@juniper.net

Kent Watsen

Juniper Networks

Email: kwatsen@juniper.net

Robert Wilton

Cisco Systems

Email: rwilton@cisco.com


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

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

nmalykh@gmail.com

1Network Configuration Protocol — протокол настройки сети.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4XML Path Language — язык путей XML.

5Forwarding and Control Element Separation — разделение элементов пересылки и управления.

6Field Replaceable Unit — заменяемый в процессе работы блок.




RFC 8344 A YANG Data Model for IP Management

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8344                                Tail-f Systems
Obsoletes: 7277                                               March 2018
Category: Standards Track
ISSN: 2070-1721

Модель данных YANG для управления IP

A YANG Data Model for IP Management

PDF

Тезисы

Этот документ определяет модель данных YANG для управления реализациями IP. Модель включает данные конфигурации и состояния системы.

Модель данных YANG в этом документе соответствует архитектуре хранилища данных сетевого управления NMDA1, определенной в RFC 8342.

Документ отменяет действие RFC 7277.

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

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

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

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

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

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

Этот документ определяет модель данных YANG [RFC7950] для управления реализациями IP.

Модель данных охватывает конфигурацию параметров IPv4 и IPv6 на уровне интерфейсов, а также отображение адресов IP на адреса канального уровня. Модель также дает информацию об используемых в работе адресах IP и имеющихся отображениях канального уровня. Параметры на уровне интерфейсов добавлены путем дополнения (augmentation) модели данных интерфейса, определенной в [RFC8343].

Эта версия модели данных IP поддерживает архитектуру хранилищ NMDA [RFC8342].

1.1. Отличия от RFC 7277

Ветви (subtree) ipv4 и ipv6 с узлами данных config false в ветви /interfaces-state/interface отменены. Все узлы данных config false сейчас присутствуют в ветвях ipv4 и ipv6 субдерева /interfaces/interface.

Серверы, не поддерживающие NMDA или желающие работать с клиентами, не поддерживающими NMDA, могут реализовать отмененные ветви ipv4 и ipv6 в субдереве /interfaces-state/interface.

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

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

Перечисленные ниже термины определены в [RFC8342] и не определяются здесь заново.

  • client (клиент);

  • server (сервер);

  • configuration (конфигурация);

  • system state (состояние системы);

  • intended configuration (предполагаемая конфигурация);

  • running configuration datastore (хранилище данных рабочей конфигурации);

  • operational state (операционное состояние);

  • operational state datastore (хранилище данных операционного состояния).

Перечисленные ниже термины определены в [RFC7950] и не определяются здесь заново.

  • augment (дополнение, усиление);

  • data model (модель данных);

  • data node (узел данных).

Терминология для описания моделей YANG представлена в [RFC7950].

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

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

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

Этот документ определяет модуль YANG ietf-ip, который дополняет списки interface, определенные в модуле ietf-interfaces [RFC8343], связанными с IP узлами данных.

Структура узлов данных IP на уровне интерфейса, за исключением отмененных полей данных, приведена ниже.

   module: ietf-ip
     augment /if:interfaces/if:interface:
       +--rw ipv4!
       |  +--rw enabled?      boolean
       |  +--rw forwarding?   boolean
       |  +--rw mtu?          uint16
       |  +--rw address* [ip]
       |  |  +--rw ip               inet:ipv4-address-no-zone
       |  |  +--rw (subnet)
       |  |  |  +--:(prefix-length)
       |  |  |  |  +--rw prefix-length?   uint8
       |  |  |  +--:(netmask)
       |  |  |     +--rw netmask?         yang:dotted-quad
       |  |  |             {ipv4-non-contiguous-netmasks}?
       |  |  +--ro origin?          ip-address-origin
       |  +--rw neighbor* [ip]
       |     +--rw ip                    inet:ipv4-address-no-zone
       |     +--rw link-layer-address    yang:phys-address
       |     +--ro origin?               neighbor-origin
       +--rw ipv6!
          +--rw enabled?                     boolean
          +--rw forwarding?                  boolean
          +--rw mtu?                         uint32
          +--rw address* [ip]
          |  +--rw ip               inet:ipv6-address-no-zone
          |  +--rw prefix-length    uint8
          |  +--ro origin?          ip-address-origin
          |  +--ro status?          enumeration
          +--rw neighbor* [ip]
          |  +--rw ip                    inet:ipv6-address-no-zone
          |  +--rw link-layer-address    yang:phys-address
          |  +--ro origin?               neighbor-origin
          |  +--ro is-router?            empty
          |  +--ro state?                enumeration
          +--rw dup-addr-detect-transmits?   uint32
          +--rw autoconf
             +--rw create-global-addresses?        boolean
             +--rw create-temporary-addresses?     boolean
             |       {ipv6-privacy-autoconf}?
             +--rw temporary-valid-lifetime?       uint32
             |       {ipv6-privacy-autoconf}?
             +--rw temporary-preferred-lifetime?   uint32
                     {ipv6-privacy-autoconf}?

Модель определяет для интерфейса два контейнера — ipv4 и ipv6, представляющие семейства адресов IPv4 и IPv6. В каждом контейнере имеется лист enabled, который показывает разрешено ли семейство адресов на данном интерфейсе, и лист forwarding, показывающий разрешена ли пересылка пакетов IP данного семейства на этом интерфейсе. В каждом контейнере имеется также список адресов и список отображений адресов IP на адреса канального уровня.

3. Связь с IP-MIB

Если устройство реализует IP-MIB [RFC4293], каждая запись в списках ipv4/address и ipv6/address отобрахается в один из объектов ipAddressEntry, где ipAddressIfIndex указывает address в объеке для интерфейса.

IP-MIB определяет объекты для управления сообщениями IPv6 Router Advertisement. Соответствующие узла данных YANG определены в [RFC8022].

Записи ipv4/neighbor и ipv6/neighbor отображаются на ipNetToPhysicalTable.

Ниже приведена таблица соответствия узлов данных YANG объектам IP-MIB.

Узлы данных YANG для интерфейса и связанные объекты IP-MIB.

Узел данных YANG в /if:interfaces/if:interface

Объект IP-MIB

ipv4

ipv4InterfaceEnableStatus

ipv4/enabled

ipv4InterfaceEnableStatus

ipv4/address

ipAddressEntry

ipv4/address/ip

ipAddressAddrType

ipAddressAddr

ipv4/neighbor

ipNetToPhysicalEntry

ipv4/neighbor/ip

ipNetToPhysicalNetAddressType

ipNetToPhysicalNetAddress

ipv4/neighbor/link-layer-address

ipNetToPhysicalPhysAddress

ipv4/neighbor/origin

ipNetToPhysicalType

ipv6

ipv6InterfaceEnableStatus

ipv6/enabled

ipv6InterfaceEnableStatus

ipv6/forwarding

ipv6InterfaceForwarding

ipv6/address

ipAddressEntry

ipv6/address/ip

ipAddressAddrType

ipAddressAddr

ipv4/address/origin

ipAddressOrigin

ipv6/address/status

ipAddressStatus

ipv6/neighbor

ipNetToPhysicalEntry

ipv6/neighbor/ip

ipNetToPhysicalNetAddressType

ipNetToPhysicalNetAddress

ipv6/neighbor/link-layer-address

ipNetToPhysicalPhysAddress

ipv6/neighbor/origin

ipNetToPhysicalType

ipv6/neighbor/state

ipNetToPhysicalState

4. Модуль YANG для управления IP

Этот модуль импортирует определения типов (typedef) из [RFC6991] и [RFC8343], а они ссылаются на [RFC791], [RFC826], [RFC4861], [RFC4862], [RFC4941], [RFC7217] и [RFC8200].

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

     import ietf-interfaces {
       prefix if;
     }
     import ietf-inet-types {
       prefix inet;
     }
     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NETMOD (Network Modeling) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
        WG List:  <mailto:netmod@ietf.org>

        Editor:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>";
     description
       "This module contains a collection of YANG definitions for
        managing IP implementations.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8344; see
        the RFC itself for full legal notices.";

     revision 2018-02-22 {
       description
         "Updated to support NMDA.";
       reference
         "RFC 8344: A YANG Data Model for IP Management";
     }

     revision 2014-06-16 {
       description
         "Initial revision.";
       reference
         "RFC 7277: A YANG Data Model for IP Management";
     }

     /*
      * Функции
      */

     feature ipv4-non-contiguous-netmasks {
       description
         "Indicates support for configuring non-contiguous
          subnet masks.";
     }

     feature ipv6-privacy-autoconf {
       description
         "Indicates support for privacy extensions for stateless address
          autoconfiguration in IPv6.";
       reference
         "RFC 4941: Privacy Extensions for Stateless Address
                    Autoconfiguration in IPv6";
     }

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

     typedef ip-address-origin {
       type enumeration {
         enum other {
           description
             "None of the following.";
         }
         enum static {
           description
             "Indicates that the address has been statically
              configured -- for example, using the Network Configuration
              Protocol (NETCONF) or a command line interface.";
         }
         enum dhcp {
           description
             "Indicates an address that has been assigned to this
              system by a DHCP server.";
         }
         enum link-layer {
           description
             "Indicates an address created by IPv6 stateless
              autoconfiguration that embeds a link-layer address in its
              interface identifier.";
         }
         enum random {
           description
             "Indicates an address chosen by the system at
              random, e.g., an IPv4 address within 169.254/16, a
              temporary address as described in RFC 4941, or a
              semantically opaque address as described in RFC 7217.";
           reference
             "RFC 4941: Privacy Extensions for Stateless Address
                        Autoconfiguration in IPv6
              RFC 7217: A Method for Generating Semantically Opaque
                        Interface Identifiers with IPv6 Stateless
                        Address Autoconfiguration (SLAAC)";
         }
       }
       description
         "The origin of an address.";
     }

     typedef neighbor-origin {
       type enumeration {
         enum other {
           description
             "None of the following.";
         }
         enum static {
           description
             "Indicates that the mapping has been statically
              configured -- for example, using NETCONF or a command line
              interface.";
         }

         enum dynamic {
           description
             "Indicates that the mapping has been dynamically resolved
              using, for example, IPv4 ARP or the IPv6 Neighbor
              Discovery protocol.";
         }
       }
       description
         "The origin of a neighbor entry.";
     }


     /*
      * Узлы данных
      */

     augment "/if:interfaces/if:interface" {
       description
         "IP parameters on interfaces.

          If an interface is not capable of running IP, the server
          must not allow the client to configure these parameters.";

       container ipv4 {
         presence
           "Enables IPv4 unless the 'enabled' leaf
            (which defaults to 'true') is set to 'false'";
         description
           "Parameters for the IPv4 address family.";

         leaf enabled {
           type boolean;
           default true;
           description
             "Controls whether IPv4 is enabled or disabled on this
              interface.  When IPv4 is enabled, this interface is
              connected to an IPv4 stack, and the interface can send
              and receive IPv4 packets.";
         }
         leaf forwarding {
           type boolean;
           default false;
           description
             "Controls IPv4 packet forwarding of datagrams received by,
              but not addressed to, this interface.  IPv4 routers
              forward datagrams.  IPv4 hosts do not (except those
              source-routed via the host).";
         }
         leaf mtu {
           type uint16 {
             range "68..max";
           }
           units "octets";
           description
             "The size, in octets, of the largest IPv4 packet that the
              interface will send and receive.

              The server may restrict the allowed values for this leaf,
              depending on the interface's type.

              If this leaf is not configured, the operationally used MTU
              depends on the interface's type.";
           reference
             "RFC 791: Internet Protocol";
         }
         list address {
           key "ip";
           description
             "The list of IPv4 addresses on the interface.";
           leaf ip {
             type inet:ipv4-address-no-zone;
             description
               "The IPv4 address on the interface.";
           }
           choice subnet {
             mandatory true;
             description
               "The subnet can be specified as a prefix length or,
                if the server supports non-contiguous netmasks, as
                a netmask.";
             leaf prefix-length {
               type uint8 {
                 range "0..32";
               }
               description
                 "The length of the subnet prefix.";
             }

             leaf netmask {
               if-feature ipv4-non-contiguous-netmasks;
               type yang:dotted-quad;
               description
                 "The subnet specified as a netmask.";
             }
           }
           leaf origin {
             type ip-address-origin;
             config false;
             description
               "The origin of this address.";
           }
         }
         list neighbor {
           key "ip";
           description
             "A list of mappings from IPv4 addresses to
              link-layer addresses.

              Entries in this list in the intended configuration are
              used as static entries in the ARP Cache.

              In the operational state, this list represents the ARP
              Cache.";
           reference
             "RFC 826: An Ethernet Address Resolution Protocol";

           leaf ip {
             type inet:ipv4-address-no-zone;
             description
               "The IPv4 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             mandatory true;
             description
               "The link-layer address of the neighbor node.";
           }
           leaf origin {
             type neighbor-origin;
             config false;
             description
               "The origin of this neighbor entry.";
           }
         }
       }

       container ipv6 {
         presence
           "Enables IPv6 unless the 'enabled' leaf
            (which defaults to 'true') is set to 'false'";
         description
           "Parameters for the IPv6 address family.";

         leaf enabled {
           type boolean;
           default true;
           description
             "Controls whether IPv6 is enabled or disabled on this
              interface.  When IPv6 is enabled, this interface is
              connected to an IPv6 stack, and the interface can send
              and receive IPv6 packets.";
         }
         leaf forwarding {
           type boolean;
           default false;
           description
             "Controls IPv6 packet forwarding of datagrams received by,
              but not addressed to, this interface.  IPv6 routers
              forward datagrams.  IPv6 hosts do not (except those
              source-routed via the host).";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                        Section 6.2.1, IsRouter";
         }
         leaf mtu {
           type uint32 {
             range "1280..max";
           }
           units "octets";
           description
             "The size, in octets, of the largest IPv6 packet that the
              interface will send and receive.

              The server may restrict the allowed values for this leaf,
              depending on the interface's type.

              If this leaf is not configured, the operationally used MTU
              depends on the interface's type.";
           reference
             "RFC 8200: Internet Protocol, Version 6 (IPv6)
                        Specification
                        Section 5";
         }

         list address {
           key "ip";
           description
             "The list of IPv6 addresses on the interface.";

           leaf ip {
             type inet:ipv6-address-no-zone;
             description
               "The IPv6 address on the interface.";
           }
           leaf prefix-length {
             type uint8 {
               range "0..128";
             }
             mandatory true;
             description
               "The length of the subnet prefix.";
           }
           leaf origin {
             type ip-address-origin;
             config false;
             description
               "The origin of this address.";
           }
           leaf status {
             type enumeration {
               enum preferred {
                 description
                   "This is a valid address that can appear as the
                    destination or source address of a packet.";
               }
               enum deprecated {
                 description
                   "This is a valid but deprecated address that should
                    no longer be used as a source address in new
                    communications, but packets addressed to such an
                    address are processed as expected.";
               }
               enum invalid {
                 description
                   "This isn't a valid address, and it shouldn't appear
                    as the destination or source address of a packet.";
               }

               enum inaccessible {
                 description
                   "The address is not accessible because the interface
                    to which this address is assigned is not
                    operational.";
               }
               enum unknown {
                 description
                   "The status cannot be determined for some reason.";
               }

               enum tentative {
                 description
                   "The uniqueness of the address on the link is being
                    verified.  Addresses in this state should not be
                    used for general communication and should only be
                    used to determine the uniqueness of the address.";
               }
               enum duplicate {
                 description
                   "The address has been determined to be non-unique on
                    the link and so must not be used.";
               }
               enum optimistic {
                 description
                   "The address is available for use, subject to
                    restrictions, while its uniqueness on a link is
                    being verified.";
               }
             }
             config false;
             description
               "The status of an address.  Most of the states correspond
                to states from the IPv6 Stateless Address
                Autoconfiguration protocol.";
             reference
               "RFC 4293: Management Information Base for the
                          Internet Protocol (IP)
                          - IpAddressStatusTC
                RFC 4862: IPv6 Stateless Address Autoconfiguration";
           }
         }

         list neighbor {
           key "ip";
           description
             "A list of mappings from IPv6 addresses to
              link-layer addresses.

              Entries in this list in the intended configuration are
              used as static entries in the Neighbor Cache.

              In the operational state, this list represents the
              Neighbor Cache.";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";

           leaf ip {
             type inet:ipv6-address-no-zone;
             description
               "The IPv6 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             mandatory true;
             description
               "The link-layer address of the neighbor node.

                In the operational state, if the neighbor's 'state' leaf
                is 'incomplete', this leaf is not instantiated.";
           }
           leaf origin {
             type neighbor-origin;
             config false;
             description
               "The origin of this neighbor entry.";
           }
           leaf is-router {
             type empty;
             config false;
             description
               "Indicates that the neighbor node acts as a router.";
           }

           leaf state {
             type enumeration {
               enum incomplete {
                 description
                   "Address resolution is in progress, and the
                    link-layer address of the neighbor has not yet been
                    determined.";
               }
               enum reachable {
                 description
                   "Roughly speaking, the neighbor is known to have been
                    reachable recently (within tens of seconds ago).";
               }
               enum stale {
                 description
                   "The neighbor is no longer known to be reachable, but
                    until traffic is sent to the neighbor no attempt
                    should be made to verify its reachability.";
               }
               enum delay {
                 description
                   "The neighbor is no longer known to be reachable, and
                    traffic has recently been sent to the neighbor.
                    Rather than probe the neighbor immediately, however,
                    delay sending probes for a short while in order to
                    give upper-layer protocols a chance to provide
                    reachability confirmation.";
               }
               enum probe {
                 description
                   "The neighbor is no longer known to be reachable, and
                    unicast Neighbor Solicitation probes are being sent
                    to verify reachability.";
               }
             }
             config false;
             description
               "The Neighbor Unreachability Detection state of this
                entry.";
             reference
               "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                          Section 7.3.2";
           }
         }

         leaf dup-addr-detect-transmits {
           type uint32;
           default 1;
           description
             "The number of consecutive Neighbor Solicitation messages
              sent while performing Duplicate Address Detection on a
              tentative address.  A value of zero indicates that
              Duplicate Address Detection is not performed on
              tentative addresses.  A value of one indicates a single
              transmission with no follow-up retransmissions.";
           reference
             "RFC 4862: IPv6 Stateless Address Autoconfiguration";
         }
         container autoconf {
           description
             "Parameters to control the autoconfiguration of IPv6
              addresses, as described in RFC 4862.";
           reference
             "RFC 4862: IPv6 Stateless Address Autoconfiguration";

           leaf create-global-addresses {
             type boolean;
             default true;
             description
               "If enabled, the host creates global addresses as
                described in RFC 4862.";
             reference
               "RFC 4862: IPv6 Stateless Address Autoconfiguration
                          Section 5.5";
           }
           leaf create-temporary-addresses {
             if-feature ipv6-privacy-autoconf;
             type boolean;
             default false;
             description
               "If enabled, the host creates temporary addresses as
                described in RFC 4941.";
             reference
               "RFC 4941: Privacy Extensions for Stateless Address
                          Autoconfiguration in IPv6";
           }
           leaf temporary-valid-lifetime {
             if-feature ipv6-privacy-autoconf;
             type uint32;
             units "seconds";
             default 604800;
             description
               "The time period during which the temporary address
                is valid.";
             reference
               "RFC 4941: Privacy Extensions for Stateless Address
                          Autoconfiguration in IPv6
                          - TEMP_VALID_LIFETIME";
           }
           leaf temporary-preferred-lifetime {
             if-feature ipv6-privacy-autoconf;
             type uint32;
             units "seconds";
             default 86400;
             description
               "The time period during which the temporary address is
                preferred.";
             reference
               "RFC 4941: Privacy Extensions for Stateless Address
                          Autoconfiguration in IPv6
                          - TEMP_PREFERRED_LIFETIME";
           }
         }
       }
     }

     /*
      * Унаследованные узлы данных операционных состояний
      */

     augment "/if:interfaces-state/if:interface" {
       status deprecated;
       description
         "Data nodes for the operational state of IP on interfaces.";

       container ipv4 {
         presence
           "Present if IPv4 is enabled on this interface";
         config false;
         status deprecated;
         description
           "Interface-specific parameters for the IPv4 address family.";

         leaf forwarding {
           type boolean;
           status deprecated;
           description
             "Indicates whether IPv4 packet forwarding is enabled or
              disabled on this interface.";
         }
         leaf mtu {
           type uint16 {
             range "68..max";
           }
           units "octets";
           status deprecated;
           description
             "The size, in octets, of the largest IPv4 packet that the
              interface will send and receive.";
           reference
             "RFC 791: Internet Protocol";
         }

         list address {
           key "ip";
           status deprecated;
           description
             "The list of IPv4 addresses on the interface.";

           leaf ip {
             type inet:ipv4-address-no-zone;
             status deprecated;
             description
               "The IPv4 address on the interface.";
           }

           choice subnet {
             status deprecated;
             description
               "The subnet can be specified as a prefix length or,
                if the server supports non-contiguous netmasks, as
                a netmask.";
             leaf prefix-length {
               type uint8 {
                 range "0..32";
               }
               status deprecated;
               description
                 "The length of the subnet prefix.";
             }
             leaf netmask {
               if-feature ipv4-non-contiguous-netmasks;
               type yang:dotted-quad;
               status deprecated;
               description
                 "The subnet specified as a netmask.";
             }
           }
           leaf origin {
             type ip-address-origin;
             status deprecated;
             description
               "The origin of this address.";
           }
         }
         list neighbor {
           key "ip";
           status deprecated;
           description
             "A list of mappings from IPv4 addresses to
              link-layer addresses.

              This list represents the ARP Cache.";
           reference
             "RFC 826: An Ethernet Address Resolution Protocol";

           leaf ip {
             type inet:ipv4-address-no-zone;
             status deprecated;
             description
               "The IPv4 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             status deprecated;
             description
               "The link-layer address of the neighbor node.";
           }
           leaf origin {
             type neighbor-origin;
             status deprecated;
             description
               "The origin of this neighbor entry.";
           }
         }
       }


       container ipv6 {
         presence
           "Present if IPv6 is enabled on this interface";
         config false;
         status deprecated;
         description
           "Parameters for the IPv6 address family.";

         leaf forwarding {
           type boolean;
           default false;
           status deprecated;
           description
             "Indicates whether IPv6 packet forwarding is enabled or
              disabled on this interface.";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                        Section 6.2.1, IsRouter";
         }
         leaf mtu {
           type uint32 {
             range "1280..max";
           }
           units "octets";
           status deprecated;
           description
             "The size, in octets, of the largest IPv6 packet that the
              interface will send and receive.";
           reference
             "RFC 8200: Internet Protocol, Version 6 (IPv6)
                        Specification
                        Section 5";
         }

         list address {
           key "ip";
           status deprecated;
           description
             "The list of IPv6 addresses on the interface.";

           leaf ip {
             type inet:ipv6-address-no-zone;
             status deprecated;
             description
               "The IPv6 address on the interface.";
           }
           leaf prefix-length {
             type uint8 {
               range "0..128";
             }
             mandatory true;
             status deprecated;
             description
               "The length of the subnet prefix.";
           }
           leaf origin {
             type ip-address-origin;
             status deprecated;
             description
               "The origin of this address.";
           }
           leaf status {
             type enumeration {
               enum preferred {
                 description
                   "This is a valid address that can appear as the
                    destination or source address of a packet.";
               }
               enum deprecated {
                 description
                   "This is a valid but deprecated address that should
                    no longer be used as a source address in new
                    communications, but packets addressed to such an
                    address are processed as expected.";
               }
               enum invalid {
                 description
                   "This isn't a valid address, and it shouldn't appear
                    as the destination or source address of a packet.";
               }

               enum inaccessible {
                 description
                   "The address is not accessible because the interface
                    to which this address is assigned is not
                    operational.";
               }
               enum unknown {
                 description
                   "The status cannot be determined for some reason.";
               }
               enum tentative {
                 description
                   "The uniqueness of the address on the link is being
                    verified.  Addresses in this state should not be
                    used for general communication and should only be
                    used to determine the uniqueness of the address.";
               }
               enum duplicate {
                 description
                   "The address has been determined to be non-unique on
                    the link and so must not be used.";
               }
               enum optimistic {
                 description
                   "The address is available for use, subject to
                    restrictions, while its uniqueness on a link is
                    being verified.";
               }
             }
             status deprecated;
             description
               "The status of an address.  Most of the states correspond
                to states from the IPv6 Stateless Address
                Autoconfiguration protocol.";
             reference
               "RFC 4293: Management Information Base for the
                          Internet Protocol (IP)
                          - IpAddressStatusTC
                RFC 4862: IPv6 Stateless Address Autoconfiguration";
           }
         }

         list neighbor {
           key "ip";
           status deprecated;
           description
             "A list of mappings from IPv6 addresses to
              link-layer addresses.

              This list represents the Neighbor Cache.";
           reference
             "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)";

           leaf ip {
             type inet:ipv6-address-no-zone;
             status deprecated;
             description
               "The IPv6 address of the neighbor node.";
           }
           leaf link-layer-address {
             type yang:phys-address;
             status deprecated;
             description
               "The link-layer address of the neighbor node.";
           }
           leaf origin {
             type neighbor-origin;
             status deprecated;
             description
               "The origin of this neighbor entry.";
           }
           leaf is-router {
             type empty;
             status deprecated;
             description
               "Indicates that the neighbor node acts as a router.";
           }
           leaf state {
             type enumeration {
               enum incomplete {
                 description
                   "Address resolution is in progress, and the
                    link-layer address of the neighbor has not yet been
                    determined.";
               }
               enum reachable {
                 description
                   "Roughly speaking, the neighbor is known to have been
                    reachable recently (within tens of seconds ago).";
               }

               enum stale {
                 description
                   "The neighbor is no longer known to be reachable, but
                    until traffic is sent to the neighbor no attempt
                    should be made to verify its reachability.";
               }
               enum delay {
                 description
                   "The neighbor is no longer known to be reachable, and
                    traffic has recently been sent to the neighbor.
                    Rather than probe the neighbor immediately, however,
                    delay sending probes for a short while in order to
                    give upper-layer protocols a chance to provide
                    reachability confirmation.";
               }
               enum probe {
                 description
                   "The neighbor is no longer known to be reachable, and
                    unicast Neighbor Solicitation probes are being sent
                    to verify reachability.";
               }
             }
             status deprecated;
             description
               "The Neighbor Unreachability Detection state of this
                entry.";
             reference
               "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                          Section 7.3.2";
           }
         }
       }
     }
   }
   <CODE ENDS>

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

Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688]. В соответствии с форматом RFC 3688 выполнены перечисленные ниже регистрации.

      URI: urn:ietf:params:xml:ns:yang:ietf-ip
      Registrant Contact: The NETMOD WG of the IETF.
      XML: N/A; the requested URI is an XML namespace.

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].

      Name:         ietf-ip
      Namespace:    urn:ietf:params:xml:ns:yang:ietf-ip
      Prefix:       ip
      Reference:    RFC 8344

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

Описанный в этом документе модуль YANG определяет схему для данных, доступ к которым выполняется с помощью протоколов сетевого управления типа NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспортный уровень с обязательной реализациией защищенного транспорта SSH4 [RFC6242]. Нижним уровнем RESTCONF является HTTPS с обязательной для реализацией транспорта TLS [RFC5246].

Модель управления доступом NETCONF [RFC8341] обеспечивает меры по ограничению доступа для отдельных пользователей NETCONF или RESTCONF предопределенным подмножеством всех доступных операций и содержимого NETCONF или RESTCONF.

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

ipv4/enabled и ipv6/enabled

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

ipv4/address и ipv6/address

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

ipv4/forwarding и ipv6/forwarding

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

ipv6/autoconf

Листья в этой ветви управляют автоматической настройкой адресов IPv6 и, в частности, возможностью использования временных адресов. Изменяя соответствующие листься, атакующий может влиять на адреса, применяемые узлом и, опосредованно, на приватность пользователей узла.

ipv4/mtu и ipv6/mtu

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

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

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

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

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

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

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

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

[RFC4941] Narten, T., Draves, R., and S. Krishnan, «Privacy Extensions for Stateless Address Autoconfiguration in IPv6», RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.

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

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

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

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

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

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

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

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

[RFC826] Plummer, D., «An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware», STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC4293] Routhier, S., Ed., «Management Information Base for the Internet Protocol (IP)», RFC 4293, DOI 10.17487/RFC4293, April 2006, <https://www.rfc-editor.org/info/rfc4293>.

[RFC7217] Gont, F., «A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)», RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>.

[RFC8022] Lhotka, L. and A. Lindem, «A YANG Data Model for Routing Management», RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>.

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

Прилежение A. Пример отклика NETCONF <get-config>

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

Фрагменты XML [W3C.REC-xml-20081126] в этом и следующем приложении даны лишь в качестве примеров.

   <rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data>
       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
         <interface>
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <address>
               <ip>192.0.2.1</ip>
               <prefix-length>24</prefix-length>
             </address>
           </ipv4>
           <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <mtu>1280</mtu>
             <address>
               <ip>2001:db8::10</ip>
               <prefix-length>32</prefix-length>
             </address>
             <dup-addr-detect-transmits>0</dup-addr-detect-transmits>
           </ipv6>
         </interface>
       </interfaces>
     </data>
   </rpc-reply>

Приложение B. Пример отклика NETCONF <get-data>

В этом приложении дан пример отклика на запрос NETCONF <get-data> для хранилища состояния на устройстве, поддерживающем описанную в этом документе модель данных.

В примере используется аннотация origin, определенная в модуле ietf-origin [RFC8342].

   <rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
           xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

         <interface or:origin="or:intended">
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <!-- other parameters from ietf-interfaces omitted -->

           <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <enabled or:origin="or:default">true</enabled>
             <forwarding or:origin="or:default">false</forwarding>
             <mtu or:origin="or:system">1500</mtu>
             <address>
               <ip>192.0.2.1</ip>
               <prefix-length>24</prefix-length>
               <origin>static</origin>
             </address>
             <neighbor or:origin="or:learned">
               <ip>192.0.2.2</ip>
               <link-layer-address>
                 00:00:5E:00:53:AB
               </link-layer-address>
             </neighbor>
           </ipv4>
           <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <enabled or:origin="or:default">true</enabled>
             <forwarding or:origin="or:default">false</forwarding>
             <mtu>1280</mtu>
             <address>
               <ip>2001:db8::10</ip>
               <prefix-length>32</prefix-length>
               <origin>static</origin>
               <status>preferred</status>
             </address>
             <address or:origin="or:learned">
               <ip>2001:db8::1:100</ip>
               <prefix-length>32</prefix-length>
               <origin>dhcp</origin>
               <status>preferred</status>
             </address>
             <dup-addr-detect-transmits>0</dup-addr-detect-transmits>
             <neighbor or:origin="or:learned">
               <ip>2001:db8::1</ip>
               <link-layer-address>
                 00:00:5E:00:53:AB
               </link-layer-address>
               <origin>dynamic</origin>
               <is-router/>
               <state>reachable</state>
             </neighbor>
             <neighbor or:origin="or:learned">
               <ip>2001:db8::4</ip>
               <origin>dynamic</origin>
               <state>incomplete</state>
             </neighbor>
           </ipv6>
         </interface>
       </interfaces>
     </data>
   </rpc-reply>

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

Автор благодарит Jeffrey Lange, Ladislav Lhotka, Juergen Schoenwaelder и Dave Thaler за их полезные комментарии.

Адрес автора

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com


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

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

nmalykh@gmail.com

1Network Management Datastore Architecture.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Secure Shell — защищенная среда выполнения команд.




RFC 8341 Network Configuration Access Control Model

Internet Engineering Task Force (IETF)                        A. Bierman
Request for Comments: 8341                                     YumaWorks
STD: 91                                                     M. Bjorklund
Obsoletes: 6536                                           Tail-f Systems
Category: Standards Track                                     March 2018
ISSN: 2070-1721

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

Network Configuration Access Control Model

PDF

Тезисы

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

Данный документ отменяет RFC 6536.

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF2 и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG3. Дополнительная информация о документах Internet Standard представлена в разделе 2 документа RFC 7841.

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

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

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

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

Оглавление

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

1. Введение

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

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

Этот документ решает вопросы управления доступом к операциям и содержимому протоколов NETCONF [RFC6241] и RESTCONF [RFC8040]. Документ включает три основных раздела.

  1. Цели управления доступом.

  2. Модель управления доступом для NETCONF (NACM).

  3. Модель данных YANG (ietf-netconf-acm.yang).

YANG версии 1.1 [RFC7950] добавляет две новых конструкции, для которых требуется специальный контроль доступа. Оператор action похож на оператор rpc, за исключением того, что он размещается в узле данных. Оператор notification также может размещаться в узле данных.

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

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

Приведенные ниже термины определены в [RFC8342] и не переопределяются здесь:

  • datastore — хранилище данных;

  • configuration datastore хранилище конфигурации;

  • conventional configuration datastore традиционное (обычное) хранилище данных конфигурации;

  • candidate configuration datastore хранилище будущей конфигурации, хранилище-кандидат;

  • running configuration datastore хранилище рабочей конфигурации;

  • startup configuration datastore хранилище стартовой конфигурации;

  • operational state datastore хранилище рабочего состояния;

  • client — клиент;

  • server — сервер.

Приведенные ниже термины определены в [RFC6241] и не переопределяются здесь:

  • protocol operation — протокольная операция;

  • session — сессия;

  • user — пользователь.

Приведенные ниже термины определены в [RFC7950] и не переопределяются здесь:

  • action — действие;

  • data node — узел данных;

  • data definition statement — оператор определения данных.

Приведенные ниже термины определены в [RFC8040] и не переопределяются здесь:

  • data resource — ресурс данных;

  • datastore resource — ресурс хранилища данных;

  • operation resource — операционный ресурс;

  • target resource — целевой ресурс.

Приведенный ниже термин определен в [RFC7230] и не переопределяется здесь:

  • request URI — идентификатор запроса.

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

access control – контроль доступа

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

access control model (ACM) – модель контроля доступа

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

access control rule – правило контроля доступа

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

access operation – операция доступа

Способ получения запросом доступа к концептуальному объекту (none — нет, read — чтение, create — создание, delete — удаление, update — обновление или execute — исполнение).

data node hierarchy и иерархия узла данных

Иерархия узлов данных, указывающая конкретный узел action или notification в хранилище данных.

recovery session – сеанс восстановления

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

write access – доступ для записи

Общее обозначение операций create, delete и update.

1.2. Отличия от RFC 6536

Процедуры и модель данных NACM были обновлены для поддержки новых возможностей моделирования в версии языка YANG 1.1. Операторы action и notification могут использоваться с узлами данных для определения операций и уведомлений в конкретной модели данных.

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

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

Было разъяснено поведение доступа к узлу данных при совпадении пути для включения соответствующих нисходящих узлов указанного пути.

Разъяснено поведение в части прав доступа к операции <edit-config> для указания того, что право записи не требуется для узлов данных, которые неявно меняются за счет побочных эффектов (типа вычисления операторов YANG when или неявного удаления при создании узла данных в другой ветви оператора YANG choice).

Раздел «Вопросы безопасности» был обновлен в соответствии с документом «YANG module security guidelines» [YANG-SEC]. Отметим, что модуль YANG в этом документе не определяет новых операций RPC.

2. Цели управления доступом

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

2.1. Точки управления доступом

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

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

Эти точки контроля показаны на рисунке 1 и кратко описаны ниже.

Протокольные операции

Разрешение на вызов конкретных операций протокола.

Хранилище данных

Разрешение считывать и/или изменять конкретные узлы данных внутри хранилища.

Уведомления

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

             +-------------+                 +-------------+
запрос       |протокольная |                 |  доступ к   |
клиента -->  |  операция   | ------------->  | узлу данных |
             | разрешена?  | хранилище данных|  разрешен?  |
             +-------------+ или доступ к    +-------------+
                             данным состояния

             +----------------+
             |  уведомление   |
событие -->  |  разрешено?    |
             +----------------+

Рисунок 1.

2.2. Простота

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

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

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

2.3. Процедурный интерфейс

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

2.4. Доступ к хранилищу данных

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

2.5. Пользователи и группы

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

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

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

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

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

2.7. Возможности настройки

Требуются подходящие механизмы настройки и управления, позволяющие упростить администратору все аспекты управления поведением ACM. Для этого нужна стандартная модель данных, подходящая для использования с протокольной операцией <edit-config>. Требуется поддержка правил управления доступом для ограничения доступа к конкретным субдеревьям внутри конфигурационного хранилища.

2.8. Идентификация требующего защиты содержимого

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

Чувствительные в плане безопасности объекты необходимо указывать в разделе RFC «Вопросы безопасности». Это хорошо, но не достаточно в силу приведенных ниже причин.

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

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

  • ACM на каждом сервере требуется настроить для снижения рисков безопасности, например, требуя привилегированного доступа к операциям чтения и записи для конкретных данных, указанных в разделе «Вопросы безопасности».

  • Если ACM не настроена заранее, возникает интервал уязвимости между загрузкой новой модели данных а настройкой, включением и отладкой новых правил контроля доступа для этой модели.

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

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

3. Модель управления доступом для NETCONF (NACM)

3.1. Обзор

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

3.1.1. Свойства

Возможности модели NACM перечислены ниже.

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

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

  • Используется просто и понятный набор разрешений для хранилища данных.

  • Поддержка меток безопасности YANG (например, оператор nacm:default-deny-write) позволяет автоматически исключать доступ к чувствительным данным по умолчанию.

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

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

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

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

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

3.1.2. Внешние зависимости

Для целей сетевого управления в этом документе используются протоколы NETCONF [RFC6241] и RESTCONF [RFC8040].

Язык моделирования данных YANG [RFC7950] служит для определения моделей данных, используемых с NETCONF или RESTCONF. YANG также используется для моделей данных в этом документе.

3.1.3. Модель обработки сообщения

На рисунке 1 показана концептуальная модель потока сообщений, включая точки, где применяется контроль доступа в процессе обработки сообщений NETCONF.

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

Прямоугольник pre-read data node acc. ctl на рисунке указывает групповой доступ для чтения, поскольку он относится к предкам узла данных для действия или уведомления. Например, если действие определено как /interfaces/interface/reset-interface, группа должна иметь полномочия (1) читать /interfaces и /interfaces/interface, а также (2) выполнять /interfaces/interface/reset-interface.

           +-------------------------+
           |        сессия           |
           |      (username)         |
           +-------------------------+
              |                 ^
              V                 |
    +--------------+     +---------------+
    | диспетчер    |     |  генератор    |
    | сообщений    |     |  сообщений    |
    +--------------+     +---------------+
      |      |               ^         ^
      |      V               |         |
      |  +=============+     |         |
      |  | pre-read    |     |         |
      |  | data node   |     |         |
      |  | acc. ctl    |     |         |
      |  +=============+     |         |
      |    |                 |         |
      V    V                 |         |
+===========+     +-------------+   +----------------+
| operation |---> |  генератор  |   |   генератор    |
| acc. ctl  |     |  откликов   |   | <notification> |
+===========+     +-------------+   +----------------+
      |              ^    ^                ^
      V       +------+    |                |
+-----------+ |   +=============+  +================+
| обработчик| |   |    read     |  | <notification> |
| операции  |-+   | data node   |  |  access ctl    |
|           |     | acc. ctl    |  |                |
+-----------+     +=============+  +================+
      |   |                  ^       ^     ^
      V   +----------------+ |       |     |
+===========+              | |       | +============+
|  write    |              | |       | | pre-read   |
| data node |              | |       | | data node  |
| acc. ctl  | -----------+ | |       | | acc. ctl   |
+===========+            | | |       | +============+
      |                  | | |       |   ^
      V                  V V |       |   |
+---------------+      +-------------------+
|   хранилище   | ---> |      server       |
|  конфигурации |      |  instrumentation  |
|               | <--- |                   |
+---------------+      +-------------------+

Рисунок 2.

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

  • Для каждой активной сессии контроль доступа выполняется индивидуально для всех сообщений <rpc> (кроме <close-session>), полученных сервером, если сессия не идентифицирована как восстановительная.

  • Если вызвана операция <action>, определенная в [RFC7950], доступ к чтению требуется для всех экземпляров в иерархии узлов данных, идентифицирующих указанное действие в хранилище данных, а также требуется доступ к исполнению для узла action. Если пользователь не имеет права читать все указанные узлы данных и выполнять действие, запрос отвергается с возвратом ошибки access-denied.

  • В остальных случаях, если пользователь не имеет права выполнять указанную операцию протокола, запрос отвергается с возвратом ошибки access-denied.

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

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

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

  • Если в субдереве данных задан оператор notification, как указано в [RFC7950], доступ к чтению требуется для всех экземпляров в иерархии узлов данных, идентифицирующих указанное уведомление в хранилище данных, а также к чтению узла notification. Если пользователь не имеет полномочий для чтения всех заданных узлов данных и узла notification, уведомление для этой подписки отбрасывается.

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

3.2. Доступ к хранилищу данных

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

Все обычные хранилища данных и рабочее хранилище контролируются NACM. Локальные и удаленные файлы или хранилища, доступ к которым осуществляется через параметр <url>, не контролируются NACM.

3.2.1. Отображение новых хранилищ данных в NACM

Возможно, что с течением времени будут определены новые хранилища данных для использования с NETCONF. NACM может применяться к другим хранилищам, в которых права доступа определены подобно NACM. Для применения NACM к новому хранилищу данных, для такого хранилища должно быть определено отображение на права доступа NACM CRUDX5. Возможно, что применима будет лишь часть прав доступа NACM. Например, для хранилищ с доступом только на чтение могут потребоваться лишь контроль поиска информации. Операции и права доступа, не поддерживающие модель NACM CRUDX, выходят за рамки этого документа. Хранилищу данных не требуется использовать NACM, например, спецификация хранилища может определять другой метод или не применять контроль доступа совсем.

3.2.2. Права доступа

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

Модель CRUDX может поддерживать все протокольные операции:

  • создание — позволяет клиенту добавлять новые экземпляры узлов данных в хранилище;

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

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

  • удаление — позволяет клиенту удалять экземпляры узлов данных из хранилища;

  • eXec — позволяет клиенту выполнять операции.

3.2.3. Методы RESTCONF

Протокол RESTCONF использует методы HTTP для выполнения операций с хранилищами данных, подобно протоколу NETCONF. Процедуры NACM разрабатывались для протокола NETCONF, поэтому методы RESTCONF были отображены на операции NETCONF для целей обработки контроля доступа. Процедуры исполнения правил, описанные в этом документе, применимы к обоим протоколам, если явно не указано иное.

При обработке запросов RESTCONF к ресурсам данных нужно рассматривать URI запросов, как описано ниже.

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

  • Для запросов PUT, PATCH и DELETE любые узлы данных, являющиеся предками узлов целевого ресурса, для целей контроля доступа на считаются частью запроса на редактирование. Операцией доступа для таких запросов считается none (нет операции). The edit begins at the target resource.

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

Контроль доступа применяется для всех запросов RESTCONF. В приведенной ниже таблице приведены сопоставления запросов с операциями протокола NETCONF. Значение none показывает, что операция NACM не применяется к данному методу RESTCONF.

Таблица 1. Сопоставление методов RESTCONF с NETCONF.

 

Метод

Класс ресурсов

Операция NETCONF

Операция доступа

OPTIONS

все

none

none

HEAD

все

<get>, <get-config>

read

GET

все

<get>, <get-config>

read

POST

хранилище, данные

<edit-config>

create

POST

операция

заданная операция

execute

PUT

данные

<edit-config>

create, update

PUT

хранилище

<copy-config>

update

PATCH

данные, хранилище

<edit-config>

update

DELETE

данные

<edit-config>

delete

 

3.2.4. Операции <get> и <get-config>

Права доступа NACM не связаны напрямую с протокольными операциями <get> и <get-config>, а применяются ко всем операциям <rpc>, которые приводить к операции read для целевого хранилища данных. В этом параграфе описано, как эти права доступа применяются к конкретным операциям доступа, поддерживаемым протокольными операциями <get> и <get-config>.

Узлы данных, к которым клиент не имеет доступа на чтение, просто опускаются вместе с их потомками из сообщения <rpc-reply>. Это деляется для того, чтобы обеспечить возможность корректной работы фильтров NETCONF для <get> и <get-config> вместо возврата ошибки access-denied в результате срабатывания фильтров при отсутствии полномочий на чтение некоторых узлов данных. Для целей фильтрации NETCONF критерии выбора применяются к подможеству узлов, которые пользователь имеет право читать, а не ко всему хранилищу данных.

3.2.5. Операция <edit-config>

Права доступа NACM не связаны напрямую с атрибутом «операции» <edit-config>, хотя они похожи. Права доступа NACM применяются ко всем протокольным операциям, которые в результате будут приводить к определенной операции доступа к целевому хранилищу данных. В это параграфе описано как эти права доступа применяются к конкретным операциям доступа, поддерживаемым протокольной операцией <edit-config>.

Если реальной операцией доступа для отдельного узла данных является none (т. е. default-operation=none), контроль доступа для этого узла не применяется. Это требуется для того, чтобы разрешить доступ к субдереву в более крупной структуре данных. Например, пользователь может иметь полномочия на создание новых записей в списке /interfaces/interface, но не иметь полномочий для создания или удаления его родительского контейнера (/interfaces). Если контейнер /interfaces уже имеется в целевом хранилище, при редактировании списка /interfaces/interface эффективной операцией для узла /interfaces будет none.

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

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

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

Операция <edit-config> для слияния или замены может включать узлы данных, которые являются неизменяемой частью имеющегося хранилища данных. Например, узел container или list может служить для именования, но не изменения соответствующего узла в хранилище. Такие неизменяемые узлы данных игнорируются сервером и не требуют от клиента каких-либо прав доступа.

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

Содержимое конкретных узлов с ограничениями доступа недопустимо включать в какие-либо элементы откликов <rpc-error>.

Операция <edit-config> может приводить к неявному созданию или удалению узлов в результате неявных побочных эффектов запрошенной операции. Например выражение оператора YANG when может давать разные результаты, в зависимости от которых узлы данных могут создаваться или удаляться или при создании узла данных в одной из ветвей оператора YANG choice узлы в других вариантах этого оператора могут неявно удаляться. Для узлов данных, которые неявно изменяются в результате побочных эффектов другой разрешенной операции, не требуется прав доступа NACM.

3.2.6. Операция <copy-config>

Контроль доступа для операции <copy-config> требует специального рассмотрения, поскольку эта операция позволяет администратору полностью заменить содержимое целевого хранилища.

Если источником протокольной операции <copy-config> является хранилище рабочей конфигурации, а целью — хранилище стартовой конфигурации, от клиента требуется лишь доступ к выполнению операции <copy-config>.

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

  • Если источником операции <copy-config> является хранилище, узлы данных, к которым у клиента нет доступа на чтение, просто опускаются.

  • Если целью операции <copy-config> является хранилище данных, клиенту нужен доступ к обновляемым узлам. В частности должны выполняться приведенные ниже условия.

    • Если протокольная операция ведет к созданию узла в хранилище, а пользователь не имеет для этого узла права на создание (create), протокольная операция отвергается с ошибкой access-denied.

    • Если протокольная операция ведет к удалению узла в хранилище, а пользователь не имеет для этого узла права на удаление (delete), протокольная операция отвергается с ошибкой access-denied.

    • Если протокольная операция ведет к обновлению узла в хранилище, а пользователь не имеет для этого узла права на обновление (update), протокольная операция отвергается с ошибкой access-denied.

3.2.7. Операция <delete-config>

Доступ к протокольной операции <delete-config> по умолчанию отвергается. Лист exec-default не применяется к этой операции протокола. Для разрешения вызова этой операции правила контроля доступа должны быть заданы явно, если сессия не является восстановительной.

3.2.8. Операция <commit>

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

Например, если сессия может читать все хранилище, но изменять лишь один лист, эта сессия должна иметь право редактирования и представления (commit) лишь для этого листа.

3.2.9. Операция <discard-changes>

От клиента требуется лишь право выполнять протокольную операцию <discard-changes>. Прав доступа к хранилищу не требуется.

3.2.10. Операция <kill-session>

Операция <kill-session> не меняет хранилища напрямую, однако она позволяет из одной сессии прервать другую, которая могла редактировать хранилище данных.

Доступ к протокольной операции <kill-session> по умолчанию отвергается. Лист exec-default не применяется к этой операции протокола. Для разрешения вызова этой операции правила контроля доступа должны быть заданы явно, если сессия не является восстановительной.

3.3. Компоненты модели

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

3.3.1. Пользователи

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

Как описано в [RFC6241], строка имени пользователя выводится из транспортного уровня в процессе организации сессии. Если транспортный уровень не может проверить подлинность пользователя, сессия прерывается.

3.3.2. Группы

Доступ к конкретной операции протокола NETCONF предоставляется для сессии. Сессия связана с группой (т. е. не с пользователем).

Группы идентифицируются по именам. Имена уникальны в масштабе сервера.

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

Члены группы идентифицируются строками имен пользователей.

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

3.3.3. Сеанс восстановления при аварии

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

3.3.4. Глобальные элементы исполнения

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

3.3.4.1. Переключатель enable-nacm

Глобальный переключатель enable-nacm служит для включения и отключения процедур контроля доступа. Когда этот переключатель имеет значение true, все запросы проверяются на соответствие правилам контроля доступа и выполняются только разрешенные запреты на доступ. При значении глобального переключателя false все запросы на доступ разрешены.

3.3.4.2. Переключатель read-default

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

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

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

3.3.4.3. Переключатель write-default

Переключатель write-default определяет принятый по умолчанию режим доступа к изменению конфигурационных данных. Когда глобальный переключатель enable-nacm имеет значение true, данный переключатель используется при отсутствии совпадений с правилами контроля доступа, которые явно разрешают или запрещают доступ для записи в запрошенное хранилище.

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

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

3.3.4.4. Переключатель exec-default

Переключатель exec-default определяет принятый по умолчанию режим доступа к выполнению протокольных операций. Когда глобальный переключатель enable-nacm имеет значение true, данный переключатель используется при отсутствии совпадений с правилами контроля доступа, которые явно разрешают или запрещают доступ к исполнению запрошенной операции протокола NETCONF.

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

Когда этот глобальный переключатель имеет значение deny и нет совпадения с правилом контроля доступа к запрошенной операции протокола NETCONF, такой доступ отвергается (см п. 12 в параграфе 3.4.4 и п. 13 в параграфе 3.4.5).

3.3.4.5. Переключатель enable-external-groups

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

При значении этого переключателя false имена групп, сообщенные транспортным уровнем, игнорируются NACM.

3.3.5. Правила контроля доступа

В NACM доступны 4 типа правил, перечисленные ниже.

module – правило для модуля

Управляет доступом к определениям в модуле YANG, указанном именем.

protocol operation – правило для протокольной операции

Управляет доступом к конкретной операции протокола, указанной именем и модулем YANG.

data node – правило для узла данных

Управляет доступом к конкретному узлу данных (и его потомкам), указанному путем в концептуальном документе XML для узла данных.

Notification – правило для уведомлений

Управляет доступом к конкретному типу уведомлений, указанному именем и модулем YANG.

3.4. Процедуры исполнения контроля доступа

Необходимо выполнить 6 этапов проверки, 4 из которых относятся к модели обработки сообщений NETCONF (параграф 3.1.3):

  1. начальные операции;

  2. организация сессии;

  3. обработка ошибок access-denied;

  4. проверка пригодности входящих сообщений RPC;

  5. проверка доступа к узлу данных;

  6. полномочия для исходящих <notification>.

Кроме того, нужно учитывать стартовый режим сервера NETCONF, организацию сессии, а также процедуры обработки ошибок access-denied.

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

3.4.1. Начальные операции

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

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

3.4.2. Организация сессии

Модель контроля доступа применяется к четко сформированному содержимому XML, передаваемому между клиентом и сервером после организации сессии и успешного обмена сообщениями <hello>.

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

3.4.3. Обработка ошибок access-denied

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

Серверу недопустимо включать какую-либо информацию, которую клиенту не разрешено читать, в элементы <error-info> откликов <rpc-error>.

3.4.4. Проверка входящих сообщений RPC

На рисунке 3 показана базовая концептуальная структура модели обработки контроля доступа для входящих сообщений NETCONF <rpc> на сервере.

         Сервер NETCONF 
         +------------+
         | Диспетчер  |
         | сообщений  |
         |    XML     |
         +------------+
                |
                |
                V
        +---------------+
        |сообщение <rpc>|
        +---------------+
          |    |     |
          |    |     +--------------------------------+
          |    +---------------+                      |
          V                    V                      V
+------------------+ +--------------------+ +--------------------+
|фирменная операция| |стандартная операция| |стандартная операция|
|    <my-edit>     | |   <edit-config>    | |      <unlock>      |
+------------------+ +--------------------+ +--------------------+
            |                 |
            |                 |
            V                 V
           +----------------------+
           |      Хранилище       |
           |    конфигурации      |
           +----------------------+

Рисунок 3.

 

Контроль доступа начинается с диспетчера сообщений.

После проверки сервером пригодности элемента <rpc>, определения пространства имен URI и имени элемента, запрашивающего протокольную операцию сервер проверяет права пользователя на вызов протокольной операции.

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

  1. Если лист enable-nacm имеет значение false, протокольная операция разрешена.

  2. Если запрашивающая сессия определена как восстановительная, протокольная операция разрешена.

  3. Если запрошена операция NETCONF <close-session>, протокольная операция разрешена.

  4. Проверяются все записи group для поиска в них записи user-name, значение которой совпадает с именем пользователя для сделавшей запрос сессии. Если лист enable-external-groups имеет значение true, эти группы добавляются в список групп, предоставленный транспортным уровнем.

  5. Если групп не найдено, переход к п. 10.

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

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

    • Лист module-name в правиле имеет значение * или совпадает с именем модуля YANG, где определена протокольная операция.

    • (1) правило не имеет rule-type или (2) rule-type имеет значение protocol-operation, а rpc-name имеет значение * или совпадает с именем запрошенной операции протокола.

    • Лист access-operations в правиле имеет установленный бит exec или специальное значение *.

  8. Если соответствующее правило найдено, проверяется лист action. Если он имеет значение permit, протокольная операция разрешена, в противном случае она отвергается.

  9. Этот пункт соответствует ситуации, когда не найдено совпадающего правила ни в одной записи rule-list.

  10. Если запрошенная протокольная операция определена в модуле YANG, анонсированном в возможностях сервера, и оператор rpc содержит оператор nacm:default-deny-all, протокольная операция отвергается.

  11. Если протокольная операция является операцией протокола NETCONF <kill-session> или <delete-config>, эта операция отвергается.

  12. Если лист exec-default имеет значение permit, протокольная операция разрешена, иначе она отвергается.

Если пользователь не уполномочен вызывать операцию протокола, генерируется сообщение <rpc-error> с приведенной ниже информацией.

error-tag

access-denied

error-path

Указывает запрошенную операцию. Приведенный ниже пример представляет операцию <edit-config> в базовом пространстве имен NETCONF.

         <error-path
           xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
             /nc:rpc/nc:edit-config
         </error-path>

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

3.4.5. Проверка доступа к узлу данных

Если (1) осуществляется доступ к узлу данных или (2) к узлу привязано действие или уведомление, сервер должен гарантировать, что пользователь уполномочен выполнять запрошенную операцию доступа read, create, update, delete или execute для указанного узла данных.

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

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

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

  1. Если лист enable-nacm имеет значение false, доступ разрешен.

  2. Если запрашивающая сессия определена как восстановительная, доступ разрешен.

  3. Проверяются все записи group для поиска в них записи user-name, значение которой совпадает с именем пользователя для сделавшей запрос сессии. Если лист enable-external-groups имеет значение true, эти группы добавляются в список групп, предоставленный транспортным уровнем.

  4. Если групп не найдено, переход к п. 9.

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

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

    • Лист module-name в правиле имеет значение * или совпадает с именем модуля YANG, где определена протокольная операция.

    • (1) правило не имеет rule-type или (2) rule-type имеет значение data-node, а path соответствует запрашиваемому узлу данных, действия или уведомления. Путь считается соответствующим, если запрошенный узел является узлом, заданным этим путем, или наследником такого узла.

    • Для операции read лист access-operations в правиле имеет установленный бит read или специальное значение *.

    • Для операции create лист access-operations в правиле имеет установленный бит create или специальное значение *.

    • Для операции delete лист access-operations в правиле имеет установленный бит delete или специальное значение *.

    • Для операции update лист access-operations в правиле имеет установленный бит update или специальное значение *.

    • Для операции execute лист access-operations в правиле имеет установленный бит exec или специальное значение *.

  1. Если соответствующее правило найдено, проверяется лист action. Если он имеет значение permit, протокольная операция разрешена, в противном случае она отвергается. Для операции read отказ (denied) означает, что запрошенные данные не возвращаются в отклике.

  2. Этот пункт соответствует ситуации, когда не найдено совпадающего правила ни в одной записи rule-list.

  3. Если запрошенный узел данных для операции read определен в модуле YANG, анонсированном в возможностях сервера и оператор определения данных содержит оператор nacm:default-deny-all, запрошенный узел данных и все его наследники не включаются в отклик.

  4. Если запрошенный узел данных для операции write определен в модуле YANG, анонсированном в возможностях сервера, и оператор определения данных содержит оператор nacm:default-deny-write или nacm:default-deny-all, запрошенная операция отвергается для узла данных и всех его наследников.

  5. Если для операции read лист read-default имеет значение permit, запрошенный узел включается в отклик, в противном случае запрошенный узел и все его потомки не включаются в отклик.

  6. Если для операции write лист write-default имеет значение permit, запрос разрешается, иначе отвергается.

  7. Если для операции execute лист exec-default имеет значение permit, запрос разрешается, иначе отвергается.

3.4.6. Предоставление полномочий для исходящего уведомления

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

Если уведомление задано в субдереве данных, как указано в [RFC7950], требуется доступ для чтения к уведомлению. Обработка продолжается в соответствии с параграфом 3.4.5.

На рисунке 4 показана концептуальная модель обработки для исходящих сообщений <notification>.

      Сервер NETCONF 
      +------------+
      |  Генератор |
      |  сообщений |
      |     XML    |
      +------------+
            ^
            |
    +----------------+
    |   Генератор    |
    | <notification> |
    +----------------+
            ^
            |
   +=================+
   | <notification>  |
   |контроль доступа |
   |  <eventType>    |
   +=================+
            ^
            |
+------------------------+
| Оборудование сервера   |
+------------------------+
          |     ^
          V     |
 +----------------------+
 |      Хранилище       |
 |     конфигурации     |
 +----------------------+

Рисунок 4.


Для генерации уведомления по указанной подписке [RFC5277] полномочия выдаются в соответствии с приведенным ниже описанием.

  1. Если лист enable-nacm имеет значение false, уведомление разрешено.

  2. Если сессия определена как восстановительная, уведомление разрешено.

  3. Если уведомление отосится к типу NETCONF <replayComplete> или <notificationComplete> [RFC5277], оно разрешено.

  4. Проверяются все записи group для поиска в них записи user-name, значение которой совпадает с именем пользователя для сделавшей запрос сессии. Если лист enable-external-groups имеет значение true, эти группы добавляются в список групп, предоставленный транспортным уровнем.

  5. Если групп не найдено, переход к п. 10.

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

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

    • Лист module-name в правиле имеет значение * или совпадает с именем модуля YANG, где определено уведомление.

    • (1) правило не имеет rule-type или (2) rule-type имеет значение notification, а notification-name имеет значение * или совпадает с именем уведомления.

    • Лист access-operations в правиле имеет установленный бит read или специальное значение *.

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

  2. Этот пункт соответствует ситуации, когда не найдено совпадающего правила ни в одной записи rule-list.

  3. Если запрошенное уведомление определено в модуле YANG, анонсированном в возможностях сервера, и оператор notification содержит оператор nacm:default-deny-all, уведомление для соответствующей подписки отбрасывается.

  4. Если для лист read-default имеет значение permit, уведомление разрешено, в противном случае оно отвергается.

3.5. Определения модели данных

3.5.1. Организация данных

На приведенном ниже рисунке показана структура и содержимое модуля NACM YANG.

   module: ietf-netconf-acm
     +--rw nacm
        +--rw enable-nacm?              boolean
        +--rw read-default?             action-type
        +--rw write-default?            action-type
        +--rw exec-default?             action-type
        +--rw enable-external-groups?   boolean
        +--ro denied-operations         yang:zero-based-counter32
        +--ro denied-data-writes        yang:zero-based-counter32
        +--ro denied-notifications      yang:zero-based-counter32
        +--rw groups
        |  +--rw group* [name]
        |     +--rw name         group-name-type
        |     +--rw user-name*   user-name-type
        +--rw rule-list* [name]
           +--rw name     string
           +--rw group*   union
           +--rw rule* [name]
              +--rw name                 string
              +--rw module-name?         union
              +--rw (rule-type)?
              |  +--:(protocol-operation)
              |  |  +--rw rpc-name?            union
              |  +--:(notification)
              |  |  +--rw notification-name?   union
              |  +--:(data-node)
              |     +--rw path                 node-instance-identifier
              +--rw access-operations?   union
              +--rw action               action-type
              +--rw comment?             string

3.5.2. Модуль YANG

Приведенный ниже модуль YANG задает нормативное содержимое NETCONF, которое должно поддерживаться сервером.

Модуль YANG ietf-netconf-acm импортирует определения типов из [RFC6991].

   <CODE BEGINS> file "ietf-netconf-acm@2018-02-14.yang"
   module ietf-netconf-acm {

     namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm";

     prefix nacm;

     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NETCONF (Network Configuration) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netconf/> 
        WG List:  <mailto:netconf@ietf.org> 

        Author:   Andy Bierman
                  <mailto:andy@yumaworks.com> 

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>"; 

     description
       "Модель управления доступом NETCONF.

        Copyright (c) 2012 - 2018 IETF Trust and the persons
        identified as authors of the code.  All rights reserved.

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

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

     revision "2018-02-14" {
       description
         "Добавлена поддержка действий и уведомлений YANG 1.1, привязанных
          к узлам данных. Уточнено использование расширений NACM в других
          моделях данных.";
       reference
         "RFC 8341: Network Configuration Access Control Model";
     }

     revision "2012-02-22" {
       description
         "Initial version.";
       reference
         "RFC 6536: Network Configuration Protocol (NETCONF)
                    Access Control Model";
     }

     /*
      * Extension statements
      */

     extension default-deny-write {
       description
         "Служит для индикации того, что узел модели данных
          представляет деликатный параметр безопасности системы.

          При наличии этого расширения сервер NETCONF будет разрешать
          запись для узла лишь указанным «сеансам восстановления». Для
          прочих пользователей требуется явное правило контроля доступа.

          Если используется модуль NACM, он должен быть включен (т. е.
          объект /nacm/enable-nacm должен иметь значение true) или это
          расширение будет игнорироваться.

          Расширение default-deny-write МОЖЕТ присутствовать лишь в
          операторе определения данных. В иных случаях оно игнорируется.";
     }

     extension default-deny-all {
       description
         "Используется для указания того, что узел модели данных управляет
          очень деликатным параметром безопасности.

          При наличии этого расширения сервер NETCONF будет разрешать
          запись для узла лишь указанным «сеансам восстановления». Для
          прочих пользователей требуется явное правило контроля доступа.

          Если используется модуль NACM, он должен быть включен (т. е.
          объект /nacm/enable-nacm должен иметь значение true) или это
          расширение будет игнорироваться.

          Расширение default-deny-all МОЖЕТ присутствовать лишь в
          операторе определения данных, операторе rpc или notification.
          statement. В иных случаях оно игнорируется.";
     }

     /*
      * Производные типы
      */

     typedef user-name-type {
       type string {
         length "1..max";
       }
       description
         "Строка общего назначения для имени пользователя.";
     }

     typedef matchall-string-type {
       type string {
         pattern '\*';
       }
       description
         "Строка, содержащая один символ *, используется для 
          представления всех возможных значений отдельного листа,
          использующего этот тип данных.";
     }

     typedef access-operations-type {
       type bits {
         bit create {
           description
             "Любая операция протокола, создающая новый узел данных.";
         }
         bit read {
           description
             "Любая операция протокола или уведомление, возвращающие
              значение узла данных.";
         }
         bit update {
           description
             "Любая операция протокола, изменяющая узел данных.";
         }

         bit delete {
           description
             "Любая операция протокола, удаляющая узел данных.";
         }
         bit exec {
           description
             "Выполнение заданной операции протокола.";
         }
       }
       description
         "Операция доступа.";
     }

     typedef group-name-type {
       type string {
         length "1..max";
         pattern '[^\*].*';
       }
       description
         "Имя группы администраторов, в которую можно назначить
          пользователей.";
     }

     typedef action-type {
       type enumeration {
         enum permit {
           description
             "Запрошенное действие разрешено.";
         }
         enum deny {
           description
             "Запрошенное действие отвергнуто.";
         }
       }
       description
         "Действие, выполняемое сервером при соответствии 
          конкретному правилу.";
     }

     typedef node-instance-identifier {
       type yang:xpath1.0;
       description
         "Путь, используемый для представления строки идентификатора
          специального узла данных, действия или уведомления.

          Значением идентификатора экземпляра узла является
          выражение YANG instance-identifier без ограничений.

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

          Это выражение XML Path Language (XPath) оценивается в описанном
          ниже контексте.

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

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

             -  Библиотекой функций служит библиотека ядра, но следует
                отметить, что синтаксические ограничения instance-identifier
                не разрешают функций.

             -  Узлом контекста является корневой узел дерева данных.

          Доступное дерево включает действия и уведомления, привязанные
          к узлам данных.";
     }

     /*
      * Операторы определения данных
      */

     container nacm {
       nacm:default-deny-all;

       description
         "Параметры для модели управления доступом NETCONF.";

       leaf enable-nacm {
         type boolean;
         default "true";
         description
           "Разрешает или запрещает выполнение всех операций 
            контроля доступа NETCONF. Значение true включает
            управление, false отключает.";
       }

       leaf read-default {
         type action-type;
         default "permit";
         description
           "Решает вопрос предоставления доступа на чтение при
            отсутствии подходящего правила для конкретного запроса.";
       }

       leaf write-default {
         type action-type;
         default "deny";
         description
           "Решает вопрос предоставления доступа на создание,
            изменение или удаление при отсутствии подходящего
            правила для конкретного запроса.";
       }

       leaf exec-default {
         type action-type;
         default "permit";
         description
           "Решает вопрос предоставления доступа на исполнение при
            отсутствии подходящего правила для конкретного запроса.";
       }

       leaf enable-external-groups {
         type boolean;
         default "true";
         description
           "Задает, будет ли сервер использовать группы, переданные 
            транспортым уровнем NETCONF при назначении пользователя для
            набора групп NACM. Если этот лист имеет значение false, все
            имена групп, сообщенные транспортным уровнем, сервер игнорирует.";
       }

       leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Число случаев отказа от выполнения протокольных операций
            с момента последней перезагрузки сервера.";
       }

       leaf denied-data-writes {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Число случаев отказа от выполнения протокольной операции
            изменения хранилища данных  с момента последней 
            перезагрузки сервера.";
       }

       leaf denied-notifications {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Число случаев отказа от предоставления подписки на 
            уведомления с момента последней перезагрузки сервера.";
       }

       container groups {
         description
           "Группы контроля доступа NETCONF.";

         list group {
           key name;

           description
             "Запись для одной группы NACM. Этот список будет 
              включать лишь заданные в конфигурации, а не полученные 
              от транспортных протоколов записи.";

           leaf name {
             type group-name-type;
             description
               "Имя группы, связанной с этой записью.";
           }

           leaf-list user-name {
             type user-name-type;
             description
               "Каждая запись указывает имя пользователя - члена
                группы, связанной с записью.";
           }
         }
       }

       list rule-list {
         key name;
         ordered-by user;
         description
           "Упорядоченный набор правил контроля доступа.";

         leaf name {
           type string {
             length "1..max";
           }
           description
             "Произвольное имя, назначенное для rule-list.";
         }
         leaf-list group {
           type union {
             type matchall-string-type;
             type group-name-type;
           }
           description
             "Список административных групп, которым будут 
              назначены права доступа, заданные списком rule.

              * указывает, что запись применяется ко всем группам.";
         }

         list rule {
           key name;
           ordered-by user;
           description
             "Одно правило управления доступом.

              Правила обрабатываются в заданном пользователем порядке до 
              первого совпадения. Совпадением считается соответствие 
              module-name, rule-type и access-operations запросу. Если
              правило соответствует, лист action определяет 
              предоставление доступа.";

           leaf name {
             type string {
               length "1..max";
             }
             description
               "Произвольное имя, назначенное для правила.";
           }

           leaf module-name {
             type union {
               type matchall-string-type;
               type string;
             }
             default "*";
             description
               "Имя модуля, связанного с данным правилом.

                Этот лист дает совпадение, если он имеет значение * или 
                объект, требующий доступа, определен в модуле с заданным 
                именем.";
           }
           choice rule-type {
             description
               "Этот выбор будет соответствовать, если все листья в правиле
                соответствуют запросу. При отсутствии листьев выбор 
                соответствует всем запросам.";
             case protocol-operation {
               leaf rpc-name {
                 type union {
                   type matchall-string-type;
                   type string;
                 }
                 description
                   "Этот лист (leaf) считается соответствующим, если он имеет 
                    значение * или его значение совпадает с именем запрошенной
                    протокольной операции.";
               }
             }
             case notification {
               leaf notification-name {
                 type union {
                   type matchall-string-type;
                   type string;
                 }
                 description
                   "Этот лист (leaf) считается соответствующим, если он имеет 
                    значение * или его значение совпадает с именем запрошенного
                    уведомления.";
               }
             }

             case data-node {
               leaf path {
                 type node-instance-identifier;
                 mandatory true;
                 description
                   "Идентификатор экземпляра, связанный с узлом данных,
                    действием или уведомлением, контролируемым данным
                    правилом.

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

                    Специальное значение / указывает все содержимое хранилища.";
               }
             }
           }

           leaf access-operations {
             type union {
               type matchall-string-type;
               type access-operations-type;
             }
             default "*";
             description
               "Операции доступа, связанные с этим правилом.

                Лист будет соответствовать, если он имеет значение * или
                бит, соответствующий запрашиваемой операции, установлен.";
           }

           leaf action {
             type action-type;
             mandatory true;
             description
               "Действие по управлению доступом, связанное с правилом.
                Если определено, что правило соответствует конкретному
                запросу, этот объект указывает, принимается или 
                отвергается запрос.";
           }

           leaf comment {
             type string;
             description
               "Текстовое описание правила доступа.";
           }
         }
       }
     }
   }

   <CODE ENDS>

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

Этот документ повторно использует URI для ietf-netconf-acm в реестре IETF XML.

Документ обновляет регистрацию модуля в реестре YANG Module Names ссылкой на данный RFC вместо RFC 6536 для ietf-netconf-acm. В соответствии с форматом в [RFC6020] регистрируются приведенные ниже параметры.

        Name: ietf-netconf-acm
        Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm
        Prefix: nacm
        Reference: RFC 8341

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

Описанный в этом документе модуль YANG определяет схему для данных, которая разработана для обеспечения доступа с помощью протоколов сетевого управления типа NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт и обязательным для реализации является защищенный транспорт SSH6 [RFC6242]. Нижним уровнем RESTCONF является протокол HTTPS и обязательный для реализации транспорт TLS [RFC5246].

Модель контроля доступа NETCONF [RFC8341] обеспечивает способы ограничения доступа для отдельных пользователей NETCONF или RESTCONF к предопределенному подмножеству всех доступных протокольных операций и содержимого NETCONF или RESTCONF.

Имеется риск, связанный с недостаточным контролем доступа для опций RESTCONF и методов PATCH. Риск заключается в том, что отклик на OPTIONS и PATCH может варьироваться в зависимости от наличия или отсутствия ресурса, соответствующего пути URL. Это может быть использовано для тривиальной проверки наличия или отсутствия значений в дереве. Поэтому серверу недопустимо менять свои отклики в зависимости от существования ресурса, что может показать наличие или отсутствие экземпляров ресурса. В частности, не следует выдавать какую-либо информацию об экземпляре без уверенности в том, что клиент имеет полномочия, требуемые для такого доступа. Предполагается, что сервер всегда возвращает отклик об ошибке access-denied.

Для многих узлов данных, определенных в этом модуле YANG, возможна запись/создание/удаление (т. е. config имеет значение true, установленное по умолчанию). Такие узлы могут считаться чувствительными или уязвимыми в некоторых сетевых средах. Операции записи (например, edit-config) в такие узлы без надлежащей защиты могут оказывать негативное влияние на работу сети. Ниже перечислены субдеревья и узлы данных с указанием их чувствительности/уязвимости:

  • /nacm: все субдерево /nacm связано с безопасностью (см. подробности в последующих параграфах).

Далее очерчены вопросы, которые администратору нужно рассмотреть при настройке сервера NETCONF с NACM.

5.1. Настройка и мониторинг NACM

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

По умолчанию выполнение NACM включено. По умолчанию доступ read разрешен для всего содержимого хранилища данных (пока в определении данных не задано nacm:default-deny-all), доступ exec разрешен для безопасных операций протокола. Администратор должен обеспечить включение NACM, а также решить, правильно ли настроены принятые по умолчанию параметры. Нужно убедиться в корректности настройки перечисленных ниже узлов данных и параметров:

  • /nacm/enable-nacm (по умолчанию true)

  • /nacm/read-default (по умолчанию permit)

  • /nacm/write-default (по умолчанию deny)

  • /nacm/exec-default (по умолчанию permit)

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

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

Администратор должен убедиться, что трансляция зависящего от транспорта или реализации отождествления пользователя в имя пользователя NACM однозначна и корректна. Это требование подробно описано в параграфе 2.2 [RFC6241].

Администратор должен знать, что структуры данных YANG, представляющие правила контроля доступа (/nacm/rule-list и /nacm/rule-list/rule), упорядочены клиентом. Сервер будет проверять правила контроля доступа в соответствии с их относительным концептуальным порядком в хранилище рабочей конфигурации.

Отметим, что структура данных /nacm/groups содержит имена административных групп, используемых сервером. Эти имена групп могут настраиваться локально и/или через внешний протокол типа RADIUS [RFC2865] [RFC5607].

Для определения имен групп администратор должен понимать свойства безопасности всех внешних протоколов, используемых транспортным уровнем. Например, если протокол не обеспечивает защиты от MITM-атак7, атакующий может подставить имена групп, которые будут затем включены в конфигурацию NACM так, что пользователь получит избыточные полномочия. В таких случаях администратор может отключить такие имена групп, установив для /nacm/enable-external-groups значение false.

Некоторые из доступных для чтения узлов данных в этом модуле YANG могут оказаться чувствительными или уязвимыми в отдельных сетевых средах. Для таких узлов важно контролировать доступ на чтение (например, с помощью get, get-config или notification). Ниже перечислены чувствительные/уязвимые субдеревья и узлы данных:

  • /nacm/enable-nacm

  • /nacm/read-default

  • /nacm/write-default

  • /nacm/exec-default

  • /nacm/enable-external-groups

  • /nacm/groups

  • /nacm/rule-list

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

5.2. Общие вопросы настройки конфигурации

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

Для сессии с некоторыми правами записи (например, вызов <edit-config>), но без какого-либо доступа к конкретному субдереву с конфиденциальными данными можно определить наличие или отсутствие таких данных. Это можно сделать путем повторяющихся вызовов некой операции редактирования (создание, обновление или удаление) с возможным получением отклика access-denied. Такая «ловля на живца» может определить наличие или отсутствие конкретных чувствительных данных даже без наличия поля error-path в отклике <rpc-error>.

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

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

Возможно, что само определение модели данных (например, оператор YANG when или choice) позволит сессии неявно создавать или удалять узлы, для которых сессия не имеет прав записи, за счет побочных эффектов при обработке разрешенной операции <edit-config>.

Существует риск того, что нестандартные протокольные операции или даже стандартная операция <get> могут возвращать данные, которые являются «псевдонимом» или «копией» конфиденциальных данных из другого объекта. Может просто существовать множество определений модели данных, которые раскрывают или даже настраивают базовое серверное оборудование.

Модель данных может содержать внешние ключи (например, YANG leafref), которые раскрывают значения из другой структуры данных. Администратор должен осознавать деликатность моделей данных с узлами leafref. Это влечет за собой поиск всех объектов leafref, которые «указывают» на деликатные данные (т. е. значений операторов path), явно или неявно включая узлы конфиденциальных данных.

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

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

Сессия может нарушать управление конфигурацией даже без права записи в конфигурацию просто путем блокировки хранилища. Это может делаться для обеспечения стабильности всей или части конфигурации во время операций извлечения данных или возникать в результате DoS-атаки8. Сервер не может различить эти два случая. Администратор может ограничить доступ к исполнению (exec) для перечисленных ниже протокольных операций:

  • <lock>

  • <unlock>

  • <partial-lock>

  • <partial-unlock>

5.3. Устройство модели данных

Разработчикам нужно четко указать все деликатные данные, уведомления и протокольные операции, определенные в модуле YANG. Для таких определений должен присутствовать оператор nacm:default-deny-write или nacm:default-deny-all в дополнение к четкому описанию рисков безопасности.

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

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

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

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

[RFC5277] Chisholm, S. and H. Trevino, «NETCONF Event Notifications», RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.

[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>./WP/rfc6242/

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

[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

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

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

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

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

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.

[RFC5607] Nelson, D. and G. Weber, «Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management», RFC 5607, DOI 10.17487/RFC5607, July 2009, <https://www.rfc-editor.org/info/rfc5607>.

[YANG-SEC] IETF, «YANG Security Guidelines», <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>.

Приложение A. Примеры использования

Приведенные ниже фрагменты XML [W3C.REC-xml-20081126] служат лишь примерами настройки NACM для решения некоторых задач контроля доступа.

A.1. Пример <groups>

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

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

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <groups>
       <group>
         <name>admin</name>
         <user-name>admin</user-name>
         <user-name>andy</user-name>
       </group>

       <group>
         <name>limited</name>
         <user-name>wilma</user-name>
         <user-name>bam-bam</user-name>
       </group>

       <group>
         <name>guest</name>
         <user-name>guest</user-name>
         <user-name>guest@example.com</user-name>
       </group>
     </groups>
   </nacm>

Этот пример включает три группы:

   admin: два пользователя с именами admin и andy
   limited: два пользователя с именами wilma и bam-bam
   guest: два пользователя с именами guest и guest@example.com.

A.2. Пример правила для модуля

Правила модуля служат для контроля доступа ко всему содержимому, определенному в конкретном модуле. Правило модуля имеет установленный лист module-name, но не имеет установленных узлов из выбора rule-type.

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>guest-acl</name>
       <group>guest</group>
       <rule>
         <name>deny-ncm</name>
         <module-name>ietf-netconf-monitoring</module-name>
         <access-operations>*</access-operations>
         <action>deny</action>
         <comment>
             Не позволяет гостям получить доступ к данным 
             мониторинга NETCONF.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>limited-acl</name>
       <group>limited</group>
       <rule>
         <name>permit-ncm</name>
         <module-name>ietf-netconf-monitoring</module-name>
         <access-operations>read</access-operations>
         <action>permit</action>
         <comment>
             Позволяет считывать данные мониторинга NETCONF.
         </comment>
       </rule>
       <rule>
         <name>permit-exec</name>
         <module-name>*</module-name>
         <access-operations>exec</access-operations>
         <action>permit</action>
         <comment>
             Позволяет вызывать поддерживаемые операции сервера.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>admin-acl</name>
       <group>admin</group>
       <rule>
         <name>permit-all</name>
         <module-name>*</module-name>
         <access-operations>*</access-operations>
         <action>permit</action>
         <comment>
             Дает группе admin полный доступ к операциям и данным.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример демонстрирует 4 правила:

   deny-ncm: предотвращает доступ группы guest к считыванию данных
      мониторинга в модуле YANG ietf-netconf-monitoring.
   permit-ncm: позволяет группе limited читать модуль YANG
      ietf-netconf-monitoring.
   permit-exec: позволяет группе limited вызывать любые протокольные
      операции, поддерживаемые сервером.
   permit-all: предоставляет группе admin полный доступ к содержимому
      сервера. Далее не будет правил, соответствующих группе admin,
      поскольку это правило для модуля.

A.3. Пример правила для протокольной операции

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

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>guest-limited-acl</name>
       <group>limited</group>
       <group>guest</group>
       <rule>
         <name>deny-kill-session</name>
         <module-name>ietf-netconf</module-name>
         <rpc-name>kill-session</rpc-name>
         <access-operations>exec</access-operations>
         <action>deny</action>
         <comment>
           Не позволяет группам limited и guest 'убить' чужую сессию.
         </comment>
       </rule>
       <rule>
         <name>deny-delete-config</name>
         <module-name>ietf-netconf</module-name>
         <rpc-name>delete-config</rpc-name>
         <access-operations>exec</access-operations>
         <action>deny</action>
         <comment>
            Не позволяет группам limited и guest удалять конфигурации.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>limited-acl</name>
       <group>limited</group>
       <rule>
         <name>permit-edit-config</name>
         <module-name>ietf-netconf</module-name>
         <rpc-name>edit-config</rpc-name>
         <access-operations>exec</access-operations>
         <action>permit</action>
         <comment>
           Позволяет группе limited редактировать конфигурацию.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример содержит правила для трех операций:

   deny-kill-session: предотвращает вызов группами limited и guest 
      протокольной операции NETCONF <kill-session>.
   deny-delete-config: предотвращает вызов группами limited и guest 
      протокольной операции NETCONF <delete-config>.
   permit-edit-config: разрешает группе limited вызывать операцию
      NETCONF <edit-config>. Это правило не будет работать, пока не
      установлено значение deny для листа exec-default.

A.4. Пример правила для узла данных

Правила узла данных служат для контроля доступа к конкретным (config и non-config) узлам данных в содержимом NETCONF, предоставляемом сервером.

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>guest-acl</name>
       <group>guest</group>
       <rule>
         <name>deny-nacm</name>
         <path xmlns:n="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
           /n:nacm
         </path>
         <access-operations>*</access-operations>
         <action>deny</action>
         <comment>
           Запрет для группы guest доступа к данным /nacm.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>limited-acl</name>
       <group>limited</group>
       <rule>
         <name>permit-acme-config</name>
         <path xmlns:acme="http://example.com/ns/netconf">
           /acme:acme-netconf/acme:config-parameters
         </path>
         <access-operations>
           read create update delete
         </access-operations>
         <action>permit</action>
         <comment>
           Предоставление группе limited полного доступа к 
           конфигурационным параметрам acme NETCONF. Показана
           длинная форма access-operations вместо сокращенной.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>guest-limited-acl</name>
       <group>guest</group>
       <group>limited</group>
       <rule>
         <name>permit-dummy-interface</name>
         <path xmlns:acme="http://example.com/ns/itf">
           /acme:interfaces/acme:interface[acme:name='dummy']
         </path>
         <access-operations>read update</access-operations>
         <action>permit</action>
         <comment>
           Разрешает группам limited и guest чтение и обновление
           для интерфейса dummy.
         </comment>
       </rule>
     </rule-list>

     <rule-list>
       <name>admin-acl</name>
       <group>admin</group>
       <rule>
         <name>permit-interface</name>
         <path xmlns:acme="http://example.com/ns/itf">
           /acme:interfaces/acme:interface
         </path>
         <access-operations>*</access-operations>
         <action>permit</action>
         <comment>
           Разрешает группе admin полный доступ к интерфейсам acme.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример содержит 4 правила для узлов данных:

   deny-nacm: предотвращает доступ группы guest к субдереву /nacm.
   permit-acme-config: разрешает для группы limited доступ read-write
      к acme <config-parameters>.
   permit-dummy-interface: разрешает для групп limited и guest доступ
      read-update к записи acme <interface> с именем dummy. Запись не
      может быть создана или удалена этими группами, можно лишь менять ее.
   permit-interface: дает группе admin доступ read-write ко всем записям
      acme <interface>.

A.5. Пример правила для уведомления

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

   <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
     <rule-list>
       <name>sys-acl</name>
       <group>limited</group>
       <group>guest</group>
       <rule>
         <name>deny-config-change</name>
         <module-name>acme-system</module-name>
         <notification-name>sys-config-change</notification-name>
         <access-operations>read</access-operations>
         <action>deny</action>
         <comment>
           Не позволяет группам guest и limited получать 
           уведомления о смене конфигурации.
         </comment>
       </rule>
     </rule-list>
   </nacm>

Этот пример показывает одно правило для уведомлений:

   deny-config-change: предотвращает отправку в группы limited и
      guest уведомлений о событиях типа acme <sys-config-change>.

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

Andy Bierman

YumaWorks

685 Cochran St.

Suite #160

Simi Valley, CA 93065

United States of America

Email: andy@yumaworks.com

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com


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

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

nmalykh@gmail.com

1Network Configuration.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Remote Procedure Call — вызов удаленных процедур.

5Create, Read, Update, Delete, eXec — создание, чтение, обновление, удаление, исполнение.

6Secure Shell.

7Man-in-the-middle — перехват и изменение пакетов с участием человека.

8Denial-of-service — отказ в обслуживании.




RFC 8340 YANG Tree Diagrams

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8340                                Tail-f Systems
BCP: 215                                                  L. Berger, Ed.
Category: Best Current Practice                  LabN Consulting, L.L.C.
ISSN: 2070-1721                                               March 2018

Диаграммы деревьев YANG

YANG Tree Diagrams

 PDF

Тезисы

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

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

Этот документ относится к категории обмена опытом (Internet Best Current Practice).

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

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

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

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

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

Оглавление

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

1. Введение

Диаграммы деревьев YANG впервые были опубликованы в RFC 6536. Они используются для упрощенного графического представления модели данных и могут создаваться автоматически с помощью таких инструментов, как pyang [PYANG]. В этом документе описан синтаксис, применяемый в диаграммах деревьев YANG. Предполагается, что этот документ будет обновляться или заменяться по мере внесения изменений в язык YANG [RFC7950].

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

Пример диаграммы дерева можно найти в разделе 3 документа [RFC8343]. Часть такого дерева приведена ниже.

     +--rw interfaces
        +--rw interface* [name]
           +--rw name                        string
           +--rw description?                string
           +--rw type                        identityref
           +--rw enabled?                    boolean
           +--rw link-up-down-trap-enable?   enumeration {if-mib}?

2. Синтаксис диаграммы дерева

В этом разделе описано значение символов, применяемых в диаграммах деревьев YANG.

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

Модуль указывается тегом module:, за которым следует имя модуля <module-name>. Далее следует один или несколько разделов в соответствии с приведенными ниже правилами.

  1. Определенные в модуле узлы верхнего уровня смещаются пробелами на две позиции.

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

  3. RPC смещаются на два пробела и указываются тегом rpcs:.

  4. Уведомления смещаются на два пробела и указываются тегом notifications:.

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

  6. Структуры yang-data смещаются на два пробела и указываются ключевым словом yang-data, за которым следует имя структуры yang-data и двоеточие (:).

Относительная организация каждого раздела обеспечивается с использованием текстового формата, который обычно применяется для вывода команд отображения дерева каталогов фаловых систем. Каждый узел дерева имеет префикс +—. Узлы схемы, являющиеся потомками другого узла смещаются от родителя на три пробела. Братские узлы схемы указываются с одинаковым смещением и разделяются пустой строкой, а для связывания используется символ |.

Пример полного формата с учетом соглашений о смещениях приведен ниже.

     module: <module-name>
       +--<node>
       |  +--<node>
       |     +--<node>
       +--<node>
          +--<node>
             +--<node>

       augment <target-node>:
         +--<node>
            +--<node>
            +--<node>
               +--<node>
       augment <target-node>:
         +--<node>

       rpcs:
         +--<rpc-node>
         +--<rpc-node>
            +--<node>
            |  +--<node>
            +--<node>

       notifications:
         +--<notification-node>
         +--<notification-node>
            +--<node>
            |  +--<node>
            +--<node>

       grouping <grouping-name>:
         +--<node>
            +--<node>
            |  +--<node>
            +--<node>
       grouping <grouping-name>:
         +--<node>


       yang-data <yang-data-name>:
         +--<node>
            +--<node>
            |  +--<node>
            +--<node>
       yang-data <yang-data-name>:
         +--<node>

2.1. Субмодуль

Субмодули представляются аналогично модулям, но указываются тегом submodule:, за которым следует имя субмодуля <module-name>. Например,

     submodule: <module-name>
       +--<node>
       |  +--<node>
       |     +--<node>

2.2. Группировка

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

Например, приведенная ниже диаграмма показывает группировку tls-transport из [RFC7407] без раскрытия

       +--rw tls
          +---u tls-transport

Если группу раскрыть, она пример вид

       +--rw tls
          +--rw port?                 inet:port-number
          +--rw client-fingerprint?   x509c2n:tls-fingerprint
          +--rw server-fingerprint?   x509c2n:tls-fingerprint
          +--rw server-identity?      snmp:admin-string

Группировки могут присутствовать в разделе groupings.

2.3. Структура yang-data

Если модуль определяет структуры yang-data [RFC8040], эти структуры могут присутствовать в разделе yang-data.

2.4. Сжатое представление узлов

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

       +--<node>
       |  ...
       +--<node>
          +--<node>
             +--<node>

2.5. Комментарий

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

2.6. Представление узла

Каждый узел модуля YANG указывается в форме

     <status>--<flags> <name><opts> <type> <if-features>

       <status> 
         +  текущий
         x  устаревший (deprecated)
         o  отмененный obsolete)

       <flags>
         rw  для узлов данных конфигурации и узлов выбора
         ro  для узлов неконфигурационных данных и узлов выбора,
             выходных параметров rpc и операций (actions), а 
             также параметров уведомлений
         -w  для входных параметров rpc и операций
         -u  для использования в группировках
         -x  для rpc и операций
         -n  для уведомлений
         mp  для узлов с оператором расширения mount-point

Узлы вариантов (case) не имеют флагов.

       <name> имя узла
         (<name>) означает, что узел является узлом выбора
        :(<name>) означает, что узел является узлом варианта (case)

Если узел добавлен в дерево из другого модуля, его имя указывается в форме <prefix>:<name>, где <prefix> указывает префикс, заданный в модуле, где определен узел.

Если узел является вариантом (case) перед <name> побелы не используются.

       <opts> 
         ?  для опционального узла leaf, choice, anydata, anyxml
         !  для контейнера присутствия
         *  для leaf-list или list
         [<keys>] для ключей списка
         /  для узла данных верхнего уровня в смонитрованном модуле
         @  для узла данных верхнего уровня модуля, указанного в точке
            монтирования родительской ссылки

       <type> название типа для leaf и leaf-list

Для leafref тип указывается как (1) -> TARGET, где TARGET указывает путь leafref с удалением (по возможности) ссылок или (2) leafref.

       <if-features> список функций (feature) от которых узел зависит,
         указывается в фигурных скобках, за которыми следует символ ? {...}?

Между разделяемыми пробелами полями (например, <opts> и <type>) число пробелов может быть любым. Дополнительные пробелы могут применяться, например, для выравнивания полей (например, в списке или контейнере) с целью удобочитаемости.

3. Рекомендации по использованию в RFC

В этом разделе приводятся рекомендации, связанные с использованием диаграмм деревьев в RFC.

3.1. Разрыв длинных строк

В документах Internet-Draft и RFC размер строки ограничен 72 символами. Когда представление узла требует более длинной строки, следует использовать перевод строки между <opts> и <type> или между <type> и <if-feature>. Новую строки следует дополнить пробельными символами так, чтобы она начиналась под <name> со смещением в 2 символа.

     notifications:
       +---n yang-library-change
          +--ro module-set-id
                  -> /modules-state/module-set-id

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

     augment /nat:nat/nat:instances/nat:instance/nat:mapping-table
               /nat:mapping-entry:

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

     pyang -f tree --tree-line-length 50 ietf-yang-library.yang

При включении диаграмм в качестве рисунков с Internet-Draft или RFC имеет смысл указать —tree-line-length 69.

3.2. Группировки

Если модуль YANG состоит только из группировок, диаграмма дерева должна включать группировки. Можно снова воспользоваться компилятором pyang для создания диаграммы дерева с группировками, используя параметры -f tree —tree-print-groupings.

3.3. Длинные диаграммы

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

Пример разделения диаграммы можно видеть в [RFC7407], где параграф 2.4 включает диаграмму конфигурации engine

       +--rw snmp
          +--rw engine
             // дополнительные параметры из ветви engine

Далее в параграфе 2.5 [RFC7407] показана диаграмма конфигурации target

       +--rw snmp
          +--rw target* [name]
             // дополнительные параметры из ветви target

Уже упомянутая команда pyang будет полезна для создания таких деревьев. Для приведенного выше примера использовалась команда

     pyang -f tree --tree-path /snmp/target ietf-snmp.yang

4. Диаграммы деревьев с точками монтирования YANG

Монтирование схемы YANG, определенное в [SCHEMA-MOUNT], требует некоторого обсуждения. Монтирование схемы является базовым механизмом, который позволяет монтировать один или несколько модулей YANG в заданном месте другой (родительской) схемы. Место установки указывается «точкой монтирования» и любой контейнер или список могут служить в качестве таких точек. Точки монтирования указываются путем включения оператора расширения mount-point в качестве субоператора для узла контейнера или списка. Таким образом узлы точек монтирования напрямую указываются в определении схемы модуля и могут быть указаны в дереве с помощью флага mp.

В следующем примере, заимствованном из [YANG-NIs], контейнер vrf-root включает оператор расширения mount-point в качестве части свого определения.

     module: ietf-network-instance
       +--rw network-instances
          +--rw network-instance* [name]
             +--rw name           string
             +--rw enabled?       boolean
             +--rw description?   string
             +--rw (ni-type)?
             +--rw (root-type)
                +--:(vrf-root)
                |  +--mp vrf-root

4.1. Представление деревьев с точками монтирования

Реальные модули, доступные под точкой монтирования, контролируются сервером и предоставляются клиентам. Эта информация обычно представляется через модуль монтирования схемы (ietf-yang-schema-mount), определенный в [SCHEMA-MOUNT]. Модуль монтирования схемы поддерживает раскрытие (exposure) как смонтированных схем, так и «родительских ссылок». Последние используются для оценки выражений XPath3 в смонтированных модулях и не представляют доступные клиенту пути, укаазнная ссылкой информация доступна клиентам через родительскую схему. Монтирование схемы также определяет «строенный» (inline) тип точек монтирования, где смонтированные модули раскрываются через библиотечный модуль YANG.

Хотя доступные под точкой монтирования модули не указываются в модулях YANG с точками монтирования, определяющий модуль документ будет описывать предусмотренное использование модуля и может указывать как модули, которые будут монтироваться, так и родительские модули, на которые монтируемые модули могут ссылаться. Тример такого описания можно найти в [YANG-NIs]. Конкретная реализация модуля с точками монтирования будет также поддерживать список монтируемых и указанных ссылками модулей. В описании предполагаемого использования и фактической реализации полезно указать, как смонтированные модули будут создаваться и указываться под точкой монтирования в диаграмме дерева.

В таких диаграммах точку монтирования следует рассматривать аналогично контейнеру, использующему группировку. Флаги следует устанавливать с учетом листа config, упомянутого выше, а указанные выше опции монтирования должны быть показаны для узлов верхнего уровня в монтируемом или указанном ссылкой модуле. В следующем примере, взятом из [YANG-Nis], представлен предыдущий пример с установленными модулями YANG ietf-routing [YANG-Routing] и ietf-ospf [OSPF-YANG], узлами из модуля YANG ietf-interfaces [RFC8343], доступными через родительскую ссылку, и узел config со значением true.

     module: ietf-network-instance
       +--rw network-instances
          +--rw network-instance* [name]
             +--rw name           string
             +--rw enabled?       boolean
             +--rw description?   string
             +--rw (ni-type)?
             +--rw (root-type)
                +--:(vrf-root)
                   +--mp vrf-root
                      +--ro rt:routing-state/
                      |  +--ro router-id?
                      |  +--ro control-plane-protocols
                      |     +--ro control-plane-protocol* [type name]
                      |        +--ro ospf:ospf
                      |           +--ro instance* [af]
                      |           ...
                      +--rw rt:routing/
                      |  +--rw router-id?
                      |  +--rw control-plane-protocols
                      |     +--rw control-plane-protocol* [type name]
                      |     +--rw ospf:ospf
                      |        +--rw instance* [af]
                      |           ...
                      +--ro if:interfaces@
                      |  ...
                      +--ro if:interfaces-state@
                      |  ...

Следует подчеркнуть, что модуль ietf-ospf дополняет ietf-routing и хотя он не указан в модуле монтирования схемы (или встроенной библиотеке YANG), в диаграмме дерева не используется специального обозначения монтирования.

Определения точки монтирования, самого по себе, не достаточно для указания используются ли смонтированные модули для данных конфигурации или иных данных. Это определяется листом config модуля ietf-yang-schema-mount, связанным с конкретной точкой монтирования и указывается на смонтированных узлах верхнего уровня. Например, в приведенном выше дереве, где лист config для модуля ietf-routing указывает false, узлы в ветви rt:routing будут иметь другие флаги.

                      +--ro rt:routing/
                      |  +--ro router-id?
                      |  +--ro control-plane-protocols
                         ...

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

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

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

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

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

[OSPF-YANG] Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, «Yang Data Model for OSPF Protocol», Work in Progress, draft-ietf-ospf-yang-10, March 2018.

[PYANG] «pyang», February 2018, <https://github.com/mbj4668/pyang>.

[RFC7407] Bjorklund, M. and J. Schoenwaelder, «A YANG Data Model for SNMP Configuration», RFC 7407, DOI 10.17487/RFC7407, December 2014, <https://www.rfc-editor.org/info/rfc7407>.

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

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

[SCHEMA-MOUNT] Bjorklund, M. and L. Lhotka, «YANG Schema Mount», Work in Progress, draft-ietf-netmod-schema-mount-08, October 2017.

[YANG-NIs] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, «YANG Model for Network Instances», Work in Progress, draft-ietf-rtgwg-ni-model-11, March 2018.

[YANG-Routing] Lhotka, L., Lindem, A., and Y. Qu, «A YANG Data Model for Routing Management (NMDA Version)», Work in Progress, draft-ietf-netmod-rfc8022bis-114, January 2018.

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

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Lou Berger (редактор)

LabN Consulting, L.L.C.

Email: lberger@labn.net


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3XML Path Language — язык путей XML.

4Работа завершена и опубликована в RFC 8349. Прим. перев.




RFC 8345 A YANG Data Model for Network Topologies

Internet Engineering Task Force (IETF)                          A. Clemm
Request for Comments: 8345                                        Huawei
Category: Standards Track                                      J. Medved
ISSN: 2070-1721                                                    Cisco
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                              N. Bahadur
                                                       Bracket Computing
                                                      H. Ananthakrishnan
                                                           Packet Design
                                                                  X. Liu
                                                                   Jabil
                                                              March 2018

Модель данных YANG для сетевой топологии

A YANG Data Model for Network Topologies

PDF

Тезисы

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

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

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

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

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

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

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

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

Оглавление

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

1. Введение

В этом документе вводится абстрактная (базовая) модель данных [RFC3444] YANG [RFC7950] для представления сетей и топологии. Модель делится на две части. Первая часть определяет модель данных сети, которая позволяет определить сетевые иерархии или стеки сетей (т. е. наложенные сети) и поддержку кадастра узлов, содержащихся в сети. Вторая часть дополняет базовую модель сети информацией, описывающей сетевую топологию. В частности, она добавляет концепцию каналов (соединений) и точек завершения для описания соединений узлов в сети. Кроме того, модель данных задает вертикальные отношения между сетями, которые могут быть дополнены для охвата как кадастров, так и топологии сети и/или служб.

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

Модель данных может быть дополнена путем задания отдельных типов сетей и топологии. Например, дополнение модели может включать информацию об атрибутах узлов для конкретного типа сети. Примеры дополненных моделей включают модели данных для топологии канального уровня (L2), варианты топологии сетевого уровня (L3) типа IGP, IS-IS [RFC1195] и OSPF [RFC2328], данные организации трафика (TE3) [RFC3209] и разные варианты топологии транспорта и служб. Информация для конкретного типа сети будут собираться в отдельные модели, зависящие от сетевой технологии.

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

               +------------------------+
               |                        |
               | Абстрактная модель сети|
               |                        |
               +------------------------+
                            |
                    +-------+-------+
                    |               |
                    V               V
             +------------+  ..............
             | Абстрактная|  :  Модель(и) :
             |   модель   |  :  кадастра  :
             |  топологии |  :            :
             +------------+  ''''''''''''''
                    |
      +-------------+-------------+-------------+
      |             |             |             |
      V             V             V             V
............  ............  ............  ............
:  Модель  :  :  Модель  :  :  Модель  :  :  Модель  :
: топологии:  : топологии:  : топологии:  : топологии:
:    L1    :  :    L2    :  :    L3    :  :  сервиса :
''''''''''''  ''''''''''''  ''''''''''''  ''''''''''''

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


Модуль YANG для абстрактной (базовой) сети, определенный в этом документе, называется ietf-network (параграф 6.1) и содержит список узлов абстрактной сети, а также определяет концепцию «иерахии сетей» (стека). Узел абстрактной сети может быть дополнен в моделях данных кадастра или топологии зависящими от этого кадастра или топологии атрибутами. Иерархия (стек) сетей позволяет данной сети иметь одну или множество «поддерживающих сетей». Отношения между моделью данных базовой сети, моделями данных кадастра и топологическими моделями данных показаны на рисунке 1 (линии из точек указывают возможность дополнения моделей, определенных в этом документе).

Модуль YANG для топологии сети, определенный в этом документе, называется ietf-network-topology (параграф 6.2) и определяет базовую топологическую модель с максимальным уровнем абстракции. Модуль определяет граф и компоненты топологии — узлы (node), ребра (edge) и точки завершения (termination point). Узлы (из модуля ietf-network) представляют вершины графа, а соединения — его ребра. Узлы также включают точки завершения для привязки соединений. Сеть может содержать множество топологий, например, топология разных уровней и топология перекрытий. Поэтому модель данных поддерживает связь между топологиями, а также зависимости между узлами и точками завершения разных топологий. Пример топологического стека приведен на рисунке 2.

       +---------------------------------------+
      /            _[X1]_          "Service"  /
     /           _/  :   \_                  /
    /          _/     :    \_               /
   /         _/        :     \_            /
  /         /           :      \          /
 /       [X2]__________________[X3]      /
+---------:--------------:------:-------+
           :              :     :
       +----:--------------:----:--------------+
      /      :              :   :        "L3" /
     /        :              :  :            /
    /         :               : :           /
   /         [Y1]_____________[Y2]         /
  /           *               * *         /
 /            *              *  *        /
+--------------*-------------*--*-------+
                *           *   *
       +--------*----------*----*--------------+
      /     [Z1]_______________[Z2] "Optical" /
     /         \_         *   _/             /
    /            \_      *  _/              /
   /               \_   * _/               /
  /                  \ * /                /
 /                    [Z]                /
+---------------------------------------+

Рисунок 2. Пример иерархии (стека) топологий.


На рисунке 2 показаны три уровня топологии. На верхнем уровне Service показаны отношения между элементами служб типа сервисных функций и цепочек услуг. Топология сетевого уровня L3 показывает элементы уровня L3 (IP), а уровень Optical показывает сетевые элементы физического уровня L1. Сервисные функции в топологии Service отображаются на сетевые элементы топологии L3, которые в свою очередь отображаются на элементы физического уровня топологии Optical. Две сервисных функции (X1 и X3) отображаются на один элемент L3 (Y2) — это может происходить, например, при реализации двух функций на одной виртуальной машине VM4 (или сервере) — и сообща используют сетевые интерфейсы. Один сетевой элемент L3 (Y2) отображается на два элемента уровня Optical (Z2 и Z). Это может быть, например, при подключении одного маршрутизатора IP к разным мультиплексорам ROADM5 в оптическом домене.

Другой пример стека топологий служб показан на рисунке 3.

                         VPN1                       VPN2
      +---------------------+    +---------------------+
     /   [Y5]...           /    / [Z5]______[Z3]      /
    /    /  \  :          /    /  : \_       / :     /
   /    /    \  :        /    /   :   \_    /  :    /
  /    /      \  :      /    /   :      \  /   :   /
 /   [Y4]____[Y1] :    /    /   :       [Z2]   :  /
+------:-------:---:--+    +---:---------:-----:-+
       :        :   :         :          :     :
       :         :   :       :           :     :
       :  +-------:---:-----:------------:-----:-----+
       : /       [X1]__:___:___________[X2]   :     /
       :/         / \_  : :       _____/ /   :     /
       :         /    \_ :  _____/      /   :     /
      /:        /       \: /           /   :     /
     / :       /        [X5]          /   :     /
    /   :     /       __/ \__        /   :     /
   /     :   /    ___/       \__    /   :     /
  /       : / ___/              \  /   :     /
 /        [X4]__________________[X3]..:     /
+------------------------------------------+
                                 L3 Topology

Рисунок 3. Пример топологической иерархии (стека).


На рисунке 3 показаны две топологии сервиса VPN (VPN1 и VPN2) организованные на базе общей топологии L3. Каждая топология сервиса VPN отображается на подмножество узлов общей топологии L3.

Существует множество применений для такой модели данных. Например, в контексте интерфейса в систему маршрутизации I2RS6 узлы сети могут использовать модель данных для понимания общей топологии сети и ее представления сетевому контроллеру. Контроллер может использовать данные подтвержденной топологии для сравнения и согласования своего представления топологии сети с ее представлением управляемыми им элементами. В дополнение к этому узлы сети могут распространять свое понимание для сравнения и согласования между собой или с помощью контроллера. Помимо сетевых элементов и непосредственного контекста самого I2RS, сетевой контроллер может использовать модель данных для представления своего взгляда на топологию, которую он контролирует, приложениям на своем северном интерфейсе. Другие случаи, где может быть применена описанная модель данных, рассмотрены в [USECASE-REQS].

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

Модель данных позволяет сети ссылаться на поддерживающую сеть, поддерживающие узлы, каналы и т. п. Модель также позволяет делить на уровни сеть, расположенную «поверх» сети, контролируемой системой. Этот позволяет настраивать наложенные сети поверх тех сетей, которые были обнаружены. В частности, эта модель данных структурирована для поддержки реализации в форме части эфемерного хранилища данных [RFC8342], требования к которому определены в разделе 3 [RFC8242]. Это позволяет записывать данные сетевой топологии, т. е. обеспечивает возможность настройки клиентом без контроля системы для ссылки на динамически получаемые данные, которые контролируются системой, а не настраиваются клиентом. Простой пример использования может включать наложенную сеть, которая поддерживается динамически определяемой сетевой топологией с маршрутизацией IP. Когда реализация помещает записанные данные для этой модели в эфемерное хранилище, такая сеть может указывать на другую сеть, контролируемую системой.

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

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

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

Datastore – хранилище данных

Концептуальное место для хранения и доступа к информации. Хранилище может быть реализовано, например, в виде файла, базы данных, flash-памяти или их комбинации. Хранилище отображается на экземпляр дерева данных YANG (определение из [RFC8342]).

Data subtree – ветвь (субдерево) данных

Конкретный узел данных и узлы, иерархические входящие в него.

IGP

Interior Gateway Protocol — протокол внутреннего шлюза.

IS-IS

Intermediate System to Intermediate System — протокол взаимодействия промежуточных систем.

OSPF

Open Shortest Path First — сначала кратчайший путь (протокол маршрутизации по состоянию канала).

SDN

Software-Defined Networking — программно определяемая сеть.

URI

Uniform Resource Identifier — унифицированный идентификатор ресурса.

VM

Virtual Machine — виртуальная машина.

4. Структура модели

4.1. Базовая модель сети

Модель данных абстрактной (базовой) сети определена в модуле ietf-network. Ее структура показана на рисунке 4. Обозначения на рисунке соответствуют синтаксису, используемому в [RFC8340].

   module: ietf-network
     +--rw networks
        +--rw network* [network-id]
           +--rw network-id            network-id
           +--rw network-types
           +--rw supporting-network* [network-ref]
           |  +--rw network-ref    -> /networks/network/network-id
           +--rw node* [node-id]
              +--rw node-id            node-id
              +--rw supporting-node* [network-ref node-ref]
                 +--rw network-ref
                 |       -> ../../../supporting-network/network-ref
                 +--rw node-ref       -> /networks/network/node/node-id

Рисунок 4. Структура модели данных абстрактной (базовой) сети.


Модель данных содержит контейнер со списком сетей. Каждая сеть фиксируется в своей записи, указанной network-id.

Сеть имеет тот или иной тип (например L2, L3, OSPF, IS-IS) или относится сразу к нескольким типам. Тип или типы указываются под контейнером network-types. В этой модели он служит лишь дополнением цели. Модули для конкретного типа сети будут позднее добавлять новые узлы данных для представления типа ниже этой цели (т. е. ниже network-types) с помощью дополнения YANG.

Когда сеть имеет определенный тип, она будет содержать соответствующий узел данных. Узлы всегда следует представлять с использованием контейнеров присутствия, а не листьев типа empty. Это обеспечивает представление иерархий подтипов сетей в информации экземпляра. Например, экземпляр сети OSPF (который в то же время является сетью L3 unicast IGP) будет содержать под network-types другой контейнер присутствия l3-unicast-igp-network, который в свою очередь будет содержать контейнер присутствия ospf-network. Фактические примеры можно найти в [RFC8346].

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

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

Следует отметить, что узел не существует отдельно от сети — он является частью содержащей его сети. В тех случаях, когда устройство или элемент является частью нескольких сетей или нескольких уровней стека сетей, такое устройство или объект будет представлено множеством узлов (по одному для каждой сети). Иными словами, узел представляет абстракцию устройства для отдельной сети, в которую это устройство входит. Для индикации включения одного устройства или элемента в разные топологии или сети можно создать одну «физическую» сеть со списком узлов для каждого из устройств или элементов. Эту (физическую) сеть (узлы и элементы сети) можно называть базовой (underlay) сетью, а ее узлы — узлами других (логических) сетей и узлов. Отметим, что модель данных позволяет определить более одной базовой сети (и узла), что дает возможность одновременно представлять многоуровневые топологии и топологии служб, а также физическое размещение.

Подобно сети, узел может поддерживаться другими узлами и отображаться на один или множество других узлов в базовой сети. Это фиксируется в списке supporting-node (поддерживающий узел). Результирующая иерархия узлов позволяет также представлять стеки устройств, где узлы одного уровня поддерживаются набором узлов нижележащего уровня. Например,

  • узел router может поддерживаться узлом, представляющим процессор маршрутизатора, и отдельными узлами для разных интерфейсных плат и сервисных модулей;

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

и т. д.

Данные о сети на определенном уровне могут происходить один из двух источников: (1) данные настраиваются клиентским приложением (например, в случае наложенных сетей эти данные могут задаваться контроллером SDN) или (2) данные автоматически контролируются системой в случае сети, которая может быть обнаружена. Настраиваемая (наложенная) сеть может ссылаться на обнаруживаемую (базовую) сеть.

Для учета этих возможностей используется пересмотренная архитектура хранилищ данных [RFC8342]. В частности, для каждой сети источник данных указывается аннотацией метаданных origin [RFC7952] (в соответствии с определением [RFC8342]) — intended для данных, настраиваемых клиентским приложением и learned для раскрываемых данных. Раскрываемые данные автоматически заполняются как часть рабочего хранилища данных. Настраиваемые данные являются частью конфигурации и предусмотренных хранилищ. Настраиваемые данные, которые действительно применяются, дополнительно отражаются в рабочем хранилище. Данные в этом хранилище всегда будут иметь полную целостность ссылок. Если сконфигурированный элемент данных (например, узел) имеет «оборванную» ссылку на отсутствующий элемент (например, поддерживающий узел), этот сконфигурированный элемент будет автоматически удален из рабочего хранилища и останется лишь в хранилище предполагаемой конфигурации. Для устранения конфликта клиентское приложение (например, контроллер SDN) должно указать корректные ссылки на поддерживающие ресурсы.

4.2. Базовая модель данных сетевой топологии

Модель данных абстрактной (базовой) сетевой топологии определена в модуле ietf-network-topology. Она построена на основе модели данных сети, определенной в модуле ietf-network и дополненном каналами (определяют соединения между узлами) и точками завершения (содержащиеся в узлах привязки к каналам). Структура модели топологии сети представлена на рисунке 5. Синтаксис обозначений соответствует [RFC8340].

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

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

   module: ietf-network-topology
     augment /nw:networks/nw:network:
       +--rw link* [link-id]
          +--rw link-id            link-id
          +--rw source
          |  +--rw source-node?   -> ../../../nw:node/node-id
          |  +--rw source-tp?     leafref
          +--rw destination
          |  +--rw dest-node?   -> ../../../nw:node/node-id
          |  +--rw dest-tp?     leafref
          +--rw supporting-link* [network-ref link-ref]
             +--rw network-ref
             |       -> ../../../nw:supporting-network/network-ref
             +--rw link-ref       leafref
     augment /nw:networks/nw:network/nw:node:
       +--rw termination-point* [tp-id]
          +--rw tp-id                           tp-id
          +--rw supporting-termination-point*
                  [network-ref node-ref tp-ref]
             +--rw network-ref
             |       -> ../../../nw:supporting-node/network-ref
             +--rw node-ref
             |       -> ../../../nw:supporting-node/node-ref
             +--rw tp-ref         leafref

Рисунок 5. Структура модели данных топологии абстрактной (базовой) сети.


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

4.3. Расширение модели данных

Чтобы создать производную модель данных для конкретного типа сети, базовая модель может быть расширена. Это можно сделать примерно так — создается новый модуль YANG для нового типа сети и в этом модуле определяются дополнения к модулям ietf-network и ietf-network-topology.

Начнем дополнение с модуля ietf-network. Сначала требуется определить новый тип сети — это делается путем определения контейнера присутствия, который представляет новый тип сети. Новый тип добавляется под контейнером базовых типов. Далее определяются узлы данных для всех параметров узла, относящиеся к конкретному типу сети, и добавляются в список узлов. Новые узлы данных могут быть определены как условные (when) по наличию соответствующего типа в содержащей сети. При наличии каких-либо требований или ограничений применительно к иерархии сетей типа потребности нового типа сети в определенной базовой сети, можно определить соответствующие ограничения, а также дополнения к списку поддерживающих сетей. Однако следует соблюдать осторожность и избегать слишком большого числа ограничений.

Далее определяются дополнения для модуля ietf-network-topology. Определяются узлы данных для параметров каналов и точек завершения, которые относятся к новому типу сети. Эти узлы добавляются в списки каналов и точек завершения, соответственно. Эти узлы данных также могут определяться по условию присутствия соответствующего типа сети в содержащей сети с помощью оператора when.

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

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

4.4. Обсуждение и выбор некоторых решений

4.4.1. Структура контейнера

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

4.4.2. Базовые иерархии и отображения

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

Когда требуются более конкретные отображения между верхним и нижним уровнем, эта информация может фиксироваться в модулях дополнения. Например, для указания того, что точка завершения определенного типа сети отображается на интерфейс, может быть добавлен модуль дополнения для точки завершения. Дополнение создает лист типа interface-ref, который указывает на соответствующий интерфейс [RFC8343]. Аналогично, если узел отображается на конкретное устройство или элемент сети, модуль дополнения может дополнять данные узла листом, указывающим на элемент сети.

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

4.4.3. Изменения в базовых сетях

В сети возможны разные флуктуации, даже если эта сеть является базовой для других сетей. При удалении поддерживающего узла, канала или точки завершения поддерживающие leafref в наложении становятся «подвешенными». Для таких случаев в модели данных используется конструкция require-instance языка YANG 1.1 [RFC7950].

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

Приложение, поддерживающее наложение, отвечает за возможность оттока в базовую сеть. Когда сервер получает запрос на настройку наложенной сети, ему следует проверить, указывают ли поддерживающие узлы/каналы/точки завершения на реально существующие узлы базовой сети, т. е. убедиться в том, что узлы отражены в хранилище рабочего состояния. Запросы конфигурации, в которых узлы/каналы/точки завершения указывают на несуществующие узлы, следует отвергать. Приложение отвечает за обновление наложений при последующем удалении узла/канала/точки завершения. По этой причине приложение может подписаться на обновления в базовой сети, например, с помощью механизмов, определенных в [YANG-Push].

4.4.4. Использование группировок

Модель данных использует группировки вместо простого определения узлов данных как встроенных (inline). Это упрощает включение соответствующих узлов данных в уведомления, не требуя заново определять каждый включаемый узел данных. Однако это усложняет задание ограничений, поскольку ограничения, вовлекающие узлы данных вне группировки требуется задавать вместе с оператором uses при использовании группировки. Это также означает, что ограничения и операторы языка описания путей (XPath7) требуется указывать так, чтобы они сначала перемещались «вниз» и выбирали весь набор узлов, а не просто задавать их для отдельных узлов данных.

4.4.5. Тип и направленность соединений

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

4.4.6. Многодомность и агрегирование каналов

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

4.4.7. Избыточность отображения

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

4.4.8. Типизация

Типы сетей представляются с использованием контейнера, который содержит узел данных для каждого из имеющихся в сети типа. Сеть может включать одновременно несколько типов сетей, поэтому применяется контейнер вместо конструкции case, причем каждый тип сети в свою очередь представляется выделенным контейнером присутствия. Причина того, чтобы не использовать просто пустой лист или (что еще проще) отказаться от контейнера network и просто использовать взамен лист-список (leaf-list) network-type, заключается в возможности представления иерархий классов для типов сетей, где один тип уточняет другой. Контейнеры для определенного типа сети определяются в связанных с сетью модулях, дополняющий контейнер network-types.

4.4.9. Представление одного устройства в нескольких сетях

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

Этот сценарий представлен на рисунке 6, где приведены 3 сети с двумя узлами в каждой. Физическая сеть (P на рисунке) состоит из двух узлов (D1 и D2), являющихся устройствами. Вторая сеть (X) имеет третью (Y) в качестве базовой и для обеих сетей X и Y физическая сеть P служит базовой. X1 имеет базовые узлы Y1 и D1, а для Y1 узел D1 является базовым. Аналогично, X2 имеет базовые узлы Y2 и D2, а Y2 имеет базовый узел D2. Размещение X1 и Y1 на обном физическом узле (D1) легко увидеть на рисунке.

                  +---------------------+
                 /   [X1]____[X2]      /  X (наложенный сервис)
                +----:--:----:--------+
                  ..:    :..: :
         ........:     ....: : :....
  +-----:-------------:--+    :     :...
 /   [Y1]____[Y2]....:  /      :..      :
+------|-------|-------+          :..    :...
 Y(L3) |       +---------------------:-----+ :
       |                         +----:----|-:----------+
       +------------------------/---[D1]  [D2]         /
                               +----------------------+
                                 P (физическая сеть)

Рисунок 6. Пример иерархии топологий — множественное наложение.


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

4.4.10. Поддержка настроенной клиентом и управляемой системой топологии

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

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

В общем случае настроенная сетевая топология будет указывать базовую топологию и включать информацию об уровнях, такую, как поддерживающие узлы, каналы и точки завершения. Поддерживающие объекты должны быть созданы в рабочем хранилище. Если настроенный элемент данных (такой как узел) имеет «подвешенную» ссылку на несуществующий элемент данных (например, поддерживающий узел), настроенный элемент будет автоматически удален из хранилища <operational> и отобразиться лишь в <intended>. Клиентское приложение может разрешить такую проблему и убедиться в корректности настройки ссылок на поддерживающие ресурсы.

Для каждой сети источник данных указывается в аннотации метаданных origin [RFC7952], определенной в [RFC8342]. В общем случае источником обнаруженных сетевых данных является обучение (learned), а настроенных — intended.

4.4.11. Идентификаторы в виде строк и URI

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

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

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

Эта модель данный использует типы данных, определенные в [RFC6991].

Это независимая от протоколов модель данных YANG с топологической информацией. Она отделена и не связана с моделями данных, служащими для настройки протоколов маршрутизации или маршрутной информации (например, модуль YANG ietf-routing [RFC8022]).

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

6. Модули YANG

6.1. Определение абстрактной сети — ietf-network

   <CODE BEGINS> file "ietf-network@2018-02-26.yang"

   module ietf-network {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-network";
     prefix nw;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     organization
       "Рабочая группа IETF I2RS (интерфейс в систему маршрутизации)";

     contact
       "WG Web:    <https://datatracker.ietf.org/wg/i2rs/> 
        WG List:   <mailto:i2rs@ietf.org> 

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

        Editor:    Jan Medved
                   <mailto:jmedved@cisco.com> 

        Editor:    Robert Varga
                   <mailto:robert.varga@pantheon.tech> 

        Editor:    Nitin Bahadur
                   <mailto:nitin_bahadur@yahoo.com> 

        Editor:    Hariharan Ananthakrishnan
                   <mailto:hari@packetdesign.com> 

        Editor:    Xufeng Liu
                   <mailto:xufeng.liu.ietf@gmail.com>"; 

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

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

        Распространение и использование с исходной или двоичной форме
        с внесением изменений или без них определяется лицензией
        Simplified BSD License, изложенной в разделе 4.c IETF Trust
        Legal Provisions для документов IETF
        (https://trustee.ietf.org/license-info). 

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

     revision 2018-02-26 {
       description
         "Первоначальный вариант.";
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }

     typedef node-id {
       type inet:uri;
       description
         "Идентификатор узла. Точная структура node-id будет
          определяться реализацией. Например, некоторые 
          реализации МОГУТ выбрать URI с включением network-id
          как части пути. Идентификаторы СЛЕДУЕТ выбирать так,
          чтобы один и тот же узел в реальной сетевой топологии
          всегда указывался одним и тем же идентификатором, даже при
          размещении модели данных в раздельных хранилищах. Реализация
          МОЖЕТ фиксировать в идентификаторах некую семантику, например,
          для указания типа узла.";
     }

     typedef network-id {
       type inet:uri;
       description
	  "Идентификатор сети. Точная структура network-id будет зависеть от
	   реализации. Идентификаторы СЛЕДУЕТ выбирать так, чтобы одна и та же
          сеть всегда указывалась одним идентификатором даже при создании
          экземпляров модели в разных хранилищах данных. Реализация МОЖЕТ
          зафиксировать семантику идентификаторов (например, для указания
          типа сети).";
     }

     grouping network-ref {
       description
         "Содержит информацию, требуемую для ссылки на сеть (например, базовая сеть).";
       leaf network-ref {
         type leafref {
           path "/nw:networks/nw:network/nw:network-id";
         require-instance false;
         }
         description
           "Служит для ссылки на сеть (например, базовая сеть).";
       }
     }

     grouping node-ref {
       description
         "Содержит информацию, требуемую для ссылки на узел.";
       leaf node-ref {
         type leafref {
           path "/nw:networks/nw:network[nw:network-id=current()/../"+
             "network-ref]/nw:node/nw:node-id";
           require-instance false;
         }
         description
           "Служит для ссылки на узел. Излы идентифицируются относительно сети,
            которая их содержит.";
       }
       uses network-ref;
     }

     container networks {
       description
         "Служит контейнером верхнего уровня для списка сетей.";
       list network {
         key "network-id";
         description
           "Описывает сеть. Сеть обычно содержит опись узлов, топологическую
            информацию (дополненную моделью данных топологии сети) и сведения
            об уровнях.";
         leaf network-id {
           type network-id;
           description
             "Идентифицирует сеть.";
         }
         container network-types {
           description
             "Служит в качестве цели дополнения. Тип сети указывается
              соответствующими контейнерами присутствия, добавленными
              в этот контейнер.";
         }
         list supporting-network {
           key "network-ref";
           description
             "Базовая сеть, испольуемая для представления многоуровневой топологии.";
           leaf network-ref {
             type leafref {
               path "/nw:networks/nw:network/nw:network-id";
             require-instance false;
             }
             description
               "Ссылка на базлвую сеть.";
           }
         }
         list node {
           key "node-id";
           description
             "Опись узлов сети.";
           leaf node-id {
             type node-id;
             description
               "Уникальный идентификатор узла в сети.";
           }
           list supporting-node {
             key "network-ref node-ref";
             description
               "Представляет другой узел, находящийся в базовой сети и 
                поддерживающий данный узел. Служит для представления 
                многоуровневой структуры.";
             leaf network-ref {
               type leafref {
                 path "../../../nw:supporting-network/nw:network-ref";
               require-instance false;
               }
               description
                 "Указывает базовую сеть, к которой относится базовый узел.";
             }
             leaf node-ref {
               type leafref {
                 path "/nw:networks/nw:network/nw:node/nw:node-id";
               require-instance false;
               }
               description
                 "Указывает сам базовый узел.";
             }
           }
         }
       }
     }
   }

   <CODE ENDS>

6.2. Определение топологии абстрактной сети — ietf-network-topology

   <CODE BEGINS> file "ietf-network-topology@2018-02-26.yang"

   module ietf-network-topology {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
     prefix nt;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-network {
       prefix nw;
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }

     organization
       "Рабочая группа IETF I2RS (интерфейс в систему маршрутизации)";

     contact
       "WG Web:    <https://datatracker.ietf.org/wg/i2rs/> 
        WG List:   <mailto:i2rs@ietf.org> 

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

        Editor:    Jan Medved
                   <mailto:jmedved@cisco.com> 

        Editor:    Robert Varga
                   <mailto:robert.varga@pantheon.tech> 

        Editor:    Nitin Bahadur
                   <mailto:nitin_bahadur@yahoo.com> 

        Editor:    Hariharan Ananthakrishnan
                   <mailto:hari@packetdesign.com> 

        Editor:    Xufeng Liu
                   <mailto:xufeng.liu.ietf@gmail.com>"; 

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

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

        Распространение и использование с исходной или двоичной форме
        с внесением изменений или без них определяется лицензией
        Simplified BSD License, изложенной в разделе 4.c IETF Trust
        Legal Provisions для документов IETF
        (https://trustee.ietf.org/license-info). 

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

     revision 2018-02-26 {
       description
         "Первый выпуск.";
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }

     typedef link-id {
       type inet:uri;
       description
         "Идентификатор канала в топологии. Точная структура link-id
          зависит от реализации. Идентификаторы СЛЕДУЕТ выбирать так,
          что данный канал в реальной сетевой топологии всегда будет
          указываться одним идентификатором даже при размещении модели
          данных в раздельных хранилищах. Реализация МОЖЕТ выбрать
          семантику идентификаторов, например, указывать тип канала 
          и/или тип топологии, к которой относится канал.";
     }

     typedef tp-id {
       type inet:uri;
       description
         "Идентификатор точки завершения на узле. Точная структура tp-id
          зависит от реализации. Идентификаторы СЛЕДУЕТ выбирать так,
          данная точка завершения всегда будет указываться одним
          идентификатором даже при размещении модели данных в
          раздельных хранилищах. Реализация МОЖЕТ выбрать семантику
          идентификаторов, например, указывать тип точки завершения 
          и/или тип узла, к которому относится точка завершения.";
     }

     grouping link-ref {
       description
         "Эта группировка может служить для указания канала в
          конкретной сети. Хотя этот модуль не применяет группировку,
          она определена для удобства дополнения модулей.";
       leaf link-ref {
         type leafref {
           path "/nw:networks/nw:network[nw:network-id=current()/../"+
             "network-ref]/nt:link/nt:link-id";
           require-instance false;
         }
         description
           "Тип для абсолютной ссылки на экземпляр канала (этот тип не
            следует применять для относительных ссылок, используя для
            них относительный путь.)";
       }
       uses nw:network-ref;
     }

     grouping tp-ref {
       description
         "Эта группировка может служить для указания точки завершения
          на конкретном узле. Хотя этот модуль не применяет группировку,
          она определена для удобства дополнения модулей.";
       leaf tp-ref {
         type leafref {
           path "/nw:networks/nw:network[nw:network-id=current()/../"+
             "network-ref]/nw:node[nw:node-id=current()/../"+
             "node-ref]/nt:termination-point/nt:tp-id";
           require-instance false;
         }
         description
           "Тип для абсолютной ссылки на точку завершения
            (этот тип не следует применять для относительных ссылок,
            используя для них относительный путь.)";
       }
       uses nw:node-ref;
     }

     augment "/nw:networks/nw:network" {
       description
         "Add links to the network data model.";
       list link {
         key "link-id";
         description
           "Сетевой канал соединяет локальный (источник) и удаленный
            (получатель) узел через набор точек завершения 
            соответствующих узлов. Можно иметь несколько каналов между
            парой узлов. Канал можно перемещать между точками
            завершения. Поэтому для однозначного различения каналов
            каждый из них указывается выделенным идентификатором.
            Отметим, что канал моделирует соединение «точка-точка», а
            не многоточечное.";
         leaf link-id {
           type link-id;
           description
             "Идентификатор канала в топологии. Канал связан с
              топологией, к которой он относится.";
         }
         container source {
           description
             "Контейнер, содержащий логический источник конкретного канала.";
           leaf source-node {
             type leafref {
               path "../../../nw:node/nw:node-id";
               require-instance false;
             }
             description
               "Идентификатор узла-источника. Должен быть в той же топологии.";
           }
           leaf source-tp {
             type leafref {
               path "../../../nw:node[nw:node-id=current()/../"+
                 "source-node]/termination-point/tp-id";
               require-instance false;
             }
             description
               "Эта точка завершения размещается внутри узла-источника и
                завершает канал.";
           }
         }

         container destination {
           description
             "Контейнер, содержащий логического получателя конкретного канала.";
           leaf dest-node {
             type leafref {
               path "../../../nw:node/nw:node-id";
             require-instance false;
             }
             description
               "Идентификатор узла-получателя. Должен быть в той же топологии.";
           }
           leaf dest-tp {
             type leafref {
               path "../../../nw:node[nw:node-id=current()/../"+
                 "dest-node]/termination-point/tp-id";
               require-instance false;
             }
             description
               "Эта точка завершения размещается внутри узла-получателя и
                завершает канал.";
           }
         }
         list supporting-link {
           key "network-ref link-ref";
           description
             "Указывает канал или каналы, от которых данный канал зависит.";
           leaf network-ref {
             type leafref {
               path "../../../nw:supporting-network/nw:network-ref";
             require-instance false;
             }
             description
               "Этот лист указывает топологию, в которой присутствует 
                поддерживающий канал.";
           }

           leaf link-ref {
             type leafref {
               path "/nw:networks/nw:network[nw:network-id=current()/"+
                 "../network-ref]/link/link-id";
               require-instance false;
             }
             description
               "Этот лист указывает канал, который является базы поддержки
                данного канала. Петли ссылок, где канал указывает себя
                как свою же базу напрямую или опосредованно, не разрешены.";
           }
         }
       }
     }
     augment "/nw:networks/nw:network/nw:node" {
       description
         "Дополняет точки завершения каналов. Эти точки могут в конце
          концов отображаться на интерфейсы.";
       list termination-point {
         key "tp-id";
         description
           "Точка завершения может быть окончанием канала. В зависимости
            от топологии такая точка может указывать, например, на порт
            или интерфейс.";
         leaf tp-id {
           type tp-id;
           description
             "Идентификатор точки завершения.";
         }
         list supporting-termination-point {
           key "network-ref node-ref tp-ref";
           description
             "Этот список указывает все точки завершения, от которых 
              данная точка завершения зависит или куда отображается.
              Эти точки будут сами по себе содержаться в поддерживающем
              узле. Эта информация о зависимостях может быть выведена из
              зависимостей между каналами. Поэтому не требуется отдельно
              настраивать этот элемент и нет необходимости формулировать
              соответствующее ограничение. Нужная информация просто
              обеспечивается реализующей системой.";
           leaf network-ref {
             type leafref {
               path "../../../nw:supporting-node/nw:network-ref";
             require-instance false;
             }
             description
               "Этот лист указывает, в какой топологии присутствует
                поддерживающая точка завершения.";
           }
           leaf node-ref {
             type leafref {
               path "../../../nw:supporting-node/nw:node-ref";
             require-instance false;
             }
             description
               "Этот лист указывает, в каком узле присутствует
                поддерживающая точка завершения.";
           }
           leaf tp-ref {
             type leafref {
               path "/nw:networks/nw:network[nw:network-id=current()/"+
                 "../network-ref]/nw:node[nw:node-id=current()/../"+
                 "node-ref]/termination-point/tp-id";
               require-instance false;
             }
             description
               "Ссылка на базовый узел (этот узел должен находиться
                в другой топологии).";
           }
         }
       }
     }
   }

   <CODE ENDS>

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

Этот документ регистрирует перечисленные ниже URI пространств имен в реестре IETF XML Registry [RFC3688].

   URI: urn:ietf:params:xml:ns:yang:ietf-network
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-network-topology
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-network-state
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-network-topology-state
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.

   This document registers the following YANG modules in the "YANG
   Module Names" registry [RFC6020]:

   Name:      ietf-network
   Namespace: urn:ietf:params:xml:ns:yang:ietf-network
   Prefix:    nw
   Reference: RFC 8345

   Name:      ietf-network-topology
   Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
   Prefix:    nt
   Reference: RFC 8345

   Name:      ietf-network-state
   Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state
   Prefix:    nw-s
   Reference: RFC 8345

   Name:      ietf-network-topology-state
   Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state
   Prefix:    nt-s
   Reference: RFC 8345

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

Заданные в этом документе модули YANG определяют схему для данных, которые предназначены для доступа через сеть с помощью протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный сетевой транспорт с обязательной реализацией протокола SSH9 [RFC6242], а нижним уровнем RESTCONF — протокол HTTPS с обязательной реализацией TLS [RFC5246].

Модель контроля доступа NETCONF [RFC8341] позволяет разрешать доступ к заданному подмножеству доступных операций и содержимого NETCONF или RESTCONF лишь уполномоченным пользователям NETCONF или RESTCONF.

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

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

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

В модуле ietf-network:

  • network — вредоносный клиент может пытаться удалить или добавить сеть в целью удаления наложенной топологии или добавления ненужного наложения;

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

  • node — вредоносный клиент может пытаться удалить или добавить узел, например, для нарушения работы наложенной топологии;

  • supporting node — вредоносный клиент может пытаться сменить поддерживающий узел для нарушения уровней наложения.

В модуле ietf-network-topology:

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

  • termination point — вредоносный клиент может пытаться удалить точки завершения с узла, добавить «фантомные» точки на узел или изменить зависимости уровней для точек завершения с целью нарушения целостности топологии и возможного нарушения порядка операций наложения.

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

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

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

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

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

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

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

[RFC2328] Moy, J., «OSPF Version 2», STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

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

[RFC3444] Pras, A. and J. Schoenwaelder, «On the Difference between Information Models and Data Models», RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.

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

[RFC7952] Lhotka, L., «Defining and Using Metadata with YANG», RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>.

[RFC8022] Lhotka, L. and A. Lindem, «A YANG Data Model for Routing Management», RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>.

[RFC8242] Haas, J. and S. Hares, «Interface to the Routing System (I2RS) Ephemeral State Requirements», RFC 8242, DOI 10.17487/RFC8242, September 2017, <https://www.rfc-editor.org/info/rfc8242>.

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

[RFC8343] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, «A YANG Data Model for Layer 3 Topologies», RFC 8346, DOI 10.17487/RFC8346, March 2018, <https://www.rfc-editor.org/info/rfc8346>.

[USECASE-REQS] Hares, S. and M. Chen, «Summary of I2RS Use Case Requirements», Work in Progress, draft-ietf-i2rs-usecase-reqs-summary-03, November 2016.

[YANG-Push] Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, «YANG Datastore Subscription», Work in Progress, draft-ietf-netconf-yang-push-1510, February 2018.

Приложение A. Примеры использования модели

A.1. Излечение топологии из элемента сети

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

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

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

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

A.2. Изменение топологии TE, импортированной из оптического контроллера

Рассмотрим случай, где Optical Controller представляет свою топологию клиентскому контроллеру пакетов в абстрактных терминах TE. Эта настраиваемая топология (которая объединяется с собственной топологией клиента) содержит достаточно данных, чтобы рассчитывающий пути клиент мог выбрать путь через оптический домен в соответствии с его политикой. Если клиент считает, что в данный момент) импортированная топология не соответствует в точности его требованиям, он может запросить изменение топологии. Такой запрос настройки может включать добавление или удаление элементов топологии или изменение атрибутов имеющихся элементов. Для оптического контроллера эти запросы транслируются в изменение настроек экспортируемой абстрактной топологии.

A.3. Аннотирование топологии для локальных расчетов

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

A.4. Основанная на контроллере SDN конфигурация наложенной сети

В этом варианте контроллер SDN (например, Open Daylight) поддерживает представление топологии, которой он управляет, на основе информации, обнаруженной в сети. Кроме того, он обеспечивает приложение, в котором настраивается и поддерживается топология наложения.

Таким образом, контроллер SDN должен поддерживать две роли:

  • клиент сети;

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

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

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

Приложение B. Модели YANG для реализаций без поддержки NMDA

Определенные в этом документе модули YANG предназначены для применения с реализациями, поддерживающими архитектуру NMDA, определенную в [RFC8342]. Чтобы реализации могли использовать модель данных даже без поддержки NMDA, определены два используемых совместно модуля ietf-network-state и ietf-network-topology-state, представляющие рабочее состояние и топологию сети, соответственно. Эти модули «отражают» модули ietf-network и ietf-network-topology (параграфы 6.1 и 6.2), однако все их узлы не поддерживают настройку. Они представляют состояние, которое возникает при (1) получении топологической информации из сети или применения конфигурации из «отраженных» модулей.

Парные модули ietf-network-state и ietf-network-topology-state являются избыточными и их не следует включать в реализации с поддержкой NMDA, поэтому они определены в приложениях B.1 и B.2 (ниже), а не в основном тексте.

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

B.1. Модуль YANG для состояния сети

<CODE BEGINS> file "ietf-network-state@2018-02-26.yang"

module ietf-network-state {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
  prefix nw-s;

  import ietf-network {
    prefix nw;
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }

  organization
    "Рабочая группа IETF I2RS (интерфейс в систему маршрутизации)";

  contact
    "WG Web:    <https://datatracker.ietf.org/wg/i2rs/> 
     WG List:   <mailto:i2rs@ietf.org> 

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

     Editor:    Jan Medved
                <mailto:jmedved@cisco.com> 

     Editor:    Robert Varga
                <mailto:robert.varga@pantheon.tech> 

     Editor:    Nitin Bahadur
                <mailto:nitin_bahadur@yahoo.com> 

     Editor:    Hariharan Ananthakrishnan
                <mailto:hari@packetdesign.com> 

     Editor:    Xufeng Liu
                <mailto:xufeng.liu.ietf@gmail.com>"; 

  description
    "Этот модуль определяет общую базовую модель данных для
     набора узлов в сети. Определения узлов затем применяются
     в сетевой топологии и описях (inventorY). Модуль представляет
     информацию, которая (1) изучается автоматически и заполняется
     или (2) является результатом применения сетевой информации,
     заданной в соответствии с моделью данных ietf-network,
     отражающей соответствующие узлы этой модели.

     Модель данных отражает ietf-network, но содержит лишь данные
     состояния, доступные только для чтения. Модель данных не 
     требуется, когда инфраструктура базовой реализации
     поддерживает архитектуру NMDA.

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

     Распространение и использование с исходной или двоичной форме
     с внесением изменений или без них определяется лицензией
     Simplified BSD License, изложенной в разделе 4.c IETF Trust
     Legal Provisions для документов IETF
     (https://trustee.ietf.org/license-info). 

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

  revision 2018-02-26 {
    description
      "Первый выпуск.";
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }

  grouping network-ref {
    description
      "Содержит информацию, необходимую для указания сети, например,
       указывает базовую сеть.";
    leaf network-ref {
      type leafref {
        path "/nw-s:networks/nw-s:network/nw-s:network-id";
      require-instance false;
      }
      description
        "Служит для указания сети, например, базовой.";
    }
  }

  grouping node-ref {
    description
      " Содержит информацию, необходимую для указания узла.";
    leaf node-ref {
      type leafref {
        path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
          "/../network-ref]/nw-s:node/nw-s:node-id";
        require-instance false;
      }
      description
        "Служит для указания узла относительно содержащей его сети.";
    }
    uses network-ref;
  }

  container networks {
    config false;
    description
      "Служит контейнером верхнего уровня для списка сетей.";
    list network {
      key "network-id";
      description
        "Описывает сеть. Обычно сеть содержит опись узлов, 
         топологическую информацию (дополненную моделью данных
         сетевой топологии) и информацию об уровнях.";
      container network-types {
        description
          "Служит целью дополнения. Тип сети указывается через
           соответствующие контейнеры присутствия, добавленные
           в этот контейнер.";
      }
      leaf network-id {
        type nw:network-id;
        description
          "Identifies a network.";
      }
      list supporting-network {
        key "network-ref";
        description
          "Базовая сеть, используемая для представления 
           многоуроневой сетевой топологии.";
        leaf network-ref {
          type leafref {
            path "/nw-s:networks/nw-s:network/nw-s:network-id";
          require-instance false;
          }
          description
            "Указывает базовую сеть.";
        }
      }

      list node {
        key "node-id";
        description
          "Опись узлов данной сети.";
        leaf node-id {
          type nw:node-id;
          description
            "Однозначно указывает узел в содержащей его сети.";
        }
        list supporting-node {
          key "network-ref node-ref";
          description
            "Представляет другой узел, находящийся в базовой сети и
             поддерживающий данный узел. Служит для представления
             многоуровневой структуры.";
          leaf network-ref {
            type leafref {
              path "../../../nw-s:supporting-network/nw-s:network-ref";
            require-instance false;
            }
            description
              "Указывает базовую сеть, в которой находится базовый узел.";
          }
          leaf node-ref {
            type leafref {
              path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
            require-instance false;
            }
            description
              "Указывает сам базовый узел.";
          }
        }
      }
    }
  }
}

<CODE ENDS>

B.2. Модуль YANG для состояния сетевой топологии

  <CODE BEGINS> file "ietf-network-topology-state@2018-02-26.yang"

  module ietf-network-topology-state {
    yang-version 1.1;
    namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
    prefix nt-s;

    import ietf-network-state {
      prefix nw-s;
      reference
        "RFC 8345: A YANG Data Model for Network Topologies";
    }
    import ietf-network-topology {
      prefix nt;
      reference
        "RFC 8345: A YANG Data Model for Network Topologies";
    }

    organization
       "Рабочая группа IETF I2RS (интерфейс в систему маршрутизации)";

    contact
      "WG Web:    <https://datatracker.ietf.org/wg/i2rs/> 
       WG List:   <mailto:i2rs@ietf.org> 

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

       Editor:    Jan Medved
                  <mailto:jmedved@cisco.com> 

       Editor:    Robert Varga
                  <mailto:robert.varga@pantheon.tech> 

       Editor:    Nitin Bahadur
                  <mailto:nitin_bahadur@yahoo.com> 

       Editor:    Hariharan Ananthakrishnan
                  <mailto:hari@packetdesign.com> 

       Editor:    Xufeng Liu
                  <mailto:xufeng.liu.ietf@gmail.com>"; 

    description
      "Эта модель определяет общую базовую модель данных для состояния
       сетевой топологии, представляющую топологию, полученную (1) путем
       обучения или (2) в результате применения топологии, настроенной в
       модели данных ietf-network-topology и отражающей соответствующие
       узлы данных в этой модели. Она дополняет базовую модель данных 
       состояния сети каналами для подключения узлов и точками 
       завершения каналов на узлах.

       Модель данных отражает ietf-network-topology, но содержит лишь 
       данные состояния, доступные только для чтения. Модель данных не 
       требуется, когда инфраструктура базовой реализации
       поддерживает архитектуру NMDA.

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

       Распространение и использование с исходной или двоичной форме
       с внесением изменений или без них определяется лицензией
       Simplified BSD License, изложенной в разделе 4.c IETF Trust
       Legal Provisions для документов IETF
       (https://trustee.ietf.org/license-info). 

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

    revision 2018-02-26 {
      description
        "Первый выпуск.";
      reference
        "RFC 8345: A YANG Data Model for Network Topologies";
    }

    grouping link-ref {
      description
        "Указывает канал в конкретной сети. Эта группировка не 
         применяется в модуле и определена для удобства его дополнения.";
      leaf link-ref {
        type leafref {
          path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
            "/../network-ref]/nt-s:link/nt-s:link-id";
          require-instance false;
        }
        description
          "Тип для абсолютной ссылки на экземпляр канала
           (этот тип не следует применять для относительных ссылок,
           используя для них относительный путь.)";
      }
      uses nw-s:network-ref;
    }

    grouping tp-ref {
      description
        "Указывает точку завершения в конкретном узле. Эта группировка не 
         применяется в модуле и определена для удобства его дополнения.";
      leaf tp-ref {
        type leafref {
          path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
            "/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
            "node-ref]/nt-s:termination-point/nt-s:tp-id";
          require-instance false;
        }
        description
          "Тип для абсолютной ссылки на точку завершения
           (этот тип не следует применять для относительных ссылок,
           используя для них относительный путь.)";
      }
      uses nw-s:node-ref;
    }
    augment "/nw-s:networks/nw-s:network" {
      description
        "Добавляет каналы в модель данных сети.";
      list link {
        key "link-id";
        description
          "Сетевой канал соединяет локальный (источник) и удаленный
           (получатель) узел через набор точек завершения 
           соответствующих узлов. Можно иметь несколько каналов между
           парой узлов. Канал можно перемещать между точками
           завершения. Поэтому для однозначного различения каналов
           каждый из них указывается выделенным идентификатором.
           Отметим, что канал моделирует соединение «точка-точка», а
           не многоточечное.";
        container source {
          description
            "Контейнер, содержащий логический источник конкретного канала.";
          leaf source-node {
            type leafref {
              path "../../../nw-s:node/nw-s:node-id";
              require-instance false;
            }
            description
              "Идентификатор узла-источника. Должен быть в той же топологии.";
          }
          leaf source-tp {
            type leafref {
              path "../../../nw-s:node[nw-s:node-id=current()/../"+
                "source-node]/termination-point/tp-id";
              require-instance false;
            }
            description
               "Эта точка завершения размещается внутри узла-источника и
                завершает канал.";
          }
        }
        container destination {
          description
             "Контейнер, содержащий логического получателя конкретного канала.";
          leaf dest-node {
            type leafref {
              path "../../../nw-s:node/nw-s:node-id";
            require-instance false;
            }
            description
               "Идентификатор узла-получателя. Должен быть в той же сети.";
          }
          leaf dest-tp {
            type leafref {
              path "../../../nw-s:node[nw-s:node-id=current()/../"+
                "dest-node]/termination-point/tp-id";
              require-instance false;
            }
            description
               "Эта точка завершения размещается внутри узла-получателя и
                завершает канал.";
          }
        }
        leaf link-id {
          type nt:link-id;
          description
            "Идентификатор канала в топологии, к которой канал относится.";
        }
        list supporting-link {
          key "network-ref link-ref";
          description
            "Идентификатор канала или каналов, от которых данный канал завсит.";
          leaf network-ref {
            type leafref {
              path "../../../nw-s:supporting-network/nw-s:network-ref";
            require-instance false;
            }
            description
              "Этот лист указывает, в какой базовой топологии присутствует
               поддерживающий канал.";
          }
          leaf link-ref {
            type leafref {
              path "/nw-s:networks/nw-s:network[nw-s:network-id="+
                "current()/../network-ref]/link/link-id";
              require-instance false;
            }
            description
              "Это лист указывает канал, который является частью базы для
               данного канала. Петли, в которых канал указывает себя в
               качестве своей основы, напрямую или косвенно, не разрешены.";
          }
        }
      }
    }

    augment "/nw-s:networks/nw-s:network/nw-s:node" {
      description
        "Дополняет точки завершения каналов. Точки завершения в
         конце концов указывают на интерфейсы.";
      list termination-point {
        key "tp-id";
        description
          "Точка завершения может заканчивать канал. В зависимости от типа
           топологии точка завершения может указывать, например, на порт 
           или интерфейс.";
        leaf tp-id {
          type nt:tp-id;
          description
            "Идентификатор точки завершения.";
        }
        list supporting-termination-point {
          key "network-ref node-ref tp-ref";
          description
            "Этот список указывает все точки завершения, от которых 
             данная точка завершения зависит или куда отображается.
             Эти точки будут сами по себе содержаться в поддерживающем
             узле. Эта информация о зависимостях может быть выведена из
             зависимостей между каналами. Поэтому не требуется отдельно
             настраивать этот элемент и нет необходимости формулировать
             соответствующее ограничение. Нужная информация просто
             обеспечивается реализующей системой.";
          leaf network-ref {
            type leafref {
              path "../../../nw-s:supporting-node/nw-s:network-ref";
            require-instance false;
            }
            description
              "Этот лист указывает, в какой топологии присутствует
               поддерживающая точка завершения.";
          }
          leaf node-ref {
            type leafref {
              path "../../../nw-s:supporting-node/nw-s:node-ref";
            require-instance false;
            }
            description
              "Этот лист указывает, в каком узле присутствует
               поддерживающая точка завершения.";
          }
          leaf tp-ref {
            type leafref {
              path "/nw-s:networks/nw-s:network[nw-s:network-id="+
                "current()/../network-ref]/nw-s:node[nw-s:node-id="+
                "current()/../node-ref]/termination-point/tp-id";
              require-instance false;
            }
            description
              "Ссылка на базовый узел (этот узел должен находиться
               в другой топологии).";
          }
        }
      }
    }
  }
  <CODE ENDS>

Приложение C. Пример

В этом приложении представлен пример экземпляра дерева данные в коде JSON [RFC7951]. Пример создает экземпляр ietf-network-topology (и дополняемого им ietf-network) для топологии, показанной на рисунке 7. Имеется три узла — D1, D2, и D3. У D1 имеется 3 точки завершения (1-0-1, 1-2-1, 1-3-1), у D2 — тоже три (2-1-1, 2-0-1, 2-3-1), а у D3 — две (3-1-1 и 3-2-1). Кроме того, имеется 6 односторонних каналов, по паре разнонаправленных между каждыми двумя узлами.

 +------------+                   +------------+
 |     D1     |                   |     D2     |
/-\          /-\                 /-\          /-\
| | 1-0-1    | |---------------->| | 2-1-1    | |
| |    1-2-1 | |<----------------| |    2-0-1 | |
\-/  1-3-1   \-/                 \-/  2-3-1   \-/
 |   /----\   |                   |   /----\   |
 +---|    |---+                   +---|    |---+
     \----/                           \----/
      A  |                             A  |
      |  |                             |  |
      |  |                             |  |
      |  |       +------------+        |  |
      |  |       |     D3     |        |  |
      |  |      /-\          /-\       |  |
      |  +----->| | 3-1-1    | |-------+  |
      +---------| |    3-2-1 | |<---------+
                \-/          \-/
                 |            |
                 +------------+

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


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

   {
     "ietf-network:networks": {
       "network": [
         {
           "network-types": {
           },
           "network-id": "otn-hc",
           "node": [
             {
               "node-id": "D1",
               "termination-point": [
                 {
                   "tp-id": "1-0-1"
                 },
                 {
                   "tp-id": "1-2-1"
                 },
                 {
                   "tp-id": "1-3-1"
                 }
               ]
             },
             {
               "node-id": "D2",
               "termination-point": [
                 {
                   "tp-id": "2-0-1"
                 },
                 {
                   "tp-id": "2-1-1"
                 },
                 {
                   "tp-id": "2-3-1"
                 }
               ]
             },
             {
               "node-id": "D3",
               "termination-point": [
                 {
                   "tp-id": "3-1-1"
                 },
                 {
                   "tp-id": "3-2-1"
                 }
               ]
             }
           ],
           "ietf-network-topology:link": [
             {
               "link-id": "D1,1-2-1,D2,2-1-1",
               "source": {
                 "source-node": "D1",
                 "source-tp": "1-2-1"
               }
               "destination": {
                 "dest-node": "D2",
                 "dest-tp": "2-1-1"
               }
             },
             {
               "link-id": "D2,2-1-1,D1,1-2-1",
               "source": {
                 "source-node": "D2",
                 "source-tp": "2-1-1"
               }
               "destination": {
                 "dest-node": "D1",
                 "dest-tp": "1-2-1"
               }
             },
             {
               "link-id": "D1,1-3-1,D3,3-1-1",
               "source": {
                 "source-node": "D1",
                 "source-tp": "1-3-1"
               }
               "destination": {
                 "dest-node": "D3",
                 "dest-tp": "3-1-1"
               }
             },
             {
               "link-id": "D3,3-1-1,D1,1-3-1",
               "source": {
                 "source-node": "D3",
                 "source-tp": "3-1-1"
               }
               "destination": {
                 "dest-node": "D1",
                 "dest-tp": "1-3-1"
               }
             },
             {
               "link-id": "D2,2-3-1,D3,3-2-1",
               "source": {
                 "source-node": "D2",
                 "source-tp": "2-3-1"
               }
               "destination": {
                 "dest-node": "D3",
                 "dest-tp": "3-2-1"
               }
             },
             {
               "link-id": "D3,3-2-1,D2,2-3-1",
               "source": {
                 "source-node": "D3",
                 "source-tp": "3-2-1"
               }
               "destination": {
                 "dest-node": "D2",
                 "dest-tp": "2-3-1"
               }
             }
           ]
         }
       ]
     }
   }

Рисунок 8. Экземпляр дерева данных.

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

Мы хотели бы выразить признательность за полезный включа в работу, комментарии и предложения Alia Atlas, Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, Qin Wu и Xian Zhang.

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

Многие люди в дополнение к перечисленным в разделе «Адреса авторов» внесли свой вклад в модель данных, представленную в этом документе. В число таких людей входят:

  • Vishnu Pavan Beeram, Juniper;

  • Ken Gray, Cisco;

  • Tom Nadeau, Brocade;

  • Tony Tkacik;

  • Kent Watsen, Juniper;

  • Aleksandr Zhdankin, Cisco.

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

Alexander Clemm

Huawei USA — Futurewei Technologies Inc.

Santa Clara, CA

United States of America

Email: ludwig@clemm.org, alexander.clemm@huawei.com

Jan Medved

Cisco

Email: jmedved@cisco.com

Robert Varga

Pantheon Technologies SRO

Email: robert.varga@pantheon.tech

Nitin Bahadur

Bracket Computing

Email: nitin_bahadur@yahoo.com

Hariharan Ananthakrishnan

Packet Design

Email: hari@packetdesign.com

Xufeng Liu

Jabil

Email: xufeng.liu.ietf@gmail.com


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Traffic engineering.

4Virtual Machine.

5Reconfigurable Optical Add/Drop Multiplexer — перенастраиваемый оптический мультиплексор ввода-вывода.

6Interface to the Routing System.

7XML Path Language.

8Network Management Datastore Architecture — архитектура хранилища данных сетевого управления.

9Secure Shell — защищенная оболочка.

10Доступен более свежий вариант документа. Прим. перев.

11Network Management System.

12Operations Support System.




RFC 8343 A YANG Data Model for Interface Management

Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8343                                Tail-f Systems
Obsoletes: 7223                                               March 2018
Category: Standards Track
ISSN: 2070-1721

A YANG Data Model for Interface Management

Модель данных YANG для управления интерфейсами

PDF

Тезисы

В этом документе определена модель данных YANG для управления сетевыми интерфейсами. Предполагается добавление (augment) расширений для конкретных типов интерфейсов к определенной здесь базовой модели. Модель включает данные конфигурации и состояния (информация о состоянии и счетчики статистики).

Определенная здесь модель данных YANG соответствует архитектуре хранилищ конфигурации NMDA1, определенной в RFC 8342.

Данный документ отменяет RFC 7223.

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

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

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

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

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

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

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

Оглавление

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

1. Введение

Этот документ определяет модель данных YANG [RFC7950] для управления сетевыми интерфейсами. Предполагается, что базовая модель будет дополнена (augment) моделями данных для конкретных типов интерфейсов.

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

Модель включает данные конфигурации и состояния (информация о состоянии и счетчики статистики).

Эта версия модели данных интерфейсов поддерживает архитектуру хранилищ конфигурации NMDA [RFC8342].

1.1. Отличия от RFC 7223

Субдерево «/interfaces-state» с узлами данных config false было исключено и все узлы config false сейчас представлены в субдереве «/interfaces».

Серверы, не реализующие NMDA или желающие поддерживать клиентов, не реализующих NMDA, могут реализовать отмененное дерево «/interfaces-state».

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

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

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

system-controlled interface – управляемый системой интерфейс

Интерфейс называют управляемым системой (system-controlled), если система создает или удаляет интерфейс независимо от того, был ли он явно настроен. Примерами являются интерфейсы, представляющий физические компоненты, которые могут добавляться в систему или удаляться из нее (например, линейные платы или подключаемые в процессе работы беспроводные интерфейсы). Управляемые системой интерфейсы могут появляться при включении той или иной функциональности (например, loopback-интерфейс при включении стека IP).

user-controlled interface – управляемый пользователем интерфейс

Интерфейс называют управляемым пользователем (user-controlled), если создание интерфейса определяется его явной настройкой в хранилище рабочей конфигурации, а удаление — явным удалением конфигурации интерфейса из этого хранилища. Примерами являются интерфейсы VLAN, настроенные на управляемых системой интерфейсах Ethernet.

Ниже приведен список используемых терминов из [RFC8342].

  • client — клиент;

  • server — сервер;

  • configuration — конфигурация;

  • system state — состояние системы;

  • operational state — операционное (рабочее) состояние;

  • intended configuration — предполагаемая конфигурация;

  • running configuration datastore — хранилище рабочей конфигурации;

  • operational state datastore — хранилище данных операционногой состояния.

Ниже приведен список используемых терминов из [RFC7950].

  • augment — дополнение;

  • data model — модель данных;

  • data node — узел данных.

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

Диаграммы деревьев в этом документе используют нотацию, определенную в [RFC8340].

2. Цели

В этом разделе описаны некоторые из целей разработки модели, представленной в разделе 5.

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

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

  • Ссылки на интерфейсы должны быть как можно проще, предпочтительно с использованием одного leafref.

  • Отображение на ifIndex [RFC2863], используемое протоколом SNMP4 для указания интерфейсов, должно быть четким.

  • Модель должна поддерживать уровни интерфейсов — как (1) простые, где один интерфейс работает поверх единственного другого, так и (2) более сложные, где один интерфейс может быть результатом агрегирования N других интерфейсов или N интерфейсов могут мультиплексироваться в один.

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

  • Модель данных должна поддерживать как физические, так и логические интерфейсы.

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

3. Модель данных интерфейса

А этом документе определен модуль YANG «ietf-interfaces», который имеет показанную ниже структуру без субдерева «/interfaces-state».

   module: ietf-interfaces
     +--rw interfaces
        +--rw interface* [name]
           +--rw name                        string
           +--rw description?                string
           +--rw type                        identityref
           +--rw enabled?                    boolean
           +--rw link-up-down-trap-enable?   enumeration {if-mib}?
           +--ro admin-status                enumeration {if-mib}?
           +--ro oper-status                 enumeration
           +--ro last-change?                yang:date-and-time
           +--ro if-index                    int32 {if-mib}?
           +--ro phys-address?               yang:phys-address
           +--ro higher-layer-if*            interface-ref
           +--ro lower-layer-if*             interface-ref
           +--ro speed?                      yang:gauge64
           +--ro statistics
              +--ro discontinuity-time    yang:date-and-time
              +--ro in-octets?            yang:counter64
              +--ro in-unicast-pkts?      yang:counter64
              +--ro in-broadcast-pkts?    yang:counter64
              +--ro in-multicast-pkts?    yang:counter64
              +--ro in-discards?          yang:counter32
              +--ro in-errors?            yang:counter32
              +--ro in-unknown-protos?    yang:counter32
              +--ro out-octets?           yang:counter64
              +--ro out-unicast-pkts?     yang:counter64
              +--ro out-broadcast-pkts?   yang:counter64
              +--ro out-multicast-pkts?   yang:counter64
              +--ro out-discards?         yang:counter32
              +--ro out-errors?           yang:counter32

3.1. Списки интерфейсов

Представленная в документе модель данных использует плоский список интерфейсов (/interfaces/interface), каждый из которых указывается именем. Кроме того, каждый интерфейс имеет обязательный лист type.

Модуль iana-if-type [RFC7224] определяет отождествления YANG для типов интерфейсов в поддерживаемом IANA реестре «ifType definitions».

Имеется один список настроенных интерфейсов (/interfaces/interface) и отдельный список рабочих состояний интерфейсов (/interfaces-state/interface).

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

В качестве примера возможного дополнения для конкретного типа интерфейса рассмотрим приведенный ниже фрагмент кода YANG. Более полный пример приведен в Приложении A.

     import interfaces {
         prefix "if";
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
         when "if:type = 'ianaift:ethernetCsmacd'";

         container ethernet {
             leaf duplex {
                 ...
             }
         }
     }

Для управляемых системой интерфейсов name является зависимым от устройства именем интерфейса.

Если устройство поддерживает произвольное именование управляемых пользователем интерфейсов, сервер анонсирует свойство arbitrary-names. Если сервер не анонсирует это свойство, имена управляемых пользователем интерфейсов должны соответствовать схеме именования для устройства. Способ получения клиентом информации о схемах именования таких устройств выходит за рамки документа. Примеры приведены в приложениях E.1 и E.2.

Когда системно-управляемый интерфейс создается системой в операционном состоянии, она пытается применить предполагаемую с именем нового интерфейса. Если такой конфигурации не найдено или заданный в конфигурации тип не соответствует типу реального интерфейса, система создает интерфейс без применения явной конфигурации.

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

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

3.2. Указание интерфейсов

Интерфейс указывается именем, которое уникально в рамках сервера. Это свойство фиксируется в определениях типа (typedef) interface-ref, которые другим модулям YANG следует применять, когда нужно указать интерфейс.

3.3. Уровни интерфейсов

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

Ниже приведен пример модели с такими узлами. Более полный пример представлен в Приложении B.

     import interfaces {
         prefix "if";
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
         when "if:type = 'ianaift:ieee8023adLag'";

         leaf-list slave-if {
             type if:interface-ref;
             must "/if:interfaces/if:interface[if:name = current()]"
                + "/if:type = 'ianaift:ethernetCsmacd'" {
                 description
                     "Ведомый (slave) интерфейс должен иметь тип 
                      'ethernetCsmacd'.";
             }
         }
         // Другие параметры настройки связки, время восстановления и пр.
     }

Хотя параметры уровней настраиваются в моделях для конкретных типов интерфейсов, два базовых leaf-list (higher-layer-if и lower-layer-if) представляют доступную только для чтения иерархию уровней интерфейсов.

4. Связь с IF-MIB

Если устройство реализует IF-MIB [RFC2863], каждая запись списка /interfaces/interface обычно отображается на один элемент ifEntry. Лист if-index должен содержать ifIndex соответствующего элемента ifEntry.

В большинстве случаев name из записи /interfaces/interface отображается на ifName. База IF-MIB позволяет двум разным ifEntry иметь общее имя ifName. Поддерживающие такую возможность устройства, которые соответствуют также определенной в этом документе модели данных, не могут иметь взаимно-однозначного отображения между листом name и ifName.

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

IF-MIB определяет также открытый для записи объект ifPromiscuousMode. Поскольку агенты SNMP обычно не реализуют этот объект как конфигурационный, он не отображается в модуль ietf-interfaces.

Объект ifMtu из IF-MIB не отображается в модуль ietf-interfaces. Предполагается, что модули YANG для конкретных типов интерфейсов будут представлять MTU с помощью дополнения модели ietf-interfaces.

В IF-MIB имеется множество счетчиков, существующих в 32-битовом и 64-битовом варианте. 64-битовые счетчики были добавлены для поддержки интерфейсов со скоростью выше 20000000 бит/с. Современные реализации обычно поддерживают такие интерфейсы, поэтому модель данных включает лишь 64-битовые счетчики. Отметим, что NETCONF и SNMP могут различаться по частоте обращения к этим счетчикам. Например, многие реализации SNMP кэшируют значения счетчиков в течение некоторого времени.

Объекты ifDescr и ifConnectorPresent из IF-MIB не отображаются в модуль ietf-interfaces.

Ниже приведены таблицы сопоставления узлов данных YANG и объектов IF-MIB.

Узлы YANG и соответствующие объекты IF-MIB.

Узел данных YANG в /interfaces/interface

Объект IF-MIB

name

ifName

type

ifType

description

ifAlias

admin-status

ifAdminStatus

oper-status

ifOperStatus

last-change

ifLastChange

if-index

ifIndex

link-up-down-trap-enable

ifLinkUpDownTrapEnable

phys-address

ifPhysAddress

higher-layer-if and lower-layer-if

ifStackTable

speed

ifSpeed and ifHighSpeed

discontinuity-time

ifCounterDiscontinuityTime

in-octets

ifHCInOctets

in-unicast-pkts

ifHCInUcastPkts

in-broadcast-pkts

ifHCInBroadcastPkts

in-multicast-pkts

ifHCInMulticastPkts

in-discards

ifInDiscards

in-errors

ifInErrors

in-unknown-protos

ifInUnknownProtos

out-octets

ifHCOutOctets

out-unicast-pkts

ifHCOutUcastPkts

out-broadcast-pkts

ifHCOutBroadcastPkts

out-multicast-pkts

ifHCOutMulticastPkts

out-discards

ifOutDiscards

out-errors

ifOutErrors

5. Модуль YANG

Этот модуль YANG импортирует определения типов (typedef) из [RFC6991].

   <CODE BEGINS> file "ietf-interfaces@2018-02-20.yang"

   module ietf-interfaces {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
     prefix if;

     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NETMOD (Network Modeling) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        Editor:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>"; 

     description
       "Этот модуль содержит набор определений YANG для управления
        сетевыми интерфейсами.

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

        Распространение и использование в исходной и двоичной форме
        с изменениями или без них разрешается в соответствии с условиями,
        указанными в упрощенной лицензии BSD, изложенной в разделе 4.c
        Правового положения IETF Trust применительно к документам IETF
        (http://trustee.ietf.org/license-info). 

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

     revision 2018-02-20 {
       description
         "Обовление для поддержки NMDA.";
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }

     revision 2014-05-08 {
       description
         "Первый выпуск.";
       reference
         "RFC 7223: A YANG Data Model for Interface Management";
     }

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

     typedef interface-ref {
       type leafref {
         path "/if:interfaces/if:interface/if:name";
       }
       description
         "Этот тип применяется моделями данных, которым нужно 
          указывать настроенные интерфейсы.";
     }

     /*
      * Отождествления
      */

     identity interface-type {
       description
         "Базовое отождествление, из которого выводятся конкретные типы.";
     }

     /*
      * Возможности
      */

     feature arbitrary-names {
       description
         "Это свойство показывает, что управляемые пользователем интерфейсы
          могут иметь произвольные имена.";
     }
     feature pre-provisioning {
       description
         "Это свойство показаывает, что устройство поддерживает подготовленные
          заранее конфигурации интерфейсов, т. е. можно настроить интерфейс,
          которого еще нет в системе.";
     }
     feature if-mib {
       description
         "Это свойство указывает поддержку устройством IF-MIB.";
       reference
         "RFC 2863: The Interfaces Group MIB";
     }

     /*
      * Узлы данных
      */

     container interfaces {
       description
         "Параметры интерфейса.";

       list interface {
         key "name";

         description
           "Список интерфейсов устройства.

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

            Системно-управляемые интерфейсы, созданные системой, всегда
            присутствуют в этом списке операционного состояния, даже
            если они не настроены.";

        leaf name {
           type string;
           description
             "Имя интерфейса .

              Устройство МОЖЕТ ограничивать разрешенные для этого листа
              значения, возможно в зависимости от типа интерфейса.
              Для управляемых системой интерфейсов этот лист содержит
              зависимое от устройства имя интерфейса. 

              Когда клиент пытается создать конфигурацию для управляемого
              системой интерфейса, которого нет в операционной состоянии,
              сервер МОЖЕТ отвергнуть запрос, если система не поддерживает 
              предварительной настройки интерфейсов или имя указывает 
              интерфейс, который не может присутствовать в системе. 
              Сервер NETCONF ДОЛЖЕН вернуть отклик rpc-error с
              error-tag 'invalid-value' в таком случае.

              Если устройство поддерживает предварительную настройку
              интерфейсов, анонсируется свойство 'pre-provisioning'.

              Если устройство разрешает произвольные имена для управляемых
              пользователем интерфейсов, анонсируется свойство 
              'arbitrary-names'.

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

              Реализация сервера МОЖЕТ отображать этот лист на объект MIB 
              ifName. Такая реализация должна использовать тот или иной
              механизм обработки различий в размере и разрешенных символах
              для этого листа и ifName. Определение таких механизмов
              выходит за рамки этого документа.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifName";
         }

         leaf description {
           type string;
           description
             "Текстовое описание интерфейса.

              Реализация сервера МОЖЕТ отображать этот лист на объект MIB 
              ifAlias. Такие реализации должны использовать тот или иной
              механизм для обработки различий в размере и разрешенных
              символах для этого листа и ifAlias. Определение таких
              механизмов выходит за рамки документа.

              Поскольку ifAlias определяется для сохранения в
              энергонезависимой памяти, реализация MIB ДОЛЖНА отображать 
              ifAlias на значение 'description' в постоянном хранилище.
           reference
             "RFC 2863: The Interfaces Group MIB - ifAlias";
         }

         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           description
             "Тип интерфейса.

              При создании записи для интерфейса сервер МОЖЕТ 
              инициализировать лист type действующим значением, например, 
              если можно вывести тип из имени интерфейса.

              Если клиент пытается установить для типа интерфейса значение,
              которое никогда не используется системой (например, тип не
              поддерживается или не соответствует имени), сервер ДОЛЖЕН
              отвергнуть запрос. Сервер NETCONF ДОЛЖЕН возвратить отклик
              rpc-error с error-tag 'invalid-value' в таком случае.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifType";
         }

         leaf enabled {
           type boolean;
           default "true";
           description
             "Этот лист содержит настроенное, желаемое состояние интерфейса.

              Системы, реализующие IF-MIB, используют значение этого листа в
              хранилище running для установки в IF-MIB.ifAdminStatus 
              значения up или down после инициализации ifEntry как описано в
              RFC 2863.

              Изменение этого листа в хранилище running отражается в
              ifAdminStatus, но при изменении ifAdminStatus с помощью 
              SNMP этот лист не меняется.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
         }

         leaf link-up-down-trap-enable {
           if-feature if-mib;
           type enumeration {
             enum enabled {
               value 1;
               description
                 "Указывает следует ли генерировать уведомления SNMP 
              linkUp/linkDown для этого интерфейса.";
             }
             enum disabled {
               value 2;
               description
                 "Указывает следует ли генерировать уведомления SNMP 
              linkUp/linkDown для этого интерфейса.";
             }
           }
           description
             "Указывает следует ли генерировать уведомления SNMP 
              linkUp/linkDown для этого интерфейса.

              Если этот узел не настроен, значение enabled применяется
              сервером для интерфейсов, которые не работают поверх другого
              интерфейса (т. е. нет записей lower-layer-if), и disabled 
              в остальных случаях.";
           reference
             "RFC 2863: The Interfaces Group MIB -
                        ifLinkUpDownTrapEnable";
         }

         leaf admin-status {
           if-feature if-mib;
           type enumeration {
             enum up {
               value 1;
               description
                 "Готов пропускать пакеты.";
             }
             enum down {
               value 2;
               description
                 "Не готов пропускать пакеты и не находится в режиме теста.";
             }
             enum testing {
               value 3;
               description
                 "Находится в режиме тестирования.";
             }
           }
           config false;
           mandatory true;
           description
             "Желаемое состояние интерфейса.

              Этот лист имеет такую же семантику, как ifAdminStatus.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
         }

         leaf oper-status {
           type enumeration {
             enum up {
               value 1;
               description
                 "Готов пропускать пакеты.";
             }
             enum down {
               value 2;
               description
                 "Интерфейс не пропускает никаких пакетов.";
             }
             enum testing {
               value 3;
               description
                 "В режиме тестирования. Не может пропускать рабочих 
                  пакетов.";
             }
             enum unknown {
               value 4;
               description
                 "Состояние не может быть определено по каким-то причинам.";
             }
             enum dormant {
               value 5;
               description
                 "Ожидание внешнего события.";
             }
             enum not-present {
               value 6;
               description
                 "Отсутствует тот или иной (обычно аппаратный) компонент.";
             }
             enum lower-layer-down {
               value 7;
               description
                 "Не работает вследствие состояния нижележащего интерфейса.";
             }
           }
           config false;
           mandatory true;
           description
             "Текущее операционное состояние интерфейса.

              Этот лист имеет такую же семантику, как ifOperStatus.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifOperStatus";
         }

         leaf last-change {
           type yang:date-and-time;
           config false;
           description
             "Время перехода интерфейса в текущее операционное состояние.
              Если текущее состояние началось до предыдущей реинициализации
              локальной подсистемы сетевого управления, этого узла не будет.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifLastChange";
         }

         leaf if-index {
           if-feature if-mib;
           type int32 {
             range "1..2147483647";
           }
           config false;
           mandatory true;
           description
             "Значение ifIndex для ifEntry, представленной этим интерфейсом.";
              interface.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifIndex";
         }

         leaf phys-address {
           type yang:phys-address;
           config false;
           description
             "Адрес интерфейса на его протокольном подуровне. Например,
              для интерфейса 802.x этот объект обычно содержит MAC5-адрес
              Зависящие от среды модули должны определять порядок битов
              и байтов, а также формат значения для этого объекта. Для
              интерфейсов, не имеющих такого адреса (например, 
              последовательная линия), этого узла не будет.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
         }

         leaf-list higher-layer-if {
           type interface-ref;
           config false;
           description
             "Список ссылок на интерфейсы, работающие поверх этого
              интерфейса.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifStackTable";
         }

         leaf-list lower-layer-if {
           type interface-ref;
           config false;
           description
             "Список ссылок на интерфейсы под этим интерфейсом.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifStackTable";
         }

         leaf speed {
           type yang:gauge64;
           units "bits/second";
           config false;
           description
               "Оценка текущей пропускной способности интерфейса в бит/с.
                Для интерфейсов, не меняющих пропускной способности или
                не позволяющих точно оценить ее, в этом узле следует
                указывать номинальную пропускную способность. Для 
                интерфейсов, не использующих концепцию пропускной 
                способности, этот узел не присутствует.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifSpeed, ifHighSpeed";
         }

         container statistics {
           config false;
           description
             "Набор связанных с интерфейсом объектов статистики.";

           leaf discontinuity-time {
             type yang:date-and-time;
             mandatory true;
             description
               "Время последнего события, когда один или несколько 
                счетчиков интерфейса подверглись разрыву. Если таких
                событий не было с момента последней реиинициализации
                локальной подсистемы управления, указывается время с
                момента этой реинициализации.";
           }

           leaf in-octets {
             type yang:counter64;
             description
               "Общее число октетов, принятых на интерфейсе с учетом
                символов кадрирования.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInOctets";
           }

           leaf in-unicast-pkts {
             type yang:counter64;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые не были направлены по 
                широковещательному или групповому адресу этого подуровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
           }

           leaf in-broadcast-pkts {
             type yang:counter64;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые были направлены по 
                широковещательному адресу этого подуровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCInBroadcastPkts";
           }

           leaf in-multicast-pkts {
             type yang:counter64;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые были направлены по 
                групповому адресу этого подуровня. Для протокола
                уровня MAC учитываются групповые (Group) и
                функциональные (Functional) адреса.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCInMulticastPkts";
           }

           leaf in-discards {
             type yang:counter32;
             description
               "Число входящих пакетов, которые несмотря на отсутствие
                ошибок были выбраны для отбрасывания с целью предотвратить
                их доставку протоколу вышележащего уровня. Одной из 
                возможных причин отбрасывания является освобождение буферов.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInDiscards";
           }

           leaf in-errors {
             type yang:counter32;
             description
               "Для ориентированных на пакеты интерфейсов - число входящих
                пакетов с ошибками, препятствующими передаче протоколу 
                вышележащего уровня. Для ориентированных на символы 
                интерфейсов и интерфейсов с фиксированным размером блоков -
                число входящих блоков передачи с ошибками, препятствующими 
                доставке протоколу вышележащего уровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInErrors";
           }

           leaf in-unknown-protos {
             type yang:counter32;
             description
               "Для ориентированных на пакеты интерфейсов - число принятых
                через интерфейс пакетов, которые были отброшены по причине
                неизвестного или не поддерживаемого протокола. Для символьно-
                ориентированных интерфейсов и интерфейсов с фиксированным 
                размером блока и поддержкой мультиплексирования протоколов - 
                число принятых через интерфейс блоков передачи, которые были 
                отброшены по причине неизвестного или не поддерживаемого 
                протокола. Для интерфейсов, не поддерживающих 
                мультиплексирование протоколов, этот счетчик не присутствует.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos";
           }


           leaf out-octets {
             type yang:counter64;
             description
               "Общее число переданных интерфейсом октетов, включая символы
                кадрирования.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCOutOctets";
           }

           leaf out-unicast-pkts {
             type yang:counter64;
             description
               "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу по адресу, не являющемуся
                широковещательным или групповым адресам для этого 
                подуровня, включая отброшенные и не переданные пакеты.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts";
           }

           leaf out-broadcast-pkts {
             type yang:counter64;
             description
               "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу, направленных по
                широковещательным адресам для этого подуровня,
                включая отброшенные и не переданные пакеты.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";

             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCOutBroadcastPkts";
           }

           leaf out-multicast-pkts {
             type yang:counter64;
             description
                "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу, направленных по
                групповым адресам для этого подуровня, включая
                отброшенные и не переданные пакеты. Для протокола уровня
                MAC это включает групповые и функциональные адреса.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCOutMulticastPkts";
           }

           leaf out-discards {
             type yang:counter32;
             description
               "Число исходящих пакетов, которые были выбраны для 
                отбрасывания, несмотря на отсутствие препятствующих
                передаче ошибок. Возможной причиной такого отбрасывания
                является освобождение буферного пространства.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifOutDiscards";
           }

           leaf out-errors {
               "Для пакетно-ориентированных интерфейсов - число исходящих
                пакетов, которые не были переданы по причине ошибок. Для
                символьных интерфейсов и интерфейсов с постоянным размером
                блока - число блоков, не переданных из-за ошибок.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifOutErrors";
           }
         }

       }
     }

     /*
      * Устаревшие определения типов
      */
     typedef interface-state-ref {
       type leafref {
         path "/if:interfaces-state/if:interface/if:name";
       }
       status deprecated;
       description
         "Этот тип применяется моделями данных, которым нужно 
          указывать работающие интерфейсы.";
     }

     /*
      * Устаревшие узлы данных состояния
      */

     container interfaces-state {
       config false;
       status deprecated;
       description
         "Узлы данных для операционных состояний интерфейсов.";
       list interface {
         key "name";
         status deprecated;

         description
           "Список интерфейсов в устройстве.
            
            Системно-управляемые интерфейсы, созданные системой, всегда
            присутствуют в этом списке, независимо от их конфигурации.";

         leaf name {
           type string;
           status deprecated;
           description
             "Имя интерфейса.

              Реализация сервера МОЖЕТ отображать этот лист на объект 
              MIB ifName. Такие реализации должны использовать тот или
              иной механизм для обработки различий в размере и разрешенных
              символах для этого листа и ifName. Определение механизмов
              выходит за рамки этого документа.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifName";
         }

         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           status deprecated;
           description
              "Тип интерфейса.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifType";
         }

         leaf admin-status {
           if-feature if-mib;
           type enumeration {
             enum up {
               value 1;
               description
                 "Готов пропускать пакеты.";
             }
             enum down {
               value 2;
               description
                 "Не готов пропускать пакеты и не находится в режиме теста.";
             }
             enum testing {
               value 3;
               description
                 "Находится в режиме тестирования.";
             }
           }
           mandatory true;
           status deprecated;
           description
             "Желаемое состояние интерфейса.

              Этот лист имеет такую же семантику, как ifAdminStatus.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
         }

         leaf oper-status {
           type enumeration {
             enum up {
               value 1;
               description
                 "Готов пропускать пакеты.";
             }
             enum down {
               value 2;
               description
                 "Интерфейс не пропускает никаких пакетов.";
             }
             enum testing {
               value 3;
               description
                 "В режиме тестирования. Не может пропускать рабочих 
                  пакетов.";
             }
             enum unknown {
               value 4;
               description
                 "Состояние не может быть определено по каким-то причинам.";
             }
             enum dormant {
               value 5;
               description
                 "Ожидание внешнего события.";
             }
             enum not-present {
               value 6;
               description
                 "Отсутствует тот или иной (обычно аппаратный) компонент.";
             }
             enum lower-layer-down {
               value 7;
               description
                 "Не работает вследствие состояния нижележащего интерфейса.";
             }
           }
           mandatory true;
           status deprecated;
           description
             "Текущее операционное состояние интерфейса.

              Этот лист имеет такую же семантику, как ifOperStatus.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifOperStatus";
         }

         leaf last-change {
           type yang:date-and-time;
           status deprecated;
           description
             "Время перехода интерфейса в текущее операционное состояние.
              Если текущее состояние началось до предыдущей реинициализации
              локальной подсистемы сетевого управления, этого узла не будет.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifLastChange";
         }

         leaf if-index {
           if-feature if-mib;
           type int32 {
             range "1..2147483647";
           }
           mandatory true;
           status deprecated;
           description
             "Значение ifIndex для ifEntry, представленной этим интерфейсом.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifIndex";
         }

         leaf phys-address {
           type yang:phys-address;
           status deprecated;
           description
             "Адрес интерфейса на его протокольном подуровне. Например,
              для интерфейса 802.x этот объект обычно содержит MAC-адрес
              Зависящие от среды модули должны определять порядок битов
              и байтов, а также формат значения для этого объекта. Для
              интерфейсов, не имеющих такого адреса (например, 
              последовательная линия), этого узла не будет.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
         }

         leaf-list higher-layer-if {
           type interface-state-ref;
           status deprecated;
           description
             "Список ссылок на интерфейсы, работающие поверх этого
              интерфейса.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifStackTable";
         }

         leaf-list lower-layer-if {
           type interface-state-ref;
           status deprecated;
           description
             "Список ссылок на интерфейсы под этим интерфейсом.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifStackTable";
         }

         leaf speed {
           type yang:gauge64;
           units "bits/second";
           status deprecated;
           description
               "Оценка текущей пропускной способности интерфейса в бит/с.
                Для интерфейсов, не меняющих пропускной способности или
                не позволяющих точно оценить ее, в этом узле следует
                указывать номинальную пропускную способность. Для 
                интерфейсов, не использующих концепцию пропускной 
                способности, этот узел не присутствует.";
           reference
             "RFC 2863: The Interfaces Group MIB -
                        ifSpeed, ifHighSpeed";
         }

         container statistics {
           status deprecated;
           description
             "Набор связанных с интерфейсом объектов статистики.";

           leaf discontinuity-time {
             type yang:date-and-time;
             mandatory true;
             status deprecated;
             description
               "Время последнего события, когда один или несколько 
                счетчиков интерфейса подверглись разрыву. Если таких
                событий не было с момента последней реиинициализации
                локальной подсистемы управления, указывается время с
                момента этой реинициализации.";
           }

           leaf in-octets {
             type yang:counter64;
             status deprecated;
             description
               "Общее число октетов, принятых на интерфейсе с учетом
                символов кадрирования.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInOctets";
           }

           leaf in-unicast-pkts {
             type yang:counter64;
             status deprecated;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые не были направлены по 
                широковещательному или групповому адресу этого подуровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
           }

           leaf in-broadcast-pkts {
             type yang:counter64;
             status deprecated;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые были направлены по 
                широковещательному адресу этого подуровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCInBroadcastPkts";
           }

           leaf in-multicast-pkts {
             type yang:counter64;
             status deprecated;
             description
               "Число пакетов, доставленных этим подуровнем на 
                вышележащий (под)уровень, которые были направлены по 
                групповому адресу этого подуровня. Для протокола
                уровня MAC учитываются групповые (Group) и
                функциональные (Functional) адреса.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCInMulticastPkts";
           }

           leaf in-discards {
             type yang:counter32;
             status deprecated;
             description
               "Число входящих пакетов, которые несмотря на отсутствие
                ошибок были выбраны для отбрасывания с целью предотвратить
                их доставку протоколу вышележащего уровня. Одной из 
                возможных причин отбрасывания является освобождение буферов.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInDiscards";
           }

           leaf in-errors {
             type yang:counter32;
             status deprecated;
             description
               "Для ориентированных на пакеты интерфейсов - число входящих
                пакетов с ошибками, препятствующими передаче протоколу 
                вышележащего уровня. Для ориентированных на символы 
                интерфейсов и интерфейсов с фиксированным размером блоков -
                число входящих блоков передачи с ошибками, препятствующими 
                доставке протоколу вышележащего уровня.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInErrors";
           }

           leaf in-unknown-protos {
             type yang:counter32;
             status deprecated;
             description
               "Для ориентированных на пакеты интерфейсов - число принятых
                через интерфейс пакетов, которые были отброшены по причине
                неизвестного или не поддерживаемого протокола. Для символьно-
                ориентированных интерфейсов и интерфейсов с фиксированным 
                размером блока и поддержкой мультиплексирования протоколов - 
                число принятых через интерфейс блоков передачи, которые были 
                отброшены по причине неизвестного или не поддерживаемого 
                протокола. Для интерфейсов, не поддерживающих 
                мультиплексирование протоколов, этот счетчик не присутствует.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos";
           }


           leaf out-octets {
             type yang:counter64;
             status deprecated;
             description
               "Общее число переданных интерфейсом октетов, включая символы
                кадрирования.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCOutOctets";
           }

           leaf out-unicast-pkts {
             type yang:counter64;
             status deprecated;
             description
               "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу по адресу, не являющемуся
                широковещательным или групповым адресам для этого 
                подуровня, включая отброшенные и не переданные пакеты.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts";
           }

           leaf out-broadcast-pkts {
             type yang:counter64;
             status deprecated;
             description
               "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу, направленных по
                широковещательным адресам для этого подуровня,
                включая отброшенные и не переданные пакеты.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCOutBroadcastPkts";
           }

           leaf out-multicast-pkts {
             type yang:counter64;
             status deprecated;
             description
                "Общее число пакетов, для которых протокол вышележащего
                уровня запросил передачу, направленных по
                групповым адресам для этого подуровня, включая
                отброшенные и не переданные пакеты. Для протокола уровня
                MAC это включает групповые и функциональные адреса.
                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCOutMulticastPkts";
           }

           leaf out-discards {
             type yang:counter32;
             status deprecated;
             description
               "Число исходящих пакетов, которые были выбраны для 
                отбрасывания, несмотря на отсутствие препятствующих
                передаче ошибок. Возможной причиной такого отбрасывания
                является освобождение буферного пространства.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifOutDiscards";
           }

           leaf out-errors {
             type yang:counter32;
             status deprecated;
             description
               "Для пакетно-ориентированных интерфейсов - число исходящих
                пакетов, которые не были переданы по причине ошибок. Для
                символьных интерфейсов и интерфейсов с постоянным размером
                блока - число блоков, не переданных из-за ошибок.

                Разрыв значения этого счетчика может происходить при
                реинициализации системы управления или иных событиях
                указанных временем 'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifOutErrors";
           }
         }
       }
     }
   }

   <CODE ENDS>

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

Этот документ регистрирует URI в реестре «IETF XML Registry» [RFC3688]. В соответствии с форматом RFC 3688 выполнена приведенная ниже регистрация.

      URI: urn:ietf:params:xml:ns:yang:ietf-interfaces
      Registrant Contact: The IESG.
      XML: N/A, the requested URI is an XML namespace.

Документ регистрирует модуль YANG в реестре «YANG Module Names» [RFC6020].

      name:         ietf-interfaces
      namespace:    urn:ietf:params:xml:ns:yang:ietf-interfaces
      prefix:       if
      reference:    RFC 8343

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

Описанный в этом документе модуль YANG определяет схему данных, которая предназначения для доступа по протоколам сетевого управления, таким как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт с обязательной поддержкой SSH6 [RFC6242]. Нижним уровнем RESTCONF является HTTPS с обязательной поддержкой TLS [RFC5246].

Модель управления доступом NETCONF [RFC8341] обеспечивает способы ограничения доступа отдельным пользователям NETCONF или RESTCONF заданным подмножеством всех доступных операций и содержимого NETCONF или RESTCONF.

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

/interfaces/interface

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

/interfaces/interface/enabled

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

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

[RFC2863] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, DOI 10.17487/RFC2863, June 2000, <https://www.rfc-editor.org/info/rfc2863>.

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

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

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

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

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

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

[RFC7224] Bjorklund, M., «IANA Interface Type YANG Module», RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.

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

Приложение A. Пример модуля для интерфейса Ethernet

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

   module example-ethernet {
     namespace "http://example.com/ethernet";
     prefix "eth";

     import ietf-interfaces {
       prefix if;
     }
     import iana-if-type {
       prefix ianaift;
     }

     // Конфигурационные параметры для интерфейсов Ethernet 
     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:ethernetCsmacd'";

       container ethernet {
         container transmission {
           choice transmission-params {
             case auto {
               leaf auto-negotiate {
                 type empty;
               }
             }
             case manual {
               container manual {
                 leaf duplex {
                   type enumeration {
                     enum "half";
                     enum "full";
                   }
                 }
                 leaf speed {
                   type enumeration {
                     enum "10Mb";
                     enum "100Mb";
                     enum "1Gb";
                     enum "10Gb";
                   }
                 }
               }
             }
           }
           leaf duplex {
             type enumeration {
               enum "half";
               enum "full";
             }
             config false;
           }
         }
         // Другие параметры, относящиеся к Ethernet ...
       }
     }
   }

Приложение B. Пример модуля для связки интерфейсов Ethernet

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

   module example-ethernet-bonding {
     namespace "http://example.com/ethernet-bonding";
     prefix "bond";

     import ietf-interfaces {
       prefix if;
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:ieee8023adLag'";

       leaf-list slave-if {
         type if:interface-ref;
         must "/if:interfaces/if:interface[if:name = current()]"
            + "/if:type = 'ianaift:ethernetCsmacd'" {
           description
             "Ведомый (slave) интерфейс должен иметь тип 'ethernetCsmacd'.";
         }
       }
       leaf bonding-mode {
         type enumeration {
           enum round-robin;
           enum active-backup;
           enum broadcast;
         }
       }
       // Другие параметры конфигурации связки, время восстановления и пр.
     }
   }

Приложение C. Пример модуля для интерфейса VLAN

В этом приложении представлен пример определения интерфейса VLAN.

   module example-vlan {
     namespace "http://example.com/vlan";
     prefix "vlan";

     import ietf-interfaces {
       prefix if;
     }
     import iana-if-type {
       prefix ianaift;
     }

     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:ethernetCsmacd' or
             if:type = 'ianaift:ieee8023adLag'";
       leaf vlan-tagging {
         type boolean;
         default false;
       }
     }

     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:l2vlan'";

       leaf base-interface {
         type if:interface-ref;
         must "/if:interfaces/if:interface[if:name = current()]"
            + "/vlan:vlan-tagging = 'true'" {
           description
             "На базовом интерфейсе должны быть разрешены теги VLAN.";
         }
       }
       leaf vlan-id {
         type uint16 {
           range "1..4094";
         }
         must "../base-interface" {
           description
             "При определении vlan-id должен быть указан базовый интерфейс.";
         }
       }
     }
   }

Приложение D. Пример отклика NETCONF <get-config>

В этом приложении дан пример отклика на запрос NETCONF <get-config> для хранилища рабочей конфигурации на устройстве, реализующем приведенный выше пример модели данных.

   <rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data>
       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
           xmlns:vlan="http://example.com/vlan">

         <interface>
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <enabled>false</enabled>
         </interface>

         <interface>
           <name>eth1</name>
           <type>ianaift:ethernetCsmacd</type>
           <enabled>true</enabled>
           <vlan:vlan-tagging>true</vlan:vlan-tagging>
         </interface>

         <interface>
           <name>eth1.10</name>
           <type>ianaift:l2vlan</type>
           <enabled>true</enabled>
           <vlan:base-interface>eth1</vlan:base-interface>
           <vlan:vlan-id>10</vlan:vlan-id>
         </interface>

         <interface>
           <name>lo1</name>
           <type>ianaift:softwareLoopback</type>
           <enabled>true</enabled>
         </interface>

       </interfaces>
     </data>
   </rpc-reply>

Приложение E. Пример отклика NETCONF <get-data>

В этом приложении дан пример отклика на запрос NETCONF <get-data> для хранилища операционного состояния на устройстве, реализующем приведенный выше пример модели данных.

В этом примере используется аннотация origin, определенная в модуле «ietf-origin» [RFC8342].

   <rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
           xmlns:vlan="http://example.com/vlan"
           xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

         <interface or:origin="or:intended">
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <enabled>false</enabled>
           <admin-status>down</admin-status>
           <oper-status>down</oper-status>
           <if-index>2</if-index>
           <phys-address>00:01:02:03:04:05</phys-address>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

         <interface or:origin="or:intended">
           <name>eth1</name>
           <type>ianaift:ethernetCsmacd</type>
           <enabled>true</enabled>
           <admin-status>up</admin-status>
           <oper-status>up</oper-status>
           <if-index>7</if-index>
           <phys-address>00:01:02:03:04:06</phys-address>
           <higher-layer-if>eth1.10</higher-layer-if>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
           <vlan:vlan-tagging>true</vlan:vlan-tagging>
         </interface>

         <interface or:origin="or:intended">
           <name>eth1.10</name>
           <type>ianaift:l2vlan</type>
           <enabled>true</enabled>
           <admin-status>up</admin-status>
           <oper-status>up</oper-status>
           <if-index>9</if-index>
           <lower-layer-if>eth1</lower-layer-if>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
           <vlan:base-interface>eth1</vlan:base-interface>
           <vlan:vlan-id>10</vlan:vlan-id>
         </interface>


         <!-- Этот интерфейс не настроен -->
         <interface or:origin="or:system">
           <name>eth2</name>
           <type>ianaift:ethernetCsmacd</type>
           <admin-status>down</admin-status>
           <oper-status>down</oper-status>
           <if-index>8</if-index>
           <phys-address>00:01:02:03:04:07</phys-address>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

         <interface or:origin="or:intended">
           <name>lo1</name>
           <type>ianaift:softwareLoopback</type>
           <enabled>true</enabled>
           <admin-status>up</admin-status>
           <oper-status>up</oper-status>
           <if-index>1</if-index>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- Здесь показаны счетчики -->
           </statistics>
         </interface>

       </interfaces>
     </data>
   </rpc-reply>

Приложение F. Примеры схем именования интерфейсов

В этом приложении приведены примеры стратегии развертывания.

В примерах используется модель данных ex-vlan (Приложение C) для показа настройки управляемых пользователем интерфейсов.

F.1. Маршрутизатор с ограничениями для имен интерфейсов

В этом примере маршрутизатор имеет 4 линейных платы с восемью портами на каждой. Гнезда для плат имеют физические номера от 0 до 3, а порты на каждой плате — от 0 до 7. Каждая плата имеет порты Fast Ethernet или Gigabit Ethernet.

Обусловленными устройством именами физических интерфейсов будут fastethernet-N/M или gigabitethernet-N/M.

Имена интерфейсов VLAN ограничены формой <physical-interface-name>.<subinterface-number>.

Предполагается, что схема именования известна оператору. Реализация автоматически инициализирует значение type в соответствии с именем интерфейса.

Сервер NETCONF не анонсирует возможность arbitrary-names в сообщении <hello>.

Оператор может настроить физический интерфейс, передавая команду <edit-config>, содержащую

     <interface nc:operation="create">
       <name>fastethernet-1/0</name>
     </interface>

При получении сервером такого запроса он будет устанавливать для листа type значение ianaift:ethernetCsmacd. Если клиент передаст команду <get-config> после приведенной выше команды <edit-config>, он получит

     <interface>
       <name>fastethernet-1/0</name>
       <type>ianaift:ethernetCsmacd</type>
     </interface>

Клиент может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>fastethernet-1/0.10005</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>fastethernet-1/0</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

Если клиент попытается изменить тип физического интерфейса командой <edit-config>, содержащей

     <interface nc:operation="merge">
       <name>fastethernet-1/0</name>
       <type>ianaift:tunnel</type>
     </interface>

сервер вернет ошибку invalid-value, поскольку новый тип не соответствует имени.

F.2. Маршрутизатор с произвольными именами интерфейсов

В этом примере маршрутизатор имеет 4 линейных платы с восемью портами на каждой. Гнезда для плат имеют физические номера от 0 до 3, а порты на каждой плате — от 0 до 7. Каждая плата имеет порты Fast Ethernet или Gigabit Ethernet.

Обусловленными устройством именами физических интерфейсов будут fastethernet-N/M или gigabitethernet-N/M.

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

Сервер NETCONF анонсирует возможность arbitrary-names в сообщении <hello>.

Физические интерфейсы настраиваются в соответствии с приложением F.1.

Оператор может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>acme-interface</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>fastethernet-1/0</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

При необходимости оператор может перенести конфигурацию с именем acme-interface на другой физический интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="merge">
       <name>acme-interface</name>
       <vlan:base-interface>fastethernet-1/1</vlan:base-interface>
     </interface>

F.3. Коммутатор Ethernet с ограничениями для имен интерфейсов

В этом примере коммутатор Ethernet имеет множество портов, каждый из которых указывается простым номером.

Зависящие от устройства имена физических интерфейсов являются номерами, соответствующими номерам физических портов.

Оператор может настроить физический интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>6</name>
     </interface>

Когда сервер получает такой запрос, он устанавливает для листа type значение ianaift:ethernetCsmacd. Если клиент выполнит команду <get-config> после показанной выше команды <edit-config>, он получит

     <interface>
       <name>6</name>
       <type>ianaift:ethernetCsmacd</type>
     </interface>

F.4. Типовой хост с ограничениями для имен интерфейсов

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

Имена интерфейсов VLAN ограничены формой <physical-interface-name>:<vlan-number>.

Сервер NETCONF не анонсирует возможность arbitrary-names в сообщении <hello>.

Оператор может настроить интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>eth8</name>
     </interface>

Когда сервер получает такой запрос, он устанавливает для листа type значение ianaift:ethernetCsmacd. Если клиент выполнит команду <get-config> после показанной выше команды <edit-config>, он получит

     <interface>
       <name>eth8</name>
       <type>ianaift:ethernetCsmacd</type>
     </interface>

Клиент может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>eth8:5</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>eth8</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

F.5. Типовой хост с произвольными именами интерфейсов

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

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

Сервер NETCONF анонсирует возможность arbitrary-names в сообщении <hello>.

Физические интерфейсы настраиваются как в приложении F.4.

Оператор может настроить интерфейс VLAN с помощью команды <edit-config>, содержащей

     <interface nc:operation="create">
       <name>acme-interface</name>
       <type>ianaift:l2vlan</type>
       <vlan:base-interface>eth8</vlan:base-interface>
       <vlan:vlan-id>5</vlan:vlan-id>
     </interface>

При необходимости оператор может перенести конфигурацию с именем acme-interface на другой физический интерфейс с помощью команды <edit-config>, содержащей

     <interface nc:operation="merge">
       <name>acme-interface</name>
       <vlan:base-interface>eth3</vlan:base-interface>
     </interface>

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

Автор благодарен Alexander Clemm, Per Hedeland, Ladislav Lhotka и Juergen Schoenwaelder за ценные замечания.

Адрес автора

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

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

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

nmalykh@protocols.ru

1Network Management Datastore Architecture — архитектура хранилища данных сетевого управления.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Simple Network Management Protocol — простой протокол сетевого управления.

5Media Access Control — управление доступом к среде передачи.

6Secure Shell — защищенная оболочка.