RFC 6020 YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)

Please enter banners and links.

image_print
Internet Engineering Task Force (IETF)                 M. Bjorklund, Ed.
Request for Comments: 6020                                Tail-f Systems
Category: Standards Track                                   October 2010
ISSN: 2070-1721

YANG – моделирование данных для протокола NETCONF

YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)

PDF

Тезисы

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

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

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

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

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

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

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

YANG представляет собой язык моделирования данных, используемый в моделях конфигурации и состояний, с которыми работает протокол настройки конфигурации сети (NETCONF), вызовы удаленных процедур NETCONF и уведомления NETCONF. YANG служит для моделирования операций и содержимого уровней NETCONF (см. параграф 1.1 в [RFC4741]).

Этот документ описывает синтаксис и семантику языка YANG, представления модели данных, определенной в модуле YANG на языке XML4, и использование операций NETCONF для манипулирования данными.

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

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

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

anyxml

Узел данных, содержащий неизвестный блок (chunk) данных XML.

augment – дополнение

Добавляет новые узлы схемы к ранее определенному узлу.

base type – базовый тип

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

built-in type – встроенный тип

Тип данных YANG, определенный в спецификации языка YANG (например, uint32 или string).

choice – выбор

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

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

Набор данных (с возможностью записи), который требуется для перевода системы из исходного состояния в текущее [RFC4741].

conformance – соответствие

Мера соответствия устройства модели данных.

container – контейнер

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

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

Оператор, определяющий новые узлы данных, – container, leaf, leaf-list, list, choice, case, augment, uses и anyxml.

data model – модель данных

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

data node – узел данных

Узел в дереве схемы, экземпляр которого может быть создан в дереве данных, – container, leaf, leaf-list, list и anyxml.

data tree – дерево данных

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

derived type – производный тип

Тип, созданный на основе встроенного (например, uint32) или другого производного типа.

device deviation – отклонение устройства

Отказ устройства корректно реализовать модуль.

extension – расширение

Расширения добавляют в операторы семантику, отличную от YANG. Оператор extension определяет новые операторы для выражения такой семантики.

feature – возможность, функция

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

grouping – группировка

Набор многократно используемых (reusable) узлов схемы, который может использоваться локально в модуле или в других модулях, импортирующих его. Оператор grouping не является оператором определения данных, поэтому он не задает каких-либо узлов в дереве схемы.

identifier – идентификатор

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

instance identifier – идентификатор экземпляра

Механизм для идентификации отдельного узла в дереве данных.

interior node – внутренний узел

Узел в иерархии, который не является листом (leaf).

leaf – лист

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

leaf-list – лист-список

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

list – список

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

module – модуль

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

RPC5

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

RPC operation – операция RPC

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

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

Узел в дереве схемы – container, leaf, leaf-list, list, choice, case, rpc, input, output, notification или anyxml.

schema node identifier идентификатор узла схемы

Механизм для указания конкретного узла в дереве схемы.

schema tree – дерево схемы

Определение иерархии, заданное внутри модуля.

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

Дополнительные данные в системе, которые не относятся к конфигурации, например, доступная лишь для чтения статистика и информация о состоянии [RFC4741].

submodule – субмодуль

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

top-level data node – узел данных верхнего уровня

Узел данных, не имеющий других узлов данных между собой и оператором module или submodule.

uses – использует

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

3.1. Обязательные узлы

Обязательными узлами являются перечисленные ниже:

  • узлы leaf, choice или anyxml с оператором mandatory, имеющим значение true;

  • узлы list или leaf-list, в которых оператор min-elements имеет значение больше 0;

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

4. Обзор YANG

4.1. Функциональный обзор

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

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

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

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

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

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

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

Модули YANG могут транслироваться в эквивалентный синтаксис XML, называемый YIN6 (раздел 11), что позволяет приложениям использовать анализаторы XML и сценарии XSLT7 для работы с моделями. Преобразование из YANG в YIN происходит без семантических потерь, поэтому YIN можно обратно преобразовать в YANG.

YANG обеспечивает баланс моделирования данных на верхнем уровне и кодирования битов на нижнем уровне. Читатель модуля YANG может видеть верхний уровень представления модели данных, понимая, как эти данные будут кодироваться в операциях NETCONF.

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

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

Насколько это возможно, YANG поддерживает совместимость со структурами SMIv28 [RFC2578] [RFC2579] протокола SNMP9. Основанные на SMIv2 модули MIB могут автоматически преобразовываться в модули YANG с доступом только для чтения (read-only) [RFC6643]. Однако YANG не обеспечивает трансляции в SMIv2.

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

