RFC 6241 (часть 2)

Please enter banners and links.

image_print

Часть 1.


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

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

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

Возможности NETCONF указываются идентификаторами URI. Базовые возможности определяются с использованием идентификаторов URN в соответствии с методом, описанным в RFC 3553 [RFC3553]. Определенные в этом документе возможности используют формат

      urn:ietf:params:netconf:capability:{name}:1.x

где {name} указывает имя возможности. В обсуждениях и почтовых сообщениях возможности часто указываются в сокращенном виде :{name} или :{name}:{version}, если существует несколько версий возможности. Например, возможность foo будет иметь формальное имя urn:ietf:params:netconf:capability:foo:1.0, и сокрашенное :foo. Сокращенную форму недопустимо применять в протоколе.

8.1. Обмен данными о возможностях

Возможности анонсируются в сообщениях, переданных каждым партнером в процессе организации сессии. Когда сеанс NETCONF организован, каждый партнер (и клиент, и сервер) должен передать элемент <hello> содержащий список поддерживаемых возможностей. Каждый из партнеров должен анонсировать по меньшей мере базовую возможность NETCONF urn:ietf:params:netconf:base:1.1. Партнеры могут включать возможности из предыдущих версий NETCONF для индикации поддержки разных версий протокола.

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

Сервер, передающий элемент <hello>, должен включать в него элемент <session-id> с идентификатором данной сессии NETCONF. Клиенту при передаче элемента <hello> недопустимо включать в него элемент <session-id>.

Сервер, получивший сообщение <hello> с элементом <session-id>, должен прервать сессию NETCONF. Аналогично, клиент, не получивший элемент <session-id> в сообщении <hello> от сервера, должен прервать сессию NETCONF (без отправки <close-session>).

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

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         urn:ietf:params:netconf:base:1.1
       </capability>
       <capability>
         urn:ietf:params:netconf:capability:startup:1.0
       </capability>
       <capability>
         http://example.net/router/2.3/myfeature
       </capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>

Каждый из партнеров передает сообщение <hello> сразу после организации соединения. Партнерам недопустимо ждать приветствия от другой стороны перед отправкой своего.

8.2. Возможность записи в рабочую конфигурацию

8.2.1. Описание

Возможность :writable-running говорит о том, что устройство поддерживает непосредственную запись в хранилище конфигурации <running>. Иными словами, устройство поддерживает операции <edit-config> и <copy-config> с целевым хранилищем <running>.

8.2.2. Зависимости

Нет.

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

Возможность :writable-running указывается строкой

      urn:ietf:params:netconf:capability:writable-running:1.0

8.2.4. Новые операции

Нет.

8.2.5. Изменения существующих операций

8.2.5.1. <edit-config>

Возможность :writable-running меняет операцию <edit-config>, позволяя указывать элемент <running> в качестве <target>.

8.2.5.2. <copy-config>

Возможность :writable-running меняет операцию <copy-config>, позволяя указывать элемент <running> в качестве <target>.

8.3. Поддержка конфигурации-кандидата

8.3.1. Описание

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

Операция <commit> представляет текущее содержимое конфигурации-кандидата в рабочую конфигурацию устройства. Хотя это представление выглядит простым копированием, оно выделена в специальную операцию по Сохранение концепции верхнего уровня как операции первого класса, позволяет разработчикам более ясно представлять, что запрашивает клиент и что должен выполнить сервер. Это делает цели более понятными, специальные случаи менее сложными, а взаимодействие операций более прямым. Например, возможность :confirmed-commit:1.1 (параграф 8.4) не имеет смысла в качестве операции подтверждаемого копирования (copy confirmed).

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

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

8.3.2. Зависимости

Нет.

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

Возможность :candidate указывается строкой

      urn:ietf:params:netconf:capability:candidate:1.0

8.3.4. Новая операция

8.3.4.1. <commit>

Описание

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

Для представления конфигурации-кандидата в качестве новой текущей конфигурации устройства служит операция <commit>.

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

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

Если система не поддерживает возможность :candidate, операция <commit> будет недоступна.

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

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

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

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

Пример

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

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

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

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

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

8.3.5. Изменение существующий операций

8.3.5.1. <get-config>, <edit-config>, <copy-config>, <validate>

Конфигурация-кандидат может служить в качестве источника или цели в любой из операций <get-config>, <edit-config>, <copy-config> и <validate> при ее задании параметром <source> или <target>, соответственно. Для указания этой конфигурации служит элемент <candidate>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <candidate/>
         </source>
       </get-config>
     </rpc>
8.3.5.2. <lock> и <unlock>

Конфигурация-кандидат может быть заблокирована операцией <lock> при указании элемента <candidate> в качестве параметра <target>.

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

Для снятия блокировки конфигурации-кандидата служит операция <unlock> с элементом <candidate> в качестве параметра <target>.

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

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

8.4. Подтверждаемое представление

8.4.1. Описание

Возможность :confirmed-commit:1.1 показывает поддержку сервером операции <cancel-commit> и параметров <confirmed>, <confirm-timeout>, <persist>, <persist-id> для операции <commit> (см. параграф 8.3).

Подтверждаемая операция <commit> должна быть отменена, если подтверждающая подача (commit) не состоялась в течение заданного интервала (по умолчанию 600 секунд = 10 минут). Подтвержденная подача — это операция <commit> без параметра <confirmed>. Интервал ожидания можно изменить с помощью параметра <confirm-timeout>. Если до истечения срока была введена следующая подтверждаемая операция <commit>, таймер сбрасывается в новое значение (по умолчанию 600 секунд). И подтверждающая подача и следующая подтверждаемая операция <commit> могут вносить в конфигурацию дополнительные изменения.

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

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

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

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

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

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

Версия 1.0 этой возможности была определена в [RFC4741]. Этот документ определяет версию 1.1, которая расширяет версию 1.0 путем добавления новой операции <cancel-commit> и двух новых необязательных параметров <persist> и <persist-id>. Для совместимости со старыми клиентами серверы, поддерживающие эту спецификацию, могут анонсировать версию 1.0 в дополнение к версии 1.1.

8.4.2. Зависимости

Возможность :confirmed-commit:1.1 имеет смысл только при наличии поддержки возможности :candidate.

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

Возможность :confirmed-commit:1.1 указывается строкой

      urn:ietf:params:netconf:capability:confirmed-commit:1.1

8.4.4. Новые операции

8.4.4.1. <cancel-commit>

