RFC 6241 Network Configuration Protocol (NETCONF)

Please enter banners and links.

image_print
Internet Engineering Task Force (IETF)                      R. Enns, Ed.
Request for Comments: 6241                              Juniper Networks
Obsoletes: 4741                                        M. Bjorklund, Ed.
Category: Standards Track                                 Tail-f Systems
ISSN: 2070-1721                                    J. Schoenwaelder, Ed.
                                                       Jacobs University
                                                         A. Bierman, Ed.
                                                                 Brocade
                                                               June 2011

Протокол настройки сети (NETCONF)

Network Configuration Protocol (NETCONF)

PDF

Тезисы

Протокол настройки сети (NETCONF1), определенный в этом документе, обеспечивает механизмы установки, изменения и удаления конфигурационных параметров сетевых устройств. Он использует представление данных на основе расширяемого языка разметки (XML2) для параметров конфигурации и протокольных сообщений. Работа протокола NETCONF основана на удаленных вызовах процедур (RPC3). Данный документ служит заменой RFC 4741.

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

Этот документ содержит проект стандарта Internet (Internet Standards Track).

Документ является результатом работы IETF4 и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG5. Дополнительная информация о стандартах Internet приведена в разделе 2 документа RFC 5741.

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

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

1. Введение

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

Протокол NETCONF использует парадигму удаленного вызова процедур (RPC). Клиент кодирует RPC в формат XML [W3C.REC-xml-20001006] и передает его серверу через защищенную, ориентированную на соединения сессию Сервер возвращает отклик в формате XML. Содержимое запросов и откликов полностью описывается в XML DTD или схемах XML, позволяя сторонам учитывать синтаксические ограничения при обмене.

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

NETCONF позволяет клиенту определить набор протокольных расширений, поддерживаемых сервером. Благодаря этому, клиент может настроить свое поведение так, чтобы в полной мере использовать представленные устройством возможности. Определения возможностей могут легко расширяться без централизованного управления. Стандартные и нестандартные могут быть определены с семантической и синтаксической строгостью. Воззможности рассматриваются в разделе 8.

Протокол NETCONF является одним из блоков для построения автоматизированных систем настройки конфигурации. XML — это язык обмена информацией, обеспечивающий гибкий, но четко определенный механизм представления иерархического содержимого. Протокол NETCONF может использоваться вместе с технологиями преобразования на основе XML типа XSLT [W3C.REC-xslt-19991116] для создания систем автоматической генерации полных или частичных наборов данных конфигурации. Система может запрашивать в одной или нескольких базах данных информацию о топологии сети, каналах, правилах, пользователях и службах. Эти данные могут преобразовываться с помощью одного или множества сценариев XSLT из нацеленных на задачи и независимых от производителя схем данных в формы для конкретного производителя, продукции, операционной системы и версии программ. Полученные в результате данные могут быть переданы устройству по протоколу NETCONF.

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

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

candidate configuration datastore – дополнительное хранилище конфигурации (кандидат)

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

capability – дополнительная возможность

Функциональность, дополняющая базовую спецификацию NETCONF.

client – клиент

Инициирует (вызывает) протокольные операции на сервере. В дополнение к этому клиент может получать от сервера уведомления.

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

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

datastore – хранилище

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

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

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

message – сообщение

Протокольный объект, передаваемый через соединение. Сообщения используют формат XML.

notification – уведомления

Инициированное сервером сообщение о неком событии на сервере.

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

Вызов указанной удаленной процедуры при использовании в протоколе NETCONF.

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

Реализуется путем обмена сообщениями <rpc> и <rpc-reply>.

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

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

server – сервер

Выполняет протокольные операции, инициированные клиентом. Кроме того, сервер может передавать клиенту уведомления.

session – сессия

Клиент и сервер обмениваются сообщениями, используя защищенную, ориентированную на соединения сессию.

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

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

state data – данные состояния

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

user – пользователь

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

1.2. Обзор протокола

NETCONF использует простой механизм на основе RPC для организации взаимодействия между клиентом и сервером. Клиент может быть сценарием (script) или приложением и обычно является частью системы управления сетью. Сервером обычно выступает сетевое устройство. Термины «устройство» и «сервер» в этом документе имеют общее значение, равно как термины «клиент» и «приложение».

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

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

        Layer                 Example
    +-------------+      +-----------------+      +----------------+
(4) |   Content   |      |  Configuration  |      |  Notification  |
    |             |      |      data       |      |      data      |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------+              |
(3) | Operations  |      |  <edit-config>  |              |
    |             |      |                 |              |
    +-------------+      +-----------------+              |
           |                       |                      |
    +-------------+      +-----------------+      +----------------+
(2) |  Messages   |      |     <rpc>,      |      | <notification> |
    |             |      |   <rpc-reply>   |      |                |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------------------------------+
(1) |   Secure    |      |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
    |  Transport  |      |                                         |
    +-------------+      +-----------------------------------------+

