RFC 8527 RESTCONF Extensions to Support the Network Management Datastore Architecture

Опубликовано 29.03.2019 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                      M. Bjorklund
Request for Comments: 8527                                Tail-f Systems
Updates: 8040                                           J. Schoenwaelder
Category: Standards Track                              Jacobs University
ISSN: 2070-1721                                                P. Shafer
                                                        Juniper Networks
                                                               K. Watsen
                                                         Watsen Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2019

RESTCONF Extensions to Support the Network Management Datastore Architecture

Расширения RESTCONF для поддержки архитектуры NMDA

PDF

Аннотация

Этот документ расширяет протокол RESTCONF, определенный в RFC 8040, для поддержки архитектуры NMDA1, определенной в RFC 8342.

Документ обновляет RFC 8040 за счет добавления новых ресурсов и нового параметра запросов, а также требования использовать библиотеку YANG (описана RFC 8525) на серверах RESTCONF, реализующих NMDA.

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

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

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

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

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

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

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

1. Введение

Этот документ расширяет протокол RESTCONF [RFC8040] для поддержки архитектуры NMDA, определенной в [RFC8342].

Документ обновляет [RFC8040], чтобы позволить клиентам RESTCONF определять обеспечиваемые сервером RESTCONF хранилища и поддерживаемые каждым хранилищем модули, а также взаимодействовать со всеми хранилищами с архитектурой NMDA. В частности, обновление добавляет новые ресурсы хранилищ и новый параметр запроса, а также требует применять библиотеку YANG [RFC8525] на серверах RESTCONF с поддержкой NMDA.

Представленное здесь решение совместимо с [RFC8040]. Это достигнуто за счет того, что новые ресурсы добавлены без изменения семантики имеющихся ресурсов.

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

С документе применяется терминология, определенная NMDA [RFC8342].

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

2. Хранилище данных и требования YANG Library

Соответствующий NMDA сервер RESTCONF должен поддерживать хранилище рабочего состояния и должен реализовать как минимум выпуск 2019-01-04 модуля ietf-yang-library, определенного в [RFC8525].

Такой сервер указывает свою поддержку NMDA путем реализации ресурса {+restconf}/ds/ietf-datastores:operational и выпуска модуля ietf-yang-library не раньше 2019-01-04.

Клиент RESTCONF может проверить поддержку сервером архитектуры NMDA с помощью метода HEAD или GET для ресурса {+restconf}/ds/ietf-datastores:operational.

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

3. Расширения RESTCONF

В этом разделе описаны расширения RESTCONF, требуемые для поддержки архитектуры NMDA.

3.1. Новые ресурсы хранилища данных

Документ определяет набор новых ресурсов, представляющих хранилища данных [RFC8342]. Эти ресурсы доступны с использованием шаблона пути

     {+restconf}/ds/<datastore>

Компонента <datastore> кодируется как identityref в соответствии с правилами JSON, заданными в параграфе 6.8 [RFC7951]. Должны применяться идентификаторы с указанием пространства имен, которые должны выводиться из отождествления datastore, определенного в модуле YANG ietf-datastores [RFC8342].

В частности

  • ресурс {+restconf}/ds/ietf-datastores:operational указывает хранилище рабочего состояния;

  • ресурс {+restconf}/ds/ietf-datastores:running указывает хранилище рабочей конфигурации;

  • ресурс {+restconf}/ds/ietf-datastores:intended указывает хранилище предполагаемой конфигурации.

Сервер с поддержкой NMDA должен реализовать ресурс {+restconf}/ds/ietf-datastores:operational и может реализовать другие ресурсы.

Действия YANG могут вызываться лишь для ресурса {+restconf}/ds/ietf-datastores:operational.

Например, если сервер реализует хранилище с именем ds-ephemeral, определенное в модуле example-ds-ephemeral, он будет поддерживать ресурс {+restconf}/ds/example-ds-ephemeral:ds-ephemeral.

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

Для новых ресурсов хранилища данных (параграф 3.1) доступны те же протокольные операции, которые определены в [RFC8040] для ресурса {+restconf}/data с некоторыми исключениями, перечисленными ниже.

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

  • Некоторые хранилища по своей природе доступны лишь для чтения (например, <intended>), поэтому попытки изменить их будут приводить к отказам. Сервер должен возвращать в таких случаях отклик «405 Method Not Allowed» с кодом ошибки operation-not-supported.

  • Семантика параметра запроса with-defaults (параграф 4.8.9 в [RFC8040]) отличается при взаимодействии с хранилище рабочего состояния (см. параграф 3.2.1).

  • Абзац 3 в параграфе 3.5.4 [RFC8040] не применим при взаимодействии с ресурсами ветви {+restconf}/ds.

