Internet Engineering Task Force (IETF) D. Kumar
Request for Comments: 8532 Cisco
Category: Standards Track M. Wang
ISSN: 2070-1721 Q. Wu, Ed.
Huawei
R. Rahman
S. Raghavan
Cisco
April 2019
Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
Базовая модель данных YANG для управления протоколами OAM без соединений
Аннотация
В этом документе представлена базовая модель данных YANG для управления протоколами OAM1, не использующими соединений (connectionless). Модель данных определена с использованием языка YANG, заданного в RFC 7950. Модель представляет независимую от технологии абстракцию важных конструкций OAM для протоколов OAM, не использующих соединений. Представленная здесь модель может быть расширена путём включения детялей для конкретных технологий.
Такой подход обеспечивает два важных преимущества – во-первых, единообразие для разных протоколов OAM, во-вторых, поддержка как вложенных рабочих процессов OAM (т. е. выполнение функций OAM на одном или разных уровнях через один унифицированный интерфейс), так и интерактивных процессов OAM (т. е. выполнение функций OAM на одном уровне через унифицированный интерфейс).
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8532.
Авторские права
Copyright (c) 2019. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в 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].
Утилиты Ping и Traceroute [RFC4443], а также обнаружение двухсторонней пересылки (Bidirectional Forwarding Detection или BFD) [RFC5880] являются общеизвестными инструментами проверки и отыскания точки отказа, особенно в сетях IP [RFC792]. За прошедшие годы в разных технологиях были разработаны похожие наборы для решения таких же задач.
Различные инструменты OAM могут поддерживать технологии, ориентированные на соединения, и технологии без соединений. В первом случае до передачи данных организуется соединение и после его создания для передачи фактических данных пользователя больше не требуется дополнительных управляющих сведений, таких как сигнализация или сведения об операциях и обслуживании. В технологиях без соединений данные обычно передаются конечными точками без предварительного согласования, но для идентификации получателя требуется управляющая информация (например, [G.800] и [RFC7276]). Модель данных YANG для протоколов OAM, использующих соединения, приведена в [RFC8531].
Этот документ определяет модель данных YANG [RFC7950] для протоколов OAM, не использующих соединений. Базовая модель данных YANG для OAM без соединений включает только данные конфигурации и состояния. Она может применяться в сочетании с моделью метода извлечения данных, описанной в [RFC8533] и содержащей процедуры извлечения, такие как RPC, или использоваться независимо от этой модели извлечения данных.
2. Используемые соглашения
Ниже указаны используемые в этом документе термины, которые определены в [RFC6241].
- client – клиент;
- configuration data – данные конфигурации;
- server – сервер;
- state data – данные состояния.
Ниже указаны используемые в этом документе термины, которые определены в [RFC7950].
- augment – дополнение;
- data model – модель данных;
- data node – узел данных.
Термины для описания моделей данных YANG представлены в [RFC7950].
2.1. Сокращения
BFD – Bidirectional Forwarding Detection [RFC5880] – обнаружение двухсторонней пересылки.
RPC – Remote Procedure Call [RFC1831] – удалённый вызов процедуры.
DSCP – Differentiated Services Code Point – код дифференцированного обслуживания.
VRF – Virtual Routing and Forwarding [RFC4382] – виртуальная маршрутизация и пересылка.
OWAMP – One-Way Active Measurement Protocol [RFC4656] – протокол односторонних активных измерений.
TWAMP – Two-Way Active Measurement Protocol [RFC5357] – протокол двухсторонних активных измерений.
AS – Autonomous System – автономная система.
LSP – Label Switched Path – путь с коммутацией по меткам.
TE – Traffic Engineering – огранизация (построение) трафика.
MPLS – Multiprotocol Label Switching – многопротокольная коммутация по меткам.
NI – Network Instance – сетевой интерфейс.
PTP – Precision Time Protocol [IEEE.1588v2] – протокол точного времени.
NTP – Network Time Protocol [RFC5905] – протокол сетевого времени.
2.2. Терминология
MAC
Media Access Control – управление доступом к среде.MAC address
Адрес интерфейса на канальном уровне.TP
Test Point – тестовая точка. Функциональный элемент, определённый на узле сеть, который может инициировать и/или реагировать на диагностические тесты OAM. Этот документ сосредоточен на функциональности TP в плоскости данных.RPC operation
Конкретная операция RPC.CC
Continuity Check – проверка непрерывности [RFC7276], служащая для проверки доступности адресата и называемая также проверкой доступности.2.3. Диаграммы деревьев
Диаграммы деревьев данных в этом документе используют нотацию [RFC8340].
3. Обзор модели OAM без соединений
Модель данных YANG для протоколов OAM без соединений разделена на два модуля:
-
ietf-lime-time-types содержит базовые определения, такие как связанные со временем типы данных;
-
ietf-connectionless-oam задаёт независимые от топологии абстракции основных конструкций OAM для протоколов OAM, не использующих соединений.
Модуль ietf-connectionless-oam дополняет путь /networks/network/node, заданный в модуле ietf-network [RFC8345] группировкой test-point-locations (параграф 3.5). Узлы сети в пути /networks/network/node служат для описания сетевых иерархий и инвентаризации узлов сети. В группировке test-point-locations местоположение каждой тестовой точки определяется листом tp-location-type, выбор которого ведёт к контейнеру, включающему test-point-locations. Каждый список test-point-locations включает группировку test-point-location-info, содержащую группировки:
-
tp-technology;
-
tp-tools;
-
connectionless-oam-tps.
Группировки tp-address и tp-address-ni не входят в группировку test-point-location-info. Чтобы обеспечить независимость от адресации и различный состав. В зависимости от выбора tp-location-type (определяется tp-address-ni) каждый контейнер отличается по своему составу test-point-locations, а test-point-location-info является общим аспектом всех test-point-locations.
Группировка tp-address-ni служит для описания соответствующего экземпляра сети, а tp-technology указывает технологические детали OAM. Группировка connectionless-oam-tps применяется для описания связи тестовой точки с другими тестовыми точками. Группировка tp-tools описывает поддерживаемые инструменты OAM.
На верхнем уровне модели имеется контейнер cc-oper-data для статистики сессии, а также задана группировка для общей статистики сессий, применимой лишь для проактивных сеансов OAM (см. 3.2. Инструменты).
3.1. Адрес TP
В протоколах OAM адресом TP может быть:
-
MAC-адрес [RFC6136] для TP канального уровня;
-
адрес IPv4 или IPv6 для TP уровня IP;
-
атрибут TP, указывающий TP связанную с функцией прикладного уровня;
-
Router-id для представления устройства или узла, обычно применяемый для идентификации узлов при маршрутизации и в других протоколах плоскости управления [RFC8294].
Для задания способов пересылки тестовых пакетов группировка tp-address должна быть связана с дополнительными параметрами, например DSCP для IP или Traffic Class [RFC5462] для MPLS. В базовой модели YANG для OAM без соединений эти параметры не задаются явно и пользователь модели может добавлять параметры в соответствии со своими требованиями.
3.2. Инструменты
Различные инструменты OAM могут применяться с проактивной активацией или по запросу. Проактивными являются действия OAM, выполняемые непрерывно для упреждающего информирования об отказах. Для проактивного метода OAM требуется сохраняющаяся конфигурация. Действия OAM по запросу инициируются ручным вмешательством для выполнения определённой диагностики в ограниченном интервале времени. Для таких методов нужна лишь временная конфигурация (например, [RFC7276] и [G.8013]). В OAM без соединений группировка session-type определяет тип активации для текущей сессии.
В OAM без соединений атрибуты инструментов служат для описания инструментария поиска и изоляции отказов. Кроме того, они могут служить условиями ограничений при расширении базовой модели для конкретной технологии OAM. Например, для настройки ICMP PING следует установить в листе ../coam:continuity-check значение true, а затем дополнить базовую модель LIME4 деталями, относящимися к ICMP PING.
3.3. Соседние тестовые точки OAM
С учётом многоуровневой архитектуры типичного сетевого стека набор связанных протоколов OAM также имеет многоуровневую структуру – каждый коммуникационный уровень в стеке может иметь свои протоколы OAM [RFC7276], которые могут быть связаны с определенным административным доменом. Управление этими связанными протоколами OAM требует соответствующих тестовых точек на узлах, доступных соответствующему домену управления. Поэтому данный сетевой интерфейс может на деле представлять несколько тестовых точек.
Каждая тестовая точка OAM может иметь список связанных с ней соседних тестовых точек на других уровнях стека протоколов для того же интерфейса. Это позволяет пользователям легко перемещаться между связанными соседними уровнями для эффективного поиска и устранения неполадок. В этой модели лист position задаёт относительное положение соседней тестовой точки, соответствующей текущей тестовой точке и это позволяет сопоставлять отказы в разных местах. Если имеется соседняя тестовая точка, размещённая впереди текущей, для листа position устанавливается значение -1. Если имеется соседняя тестовая точка, размещённая после текущей, лист position имеет значение 1. При отсутствии соседних тестовых точек впереди или позади текущей точки лист position имеет значение 0.
+-- oam-neighboring-tps* [index]
+-- index? uint16
+-- position? int8
+-- (tp-location)?
+--:(mac-address)
| +-- mac-address-location? yang:mac-address
+--:(ipv4-address)
| +-- ipv4-address-location? inet:ipv4-address
+--:(ipv6-address)
| +-- ipv6-address-location? inet:ipv6-address
+--:(as-number)
| +-- as-number-location? inet:as-number
+--:(router-id)
+-- router-id-location? rt:router-id
3.4. Сведения о местоположении TP
Это базовая группировка для сведений о местоположении тестовой точки (test-point-location-info), указывающая расположение TP с использованием группировок tp-technology, tp-tools и oam-neighboring-tps, показанных выше.
3.5. Местоположение TP
Это базовая группировка для местоположений TP. Лист tp-location-type служит для указания типа местоположения, например, ipv4-location-type, ipv6-location-type и т. п. Для каждого типа местоположения задан контейнер со списком адресов тестовых точек и ключом, сведениями о местоположении TP, определенными выше, и именем экземпляра сети (например, именем VRF), если оно требуется.
3.6. Данные обнаружения пути
Это базовая группировка для модели данных обнаружения пути, которые можно получить с помощью любого метода извлечения, включая операции RPC. Вывод метода обнаружения пути включает контейнеры src-test-point и dst-test-point, листья sequence-number и hop-cnt, различные типы статистики сессии и сведения, относящиеся к проверке и трассировке пути. Обнаружение пути включает данные, извлекаемые по этапам пересылки (per-hop), через список элементов path-trace-info-list, включающий группировку timestamp, ingress-intf-name, egress-intf-name и app-meta-data. Модель данных обнаружения пути сделана достаточно общей для использования различных методов извлечения данных и по этой причине ни одно поле не является обязательным. Набор методов извлечения задан в [RFC8533].
3.7. Данные проверки непрерывности
Это базовая группировка для модели данных проверки непрерывности, которые можно получить с помощью любого метода извлечения, включая операции RPC. Вывод Continuity Check включает контейнеры src-test-point и dst-test-point, листья sequence-number и hop-cnt, различные типы статистики сессии и сведения, относящиеся к проверке и трассировке пути. Модель данных проверки непрерывности сделана достаточно общей для использования различных методов извлечения данных и по этой причине ни одно поле не является обязательным. Набор методов извлечения задан в [RFC8533].
3.8. Иерархия данных OAM
Ниже приведена полная иерархия данных, связанных с моделью YANG OAM.
module: ietf-connectionless-oam
+--ro cc-session-statistics-data {continuity-check}?
+--ro cc-session-statistics* [type]
+--ro type identityref
+--ro cc-ipv4-sessions-statistics
| +--ro cc-session-statistics
| +--ro session-count? uint32
| +--ro session-up-count? uint32
| +--ro session-down-count? uint32
| +--ro session-admin-down-count? uint32
+--ro cc-ipv6-sessions-statistics
+--ro cc-session-statistics
+--ro session-count? uint32
+--ro session-up-count? uint32
+--ro session-down-count? uint32
+--ro session-admin-down-count? uint32
augment /nd:networks/nd:network/nd:node:
+--rw tp-location-type? identityref
+--rw ipv4-location-type
| +--rw test-point-ipv4-location-list
| +--rw test-point-locations* [ipv4-location ni]
| +--rw ipv4-location inet:ipv4-address
| +--rw ni routing-instance-ref
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root? <anydata>
| +--rw oam-neighboring-tps* [index]
| +--rw index uint16
| +--rw position? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(router-id)
| +--rw router-id-location? rt:router-id
+--rw ipv6-location-type
| +--rw test-point-ipv6-location-list
| +--rw test-point-locations* [ipv6-location ni]
| +--rw ipv6-location inet:ipv6-address
| +--rw ni routing-instance-ref
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root? <anydata>
| +--rw oam-neighboring-tps* [index]
| +--rw index uint16
| +--rw position? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(router-id)
| +--rw router-id-location? rt:router-id
+--rw mac-location-type
| +--rw test-point-mac-address-location-list
| +--rw test-point-locations* [mac-address-location]
| +--rw mac-address-location yang:mac-address
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root? <anydata>
| +--rw oam-neighboring-tps* [index]
| +--rw index uint16
| +--rw position? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(router-id)
| +--rw router-id-location? rt:router-id
+--rw group-as-number-location-type
| +--rw test-point-as-number-location-list
| +--rw test-point-locations* [as-number-location]
| +--rw as-number-location inet:as-number
| +--rw ni? routing-instance-ref
| +--rw (technology)?
| | +--:(technology-null)
| | +--rw tech-null? empty
| +--rw tp-tools
| | +--rw continuity-check boolean
| | +--rw path-discovery boolean
| +--rw root? <anydata>
| +--rw oam-neighboring-tps* [index]
| +--rw index uint16
| +--rw position? int8
| +--rw (tp-location)?
| +--:(mac-address)
| | +--rw mac-address-location? yang:mac-address
| +--:(ipv4-address)
| | +--rw ipv4-address-location? inet:ipv4-address
| +--:(ipv6-address)
| | +--rw ipv6-address-location? inet:ipv6-address
| +--:(as-number)
| | +--rw as-number-location? inet:as-number
| +--:(router-id)
| +--rw router-id-location? rt:router-id
+--rw group-router-id-location-type
+--rw test-point-system-info-location-list
+--rw test-point-locations* [router-id-location]
+--rw router-id-location rt:router-id
+--rw ni? routing-instance-ref
+--rw (technology)?
| +--:(technology-null)
| +--rw tech-null? empty
+--rw tp-tools
| +--rw continuity-check boolean
| +--rw path-discovery boolean
+--rw root? <anydata>
+--rw oam-neighboring-tps* [index]
+--rw index uint16
+--rw position? int8
+--rw (tp-location)?
+--:(mac-address)
| +--rw mac-address-location? yang:mac-address
+--:(ipv4-address)
| +--rw ipv4-address-location? inet:ipv4-address
+--:(ipv6-address)
| +--rw ipv6-address-location? inet:ipv6-address
+--:(as-number)
| +--rw as-number-location? inet:as-number
+--:(router-id)
+--rw router-id-location? rt:router-id
4. Модуль YANG LIME Time Types
<CODE BEGINS> file "ietf-lime-time-types@2019-04-16.yang"
module ietf-lime-time-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-lime-time-types";
prefix lime;
organization
"IETF LIME Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lime>
WG List: <mailto:lmap@ietf.org>
Editor: Qin Wu
<bill.wu@huawei.com>";
description
"Этот модуль содержит связанные с временем определения,
используемые моделями, написанными для среды LIME. Модуль
задаёт идентификаторы, а не элементы дерева схемы.
Авторские права (Copyright (c) 2019) принадлежат IETF Trust
и лицам, указанным как авторы кода. Все права защищены.
Распространение и использование модуля в исходном или двоичном
формате, с изменениями или без таковых разрешено в соответствии
с условиями лицензии Simplified BSD License, изложенными в
разделе 4.c документа IETF Trust's Legal Provisions для
документов IETF (http://trustee.ietf.org/license-info).
Эта версия модуля YANG является частью RFC 8533, где правовые
аспекты изложены более полно.";
revision 2019-04-16 {
description
"Initial version.";
reference
"RFC 8532: Generic YANG Data Model for the Management of
Operations, Administration, and Maintenance (OAM) Protocols
That Use Connectionless Communications";
}
/*** Набор базовых типов, связанных со временем ***/
/*** Идентификаторы единиц времени ***/
identity time-unit-type {
description
"Тип единицы времени.";
}
identity hours {
base time-unit-type;
description
"Время в часах.";
}
identity minutes {
base time-unit-type;
description
"Время в минутах.";
}
identity seconds {
base time-unit-type;
description
"Время в секундах.";
}
identity milliseconds {
base time-unit-type;
description
"Время в миллисекундах.";
}
identity microseconds {
base time-unit-type;
description
"Время в микросекундах.";
}
identity nanoseconds {
base time-unit-type;
description
"Время в наносекундах.";
}
/*** Идентификаторы формата метки времени ***/
identity timestamp-type {
description
"Базовый идентификатор для типов временных меток.";
}
identity truncated-ptp {
base timestamp-type;
description
"64-битовая краткая метка PTP.";
}
identity truncated-ntp {
base timestamp-type;
description
"32-битовая краткая метка NTP.";
}
identity ntp64 {
base timestamp-type;
description
"64-битовая метка NTP.";
}
identity icmp {
base timestamp-type;
description
"32-битовая метка ICMP.";
}
identity ptp80 {
base timestamp-type;
description
"80-битовая метка PTP.";
}
}
<CODE ENDS>
5. Модуль YANG для OAM без соединений
Этот модуль импортирует определение производных типов YANG (модуль ietf-yang-types) и определения связанных с Internet производных типов (модуль ietf-inet-types) из [RFC6991], модуль ietf-routing-types из [RFC8294], ietf-interfaces из [RFC8343], ietf-network из [RFC8345], ietf-network-instance из [RFC8529] и ietf-lime-time-types из раздела 4. Модуль ссылается на [IEEE.1588v1], [IEEE.1588v2], [RFC8029], и RFC, упомянутые в документе.
<CODE BEGINS> file "ietf-connectionless-oam@2019-04-16.yang"
module ietf-connectionless-oam {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-connectionless-oam";
prefix cl-oam;
import ietf-yang-schema-mount {
prefix yangmnt;
}
import ietf-network {
prefix nd;
}
import ietf-yang-types {
prefix yang;
}
import ietf-interfaces {
prefix if;
}
import ietf-inet-types {
prefix inet;
}
import ietf-network-instance {
prefix ni;
}
import ietf-routing-types {
prefix rt;
}
import ietf-lime-time-types {
prefix lime;
}
organization
"IETF LIME Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lime>
WG List: <mailto:lmap@ietf.org>
Deepak Kumar <dekumar@cisco.com>
Qin Wu <bill.wu@huawei.com>
Srihari Raghavan <srihari@cisco.com>
Michael Wang <wangzitao@huawei.com>
Reshad Rahman <rrahman@cisco.com>";
description
"Этот модуль YANG задаёт базовую конфигурацию, модель данных и
статистику для протоколов OAM без явных соединений, описанные
независимо от протокола. Предполагается, что каждый протокол
отображает соответствующие абстракции в свой естественный формат.
Протоколы могут расширять заданную здесь модель данных 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 8532, где правовые
аспекты изложены более полно.";
revision 2019-04-16 {
description
"Базовая модель для OAM.";
reference
"RFC 8532: Generic YANG Data Model for the Management of
Operations, Administration, and Maintenance (OAM) Protocols
That Use Connectionless Communications";
}
feature connectionless {
description
"Указывает, что решение OAM работает без соединений.";
}
feature continuity-check {
description
"Указывает, что сервер поддерживает выполнение команды OAM
Continuity Check и возвращает отклик. Серверы, не анонсирующие
это свойство, не поддерживают выполнение Continuity Check и
модель операции RPC для команд Continuity Check.";
}
feature path-discovery {
description
"Указывает, что сервер поддерживает выполнение команды OAM для
поиска пути и возвращает отклик. Серверы, не анонсирующие это
свойство, не поддерживают выполнение команд поиска пути и
модель операции RPC для команд обнаружения пути.";
}
feature ptp-long-format {
description
"Указывает длинный формат временных меток PTP.";
}
feature ntp-short-format {
description
"Указывает короткий формат временных меток NTP.";
}
feature icmp-timestamp {
description
"Указывает формат временных меток ICMP.";
}
identity traffic-type {
description
"Базовый идентификатор типа трафика (IPv4, IPv6 и т. п.).";
}
identity ipv4 {
base traffic-type;
description
"Идентификатор трафика IPv4.";
}
identity ipv6 {
base traffic-type;
description
"Идентификатор трафика IPv6.";
}
identity address-attribute-types {
description
"Базовый идентификатор типа атрибута адреса -
Generic IPv4/IPv6 Prefix, BGP Labeled IPv4/IPv6 Prefix,
Tunnel ID, PW ID, VPLS VE ID и т. п. (см. RFC 8029).";
}
typedef address-attribute-type {
type identityref {
base address-attribute-types;
}
description
"Тип атрибута целевого адреса.";
}
typedef percentage {
type decimal64 {
fraction-digits 5;
range "0..100";
}
description
"Процент.";
}
typedef routing-instance-ref {
type leafref {
path "/ni:network-instances/ni:network-instance/ni:name";
}
description
"Тип для листьев, указывающих конфигурацию экземпляра
маршрутизации.";
}
grouping cc-session-statistics {
description
"Группировка для статистики сессии.";
container cc-session-statistics {
description
"CC session counters.";
leaf session-count {
type uint32;
default "0";
description
"Число сессий Continuity Check. Значение 0 указывает, что
счётчик сессий не передан.";
}
leaf session-up-count {
type uint32;
default "0";
description
"Число активных сессий. Значение 0 указывает, что
счётчик сессий не передан.";
}
leaf session-down-count {
type uint32;
default "0";
description
"Число неактивных (down) сессий. Значение 0 указывает, что
счётчик сессий не передан.";
}
leaf session-admin-down-count {
type uint32;
default "0";
description
"Число сессий, отключённых администратором (admin-down).
Значение 0 указывает, что счётчик сессий не передан.";
}
}
}
grouping session-packet-statistics {
description
"Группировка для статистики по пакетам сессии.";
container session-packet-statistics {
description
"Статистика по пакетам сессии.";
leaf rx-packet-count {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число полученных пакетов OAM. Значение устанавливается
в 0 при создании сессии и монотонно увеличивается до
максимума 2^32-1 (4294967295), где оно снова переходит в 0.";
}
leaf tx-packet-count {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число переданных пакетов OAM. Значение устанавливается
в 0 при создании сессии и монотонно увеличивается до
максимума 2^32-1 (4294967295), где оно снова переходит в 0.";
}
leaf rx-bad-packet {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число полученных некорректных пакетов OAM. При создании
сессии устанавливается 0, затем значение монотонно растёт до
максимума 2^32-1 (4294967295), где оно снова переходит в 0.";
}
leaf tx-packet-failed {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число пакетов OAM, которые не удалось передать. При
создании сессии устанавливается 0, затем значение монотонно
растёт до 2^32-1 (4294967295), где оно снова переходит в 0.";
}
}
}
grouping cc-per-session-statistics {
description
"Группировка для статистики по сессиям.";
container cc-per-session-statistics {
description
"Статистика на сессию.";
leaf create-time {
type yang:date-and-time;
description
"Дата и время создания сессии.";
}
leaf last-down-time {
type yang:date-and-time;
description
"Дата и время последнего отключения (down) сессии.";
}
leaf last-up-time {
type yang:date-and-time;
description
"Дата и время последней активации (up) сессии.";
}
leaf down-count {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число отключённых (down) сессий Continuity Check. При
создании устанавливается 0, затем значение монотонно
растёт до 2^32-1 (4294967295), где оно снова переходит в 0.";
}
leaf admin-down-count {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число сессий Continuity Check, отключённых
администратором (admin-down). При создании устанавливается
0, затем значение монотонно растёт до 2^32-1 (4294967295),
где оно снова переходит в 0.";
}
uses session-packet-statistics;
}
}
grouping session-error-statistics {
description
"Группировка для статистики ошибок по сессиям.";
container session-error-statistics {
description
"Статистика ошибок на сессию.";
leaf packet-loss-count {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число отбрасываний принятых пакетов. При создании
сессии устанавливается 0, затем значение монотонно растёт до
2^32-1 (4294967295), где оно снова переходит в 0.";
}
leaf loss-ratio {
type percentage;
description
"Доля потерянных пакетов в процентах от числа переданных.";
}
leaf packet-reorder-count {
type uint32 {
range "0..4294967295";
}
default "0";
description
"Общее число переупорядочений пакетов. При создании сессии
устанавливается 0, затем значение монотонно растёт до
2^32-1 (4294967295), где оно снова переходит в 0.";
}
leaf packets-out-of-seq-count {
type uint32 {
range "0..4294967295";
}
description
"Общее число пакетов принятых с нарушением порядка. При
создании сессии устанавливается 0, затем значение монотонно
растёт до 2^32-1 (4294967295) и снова переходит в 0.";
}
leaf packets-dup-count {
type uint32 {
range "0..4294967295";
}
description
"Общее число принятых дубликатов пакетов. При создании
сессии устанавливается 0, затем значение монотонно
растёт до 2^32-1 (4294967295) и снова переходит в 0.";
}
}
}
grouping session-delay-statistics {
description
"Группировка для статистики задержек по сессиям.";
container session-delay-statistics {
description
"Сводные сведения о задержках для сессии. По умолчанию для
измерения применяется односторонний протокол (например, OWAMP).
Если используется двухсторонний протокол (например, TWAMP), это
указывается с помощью protocol-id, заданного в операции RPC
для метода извлечения в OAM без соединения (RFC 8533), т. е.
устанавливается protocol-id как OWAMP. Отметим, что для
задержки задан лишь один протокол измерения из соображений
функциональной совместимости.";
leaf time-unit-value {
type identityref {
base lime:time-unit-type;
}
default "lime:milliseconds";
description
"Единица времени - s, ms, ns, и т. п.";
}
leaf min-delay-value {
type uint32;
description
"Минимальная наблюдавшаяся задержка.";
}
leaf max-delay-value {
type uint32;
description
"Максимальная наблюдавшаяся задержка.";
}
leaf average-delay-value {
type uint32;
description
"Средняя задержка.";
}
}
}
grouping session-jitter-statistics {
description
"Группировка для статистики вариаций задержки по сессиям.";
container session-jitter-statistics {
description
"Сводные сведения о вариациях задержки для сессии. По умолчанию
вариации измеряются с помощью IPDV в соответствии с RFC 3393.
Если применяется иной метод (например, Packet Delay Variation
из ITU-T Recommendation Y.1540), его можно указать с помощью
protocol-id-meta-data о операции RPC методов извлечения для
OAM без соединений (RFC 8533). Отметим, что для вариаций
задержки задан лишь один протокол измерения из соображений
функциональной совместимости.";
leaf unit-value {
type identityref {
base lime:time-unit-type;
}
default "lime:milliseconds";
description
"Единица времени - s, ms, ns, и т. п.";
}
leaf min-jitter-value {
type uint32;
description
"Минимальные наблюдавшиеся вариации задержки.";
}
leaf max-jitter-value {
type uint32;
description
"Максимальные наблюдавшиеся вариации задержки.";
}
leaf average-jitter-value {
type uint32;
description
"Средние вариации задержки.";
}
}
}
grouping session-path-verification-statistics {
description
"Группировка для статистики проверки пути на сессию.";
container session-path-verification-statistics {
description
"Статистика проверки пути OAM на сессию.";
leaf verified-count {
type uint32 {
range "0..4294967295";
}
description
"Общее число пакетов, прошедших по предусмотренному пути.
Исходно устанавливается 0, затем значение монотонно растёт
до 2^32-1 (4294967295), где оно снова переходит в 0.";
}
leaf failed-count {
type uint32 {
range "0..4294967295";
}
description
"Общее число пакетов, прошедших по непредусмотренному пути.
Исходно устанавливается 0, затем значение монотонно растёт
до 2^32-1 (4294967295), где оно снова переходит в 0.";
}
}
}
grouping session-type {
description
"Указывает тип активации при создании сессии.";
leaf session-type {
type enumeration {
enum proactive {
description
"Текущая сессия является проактивной.";
}
enum on-demand {
description
"Текущая сессия создана по запросу.";
}
}
default "on-demand";
description
"Указывает тип активации при создании сессии.";
}
}
identity tp-address-technology-type {
description
"Тип адреса тестовой точки.";
}
identity mac-address-type {
base tp-address-technology-type;
description
"Адрес типа MAC.";
}
identity ipv4-address-type {
base tp-address-technology-type;
description
"Адрес типа IPv4.";
}
identity ipv6-address-type {
base tp-address-technology-type;
description
"Адрес типа IPv6.";
}
identity tp-attribute-type {
base tp-address-technology-type;
description
"Тип атрибута тестовой точки.";
}
identity router-id-address-type {
base tp-address-technology-type;
description
"Тип адреса System ID.";
}
identity as-number-address-type {
base tp-address-technology-type;
description
"Адрес типа номер AS.";
}
identity route-distinguisher-address-type {
base tp-address-technology-type;
description
"Адрес типа Route Distinguisher.";
}
grouping tp-address {
leaf tp-location-type {
type identityref {
base tp-address-technology-type;
}
mandatory true;
description
"Тип адреса тестовой точки.";
}
container mac-address {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:mac-address-type')" {
description
"Адрес типа MAC.";
}
leaf mac-address {
type yang:mac-address;
mandatory true;
description
"MAC-адрес.";
}
description
"Указание TP по MAC-адресу.";
}
container ipv4-address {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:ipv4-address-type')" {
description
"Адрес типа IPv4.";
}
leaf ipv4-address {
type inet:ipv4-address;
mandatory true;
description
"Адрес IPv4.";
}
description
"Указание TP по IP-адресу.";
}
container ipv6-address {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:ipv6-address-type')" {
description
"Адрес типа IPv6.";
}
leaf ipv6-address {
type inet:ipv6-address;
mandatory true;
description
"Адрес IPv6.";
}
description
"Указание TP по адресу IPv6.";
}
container tp-attribute {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:tp-attribute-type')" {
description
"Тип атрибута тестовой точки.";
}
leaf tp-attribute-type {
type address-attribute-type;
description
"Тип тестовой точки.";
}
choice tp-attribute-value {
description
"Значение тестовой точки.";
case ip-prefix {
leaf ip-prefix {
type inet:ip-prefix;
description
"Базовый префикс IPv4/IPv6. См. параграфы 3.2.13 и
3.2.14 в RFC 8029.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
}
case bgp {
leaf bgp {
type inet:ip-prefix;
description
"Префикс IPv4/IPv6 с меткой BGP. См. параграфы
3.2.11 и 3.2.12 в RFC 8029.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
}
case tunnel {
leaf tunnel-interface {
type uint32;
description
"Базовый идентификатор туннеля IPv4/IPv6. См.
параграфы 3.2.3 и 3.2.4 в RFC 8029.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures.";
}
}
case pw {
leaf remote-pe-address {
type inet:ip-address;
description
"Адрес удалённого PE. См. параграф 3.2.8 в RFC 8029.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
leaf pw-id {
type uint32;
description
"Ненулевой 32-битовый Pseudowire ID. См. параграфы
3.2.8 и 3.2.9 в RFC 8029.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
}
case vpls {
leaf route-distinguisher {
type rt:route-distinguisher;
description
"Route Distinguisher - 8-октетный идентификатор,
служащий для различения сведений о разных
L2VPN, анонсируемых узлом.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
leaf sender-ve-id {
type uint16;
description
"2-октетный идентификатор VE ID отправителя.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
leaf receiver-ve-id {
type uint16;
description
"2-октетный идентификатор VE ID получателя.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
}
case mpls-mldp {
choice root-address {
description
"Выбор корневого адреса.";
case ip-address {
leaf source-address {
type inet:ip-address;
description
"Адрес IP.";
}
leaf group-ip-address {
type inet:ip-address;
description
"IP-адрес группы.";
}
}
case vpn {
leaf as-number {
type inet:as-number;
description
"Номер AS, указывающий автономную систему.";
}
}
case global-id {
leaf lsp-id {
type string;
description
"LSP ID - идентификатор LSP в сети MPLS.";
reference
"RFC 8029: Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures";
}
}
}
}
}
description
"Контейнер атрибутов тестовой точки.";
}
container system-info {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:router-id-address-type')" {
description
"Тип адреса System ID.";
}
leaf router-id {
type rt:router-id;
description
"Router ID этого узла.";
}
description
"Контейнер Router ID.";
}
description
"Адрес TP.";
}
grouping tp-address-ni {
description
"Адрес тестовой точки с VRF.";
leaf ni {
type routing-instance-ref;
description
"Лист ni служит для описания разделения виртуальных ресурсов,
которое может присутствовать в сетевом устройстве. Примером
может служить широко используемый 'экземпляр VRF'.";
}
uses tp-address;
}
grouping connectionless-oam-tps {
list oam-neighboring-tps {
key "index";
leaf index {
type uint16 {
range "0..65535";
}
description
"Индекс списка соседних тестовых точек выше и ниже в стеке
для интерфейса, связанного с текущей тестовой точкой.";
}
leaf position {
type int8 {
range "-1..1";
}
default "0";
description
"Положение соседней тестовой точки относительно текущей.
Значение 0 указывает тестовую точку на том же уровне, что и
текущая, -1 указывает точку ниже в стеке, +1 - точку выше.";
}
choice tp-location {
case mac-address {
leaf mac-address-location {
type yang:mac-address;
description
"MAC-адрес.";
}
description
"Указание TP по MAC-адресу.";
}
case ipv4-address {
leaf ipv4-address-location {
type inet:ipv4-address;
description
"Адрес IPv4.";
}
description
"Указание TP по адресу IP.";
}
case ipv6-address {
leaf ipv6-address-location {
type inet:ipv6-address;
description
"Адрес IPv6.";
}
description
"Указание TP по адресу IPv6.";
}
case as-number {
leaf as-number-location {
type inet:as-number;
description
"Местоположение по номеру AS.";
}
description
"Номер AS для point-to-multipoint OAM.";
}
case router-id {
leaf router-id-location {
type rt:router-id;
description
"Местоположение по System ID.";
}
description
"System ID.";
}
description
"Местоположение TP.";
}
description
"Список соседних тестовых точек на том же уровне, связанных с
текущей тестовой точкой. Для соседней точки после текущей
устанавливается позиция +1, для соседа перед текущей точкой -
-1, а при отсутствии соседних точек на этом уровне - 0.";
}
description
"Список соседних тестовых точек для OAM без соединений.";
}
grouping tp-technology {
choice technology {
default "technology-null";
case technology-null {
description
"Заглушка для случая, когда технология не нужна.";
leaf tech-null {
type empty;
description
"Технология не задана.";
}
}
description
"Выбор технологии.";
}
description
"Технология OAM.";
}
grouping tp-tools {
description
"Инструменты OAM в тестовой точке.";
container tp-tools {
leaf continuity-check {
type boolean;
mandatory true;
description
"Флаг поддержки функции Continuity Check.";
reference
"RFC 792: INTERNET CONTROL MESSAGE PROTOCOL
RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
RFC 5880: Bidirectional Forwarding Detection
RFC 5881: BFD for IPv4 and IPv6
RFC 5883: BFD for Multihop Paths
RFC 5884: BFD for MPLS Label Switched Paths
RFC 5885: BFD for PW VCCV
RFC 6450: Multicast Ping Protocol
RFC 8029: Detecting Multiprotocol Label Switched (MPLS)
Data-Plane Failures";
}
leaf path-discovery {
type boolean;
mandatory true;
description
"Флаг поддержки функции обнаружения пути.";
reference
"RFC 792: INTERNET CONTROL MESSAGE PROTOCOL
RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification
RFC 4884: Extended ICMP to Support Multi-Part Messages
RFC 5837: Extending ICMP for Interface and Next-Hop
Identification
RFC 8029: Detecting Multiprotocol Label Switched (MPLS)
Data-Plane Failures";
}
description
"Контейнер для инструментов OAM в тестовой точке.";
}
}
grouping test-point-location-info {
uses tp-technology;
uses tp-tools;
anydata root {
yangmnt:mount-point "root";
description
"Корень для моделей, поддерживаемых на тестовую точку.";
}
uses connectionless-oam-tps;
description
"Местоположение тестовой точки.";
}
grouping test-point-locations {
description
"Группа местоположений тестовых точек.";
leaf tp-location-type {
type identityref {
base tp-address-technology-type;
}
description
"Тип местоположения тестовой точки.";
}
container ipv4-location-type {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:ipv4-address-type')" {
description
"Тестовая точка указана адресом IPv4.";
}
container test-point-ipv4-location-list {
list test-point-locations {
key "ipv4-location ni";
leaf ipv4-location {
type inet:ipv4-address;
description
"Адрес IPv4.";
}
leaf ni {
type routing-instance-ref;
description
"Лист ni служит для описания экземпляра сети.";
}
uses test-point-location-info;
description
"Список местоположений тестовых точек.";
}
description
"Контейнер верхнего уровня для списка местоположений
тестовых точек.";
}
description
"Контейнер для местоположений по адресу IPv4.";
}
container ipv6-location-type {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:ipv6-address-type')" {
description
"Тестовая точка указана адресом IPv6.";
}
container test-point-ipv6-location-list {
list test-point-locations {
key "ipv6-location ni";
leaf ipv6-location {
type inet:ipv6-address;
description
"Адрес IPv6.";
}
leaf ni {
type routing-instance-ref;
description
"Лист ni служит для описания экземпляра сети.";
}
uses test-point-location-info;
description
"Список местоположений тестовых точек.";
}
description
"Контейнер верхнего уровня для списка местоположений
тестовых точек.";
}
description
"Контейнер для местоположений по адресу IPv6.";
}
container mac-location-type {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:mac-address-type')" {
description
"Тестовая точка указана адресом MAC.";
}
container test-point-mac-address-location-list {
list test-point-locations {
key "mac-address-location";
leaf mac-address-location {
type yang:mac-address;
description
"MAC-адрес.";
}
uses test-point-location-info;
description
"Список местоположений тестовых точек.";
}
description
"Контейнер верхнего уровня для списка местоположений
тестовых точек.";
}
description
"Контейнер для местоположений по адресу MAC.";
}
container group-as-number-location-type {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:as-number-address-type')" {
description
"Тестовая точка указана номером AS.";
}
container test-point-as-number-location-list {
list test-point-locations {
key "as-number-location";
leaf as-number-location {
type inet:as-number;
description
"Номер AS для point-to-multipoint OAM.";
}
leaf ni {
type routing-instance-ref;
description
"Лист ni служит для описания экземпляра сети.";
}
uses test-point-location-info;
description
"Список местоположений тестовых точек.";
}
description
"Контейнер верхнего уровня для списка местоположений
тестовых точек.";
}
description
"Контейнер для местоположений по номеру AS.";
}
container group-router-id-location-type {
when "derived-from-or-self(../tp-location-type,"
+ "'cl-oam:router-id-address-type')" {
description
"Тестовая точка указана номером System ID.";
}
container test-point-system-info-location-list {
list test-point-locations {
key "router-id-location";
leaf router-id-location {
type rt:router-id;
description
"System ID.";
}
leaf ni {
type routing-instance-ref;
description
"Лист ni служит для описания экземпляра сети.";
}
uses test-point-location-info;
description
"Список местоположений тестовых точек.";
}
description
"Контейнер верхнего уровня для списка местоположений
тестовых точек.";
}
description
"Контейнер для местоположений по System ID.";
}
}
augment "/nd:networks/nd:network/nd:node" {
description
"Дополняет путь /networks/network/node, заданный в модуле
ietf-network (RFC 8345), группировкой test-point-locations.";
uses test-point-locations;
}
grouping timestamp {
description
"Группировка для временных меток.";
leaf timestamp-type {
type identityref {
base lime:timestamp-type;
}
description
"Тип временной метки, например, Truncated PTP или NTP.";
}
container timestamp-64bit {
when "derived-from-or-self(../timestamp-type,"
+ "'lime:truncated-ptp')"
+ "or derived-from-or-self(../timestamp-type,"
+ "'lime:ntp64')" {
description
"Применяется лишь для усечённых меток PTP и 64-битовых NTP.";
}
leaf timestamp-sec {
type uint32;
description
"Абсолютная метка в секундах в соответствии с IEEE 1588v2 или
секунды из 64-битовой метки NTP.";
}
leaf timestamp-nanosec {
type uint32;
description
"Дробная часть в наносекундах в соответствии с IEEE 1588v2 или
дробная часть 64-битовой метки NTP.";
}
description
"Контейнер для 64-битовой временной метки. Метки NTP заданы в
RFC 5905, усечённые метки PTP - в IEEE 1588v1.";
reference
"RFC 5905: Network Time Protocol Version 4: Protocol and
Algorithms Specification
IEEE 1588v1: IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems Version 1";
}
container timestamp-80bit {
when "derived-from-or-self(../timestamp-type, 'lime:ptp80')" {
description
"Применяется лишь для 80-битовых меток PTP.";
}
if-feature "ptp-long-format";
leaf timestamp-sec {
type uint64 {
range "0..281474976710655";
}
description
"48-битовая метка в секундах в соответствии с IEEE 1588v2.";
}
leaf timestamp-nanosec {
type uint32;
description
"Дробная часть в наносекундах в соответствии с IEEE 1588v2.";
}
description
"Контейнер для 80-битовой метки времени.";
}
container ntp-timestamp-32bit {
when "derived-from-or-self(../timestamp-type,"
+ "'lime:truncated-ntp')" {
description
"Применимо лишь к коротким 32-битовым меткам NTP.";
}
if-feature "ntp-short-format";
leaf timestamp-sec {
type uint16;
description
"Метка в секундах в коротком формате NTP.";
}
leaf timestamp-nanosec {
type uint16;
description
"Дробная часть 16-битовой метки NTP.";
}
description
"Контейнер для 32-битовой метки времени RFC 5905.";
reference
"RFC 5905: Network Time Protocol Version 4: Protocol and
Algorithms Specification.";
}
container icmp-timestamp-32bit {
when "derived-from-or-self(../timestamp-type, 'lime:icmp')" {
description
"Применимо лишь к меткам времени ICMP.";
}
if-feature "icmp-timestamp";
leaf timestamp-millisec {
type uint32;
description
"Миллисекунды метки времени ICMP.";
}
description
"Контейнер для 32-битовой метки времени. Метки ICMP заданы в
RFC 792.";
}
}
grouping path-discovery-data {
description
"Вывод данных от узлов, связанных с обнаружением пути.";
container src-test-point {
description
"Исходная тестовая точка.";
uses tp-address-ni;
}
container dest-test-point {
description
"Целевая тестовая точка.";
uses tp-address-ni;
}
leaf sequence-number {
type uint64;
default "0";
description
"Порядковый номер в пакете данных, 0 указывает, что номер
не передаётся.";
}
leaf hop-cnt {
type uint8;
default "0";
description
"Число пересылок, 0 указывает, что это число не передаётся.";
}
uses session-packet-statistics;
uses session-error-statistics;
uses session-delay-statistics;
uses session-jitter-statistics;
container path-verification {
description
"Необязательные сведения, относящиеся к проверке пути.";
leaf flow-info {
type string;
description
"Сведения, укахывающие поток.";
}
uses session-path-verification-statistics;
}
container path-trace-info {
description
"Необязательные сведения поэтапной трассировки пути о тестовых
точках. Обычно указывают 1 элемент на интервал (hop), такой как
операцию RPC для обнаружения пути, но могут включаться и другие
сведения от методов извлечения данных.";
list path-trace-info-list {
key "index";
description
"Список сведений трассировки пути.";
leaf index {
type uint32;
description
"Индекс сведений трассировки.";
}
uses tp-address-ni;
uses timestamp;
leaf ingress-intf-name {
type if:interface-ref;
description
"Имя входного интерфейса.";
}
leaf egress-intf-name {
type if:interface-ref;
description
"Имя выходного интерфейса.";
}
leaf queue-depth {
type uint32;
description
"Длина очереди интерфейса, с которого пакет пересылается.
Это может быть текущее число буферов памяти, использованных
очередью, а пакет может занимать 1 или несколько таких
буферов.";
}
leaf transit-delay {
type uint32;
description
"Время, затраченное пакетом на прохождение через узел.";
}
leaf app-meta-data {
type uint64;
description
"Зависящие от приложения данные, добавленные узлом.";
}
}
}
}
grouping continuity-check-data {
description
"Вывод данных Continuity Check от узлов.";
container src-test-point {
description
"Исходная тестовая точка.";
uses tp-address-ni;
leaf egress-intf-name {
type if:interface-ref;
description
"Имя выходного интерфейса.";
}
}
container dest-test-point {
description
"Целевая тестовая точка.";
uses tp-address-ni;
leaf ingress-intf-name {
type if:interface-ref;
description
"Имя входного интерфейса.";
}
}
leaf sequence-number {
type uint64;
default "0";
description
"Порядковый номер в пакете данных, 0 указывает, что номер
не передаётся.";
}
leaf hop-cnt {
type uint8;
default "0";
description
"Число пересылок, 0 указывает, что это число не передаётся.";
}
uses session-packet-statistics;
uses session-error-statistics;
uses session-delay-statistics;
uses session-jitter-statistics;
}
container cc-session-statistics-data {
if-feature "continuity-check";
config false;
list cc-session-statistics {
key "type";
leaf type {
type identityref {
base traffic-type;
}
description
"Тип трафика.";
}
container cc-ipv4-sessions-statistics {
when "../type = 'ipv4'" {
description
"Применимо только для трафика IPv4.";
}
description
"CC ipv4 sessions.";
uses cc-session-statistics;
}
container cc-ipv6-sessions-statistics {
when "../type = 'ipv6'" {
description
"Применимо только для трафика IPv6.";
}
description
"Сессии IPv6 CC.";
uses cc-session-statistics;
}
description
"Список статистических данных сессии CC.";
}
description
"Рабочие сведения CC.";
}
}
<CODE ENDS>
6. Применимость модели
Заданный в этом документе модуль ietf-connectionless-oam обеспечивает независимую от технологии абстракцию основных конструкций OAM для протоколов OAM без организации соединений. Этот модуль можно расширить включением связанных с технологией деталей, например, узлов данных с зависимыми от технологии функциями параметрами, помещённых в подходящие места базовой модели, чтобы создать связанную с технологией модель OAM без соединений.
В этом разделе показана применимость модели данных YANG OAM для разных технологий OAM без соединений, например, BFD и LSP ping. Отметим, что фрагменты кода расширений приведены здесь лишь для иллюстрации. Полными расширениями моделей следует заниматься рабочим группам соответствующих протоколов.
6.1. Расширение BFD
RFC 7276 определяет BFD как ориентированный на соединения протокол. Он применяется для мониторинга протоколов без организации соединений в случае базового BFD для IP.
6.1.1. Метод дополнения
В последующих параграфах показано, как расширить модуль ietf-connectionless-oam для охвата технологии BFD. Для этого вводится набор расширений, таких как тип технологии и атрибуты тестовой точки.
Отметим, что модель данных YANG BFD стандартизована в [BFD-YANG]. Дополнение модуля ietf-connectionless-oam связанными с BFD деталями обеспечивает дополнительный подход с унифицированным представлением управляющих сведений в разных протоколах OAM. Связанные с BFD детали могут быть группировкой в модели BFD, что позволит избежать дублирования работы.
6.1.1.1. Расширение technology-type
В модуле ietf-connectionless-oam не задан тип технологии BFD, поэтому нужно расширение модуля. Ниже приведён фрагмент кода, добавляющий тип bfd в модуль ietf-connectionless-oam.
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations/coam:technology"
{
leaf bfd{
type string;
}
}
6.1.1.2. Расширение атрибутов тестовой точки
Для поддержки BFD модуль ietf-connectionless-oam можно расширить добавлением конкретных параметров в список test-point-locations и/или нового типа местоположения, такого как «BFD через MPLS TE» в узел выбора location-type.
6.1.1.2.1. Определение и вставка новых узлов в test-point-location
В модуле ietf-connectionless-oam задано несколько списков test-point-location в узле выбора location-type. Поэтому для вывода модели для неких технологий BFD (таких как IP single-hop, IP multihop и т. п.) нужно добавить узлы с конкретными данными BFD в соответствующий список test-point-locations. В этом параграфе используются некоторые группировки из [BFD-YANG]. Приведённый ниже код показывает, как можно расширить модуль ietf-connectionless-oam для поддержки BFD IP Single-Hop.
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations"
{
container session-cfg {
description "Конфигурация сессии BFD IP single-hop.";
list sessions {
key "interface dest-addr";
description "Список сессий IP single-hop";
leaf interface {
type if:interface-ref;
description
"Интерфейс, на котором работает сессия BFD.";
}
leaf dest-addr {
type inet:ip-address;
description "IP-адрес партнёра";
}
uses bfd:bfd-grouping-common-cfg-parms;
uses bfd:bfd-grouping-echo-cfg-parms;
}
}
}
Похожие дополнения можно сделать для других технологий BFD, таких как BFD IP Multihop, BFD over MPLS и т. п.
6.1.1.2.2. Добавление вариантов location-type
Если в модуле ietf-connectionless-oam нет варианта location-type, подходящего для расширения, можно добавить новый вариант, поместив его в узел выбора location-type. Это обеспечивает гибкость и пользователь модуля может добавить location-type для поддержки других типов тестовых точек, отсутствующих в модуле ietf-connectionless-oam. В этом параграфе приведён пример добавления location-type для поддержки BFD over MPLS-TE с использованием группировок из модуля, заданного в [BFD-YANG].
augment "/nd:networks/nd:network/nd:node/coam:location-type"{
case te-location{
list test-point-location-list{
key "tunnel-name";
leaf tunnel-name{
type leafref{
path "/te:te/te:tunnels/te:tunnel/te:name";
}
description
"Указание экземпляра TE.";
}
uses bfd:bfd-grouping-common-cfg-parms;
uses bfd-mpls:bfd-encap-cfg;
}
}
}
Похожие дополнения возможны для поддержки других технологий BFD, таких как BFD через LAG и т. п.
6.1.2. Монтирование схемы
Ещё одним методом является использование механизма монтирования схемы из [RFC8528] в модуле ietf-connectionless-oam. В списке test-point-locations задаётся атрибут root, создающий точку монтирования для моделей, которые будут добавляться в test-point-locations. Таким способом модуль ietf-connectionless-oam может предоставить в иерархии узлов место, куда можно присоединить другие модели данных YANG OAM без специального расширения модуля YANG ietf-connectionless-oam. Отметим ограничение метода монтирования схемы, связанное с невозможностью указывать определённые модули, которые нужно примонтировать. Ниже приведён фрагмент кода с определением атрибута root.
anydata root {
yangmnt:mount-point root;
description
"Корень для моделей, поддерживаемых тестовой точкой.";
}
В следующем параграфе показано, как модуль ietf-connectionless-oam может применять монтирование схемы для поддержки технологии BFD.
6.1.2.1. Модули BFD, заполняемые в примонтированных схемах
Для поддержки технологий BFD ietf-bfd-ip-sh и ietf-bfd-ip-mh модули YANG можно заполнить в контейнере schema-mounts.
<schema-mounts
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<mount-point>
<module> ietf-connectionless-oam </module>
<name>root</name>
<use-schema>
<name>root</name>
</use-schema>
</mount-point>
<schema>
<name>root</name>
<module>
<name>ietf-bfd-ip-sh </name>
<revision>2016-07-04</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh
</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>ietf-bfd-ip-mh</name>
<revision> 2016-07-04</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh
</namespace>
<conformance-type>implement</conformance-type>
</module>
</schema>
</schema-mounts>
Модуль ietf-connectionless-oam может иметь вид
<ietf-connectionless-oam
uri="urn:ietf:params:xml:ns:yang:ietf-connectionless-oam">
...
<test-point-locations>
<ipv4-location>192.0.2.1</ipv4-location>
...
<root>
<ietf-bfd-ip-sh uri="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
<ip-sh>
foo
...
</ip-sh>
</ietf-bfd-ip-sh>
<ietf-bfd-ip-mh uri="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh">
<ip-mh>
foo
...
</ip-mh>
</ietf-bfd-ip-mh>
</root>
</test-point-locations>
</ietf-connectionless-oam>
6.2. Расширение LSP Ping
6.2.1. Метод дополнения
В следующих параграфах показано, как можно расширить модуль ietf-connectionless-oam для поддержки технологии LSP ping. Для этого задан набор расширений, таких как technology-type и attributes для тестовой точки.
Модель данных YANG LSP Ping задана в [LSP-PING-YANG]. Как и для BFD, можно дополнить модель ietf-connectionless-oam деталями, относящимися к LSP Ping для однородного представления разных технологий. Эти детали могут быть группировкой, заданной в модели LSP Ping, для предотвращение дублирования работы.
6.2.1.1. Расширение technology-type
Тип технологии LSP Ping не задан в модуле ietf-connectionless-oam, поэтому для него нужно расширение модуля. Ниже приведён фрагмент кода, добавляющий в ietf-connectionless-oam тип lsp-ping.
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations/coam:technology"
{
leaf lsp-ping{
type string;
}
}
6.2.1.2. Расширение атрибутов тестовой точки
Для поддержки LSP Ping можно расширить модуль ietf-connectionless-oam, определив параметры, связанные с LSP Ping, и поместив их в список test-point-locations. Можно использовать атрибуты или группировки из [LSP-PING-YANG], как показано ниже. Приведённый фрагмент кода показывает дополнение списка test-point-locations атрибутами LSP Ping.
augment "/nd:networks/nd:network/nd:node/"
+"coam:location-type/coam:ipv4-location-type"
+"/coam:test-point-ipv4-location-list/"
+"coam:test-point-locations"
{
list lsp-ping {
key "lsp-ping-name";
leaf lsp-ping-name {
type string {
length "1..31";
}
mandatory "true";
description "Имя теста LSP Ping.";
...
}
6.2.2. Монтирование схемы
Ещё одним методом является использование механизма монтирования схемы из [RFC8528] в модуле ietf-connectionless-oam. В списке test-point-locations задаётся атрибут root, создающий точку монтирования для моделей, которые будут добавляться в test-point-locations. Таким способом модуль ietf-connectionless-oam может предоставить в иерархии узлов место, куда можно присоединить другие модели данных YANG OAM без специального расширения модуля YANG ietf-connectionless-oam. Отметим ограничение метода монтирования схемы, связанное с невозможностью указывать определённые модули, которые нужно примонтировать. Ниже приведён фрагмент кода с определением атрибута root.
anydata root {
yangmnt:mount-point root;
description
"Корень для моделей, поддерживаемых тестовой точкой.";
}
В следующем параграфе показано, как модуль ietf-connectionless-oam может применять монтирование схемы для поддержки технологии LSP Ping.
6.2.2.1. Методы LSP Ping, заполняемые в примонтированных схемах
Для поддержки технологии LSP Ping модуль YANG ietf-lsp-ping [LSP-PING-YANG] можно заполнить в контейнере schema-mounts.
<schema-mounts
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<mount-point>
<module> ietf-connectionless-oam </module>
<name>root</name>
<use-schema>
<name>root</name>
</use-schema>
</mount-point>
<schema>
<name>root</name>
<module>
<name>ietf-lsp-ping </name>
<revision>2016-03-18</revision>
<namespace>
urn:ietf:params:xml:ns:yang: ietf-lsp-ping
</namespace>
<conformance-type>implement</conformance-type>
</module>
</schema>
</schema-mounts>
Модуль ietf-connectionless-oam может иметь вид
<ietf-connectionless-oam
uri="urn:ietf:params:xml:ns:yang:ietf-connectionless-oam">
...
<test-point-locations>
<ipv4-location> 192.0.2.1</ipv4-location>
...
<root>
<ietf-lsp-ping uri="urn:ietf:params:xml:ns:yang:ietf-lsp-ping">
<lsp-pings>
foo
...
</lsp-pings>
</ietf-lsp-ping>
</root>
</test-point-locations>
</ietf-connectionless-oam>
7. Вопросы безопасности
Описанный здесь модуль YANG определяет схему для данных, которые предназначены для доступа с помощью протоколов сетевого управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищённый транспорт с обязательной поддержкой протокола SSH5 [RFC6242]. Нижним уровнем RESTCONF служит HTTPS с обязательной поддержкой протокола TLS [RFC8446].
Модель управления доступом к конфигурации сети [RFC8341] обеспечивает способы ограничить доступ определенных пользователей NETCONF или RESTCONF предопределенным подмножеством операций и содержимого NETCONF или RESTCONF.
Множество узлов данных в модуле YANG доступны для чтения, создания и удаления (значение config true, принятое по умолчанию). Эти узлы могут считаться деликатными в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без соответствующей защиты может оказывать негативное влияние на работу сети. К таким узлам и ветвям относятся:
/nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:ipv4-location-type/cl-oam:test-point-ipv4-location-list/cl-oam:test-point-locations/ /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:ipv6-location-type/cl-oam:test-point-ipv6-location-list/cl-oam:test-point-locations/ /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:mac-location-type/cl-oam:test-point-mac-address-location-list/cl-oam:test-point-locations/ /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:group-as-number-location-type/cl-oam:test-point-as-number-location-list/cl-oam:test-point-locations/ /nd:networks/nd:network/nd:node/cl-oam:location-type/cl-oam:group-router-id-location-type/cl-oam:test-point-system-info-location-list/cl-oam:test-point-locations/
Несанкционированный доступ к любому из этих списков может отрицательно повлиять на систему управления OAM в плане сквозной обработки и координации OAM на базовых уровнях сети. Это может приводить к нестабильности конфигурации, некорректным отчётам и неверному представления механизмов OAM, служащих для управления сетью.
Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.
/coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-count/ /coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-up-count/ /coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-down-count/ /coam:cc-session-statistics-data/cl-oam:cc-ipv4-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-admin-down-count/ /coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-count/ /coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-up-count/ /coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-down-count//coam:cc-session-statistics-data/cl-oam:cc-ipv6-sessions-statistics/cl-oam:cc-session-statistics/cl-oam:session-admin-down-count/
8. Взаимодействие с IANA
Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688]
URI: urn:ietf:params:xml:ns:yang:ietf-lime-time-types
Registrant Contact: The IESG.
XML: N/A; запрошенный URI является пространством имён XML.
URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
Registrant Contact: The IESG.
XML: N/A; запрошенный URI является пространством имён XML.
Этот документ регистрирует два модуля YANG в реестре YANG Module Names [RFC6020].
Name: ietf-lime-time-types
Namespace: urn:ietf:params:xml:ns:yang:ietf-lime-time-types
Prefix: lime
Reference: RFC 8532
Name: ietf-connectionless-oam
Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam
Prefix: cl-oam
Reference: RFC 8532
9. Литература
9.1. Нормативные документы
[RFC792] Postel, J., “Internet Control Message Protocol”, RFC 792, September 1981.
[RFC1831] Srinivasan, R., “RPC: Remote Procedure Call Protocol Specification Version 2”, RFC 1831, DOI 10.17487/RFC1831, August 1995, <https://www.rfc-editor.org/info/rfc1831>.
[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC4382] Nadeau, T., Ed. and H. van der Linde, Ed., “MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base”, RFC 4382, DOI 10.17487/RFC4382, February 2006, <https://www.rfc-editor.org/info/rfc4382>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP)”, RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5880] Katz, D. and D. Ward, “Bidirectional Forwarding Detection (BFD)”, RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[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>.
[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, “Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures”, RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[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>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, “Common YANG Data Types for the Routing Area”, RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.
[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>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, “A YANG Data Model for Network Topologies”, RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.
[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>.
[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, “YANG Model for Network Instances”, RFC 8529, DOI 10.17487/RFC8529, March 2019, <https://www.rfc-editor.org/info/rfc8529>.
9.2. Дополнительная литература
[BFD-YANG] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, “YANG Data Model for Bidirectional Forwarding Detection (BFD)”, Work in Progress6, draft-ietf-bfd-yang-17, August 2018.
[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.
[IEEE.1588v1] “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 1”, IEEE Std 1588, 2002.
[IEEE.1588v2] “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2”, IEEE Std 1588, 2008.
[LSP-PING-YANG] Zheng, L., Zheng, G., Mirsky, G., Rahman, R., and F. Iqbal, “YANG Data Model for LSP-Ping”, Work in Progress, draft-zheng-mpls-lsp-ping-yang-cfg-10, January 2019.
[RFC5462] Andersson, L. and R. Asati, “Multiprotocol Label Switching (MPLS) Label Stack Entry: “EXP” Field Renamed to “Traffic Class” Field”, RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[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>.
[RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., “Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework”, RFC 6136, DOI 10.17487/RFC6136, March 2011, <https://www.rfc-editor.org/info/rfc6136>.
[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>.
[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>.
[RFC8528] Bjorklund, M. and L. Lhotka, “YANG Schema Mount”, RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/info/rfc8528>.
[RFC8531] Kumar, D., Wu, Q., and M. Wang, “Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols”, RFC 8531, DOI 10.17487/RFC8531, April 2019, <https://www.rfc-editor.org/info/rfc8531>.
[RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, ” A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications”, RFC 8533, DOI 10.17487/RFC8533, April 2019.
Благодарности
Авторы документа благодарны Elwyn Davies, Alia Atlas, Brian E. Carpenter, Greg Mirsky, Adam Roach, Alissa Cooper, Eric Rescorla, Ben Campbell, Benoit Claise, Kathleen Moriarty, Carlos Pignataro и другим людям за их предметные рецензии и комментарии, а также предложения по стабилизации и улучшению этого документа.
Адреса авторов
Deepak Kumar CISCO Systems 510 McCarthy Blvd Milpitas, CA 95035 United States of America Email: dekumar@cisco.com Michael Wang Huawei Technologies, Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China Email: wangzitao@huawei.com Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Reshad Rahman Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: rrahman@cisco.com Srihari Raghavan Cisco Systems Tril Infopark Sez, Ramanujan IT City Neville Block, 2nd floor, Old Mahabalipuram Road Chennai, Tamil Nadu 600113 India Email: srihari@cisco.comПеревод на русский язык
Николай Малых
1Operations, Administration, and Maintenance – эксплуатация, администрирование, обслуживание.
2Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
3Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.
4Layer Independent OAM Management in the Multi-Layer Environment – независимое от уровня управление OAM в многоуровневой среде.
5Secure Shell – защищенная оболочка.