RFC 8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

Internet Engineering Task Force (IETF)                          D. Kumar
Request for Comments: 8531                                         Cisco
Category: Standards Track                                          Q. Wu
ISSN: 2070-1721                                                  M. Wang
                                                                  Huawei
                                                              April 2019

Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

Базовая модель данных YANG для ориентированных на соединения протоколов OAM

PDF

Аннотация

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

Модель данных YANG в этом документе соответствует архитектуре NMDA¹.

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

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

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

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

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

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

1. Введение

OAM включает важные сетевые функции, которые позволяют операторам:

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

Обзор инструментов OAM представлен в [RFC7276]. За долгие годы было разработано множество инструментов для контроля отказов и управления производительностью.

Разные наборы инструментов OAM могут поддерживать как технологии на основе соединений, так и без них. В ориентированных на соединения технологиях соединение создается до начала передачи данных. После организации соединения не требуется передачи дополнительной управляющей информации (такой как сигналы или операции) для передачи пользовательских данных. В технологиях без организации соединений данные обычно передаются между взаимодействующими конечными точками без предварительного согласования, но нужны управляющие данные для указания получателя (например, [G.800]). Модель данных YANG для протоколов OAM без организации соединений задана в [RFC8532] и [IEEE802.1Q].

Контроль отказов в соединениях (CFM), как указано в [IEEE802.1Q], является четко определенным стандартом OAM, широко распространенным в сетях Ethernet. ITU-T [G.8013], MEF Forum (MEF) Service OAM [MEF-17], MPLS-TP⁴ [RFC6371] и TRILL [RFC7455] определяют механизмы OAM, основанные на модели управляемости CFM [IEEE802.1Q].

С учетом широкого распространения базовых концепций OAM, определенных в CFM [IEEE802.1Q], разумным шагом будет разработка унифицированной схемы управления для ориентированных на соединения решений OAM на базе этих концепций. В этом документе модель CFM [IEEE802.1Q] служит основой для расширения до технологически независимой модели и определения соответствующей модели данных YANG. Представленная здесь модель данных YANG служит базой для ориентированных на соединения протоколов OAM и поддерживает базовую проверку непрерывности, проверку связности и обнаружение пути (traceroute). Базовая модель YANG для ориентированных на соединения решений OAM разработана с возможностью расширения на другие технологии, основанные на соединениях. Зависимые от технологии узлы и команды (RPC) определяются в зависимых от технологии моделях данных YANG, которые используют и расширяют определенную здесь базовую модель. Например, расширяемые виртуальные ЛВС (VXLAN⁵), используют порт отправителя UDP для энтропии потока, а TRILL использует (a) MAC-адрес, (b) тег VLAN или метку Fine-Grained Label и/или (c) адрес IP для энтропии потока в хэшировании при выборе среди множества путей. С учетом этих различий соответствующие модели данных YANG будут определять подходящие структуры в качестве дополнения к представленной здесь базовой модели. Это решает три задачи – во-первых, каждая модель данных YANG сохраняется компактной и управляемой, во-вторых, такие модели можно разрабатывать независимо, и в-третьих, реализации могут ограничиваться поддержкой лишь нужного набора моделей YANG. Например, TRILL RBridge может ограничиться реализацией базовой модели данных и модели TRILL YANG.

Представленная здесь модель данных YANG генерируется на уровне управления. Инкапсуляция и конечные автоматы состояний могут различаться для каждого протокола OAM. Пользователь, желающий ввести программу проверки непрерывности работы (Continuity Check), Loopback или организовать сеанм мониторинга производительности, может сделать это независимо от базового протокола, технологии или конкретной реализации производителя.

В качестве примера рассмотрим случай, где в соединении между устройствами A возникает отказ B. Между A и B имеются мосты IEEE 802.1 a, b и c. Предположим, что эти мосты используют CFM [IEEE802.1Q]. Пользователь, увидев отказ, может решить, что следует выполнить проверку на более низком уровне в разных сегментах пути и запускает соответствующие средства проверки (Loopback Message) и изоляции (Looktrace Message) отказов, использующие общий API. Такая возможность детализации до нижнего уровня стека протоколов в конкретном сегменте пути для поиска точки отказа, называется вложенным процессом OAM. Это полезная концепция, которая обеспечивает эффективный поиск неполадок и процесс обслуживания. Представленная в документе модель данных OAM YANG, ориентированная на соединения, облегчает такой подход не требуя менять базовые протоколы.

Модель данных YANG в этом документе соответствует архитектуре сетевых хранилищ NMDA⁶, определенной в [RFC8342].

2. Используемые соглашения

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

Многие из применяемых в документе терминов (включая указанные в параграфах 2.1 и 2.2) относятся к сфере OAM. Этот документ не пытается объяснить эти термины и предполагает знакомство читателя с концепциями. Хороший обзор представлен в [IEEE802.1Q]. Термины OAM в работах IETF рассмотрены в [RFC6371].

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

CCM

Continuity Check Message – сообщение проверки непрерывности [IEEE802.1Q].

ECMP

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

LBM

Loopback Message – сообщение Loopback [IEEE802.1Q].

LTM

Linktrace Message – сообщение Linktrace [IEEE802.1Q].

Maintenance Point – точка обслуживания [IEEE802.1Q].

MEP

Maintenance End Point – конечная точка обслуживания [RFC7174] (называется также Maintenance association End Point [IEEE802.1Q] и MEG End Point [RFC6371]).

MIP

Maintenance Intermediate Point – промежуточная точка обслуживания [RFC7174] (называется также Maintenance domain Intermediate Point [IEEE802.1Q] и MEG Intermediate Point [RFC6371]).

Maintenance Association – ассоциация обслуживания [IEEE802.1Q] [RFC7174].

Maintenance Domain – домен (область) обслуживания [IEEE802.1Q].

MEG

Maintenance Entity Group – группа объектов обслуживания [RFC6371].

MTV

Multi-destination Tree Verification Message – сообщение проверки дерева со множеством получателей.

OAM

Operations, Administration, and Maintenance – эксплуатация, администрирование, обслуживание [RFC6291].

TRILL

Transparent Interconnection of Lots of Links – прозрачное соединение множества каналов [RFC6325].

CFM

Connectivity Fault Management – обслуживание отказов в соединениях [RFC7174] [IEEE802.1Q].

RPC

Remote Procedure Call – вызов удаленной процедуры.

Continuity Check – проверка непрерывности [RFC7276].

Connectivity Verification – проверка связности [RFC7276].

2.2. Термины

Continuity Checks – проверка непрерывности

CC служит для проверки доступности адресата, поэтому называется также проверкой доступности.

Connectivity Verification – проверка связности

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

Proactive OAM – OAM в проактивном режиме

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

On-demand OAM – OAM по запросу

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

2.3. Диаграммы деревьев

В диаграммах деревьев применяется нотация, определенная в [RFC8340].

3. Архитектура базовой модели YANG для OAM на базе соединений

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

                       +-----------+
                       |Connection-|
                       | Oriented  |
                       |  generic  |
                       | OAM YANG  |
                       +-+-+-+-+-+-+
                             |
                             |
                             |
     +------------------------------------------+
     |                       |                  |
+-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
| TRILL   |          | MPLS-TP |     . . .|  foo    |
|OAM YANG |          |OAM YANG |          |OAM YANG |
+-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
     |                    |                     |
     |                    |               +-+-+-+-+-+
     |                    |          . . .|  foo    |
     |                    |               |sub tech |
     |                    |               +-+-+-+-+-+
     |                    |                     |
     |                    |                     |
+---------------------------------------------------+
|                      Uniform API                  |
+---------------------------------------------------+

Рисунок 1. Связь модели OAM YANG с базовой моделью YANG.

4. Обзор ориентированной на соединения модели данных OAM YANG