Описание

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

Параметры

persist-id

Отменяет устойчивую к разрыву сессии подтверждаемую подачу конфигурации. Значение должно совпадать со значением параметра <persist> в операции <commit>. Если значения различаются, операция завершается отказом с ошибкой invalid-value.

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

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

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

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

Пример

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

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

     <rpc message-id="102"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <cancel-commit/>
     </rpc>

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

8.4.5. Изменение существующих операций

8.4.5.1. <commit>

Возможность :confirmed-commit:1.1 добавляет 4 новых параметра для операции <commit>.

Параметры

confirmed

Выполнить подтверждаемую операцию <commit>.

confirm-timeout

Время ожидания для подтверждаемого представления (в секундах). Если тайм-аут на задан, время ожидания составит 600 секнд.

persist

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

persist-id

Используется в следующем подтверждаемом представлении или в подтверждающем представлении из любой сессии с маркером предыдущей операции <commit>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <confirm-timeout>120</confirm-timeout>
       </commit>
     </rpc>

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

Пример

     <!-- начало устойчивой к разрыву сессии операции confirmed-commit -->
     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <persist>IQ,d4668</persist>
       </commit>
     </rpc>

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

     <!-- подтверждение устойчивой к разрыву сессии операции confirmed-commit,
          confirmed-commit, возможно из другой сессии -->
     <rpc message-id="102"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <persist-id>IQ,d4668</persist-id>
       </commit>
     </rpc>

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

8.5. Возможность отката после ошибки

8.5.1. Описание

Эта возможность говорит о поддержке сервером значения rollback-on-error для параметра <error-option> операции <edit-config>.

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

8.5.2. Зависимости

Нет.

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

Возможность :rollback-on-error указывается строкой

      urn:ietf:params:netconf:capability:rollback-on-error:1.0

8.5.4. Новые операции

Нет.

8.5.5. Изменения существующих операций

8.5.5.1. <edit-config>

Возможность :rollback-on-error позволяет указывать значение rollback-on-error для параметра <error-option> операции <edit-config>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <error-option>rollback-on-error</error-option>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>100000</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>

8.6. Проверка пригодности

8.6.1. Описание

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

Анонсирование этой возможности означает поддержку протокольной операции <validate> и проверки по крайней мере синтаксических ошибок. Кроме того, эта возможность поддерживает параметр <test-option> для операции <edit-config>, который задает проверку по крайней мере синтаксических ошибок.

Версия 1.0 этой возможности была определена в [RFC4741]. Описанная здесь версия 1.1 расширяет версию 1.0 путем добавления значения test-only для параметра <test-option> операции <edit-config>. Для совместимости со старыми клиентами серверы, поддерживающие эту спецификацию, могут анонсировать версию 1.0 в дополнение к версии 1.1.

8.6.2. Зависимости

Нет.

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

Возможность :validate:1.1 указывается строкой

      urn:ietf:params:netconf:capability:validate:1.1

8.6.4. Новые операции

8.6.4.1. <validate>

Описание

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

Параметры

source

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

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

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

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

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

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

Пример

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

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

8.6.5. Изменения существующих операций

8.6.5.1. <edit-config>

Возможность :validate:1.1 меняет операцию <edit-config>, позволяя принимать параметр <test-option>.

8.7. Раздельное стартовое хранилище

8.7.1. Описание

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

8.7.2. Зависимости

Нет.

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

Возможность :startup указывается строкой

      urn:ietf:params:netconf:capability:startup:1.0

8.7.4. Новые операции

Нет.

8.7.5. Изменения существующих операций

8.7.5.1. General

Возможность :startup добавляет конфигурационное хранилище <startup/> к аргументам некоторых операций NETCONF. Сервер должен поддерживать это значение для указанных в таблице парметров.

Операция

Параметры

Примечания

<get-config>

<source>

<copy-config>

<source> <target>

<lock>

<target>

<unlock>

<target>

<validate>

<source>

Если анонсирована возможность :validate:1.1

<delete-config>

<target>

Сбрасывает устроство в заводские установки

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

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

8.8. Поддержка URL

8.8.1. Описание

Узел NETCONF может поддерживать элемент <url> в качестве значения параметров <source> и <target>. Эта возможность дополнительно идентифицируется аргументами URL, указывающими поддерживаемые схемы URL.

8.8.2. Зависимости

Нет.

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

Возможность :url указывается строкой

      urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}

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

      urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file

8.8.4. Новые операции

Нет.

8.8.5. Изменения существующих операций

8.8.5.1. <edit-config>

Возможность :url меняет операцию <edit-config>, позволяя той принимать элемент <url> в качестве параметра <config>.

Файл, на который указывает url в качестве содержимого конфигурационных данных для редактирования, кодируется в формате XML внутри элемента <config> в пространстве имен urn:ietf:params:xml:ns:netconf:base:1.0.

8.8.5.2. <copy-config>

Возможность :url меняет операцию <copy-config>, позволяя той принимать элемент <url> в качестве параметров <source> и <target>.

Файл, на который указывает url в качестве полного конфигурационного хранилища, кодируется в формате XML внутри элемента <config> в пространстве имен urn:ietf:params:xml:ns:netconf:base:1.0.

8.8.5.3. <delete-config>

Возможность :url меняет операцию <delete-config>, позволяя ей принимать элемент <url> в качестве параметра <target>.

8.8.5.4. <validate>

Возможность :url меняет операцию <validate>, позволяя ей принимать элемент <url> в качестве параметра <source>.

8.9. Выражения XPath

8.9.1. Описание

Возможность XPath показывает, что узел NETCONF поддерживает использование выражений XPath в элементах <filter>. Описание XPath приведено в [W3C.REC-xpath-19991116].

Модель данных в выражениях XPath совпадает с используемой в XPath 1.0 [W3C.REC-xpath-19991116] с тем же расширением для потомков корневого узла, которое применяется в XSLT 1.0 ([W3C.REC-xslt-19991116], параграф 3.1). В частности, это означает, что корневой узел может иметь в качестве потомков любое число элементов.

Выражения XPath оцениваются в следующем контексте:

  • набор объявлений пространств имен составляют те, которые относятсе к зоне действия элемента <filter>;

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

  • библиотекой функций является основная библиотека, дополненная функциями модели данных;

  • узлом контекста является корневой узел.

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

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

8.9.2. Зависимости

Нет.

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

