Internet Engineering Task Force (IETF) J. Dong
Request for Comments: 8944 X. Wei
Category: Standards Track Q. Wu
ISSN: 2070-1721 Huawei
M. Boucadair
Orange
A. Liu
Tecent
November 2020
A YANG Data Model for Layer 2 Network Topologies
Модель YANG для сетевой топологии канального уровня
Аннотация
Этот документ определяет модель данных YANG для сетевой топологии канального уровня (L2). В частности, модель дополняет базовые модели сети и сетевой топологии атрибутами, относящимися к L2.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8944.
Авторские права
Авторские права (Copyright (c) 2020) принадлежат 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).
[RFC8345] определяет модели данных YANG [RFC6020] [RFC7950] абстрактной (базовой) сети и сетевой топологии, которые можно дополнить зависящими от технологии деталями для построения соответствующей технологии модели.
Этот документ определяет модель данных YANG для сетевых топологий канального уровня (L2) путем дополнения моделей данных базовой сети (параграф 6.1 в [RFC8345]) и базовой топологии (параграф 6.2 в [RFC8345]) относящимися к уровню L2 атрибутами. Пример представлен в приложении B.
Такая модель данных имеет много применений. Например, в контексте интерфейса в систему маршрутизации I2RS3 узлы сети могут использовать модель данных для фиксации своего представления о топологии сети в целом и раскрытия его контроллеру сети. Контроллер может использовать экземпляры данных топологии для сравнения и согласования со своим представлением о топологии сети. В дополнение к этому узлы сети могут сравнивать и согласовывать эти представления между собой самостоятельно или с помощью контроллера. Помимо элементов сети и самого контекста I2RS контроллер сети может применять модель данных для представления контролируемой им топологии внешним приложениям. Другие варианты применения модели данных рассмотрены в [I2RS-UR].
В документе применяются базовые типы YANG, определенные в [RFC6991], и принимается архитектура хранилища NMDA4 [RFC8342].
2. Терминология
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
Термины для описания модулей YANG определены в [RFC7950], значения символов, используемых в диаграммах деревьев, – в [RFC8340].
3. Модель топологии L2
Модуль YANG для сетевой топологии уровня L2 разработан в качестве базового для сетей L2 на основе разных технологий канального уровня. Модуль можно применять как для физических, так и для логических (виртуальных) топологий L2.
Связь модуля топологии L2 с модулями базовой сети и сетевой топологии показана на рисунке 1. Для представления топологии L2 модели базовой сети и сетевой топологии дополнены относящейся к L2 информацией, такой как идентификаторы, сущности (элементы, например, PBB5 [IEEE802.1ah], QinQ [IEEE802.1ad], VXLAN6 [RFC7348]), атрибуты и состояния сетей L2, узлы, каналы и точки завершения. Часть информации может быть собрана протоколом LLDP7 [IEEE802.1AB] или другим протоколом L2, а другая часть настроена в локальной конфигурации.
+---------------------+
| ietf-network |
+----------^----------+
|
|
+---------------------+
|ietf-network-topology|
+----------^----------+
|
|
+----------^----------+
| ietf-l2-topology |
+---------------------+
Рисунок 1. Структура модуля YANG.
Структура модуля YANG ietf-l2-topology в форме дерева представлена ниже.
module: ietf-l2-topology
augment /nw:networks/nw:network/nw:network-types:
+--rw l2-topology!
augment /nw:networks/nw:network:
+--rw l2-topology-attributes
+--rw name? string
+--rw flags* l2-flag-type
augment /nw:networks/nw:network/nw:node:
+--rw l2-node-attributes
+--rw name? string
+--rw flags* node-flag-type
+--rw bridge-id* string
+--rw management-address* inet:ip-address
+--rw management-mac? yang:mac-address
+--rw management-vlan? string
augment /nw:networks/nw:network/nt:link:
+--rw l2-link-attributes
+--rw name? string
+--rw flags* link-flag-type
+--rw rate? uint64
+--rw delay? uint32
+--rw auto-nego? boolean
+--rw duplex? duplex-mode
augment /nw:networks/nw:network/nw:node/nt:termination-point:
+--rw l2-termination-point-attributes
+--rw interface-name? string
+--rw mac-address? yang:mac-address
+--rw port-number* uint32
+--rw unnumbered-id* uint32
+--rw encapsulation-type? identityref
+--rw outer-tag? dot1q-types:vid-range-type {VLAN}?
+--rw outer-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--rw inner-tag? dot1q-types:vid-range-type {VLAN}?
+--rw inner-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--rw lag? boolean
+--rw member-link-tp*
-> /nw:networks/network/node/nt:termination-point/tp-id
+--rw vxlan {VXLAN}?
+--rw vni-id? vni
notifications:
+---n l2-node-event
| +--ro event-type? l2-network-event-type
| +--ro node-ref?
-> /nw:networks/network[nw:network-id=current()
/../network-ref]/node/node-id
| +--ro network-ref? -> /nw:networks/network/network-id
| +--ro l2-topology!
| +--ro l2-node-attributes
| +--ro name? string
| +--ro flags* node-flag-type
| +--ro bridge-id* uint64
| +--ro management-address* inet:ip-address
| +--ro management-mac? yang:mac-address
| +--ro management-vlan? string
+---n l2-link-event
| +--ro event-type? l2-network-event-type
| +--ro link-ref?
-> /nw:networks/network[nw:network-id=current()
/../network-ref]/nt:link/link-id
| +--ro network-ref? -> /nw:networks/network/network-id
| +--ro l2-topology!
| +--ro l2-link-attributes
| +--ro name? string
| +--ro flags* link-flag-type
| +--ro rate? uint64
| +--ro delay? uint32
| +--ro auto-nego? boolean
| +--ro duplex? duplex-mode
+---n l2-termination-point-event
+--ro event-type? l2-network-event-type
+--ro tp-ref?
-> /nw:networks/network[nw:network-id=current()
/../network-ref]/node[nw:node-id=current()
/../node-ref]/nt:termination-point/tp-id
+--ro node-ref?
-> /nw:networks/network[nw:network-id=current()
/../network-ref]/node/node-id
+--ro network-ref? -> /nw:networks/network/network-id
+--ro l2-topology!
+--ro l2-termination-point-attributes
+--ro interface-name? string
+--ro mac-address? yang:mac-address
+--ro port-number* uint32
+--ro unnumbered-id* uint32
+--ro encapsulation-type? identityref
+--ro outer-tag? dot1q-types:vid-range-type {VLAN}?
+--ro outer-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--ro inner-tag? dot1q-types:vid-range-type {VLAN}?
+--ro inner-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--ro lag? boolean
+--ro member-link-tp*
-> /nw:networks/network/node/nt:termination-point/tp-id
+--ro vxlan {VXLAN}?
+--ro vni-id? vni
Модуль YANG для топологии L2 дополняет модули ietf-network и ietf-network-topology.
-
Вводится новый тип l2-network-type, представляемый контейнером и помещаемый под контейнером network-types модуля ietf-network, определенного в параграфе 6.1 [RFC8345].
-
Введены дополнительные атрибуты сети в группировке l2-network-attributes, дополняющие список network модуля ietf-network. Атрибуты включают имя сети L2 и набор флагов. Каждый тип флагов представлен отдельной сущностью (объектом).
-
Вводятся дополнительные элементы (объекты) данных для узлов L2 путем дополнения списка node базового модуля ietf-network. Новые объекты включают идентификатор узла L2, адрес управления, MAC-адрес управления, VLAN для управления и набор флагов.
-
Вводятся дополнительные элементы (объекты) данных для точек завершения L2 путем дополнения списка termination-point модуля ietf-network-topology, определенного в параграфе 6.2 [RFC8345]. Новые объекты включают имя интерфейса, тип инкапсуляции, индикацию поддержки агрегирования (lag) и атрибуты, связанные с типом точки завершения L2.
-
Каналы в модуле ietf-network-topology дополняются набором параметров L2, позволяющим связать канал с именем, набором атрибутов канала L2 и флагами.
-
В модуле введены необязательные атрибуты L2, связанные с технологией, как свойства L2, поскольку такие атрибуты могут быть полезны для раскрытия вышележащим службам (приложениям). Отметим, что изучение или настройка таких расширенных атрибутов L2 выходят за рамки модуля YANG для топологии L2 и следует использовать для них дополнительные модули YANG (например, [TRILL-YANG]).
4. Модуль YANG для топологии L2
Этот модуль использует типы, определенные в [RFC6991], [RFC7224], [IEEE802.1Qcp] и [RFC8345], а также ссылается на [IEEE802.1Q-2014], [IEEE802.1ad], [RFC7348] и [RFC7727].
<CODE BEGINS> file "ietf-l2-topology@2020-11-15.yang"
module ietf-l2-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology";
prefix l2t;
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991:Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991:Common YANG Data Types";
}
import iana-if-type {
prefix ianaift;
reference
"RFC 7224: IANA Interface Type YANG Module";
}
import ieee802-dot1q-types {
prefix dot1q-types;
reference
"IEEE Std 802.1Qcp-2018: Bridges and Bridged
Networks - Amendment: YANG Data Model";
}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2rs>
WG List: <mailto:i2rs@ietf.org>
Editor: Jie Dong
<mailto:jie.dong@huawei.com>
Editor: Xiugang Wei
<mailto:weixiugang@huawei.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Editor: Anders Liu
<mailto:andersliu@tencent.com>";
description
"Этот модуль определяет базовую модель сетевой топологии L2.
Авторские права (Copyright (c) 2020) принадлежат IETF Trust
и лицам, указанным как авторы кода. Все права защищены.
Распространение и использование в исходной или двоичной форме
с изменениями или без таковых разрешено в соответствии с
упрощенной лицензией BSD, как указано в параграфе 4.c
документа IETF Trust Legal Provisions применительно к
документам IETF (https://trustee.ietf.org/license-info).
Данная версия модуля YANG является частью RFC 8944, где
правовые аспекты изложены более полно.";
revision 2020-11-15 {
description
"Исходный выпуск.";
reference
"RFC 8944: A YANG Data Model for Layer 2 Network Topologies";
}
feature VLAN {
description
"Включает поддержку VLAN в соответствии с IEEE 802.1Q.";
reference
"IEEE Std 802.1Q-2014: Bridges and Bridged Networks";
}
feature QinQ {
description
"Включает поддержку двойных тегов QinQ IEEE 802.1ad.";
reference
"IEEE Std 802.1ad: Provider Bridges";
}
feature VXLAN {
description
"Включает поддержку VXLAN в соответствии с RFC 7348.";
reference
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
}
identity flag-identity {
description
"базовый тип для флагов.";
}
identity eth-encapsulation-type {
base ianaift:iana-interface-type;
description
"Базовое отождествление, из которого выводятся конкретные
типы инкапсуляции Ethernet.";
reference
"RFC 7224: IANA Interface Type YANG Module";
}
identity ethernet {
base eth-encapsulation-type;
description
"Естественная инкапсуляция Ethernet.";
}
identity vlan {
base eth-encapsulation-type;
description
"Инкапсуляция VLAN.";
}
identity qinq {
base eth-encapsulation-type;
description
"Инкапсуляция QinQ.";
}
identity pbb {
base eth-encapsulation-type;
description
"Инкапсуляция PBB в соответствии с IEEE 802.1ah.";
}
identity trill {
base eth-encapsulation-type;
description
"Инкапсуляция TRILL.";
}
identity vpls {
base eth-encapsulation-type;
description
"Инкапсуляция интерфейса VPLS.";
}
identity vxlan {
base eth-encapsulation-type;
description
"Инкапсуляция VXLAN MAC в UDP.";
reference
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
}
typedef vni {
type uint32 {
range "0..16777215";
}
description
"Идентификатор сети или сегмента VXLAN, обеспечивающий
сосуществование до 16M сегментов VXLAN в одном
административном домене.
Использование значения 0 зависит от реализации.";
reference
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
}
typedef l2-flag-type {
type identityref {
base flag-identity;
}
description
"Базовый тип для флагов L2. Примером типа флага L2
является trill, представляющий топологию типа trill.";
}
typedef node-flag-type {
type identityref {
base flag-identity;
}
description
"Атрибуты флага узла. Примером может служить
физический узел.";
}
typedef link-flag-type {
type identityref {
base flag-identity;
}
description
"Атрибуты флага соединения. Одним из примеров служит
псевдопровод.";
}
typedef l2-network-event-type {
type enumeration {
enum addition {
value 0;
description
"Добавлен узел, канал или точка завершения L2.";
}
enum removal {
value 1;
description
"Удален узел, канал или точка завершения L2.";
}
enum update {
value 2;
description
"Изменен узел, канал или точка завершения L2.";
}
}
description
"Тип события сети L2 для уведомления.";
}
typedef duplex-mode {
type enumeration {
enum full-duplex {
description
"Указывает полнодуплексный режим.";
}
enum half-duplex {
description
"Указывает полудуплексный режим.";
}
}
description
"Указывает тип дуплексного режима.";
}
grouping l2-network-type {
description
"Указывает, что топология относится к типу L2.";
container l2-topology {
presence "Indicates L2 Network Topology.";
description
"Наличие контейнерного узла указывает сетевую
топологию L2.";
}
}
grouping l2-topology-attributes {
description
"Атрибуты области действия топологии L2.";
container l2-topology-attributes {
description
"Содержит атрибуты топологии L2.";
leaf name {
type string;
description
"Имя топологии.";
}
leaf-list flags {
type l2-flag-type;
description
"Флаги топологии.";
}
}
}
grouping l2-node-attributes {
description
"Атрибуты узла L2.";
container l2-node-attributes {
description
"Содержит атрибуты узла L2 .";
leaf name {
type string;
description
"Имя узла.";
}
leaf-list flags {
type node-flag-type;
description
"Флаги узла. Могут служить для указания
атрибутов флага узла.";
}
leaf-list bridge-id {
type string {
pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){7}';
}
description
"Идентификатор моста в форме строки октетов
из 8 шестнадцатеричных чисел. Включает 4 бита
приоритета, 12-битовый идентификатор MSTI-ID и
базовый идентификатор моста. Идентификаторы
могут присутствовать для каждого экземпляра STP.";
reference
"RFC 7727: Spanning Tree Protocol (STP) Application of
the Inter-Chassis Communication Protocol
(ICCP)";
}
leaf-list management-address {
type inet:ip-address;
description
"IP-адрес для управления.";
}
leaf management-mac {
type yang:mac-address;
description
"MAC-адрес для управления мостом. Это может быть
Bridge Base VLAN ID (VID), MAC-адрес интерфейса и пр.";
}
leaf management-vlan {
type string;
description
"VLAN, поддерживающая адрес управления. Тип и значение
реального VLAN ID будут относится к этой VLAN.";
}
}
}
grouping l2-link-attributes {
description
"L2 link attributes.";
container l2-link-attributes {
description
"Содержит атрибуты соединения L2.";
leaf name {
type string;
description
"Link name.";
}
leaf-list flags {
type link-flag-type;
description
"Флаги соединения. Может применяться для
флагов атрибута соединения.";
}
leaf rate {
type uint64;
units "Kbps";
description
"Скорость соединения. Задает требования к
пропускной способности для конкретного
соединения между источником и получателем.";
}
leaf delay {
type uint32;
units "microseconds";
description
"Односторонняя задержка в микросекундах.";
}
leaf auto-nego {
type boolean;
default "true";
description
"Значение true при поддержке автосогласования,
false, если автосогласование не поддерживается.";
}
leaf duplex {
type duplex-mode;
description
"Раскрывает режим дуплека - full-duplex или half-duplex.";
}
}
}
grouping l2-termination-point-attributes {
description
"Атрибуты точки завершения L2.";
container l2-termination-point-attributes {
description
"Содержит атрибуты точки завершения L2 .";
leaf interface-name {
type string;
description
"Имя интерфейса, которое может (но не обязано)
соответствовать ссылке на интерфейс содержащего узла,
т. е. имя пути к узлу данных соответствующего
интерфейса на содержащем узле напоминает тип
данных interface-ref, определенный в RFC 8343.
Следует отметить, что тип interface-ref из RFC 8343
нельзя использовать напрямую, поскольку он служит для
ссылки на интерфейс в хранилище данных одного узла сети,
а не однозначного указания интерфейсов в сети.";
}
leaf mac-address {
type yang:mac-address;
description
"MAC-адрес интерфейса для управления логическим каналом.";
}
leaf-list port-number {
type uint32;
description
"Список номеров портов моста, для которых каждая запись
содержит информацию управления.";
}
leaf-list unnumbered-id {
type uint32;
description
"Список идентификаторов безадресных интерфейсов.
Такой идентификатор будет соответствовать значению
ifIndex для интерфейса, т. е. значению ifIndex для
ifEntry, представляющей интерфейс в реализации, где
поддерживается Interfaces Group MIB (RFC 2863).";
}
leaf encapsulation-type {
type identityref {
base eth-encapsulation-type;
}
description
"Тип инкапсуляции для этой точки завершения.";
}
leaf outer-tag {
if-feature "VLAN";
type dot1q-types:vid-range-type;
description
"Внешний тег VLAN. Может указываться список VLAN
или не перекрывающиеся диапазоны VLAN.";
}
leaf outer-tpid {
if-feature "QinQ";
type dot1q-types:dot1q-tag-type;
description
"Указывает конкретный тип 802.1Q внешнего тега VLAN.";
}
leaf inner-tag {
if-feature "VLAN";
type dot1q-types:vid-range-type;
description
"Внутренний тег VLAN. Может указываться список VLAN
или не перекрывающиеся диапазоны VLAN";
}
leaf inner-tpid {
if-feature "QinQ";
type dot1q-types:dot1q-tag-type;
description
"Указывает конкретный тип 802.1Q внутреннего тега VLAN .";
}
leaf lag {
type boolean;
default "false";
description
"Указывает поддерживается ли агрегирование (lag).
Значение true говорит о наличии поддержки.";
}
leaf-list member-link-tp {
when "../lag = 'true'" {
description
"Используется только при поддержке интерфейсов lag.";
}
type leafref {
path "/nw:networks/nw:network/nw:node"
+ "/nt:termination-point/nt:tp-id";
}
description
"Список точек завершения каналов, связанных с конкретной
точкой завершения L2.";
}
container vxlan {
when "derived-from-or-self(../encapsulation-type, "
+ "'l2t:vxlan')" {
description
"Применимо лишь при инкапсуляции Ethernet типа vxlan.";
}
if-feature "VXLAN";
leaf vni-id {
type vni;
description
"VXLAN Network Identifier (VNI).";
}
description
"Тип инкапсуляции VXLAN.";
}
}
}
augment "/nw:networks/nw:network/nw:network-types" {
description
"Вводит новый тип сети для топологии L2.";
uses l2-network-type;
}
augment "/nw:networks/nw:network" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description
"Параметры дополнения, применимые лишь к сети с топологией L2.";
}
description
"Конфигурационные параметры для сети L2 в целом.";
uses l2-topology-attributes;
}
augment "/nw:networks/nw:network/nw:node" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description
"Параметры дополнения, применимые лишь к сети с топологией L2.";
}
description
"Конфигурационные параметры для L2 на уровне узла.";
uses l2-node-attributes;
}
augment "/nw:networks/nw:network/nt:link" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description
"Параметры дополнения, применимые лишь к сети с топологией L2.";
}
description
"Дополнение топологической информации канала L2.";
uses l2-link-attributes;
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description
"Параметры дополнения, применимые лишь к сети с топологией L2.";
}
description
"Дополнение топологических данных точки завершения L2.";
uses l2-termination-point-attributes;
}
notification l2-node-event {
description
"Уведомление о событии на узле L2.";
leaf event-type {
type l2-network-event-type;
description
"Тип события.";
}
uses nw:node-ref;
uses l2-network-type;
uses l2-node-attributes;
}
notification l2-link-event {
description
"Уведомление о событии на канале L2.";
leaf event-type {
type l2-network-event-type;
description
"Тип события.";
}
uses nt:link-ref;
uses l2-network-type;
uses l2-link-attributes;
}
notification l2-termination-point-event {
description
"Уведомление о событии в точке завершения L2.";
leaf event-type {
type l2-network-event-type;
description
"Тип события.";
}
uses nt:tp-ref;
uses l2-network-type;
uses l2-termination-point-attributes;
}
}
<CODE ENDS>
5. Взаимодействие с IANA
Агентство IANA зарегистрировало приведенные ниже URI в субреестре ns реестра The IETF XML Registry [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. IANA has registered the following YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. Name: ietf-l2-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology Prefix: l2t Reference: RFC 8944 Name: ietf-l2-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state Prefix: l2t-s Reference: RFC 8944
Эти модули не поддерживаются IANA.
6. Вопросы безопасности
Заданные этим документом модули YANG определяют схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF8 [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищенный транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446]. Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определенных пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.
Модуль топологии L2 задает данные, которые могут быть настраиваемыми в некоторых экземплярах (например, для виртуальной топологии, создаваемой клиентским приложением). В таких случаях вредоносный клиент может создавать нежелательную топологию. В частности, он может пытаться удалить или добавить узлы, каналы или точки завершения, создавая или удаляя соответствующие элементы в списках узлов, каналов или точек завершения. При изучении топологии сервер будет автоматически запрещать такие попытки недопустимой настройки. Для настроенной топологии (из хранилища intended) нежелательная конфигурация может вступить в силу и попасть в хранилище рабочей конфигурации [RFC8342], приводя к нарушению работы служб, обеспечиваемых через такую топологию. Поэтому важно применять NACM для предотвращения изменения топологии не имеющими полномочий клиентами.
В этом модуле данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. По умолчанию config имеет значение true). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены субдеревья и узлы, которые могут быть конфиденциальны или уязвимы.
l2-network-attributes
Враждебный клиент может пытаться сорвать настройку любых атрибутов, таких как имена и флаги.
l2-node-attributes
Враждебный клиент может пытаться сорвать настройку важных атрибутов узла, таких как имя и адрес управления.
l2-link-attributes
Враждебный клиент может пытаться сорвать настройку важных атрибутов канала, таких как скорость и задержка.
l2-termination-point-attributes:
Враждебный клиент может пытаться сорвать настройку важных атрибутов точки завершения (например, maximum-frame-size).
Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). В частности, модуль YANG для топологии L2 может раскрывать конфиденциальную информацию, например, MAC-адреса устройств или идентификаторы VLAN илиVXLAN. Неограниченный доступ к такой информации может приводить к нарушению конфиденциальности. Из MAC-адресов сетевых устройств можно получить информацию об их размещении для обхода защиты таких данных в операционной системе.
7. Литература
7.1. Нормативные документы
[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>.
[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC7224] Bjorklund, M., “IANA Interface Type YANG Module”, RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, “Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”, RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[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>.
[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>.
[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>.
7.2. Дополнительная литература
[I2RS-UR] Hares, S. and M. Chen, “Summary of I2RS Use Case Requirements”, Work in Progress, Internet-Draft, draft-ietf-i2rs-usecase-reqs-summary-03, 15 November 2016, <https://tools.ietf.org/html/draft-ietf-i2rs-usecase-reqs-summary-03>.
[IEEE802.1AB] IEEE, “IEEE Standard for Local and metropolitan area networks – Station and Media Access Control Connectivity Discovery”, IEEE Std 802.1AB-2016, DOI 10.1109/IEEESTD.2016.7433915, March 2016, <https://doi.org/10.1109/IEEESTD.2016.7433915>.
[IEEE802.1ad] IEEE, “IEEE Standard for Local and Metropolitan Area Networks–Virtual Bridged Local Area Networks—Amendment 4: Provider Bridges”, IEEE Std 802.1ad-2005, DOI 10.1109/IEEESTD.2006.6044678, May 2006, <https://doi.org/10.1109/IEEESTD.2006.6044678>.
[IEEE802.1ah] IEEE, “IEEE Standard for Local and metropolitan area networks — Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges”, IEEE Std 802.1ah-2008, DOI 10.1109/IEEESTD.2008.4602826, August 2008, <https://doi.org/10.1109/IEEESTD.2008.4602826>.
[IEEE802.1Q-2014] IEEE, “IEEE Standard for Local and metropolitan area networks–Bridges and Bridged Networks”, IEEE 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December 2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
[IEEE802.1Qcp] IEEE, “IEEE Standard for Local and metropolitan area networks–Bridges and Bridged Networks–Amendment 30: YANG Data Model”, IEEE Std 802.1Qcp-2018, DOI 10.1109/IEEESTD.2018.8467507, September 2018, <https://doi.org/10.1109/IEEESTD.2018.8467507>.
[RFC7727] Zhang, M., Wen, H., and J. Hu, “Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)”, RFC 7727, DOI 10.17487/RFC7727, January 2016, <https://www.rfc-editor.org/info/rfc7727>.
[RFC7951] Lhotka, L., “JSON Encoding of Data Modeled with YANG”, RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.
[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>.
[TRILL-YANG] Hao, W., Li, Y., Kumar, D., Durrani, M., Zhai, H., and L. Xia, “TRILL YANG Data Model”, Work in Progress, Internet-Draft, draft-ietf-trill-yang-04, 20 December 2015, <https://tools.ietf.org/html/draft-ietf-trill-yang-04>.
Приложение A. Модуль для реализаций без поддержки NMDA
Определенный здесь модуль YANG ietf-l2-topology дополняет модули ietf-network и ietf-network-topology, разработанные для использования с реализациями, поддерживающими хранилища NMDA [RFC8342]. Для работы с реализациями, не поддерживающими NMDA, определен набор сопутствующих модулей, представляющих модель состояния сети и топологию, ietf-network-state и ietf-network-topology-state.
Для использования определенной в этом документе модели топологии L2 с реализациями без поддержки NMDA создан сопутствующий модуль, представляющий рабочее состояние топологии L2. Модуль ietf-l2-topology-state соответствует модулю ietf-l2-topology, определенному в разделе 4, однако он дополняет ietf-network-state и ietf-network-topology-state (вместо ietf-network и ietf-network-topology), а все его узлы данных являются ненастраиваемыми.
Модуль ietf-l2-topology не следует поддерживать в реализациях, поддерживающих NMDA. По этой причине модуль определен в информационном приложении.
Поскольку структура модуля соответствует структуре базовых модулей, дерево YANG для него не приводится здесь.
<CODE BEGINS> file "ietf-l2-topology-state@2020-11-15.yang"
module ietf-l2-topology-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology-state";
prefix l2t-s;
import ietf-network-state {
prefix nw-s;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology-state {
prefix nt-s;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-l2-topology {
prefix l2t;
reference
"RFC 8944: A YANG Data Model for Layer 2 Network Topologies";
}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Jie Dong
<mailto:jie.dong@huawei.com>
Editor: Xiugang Wei
<mailto:weixiugang@huawei.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Editor: Anders Liu
<andersliu@tencent.com>";
description
"Этот модуль определяет модель состояния сетевой топологии L2,
представляя топологию, которая была изучена (learned) или
является результатом применения модели ietf-l2-topolog,
отражающей узлы данных этой модели.
Модель отражает ietf-l2-topology, но включает только данные
состояния, доступные лишь для чтения ( read-only). Модель не
нужна при поддержке базовой инфраструктурой хранилища NMDA.
Авторские права (Copyright (c) 2020) принадлежат IETF Trust
и лицам, указанным как авторы кода. Все права защищены.
Распространение и использование в исходной или двоичной форме
с изменениями или без таковых разрешено в соответствии с
упрощенной лицензией BSD, как указано в параграфе 4.c
документа IETF Trust Legal Provisions применительно к
документам IETF (https://trustee.ietf.org/license-info).
Данная версия модуля YANG является частью RFC 8944, где
правовые аспекты изложены более полно.";
revision 2020-11-15 {
description
"Исходный выпуск.";
reference
"RFC 8944: A YANG Data Model for Layer 2 Network Topologies";
}
/*
* Узлы данных
*/
augment "/nw-s:networks/nw-s:network/nw-s:network-types" {
description
"Вводит новый тип сети для топологии L2.";
uses l2t:l2-network-type;
}
augment "/nw-s:networks/nw-s:network" {
when 'nw-s:network-types/l2t-s:l2-topology' {
description
"Параметры дополнения для сетей с топологией L2.";
}
description
"Конфигурационные параметры сети L2 в целом.";
uses l2t:l2-topology-attributes;
}
augment "/nw-s:networks/nw-s:network/nw-s:node" {
when '../nw-s:network-types/l2t-s:l2-topology' {
description
"Параметры дополнения для сетей с топологией L2.";
}
description
"Конфигурационные параметры L2 на уровне узла.";
uses l2t:l2-node-attributes;
}
augment "/nw-s:networks/nw-s:network/nt-s:link" {
when '../nw-s:network-types/l2t-s:l2-topology' {
description
"Параметры дополнения для сетей с топологией L2.";
}
description
"Дополнение топологической информации канала L2.";
uses l2t:l2-link-attributes;
}
augment "/nw-s:networks/nw-s:network/nw-s:node/"
+ "nt-s:termination-point" {
when '../../nw-s:network-types/l2t-s:l2-topology' {
description
"Параметры дополнения для сетей с топологией L2.";
}
description
"Дополнение данных топологии точки завершения L2.";
uses l2t:l2-termination-point-attributes;
}
/*
* Уведомления
*/
notification l2-node-event {
description
"Уведомление о событии на узле L2.";
leaf event-type {
type l2t:l2-network-event-type;
description
"Event type.";
}
uses nw-s:node-ref;
uses l2t:l2-network-type;
uses l2t:l2-node-attributes;
}
notification l2-link-event {
description
"Уведомление о событии на канале L2.";
leaf event-type {
type l2t:l2-network-event-type;
description
"Event type.";
}
uses nt-s:link-ref;
uses l2t:l2-network-type;
uses l2t:l2-link-attributes;
}
notification l2-termination-point-event {
description
"Уведомление о событии в точке завершения L2.";
leaf event-type {
type l2t:l2-network-event-type;
description
"Event type.";
}
uses nt-s:tp-ref;
uses l2t:l2-network-type;
uses l2t:l2-termination-point-attributes;
}
}
<CODE ENDS>
Приложение B. Пример
В этом приложении дан пример экземпляра дерева данных в представлении JSON [RFC7951]. Пример создает топологию ietf-l2-topology для показанной на рисунке 2 сети. Здесь имеется три узла – D1, D2, D3. В D1 имеется три точки завершения (1-0-1, 1-2-1, 1-3-1), в D2 тоже три (2-1-1, 2-0-1, 2-3-1), а в D3 – две (3-1-1 и 3-2-1). Точка завершения 1-0-1 поддерживает lag с двумя каналами 1-0-1-1 и 1-0-1-2. Имеется 6 односторонних каналов, по два между каждой парой точек.
+------------+ +------------+
| D1 | | D2 |
1-0-1-1 /-\ /-\ /-\ /-\
<--------->| | 1-0-1 | |---------------->| | 2-1-1 | |
1-0-1-2 | | 1-2-1 | |<----------------| | 2-0-1 | |
<--------> \-/ 1-3-1 \-/ \-/ 2-3-1 \-/
| /----\ | | /----\ |
+---| |---+ +---| |---+
\----/ \----/
A | A |
| | | |
| | | |
| | +------------+ | |
| | | D3 | | |
| | /-\ /-\ | |
| +----->| | 3-1-1 | |-------+ |
+---------| | 3-2-1 | |<---------+
\-/ \-/
| |
+------------+
Рисунок 2. Пример топологии сети.
Соответствующий экземпляр дерева данных представлен ниже.
{
"ietf-network:networks": {
"network": [
{
"network-id": "l2-topo-example",
"node": [
{
"node-id": "D1",
"ietf-network-topology:termination-point": [
{
"tp-id": "1-0-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:d0",
"lag": true,
"member-link-tp": [
"1-0-1-1",
"1-0-1-2"
]
}
},
{
"tp-id": "1-0-1-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:d3"
}
},
{
"tp-id": "1-0-1-2",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:d4"
}
},
{
"tp-id": "1-2-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:d1"
}
},
{
"tp-id": "1-3-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:d2"
}
}
],
"ietf-l2-topology:l2-node-attributes": {
"management-address": [
"192.0.2.1",
"2001:db8:0:1::"
]
}
},
{
"node-id": "D2",
"ietf-network-topology:termination-point": [
{
"tp-id": "2-0-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:e0"
}
},
{
"tp-id": "2-1-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:e1"
}
},
{
"tp-id": "2-3-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:e2"
}
}
],
"ietf-l2-topology:l2-node-attributes": {
"management-address": [
"192.0.2.2",
"2001:db8:0:2::"
]
}
},
{
"node-id": "D3",
"ietf-network-topology:termination-point": [
{
"tp-id": "3-1-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:f0"
}
},
{
"tp-id": "3-2-1",
"ietf-l2-topology:l2-termination-point-attributes": {
"mac-address": "00:00:5e:00:53:f1"
}
}
],
"ietf-l2-topology:l2-node-attributes": {
"management-address": [
"192.0.2.3",
"2001:db8:0:3::"
]
}
}
],
"ietf-network-topology:link": [
{
"link-id": "D1,1-2-1,D2,2-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-2-1"
},
"destination": {
"dest-node": "D2",
"dest-tp": "2-1-1"
},
"ietf-l2-topology:l2-link-attributes": {
"rate": "1000"
}
},
{
"link-id": "D2,2-1-1,D1,1-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-1-1"
},
"destination": {
"dest-node": "D1",
"dest-tp": "1-2-1"
},
"ietf-l2-topology:l2-link-attributes": {
"rate": "1000"
}
},
{
"link-id": "D1,1-3-1,D3,3-1-1",
"source": {
"source-node": "D1",
"source-tp": "1-3-1"
},
"destination": {
"dest-node": "D3",
"dest-tp": "3-1-1"
},
"ietf-l2-topology:l2-link-attributes": {
"rate": "1000"
}
},
{
"link-id": "D3,3-1-1,D1,1-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-1-1"
},
"destination": {
"dest-node": "D1",
"dest-tp": "1-3-1"
},
"ietf-l2-topology:l2-link-attributes": {
"rate": "1000"
}
},
{
"link-id": "D2,2-3-1,D3,3-2-1",
"source": {
"source-node": "D2",
"source-tp": "2-3-1"
},
"destination": {
"dest-node": "D3",
"dest-tp": "3-2-1"
},
"ietf-l2-topology:l2-link-attributes": {
"rate": "1000"
}
},
{
"link-id": "D3,3-2-1,D2,2-3-1",
"source": {
"source-node": "D3",
"source-tp": "3-2-1"
},
"destination": {
"dest-node": "D2",
"dest-tp": "2-3-1"
},
"ietf-l2-topology:l2-link-attributes": {
"rate": "1000"
}
}
]
}
]
}
}
Благодарности
Авторы признательны за комментарии и предложения Susan Hares, Alia Atlas, Juergen Schoenwaelder, Mach Chen, Alexander Clemm, Sriganesh Kini, Oscar Gonzalez de Dios, Stig Venaas, Christian Huitema, Meral Shirazipour, Benjamin Kaduk, Don Fedyk.
Большое спасибо Ladislav Lhotka за рецензирование.
Адреса авторов
Jie Dong
Huawei
Huawei Campus
No. 156 Beiqing Rd.
Beijing
100095
China
Email: jie.dong@huawei.com
Xiugang Wei
Huawei
Huawei Campus
No. 156 Beiqing Rd.
Beijing
100095
China
Email: weixiugang@huawei.com
Qin Wu
Huawei
101 Software Avenue
Yuhua District
Nanjing
210012
China
Email: bill.wu@huawei.com
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Anders Liu
Tecent
Yinke Building
38 Haidian St
Haidian District
Beijing
100080
China
Email: andersliu@tencent.com
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force.
2Internet Engineering Steering Group.
3Interface to the Routing System.
4Network Management Datastore Architecture – архитектура хранилища данных управления сетью.
5Provider Backbone Bridging – магистральные мосты провайдера.
6Virtual eXtensible Local Area Network – виртуальная расширяемая ЛВС.
7Link Layer Discovery Protocol – протокол обнаружения на канальном уровне.
8Network Configuration Protocol – протокол настройки сети.