Рисунок 1. Уровни протокола NETCONF.

  1. Уровень защищенного транспорта (Secure Transport) обеспечивает коммуникационный путь между клиентом и сервером. NETCONF может работать на основе любого транспортного протокола, соответствующего базовым требованиям, которые приведены в разделе 2.

  2. Уровень сообщений (Messages) обеспечивает простой и независимый от транспорта механизм кадрирования сообщений для представления RPC и уведомлений. Сообщения RPC описаны в разделе 4, а уведомления – в [RFC5717].

  3. Уровень операций (Operations) определяет набор базовых операций протокола, выполняемых методами RPC с представлением параметров в формате XML. Список базовых операций протокола приведен в разделе 7.

  4. Уровень содержимого (Content) выходит за рамки этого документа. Предполагается выполнение отдельной работы по стандартизации моделей данных NETCONF.

Язык моделирования данных YANG [RFC6020] был разработан для описания моделей данных и операций протокола NETCONF. Этот язык охватывает уровни (3) и (4) на рисунке 1.

1.3. Возможности

Возможности NETCONF (capability) представляют собой наборы функциональности, дополняющие базовую спецификацию NETCONF. Возможности указываются идентификаторами URI7 [RFC3986].

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

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

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

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

1.4. Разделение данных конфигурации и состояния

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

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

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

  • наборы данных будут велики;

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

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

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

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

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

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

Транспортный протокол должен обеспечивать уровню протокола NETCONF индикацию типа сессии (клиент или сервер).

Ниже более подробно описаны требования NETCONF к протоколу транспортного уровня.

2.1. Ориентированная на соединения работа

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

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

2.2. Проверка подлинности, целостность и конфиденциальность

Соединения NETCONF должны обеспечивать контроль подлинности, целостность данных, их защиту и предотвращение повторного использования (replay). Эти возможности NETCONF определяются транспортным протоколом. У партнеров NETCONF предполагается подобающий уровень защиты и конфиденциальности, независимо от данной спецификации. Например, соединения могут шифроваться с использованием защиты на транспортном уровне (TLS8) [RFC5246] или SSH9 [RFC4251], в зависимости от нижележащего протокола.

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

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

Процесс аутентификации должен приводить к подтверждению подлинности отождествления клиента, известного серверу. Аутентифицированное отождествление клиента обычно называют имене пользователя NETCONF. Имя пользователя является строкой символов, соответствующих Char из параграфа 2.2 [W3C.REC-xml-20001006]. Алгоритм создания имен пользователей зависит от транспортного протокола и применяемого им механизма аутентификации. Транспортный протокол должен предоставлять имя пользователя для применения на других уровнях NETCONF.

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

2.3. Обязательный транспортный протокол

Реализации NETCONF должны поддерживать отображение транспортного протокола SSH [RFC6242].

3. Вопросы XML

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

Все сообщения NETCONF должны использовать формат XML с кодировкой UTF-8 [RFC3629]. При получении сообщения <rpc> с некорректным форматом XML или отличающейся от UTF-8 кодировкой следует передавать в ответ сообщение об ошибке malformed-message. Если такое сообщение по какой-либо причине не может быть передано, сервер должен прервать сессию.

Сообщение NETCONF может начинаться с заголовка (декларации) XML (см. параграф 2.8 в [W3C.REC-xml-20001006]).

В этом разделе рассмотрены некоторые вопросы XML, связанные с NETCONF.

3.1. Пространство имен

Все элементы протокола NETCONF определены в пространстве имен

      urn:ietf:params:xml:ns:netconf:base:1.0

Имена возможностей NETCONF должны быть идентификаторами URI [RFC3986]. Возможности NETCONF рассмотрены в разделе 8.

3.2. Декларации типа документов

Декларации типа документов (см. параграф 2.8 в [W3C.REC-xml-20001006]) недопустимо включать в содержимое NETCONF.

4. Модель RPC

Протокол NETCONF использует коммуникационную модель на основе RPC. Партнеры NETCONF применяют элементы <rpc> и <rpc-reply> для обеспечения независимого от транспортного протокола кадрирования запросов и откликов NETCONF.

Синтаксис представления XML для уровня сообщений (Messages) в RPC формально определен в схеме XML, представленной в Приложении B.

4.1. Элемент <rpc>

Элемент <rpc> служит для представления запросов NETCONF, передаваемых от клиентов к серверам.

Элемент <rpc> имеет обязательный атрибут message-id, являющийся строкой, выбранной отправителем RPC и обычно представляющей собой символьное представление монотонно возрастающих целых чисел. Получатель RPC не декодирует и не интерпретирует эту строку, лишь сохраняя ее для последующего использования в качестве атрибута message-id в своем сообщении <rpc-reply>. Отправитель должен обеспечить нормализацию значений message-id в соответствии с правилами нормализации атрибутов, определенными в [W3C.REC-xml-20001006], если хочет получать строку назад в неизменном виде. Например,

       <rpc message-id="101"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <some-method>
           <!-- параметры метода -->
         </some-method>
       </rpc>

При наличии в элементе <rpc> дополнительных атрибутов партнер NETCONF должен возвращать эти атрибуты неизменными в элементе <rpc-reply>. Это относится ко всем атрибутам xmlns.