Возможность :xpath указывается строкой

      urn:ietf:params:netconf:capability:xpath:1.0

8.9.4. Новые операции

Нет.

8.9.5. Изменения существующих операций

8.9.5.1. <get-config> и <get>

Возможность :xpath меняет операции <get> и <get-config>, позволяя им принимать значение xpath в атрибуте type элемента <filter>. Если атрибут type имеет значение xpath, в элементе <filter> должен присутствовать атрибут select, который будет считаться выражением XPath и применяться для фильтрации возвращаемых данных .В таком случае сам элемент <filter> должен быть пустым.

Результатом XPath для выбора должен быть набор узлов (node-set). Каждый узел в node-set Должен соответствовать узлу в базовой модели данных. Для корректной идентификации каждого узла служат приведенные ниже правила.

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

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

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <!-- найти пользователя с именем named fred -->
         <filter xmlns:t="http://example.com/schema/1.2/config"
                 type="xpath"
                 select="/t:top/t:users/t:user[t:name='fred']"/>
        </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>
               <company-info>
                 <id>2</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

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

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

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

Проверка полномочий отдельного пользователя сервером NETCONF может (но не обязательно) отображаться (1:1) на дугие интерфейсы. Во-первых, модели данных могут быть несоместимы. Во-вторых, может оказаться желательным проверка полномочий на основе механизмов, доступных на уровне защищенного транспорта (например, SSH, BEEP1 и т. п.).

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

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

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

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

Следует подчеркнуть важность понимания того, что разные операции по своей природе имеют разный уровнеь «деликатности». Например, операция <copy-config> для стартовой или рабочей конфигурации явно не является обычной операцией инициализации, как <edit-config>. Такие глобальные операции должны запрещать изменение данных лицам, не имеющим на то полномочий. Например, если пользователь A не имеет права настраивать адрес IP на интерфейсе, а пользователь B настраивает такой адрес в конфигурации <candidate>, пользователю A недопустимо разрешать представление конфигурации <candidate>.

Точно так же, если кто-то скажет: «запишите конфигурацию, хранящуюся по ссылке URL,» – этого не следует делать без должной проверки полномочий.

Операция <lock> показывает, что протокол NETCONF предназначен для использования системами, которым администратор имеет некое доверие. Как указано в этом документе, можно заблокировать части конфигурации, что сделает их недоступными для других. В конечном итоге может быть заблокирована конфигурация целиком. Для смягчения этой проблемы есть два подхода. Можно «убить» другую сессию NETCONF программными средствами в рамках протокола NETCONF, если идентификатор этой сессии известен. Другим вариантом является снятие блокировки с использованием пользовательского интерфейса самого устройства. Эти два механизма могут действовать один против другого, что может быть устранено путем удаления нарушителя с сервера AAA2. Однако такое решение удобно не во всех случаях (например, при использовании парных ключей SSH).

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

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

Этот документ регистрирует URI для пространства имен NETCONF XML в реестре IETF XML [RFC3688].

Агентство IANA обновиле приведенные ниже URI со ссылками на этот документ.

   URI: urn:ietf:params:xml:ns:netconf:base:1.0
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.

10.2. Схема NETCONF XML

Этот документ регистрирует URI для схемы NETCONF XML в реестре IETF XML [RFC3688].

Агентство IANA обновиле приведенные ниже URI со ссылками на этот документ.

   URI: urn:ietf:params:xml:schema:netconf
   Registrant Contact: The IESG.
   XML: Appendix B of this document.

10.3. Модуль для YANG NETCONF

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

     name:        ietf-netconf
     namespace:   urn:ietf:params:xml:ns:netconf:base:1.0
     prefix:      nc
     reference:   RFC 6241

10.4. URN для возможностей NETCONF

Агенство IANA создало и поддерживает реестр Network Configuration Protocol (NETCONF) Capability URNs для идентификаторов возможностей NETCONF. Добавление в этот реестр выполняется по процедуре IETF Standards Action.

Агентство IANA обновило в реестре перечисленные в таблице возможности со ссылками на этот документ.

Индекс

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

:writable-running

urn:ietf:params:netconf:capability:writable-running:1.0

:candidate

urn:ietf:params:netconf:capability:candidate:1.0

:rollback-on-error

urn:ietf:params:netconf:capability:rollback-on-error:1.0

:startup

urn:ietf:params:netconf:capability:startup:1.0

:url

urn:ietf:params:netconf:capability:url:1.0

:xpath

urn:ietf:params:netconf:capability:xpath:1.0

В реестр добавлены также перечисленные в следующей таблице возможности.

Индекс

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

:base:1.1

urn:ietf:params:netconf:base:1.1

:confirmed-commit:1.1

urn:ietf:params:netconf:capability:confirmed-commit:1.1

:validate:1.1

urn:ietf:params:netconf:capability:validate:1.1

11. Авторы

Кроме редакторов в написании этого документа принимали участие

Ken Crozier, Cisco Systems;

Ted Goddard, IceSoft;

Eliot Lear, Cisco Systems;

Phil Shafer, Juniper Networks;

Steve Waldbusser;

Margaret Wasserman, Painless Security, LLC.

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

Авторы признательны члена рабочей группы NETCONF. В частнсти, авторы благодарны Wes Hardaker за настойчивость и терпение при разъяснении вопросов безопасности. Спасибо также Randy Presuhn, Sharon Chisholm, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen, Dave Harrington, Ladislav Lhotka, Tom Petch и Kent Watsen за их ценные советы.

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, “An IETF URN Sub-namespace for Registered Protocol Parameters”, BCP 73, RFC 3553, June 2003.