4.2. Обзор языка

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

4.2.1. Модули и субмодули

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

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

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

Оператор include позволяет модулю или субмодулю ссылаться на свои субмодули, а оператор import позволяет ссылаться на данные в других модулях.

4.2.2. Основы моделирования данных

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

4.2.2.1. Лист

Узел leaf содержит простые данные типа integer или string, имеет единственное значение конкретного типа и не имеет дочерних узлов.

Пример YANG

       leaf host-name {
           type string;
           description "Имя хоста для данной системы";
       }

Пример NETCONF XML

       <host-name>my.example.com</host-name>

Оператор leaf описан в параграфе 7.6.

4.2.2.2. Список листьев

Список листьев (leaf-list) определяет последовательность значений определенного типа с единственным значением конкретного типа для каждого листа.

Пример YANG

     leaf-list domain-search {
         type string;
         description "Список доменных имен для поиска";
     }

Пример NETCONF XML

     <domain-search>high.example.com</domain-search>
     <domain-search>low.example.com</domain-search>
     <domain-search>everywhere.example.com</domain-search>

Оператор leaf-list описан в параграфе 7.7.

4.2.2.3. Контейнер

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

Пример YANG

     container system {
         container login {
             leaf message {
                 type string;
                 description
                     "Сообщение при старте сеанса входа в систему";
             }
         }
     }

Пример NETCONF XML

     <system>
       <login>
         <message>Доброе утро</message>
       </login>
     </system>

Оператор container описан в параграфе 7.5.

4.2.2.4. Список

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

Пример YANG

     list user {
         key "name";
         leaf name {
             type string;
         }
         leaf full-name {
             type string;
         }
         leaf class {
             type string;
         }
     }

Пример NETCONF XML

     <user>
       <name>glocks</name>
       <full-name>Goldie Locks</full-name>
       <class>intruder</class>
     </user>
     <user>
       <name>snowey</name>
       <full-name>Snow White</full-name>
       <class>free-loader</class>
     </user>
     <user>
       <name>rzell</name>
       <full-name>Rapun Zell</full-name>
       <class>tower</class>
     </user>

Оператор list описан в параграфе 7.8.

4.2.2.5. Пример модуля

Ниже показан пример комбинации операторов для определения модуля.

     // Содержимое примера "acme-system.yang"
     module acme-system {
         namespace "http://acme.example.com/system";
         prefix "acme";

         organization "ACME Inc.";
         contact "joe@acme.example.com";
         description
             "Модуль для элементов, реализующих систему ACME.";

         revision 2007-06-09 {
             description "Первый выпуск.";
         }

         container system {
             leaf host-name {
                 type string;
                 description "Имя хоста для этой системы";
             }

             leaf-list domain-search {
                 type string;
                 description "Список доменных имен для поиска";
             }

             container login {
                 leaf message {
                     type string;
                     description
                         "Сообщение, выдаваемое при старте сеанса входа";
                 }

                 list user {
                     key "name";
                     leaf name {
                         type string;
                     }
                     leaf full-name {
                         type string;
                     }
                     leaf class {
                         type string;
                     }
                 }
             }
         }
     }

4.2.3. Данные состояния

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

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

     list interface {
         key "name";

         leaf name {
             type string;
         }
         leaf speed {
             type enumeration {
                 enum 10m;
                 enum 100m;
                 enum auto;
             }
         }
         leaf observed-speed {
             type uint32;
             config false;
         }
     }

4.2.4. Встроенные типы

Язык YANG имеет набор встроенных типов, подобно многим языкам программирования, но с некоторыми отличиями, которые связаны со специальными требованиями сетевого управления. В таблице перечислены встроенные типы, которые подробно описаны в разделе 9.

 

Имя

Описание

binary

произвольные двоичные данные

bits

набор битов или флагов

boolean

true или false

decimal64

64-битовое десятичное число со знаком

empty

лист, не имеющий какого-либо значения

enumeration

одно из перечисляемого набора строковых значений

identityref

ссылка на абстрактное отождествление (identity)

instance-identifier

ссылка на узел дерева данных

int8

8-битовое целое число со знаком

int16

16-битовое целое число со знаком

int32

32-битовое целое число со знаком

int64

64-битовое целое число со знаком

leafref

ссылка на экземпляр листа

