RFC 6481 A Profile for Resource Certificate Repository Structure

Опубликовано 08.02.2012 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                         G. Huston
Request for Comments: 6481                                    R. Loomans
Category: Standards Track                                  G. Michaelson
ISSN: 2070-1721                                                    APNIC
                                                           February 2012

Профиль структуры репозитория сертификатов ресурсов

A Profile for Resource Certificate Repository Structure

PDF

Аннотация

Этот документ определяет профиль для структуры распределенного репозитория ресурсов инфраструктуры открытых ключей ресурсов (RPKI¹). Каждая отдельная точка публикации репозитория является каталогом, содержащим файлы, которые соответствуют сертификатам ресурсов X.509/PKIX, спискам отзыва (CRL²) и подписанным объектам. Профиль определяет схему именования объектов (файлов), содержимое точек публикации репозитория (каталогов) и предлагаемую внутреннюю структуру локального кэша репозитория для облегчения процедур синхронизации распределенного множества точек публикации и процедур построения путей сертификации.

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

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

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

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

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

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

1. Введение

Для проверки аттестаций, сделанных в контексте RPKI [RFC6480] зависимым сторонам (RP⁵) нужен доступ ко всем сертификатам ресурсов X.509/PKIX, спискам отзыва (CRL) и подписанным объектам, совместно определяющим RPKI.

Каждый эмитент сертификата, CRL или подписанного объекта делает его доступным для загрузки в RP путем публикации объектов в репозитории RPKI.

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

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

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

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

Предполагается, что читатель знаком с терминами и концепциями, описанными в документах «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» [RFC5280] и «X.509 Extensions for IP Addresses and AS Identifiers» [RFC3779].

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

Repository Object (или Object) — объект репозитория

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

Repository Publication Point — точка публикации репозитория

Обозначает набор объектов (Repository Object), опубликованных в общей точке публикации. Обычно это каталог файловой системы с публичным доступом, который указывается идентификатором URI [RFC3986], хотя иная форма локального хранилища, которая выглядит подобно простому каталогу файлов, также описывается этим термином.

Repository Instance — экземпляр репозитория

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

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

2. Содержимое и структура точки публикации репозитория RPKI

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

В этом разделе описана коллекция объектов (сертификаты RPKI, списки CRL, манифесты и подписанные объекты), поддерживаемая в точке публикации репозитория.

               +--------+
    +--------->| Cert A |<----+
    |          |  AIA   |     |
    |  +--------- SIA   |     |
    |  |       +--------+     |
    |  |                      |
    |  |  +-------------------|------------------+
    |  |  |                   |                  |
    |  +->|   +--------+      |   +--------+     |
    |     |   | Cert B |      |   | Cert C |     |
    |     |   | CRLDP-------+ |   | CRLDP-----+  |
    +----------- AIA   |    | +----- AIA   |  |  |
          |   |  SIA------+ |     |  SIA------------+
          |   +--------+  | |     +--------+  |  |  |
          |               | V                 V  |  |
          |               | +-----------------+  |  |
          |               | | CRL, изданный A |  |  |
          | Каталог       | +-----------------+  |  |
          | репозитория A |                      |  |
          +---------------|----------------------+  |
                          |                         |
+----------------+        |    +----------------+   |
| Каталог        |<-------+    | Каталог        |<--+
| репозитория B  |             | репозитория C  |
+----------------+             +----------------+

Рисунок 1: Использование расширений AIA и SIA в RPKI.

Для каждого сертификата удостоверяющего центра (УЦ или CA⁷) в RPKI имеется соответствующая точка публикации репозитория, которая является уполномоченной для всех текущих сертификатов и CRL, выпущенных этим CA. Расширение SIA в сертификате содержит идентификатор URI [RFC3986], указывающий точку публикации репозитория и механизмы доступа к нему. В дополнение к этому расширение AIA⁸ содержит идентификатор URI, указывающий полномочное местоположение сертификата CA, которым был выпущен данный сертификат.

Например, если субъект сертификата A выпустил сертификаты B и C, то расширение AIA сертификатов B и C будет указывать на точку публикации сертификата объекта A, а расширение SIA в сертификате A будет указывать точку публикации (каталог), содержащий сертификаты B и C (см. рисунок 1).

На рисунке 1 сертификаты B и C изданы CA A. Следовательно, расширения AIA в сертификатах B и C будут указывать на (сертификат) A, а расширение SIA в сертификате A — на точку публикации репозитория для продукции CA A, который включает сертификаты B и C, а также CRL выпущенный A. Расширение CRLDP⁹ в сертификатах B и C будет указывать на CRL, выпущенные A.

В такой структуре распределенного хранилища точка публикации репозитория CA содержит все опубликованные этим CA сертификаты, а также выпущенные им списки отзыва (CRL). Этот репозиторий включает также все опубликованные объекты с цифровыми подписями, которые проверяются по сертификатам конечных элементов (EE¹⁰), выпущенных этим CA.

2.1. Манифесты

Каждая точка публикации репозитория должна включать манифест [RFC6486], содержащий список имен всех объектов, а также хэш-значение содержимого каждого объекта, опубликованного в настоящий момент CA или EE.

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

2.2. Точки публикации репозиториев CA

Сертификат CA имеет два элемента accessMethod, заданных в поле SIA. Элемент id-ad-caRepository accessMethod связан с элементом accessLocation, который указывает точку публикации репозитория с сертификатами, выпущенными этим CA, как указано в [RFC6487]. Элемент id-ad-rpkiManifest accessMethod связан с элементом accessLocation, указывающим с помощью URI объекта (а не URI каталога) на объект манифеста, связанного с этим CA.

Репозиторий публикации CA содержит текущие (не просроченные и не отозванные) сертификаты, выпущенные этим CA, наиболее свежий список CRL, выпущенный этим CA, текущий манифест и все прочие подписанные объекты, которые могут быть проверены с использованием сертификата EE [RFC6487] выпущенного этим CA.

Манифест CA содержит имена (файлов) данного набора объектов, а также хэш-значение содержимого каждого объекта за исключением самого манифеста.

Устройство RPKI требует уникальной привязки CA к одной паре ключей. Таким образом, административный орган, являющийся CA, выполняет смену ключей путем генерации нового сертификата CA с новым именем сегмента и новой парой ключей [RFC6489] (смена имени обусловлена тем, что в контексте RPKI имена субъектов во всех выпускаемых CA сертификатах должны быть уникальными, а также тем, что в процедуре смены ключей RPKI создается новый экземпляр CA с новым ключом). В таких случаях объекту следует продолжать использование прежней точки публикации репозитория для обоих экземпляров CA в процессе смены ключей, обеспечивая в процессе смены ключей сохранение пригодности ссылок на выпущенные этим CA сертификаты, которые указаны в расширении AIA непрямых подчиненных объектов, а также ограничение перевыпуска подчиненных сертификатов только прямыми «подчиненными» данного CA [RFC6489]. В таких случаях точка публикации репозитория будет содержать CRL, манифест и подчиненные сертификаты для обоих экземпляров CA (для объекта можно использовать разные точки публикации для старого и нового CA, но в таких случаях требуется очень аккуратная координация с подчиненными CA и EE, чтобы указатели AIA на уровнях иерархии RPKI, не подчиненных данному CA непосредственно, корректно согласовывались с подчиненной продукцией нового CA.)

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

CRL

Когда CA выпускает новый список CRL, он заменяет им прежний CRL (выпущенный с той же парой ключей CA) в точке публикации репозитория. CA недопустимо сохранять прежние CRL в точке публикации. Таким образом, они должны заменять (переписывать) прежние CRL, подписанный тем же (экземпляром) CA. Ненормативные рекомендации по именованию таких объектов предлагают выбирать имена файлов для CRL в репозитории на основе открытого ключа CA. Один из таких методов создания имени CRL описан в параграфе 2.1 [RFC4387] — 160 битов хэш-значения открытого ключа CA преобразуются в строку из 27 символов с использованием модифицированного кодирования Base64, как описано в разделе 5 (таблица 2) [RFC4648]. Для файла должно использоваться расширение имени .crl, обозначающее CRL. Каждый файл .crl содержит один CRL в формате DER.

Манифест

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

Сертификаты

В RPKI орган сертификации CA может выпускать серии сертификатов для одного имени субъекта с одним открытым ключом и одним и тем же набором ресурсов. Однако зависимым от инфраструктуры сторонам нужен доступ лишь к последнему сертификату такой серии. Поэтому для сертификатов таких серий следует применять одно имя файла. Это приводит к тому, что каждый новый сертификат в серии будет записываться вместо его предшественника. Можно использовать разные имена, но это осложнит проверку для пользователей. Ненормативные рекомендации по именованию сертификатов предлагают реализовать (локальное) правило, требующее от субъекта использовать уникальную пару ключей для каждой уникальной серии сертификатов, выпущенных для него. Это позволяет CA использовать схему именования на основе открытого ключа субъекта, как это описано выше для имен файлов CRL. Опубликованные сертификаты должны использовать расширение .cer, показывающее, что объект является сертификатом. Каждый файл .cer содержит один сертификат в формате DER.

Подписанные объекты

Подписанные объекты RPKI [RFC6488] публикуются в точке публикации репозитория, указываемой SIA в сертификате CA, который выпустил сертификат EE, используемый для проверки подписи этого объекта (напрямую указана SIA в сертификате EE). Ненормативные рекомендации по именованию подписанных объектов предлагают создавать имена на основе открытого ключа соответствующего сертификата EE, применяя описанный выше алгоритм. Для опубликованных подписанных объектов RPKI недопустимо использовать расширения имен файлов .crl, .mft, .cer.

На момент публикации этого документа была определена одна форма подписанного объекта ROA¹² [RFC6482]. Опубликованные ROA должны иметь расширение имени файлов .roa, указывающие, что объект является ROA.

3. Вопросы публикации сертификатов ресурсов

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

Репозиторий следует размещать на доступном сервисе с высокопроизводительной платформой.
Репозиторий должен быть доступен с помощью rsync [RFC5781] [RSYNC]. Поддержка других механизмов возможна по выбору оператора. Поддерживаемые механизмы должны быть согласованы с элементом accessMethod, указанным в SIA соответствующих сертификатов CA и EE.
В каждой точке публикации репозитория CA следует размещать продукцию этого CA, включая те объекты, которые могут быть проверены по сертификатам EE, выпущенным этим CA. Подписанная продукция связанных CA той же организации (объекта) может размещаться в той же точке публикации репозитория CA. Непосредственно в точке публикации репозитория не следует размещать объектов, отличных от каталогов.

Каждому из таких каталогов следует быть точкой публикации сертификата CA или EE, содержащегося в каталоге CA. Эти соображения применимы также к каталогам следующего уровня внутри этих каталогов. Наличие содержимого, не являющегося продукцией CA, может создать путаницу для RP, которым в таких случаях следует соблюдать осторожность, чтобы не счесть годную продукцию CA неприемлемой для использования.
Подписанные объекты размещаются в месте, указанном полем SIA в сертификате EE, используемом для проверки подписи каждого объекта. Подписанные объекты размещаются в точке публикации репозитория сертификата CA, выпустившего сертификат EE. Расширение SIA в сертификате EE указывает сам объект, а не каталог в точке публикации репозитория [RFC6487].
В параграфе 2.1 сказано, что операторам репозитория следует реализовать ту или иную форму управления каталогами в репозитории, чтобы гарантировать, что RP, выполняющие операции поиска в репозитории, не получали промежуточных состояний при внесении изменений в репозиторий и связанные с ним манифесты. Несмотря на следующий комментарий, RP не следует полагаться на соответствие манифеста содержимому репозитория и следует подобающим образом организовать свои операции поиска (см. раздел 5).

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

Наиболее часто используемым способом предотвращения несоответствия при обновлении больших каталогов является «пакетная» обработка, когда готовится пакет изменений содержимого каталога, создается рабочая копия содержимого каталога и к ней применяется пакет изменений. После завершения операции изменяется символьная ссылка в файловой системе. Содержимое старого каталога может быть удалено по истечении некоторого времени. Однако следует отметить, что результат применения этого метода в плане обеспечения целостности клиентских операций синхронизации зависит от взаимодействия поддерживаемого механизма доступа с локальной файловой системой репозитория. Существует вероятность того, что RP увидит некоторое несоответствие между манифестом и содержимым каталога. Поскольку хранилище может находиться в состоянии частичного обновления, невозможно дать гарантию наличия постоянной согласованности.

4. Повторный выпуск сертификатов и репозитории

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

В параграфе 2.2 отмечено, что при смена ключей CA следует использовать для точки публикации имя, которое сохраняется после этой замены. В таких случаях точка публикации репозитория будет содержать CRL и манифесты обоих экземпляров CA в течение процедуры смены ключей. Процедура смены ключей в RPKI [RFC6489] требует, чтобы подчиненная продукция старого CA переписывалась в общей точке публикации репозитория подчиненной продукцией нового CA.

5. Синхронизация репозитория с локальным кэшем

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

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

Общей моделью синхронизации репозитория является проход «сверху-вниз» по распределенной структуре. Процесс начинается с локального набора доверенных привязок, соответствующего локальному выбору привязок TA, которые могут использоваться для загрузки начального набора самоподписанных сертификатов ресурсов, формирующего «затравку» процесса [RFC6490]. Далее локальный кэш заполняется всеми действительными сертификатами, которые были выпущены найденными эмитентами. Эта процедура может рекурсивно повторяться для каждого из этих подчиненных сертификатов. Для такого процесса прохождения через репозиторий следует задавать локальное ограничение максимальной длины цепочки от начальных доверенных привязок. Если этого не сделать, может образоваться петля указателей SIA или возникнуть иные вырожденные формы логической иерархии RPKI, что будет приводить к невозможности RP выполнить синхронизацию репозитория с локальным кэшем RPKI.

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

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

Целостность хранилищ баз данных не предполагается защищенной и операции извлечения данных из репозитория могут быть уязвимы для разных форм MITM-атак¹³. Повреждение извлекаемых объектов обнаруживается зависимыми сторонами путем проверки подписей, связанных с каждым объектом. Подмена новых экземпляров объектов более старыми обнаруживается с помощью манифестов. Добавление отозванных, удаленных сертификатов обнаруживается путем получения и обработки CRL в периодическом режиме. Однако даже при использовании манифестов и CRL зависимая сторона может не обнаружить некоторые варианты атак с подменой на основе старых (но с неистекшим сроком действия) объектов .

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

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

7.1. Типы сред

Агентство IANA зарегистрировало два новых типа (media type):

      application/rpki-manifest
      application/rpki-roa

Данный документ также использует расширения имен файлов .cer и .crl file для типов application/pkix-cert и application/pkix-crl, определенных в [RFC2585].

7.1.1. application/rpki-manifest

   MIME media type name:  application
   MIME subtype name:  rpki-manifest
   Required parameters:  None
   Optional parameters:  None
   Encoding considerations:  binary
   Security considerations:  Carries an RPKI Manifest [RFC6486]
   Interoperability considerations:  None
   Published specification:  This document
   Applications that use this media type:  Any MIME-complaint transport
   Additional information:
      Magic number(s):  None
      File extension(s):  .mft
      Macintosh File Type Code(s):
   Person & email address to contact for further information:
      Geoff Huston <gih@apnic.net>
   Intended usage:  COMMON
   Author/Change controller:  Geoff Huston <gih@apnic.net>

7.1.2. application/rpki-roa

   MIME media type name:  application
   MIME subtype name:  rpki-roa
   Required parameters:  None
   Optional parameters:  None
   Encoding considerations:  binary
   Security considerations:  Carries an RPKI ROA [RFC6482]
   Interoperability considerations:  None
   Published specification:  This document
   Applications that use this media type:  Any MIME-complaint transport
   Additional information:
      Magic number(s):  None
      File extension(s):  .roa
      Macintosh File Type Code(s):
   Person & email address to contact for further information:
      Geoff Huston <gih@apnic.net>
   Intended usage:  COMMON
   Author/Change controller:  Geoff Huston <gih@apnic.net>

7.2. Реестр RPKI Repository Name Scheme

Агентство IANA создало реестр RPKI Repository Name Scheme, содержащий трехсимвольные расширения имен файлов для объектов репозитория RPKI. Содержимое реестра поддерживается на основе процедуры IETF Review [RFC5226]. Начальное состояние реестра отражено в таблице.

Расширение имени	Объект RPKI	Документ
.cer	Сертификат	[RFC6481]
.crl	Список отзыва сертификатов	[RFC6481]
.mft	Манифест	[RFC6481]
.roa	Полномочия по созданию маршрутов	[RFC6481]

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

Этот документ много выиграл от полезных комментариев и предложений Stephen Kent, Matt Lepenski, Michael Elkins, Russ Housley и Sean Turner.

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

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

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

[RFC6482] Lepinski, M., Kent, S., and D. Kong, «A Profile for Route Origin Authorizations (ROAs)», RFC 6482, February 2012.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, «Manifests for the Resource Public Key Infrastructure (RPKI)», RFC 6486, February 2012.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, «A Profile for X.509 PKIX Resource Certificates», RFC 6487, February 2012.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, «Signed Object Template for the Resource Public Key Infrastructure (RPKI)», RFC 6488, February 2012.

[RSYNC] rsync web pages, <http://rsync.samba.org/>.

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

[RFC2585] Housley, R. and P. Hoffman, «Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP», RFC 2585, May 1999.

[RFC3779] Lynn, C., Kent, S., and K. Seo, «X.509 Extensions for IP Addresses and AS Identifiers», RFC 3779, June 2004.

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

[RFC4387] Gutmann, P., Ed., «Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP», RFC 4387, February 2006.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC5781] Weiler, S., Ward, D., and R. Housley, «The rsync URI Scheme», RFC 5781, February 2010.

[RFC6480] Lepinski, M. and S. Kent, «An Infrastructure to Support Secure Internet Routing», RFC 6480, February 2012.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, «Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)», BCP 174, RFC 6489, February 2012.

[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, «Resource Public Key Infrastructure (RPKI) Trust Anchor Locator», RFC 6490, February 2012.

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

Geoff Huston

APNIC

EMail: gih@apnic.net

URI: http://www.apnic.net

Robert Loomans

APNIC

EMail: robertl@apnic.net

URI: http://www.apnic.net

George Michaelson

APNIC

EMail: ggm@apnic.net

URI: http://www.apnic.net

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

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

nmalykh@gmail.com

1Resource Public Key Infrastructure.

2Certificate Revocation List — список отзыва сертификатов.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Relying party.

6Subject Information Access — доступ к информации субъекта.

7Certification Authority — агентство по сертификации.

8Authority Information Access — доступ к информации УЦ (агентства).

9CRL Distribution Points — тоски распространения CRL.

10End-entity.

11Отмечено, что при отсутствии такого режима доступа RP могут быть показаны промежуточные состояния, в которых содержимое репозитория не отражено точно в манифесте. Конкретные случая такого рассогласования и действия в таких ситуациях рассмотрены в [RFC6486].

12Route Origination Authorization — полномочия по созданию маршрута.

13Man-in-the-middle — атака по пути передачи с участием человека.

Рубрика: RFC | Комментарии отключены

RFC 6480 An Infrastructure to Support Secure Internet Routing

Опубликовано 06.02.2012 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                       M. Lepinski
Request for Comments: 6480                                       S. Kent
Category: Informational                                 BBN Technologies
ISSN: 2070-1721                                            February 2012

Инфраструктура для поддержки защищенной маршрутизации в Internet

An Infrastructure to Support Secure Internet Routing

PDF

Аннотация

Этот документ описывает архитектуру системы для поддержки улучшенной защиты маршрутизации в сети Internet. Основой этой архитектуры является инфраструктура открытых ключей ресурсов (RPKI¹), которая представляет иерархию выделения адресов IP и номеров автономных систем (AS²), а также распределенную систему репозиториев для хранения и распространения объектов данных, составляющих RPKI, а также других подписанных объектов, требуемых для повышения безопасности маршрутизации. В качестве первого применения этой архитектуры данный документ описывает, как законный владелец адресного пространства IP может явно и проверяемо уполномочить одну или множество AS порождать маршруты в его адресное пространство. Такие проверяемые полномочия могут использоваться, например, для более защищенных маршрутных фильтров BGP.

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

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

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

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

1. Введение

Этот документ описывает архитектуру системы для поддержки улучшенной защиты маршрутизации BGP [RFC4271] в сети Internet. Архитектура включает три основных элемента:

инфраструктура открытых ключей ресурсов (RPKI⁵);
подписанные объекты маршрутизации для поддержки защиты маршрутизации;
распределенная система репозиториев для хранения объектов PKI и подписанных объектов маршрутизации.

Описанная в этом документе архитектура позволяет объекту достоверно заявлять свое законное владение множеством адресов IP или номеров AS. В качестве начального применения этой архитектуры документ описывает как законный владелец адресного пространства IP может явно и достоверно предоставить одной или множеству AS полномочия на создание (originate) маршрутов в это адресное пространство. Такая проверяемая передача полномочий может применяться, например, для создания более защищенных фильтров маршрутов BGP. В дополнение к такому применению определенная этой архитектурой инфраструктура также предназначена для обеспечения в будущем поддержки защищенных протоколов типа Secure BGP [S-BGP] или Secure Origin BGP [soBGP]. Эта архитектура применима для маршрутизации дейтаграмм как IPv4, так и IPv6. В настоящее время архитектура поддерживает только адреса семейств IPv4 и IPv6. Таким образом, например, использование этой архитектуры с метками MPLS выходит за рамки этого документа.

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

Для упрощения реализации везде, где было возможно, использованы существующие стандарты IETF — например, широко используется профиль сертификатов X.509, определенный для инфраструктуры открытых ключей с использованием X.509 (PKIX⁶) [RFC5280] и расширения для представления адресов IP и номеров AS, определенные в RFC 3779 [RFC3779]. Используется также синтаксис криптографических сообщений (CMS⁷) [RFC5652] для вновь определенных подписанных объектов [RFC6488], требуемых этой инфраструктурой.

Как отмечено выше, архитектура включает три основных компоненты — X.509 PKI, в которой сертификатами аттестуются владение адресами IP и номерами AS; подписанные объекты, которые не являются сертификатами (включая манифесты и полномочия по созданию маршрутов) и используются инфраструктурой; распределенная система репозиториев, которая делает все эти подписанные объекты доступными для использования ISP в процессах принятия решений о маршрутизации. Эти три базовых компоненты обеспечивают некоторые функции защиты, наиболее заметной из которых является криптографическая проверка полномочий автономной системы на порождение маршрутов для данного префикса [RFC6483].

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

В этом документе слова «держатель адресного пространства» (address space holder) и «держатель адресного пространства IP» (holder of IP address space) указывают законного владельца адресного блока IP, который получил эти адреса через стандартную иерархию распределения IP-адресов. Т. е. владелец (держатель) адресного пространства получил этот блок адресов непосредственно от IANA или регионального регистратора (RIR⁸) или путем вторичного распределения от национального (NIR⁹) или местного (LIR¹⁰) регистратора. Слова «держатель (владелец) ресурса» обозначают законного владельца ресурса адресов IP или номеров AS.

В этом документе термины «регистратор» (registry) и ISP указывают организацию, которая имеет ресурсы адресов IP и/или номеров AS для последующего распределения (sub-allocate).

2. Инфраструктура открытых ключей для INR

Поскольку держатель блока адресов IP имеет право определять топологическое назначение (цель) дейтаграмм IP, адресованных в этот блок, решения о междоменной маршрутизации традиционно основываются на информации о распределении адресного пространства IP. Таким образом, базовая функция этой архитектуры заключается в обеспечении криптографически проверяемой аттестации выделения адресов. В современной практике распределение адресов IP происходит по иерархической модели. Вершиной иерархии является агентство IANA. Ниже IANA размещается 5 региональных регистраторов (RIR), каждый из которых управляет распределением адресов и номеров AS в своем географическом регионе. В некоторых регионах имеется третий уровень иерархии, включающий национальных (NIR) и местных (LIR¹¹) регистраторов, а также абонентов с так называемыми «провайдеро-независимыми» (переносимыми) блоками адресов. В остальных регионах третий уровень состоит только из LIR/ISP и абонентов с переносимыми блоками.

В общем случае владелец блока адресов IP может выделять части этого блока для себя (т. е. отдельного подразделения в рамках одной организации) или другой организации в зависимости от контрактных ограничений, задаваемых регистраторами. В результате этого распределение адресного пространства IP можно естественным образом описать с помощью иерархической инфраструктуры открытых ключей, в которой каждый сертификат удостоверяет выделение адресов IP, а выпуск подчиненных (subordinate) сертификатов соответствует выделению фрагментов этого блока адресов IP. Сказанное выше относится и к распределению номеров AS, но правом «вторичного» выделения номеров AS наделены только RIR и NIR. Таким образом, распределение адресов IP и номеров AS можно выразить в рамках одной инфраструктуры PKI. Эта PKI, которую в дальнейшем будем называть инфраструктурой открытых ключей ресурсов (RPKI), является центральной компонентой этой архитектуры.

2.1. Роль в архитектуре

Сертификаты в PKI называют сертификатами ресурсов и они соответствуют профилю, заданному в [RFC6487]. Сертификаты ресурсов удостоверяют выделение субъекту адресов IP или номеров AS эмитентом (сертификата). Это нужно для привязки открытого ключа в сертификате ресурса к адресам IP или номерам AS, включенным в расширения сертификата IP Address Delegation или AS Identifier Delegation, как указано в RFC 3779 [RFC3779].

Важной особенностью этой PKI является то, что сертификаты не удостоверяют отождествление субъекта. Следовательно, имена субъектов в сертификатах не обязаны быть описательными. Т. е. PKI ресурсов предназначена для проверки полномочий, а не подлинности субъекта. Этим она отличается от большинства других PKI, где эмитент гарантирует, что описательное имя субъекта сертификата надежно связано с объектом, который владеет секретным ключом, соответствующим открытому ключу в сертификате. Поскольку от эмитентов не требуется проверка права объекта на использование указанного в сертификате имени субъекта, это позволяет устранить связанные с такой проверкой издержки и ответственность. В результате исполнение функций органа сертификации (CA¹²) существенно упрощается.

Большинство сертификатов этой PKI подтверждают базовые факты, на основе которых работает остальная инфраструктура. Сертификаты CA в PKI удостоверяют обладание адресными блоками IP и номерами AS. Сертификаты конечных элементов (EE¹³) выпускаются CA владельца ресурса для передачи полномочий, подтверждаемых этими сертификатами. Основным назначением сертификатов EE является проверка пригодности полномочий генерации маршрутов (ROA¹⁴), подписанных объектов, которые явно подтверждают передачу владельцем ресурса прав генерации маршрутов в указанный блок адресов данной AS (см. раздел 3). Сертификаты конечных элементов используются также для проверки других подписанных объектов типа манифестов, которые будут использоваться для обеспечения целостности системы репозиториев (см. раздел 5).

2.2. Сертификаты CA

Любой держатель ресурса, имеющий полномочия дальнейшего распределения этого ресурса, должен иметь возможность выпускать сертификаты ресурсов в соответствии с выделением. Например, сертификаты CA будут связаны с IANA и каждым из регистраторов RIR, NIR и LIR/ISP. Сертификат CA требуется также для обеспечения держателю ресурса возможности выпуска ROA, поскольку он должен выпустить соответствующий сертификат конечного элемента для проверки пригодности каждого ROA. Таким образом, некоторые объекты, которые не распределяют свои ресурсы между другими объектами, также должны иметь сертификаты CA для своих ресурсов (например, абоненту с несколькими подключениями и провайдеро-независимым блоком адресов потребуется сертификат для выпуска ROA). Абонентам с одним подключением и адресами от LIR/ISP, если они не переходят к другому LIR/ISP, не потребуется участие в PKI. Абонентам с несколькими подключениями и адресами от LIR/ISP в некоторых случаях может потребоваться участие в PKI (см. параграф 7.3.2).

В отличие от большинства других PKI, здесь отличительные имена субъектов в сертификатах CA выбираются эмитентом сертификата. Отличительные имена субъектов не пытаются описать эти субъекты. Отличительное имя субъекта должно включать атрибут CommonName и может дополнительно включать атрибут serial.

В этой PKI эмитенты сертификатов, являясь регистраторами RIR, NIR или LIR/ISP, не занимаются проверкой юридических прав субъекта на заявленное им отождествление. Следовательно, выбор отличительного имени, не пытающегося описать этот субъект, минимизирует возможности субъектов злоупотреблять сертификатами для отождествления себя и минимизирует юридическую ответственность эмитентов. Поскольку все сертификаты CA выпускаются для субъектов, с которыми эмитент имеет реальное взаимодействие, эмитентам рекомендуется выбирать для субъектов имена, которые позволят связать сертификат с имеющимися в его базе данных записями для этого субъекта. Например, регистратор может использовать ключи своей базы данных или идентификаторы абонентов в качестве атрибута CommonName выпускаемых для субъекта сертификатов.

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

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

2.3. Сертификаты конечных элементов (EE)

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

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

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

Сертификат EE, используемый для проверки подписанного объекта инкапсулируется CMS¹⁵ (см. [RFC6488]) подписанного объекта. Следовательно, не требуется передавать сертификат EE отдельно от подписанного объекта. Подобно этому, не требуется присутствия сертификата EE в системе репозиториев RPKI иначе, чем в виде части соответствующего подписанного объекта.

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

2.4. Доверенные привязки

В любой PKI каждая зависимая от нее сторона (RP¹⁶) выбирает свой комплект доверенных привязок (TA¹⁷). Это общее свойство систем PKI применимо и здесь. Имеется иерархия выделения адресов IP и номеров AS и, таким образом IANA и,или пять регистраторов RIR являются очевидными кандидатами на роль TA. Тем не менее, каждый RP самостоятельно выбирает для себя множество доверенных привязок, которые будут применяться для проверки пригодности сертификатов.

Например, RP (пусть это будет LIR/ISP) может создать доверенную привязку применительно ко всему адресному пространству и/или всем номерам AS, для которой RP имеет соответствующий секретный ключ. После этого RP может выпускать сертификаты с этой доверенной привязкой для любого желаемого объекта в PKI и это приведет к тому, что все пути сертификации, завершающиеся в этой заданной локально привязке, будут соответствовать требованиям по проверке пригодности, указанным в RFC 3779. Крупным ISP, которые используют блоки приватных адресов IP (см. RFC 1918) и применяют внутри себя протокол BGP, потребуется создать такой тип доверенной привязки чтобы организовать CA, которому выделено все пространство приватных адресов. После этого RP может в рамках этого CA выпускать сертификаты, которые будут соответствовать внутреннему использованию приватных адресов.

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

Предполагается, что некоторые элементы существующей иерархии распределения адресов IP и номеров AS могут опубликовать материал о доверенных привязках для использования от инфраструктуры зависимыми сторонами (RP). Стандартный профиль для публикации такого материала можно найти в [RFC6490].

3. Полномочия на создание маршрутов

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

3.1. Роль в архитектуре

ROA подтверждают факт передачи владельцем префиксов полномочий по созданию маршрутов к этим префиксам автономной системе. Структура ROA соответствует формату, описанному в [RFC6482]. Действительность полномочий зависит от того, является ли подписавшая ROA сторона держателем префикса в ROA, — это удостоверяется сертификатом конечного элемента из PKI, чей секретный ключ соответствует использованному для подписи ROA.

ROA могут использоваться зависимыми сторонами для проверки того, что AS, создавшая маршрут для данного префикса IP, имеет полномочия от владельца данного префикса. Например, ISP может использовать действительные ROA в качестве входных данных при создании маршрутных фильтров для своих маршрутизаторов BGP (см. [RFC6483], где описано использование ROA в целях проверки полномочий на создание маршрутов BGP).

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

3.2. Синтаксис и семантика

ROA представляет собой явное разрешение для одной AS создавать маршруты к одному или множеству префиксов и подписывается владельцем этих префиксов. Концептуально ROA состоит из двух частей — общего шаблона CMS, одинакового для всех подписанных объектов RPKI [RFC6488] и инкапсулированного содержимого ROA, которое указывает наличие полномочий [RFC6482].

На высоком уровне ROA содержит (1) номер AS и (2) список адресных префиксов IP, дополнительно может включаться (3) максимальный размер наиболее конкретных префиксов, которые AS имеет право анонсировать для каждого префикса (этот элемент упрощает компактную передачу полномочий на анонсирования, например, любых префиксов длиной от 20 до 24 битов, содержащихся внутри данного 20-битового префикса).

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

ROA подписывается с использованием секретного ключа, соответствующего открытому ключу в сертификате конечного элемента (EE) в инфраструктуре PKI. Для того, чтобы ROA была пригодна, соответствующий ей сертификат конечного элемента должен быть действительным и префиксы адресов IP в ROA должны совпадать с префиксами адресов IP, указанными в расширении (RFC 3779) сертификата EE. Следовательно, срок действия ROA неявно определяется сроком действия соответствующего сертификата. ROA отзываются путем отзыва соответствующих сертификатов EE. Отдельного метода отзыва ROA не задается. Можно подумать, что такая модель отзыва будет приводить к увеличению размера списков CRL для сертификации CA, подписывающих сертификаты EE. Однако маршрутные анонсы в публичной сети Internet используются достаточно долго. Следовательно, поскольку сертификаты EE служащие для проверки ROA действительны несколько месяцев, вероятность отзыва множества ROA в течение этого срока достаточно мала.

   ---------                ---------
   |  RIR  |                |  NIR  |
   |  CA   |                |  CA   |
   ---------                ---------
       |                        |
       |                        |
       |                        |
   ---------                ---------
   |  ISP  |                |  ISP  |
   |  CA 1 |                |  CA 2 |
   ---------                ---------
       |     \                      |
       |      -----                 |
       |           \                |
----------    ----------      ----------
|  ISP   |    |  ISP   |      |  ISP   |
|  EE 1a |    |  EE 1b |      |  EE 2  |
----------    ----------      ----------
    |             |               |
    |             |               |
    |             |               |
----------    ----------      ----------
| ROA 1a |    | ROA 1b |      | ROA 2  |
----------    ----------      ----------

Рисунок 1. ISP, получающий ресурсы от RIR и NIR (требуется два сертификата CA в соответствии с RFC 3779)

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

4. Репозитории

Изначально LIR/ISP будут использовать ресурсы PKI путем получения и проверки каждого разрешения ROA для создания таблицы префиксов, к которым AS уполномочена создавать маршруты. Для проверки пригодности ROA провайдерам (LIR/ISP) потребуется получить все сертификаты и CRL. Основной функцией системы распределенных репозиториев, описанной здесь, является хранение этих подписанных объектов и обеспечение их доступности для загрузки LIR/ISP. Отметим, что эта система репозиториев обеспечивает механизм, с помощью которого зависимые стороны могут получать свежие данные с удобной для себя частотой обновления. Однако не обеспечивается механизмов «выталкивания» свежих данных зависимым сторонам (например, путем включения объектов PKI в сообщения BGP или других протоколов) и такие механизмы выходят за рамки настоящего документа.

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

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

4.1. Роль в архитектуре

Система репозиториев является недоверенным «клиринговым центром» для всех подписанных объектов, которые должны быть доступны зависимым сторонам в глобальном масштабе. При создании сертификатов и CRL они размещаются (выгружаются) в этом репозитории, а потом загружаются зависимыми сторонами (в основном LIR/ISP) для использования. ROA и манифесты являются примерами дополнительных объектов в репозитории, а в будущем архитектура может быть дополнена другими элементами. В этом документе кратко описаны способы поддержки подписанных объектов (сертификаты, CRL, ROA и манифесты) в репозитории. По мере добавления в систему репозиториев новых подписанных элементов это описание потребует внесения изменений, но предполагается, что основные принципы устройства сохранятся неизменными. Полное описание системы репозиториев дано в [RFC6481].

4.2. Содержимое и структура

Хотя репозиторий представляет собой единую систему, к которой обращаются зависимые стороны, в реальности эта система состоит из множества баз данных. Эти базы распределены между регистраторами (RIR, NIR, LIR/ISP). По минимуму база данных, поддерживаемая каждым из регистраторов, будет включать все сертификаты CA и EE, списки CRL и манифесты, подписанные CA, которые связаны с этим регистратором. Репозитории LIR/ISP будут включать также ROA. Регистраторам также настоятельно рекомендуется хранить копии данных из репозиториев их клиентов и клиентов этих клиентов (и . д.) для облегчения доступа зависимых сторон ко всему содержимому репозитория. В идеальном случае каждый RIR будет держать у себя данные PKI от всех элементов своего географического региона.

Для каждого сертификата в PKI в файловой системе репозитория будет присутствовать каталог, служащий полномочной точкой публикации для всех объектов (сертификаты, CRL, ROA и манифесты), проверяемых с помощью этого сертификата. Расширение сертификата SIA¹⁸ [RFC5280] содержит идентификатор URI, указывающий этот каталог. Кроме того, расширение сертификата AIA¹⁹ [RFC5280] содержит URI со ссылкой на полномочное место публикации сертификата CA, который применялся для выпуска данного сертификата. Т. е. если сертификат A служит для проверки сертификата B, расширение AIA в сертификате B указывает на сертификат A, а расширение SIA в сертификате A указывает каталог с сертификатом B (см. Рисунок 2).

           +--------+
+--------->| Cert A |<----+
|          | CRLDP  |     |
|          |  AIA   |     |
|  +--------- SIA   |     |
|  |       +--------+     |
|  |                      |
|  |                      |
|  |                      |
|  |  +-------------------|------------------+
|  |  |                   |                  |
|  +->|   +--------+      |   +--------+     |
|     |   | Cert B |      |   | Cert C |     |
|     |   | CRLDP ----+   |   | CRLDP -+-+   |
+----------- AIA   |  |   +----- AIA   | |   |
      |   |  SIA   |  |       |  SIA   | |   |
      |   +--------+  |       +--------+ |   |
      |               V                  |   |
      |           +---------+            |   |
      |           | CRL от A|<-----------+   |
      |           +---------+                |
      |   Каталог публикации репозитория A   |
      +--------------------------------------+

Рисунок 2. Использование расширений SIA и AIA в RPKI.

На рисунке 2 сертификаты B и C выпущены CA A. Следовательно, расширения AIA в сертификатах B и C указывают на (сертификат) A, а расширение SIA в A указывает на точку публикации подчиненной продукции CA A, включающую сертификаты B и C, а также CRL, выпущенные A. Расширение CRLDP²⁰ в сертификатах B и C указывает на CRL, выпущенные A.

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

4.3. Протоколы доступа

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

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

Выгрузка, обновление, удаление (upload/change/delete). Протоколы доступа должны также поддерживать для издателей сертификатов, CRL и других подписанных объектов возможность добавления и удаления таких объектов. Должны обеспечиваться также механизмы изменения объектов в репозитории. Все протоколы доступа, позволяющие вносить изменения в репозиторий (путем добавления, удаления или изменения его содержимого), должны поддерживать проверку полномочий вносящей изменения стороны и использованием подходящего контроля доступа (см. параграф 4.4).

Для обеспечения всем зависимым сторонам возможности получать все подписанные объекты RPKI все точки публикации должны быть доступны по протоколу rsync (см. [RFC5781] и [RSYNC]), хотя могут применяться и другие протоколы загрузки. Точки публикации репозитория могут обеспечивать функциональность добавления, удаления и изменения объектов с помощью желаемого набора протоколов доступа, при условии того, что все такие протоколы подходят для коммуникаций всем сертификационным органам, содержащим данные в этой точке публикации.

4.4. Управление доступом

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

5. Манифесты

Манифест представляет собой подписанный объект со списком всех подписанных объектов (кроме самого манифеста), выпущенных органом, ответственным за публикацию в системе репозитория. Для каждого действующего сертификата, CRL или ROA, выпущенного агентством, манифест содержит имя файла с объектом и хэш содержимого этого файла.

Ка и ROA, манифест подписывается с помощью секретного ключа, парный открытый ключ которого указан в сертификате конечного элемента. Этот сертификат EE, в свою очередь, подписывается соответствующим CA. Поскольку секретный ключ в сертификате EE используется для подписи единственного манифеста, этот манифест можно отозвать путем отзыва сертификата EE. В таких случаях для предотвращения неоправданного роста CRL срок действия сертификата EE, используемого для проверки манифеста, следует делать таким же как у самого манифеста.

Манифесты могут применяться зависимыми сторонами при создании локального кэша (см. раздел 6) для снижения риска атак с удалением файлов из репозитория или подменой подписанных объектов. Такая защита нужна, поскольку система репозитория не является доверенной, несмотря на подписи во всех объектах.

5.1. Синтаксис и семантика

Манифест содержит список всех файлов (и хэш-значений их содержимого) в точке публикации репозитория на конкретный момент. Подробная спецификация содержимого манифеста приведена в [RFC6486], кратко же можно сказать, что манифест включает (1) порядковый номер, (2) время выпуска, (3) время планового выпуска следующего манифеста, (4) список имен файлов и хэш-значений их содержимого.

Номер манифеста является числом, которое увеличивается при выпуска каждого нового манифеста. Агентству требуется выпускать новый манифест по факту изменения содержимого репозитория или наступления заданного момента обновления манифеста. Таким образом, манифест действует до наступления указанного в нем срока обновления или до появления манифеста с большим порядковым номером (до первого из событий). Отметим, что сертификат EE используется для подписи лишь одного манифеста и при выпуске нового манифеста CA должен также выпустить новый CRL с включением сертификата EE, соответствующего старому манифесту. Отозванный сертификат EE для старого манифеста будет удален из CRL по истечении срока его действия и списки CRL сильно расти не будут.

6. Поддержка локального кэша

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

Запросить в системе репозиториев копии всех сертификатов, манифестов и CRL, выпущенных в PKI.
Для каждого сертификата CA в PKI проверить подпись соответствующего манифеста. Дополнительно убедиться, что текущее время меньше значения, указанного в поле nextUpdate манифеста.
Для каждого манифеста проверить, что сертификаты и CRL, выпущенные с помощью соответствующего сертификата CA, соответствуют хэш-значениям в манифесте. Убедиться в том, что манифест не содержит отсутствующих в репозитории сертификатов и манифестов. При несоответствии хэш-значений или отсутствии какого-либо сертификата или CRL следует уведомить администратора репозитория о повреждении данных.
Проверить пригодность каждого сертификата EE путем построения и проверки пути сертификации (включая проверку относящихся к нему CRL) до заданных в локальной конфигурации TA (см. [RFC6487]).

Поскольку зависимые стороны будут проводить эти проверки регулярно, эффективней для них будет запрашивать из репозитория лишь объекты, изменившиеся с момента последнего обновления локального кэша зависимой стороны.

Отметим также, что проверка соответствия манифесту всех выпущенных объектов позволяет зависимой стороне быть уверенной в том, что не были пропущены обновления каких-либо объектов.

7. Основные операции

Создание и поддержка описанной выше инфраструктуры потребует дополнительных «побочных» операций при нормальном распределении ресурсов и процедур проверки полномочий маршрутизации. Например, абонент с провайдеро-независимыми (переносимыми) адресами, организующий взаимодействие с ISP, должен будет выпустить одно или множество разрешений ROA, указывающих данного провайдера (ISP), в дополнение к обычным техническим и административным процедурам. Основным современным применением этой инфраструктуры является создание маршрутных фильтров — используя ROA, можно создавать фильтры маршрутов автоматически и с гарантией того, что держатель анонсируемого префикса уполномочил создающую маршруты AS на анонсирование этих маршрутов.

7.1. Издание сертификатов

Выпуск сертификатов требуется в нескольких ситуациях. Для любого выделения, которое может быть разделено по субстратам , требуется сертификат CA — например, для того, чтобы выпускать сертификаты при возникновении необходимости выделения очередного субстрата. Владельцы провайдеро-независимых адресов IP тоже должны иметь сертификаты, чтобы иметь возможность выпуска ROA для каждого ISP, уполномоченного создавать маршрут к этим блокам адресов (поскольку адреса получены не от ISP). Кроме того, абонентам с множественными подключениями тоже нужны сертификаты, если они намерены выпускать ROA для своих адресов (см. параграф 7.3.2). Прочим держателям ресурсов не требуются сертификаты CA в рамках PKI.

В конечном итоге владелец ресурса не будет запрашивать сертификаты ресурса, а получит их в качестве «побочного» эффекта при выделении ресурса. Однако при начальном развертывании RPKI потребуется явный выпуск множества сертификатов для выделенных ранее ресурсов. Отметим, что во всех случаях органом, выпускающим сертификат CA, будет тот, кто выделил ресурс. Это отличается от других PKI, где субъект может запросить сертификат в любом CA.

Если владелец ресурса с течением времени получает множество распределений, он может увеличить набор сертификатов для подтверждения этих ресурсов. Если держатель ресурса получает множество распределений из одного источника, множество таких ресурсов может быть объединено в одном сертификате ресурса при согласии на это держателя ресурсов и эмитента. Это реализуется путем объединения множества расширений IP Address Delegation и AS Identifier Delegation в одиночные расширения (каждого типа) нового сертификата. Однако создание комбинированного сертификата для ресурсов с разными сроками действия может вызывать проблемы, поскольку в сертификате может быть только один срок действия.

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

7.2. Смена ключа CA

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

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

В [RFC6489] задана консервативная процедура смены ключей, которую центрам сертификации следует применять при замене открытого (и секретного) ключа, связанного с его сертификатом RPKI CA. Основные свойства этой процедуры указаны ниже. Во-первых, поскольку данные из подписанных объектов RPKI могут применяться в маршрутизации, процедура гарантирует, что в процессе ее выполнения ни одна из зависимых сторон не получит некорректных заключений о пригодности подписанных объектов. Отметим, в частности, что CA не может предполагать использование зависимыми сторонами какого-либо конкретного алгоритма построения пути сертификации от сертификата EE до одной из доверенных привязок. Следовательно в течение процедуры смены ключей обеспечивается максимально возможная целостность точек SIA и AIA в иерархии RPKI. Во-вторых, процедура смены ключей рассчитана так, что повторный выпуск всех сертификатов, расположенных ниже данного CA в иерархии RPKI, не требуется. Естественно, потребуется заново подписать все сертификаты, выпущенные непосредственно CA, меняющим ключи. Однако указатели SIA и AIA в сертификатах задаются так, что дальнейшего повторного выпуска сертификатов не требуется.

7.3. Управление ROA

Когда держатель адресов IP хочет передать AS полномочия на создание маршрутов к его адресам, он должен выпустить сертификат конечного элемента с нужным префиксом в расширении IP Address Delegation. Для подписи ROA с адресным префиксом и номером уполномоченной AS используется соответствующий секретный ключ. Держатель адресов может включить в сертификат EE и соответствующее разрешение ROA множество адресных префиксов. Любой держатель адресов, выпускающий ROA для префикса должен иметь сертификат ресурса для включающего этот префикс распределения. Стандартная процедура выпуска ROA описана ниже.

Создается сертификат конечного элемента с префиксом (префиксами) для которого ROA дает полномочия.
Создается содержимое ROA с префиксами из сертификата EE и номером AS, получающей полномочия.
ROA подписывается с использованием секретного ключа, соответствующего сертификату EE (ROA представляется содержимым, инкапсулированным в подписанное сообщение CMS [RFC5652]).
Сертификат конечного элемента и ROA выгружаются в систему репозитория.

Стандартная процедура отзыва ROA заключается в отзыве соответствующего сертификата конечного элемента путем выпуска CRL и выгрузки его в репозиторий. Отозванные ROA и сертификаты EE следует удалять из репозитория.

При отзыве ROA следует соблюдать осторожность, поскольку такой отзыв может привести к тому, что зависимые стороны сочтут маршрутные анонсы, соответствующих префиксам и номеру AS в ROA, несанкционированными (и это может привести к изменению картины маршрутизации с отказом от пересылки пакетов на основе этих анонсов). В частности, держателю ресурса следует придерживаться описанного ниже принципа «сделать до прерывания». Перед отзывом ROA для префикса, который держатель хочет маршрутизировать в Internet, важно обеспечить для этого ресурса наличие другого действительного разрешения ROA с тем же префиксом (номер AS может быть иным). Кроме того, держателю ресурса следует убедиться в том, что AS, указанная в дополнительном ROA, действительно создает маршруты к соответствующему префиксу. Зависимая от инфраструктуры сторона должна получить новые ROA из системы репозитория до принятия маршрутных решений в ответ на отзыв ROA.

7.3.1. Абоненты с одним подключением

В BGP абонентам с одним подключением и адресами от провайдера (PA²¹) не нужно явно давать разрешение на анонсы маршрутов к используемым префиксам, поскольку его ISP уже анонсирует более общий префикс и маршрутизирует трафик в сеть абонента. Поскольку для префиксов таких абонентов отдельные маршруты не анонсируются, выпуск ROA также не нужен — ISP абонента будет выпускать нужные ROA для более общих префиксов с сертификатами своих ресурсов. Таким образом «однодомный» абонент с адресами IP из блока своего провайдера просто не входит в RPKI, не получая сертификата CA и не выпуская сертификатов EE или разрешений ROA.

7.3.2. Абоненты с множеством подключений

Рассмотрим абонента с адресами PA от основного ISP (т. е., IP-адреса этого абонента являются частью адресного пространства этого ISP) и дополнительным «восходящим» соединением с одним или несколькими резервными ISP. Для таких «многодомных» абонентов предпочтительным решением является получение номера AS и использование протокола BGP для каждого из своих провайдеров. Для такой ситуации рекомендуется два способа поддержки ROA. В первом основной ISP выпускает сертификат CA для абонента и этот абонент выпускает ROA со своим номером AS и адресным префиксом IP. Во втором варианте ISP не выпускает сертификата CA для абонента, а просто от его имени выпускает ROA с номером AS и префиксом IP этого абонента.

Если абонент не может или не хочет получить номер AS и использовать BGP, он может запросить у своего основного ISP создание ROA для каждого дополнительного ISP, дающие этим ISP полномочия на создание маршрутов к блоку адресов абонента. Основной ISP также создает ROA со своим номером AS и адресным префиксом абонента. Очевидно, что в таких случаях основной ISP будет анонсировать точный префикс абонента, а не включающий его блок адресов. Отметим, что такой подход ведет к несогласованности номеров AS происхождения маршрута и адресных префиксов абонентов, что является нежелательным для публичной сети Internet и по этой причине не рекомендуется.

7.3.3. Провайдеро-независимые адреса

Провайдеро-независимыми (переносимыми) называются блоки адресов, получаемые абонентами непосредственно от RIR или NIR. Поскольку такие блоки адресов не входят в пространство какого-либо ISP, ни один из провайдеров не будет анонсировать более общий префикс. Держатель переносимого блока адресов IP должен предоставить одной или множеству AS полномочия на создание маршрутов к своим префиксам. Поэтому держатель ресурса должен создать один или множество сертификатов EE и соответствующих ROA, чтобы позволить этим AS создавать маршруты к его префиксам. Выпуск ROA требуется по причине того, что ROA провайдеров не дают полномочий на создание маршрутов в переносимый блок адресов.

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

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

Механизмы защиты, обеспечиваемые этой архитектурой, основаны на целостности и доступности описываемой инфраструктуры. Целостность объектов в инфраструктуре обеспечивается средствами контроля доступа к репозиториям, описанными в параграфе 4.4. В силу своей распределенной структуры система репозитория устойчива к атакам на отказ в обслуживании (denial-of-service), однако нужны и дополнительные меры предосторожности на базе репликации и создания резервных копий, а также физической защиты серверов с базами данных.

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

Инструкции для IANA в части RPKI приведены в [RFC6491].

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

Описанная здесь архитектура основана на идеях и работе большой группы людей. Работа была бы невозможна без интеллектуального вклада George Michaelson, Robert Loomans, Sanjaya и Geoff Huston из APNIC, Robert Kisteleki и Henk Uijterwaal из RIPE NCC, Tim Christensen и Cathy Murphy из ARIN, Rob Austein из ISC и Randy Bush из IIJ.

Авторы в долгу перед всеми, кто внес вклад в эту архитектуру, но особо хочется отметить Rob Austein за концепцию манифеста и Geoff Huston за концепцию проверки пригодности объектов на базе однократного применения ключевых пар сертификатов EE, а также Richard Barnes за помощь в подготовке предварительной версии этого документа.

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

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

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

[RFC3779] Lynn, C., Kent, S., and K. Seo, «X.509 Extensions for IP Addresses and AS Identifiers», RFC 3779, June 2004.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC5652] Housley, R., «Cryptographic Message Syntax (CMS)», STD 70, RFC 5652, September 2009.

[RFC5781] Weiler, S., Ward, D., and R. Housley, «The rsync URI Scheme», RFC 5781, February 2010.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, «A Profile for Resource Certificate Repository Structure», RFC 6481, February 2012.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, «A Profile for Route Origin Authorizations (ROAs)», RFC 6482, February 2012.

[RFC6486] Austein, R., Huston., G., Kent, S., and M. Lepinski, «Manifests for the Resource Public Key Infrastructure», RFC 6486, February 2012.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, «A Profile for X.509 PKIX Resource Certificates», RFC 6487, February 2012.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, «Signed Object Template for the Resource Public Key Infrastructure», RFC 6488, February 2012.

[RFC6491] Manderson, T., Vegoda, L., and S. Kent, «Resource Public Key Infrastructure (RPKI) Objects Issued by IANA», RFC 6491, February 2012.

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

[RFC6483] Huston, G. and G. Michaelson, «Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)», RFC 6483, February 2012.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, «Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)», BCP 174, RFC 6489, February 2012.

[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, «Resource Public Key Infrastructure (RPKI) Trust Anchor Locator», RFC 6490, February 2012.

[RSYNC] rsync web pages, <http://rsync.samba.org/>.

[S-BGP] Kent, S., Lynn, C., and Seo, K., «Secure Border Gateway Protocol (Secure-BGP)», IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000.

[soBGP] White, R., «soBGP», May 2005, <ftp://ftp-eng.cisco.com/sobgp/index.html>

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

Matt Lepinski

BBN Technologies

10 Moulton St.

Cambridge, MA 02138

EMail: mlepinski@bbn.com

Stephen Kent

BBN Technologies

10 Moulton St.

Cambridge, MA 02138

EMail: kent@bbn.com

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

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

nmalykh@gmail.com

1Resource Public Key Infrastructure.

2Autonomous System.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Resource Public Key Infrastructure.

6Public Key Infrastructure using X.509.

7Cryptographic Message Syntax.

8Regional Internet Registry.

9National Internet Registry.

10Local Internet Registry.

11Термин LIR в некоторых регионах используется для обозначения ISP. Поэтому в оставшейся части документа применяется обозначение LIR/ISP в целях упрощения.

12Certification Authority — агентство по сертификации.

13End-entity.

14Route Origination Authorization.

15Cryptographic Message Syntax — синтаксис криптографических сообщений.

16Relying party — зависимая сторона, потребитель.

17Trust anchor.

18Subject Information Access — доступ к информации о субъекте.

19Authority Information Access — доступ к информации об агентстве.

20CRL Distribution Points — точки публикации CRL.

21Provider Aggregatable — агрегируемые провайдером.

Рубрика: RFC | Комментарии отключены

RFC 6482 A Profile for Route Origin Authorizations (ROAs)

Опубликовано 04.02.2012 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                       M. Lepinski
Request for Comments: 6482                                       S. Kent
Category: Standards Track                                        D. Kong
ISSN: 2070-1721                                         BBN Technologies
                                                           February 2012

Профиль полномочий на создание маршрутов (ROA)

A Profile for Route Origin Authorizations (ROAs)

PDF

Аннотация

Этот документ определяет стандартный профиль для ROA¹. Объекты ROA имеют цифровую подпись и обеспечивают способ проверки того, что держатель адресного блока IP уполномочил автономную систему (AS²) создавать маршруты к одному или множеству префиксов из этого блока адресов.

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

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

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

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

1. Введение

Основным назначением инфраструктуры открытых ключей ресурсов (RPKI⁵) является повышение уровня защиты маршрутизации (см. [RFC6480]). Для этой системы нужен механизм, который позволит элементам проверить наличие у данной AS полномочий анонсировать маршруты для одного или нескольких префиксов и блока адресов IP. Эта функция обеспечивается с помощью ROA.

ROA использует шаблон для объектов RPKI с цифровой подписью [RFC6488], который определяет синтаксис инкапсуляции CMS⁶ [RFC5652] для содержимого ROA, а также базовую процедуру проверки пригодности для подписанных объектов RPKI. Поэтому для завершения спецификации ROA (см. раздел 4 в [RFC6488]) данный документ включает перечисленные ниже определения.

OID для идентификации подписанного объекта, каковым будет ROA (OID присутствует в поле eContentType объекта encapContentInfo, а также в качестве content-type подписанного атрибута в объекте signerInfo).
Синтаксис ASN.1 для ROA eContent (эта информация указывает AS, которое даются полномочия на создание маршрутов, а также префиксы, к которым AS может создавать маршруты). ASN.1 для ROA eContent использует правила отличительного кодирования (DER⁷) [X.690].
Для проверки пригодности ROA требуется дополнительный этап (в дополнение к этапам проверки, заданным в [RFC6488]).

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

2. ROA Content-Type

Тип содержимого (content-type) для ROA определяется как routeOriginAuthz и имеет значение 1.2.840.113549.1.9.16.1.24.

Этот идентификатор OID должен присутствовать в поле eContentType объекта encapContentInfo и в content-type подписанного атрибута объекта signerInfo (см. [RFC6488]).

3. ROA eContent

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

      RouteOriginAttestation ::= SEQUENCE {
         version [0] INTEGER DEFAULT 0,
         asID  ASID,
         ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }

      ASID ::= INTEGER

      ROAIPAddressFamily ::= SEQUENCE {
         addressFamily OCTET STRING (SIZE (2..3)),
         addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }

      ROAIPAddress ::= SEQUENCE {
         address IPAddress,
         maxLength INTEGER OPTIONAL }

      IPAddress ::= BIT STRING

Отметим, что это содержимое появляется поле eContent объекта encapContentInfo (см. [RFC6488]).

3.1. version

Номер версии в поле version для RouteOriginAttestation должен иметь значение 0.

3.2. asID

Поле asID содержит номер AS, которой предоставлены полномочия создавать маршруты для данных префиксов IP.

3.3. ipAddrBlocks

Поле ipAddrBlocks представляет набор адресных префиксов IP, для которых AS уполномочена создавать маршруты. Отметим, что для этого поля используется более строгий синтаксис по сравнению с расширением передачи полномочий на адреса IP, определенным в RFC 3779. Указанное расширение позволяет представлять произвольные диапазоны адресов, а в ROA могут указываться только префиксы.

В структуре ROAIPAddressFamily поле addressFamily содержит идентификатор семейства адресов (AFI⁸) адресного семейства IP. Данная спецификация поддерживает адреса IPv4 и IPv6. Следовательно, поле addressFamily должно иметь значение 0001 или 0002.

В структуре ROAIPAddress поле addresses представляет префиксы в форме последовательности типа IPAddress (см. [RFC3779]). При наличии поля maxLength оно должно содержать целое число, значение которого не меньше размера сопровождающего префикса и не больше (в битах) размера адреса IP для данного семейства (32 для IPv4 и 128 для IPv6). При наличии поля maxLength оно задает максимальный размер адресного префикса IP, который разрешено анонсировать AS (например, если задан префикс IP 203.0.113/24 и maxLength = 26, AS уполномочена анонсировать любой более конкретный префикс, размер которого не превышает 26, т. е. AS может анонсировать префиксы 203.0.113/24, 203.0.113.128/25 или 203.0.113.0/25, но не 203.0.113.0/27). Если поле maxLength не задано, AS может анонсировать только точный префикс, заданный ROA.

Отметим, что действительное разрешение ROA может содержать адресный префикс IP (в элементе ROAIPAddress), охватываемый другим адресным префиксом IP (в отдельном элементе ROAIPAddress). Например, ROA может содержать префикс 203.0.113/24 с maxLength = 26, а также префикс 203.0.113.0/28 с maxLength = 28 (ROA будет разрешать указанной AS анонсировать любой префикс, начинающийся с 203.0.113 и имеющим минимальный размер 24, а максимальный — 26, а также префикс 203.0.113.0/28). Кроме того ROA может содержать два элемента ROAIPAddress с одинаковыми префиксами IP. Однако это не рекомендуется, поскольку в таком случае ROAIPAddress с меньшим maxLength не будет давать указанной AS дополнительных прав и может быть опущена без изменения смысла ROA.

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

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

Убедиться в наличии расширения IP Address Delegation [RFC3779] в сертификате конечного элемента (EE⁹), содержащемся в ROA, а также проверить вхождение всех адресных префиксов IP, содержащихся в ROA, в набор адресов IP, заданных расширением IP Address Delegation в сертификате EE.

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

Не принимается каких-либо допущений о конфиденциальности данных в ROA и предполагается, что ROAs будут храниться в репозиториях, доступных всем ISP и, возможно, всем пользователям Internet. С ROA не связано явной проверки подлинности, поскольку PKI, используемая для проверки пригодности ROA, обеспечивает проверку полномочий, но не подлинности. Хотя для ROA представляют собой подписанные объекты прикладного уровня, они не предназначены для передачи информации, от которой невозможно отказаться.

Целью ROA является передача полномочий AS на создание маршрутов к указанным в ROA префиксам. Поэтому должна обеспечиваться целостность ROA. Спецификация ROA использует формат подписанных объектов RPKI, поэтому все вопросы безопасности,, рассмотренные в [RFC6488], применимы и для ROA. Кроме того, профиль подписанного объекта использует формат подписанных сообщений CMS для обеспечения целостности, поэтому ROA наследуют все аспекты защиты, связанные с этой структурой данных.

Право подписавшей ROA стороны предоставлять AS полномочия создания маршрутов к адресным префиксам подтверждается с помощью инфраструктуры открытых ключей для адресов IP и номеров AS, описанной в [RFC6480]. В частности, подписи ROA должны проверяться с использованием сертификатов X.509, выпущенный в рамках этой PKI, а также должно проверяться соответствие адресных префиксов из ROA адресам, указанным в расширении сертификата.

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

Агентство IANA зарегистрировало показанный ниже подписанный объект (RPKI Signed Object).

   ROA    1.2.840.113549.1.9.16.1.24    [RFC6482]

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

Авторы благодарят Charles Gardiner и Russ Housley за помощь и вклад в работу. В дополнение к этому авторы выражают благодарность Rob Austein, Roque Gagliano, Danny McPherson и Sam Weiler за внимательное рецензирование и полезные комментарии.

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

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

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

[RFC5652] Housley, R., «Cryptographic Message Syntax (CMS)», STD 70, RFC 5652, September 2009.

[RFC3779] Lynn, C., Kent, S., and K. Seo, «X.509 Extensions for IP Addresses and AS Identifiers», RFC 3779, June 2004.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, «A Profile for X.509 PKIX Resource Certificates», RFC 6487, February 2012.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, «Signed Object Template for the Resource Public Key Infrastructure (RPKI)», RFC 6488, February 2012.

[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

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

[RFC6480] Lepinski, M. and S. Kent, «An Infrastructure to Support Secure Internet Routing», RFC 6480, February 2012.

Приложение A. Модуль ASN.1

Это нормативное приложение содержит модуль ASN.1, задающий содержимое ROA в синтаксисе ASN.1.

   RPKI-ROA { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs9(9) smime(16) mod(0) 61 }

   DEFINITIONS EXPLICIT TAGS ::= BEGIN

   RouteOriginAttestation ::= SEQUENCE {
      version [0] INTEGER DEFAULT 0,
      asID  ASID,
      ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }

   ASID ::= INTEGER

   ROAIPAddressFamily ::= SEQUENCE {
      addressFamily OCTET STRING (SIZE (2..3)),
      addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }

   ROAIPAddress ::= SEQUENCE {
      address IPAddress,
      maxLength INTEGER OPTIONAL }

   IPAddress ::= BIT STRING

   END

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

Matt Lepinski

BBN Technologies

10 Moulton Street

Cambridge MA 02138

EMail: mlepinski@bbn.com

Stephen Kent

BBN Technologies

10 Moulton Street

Cambridge MA 02138

EMail: skent@bbn.com

Derrick Kong

BBN Technologies

10 Moulton Street

Cambridge MA 02138

EMail: dkong@bbn.com

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

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

nmalykh@gmail.com

1Route Origin Authorization — полномочия создания маршрутов.

2Autonomous System.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Resource Public Key Infrastructure.

6Crytopgraphic Message Syntax — синтаксис криптографических сообщений.

7Distinguished Encoding Rules.

8Address Family Identifier.

9End-entity.

Рубрика: RFC | Комментарии отключены

Файловая система sysfs для экспорта объектов ядра

Опубликовано 16.08.2011 автором Nikolai Malykh

PDF

Patrick Mochel <mochel@osdl.org>

Mike Murphy <mamurph@cs.clemson.edu>

Обновление: 16 августа 2011

Оригинал: 10 января 2003

Что это такое

Файловая система sysfs создается в ОЗУ компьютера и реализована исходно на базе ramfs. Она обеспечивает возможность экспорта структур данных ядра, их атрибутов и связей между объектами в пользовательское пространство. Файловая система sysfs непосредственно связана с инфраструктурой kobject (см. документ Documentation/kobject.txt).

Использование sysfs

Поддержка sysfs определяется опцией CONFIG_SYSFS при сборке ядра. Для доступа к файловой системе используется команда mount -t sysfs sysfs /sys

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

Для каждого регистрируемого у системе объекта kobject создается каталог в файловой системе sysfs. Этот каталог создается, как субкаталог родительского объекта kobject, что дает в результате представление иерархии объектов для пользовательского пространства. Каталоги верхнего уровня в sysfs представляют «корни» иерархии объектов.

В sysfs сохраняется указатель на объект kobject, который реализует каталог в объекте sysfs_dirent, связанном с каталогом. В прошлом указатель на этот объект kobject использовался sysfs для прямого учета открытия и закрытия файлов kobject. В современных реализациях sysfs implementation счетчик ссылок kobject изменяется только непосредственно функцией sysfs_schedule_callback().

Атрибуты

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

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

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

Определение атрибута весьма просто:

struct attribute {
	char * name;
	struct module *owner;
	umode_t mode;
};

int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);

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

Например, модель драйвера определяет структуры device_attribute вида:

struct device_attribute {
	struct attribute	attr;
	ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
	ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
};

int device_create_file(struct device *, const struct device_attribute *);
void device_remove_file(struct device *, const struct device_attribute *);

Эта же модель определяет функцию для работы с атрибутами:

#define DEVICE_ATTR(_name, _mode, _show, _store) \
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)

Например, декларирование

static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);

эквивалентно выполнению операции

static struct device_attribute dev_attr_foo = {
	.attr	= {	
		.name = "foo",	
		.mode = S_IWUSR | S_IRUGO,
		.show = show_foo,
		.store = store_foo,
	},
};

Специфические для подсистемы вызовы (Callback)

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

struct sysfs_ops {
	ssize_t (*show)(struct kobject *, struct attribute *, char *);
	ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
};

[подсистемам следует иметь уже определенную в качестве деструктора для данного типа структуру kobj_type, в которой хранится указатель sysfs_ops; см. документацию kobject]

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

#define to_dev(obj) container_of(obj, struct device, kobj)
#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr, har *buf) {
		struct device_attribute *dev_attr = to_dev_attr(attr);
		struct device *dev = to_dev(kobj);		
		ssize_t ret = -EIO;

		if (dev_attr->show)		
			ret = dev_attr->show(dev, dev_attr, buf);
		if (ret >= (ssize_t)PAGE_SIZE) {
			print_symbol("dev_attr_show: %s returned bad count\n",	(unsigned long)dev_attr->show);
		}
		return ret;
}

Чтение и запись атрибутов

Для чтения и записи атрибутов при их декларировании должны задаваться методы show() и store(). Методы следует делать достаточно простыми:

ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
	const char *buf, size_t count);

Иными словами, методам следует принимать в качестве параметров лишь объект, атрибут и буфер.

Sysfs выделяет буфер размера (PAGE_SIZE) и передает его методу. Sysfs будет вызывать соответствующий метод один раз при каждой операции чтения или записи. Это требует от реализации метода следующего поведения:

При операции read методу show() следует заполнять буфер целиком. С учетом того, что атрибут содержит лишь одно экспортируемое значение или массив однотипных значений здесь не должно возникать сложностей. В результате из пользовательского пространства становится возможным частичное считывание и перемещение вперед по файлу (seek). Если приложение вернется к началу файла или выполнит операцию pread с нулевым смещением, метод show() будет вызван снова для повторного заполнения буфера.
При записи (write) sysfs предполагает, что буфер передается целиком при первой операции записи. Содержимое буфера sysfs целиком передает методу store().

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

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

Примечания

при записи метод show() вызывается независимо от текущей позициив файле;
размер буфера всегда составляет PAGE_SIZE байтов (на i386 это 4096);
методам show() следует возвращать число байтов, записанных в буфер )значение, возвращаемое scnprintf());
методам show() следует всегда использовать scnprintf();
методам store() следует возвращать число использованных байтов буфера (если использовались все байты, просто возвращается аргумент count);
методы show() и store() могут возвращать коды ошибок (особенно при получении некорректного значения);
объекты, переданные методам, помещаются в память с использованием счетчика ссылок sysfs, однако указываемый физический объект (например, устройство) может отсутствовать в системе и при необходимости следует проверять его наличие.

Пример очень простой и естественной реализации атрибута устройства показан ниже:

static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf) {
	return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name);
}

static ssize_t store_name(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) {
	snprintf(dev->name, sizeof(dev->name), "%.*s", (int)min(count, 
		sizeof(dev->name) - 1), buf);
	return count;
}

static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);

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

Схема каталогов верхнего уровня

Каталог sysfs показывает соотношения между структурами данных ядра. Субкаталоги верхнего уровня имеют вид:

block/
bus/
class/
dev/
devices/
firmware/
net/
fs/

Каталог devices/ представляет дерево файлов, связанных с устройствами, и отображает их напрямую во внутреннее дерево устройств ядра, представляющее собой иерархию структур device. В каталоге bus/ содержится плоская схема различных типов шин в ядре. Каталог для каждой из шин включает два субкаталога:

devices/
drivers/

В субкаталоге devices/ размещаются символьные ссылки для каждого обнаруженного в системе устройства на соответствующие устройства в каталоге устройств корневой файловой системы (root/).

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

Дерево fs/ содержит каталоги для некоторых файловых систем. В настоящее время система, желающая экспортировать атрибуты, должна создавать свою иерархию в дереве fs/ (см, например документ Documentation/filesystems/fuse.txt в дистрибутиве ядра).

Каталог dev/ содержит два субкаталога char/ и block/, в каждом из которых размещаются символьные ссылки с именами вида <major>:<minor>. Эти ссылки указывают на каталоги sysfs для каждого из устройств. Структура /sys/dev обеспечивает возможность быстрого поиска интерфейса sysfs для устройства по результатам операции stat.

Дополнительную информацию о конкретных свойствах драйверов можно найти в каталоге Documentation/driver-model/.

Примечание: Этот раздел пока не завершен.

Текущие интерфейсы

Ниже перечислены интерфейсные уровни, существующие в sysfs на текущий момент.

Устройства (include/linux/device.h)

Структура

struct
 device_attribute {
	struct attribute	attr;
	ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
	ssize_t (*store)(struct device *dev, struct device_attribute *attr,
			 const char *buf, size_t count);
};

Декларирование

DEVICE_ATTR(_name, _mode, _show, _store);

Создание и удаление

int device_create_file(struct device *dev, const struct device_attribute * attr);
void device_remove_file(struct device *dev, const struct device_attribute * attr);

Драйверы шин (include/linux/device.h)

Структура

struct bus_attribute {
        struct attribute attr;
        ssize_t (*show)(struct bus_type *, char * buf);
        ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
};

Декларирование

BUS_ATTR(_name, _mode, _show, _store)

Создание и удаление

int bus_create_file(struct bus_type *, struct bus_attribute *);
void bus_remove_file(struct bus_type *, struct bus_attribute *);

Драйверы устройств (include/linux/device.h)

Структура

struct driver_attribute {
    struct attribute        attr;
    ssize_t (*show)(struct device_driver *, char * buf); 
    ssize_t (*store)(struct device_driver *, const char * buf, size_t count);
};

Декларирование

DRIVER_ATTR(_name, _mode, _show, _store)

Создание и удаление

int driver_create_file(struct device_driver *, const struct driver_attribute *);
void driver_remove_file(struct device_driver *, const struct driver_attribute *);

Документация

Структура каталога sysfs и атрибуты в каждом из субкаталогов определяют бинарный интерфейс (ABI) между ядром и пользовательским пространством. Как и для всякого ABI здесь важно обеспечить стабильность и надлежащее документирование. Все новые атрибуты sysfs должны документироваться в Documentation/ABI. Дополнительную информацию можно найти в документе Documentation/ABI/README.

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

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

nmalykh@protokols.ru

Рубрика: Linux | Комментарии отключены

RFC 6328 IANA Considerations for Network Layer Protocol Identifiers

Опубликовано 20.07.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 6328                                        Huawei
BCP: 164                                                       July 2011
Category: Best Current Practice
ISSN: 2070-1721

Значения, выделенные IANA для идентификаторов сетевых протоколов

IANA Considerations for Network Layer Protocol Identifiers

PDF

Аннотация

Некоторые протоколы, разрабатываемые или расширяемые IETF, используют идентификаторы протоколов сетевого уровня NLPID¹ ISO/IEC². В этом документе рассматриваются вопросы IANA, связанные с NLPID.

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

Документ относится к категории Internet Best Current Practice.

Документ является результатом работы IETF³ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG⁴. Дополнительную информацию о BCP можно найти в разделе 2 в RFC 5741.

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

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

1. Введение

Некоторые протоколы, разрабатываемые или расширяемые IETF, используют идентификаторы протоколов сетевого уровня NLPID ISO/IEC.

Термин NLPID фактически не используется в [ISO9577], где упоминаются однооктетные идентификаторы начального (IPI⁵) и последующего (SPI⁶) протокола. Хотя эти два типа идентификаторов логически различаются, большинство значения пригодно для использования в качестве IPI и SPI. В оставшейся части документа термин NLPID относится к обоим типам.

Реестр значений NLPID поддерживается ISO/IEC путем обновления [ISO9577]. Процедуры, заданные ISO/IEC в этом документе, указывают, что код NLPID может выделяться без одобрения ISO/IEC, если значение кода не относится к диапазону, выделенному для организаций, которые не являются организацией, выделяющей код, и уведомлен комитет ISO/IEC JTC1 SC6.

В этом документе рассматриваются вопросы IANA, связанные с NLPID. Т. е. документ задает уровень одобрения IETF, требуемый для выделения кода, используемые для этого процедуры и действия, предпринимаемые IANA по части NLPID, и связанные с этим рекомендации.

Если в этом документе явно не указано иное, предполагаются процедуры [RFC5226].

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

2. NLPID

[ISO9577] определяет однооктетные идентификаторы протоколов сетевого уровня, обозначаемые термином NLPID.

Идентификаторы NLPID используются во многих протоколах. Примерами могут служить поле mar$pro.type протокола сервера преобразования групповых адресов [RFC2022], поле ar$pro.type в протоколе определения следующего интервала NBMA⁷ [RFC2332] и IS-IS Protocols Supported TLV [RFC1195] (см. Приложение B).

2.1. Субдиапазоны NLPID

Субдиапазоны возможных значений NLPID разделены в [ISO9577] на категории по организациям, как показано ниже. Значения большей частью распределены между ISO/IEC и ITU-T⁸.

Код	Категория
0x00	ISO/IEC
0x01-0x0F	ITU-T
0x10-0x3F	ITU-T Rec. X.25 и ISO/IEC 8208
0x40-0x43	ISO/IEC
0x44	ITU-T
0x45-0x4F	ISO/IEC
0x50-0x6F	ITU-T Rec. X.25 и ISO/IEC 8208
0x70-0x7F	ITU-T и ISO/IEC
0x80	ISO/IEC (см. параграф 2.2)
0x81-0x8F	ISO/IEC
0x90-0xAF	ITU-T Rec. X.25 и ISO/IEC 8208
0xB0-0xBF	ITU-T
0xC0-0xCF	Доступны для IANA (см. параграф 2.3)
0xD0-0xEF	ITU-T Rec. X.25 ISO/IEC 8208
0xF0-0xFE	ITU-T и ISO/IEC
0xFF	Зарезервирован для механизма расширения, разрабатываемого совместно ITU-T и ISO/IEC

2.2. Код 0x80

NLPID 0x80 называют кодом IEEE⁹ SNAP¹⁰. За ним следуют 5 октетов, задающих протокол в соответствии с соглашениями IEEE SNAP SAP¹¹. Эти соглашения описаны в разделе 3 [RFC5342]. В частности, такая 5-октетная последовательность может начинаться с идентификатора организации IANA OUI¹², за которым следуют 2 октета, также выделенные IANA в соответствии с [RFC5342]. Для идентификаторов протоколов используется общий реестр IANA, независимо от их применения в 0x80 NLPID или IEEE SNAP SAP LSAP¹³ (0xAAAA). Выделенные IANA значения могут использоваться в любом подходящем контексте.

По причине ограниченности числа кодов NLPID в распоряжении IANA рекомендуется использовать IEEE SNAP NLPID вместо выделения нового однооктетного кода NLPID.

2.3. Значения NLPID, доступные для распределения IANA

Для распределения IANA стандарт [ISO9577] выделяет ограниченное число кодов. По этой причине желательно применять там, где это возможно, код 0x80, как указано выше в параграфе 2.2, или получать коды из диапазонов, выделенных другим организациям. Например, код 0x8E был выделен для IPv6 [RFC2460], хотя он относится к диапазону значений ISO/IEC. Однооктетные коды, выделенные для TRILL и IEEE 802.1aq, предназначены для использования в IS-IS Protocols Supported TLV [RFC1195].

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

Код	Назначение
0xC0	TRILL [RFC6325]
0xC1	IEEE 802.1aq [802.1aq]
0xC2-0xCB	Доступны для назначения
0xCC	IPv4 [RFC791]
0xCD-0xCE	Доступны для назначения
0xCF	PPP [RFC1661]

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

Пока имеются свободные значения, IANA будет выделять новые коды по процедуре IETF Review [RFC5226].

При выделении NLPID агентство IANA информировать ответственного от IETF за связь с ISO/IEC JTC1¹⁴ SC6¹⁵ [JTC1SC6] или IAB, если ответственного не удается определить. Ответственный за связь (или IAB) обеспечивает информирование ISO/IEC JTC1 SC6 для обновления [ISO9577] поскольку ISO/IEC JTC1 SC6 отвечает за поддержку [ISO9577]. Для упрощения этого процесса желательно со стороны IAB поддерживать связь IETF с ISO/IEC JTC1 SC6.

В этом документе выделены два значения кодов 0xC0 и 0xC1, как показано в параграфе 2.3, и агентство IANA просит ответственного за связь (или IAB) проинформировать об этом ISO/IEC JTC1 SC6.

IANA поддерживает web-страницу со значениями NLPID, которые были выделены для протоколов, разрабатываемых или расширяемых IETF, или представляющими иной интерес. Начальное содержимое этой страницы приведено в Приложении A. IANA будет обновлять эту страницу в случае (1) выделения агентством значений NLPID и (2) выделения или освобожения значений по запросам IANA к отвественному за связь от IETF, как указано выше.

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

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

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

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

[ISO9577] International Organization for Standardization «Information technology — Telecommunications and Information exchange between systems — Protocol identification in the network layer», ISO/IEC TR 9577:1999, 1999-12-15.

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

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226 ¹⁶, May 2008.

[RFC5342] Eastlake 3rd., D., «IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters», BCP 141, RFC 5342, September 2008.

[RFC6325] Radia, P., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, «RBridges: Base Protocol Specification», RFC 6325, July 2011.

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

[802.1aq] Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 9: Shortest Path Bridging, Draft IEEE P802.1aq/D2.1, 21 August 2009.

[JTC1SC6] ISO/IEC JTC1 SC6 (International Organization for Standardization / International Electrotechnical Commission, Joint Technical Committee 1, Study Committee 6), http://www.iso.org/iso/iso_technical_committee.html?commid=45072

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1195] Callon, R., «Use of OSI IS-IS for routing in TCP/IP and dual environments», RFC 1195, December 1990.

[RFC1661] Simpson, W., Ed., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

[RFC1707] McGovern, M. and R. Ullmann, «CATNIP: Common Architecture for the Internet», RFC 1707, October 1994.

[RFC2022] Armitage, G., «Support for Multicast over UNI 3.0/3.1 based ATM Networks», RFC 2022, November 1996.

[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, «NBMA Next Hop Resolution Protocol (NHRP)», RFC 2332, April 1998.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

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

Спасибо всем перечисленным ниже в алфавитном порядке участникам работы:

Ayan Banerjee, Gonzalo Camarillo, Dinesh Dutt, Don Fedyk, Alfred Hines, Russ Housley, Andrew Malis, Radia Perlman, Dan Romascanu и Peter Ashwood-Smith.

Приложение A. Исходная Web-страница IANA NLPID

Представляющие интерес значения NLPID.

Код	Использование
0x00	Null
0x08	Q.933 (RFC 2427)
0x80	IEEE SNAP (RFC 6328)
0x81	ISO CLNP (Connectionless Network Protocol)
0x82	ISO ES-IS
0x83	IS-IS (RFC 1195)
0x8E	IPv6 (RFC 2460)
0xB0	FRF.9 (RFC 2427)
0xB1	FRF.12 (RF C2427)
0xC0	TRILL (RFC 6325)
0xC1	IEEE 802.1aq
0xCC	IPv4 (RFC 791)
0xCF	PPP (RFC 1661)

Примечание. В соответствии с [RFC1707] значение NLPID 0x70 выделено для протокола IPv7. Это назначение представляется утратившим действие и не включено в ISO/IEC 9577. Назначение IPv7 было временным в момент выбора из трех кандидатов следующего поколения IP после IPv4 (IPv6, IPv7 и IPv8). Был выбран вариант IPv6.

Приложение B. RFC, упоминающие NLPID

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

RFC 1195	Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
RFC 1356	Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode
RFC 1377	The PPP OSI Network Layer Control Protocol (OSINLCP)
RFC 1661	The Point-to-Point Protocol (PPP)
RFC 1707	CATNIP: Common Architecture for the Internet
RFC 1755	ATM Signaling Support for IP over ATM
RFC 2022	Support for Multicast over UNI 3.0/3.1 based ATM Networks
RFC 2332	NBMA Next Hop Resolution Protocol (NHRP)
RFC 2337	Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
RFC 2363	PPP Over FUNI
RFC 2390	Inverse Address Resolution Protocol
RFC 2427	Multiprotocol Interconnect over Frame Relay
RFC 2590	Transmission of IPv6 Packets over Frame Relay Networks Specification
RFC 2684	Multiprotocol Encapsulation over ATM Adaptation Layer 5
RFC 2955	Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function
RFC 3070	Layer Two Tunneling Protocol (L2TP) over Frame Relay
RFC 5308	Routing IPv6 with IS-IS

Адрес автора

Donald E. Eastlake 3rd

Huawei Technologies

155 Beaver Street

Milford, MA 01757 USA

Phone: +1-508-333-2270

EMail: d3e3e3@gmail.com

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

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

nmalykh@gmail.com

1Network Layer Protocol Identifier.

2International Organization for Standardization/International Electrotechnical Commission — Международный комитет по стандартизации/Международная электротехническая комиссия.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Initial Protocol Identifier — идентификатор начального протокола.

6Subsequent Protocol Identifier — идентификатор последующего протокола.

7Non-Broadcast Multi-Access — множественный доступ без широковещания.

8International Telecommunication Union — Telecommunication Standardization Sector — Международный союз электросвязи — сектор телекоммуникационных стандартов (МСЭ-Т).

9Institute of Electrical & Electronics Engineers — Институт инженеров электротехники и электроники.

10SubNetwork Access Protocol — протокол доступа к подсети.

11Service Access Point — точка доступа к сервису.

12Organizationally Unique Identifier — уникальный идентификатор организации.

13Link-Layer Service Access Point — точка доступа к сервису канального уровня.

14Joint Technical Committee 1 — Объединенный технический комитет 1.

15Study Committee 6 — Исследовательский комитет 6.

16Заменен RFC 8126. Прим. перев.

17Заменен RFC 7042. Прим. перев.

18Заменен RFC 8200. Прим. перев.

Рубрика: RFC | Комментарии отключены

RFC 6325 Routing Bridges (RBridges): Base Protocol Specification

Опубликовано 01.07.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        R. Perlman
Request for Comments: 6325                                    Intel Labs
Category: Standards Track                                D. Eastlake 3rd
ISSN: 2070-1721                                                   Huawei
                                                                 D. Dutt
                                                                  S. Gai
                                                           Cisco Systems
                                                             A. Ghanwani
                                                                 Brocade
                                                               July 2011

Базовая спецификация протокола маршрутизирующих мостов

Routing Bridges (RBridges): Base Protocol Specification

PDF

Аннотация

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

Мосты RBridge совместимы с прежними пользовательскими мостами IEEE 802.1, а также с маршрутизаторами и оконечными узлами IPv4 и IPv6. Они невидимы для современных маршрутизаторов IP как мосты и, подобно маршрутизаторам, прерывают действие протокола STP².

Решение поддерживает виртуальные сети VLAN и оптимизацию распространения групповых (multi-destination) кадров на основе VLAN ID и выведенных из IP multicast-групп. Поддерживается также масштабирование таблиц индивидуальной пересылки на транзитных мостах RBridge в соответствии с числом мостов RBridge (а не числом конечных узлов), что позволяет сделать таблицы пересылки существенно меньше, чем в традиционных мостах.

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

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

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

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

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

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

1. Введение

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

Мосты IEEE 802.1 не сталкиваются с такими проблемами, прозрачно соединяя множество физических каналов в одну локальную сеть с точки зрения IP [802.1D]. Однако мост 802.1 выполняет пересылку с использованием протокола STP, с которым связан ряд недостатков.

Протокол STP работает на основе блокировки портов, ограничивая число каналов пересылки, что создает «пробки» за счет концентрации трафика в некоторых каналах.
Пересылка не происходит по парному кратчайшему пути, вместо этого используются каналы, оставшиеся после удаления протоколом STP избыточных путей.
В заголовке Ethernet нет счетчика интервалов пересылки (поля TTL⁵). Это создает опасность возникновения временных петель (например, при потере сообщений STP или добавлении компонент типа повторителей).
VLAN могут разбиваться на части при перестройке STP.

В этом документе описаны маршрутизирующие мосты RBridge [Rbridges], в которых реализован протокол TRILL, описанные ниже в поэтической форме. RBridge объединяет преимущества мостов и маршрутизаторов, являясь, как указано в этом документе, приложением маршрутизации по состоянию каналов к решению проблемы осведомленных о VLAN пользовательских мостов. За исключением указанных в документе случаев мосты RBridge могут постепенно заменить пользовательские мосты IEEE [802.1Q-2005] и [802.1D].

Хотя мосты RBridge могут применяться для разных протоколов канального уровня, данная спецификация относится к каналам IEEE [802.3]. Предполагается, что другие типы каналов будут описаны в отдельных документах.

Протокол TRILL, как указано в этом документе, разработан в качестве протокола ЛВС и не предназначен для масштабирования за пределы размеров сузествующих ЛВС на основе мостов. Дополнительное рассмотрение области проблем, решаемых с помощью мостов RBridge, приведено в [RFC5556].

1.1. Алгоритм версии 2 от Ray Perlner

I hope that we shall one day see
A graph more lovely than a tree.

A graph to boost efficiency
While still configuration-free.

A network where RBridges can
Route packets to their target LAN.

The paths they find, to our elation,
Are least cost paths to destination!

With packet hop counts we now see,
The network need not be loop-free!

RBridges work transparently,
Without a common spanning tree.

1.2. Нормативное содержимое и приоритеты

Большая часть нормативного материала приведена в разделах 1 — 4 этого документа. При возникновении конфликтов между этими четырьмя разделами приоритет имеют сведения из раздела с большим номером.

1.3. Терминология и обозначения

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

TRILL — это протокол, заданный этим документом, а RBridge — устройство, реализующее этот протокол. Регистр второй буквы в Rbridge значения не имеет, корректны оба варианта Rbridge и RBridge.

В этом документе термин «канал» (если явно не указано иное) означает ЛВС на основе мостов (bridged LAN), т. е. представляет собой комбинацию из одного или множества каналов [802.3], которые могут включать мосты, концентраторы (hub), повторители (repeater) и т. п. Термин «простой канал» означает соединение «точка-точка» или канал с множественным доступом, не включающие мостов или RBridge.

Термин «порт» (если явно не указано иное) обозначает физический, виртуальный [802.1AE] или псевдопорт [802.1X]. Термин «физический порт» обозначает физическую точку подключения между RBridge и каналом.

Термин «кампус» относится к RBridge, а «ЛВС на базе мостов» — к обычным мостам. Кампус RBridge состоит из сети мостов RBridge, обычных мостов, концентраторов, повторителей, простых каналов и т. п., ограниченных конечными станциями и маршрутизаторами.

Термин «связующее дерево» (spanning tree) в этом документе обозначает классический а также ускоренный вариант spanning tree (как в протоколе RSTP⁶).

В документе используется 16-ричное представление адресов MAC. Каждый октет (8-битовый байт) указывается двумя шестнадцатеричными цифрами, задающими значение октета в форме целого числа без знака. Октеты разделяются символом дефиса. В документе используется принятый в IETF порядок представления битов, хотя в физической среде IEEE [802.3] биты внутри октета передаются от младшего к старшему, т. е. в обратном порядке.

1.4. Категории кадров L2

В этом документе кадры уровня 2 (L2) делятся на 5 категорий:

кадры управления L2 (типа BPDU⁷);
естественные кадры (кадры данных без инкапсуляции TRILL);
кадры данных TRILL (кадры данных с инкапсуляцией TRILL);
кадры управления TRILL;
прочие кадры TRILL.

Идентификация этих категорий кадров описана ниже.

Кадры управления L2 используют групповой адрес получателя из диапазона 01-80-C2-00-00-00 — 01-80-C2-00-00-0F или адрес 01-80-C2-00-00-21. Мостам RBridge недопустимо инкапсулировать и пересылать такие кадры, хотя они могут (если в документе не указано иное) выполнять для этих кадров функции L2 (типа MAC-security). Кадры с адресом получателя 01-80-C2-00-00-00 (BPDU) или 01-80-C2-00-00-21 (протокол регистрации VLAN) в этом документе называются кадрами управления верхнего уровня (high-level control frames), все остальные управляющие кадры L2 — кадрами управления нижнего уровня.
Естественными кадрами называются кадры, не относящиеся к управления и имеющие значение Ethertype, отличное от TRILL и L2-IS-IS, а также адресованные получателям, MAC-адреса которых отличаются от 16 зарезервированных для TRILL групповых адресов.
В кадрах данных TRILL поле Ethertype имеет значение TRILL. Кроме того, в групповых кадрах этой категории используется групповой MAC-адрес All-Rbridges.
В кадрах управления TRILL поле Ethertype имеет значение L2-IS-IS, а групповые кадры этой категории передаются по MAC-адресу All-IS-IS-RBridges. Отметим, что кадры ESADI снаружи выглядят как кадры данных TRILL и обрабатываются так же, но при декапсуляции имеют Ethertype = L2-IS-IS.
Остальные кадры TRILL используют в качестве адреса получателя один из 16 зарезервированных для TRILL групповых адресов, но не All-Rbridges или All-IS-IS-RBridges. Мосты RBridge, соответствующие этой спецификации, должны отбрасывать такие кадры.

1.5. Сокращения

AllL1ISs — All Level 1 Intermediate Systems — все промежуточные системы физического уровня.

AllL2ISs — All Level 2 Intermediate Systems — все промежуточные системы канального уровня.

BPDU — Bridge PDU — блок данных протокола мостов.

CHbH — Critical Hop-by-Hop — флаг наличия критичной поэтапной опции.

CItE — Critical Ingress-to-Egress — флаг наличия критичной сквозной опции.

CSNP — Complete Sequence Number PDU — блок данных полного порядкового номера.

DA — Destination Address — адрес получателя.

DR — Designated Router — назначенный маршрутизатор.

DRB — Designated RBridge — назначенный RBridge.

EAP — Extensible Authentication Protocol — расширяемый протокол аутентификации.

ECMP — Equal Cost Multipath — множество равноценных путей.

EISS — Extended Internal Sublayer Service — расширенный сервис внутреннего подуровня.

ESADI — End-Station Address Distribution Information — информация о распространении адресов конечных станций.

FCS — Frame Check Sequence — последовательность проверки кадра (контрольная сумма).

GARP — Generic Attribute Registration Protocol — базовый протокол регистрации атрибутов.

GVRP — GARP VLAN Registration Protocol — протокол GARP для регистрации VLAN.

IEEE — Institute of Electrical and Electronics Engineers — институт инженеров по электрике и электронике.

IGMP — Internet Group Management Protocol — протокол управления группами Internet.

IP — Internet Protocol — протокол Internet.

IS-IS — Intermediate System to Intermediate System — протокол маршрутизации между промежуточными системами.

ISS — Internal Sublayer Service — внутренний сервис подуровня.

LAN — Local Area Network — локальная (вычислительная) сеть, ЛВС

LSP — Link State PDU — блок данных состояния канала.

MAC — Media Access Control — контроль доступа к среде.

MLD — Multicast Listener Discovery — обнаружение «слушателей» группового трафика.

MRD — Multicast Router Discovery — обнаружение маршрутизаторов группового трафика.

MTU — Maximum Transmission Unit — максимальный размер передаваемого блока.

MVRP — Multiple VLAN Registration Protocol — протокол регистрации множества VLAN.

NSAP — Network Service Access Point — точка доступа к сетевому сервису.

P2P — Point-to-point — соединение между парой точек, «точка-точка».

PDU — Protocol Data Unit — блок данных протокола.

PPP — Point-to-Point Protocol — протокол соединений «точка-точка».

RBridge — Routing Bridge — маршрутизирующий мост.

RPF — Reverse Path Forwarding — пересылка по обратному пути.

SA — Source Address — адрес отправителя.

SNMP — Simple Network Management Protocol — простой протокол сетевого управления.

SPF — Shortest Path First — сначала кратчайший путь.

TLV — Type, Length, Value — тип, размер, значение.

TRILL — TRansparent Interconnection of Lots of Links — прозрачное соединение множества каналов.

VLAN — Virtual Local Area Network — виртуальная ЛВС.

VRP — VLAN Registration Protocol — протокол регистрации VLAN.

2. Маршрутизирующие мосты

В этом разделе представлен краткий обзор маршрутизирующих мостов RBridge, реализующих протокол TRILL, без учета некоторых деталей. Подробные спецификации представлены в разделах 3 и 4.

TRILL, как описано в этом документе с некоторыми рассмотренными здесь исключениями, обеспечивает сервис [802.1Q-2005] с учетом VLAN. Как указано ниже, TRILL размещается над уровнем портов RBridge.

Маршрутизирующие мосты RBridge, описанные в этом документе не поддерживают услуг провайдерских мостов [802.1ad], включая магистральные [802.1ah], или похожего на них сервиса. Расширение TRILL для поддержки провайдерских служб оставлено для будущей работы и отдельного документа. Однако провайдерские мосты (включая магистральные) могут использоваться для соединения частей кампуса RBridge.

2.1. Общий обзор

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

Для снижения влияния временных петель RBridge выполняют пересылку на основе заголовка со счетчиком интервалов. Маршрутизирующие мосты RBridge также задают RBridge следующего интервала пересылки как адресата кадра при пересылке индивидуальных кадров через канал с общей средой (shared-media), что позволяет избежать появления дополнительных кадров при наличии временной петли. Выполняется проверка пересылки по обратному пути (RPF) и другие проверки для кадров с множеством получателей с целью дополнительного контроля возможных петель трафика (параграф 4.5.2).

Первый RBridge (RB1), с которым индивидуальный кадр сталкивается в кампусе, инкапсулирует принятый кадр с использованием заголовка TRILL, который задает последний RBridge (RB2), где происходит декапсуляция кадра. RB1 называют входным RBridge, а RB2 — выходным. Для экономии места в заголовке TRILL и упрощения поиска при пересылке, между RBridge поддерживается протокол динамического получения псевдонимов (nickname), выбирающий 2-октетный псевдоним для RBridge, который уникален в масштабе кампуса и служит сокращением для IS-IS ID данного RBridge. Двухоктетные псевдонимы служат для указания входного и выходного RBridge в заголовке TRILL.

Поддерживается распространение кадров со множеством получателей по множеству путей с разными деревьями распространения и ECMP для индивидуальных кадров (Приложение C).

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

Маршрутизирующие мосты RBridge используют на канале протокол для выбора DRB. Протокол выбора TRILL-IS-IS на канале несколько отличается от протокола выбора L3 IS-IS [ISO10589], поскольку в TRILL может быть указан только один RBridge в качестве DRB, а в L3 IS-IS можно выбрать множество DR (называемых также also known as Designated Intermediate System). Как и маршрутизатор IS-IS, DRB может давать каналу имя псевдоузла, выдавать LSP от имени псевдоузла (Link State PDU) и выдавать в канал CSNP. В дополнение к этому DRB имеет некоторые специфические для TRILL обязанности, включая указание VLAN, используемой в качестве Designated VLAN при коммуникациях между RBridge на данном канале (параграф 4.2.4.2).

DRB инкапсулирует и декапсулирует весь трафик данных канала или при распределении нагрузки передает эти полномочия для одной или нескольких VLAN другим RBridge на канале. В любой момент на канале должно быть не более одного RBridge, который инкапсулирует и декапсулирует трафик для конкретной VLAN. Будем называть RBridge, назначенный для пересылки трафика VLAN-x от имени канала «назначенным узлом пересылки VLAN-x» (параграф 4.2.4.3). Дополнительное обсуждение VLAN приведено в параграфе 2.5.

Маршрутизирующим мостам следует поддерживать протокол SNMPv3 [RFC3411]. База RBridge MIB будет задана в отдельном документе. Если на RBridge доступен сервис IP, ему следует поддерживать SNMPv3 по протоколу UDP для IPv4 [RFC3417] и IPv6 [RFC3419], однако в кампусе управление может использоваться даже для RBridge без поддержки IP или другого транспортного стека L3, а также без адреса L3 путем доставки данных SNMP через Ethernet [RFC4789].

2.2. Адреса конечных станций

RBridge RB1, который служит узлом пересылки для VLAN-x, на каждом из своих каналов должен определять местоположение конечных узлов VLAN-x как на каналах, для которых он является узлом пересылки VLAN-x, так и на других каналах в кампусе. RB1 определяет порты, VLAN, и адреса L2 (MAC) конечных узлов на каналах, для которых он является узлом пересылки VLAN-x, по адресам отправителей кадров, для которых он служит мостом (см., например, параграф 8.7 в [802.1Q-2005]), из конфигурации или протокола явной регистрации L2 типа привязки и аутентификации IEEE 802.11. RB1 определяет VLAN и адрес L2 удаленных конечных точек VLAN-x и соответствующего RBridge, к которому они могут быть подключены, путем просмотра псевдонима входного RBridge в заголовке TRILL, а также VLAN и MAC-адреса отправителя во внутренних кадрах данных TRILL, которые он декапсулирует.

Кроме того, RBridge назначенный ретранслятором VLAN-x хотя бы для одного канала, может использовать протокол ESADI для анонсирования части или всех конечных узлов VLAN-x на этих каналах.

Протокол ESADI можно использовать для анонсирования конечных узлов, которые были анонсированы явно. Такая информация может быть более достоверной, чем определенная из кадров, декапсулированных в канал. Кроме того, зарегистрированные и распространяемые таким способом адреса могут быть более защищены по двум причинам — (1) регистрация может выполняться с проверкой подлинности (например, с использованием криптографических методов EAP через [802.1X]) и (2) протокол ESADI поддерживает криптографическую аутентификацию своих сообщений [RFC5304] [RFC5310] для более защищенной передачи.

Если конечная станция отключается от одного RBridge и подключается к другому, в зависимости от обстоятельств кадры для этой станции могут попадать в «черную дыру». Т. е. они просто могут быть отправлены прежнему RBridge, который конечная станция использовала, пока кэшированный адрес на некоторых удаленных RBridge не устареет (возможно в течение минут или дольше). При использовании протокола ESADI разрыв соединения при переключении станции может вызвать незамедлительную передачу обновления.

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

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

2.3. Архитектура инкапсуляции RBridge

В качестве технологии L2 для соединения между RBridge может служить IEEE [802.3] или другие технологии канального уровня типа PPP [RFC1661]. Это возможно в результате того, что функция трансляции RBridge работает на основе технологий L2. Однако в этом документе описывается лишь инкапсуляция IEEE 802.3.

На рисунке показаны два RBridge RB1 и RB2, соединенных между собой через облако (сеть) Ethernet, которое может включать концентраторы, среды «точка-точка» или с множественным доступом, мосты IEEE 802.1D и 802.1Q.

              ------------
             /            \
+-----+     /    Облако    \    +-----+
| RB1 |----<                >---| RB2 |
+-----+     \   Ethernet   /    +-----+
             \            /
              ------------

Рисунок 1. Соединение между Rbridge.

На рисунке 2 показан формат кадра данных TRILL или кадра ESADI в облаке Ethernet между RB1 и RB2.

+--------------------------------+
|   Внешний заголовок Ethernet   |
+--------------------------------+
|        Заголовок TRILL         |
+--------------------------------+
|  Внутренний заголовок Ethernet |
+--------------------------------+
|        Ethernet Payload        |
+--------------------------------+
|         Ethernet FCS           |
+--------------------------------+

Рисунок 2. Кадр TRILL, инкапсулированный в Ethernet.

При использовании среды, отличающейся от Ethernet, используется заголовок конкретной среду вместо внешнего заголовка Ethernet. На рисунке 3 показана инкапсуляция TRILL для передачи по протоколу PPP.

+--------------------------------+
|         Заголовок PPP          |
+--------------------------------+
|        Заголовок TRILL         |
+--------------------------------+
|  Внутренний заголовок Ethernet |
+--------------------------------+
|        Ethernet Payload        |
+--------------------------------+
|             PPP FCS            |
+--------------------------------+

Рисунок 3. Кадр TRILL, инкапсулированный в PPP.

Внешний заголовок определяется типом канала. В данном документе рассматриваются лишь соединения [802.3], но возможны и другие типы.

В любом случае внутренний заголовок Ethernet и данные (Ethernet Payload) берутся из принятого кадра и инкапсулируются с использованием заголовка TRILL для передачи между RBridge. Использование заголовка TRILL обеспечивает ряд преимуществ:

снижения влияния петель за счет наличия счетчика интервалов (hop count);
отсутствие необходимости определять VLAN и MAC-адрес конечной станции на транзитных RBridge;
отправка индивидуальных кадров в направлении выходного RBridge (это позволяет на транзитных RBridge держать таблицы индивидуальной пересылки с размером, определяемым числом RBridge, а не общим числом конечных станций);
предоставление отдельного тега VLAN для пересылки трафика между RBridge, независимо от VLAN естественного кадра.

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

2.4. Обзор пересылки

Маршрутизирующие мосты RBridge являются маршрутизаторами в том смысле, что при пересылке кадра транзитным RBridge внешний заголовок L2 заменяется на каждом устройстве пересылки подходящим заголовком L2 для следующего интервала, а значение счетчика интервалов уменьшается. Несмотря на изменение внешнего заголовка L2 и счетчика интервалов в заголовке TRILL, инкапсулированный исходный кадр сохраняется, включая тег VLAN (см. подробности в параграфе 4.6).

С точки зрения пересылки транзитные кадры можно разделить на 2 категории — заведомо индивидуальные (known-unicast) и групповые (multi-destination). Кадры управления L2 и TRILL, а также прочие (не данные) кадры TRILL не являются транзитными, не пересылаются RBridge и не входят в эти категории.

2.4.1. Заведомо индивидуальные кадры

К этой категории относятся кадры, в которых используется индивидуальный внутренний MAC-адрес получателя (Inner.MacDA) и для которых входной RBridge знает выходной RBridge для MAC-адреса получателя в VLAN кадра.

Такие кадры поэтапно передаются через цепочку RBridge до выходного RBridge.

2.4.2. Групповые кадры

Это кадры, которые должны доставляться множеству получателей.

Варианты групповых кадров перечислены ниже.

Индивидуальные кадры для которых местоположение адресата не известно — Inner.MacDA содержит индивидуальный адрес, но входной RBridge не может определить его местоположение по VLAN в кадре.
Групповые кадры, для которых адрес получателя L2 выводится из группового адреса IP — Inner.MacDA содержит групповой адрес из набора групповых адресов L2, выведенный из группового адреса IPv4 [RFC1112] или IPv6 [RFC2464]. Эти кадры обрабатываются в зависимости от ситуации:
1. отчеты о принадлежности к группам IGMP [RFC3376] и MLD [RFC2710];
2. запросы IGMP [RFC3376] и MLD [RFC2710], а также анонсы MRD [RFC4286];
3. другие групповые кадры L2, выведенные из IP.
Групповые кадры, для которых адрес получателя L2 не взят из группового адреса IP, Inner.MacDA содержит групповой адрес, не являющийся групповым адресом L2, полученным из группового адреса IPv4 или IPv6.
Широковещательные кадры — Inner.MacDA содержит широковещательный адрес FF-FF-FF-FF-FF-FF.

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

2.5. Мосты RBridge и VLAN

Технология VLAN обеспечивает способ разделения конечных узлов в кампусе на группы L2 [802.1Q-2005]. Для использования VLAN нужна настройка. По умолчанию приемный порт определяет VLAN переданного конечной станцией кадра. Конечные станции могут также явно включать эту информацию в кадр.

Мосты IEEE [802.1Q-2005] можно настроить для поддержки множества пользовательских VLAN на одном простом канале путем вставки в кадр (и удаления) тега VLAN. Теги VLAN, используемые TRILL, имеют такой же формат, как теги VLAN, определенные в IEEE [802.1Q-2005]. Как показано на рисунке 2, такие теги могут появляться в двух местах кадров с инкапсуляцией TRILL, передаваемых по каналу IEEE [802.3] — один тег во внешнем заголовке (Outer.VLAN), другой во внутреннем (Inner.VLAN). Внутренние и внешние теги VLAN более подробно рассмотрены в параграфе 4.1.

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

Работа TRILL IS-IS на канале более подробно описана в параграфе 4.2.4.

2.5.1. VLAN на канале

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

TRILL требует наличия на канале по меньшей мере одной VLAN, обеспечивающей связь со всеми RBridge на этом канале. По умолчанию это VLAN 1, хотя RBridge могут быть настроены на другую VLAN. DRB указывает другим RBridge, какую VLAN использовать.

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

Настройка моста и порта может приводить к трансляции VLAN на канале (кадры VLAN-x станут кадрами VLAN-y). TRILL детектирует это, помещая копию внешнего тега VLAN в сообщения TRILL-Hello и проверяя такие сообщения на приемной стороне. При обнаружении принимаются меры, обеспечивающие наличие на канале единственного назначенного устройства пересылки, для предотвращения возможных петель и дублирования кадров (параграф 4.4.5).

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

2.6. RBridge и мосты IEEE 802.1

Порты RBridge за исключением описанных ниже случаев, работают «поверх» портов IEEE [802.1Q-2005].

2.6.1. Порты RBridge и уровни 802.1

Порты RBridge используют функции обработки VLAN и приоритета портов [802.1Q-2005]. В дополнение к этому они могут реализовать другие функции низкого уровня протоколов 802.1, а также протоколов для используемого канала типа PAUSE (Приложение 31B в [802.3]), контроля доступа по портам [802.1X], защиты MAC [802.1AE] или агрегирования каналов [802.1AX].

Однако RBridge не используют связующее дерево и не блокируют порты, как это делает STP. На рисунке 4 показана высокоуровневая диаграмма RBridge с одним портом, подключенным к каналу IEEE 802.3. Одинарные линии представляют поток управляющей информации, двойные — поток кадров и управляющей информации.

Верхний интерфейс к низкоуровневой логике управления портом/каналом соответствует ISS⁸ в [802.1Q-2005]. В RBridge кадры управления высокого уровня обрабатываются над интерфейсом ISS.

Верхний интерфейс к обработке VLAN и приоритета соответствует EISS⁹ в [802.1Q-2005]. В RBridge естественные и TRILL-кадры обрабатываются над интерфейсом EISS и относятся к обработке VLAN и приоритета.

2.6.2. Поэтапное развертывание

Поскольку маршрутизирующие мосты RBridge совместимы с пользовательскими мостами IEEE [802.1Q-2005] с некоторыми отмеченными в этом документе исключениями, ЛВС на основе мостов можно обновлять постепенно, заменяя традиционные мосты на RBridge. Мосты, которые пока не заменены, будут прозрачны для трафика RBridge. Физические каналы, напрямую соединяющие такие мосты, и сами эти мосты образуют ЛВС. Такая ЛВС на основе мостов с точки зрения RBridge будет выглядеть каналами с множественным доступом.

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

Поскольку RBridge (как описано в этом документе) обеспечивают лишь обслуживание пользователей, они не могут заменить PB или PBB, как пользовательский мост не может заменить провайдерский. Однако такие провайдерские устройства могут быть частью ЛВС на базе мостов между устройствами RBridge. Расширение TRILL для поддержки провайдерских услуг оставлено на будущее и будет описано в отдельных документах.

                      +-----------------------------------------
                      |                RBridge
                      |
                      |     Машина пересылки, IS-IS, etc.
                      | Обработка естественных и TRILL-кадров
                      |
                      +----+---+--------++----------------------
                           |   |        ||       другие порты...
             +-------------+   |        ||
             |                 |        ||
+------------+-------------+   |        ||
|         RBridge          |   |   +----++-------+ <- EISS
|                          |   |   |             |
|Обработка кадра управления|   |   | 802.1Q-2005 |
|верхнего уровня(BPDU, VRP)|   |   |  Обработка  |
|                          |   |   |  Port VLAN  |
+-----------++-------------+   |   |  и Priority |
            ||                 |   |             |
  +---------++-----------------+---+-------------+ <-- ISS
  |                                              |
  |    Обработка кадра управления нижнего уровня |
  |    802.1/802.3, логика управления Port/Link  |
  |                                              |
  +-----------++---------------------------------+
              ||
              ||        +------------+
              ||        | 802.3 PHY  |
              |+--------+ (физический+--------- Канал
              +---------+ интерфейс) +--------- 802.3
                        |            |
                        +------------+

Рисунок 4. Модель порта RBridge.

При замене мостов с настройками на уровне порта протоколов типа управления доступом по портам [802.1X] или защиты на уровне MAC [802.1AE] в устанавливаемых RBridge потребуется аналогичная настройка для таких протоколов. В дополнение к этому устанавливаемые RBridge должны поддерживать тот же тип канала и протоколы канального уровня, какие использовались на заменяемых мостах.

Кампус RBridge будет работать лучше всего при замене всех мостов IEEE [802.1D] и [802.1Q-2005] на RBridge, если маршрутизирующие мосты RBridge имеют такую же скорость и производительность. Однако на промежуточных этапах обновления повышение производительности будет не столь велико по причине замены на RBridge лишь части мостов.

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

3. Детали заголовка TRILL

В этом разделе описан заголовок TRILL, а другие детали устройства RBridge рассмотрены в разделе 4.

3.1. Формат заголовка TRILL

Заголовок TRILL показан на рисунке 5 и не зависит от используемого канального уровня. Для канального уровня IEEE [802.3] используется префикс в виде 16-битового поля TRILL Ethertype [RFC5342], обеспечивающего выравнивание по 64-битовой границе. Если значение Op-Length кратно 64 битам, обеспечивается обычное выравнивание содержимого инкапсулированного кадра.

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

V (Version) — 2-битовое целое число без знака (параграф 3.2).
R (Reserved) — 2 бита (параграф 3.3).
M (Multi-destination) — 1 бит (параграф 3.4).
Op-Length (Options Length) — 5-битовое целое число без знака (параграф 3.5).
Hop Count — 6-битовое целое число без знака (параграф 3.6).
Egress RBridge Nickname — 16-битовый идентификатор (параграф 3.7.1).
Ingress RBridge Nickname: 16-битовый идентификатор (параграф 3.7.2).
Опции присутствуют при отличном от 0 поле Op-Length (параграф 3.8).

                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Egress RBridge Nickname     |  Ingress RBridge Nickname     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Опции...
+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 5. Заголовок TRILL.

3.2. Версия (V)

Поле версии (V) имеет размер 2 бита и данный документ задает TRILL версии 0. RBridge RB1 должен проверять значение поля V в полученных кадрах с инкапсуляцией TRILL. Если поле V имеет не понятное RB1 значение, RB1 должен отбрасывать кадр без уведомления отправителя. Выделение новых значений номера версии TRILL происходит по процедуре IETF Standards Action.

3.3. Резерв (R)

Два бита R зарезервированы для использования в будущих расширениях нулевой версии протокола TRILL. Эти поля должны устанавливаться в 0 при добавлении заголовка TRILL на входном RBridge, прозрачно копироваться без обработки транзитными RBridge и игнорироваться выходнымы RBridge. Распределение резервных битов TRILL должно происходить по процедуре IETF Standards Action.

3.4. Множество получателей (M)

Бит M (параграф 2.4.2) указывает, что кадр доставляется некому классу конечных станций через дерево распространения, заданное псевдонимом выходного RBridge.

M = 0 (FALSE) — поле Egress RBridge Nickname содержит псевдоним выходного RBridge для известного индивидуального MAC-адреса.
M = 1 (TRUE) — поле Egress RBridge Nickname содержит псевдоним, который задает дерево распространения. Псевдоним выбирается входным RBridge для кадра данных TRILL или исходным RBridge для TRILL ESADI.

3.5. Op-Length

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

Поле заголовка Op-Length указывает размер опций заголовка TRILL в 4-октетных блоках, что позволяет использовать опции суммарным размером до 124 октетов. Нулевое значение Op-Length говорит об отсутствии опций. При наличии опций они размещаются непосредственно за полем Ingress RBridge Nickname.

Информация о поддерживаемых опциях TRILL приведена в параграфе 3.8.

3.6. Счетчик интервалов

Поле счетчика интервалов Hop Count представляет собой 6-битовое целое число без знака. RBridge отбрасывает кадры с нулевым значением счетчика, а в остальных случаях декрементирует значение поля (это отличается от IPv4 и IPv6 для поддержки последующего добавления функции типа traceroute, позволяющей получить информацию о превышении счетчика интервалов от выходного RBridge).

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

Для кадров с множеством получателей входному RBridge (или исходному RBridge для кадров TRILL ESADI) следует устанавливать в поле Hop Count значение не меньше ожидаемого числа интервалов до самого удаленного RBridge. Для решения этой задачи RBridge RBn рассчитывает для каждой ветви от RBn указанного дерева распространения с корнем Rbi число интервалов пересылки в ветви и выбирает максимальное значение.

Кадры с множеством адресатов представляют некоторую опасность, поскольку петля, включающая одно или несколько разветвлений дерева распространения, приводит к быстрой генерации множества копий кадра даже при использовании механизма подсчета интервалов. Именно по этой причине кадры с множеством адресатов подвергаются строгой проверке пересылки по обратному пути и другим проверкам, описанным в параграфе 4.5.2. В качестве дополнительной меры управления трафиком при пересылке кадра с множеством адресатов в ветвь дерева распространения транзитный RBridge RBm может уменьшить значение счетчика интервалов более чем на 1, если это не приводит к недоступности адресатов в данной ветви дерева распространения с корнем Rbi. Использование счетчика интервалов близкого или равного минимальному требуемому для кадров с множеством адресатов обеспечивает дополнительную защиту от проблем пересылки, связанных с временными петлями.

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

3.7. Псевдонимы RBridge

Псевдонимы представляют собой 16-битовые значения, которые назначаются динамически и служат сокращением для идентификаторов RBridge IS-IS ID, обеспечивающим более компактное представление, и могут использоваться для указания потенциально различных деревьев распространения с общим корнем. Такой подход позволяет обозначить до 2¹⁶ RBridge, однако значение 0x0000 зарезервировано для указания отсутствия псевдонима, диапазон 0xFFC0 — 0xFFFE зарезервирован для будущих спецификаций, а значение 0xFFFF зарезервировано навсегда. RBridge комбинируют протокол получения псевдонимов с протоколом маршрутизации по состоянию канала (параграф 3.7.3) для получения одного или множества псевдонимов, уникальных в масштабе кампуса.

3.7.1. Псевдоним выходного RBridge

Существует два варианта содержимого поля Egress RBridge Nickname в зависимости от бита M (параграф 3.4). Псевдоним задается входным RBridge для кадров данных TRILL и исходным RBridge для кадров TRILL ESADI.

Для заведомо индивидуальных кадров данных TRILL бит M = 0 и поле Egress RBridge Nickname задает выходной RBridge, т. е. RBridge который должен удалить инкапсуляцию TRILL и переслать естественный кадр. После установки поля Egress RBridge Nickname его недопустимо менять на последующих транзитных RBridge.
Для кадров данных TRILL с множеством получателей и кадров TRILL ESADI бит M = 1. Поле Egress RBridge Nickname содержит псевдоним, задающий дерево распространения, выбранное для пересылки кадра. Этот корневой псевдоним недопустимо менять на транзитных RBridge.

3.7.2. Псевдоним входного RBridge

В поле Ingress RBridge Nickname указывается псевдоним входного RBridge для кадров данных TRILL и псевдоним исходного RBridge для кадров TRILL ESADI. Если в конфигурации RBridge входной псевдоним имеет множество значений, следует использовать один и тот же псевдоним в поле Ingress RBridge Nickname при инкапсуляции кадров с любыми значениями Inner.MacSA и Inner.VLAN. Это упрощает определение (learning) конечных узлов.

После установки поля Ingress RBridge Nickname его недопустимо менять на последующих транзитных RBridge.

3.7.3. Выбор псевдонима RBridge

Протокол выбора псевдонима работает на основе TRILL IS-IS, как показано ниже.

Псевдоним или псевдонимы для использования RBridge передаются в IS-IS TLV¹⁰ вместе приоритетом [RFC6326]. Каждый RBridge выбирает свои псевдонимы самомстоятельно.
Значения псевдонимов могут быть настраиваемыми. RBridge, на котором настроен один или множество псевдонимов, будет иметь приоритет на использование этих значений пред всеми RBridge, у которых нет настроенного псевдонима.
Значение 0x0000 и диапазон 0xFFC0 — 0xFFFF зарезервированы и их недопустимо выбирать для настройки RBridge. Значение 0x0000 служит для индикации того, что псевдоним не известен.
Приоритет использования поля, сообщаемый с псевдонимом, является 8-битовым целым числом без знака, в котором старший бит (0x80) показывает, что значение псевдонима задано. Для 7 младших битов по умолчанию используется значение 0x40, но может быть задано другое значение. Кроме того, RBridge может увеличить приоритет после удержания псевдонима в течение некоторого времени. Однако установка старшего бита недопустима, если псевдоним не задан в конфигурации.
После получения псевдонима RBridge ему следует пытаться применять тот же псевдоним после перезагрузки.
Каждый RBridge отвечает за уникальность каждого из своих псевдонимов. Если RB1 выбрал себе псевдоним x, а затем обнаружил из сообщения LSP для RB2, что тот также выбрал псевдоним x, тогда RBridge или псевдоузел с численно большим приоритетом сохраняет свой псевдоним или его сохраняет RBridge с численно большим IS-IS System ID, если имеется привязка приоритетов, а другой RBridge должен выбрать новый псевдоним¹¹. Это может потребовать замены псевдонима RBridge, заданного в конфигурации.
Для снижения вероятности совпадения псевдонимов RBridge выбирает псевдоним случайно из числа представляющихся доступными на основе своей копии состояния канала. Этот случайный выбор может происходить путем хэширования RBridge некоторых своих параметров типа SystemID, даты и времени, а также дугих источников энтропии типа приведенных в [RFC4086] каждый раз или с использованием таких хэш-значений для создания «затравки» (seed) и выбора на основе псевдослучайных значений, созданных с этой затравкой [RFC4086]. Случайным значениям или затравке, а также применяемому алгоритму следует обеспечивать равномерное распределение значений, выбираемых из пространства доступных псевдонимов. Схождение бесконфликтного распределения псевдонимов в кампусе может быть ускорено путем выбора новых псевдонимов лишь из числа тех, которые представляются доступными, и выбора при конфликте псевдонима с более высоким приоритетом из числа вовлеченных в конфликт. Не обязательно применять один алгоритм выбора псевдонимов для всех RBridge.
При слиянии двух кампусов RBridge возможны временные конфликты псевдонимов. Как только каждый RBridge получает LSP от других RBridge, устройство RBridge, которому нужно сменить псевдоним выбирает новые псевдонимы, которые представляются не конфликтующими с имеющимися псевдонимами. Некоторым RBridge может потребоваться неоднократная смена псевдонима в процессе разрешения конфликта.
Для снижения вероятности узурпирования новым RBridge уже используемого псевдонима устройству RBridge следует дождаться получения от соседа базы данных о состоянии каналов, прежде чем анонсировать какие-либо псевдонимы, не заданные в конфигурации.
По умолчанию RBridge имеет лишь один псевдоним, но может быть настроен на запрос множества псевдонимов. Каждый такой псевдоним будет задавать дерево кратчайшего пути с корнем RBridge, в результате использования номера дерева при разрыве лишних связей (tiebreaking) в случае наличия равноценных путей (параграф 4.5.1), деревья для разных псевдонимов вероятно будут использовать разные каналы. По причине связанной с расчетом деревьев нагрузки запросом множества псевдонимов для RBridge следует пользоваться экономно. Например, это следует использовать на нескольких RBridge, которые в топологии кампуса хорошо подходят в качестве мест для расчета разных деревьев распространения кратчайших путей. Таким деревьям нужны разные псевдонимы, поскольку трафик может идти разными путями.
Если нужно сделать корнем дерева псевдоузел, DRB может запросить один или несколько псевдонимов в LSP псевдоузла.

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

3.8. Опции заголовка TRILL

Все RBridge должны быть способны пропускать заданное полем Op-Length число 4-октетных блоков (параграф 3.5) для нахождения внутреннего кадра, поскольку RBridge должны находить MAC-адрес получателя и тег VLAN во внутреннем кадре. Транзитным RBridge такая информация нужна для фильтрации VLAN, групповой адресации IP и т. п. Выходным RBridge внутренний заголовок нужен для корректной декапсуляции и обработки внутреннего кадра.

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

+------+------+----+----+----+----+----+----+
| CHbH | CItE |          Reserved           |
+------+------+----+----+----+----+----+----+

Рисунок 6. Начальный октет флагов в области опций.

Установленный бит CHbH указывает наличие хотя бы одной критической поэтапной (hop-by-hop) опции. Транзитные RBridge, которые не поддерживают присутствие таких опций (например, RBridge без поддержки опций), должны отбрасывать такие кадры. Если ChbH=0, кадр является безопасным с точки зрения обработки опций для пересылки транзитными узлами, независимо от поддержки опций данным RBridge. Транзитный RBridge, который не поддерживает присутствующих опций, должен просто пересылать область опций в кадре.

Установленный бит CItE указывает наличие хотя бы одной критической сквозной (ingress-to-egress) опции. Сброшенный бит говорит об отсутствии таких опций. Если любой из флагов CHbH и CItE установлен, входные RBridge, которые не поддерживают всех имеющихся критических опций (например, RBridge совсем не поддерживающий опций), должны отбросить такой кадр. Если оба флага CHbH и CItE сброшены, кадр является безопасным с точки зрения опций для обработки любым RBridge, независимо от поддержки им тех или иных опций.

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

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

4. Другие детали устройства RBridge

В разделе 3 был описан заголовок TRILL, а в этом разделе рассмотрены другие внутренние детали RBridge.

4.1. Инкапсуляция данных Ethernet

Кадры TRILL с данными и ESADI для передачи по каналам Ethernet инкапсулируются с использованием внешнего заголовка Ethernet (Рисунок 2). Этот внешний заголовок для моста на пути между двумя RBridge выглядит как заголовок обычного кадра Ethernet, поэтому мосты будут пересылать кадры обычным способом. Чтобы RBridge могли отличать такие кадры данных TRILL, во внешнем заголовке используется новое значение TRILL Ethertype (параграф 7.2).

На рисунке 7 показан кадр TRILL Data с внешним тегом VLAN, проходящий через канал Ethernet, как показано в верхней части рисунка, между транзитными RBridge RB3 и RB4. Естественный кадр от конечной станции Esa был инкапсулирован входным RBridge RB1, а затем декапсулирован выходным RBridge RB2 и доставлен адресату Esb. Показанная инкапсуляция будет более эффективна при отсутствии опций TRILL или наличии опций, размер которых кратен 64 битам, за счет выравнивания исходного кадра Ethernet по 64-битовой границе.

При передаче кадра TRILL Data через облако Ethernet, он будет включать три пары адресов, указанные ниже.

Внешний заголовок Ethernet. Внешние MAC-адреса получателя (Outer.MacDA) и отправителя (Outer.MacSA). Эти адреса служат для указания следующего RBridge и передающего RBridge, соответственно.
Заголовок TRILL. Egress Nickname и Ingress Nickname указывают псевдонимы выходного и входного RBridge, соответственно, если кадр не имеет множества получателей (в последнем случае Egress Nickname задает дерево распространения, в которое кадр будет передаваться).
Внутренний заголовок Ethernet. Внутренние MAC-адреса получателя (Inner.MacDA) и отправителя (Inner.MacSA). Эти адреса указываются отправителем исходного кадра.

Поток
     +-----+  +-------+   +-------+       +-------+   +-------+  +----+
     | ESa +--+  RB1  +---+  RB3  +-------+  RB4  +---+  RB2  +--+ESb |
     +-----+  |ingress|   |transit|   ^   |transit|   |egress |  +----+
              +-------+   +-------+   |   +-------+   +-------+
                                      |
Внешний заголовок Ethernet            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Внешний MAC-адрес получателя (RB4)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Внешний MAC-адрес получателя  | Внешний MAC-адрес отправителя |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Внешний MAC-адрес отправителя (RB3)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Заголовок TRILL
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = TRILL             | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress (RB2) Nickname         | Ingress (RB1) Nickname        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Внутренний заголовок Ethernet
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Внутренний MAC-адрес получателя  (ESb)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Внутренний MAC-адрес получателя|Внутренний MAC-адрес отправит. |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Внутренний MAC-адрес отправителя  (ESa)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Данные
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype исходных данных     |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                  Исходные данные Ethernet     |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FCS
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Новая FCS (Frame Check Sequence)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Инкапсуляция TRILL Data для Encapsulation over Ethernet.

Кадр данных TRILL может также иметь два тега VLAN, как описано ниже в параграфах 4.1.2 и 4.1.3, для передачи двух разных идентификаторов VLAN и задания приоритета.

4.1.1. Информация тега VLAN

Тег VLAN (раньше назывался Q-тегом), известный также как C-тег для пользовательских тегов, включает идентификатор VLAN ID и поле приоритета, как показано на рисунке 8. Поле VLAN ID может иметь значение 0, если VLAN не указана и тег просто задает приоритет, хотя обычно такие кадры называют priority tagged, а не VLAN tagged [802.1Q-2005].

Использование S-тегов [802.1ad], которые называют также тегами сервиса, и стеки тегов выходят за рамки этого документа.

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Priority  | C |                  VLAN ID                      |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Рисунок 8. Информация тега VLAN.

Как рекомендовано в [802.1Q-2005], RBridge следует реализовать так, чтобы обеспечивалась возможность использовать полный диапазон VLAN ID от 0x001 до 0xFFE. Маршрутизирующие мосты RBridge могут поддерживать меньшее число одновременно активных VLAN ID. VLAN ID = 0 указывает, что VLAN не задана, а значение VLAN ID = 0xFFF зарезервировано.

Использование VLAN ID 0xFFF недопустимо. RBridge должны отбрасывать все принятые кадры с Outer.VLAN ID = 0xFFF. RBridge должны отбрасывать все кадры, для которых проверка Inner.VLAN ID дала значение 0xFFF (такая проверка требуется на всех выходных RBridge, которые декапсулируют кадры).

Бит C, показанный на рисунке 8, не используется в Inner.VLAN протокола TRILL. Он должен устанавливаться в 0 входными RBridge, передаваться без изменения транзитными и игнорироваться выходными RBridge.

Как указано в [802.1Q-2005], поле Priority содержит целое число без знака от 0 до 7, где 1 указывает низший приоритет, 7 — высший, а 0 указывает приоритет выше уровня 1, но ниже уровня 2. Поправка [802.1ad] к стандарту [802.1Q-2005] разрешает отображение некоторых смежных пар уровней приоритета на один уровень с правом или без права отбрасывания. Текущая работа IEEE 802.1 (802.1az, Appendix E) предлагает возможность настройки «групп приоритетов», которым предоставляются некие гарантии пропускной способности. Порты RBridge тоже могут реализовать такие опции. Маршрутизирующим мостам RBridge не обязательно реализовать любое определенное число различающихся уровней приоритета, но они могут трактовать несколько смежных уровней таким способом.

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

C-Tag Ethertype [RFC5342] имеет значение 0x8100.

4.1.2. Внутренний тег VLAN

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

При получении RBridge естественных кадров связанные с ним VLAN ID и приоритет определяются в соответствии с [802.1Q-2005] (см. Приложение D и параграф 6.7 в [802.1Q-2005]). Если RBridge является назначенным устройством пересылки для VLAN и доставка кадра требует передачи в один или множество других каналов, входной RBridge созлает кадр данных TRILL с VLAN ID и приоритетом на основе Inner.VLAN.

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

4.1.3. Внешний тег VLAN

В кадрах TRILL, передаваемых RBridge, за исключением некоторых кадров TRILL-Hello, используется значение Outer.VLAN ID, заданной назначенным RBridge (DRB) для канала, в который кадры передаются. Этот идентификатор называется Designated VLAN. Для кадров данных TRILL и кадров ESADI в качестве приоритета в теге Outer.VLAN следует указывать приоритет из Inner.VLAN tag.

В кадрах TRILL, пересылаемых транзитным RBridge, используется приоритет из Inner.VLAN полученного кадра. Кадры TRILL Data передаются с приоритетом, связанным с соответствующим естественным кадром, который был получен (Приложение D). Кадры TRILL IS-IS следует передавать с приоритетом 7.

Реальное присутствие тега Outer.VLAN при передаче кадра TRILL в среду зависит от настройки порта RBridge, через который передается кадр, так же, как наличие тега VLAN при передаче кадра мостом [802.1Q-2005] зависит от настройки порта (параграф 4.9.2).

4.1.4. Контрольная сумма FCS

Каждый кадр Ethernet включает контрольную сумму FCS¹², которая рассчитывается для всего кадра и служит для обнаружения проблем, связанных с битовыми ошибками при передаче в канале. Таким образом, при инкапсуляции кадра исходное значение FCS не включается и отбрасывается. Все кадры, принятые с ошибкой FCS, следует отбрасывать (это может быть невозможно при «сквозной» (cut through) коммутации). Поле FCS обычно меняется при инкапсуляции, декапсуляции и на каждом интервале TRILL в результате изменения внешних адресов получателя и отправителя, декрементирования счетчика интервалов и т. п.

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

4.2. Протокол на основе состояния каналов (IS-IS)

TRILL использует расширение IS-IS [ISO10589] [RFC1195] в качестве протокола маршрутизации. IS-IS обеспечивает два преимущества:

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

В этом параграфе описано использование в TRILL протокола IS-IS без протокола TRILL-Hello, который отдельно описан в параграфе 4.4, а также сообщений MTU-probe и MTU-ack, описанных в параграфе 4.3.

4.2.1. Отождествление RBridge для IS-IS

Каждый RBridge имеет уникальный 48-битовый (6 октетов) идентификатор IS-IS System ID, который может быть создан на основе любого уникального MAC-адреса RBridge.

Псевдоузел получает 7-октетный идентификатор от создавшего его DRB, путем добавления 1 октета к имеющемуся у DRB 6-октетному идентификатору. В качестве 6-октетного идентификатора для создания идентификатора псевдоузла следует применять идентификатор DRB, пока этот DRB не создает идентификаторов псевдоузлов больше чем для 255 каналов. Единственным требованием является уникальность 7-октетных идентификаторов в рамках кампуса и отличное от 0 значение седьмого октета. RBridge имеет 7-октетный идентификатор, состоящий из 6-октетного идентификатора системы и седьмого октета со значением 0.

В этом документе IS-IS ID используется для обозначения 7-октетного значения, которое может быть идентификатором RBridge или псевдоузла.

4.2.2. Экземпляры IS-IS

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

Естественные кадры L3 IS-IS используют специальные групповые адреса получателей типа AllL1ISs или AllL2ISs. При инкапсуляции TRILL эти групповые адреса отображаются как Inner.MacDA, а Outer.MacDA будет групповым адресом All-RBridges.

В рамках TRILL имеется экземпляр IS-IS для всех RBridge в кампусе, как описано в параграфе 4.2.3. Этот экземпляр использует кадры TRILL IS-IS, которые отличаются по Ethertype L2-IS-IS. Кроме того, для групповых кадров TRILL IS-IS имеется специальный групповой адрес All-IS-IS-RBridges. Кадры TRILL IS-IS не имеют заголовка TRILL.

ESADI является отдельным протоколом, отличающимся от экземпляра IS-IS, реализованного на всех RBridge. Отдельный экземпляр ESADI используется для каждой VLAN и кадры ESADI инкапсулируются подобно кадрам данных TRILL. После заголовка TRILL в кадрах ESADI размещается внутренний заголовок Ethernet с Inner.MacDA = All-ESADI-Rbridges и Ethertype = L2-IS-IS, за которым следует кадр ESADI.

4.2.3. Кадры TRILL IS-IS

Все RBridge должны принимать участие в работе экземпляра TRILL IS-IS, что создает единую область L1 IS-IS с нулевым адресом. Кадры TRILL IS-IS никогда не пересылаются RBridge и при получении обрабатываются локально (такая обработка может заставить RBridge передать дополнительные кадры TRILL IS-IS).

Кадр TRILL IS-IS на канале 802.3 имеет показанную ниже структуру. Все такие кадры кодируются в Ethertype. Порт RBridge, из которого передается такой кадр, будет вырезать внешний тег VLAN, если это задано в его конфигурации.

VLAN, указанная в Outer.VLAN, будет назначенной (Designated) VLAN для канала, в который передается кадр, за исключением некоторых случаев TRILL Hello.

Внешний заголовок Ethernet
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Групповой адрес All-IS-IS-RBridges                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-IS-IS-RBridges (продолж.) | Source RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Source RBridge MAC Address (продолжение)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   L2-IS-IS Ethertype          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Данные IS-IS
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Общий заголовок IS-IS, поля IS-IS PDU, IS-IS TLV         |

FCS
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 FCS (Frame Check Sequence)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Формат кадра TRILL IS-IS.

4.2.4. Приветствия TRILL, DRB и назначенные устройства пересылки

RBridge используют TRILL Hello, если только на уровне портов не настроено использование P2P Hello. Кадры TRILL-Hello описаны в параграфе 4.4.

RBridge обычно настраиваются на использование P2P Hello лишь в тех случаях, когда на канале имеется лишь два устройства. Однако могут возникать случаи когда настройка типа приветствий в RBridge ошибочна. Это не представляет опасности, но может снижать уровень связности между RBridge. Порт RBridge, настроенный на использование P2P Hello, игнорирует TRILL Hello и наоборот.

Если любой из портов RBridge на канале настроен на использование TRILL Hello, один из использующих TRILL Hello портов RBridge выбирается DRB (назначенный RBridge) для канала. Этот выбор основан на заданном в конфигурации приоритете (старшее поле) и MAC-адресе отправителя в кадрах TRILL-Hello. DRB, как описано в параграфе 4.2.4.2, назначает VLAN для использования на канале в коммуникациях между RBridge через порты, не являющиеся P2P RBridge, и назначает себя или другой RBridge на канале узлом пересылки (параграф 4.2.4.3) для VLAN на этом канале.

4.2.4.1. Каналы с P2P Hello

Порты RBridge можно настроить на использование IS-IS P2P Hello. Это предполает, что порт использует для соединения с другим RBridge соединение «точка-точка». RBridge недопустимо обслуживать какие-либо конечные станции (естественные кадры) на портах, настроенных на использование P2P Hello.

Как и в случае L3 IS-IS, такие порты P2P не участвуют в выборе DRB. Они передают все кадры с тегами VLAN как относящиеся к желаемой назначенной (Desired Designated) VLAN, настроенной для порта, хотя тег может быть вырезан при соответствующей настройке порта. Поскольку весь трафик через порт должен представлять кадры TRILL или кадры управления L2, такой порт не может быть назначенным узлом пересылки. Порты RBridge P2P должны использовать треэтапное согласование IS-IS [RFC5303], чтобы с каналом были связаны расширенные идентификаторы устройств для целей прерывания (параграф 4.5.2).

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

Хотя ошибочная настройка портов как P2P не создает опасностей, она может приводить к потере связности.

4.2.4.2. Назначенный RBridge

TRILL IS-IS выбирает один RBridge для каждого канала ЛВС в качестве назначенного RBridge (DRB), выполняющего особые функции, перечисленные ниже.

Выбор для канала и анонсирование в TRILL Hello идентификатора назначенной VLAN ID для использования в коммуникациях между RBridge. Эта VLAN используется для всех кадров данных с инкапсуляцией TRILL, кадров ESADI и кадров TRILL IS-IS за исключением некоторых кадров TRILL-Hello.
Если канал представлен в топологии IS-IS как псевдоузел, выбор идентификатора этого псевдоузла и анонсирование его в TRILL Hello, а также выпуск LSP от имени псевдоузла.
Выпуск CSNP.
Для каждой VLAN-x на канале выбор RBridge в качестве назначенного устройства пересылки VLAN-x (DRB может выбрать себя в качестве назначенного узла пересылки VLAN-x для всех или некоторых VLAN).
Перед назначением узла пересылки VLAN-x (включая самого себя) ожидание не менее Holding Time (чтобы убедиться в том, что реально является DRB).
Если настроена передача кадров TRILL-Hello, продолжение их отправки во все разрешенные VLAN, которые были указаны а наборе Announcing VLANs этого DRB (по умолчанию все разрешенные VLAN).

4.2.4.3. Назначенное устройство пересылки VLAN-x

Назначенный узел пересылки VLAN-x для канала отвечает за перечисленные ниже вопросы. В канале с точками предотвращения петель узел пересылки для порта, находящийся в состоянии inhibited (заблокирован), отбрасывает получаемые естественные кадры, не пересылая их, но все естественные кадры VLAN, для которой он назначен, узел не отбрасывает, а декапсулирует.

Предотвращение петель.
- Блокировка самого себя на задаваемое в конфигурации порта время от 0 до 30 секунд (по умолчанию) после обнаружения смены корневого моста на канале (параграф 4.9.3.2).
- Блокировка самого себя для VLAN-x при получении кадра Hello, в котором отправитель заявляет себя назначенным узлом пересылки и который:
  - принят в VLAN-x (имеет VLAN-x в качестве Outer.VLAN) или
  - был изначально передан в VLAN-x, как указано в теле Hello.
- Необязательный отказ от декапсуляции кадра от входного RBridge Rbm, если у него LSP этого RBm, а корневой мост на канале, в который следует пересылать не указан в списке корневых мостов RBm для VLAN-x. Это называется «проверкой декапсуляции» (decapsulation check) или «проверкой конфликта корневых мостов» (root bridge collision check).
Пока нет блокировки (см. выше), прием естественного трафика VLAN-x и соответствующая пересылка его.
Прием трафика VLAN-x для канала и (пока нет блокировки), передача его в естественной форме после декапсуляции.
Определение (learning) MAC-адреса локальных узлов VLAN-x путем просмотра адреса отправителя в кадрах VLAN-x из канала.
Необязательное определение (learning) порта локальных узлов VLAN-x на основе любых протоколов регистрации L2 типа ассоциаций и аутентификации IEEE 802.11.
Отслеживание комбинаций {входной RBridge, VLAN, MAC-адрес} удаленных конечных узлов VLAN-x, определенных путем просмотра полей {входной RBridge, Inner.VLAN ID, Inner.MacSA} в кадрах VLAN-x принимаемых для декапсуляции в канал.
Необязательное наблюдение естественных кадров IGMP [RFC3376], MLD [RFC2710] и MRD [RFC4286] для определения наличия локальных получателей группового трафика и групповых маршрутизаторов.
Необязательное прослушивание сообщений TRILL ESADI для VLAN-x с целью определения триплетов {входной RBridge, VLAN-x, MAC-адрес} и уровня доверия к таким явно анонсируемым конечным узлам.
Необязательное анонсирование в сообщениях ESADI конечных узлов VLAN-x на каналах, для которых выполняются функции назначенного узла пересылки.
Передача кадров TRILL-Hello в VLAN-x, если набор Announcing VLANs, заданный для порта, не запрещает это.
Прослушивание BPDU на общем связующем дереве для определения корневого моста (если он есть) на канале и указания в своем LSP полного набора корневых мостов, видимых на всех каналах, для которых выполняются функции назначенного узла пересылки для VLAN-x.

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

4.2.4.4. Информация TRILL LSP

Ниже перечислены информационные элементы TRILL IS-IS LSP, упоминаемые в этом документе. Элементы, не указанные в списке как необязательные, должны включаться всегда. Остальные элементы можно включать, если это явно не запрещено в данном документе. Реальное представление этой информации, а также значения типа и подтипа IS-IS для всех новых элементов данных TLV заданы в отдельных документах [RFC6165] [RFC6326].

Идентификаторы соседей IS-IS (псевдоузлы и RBridge) маршрутизирующего моста RBridge RBn и стоимость каналов до каждого из этих соседей. RBridge должны использовать Extended IS Reachability TLV (#22 или «метрика ширины» [RFC5305]), а использование IS Reachability TLV (#2 или «метрика узости») недопустимо. Для упрощения эффективной работы без настройки конфигурации и в соответствии с [802.1D] RBridge следует устанавливать по умолчанию в качестве стоимости канала целую часть результата деления числа 20 000 000 000 000 (двадцать триллионов) на скорость порта RBridge, но не более 2²⁴-2 (16 777 214). Например, стоимость канала в порт 1 Гбит/с составит 20 000 (отметим, что число 2²⁴-1 имеет в IS-IS специальное значение и будет исключать канал из маршрутов SPF). Принятая по умолчанию стоимость канала может быть уменьшена для агрегированных соединений и/или увеличена до значения, не превышающего 2²⁴-2, если канал является ЛВС на базе мостов. Проверенное значение MTU для канала (параграф 4.3) может включаться в суб-TLV.
Указанная ниже информация в сочетании с каждым псевдонимом RBridge RBn:
1. значение псевдонима (2 октета);
2. 8-битовое целое число без знака, указывающее приоритет RBn для данного псевдонима (параграф 3.7.3);
3. 16-битовое целое число без знака, указывающее приоритет данного псевдонима при выборе корня дерева распространения.
Максимальный номер версии заголовка TRILL, поддерживаемой RBridge RBn.
Приведенная ниже информация в дополнение к приоритету корня дерева на уровне псевдонима вкупе с определением и анонсированием дерева распространения (использование этой информации рассмотрено в параграфе 4.5).
1. 16-битовое целое число без знака, указывающее количество деревьев всех RBridge в кампусе, которое вычисляется в случае когда RBn имеет корень дерева с высшим приоритетом.
2. 16-битовое целое число без знака, указывающее количество деревьев, которые будет использовать RBn.
3. 16-битовое целое число без знака, указывающее максимальное количество деревьев, которые RBn способен рассчитать.
4. Список псевдонимов, предназначенных для расчета деревьев распространения на всех RBridge в кампусе.
5. Список псевдонимов, являющихся деревьями распространения, которые RBn может использовать, выступая в качестве входа для кадров со множеством получателей.
Список идентификаторов VLAN, подключенных непосредственно к Rbn для каналов, на которых RBn является назначенным узлом пересылки для этих VLAN¹³. RBridge могут связывать анонсируемые соединения для разных групп VLAN с конкретными псевдонимами, которыми они владеют. В дополнение к этому LSP содержит указанную ниже информацию для каждой VLAN.
1. Флаги подключенных групповых маршрутизаторов для VLAN. Это два бита информации, которые указывают наличие подключенного к RBridge группового маршрутизатора IPv4 и/или IPv6 для данной VLAN. RBridge, который не отслеживает управление групповой адресацией IP, должен устанавливать оба эти флага (параграф 4.5.4). Эта информация используется, поскольку отчеты о принадлежности к группам IGMP [RFC3376] и MLD [RFC2710] должны передаваться во все каналы с групповыми маршрутизаторами IP, а в каналы без таких маршрутизаторов передавать их не следует. Кроме того, все кадры для полученных от IP групповых адресов должны передаваться во все каналы с групповыми маршрутизаторами IP (в данной VLAN) в дополнение к каналам, откуда узел IP явно запросил включение в группу, для которой предназначен кадр, за исключением некоторых групповых адресов IP, которые должны трактоваться как широковещательные.
2. Для каждой VLAN обязательный анонс набора идентификаторов корневых мостов для всех каналов RBn, на которых RBn назначен узлом пересылки для данной VLAN. При использовании на канале протокола MSTP это будет корневой мост CIST¹⁴. Это нужно для быстрого обнаружения ситуаций, когда два облака L2 случайно сливаются, поскольку без этого временно могут существовать два DRB для одной VLAN на одном канале (параграф 4.2.4.3.).
3. (Необязательно) для каждой VLAN групповые адреса L2, выведенные из уведомлений IPv4 IGMP и IPv6 MLD, полученных от присоединенных конечных узлов данной VLAN, с указанием местоположения получателей для этих групповых адресов (параграф 4.5.5).
4. Для каждой VLAN флаг участия в протоколе ESADI, приоритет и время удержания. Установленный флаг показывает желание RBridge получать такие кадры TRILL ESADI (параграф 4.2.5.1).
5. Для каждой VLAN счетчик потерь статуса назначенного узла пересылки (параграф 4.8.3).
(Необязательно) размер наибольшего кадра TRILL IS-IS, который RBridge может обрабатывать с использованием originatingLSPBufferSize TLV #14 (параграф 4.3).
(Необязательно) список групп VLAN, где определение адресов выполняется совместно во всей группе VLAN (параграф 4.8.4). Каждая группа VLAN является списком идентификаторов VLAN, где первый идентификатор является «основным», а все прочие — «вторичными». Это служит для обнаружения некорректных конфигураций и выходит за рамки данного документа. RBridge, не поддерживающие совместное определение адресов VLAN, игнорируют это поле.
(Необязательно) Authentication TLV #10 (раздел 6).

4.2.5. Протокол TRILL ESADI

Маршрутизирующие мосты RBridge, которые назначены узлами пересылки VLAN-x для канала, могут принимать участие в работе протокола TRILL ESADI для этой VLAN. Все транзитные RBridge должны корректно пересылать кадры TRILL ESADI, как будто они являются групповыми кадрами данных TRILL. Кадры TRILL ESADI структурно похожи на кадры IS-IS, но всегда инкапсулируются в кадры TRILL при передаче к линию, как будто это кадры данных TRILL.

В результате аткой пересылки протоколу ESADI на RBridge кажется, будто он напрямую подключен к общему виртуальному каналу, соединяющему со всеми RBridge кампуса, но каоторых работает ESADI для этой VLAN. RBridge, которые не реализуют протокол ESADI или не назначены узлами пересылки для данной VLAN, не будут декапсулировать или обрабатывать локально какие-либо кадры TRILL ESADI, полученные ими для данной VLAN. Иными словами, эти кадры будут просто туннелироваться через транзитные RBridge, которые будут трактовать их в точности так же, как групповые кадры данных TRILL, не выполняя при пересылке какой-либо специальной обработки.

Структура кадров TRILL ESADI, передаваемых в канал IEEE 802.3, показана ниже. Внешний тег VLAN не будет присутствовать, если он был вырезан портом, через который кадр был передан.

Внешний заголовок Ethernet
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Next Hop Destination Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Hop Destination Address  | Sending RBridge MAC Address   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Sending RBridge Port MAC Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Заголовок TRILL
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = TRILL             | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress (Dist. Tree) Nickname  | Ingress (Origin) Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Внутренний заголовок Ethernet
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             All-ESADI-RBridges Multicast Address              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-ESADI-RBridges continued  | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Origin RBridge MAC Address continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = L2-IS-IS          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Данные ESADI (в формате IS-IS)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |
FCS
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  FCS (Frame Check Sequence)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Формат кадра TRILL ESADI.

Поля Next Hop Destination Address или Outer.MacDA содержат групповой адрес All-Rbridges. VLAN в поле Outer.VLAN всегда будет назначенной (Designated) VLAN для канала, через который кадр передается. Поля V и R будут иметь значение 0, а M — 1. VLAN в поле Inner.VLAN будет указывать VLAN, к которой применяется кадр ESADI. В поле Origin RBridge MAC Address или Inner.MacSA должен указываться уникальный в глобальном масштабе MAC-адрес, принадлежащий RBridge, создавшему кадр ESADI (например, MAC-адрес любого из портов) и каждый RBridge должен использовать одно значение Inner.MacSA для всех создаваемых им кадров ESADI.

4.2.5.1. Участие в TRILL ESADI

RBridge не передает никаких Hello в результате участия в протоколе ESADI. Информации, доступной в базе данных о состояниях каналов TRILL IS-IS, достаточно для определения ESADI DRB на виртуальном канале протокола ESADI для каждой VLAN. В частности, база состояний каналов для каждого RBridge включает VLAN (если они есть), для которых RBridge участвует в протоколе ESADI, приоритет выбора в качестве DRB для протокола ESADI в каждой из этих VLAN, время удержания, а также идентификатор системы IS-IS для исключения лишнего (breaking tie) при выборе приоритета.

RBridge не нужно выполнять каких-либо маршрутных расчетов в результате участия в протоколе ESADI. Поскольку все RBridge, участвующие в ESADI для конкретной VLAN, представляются соединенными общим виртуальным каналом, маршрутные решения не требуются. Участвующий в протоколе RBridge просто передает создаваемые им кадры ESADI в этот виртуальный канал.

ESADI DRB передает кадры TRILL-ESADI-CSNP в виртуальный канал ESADI. Для отказоустойчивости принимающий участие в протоколе RBridge, который определил, что ESADI DRB следует быть некому другому RBridge на этом виртуальном канале, но тот не принял и не передал TRILL-ESADI-CSNP в течение времени удержания ESADI DRB, может сам передать TRILL-ESADI-CSNP в виртуальный канал. Участвующему в протоколе RBridge, который определил отсутствие других RBridge в протоколе ESADI для конкретной VLAN, не следует передавать информацию ESADI или кадры TRILL-ESADI-CSNP в виртуальный канал для этой VLAN.

4.2.5.2. Информация TRILL ESADI

Информация, распространяемая протоколом ESADI, представляет собой список MAC-адресов локальных конечных станций, известных исходному RBridge, с однооктетным уровнем «доверия» (0 — 254) для каждого из адресов (параграф 4.8).

Это необязательное представление для трансляции VLAN ID в RBridge, как указано в [VLAN-MAPPING], включая трансляцию кадров TRILL ESADI. Если кадры TRILL ESADI могут содержать идентификаторы VLAN в произвольном месте внутри себя, такая трансляция становится непрактичной. Поэтому в кадры TRILL ESADI недопустимо включать идентификаторы VLAN для VLAN, к которой они применяются, после тега Inner.VLAN.

4.2.6. SPF, пересылка и неоднозначные получатели

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

При построении таблицы пересылки RBridge RB1 рассчитывает кратчайшие пути от самого себя, как описано в Приложении C.1 к [RFC1195]. Псевдонимы добавляются в расчет кратчайшего пути на финальном этапе, как с конечными узлами. Если один и тот же псевдоним заявляет несколько RBridge (скажем, RBa и RBb), это будет временным состоянием и RBa или RBb выберет другой псевдоним. Однако RB1 просто добавит этот псевдоним, как будто он связан сразу с RBa и Rbb, при этом он будет использовать свой стандартный расчет кратчайшего пути для выбора следующего этапа пересылки.

Входной RBridge RB2 отображает заведомо индивидуальные MAC-адреса получателей и VLAN в естественных кадрах на псевдоним выходного RBridge. Если RB2 узнает адреса лишь из просмотра полученных и декапсулированных кадров, тогда эти MAC-не могут дублироваться внутри VLAN в таблицах RB2, поскольку свежая информация с уровнем доверия не меньше имеющегося у прежней будет переписывать имеющуюся информацию, а информация с меньшим уровнем доверия будет игнорироваться. Однако дубликаты MAC внутри VLAN могут появляться в данных ESADI, а также возможны совпадения адресов между данными ESADI и адресами, полученными из просмотра полученных и декапсулированных кадров, заданными в конфигурации вручную или узнанными от протокола регистрации L2. При возникновении дубликатов MAC-адресов внутри VLAN устройство RB2 будет передавать кадру по MAC с более высоким уровнем доверия. Если уровни доверия для дубликатов совпадают, для согласованности предполагается, что RB2 будет отправлять все такие кадры (или все такие кадры одного потока ECMP) в направлении одного выходного RBridge. Однако и при использовании других правил не будет возникать проблем с сетью, поскольку транзитные RBridge не проверяют Inner.MacDA для заведомо индивидуальных кадров.

4.3. Размер MTU на канале между RBridge

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

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

4.3.1. Определение TRILL IS-IS MTU в масштабе кампуса

В стабильном кампусе в конечном итоге должно быть достигнуто соглашение между всеми RBridge в части значения Sz — минимального приемлемого размера на каналах между RBridge в кампусе для корректной работы TRILL IS-IS. Все RBridge должны форматировать свои сообщения с информацией о состоянии канала в блоки, размер которых не превышает согласованного Sz. Каждому RBridge RB1 следует проверить соседние RBridge (скажем, RB2), чтобы убедиться в возможности пересылки через канал RB1-RB2 пакетов, размер которых составляет по меньшей мере Sz.

Значение Sz не оказывает прямого влияния на конечные станции и не связан напрямую с какими-либо значениями path MTU на пути между конечными станциями. Способы использования Sz или каких-либо данных об MTU на каналах, собранных TRILL IS-IS при организации трафика на маршрутах или определении MTU для любого пути, выходят за рамки этого документа. Естественные кадры, размер которых после инкапсуляции TRILL превысит MTU для канала, обычно будут отбрасываться.

Sz определяется за счет того, что каждый RBridge (необязательно) анонсирует в своих LSP свое представление о значении Sz в кампусе. Этот элемент LSP называется в IS-IS originatingLSPBufferSize, TLV #14. Принятое по умолчанию и минимальное значение для Sz, а также неявно анонсируемое значение Sz в отсутствие TLV составляет 1470 октетов. Этот размер (который также является минимальным размером TRILL-Hello) был выбран для того, чтобы сделать крайне маловероятным возникновение проблем MTU для управляющих кадров TRILL с разумными дополнительными заголовками, тегами и/или инкапсуляцией на канале между RBridge.

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

4.3.2. Тестирование размера MTU для канала

Имеется два новых типа сообщений TRILL IS-IS для обмена между парой соседних RBridge с целью проверки размера пакетов, передаваемых через соединение в обоих направлениях:

MTU-probe;
MTU-ack.

Оба типа сообщений заполняются до проверяемого размера.

Передача сообщения MTU-probe не обязательна, однако RBridge RB2, получивший MTU-probe от RB1, должен ответить сообщением MTU-ack, дополненным до размера полученного MTU-probe. Сообщение MTU-probe можно передать по групповому адресу All-IS-IS-Rbridges¹⁵ или индивидуальному адресу конкретного RBridge. Сообщения MTU-ack обычно передаются по индивидуальному адресу отправителя MTU-probe, но могут передаваться и по групповому адресу All-IS-IS-Rbridges¹.

Если RB1 не получает MTU-ack на пробный пакет размера X от RB2 после k попыток (k — конфигурационный параметр, по умолчанию равный 3), RB1 предполагает, что канал RB1-RB2 не поддерживает размер X. Если X не превышает Sz, RB1 устанавливает флаг failed minimum MTU test (отказ при проверке минимального MTU) для RB2 в своем сообщении Hello. Если кадры размера X проходят и X > Sz, RB1 анонсирует наибольшее из проверенных значений X для каждого отношения смежности в сообщениях TRILL Hello, передаваемых в соответствующий канал, и может анонсировать X как атрибут канала устройству RB2 в своих LSP.

4.4. Протокол TRILL-Hello

Протокол TRILL-Hello несколько отличается от протокола L3 IS-IS LAN Hello и использует новый тип сообщений IS-IS — TRILL-Hello.

4.4.1. Обоснование TRILL-Hello

Причина определения нового типа каналов в TRILL заключается в том, в L3 IS-IS протокол LAN Hello может приводить к выбору нескольких назначенных маршрутизаторов (DR¹⁶), поскольку при выборе DR маршрутизаторы игнорируют другие маршрутизаторы, с которыми нет двухсторонней связи. Кроме того, сообщения L3 IS-IS LAN Hello дополняются, чтобы предотвратить организацию отношений смежности между соседями, которые не могут обмениваться между собой пакетами максимального размера. Это означает для L3 IS-IS, что соседи, которые соединенны между собой, но MTU в этом соединении меньше значения, которое они считают максимальным размером пакетов, не будут видеть сообщений Hello от другой стороны. В результате маршрутизаторы могут формировать «клику» и канал превращается в несколько псевдоузлов.

Такое поведение хорошо для уровня L3, но не подходит для L2, где могут возникать петли при наличии множества DRB. Поэтому протокол TRILL-Hello несколько отличается от протокола LAN Hello в L3 IS-IS.

Еще одна связанная с TRILL-Hello проблема заключается в гарантии того, что подмножества информации, которые могут появляться в любом отдельном сообщении, будут обрабатываться в духе IS-IS LSP и CSNP. Кадры TRILL-Hello могут быть очень большими, хотя они и не дополняются. Примером этого могут быть ситуации когда некая магистральная технология используется для соединения сотен сайтов TRILL, в результате чего TRILL становится гигантской сетью Ethernet, где RBridge, подключенные к этому облаку, будут воспринимать эту магистраль как один канал с сотнями соседей.

В TRILL (в отличие от L3 IS-IS) DRB выбирается исключительно на основе приоритета и MAC-адреса. Иными словами, если RB2 получает TRILL-Hello от RB1 с более высокими (приоритет, MAC), RB2 выбирает RB1 в качестве DRB, независимо от того, указывает ли RB1 устройство RB2 в своем TRILL-Hello.

Хотя список соседей в TRILL-Hello не влияет на выбор DRB, он определяет, что анонсируется в LSP. RB1 указывает только каналы к RBridge, с которыми у него есть двухсторонняя связь. Если RB1 является DRB на канале и по какой-либо причине (несоответствие MTU или односторонняя связь) RB1 и RB2 не имеют двухсторонней связи, RB2 не указывает свой канал к RB1 (или псевдоузлу), а RB1 (или RB1 от имени псевдоузла) не указывает канал к RB2.

4.4.2. Содержимое TRILL-Hello и синхронизация

TRILL-Hello — это новый тип кадров IS-IS. Сообщение начинается с обычного фиксированного заголовка (как в IS-IS LAN Hello), который включает 7-битовое значение приоритета для выбора RBridge в качестве DRB на данном канале. Кадры TRILL-Hello передаются с такой же временной координацией, как IS-IS LAN Hello.

Кадрам TRILL-Hello, включая Outer.MacDA и Outer.MacSA, но без учета Outer.VLAN и других тегов, недопустимо превышать размер 1470 октетов и дополнять эти сообщения не следует. Приведенная ниже информация должна присутствовать в каждом кадре TRILL-Hello, TLV в действительности могут быть sub-TLV, как описано в [RFC6165] [RFC6326].

VLAN ID назначенной VLAN для канала.
Копия Outer.VLAN ID которая была в кадре Hello при передаче.
16-битовый идентификатор порта, назначенный передающим RBridge порту, куда передается TRILL-Hello, так, чтобы у двух портов данного RBridge идентификаторы не совпадали.
Псевдоним передающего RBridge.
Перечисленные ниже флаги:
1. флаг, показывающий что отправитель обнаружил трансляцию VLAN на канале в течение двух последних интервалов Holding Time;
2. флаг, показывающий что отправитель считает себя назначенным узлом пересылки для VLAN и порта, в который передан TRILL-Hello.

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

Набор VLAN, для которых на порту разрешено обслуживание конечных станций.
Флаги, описанные ниже:
1. флаг, установка которого показывает, что порт отправителя был настроен как порт доступа;
2. флаг, установка которого показывает, что порт отправителя был настроен как транковый;
3. флаг обхода псевдоузла описанный ниже в этом параграфе.
Если отправитель является DRB, могут присутствовать мосты Rbridge (исключая самого себя), назначенные пересылающими для данного канала и VLAN, к которым они подключены. Как описано ниже, этот блок TLV рассчитан на то, что не всю информацию о назначениях следует включать в каждое сообщение Hello. Его отсутствие означает, что назначенным пересылающим устройствам, следует продолжать работать, как было назначено ранее.
Список соседей TRILL. Это новый блок TLV, отличающийся от IS-IS Neighbor TLV для согласования с фрагментацией и отчетов об MTU на канале (параграф 4.4.2.1).

Блок Appointed Forwarders TLV задает диапазон VLAN, а в этом диапазоне — Rbridge (если таковой имеется), отличный от DRB и назначенный пересылающим устройством для VLAN этого диапазона [RFC6326]. Назначение RBridge пересылающим на порту для VLAN, которая не разрешена на этом порту, не оказывает влияния.

Предполагается, что многие каналы между RBridge будут относиться в типу «точка-точка» и в этом случае использование псевдоузлов явно увеличивает сложность. Если DRB задает бит обхода псевдоузлов в своих TRILL-Hello, мосты RBridge на канале просто укажут свою смежность типа «точка-точка». Это не оказывает влияния на лавинную рассылку LSP в канал и влияет лишь на генерацию LSP.

Например, если кроме RB1 и RB2 на канале нет других RBridge и RB1 является DRB, тогда при создании RB1 псевдоузла, который он будет использовать, будет три 3 LSP — скажем, RB1.25 (псевдоузел), RB1 и RB2, где RB1.25 будет сообщать о связности с RB1 и RB2, а RB1 и RB2 просто сообщать, что они соединены с RB1.25. Если DRB RB1 установит бит обхода псевдоузлов в своих сообщениях Hello, будет только два 2 LSP — RB1 и RB2 сообщат лишь о соединении в другим узлом.

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

4.4.2.1. Список соседей TRILL

Новый блок TRILL Neighbor TLV включает для каждого соседа из списка перечисленную ниже информацию.

MAC-адрес соседа.
Размер MTU для этого соседа в виде 2-октетного целого числа без знака, указывающего количество 4-октетных блоков. Нулевое значение говорит, что величина MTU не проверялась.
Флаг отказа при проверке минимального MTU (failed minimum MTU test).

Чтобы разрешить частичные отчеты о соседях, идентификаторы соседей должны быть отсортированы. Если в сообщении Hello от RB1 указан набор соседей { X1, X2, X3, … Xn }, то X1 < X2 < X3, … < Xn. Если идентификатор RBridge RB2 находится между X1 и Xn и не присутствует в RB1 Hello, RB2 знает, что RB1 не слышит Hello от RB2.

В дополнение к этом имеется два общих флага TRILL Neighbor List TLV для наименьшего и наибольшего идентификатора, указанных в этом сообщении Hello. Если все сосседи попадают в TRILL-Hello от RB1, устанавливаются оба флага.

Если RB1 указывает { X1, … Xn } в своем сообщении Hello с установленным флаго smallest, а RB2 ID меньше X1, RB2 знает, что RB1 не слышит Hello от RB2. Аналогично, если RB2 ID больше Xn и установлен флаг largest, RB2 знает, что RB1 не слышит Hello от RB2.

Чтобы любой RBridge RB2 мог достоверно определить, может ли RB1 слышать RB2, список соседей RB1 должен в конечном итоге охватывать все возможные диапазоны идентификаторов, т. е. в течение периода, определяемого политикой RB1 и не обязательно в какой-либо конкретный интервал типа времени ожидания. Иными словами, если X1 является наименьшим идентификатором, указанным в обном из списков соседей RB1 и флаг smallest не установлен, идентификатор X1 должен также появляться как наибольший идентификатор в другом списке соседей TRILL-Hello. Или фрагменты могут перекрываться, пока нет зазоров, при которых некий диапазон между Xi Xj не появляется ни в одном из фрагментов.

4.4.3. Теги VLAN для TRILL MTU-Probe и TRILL Hello

Механизм проб MTU предназначен для определения MTU между мостами RBridge. Пробы MTU и подтверждения передаются лишь на Designated VLAN.

RBridge RBn поддерживает для каждого порта одну и ту же информацию VLAN как клиент моста IEEE [802.1Q-2005], включая набор VLAN, для которых разрешен вывод через порт (параграф 4.9.2). В дополнение к этому RBn поддерживает относящиеся к TRILL параметры VLAN на уровне порта, перечисленные ниже.

Желаемая Designated VLAN — виртуальная ЛВС, которую RBn, будучи DRB, станет указывать в своих TRILL-Hello как the VLAN для использования всеми RBridge на канале для обмена всеми кадрами TRILL за исключением некоторых TRILL-Hello. Это должна быть VLAN, разрешенная на порту RBn. По умолчанию это VLAN с наименьшим из числа разрешенных номером, в качестве которой по умолчанию в RBridge служит VLAN 1.
Designated VLAN — виртуальная ЛВС, которая будет использоваться на канале для всех кадров TRILL за исключением некоторых TRILL Hello. Это желаемая RBn Desired Designated VLAN, если RBn считает себя DRB или Designated VLAN DRB Hello, если RBn не является DRB.
Набор анонсирующих VLAN. По умолчанию это набор разрешенных VLAN на порту, но в конфигурации может задаваться и подмножество разрешенных VLAN.
Набор пересылающих VLAN — множество VLAN, для которых порт RBridge назначен рассылающим для VLAN на порту. В этом наборе должны содержаться лишь разрешенные для порта VLAN (возможно все).

На каждом из своих портов, где не настроена передача P2P Hello, RBridge передает TRILL-Hello с Outer.VLAN каждой VLAN из набора VLAN. Этот набор зависит от статуса DRB в RBridge и указанных выше параметров VLAN. RBridge передают TRILL Hello с Outer.VLAN назначенной сети (Designated VLAN), пока эта VLAN не разрешена на данном порту. В дополнение к этому DRB передает TRILL Hello с тегом Outer.VLAN каждой включенной VLAN в своем наборе Announcing VLANs. Все RBridge, не являющиеся DRB, передают TRILL-Hello с тегом Outer.VLAN tagged каждой включенной VLAN, которая входит в пересечение набора Forwarding VLAN и Announcing VLAN. При передача кадров TRILL-Hello выполняются приведенные ниже условия.

   Если отправитель является DRB
      пересечение ( включенные VLAN, объединение ( Designated VLAN, Announcing VLANs ) )
   Если отправитель не является DRB
      пересечение ( включенные VLAN, объединение ( Designated VLAN,
         пересечение ( Forwarding VLAN, Announcing VLANs ) ) )

Установка для Announcing VLANs пустого значения минимизирует число TRILL-Hello. В этом случае TRILL-Hello помечаются лишь Designated VLAN. Следует проявлять осторожность при настройке RBridge без отправке TRILL Hello в любую сеть VLAN, где этот RBridge назначен пересылающим, поскольку при некоторых обстоятельствах отказ передавать такие сообщения Hello может приводить к возникновению петель.

В этой спецификации число TRILL-Hellos максимизируется путем установки по умолчанию в Announcing VLANs полного набора идентификаторов включенных VLAN ID. В этом случае DRB будет передавать кадры TRILL-Hello, помеченные всеми тегами Enabled VLAN, кроме того, не являющийся DRB мост RBridge RBn будет передавать кадры TRILL-Hello с тегом Designated VLAN (если она включена) и с тегами всех VLAN, для которых RBn назначен пересылающим. Возможна передача даже большего числа TRILL-Hello. В частности, мосты RBridge, не являющиеся DRB, могут передавать TRILL-Hello в разрешенные VLAN для которых они не назначены пересылающими и которые не являются Designated VLAN. Это не причинит никакого вреда, но увеличит нагрузку на каналы связи и повысит объем обработки.

При активизации (up) порта RBridge он будет считать себя DRB для этого порта, пока не получит TRILL-Hello от RBridge с большим приоритетом, и на основании этого будет передавать пакеты TRILL-Hello. Даже если мост распознал другой RBridge на канале в качестве DRB, при отсутствии на этом порту TRILL-Hello от RBridge с более высоким приоритетом, как DRB в течение достаточно долгого времени (как указано в IS-IS), он продолжит считать себя DRB.

4.4.4. Множество портов на одном канале

RBridge RB1 может иметь несколько портов на одном канале и в этом случае для RB1 важно распознать такие порты. Например, если RB1 назначен пересылающим для VLAN A, он знает лишь об одном своем порту как о назначенном пересылающем для VLAN A на этом канала.

RB1 обнаруживает такие ситуации на основе приема сообщений с одним идентификатором псевдоузла IS-IS через несколько портов. RB1 может иметь набор портов (скажем, { p1, p2, p3 }) на одном канале, другой (например, { p4, p5 }) — на втором, а остальные порты (скажем, p6, p7, p8), подключены. Назовем множество портов, подключенных к одному каналу «группой портов» (port group).

Если RB1 видит, что набор портов (например, { p1, p2, p3 }) является группой на канале, тогда он должен обеспечить предотвращение петель при инкапсуляции и декапсуляции пакетов, связанных с этим каналом. Если RB1 назначен пересылающим для VLAN A на канале Ethernet, он должен инкапсулировать и декапсулировать VLAN A лишь на одном из портов. Однако, будучи назначенным пересылающим для нескольких VLAN, RB1 может распределять нагрузку между портами, используя один порт для одного набора VLAN, другой — для другого (не связанного с первым).

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

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

Если несколько портов RBridge подключено к каналу и эти порты имеют один MAC-адрес, их можно различать по идентификаторам порта в TRILL-Hello.

4.4.5. Трансляция VLAN в канале

IEEE [802.1Q-2005] не предусматривает для мостов изменения C-tag VLAN ID в принятых кадрах с тегами, т. е. трансляцию VLAN. Тем не менее, некоторые мосты поддерживают такую возможность и в таких случаях ЛВС на основе мостов можно настроить для отображения такого поведения. Например, порт моста можно настроить на вырезание тегов VLAN на выходе и передачу полученных кадров без тега в канал, ведущий к порту другого моста, настроенному помечать такие кадры тегом другой VLAN. Хотя настройки каждого порта корректны по отношению к [802.1Q-2005], в совокупности выполняются действия, не разрешенные для отдельного клиентского моста [802.1Q-2005]. Поскольку порты RBridge имеют такие же функции VLAN, как у пользовательских мостов [802.1Q-2005], это может происходить даже при отсутствии мостов (отображение VLAN называется в IEEE 802.1 трансляцией — VLAN ID translation).

RBridge включают идентификатор Outer.VLAN ID в каждое сообщение TRILL-Hello. При получении TRILL-Hello RBridge сравнивает сохраненную копию с Outer.VLAN ID из принятого кадра. Если значения различаются и VLAN ID в пакете Hello имеет значение X, а Outer.VLAN — Y, можно предположить трансляцию VLAN ID X в VLAN ID Y.

Когда не являющийся DRB мост RB2 обнаруживает отображение VLAN на основе принятого TRILL-Hello, где тег VLAN в теле Hello отличается от тега во внешнем заголовке, он устанавливает флаг во всех своих TRILL-Hello на время двух интервалов Holding Time с момента последнего обнаружения им трансляции VLAN. Когда DRB RB1 знает о трансляции VLAN из принятого кадра TRILL-Hello с отображенеим или из флага VLAN mapping detected в TRILL-Hello от соседа на канале, RB1 занаво назначает пересылающие мосты для VLAN, чтобы на канале был лишь один пересылающий для всех VLAN.

4.5. Деревья распространения

RBridge используют деревья распространения для пересылки групповых кадров (параграф 2.4.2). Деревья распространения являются двунаправленными (не ориентированными). Хотя одного дерева логически достаточно для всего кампуса, расчет дополнительных деревьев оправдан по нескольким причинам. Это позволяет использовать несколько путей для групповых кадров и выбрать корень дерева ближе (в пределе — входной RBridge). Более близкий корень повышает эффективность доставки групповых кадров, которые будут передаваться в подмножество каналов кампуса, и снижает вероятность нарушения порядка доставки когда индивидуальный адрес меняет состояние между неизвестным и известным. Если используется приложение, где случайное нарушение порядка доставки вызывает проблемы, кампус RBridge следует организовать так, чтобы вероятность нарушения порядка была максимально низкой, например, с помощью протокола ESADI, настраивая адреса для устранения кадров неизвестным индивидуальным получателя или используя кадры keep alive.

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

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

RBridge заранее рассчитывают все деревья, которые могут использоваться, и сохраняют состояние для фильтров проверки пересылки по обратному пути (Reverse Path Forwarding Check, параграф 4.5.2). Поскольку номер дерева служит для устранения конфликтов, всем RBridge важно знать:

сколько деревьев нужно рассчитывать;
какие деревья рассчитывать;
какой номер имеет каждое дерево;
какое из деревьев каждого входного RBridge можно выбрать (для фильтров Reverse Path Forwarding Check).

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

Каждый RBridge анонсирует в своих LSP максимальное число деревьев распространения, которые мост может рассчитать, и число деревьев, которые он хочет, чтобы рассчитывалось на всех RBridge кампуса. Число деревьев (k), рассчитываемых для кампуса, — это число, желаемое RBridge RB1, у которого псевдоним имеет высший приоритет корня дерева, но не более наименьшего числа деревьев, поддерживаемых RBridge в кампусе. Если RB1 не задает конкретные корни деревьев распространения, как описано ниже, все RBridge в кампусе будут рассчитывать k деревьев с высшим приоритетом. Отметим, что некоторые из этих k деревьев могут оказаться в одном RBridge, имеющем множество псевдонимов.

Если RBridge указывает число рассчитываемых им или желаемым для кампуса деревьев 0, это считается указанием одного дерева. Т. е. по умолчанию k = 1.

В дополнение к этому RBridge RB1 с высшим приоритетом корня может явно анонсировать набор из s деревьев, предоставив список псевдонимов s. В этом случае будут рассчитываться первые k из этих s деревьев. Если s < k или любой из s псевдонимов, связанных с деревьями, анонсируемыми RB1, отсутствует в базе данных LSP, устройства RBridge по-прежнему рассчитывают k деревьев и выбранные деревья будут иметь наивысший приоритет.

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

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

Рассчитанные для кампуса k деревьев упорядочиваются по номерам от 1 до k. В дополнение к анонсированию значения k устройство RB1 может явно анонсировать множество из s деревьев, предоставляя список из s псевдонимов.

Если s == k, деревья нумеруются в порядке их анонсирования .
Если s == 0, деревья нумеруются в порядке снижения приоритета. Например, если RB1 анонсирует лишь k=2, дерево с высшим приоритетом будет иметь номер 1, а со следующим — номер 2.
Если s < k, анонсированные RB1 деревья нумеруются с 1 в порядке анонсирования. Затем среди оставшихся выбираются деревья с наивысшим приоритетом и нумерация продолжается. Например, если RB1 анонсирует k=4 и { Tx, Ty } как псевдонимы корней деревьев, а приоритеты в кампусе упорядочены как Ty > Ta > Tc > Tb > Tx, Tx получит номер 1, а Ty — 2, поскольку в этом порядке они объявлены RB1. Затем Ta получит номер 3, а Tc — 4 в соответствии с приоритетом деревьев, которые еще не пронумерованы.

4.5.1. Расчет дерева распространения

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

При расчете дерева распространения важно, чтобы все RBridge выбирали для дерева одни и те же каналы. Поэтому при наличии равноценных путей для конкретного дерева все RBridge должны использовать одни и те же средства устранения конфликтов. Желательно также разрешить распределение трафика через как можно большее число каналов. По этой причине простые средства устранения конфликтов (tiebreaker), такие как «выбор всегда родителя с меньшим идентификатором», применять нежелательно. Взамен TRILL использует номер дерева в качестве параметра алгоритма устранения конфликтов.

При расчете дерева с номером j запоминаются все возможные равноценные родители для узла N. После расчета всего «дерева» (в реальности ориентированного графа) для каждого узла N, если он имеет p родителей, они упорядочиваются по возрастанию в соответствии с 7-октетными IS-IS ID, рассматриваемыми как целые числа без знака и нумерация начинается с 0. Для дерева j выбирается родитель с N = j mod p.

Отметим, что может быть множество равноценных каналов между N и возможным родителем P, не имеющих псевдоузлов, поскольку эти каналы имеют тип «точка-точка» или подавляют псевдоузлы. Такие каналы считаются одним каналом при построении дерева, поскольку все они имеют одного родителя P с идентификатором IS-IS ID = P.0.

Иными словами, набор возможных родителей N для дерева с корнем R состоит из узлов с равноценными путями от R к N¹⁷ и разными идентификаторами IS-IS ID, полученными из LSP.

4.5.2. Проверка кадров с множеством получателей

При получении RBridge группового кадра с инкапсуляцией TRILL выполняются 4 проверки, которые могут приводить к отбрасыванию кадра.

Проверка смежности в дереве. Каждый RBridge RBn хранит свои смежности (пары { port, neighbor }) для каждого рассчитанного им дерева. Одна из этих смежностей ведет к корневому RBi, а остальные — к листьям. После выбора смежностей неважно, какая из них ведет к корневому RBi, а какие — от него. RBridge должны отбрасывать групповые кадры, приходящие в порт от RBridge, не являющегося смежным для дерева, по которому распространяется кадр. Предположим, что RBn считает, что смежности a, c и f находятся в дереве RBi. Групповой кадр для дерева распространения RBi, полученный от любого из смежных узлов a, c, f пересылается двум другим смежным узлам, а прочие кадры отбрасываются. Если RBn имеет несколько портов на канале, групповые кадры, передаваемые им в один из таких портов, будут получены на другой стороне, но отброшены, поскольку RBridge не является смежным для себя.
Проверка RPF. Другим методом, используемым в RBridge для предотвращения петель групповой пересылки при изменении топологии является проверка пересылки по обратному пути (RPF). Здесь проверяется, что групповой кадр прибыл из ожидаемого канала на основе дерева и входного RBridge. RBridge должны отбрасывать групповые кадры, не прошедшие проверку RPF.

Для ограничения числа состояний, требуемых при проверке RPF, каждый RBridge RB2 должен анонсировать деревья, которые он может выбрать в качестве входных для групповых пакетов. Когда любой из RBridge (например, RB3) рассчитывает дерево по псевдониму X, он,вычисляет для каждого RBridge RB2, который может быть входным для дерева X, канал, откуда RB3 следует получать пакеты от RB2 по дереву X, и отмечает для этого канала, что RB2 является действительным входным RBridge для дерева X.

Информация о том, какие деревья может выбрать RB2, включается в LSP от RB2. Подобно тому, как RBridge RB1 указывает k деревьев, которые будут рассчитываться всеми RBridge, RB2 задает число j, которое указывает общее количество разных деревьев, которые может задать RB2, а конкретные деревья, которые может указать RB2, представляют собой комбинацию указанных деревьев и деревьев, выбранных из числа имеющих наиболее высокий приоритет.

j возможных входных деревьев для RB2 — это деревья с псевдонимами, явно указанными RB2 в specified ingress tree nicknames (и включенные в k деревьев, выбранных в масштабе кампуса RBridge RB1 с наибольшим приоритетом), а остальные (вплоть до k, если j = 0 и или minimum(j, k) в противном случае ¹⁸) — деревья с наибольшим приоритетом из числа выбранных в масштабе кампуса k деревьев.

По умолчанию j = 1. Значение 0 для j является особым и означает, что RB2 может выбрать любое k деревьев, рассчитанных для кампуса.
Проверка параллельных каналов. Если при построении дерева и устранении конфликтов для конкретного дерева группового распространения выбирается канал без псевдоузлов между RB1 и RB2, этот канал может фактически состоять из нескольких. Эти параллельные каналы будут видимы для RB1 и RB2, но не для остального кампуса (поскольку каналы не представлены псевдоузлами). Если эти параллельные каналы включены в дерево, для RB1 и RB2 важно решить, какой из каналов использовать, но для остальных RBridge это не имеет значения, поэтому алгоритму устранения петель (tiebreaking) не требуется быть видимым для всех RBridge, кроме RB1 и RB2. В этом случае смежности RB1-RB2 упорядочиваются как описано ниже, причем более предпочтительной будет та, через которую RB1 и RB2 передают групповые кадры между собой.
1. Наиболее предпочтительны канала, организованные P2P Hello. Алгоритм устранения конфликтов между ними основан на предпочтении смежности с наибольшим Extended Circuit ID устройства RBridge с большим System ID.
2. Затем рассматриваются каналы, организованные через кадры TRILL-Hello с подавленными псевдоузлами. Отметим, что псевдоузлы подавляются в LSP, но остаются в TRILL-Hello, поэтому они доступны для устранения конфликтов. Среди этих каналов тот, у которого больше идентификатор псевдоузла.
Проверка группы портов. Если RBridge имеет несколько портов на одном канале, групповые пакеты будут приходить из каждого такого канала. Все такие копии, кроме одной, должны отбрасываться. Все кадры, являющиеся частью одного потока должны приниматься через один порт во избежание разупорядочения.

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

4.5.3. Сокращение дерева распространения

Каждое дерево распространения следует сокращать по VLAN, сокращая нисходящие ветви без потенциальных получателей. Групповые кадры TRILL Data следует пересылать лишь в ветви, которые не сокращаются.

В двух случаях следует выполнять дополнительное сокращение — (1) сообщения IGMP [RFC3376], MLD [RFC2710] MRD [RFC4286], которые доставляются лишь в каналы с групповыми маршрутизаторами IP и (2) другие групповые кадры, полученные из групповых адресов IP, которые следует доставлять лишь в каналы с зарегистрированными получателями и каналы с групповыми маршрутизаторами IP, за исключением групповых адресов IP, которые должны быть широковещательными. Каждый из этих случаев обрабатывается на уровне VLAN.

Пусть RBridge RBn знает, что смежности (a, c, f) находятся в дереве распространения nickname1. RBn отмечает данные сокращения для каждой смежности в дереве nickname1:

набор VLAN, доступных в нисходящем направлении;
для каждой из таких VLAN устанавливаются флаги, указывающие, есть ли в них групповые маршрутизаторы нисходящей рассылки IPv4 или IPv6;
множество групповых адресов L2, выведенных из multicast-групп IP, для которых есть нисходящие адресаты.

4.5.4. Оптимизация дерева распространения

RBridge должны определять VLAN, связанную со всеми получаемыми естественными кадрами и корректно применять правила VLAN при отправке естественных кадров через выходные порты RBridge в соответствии с настройками этих портов и их назначением пересылающими (forwarder). Узлам RBridge следует также сокращать дерево распространения групповых кадров в соответствии с VLAN. Поскольку такое сокращение не обязательно, узлы могут получать кадры данных TRILL или ESADI, которые следовало сократить ранее в дереве распространения. RBridge отбрасывает такие кадры без уведомления. Некоторые RBridge в кампусе могут сокращать деревья распространения для VLAN.

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

RBridge, который не проверяет поступающие естественные кадры IGMP [RFC3376], MLD [RFC2710], MRD [RFC4286], должен сообщить, что к нему подключены групповые маршрутизаторы IPv4 и IPv6 IP для всех VLAN, где он назначен пересылающим. Не требуется анонсировать полученных из IP групповых получателей. Это приведет к тому, что весь полученный из IP групповой трафик будет передаваться данному RBridge для этих VLAN. Трафик будет потом пересылаться в каналы, для которых RBridge назначен пересылающим, при совпадении VLAN со значением VLAN для которой узел назначен пересылающим на этом канале (это может вести к подавлению некоторых сообщений IGMP о принадлежности к группе, но оно не существенно, поскольку весь групповой трафик, запрашиваемый такими сообщениями будет передаваться конечным станциям).

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

Дополнительная информация приведена в документе Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches [RFC4541].

4.5.5. Пересылка с использованием дерева распространения

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

RBridge RBn принимает групповой кадр TRILL Data с внутренним VLAN-x и заголовком TRILL, указывающим выбор дерева с псевдонимом nickname1.
Если источник принятого кадра не находится в одной из смежностей дерева nickname1 для указанного входного RBridge, кадр отбрасывается (параграф 4.5.1).
Если кадр содержит анонс IGMP или MLD или запрос MRD, инкапсулированный в нем кадр пересылается в смежности дерева nickname1, которые указывают наличие нисходящих групповых маршрутизаторов IPv4 или IPv6 (что подходит) для VLAN-x.
В остальных случаях, если кадр направлен по групповому адресу L2, полученному из multicast-группы IP, но адрес IP не находится в диапазоне групповых адресов IP, которые должны считаться широковещательными, кадр пересылается в смежности дерева nickname1, которые указывают наличие нисходящих групповых маршрутизаторов IPv4 или IPv6 (что подходит) для VLAN-x, а также в смежности, указывающие наличие получателей VLAN-x для данного группового адреса.
В противном случае (внутренний кадр предназначен для группового адреса L2, не выведенного из multicast-группы IP, неизвестного адресата, является широковещательным или является групповым адресом IP, который нужно считать широковещательным) кадр пересылается в смежность тогда и только тогда, когда эта смежность присутствует в дереве nickname1 и помечена как ведущая к каналам VLAN-x.

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

Кадры TRILL ESADI будут доставляться лишь мостам RBridge, назначенным пересылающими для их VLAN. Такие кадры будут групповыми для всего кампуса, подобно другим групповым кадрам, не полученным из групповых кадров данных IP, в дереве распространения, выбранном RBridge, который создал кадр TRILL ESADI и сокращаются в соответствии с внутренним Inner.VLAN ID. Таким образом, все RBridge, назначенные пересылающими для канала в эту VLAN, получат данный кадр.

4.6. Поведение обработки пакетов

В этом параграфе описано поведение RBridge для всех вариантов принимаемых пакетов, включая пакеты, которые будут пересылаться. В параграфе 4.6.1 рассмотрены естественные кадры, в 4.6.2 — кадры TRILL, а в 4.6.3 — кадры управления L2. Обработку можно организовать или упорядочить не так, как описано здесь, если обеспечивается описанный здесь результат. Определения кадров приведены в параграфе 1.4.

Поврежденные кадры, например, кадры с некратным 8 битам размером, слишком короткие для используемого протокола или оборудования, а также кадры с некорректным значением FCS отбрасываются при получении портом RBridge, как это делается портами мостов IEEE 802.1.

Информация об адреса получателя ( { VLAN, Outer.MacSA, port } ) по умолчанию изучается для всех кадров с индивидуальным адресом отправителя (параграф 4.8).

4.6.1. Прием естественного кадра

Если порт настроен как отключенный (disabled), отключена служба конечной станции на порту (end-station service) настройкой порта в качестве транкового или порт настроен на использование P2P Hello, кадр отбрасывается.

Входной RBridge RB1 определяет VLAN ID для естественного кадра по тем же правилам, что и мосты IEEE [802.1Q-2005] (Приложение D и параграф 4.9.2). После определения VLAN если RB1 не назначен пересылающим для этой VLAN на принявшем кадр порту или заблокирован, кадр отбрасывается. В случае назначения пересылающим для VLAN и отсутствия блокировки (параграф 4.2.4.3), естественный кадр пересылается в соответствии с параграфом 4.6.1.1 (индивидуальный) или 4.6.1.2 (групповой или широковещательный).

4.6.1.1. Индивидуальные кадры

Если MAC-адрес получателя естественного кадра является индивидуальным (unicast) выполняются указанные ниже действия. Для адрес получателя L2 и VLAN выполняется в базе данных входного RBridge для MAC-адресов и VLAN с целью найти выходной RBridge Rbm, локальный выходной порт или определить, что адресат недоступен. Возможны 4 случая.

Адресатом является принявший кадр RBridge, кадр обрабатывается локально.
Если известно, что адресат размещен на том же канале, откуда был принят естественный кадр, но не является данным RBridge, этот RBridge отбрасывает кадр без уведомления, поскольку адресат уже получил его.
Если известно, что адресат размещен на другом локальном канале, где RBm назначен пересылающим, RB1 преобразует кадр в кадр TRILL Data с Outer.MacDA следующего RBridge в направлении RBm, заголовком TRILL с M = 0, и входным псевдонимом для RB1 и выходным псевдонимом для RBm. Если входной RB1 имеет множество псевдонимов, следует всякий раз использовать один псевдоним во входном поле nickname при каждой инкапсуляции естественного кадра с любым MAC-адресом отправителя и VLAN. Это упрощает обучение конечных узлов. Если RBm является RB1, обработка выполняется в соответствии с параграфом 4.6.2.4, в противном случае для Outer.MacSA устанавливается MAC-адрес порта RB1 на пути к следующему RBridge в направлении RBm и кадр помещается в очередь для передачи через этот порт.
Если индивидуальный MAC-адрес получателя не известен в указанной в кадре VLAN, RB1 обрабатывает кадр в соответствии с параграфом 4.6.1.2 для широковещательной передачи, но в поле Inner.MacDA указывается исходный индивидуальный адрес получателя.

4.6.1.2. Групповые и широковещательные кадры

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

Если кадр является естественным кадром IGMP [RFC3376], MLD [RFC2710] или MRD [RFC4286], RB1 следует анализировать его, определяя принадлежность к группе или индикацию группового маршрутизатора IP и анонсируя эти данные в подходящие VLAN в своих LSP (параграф 4.7).

Естественные групповые кадры RB1 пересылает в естественной форме в свои каналы, где размещаются подходящие назначенные узлы пересылки для VLAN кадра с учетом дополнительной отсечки и блокировки. В дополнение к этому естественный кадр преобразуется в кадр TRILL Data с групповым адресом All-RBridges в поле Outer.MacDA, заголовком TRILL с M = 1 9групповой), входным псевдонимом для RB1 и выходным псевдонимом для выбранного дерева распространения. Затем кадр пересылается в сокращенное дерево распространения (параграф 4.5) с установкой в Outer.MacSA каждой переданной копии MAC-адреса порта RB1, куда кадр передается.

По умолчанию RB1 записывает в выходное поле nickname псевдоним дерева распространения и набора анонсированных для использования, корень которого имеет наименьшую стоимость из RB1. Однако RB1 может выбирать другие деревья распространения, если RB1 настроен на распределение группового трафика по разным путям. В этом RB1 должен выбрать дерево, указав псевдоним, являющийся корнем дерева распространения (параграф 4.5). Кроме того, RB1 должен выбрать псевдоним, объявленный им (в своем LSP), как один из тех, которые RB1 может использовать. Используемая RB1 стратегия выбора для распространения группового трафика по нескольким путям выходит за рамки этого документа.

4.6.2. Прием кадра TRILL

Кадр TRILL имеет тип (Ethertype) TRILL или L2-IS-IS и групповой адрес Outer.MacDA, выделенный для TRILL (параграф 7.2). Приведенные ниже проверки выполняются последовательно и первое совпадение определяет обработку кадра.

Если Ethertype == L2-IS-IS, а Outer.MacDA содержит All-IS-IS-RBridges или индивидуальный MAC-адрес принявшего кадр порта RBridge, кадр обрабатывается в соответствии с параграфом 4.6.2.1¹⁹.
Если в Outer.MacDA указан групповой адрес, выделенный для TRILL, но не All-RBridges, кадр отбрасывается.
Если Outer.MacDA содержит индивидуальный адрес, не совпадающий с MAC-адресом принявшего кадр порта RBridge, кадр отбрасывается (такие кадры скорей всего адресованы другим RBridge на канале с множественным доступом и эти RBridge обработают их).
Ethertype отличается от TRILL, кадр отбрасывается.
Если поле Version в заголовке TRILL больше 0, кадр отбрасывается.
Если счетчик интервалов ракен 0, кадр отбрасывается.
Если Outer.MacDA содержит групповой адрес, а M == 0 или адрес в Outer.MacDA является индивидуальным, а M == 1, кадр отбрасывается.
По умолчанию RBridge недопустимо пересылать кадры с инкапсуляцией TRILL от соседа, с которым нет смежности TRILL IS-IS. RBridge можно настроить на уровне порта на восприятие таких кадров для пересылки в клучаях, когда известно, что не являющееся партнером устройство (например, конечная станция) настроено на передачу кадров с инкапсуляцией TRILL, которые можно без опаски пересылать.
Затем проверяется Inner.MacDA. Если это групповой адрес All-ESADI-Rbridges и RBn реализует протокол ESADI, выполняется обработка в соответствии с параграфом 4.6.2.2. если адрес иной или RBn не поддерживает ESADI, выполняется обработка, описанная в параграфе 4.6.2.3.

4.6.2.1. Кадры управления TRILL

Кады обрабатываются экземпляром TRILL IS-IS на RBn и не пересылаются.

4.6.2.2. Кадры TRILL ESADI

Если M == 0, кадр отбрасывается без уведомления.

Выходной псевдоним указывает дерево распространения. Кадр пересылается в соответствии с параграфом 4.6.2.5. Кроме того, если пересылающий RBridge назначен пересылающим (appointed forwarder) для канала в указанную VLAN, реализует протокол TRILL ESADI и этот протокол включен на пересылающем RBridge для этой VLAN, внутренний кадр декапсулируется и передается локальному протоколу ESADI.

4.6.2.3. Кадры данных TRILL

Затем проверяется флаг M. При нулевом значении обработка продолжается в соответствии с параграфом 4.6.2.4, в противном случае — в соответствии с параграфом 4.6.2.5.

4.6.2.4. Заведомо индивидуальные кадры данных TRILL

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

Если RBn является транзитным RBridge, счетчик интервалов уменьшается на 1 и кадр передается следующему RBridge в направлении выходного RBridge (возможность уменьшать счетчик дольше чем на 1 в некоторых обстоятельствах (параграф 3.6) применима лишь для групповых кадров, а здесь рассматриваются лишь заведомо индивидуальные). Поле Inner.VLAN не проверяется транзитным RBridge при пересылке заведомо индивидуальных кадров TRILL Data. Для пересылаемого кадра Outer.MacSA является MAC-адресом передающего порта, Outer.MacDA — индивидуальным адресом следующего RBridge, а VLAN — Designated VLAN на канале, куда кадр передается.

Если RBn не является транзитным RBridge, т. е. указанный выходной RBridge является выполняющим обработку, Inner.MacSA и Inner.VLAN ID (по умолчанию) определяются как связанные со в входным псевдонимом, если он известен и не является зарезервированным, или Inner.MacSA не является индивидуальным. Тогда пересылаемый кадр декапсулируется и выполняются указанные ниже действия.

Проверяется Inner.MacDA и кадра с неиндивидуальным получателем отбрасываются.
Если Inner.MacDA соответствует RBridge, выполняющему обработку, кадр доставляется локально.
Проверяется Inner.VLAN ID и при значении 0x0 или 0xFFF кадр отбрасывается.
Выполняется поиск Inner.MacDA и Inner.VLAN ID в локальном кэше адресов RBn и кадр пересылается в один из каналов, соответствующих адресату, если RBridge назначен пересылающим для данного канала в VLAN кадра и не заблокирован (отбрасывается при блокировке), или обрабатывается, как описано ниже.

Заведомо индивидуальный кадр TRILL Data может прийти на выходной RBridge лишь для того, чтобы обнаружить, что RBridge реально не знает комбинации Inner.MacDA и Inner.VLAN. Это может произойти, например, в результате завершения срока действия кэшированных в таблице выходного RBridge адресов MAC. В этом случае выходной RBridge передает естественный кадр во все каналы, которые относятся к VLAN кадра, где RBridge назначен пересылающим и не заблокирован. Исключение состоит в том, что RBridge может воздержаться от передачи кадра в каналы, где ему известно об отсутствии конечной станции с MAC-адресом получателя, например, в канал, настроенный как транк (параграф 4.9.1).

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

4.6.2.5. Кадры данных TRILL для множества получателей

Проверяются выходной и входной псевдоним в заголовке TRILL и кадр отбрасывается, если любой из псевдонимов не известен или зарезервирован.

Проверяется Outer.MacSA и кадр отбрасывается при отсутствии смежности для дерева, указанного псевдонимом выходного RBridge на порту, где был принят кадр. Выполняется проверка RPF для входного и выходного псевдонимов и кадр отбрасывается при отрицательном результате. При наличии нескольких параллельных каналов с подавлением TRILL-Hello от псевдоузлов к RBridge предыдущего интервала кадр отбрасывается, если он получен на неверном канале. Если несколько портов RBridge подключены к одному каналу, кадр отбрасывается при его получении из неверного канала. Дополнительные сведения о таких проверках даны в параграфе 4.5.2.

Если Inner.VLAN ID в кадре имеет значение 0x0 или 0xFFF, кадр отбрасывается.

Если RBridge назначен пересылающим для Inner.VLAN ID из кадра, значения Inner.MacSA и Inner.VLAN ID по умолчанию определяются как связанные со входным псевдонимом, если он не является неизвестным или зарезервированным или Inner.MacSA не является индивидуальным адресом. Тогда копия кадра декапсулируется и передается в естественной форме в те каналы для данной VLAN, где RBridge назначен пересылающим, с учетом дополнительного сокращения и блокировки (параграф 4.2.4.3) и/или обрабатывается локально, когда это применимо.

Счетчик интервалов уменьшается (возможно, более чем на, как указано в параграфе 3.6) и кадр пересылается вниз по дереву, заданному псевдонимом выходного RBridge, как указано в параграфе 4.5.

Для пересылаемого кадра в поле Outer.MacSA указывается адрес порта, куда кадр передается, в Outer.MacDA — групповой адрес All-RBridges, а в VLAN — Designated VLAN для канала, куда передается кадр.

4.6.3. Прием кадров управления L2

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

Имя	Описание	Адрес получателя
BPDU	параграф 4.9.3	01-80-C2-00-00-00
VRP	параграф 4.9.4	01-80-C2-00-00-21

4.7. Изучение IGMP, MLD и MRD

Входным RBridge следует на основе естественных кадров IGMP [RFC3376], MLD [RFC2710] и MRD [RFC4286], принимаемых на портах в VLAN, где они назначены пересылающими (и не заблокированы) узнавать, какие выведенные из групповых сообщений IP кадры следует пересылать в какие каналы. Такие кадры (в общем случае) являются инкапсулированными в TRILL Data и распространяются в соответствии с параграфом 4.5.

Сообщения о членстве IGMP или MLD, полученные в естественной форме из канала, указывают групповых получателей для данной группы на данном канале. Запросы IGMP или MLD, а также анонсы MRD в естественной форме из канала указывают присутствие на канале группового маршрутизатора IP.

Сообщения о принадлежности к multicast-группам IP, должны передаваться в масштабе кампуса и доставляться всем групповым маршрутизаторам IP (различая IPv4 и IPv6). Весь полученный из IP групповой трафик также должен передаваться всем групповым маршрутизаторам IP с той же версией протокола IP.

Групповые данные IP следует передавать лишь в каналы, где имеется групповой маршрутизатор для данной версии IP (IPv4 или IPv6) или групповой получатель IP для выведенного из IP адреса MAC, если групповой адрес IP не относится к диапазону, который должен считаться широковещательным.

RBridge не обязаны анонсировать себя в качестве получателей группы IPv4 All-Snoopers (применяется для отчетов MRD [RFC4286]), поскольку групповой адрес IPv4 для этой группы относится к диапазону, куда передаются все групповые кадры IP, т. е. является широковещательным (см. параграф 2.1.2 в [RFC4541]). Однако RBridge, выполняющие оптимизацию выведенных из IPv6 групп, должны анонсировать себя в качестве получателей группы IPv6 All-Snoopers.

Дополнительная информация приведена в параграфе Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches [RFC4541].

4.8. Детали адреса конечной станции

RBridge узнают MAC-адреса и VLAN локально подключенных конечных станций для пар канал-VLAN, гле они назначены пересылающими. Эта информация позволяет:

пересылать естественную форму заведомо индивидуальных кадров TRILL в корректный канал;
решать для входящих естественных индивидуальных кадров на канале, где RBridge назначен пересылающим для VLAN, является ли кадр:
- заведомо адресованным другой конечной станции на том же канале (не нужно делать ничего);
- нужно преобразовать кадр TRILL Data и переслать его.

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

4.8.1. Определение адресов конечных станций

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

Просмотр в кадрах VLAN-x, полученных на портах, где он назначен пересылающим для VLAN-x, триплетов { MAC-адрес отправителя, VLAN, порт }.
Триплеты { MAC-адрес отправителя, VLAN, псевдоним входного RBridge } в любом декапсулируемом им естественном кадре.
Изучение в протоколах регистрации L2 { MAC-адрес отправителя, VLAN, порт } для конечных станций, зарегистрированных на локальном порту.
Использование протокола TRILL ESADI для одной или нескольких VLAN и получение за счет этого информации об удаленных адресах и/или передача локальной информации об адресах.
Настройка в системе управления.

RBridge должны реализовать пп. 1 и 1 и 2. RBridge используют эти возможности, пока для одной или нескольких VLAN и/или портов не отключено обучение по принятым кадрам или/и декапсуляции передаваемых кадров.

RBridge могут реализовать пп. 3 и 4. При реализации п. 4 протокол ESADI работает лишь в том случае, когда RBridge настроен делать это на уровне VLAN.

RBridge следует реализовать п. 5.

Записи в таблице полученных при обучении адресов MAC и VLAN, а также связанная с ними информация также используют однооктетный (без знака) уровень доверия, обоснование которого приведено ниже. Информация, полученная в результате наблюдения за данными, имеет уровень достоверности 0x20, если в конфигурации не задано другое значение. Этот уровень можно настраивать на уровне RBridge раздельно для информации из естественных кадров и данных из инкапсулированных кадров удаленного происхождения. Информация, полученная от протокола TRILL ESADI имеет уровень достоверности от 0 до 254. Информация, заданная системой управления, по умолчанию имеет уровень достоверности 255, но можно задать в конфигурации иное значение.

Таблица полученных при обучении MAC-адресов включает квартеты (1) { достоверность, VLAN, MAC-адрес, локальный порт } для адресов, полученных из локальных естественных кадров и локальных протоколов регистрации, квартеты (2) { достоверность, VLAN, MAC-адрес, псевдоним выходного RBridge } для адресов, полученных из инкапсулированных удаленных кадров и баз данных ESADI о состоянии каналов, (3) дополнительную информацию для реализации тайм-аутов изученных и статически заданных адресов и т. п.

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

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

4.8.2. Обоснование уровня достоверности при обучении

Механизм уровней достоверности позволяет администраторам кампуса RBridge установить предпочтения для некоторых источников получения информации по отношению к другим. В принятой по умолчанию конфигурации без дополнительного протокола ESADI изучение адресов происходит лишь путем наблюдения за естественными локальными кадрами и декапсуляции принятых кадров TRILL Data. Оба эти источника по умолчанию имеют уровень достоверности 0x20 и, поскольку получение данных с таким же или более высоким уровнем достоверности ведет к переопределению имеющихся записей, такое поведение имитирует принятое по умолчанию обучение в мостах 802.1.

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

Локально полученные естественные кадры можно считать более надежными, нежели декапсулированные кадры из удаленных частей кампуса. Чтобы полученные из таких локальных кадров MAC-адреса не могли быть захвачены удаленными фиктивными кадрами, можно повысить уровень достоверности для адресов из локальных кадров или снизить его для адресов, полученных при декапсуляции удаленных кадров.
MAC-адреса, полученные от протоколов регистрации L2 с криптографической защитой, такой как протокол 802.1X с криптографией EAP, можно считать более надежными, чем адреса, полученные из простого наблюдения за кадрами данных. При передаче такой защищенной информации по протоколу ESADI использование аутентификации в кадрах TRILL ESADI LSP может существенно осложнить подделку кадров в процессе передачи. В результате может оказаться разумным повышение уровня достоверности для данных, полученных по протоколу ESADI, и переопределение этими данными записей, полученных иным путем.

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

4.8.3. Забывание адресов конечных станций

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

Для адресов конечных станций, полученных из принятых локально кадров, время ожидания следующего принятого или декапсулированного естественного кадра соответствует рекомендациям [802.1D]. Оно называется временем старения (Ageing Time), настраивается на уровне RBridge в диапазоне от 10 до 1000000 и по умолчанию составляет 300 секунд.

Для адресов, полученных по протоколу TRILL ESADI ситуация отличается. Вопрос удаления информации из ESADI LSP (или таймаута протокола ESADI, если RBridge становится недоступным) решает RBridge-источник.

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

Когда RBridge RBn перестает быть назначенным пересылающим для VLAN-x на всех своих портах, он забывает все адреса конечных станций, полученные из декапсуляции естественных кадров VLAN-x. Если RBn участвует в работе протокола TRILL ESADI для VLAN-x, он прекращает это участие после передачи финального LSP, обнуляющего информацию об адресах конечных станций для VLAN. Кроме того, все другие RBridge, пересылающие кадры для VLAN-x хотя бы на одном из портов, отмечают, что данные о состоянии канала для RBn изменились и говорят об утрате канала в VLAN-x. В результате они забывают адресную информацию, полученную при декапсуляции кадров VLAN-x, которая указывает, что RBn является входным RBridge.

Когда отмечается увеличение значения счетчика потерь статуса назначенного пересылающего RBridge RBn для VLAN-x в базе данных TRILL IS-IS о состоянии каналов, но RBn продолжает быть назначенным пересылающим для VLAN-x хотя бы на одном порту, все остальные RBridge, являющиеся назначенными пересылающими для VLAN-x, меняют информацию о старении всех адресов, полученных при декапсуляции естественных кадров VLAN-x от входного RBridge RBn. В каждой записи оставшееся время корректируется так, чтобы оно не превышало конфигурационный параметр на уровне RBridge, называемый задержкой пересылки (Forward Delay) в соответствии с [802.1D]. Этот параметр имеет значения от 4 до 30 и по умолчанию установлено 15 секунд.

4.8.4. Общее изучение VLAN

RBridge могут транслировать VLAN ID в меньшее число идентификаторов для изучения адресов, как это делают мосты [802.1Q-2005]. Эти идентификаторы применяются для сопоставления при поиске адресов взамен VLAN ID. Если идентификатор VLAN, для которой адрес был получен, не был сохранен, возникают два последствия.

RBridge больше не имеет информации, требуемой для участия в протоколе TRILL ESADI для VLAN, чьи идентификаторы не были сохранены.
В случаях, где параграф 4.8.3 требует отбрасывания полученной адресной информации для конкретной VLAN, когда VLAN ID недоступен для записей с идентификатором VLAN общего пользования, оставшееся время для каждой записи с этим идентификатором VLAN устанавливается не больше Forward Delay для RBridge.

Несмотря на то, что это выходит за рамки данной спецификации, имеются некоторые функции L2, в которых множество VLAN использует общее обучение, где одна из VLAN является первичной, а другие VLAN в группе — вторичными. Примером этого является разделение трафика разных сообществ по тегам VLAN с предоставлением некоторых ресурсов (например, маршрутизатор IP или сервер DHCP) всем сообществам. Реализация этой функции возможна путем предоставления некого тега VLAN (например, Z) каналу к общему ресурсу, а другие теги (скажем, A, C, D) включить в группу сторичных { primary = Z, secondaries = A, C, D }. RBridge, знающий об этой группировке и подключенный к одной из вторичных VLAN в группе, заявляет также свою принадлежность к первичной VLAN. Таким образом, RBridge, подключенный к A, будет также заявлять свое подключение к Z. RBridge, подключенный к первичной VLAN, будет также заявлять свое подключение ко всем VLAN в группе.

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

4.9. Порты RBridge

В параграфе 4.9.1 описано несколько битов конфигурации порта RBridge, в параграфе 4.9.2 приведена логическая структура порта, а параграфы 4.9.3 и 4.9.4 посвящены обработке высокоуровневых кадров управления.

4.9.1. Конфигурация порта RBridge

Имеется 4 бита, задающие конфигурацию порта²⁰.

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

Если в DRB RB1 этот бит не установлен, но у соседа по каналу RB2 установлен, RB1 не будет назначать RB2 пересылающим для какой-либо VLAN и ни один из RBridge (включая псевдоузлы) не будет указывать RB2 как соседа в своих LSP.

Если порт с отключенным обслуживанием конечных станций сообщает в переданном через этот порт кадре TRILL-Hello, для каких VLAN он поддерживает конечные станции, он указывает отсутствие таковых.
Бит запрета трафика TRILL (порт доступа) устанавливается для предотвращения отправки через порт любых кадров TRILL, за исключением TRILL-Hello, поскольку порт предназначен лишь для естественного трафика конечных станций. По умолчанию этот запрет не установлен. Этот бить указывается в кадрах TRILL-Hello. Если RB1 является DRB и установил этот бит в своем TRILL-Hello, DRB по-прежнему назначает пересылающие мосты для VLAN. Однако обычно в LSP не сообщается о псевдоузлах и каких-либо каналах между RBridge, связанных с этим каналом.

В некоторых случаях даже при установленном DRB флаге порта доступа этот DRB может создать псевдоузел для порта доступа. Тогда другие RBridge сообщают о связности с псевдоузлом в своих LSP, но DRB устанавливает флаг перегрузки (overload) в LSP псевдоузла.
Бит использования P2P Hello, при установке которого пакеты Hello, передаваемые этим портом, являются IS-IS P2P Hello. По умолчанию используются TRILL-Hello (см. параграф 4.2.4.1).

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

         Отключение > P2P > Доступ > Транк

4.9.2. Структура порта RBridge

Порт RBridge можно смоделировать как низкоуровневую структуру, похожую на структуру порта в мосту [802.1Q-2005], как показано на рисунке 11. Двойные линии на рисунке представляют общий поток кадров и информации, а одинарные — только потоки информации. Прерывистый пунктир канала с VRP (GVRP/MVRP) показывает необязательность поддержки VRP. Реальная реализация порта RBridge может иметь иную структуру, обеспечивающую такое же поведение.

                  +----------------------------------------------
                  |                RBridge
                  |
                  |Пересылка между портами, IS-IS.  Управл., ...
                  |
                  +----++----------------------+-------------++--
                       ||                      |             ||
                Данные || TRILL                |             ||
                       ||                   +--+---------+   ||
         +-------------++-----+             | Обработка  |   ||
         |    Инкапсуляция    |      +------+   TRILL    |   ||
         |    Декапсуляция    |      |      | IS-IS Hello|   ||
         |                    |      |      +-----++-----+   ||
         +--------------------+      |            ||         ||
         |  RBridge Appointed +------+            ||         ||
     +---+   Forwarder и      |                   ||         ||
     |   |  Inhibition Logic  +==============\\   ||   //====++
     |   +---------+--------+-+  Естественные  \\ ++ //
     |             |        |    кадры           \++/
     |             |        |                     ||
+----+-----+  +- - + - - +  |                     ||
|Обработка |  |Обработка |  |                     || Все TRILL и
|  RBridge |  |  RBridge |  |                     ||естеств. кадры
|   BPDU   |  |    VRP   |  |                     ||
+-----++---+  + - - -+- -+  |            +--------++--+ <- EISS
      ||             |      |            | Обработка  |
      ||            |       |            |   802.1Q   |
      ||             |      |            | Port VLAN  |
      ||            |       |            | и Priority |
  +---++------------++------+------------+------------+ <-- ISS
  |        Обработка 802.1/802.3 Low-Level Control    |
  |        Frame, Port/Link Control Logic             |
  +------------++-------------------------------------+
               ||
               ||        +------------+
               ||        | 802.3 PHY  |
               ++========+(физический +======== Канал 802.3
                         | интерфейс) |         
                         +------------+

Рисунок 11. Модель порта RBridge.

Низкоуровневые кадры управления обрабатываются управляющей логикой порта (канала) как это происходит в портах моста [802.1Q-2005]. Это может дополнительно включать разные протоколы 802.1 или связанные с каналом протоколы, такие как PAUSE (Annex 31B of [802.3]), обнаружение канального уровня [802.1AB], агрегирование каналов [802.1AX], защита MAC [802.1AE] или контроль доступа на уровне порта [802.1X]. Эти кадры обрабатываются на низком уровне, но могут влиять на высокоуровневую обработку. Например, протокол регистрации L2 может влиять на достоверность полученных при обучении адресов. Верхний интерфейс к этой низкоуровневой логике управления в порту соответствует службе внутреннего подуровня ISS (Internal Sublayer Service) [802.1Q-2005].

Высокоуровневые кадры управления (BPDU и VRP, при его поддержке) не имеют тегов VLAN. Хотя эти кадры передаются через интерфейс ISS, они не подвергаются обработке VLAN на порту. Поведение при получении BPDU или VRP с тегом VLAN не определено. Если VRP не реализован, все кадры VRP отбрасываются. Обработка BPDU описана в параграфе 4.9.3, а обработка кадров VRP — в параграфе 4.9.4.

Для кадров, отличающихся от кадров управления L2 (т. е. все кадры TRILL и естественные кадры), выполняется обработка VLAN и приоритета, как в мостах [802.1Q-2005]. Верхний интерфейс к обработке в порту VLAN и приоритета соответствует расширенной службе внутреннего подуровня EISS (Extended Internal Sublayer Service) [802.1Q-2005].

В этой модели операции порта RBridge ниже уровня EISS идентичны операциям в мостах [802.1Q-2005] за исключением (1) обработки высокоуровневых кадров и (2) того, что отбрасывание кадров с превышением максимальной задержки при передаче (MTD — Maximum Transit Delay) не обязаьельно, но возможно.

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

TRILL-Hello, зонды MTU и подтверждения MTU обрабатываются на уровне порта и, подобно кадрам TRILL IS-IS, никогда не пересылаются. Они могут влиять на назначенного пересылающего и логику блокировки, а также на LSP RBridge.

За исключением TRILL-Hello, зондов и подтверждений MTU, все управляющие кадры TRILL, а также кадры данных TRILL и кадры ESADI передаются для высокоуровневой обработки RBridge при получении и передаются вниз для отправки или пересылки. Отметим, что эти кадры никогда не блокируются логикой назначенного пересылающего и блокировки, которая влияет лишь на естественные кадры, но имеются дополнительные фильтры, такие как RPF.

4.9.3. Обработка BPDU

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

4.9.3.1. Прием BPDU

RBridge должны «слушать» BPDU с конфигурацией связующего дерева, принимаемые на порту, и отслеживать корневой мост на канале, если он имеется. Если на канале применяется протокол MSTP, это корень CIST. Такая информация сообщается на уровне VLAN мостом RBridge в его LSP и может применяться, как указано в параграфе 4.2.4.3. Кроме того, получение BPDU с конфигурацией связующего дерева используется в качестве индикации того, что канал относится к ЛВС на основе мостов, что может влиять не передачу RBridge пакетов BPDU.

RBridge недопустимо инкапсулировать или пересылать получаемые кадры BPDU.

RBridge отбрасывает BPDU с изменениями топологии, учетом параграфа 4.9.3.3.

4.9.3.2. Смена корневого моста

Смена корневого моста, видимая в BPDU связующего дерева, принимаемых на порту RBridge, может указывать изменение топологии ЛВС на основе мостов, включая возможное слияние двух ЛВС и т. п., без какой-либо физической индикации на порту. Во время изменения топологии мосты могут переходить в состояние pre-forwarding, где блокируются кадры TRILL-Hello. По этой причине RBridge, видя смену корневого моста на порту, для которого он назначен пересылающим в одной или нескольких VLAN, блокируется на время до 30 секунд. Блокировка заставляет назначенного для пересылки отбрасывать все естественные кадры принятые или предназначенные для отправки через канал. Интервал блокировки настраивается в конфигурации и по умолчанию составляет 30 секунд.

Рассмотрим в качестве примера две ЛВС на основе мостов, поддерживающие множество VLAN, со своими RBridge в качестве назначенных пересылающих. Если сети будут объединены путем подключения кабеля или иным способом, RBridge, подключенные к исходной ЛВС на основе мостов с более низким приоритетом корня, увидят смену корневого моста, а в друго ЛВС этого не произойдет. Таким образом, все назначенные пересылающие в сети с более низким приоритетом будут заблокированы на время, пока все не будет рассортировано с помощью BPDU в объединенной сети и кадров TRILL-Hello между вовлеченными RBridge.

4.9.3.3. Передача BPDU

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

RBridge могут поддерживать передачу spanning tree BPDU в целях принудительного разделения ЛВС на основе мостов в соответствии с Приложением A.3.3.

4.9.4. Динамическая регистрация VLAN

Динамическая регистрация VLAN позволяет мостам (реже, конечным станциям) запрашивать включение или отключение VLAN на портах, ведущих к запрашивающей стороне. Это делается с помощью кадров протокола регистрации VLAN (VRP²¹) — GVRP или MVRP. RBridge могут реализовать GVRP и/или MVRP, как описано ниже.

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

На портах RBridge можно включить динамические VLAN. Если RBridge поддерживает VRP, реальное включение динамических VLAN определяется кадрами GVRP/MVRP, полученными на порту, как на мостах [802.1Q-2005] и [802.1ak].

RBridge, поддерживающий VRP, передает кадры GVRP/MVRP как мост [802.1Q-2005] или [802.1ak] на каждом порту, не настроенном как транковый порт RBridge или порт P2P. С этой целью он передает кадры VRP для запроса трафика в тех VLAN, где он назначен пересылающим и в Designated VLAN, если Designated VLAN не отключена на порту. Трафик других VLAN не запрашивается.

5. Параметры RBridge

В этом разделе приведен список параметров RBridge. Предполагается, что TRILL MIB будет включать многие из указанных здесь элементов, а также другие данные о состоянии RBridge, а также сведения о трафике и ошибках.

TRILL добавляет принятые по умолчанию значения и диапазоны. Для параметров в форме 16-битовых целых чисел без знака при отсутствии указанного максимума принимается максимальное значение 2¹⁶-1. Для параметров, импортированных из [802.1Q-2005], [802.1D] и IS-IS [ISO10589] [RFC1195] принятые по умолчанию значения и диапазоны указаны в соответствующих стандартах.

5.1. Параметры для RBridge в целом

Ниже перечислены параметры, встречающиеся в RBridge.

Число псевдонимов, которое по умолчанию составляет 1 и может быть задано в диапазоне от 1 до 256.
Желаемое число деревьев распространения для расчета каждым RBridge в кампусе и желаемое число деревьев распространения, анонсируемых RBridge для использования. Задаются 16-битвыми целыми числами без знака, по умолчанию 1 (параграф 4.5).
Максимальное число деревьев распространения, которые RBridge может рассчитать. Выражается 16-битовым целым числом без знака, которое зависит от реализации и окружения, но не может быть изменено в конфигурации.
Два списка псевдонимов деревьев распространения — рассчитываемые и используемые, как описано в параграфе 4.5. По умолчанию списки пусты.
Параметры Ageing Timer и Forward Delay, их значения по умолчанию и диапазоны описаны в [802.1Q-2005].
Два октета без знака, представляющие достоверность триплетов { MAC, VLAN, локальный порт }, полученных из принятых локально естественных кадров, и триплетов { MAC, VLAN, удаленный RBridge }, полученных из декапсулированных кадров. По умолчанию октеты имеют значение 0x20, а диапазон составляет 0x00 — 0xFE.
Желаемое значение минимального подходящего MTU на каналах между RBridge в кампусе, т. е. originatingLSPBufferSize. Это 16-битовое целое число без знака, задающее размер в октетах и по умолчанию равное 1470, которое является минимальным приемлемым MTU. При анонсировании меньших значений они игнорируются.
Число неудачных попыток проверки MTU, после которого RBridge считает, что конкретное значение MTU не поддерживается. По умолчанию заданы 3 попытки, допустимы значения от 1 до 255.

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

5.2. Параметры для каждого псевдонима в RBridge

RBridge имеет перечисленные ниже параметры конфигурации для каждого псевдонима.

Приоритет удержания псевдонима со значением по умолчанию 0x40, если конкретного псевдонима не задано и 0xC0 в противном случае (параграф 3.7.3).
Приоритет псевдонима при выборе корня дерева распространения в виде 16-битового целого числа без знака (по умолчанию 0x8000).
Значение псевдонима в виде 16-битового целого числа без знака. По умолчанию принимается заданное в конфигурации значение, а при его отсутствии — последнее использованное значение, если RBridge инициализируется после перезагрузки и случайное значение в остальных случаях. Однако в любом случае резервные значения 0x0000 и 0xFFC0 — 0xFFFF не используются (параграф 3.7.3).

5.3. Параметры для каждого порта в RBridge

RBridge имеет перечисленные ниже параметры конфигурации для каждого порта.

Такой же набор параметров, как у порта [802.1Q-2005] в терминах C-VLAN ID. В дополнение к этому имеется набор Announcing VLANs с разрешенными по умолчанию VLAN на порту (параграф 4.4.3) и диапазоном от пустого набора до всех разрешенных VLAN.
Такой же набор параметров, как у порта [802.1Q-2005] в терминах отображения кода приоритета для кадра (см. [802.1Q-2005]).
Время запрета для порта когда он фиксирует смену корневого моста в подключенной ЛВС на базе мостов. Время указывается в секундах и может принимать значения от 0 до 30 (принято по умолчанию).
Desired Designated VLAN, которую RBridge будет анонсировать в своих TRILL Hello, если он является DRB для канала через этот порт. По умолчанию используется меньший идентификатор VLAN, разрешенных на порту, и в конфигурации может быть задан идентификатор любой действительной VLAN, разрешенной на этом порту (от 0x001 до 0xFFE).
4 конфигурационных бита на порт — отключен (по умолчанию 0 — включен), отключено обслуживание конечных станций (транк, по умолчанию 0 — не транк), порт доступа (по умолчанию 0 — не только порт доступа) и использование P2P Hello (по умолчанию 0 — используются TRILL Hello), см. параграф 4.9.1.
Один бит на порт, установка которого запрещает определение триплетов {MAC-адрес, VLAN, порт} из локально принятых портом естественных кадров (по умолчанию 0 — обучение разрешено).
Приоритет RBridge при выборе DRB и время удержания (Holding Time) для этого порта с использованием по умолчанию значения, заданных в IS-IS [ISO10589] [RFC1195].
Бит, установка которого разрешает прием кадров с инкапсуляцией TRILL от Outer.MacSA, с которым RBridge не имеют смежности IS-IS (по умолчанию 0 — запрещено).
Необязательная конфигурация передачи BPDU для решения проблемы кабельного шкафа, описанной в Приложении A.3.3. По умолчанию адресом моста является System ID устройства RBridge с меньшим значением System ID. Если RB1 и RB2 являются частью топологии кабельного шкафа, оба устройства должны быть настроены так, чтобы знать об этом и знать идентификатор, который следует использовать в протоколе STP на заданном порту.

5.4. Параметры для каждой VLAN в RBridge

RBridge имеет перечисленные ниже параметры конфигурации для каждой VLAN.

Флаг участия в протоколе ESADI, 7-битовое значение приоритета и время удержания (Holding Time). По умолчанию флаг сброшен, используемые по умолчанию значения приоритета и времени удержания заданы в IS-IS [ISO10589] [RFC1195].
Один бит для каждой VLAN, указывающий запрет определения триплетов {MAC-адрес, VLAN, удаленный RBridge} из кадров, декапсулированных в VLAN. По умолчанию бит сброшен (0) и обучение разрешено.

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

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

К число мер противодействия относятся настройка для протоколов TRILL IS-IS и ESADI защиты IS-IS [RFC5304] [RFC5310], а также игнорирование неаутентифицированных кадров управления TRILL и кадров ESADI. При использовании защиты IS-IS требуется настройка конфигурации RBridge.

Могут использоваться также механизмы допуска портов и защиты каналов IEEE 802.1 типа [802.1X] и [802.1AE]. Их лучше всего рассматривать как реализованные ниже TRILL (параграф 4.9.2) и не входящие в сферу действия (просто потому, что они, как правило, выходят за рамки стандартов для мостов [802.1D] и 802.1Q). Однако TRILL может использовать защищенную регистрацию через уровень доверия дополнительного протокола TRILL ESADI (параграф 4.8).

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

RBridge не мешают узлу выдавать себя за другой узел, например, путем отправки ложных откликов ARP/ND. Однако RBridges не конфликтуют с какими-либо схемами, защищающими обнаружение соседей.

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

Протокол TRILL поддерживает VLAN. Это обеспечивает логическое разделение трафика, но требует внимания к вопросам безопасности использования VLAN. Для обеспечения гарантий разделения все RBridge и каналы (включая ЛВС на базе мостов) в кампусе должны быть защищены и настроены так, чтобы блокировать использование кадров динамической регистрации VLAN конечными станциями или получение ими доступа к каким-либо VLAN, передающим трафик, для которого эти станции не имеют полномочий.

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

6.2. DoS-атаки BPDU/Hello

Протокол TRILL требует, чтобы назначенный узел пересылки на порту RBridge временно блокировался, если он видит кадр TRILL-Hello от другого RBridge, заявляющий себя назначенным узлом пересылки для той же VLAN, или корневой мост меняет порт. Таким образом, может показаться, что обманные BPDU, указывающие повторяющуюся смену корневого моста, или обманные кадра TRILL-Hello с установленным флагом Appointed Forwarder позволяют организовать серьезную атаку на отказ служб. Однако на деле ситуация не столь плоха.

Лучшей мерой против обманных кадров TRILL-Hello и других сообщений IS-IS является использование защиты IS-IS [RFC5304] [RFC5310]. Злонамеренные конечные станции обычно не смогут получить доступа к нужному ключевому материалу IS-IS, а без этого не смогут создать обманных сообщений.

Аутентификация, похожая на защиту IS-IS, обычно недоступна для BPDU. Однако в большинстве современных проводных ЛВС используется только соединения «точка-точка». Если у вас кампус RBridge с соединениями «точка-точка», худшее, что может сделать конечная точка с помощью обманных BPDU или кадров TRILL-Hello, это предотвращение обслуживания самой себя. Это можно сделать путем блокировки пересылки естественных кадров на RBridge, к которому станция подключена, или путем ложно активации проверки декапсуляции (параграф 4.2.4.3).

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

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

7. Вопросы выделения значений

В этом разделе рассмотрено выделение значений через IANA и IEEE 802 (см. [RFC5226]).

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

Создан новый реестр IANA для параметров TRILL, в котором организовано два описанных ниже субреестра.

Начальное содержимое субреестра TRILL Nicknames приведено ниже.

0x0000 - резерв для индикации отсутствия псевдонима
0x0001-0xFFBF - динамически назначаются устройствами RBridge в каждом кампусе RBridge
0xFFC0-0xFFFE - доступны для выделения по процедуре RFC Required (1 значение) или IETF Review (1 или множество значений)
0xFFFF - постоянный резерв.

Начальное содержимое субреестра TRILL Multicast Address приведено ниже.

     01-80-C2-00-00-40  - All-RBridges
     01-80-C2-00-00-41  - All-IS-IS-RBridges
     01-80-C2-00-00-42  - All-ESADI-RBridges
     01-80-C2-00-00-43 to 01-80-C2-00-00-4F - доступны для выделения по процедуре IETF Review.

7.2. Регистрация значений в IEEE

Значение Ethertype 0x22F3 назначено IEEE Registration Authority для протокола TRILL.

Значение Ethertype 0x22F4 назначено IEEE Registration Authority для L2-IS-IS.

Блок из 16 групповых MAC-адресов <01-80-C2-00-00-40> — <01-80-C2-00-00-4F> назначен IEEE Registration Authority для использования протоколом IETF TRILL.

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

[802.1ak] «IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks / Multiple Registration Protocol», IEEE Standard 802.1ak-2007, 22 June 2007.

[802.1D] «IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges», 802.1D-2004, 9 June 2004.

[802.1Q-2005] «IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks», 802.1Q-2005, 19 May 2006.

[802.3] «IEEE Standard for Information technology / Telecommunications and information exchange between systems / Local and metropolitan area networks / Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications», 802.3-2008, 26 December 2008.

[ISO10589] ISO/IEC, «Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)», ISO/IEC 10589:2002.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, August 1989.

[RFC1195] Callon, R., «Use of OSI IS-IS for routing in TCP/IP and dual environments», RFC 1195, December 1990.

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

[RFC2464] Crawford, M., «Transmission of IPv6 Packets over Ethernet Networks», RFC 2464, December 1998.

[RFC2710] Deering, S., Fenner, W., and B. Haberman, «Multicast Listener Discovery (MLD) for IPv6», RFC 2710, October 1999.

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, «Internet Group Management Protocol, Version 3», RFC 3376, October 2002.

[RFC3417] Presuhn, R., Ed., «Transport Mappings for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3417, December 2002.

[RFC3419] Daniele, M. and J. Schoenwaelder, «Textual Conventions for Transport Addresses», RFC 3419, December 2002.

[RFC4286] Haberman, B. and J. Martin, «Multicast Router Discovery», RFC 4286, December 2005.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, «Three-Way Handshake for IS-IS Point-to-Point Adjacencies», RFC 5303, October 2008.

[RFC5305] Li, T. and H. Smit, «IS-IS Extensions for Traffic Engineering», RFC 5305, October 2008.

[RFC6165] Banerjee, A. and D. Ward, «Extensions to IS-IS for Layer-2 Systems», RFC 6165, April 2011.

[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, «Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS», RFC 6326, July 2011.

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

[802.1AB] «IEEE Standard for Local and Metropolitan Networks / Station and Media Access Control Connectivity Discovery», 802.1AB-2009, 17 September 2009.

[802.1ad] «IEEE Standard for and metropolitan area networks / Virtual Bridged Local Area Networks / Provider Bridges», 802.1ad-2005, 26 May 2005.

[802.1ah] «IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Provider Backbone Bridges», 802.1ah-2008, 1 January 2008.

[802.1aj] Virtual Bridged Local Area Networks / Two-Port Media Access Control (MAC) Relay, 802.1aj Draft 4.2, 24 September 2009.

[802.1AE] «IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Security», 802.1AE-2006, 18 August 2006.

[802.1AX] «IEEE Standard for Local and metropolitan area networks / Link Aggregation», 802.1AX-2008, 1 January 2008.

[802.1X] «IEEE Standard for Local and metropolitan area networks / Port Based Network Access Control», 802.1X-REV Draft 2.9, 3 September 2008.

[RBridges] Perlman, R., «RBridges: Transparent Routing», Proc. Infocom 2005, March 2004.

[RFC1661] Simpson, W., Ed., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, «An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks», STD 62, RFC 3411, December 2002.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

[RFC4541] Christensen, M., Kimball, K., and F. Solensky, «Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches», RFC 4541, May 2006.

[RFC4789] Schoenwaelder, J. and T. Jeffree, «Simple Network Management Protocol (SNMP) over IEEE 802 Networks», RFC 4789, November 2006.

[RFC5304] Li, T. and R. Atkinson, «IS-IS Cryptographic Authentication», RFC 5304, October 2008.

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, «IS-IS Generic Cryptographic Authentication», RFC 5310, February 2009.

[RFC5342] Eastlake 3rd, D., «IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters», BCP 141, RFC 5342, September 2008.

[RFC5556] Touch, J. and R. Perlman, «Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement», RFC 5556, May 2009.

[RP1999] Perlman, R., «Interconnection: Bridges, Routers, Switches, and Internetworking Protocols, 2nd Edition», Addison Wesley Longman, Chapter 3, 1999.

[VLAN-MAPPING] Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., and D. Eastlake 3rd, «RBridges: Campus VLAN and Priority Regions», Work in Progress, April 2011.

Приложение A. Вопросы поэтапного развертывания

Некоторые аспекты частичного развертывания RBridge описаны ниже для определения стоимости каналов (Приложение A.1) и возможных перегрузок в результате пробок на назначенном устройстве пересылки ( Приложение A.2). В Приложении A.3 рассмотрен конкретный пример проблемы, связанной с использованием TRILL одного назначенного устройства пересылки на канал и VLAN .

A.1. Определение стоимости канала

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

+-----+        +----+        +----+        +-----+
|     |Быстрый |    |Медлен. |    |Быстрый |     |
| RB1 +--------+ B1 +--------+ B2 +--------+ RB2 |
|     | канал  |    | канал  |    | канал  |     |
+-----+        +----+        +----+        +-----+

Рисунок 12. Стоимость канала с мостами.

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

Однако эта проблема присуща не только RBridge. Мосты могут сталкиваться с подобными ситуациями в результате сокрытия каналов повторителями, а маршрутизаторы — в результате сокрытия мостами, повторителями и RBridge.

A.2. Назначенные устройства пересылки и ЛВС на базе мостов

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

Требование входа (и выхода) естественных кадров в канал через назначенный для канала узел пересылки для VLAN, к которой относится кадр, может приводить к насыщению и неоптимальной маршрутизации (похожие проблемы могут возникать в ЛВС на базе мостов в результате использования алгоритма STP). Область влияния этой проблемы сильно зависит от топологии сети. Например, если ЛВС использует топологию «звезда» с мостами ядра, к которым подключены лишь другие мосты, и соединенными с ядром периферийными мостами, к которым подключены конечные станции, замена всех мостов в ядре на RBridge без замены периферийных мостов обычно будет повышать производительность без возникновения перегрузки устройств пересылки.

Решения этой проблемы описаны ниже, а в Приложении A.3 рассмотрен конкретный пример.

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

Имеется 4 метода решения описанной выше проблемы, которые в той или иной степени можно комбинировать.

Замена больше части пользовательских мостов IEEE 802.1 на RBridge для минимизации числа остающихся ЛВС на базе мостов между RBridge. Это не требует настройки RBridge, если заменяемые ими мосты не требовали настройки конфигурации.
Изменение топологии сети для минимизации проблемы. Если вовлеченные в процесс мосты и RBridge были настроены, может потребоваться изменение настроек.
Настройка RBridge и мостов так, чтобы оставшиеся станции ЛВС на базе мостов были разделены по разным VLAN с разными назначенными узлами пересылки. Если конечные станции уже находятся в разных VLAN, сделать это просто (параграф 4.2.4.2). если конечные станции находятся в одной VLAN и должны быть распределены по разным, этот метод может привести к проблемам связности между конечными станциями.
Настройка RBridge так, чтобы их порты, подключенные к ЛВС на базе мостов, передавали BPDU настройки STP (Приложение A.3.3) для форсированного разделения ЛВС на базе мостов²². Для использования этого метода RBridge должны поддерживать эту необязательную функцию и для этого потребуется их настройка, но вовлеченные в процесс мосты обычно настраивать не требуется. Этот метод делает сеть на базе мостов недоступной для трафика TRILL по причине ее разделения.

В отличие от п. 3 могут существовать ЛВС на базе мостов, использующие VLAN, может применяться больше VLAN, чем требуется для поддержки протокола MSTP²³ или могут использоваться иные меры снижения перегрузок, вызываемых одним деревом STP. Замена мостов IEEE 802.1 в таких ЛВС на RBridge может привести к снижению числа VLAN или отказу от них с соответствующим упрощением настройки.

A.3. Топология кабельного шкафа

Если имеются мосты 802.1, а RBridge не настроены корректно, связующее дерево моста или DRB могут принимать некорректные решения. Ниже приведен конкретный пример более общей проблемы, которая может возникать при подключении ЛВС на основе мостов по множеству RBridge.

При наличии двух (и более) групп конечных узлов, каждая из которых подключена к мосту (скажем, B1 и B2), а каждый мост подключен к RBridge (скажем, RB1 и RB2, соответственно) и имеется дополнительный канал между B1 и B2 (см. Рисунок 13) может оказаться желательным использовать канал B1-B2 лишь в качестве резервного на сдучай отказа одного из устройств RB1 и RB2 или каналов B1-RB1 и B2-RB2.

+-------------------------------+
|             |          |      |
|Центр     +-----+    +-----+   |
|обработки-| RB1 |----| RB2 |-  |
|данных    +-----+    +-----+   |
|             |          |      |
+-------------------------------+
              |          |
              |          |
+-------------------------------+
|             |          |      |
|          +----+     +----+    |
|Кабельный | B1 |-----| B2 |    |
|шкаф ЛВС  +----+     +----+    |
|на базе                        |
|мостов                         |
+-------------------------------+

Рисунок 13. Топология кабельного шкафа.

Например, B1 и B2 могут размещаться в кабельном шкафу и для них легко можно организовать короткое, высокоскоростное и недорогое соединения, а RB1 и RB2 — в удаленном центре обработки данных, поэтому каналы RB1-B1 и RB2-B2 будут более медленными и дорогими.

В используемом по умолчанию варианте поведения один из RB1 и RB2 (скажем, RB1) может стать DRB для ЛВС на базе мостов, включающей B1 и B2, и назначит себя устройством пересылки для VLAN этой ЛВС. В результате RB1 будет пересылать весь трафик в канал (из канала) и конечные узлы, подключенные к B2, будут соединены с кампусной сетью по пути B2-B1-RB1, а не по желаемому каналу B2-RB2. Это будет вести к расходу пропускной способности пути B2-RB2 и сокращать пропускную способность между конечными станциями и центром обработки данных наполовину. Желаемым поведением будет использование обоих каналов RB1-B1 и RB2-B2.

Ниже описаны три варианта решения этой проблемы.

A.3.1. Решение на основе RBridge

Если B1 и B2 заменить на RBridge, все будет работать без настройки (за исключением поддержки VLAN), но это может быть неразумно при постепенном переходе на RBridge.

A.3.2. Решение на основе VLAN

Если конечные станции, подключенные к B1 и B2 уже разделены между множеством VLAN, RB1 и RB2 могут оказаться настроенными так, что в зависимости от выбора одного из них в качестве DRB для этого канала он будет назначать себя устройством пересылки для некоторых VLAN, а другой RBridge — для оставшихся VLAN. При отказе или отключении любого из RBridge оставшийся будет назначать себя устройством пересылки для всех VLAN.

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

A.3.3. Решение на основе STP

Другим решением является настройка соответствующих портов RB1 и RB2 в составе «группы кабельного шкафа» с заданием для каждого RBridge порта Bridge Address Bx (которые может быть идентификатором системы RB1 RB2). Оба устройства RB1 и RB2 передают BPDU для своих настроенных портов, указывая их как корень Bx с высшим приоритетом. Это разделяет ЛВС на базе мостов путем блокировки канала B1-B2 на той или другой стороне (если один из мостов не настроен с высшим приоритетом и меньшим ID, что будет считаться ошибкой конфигурации). При заблокированном канале B1-B2 устройства RB1 и RB2 не смогут видеть сообщений TRILL-Hello друг от друга через этот канал и каждый будет действовать как DRB и назначенное устройство пересылки в соответствующей части дерева. При таком разделении трафик TRILL не будет проходить по пути RB1-B1-B2-RB2.

В BPDU настройки связующего дерева в качестве Root указывается Bx с высшим приоритетом, стоимость для Root равна 0, идентификатором DB является RB1 (когда кадр передает RB1) или RB2 (когда передает RB2), а значение идентификатора порта выбирается RB1 и RB2 независимо, чтобы различать свои порты. Флаг изменения топологии сброшен, а флаг подтверждения изменения топологии установлен, если на порту был принят BPDU изменения топологии пос ле того, как этот порт передал последний конфигурационный BPDU. Если RB1 и RB2 являются мостами одной сети с разделяемой средой (т. е. между ними нет других мостов), мост с большим идентификатором увидит «лучшие» BPDU (по причине tiebreaker в третьем поле — идентификатора передающего моста) и выключит свой порт.

Если возникнет отказ RB1 или канала RB1-B1, либо RB2 или канала RB2-B2, алгоритм связующего дерева перестанет видеть один из корней RBx и разблокирует канал B1-B2, поддерживая связность конечных станцию с центром обработки данных.

Если канал RB1-B1-B2-RB2 находится на срезе кампуса, а RB2 и RB1 настроены как часть группы кабельного шкафа, кампус разделится на две части при блокировке канала.

A.3.4. Сравнение решений

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

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

В данном конкретном случае решение с связующим деревом достаточно хорошо. Но оно зависит от наличия на RB1 и RB2 дополнительной возможности настройки порта на передачу STP BPDU в соответствии с Приложением A.3.3. Это также делает ЛВС на базе мостов, разделение которой было форсировано, недоступной для сквозного трафика. Наконец, хотя в этом конкретном примере аккуратно разрывается канал между двумя мостами B1 и B2, при наличии более сложной ЛВС на базе мостов, а не просто пары мостов, не будет гарантии разделения на две равные части. В таких случаях может возникнуть сильно разбалансированная нагрузка на каналы RB1-B1 и RB2-B2, хотя это лучше, чем явное использование лишь одного из этих каналов.

Приложение B. Настройка транкового порта и порта доступа

Во многих современных ЛВС на базе мостов используется модель с уровнями ядра и доступа. Мосты уровня ядра имеют с другими мостами лишь соединения «точка-точка», а мосты уровня доступа соединены с конечными станциями, мостами ядра и возможно с другими мостами доступа. Представляется очевидной организаций некоторых кампусов RBridge по аналогичной схеме.

Порт RBridge можно настроить в качестве транкового, т. е. соединяющего с другим или другими RBridge, путем запрета на нем поддержки конечных станций. Это не является причиной поддержки на таком порту множества VLAN и их включения в Announcing Set. Конечно другие RBridge, которым подключен данный, должны поддерживать ту же VLAN. Нет причин использовать для этого VLAN, отличную от принятой по умолчанию VLAN 1, если канал не проходит через операторскую сеть Ethernet или другие среды, которые потребуют работать с другим значением VLAN. Такая конфигурация минимизирует издержки, связанные с сообщениями TRILL-Hello и предотвращает ненужную декапсуляцию, а также передачу кадров для множества получателей в естественной форме (параграфы 4.2.4 и 4.9.1).

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

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

Приложение C. Поддержка множества путей

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

Трафик с множеством получателей может передаваться по множеству путей за счет использования разных корней дерева распространения для разных кадров. Например, предположим, что на рисунке 14 конечные станции, подключенные к RBy являются источниками разных групповых потоков, каждый из которых имеет множество «слушателей», подключенных к RB1 — RB9. В предположении каналов с одинаковой пропускной способностью дерево распространения с корнем RBy будет использовать преимущественно вертикальные каналы между RB1 — RB9, а дерево с корнем RBz будет использовать преимущественно горизонтальные каналы. Если RBy выберет свой псевдоним в качестве корня дерева для половины этого трафика, а RBz сделает то же для другой половины, это позволит существенно увеличить суммарную пропускную способность за счет использования вертикальных и горизонтальных каналов между RB1 — RB9.

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

        +---+
        |RBy|---------------+
        +---+               |
       /  |  \              |
     /    |    \            |
   /      |      \          |
+---+   +---+   +---+       |
|RB1|---|RB2|---|RB3|       |
+---+   +---+   +---+\      |
  |       |       |    \    |
+---+   +---+   +---+    \+---+
|RB4|---|RB5|---|RB6|-----|RBz|
+---+   +---+   +---+    /+---+
  |       |       |    /
+---+   +---+   +---+/
|RB7|---|RB8|---|RB9|
+---+   +---+   +---+

Рисунок 14. Множество путей ко множеству адресатов.

ECMP для заведомо индивидуального трафика может возникать на RBridge, если вместо использования критерия «удаления лишнего» (tiebreaker) при построении SPF будет сохраняться информация о портах, через которые доступны равноценные пути. Разные индивидуальные кадры могут тогда передаваться через разные порты и пересылаться по равноценным путям. Например, на рисунке 15, где показаны лишь RBridge и опущены все имеющиеся мосты, существует три равноценных пути между RB1 и RB2, а также два равноценных пути между RB2 и RB5. Таким образом, для трафика проходящего через эту часть кампуса слева направо, RB1 сможет выбирать из трех вариантов ECMP, а RB2 — из двух.

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

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

Если два или три из этих путей включают псевдоузлы, все 3 пути будут четко видны в состояниях каналов кампуса и применимо описанное выше использование ECMP.
Если пути используют сообщения P2P Hello или (в противном случае) не включают псевдоузлов, эти три пути в состоянии каналов будут представляться единой смежностью (adjacency). В этом случае использование множества путей между ними полностью определяется локально в RB1 и RB2. Множество путей можно свободно использовать для заведомо индивидуальных кадров, но не для кадров с множеством получателей (параграф 4.5.2).
Если все три пути между RB1 и RB2 являются одноэтапными (single hop) и имеют одинаковую пропускную способность, преимущественным решением будет их объединение в один логический канал с помощью функции агрегирования [802.1AX]. Устройства RBridge могут реализовать объединение каналов, поскольку эта функция реализована ниже TRILL (параграф 4.9.2).

                      +---+       === = 10 Гбит/с
        -----      ===|RB3|---    --- = 1 Гбит/с
       /     \   //   +---+   \
   +---+     +---+            +---+
===|RB1|-----|RB2|            |RB5|===
   +---+     +---+            +---+
       \     /   \    +---+   //
        -----     ----|RB4|===
                      +---+

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

При использовании множества путей кадры, проходящие по разным путям, могут сталкиваться с разными задержками, что может приводить к нарушению порядка доставки. Хотя часть трафика не чувствительна к таким нарушениям, большая часть трафика связана с потоками кадров, в которых нарушение порядка играет роль. Способы определения потоков и уровень их детализации выходят за рамки документа (эти вопросы рассмотрены в [802.1AX]).

Приложение D. Определение VLAN и Priority

Ниже приведена краткая информация о способах определения VLAN ID и приоритета во входящих кадрах. Более подробные сведения можно получить из [802.1Q-2005].

При получении естественного кадра без тегов не настроенный RBridge связывает с ним принятый по умолчанию приоритет 0 и VLAN ID 1. Фактически он устанавливает для непомеченного кадра в качестве идентификатора VLAN связанный с портом идентификатор «port VLAN ID». Этот идентификатор по умолчанию соответствует VLAN ID 1, но в конфигурации может быть задано другое значение VLAN ID. RBridge можно также настроить на уровне отдельного порта на отбрасывание таких кадров или связывание с ними жругого уровня приоритета. Определение VLAN ID для не помеченного входного кадра, не относящегося к управлению, возможно также на основе Ethertype или NSAP (в 802.1 называется Protocol) в принятом кадре, MAC-адреса отправителя и других локальных правил.
При получении естественного кадра с тегом приоритета не настроенный RBridge связывает с ним VLAN ID для порта (по умолчанию 1) и код приоритета, представленный тегом приоритета в кадре. RBridge можно настроить на уровне порта на отбрасывание таких кадров или связывание с ними другого VLAN ID, как указано выше. Можно также настроить отображение на код приоритета путем задания для каждого из 8 возможных значений в кадре нужно кода приоритета, который RBridge свяжет с этим кадром.
Естественные кадры с C-тегом (раньше назывался Q-тегом) на не настроенном RBridge связываются с VLAN ID и приоритетом из C-тега. RBridge можно настроить на уровне порта и VLAN на отбрасывание таких кадров. Можно также на уровне порта настроить отображение приоритета, как описано выше для кадров с тегом приоритета.

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

Приложение E. Поддержка поправок к стандарту IEEE 802.1Q-2005

В этом информационном приложении кратко описана поддержка в RBridge завершенных и разрабатываемых поправок к стандарту IEEE [802.1Q-2005]. Нет никаких гарантий, что текущие спецификации протокола RBridge и имеющиеся мосты будут поддерживать еще не завершенные поправки к [802.1Q-2005] точно так же, как нет гарантий поддержки существующими протоколами мостов или RBridge еще не разработанных поправок для TRILL.

Приведенная ниже информация отражает состояние на 25 октября 2009 г. Более свежую информацию можно найти на странице рабочей группы IEEE 802.1 (http://grouper.ieee.org/groups/802/1/).

E.1. Завершенные поправки

802.1ad-2005 Provider Bridges

Иногда называется Q-in-Q, поскольку теги VLAN называют Q-тегами. Стандарт 802.1ad задает мосты PB, которые туннелируют трафик пользовательских мостов с использованием сервисных VLAN (S-теги). Если пользовательская ЛВС является кампусом RBridge, трафик будет передаваться мостами PB. Элементы пользовательских мостов, осведомленные о PB (типа возможности настройки порта в пользовательском мосту на добавление в кадр S-тега до передачи кадра мосту PB), размещаются ниже уровня EISS и могут поддерживаться мостами RBridge без изменения протокола TRILL.

802.1ag-2007 Connectivity Fault Management (CFM)

Это свойство 802.1 по крайней мере частично зависит от симметрии пути и других характеристик связующего дерева. Комментарии, представленные группе IETF TRILL рабочей группой IEEE 802.1, говорят, что «TRILL снижает применимость CFM».

802.1ak-2007 Multiple Registration Protocol

Поддерживается для расширения, описанного в параграфе 4.9.4.

802.1ah-2008 Provider Backbone Bridges

Иногда называется MAC-in-MAC. Стандарт 802.1ah обеспечивает для PBB, которые туннелируют трафик пользовательских мостов с использованием других внешних MAC-адресов и тега (I-tag) для сохранения исходных MAC-адресов и передачи других сигналов. Если пользовательская ЛВС является кампусом RBridge, трафик будет передаваться мостами PBB. Функции пользовательских мостов, включающие осведомленность о PBB, типа способности настраивать порт пользовательского моста на добавление в кадр I-тега до отправки мосту PBB, размещаются ниже уровня EISS и могут поддерживаться мостами RBridge без изменения протокола TRILL.

802.1Qaw-2009 Management of Data-Driven and Data-Dependent

Отказы соединений. Поправка на основе 802.1ag. См. Комментарий к 802.1ag-2007 выше.

802.1Qay-2009 Provider Backbone Bridge Traffic Engineering

Поправка на основе 802.1ah для настройки маршрутизации при построении трафика. Смотри комментарий к 802.1ah-2008 выше.

E.2. Разрабатываемые поправки

Ниже перечислены поправки к стандарту IEEE [802.1Q-2005], находящиеся в разработке. Приведенные краткие описания основаны на предварительных вариантов стандартов и могут оказаться некорректными для более поздних или окончательных версий.

802.1aj Two-port MAC Relay [802.1aj]

Эта поправка задает ретранслятор MAC, который будет прозрачен для RBridge. Маршрутизирующие мосты RBridge совместимы в настоящее время с устройствами IEEE 802.1aj в том же смысле, что и мосты IEEE 802.1Q-2005.

802.1aq Shortest Path Bridging

Эта поправка обеспечивает улучшенную маршрутизацию в ЛВС на основе мостов.

802.1Qat Stream Reservation Protocol

Изменение 802.1Q для поддержки синхронизации 802.1. Этот протокол резервирует ресурсы на поддерживающих мостах.

802.1Qau Congestion Notification

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

802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive

Потоки — изменение 802.1Q для поддержки протокола синхронизации 802.1 (Timing and Synchronization). Эта поправка задает методы поддержки резервирования ресурсов с помощью протокола 802.1Qat (см. выше).

802.1Qaz Enhanced Transmission Selection

Предполагается, что эта поправка будет работать ниже уровня EISS и сможет поддерживаться на портах RBridge без изменения протокола TRILL.

802.1Qbb Priority-based Flow Control

Обычно называется per-priority pause (пауза для приоритета). Похоже, что эта поправка будет ниже уровня EISS и сможет поддерживаться на портах RBridge без изменения протокола TRILL.

802.1bc Remote Customer Service Interfaces

Расширение 802.1Q PBB. См. 802.1ad-2005 выше.

802.1Qbe Multiple Backbone Service Instance Identifier (I-SID)

Протокол регистрации (MIRP). Расширение для 802.1Q PBB. См. 802.1ah-2008 выше.

802.1Qbf Provider Backbone Bridge Traffic Engineering (PBB-TE)

Защита сегмента инфраструктуры. Расширяет стандарт 802.1Q для поддержки некоторых типов отказоустойчивости между PBB. См. 802.1ah-2008 выше.

Приложение F. Благодарности

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

Bernard Aboba, Alia Atlas, Ayan Banerjee, Caitlin Bestler, Suresh Boddapati, David Michael Bond, Stewart Bryant, Ross Callon, James Carlson, Pasi Eronen, Dino Farinacci, Adrian Farrell, Don Fedyk, Bill Fenner, Eric Gray, Sujay Gupta, Joel Halpern, Andrew Lange, Acee Lindem, Vishwas Manral, Peter McCann, Israel Meilik, David Melman, Nandakumar Natarajan, Erik Nordmark, Jeff Pickering, Tim Polk, Dan Romascanu, Sanjay Sane, Pekka Savola, Matthew R. Thomas, Joe Touch, Mark Townsley, Kate Zebrose.

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

Radia Perlman

Intel Labs

2200 Mission College Blvd.

Santa Clara, CA 95054-1549 USA

Phone: +1-408-765-8080

EMail: Radia@alum.mit.edu

Donald E. Eastlake, 3rd

Huawei Technologies

155 Beaver Street

Milford, MA 01757 USA

Phone: +1-508-333-2270

EMail: d3e3e3@gmail.com

Dinesh G. Dutt

Cisco Systems

170 Tasman Drive

San Jose, CA 95134-1706 USA

Phone: +1-408-527-0955

EMail: ddutt@cisco.com

Silvano Gai

Cisco Systems

170 Tasman Drive

San Jose, CA 95134-1706 USA

EMail: silvano@ip6.com

Anoop Ghanwani

Brocade

130 Holger Way

San Jose, CA 95134 USA

Phone: +1-408-333-7149

EMail: anoop@alumni.duke.edu

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

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

nmalykh@gmail.com

1Routing Bridge.

2Spanning tree protocol — протокол связующего дерева.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Time to Live — время жизни.

6Rapid Spanning Tree Protocol — ускоренный протокол связующего дерева.

7Bridge PDU — блок данных протокола мостов.

8Internal Sublayer Service — сервис внутреннего подуровня.

9Extended Internal Sublayer Service — расширенный сервис внутреннего подуровня.

10Type-length-value — элемент данных «тип-размер-значение».

11В оригинале это предложение содержит ошибки, см. https://www.rfc-editor.org/errata/eid3002. Прим. перев.

12Frame Check Sequence — последовательность проверки кадра.

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

14Common and Internal Spanning Tree — общее и внутреннее связующее дерево.

15В оригинале ошибочно сказано All-Rbridges, см. https://www.rfc-editor.org/errata/eid3004. Прим. перев.

16Designated Router.

17В оригинале ошибочно сказано от N к R, см. https://www.rfc-editor.org/errata/eid3508. Прим перев.

18В оригинале обычно сказано «до максимального из {j,k}», см. https://www.rfc-editor.org/errata/eid3052. Прим. перев.

19В оригинале это предложение содержит ошибки, см. https://www.rfc-editor.org/errata/eid3003. Прим. перев.

20В оригинале этот параграф содержал ошибки, см. https://www.rfc-editor.org/errata/eid4573. Прим. перев.

21VLAN registration protocol.

22Связующее дерево никогда не организуется через RBridge, но всегда завершается на портах RBridge.

23Multiple Spanning Tree Protocol — множество деревьев STP.

Рубрика: RFC | Комментарии отключены

RFC 6242 Using the NETCONF Protocol over Secure Shell (SSH)

Опубликовано 22.06.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                      M. Wasserman
Request for Comments: 6242                        Painless Security, LLC
Obsoletes: 4742                                                June 2011
Category: Standards Track
ISSN: 2070-1721

Использование протокола NETCONF на базе SSH

Using the NETCONF Protocol over Secure Shell (SSH)

PDF

Аннотация

Этот документ описывает использование протокола настройки NETCONF¹ в защищенных сеансах SSH², как подсистемы SSH. Документ отменяет действие RFC 4742.

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

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

Документ является результатом работы IETF³ и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG⁴. Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

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

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

1. Введение

Протокол NETCONF [RFC6241] на основе формата XML служит для настройки сетевого оборудования. Протокол NETCONF определен как сеансовый и не зависимый от транспорта с возможностью отображения на множество протоколов сеансового или транспортного уровня. В этом документе определяется использование NETCONF в сеансах SSH на основе соединений SSH [RFC4254] с транспортным протоколом SSH [RFC4253]. Это отображение позволяет пользователю или приложению применять NETCONF в защищенных сеансах.

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

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

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

3. Начало работы NETCONF на базе SSH

Для запуска NETCONF на основе SSH клиент SSH сначала будет организовывать транспортное соединение SSH с использованием транспортного протокола SSH, а клиент и сервер SSH будут обмениваться ключами для защиты целостности и шифрования сообщений. После этого клиент SSH будет вызывать службу ssh-userauth для проверки подлинности пользователя в соответствии с протоколом аутентификации SSH [RFC4252]. После успешной аутентификации клиент SSH будет вызывать службу ssh-connection, называемую также протоколом соединений SSH.

Имя пользователя, представленное реализацией SSH, будет доступно уровню сообщений NETCONF (как NETCONF username) без изменения. Если имя пользователя не соответствует требованиям NETCONF [RFC6241] (т. е. не может быть представлено в XML), сессия SSH должна быть разорвана. Любые преобразования аутентифицированного отождествления клиента SSH, выполняемые сервером SSH (например, через службы аутентификации или отображение на учетные записи в системе), выходят за рамки этого документа.

После организации соединения SSH клиент будет создавать канал типа session, что приведет к организации сеанса SSH.

После организации сессии SSH клиент NETCONF будет вызывать NETCONF, как подсистему SSH с именем netconf. Поддержка подсистемы является функцией SSH версии 2 (SSHv2) и отсутствует в SSHv1. Работа NETCONF в качестве подсистемы SSH избавляет от необходимости написания сценариев (script) для распознавания системных приглашений (prompt) и позволяет пропустить дополнительную информацию типа системных сообщений, выдаваемых при запуске интерпретатора команд (shell).

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

Пользователь (или приложение) может применять для обращения к NETCONF, как подсистеме SSH, через выделенный IANA порт с использованием команды вида:

   [user@client]$ ssh -s server.example.org -p 830 netconf

Отметим, что опция -s задает выполнение команды netconf, как подсистемы SSH.

3.1. Обмен информацией о возможностях

Как сказано в [RFC6241], сервер NETCONF указывает свои возможности путем передачи документа XML с элементом <hello> сразу после организации сессии NETCONF. Клиент NETCONF может проанализировать это сообщения для определения возможностей NETCONF, поддерживаемых сервером NETCONF.

Как указано в [RFC6241], клиент NETCONF также передает документ XML с элементом <hello> для индикации возможностей клиента NETCONF серверу NETCONF. Документ с элементом <hello> является первым документом XML, который клиент NETCONF передает после организации сессии NETCONF.

Приведенный ниже пример показывает обмен информацией о возможностях. Данные от клиента NETCONF отмечены символами C:, а данные от сервера NETCONF — символами S:.

   S: <?xml version="1.0" encoding="UTF-8"?>
   S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   S:   <capabilities>
   S:     <capability>
   S:       urn:ietf:params:netconf:base:1.1
   S:     </capability>
   S:     <capability>
   S:       urn:ietf:params:ns:netconf:capability:startup:1.0
   S:     </capability>
   S:   </capabilities>
   S:   <session-id>4</session-id>
   S: </hello>
   S: ]]>]]>

   C: <?xml version="1.0" encoding="UTF-8"?>
   C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   C:   <capabilities>
   C:     <capability>
   C:       urn:ietf:params:netconf:base:1.1
   C:     </capability>
   C:   </capabilities>
   C: </hello>
   C: ]]>]]>

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

4. Использование NETCONF на базе SSH

Сессия NETCONF на базе SSH включает клиента и сервер NETCONF, обменивающихся завершенными документами XML. После того, как сессия организована и произошел обмен информацией о возможностях, клиент NETCONF будет передавать завершенные документы XML с элементами <rpc>, а сервер будет отвечать завершенными документами XML с элементами <rpc-reply>.

4.1. Протокол кадрирования

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

После сообщения <hello> должен следовать разделитель ]]>]]>. При получении сообщения <hello> приемная сторона концептуально передает его на уровень сообщений (Messages). Если обе стороны анонсировали возможность :base:1.1, далее в сессии NETCONF используется механизм кадрирования chunked (4.2. Механизм кадрирования Chunked), в противном случае — старый механизм (4.3. Механизм кадрирования End-of-Message).

4.2. Механизм кадрирования Chunked

Этот механизм представляет все сообщения NETCONF с использованием chunked-кадрирования. Сообщения следуют правилу ABNF [RFC5234] Chunked-Message:

        Chunked-Message = 1*chunk
                          end-of-chunks

        chunk           = LF HASH chunk-size LF
                          chunk-data
        chunk-size      = 1*DIGIT1 0*DIGIT
        chunk-data      = 1*OCTET

        end-of-chunks   = LF HASH HASH LF

        DIGIT1          = %x31-39
        DIGIT           = %x30-39
        HASH            = %x23
        LF              = %x0A
        OCTET           = %x00-FF

Поле chunk-size представляет собой строку десятичных цифр, указывающих число октетов в chunk-data. Нули в начале поля размера не допускаются, а максимальное разрешенное значение chunk-size составляет 4294967295.

Например, сообщение

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

может быть представлено в виде (\n указывает символ перевода строки LF)

   C:  \n#4\n
   C:  <rpc
   C:  \n#18\n
   C:   message-id="102"\n
   C:  \n#79\n
   C:       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
   C:    <close-session/>\n
   C:  </rpc>
   C:  \n##\n

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

В примерах chunked-кадрирования показаны все переводы строк (LF), даже если они не являются частью механизма кадрирования. Отметим, что транспорт SSH не интерпретирует содержимого XML, т. е. не заботится о каких-либо необязательных символах LF, относящихся к XML.

Во втором и третьем блоках (chunk), показанных выше, каждая строка завершается символом LF. Для всех строк XML (кроме последней) в этом примере символы LF считаются частью chunk-data и учитываются в chunk-size.

Отметим отсутствие LF после завершающего <rpc> тега в приведенном выше сообщении. Символ LF, требуемый в начале блока end-of-chunks, следует непосредственно за последним символом > в сообщении.

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

4.3. Механизм кадрирования End-of-Message

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

При использовании этого механизма клиентом и сервером должна передаваться специальная последовательность символов ]]>]]> после каждого сообщения (документ XML) в обмене NETCONF. Концептуально транспортный уровень SSH передает все данные между парой последовательностей ]]>]]> уровню Messages.

Сессия NETCONF на базе SSH с использованием совместимого с прежними версиями кадрирования end-of-message для получения набора конфигурационных данных может иметь вид:

   C: <?xml version="1.0" encoding="UTF-8"?>
   C: <rpc message-id="105"
   C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   C:   <get-config>
   C:     <source><running/></source>
   C:     <config xmlns="http://example.com/schema/1.2/config">
   C:      <users/>
   C:     </config>
   C:   </get-config>
   C: </rpc>
   C: ]]>]]>

   S: <?xml version="1.0" encoding="UTF-8"?>
   S: <rpc-reply message-id="105"
   S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   S:   <config xmlns="http://example.com/schema/1.2/config">
   S:     <users>
   S:       <user><name>root</name><type>superuser</type></user>
   S:       <user><name>fred</name><type>admin</type></user>
   S:       <user><name>barney</name><type>admin</type></user>
   S:     </users>
   S:   </config>
   S: </rpc-reply>
   S: ]]>]]>

5. Завершение работы подсистемы NETCONF

Завершение работы NETCONF обеспечивается операцией <close-session>. Сервер NETCONF обрабатывает сообщения NETCONF от клиента в порядке их поступления. Когда сервер NETCONF получает операцию <close-session>, ему ответить завершением сессии в канале SSH. Серверу NETCONF недопустимо обрабатывать какие-либо сообщения NETCONF после получения операции <close-session>.

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

   C: \n#140\n
   C: <?xml version="1.0" encoding="UTF-8"?>\n
   C: <rpc message-id="106"\n
   C:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
   C:   <close-session/>\n
   C: </rpc>
   C: \n##\n

   S: \n#139\n
   S: <?xml version="1.0" encoding="UTF-8"?>\n
   S: <rpc-reply id="106"\n
   S:            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
   S:   <ok/>\n
   S: </rpc-reply>
   S: \n##\n

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

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

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

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

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

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

В RFC 4742 принято допущение о том, что последовательность EOM⁵ ]]>]]> не может появляться в корректно сформированных документах XML, однако это оказалось ошибкой. Последовательность EOM может вызывать проблемы в работе и открывает возможность для атак с использованием специально подготовленных сообщений RPC. Однако эта угроза не представляет опасной. Этот документ продолжает использовать последовательность EOM в начальном сообщении <hello> для предотвращения несовместимости с имеющимися реализациями. Когда обе стороны соединения поддерживают возможность :base:1.1, в сессии NETCONF после приветствия применяется специальное кадрирование (4.2. Механизм кадрирования Chunked), позволяющее предотвратить атаки со вставкой фиктивных сообщений.

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

На основе предыдущей версии этого документа (RFC 4742) агентство IANA выделило порт TCP с номером 830 для принятого по умолчанию порта в сессиях NETCONF на базе SSH.

Агентство IANA также выделило идентификатор netconf в качестве имени подсистемы SSH (SSH Subsystem Name), как указано в [RFC4250]

Имя подсистемы	Документ
netconf	RFC 4742

Агентство IANA в своих реестрах обновило информацию со ссылкой на этот документ.

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

Ted Goddard был соавтором предыдущих версий этого документа.

Документ был создан с помощью инструмента xml2rfc, описанного в RFC 2629 [RFC2629].

Много полезных предложений было получено от других членов группы разработчиков NETCONF, включая Andy Bierman, Weijing Chen, Rob Enns, Wes Hardaker, David Harrington, Eliot Lear, Simon Leinen, Phil Shafer, Juergen Schoenwaelder и Steve Waldbusser. Значительную помощь оказали также рецензии Olafur Gudmundsson, Sam Hartman, Scott Hollenbeck, Bill Sommerfeld, Balazs Lengyel, Bert Wijnen, Mehmet Ersue, Martin Bjorklund, Lada Lothka, Kent Watsen и Tom Petch.

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

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

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

[RFC4250] Lehtinen, S. and C. Lonvick, «The Secure Shell (SSH) Protocol Assigned Numbers», RFC 4250, January 2006.

[RFC4252] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Authentication Protocol», RFC 4252, January 2006.

[RFC4253] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, January 2006.

[RFC4254] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Connection Protocol», RFC 4254, January 2006.

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, June 2011.

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

[RFC2629] Rose, M., «Writing I-Ds and RFCs using XML», RFC 2629, June 1999.

Приложение A. Отличия от RFC 4742

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

Добавлен механизм кадрирования chunked для решения проблемы безопасности, связанной с EOM.
Расширен раздел «Вопросы безопасности» с включением текста, посвященного проблеме EOM.
Добавлены примеры, иллюстрирующие новое chunked-кодирование, уточнено применение символов перевода строки.
Добавлен текст об обработке имен пользователей NETCONF в соответствии с требованиями [RFC6241].
Термины client/server и manager/agent заменены на SSH client/server и NETCONF client/server.
Используется термин operation (операция) вместо command или message.
Учтены ошибки, обнаруженные в RFC 4742 к моменту публикации этого документа (см ошибки RFC 4742 на сайте http://www.rfc-editor.org).

Адрес автора

Margaret Wasserman

Painless Security, LLC

356 Abbott Street

North Andover, MA 01845

USA

Phone: +1 781 405-7464

EMail: mrw@painless-security.com

URI: http://www.painless-security.com

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

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

nmalykh@gmail.com

1Network Configuration Protocol.

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

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5End-of-message — конец сообщения.

Рубрика: RFC | Комментарии отключены

RFC 6243 With-defaults Capability for NETCONF

Опубликовано 14.06.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        A. Bierman
Request for Comments: 6243                                       Brocade
Category: Standards Track                                     B. Lengyel
ISSN: 2070-1721                                                 Ericsson
                                                               June 2011

With-defaults Capability for NETCONF

Свойство :with-defaults для протокола NETCONF

PDF

Аннотация

Протокол настройки сети (Network Configuration Protocol или NETCONF) определяет способы считывания и редактирования данных конфигурации с сервера NETCONF. В некоторых случаях часть таких данных клиент NETCONF может не устанавливать, используя взамен принятые по умолчанию значения, известные серверу. Во многих случаях клиент NETCONF заранее знает принятые по умолчанию значения и серверу NETCONF не требуется записывать их в хранилище конфигурации NETCONF или передавать клиенту в отклике на операцию извлечения данных (retrieval). В иных ситуациях клиенту NETCONF будут требоваться данные от сервера. Не все реализации серверов одинаково трактуют принятые по умолчанию данные. Этот документ определяет основанное на возможностях расширение протокола NETCONF, позволяющее клиентам NETCONF определить, как сервер обрабатывает принятые по умолчанию значения, а также задаёт новые механизмы для управления клиентом обработкой принятых по умолчанию данных на сервере.

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

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

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

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

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

1. Введение

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

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

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

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

Data model schema — схема модели данных

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

Management application — управляющее приложение

Компьютерная программа за пределами сервера NETCONF, которая настраивает или отслеживает сервер NETCONF. Управляющая программа может взаимодействовать с сервером, например, по протоколу NETCONF, через командный интерфейс (CLI) или простой протокол управления сетью (Simple Network Management Protocol или SNMP).

Schema default data — принятые по умолчанию данные схемы

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

Default data — принятые по умолчанию данные

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

Default value — принятое по умолчанию значение

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

Explicitly set data — явный набор данных

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

<with-defaults> retrieval — извлечение <with-defaults>

Протокольная операция с параметром <with-default> для управления обработкой принятых по умолчанию данных.

:with-defaults

Сокращённое обозначение идентификатора возможности with-defaults.

Ниже перечислены термины, определённые в [RFC6241].

client — клиент;
datastore — хранилище данных;
operation — операция;
server — сервер.

Термин «узел данных» (data node) определён в [RFC6020].

1.2. Принятая по умолчанию обработка

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

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

1.3. Управляемое клиентом извлечение принятых по умолчанию данных

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

Однако в некоторых случаях клиенту NETCONF требуется получать от сервера принятые по умолчанию значения:

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

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

Документ определяет свойство протокола NETCONF для идентификации поведения сервера применительно к принятым по умолчанию данным, атрибут XML [W3C.REC-xmlschema-0-20041028] для идентификации принятых по умолчанию данных и расширение модуля YANG для протокола NETCONF, позволяющее клиенту NETCONF контролировать получение от сервера принятых по умолчанию данных.

2. Базовые режимы принятой по умолчанию обработки

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

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

report-all (сообщать все);
trim (подрезка);
explicit (исключение).

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

2.1. Базовый режим report-all

В режиме report-all сервер не считает данные принятыми по умолчанию, даже если они указаны такими в схеме.

2.1.1. Базовый режим извлечения report-all

При извлечении данных с сервера в режиме report-all и отсутствии параметра <with-defaults> должны возвращаться все узлы данных.

2.1.2. Извлечение report-all <with-defaults>

Если сервер использует базовый режим report-all, он должен поддерживать параметр <with-defaults> со значением report-all, как указано в параграфе 3.1.

2.1.3. Поведение report-all <edit-config> и <copy-config>

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

Сервер, использующий базовый режим report-all, не имеет концепции принятого по умолчанию узла, поэтому режим извлечения report-all-tagged <with-defaults> не имеет смысла. Помеченных узлов не будет, поскольку нет узлов, которые пропускаются в операции базового режима извлечения. Если в каких-либо данных конфигурации присутствует атрибут default, сервер должен возвращать отклик <rpc-error> с тегом ошибки unknown-attribute.

2.2. Базовый режим trim

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

2.2.1. Базовый режим извлечения trim

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

2.2.2. Извлечение trim <with-defaults>

В базовом режиме trim сервер должен поддерживать параметр <with-defaults> со значением trim, как указано в параграфе 3.2.

2.2.3. Поведение trim <edit-config> и <copy-config>

Сервер должен считать существующим любой узел данных, который не содержит принятое в схеме по умолчанию значение. Действительный атрибут операции create для узла данных, указанного в схеме как принятый по умолчанию, должен приводить к успеху. Действительный атрибут операции delete для отсутствующего узла данных, указанного в схеме как принятый по умолчанию, должен вызывать отказ. Сервер должен возвращать отклик <rpc-error> с тегом ошибки data-missing.

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

Если сервер поддерживает значение report-all-tagged для параметра <with-defaults>, атрибут default должен приниматься на входе конфигурации, как указано в параграфах 4.5.1 и 4.5.2.

2.3. Базовый режим explicit

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

2.3.1. Базовый режим извлечения explicit

При извлечении данных с сервера в базовом режиме explicit и отсутствии параметра <with-defaults> узлы данных должны сообщаться, если они явно установлены клиентом, даже в случае заданного в схеме по умолчанию значения. Не относящиеся к конфигурации узлы данных с принятыми в схеме по умолчанию значениями должны включаться.

2.3.2. Извлечение explicit <with-defaults>

В базовом режиме explicit сервер должен поддерживать параметр <with-defaults> = explicit (параграф 3.3).

2.3.3. Поведение explicit <edit-config> и <copy-config>

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

Если сервер поддерживает режим извлечения report-all-tagged со свойством :with-defaults, атрибут default должен восприниматься при вводе конфигурации. Если параметры NETCONF <edit-config> или <copy-config> действительны, сервер будет считать помеченный узел данных (т. е. с атрибутом default, имеющим значение true или 1) как запрос на возврат этого узла к принятому по умолчанию значению. Если этот запрос действителен в контексте операции NETCONF, узел данных удаляется и возвращается принятое по умолчанию значение. Узел данных в сообщении NETCONF должен содержать значение, которое в этом случае должно совпадать с принятым по умолчанию в схеме. В ином случае сервер должен возвращать отклик <rpc-error> с тегом ошибки invalid-value.

3. Извлечение принятых по умолчанию данных

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

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

3.1. Режим извлечения report-all

При извлечении данных с <with-defaults> = report-all должны указываться все узлы данных, которые сервер считает принятыми по умолчанию.

3.2. Режим извлечения trim

При извлечении данных с <with-defaults> = trim, недопустимо указывать узлы данных, содержащие принятые в схеме по умолчанию значения. Узлы данных, не являющихся конфигурационными с принятыми в схеме по умолчанию значениями, указывать недопустимо.

3.3. Режим извлечения explicit

При извлечении данных с <with-defaults> = explicit узлы, для которых клиент установил принятое в схеме по умолчанию значение, должны включаться в отчёт. Недопустимо указывать концептуальные узлы данных, для которых сервер установил принятое в схеме по умолчанию значение. Не относящиеся к конфигурации узлы с принятым в схеме по умолчанию значением должны указываться в отчёте.

3.4. Режим извлечения report-all-tagged

В дополнение к базовым режимам имеется специальный вариант режима report-all, названный report-all-tagged. Этот режим должен поддерживаться на сервере, если параметр also-supported в свойстве :with-defaults содержит опцию report-all-tagged. Детали кодирования для этого свойства приведены в разделе 4.

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

Сервер, поддерживающий report-all-tagged, должен также воспринимать атрибут XML default при вводе конфигурации в операции <edit-config> и <copy-config>. Детали представления XML для атрибута XML default приведены в разделе 6.

4. Свойство :with-defaults

4.1. Обзор

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

Сервер NETCONF, реализующий свойство :with-defaults:

должен указать свой базовый режим поведения параметром basic-mode в URI свойств (параграф 4.3);
должен поддерживать модуль YANG из раздела 5 для режима обработки принятых по умолчанию данных, указанного параметром basic-mode;
следует поддерживать модуль YANG из раздела 5 для режима обработки принятых по умолчанию данных, указанного значением report-all или report-all-tagged;
при поддержке режима report-all-tagged должен поддерживать атрибут default;
может поддерживать модуль YANG из раздела 5 для дополнительных режимов обработки принятых по умолчанию данных.

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

Нет.

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

   urn:ietf:params:netconf:capability:with-defaults:1.0

Идентификатор должен иметь параметр basic-mode, указывающий, как сервер будет трактовать принятые по умолчанию данные, как указано в разделе 2. Параметр может принимать значения report-all, trim, explicit (раздел 2).

Идентификатор может иметь параметр also-supported, указывающий дополнительные перечисляемые значения (в дополнение к базовым режимам), которые сервер будет воспринимать для параметра <with-defaults> (раздел 5). Значением параметра является список разделённых запятыми режимов, которые поддерживаются в дополнение к режиму, указанному параметром basic-mode. Возможны значения report-all, report-all-tagged, trim, explicit (раздел 3).

Отметим, что URI этой возможности протокола отделен от URI свойства модуля YANG (раздел 5). Сервер, реализующий этот модуль, должен анонсировать URI возможности модуля YANG в соответствии с [RFC6020].

Ниже приведены примеры идентификаторов возможностей.

urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit
urn:ietf:params:netconf:capability:with-defaults:1.0?basic-
mode=explicit&also-supported=report-all,report-all-tagged

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

Нет.

4.5. Изменение имеющихся операций

4.5.1. Операции <get>, <get-config>, <copy-config>

Новый элемент XML <with-defaults> добавляется на вход операций <get>, <get-config>, <copy-config>. При наличии элемента <with-defaults> он управляет возвратом принятых по умолчанию данных. Сервер должен возвращать принятые по умолчанию данные в сообщениях NETCONF <rpc-reply> в соответствии со значением этого элемента, если сервер поддерживает заданный режим извлечения. Параметр влияет лишь на указанные операции извлечения, не оказывая влияния на другие операции и энергонезависимые хранилища данных.

Элемент <with-defaults> определён в пространстве имён XML для модуля ietf-netconf-with-defaults.yang (раздел 5), а не в пространстве имён XML для операций <get>, <get-config>, <copy-config>. Разрешённые значения элемента with-defaults берутся из определения типа with-defaults-type в разделе 5. Разрешённые значения для конкретного сервера ограничены набором, указанным сервером как поддерживаемые в возможности with-defaults параметрами basic-mode и also-supported.

При использовании неподдерживаемого значения сервер NETCONF должен возвращать <rpc-error> с тегом ошибки invalid-value. Если элемент <with-defaults> отсутствует, сервер должен следовать базовому режиму, указанному параметром basic-mode в идентификаторе возможности :with-defaults, как указано в параграфе 4.3.

Операции <get> и <get-config> поддерживают раздельные механизмы фильтрации, используя параметр <filter>. Принятая по умолчанию фильтрация концептуально выполняется до обработки параметра <filter>. Например, при <with-defaults> = report-all параметр <filter> концептуально применяется ко всем узлам данных и всем данным, принятым по умолчанию. Параметр <with-defaults> влияет на операцию <copy-config> лишь при указании цели операции в параметре <url>. Если целью является хранилище конфигурации NETCONF (running, candidate, startup), параметр <with-defaults> не оказывает влияния. Сервер должен использовать свой базовый режим при копировании данных в хранилище конфигурации NETCONF. При наличии в этом случае параметра <with-defaults> сервер должен просто игнорировать его.

Если сервер поддерживает режим report-all-tagged, атрибут default, заданный в разделе 6, влияет также на операцию <copy-config>. При установке для атрибута default значения true или 1 сервер должен рассматривать новый узел данных как запрос на возврат узла к принятому по умолчанию значению (т. е. удаление из хранилища конфигурации). Узел данных в сообщении NETCONF должен в этом случае содержать значение, которое должно совпадать с принятым в схеме по умолчанию. В ином случае сервер должен возвращать отклик <rpc-error> с тегом invalid-value.

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

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

Если атрибут операции содержит значение create и узел данных уже существует, сервер должен возвращать отклик <rpc-error> с тегом ошибки invalid-value.

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

Если сервер поддерживает режим report-all-tagged, атрибут default, заданный в разделе 6, влияет на операцию <edit-config>. При установке для атрибута default значения true или 1 сервер должен рассматривать новый узел данных как запрос на возврат узла к принятому по умолчанию значению (т. е. удаление из хранилища конфигурации). Узел данных в сообщении NETCONF должен в этом случае содержать значение, которое должно совпадать с принятым в схеме по умолчанию. В ином случае сервер должен возвращать отклик <rpc-error> с тегом invalid-value.

При наличии атрибута default эффективной операцией для целевого узла данных должна быть create, merge или replace. В иных случаях сервер должен возвращать отклик <rpc-error> с тегом ошибки invalid-value. Например, при эффективной операции create запрос на создание должен быть действительным сам по себе (т. е., недопустимо наличие создаваемого узла). Процедура определения эффективной операции задана в [RFC6241]. Операция выводится из параметра default-operation и/или иных атрибутов операции, которые присутствуют в узле данных или любом из его предков в запросе <edit-config>.

4.5.3. Другие операции

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

4.6. Взаимодействие с другими возможностями

Нет.

5. Модуль YANG для параметра <with-defaults>

Ниже приведён модуль YANG, определяющий добавление элемента with-defaults к операциям <get>, <get-config> и <copy-config>. Язык YANG определён в [RFC6020], указанные операции определены для YANG в [RFC6241]. Каждый сервер NETCONF, поддерживающий :with-defaults, должен реализовать этот модуль YANG.

  <CODE BEGINS> file="ietf-netconf-with-defaults@2011-06-01.yang"
  module ietf-netconf-with-defaults {

     namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults";

     prefix ncwd;

     import ietf-netconf { prefix nc; }

     organization
      "IETF NETCONF (Network Configuration Protocol) 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: Andy Bierman <andy.bierman@brocade.com> 

       Editor: Balazs Lengyel <balazs.lengyel@ericsson.com>"; 

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

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

       Распространение и использование в исходной или двоичной форме в
       изменениями или без таковых разрешено в соответствии с условиями,
       указанными в Simplified BSD License раздела 4.c IETF Trust's Legal 
       Provisions применительно к документам IETF
       (https://trustee.ietf.org/license-info). 

       Эта версия модуля является частью RFC 6243, где правовые аспекты
       изложены более полно.";
 
     revision 2011-06-01 {
       description
         "Исходная версия.";
       reference
        "RFC 6243: With-defaults Capability for NETCONF";
     }

     typedef with-defaults-mode {
        description
          "Возможные режимы возврата принятых по умолчанию данных.";
        reference
           "RFC 6243; Section 3.";
        type enumeration {
           enum report-all {
               description
                 "Указываются все принятые по умолчанию данные.";
               reference
                 "RFC 6243; Section 3.1";
           }
           enum report-all-tagged {
               description
                 "Указываются все принятые по умолчанию данные. Все
                  узлы, сочтённые принятыми по умолчанию данные, будут 
                  содержать атрибут XML default со значением true или 1.";
               reference
                 "RFC 6243; Section 3.4";
           }
           enum trim {
               description
                 "Значения не возвращаются, если они приняты по умолчанию.";
               reference
                 "RFC 6243; Section 3.2";
           }
           enum explicit {
               description
                 "Возвращаются значения, содержащие определение явно 
                  установленных данных.";
               reference
                 "RFC 6243; Section 3.3";
           }
       }
     }

     grouping with-defaults-parameters {
       description
         "Параметр <with-defaults> для управления операциями 
          NETCONF при извлечении принятых по умолчанию данных.";
       leaf with-defaults {
         description
           "Запрос режима обработки явных значений по умолчанию.";
         reference
           "RFC 6243; Section 4.5.1";
         type with-defaults-mode;
       }
     }

     // Расширение операции get-config
     augment /nc:get-config/nc:input {
         description
           "Добавляет параметр <with-defaults> на вход операции
            NETCONF <get-config>.";
         reference
           "RFC 6243; Section 4.5.1";

         uses with-defaults-parameters;
     }

     // Расширение операции get 
     augment /nc:get/nc:input {
         description
           "Добавляет параметр <with-defaults> на вход операции
            NETCONF <get>.";
         reference
           "RFC 6243; Section 4.5.1";

         uses with-defaults-parameters;
     }

     // Расширение операции copy-config
     augment /nc:copy-config/nc:input {
         description
           "Добавляет параметр <with-defaults> на вход операции
            NETCONF <copy-config>.";
         reference
           "RFC 6243; Section 4.5.1";

         uses with-defaults-parameters;
     }

  }
  <CODE ENDS>

6. XSD для атрибута default

Приведённый ниже документ XML Schema [W3C.REC-xml-20081126] определяет атрибут default, описанный в этом документе. XSD применяется лишь при поддержке сервером режима report-all-tagged обработки принятых по умолчанию значений.

Атрибут default использует тип данных XSD boolean. В соответствии с параграфом 3.2.2.1 XML Schema Part 2: Datatypes, допустимым лексическим представлением типа xs:boolean являются строки 0 и false для значения false и 1или true — для true. реализации должны поддерживать оба варианта представления.

<CODE BEGINS> file="defaults.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:default:1.0"
           targetNamespace="urn:ietf:params:xml:ns:netconf:default:1.0"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified"
           xml:lang="en">

  <xs:annotation>
    <xs:documentation>
      Эта схема определяет синтаксис атрибута default, заданного в 
      этом документе.
    </xs:documentation>
  </xs:annotation>

  <!-- Атрибут default -->
  <xs:attribute name="default" type="xs:boolean" default="false">
    <xs:annotation>
      <xs:documentation>
        Этот атрибут указывает, рассматривается ли сервером представленный
        этим элементом XML атрибут как принятые по умолчанию данные. При
        установке true или 1 узел данных считается принятым по умолчанию.
        Значение false или 0 говорит, что узел данных не принят по умолчанию.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
</xs:schema>
<CODE ENDS>

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

Этот документ регистрирует URN идентификатора возможности в реестре Network Configuration Protocol (NETCONF) Capability URNs

      urn:ietf:params:netconf:capability:with-defaults:1.0

Документ регистрирует два URN пространств имён XML в реестре IETF XML в соответствии с форматом [RFC3688].

      URI: urn:ietf:params:xml:ns:netconf:default:1.0
      URI: urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
   Registrant Contact: The NETCONF WG of the IETF.
   XML: N/A, the requested URIs are XML namespaces.

Документ регистрирует имя модуля в реестре YANG Module Names, определённом в [RFC6020] .

      name: ietf-netconf-with-defaults
      prefix: ncwd
      namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
      RFC: 6243

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

Документ задаёт расширение имеющихся операций протокола NETCONF. Документ не создаёт новых и не повышает имеющиеся риски безопасности для систем управления.

Свойство with-defaults даёт клиентам средство управления извлечением принятых по умолчанию данных из хранилищ NETCONF. Вопросы безопасности, отмеченные в [RFC6241], применимы и здесь.

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

Спасибо Martin Bjorklund, Sharon Chisholm, Phil Shafer, Juergen Schoenwaelder, Kent Watsen, Washam Fan и другим участникам NETCONF WG за важный вклад в этот документ.

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

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

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

[RFC6020] Bjorklund, M., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, October 2010.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, June 2011.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, «Extensible Markup Language (XML) 1.0 (Fifth Edition)», World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

[W3C.REC-xmlschema-0-20041028] Fallside, D. and P. Walmsley, «XML Schema Part 0: Primer Second Edition», World Wide Web Consortium Recommendation REC-xmlschema-0-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.

Приложение A. Примеры использования

A.1. Пример модуля YANG

Ниже приведён пример модуля YANG с таблицей интерфейсов для демонстрации поведения параметра <with-defaults> с конкретной моделью данных.

Отметим, что это просто пример и реализация модуля не требуется для поддержки свойства :with-defaults, заданного в раздел 4. Модуль не регистрируется в IANA и не считается компонентом кода. Модуль преднамеренно краток и включает лишь несколько описательных операторов.

     module example {
     namespace "http://example.com/ns/interfaces";

     prefix exam;

     typedef status-type {
        description "Статус интерфейса";
        type enumeration {
          enum ok;
          enum 'waking up';
          enum 'not feeling so good';
          enum 'better check it out';
          enum 'better call for help';
        }
        default ok;
     }

     container interfaces {
         description "Пример группы интерфейсов";

         list interface {
           description "Пример записи для интерфейса";
           key name;

           leaf name {
             description
               "Административное имя интерфейса. Этот
                идентификатор уникален лишь в зоне действия
                списка на конкретном сервере.";
             type string {
               length "1 .. max";
             }
           }

           leaf mtu {
             description
               "Значение MTU для интерфейса.";
             type uint32;
             default 1500;
           }
           leaf status {
             description
               "Текущий статус интерфейса.";
             type status-type;
             config false;
           }
         }
       }
     }

A.2. Пример набора данных

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

       <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <interfaces xmlns="http://example.com/ns/interfaces">
           <interface>
             <name>eth0</name>
             <mtu>8192</mtu>
             <status>up</status>
           </interface>
           <interface>
             <name>eth1</name>
             <mtu>1500</mtu>
             <status>up</status>
           </interface>
           <interface>
             <name>eth2</name>
             <mtu>9000</mtu>
             <status>not feeling so good</status>
           </interface>
           <interface>
             <name>eth3</name>
             <mtu>1500</mtu>
             <status>waking up</status>
           </interface>
         </interfaces>
       </data>

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

name	setby	mtu
eth0	client	8192
eth1	server	1500
eth2	client	9000
eth3	client	1500

A.3. Примеры протокольных операций

Приведённые ниже примеры показывают некоторые операции <get> с использованием элемента with-defaults. Используемая модель данных определена в Приложении A.1.

Клиент извлекает все узлы данных объекта interfaces, фильтруя их по параметру <with-defaults>.

A.3.1. <with-defaults> = report-all

В этом примере иллюстрируется обработка параметра <with-defaults> в режиме report-all.

    <rpc message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="101"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <mtu>1500</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu>1500</mtu>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.2. <with-defaults> = report-all-tagged

В этом примере иллюстрируется обработка параметра <with-defaults> в режиме report-all-tagged. Помеченными (tagged) узлами данных являются элементы, содержащие атрибут XML default со значением true или 1.

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

В примере сервер использует базовый режим trim, поэтому помечаются все узлы данных с установленными в схеме по умолчанию значениями. В базовом режиме explicit, помечаются лишь узлы данных, которые не установлены явно, а в режиме report-all никакие узлы данных не помечаются.

    <rpc message-id="102"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          report-all-tagged
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="102"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
               xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status wd:default="true">up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <mtu wd:default="true">1500</mtu>
            <status wd:default="true">up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu wd:default="true">1500</mtu>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.3. <with-defaults> = trim

В этом примере иллюстрируется обработка параметра <with-defaults> в режиме trim.

    <rpc message-id="103"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          trim
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="103"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
          </interface>
          <interface>
            <name>eth1</name>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

A.3.4. <with-defaults> = explicit

В этом примере иллюстрируется обработка параметра <with-defaults> в режиме explicit.

    <rpc message-id="104"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get>
        <filter type="subtree">
          <interfaces xmlns="http://example.com/ns/interfaces"/>
        </filter>
        <with-defaults
         xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
          explicit
        </with-defaults>
      </get>
    </rpc>

    <rpc-reply message-id="104"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <data>
        <interfaces xmlns="http://example.com/ns/interfaces">
          <interface>
            <name>eth0</name>
            <mtu>8192</mtu>
            <status>up</status>
          </interface>
          <interface>
            <name>eth1</name>
            <status>up</status>
          </interface>
          <interface>
            <name>eth2</name>
            <mtu>9000</mtu>
            <status>not feeling so good</status>
          </interface>
          <interface>
            <name>eth3</name>
            <mtu>1500</mtu>
            <status>waking up</status>
          </interface>
        </interfaces>
      </data>
    </rpc-reply>

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

Andy Bierman

Brocade

EMail: andy.bierman@brocade.com

Balazs Lengyel

Ericsson

Budapest,

Hungary

EMail: balazs.lengyel@ericsson.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC, Мониторинг и управление | Оставить комментарий

RFC 6244 An Architecture for Network Management Using NETCONF and YANG

Опубликовано 08.06.2011 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                         P. Shafer
Request for Comments: 6244                              Juniper Networks
Category: Informational                                        June 2011
ISSN: 2070-1721

An Architecture for Network Management Using NETCONF and YANG

Архитектура управления сетью с использованием NETCONF и YANG

PDF

Аннотация

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

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

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

Документ не относится к категории Internet Standards Track и публикуется для информации.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Не все документы, одобренные IESG, претендуют на статус стандартов Internet, см. . Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

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

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

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

1. Истоки NETCONF и YANG

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

В июне 2002 г. Совет по архитектуре Internet (Internet Architecture Board или IAB) провёл семинар по управлению сетями [RFC3535]. Участники этого семинара внесли ряд замечаний и рекомендация для рассмотрения в IETF проблем, с которыми операторы сталкиваются в своей работе, направляя усилия IETF на эту область.

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

На основе этих указания была создана рабочая группа NETCONF и протокол настройки сети (Network Configuration или NETCONF). Этот протокол определяет простой механизм, где сетевые приложения, выступающие как клиенты, могут вызывать операции на устройстве, действующем как сервер. Спецификация NETCONF [RFC4741] задаёт небольшой набор операций и старается избегать требований к передаваемым в этих операциях данным, предпочитая разрешать протоколу передачу любых данных. Такой подход, не зависящий от данных, позволяет независимо создавать модели данных.

Из-за отсутствия средств для определения моделей данных протокол NETCONF невозможно было использовать для работы на основе стандартов. Были рассмотрены имевшиеся языки моделирования данных, такие как определение схемы XML (XML Schema Definition или XSD) [W3CXSD] и языки определения схемы документа (Document Schema Definition Languages или DSDL) [ISODSDL], но они были отвергнуты как неподходящие для решения задач. Задание новой модели данных или протокола в XML отличается от создания документа XML. Использование операций NETCONF вносит требования к содержимому данных, которое не применяется совместно с предметной областью статических документов, для которых предназначены языки схем вроде XSD или RELAX NG.

В 2007 и 2008 гг. вопрос моделирования данных для NETCONF обсуждался в рамках OPS и APP на конференциях IETF 70 и 71 и команде разработчиков было поручено подготовить документ с требованиями [RCDML]. После обсуждения доступных вариантов в рамках CANMOD BoF на IETF 71 сообщество подготовило устав для рабочей группы NETMOD. Отличное описание этого этапа доступно по ссылке <http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html>.

В 2008 и 2009 гг. рабочая группа NETMOD подготовиля спецификацию YANG [RFC6020] как средство определения моделей данных для NETCONF, позволяющее публиковать стандартные и фирменные (proprietary) модели данных в форме, которая легко воспринимается человеком и удовлетворяет многим требованиям, внесенным на семинаре IAB NM. Это позволило использовать NETCONF для разработки стандартных моделей данных в рамках IETF.

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

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

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

2. Элементы архитектуры

2.1. NETCONF

NETCONF задаёт основанный на XML механизм удалённого вызова процедур (remote procedure call или RPC), использующий простоту и доступность высококачественных синтаксических анализаторов XML. Язык XML обеспечивает богатое, гибкое и иерархическое стандартное представление данных, соответствующее потребностям сетевых устройств. NETCONF доставляет данные конфигурации и операции в форме запросов и откликов с использованием кодирования RPC в формате XML и передачей по ориентированному на соединения транспорту.

Иерархическое представление данных XML позволяет естественным образом представлять сложные сетевые данные. Например, приведённая ниже конфигурация помещает интерфейсы в области OSPF. Элемент <ospf> содержит список элементов <area>, каждый из которых включает список элементов <interface>. Элемент <name> указывает конкретную область или интерфейс. Дополнительная конфгурация для каждой области или интерфейса указывается внутри соответствующего элемента.

         <ospf xmlns="http://example.org/netconf/ospf">

           <area>
             <name>0.0.0.0</name>
             <interface>
               <name>ge-0/0/0.0</name>
               <!-- Приоритет для интерфейса -->
               <priority>30</priority>
               <metric>100</metric>
               <dead-interval>120</dead-interval>
             </interface>

             <interface>
               <name>ge-0/0/1.0</name>
               <metric>140</metric>
             </interface>
           </area>

           <area>
             <name>10.1.2.0</name>
             <interface>
               <name>ge-0/0/2.0</name>
               <metric>100</metric>
             </interface>

             <interface>
               <name>ge-0/0/3.0</name>
               <metric>140</metric>
               <dead-interval>120</dead-interval>
             </interface>
           </area>
         </ospf>

NETCONF включает механизмы для контроля хранилищ данных конфигурации. Каждое хранилище является определённым набором данных конфигурации, который может быть источником или целью связанных с настройкой операций. Устройство может указать, есть ли у него отдельное хранилище для стартовой конфигурации (startup), возможна ли прямая запись в хранилище рабочей конфигурации (running), имеется ли хранилище подготовленной конфигурации (candidate), которая активируется вызовом операции <commit/>³.

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

Операция	Описание
commit	Представляет конфигурацию candidate в running
copy-config	Копирует одно хранилище данных в другое
delete-config	Удаляет хранилище данных конфигурации
edit-config	Меняет содержимое конфигурационного хранилища
get-config	Извлекает хранилище данных или его часть
lock	Предотвращает изменение хранилища данных другой стороной
unlock	Снимает блокировку хранилища данных

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

NETCONF также задает способы передачи клиенту асинхронных уведомлений от сервера, описанных в [RFC5277].

Кроме того, NETCONF может извлекать сведения о состоянии, получать уведомления и вызывать дополнительные методы RPC, определённые как часть возможности. Полные сведения о NETCONF представлены в [RFC4741].

2.1.1. Транспортное отображение NETCONF

NETCONF может работать по любому транспортному протоколу, удовлетворяющему требованиям RFC 4741, включая:

операции через явные соединения;
аутентификацию (проверку подлинности);
защиту целостности;
защиту конфиденциальности.

В [RFC4742] задано сопоставление с протоколом Secure Shell (SSH) [RFC4251], которые является обязательным для поддержки транспортым протоколом. Другие протоколы включают SOAP [RFC4743], блочный расширяемый протокол обмена (Blocks Extensible Exchange Protocol или BEEP) [RFC4744], и защиту транспортого уровня (Transport Layer Security или TLS) [RFC5539].

2.2. YANG

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

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

module example-ospf {
    namespace "http://example.org/netconf/ospf";
    prefix ospf;

    import network-types { // Доступ к определениям другого модуля
        prefix nett;
    }

    container ospf {   // Объявляет тег верхнего уровня
        list area {    // Объявляет список узлов area
            key name;  // Ключ name указывает членов списка
            leaf name {
                type nett:area-id;
            }
            list interface {
                key name;
                leaf name {
                    type nett:interface-name;
                }
                leaf priority {
                    description "Заданный приоритет маршрутизатора";
                    type uint8;  // Тип задаёт ограничение для
                                 // действительных значений priority.
                }
                leaf metric {
                    type uint16 {
                        range 1..65535;
                    }
                }
                leaf dead-interval {
                    units seconds;
                    type uint16 {
                        range 1..65535;
                    }
                }
            }
        }
    }
}

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

Оператор	Описание
augment	Расширяет имеющиеся иерархии данных
choice	Задаёт взаимоисключающие варианты
container	Определяет уровень в иерархии данных
extension	Добавляет новый оператор в YANG
feature	Указывает необязательную часть модели
grouping	Группирует определения данных в набор для многократного использования
key	Задаёт листья ключей для списков
leaf	Определяет лист в иерархии данных
leaf-list	Лист, который может присутствовать неоднократно
list	Иерархия, которая может присутствовать неоднократно
notification	Определяет уведомление
rpc	Задаёт входные и выходные параметры для операции RPC
typedef	Определяет новый тип
uses	Встраивает содержимое grouping

2.2.1. Ограничения

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

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

Оператор	Описание
length	Ограничивает размер строки
mandatory	Требует наличия узла
max-elements	Ограничивает число элементов в списке сверху
min-elements	Ограничивает число элементов в списке снизу
must	Выражение XPath должно иметь значение true
pattern	Должно быть выполнено регулярное выражение
range	Значение должно входить в диапазон
type leafref⁴	Значение должно присуутствовать в данных
unique	Значение должно быть уникальным в данных
when	Узел присутствует только при XPath со значением true

В операторах must и when применяются выражения XPath [W3CXPATH] для задания условий, которые семантически оцениваются по отношению к иерархии данных, но ни клиент, ни сервер не обязаны реализовать спецификацию XPath и могут применять любые средства для выполнения заданных условий.

2.2.2. Гибкость

YANG использует тип union и операторы choice и feature для предоставления разработчикам гибкости при задании моделей данных. Тип union позволяет листу воспринимать разные типы данных, таких как integer или слово unbounded (не ограничено).

     type union {
         type int32;
         type enumeration {
             enum "unbounded";
         }
     }

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

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

2.2.3. Модель расширяемости

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

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

       module vendorx-ospf {
           namespace "http://vendorx.example.com/ospf";
           prefix vendorx;
           import example-ospf {
               prefix ospf;
           }

           augment /ospf:ospf/ospf:area/ospf:interface⁵ {
               leaf no-neighbor-down-notification {
                   type empty;
                   description "Не сообщать другим протоколам
                             + " об отключении соседа.";
               }
           }
       }

Элемент <no-neighbor-down-notification> тогда помещается в пространство имён vendorx.

       <ospf xmlns="http://example.org/netconf/ospf"
             xmlns:vendorx="http://vendorx.example.com/ospf">

         <area>
           <name>0.0.0.0</name>
           <interface>
             <name>ge-0/0/0.0</name>
             <priority>30</priority>
             <vendorx:no-neighbor-down-notification/>
           </interface>
         </area>
       </ospf>

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

2.3. Трансляции YANG

Язык моделирования данных YANG является центральной частью группы связанных технологий. Сам язык YANG, описанный в [RFC6020], задаёт синтаксис и операторы, их назначение и способы комбинирования для построения иерархии узлов, описывающей модель данных.

Этот документ задаёт концепцию содержимого XML «в линии» для операций NETCONF с моделями данных из модулей YANG. Это включает базовое сопоставление узлов дерева данных YANG с элементами XML, а также механизмы, применяемые в <edit-config> для манипуляций с данными, таких как упорядочивание узлов в списке.

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

2.3.1. YIN

В некоторых средах встраивание синтаксического анализатора YANG может быть неприемлемым. Для таких случаев грамматика XML для YANG определена как YIN (YANG Independent Notation — независимая нотация), что позволяет применять синтаксические анализаторы XML, доступные как в открытом коде, так и в коммерческих версиях. Трансляция между YANG и YIN является прямой, обратимой и не вносит потерь. Операторы YANG преобразуются в элементы XML, сохраняя структуру и содержимое YANG, но позволяя использовать готовые анализаторы XML вместо анализатора YANG. YIN поддерживает полную семантическую эквивалентность YANG.

2.3.2. DSDL (RELAX NG)

Поскольку содержимое NETCONF кодируется в XML, естественно применять для проверки языки схем XML. Для упрощения этого YANG предоставляет стандартизованное сопоставление модулей YANG с языками DSDL [RFC6110], основным компонентом которых является RELAX NG. DSDL считается лучшим выбором в качестве стандартного языка схем, поскольку он учитывает не только грамматику и типы данных документа XML, но и семантические ограничения, а также правила изменения набора информации в документе. Кроме того, DSDL обеспечивает формальные средства для координации нескольких независимых схем и определения способа применения схем к разным частям документа. Это полезно, поскольку содержимое YANG обычно собрано из нескольких словарей.

2.4. Типы YANG

YANG поддерживает множество встроенных типов и позволяет выводить из них производные типы расширяемым способом. Новые типы могут задавать дополнительные ограничения для значений данных. Доступна стандартная библиотка типов для использования в YANG [RFC6021]. Эти модули YANG задают часто применяемые типы данных дял связанных с IETF стандартов.

2.5. Рекомендации IETF

Задан дополнительный набор рекомендаций для авторов и рецензентов спецификаций Standards-Track с модулями YANG [RFC6087]. Эти рекомендации следует применять как базу для обзора других документов с моделями YANG.

3. Работа с YANG

3.1. Создание решений на основе NETCONF и YANG

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

                       +----------------------------+
                       |Сервер (устройство)         |
                       |    +--------------------+  |
                       |    |     конфигурация   |  |
            +----+     |    |     ---------------|  |
            |YANG|+    |    | m d данные состоян.|  |
            |mods||+   |    | e a ---------------|  |
            +----+|| -----> | t t уведомления    |  |
             +----+|   |    | a a ---------------|  |
              +----+   |    |     операции       |  |
                       |    +--------------------+  |
                       |           ^                |
                       |           |                |
                       |           v                |
     +------+          |     +-------------+        |
     |      | -------------> |             |        |
     |Клиент| <rpc>    |     |   Машина    |        |
     | (app)|          |     |   NETCONF   |        |
     |      | <------------  |             |        |
     +------+ <rpc-reply>    +-------------+        |
                       |       /        \           |
                       |      /          \          |
                       | +--------+   +---------+   |
                       | | База   |   |Систеные |+  |
                       | | данных |   |програм. ||+ |
                       | | конфиг.|   |компонен.||| |
                       | +--------+   +---------+|| |
                       |               +---------+| |
                       |                +---------+ |
                       +----------------------------+

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

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

Клиентское приложение [C] организует сессию NETCONF с сервером (устройством) [S].
[C] и [S] обмениваются сообщениями <hello> со списком возможностей, поддерживаемых каждой стороной, что позволяет [C] узнать о модулях, поддерживаемых [S].
[C] создаёт и передаёт операцию, заданную в модуле YANG, в кодировке XML в элементе NETCONF <rpc>.
[S] получает и анализирует элемент <rpc>.
[S] проверяет содержимое запроса по модели данных их модуля YANG.
[S] выполняет запрошенную операцию, возможно меняя содержимое хранилища данных конфигурации.
[S] создаёт отклик, включающий сам отклик на операцию, запрошенные данные и возникшие ошибки.
[S] передаёт отклик в кодировке XML внутри элемента NETCONF <rpc-reply>.
[C] получает и анализирует элемент <rpc-reply>.
[C] проверяет и должным образом обрабатывает отклик.

Отметим, что клиент и сервер не обязаны обрабатывать модули YANG именно так. Содержимое модели данных может быть жёстко встроено (hard code) в сервер вместо обработки его базовой машиной. Клиент может быть нацелен на конкретную модель YANG, а не на общую обработку. Таким клиентом может быть простой сценарий оболочки (shell script), который помещает аргументы в шаблон содержимого XML и передаёт серверу.

3.2. Выполнение требований операторов

NETCONF и YANG решают многие из задач, поставленных на семинаре IAB NM.

Простота применения — язык YANG удобен для человека, прост и удобочитаем. Многие каверзные вопросы сохраняются из-за сложности проблемной области, но YANG стремится сделать их более ясными и простыми для решения.
Данные конфигурации и состояния — YANG чтеко отделяет данные конфигурации от иных типов данных.
Транзакции — NETCONF обеспечивает простой механизм транзакций.
Генерация различий — модуль YANG даёт достаточно сведения для генерации различия, которое требуется для замены одного модуля другим.
Дамп и восстановление — NETCONF позволяет сохранять и восстанавливать данные конфигурации. Это может быть выполнено для определённого модуля YANG.
Настройка всей сети — NETCONF поддерживает отказоустойчивые транзакции для настройки в масштабе сети за счёт операций представления и подтверждённого представления. При попытке внесения изменений, затрагивающих не одно устройство, эти возможности упрощают обработку отказов и позволяют создавать заведомо неделимые транзакции (успех или отказ всех операций одной транзакции — всё или ничего).
Удобство для текста — модули YANG и определяемые в них данные удобны для текста.
Обработка конфигурации — NETCONF позволяет различать передачу и активацию данных конфигурации.
Ориентированность на задачи — модуль YANG может указывать конкретные задачи как операции RPC. Клиент может вызвать операцию RPC или обратиться к любым базовым данным напрямую.
Полнота охвата — можно задать модули YANG полностью охватывающие естественные возможности устройства. Это избавляет от обращений к командному интерфейсу (command line interface или CLI) с помощью таких инструментов, как Expect [SWEXPECT].
Своевременность — модули YANG можно связать с операциями CLI для незамедлительной доступности естественных операций и данных.
Сложности реализации — гибкость YANG позволяет упростить внедрение модулей. Добавление возможностей и замена третьей нормальной формы естественной иерархией данных позволяет снизить сложность.
Простой язык моделирования данных — YANG обладает достаточными возможностями для применения в других ситуациях. В частности, можно интегрировать встроенный API и естественный интерфейс CLI для упрощения инфраструктуры.
Поддержка разных языков — YANG использует символы Unicode UTF-8 [RFC3629].
Сопоставление событий — YANG объединяет операции RPC, уведомления, данные конфигурации и состояния, разрешая внутренние ссылки. Например, поле уведомления можно пометить как указывающее партнёра BGP и клиентское приложение сможет легко найти этого партнёра в данных конфигурации.
Стоимость внедрения — были приложены значительные усилия для снижения расходов на внедрение.
Удобный для человека синтаксис — синтаксис YANG оптимизирован для чтения, особенно при рецензировании, поскольку оно чаще всего применяется человеком.
Постобработка — применение XML расширяет возможности постобработки данных, возможно с применением основанных на XML технологий, таких как XPath [W3CXPATH], XQuery [W3CXQUERY], XSLT [W3CXSLT].
Семантическое несоответствие — более богатые и описательные модели данных снижают вероятность семантического несоответствия. За счёт возможности определять новые примитивы модули YANG будут более содержательными, что позволит усилить соблюдение правил и ограничений.
Безопасность — NETCONF работает по транспортным протоколам, защищённым SSH или TLS, обеспечивающим защищённую связь и аутентификацию с использованием проверенной технологии. Защищенный транспорт может использовать имеющуюся инфраструктуру управления ключами и свидетельствами, что снижает расходы на внедрение.
Надёжность — NETCONF и YANG — цельные и надёжные технологии. NETCONF работает на основе соединений и включает механизмы автоматического восстановления при потере соединения.
Внесение изменений — модели на основе YANG поддерживают операции внесения изменений — добавление, вставка, редактирование, удаление чётко определены.
Ориентированность на методы — YANG позволяет задавать новые операции RPC, включая их имена, по сути являющиеся методами. Входные и выходные параметры операций RPC также задаются в модулях YANG.

3.3. Роли при создании решений

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

3.3.1. Разработчики моделей

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

Моделирование рассматривается также в разделе 4. Вопросы моделирования.

3.3.2. Рецензенты

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

3.3.3. Разработчики устройств

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

3.3.3.1. Базовая поддержка содержимого

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

Модули сериализации и десериализации для генерации и приёма содержимого NETCONF могут управляться метаданными модели. При получении данных метаданные проверяются для контроля пригодности входящих элементов XML.

3.3.3.2. Определения XML

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

3.3.4. Разработчики приложений

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

3.3.4.1. Жёсткое встраивание

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

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

3.3.4.2. Снизу вверх

Приложение может использовать базовый восходящий подход к настройке, концентрируясь непосредственно на данных устрйоства и обрабатывая их без особого понимания. Модули YANG могут служить для управления работой YANG-эквивалента «браузера MIB». Такое приложение работает с данными конфигурации устройства на основе их организации в модуле YANG. Например, интерфейс GUI может представлять простую визуализацию, где элементы иерархии YANG отображаются иерархией папок или панелей GUI. Щелчок на строке раскрывает содержимое соответствующей иерархии XML. Этот тип GUI легко создать путём генерации таблиц стилей XSLT по моделям данных YANG. Затем можно воспользоваться машиной XSLT для преобразования данных конфигурации в набор web-страниц.

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

3.3.4.3. Сверху вниз

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

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

       list example-bgpvpn {
           key name;
           leaf name { ... }
           leaf protocol {
               type enumeration {
                   enum bgpvpn;
                   enum l2vpn;
               }
           }
           leaf topology {
               type enumeration {
                   enum hub-n-spoke;
                   enum mesh;
               }
           }
           list members {
               key "device interface";
               leaf device { ... }
               leaf interface { ... }
           }
           list classifiers {
               ...
           }
       }

Приложение может использовать такой модуль YANG для управления своей работой, создания экземпляров VPN в базе данных и последующего выталкивания конфигурации этих VPN в отдельные устройства с использованием стандартной модели устройства (например, example-bgpvpn.yang) или преобразования стандартного содержимого устройств в тот или иной фирменный формат для нестандартных устройств.

4. Вопросы моделирования

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

4.1. Принятые по умолчанию значения

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

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

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

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

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

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

Независимо от выбора реализации устройство может поддерживать свойство with-defaults [RFC6243] и давать клиенту возможность выбрать желаемую обработку принятых по умолчанию значений.

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

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

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

полезность;
соответствие;
гибкость;
расширяемость;
отклонения.

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

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

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

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

Иногда реализации могут принимать решения, препятствующие соответствию стандартам. Такие случаи прискорбны, но могут возникать на практике, а разработчики моделей и приложений принимают такие решения на свой страх и риск. Реализацией, выдающей целочисленный лист как «корову» (cow), будет сложно управлять, но приложения должны быть готовы к такому поведению устройств в «полевых» условиях.

Несмотря на это, клиентам и серверам следует считать модуль YANG соглашением, которое обе стороны согласны выполнять. Разработчику модели следует чётко указать условия такого соглашения, а разработчикам клиентов и серверов — стремиться корректно и точно реализовать модель данных, описанную модулем YANG.

4.3. Разные данные

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

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

На семинаре IAB NM операторы сформулировали два требования, включённые в [RFC3535].

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

Протокол NETCONF, заданный в RFC 4741, различает два типа данных — данные конфигурации и данные состояния:

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

Данные состояния — это дополнительные сведения о системе, не являющиеся данными состояния, такие как доступные лишь для чтения сведения о состоянии и собранной статистике.

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

4.3.2. Определения

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

Данные конфигурации представляют собой набор доступных для записи данных, требуемых для перехода системы из принятого по умолчанию начального состояния в её текущее состояние [RFC4741].
Данные работчего состояния — это набор сведений полученных системой в процессе работы и влияющих на поведение системы подобно данным конфигурации. В отличие от данных конфигурации, данные рабочего состояния имеют временный характер и изменяются в результате взаимодействий с внутренними компонентами и другими системами по специализтолванным протоколам.
Статистические данные представляют собой доступные лишь для чтения данные, созданные самой системой. Они описывают производительность системы и её компонентов.

Приведённые ниже примеры помогут понять разницу между данными конфигурации, состояния и статистики.

4.3.2.1. Пример 1 — таблица маршрутизации IP

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

4.3.2.2. Пример 2 — интерфейсы

Сетевые интерфейсы обычно имеют большое число атрибутов, связанных с типом интерфейса, а в некоторых случаях — с подключённым к интерфейсу кабелем. Примерами являются значения MTU на интерфейсе или скорость интерфейса Ethernet.

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

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

4.3.2.3. Пример 3 — учётные записи

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

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

4.3.3. Допущения

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

4.3.3.1. Модели данных

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

4.3.3.2. Дополнительные операции по извлечению рабочего состояния

Протокол NETCONF может расширяться новыми операциями, которые, в частности, позволяют извлекать всё рабочее состояние , например, операция <get-ops> (и, возможно, также операция <get-stats>).

4.3.3.3. Хранилище данных рабочего состояния

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

4.4. Решения

В настоящее время единственным жизнеспособным вариантом является раздельное моделирование конфигурации и рабочего состояния. Листья конфигурации будут указывать желаемые значения, а листья рабочего состояния — текущие значения на устройстве. В примере с режимом дуплекса будет два листа — duplex (config true) и op-duplex (config false).

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

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

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

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

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

[ISODSDL] International Organization for Standardization, «Document Schema Definition Languages (DSDL) — Part 1: Overview», ISO/IEC 19757-1, November 2004.

[RFC3535] Schoenwaelder, J., «Overview of the 2002 IAB Network Management Workshop», RFC 3535, May 2003.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 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.

[RFC4742] Wasserman, M. and T. Goddard, «Using the NETCONF Configuration Protocol over Secure SHell (SSH)», RFC 4742, December 2006.

[RFC4743] Goddard, T., «Using NETCONF over the Simple Object Access Protocol (SOAP)», RFC 4743, December 2006.

[RFC4744] Lear, E. and K. Crozier, «Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)», RFC 4744, December 2006.

[RFC5277] Chisholm, S. and H. Trevino, «NETCONF Event Notifications», RFC 5277, July 2008.

[RFC5539] Badra, M., «NETCONF over Transport Layer Security (TLS)», RFC 5539, May 2009.

[RFC6020] Bjorklund, M., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, October 2010.

[RFC6021] Schoenwaelder, J., «Common YANG Data Types», RFC 6021, October 2010.

[RFC6087] Bierman, A., «Guidelines for Authors and Reviewers of YANG Data Model Documents», RFC 6087, January 2011.

[RFC6110] Lhotka, L., «Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content», RFC 6110, February 2011.

[RFC6243] Bierman, A. and B. Lengyel, «With-defaults Capability for NETCONF», RFC 6243, June 2011.

[SWEXPECT] «The Expect Home Page», <http://expect.sourceforge.net/>.

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

[W3CXQUERY] Boag, S., «XQuery 1.0: An XML Query Language», W3C WD WD-xquery-20050915, September 2005.

[W3CXSD] Walmsley, P. and D. Fallside, «XML Schema Part 0: Primer Second Edition», World Wide Web Consortium Recommendation REC-xmlschema-0-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.

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

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

[RCDML] Presuhn, R., Ed., «Requirements for a Configuration Data Modeling Language», Work in Progress, February 2008.

Адрес автора

Phil Shafer

Juniper Networks

EMail: phil@juniper.net

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3В оригинале ошибочно сказано commit-configuration, см. https://www.rfc-editor.org/errata/eid5760. Прим. перев.

4В оригинале ошибочно сказано reference, см. https://www.rfc-editor.org/errata/eid3012. Прим. перев.

5В оригинале ошибочно сказано interfaces, см. https://www.rfc-editor.org/errata/eid3356. Прим. перев.

6Maximum Transmission Unit — максимальный передаваемый блок.

7Lightweight Directory Access Protocol — облегченный протокол доступа к каталогам.

8Network Information Service — сетеавая информационная система.

Рубрика: RFC | Оставить комментарий

RFC 6241 Network Configuration Protocol (NETCONF)

Опубликовано 07.06.2011 автором Nikolai Malykh

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

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

Network Configuration Protocol (NETCONF)

PDF

Аннотация

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

client — клиент

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

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

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

datastore — хранилище

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

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

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

message — сообщение

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

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

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

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

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

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

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

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

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

server — сервер

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

session — сессия

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

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

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

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

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

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

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

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

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

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

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


        Уровень                Пример
    +-------------+      +-----------------+      +----------------+
(4) | Содержимое  |      |      Данные     |      |     Данные     |
    |             |      |  конфигурации   |      |   уведомления  |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------+              |
(3) |  Операции   |      |  <edit-config>  |              |
    |             |      |                 |              |
    +-------------+      +-----------------+              |
           |                       |                      |
    +-------------+      +-----------------+      +----------------+
(2) |  Сообщения  |      |     <rpc>,      |      | <notification> |
    |             |      |   <rpc-reply>   |      |                |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------------------------------+
(1) |  Защищённый |      |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
    |  транспорт  |      |                                         |
    +-------------+      +-----------------------------------------+

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

Защищённый транспорт (Secure Transport) обеспечивает коммуникационный путь между клиентом и сервером. NETCONF может работать на основе любого транспортного протокола, соответствующего базовым требованиям, которые приведены в разделе 2.
Уровень сообщений (Messages) обеспечивает простой и независимый от транспорта механизм кадрирования сообщений для представления RPC и уведомлений. Сообщения RPC описаны в разделе 4, а уведомления — в [RFC5717].
Уровень операций (Operations) определяет набор базовых операций протокола, выполняемых методами RPC с представлением параметров в формате XML. Список базовых операций протокола приведён в разделе 7.
Уровень содержимого (Content) выходит за рамки этого документа. Предполагается выполнение отдельной работы по стандартизации моделей данных NETCONF.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Вопросы XML

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

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

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

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

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

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

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

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

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

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

4. Модель RPC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

error-type

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

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

error-tag

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

error-severity

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

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

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

error-app-tag

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

error-path

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

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

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

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

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

error-message

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

error-info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1. Обзор

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

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

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

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

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

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

выбор пространства имён;
выражение для сопоставления атрибутов;
узлы включения (containment);
узлы выбора;
узлы сопоставления содержимого.

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

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

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

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

Например,

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

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

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

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

Например,

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

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

6.2.3. Узлы включения

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

Например,

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

В этом примере элемент <top> является узлом включения.

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

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

Например,

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

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

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

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

Узлу сопоставления недопустимо включать вложенные элементы.
Множество узлов сопоставления (т. е., братских узлов) логически связывается операцией AND.
Фильтрация смешанного содержимого не поддерживается.
Фильтрация содержимого списков не поддерживается.
Фильтрация содержимого, включающего только пробельные символы (whitespace), не поддерживается.
Узел сопоставления должен включать непробельные символы. Пустой элемент (например, <foo></foo>) будет считаться узлом выбора (например, <foo/>).
Пробельные символы в начале и в конце игнорируются, но эти же символы внутри блока текстовых символов учитываются и не меняются.

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

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

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

Например,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

get;
get-config;
edit-config;
copy-config;
delete-config;
lock;
unlock;
close-session;
kill-session.

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

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

7.1. <get-config>

Описание

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

Параметры

source

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

filter

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

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

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

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

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

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

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

Пример

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

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

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

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

7.2. <edit-config>

Описание

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

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

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

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

Атрибуты

operation

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

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

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

merge

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

replace

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

create

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

delete

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

remove

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

Параметры

target

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

default-operation

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

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

merge

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

replace

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

none

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

test-option

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

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

test-then-set

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

set

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

test-only

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

error-option

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

stop-on-error

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

continue-on-error

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

rollback-on-error

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

config

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

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

7.3. <copy-config>

Описание

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

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

Параметры

target

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

source

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

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

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

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

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

Пример

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

7.4. <delete-config>

Описание

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

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

Параметры

target

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

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

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

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

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

Пример

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

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

7.5. <lock>

Описание

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

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

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

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

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

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

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

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

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

Параметры

target

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

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

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

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

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

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

Пример

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

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

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

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

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

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

7.6. <unlock>

Описание

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

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

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

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

Параметры

target

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

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

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

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

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

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

Пример

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

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

7.7. <get>

Описание

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

Параметры

filter

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

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

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

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

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

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

Пример

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

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

7.8. <close-session>

Описание

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

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

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

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

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

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

Пример

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

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

7.9. <kill-session>

Описание

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

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

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

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

Параметры

session-id

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

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

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

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

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

Пример

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

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

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

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, BEEP¹⁰ и т. п.).

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

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

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

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

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

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

Операция <lock> показывает, что протокол NETCONF предназначен для использования системами, которым администратор имеет некое доверие. Как указано в этом документе, можно заблокировать части конфигурации, что сделает их недоступными для других. В конечном итоге может быть заблокирована конфигурация целиком. Для смягчения этой проблемы есть два подхода. Можно «убить» другую сессию NETCONF программными средствами в рамках протокола NETCONF, если идентификатор этой сессии известен. Другим вариантом является снятие блокировки с использованием пользовательского интерфейса самого устройства. Эти два механизма могут действовать один против другого, что может быть устранено путём удаления нарушителя с сервера AAA¹¹. Однако такое решение удобно не во всех случаях (например, при использовании парных ключей 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 6020 ¹³, 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>¹⁴.

[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. Обзор

D.1.2. Зависимости

D.1.3. Идентификатор свойства

Имя {name} свойства указывается строкой вида

      {capability uri}

D.1.4. Новые операции

D.1.4.1. <op-name>

D.1.5. Изменение операций

D.1.5.1. <op-name>

Если имеющиеся операции это свойство не меняет, это раздел можно опустить.

D.1.6. Взаимодействия с другими свойствами

Если это свойство не взаимодействует с другими, раздел можно опустить.

Приложение 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@protokols.ru

1Network Configuration Protocol.

2Extensible Markup Language.

3Remote procedure call.

4Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

5Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

6Application programming interface.

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

8Transport Layer Security.

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

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

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

12В RFC 7803 это требование было смягчено. Прим. перев.

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

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

Рубрика: RFC | Комментарии отключены