В этом документе применяются концепции модели CFM [IEEE802.1Q] и структура, которые могут быть адаптированы для других протоколов OAM, ориентированных на соединения.

На вершине модели размещается домен обслуживания (MD). Каждый домен обслуживания связан с именем обслуживания (Maintenance Name) и уровнем домена (Domain Level).

В каждом MD имеется одна или множество ассоциаций обслуживания (MA). В TRILL ассоциация MA может соответствовать Fine-Grained Label.

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

Команды представлены в протоколе управления, который ортогонален MD. В терминах YANG это команды RPC. Они обеспечивают унифицированные интерфейсы API для CC, CV, обнаружения пути (traceroute) и их эквивалентов, а также для других команд OAM.

Объекты OAM в определенной здесь базовой модели YANG будут явно или неявно настраиваться с помощью инструментов OAM. Эти инструменты ограничены набором OAM, указанным в параграфе 5.1 [RFC7276]. Для упрощения настройки «в одно касание» (zero-touch) этот документ определяет принятый по умолчанию режим OAM. Этот режим называется базовым (Base Mode) и задает принятые по умолчанию значения для каждого параметра модели (уровень MD, имя MA, адреса MEP и т. д.). Принятые по умолчанию значения зависят от технологии. Базовый режим для TRILL определен в [RFC7455], а базовые режимы для других технологий и будущие расширения, созданные в IETF, будут определены в соответствующих документах.

Важено отметить, что в модель YANG не требуется вносить изменений для поддержки Base Mode. Реализации, соответствующие этому документу, по умолчанию используют узлы данных применимой технологии. Узлы данных базовой модели доступны лишь для чтения (read-only).

4.1. Конфигурация MD

module: ietf-connection-oriented-oam
 +--rw domains
    +--rw domain* [technology md-name-string]
       +--rw technology        identityref
       +--rw md-name-string    md-name-string
       +--rw md-name-format?   identityref
       +--rw (md-name)?
       |  +--:(md-name-null)
       |     +--rw md-name-null? empty
       +--rw md-level?           md-level

Фрагмент иерархии данных домена OAM.

Контейнер domains является контейнером верхнего уровня в модуле gen-oam. Внутри этого контейнера поддерживаются отдельные списки для MD, индексируемые ключом md-name-string. Лист md-name-string имеет тип, выведенный из string. Могут включаться дополнительные форматы имен из [IEEE802.1Q] или иных стандартов путем связывания md-name-format с identity-ref. Лист md-name-format указывает формат добавленного md-name. Лист md-name представляется как конструкция choice/case. Это обеспечивает простоту дополнения.

4.2. Конфигурация MA

В данном MD может присутствовать одна или множество ассоциаций MA, представляемых в виде списка и индексируемых ma-name-string. Подобно md-name, могут добавляться форматы имен с помощью identity-ref и добавления подходящих операторов case в ma-name.

module: ietf-connection-oriented-oam
 +--rw domains
    +--rw domain* [technology md-name-string]
       .
       .
       +--rw mas
          +--rw ma* [ma-name-string]
             +--rw ma-name-string          ma-name-string
             +--rw ma-name-format?         identityref
             +--rw (ma-name)?
             |  +--:(ma-name-null)
             |     +--rw ma-name-null?     empty

Фрагмент иерархии MA.

4.3. Конфигурация MEP

В данной MA может быть одна или множество конечных точек обслуживания (MEP), представляемых списком в иерархии данных и индексируемых ключом mep-name.

module: ietf-connection-oriented-oam
 +--rw domains
    +--rw domain* [technology md-name-string]
       +--rw technology                  identityref
       .
       .
       +--rw mas
          +--rw ma* [ma-name-string]
             .
             .
             +--rw mep* [mep-name]
             |  +--rw mep-name         mep-name
             |  +--rw (mep-id)?
             |  |  +--:(mep-id-int)
             |  |     +--rw mep-id-int?      int32
             |  +--rw mep-id-format?   identityref
             |  +--rw (mep-address)?
             |  |  +--:(mac-address)
             |  |  |  +--rw mac-address?     yang:mac-address
             |  |  +--:(ip-address)
             |  |     +--rw ip-address?      inet:ip-address
             .          .
             .          .
             .          .

Фрагмент иерархии MEP.

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

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

Для целей OAM определено несколько команд RPC. В этом параграфе для иллюстрации представлен фрагмент команды проверки непрерывности (CC). Полное описание иерархии данных приведено в параграфе 4.7, а модуль YANG описан в разделе 5.

   module: ietf-connection-oriented-oam
       +--rw domains
             +--rw domain* [technology md-name-string]
             +--rw technology        identityref
       .
       .
   rpcs:
     +---x continuity-check {continuity-check}?
     |  +---w input
     |  |  +---w technology?             identityref
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?                 uint8
     |  |  +---w ttl?                    uint8
     |  |  +---w sub-type?               identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?                  uint32
     |  |  +---w cc-transmit-interval?   time-interval
     |  |  +---w packet-size?            uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x continuity-verification {connectivity-verification}?
     |  +---w input
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?            uint8
     |  |  +---w ttl?               uint8
     |  |  +---w sub-type?          identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?             uint32
     |  |  +---w interval?          time-interval
     |  |  +---w packet-size?       uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x traceroute {traceroute}?
        +---w input
        |  +---w md-name-string -> /domains/domain/md-name-string
        |  +---w md-level?      -> /domains/domain/md-level
        |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
        |  +---w cos-id?             uint8
        |  +---w ttl?                uint8
        |  +---w command-sub-type?   identityref
        |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
        |  +---w destination-mep
        |  |  +---w (mep-address)?
        |  |  |  +--:(mac-address)
        |  |  |  |  +---w mac-address?     yang:mac-address
        |  |  |  +--:(ip-address)
        |  |  |     +---w ip-address?      inet:ip-address
        |  |  +---w (mep-id)?
        |  |  |  +--:(mep-id-int)
        |  |  |     +---w mep-id-int?      int32
        |  |  +---w mep-id-format?   identityref
        |  +---w count?              uint32
        |  +---w interval?           time-interval
        +--ro output
           +--ro response* [response-index]
              +--ro response-index     uint8
              +--ro ttl?               uint8
              +--ro destination-mep
              |  +--ro (mep-address)?
              |  |  +--:(mac-address)
              |  |  |  +--ro mac-address?     yang:mac-address
              |  |  +--:(ip-address)
              |  |     +--ro ip-address?      inet:ip-address
              |  +--ro (mep-id)?
              |  |  +--:(mep-id-int)
              |  |     +--ro mep-id-int?      int32
              |  +--ro mep-id-format?   identityref
              +--ro mip {mip}?
              |  +--ro interface?     if:interface-ref
              |  +--ro (mip-address)?
              |     +--:(mac-address)
              |     |  +--ro mac-address?   yang:mac-address
              |     +--:(ip-address)
              |        +--ro ip-address?    inet:ip-address
              +--ro (monitor-stats)?
                 +--:(monitor-null)
                    +--ro monitor-null?      empty

Фрагмент иерархии RPC Call Continuity-Check.

4.5. Уведомления

Уведомления передаются при обнаружении и снятии условий дефекта и содержат имена MD и MA, тип дефекта (существующего в данный момент), идентификатор создавшей уведомление точки (generating-mepid) и сообщение defect-message с дополнительными деталями.

4.6. Статистика мониторинга

Группировка для статистики мониторинга применяется модулями YANG для конкретной технологии, которые дополняют базовую модель данных YANG для предоставления статистики с использованием похожих на OAM сообщений проверки непрерывности (CCM⁷), например, CCM transmit, CCM receive, CCM error и т. п.

4.7. Иерархия данных OAM