[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC 3629, November 2003.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, January 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.

[RFC5717] Lengyel, B. and M. Bjorklund, “Partial Lock Remote Procedure Call (RPC) for NETCONF”, RFC 5717, December 2009.

[RFC6020] Bjorklund, M., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 60203, October 2010.

[RFC6021] Schoenwaelder, J., “Common YANG Data Types”, RFC 6021, October 2010.

[RFC6242] Wasserman, M., “Using the NETCONF Configuration Protocol over Secure Shell (SSH)”, RFC 6242, June 2011.

[W3C.REC-xml-20001006] Sperberg-McQueen, C., Bray, T., Paoli, J., and E. Maler, “Extensible Markup Language (XML) 1.0 (Second Edition)”, World Wide Web Consortium REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>4.

[W3C.REC-xpath-19991116] DeRose, S. and J. Clark, “XML Path Language (Xpath) Version 1.0”, World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.

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

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, June 2000.

[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, “Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols”, BCP 70, RFC 3470, January 2003.

[RFC4251] Ylonen, T. and C. Lonvick, “The Secure Shell (SSH) Protocol Architecture”, RFC 4251, January 2006.

[RFC4741] Enns, R., “NETCONF Configuration Protocol”, RFC 4741, December 2006.

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, August 2008.

[W3C.REC-xslt-19991116] Clark, J., “XSL Transformations (XSLT) Version 1.0”, World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.

Приложение A. Список ошибок NETCONF

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

Для каждого error-tag указаны действительные значения error-type и error-severity вместе с обязательными данными error-info, если они есть.

   error-tag:      in-use
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    The request requires a resource that already is in use.

   error-tag:      invalid-value
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    The request specifies an unacceptable value for one or more parameters.

   error-tag:      too-big
   error-type:     transport, rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    The request or response (that would be generated) is
                   too large for the implementation to handle.

   error-tag:      missing-attribute
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     <bad-attribute> : name of the missing attribute
                   <bad-element> : name of the element that is supposed
                     to contain the missing attribute
   Description:    An expected attribute is missing.

   error-tag:      bad-attribute
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     <bad-attribute> : name of the attribute w/ bad value
                   <bad-element> : name of the element that contains
                     the attribute with the bad value
   Description:    An attribute value is not correct; e.g., wrong type,
                   out of range, pattern mismatch.

   error-tag:      unknown-attribute
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     <bad-attribute> : name of the unexpected attribute
                   <bad-element> : name of the element that contains
                     the unexpected attribute
   Description:    An unexpected attribute is present.

   error-tag:      missing-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the missing element
   Description:    An expected element is missing.

   error-tag:      bad-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the element w/ bad value
   Description:    An element value is not correct; e.g., wrong type,
                   out of range, pattern mismatch.

   error-tag:      unknown-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the unexpected element
   Description:    An unexpected element is present.

   error-tag:      unknown-namespace
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the element that contains
                     the unexpected namespace
                   <bad-namespace> : name of the unexpected namespace
   Description:    An unexpected namespace is present.

   error-tag:      access-denied
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Access to the requested protocol operation or
                   data model is denied because authorization failed.
   error-tag:      lock-denied
   error-type:     protocol
   error-severity: error
   error-info:     <session-id> : session ID of session holding the
                     requested lock, or zero to indicate a non-NETCONF
                     entity holds the lock
   Description:    Access to the requested lock is denied because the
                   lock is currently held by another entity.

   error-tag:      resource-denied
   error-type:     transport, rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because of
                   insufficient resources.

   error-tag:      rollback-failed
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Request to roll back some configuration change (via
                   rollback-on-error or <discard-changes> operations)
                   was not completed for some reason.

   error-tag:      data-exists
   error-type:     application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the relevant
                   data model content already exists.  For example,
                   a "create" operation was attempted on data that
                   already exists.

   error-tag:      data-missing
   error-type:     application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the relevant
                   data model content does not exist.  For example,
                   a "delete" operation was attempted on
                   data that does not exist.

   error-tag:      operation-not-supported
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the requested
                   operation is not supported by this implementation.
   error-tag:      operation-failed
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the requested
                   operation failed for some reason not covered by
                   any other error condition.

   error-tag:      partial-operation
   error-type:     application
   error-severity: error
   error-info:     <ok-element> : identifies an element in the data
                     model for which the requested operation has been
                     completed for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

                   <err-element> : identifies an element in the data
                     model for which the requested operation has failed
                     for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

                   <noop-element> : identifies an element in the data
                     model for which the requested operation was not
                     attempted for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

   Description:    This error-tag is obsolete, and SHOULD NOT be sent
                   by servers conforming to this document.

                   Some part of the requested operation failed or was
                   not attempted for some reason.  Full cleanup has
                   not been performed (e.g., rollback not supported)
                   by the server.  The error-info container is used
                   to identify which portions of the application
                   data model content for which the requested operation
                   has succeeded (<ok-element>), failed (<bad-element>),
                   or not been attempted (<noop-element>).
   error-tag:      malformed-message
   error-type:     rpc
   error-severity: error
   error-info:     none
   Description:    A message could not be handled because it failed to
                   be parsed correctly.  For example, the message is not
                   well-formed XML or it uses an invalid character set.

                   This error-tag is new in :base:1.1 and MUST NOT be
                   sent to old clients.

Приложение B. Схема XML для уровня сообщений NETCONF

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

   <CODE BEGINS> file "netconf.xsd"

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
              targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified"
              xml:lang="en"
              version="1.1">

     <xs:annotation>
       <xs:documentation>
         This schema defines the syntax for the NETCONF Messages layer
         messages 'hello', 'rpc', and 'rpc-reply'.
       </xs:documentation>
     </xs:annotation>

     <!--
        импорт стандартных определений XML
       -->
     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                schemaLocation="http://www.w3.org/2001/xml.xsd">
       <xs:annotation>
         <xs:documentation>
           This import accesses the xml: attribute groups for the
           xml:lang as declared on the error-message element.
         </xs:documentation>
       </xs:annotation>
     </xs:import>
     <!--
        Атрибут message-id
       -->
     <xs:simpleType name="messageIdType">
       <xs:restriction base="xs:string">
         <xs:maxLength value="4095"/>
       </xs:restriction>
     </xs:simpleType>
     <!--
        Типы, используемые для session-id
       -->
     <xs:simpleType name="SessionId">
       <xs:restriction base="xs:unsignedInt">
         <xs:minInclusive value="1"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="SessionIdOrZero">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>
     <!--
        Элемент <rpc>
       -->
     <xs:complexType name="rpcType">
       <xs:sequence>
         <xs:element ref="rpcOperation"/>
       </xs:sequence>
       <xs:attribute name="message-id" type="messageIdType"
                     use="required"/>
       <!--
          С элементом <rpc> могут представляться произвольные атрибуты.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc" type="rpcType"/>
     <!--
        Типы данные и элементы, используемые для создания rpc-error
       -->
     <xs:simpleType name="ErrorType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="transport"/>
         <xs:enumeration value="rpc"/>
         <xs:enumeration value="protocol"/>
         <xs:enumeration value="application"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="ErrorTag">
       <xs:restriction base="xs:string">
         <xs:enumeration value="in-use"/>
         <xs:enumeration value="invalid-value"/>
         <xs:enumeration value="too-big"/>
         <xs:enumeration value="missing-attribute"/>
         <xs:enumeration value="bad-attribute"/>
         <xs:enumeration value="unknown-attribute"/>
         <xs:enumeration value="missing-element"/>
         <xs:enumeration value="bad-element"/>
         <xs:enumeration value="unknown-element"/>
         <xs:enumeration value="unknown-namespace"/>
         <xs:enumeration value="access-denied"/>
         <xs:enumeration value="lock-denied"/>
         <xs:enumeration value="resource-denied"/>
         <xs:enumeration value="rollback-failed"/>
         <xs:enumeration value="data-exists"/>
         <xs:enumeration value="data-missing"/>
         <xs:enumeration value="operation-not-supported"/>
         <xs:enumeration value="operation-failed"/>
         <xs:enumeration value="partial-operation"/>
         <xs:enumeration value="malformed-message"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="ErrorSeverity">
       <xs:restriction base="xs:string">
         <xs:enumeration value="error"/>
         <xs:enumeration value="warning"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:complexType name="errorInfoType">
       <xs:sequence>
         <xs:choice>
           <xs:element name="session-id" type="SessionIdOrZero"/>
           <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:sequence>
               <xs:element name="bad-attribute" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="bad-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="ok-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="err-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="noop-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="bad-namespace" type="xs:string"
                           minOccurs="0" maxOccurs="1"/>
             </xs:sequence>
           </xs:sequence>
         </xs:choice>
         <!-- Элементы из любого другого пространства имен также могут
              следовать за элементами NETCONF -->
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
     <xs:complexType name="rpcErrorType">
       <xs:sequence>
         <xs:element name="error-type" type="ErrorType"/>
         <xs:element name="error-tag" type="ErrorTag"/>
         <xs:element name="error-severity" type="ErrorSeverity"/>
         <xs:element name="error-app-tag" type="xs:string"
                     minOccurs="0"/>
         <xs:element name="error-path" type="xs:string" minOccurs="0"/>
         <xs:element name="error-message" minOccurs="0">
           <xs:complexType>
             <xs:simpleContent>
               <xs:extension base="xs:string">
                 <xs:attribute ref="xml:lang" use="optional"/>
               </xs:extension>
             </xs:simpleContent>
           </xs:complexType>
         </xs:element>
         <xs:element name="error-info" type="errorInfoType"
                     minOccurs="0"/>
       </xs:sequence>
     </xs:complexType>
     <!--
        Атрибуты операции, используемые в <edit-config>
       -->
     <xs:simpleType name="editOperationType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="merge"/>
         <xs:enumeration value="replace"/>
         <xs:enumeration value="create"/>
         <xs:enumeration value="delete"/>
         <xs:enumeration value="remove"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:attribute name="operation" type="editOperationType"/>
     <!--
        Элемент <rpc-reply>
       -->
     <xs:complexType name="rpcReplyType">
       <xs:choice>
         <xs:element name="ok"/>
         <xs:sequence>
           <xs:element ref="rpc-error"
                       minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="rpcResponse"
                       minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:choice>
       <xs:attribute name="message-id" type="messageIdType"
                     use="optional"/>
       <!--
          Любые атрибуты, представленные с элементом <rpc>, должны возвращаться
          с <rpc-reply>.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc-reply" type="rpcReplyType"/>
     <!--
        Элемент <rpc-error>
          -->
     <xs:element name="rpc-error" type="rpcErrorType"/>
     <!--
        rpcOperationType используется в качестве базового типа
        для всех операций NETCONF 
       -->
     <xs:complexType name="rpcOperationType"/>
     <xs:element name="rpcOperation" type="rpcOperationType"
                 abstract="true"/>
     <!--
        rpcResponseType используется в качестве базового типа
        для всех откликов NETCONF
       -->
     <xs:complexType name="rpcResponseType"/>
     <xs:element name="rpcResponse" type="rpcResponseType"
                 abstract="true"/>
     <!--
        Элемент <hello>
       -->
     <xs:element name="hello">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="capabilities">
             <xs:complexType>
               <xs:sequence>
                 <xs:element name="capability" type="xs:anyURI"
                             maxOccurs="unbounded"/>
               </xs:sequence>
             </xs:complexType>
           </xs:element>
           <xs:element name="session-id" type="SessionId"
                       minOccurs="0"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
   </xs:schema>

   <CODE ENDS>

Приложение C. Модуль YANG для операций протокола NETCONF

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

Модуль YANG ietf-netconf импортирует определения типов (typedef) из [RFC6021].

  <CODE BEGINS> file "ietf-netconf@2011-06-01.yang"

  module ietf-netconf {

    // Пространство имен для определений NETCONF XML не изменилось 
    // по сравнению RFC 4741, который этот документ заменяет
    namespace "urn:ietf:params:xml:ns:netconf:base:1.0";

    prefix nc;

    import ietf-inet-types {
      prefix inet;
    }

    organization
      "IETF NETCONF (Network Configuration) Working Group";

    contact
      "WG Web:   <http://tools.ietf.org/wg/netconf/>
       WG List:  <netconf@ietf.org>

       WG Chair: Bert Wijnen
                 <bertietf@bwijnen.net>

       WG Chair: Mehmet Ersue
                 <mehmet.ersue@nsn.com>

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

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

       Editor:   Andy Bierman
                 <andy.bierman@brocade.com>";

    description
      "NETCONF Protocol Data Types and Protocol Operations.

       Copyright (c) 2011 IETF Trust and the persons identified as
       the document authors.  All rights reserved.

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

       This version of this YANG module is part of RFC 6241; see
       the RFC itself for full legal notices.";
    revision 2011-06-01 {
      description
        "Initial revision";
      reference
        "RFC 6241: Network Configuration Protocol";
    }

    extension get-filter-element-attributes {
      description
        "If this extension is present within an 'anyxml'
         statement named 'filter', which must be conceptually
         defined within the RPC input section for the <get>
         and <get-config> protocol operations, then the
         following unqualified XML attribute is supported
         within the <filter> element, within a <get> or
         <get-config> protocol operation:

           type : optional attribute with allowed
                  value strings 'subtree' and 'xpath'.
                  If missing, the default value is 'subtree'.

         If the 'xpath' feature is supported, then the
         following unqualified XML attribute is
         also supported:

           select: optional attribute containing a
                   string representing an XPath expression.
                   The 'type' attribute must be equal to 'xpath'
                   if this attribute is present.";
    }

    // Возможности NETCONF, определенные как функции
    feature writable-running {
      description
        "NETCONF :writable-running capability;
         If the server advertises the :writable-running
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.2";
    }

    feature candidate {
      description
        "NETCONF :candidate capability;
         If the server advertises the :candidate
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.3";
    }

    feature confirmed-commit {
      if-feature candidate;
      description
        "NETCONF :confirmed-commit:1.1 capability;
         If the server advertises the :confirmed-commit:1.1
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";

      reference "RFC 6241, Section 8.4";
    }

    feature rollback-on-error {
      description
        "NETCONF :rollback-on-error capability;
         If the server advertises the :rollback-on-error
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.5";
    }

    feature validate {
      description
        "NETCONF :validate:1.1 capability;
         If the server advertises the :validate:1.1
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.6";
    }

    feature startup {
      description
        "NETCONF :startup capability;
         If the server advertises the :startup
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.7";
    }

    feature url {
      description
        "NETCONF :url capability;
         If the server advertises the :url
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.8";
    }

    feature xpath {
      description
        "NETCONF :xpath capability;
         If the server advertises the :xpath
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.9";
    }

    // Простые типы NETCONF

    typedef session-id-type {
      type uint32 {
        range "1..max";
      }
      description
        "NETCONF Session Id";
    }

    typedef session-id-or-zero-type {
      type uint32;
      description
        "NETCONF Session Id or Zero to indicate none";
    }
    typedef error-tag-type {
      type enumeration {
         enum in-use {
           description
             "The request requires a resource that
              already is in use.";
         }
         enum invalid-value {
           description
             "The request specifies an unacceptable value for one
              or more parameters.";
         }
         enum too-big {
           description
             "The request or response (that would be generated) is
              too large for the implementation to handle.";
         }
         enum missing-attribute {
           description
             "An expected attribute is missing.";
         }
         enum bad-attribute {
           description
             "An attribute value is not correct; e.g., wrong type,
              out of range, pattern mismatch.";
         }
         enum unknown-attribute {
           description
             "An unexpected attribute is present.";
         }
         enum missing-element {
           description
             "An expected element is missing.";
         }
         enum bad-element {
           description
             "An element value is not correct; e.g., wrong type,
              out of range, pattern mismatch.";
         }
         enum unknown-element {
           description
             "An unexpected element is present.";
         }
         enum unknown-namespace {
           description
             "An unexpected namespace is present.";
         }
         enum access-denied {
           description
             "Access to the requested protocol operation or
              data model is denied because authorization failed.";
         }
         enum lock-denied {
           description
             "Access to the requested lock is denied because the
              lock is currently held by another entity.";
         }
         enum resource-denied {
           description
             "Request could not be completed because of
              insufficient resources.";
         }
         enum rollback-failed {
           description
             "Request to roll back some configuration change (via
              rollback-on-error or <discard-changes> operations)
              was not completed for some reason.";

         }
         enum data-exists {
           description
             "Request could not be completed because the relevant
              data model content already exists.  For example,
              a 'create' operation was attempted on data that
              already exists.";
         }
         enum data-missing {
           description
             "Request could not be completed because the relevant
              data model content does not exist.  For example,
              a 'delete' operation was attempted on
              data that does not exist.";
         }
         enum operation-not-supported {
           description
             "Request could not be completed because the requested
              operation is not supported by this implementation.";
         }
         enum operation-failed {
           description
             "Request could not be completed because the requested
              operation failed for some reason not covered by
              any other error condition.";
         }
         enum partial-operation {
           description
             "This error-tag is obsolete, and SHOULD NOT be sent
              by servers conforming to this document.";
         }
         enum malformed-message {
           description
             "A message could not be handled because it failed to
              be parsed correctly.  For example, the message is not
              well-formed XML or it uses an invalid character set.";
         }
       }
       description "NETCONF Error Tag";
       reference "RFC 6241, Appendix A";
    }

    typedef error-severity-type {
      type enumeration {
        enum error {
          description "Error severity";
        }
        enum warning {
          description "Warning severity";
        }
      }
      description "NETCONF Error Severity";
      reference "RFC 6241, Section 4.3";
    }

    typedef edit-operation-type {
      type enumeration {
        enum merge {
          description
            "The configuration data identified by the
             element containing this attribute is merged
             with the configuration at the corresponding
             level in the configuration datastore identified
             by the target parameter.";
        }
        enum replace {
          description
            "The configuration data identified by the element
             containing this attribute replaces any related
             configuration in the configuration datastore
             identified by the target parameter.  If no such
             configuration data exists in the configuration
             datastore, it is created.  Unlike a
             <copy-config> operation, which replaces the
             entire target configuration, only the configuration
             actually present in the config parameter is affected.";
        }
        enum create {
          description
            "The configuration data identified by the element
             containing this attribute is added to the
             configuration if and only if the configuration
             data does not already exist in the configuration
             datastore.  If the configuration data exists, an
             <rpc-error> element is returned with an
             <error-tag> value of 'data-exists'.";
        }
        enum delete {
          description
            "The configuration data identified by the element
             containing this attribute is deleted from the
             configuration if and only if the configuration
             data currently exists in the configuration
             datastore.  If the configuration data does not
             exist, an <rpc-error> element is returned with
             an <error-tag> value of 'data-missing'.";
        }
        enum remove {
          description
            "The configuration data identified by the element
             containing this attribute is deleted from the
             configuration if the configuration
             data currently exists in the configuration
             datastore.  If the configuration data does not
             exist, the 'remove' operation is silently ignored
             by the server.";
        }
      }
      default "merge";
      description "NETCONF 'operation' attribute values";
      reference "RFC 6241, Section 7.2";
    }

    // Стандартные протокольные операции NETCONF

    rpc get-config {
      description
        "Retrieve all or part of a specified configuration.";

      reference "RFC 6241, Section 7.1";

      input {
        container source {
          description
            "Particular configuration to retrieve.";

          choice config-source {
            mandatory true;
            description
              "The configuration to retrieve.";
            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config source.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config source.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config source.
                 This is optional-to-implement on the server because
                 not all servers will support filtering for this
                 datastore.";
            }
          }
        }

        anyxml filter {
          description
            "Subtree or XPath filter to use.";
          nc:get-filter-element-attributes;
        }
      }

      output {
        anyxml data {
          description
            "Copy of the source datastore subset that matched
             the filter criteria (if any).  An empty data container
             indicates that the request did not produce any results.";
        }
      }
    }

    rpc edit-config {
      description
        "The <edit-config> operation loads all or part of a specified
         configuration to the specified target configuration.";

      reference "RFC 6241, Section 7.2";

      input {
        container target {
          description
            "Particular configuration to edit.";

          choice config-target {
            mandatory true;
            description
              "The configuration target.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              if-feature writable-running;
              type empty;
              description
                "The running configuration is the config source.";
            }
          }
        }

        leaf default-operation {
          type enumeration {
            enum merge {
              description
                "The default operation is merge.";
            }
            enum replace {
              description
                "The default operation is replace.";
            }
            enum none {
              description
                "There is no default operation.";
            }
          }
          default "merge";
          description
            "The default operation to use.";
        }

        leaf test-option {
          if-feature validate;
          type enumeration {
            enum test-then-set {
              description
                "The server will test and then set if no errors.";
            }
            enum set {
              description
                "The server will set without a test first.";
            }
            enum test-only {
              description
                "The server will only test and not set, even
                 if there are no errors.";
            }
          }
          default "test-then-set";
          description
            "The test option to use.";
        }

        leaf error-option {
          type enumeration {
            enum stop-on-error {
              description
                "The server will stop on errors.";
            }
            enum continue-on-error {
              description
                "The server may continue on errors.";
            }
            enum rollback-on-error {
              description
                "The server will roll back on errors.
                 This value can only be used if the 'rollback-on-error'
                 feature is supported.";
            }
          }
          default "stop-on-error";
          description
            "The error option to use.";
        }

        choice edit-content {
          mandatory true;
          description
            "The content for the edit operation.";

          anyxml config {
            description
              "Inline Config content.";
          }
          leaf url {
            if-feature url;
            type inet:uri;
            description
              "URL-based config content.";
          }
        }
      }
    }

    rpc copy-config {
      description
        "Create or replace an entire configuration datastore with the
         contents of another complete configuration datastore.";

      reference "RFC 6241, Section 7.3";

      input {
        container target {
          description
            "Particular configuration to copy to.";

          choice config-target {
            mandatory true;
            description
              "The configuration target of the copy operation.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              if-feature writable-running;
              type empty;
              description
                "The running configuration is the config target.
                 This is optional-to-implement on the server.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config target.";
            }
          }
        }

        container source {
          description
            "Particular configuration to copy from.";

          choice config-source {
            mandatory true;
            description
              "The configuration source for the copy operation.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config source.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config source.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config source.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config source.";
            }
            anyxml config {
              description
                "Inline Config content: <config> element.  Represents
                 an entire configuration datastore, not
                 a subset of the running datastore.";
            }
          }
        }
      }
    }

    rpc delete-config {
      description
        "Delete a configuration datastore.";

      reference "RFC 6241, Section 7.4";

      input {
        container target {
          description
            "Particular configuration to delete.";

          choice config-target {
            mandatory true;
            description
              "The configuration target to delete.";

            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config target.";
            }
          }
        }
      }
    }

    rpc lock {
      description
        "The lock operation allows the client to lock the configuration
         system of a device.";
      reference "RFC 6241, Section 7.5";

      input {
        container target {
          description
            "Particular configuration to lock.";

          choice config-target {
            mandatory true;
            description
              "The configuration target to lock.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config target.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
          }
        }
      }
    }

    rpc unlock {
      description
        "The unlock operation is used to release a configuration lock,
         previously obtained with the 'lock' operation.";

      reference "RFC 6241, Section 7.6";

      input {
        container target {
          description
            "Particular configuration to unlock.";

          choice config-target {
            mandatory true;
            description
              "The configuration target to unlock.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config target.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
          }
        }
      }
    }

    rpc get {
      description
        "Retrieve running configuration and device state information.";

      reference "RFC 6241, Section 7.7";

      input {
        anyxml filter {
          description
            "This parameter specifies the portion of the system
             configuration and state data to retrieve.";
          nc:get-filter-element-attributes;
        }
      }

      output {
        anyxml data {
          description
            "Copy of the running datastore subset and/or state
             data that matched the filter criteria (if any).
             An empty data container indicates that the request did not
             produce any results.";
        }
      }
    }

    rpc close-session {
      description
        "Request graceful termination of a NETCONF session.";

      reference "RFC 6241, Section 7.8";
    }

    rpc kill-session {
      description
        "Force the termination of a NETCONF session.";

      reference "RFC 6241, Section 7.9";

      input {
        leaf session-id {
          type session-id-type;
          mandatory true;
          description
            "Particular session to kill.";
        }
      }
    }

    rpc commit {
      if-feature candidate;

      description
        "Commit the candidate configuration as the device's new
         current configuration.";

      reference "RFC 6241, Section 8.3.4.1";

      input {
        leaf confirmed {
          if-feature confirmed-commit;
          type empty;
          description
            "Requests a confirmed commit.";
          reference "RFC 6241, Section 8.3.4.1";
        }

        leaf confirm-timeout {
          if-feature confirmed-commit;
          type uint32 {
            range "1..max";
          }
          units "seconds";
          default "600";   // 10 минут
          description
            "The timeout interval for a confirmed commit.";
          reference "RFC 6241, Section 8.3.4.1";
        }

        leaf persist {
          if-feature confirmed-commit;
          type string;
          description
            "This parameter is used to make a confirmed commit
             persistent.  A persistent confirmed commit is not aborted
             if the NETCONF session terminates.  The only way to abort
             a persistent confirmed commit is to let the timer expire,
             or to use the <cancel-commit> operation.

             The value of this parameter is a token that must be given
             in the 'persist-id' parameter of <commit> or
             <cancel-commit> operations in order to confirm or cancel
             the persistent confirmed commit.

             The token should be a random string.";
          reference "RFC 6241, Section 8.3.4.1";
        }

        leaf persist-id {
          if-feature confirmed-commit;
          type string;
          description
            "This parameter is given in order to commit a persistent
             confirmed commit.  The value must be equal to the value
             given in the 'persist' parameter to the <commit> operation.
             If it does not match, the operation fails with an
            'invalid-value' error.";
          reference "RFC 6241, Section 8.3.4.1";
        }
      }
    }

    rpc discard-changes {
      if-feature candidate;

      description
        "Revert the candidate configuration to the current
         running configuration.";
      reference "RFC 6241, Section 8.3.4.2";
    }

    rpc cancel-commit {
      if-feature confirmed-commit;
      description
        "This operation is used to cancel an ongoing confirmed commit.
         If the confirmed commit is persistent, the parameter
         'persist-id' must be given, and it must match the value of the
         'persist' parameter.";
      reference "RFC 6241, Section 8.4.4.1";

      input {
        leaf persist-id {
          type string;
          description
            "This parameter is given in order to cancel a persistent
             confirmed commit.  The value must be equal to the value
             given in the 'persist' parameter to the <commit> operation.
             If it does not match, the operation fails with an
            'invalid-value' error.";
        }
      }
    }

    rpc validate {
      if-feature validate;

      description
        "Validates the contents of the specified configuration.";

      reference "RFC 6241, Section 8.6.4.1";

      input {
        container source {
          description
            "Particular configuration to validate.";

          choice config-source {
            mandatory true;
            description
              "The configuration source to validate.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config source.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config source.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config source.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config source.";
            }
            anyxml config {
              description
                "Inline Config content: <config> element.  Represents
                 an entire configuration datastore, not
                 a subset of the running datastore.";
            }
          }
        }
      }
    }
  }

  <CODE ENDS>