Имя и параметры RPC указываются в содержимом элемента <rpc>. Имя RPC является элементом, расположенным непосредственно внутри элемента <rpc>, а все параметры представляются уже внутри этого элемента.

В приведенном ниже примере вызывается метод <my-own-method>, имеющий два параметра – <my-first-parameter> со значением 14 и <another-parameter> со значением fred.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <my-own-method xmlns="http://example.net/me/my-own/1.0">
         <my-first-parameter>14</my-first-parameter>
         <another-parameter>fred</another-parameter>
       </my-own-method>
     </rpc>

В следующем примере вызывается метод <rock-the-house> с параметром <zip-code>, имеющим значение 27606-0100.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rock-the-house xmlns="http://example.net/rock/1.0">
         <zip-code>27606-0100</zip-code>
       </rock-the-house>
     </rpc>

Третий пример вызывает метод NETCONF <get> без параметров.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get/>
     </rpc>

4.2. Элемент <rpc-reply>

Сообщение <rpc-reply> передается в ответ на запрос <rpc>.

Элемент <rpc-reply> имеет обязательный атрибут message-id, который совпадает с атрибутом message-id из соответствующего запроса <rpc>.

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

Данные отклика представляются одним или множеством дочерних элементов внутри элемента <rpc-reply>.

Представленный ниже элемент <rpc> вызывает метод NETCONF <get> и включает дополнительный атрибут user-id. Отметим, что атрибут user-id не относится к пространству имен NETCONF. Возвращаемый элемент <rpc-reply> включает атрибут user-id, а также все запрошенное содержимое.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:ex="http://example.net/content/1.0"
          ex:user-id="fred">
       <get/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:ex="http://example.net/content/1.0"
          ex:user-id="fred">
       <data>
         <!-- содержимое отклика ... -->
       </data>
     </rpc-reply>

4.3. Элемент <rpc-error>

Элемент <rpc-error> передается в сообщениях <rpc-reply> при возникновении ошибки в процессе обработки запроса <rpc>.

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

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

Элемент <rpc-error> включает перечисленную ниже информацию.

error-type

Определяет концептуальный уровень, на котором возникла ошибка и включает одно из перечисляемых значений (enumeration):

  • transport (уровень защищенного транспорта);
  • rpc (уровень сообщений);
  • protocol (уровень операций);
  • application (уровень содержимого).

error-tag

Строка с кратким описанием ошибки. Разрешенные значения приведены в Приложении A.

error-severity

Строка, показывающая уровень важности ошибки в точки зрения устройства:

  • error (ошибка);
  • warning (предупреждение).

Отметим, что ни одно из значений <error-tag>, определенных в этом документе, не использует уровня warning, который является резервом на будущее.

error-app-tag

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

error-path

Содержит абсолютное выражение XPath [W3C.REC-xpath-19991116], указывающее элемент пути к узлу, связанный с ошибкой, указанной в конкретном элементе <rpc-error>. Этот элемент не применяется при отсутствии элемента данных или узла хранения, связанного с конкретной ошибкой.

Выражение XPath интерпретируется в описанном ниже контексте:

  • набор деклараций пространств имен в рамках элемента <rpc-error>;
  • набор привязок переменных пуст;
  • библиотекой функций является основная (core) библиотека функций.

Контекст узла зависит от связанного с ошибкой узла:

  • если с ошибкой может выть связан элемент данных (payload), контекстом узла будет узел документа с запросом rpc (т. е. элемент <rpc>);
  • в остальных случаях контекстом узла является корень всех моделей данных, т. е. узел, который имеет в качестве потомков узлы верхнего уровня всех моделей данных.

error-message

Содержит строку с описанием ошибки для представления человеку. Этот элемент не включается, если для соответствующей ошибки нет подходящего описания. В элемент следует включать атрибут xml:lang в соответствии с определением [W3C.REC-xml-20001006] и обсуждением в [RFC3470].

error-info

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

В Приложении A приведены стандартные ошибки NETCONF.

Например, ошибка возвращается, если элемент <rpc> получен без атрибута message-id. Отметим, что лишь в таких случаях узел NETCONF может опускать атрибут message-id в элементе <rpc-reply>.

     <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
       </get-config>
     </rpc>

     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>

Приведенный ниже отклик <rpc-reply> иллюстрирует возврат множества элементов <rpc-error>. Отметим, что используемая в примерах модель данных применяет элемент <name> для обозначения экземпляров элемента <interface>.

     <rpc-reply message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>application</error-type>
         <error-tag>invalid-value</error-tag>
         <error-severity>error</error-severity>
         <error-path xmlns:t="http://example.com/schema/1.2/config">
           /t:top/t:interface[t:name="Ethernet0/0"]/t:mtu
         </error-path>
         <error-message xml:lang="en">
           MTU value 25000 is not within range 256..9192
         </error-message>
       </rpc-error>
       <rpc-error>
         <error-type>application</error-type>
         <error-tag>invalid-value</error-tag>
         <error-severity>error</error-severity>
         <error-path xmlns:t="http://example.com/schema/1.2/config">
           /t:top/t:interface[t:name="Ethernet1/0"]/t:address/t:name
         </error-path>
         <error-message xml:lang="en">
           Invalid IP address for interface Ethernet1/0
         </error-message>
       </rpc-error>
     </rpc-reply>