Ниже представлена полная иерархия данных, относящихся к ориентированной на соединения модели данных OAM YANG.

 module: ietf-connection-oriented-oam
     +--rw domains
        +--rw domain* [technology md-name-string]
           +--rw technology        identityref
           +--rw md-name-string    md-name-string
           +--rw md-name-format?   identityref
           +--rw (md-name)?
           |  +--:(md-name-null)
           |     +--rw md-name-null?     empty
           +--rw md-level?         md-level
           +--rw mas
              +--rw ma* [ma-name-string]
                 +--rw ma-name-string    ma-name-string
                 +--rw ma-name-format?   identityref
                 +--rw (ma-name)?
                 |  +--:(ma-name-null)
                 |     +--rw ma-name-null?     empty
                 +--rw (connectivity-context)?
                 |  +--:(context-null)
                 |     +--rw context-null?     empty
                 +--rw cos-id?           uint8
                 +--rw cc-enable?        boolean
                 +--rw mep* [mep-name]
                 |  +--rw mep-name         mep-name
                 |  +--rw (mep-id)?
                 |  |  +--:(mep-id-int)
                 |  |     +--rw mep-id-int?      int32
                 |  +--rw mep-id-format?   identityref
                 |  +--rw (mep-address)?
                 |  |  +--:(mac-address)
                 |  |  |  +--rw mac-address?     yang:mac-address
                 |  |  +--:(ip-address)
                 |  |     +--rw ip-address?      inet:ip-address
                 |  +--rw cos-id?          uint8
                 |  +--rw cc-enable?       boolean
                 |  +--rw session* [session-cookie]
                 |     +--rw session-cookie             uint32
                 |     +--rw destination-mep
                 |     |  +--rw (mep-id)?
                 |     |  |  +--:(mep-id-int)
                 |     |  |     +--rw mep-id-int?      int32
                 |     |  +--rw mep-id-format?   identityref
                 |     +--rw destination-mep-address
                 |     |  +--rw (mep-address)?
                 |     |     +--:(mac-address)
                 |     |     |  +--rw mac-address?   yang:mac-address
                 |     |     +--:(ip-address)
                 |     |        +--rw ip-address?    inet:ip-address
                 |     +--rw cos-id?                    uint8
                 +--rw mip* [name] {mip}?
                    +--rw name           string
                    +--rw interface?     if:interface-ref
                    +--rw (mip-address)?
                       +--:(mac-address)
                       |  +--rw mac-address?   yang:mac-address
                       +--:(ip-address)
                          +--rw ip-address?    inet:ip-address

   rpcs:
     +---x continuity-check {continuity-check}?
     |  +---w input
     |  |  +---w technology?             identityref
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?                 uint8
     |  |  +---w ttl?                    uint8
     |  |  +---w sub-type?               identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?                  uint32
     |  |  +---w cc-transmit-interval?   time-interval
     |  |  +---w packet-size?            uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x continuity-verification {connectivity-verification}?
     |  +---w input
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?            uint8
     |  |  +---w ttl?               uint8
     |  |  +---w sub-type?          identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?             uint32
     |  |  +---w interval?          time-interval
     |  |  +---w packet-size?       uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x traceroute {traceroute}?
        +---w input
        |  +---w md-name-string -> /domains/domain/md-name-string
        |  +---w md-level?      -> /domains/domain/md-level
        |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
        |  +---w cos-id?             uint8
        |  +---w ttl?                uint8
        |  +---w command-sub-type?   identityref
        |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
        |  +---w destination-mep
        |  |  +---w (mep-address)?
        |  |  |  +--:(mac-address)
        |  |  |  |  +---w mac-address?     yang:mac-address
        |  |  |  +--:(ip-address)
        |  |  |     +---w ip-address?      inet:ip-address
        |  |  +---w (mep-id)?
        |  |  |  +--:(mep-id-int)
        |  |  |     +---w mep-id-int?      int32
        |  |  +---w mep-id-format?   identityref
        |  +---w count?              uint32
        |  +---w interval?           time-interval
        +--ro output
           +--ro response* [response-index]
              +--ro response-index     uint8
              +--ro ttl?               uint8
              +--ro destination-mep
              |  +--ro (mep-address)?
              |  |  +--:(mac-address)
              |  |  |  +--ro mac-address?     yang:mac-address
              |  |  +--:(ip-address)
              |  |     +--ro ip-address?      inet:ip-address
              |  +--ro (mep-id)?
              |  |  +--:(mep-id-int)
              |  |     +--ro mep-id-int?      int32
              |  +--ro mep-id-format?   identityref
              +--ro mip {mip}?
              |  +--ro interface?     if:interface-ref
              |  +--ro (mip-address)?
              |     +--:(mac-address)
              |     |  +--ro mac-address?   yang:mac-address
              |     +--:(ip-address)
              |        +--ro ip-address?    inet:ip-address
              +--ro (monitor-stats)?
                 +--:(monitor-null)
                    +--ro monitor-null?      empty

   notifications:
     +---n defect-condition-notification
     |  +--ro technology?         identityref
     |  +--ro md-name-string -> /domains/domain/md-name-string
     |  +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  +--ro mep-name?      -> /domains/domain/mas/ma/mep/mep-name
     |  +--ro defect-type?        identityref
     |  +--ro generating-mepid
     |  |  +--ro (mep-id)?
     |  |  |  +--:(mep-id-int)
     |  |  |     +--ro mep-id-int?      int32
     |  |  +--ro mep-id-format?   identityref
     |  +--ro (defect)?
     |     +--:(defect-null)
     |     |  +--ro defect-null?        empty
     |     +--:(defect-code)
     |        +--ro defect-code?        int32
     +---n defect-cleared-notification
        +--ro technology?         identityref
        +--ro md-name-string -> /domains/domain/md-name-string
        +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
        +--ro mep-name?      -> /domains/domain/mas/ma/mep/mep-name
        +--ro defect-type?        identityref
        +--ro generating-mepid
        |  +--ro (mep-id)?
        |  |  +--:(mep-id-int)
        |  |     +--ro mep-id-int?      int32
        |  +--ro mep-id-format?   identityref
        +--ro (defect)?
           +--:(defect-null)
           |  +--ro defect-null?        empty
           +--:(defect-code)
              +--ro defect-code?        int32

Иерархия OAM.

5. Модуль OAM YANG

Этот модуль импортирует определения типов (typedef) из [RFC6991] и [RFC8343], а также ссылается на [RFC6371], [RFC6905] и [RFC7276].

   <CODE BEGINS> file "ietf-connection-oriented-oam@2019-04-16.yang"
module ietf-connection-oriented-oam {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam";
  prefix co-oam;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-inet-types {
    prefix inet;
  }
  import ietf-interfaces {
    prefix if;
  }

  organization
    "IETF LIME Working Group";
  contact
    "WG Web:    http://datatracker.ietf.org/wg/lime 
     WG List:   <mailto:lime@ietf.org> 
     Editor:    Deepak Kumar <dekumar@cisco.com> 
     Editor:    Qin Wu <bill.wu@huawei.com> 
     Editor:    Michael Wang <wangzitao@huawei.com>"; 
  description
    "Этот модуль YANG определяет базовую конфигурацию,
     статистику и RPC для ориентированных на соединения OAM,
     применяемых в IETF независимо от протокола. Абстракция
     функционального уровня не зависит от модели YANG.
     Предполагается, что каждый протокол отображает 
     соответствующие абстракции на их естественный формат.
     Каждый протокол может расширять модель YANG, определенную 
     здесь, для решения специфических задач.

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