Приложение D. Шаблон возможности

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

D.1. capability-name (шаблон)

D.1.1. Overview

D.1.2. Dependencies

D.1.3. Capability Identifier

The {name} capability is identified by the following capability string:

      {capability uri}

D.1.4. New Operations

D.1.4.1. <op-name>

D.1.5. Modifications to Existing Operations

D.1.5.1. <op-name>

If existing operations are not modified by this capability, this section may be omitted.

D.1.6. Interactions with Other Capabilities

If this capability does not interact with other capabilities, this section may be omitted.

Приложение E. Настройка множества устройств в NETCONF

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

E.1. Операции с отдельным устройством

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

Защищенная смена конфигурации каждого отдельного устройства включает множество этапов:

  • блокировка конфигурации;

  • создание контрольной точки для рабочей конфигурации;

  • загрузка и проверка пригодности новой конфигурации;

  • замена рабочей конфигурации;

  • тестирование новой конфигурации;

  • сохранение изменений (если они устраивают);

  • снятие блокировки.

Далее все эти этапы рассмотрены более подробно.

E.1.1. Блокировка конфигурации

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

Блокировку можно организовать с помощью операции <lock>.

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

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

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

E.1.2. Контрольные точки рабочей конфигурации

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

Контрольную точку можно создать с помощью операции <copy-config>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <target>
           <url>file://checkpoint.conf</url>
         </target>
         <source>
           <running/>
         </source>
       </copy-config>
     </rpc>