4.4. Элемент <ok>

Элемент <ok> передается в сообщениях <rpc-reply> при отсутствии ошибок в процессе выполнения запроса <rpc> и данных, возвращаемых из операции. Пример показан ниже.

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

4.5. Конвейер обработки

Запросы NETCONF <rpc> должны обрабатываться управляемым устройством последовательно. Дополнительные запросы <rpc> могут быть переданы до завершения обработки предшествующих. Управляемое устройство должно передавать отклики в соответствии с порядком получения запросов.

5. Модель конфигурации

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

5.1. Хранилища конфигурации

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

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

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

Возможности из параграфов 8.3 и 8.7 определяют конфигурационные хранилища <candidate> и <startup>, соответственно.

5.2. Моделирование данных

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

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

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

6. Фильтрация ветвей

6.1. Обзор

Фильтрация ветвей (subtree) XML представляет собой механизм, который позволяет приложению выбрать отдельные ветви XML для включения в <rpc-reply> операции <get> или <get-config>. Предоставляется небольшой набор фильтров для включения, совпадения содержимого и выбора, который позволяет создать полезные, но тоже весьма ограниченные механизмы выбора. Серверу не нужно использовать специфическую для модели данных семантику при обработке, что обеспечивает простую и централизованную стратегию реализации.

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

Каждый узел, указанный в фильтре subtree, представляет собой включительный (inclusive) фильтр. Только связанные узлы в базовой модели или моделях данных внутри указанного хранилища на сервере будут выбраны фильтром. Узел выбирается, если он соответствует критерию выбора и иерархии элементов, указанных в данных фильтра, за исключением того, что абсолютное имя фильтра настроено на начало с уровня ниже <filter>.

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

6.2. Компоненты фильтра subtree

Фильтр subtree состоит из элементов XML и их атрибутов XML. В фильтрах может применяться 5 типов компонент:

  • выбор пространства имен;

  • выражение для сопоставления атрибутов;

  • сдерживающие (containment) узлы;

  • узлы выбора;

  • узлы сопоставления содержимого.

6.2.1. Выбор пространства имен

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

Для фильтра subtree определен механизм шаблонов (wildcard) пространства имен XML. Если элемент внутри элемента <filter> не определяется пространством имен (например, xmlns=””), сервер должен оценить (evaluate) все поддерживаемые пространства имен XML, при обработке данного узла фильтра subtree. Этот механизм шаблонов не применим к атрибутам XML.

Отметим, что значения префиксов для подходящих (qualified) пространств имен не принимаются во внимание при сравнении элементов фильтра с элементами базовой модели данных.

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config"/>
     </filter>

Элемент <top> является узлом выбора и только этот элемент пространств имен http://example.com/schema/1.2/config и любых дочерних узлов (из базовой модели данных) будет включен в выход фильтра.

6.2.2. Выражение для сопоставления атрибутов

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

Например,

     <filter type="subtree">
       <t:top xmlns:t="http://example.com/schema/1.2/config">
         <t:interfaces>
           <t:interface t:ifName="eth0"/>
         </t:interfaces>
       </t:top>
     </filter>

В этом примере элементы <top> и <interfaces> являются узлами сдерживания, элемент <interface> является узлом выбора, ifName является выражением для сопоставления атрибутов. Только узлы interface в пространстве имен http://example.com/schema/1.2/config, имеющие атрибут ifName со значением eth0 и находящиеся в узлах interfaces внутри узлов top, будут включены в выход фильтра.

6.2.3. Узлы сдерживания

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

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users/>
       </top>
     </filter>

В этом примере элемент <top> является узлом сдерживания.

6.2.4. Узлы выбора

Пустой узел leaf (лист) в фильтре называется узлом выбора (selection node) и представляет явный выбор фильтра в базовой модели данных. Присутствие каких-либо узлов выбора в наборе братских узлов будет приводить к выбору фильтром указанной ветви или ветвей и демпфированию автоматического выбора всего набора братских узлов в базовой модели данных. Для целей фильтрации пустой узел leaf может быть заявлен либо с пустым тегом (например, <foo/>), либо с явными тегами начала и завершения (например, <foo> </foo>). Любые пробельные символы в этой форме игнорируются.

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users/>
       </top>
     </filter>

В этом примере элемент <top> является узлом сдерживания, а элемент <users> – узлом выбора. Только узлы users в пространстве имен http://example.com/schema/1.2/config, которые находятся внутри элемента <top>, являющегося корнем хранилища конфингурации, будут включены в результат фильтрации.

6.2.5. Узлы сопоставления содержимого