     Распространение и использование модуля в исходном или двоичном
     формате, с изменениями или без таковых разрешено в соответствии 
     с условиями лицензии Simplified BSD License, изложенными в
     разделе 4.c документа IETF Trust's Legal Provisions применительно
     к документам IETF (http://trustee.ietf.org/license-info). 

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

  revision 2019-04-16 {
    description
      "Первый выпуск.";
    reference
      "RFC 8531: Generic YANG Data Model for Connection-
       Oriented Operations, Administration, and Maintenance (OAM)
       Protocols";
  }

  feature connectivity-verification {
    description
      "Это свойство указывает, что сервер поддерживает команду
       OAM для проверки связности и возвращает отклик. Серверы,
       не анонсирующие эту возможность, не будут поддерживать
       выполнение команды проверки связности или модели RPC для
       такой команды.";
  }

  feature continuity-check {
    description
      "Это свойство указывает, что сервер поддерживает команду
       OAM CC и возвращает отклик. Серверы, не анонсирующие
       эту возможность, не будут поддерживать команду CC или 
       модель RPC для нее.";
  }

  feature traceroute {
    description
      "Это свойство указывает, что сервер поддерживает команду
       OAM traceroute и возвращает отклик. Серверы, не 
       анонсирующие  эту возможность, не будут поддерживать 
       команду traceroute или модель RPC для traceroute.";
  }

  feature mip {
    description
      "Это свойство показывает, что MIP требует явной настройки.";
  }
  identity technology-types {
    description
      "Базовое отождествление типов технологии (TRILL, MPLS-TP и т. п.).";
  }

  identity command-sub-type {
    description
      "Определяет субтипы различных команд RPC, например,
       TRILL OAM как указано в RFC 6905. В большинстве
       случаев это не обязательно.";
    reference
      "RFC 6905: Requirements for OAM in Transparent
       Interconnection of Lots of Links (TRILL)";
  }

  identity on-demand {
    base command-sub-type;
    description
      "Активизация по запросу указывает, что инструмент запускается
       вручную для поиска соответствующей аномалии.
       OAM по запросу требует лишь временной настройки конфигурации.";
    reference
      "RFC 7276: An Overview of Operations, Administration, and
       Maintenance (OAM) Tools";
  }

  identity proactive {
    base command-sub-type;
    description
      "Проактивный режим показывает, что инструмент работает непрерывно,
       сообщения передаются периодически, а ошибкой считается отсутствие 
       некоторого числа сообщения. Проактивный режим требует постоянной
       настройки конфигурации.";
    reference
      "RFC 7276: An Overview of Operations, Administration, and
       Maintenance (OAM) Tools";
  }

  identity name-format {
    description
      "Определяет формат имени, отличающийся от CFM (IEEE 802.1Q). 
       Предполагается, что формат имени является идентификационной
       ссылкой, которая будет расширена новыми типами.";
  }

  identity name-format-null {
    base name-format;
    description
      "Определяет формат как пустой (null).";
  }

  identity identifier-format {
    description
      "Отождествление identifier-format может быть дополнено для
       определения других форматов, применяемых в MEP-ID и пр.";
  }

  identity identifier-format-integer {
    base identifier-format;
    description
      "Определяет identifier-format как целое число.";
  }

  identity defect-types {
    description
      "Определяет различные типы дефектов, например,
       RDI⁸, потеря непрерывности.";
  }

  identity rdi {
    base defect-types;
    description
      "RDI указывает общее состояние точек MEP.";
  }

  identity remote-mep-defect {
    base defect-types;
    description
      "Указывает, что одна или несколько удаленных MEP
       сообщили об отказе.";
  }

  identity loss-of-continuity {
    base defect-types;
    description
      "Указывает, что в течение заданного интервала не было пакетов CC
       OAM от удаленной MEP (а в случае CV, это включает требование
       наличия уникального, зависящего от технологии идентификатора MEP).";
    reference
      "RFC 6371: Operations, Administration, and Maintenance
       Framework for MPLS-Based Transport Networks";
  }

  identity cv-defect {
    base defect-types;
    description
      "Этой функции следует поддерживать мониторинг между MEP, а
       также между MEP и MIP. При выполнении CV сообщения CC и
       CC-V⁹ должны однозначно указывать проверяемую MEG и
       MEP, передающую сообщение.";
    reference
      "RFC 6371: Operations, Administration, and Maintenance
       Framework for MPLS-Based Transport Networks";
  }

  identity invalid-oam-defect {
    base defect-types;
    description
      "Указывает, что было получено 1 или несколько непригодных 
       сообщений OAM, а интервал передачи сообщений OAM еще не
       истек (3,5 раза).";
  }

  identity cross-connect-defect {
    base defect-types;
    description
      "Указывает, что был получен 1 или несколько дефектов кросс-
       соединений (например, идентификатор сервиса не соответствует
       VLAN), а интервал передачи сообщений OAM еще не истек (3,5 раза).";
  }

  typedef mep-name {
    type string;
    description
      "Базовое административное имя для MEP.";
  }

  typedef time-interval {
    type decimal64 {
      fraction-digits 2;
    }
    units "milliseconds";
    description
      "Временной интервал между пакетами в мсек, который следует
       задавать не меньше 0. Нулевой интервал означает отсутствие
       передачи пакетов.";
  }

  typedef md-name-string {
    type string;
    description
      "Базовое административное имя для MD.";
  }

  typedef ma-name-string {
    type string;
    description
      "Базовое административное имя для MA.";
  }

  typedef oam-counter32 {
    type yang:zero-based-counter32;
    description
      "Определяет 32-битовый счетчик для OAM.";
  }

  typedef md-level {
    type uint32 {
      range "0..255";
    }
    description
      "Уровень домена обслуживания (MD). Некоторые протоколы 
       могут ограничивать уровень (например, от 0 до 7).";
  }

  grouping maintenance-domain-reference {
    description
      "Эта группировка однозначно указывает MD.";
    leaf maintenance-domain {
      type leafref {
        path "/co-oam:domains/co-oam:domain/co-oam:md-name-string";
      }
      description
        "Указание конкретного MD.";
    }
  }

  grouping maintenance-association-reference {
    description
      "Эта группировка однозначно указывает MA и 
       состоит из leafref maintenance-domain-reference 
       и maintenance-association.";
    uses maintenance-domain-reference;
    leaf maintenance-association {
      type leafref {
        path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
           + "= current()/../maintenance-domain]/co-oam:mas"
           + "/co-oam:ma/co-oam:ma-name-string";
      }
      description
        "Указание конкретной MA.";
    }
  }

  grouping maintenance-association-end-point-reference {
    description
      "Эта группировка однозначно указывает MA и 
       состоит из листьев-ссылок 
       maintenance-association-reference и
       a maintenance-association-end-point.";
    uses maintenance-association-reference;
    leaf maintenance-association-end-point {
      type leafref {
        path "/co-oam:domains/co-oam:domain[co-oam:md-name-string "
           + "= current()/../maintenance-domain]/co-oam:mas"
           + "/co-oam:ma[co-oam:ma-name-string = "
           + "current()/../maintenance-association]"
           + "/co-oam:mep/co-oam:mep-name";
      }
      description
        "Указание конкретной MEP.";
    }
  }

  grouping time-to-live {
    leaf ttl {
      type uint8;
      description
        "Время жизни.";
    }
    description
      "Группировка TTL.";
  }

  grouping defect-message {
    choice defect {
      case defect-null {
        description
          "Подстановка для случаев ненужности статуса дефектов.";
        leaf defect-null {
          type empty;
          description
            "Дефекты не определены и будут определяться в моделях
             для конкретных технологий.";
        }
      }
      case defect-code {
        description
          "Подстановка для отображения кода дефекта.";
        leaf defect-code {
          type int32;
          description
            "Значение кода дефекта зависит от технологии.";
        }
      }
      description
        "Варианты сообщения о дефекте.";
    }
    description
      "Сообщение о дефекте.";
  }

  grouping mep-address {
    choice mep-address {
      default "ip-address";
      case mac-address {
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC-адрес.";
        }
        description
          "Адресация MEP на основе MAC-адреса.";
      }
      case ip-address {
        leaf ip-address {
          type inet:ip-address;
          description
            "IP-адрес.";
        }
        description
          "Адресация MEP на основе IP-адреса.";
      }
      description
        "Адресация MEP.";
    }
    description
      "Группировка для адреса MEP";
  }