string

строка символов

uint8

8-битовое целое число без знака

uint16

16-битовое целое число без знака

uint32

32-битовое целое число без знака

uint64

64-битовое целое число без знака

union

выбор одного из входящих в объединение типов

 

Оператор type описан в параграфе 7.4.

4.2.5. Производные типы (typedef)

YANG позволяет определять производные (derived) типы на основе базовых с помощью оператора typedef. Базовым типом может быть встроенный или ранее определенный производный тип, что позволяет создавать иерархии производных типов.

Производные типы могут указываться в качестве аргумента операторов type.

Пример YANG

     typedef percent {
         type uint8 {
             range "0 .. 100";
         }
         description "Процент";
     }

     leaf completed {
         type percent;
     }

Пример NETCONF XML

     <completed>20</completed>

Оператор typedef описан в параграфе 7.3.

4.2.6. Многократно используемые группы узлов (grouping)

Группы узлов могут собираться в многократно применяемые наборы и помощью оператора grouping. Группировка определяет множество узлов, которое создается с помощью оператора uses.

     grouping target {
         leaf address {
             type inet:ip-address;
             description "Целевой адрес IP";
         }
         leaf port {
             type inet:port-number;
             description "Номер целевого порта";
         }
     }

     container peer {
         container destination {
             uses target;
         }
     }

Пример NETCONF XML

     <peer>
       <destination>
         <address>192.0.2.1</address>
         <port>830</port>
       </destination>
     </peer>

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

     container connection {
         container source {
             uses target {
                 refine "address" {
                     description "IP-адрес отправителя";
                 }
                 refine "port" {
                     description "Номер порта отправителя";
                 }
             }
         }
         container destination {
             uses target {
                 refine "address" {
                     description "IP-адрес получателя";
                 }
                 refine "port" {
                     description "Номер порта получателя";
                 }
             }
         }
     }

Оператор grouping описан в параграфе 7.11.

4.2.7. Выбор

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

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

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

Пример YANG

     container food {
       choice snack {
           case sports-arena {
               leaf pretzel {
                   type empty;
               }
               leaf beer {
                   type empty;
               }
           }
           case late-night {
               leaf chocolate {
                   type enumeration {
                       enum dark;
                       enum milk;
                       enum first-available;
                   }
               }
           }
       }
    }

Пример NETCONF XML

     <food>
       <pretzel/>
       <beer/>
     </food>

Оператор choice описан в параграфе 7.9.

4.2.8. Расширение моделей данных (augment)

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

Оператор augment определяет место в иерархии модели данных, куда помещаются новые узлы, а оператор when задает условия, когда новые узлы становятся пригодными (вступают в силу).

Пример YANG

     augment /system/login/user {
         when "class != 'wheel'";
         leaf uid {
             type uint16 {
                 range "1000 .. 30000";
             }
         }
     }

В этом примере определен узел uid, который начинает действовать, когда class пользователя отличается от wheel.

Если модуль дополняет другой модуль, XML-представление данных будет отражать префикс дополняющего модуля. Например, если приведенный выше пример дополнения происходил в модуле с префиксом other, XML будет выглядеть, как показано ниже.

Пример NETCONF XML

     <user>
       <name>alicew</name>
       <full-name>Alice N. Wonderland</full-name>
       <class>drop-out</class>
       <other:uid>1024</other:uid>
     </user>

Оператор augment описан в параграфе 7.15.

4.2.9. Определения RPC

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

Пример YANG

     rpc activate-software-image {
         input {
             leaf image-name {
                 type string;
             }
         }
         output {
             leaf status {
                 type string;
             }
         }
     }

Пример NETCONF XML

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <activate-software-image xmlns="http://acme.example.com/system">
         <image-name>acmefw-2.3</image-name>
      </activate-software-image>
     </rpc>
     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <status xmlns="http://acme.example.com/system">
         The image acmefw-2.3 is being installed.
       </status>
     </rpc-reply>

Оператор rpc описан в параграфе 7.13.

4.2.10. Определения уведомлений

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

Пример YANG

     notification link-failure {
         description "Был обнаружен отказ канала";
         leaf if-name {
             type leafref {
                 path "/interface/name";
             }
         }
         leaf if-admin-status {
             type admin-status;
         }
         leaf if-oper-status {
             type oper-status;
         }
     }