Для восстановления конфигурации служит та же операция со сменой мест параметров <source> и <target>.

E.1.3. Загрузка и проверка пригодности конфигурации

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

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <candidate/>
         </target>
         <config>
           <!-- здесь указываются изменения конфигурации -->
         </config>
       </edit-config>
     </rpc>

Если устройство поддерживает возможность :validate:1.1, оно будет по умолчанию проверять пригодность входящей конфигурации при загрузке в хранилище-кандидат. Для отключения такой проверки служит параметр <test-option> со значением set. Полную проверку можно запросить с помощью операции <validate>.

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

E.1.4. Изменение рабочей конфигурации

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

Если устройство поддерживает возможность :candidate, операция <commit> копирует информацию из хранилища-кандидата в рабочую конфигурацию. Параметр <confirmed> позволяет автоматически восстановить исходную конфигурацию, если связь с устройством будет потеряна.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <confirm-timeout>120</confirm-timeout>
       </commit>
     </rpc>

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

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <!-- здесь указываются изменения конфигурации -->
         </config>
       </edit-config>
     </rpc>

E.1.5. Тестирование новой конфигурации

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

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

E.1.6. Сохранение изменений

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

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

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

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

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

E.1.7. Снятие блокировки конфигурации

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

Для снятия блокировки служит операция <unlock>.

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

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

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