  grouping mip-address {
    choice mip-address {
      default "ip-address";
      case mac-address {
        leaf mac-address {
          type yang:mac-address;
          description
            "MAC-адрес точки MIP";
        }
        description
          "Адресация MIP на основе MAC-адреса.";
      }
      case ip-address {
        leaf ip-address {
          type inet:ip-address;
          description
            "IP-адрес.";
        }
        description
          "Адресация MIP на основе IP-адреса .";
      }
      description
        "Адресация MIP.";
    }
    description
      "Адрес MIP.";
  }

  grouping maintenance-domain-id {
    description
      "Группировка, содержащая листья, достаточные 
       для идентификации MD.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      mandatory true;
      description
        "Определяет технологию.";
    }
    leaf md-name-string {
      type md-name-string;
      mandatory true;
      description
        "Определяет базовое административное имя MD.";
    }
  }

  grouping md-name {
    leaf md-name-format {
      type identityref {
        base name-format;
      }
      description
        "Формат имени MD.";
    }
    choice md-name {
      case md-name-null {
        leaf md-name-null {
          when "derived-from-or-self(../md-name-format,"
             + "'name-format-null')" {
            description
              "Формат имени MD совпадает с пустым форматом.";
          }
          type empty;
          description
            "Пустое имя MD.";
        }
      }
      description
        "Имя MD.";
    }
    description
      "Имя MD.";
  }

  grouping ma-identifier {
    description
      "Группировка с листьями, достаточными для указания MA.";
    leaf ma-name-string {
      type ma-name-string;
      description
        "Строка имени MA.";
    }
  }

  grouping ma-name {
    description
      "MA name.";
    leaf ma-name-format {
      type identityref {
        base name-format;
      }
      description
        "Формат имени MA.";
    }
    choice ma-name {
      case ma-name-null {
        leaf ma-name-null {
          when "derived-from-or-self(../ma-name-format,"
             + "'name-format-null')" {
            description
              "MA.";
          }
          type empty;
          description
            "Пусто";
        }
      }
      description
        "Имя MA.";
    }
  }

  grouping mep-id {
    choice mep-id {
      default "mep-id-int";
      case mep-id-int {
        leaf mep-id-int {
          type int32;
          description
            "MEP ID в целочисленном формате.";
        }
      }
      description
        "MEP ID.";
    }
    leaf mep-id-format {
      type identityref {
        base identifier-format;
      }
      description
        "Формат MEP ID.";
    }
    description
      "MEP ID.";
  }

  grouping mep {
    description
      "Определяет элементы в MEP.";
    leaf mep-name {
      type mep-name;
      mandatory true;
      description
        "Базовое административное имя MEP.";
    }
    uses mep-id;
    uses mep-address;
  }

  grouping monitor-stats {
    description
      "Группировка для статистики мониторинга, дополняемая 
       другими при использовании этой компоненты.";
    choice monitor-stats {
      default "monitor-null";
      case monitor-null {
        description
          "Заменитель для случаев ненужности статистики 
           мониторинга.";
        leaf monitor-null {
          type empty;
          description
            "Статистика мониторинга не определена.";
        }
      }
      description
        "Определяет состояния монитора.";
    }
  }

  grouping connectivity-context {
    description
      "Группировка, определяющая контекст связности для MA,
       например, LSP для MPLS-TP. Будет дополняться каждым
       протоколом, использующим компоненту.";
    choice connectivity-context {
      default "context-null";
      case context-null {
        description
          "Замена на случая ненужности контекста.";
        leaf context-null {
          type empty;
          description
            "Контекст не определен.";
        }
      }
      description
        "Контекст связности.";
    }
  }

  grouping cos {
    description
      "Группировка для приоритета в отправляемых пакетах,
       например, в поле CoS для MPLS-TP.";
    leaf cos-id {
      type uint8;
      description
        "Идентификатор класса обслуживания (CoS).";
    }
  }

  grouping mip-grouping {
    uses mip-address;
    description
      "Группировка для настройки MIP.";
  }

  container domains {
    description
      "Содержит относящиеся к конфигурации данные. Внутри
       контейнера имеется список сбойных доменов. Каждый
       домен имеет список MA.";
    list domain {
      key "technology md-name-string";
      description
        "Определяет список доменов в модуле 
         ietf-connection-oriented-oam.";
      uses maintenance-domain-id;
      uses md-name;
      leaf md-level {
        type md-level;
        description
          "Определяет уровень MD.";
      }
      container mas {
        description
          "Содержит относящиеся к конфигурации данные. Внутри
           контейнера имеется список MA, каждая из которых
           имеет список MEP.";
        list ma {
          key "ma-name-string";
          uses ma-identifier;
          uses ma-name;
          uses connectivity-context;
          uses cos {
            description
              "Принятый по умолчанию класс обслуживания для MA.
               Список может быть переписан для отдельных MEP,
               сессий или операций.";
          }
          leaf cc-enable {
            type boolean;
            description
              "Указывает включена ли проверка CC.";
          }
          list mep {
            key "mep-name";
            description
              "Содержит список MEP.";
            uses mep;
            uses cos;
            leaf cc-enable {
              type boolean;
              description
                "Указывает включена ли проверка CC.";
            }
            list session {
              key "session-cookie";
              description
                "Сеанс мониторинга с конкретной удаленной точкой MEP.
                 В зависимости от протокола может представлять сообщения
                 CC от удаленной MEP (если протокол применяет групповые
                 CC), целевая точка, куда передаются индивидуальные
                 эхо-запросы CC или откуда принимаются отклики (если
                 протокол использует механизм запрос-отклик с
                 индивидуальной адресацией).";
              leaf session-cookie {
                type uint32;
                description
                  "Cookie для идентификации сессий при наличии множества
                   MEP или множества сессий с одной удаленной точкой MEP.";
              }
              container destination-mep {
                uses mep-id;
                description
                  "Целевая точка MEP.";
              }
              container destination-mep-address {
                uses mep-address;
                description
                  "Адрес целевой точки MEP.";
              }
              uses cos;
            }
          }
          list mip {
            if-feature "mip";
            key "name";
            leaf name {
              type string;
              description
                "Идентификатор точки MIP.";
            }
            leaf interface {
              type if:interface-ref;
              description
                "Интерфейс.";
            }
            uses mip-grouping;
            description
              "List for MIP.";
          }
          description
            "Список ассоциаций MA.";
        }
      }
    }
  }

  notification defect-condition-notification {
    description
      "При обнаружении дефекта передается такое уведомление.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      description
        "Технология.";
    }
    leaf md-name-string {
      type leafref {
        path "/domains/domain/md-name-string";
      }
      mandatory true;
      description
        "Указывает MD, к которому относится дефект.";
    }
    leaf ma-name-string {
      type leafref {
        path "/domains/domain/mas/ma/ma-name-string";
      }
      mandatory true;
      description
        "Указывает MA, с которой связан дефект.";
    }
    leaf mep-name {
      type leafref {
        path "/domains/domain/mas/ma/mep/mep-name";
      }
      description
        "Указывает точку MEP, увидевшую дефект.";
    }
    leaf defect-type {
      type identityref {
        base defect-types;
      }
      description
        "Существующие в данный момент дефекты указанной MEP.";
    }
    container generating-mepid {
      uses mep-id;
      description
        "Указывает кто создал уведомление о дефекте или 0,
         если точка не известна.";
    }
    uses defect-message {
      description
        "Сообщение о дефекте с допонительными детялями.";
    }
  }

  notification defect-cleared-notification {
    description
      "Сообщение, передаваемое при устранении дефекта.";
    leaf technology {
      type identityref {
        base technology-types;
      }
      description
        "Технология.";
    }
    leaf md-name-string {
      type leafref {
        path "/domains/domain/md-name-string";
      }
      mandatory true;
      description
        "Указывает MD, к которому относился дефект.";
    }
    leaf ma-name-string {
      type leafref {
        path "/domains/domain/mas/ma/ma-name-string";
      }
      mandatory true;
      description
        "Указывает MA, с которой был связан дефект.";
    }
    leaf mep-name {
      type leafref {
        path "/domains/domain/mas/ma/mep/mep-name";
      }
      description
        "Указывает точку MEP, увидевшую дефект.";
    }
    leaf defect-type {
      type identityref {
        base defect-types;
      }
      description
        "Существующие в данный момент дефекты указанной MEP.";
    }
    container generating-mepid {
      uses mep-id;
      description
        "Указывает кто создал уведомление о дефекте или 0,
         если точка не известна.";
    }
    uses defect-message {
      description
        "Сообщение о дефекте с допонительными детялями.";
    }
  }

  rpc continuity-check {
    if-feature "continuity-check";
    description
      "Генерирует CC, как указано в таблице 4 RFC 7276.";
    input {
      leaf technology {
        type identityref {
          base technology-types;
        }
        description
          "Технология.";
      }
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Указывает MD, к которому относится дефект.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "Уровень MD.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Указывает MA, с которой связан дефект.";
      }
      uses cos;
      uses time-to-live;
      leaf sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Определяет различные типы команд.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "Исходная точка MEP.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Применимо лишь в случае, когда целью является MEP.";
        }
        description
          "Целевая точка MEP.";
      }
      leaf count {
        type uint32;
        default "3";
        description
          "Число передаваемых сообщений CC.";
      }
      leaf cc-transmit-interval {
        type time-interval;
        description
          "Интервал времени между эхо-запросами.";
      }
      leaf packet-size {
        type uint32 {
          range "64..10000";
        }
        description
          "Размер пакетов CC в октетах.";
      }
    }
    output {
      uses monitor-stats {
        description
          "Статистика CC.";
      }
    }
  }

  rpc continuity-verification {
    if-feature "connectivity-verification";
    description
      "Генерация CV в соответствии с таблицей 4 в RFC 7276.";
    input {
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Указывает MD, к которому относится дефект.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "Уровень MD.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Указывает MA, с которой связан дефект.";
      }
      uses cos;
      uses time-to-live;
      leaf sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Определяет различные типы команд.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "MEP-источник.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Применимо лишь в случае, когда целью является MEP.";
        }
        description
          "Целевая точка MEP.";
      }
      leaf count {
        type uint32;
        default "3";
        description
          "Число передаваемых сообщений CV.";
      }
      leaf interval {
        type time-interval;
        description
          "Интервал времени между эхо-запросами.";
      }
      leaf packet-size {
        type uint32 {
          range "64..10000";
        }
        description
          "Размер пакетов CV в октетах.";
      }
    }
    output {
      uses monitor-stats {
        description
          "Статистика CV.";
      }
    }
  }

  rpc traceroute {
    if-feature "traceroute";
    description
      "Генерирует Traceroute или Path Trace и отклики.
       В RFC 7276 указываются имена инструментов - для MPLS-TP OAM
       - это Route Tracing, а для TRILL OAM - Path Tracing. Начинает
       с TTL = 1 и увеличивает значение на 1 для каждого интервала, 
       пока не будет достигнут адресат или максимальное значение TTL.";
    input {
      leaf md-name-string {
        type leafref {
          path "/domains/domain/md-name-string";
        }
        mandatory true;
        description
          "Указывает MD, к которому относится дефект.";
      }
      leaf md-level {
        type leafref {
          path "/domains/domain/md-level";
        }
        description
          "Уровень MD.";
      }
      leaf ma-name-string {
        type leafref {
          path "/domains/domain/mas/ma/ma-name-string";
        }
        mandatory true;
        description
          "Указывает MA, с которой связан дефект.";
      }
      uses cos;
      uses time-to-live;
      leaf command-sub-type {
        type identityref {
          base command-sub-type;
        }
        description
          "Определяет различные типы команд.";
      }
      leaf source-mep {
        type leafref {
          path "/domains/domain/mas/ma/mep/mep-name";
        }
        description
          "MEP-источник.";
      }
      container destination-mep {
        uses mep-address;
        uses mep-id {
          description
            "Применимо лишь в случае, когда целью является MEP.";
        }
        description
          "Целевая точка MEP.";
      }
      leaf count {
        type uint32;
        default "1";
        description
          "Число передаваемых проб traceroute. В протоколах, где 
           передаются раздельные сообщения для каждого TTL, - это
           число пакетов, переданных с каждым значением TTL.";
      }
      leaf interval {
        type time-interval;
        description
          "Интервал времени между эхо-запросами.";
      }
    }
    output {
      list response {
        key "response-index";
        leaf response-index {
          type uint8;
          description
            "Произвольный индекс для отклика. В протоколах, где 
             гарантируется лишь один отклик для каждого TTL, 
             значение TTL может служить индексом откликов.";
        }
        uses time-to-live;
        container destination-mep {
          description
            "Точка MEP, от которой получен отклик.";
          uses mep-address;
          uses mep-id {
            description
              "Применимо лишь в случае, когда целью является MEP.";
          }
        }
        container mip {
          if-feature "mip";
          leaf interface {
            type if:interface-ref;
            description
              "Интерфейс MIP.";
          }
          uses mip-address;
          description
            "Точка MIP, отвечающая на traceroute";
        }
        uses monitor-stats {
          description
            "Статистика traceroute.";
        }
        description
          "Список откликов.";
      }
    }
  }
}

   <CODE ENDS>