Лист (leaf) с простым содержимым называется узлом сопоставления содержимого (content match node). Этот узел используется для выбора некоторых или всех его братских (sibling) узлов в результат фильтра и представляет собой фильтр точного соответствия (совпадения) содержимого элемента leaf. Ниже перечислены ограничения, применяемый к узлам сопоставления содержимого.

  • Узлу сопоставления недопустимо включать вложенные элементы.

  • Множество узлов сопоставления (т. е., братских узлов) логически связывается операцией AND.

  • Фильтрация смешанного содержимого не поддерживается.

  • Фильтрация содержимого списков не поддерживается.

  • Фильтрация содержимого, включающего только пробельные символы (whitespace), не поддерживается.

  • Узел сопоставления должен включать непробельные символы. Пустой элемент (например, <foo></foo>) будет считаться узлом выбора (например, <foo/>).

  • Пробельные символы в начале и в конце игнорируются, но эти же символы внутри блока текстовых символов учитываются и не меняются.

Если содержимое всех указанных братских узлов в фильтре subtree дает результат true, узлы для выхода фильтра выбираются в соответствии с приведенными ниже условиями.

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

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

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

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

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

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

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
           <user>
             <name>fred</name>
           </user>
         </users>
       </top>
     </filter>

В этом примере узлы <users> и <user> являются сдерживающими, а <name> – узлом сопоставления содержимого. Поскольку не указаны братские узлы для <name> (и, следовательно, нет узлов сдерживания и выбора), все «братья» узла <name> возвращаются на выходе фильтра. Только узлы user в пространстве имен http://example.com/schema/1.2/config, которые соответствуют иерархии элементов и для которых элемент <name> имеет значение fred, будут включены в выходной результат фильтра.

6.3. Обработка фильтра subtree

Выход фильтра (набор выбранных узлов) изначально пуст.

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

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

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

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

6.4. Примеры фильтрации subtree

6.4.1. Нет фильтра

При отказе от фильтрации операция <get> возвращает модель данных целиком.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <!-- ... возвращается весь набор данных ... -->
       </data>
     </rpc-reply>

6.4.2. Пустой фильтр

Пустой фильтр не выберет ничего, поскольку нет совпадений содержимого или узлов выбора. Это не будет ошибкой. Атрибут type элемента, использованный в этих примерах, рассмотрен в параграфе 7.1.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
         </filter>
       </get>
     </rpc>
     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
       </data>
     </rpc-reply>

6.4.3. Выбор всей ветви <users>

Фильтр в этом примере включает один узел выбора (<users>), поэтому фильтр выберет лишь субдерево пользователей. Этот пример представляет заполненную модель данных <users> в большинстве из приведенных ниже примеров фильтров. В реальном мире <company-info> вряд ли будет возвращаться со списком пользователей конкретного хоста или сети.

Примечание. Примеры фильтрации и конфигурации в этом документе даны в пространстве имен http://example.com/schema/1.2/config. Корневым элементом этого пространства является <top>. Элемент <top> и его потомки представляют в примере только модель конфигурационных данных.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users/>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
               <type>superuser</type>
               <full-name>Charlie Root</full-name>
               <company-info>
                 <dept>1</dept>
                 <id>1</id>
               </company-info>
             </user>
             <user>
               <name>fred</name>
               <type>admin</type>
               <full-name>Fred Flintstone</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>2</id>
               </company-info>
             </user>
             <user>
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>3</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

Следующий пример дал бы такой же результат для контейнера <users> с одним дочерним элементом (<user>).

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user/>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

6.4.4. Выбор всех элементов <name> в ветви <users>

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

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name/>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
             </user>
             <user>
               <name>fred</name>
             </user>
             <user>
               <name>barney</name>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.5. Запись для конкретного <user>

Этот фильтр задает два узла сдерживания (<users>, <user>) и один узел сопоставления содержимого (<name>). Все экземпляры братского набора, содержащие <name> со значением fred, будут включены в результат.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>fred</name>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>fred</name>
               <type>admin</type>
               <full-name>Fred Flintstone</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>2</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.6. Отдельные элементы конкретной записи <user>

Этот фильтр задает два узла сдерживания (<users>, <user>), один узел сопоставления содержимого (<name>) два узла выбора (<type>, <full-name>). Все экземпляры элементов <type> и <full-name> из братского набора, содержащие элемент <name> со значением fred будут включены в результат фильтра. Элемент <company-info> не будет включен, поскольку братский набор содержит узлы выбора.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>fred</name>
                 <type/>
                 <full-name/>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>fred</name>
               <type>admin</type>
               <full-name>Fred Flintstone</full-name>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.7. Множество ветвей

Этот фильтр содержит три ветви (name=root, fred, barney).

Фильтр ветви root включает два узла сдерживания (<users>, <user>), один узел сопоставления содержимого (<name>) и один узел выбора (<company-info>). Критерии фильтрации выполняются и выходной результат содержит ветвь company-info дерева root.

Фильтр ветви fred содержит три узла сдерживания (<users>, <user>, <company-info>), один узел сопоставления содержимого (<name>) и один узел выбора (<id>). Критерии фильрации выполняются и результат будет включает <id> в ветви company-info для пользователя fred.