Пример NETCONF XML

     <notification
         xmlns="urn:ietf:params:netconf:capability:notification:1.0">
       <eventTime>2007-09-01T10:00:00Z</eventTime>
       <link-failure xmlns="http://acme.example.com/system">
         <if-name>so-1/2/3.0</if-name>
         <if-admin-status>up</if-admin-status>
         <if-oper-status>down</if-oper-status>
       </link-failure>
     </notification>

Оператор notification описан в параграфе 7.14.

5. Концепции языка

5.1. Модули и субмодули

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

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

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

Модули используют оператор include для перечисления своих субмодулей и оператор import для ссылок на внешние модули. Аналогично, субмодули используют оператор import для ссылки на другие модули и include для ссылки на субмодули внутри модуля. В модуль или субмодуль недопустимо включать субмодули из других модулей, а субмодулям недопустимо импортировать свой модуль.

Операторы import и include служат для обеспечения доступности определений из других модулей и субмодулей:

  • для того, чтобы модуль или субмодуль мог ссылаться на определения из внешнего модуля, этот внешний модуль должен быть импортирован (import).

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

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

Недопустимо создавать замкнутые цепочки импорта или включения. Например, если модуль a включает субмодуль b, то b не может включать a.

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

5.1.1. Импорт и включение по номеру выпуска (Revision)

Опубликованные модули могут независимо изменяться время от времени. Для обеспечения возможности совершенствования модули могут импортироваться с указанием конкретного выпуска (revision). При создании модуля в нем используются текущие выпуски других модулей, которые существовали на момент разработки данного модуля. По мере публикации новых выпусков импортируемых модулей импортирующий модуль не будет автоматически меняться. Если автор модуля готов перейти к более новому выпуску импортируемого модуля, он публикует свой модуль заново с обновлением операторов import. Таким образом авторы модулей явно указывают совместимость с новым выпуском импортируемого модуля.

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

Например, модуль b импортирует модуль a.

     module a {
         revision 2008-01-01 { ... }
         grouping a {
             leaf eh { .... }
         }
     }

     module b {
         import a {
             prefix p;
             revision-date 2008-01-01;
         }

         container bee {
             uses p:a;
         }
     }

Когда автор модуля a публикует новый выпуск, изменения могут оказаться не приемлемыми с точки зрения автора модуля b. Если же новый выпуск пригоден для импорта, автор модуля b публикует свой модуль заново с обновленным оператором import.

5.1.2. Иерархии модулей

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

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

Например, экземпляр

     module my-config {
         namespace "http://example.com/schema/config";
         prefix "co";

         container system { ... }
         container routing { ... }
     }

может быть представлен в NETCONF в форме

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <!-- system data here -->
           </system>
           <routing xmlns="http://example.com/schema/config">
             <!-- routing data here -->
           </routing>
         </config>
       </edit-config>
     </rpc>

5.2. Макет файла

Модули и субмодули YANG обычно сохраняются в файлах с одним оператором module или submodule в каждом файле. Для имен файлов следует использовать приведенную ниже форму.

     module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

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

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

Все определения YANG задаются внутри модуля, привязанного к определенному пространству имен XML [XML-NAMES], которое является уникальным в глобальном масштабе идентификатором URI [RFC3986]. Клиент и сервер NETCONF используют пространство имен при кодировании данных XML.

Пространства имен XML для модулей, опубликованные в серии RFC [RFC4844], должны выделяться агентством IANA (см раздел 14).

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

Оператор namespace описан в параграфе 7.1.3.

5.3.1. Пространство имен YANG XML

YANG определяет пространство имен XML для операций NETCONF <edit-config> и содержимого <error-info>. Это пространство имеет имя urn:ietf:params:xml:ns:yang:1.

5.4. Преобразование имен группировок, типов и отождествлений

Имена группировок (grouping), типов (type) и отождествлений (identity) преобразуются в контексте их определения, а не в контексте применения. Пользователи grouping, typedef и identity не обязаны импортировать модули или включать субмодули для соблюдения всех ссылок, заданных исходным определением. Это похоже на область действия (scope) в традиционных языках программирования.

Например, если модуль определяет группировку, в которой присутствует ссылка на тип, при использовании этой группировки во втором модуле тип преобразуется (resolve) в контексте исходного (а не второго) модуля. Благодаря этому не возникает неоднозначностей при определении типа в обоих модулях.

5.5. Вложенные определения типов и группировки