6. Базовый режим

Базовый режим (принят по умолчанию, см. раздел 4) определяет принятую по умолчанию конфигурацию, которая должна присутствовать в устройстве, соответствующем данному документу. Base Mode позволяет пользователям получить опыт настройки «в одно касание». Некоторые параметры требуют задаваемого настройкой определения.

6.1. Адрес MEP

В базовом режиме работы адресом MEP по умолчанию служит IP-адрес интерфейса, где размещается MEP.

6.2. MEP ID для базового режима

В базовом режиме каждое устройство создает одну точку MEP, связанную с виртуальным портом OAM без физического уровня (NULL PHY). MEP-ID для этой точки MEP имеет значение 0 (см. разъяснение ниже).

MEP-ID по умолчанию является 2-октетным полем. Оно не применяется в линии (проводе) кроме случаев использования CCM. Важно иметь метод автоматического выведения MEP-ID для базового режима без участия пользователя. IP-адрес не подходит для этого, поскольку поле MEP-ID имеет меньший размер. Для базового режима работы по умолчанию выбрано значение MEP-ID = 0.

Пакеты CCM используют MEP-ID в поле данных (payload). CCM недопустимо применять в базовом режиме, поэтому CCM должны быть запрещены в MA для Base Mode.

Если CCM требуется, пользователи должны настроить отдельную MA и присвоить уникальные идентификаторы соответствующим MEP.

CFM [IEEE802.1Q] определяет MEP-ID как целое число без знака со значением от 1 до 8191. В этом документе предлагается расширить диапазон значений до 0 – 65535. Значение 0 резервируется для MEP-ID в базовом режиме работы и его недопустимо применять в других случаях.

6.3. Ассоциация обслуживания (MA)

Идентификаторы MA (MA-ID) [IEEE802.1Q] имеют гибкий формат и включают две части – имя MD и краткое имя MA. В базовом режиме работы значением имени MD должна быть строка символов “GenericBaseMode” (включая кавычки). Формат Short MA Name включает 2-октетный целочисленный формат (значение 3 в поле Short MA Format [IEEE802.1Q]) и имя Short MA со значением 65532 (0xFFFC).