Фильтр ветви barney содержит три узла сдерживания (<users>, <user>, <company-info>), два узла сопоставления содержимого (<name>, <type>) и один узел выбора (<dept>). Критерии фильтра не выполняются, поскольку пользователь barney не относится к типу superuser и вся ветвь пользователя barney (включая родительский элементо <user>) исключается из финального результата.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>root</name>
                 <company-info/>
               </user>
               <user>
                 <name>fred</name>
                 <company-info>
                   <id/>
                 </company-info>
               </user>
               <user>
                 <name>barney</name>
                 <type>superuser</type>
                 <company-info>
                   <dept/>
                 </company-info>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
               <company-info>
                 <dept>1</dept>
                 <id>1</id>
               </company-info>
             </user>
             <user>
               <name>fred</name>
               <company-info>
                 <id>2</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.8. Элементы с именованием атрибутов

В этом примере фильтр содержит один узел сдерживания (<interfaces>), одно выражение для сопоставления атрибутов (“ifName”) и один узел выбора (<interface>). Все экземпляры ветви <interface>, имеющие атрибут ifName со значением eth0 будут включены в результат. Элементы данных фильтра и атрибуты пригодны, поскольку непригодны атрибуты ifName не будут частью пространства имен schema/1.2.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
           <t:top xmlns:t="http://example.com/schema/1.2/stats">
             <t:interfaces>
               <t:interface t:ifName="eth0"/>
             </t:interfaces>
           </t:top>
         </filter>
       </get>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <t:top xmlns:t="http://example.com/schema/1.2/stats">
           <t:interfaces>
             <t:interface t:ifName="eth0">
               <t:ifInOctets>45621</t:ifInOctets>
               <t:ifOutOctets>774344</t:ifOutOctets>
             </t:interface>
           </t:interfaces>
         </t:top>
       </data>
     </rpc-reply>

Если ifName будет дочерним узлом, а не атрибутом, приведенный ниже запрос даст похожий результат.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/stats">
             <interfaces>
               <interface>
                 <ifName>eth0</ifName>
               </interface>
             </interfaces>
           </top>
         </filter>
       </get>
     </rpc>

7. Операции протокола

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

Базовый протокол поддерживает следующие операции:

  • get;

  • get-config;

  • edit-config;

  • copy-config;

  • delete-config;

  • lock;

  • unlock;

  • close-session;

  • kill-session.

Протокольная операция может сталкиваться с отказами по разным причинам, включая отсутствие поддержки операции (operation not supported). Инициатору не следует надеяться, что любая операция всегда будет успешной. Возвращаемые любым откликом RPC значения следует проверять на предмет наличия ошибок.

Синтексис и представление XML для протокольных операций формаль определены в модуле YANG (Приложение C). В следующих параграфах описана семантика каждой протокольной операции.

7.1. <get-config>

Описание

Извлекает содержимое конфигурационного кланилища целиком или частично.

Параметры

source

Имя конфигурационного хранилища, из которого запрашиваются данные (например, <running/>).

filter

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

Элемент <filter> может включать атрибут type, показывающий тип фильтрации в элементе <filter>. Используемый по умолчанию в NETCONF механизм фильтрации называется фильтром ветвей (subtree) и описан в разделе 6. Значение subtree явно указывает этот тип фильтрации.

Если партнер NETCONF поддерживает возможность :xpath (параграф 8.9), можно использовать xpath для индикации того, что атрибут select в элементе <filter> содержит выражение XPath.

Позитивный отклик

Если устройство может выполнить запрос, сервер передает элемент <rpc-reply>, содержащий элемент <data> с результатами запроса.

Негативный отклик

Если по какой-либо причине запрос не может быть выполнен полностью в отклик <rpc-reply> включается элемент <rpc-error>.

Пример

Для извлечения всей ветви <users> можно использовать приведенный ниже запрос.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users/>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
               <type>superuser</type>
               <full-name>Charlie Root</full-name>
               <company-info>
                 <dept>1</dept>
                 <id>1</id>
               </company-info>
             </user>
             <!-- здесь могут быть дополнительные элементы <user> -->
           </users>
         </top>
       </data>
     </rpc-reply>

В разделе 6 приведены дополнительные примеры фильтрации ветвей.

7.2. <edit-config>

Описание

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

Если партнер NETCONF поддерживает возможность :url (параграф 8.8), вместо параметра <config> может указываться элемент <url>.

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

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

Атрибуты

operation

Элементы ветви <config> могут включать атрибут operation, который относится к пространству имен NETCONF, определенному в параграфе 3.1. Атрибут указывает точку в конфигурации, к которой операция применяется, и может встречаться во множестве элементов ветви <config>.

Если атрибут operation не задан, конфигурация сливается (merge) с конфигурационным хранилищем.

Атрибут operation может принимать одно из приведенных ниже значений.

merge

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

replace

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

create