Определения типов (typedef) и группипровки (grouping) во многих операторах YANG могут быть вложенными, что позволяет лексически охватывать их иерархией операторов, в которой они появляются. Это дает возможность определять типы и группировки вблизи места их применения, а не на вершине иерархии. Такая близость улучшает читаемость определений.

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

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

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

Ссылка на тип или группировку без префикса или с префиксом текущего модуля преобразуется (resolve) путем нахождения соответствующего оператора typedef или grouping среди непосредственных субоператоров каждого оператора предка.

5.6. Соответствие

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

Для YANG возможны три варианта соответствия:

  • базовое поведение модели;

  • необязательные функции в составе модели;

  • отклонения от модели.

Эти варианты более подробно рассматриваются ниже.

5.6.1. Базовое поведение

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

5.6.2. Дополнительные возможности

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

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

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

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

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

Дополнительная информация о необязательных функциях (возможностях) приведена в параграфе 7.18.1.

5.6.3. Отклонения от модели

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

Например, модуль BGP может поддерживать любое число партнеров BGP, а конкретный сервер ограничивается поддержкой 16 партнеров. Любое приложение, пытающееся настроить семнадцатого партнера, столкнется с ошибкой. Хотя этой ошибки приложению может оказаться достаточно для того, чтобы понять ограничение, лучше было бы приложению заранее знать об этом и принять соответствующие меры, избавив пользователя от ненужной работы.

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

Описание оператора deviation приведено в параграфе 7.18.3.

5.6.4. Анонсирование информации о соответствии в сообщении <hello>

Пространство имен URI должно анонсироваться как возможность в сообщении NETCONF <hello> для индикации поддержки модуля YANG сервером NETCONF. URI анонсируемых возможностей должны иметь форму, показанную ниже.

     capability-string   = namespace-uri [ parameter-list ]
     parameter-list      = "?" parameter *( "&" parameter )
     parameter           = revision-parameter /
                           module-parameter /
                           feature-parameter /
                           deviation-parameter
     revision-parameter  = "revision=" revision-date
     module-parameter    = "module=" module-name
     feature-parameter   = "features=" feature *( "," feature )
     deviation-parameter = "deviations=" deviation *( "," deviation )

Параметр revision-date указывает выпуск модуля (см. параграф 7.1.9), который реализует сервер NETCONF, module-name – имя модуля, указанное в операторе module (см. параграф 7.1), namespace-uri – пространство имен URI для модуля, указанное в операторе namespace (см. параграф 7.1.3), feature – имя необязательной функции, реализованной устройством (см. параграф 7.18.1), а deviation – имя модуля, определяющего отклонения устройства (см. параграф 7.18.3).

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

5.6.4.1. Модули

Сервер указывает имена поддерживаемых модулей в сообщении <hello>. Пространства имен модулей кодируются в форме базовых URI в строке возможностей, а имя модуля кодируется в параметре module для базового URI.

Сервер должен анонсировать все возможности всех реализуемых им модулей.

Приведенное ниже сообщение <hello> анонисрует единственный модуль syslog.

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capability>
       http://example.com/syslog?module=syslog&revision=2008-04-01
     </capability>
   </hello>
5.6.4.2. Возможности

Сервер указывает имена поддерживаемых возможностей в соообщении <hello>. В этих сообщениях возможности кодируются в параметре features внутри URI. Значение параметра представляет собой список разделенных запятыми имен возможностей, которые устройство поддерживает для заданного модуля.

Н ниже приведен пример сообщение <hello>, анонсирующего один модуль и информирующего клиента о поддержке возможности local-storage (локальное хранилище) модуля syslog.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capability>
    http://example.com/syslog?module=syslog&features=local-storage
  </capability>
</hello>
5.6.4.3. Отклонения

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

Приведенное ниже сообщение <hello> анонсирует два модуля, информируя клиента о том, что имеются отклонения от возможностей модуля syslog, перечисленные в модуле my-devs.

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <capability>
         http://example.com/syslog?module=syslog&deviations=my-devs
       </capability>
       <capability>
         http://example.com/my-deviations?module=my-devs
       </capability>
     </hello>

5.7. Изменение хранилища данных

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

1Network Configuration Protocol.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Extensible Markup Language – расширяемый язык разметки.

5Remote Procedure Call.

6YANG Independent Notation – независимая от YANG нотация.

7Extensible Stylesheet Language Transformation – преобразование расширяемого языка стилей.

8Structure of Management Information – структура данных управления.

9Simple Network Management Protocol – простой протокол управления сетями.


Часть 2

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

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

Or