7. Применимость модели YANG для OAM на основе соединений

Определенный здесь модуль ietf-connection-oriented-oam, обеспечивает независимую от технологии абстракцию основных конструкций OAM для ориентированных на соединения протоколов. Этот модуль можно расширить путем добавления зависимых от технологий деталей, например определяя новые узлы данных с зависящими от технологии функциями и параметрами в соответствующую точку базовой модели, чтобы получить ориентированную на соединения модель OAM для конкретной технологии.

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

7.1. Расширение базовой модели данных YANG для TRILL OAM

Модуль TRILL OAM YANG [TRILL-YANG-OAM] является дополнением ориентированного на соединения модуля OAM для настройки и RPC.

Кроме того, для модуля TRILL OAM YANG нужна также поддержка базового модуля TRILL ([TRILL-YANG]), поскольку они тесно связаны между собой.

Конфигурационные расширения для ориентированного на соединения модуля OAM включают расширение для настройки MD, типа технологии, настройки MA, Connectivity-Context, настройки MEP и ECMP. В расширении RPC команды проверки связности и обнаружения пути дополняются связанными с TRILL параметрами.

7.1.1. Расширение MD Configuration

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

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

7.1.1.1. Расширение Technology Type

В базовой модели не определен тип технологии TRILL. Поэтому требуется расширение для определения этого типа в модели TRILL OAM. Тип trill определен как элемент, дополняющий базовое определение technology-types в модели.

      identity trill{
       base co-oam:technology-types;
       description
        "trill type";
      }

7.1.2. Расширение MA Configuration

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

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

7.1.2.1. Расширение Connectivity-Context

В TRILL OAM примером контекста связности является 12-битовое значение VLAN ID или 24-битовое значение Fine-Grained Label. Ориентированная на соединения базовая модель включает заменитель для context-id. Это позволяет другим технологиям легко дополнить заменитель и включить связанное с технологией расширение. Приведенный ниже фрагмент показывает пример дополнения контекста связности путем включения VLAN ID или Fine-Grained Label.

      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:connectivity-context:
            +--:(connectivity-context-vlan)
            |  +--rw connectivity-context-vlan?   vlan
            +--:(connectivity-context-fgl)
               +--rw connectivity-context-fgl?    fgl

7.1.3. Расширение MEP Configuration

Определение конфигурации MEP в базовой модели уже поддерживает настройку интерфейса MEP с адресом MAC или IP. Кроме того, адрес MEP можно представить с помощью 2-октетного RBridge Nickname в TRILL OAM. Поэтому модель TRILL OAM дополняет конфигурацию MEP базовой модели дополнительной возможностью задания адреса.

   augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:mep-address:
            +--:( mep-address-trill)
            |  +--rw mep-address-trill?  tril-rb-nickname

В дополнение к этому на уровне MEP (т. е. третьем) узел данных MEP может быть дополнен расширением ECMP.

7.1.3.1. Расширение ECMP

Поскольку TRILL поддерживает ECMP при выборе пути, энтропия потока в TRILL определяется как 96-октетное поле в Layer-Independent OAM Management расширения модели LIME¹⁰ для TRILL OAM. Фрагмент дерева приведен ниже.

      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep:
               +--rw flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:domains/co-oam:domain
   /co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session:
               +--rw flow-entropy-trill?   flow-entropy-trill

7.1.4. Расширение RPC

В модели данных TRILL OAM YANG команды RPC для проверки связности и обнаружения пути предполагаются с учетом требований TRILL. Приведенный ниже фрагмент описывает расширение TRILL OAM RPC.

      augment /co-oam:continuity-check/co-oam:input:
            +--ro (out-of-band)?
            |  +--:(ipv4-address)
            |  |  +--ro ipv4-address?      inet:ipv4-address
            |  +--:(ipv6-address)
            |  |  +--ro ipv6-address?      inet:ipv6-address
            |  +--:(trill-nickname)
            |     +--ro trill-nickname?    tril-rb-nickname
            +--ro diagnostic-vlan?   boolean
      augment /co-oam:continuity-check/co-oam:input:
               +--ro flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:continuity-check/co-oam:output:
            +--ro upstream-rbridge?   tril-rb-nickname
            +--ro next-hop-rbridge*   tril-rb-nickname
      augment /co-oam:path-discovery/co-oam:input:
            +--ro (out-of-band)?
            |  +--:(ipv4-address)
            |  |  +--ro ipv4-address?      inet:ipv4-address
            |  +--:(ipv6-address)
            |  |  +--ro ipv6-address?      inet:ipv6-address
            |  +--:(trill-nickname)
            |     +--ro trill-nickname?    tril-rb-nickname
            +--ro diagnostic-vlan?   boolean
      augment /co-oam:path-discovery/co-oam:input:
               +--ro flow-entropy-trill?   flow-entropy-trill
      augment /co-oam:path-discovery/co-oam:output/co-oam:response:
            +--ro upstream-rbridge?   tril-rb-nickname
            +--ro next-hop-rbridge*   tril-rb-nickname

7.2. Расширение базовой модели YANG для MPLS-TP OAM

Модуль MPLS-TP OAM YANG может дополнять ориентированный на соединения модуль OAM некоторыми детялями, связанными с технологией. В [MPLS-TP-OAM-YANG] представлена модель данных YANG для MPLS-TP OAM.

Конфигурационные расширения базовой модели OAM включают расширение для настройки MD, тип и субтип технологии, расширения для настройки MA и MEP.

7.2.1. Расширение MD Configuration

Конфигурационные параметры уровня MD являются управляющей информацией, которая может наследоваться в модели MPLS-TP OAM с использованием значений базовой модели в качестве принятых по умолчанию. Например, в качестве имени домена может быть задано значение area-ID или номер автономной системы провайдера (ASN¹¹) [RFC6370] для случая MPLS-TP OAM. Кроме того, на уровне MD (т. е. корневом) узел данных домена может быть дополнен типом и субтипом технологии.

7.2.1.1. Расширение Technology Type

Тип технологии MPLS-TP не определен в базовой модели, поэтому требуется расширение для определения этого типа в модели MPLS-TP OAM. Тип mpls-tp определен как элемент, дополняющий базовое определение technology-types в модели.

       identity mpls-tp{
             base co-oam:technology-types;
             description
              "mpls-tp type";
            }

7.2.1.2. Расширение Technology Subtype

Поскольку в MPLS-TP применяются разные типы инкапсуляции (такие как IP/UDP и PW-ACH), в модели MPLS-TP OAM определен узел данных technology-sub-type для идентификации используемого типа инкапсуляции. С помощью этого узла определены субтипы для инкапсуляции IP/UDP и PW-ACH, а также могут быть определены другие субтипы. Приведенный ниже фрагмент показывает пример определения нескольких типов.

   identity technology-sub-type {
         description
         "Некоторые реализации могут применять другие типы 
          инкапсуляции (IP/UDP, PW-ACH и т. п.). Вместо
          задания отдельной модели для каждого типа определен
          субтип технологии для указания инкапсуляции. Этот
          тип указывается на уровне MA."; }

              identity technology-sub-type-udp {
                base technology-sub-type;
                description
                  "Субтип для инкапсуляции IP/UDP.";
              }

              identity technology-sub-type-ach {
                base technology-sub-type;
                description
                  "Субтип для инкапсуляции PW-ACH.";
              }
              }

         augment "/co-oam:domains/co-oam:domain"
               + "/co-oam:mas/co-oam:ma" {
                leaf technology-sub-type {
                  type identityref {
                    base technology-sub-type;
                  }
                }
              }

7.2.2. Расширение MA Configuration

Конфигурационные параметры уровня MA являются управляющей информацией, которая может наследоваться в модели MPLS-TP OAM с использованием значений базовой модели в качестве принятых по умолчанию. Примерами MA Name являются MPLS-TP LSP MEG_ID, MEG Section ID, MEG PW ID [RFC6370].