Конфигурационные данные, указанные элементом, который содержит этот атрибут, добавляются в конфигурацию тогда и только тогда, когда их нет в конфигурационном хранилище. Если такие данные имеются, возвращается элемент <rpc-error> с тегом ошибки (<error-tag>) data-exists.

delete

Конфигурационные данные, указанные элементом, который содержит этот атрибут, удалюяются из конфигурационного хранилища тогда и только тогда, когда они там имеются. Если таких данных нет, возвращается элемент <rpc-error> с тегом ошибки с тегом ошибки (<error-tag>) data-missing.

remove

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

Параметры

target

Имя конфигурационного хранилища, которое будет изменено (например, <running/> или <candidate/>).

default-operation

Задает принятую по умолчанию операцию (см. описание атрибута operation выше) для данного запроса <edit-config>. По умолчанию для параметра <default-operation> используется значение merge.

Параметр <default-operation> является необязательным и может принимать одно из приведенных значений:

merge

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

replace

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

none

Заданная параметром <config> конфигурация не оказывает влияния на целевое хранилище, пока новые конфигурационные данные не включают атрибут operation для запроса другой операции. Если конфигурация в параметре <config> содержит данные, для которых в целевом хранилище нет соответствующего уровня, возвращается <rpc-error> с тегом ошибки (<error-tag>) data-missing. Использование none позволяет операциям типа delete избегать создания родительской иерархии для элемента, который будет удален.

test-option

Элемент <test-option> может быть задан лишь в тех случаях, когда устройство анонсирует возможность :validate:1.1 (параграф 8.6).

Элемент <test-option> может принимать одно из приведенных ниже значений.

test-then-set

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

set

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

test-only

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

error-option

Элемент <error-option> использует одно из приведенных ниже значений.

stop-on-error

Операция <edit-config> прерывается при первой ошибке. Этот вариант применяется по умолчанию.

continue-on-error

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

rollback-on-error

При возникновении ошибки, которая требует генерации элемента <rpc-error>, сервер прекращает обработку операции <edit-config> и восстанавливает состояние, которое было до начала операции. Опция требует поддержки на сервере возможности :rollback-on-error, описанной в параграфе 8.5.

config

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

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

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

Установка MTU 1500 на интерфейсе Ethernet0/0 в рабочей конфигурации может иметь вид

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>
     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Добавим интерфейс Ethernet0/0 в рабочую конфигурацию, заменив имеющийся интерфейс с таким именем.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <interface xc:operation="replace">
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
               <address>
                 <name>192.0.2.4</name>
                 <prefix-length>24</prefix-length>
               </address>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Удалим конфигурацию для интерфейса Ethernet0/0 из рабочей конфигурации.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <default-operation>none</default-operation>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <interface xc:operation="delete">
               <name>Ethernet0/0</name>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Удалим интерфейс 192.0.2.4 из области OSPF (другие интерфейсы этой области не изменяются).

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <default-operation>none</default-operation>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <protocols>
               <ospf>
                 <area>
                   <name>0.0.0.0</name>
                   <interfaces>
                     <interface xc:operation="delete">
                       <name>192.0.2.4</name>
                     </interface>
                   </interfaces>
                 </area>
               </ospf>
             </protocols>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.3. <copy-config>

Описание

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

Если партнер NETCONF поддерживает свойство :url (параграф 8.8), элемент <url> может присутствовать в качестве параметра <source> или <target>. Дже в тех случаях, когда устройство анонсирует поддержку возможности :writable-running, оно может отказаться от поддержки хранилища <running/> в качестве цели (<target>) операции <copy-config>. Устройство может отказаться от поддержки операций копирования одной удаленной конфигурации в другую удаленную конфигурацию, когда оба параметра <source> и <target> используют элемент <url>. Если <source> и <target> указывают один идентификатор URL или хранилище конфигурации, должна возвращаться ошибка с тегом, содержащим invalid-value.

Параметры

target

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

source

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

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <target>
           <running/>
         </target>
         <source>
           <url>https://user:password@example.com/cfg/new.txt</url>
         </source>
       </copy-config>
     </rpc>
     <rpc-reply message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.4. <delete-config>

Описание

Удаляет конфигурационное хранилище. Хранилище рабочей конфигурации <running> не может быть удалено.

Если партнер NETCONF поддерживает возможность :url (параграф 8.8), в качестве параметра <target> может присутствовать элемент <url>.

Параметры

target

Имя удаляемого хранилища конфигурации.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <delete-config>
         <target>
           <startup/>
         </target>
       </delete-config>
     </rpc>

      <rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.5. <lock>

Описание

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

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

При активной блокировке сервер должен предотвращать любые изменения заблокированных ресурсов кроме исходящих из данной сессии. Запросы SNMP и CLI на изменение ресурса должны завершаться отказом с возвратом подходящей ошибки.

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