E.2. Операции со множеством устройств

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

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

Второй класс более интересен и требует завершения операций на всех устройствах или полного возврата к пержней конфигурации. Т. е. сеть должна целиком перейти в новое состояние или восстановить прежнее. Например, переход на VPN может потребовать обновления множества устройств. Другим примером может служить определение нового класса обслуживания. Если в сети будет обновлена лишь часть устройств, приведет к проблемам, когда начнется применение нового класса определения.

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

Приложение F. Отличия от RFC 4741

В это приложении отмечены основные отличия данного документа от RFC 4741.

  • Добавлен тег ошибки malformed-message.

  • Добавлено перечисляемое значение remove для атрибута operation.

  • Отменен тег ошибки partial-operation.

  • Добавлены параметры <persist> и <persist-id> для операции <commit>.

  • Обновлен идентификатор URI базового протокола и уточнен обмен сообщениями <hello> для выбора и идентификации версии базового протокола, используемого в конкретной сессии.

  • Добавлен модуль YANG для моделирования операций и удален уровень операций из XSD.

  • Уточнено поведение блокировки для хранилища-кандидата.

  • Уточнены требования к откликам сервера на ошибки для значения delete в атрибуте operation.

  • Добавлен мезанизм шаблонов пространства имен для фильтрации ветевый (subtree).

  • Добавлено значение test-only для параметра <test-option> операции <edit-config>.

  • Добавлена операция <cancel-commit>.

  • Введено имя пользователя NETCONF и требования для транспортных протоколов, разъясняющие вывод имени пользователя.


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

Rob Enns (редактор)

Juniper Networks

EMail: rob.enns@gmail.com

Martin Bjorklund (редактор)

Tail-f Systems

EMail: mbj@tail-f.com

Juergen Schoenwaelder (редактор)

Jacobs University

EMail: j.schoenwaelder@jacobs-university.de

Andy Bierman (редактор)

Brocade

EMail: andy.bierman@brocade.com


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

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

nmalykh@gmail.com

1Blocks Extensible Exchange Protocol — расширяемый протокол обмен блоками.

2Authentication, Authorization, and Accounting — проверка подлинности, контроль полномочий и учет.

3В RFC 7950 определена спецификация версии 1.1 протокола YANG, однако новый документ не отменяет RFC 6020. Прим. перев.

4Этот документ был обновлен. На момент публикации перевода новый вариант был доступен по ссылке. Прим. перев.

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

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

Or