7.2.3. Расширение MEP Configuration

В MPLS-TP идентификатором MEP-ID служит значение метки с переменным размером в случае инкапсуляции G-ACH или 2-октетное целое число без знака при инкапсуляции IP/UDP. Одним из вариантов MEP-ID в MPLS-TP является LSP_MEP_ID [RFC6370]. В ориентированной на соединения базовой модели MEP-ID определен как узел choice/case, который может поддерживать значения int32 и такие же значения применяются в MPLS-TP. В дополнение к этому на уровне MEP (третий уровень) узел данных MEP может быть дополнен расширением для сессии или интерфейса.

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

Описанный здесь модуль YANG определяет схему для данных, которые предназначены для доступа с помощью протоколов сетевого управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищенный транспорт с обязательной поддержкой протокола SSH¹² [RFC6242]. Нижним уровнем RESTCONF служит HTTPS с обязательной поддержкой протокола TLS [RFC8446].

Модель управления доступом к конфигурации сети [RFC8341] обеспечивает способы ограничить доступ определенных пользователей NETCONF или RESTCONF предопределенным подмножеством операций и содержимого NETCONF или RESTCONF.

Множество узлов данных в модуле YANG доступны для чтения, создания и удаления (значение config true, принятое по умолчанию). Эти узлы могут считаться деликатными в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без соответствующей защиты может оказывать негативное влияние на работу сети. К таким узлам и субдеревьям относятся:

   /co-oam:domains/co-oam:domain/
   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma
   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep
   /co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session

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

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

Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688], куда внесены приведенные ниже данные.

     URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
     Registrant Contact: The IESG.
     XML: N/A; the requested URI is an XML namespace.

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

  name:         ietf-connection-oriented-oam
  namespace:    urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
  prefix:       co-oam
  reference:    RFC 8531

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

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

[IEEE802.1Q] IEEE, “IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks”, IEEE Std 802.1Q.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6370] Bocci, M., Swallow, G., and E. Gray, “MPLS Transport Profile (MPLS-TP) Identifiers”, RFC 6370, DOI 10.17487/RFC6370, September 2011, <https://www.rfc-editor.org/info/rfc6370>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

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

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

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

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

[G.800] “Unified functional architecture of transport networks”, ITU-T Recommendation G.800, 2016.

[G.8013] “OAM functions and mechanisms for Ethernet based networks”, ITU-T Recommendation G.8013/Y.1731, 2013.

[MEF-17] MEF Forum, “Service OAM Requirements & Framework – Phase 1”, MEF 17, April 2007.

[MPLS-TP-OAM-YANG] Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, “YANG Data Model for MPLS-TP Operations, Administration, and Maintenance (OAM)”, Work in Progress, draft-zhang-mpls-tp-yang-oam-05, October 2017.

[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, “Guidelines for the Use of the “OAM” Acronym in the IETF”, BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, “Routing Bridges (RBridges): Base Protocol Specification”, RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.

[RFC6371] Busi, I., Ed. and D. Allan, Ed., “Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks”, RFC 6371, DOI 10.17487/RFC6371, September 2011, <https://www.rfc-editor.org/info/rfc6371>.

[RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, “Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)”, RFC 6905, DOI 10.17487/RFC6905, March 2013, <https://www.rfc-editor.org/info/rfc6905>.

[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, “Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework”, RFC 7174, DOI 10.17487/RFC7174, May 2014, <https://www.rfc-editor.org/info/rfc7174>.

[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, “An Overview of Operations, Administration, and Maintenance (OAM) Tools”, RFC 7276, DOI 10.17487/RFC7276, June 2014, <https://www.rfc-editor.org/info/rfc7276>.

[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, “Transparent Interconnection of Lots of Links (TRILL): Fault Management”, RFC 7455, DOI 10.17487/RFC7455, March 2015, <https://www.rfc-editor.org/info/rfc7455>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8532] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, “Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications”, RFC 8532, DOI 10.17487/RFC8532, April 2019, <https://www.rfc-editor.org/info/rfc8532>.

[TRILL-YANG] Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H., and L. Xia, “TRILL YANG Data Model”, Work in Progress, draft-ietf-trill-yang-04, December 2015.

[TRILL-YANG-OAM] Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., and H. Weiguo, “YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)”, Work in Progress, draft-ietf-trill-yang-oam-05, March 2017.

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

Giles Heron предложил разработать модель данных YANG в качестве пути создания унифицированного набора OAM API и этот документ во многом вдохновлен этим преддложением. Alexander Clemm дал много ценных советов, комментариев и замечаний, которые помогли улучшить представленную здесь модель YANG.

Carlos Pignataro, David Ball, Mahesh Jethanandani, Benoit Claise, Ladislav Lhotka, Jens Guballa, Yuji Tochio, Gregory Mirsky, Huub van Helvoort, Tom Taylor, Dapeng Liu, Mishael Wexler и Adi Molkho внесли важный вклад в разработку этого документа.

Участники работы

Tissa Senevirathne

Consultant

Email: tsenevir@gmail.com

Norman Finn

CISCO Systems

510 McCarthy Blvd

Milpitas, CA 95035

United States of America

Email: nfinn@cisco.com

Samer Salam

CISCO Systems

595 Burrard St. Suite 2123

Vancouver, BC V7X 1J1

Canada

Email: ssalam@cisco.com

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

Deepak Kumar

CISCO Systems

510 McCarthy Blvd

Milpitas, CA 95035

United States of America

Email: dekumar@cisco.com

Qin Wu

Huawei

101 Software Avenue, Yuhua District

Nanjing, Jiangsu 210012

China

Email: bill.wu@huawei.com

Michael Wang

Huawei Technologies, Co., Ltd

101 Software Avenue, Yuhua District

Nanjing 210012

China

Email: wangzitao@huawei.com

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

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

nmalykh@protokols.ru

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

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4MPLS Transport Profile – транспортный профиль MPLS.

5Virtual eXtensible Local Area Network.

6Network Management Datastore Architecture – архитектура хранилища данных конфигурации сети.

7Continuity Check Message.

8Remote Defect Indication – индикация удаленного дефекта.

9Connectivity Verification.

10Multi-Layer Environment – многоуровневое расширение.

11Autonomous System Number.

12Secure Shell — защищенная оболочка.

RFC 8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

1. Введение

2. Используемые соглашения

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

2.2. Термины

2.3. Диаграммы деревьев

3. Архитектура базовой модели YANG для OAM на базе соединений

4. Обзор ориентированной на соединения модели данных OAM YANG

4.1. Конфигурация MD

4.2. Конфигурация MA

4.3. Конфигурация MEP

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

4.5. Уведомления

4.6. Статистика мониторинга

4.7. Иерархия данных OAM

5. Модуль OAM YANG

6. Базовый режим

6.1. Адрес MEP

6.2. MEP ID для базового режима

6.3. Ассоциация обслуживания (MA)

7. Применимость модели YANG для OAM на основе соединений

7.1. Расширение базовой модели данных YANG для TRILL OAM

7.1.1. Расширение MD Configuration

7.1.1.1. Расширение Technology Type

7.1.2. Расширение MA Configuration

7.1.2.1. Расширение Connectivity-Context

7.1.3. Расширение MEP Configuration

7.1.3.1. Расширение ECMP

7.1.4. Расширение RPC

7.2. Расширение базовой модели YANG для MPLS-TP OAM

7.2.1. Расширение MD Configuration

7.2.1.1. Расширение Technology Type

7.2.1.2. Расширение Technology Subtype

7.2.2. Расширение MA Configuration

7.2.3. Расширение MEP Configuration

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

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

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

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

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

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

Участники работы

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

Рубрики

Свежие записи

Архивы

Мета