Операция <lock> принимает обязательный параметр <target>, который указывает имя блокируемого конфигурационного хранилища. При активной блокировке использование заблокированного хранилища в качестве цели операции <copy-config> будет запрещено и для любой другой сессии NETCONF. Кроме того, система будет предотвращать изменение заблокированных ресурсов другими операциями управления типа SNMP или CLI. Для снятия блокировки, активизированной в другой сессии NETCONF, можно воспользоваться командой <kill-session>. Снятие блокировок, заданных другими средствами, выходит за рамки этого документа.

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

  • Блокировка уже активизирована любой сессией NETCONF или другим объектом.
  • Целевая конфигурация имеет тип <candidate>, уже изменена и эти изменения не были представлены или отменены (rolled back).
  • Целевая конфигурация имеет тип <running> и другая сессия NETCONF уже представила изменения (параграф 8.4).

Сервер должен отвечать на запрос блокировки элементом <ok> или откликом об ошибке <rpc-error>.

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

Параметры

target

Имя конфигурационного хранилища для блокировки.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Если блокировка уже установлена, элемент <error-tag> будет иметь значение lock-denied, <error-info> будет включать <session-id> для держателя блокировки. Если блокировка задана объектом, не относящимся к NETCONF, <session-id> будет иметь значение 0. Отметим, что даже частичная блокировка целевого хранилища другим объектом будет препятствовать (глобальной) блокировке NETCONF для этого хранилища.

Пример

Приведенный ниже пример показывает успешную блокировку.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <lock>
         <target>
           <running/>
         </target>
       </lock>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/> <!-- успешная блокировка -->
     </rpc-reply>

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

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <lock>
         <target>
           <running/>
         </target>
       </lock>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error> <!-- отказ блокировки -->
         <error-type>protocol</error-type>
         <error-tag>lock-denied</error-tag>
         <error-severity>error</error-severity>
         <error-message>
           Lock failed, lock is already held
         </error-message>
         <error-info>
           <session-id>454</session-id>
           <!-- блокировка задана сессией NETCONF с номером 454 -->
         </error-info>
       </rpc-error>
     </rpc-reply>

7.6. <unlock>

Описание

Операция <unlock> служит для снятия блокировки конфигурации, заданной ранее операцией <lock>.

Операция <unlock> не снимет блокировку при наличии любого из указанных условий:

  • указанная блокировка в данных момент не активна;
  • сессия, где задана операция <unlock>, отличается от установившей блокировку сессии.

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

Параметры

target

Имя конфигурационного хранилища для снятия блокировки.

Клиент NETCONF не может снимать блокировку конфигурационного хранилища, которую он не устанавливал.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <unlock>
         <target>
          <running/>
         </target>
       </unlock>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.7. <get>

Описание

Извлекает рабочую конфигурацию и данные о состоянии устройства.

Параметры

filter

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

Элемент <filter> может включать атрибут type, показывающий тип фильтрации в элементе <filter>. Используемый по умолчанию в NETCONF механизм фильтрации называется фильтром ветвей (subtree) и описан в разделе 6. Значение subtree явно указывает этот тип фильтрации.

Если партнер NETCONF поддерживает возможность :xpath (параграф 8.9), можно использовать xpath для индикации того, что атрибут select в элементе <filter> содержит выражение XPath.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>. Раздел <data> содержит запрошенные данные.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/stats">
             <interfaces>
               <interface>
                 <ifName>eth0</ifName>
               </interface>
             </interfaces>
           </top>
         </filter>
       </get>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/stats">
           <interfaces>
             <interface>
               <ifName>eth0</ifName>
               <ifInOctets>45621</ifInOctets>
               <ifOutOctets>774344</ifOutOctets>
             </interface>
           </interfaces>
         </top>
       </data>
     </rpc-reply>

7.8. <close-session>

Описание

Запрашивает аккуратное прерывание сессии NETCONF.

Сервер NETCONF при получении запроса <close-session> будет аккуратно завершать сессию, освобождая все блокировки си ресурсы, связанные с сессией, а также аккуратно закрывая все связанные с ней соединения. Любые запросы NETCONF, полученные после <close-session>, будут игнорироваться.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <close-session/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.9. <kill-session>

Описание

Принудительное завершение сессии NETCONF.

При получении узлом NETCONF запроса <kill-session> он будет прерывать все обрабатываемые операции, освобождать все связанные с сессией блокировки и ресурсы, а также закрывать связанные с ней соединения.

Если сервер NETCONF получает запрос <kill-session> в процессе выполнения подтверждаемого представления конфигурации (параграф 8.4), он должен восстановить конфигурацию, которая была до начала представления.

В остальный случаях операция <kill-session> не обеспечивает возврата к прежней конфигурации или отмены других изменений, внесенных задавшим блокировку объектом.

Параметры

session-id

Идентификатор прерываемой сессии NETCONF. Если это значение не совпадает с идентификатором текущей сесии, возвращается ошибка invalid-value.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <kill-session>
         <session-id>4</session-id>
       </kill-session>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

1Network Configuration Protocol.

2Extensible Markup Language.

3Remote procedure call.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6Application programming interface.

7Uniform resource identifier — унифицированный идентификатор ресурса.

8Transport Layer Security.

9Secure Shell – защищенная оболочка (среда).


Часть 2.

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

Добавить комментарий

Or