3.2.1. Параметр with-defaults для запроса к хранилищу рабочего состояния

Поддержка параметра запросов with-defaults (параграф 4.8.9 в [RFC8040]) необязательна при взаимодействии с ресурсом {+restconf}/ds/ietf-datastores:operational. Соответствующая возможность для индикации поддержки на сервере указывается URI

     urn:ietf:params:restconf:capability:with-operational-defaults:1.0

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

  • Если параметр запроса with-defaults не задан или имеет значение explicit, report-all или report-all-tagged, из хранилища рабочего состояния возвращаются значения in use, как определено в параграфе 5.3 [RFC8342] даже при наличии у принятого по умолчанию значения узла в модуле YANG и использовании сервером этого значения. Если with-defaults имеет значение report-all-tagged, все значения, соответствующие принятым по умолчанию в схеме, сопровождаются дополнительными метаданными, как описано в параграфе 4.8.9 [RFC8040].

  • Если параметр with-defaults имеет значение trim, возвращаются все значения in use, кроме тех, которые фильтруются на выходе для исключения принятых по умолчанию значений схемы YANG.

Серверы не обязаны поддерживать все значения для параметра with-defaults в запросах к хранилищу рабочего состояния. Если запрос содержит не поддерживаемое значение параметра, сервер возвращает ошибку в соответствии с параграфом 4.8.9 [RFC8040].

3.2.2. Новый параметр запроса with-origin

Добавлен новый параметр запроса with-origin для операции GET. При наличии этого параметра в запросе сервер будет включать в отклик аннотации метаданных origin, как определено в NMDA. Это параметр действует только для запросов к {+restconf}/ds/ietf-datastores:operational и другим хранилищам данных, производным от operational. При указании непригодного хранилища сервер должен возвращать отклик 400 Bad Request с кодом ошибки invalid-value. Аннотации метаданных origin не включаются в отклики без явного запроса клиента.

Данные в хранилище рабочего состояния могут приходить от разных источников. Серверу следует возвращать аннотацию метаданных origin, наиболее точно указывающую источник значения рабочего состояния, как указано в параграфе 5.3.4 [RFC8342].

При кодировании аннотации метаданных origin для иерархии возвращаемых узлов аннотации для дочерних узлов могут опускаться, если они совпадают с аннотациями родительских узлов, как описано в модуле YANG ietf-origin [RFC8342].

Поддержка параметра запроса with-origin является необязательной и указывается URI

     urn:ietf:params:restconf:capability:with-origin:1.0

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

Этот документ определяет два идентификатора URN в реестре RESTCONF Capability URNs, заданном в [RFC8040].

Индекс

Идентификатор возможности

 
:with-origin
 
urn:ietf:params:restconf:capability:with-origin:1.0
 
:with-operational-defaults
 
urn:ietf:params:restconf:capability:with-operational-defaults:1.0

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

Этот документ расширяет протокол RESTCONF путем добавления новых ресурсов хранилищ данных. Базовым уровнем для RESTCONF является HTTPS с обязательной реализацией защищенного транспорта TLS [RFC8446]. Протокол RESTCONF использует модель управления доступом к настройке сети [RFC8341], которая позволяет ограничивать доступ конкретных пользователей RESTCONF предопределенным набором протокольных операций и содержимого RESTCONF.

Связанные с безопасностью ограничения протокола RESTCONF (раздел 12 в [RFC8040]) применимы и к новым ресурсам хранилищ данных RESTCONF, определенным здесь.

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

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

[RFC7951] Lhotka, L., “JSON Encoding of Data Modeled with YANG”, RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

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

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

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, “YANG Library”, RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.

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

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

Watsen Networks

Email: kent+ietf@watsen.net

Robert Wilton

Cisco Systems

Email: rwilton@cisco.com



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


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


nmalykh@protokols.ru 




1Network Management Datastore Architecture — архитектура хранилища данных сетевого управления.






2Internet Engineering Task Force.






3Internet Engineering Steering Group.



 											


		
						

							Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.