RFC 9129 YANG Data Model for the OSPF Protocol

Internet Engineering Task Force (IETF)                          D. Yeung
Request for Comments: 9129                                  Arrcus, Inc.
Category: Standards Track                                          Y. Qu
ISSN: 2070-1721                                                Futurewei
                                                                J. Zhang
                                                        Juniper Networks
                                                                 I. Chen
                                                   The MITRE Corporation
                                                               A. Lindem
                                                           Cisco Systems
                                                            October 2022

YANG Data Model for the OSPF Protocol

Модель данных YANG для протокола OSPF

PDF

Аннотация

Этот документ задаёт модель данных YANG, которая может служить для настройки и управления OSPF. Модель основана на версии YANG 1.1, определённой в RFC 7950, и соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA), описанной в RFC 8342.

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

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

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

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

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

Copyright (c) 2022. Авторские права принадлежат 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).

Оглавление

Исключено в версии HTML.

1. Введение

YANG [RFC7950] — язык определения данных, служащий для задания содержимого концептуального хранилища данных, позволяющего управлять сетевыми устройствами по протоколу настройки сети (Network Configuration Protocol или NETCONF) [RFC6241], RESTCONF [RFC8040] или иному протоколу управления сетью. Кроме того, модели данных YANG могут служить основой для реализации других интерфейсов, таких как консольный (Command-Line Interface или CLI) и программный API.

Этот документ определяет модель данных YANG, которая может служить для настройки и управления OSPF. Он дополняет модель данных ядра маршрутизации, заданную в [RFC8349], и предоставляет основу для разработки моделей данных протоколов маршрутизации. Модель полностью соответствует архитектуре NMDA [RFC8342]. Модель данных интерфейса определена в [RFC8343] и применяется для ссылки на интерфейсы из протоколов маршрутизации. Модель данных для цепочек ключей [RFC8177] применяется для аутентификации OSPF и обеспечивает ссылки на настроенные цепочки ключей и криптографические алгоритмы.

Поддерживаются оба протокола OSPFv2 [RFC2328] и OSPFv3 [RFC5340]. В дополнение к протоколу ядра OSPF поддерживаются функции из других RFC, связанных с OSPF. Это включает устройства запроса [RFC1793], организацию трафика (Traffic Engineering или TE) [RFC3630], разные семейства адресов [RFC5838], аккуратный перезапуск [RFC3623] [RFC5187], опцию NSSA (Not-So-Stubby Area) [RFC3101] и OSPFv2 или OSPFv3 в качестве протокола между провайдером и клиентом (Provider Edge to Customer Edge или PE-CE) [RFC4577] [RFC6565]. Не входящие в ядро функции в модели OSPF являются необязательными.

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

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

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

В этом документе применяется графическое представление данных, определённое в [RFC8340].

2. Устройство модели данных

Хотя базовые элементы конфигурации OSPF (маршрутизаторы, области, интерфейсы) не меняются, детали модели конфигурации зависят от производителя. Различия наблюдаются в разных аспектах, включая привязку экземпляра протокола к домену маршрутизации и создание экземпляров протокола. Цель этого документа состоит в определении модели данных, обеспечивающей пользовательский интерфейс для OSPFv2 и OSPFv3. Обязательных элементов (mandatory) очень немного, что даёт производителям возможность приспособить эту модель данных к своим реализациям.

2.1. Рабочее состояние OSPF

Рабочее состояние OSPF включено в одно дерево с конфигурацией OSPF в соответствии с архитектурой NMDA [RFC8342] и дополняется лишь контейнер routing из ietf-routing [RFC8349], а контейнер routing-state не меняется.

2.2. Обзор

Модуль YANG OSPF, заданный в этом документе, включает все базовые блоки, нужные для протокола OSPF. Модуль дополняет путь /routing/control-plane-protocols/control-plane-protocol, заданный в модуле ietf-routing. Модель ietf-ospf задаёт один экземпляр OSPF, который может быть создан как OSPFv2 или OSPFv3. Несколько экземпляров создаются как экземпляры протоколов плоскости управления.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
             .
             .
          +--rw address-family?       iana-rt-types:address-family
             .
             .
          +--rw areas
          |  +--rw area* [area-id]
          |     +--rw area-id                   area-id-type
          |        .
          |        .
          |     +--rw virtual-links
          |     |  +--rw virtual-link* [transit-area-id router-id]
          |     |     .
          |     |     .
          |     +--rw sham-links {pe-ce-protocol}?
          |     |  +--rw sham-link* [local-id remote-id]
          |     |     .
          |     |     .
          |     +--rw interfaces
          |        +--rw interface* [name]
          |           .
          |           .
          +--rw topologies {multi-topology}?
             +--rw topology* [name]
                .
                .

Контейнер ospf включает один экземпляр протокола OSPF, содержащий данные конфигурации и состояния на уровне маршрутизатора OSPF. Каждый экземпляр OSPF сопоставляется с экземпляром протокола плоскости управления в соответствии с [RFC8349].

Контейнеры areas и area/interfaces определяют конфигурацию и рабочее состояние областей и интерфейсов OSPF.

Контейнер topologies определяет конфигурацию и рабочее состояние OSPF для топологий OSPF при поддержке функции (feature) multi-topology.

2.3. OSPFv2 и OSPFv3

Определённая здесь модель данных поддерживает протоколы OSPFv2 и OSPFv3. Обязательное поле version указывает применяемую версию OSPF и в соответствии с этим модель данных использует OSPFv2 или OSPFv3.

2.4. Необязательные функции

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

multi-topology

Поддержка маршрутизации MT Multi-Topology) [RFC4915].

multi-area-adj

Поддержка смежности нескольких областей OSPF [RFC5185].

explicit-router-id

Поддержка явного задания Router ID на уровне экземпляра.

demand-circuit

Поддержа устройств, запрашивающих OSPF [RFC1793].

mtu-ignore

Поддержка запрета проверки MTU пакета OSPF Database Description в соответствии с параграфом 10.6 в [RFC2328].

lls

Поддержка сигнализации LLS (OSPF Link-Local Signaling) [RFC5613].

prefix-suppression

Поддержка подавления анонсов префиксов OSPF [RFC6860].

ttl-security

Поддержка проверки безопасности для OSPF TTL (Time to Live) [RFC5082].

nsr

Поддержка OSPF NSR (Non-Stop Routing), позволяющей маршрутизатору с избыточностью плоскости управления (например, платы с двумя процессорами маршрутов — Route Processor или RP)) поддерживать своё состояние и отношения смежности при плановом или неплановом перезапуске плоскости управления. Это отличается от безостановочной пересылки (Non-Stop Forwarding или NSF) тем, что не требует содействия соседей OSPF для восстановления состояния плоскости управления.

graceful-restart

Поддержка аккуратного (graceful) перезапуска OSPF [RFC3623] [RFC5187].

auto-cost

Поддержка расчёта стоимости для интерфейса OSPF по эталонной пропускной способности [RFC2328].

max-ecmp

Поддержка настройки максимального числа равноценных путей (Equal-Cost Multi-Path или ECMP).

max-lsa

Поддержка настройки максимального числа анонсов состояния канала (Link State Advertisement или LSA), воспринимаемых экземпляром OSPF [RFC1765].

te-rid

Поддержка настройки TE Router ID, т е. Router Address TLV, как указано в параграфе 2.4.1 [RFC3630], или Router IPv6 Address TLV, как указано в разделе 3 [RFC5329].

ldp-igp-sync

Поддержка синхронизации LDP IGP [RFC5443].

ospfv2-authentication-trailer

Поддержка трейлера аутентификации OSPFv2 [RFC5709] [RFC7474].

ospfv3-authentication-ipsec

Поддержка IPsec для аутентификации OSPFv3 [RFC4552].

ospfv3-authentication-trailer

Поддержка трейлера аутентификации OSPFv3 [RFC7166].

fast-reroute

Поддержка IP Fast Reroute (IP-FRR) [RFC5714].

node-flag

Поддержка флагов узла для префиксов for OSPF [RFC7684].

node-tag

Поддержка административных флагов узла для экземпляров OSPF [RFC7777].

lfa

Поддержка беспетлевых вариантов (Loop-Free Alternate или LFA) [RFC5286].

remote-lfa

Поддержка удалённых LFA (Remote LFA или R-LFA) [RFC7490].

stub-router

Поддержка анонсов тупиковых маршрутизаторов OSPF [RFC6987].

pe-ce-protocol

Поддержка OSPF в качестве протокола PE-CE [RFC4577] [RFC6565].

ietf-spf-delay

Поддержка алгоритма задержки IETF Shortest Path First (SPF) [RFC8405].

bfd

Поддержка обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD) для нахождения соседей OSPF [RFC5880] [RFC5881].

hybrid-interface

Поддержка гибридных интерфейсов OSPF (broadcast и point-to-multipoint) [RFC6845].

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

2.5. Конфигурация и рабочее состояние маршрутизатора OSPF

Контейнер ospf размещается на верхнем уровне модели и представляет экземпляр протокола OSPF с конфигурацией и рабочим состоянием на уровне маршрутизатора. Рабочее состояние включает статистику экземпляра, статистику задержки IETF SPF, базу данных LSDB (AS-Scope Link State Database), локальную таблицу RIB, журналы SPF и LSA.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw address-family?       iana-rt-types:address-family
          +--rw enabled?              boolean
          +--rw explicit-router-id?   rt-types:router-id
          |                           {explicit-router-id}?
          +--rw preference
          |  +--rw (scope)?
          |     +--:(single-value)
          |     |  +--rw all?          uint8
          |     +--:(multi-values)
          |        +--rw (granularity)?
          |        |  +--:(detail)
          |        |  |  +--rw intra-area?   uint8
          |        |  |  +--rw inter-area?   uint8
          |        |  +--:(coarse)
          |        |     +--rw internal?     uint8
          |        +--rw external?     uint8
          +--rw nsr {nsr}?
          |  +--rw enabled?  boolean
          +--rw graceful-restart {graceful-restart}?
          |  +--rw enabled?                      boolean
          |  +--rw helper-enabled?               boolean
          |  +--rw restart-interval?             uint16
          |  +--rw helper-strict-lsa-checking?   boolean
          +--rw auto-cost {auto-cost}?
          |  +--rw enabled?               boolean
          |  +--rw reference-bandwidth?   uint32
          +--rw spf-control
          |  +--rw paths?            uint16 {max-ecmp}?
          |  +--rw ietf-spf-delay {ietf-spf-delay}?
          |     +--rw initial-delay?   uint32
          |     +--rw short-delay?     uint32
          |     +--rw long-delay?      uint32
          |     +--rw hold-down?       uint32
          |     +--rw time-to-learn?   uint32
          |     +--ro current-state?             enumeration
          |     +--ro remaining-time-to-learn?
          |                   rt-types:timer-value-milliseconds
          |     +--ro remaining-hold-down?
          |                   rt-types:timer-value-milliseconds
          |     +--ro last-event-received?       yang:timestamp
          |     +--ro next-spf-time?             yang:timestamp
          |     +--ro last-spf-time?             yang:timestamp
          +--rw database-control
          |  +--rw max-lsa?   uint32 {max-lsa}?
          +--rw stub-router {stub-router}?
          |  +--rw (trigger)?
          |     +--:(always)
          |        +--rw always!
          +--rw mpls
          |  +--rw te-rid {te-rid}?
          |  |  +--rw ipv4-router-id?   inet:ipv4-address
          |  |  +--rw ipv6-router-id?   inet:ipv6-address
          |  +--rw ldp
          |     +--rw igp-sync?   boolean {ldp-igp-sync}?
          +--rw fast-reroute {fast-reroute}?
          |  +--rw lfa {lfa}?
          +--rw node-tags {node-tag}?
          |  +--rw node-tag* [tag]
          |     +--rw tag      uint32
          +--ro router-id?          rt-types:router-id
          +--ro local-rib
          |  +--ro route* [prefix]
          |     +--ro prefix        inet:ip-prefix
          |     +--ro next-hops
          |     |  +--ro next-hop* []
          |     |     +--ro outgoing-interface?   if:interface-ref
          |     |     +--ro next-hop              inet:ip-address
          |     +--ro metric?       uint32
          |     +--ro route-type?   route-type
          |     +--ro route-tag?    uint32
          +--ro statistics
          |  +--ro discontinuity-time         yang:date-and-time
          |  +--ro originate-new-lsa-count?   yang:counter32
          |  +--ro rx-new-lsas-count?         yang:counter32
          |  +--ro as-scope-lsa-count?        yang:gauge32
          |  +--ro as-scope-lsa-chksum-sum?   uint32
          |  +--ro database
          |  |  +--ro as-scope-lsa-type*
          |  |     +--ro lsa-type?        uint16
          |  |     +--ro lsa-count?       yang:gauge32
          |  |     +--ro lsa-cksum-sum?   uint32
          |  +--ro protected-routes {fast-reroute}?
          |  |  +--ro address-family-stats*
          |  |         [address-family prefix alternate]
          |  |     +--ro address-family
          |  |         iana-rt-types:address-family
          |  |     +--ro prefix                  inet:ip-prefix
          |  |     +--ro alternate               inet:ip-address
          |  |     +--ro alternate-type?         enumeration
          |  |     +--ro best?                   boolean
          |  |     +--ro non-best-reason?        string
          |  |     +--ro protection-available?   bits
          |  |     +--ro alternate-metric-1?     uint32
          |  |     +--ro alternate-metric-2?     uint32
          |  |     +--ro alternate-metric-3?     uint32
          |  +--ro unprotected-routes {fast-reroute}?
          |  |  +--ro address-family-stats* [address-family prefix]
          |  |     +--ro address-family    iana-rt-types:address-family
          |  |     +--ro prefix            inet:ip-prefix
          |  +--ro protection-statistics* [frr-protection-method]
          |     +--ro frr-protection-method    string
          |     +--ro address-family-stats* [address-family]
          |        +--ro address-family
          |             iana-rt-types:address-family
          |        +--ro total-routes?           uint32
          |        +--ro unprotected-routes?     uint32
          |        +--ro protected-routes?       uint32
          |        +--ro linkprotected-routes?   uint32
          |        +--ro nodeprotected-routes?   uint32
          +--ro database
          |  +--ro as-scope-lsa-type* [lsa-type]
          |     +--ro as-scope-lsas
          |        +--ro as-scope-lsa* [lsa-id adv-router]
          |           +--ro lsa-id               union
          |           +--ro adv-router           inet:ipv4-address
          |           +--ro decoded-completed?   boolean
          |           +--ro raw-data?            yang:hex-string
          |           +--ro (version)?
          |              +--:(ospfv2)
          |              |  +--ro ospfv2
          .              .
          .              .
          |              +--:(ospfv3)
          |                 +--ro ospfv3
          .
          .
          +--ro spf-log
          |  +--ro event* [id]
          |     +--ro id                    uint32
          |     +--ro spf-type?             enumeration
          |     +--ro schedule-timestamp?   yang:timestamp
          |     +--ro start-timestamp?      yang:timestamp
          |     +--ro end-timestamp?        yang:timestamp
          |     +--ro trigger-lsa*
          |        +--ro area-id?      area-id-type
          |        +--ro type?         uint16
          |        +--ro lsa-id?       union
          |        +--ro adv-router?   rt-types:router-id
          |        +--ro seq-num?      uint32
          +--ro lsa-log
          |  +--ro event* [id]
          |     +--ro id                    uint32
          |     +--ro lsa
          |     |  +--ro area-id?      area-id-type
          |     |  +--ro type?         uint16
          |     |  +--ro lsa-id?       union
          |     |  +--ro adv-router?   rt-types:router-id
          |     |  +--ro seq-num?      uint32
          |     +--ro received-timestamp?   yang:timestamp
          |     +--ro reason?               identityref
          .
          .

2.6. Конфигурация и рабочее состояние области OSPF

Контейнер area содержит конфигурацию области OSPF и список контейнеров для всех интерфейсов OSPF в эту область. Рабочее состояние области включает статистику и LSDB.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw areas
          |  +--rw area* [area-id]
          |     +--rw area-id                   area-id-type
          |     +--rw area-type?                identityref
          |     +--rw summary?                  boolean
          |     +--rw default-cost?             ospf-metric
          |     +--rw ranges
          |     |  +--rw range* [prefix]
          |     |     +--rw prefix       inet:ip-prefix
          |     |     +--rw advertise?   boolean
          |     |     +--rw cost?        ospf-metric
          |     +--rw topologies {ospf:multi-topology}?
          |     |  +--rw topology* [name]
          |     |     +--rw name  -> ../../../../../../../../
          |     |                    ../../../rt:ribs/rib/name
          |     |     +--rw summary?        boolean
          |     |     +--rw default-cost?   ospf-metric
          |     |     +--rw ranges
          |     |         +--rw range* [prefix]
          |     |            +--rw prefix       inet:ip-prefix
          |     |            +--rw advertise?   boolean
          |     |            +--rw cost?        ospf-metric
          |     +--ro statistics
          |     |  +--ro discontinuity-time           yang:date-and-time
          |     |  +--ro spf-runs-count?              yang:counter32
          |     |  +--ro abr-count?                   yang:gauge32
          |     |  +--ro asbr-count?                  yang:gauge32
          |     |  +--ro ar-nssa-translator-event-count?
          |     |                                     yang:counter32
          |     |  +--ro area-scope-lsa-count?        yang:gauge32
          |     |  +--ro area-scope-lsa-cksum-sum?    uint32
          |     |  +--ro database
          |     |     +--ro area-scope-lsa-type*
          |     |        +--ro lsa-type?        uint16
          |     |        +--ro lsa-count?       yang:gauge32
          |     |        +--ro lsa-cksum-sum?   uint32
          |     +--ro database
          |     |  +--ro area-scope-lsa-type* [lsa-type]
          |     |     +--ro lsa-type           uint16
          |     |     +--ro area-scope-lsas
          |     |        +--ro area-scope-lsa* [lsa-id adv-router]
          |     |           +--ro lsa-id               union
          .     .           .
          .     .           .
          |     |           +--ro (version)?
          |     |              +--:(ospfv2)
          |     |              |  +--ro ospfv2
          |     |              |     +--ro header
          .     .              .     .
          .     .              .     .
          |     |              |     +--ro body
          |     |              |        +--ro router
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro network
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro summary
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro external
          .     .              .        .
          .     .              .        .
          |     |              |        +--ro opaque
          .     .              .        .
          .     .              .        .
          |     |              +--:(ospfv3)
          |     |                 +--ro ospfv3
          |     |                    +--ro header
          .     .                    .
          .     .                    .
          |     |                    +--ro body
          |     |                       +--ro router
          .     .                       .
          .     .                       .
          |     |                       +--ro network
          .     .                       .
          .     .                       .
          |     |                       +--ro inter-area-prefix
          .     .                       .
          .     .                       .
          |     |                       +--ro inter-area-router
          .     .                       .
          .     .                       .
          |     |                       +--ro as-external
          .     .                       .
          .     .                       .
          |     |                       +--ro nssa
          .     .                       .
          .     .                       .
          |     |                       +--ro link
          .     .                       .
          .     .                       .
          |     |                       +--ro intra-area-prefix
          .     .                       .
          .     .                       .
          |     |                       +--ro router-information
          .     .                       .
          .     .                       .
          |     +--rw virtual-links
          |     |  +--rw virtual-link* [transit-area-id router-id]
          |     |     +--rw transit-area-id       -> ../../../../
          |     |                                    area/area-id
          |     |     +--rw router-id             rt-types:router-id
          |     |     +--rw hello-interval?       uint16
          |     |     +--rw dead-interval?        uint32
          |     |     +--rw retransmit-interval?  uint16
          |     |     +--rw transmit-delay?       uint16
          |     |     +--rw lls?                  boolean {lls}?
          |     |     +--rw ttl-security {ttl-security}?
          |     |     |  +--rw enabled?  boolean
          |     |     |  +--rw hops?     uint8
          |     |     +--rw enabled?              boolean
          |     |     +--rw authentication
          |     |     |  +--rw (auth-type-selection)?
          |     |     |     +--:(ospfv2-auth)
          |     |     |     |  +--rw ospfv2-auth-trailer-rfc?
          |     |     |     |  |       ospfv2-auth-trailer-rfc-version
          |     |     |     |  |        {ospfv2-authentication-trailer}?
          |     |     |     |  +--rw (ospfv2-auth-specification)?
          |     |     |     |     +--:(auth-key-chain) {key-chain}?
          |     |     |     |     |  +--rw ospfv2-key-chain?
          |     |     |     |     |         key-chain:key-chain-ref
          |     |     |     |     +--:(auth-key-explicit)
          |     |     |     |        +--rw ospfv2-key-id?     uint32
          |     |     |     |        +--rw ospfv2-key?        string
          |     |     |     |        +--rw ospfv2-crypto-algorithm?
          |     |     |     |                identityref
          |     |     |     +--:(ospfv3-auth-ipsec)
          |     |     |     |      {ospfv3-authentication-ipsec}?
          |     |     |     |  +--rw sa?                       string
          |     |     |     +--:(ospfv3-auth-trailer)
          |     |     |        |  {ospfv3-authentication-trailer}?
          |     |     |        +--rw (ospfv3-auth-specification)?
          |     |     |           +--:(auth-key-chain) {key-chain}?
          |     |     |           |  +--rw ospfv3-key-chain?
          |     |     |           |          key-chain:key-chain-ref
          |     |     |           +--:(auth-key-explicit)
          |     |     |              +--rw ospfv3-sa-id?        uint16
          |     |     |              +--rw ospfv3-key?          string
          |     |     |              +--rw ospfv3-crypto-algorithm?
          |     |     |                      identityref
          |     |     +--ro cost?              ospf-link-metric
          |     |     +--ro state?             if-state-type
          |     |     +--ro hello-timer?       rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro wait-timer?        rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro dr-router-id?      rt-types:router-id
          |     |     +--ro dr-ip-addr?        inet:ip-address
          |     |     +--ro bdr-router-id?     rt-types:router-id
          |     |     +--ro bdr-ip-addr?       inet:ip-address
          |     |     +--ro statistics
          |     |     |  +--ro discontinuity-time     yang:date-and-time
          |     |     |  +--ro if-event-count?        yang:counter32
          |     |     |  +--ro link-scope-lsa-count?  yang:gauge32
          |     |     |  +--ro link-scope-lsa-cksum-sum?
          |     |     |                               uint32
          |     |     |  +--ro database
          |     |     |     +--ro link-scope-lsa-type*
          |     |     |        +--ro lsa-type?        uint16
          |     |     |        +--ro lsa-count?       yang:gauge32
          |     |     |        +--ro lsa-cksum-sum?   int32
          |     |     +--ro neighbors
          |     |     |  +--ro neighbor* [neighbor-router-id]
          |     |     |     +--ro neighbor-router-id
          |     |     |                           rt-types:router-id
          |     |     |     +--ro address?        inet:ip-address
          |     |     |     +--ro dr-router-id?   rt-types:router-id
          |     |     |     +--ro dr-ip-addr?     inet:ip-address
          |     |     |     +--ro bdr-router-id?  rt-types:router-id
          |     |     |     +--ro bdr-ip-addr?    inet:ip-address
          |     |     |     +--ro state?          nbr-state-type
          |     |     |     +--ro dead-timer? rt-types:
          |     |     |     |                  rtimer-value-seconds16
          |     |     |     +--ro statistics
          |     |     |        +--ro discontinuity-time
          |     |     |                           yang:date-and-time
          |     |     |        +--ro nbr-event-count?
          |     |     |                           yang:counter32
          |     |     |        +--ro nbr-retrans-qlen?
          |     |     |                           yang:gauge32
          |     |     +--ro database
          |     |        +--ro link-scope-lsa-type* [lsa-type]
          |     |           +--ro lsa-type           uint16
          |     |           +--ro link-scope-lsas
          .     .
          .     .
          |     +--rw sham-links {pe-ce-protocol}?
          |     |  +--rw sham-link* [local-id remote-id]
          |     |     +--rw local-id               inet:ip-address
          |     |     +--rw remote-id              inet:ip-address
          |     |     +--rw hello-interval?        uint16
          |     |     +--rw dead-interval?         uint32
          |     |     +--rw retransmit-interval?   uint16
          |     |     +--rw transmit-delay?        uint16
          |     |     +--rw lls?                   boolean {lls}?
          |     |     +--rw ttl-security {ttl-security}?
          |     |     |  +--rw enabled?  boolean
          |     |     |  +--rw hops?     uint8
          |     |     +--rw enabled?            boolean
          |     |     +--rw authentication
          |     |     |  +--rw (auth-type-selection)?
          |     |     |     +--:(ospfv2-auth)
          |     |     |     |  +--rw ospfv2-auth-trailer-rfc?
          |     |     |     |  |       ospfv2-auth-trailer-rfc-version
          |     |     |     |  |        {ospfv2-authentication-trailer}?
          |     |     |     |  +--rw (ospfv2-auth-specification)?
          |     |     |     |     +--:(auth-key-chain) {key-chain}?
          |     |     |     |     |  +--rw ospfv2-key-chain?
          |     |     |     |     |         key-chain:key-chain-ref
          |     |     |     |     +--:(auth-key-explicit)
          |     |     |     |        +--rw ospfv2-key-id?     uint32
          |     |     |     |        +--rw ospfv2-key?        string
          |     |     |     |        +--rw ospfv2-crypto-algorithm?
          |     |     |     |                identityref
          |     |     |     +--:(ospfv3-auth-ipsec)
          |     |     |     |      {ospfv3-authentication-ipsec}?
          |     |     |     |  +--rw sa?                       string
          |     |     |     +--:(ospfv3-auth-trailer)
          |     |     |        |  {ospfv3-authentication-trailer}?
          |     |     |        +--rw (ospfv3-auth-specification)?
          |     |     |           +--:(auth-key-chain) {key-chain}?
          |     |     |           |  +--rw ospfv3-key-chain?
          |     |     |           |          key-chain:key-chain-ref
          |     |     |           +--:(auth-key-explicit)
          |     |     |              +--rw ospfv3-sa-id?        uint16
          |     |     |              +--rw ospfv3-key?          string
          |     |     |              +--rw ospfv3-crypto-algorithm?
          |     |     |                      identityref
          |     |     +--rw cost?               ospf-link-metric
          |     |     +--rw mtu-ignore?         boolean
          |     |                               {mtu-ignore}?
          |     |     +--rw prefix-suppression? boolean
          |     |                               {prefix-suppression}?
          |     |     +--ro state?              if-state-type
          |     |     +--ro hello-timer?       rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro wait-timer?        rt-types:
          |     |     |                         rtimer-value-seconds16
          |     |     +--ro dr-router-id?       rt-types:router-id
          |     |     +--ro dr-ip-addr?         inet:ip-address
          |     |     +--ro bdr-router-id?      rt-types:router-id
          |     |     +--ro bdr-ip-addr?        inet:ip-address
          |     |     +--ro statistics
          |     |     |  +--ro discontinuity-time     yang:date-and-time
          |     |     |  +--ro if-event-count?        yang:counter32
          |     |     |  +--ro link-scope-lsa-count?  yang:gauge32
          |     |     |  +--ro link-scope-lsa-cksum-sum?
          |     |     |                               uint32
          |     |     |  +--ro database
          |     |     |     +--ro link-scope-lsa-type*
          |     |     |        +--ro lsa-type?        uint16
          |     |     |        +--ro lsa-count?       yang:gauge32
          |     |     |        +--ro lsa-cksum-sum?   uint32
          |     |     +--ro neighbors
          |     |     |  +--ro neighbor* [neighbor-router-id]
          |     |     |     +--ro neighbor-router-id
          |     |     |                           rt-types:router-id
          |     |     |     +--ro address?        inet:ip-address
          |     |     |     +--ro dr-router-id?   rt-types:router-id
          |     |     |     +--ro dr-ip-addr?     inet:ip-address
          |     |     |     +--ro bdr-router-id?  rt-types:router-id
          |     |     |     +--ro bdr-ip-addr?    inet:ip-address
          |     |     |     +--ro state?          nbr-state-type
          |     |     |     +--ro cost?           ospf-link-metric
          |     |     |     +--ro dead-timer? rt-types:
          |     |     |     |                  rtimer-value-seconds16
          |     |     |     +--ro statistics
          |     |     |        +--ro discontinuity-time?
          |     |     |                           yang:date-and-time
          |     |     |        +--ro nbr-event-count?
          |     |     |                           yang:counter32
          |     |     |        +--ro nbr-retrans-qlen?
          |     |     |                           yang:gauge32
          |     |     +--ro database
          |     |        +--ro link-scope-lsa-type* [lsa-type]
          |     |           +--ro lsa-type           uint16
          |     |           +--ro link-scope-lsas
          .     .
          .     .

2.7. Конфигурация и рабочее состояние интерфейса OSPF

Контейнер interface содержит конфигурацию и рабочее состояние интерфейса OSPF. Рабочее состояние интерфейса включает статистику интерфейса, список соседей и link-local LSDB.

   module: ietf-ospf
     augment /rt:routing/rt:control-plane-protocols/
              rt:control-plane-protocol:
       +--rw ospf
          .
          .
          +--rw areas
          |  +--rw area* [area-id]
          |     .
          |     .
          |     +--rw interfaces
          |        +--rw interface* [name]
          |           +--rw name                   if:interface-ref
          |           +--rw interface-type?        enumeration
          |           +--rw passive?               boolean
          |           +--rw demand-circuit?        boolean
          |                                        {demand-circuit}?
          |           +--rw priority?              uint8
          |           +--rw multi-areas {multi-area-adj}?
          |           |  +--rw multi-area* [multi-area-id]
          |           |     +--rw multi-area-id      area-id-type
          |           |     +--rw cost?              ospf-link-metric
          |           +--rw static-neighbors
          |           |  +--rw neighbor* [identifier]
          |           |     +--rw identifier       inet:ip-address
          |           |     +--rw cost?            ospf-link-metric
          |           |     +--rw poll-interval?   uint16
          |           |     +--rw priority?        uint8
          |           +--rw node-flag?             boolean
          |                                        {node-flag}?
          |           +--rw bfd {bfd}?
          |           |  +--rw enabled?            boolean
          |           |  +--rw local-multiplier?   multiplier
          |           |  |      {client-base-cfg-parms}?
          |           |  +--rw (interval-config-type)?
          |           |  |      {client-base-cfg-parms}?
          |           |     +--:(tx-rx-intervals)
          |           |     |  +--rw desired-min-tx-interval?  uint32
          |           |     |  +--rw required-min-rx-interval? uint32
          |           |     +--:(single-interval)
          |           |     |   {single-minimum-interval}?
          |           |        +--rw min-interval?             uint32
          |           +--rw fast-reroute {fast-reroute}?
          |           |  +--rw lfa {lfa}?
          |           |     +--rw candidate-enabled?  boolean
          |           |     +--rw enabled?            boolean
          |           |     +--rw remote-lfa {remote-lfa}?
          |           |        +--rw enabled?  boolean
          |           +--rw hello-interval?        uint16
          |           +--rw dead-interval?         uint32
          |           +--rw retransmit-interval?   uint16
          |           +--rw transmit-delay?        uint16
          |           +--rw lls?                   boolean {lls}?
          |           +--rw ttl-security {ttl-security}?
          |           |  +--rw enabled?  boolean
          |           |  +--rw hops?     uint8
          |           +--rw enabled?               boolean
          |           +--rw authentication
          |           |  +--rw (auth-type-selection)?
          |           |     +--:(ospfv2-auth)
          |           |     |  +--rw ospfv2-auth-trailer-rfc?
          |           |     |  |       ospfv2-auth-trailer-rfc-version
          |           |     |  |        {ospfv2-authentication-trailer}?
          |           |     |  +--rw (ospfv2-auth-specification)?
          |           |     |     +--:(auth-key-chain) {key-chain}?
          |           |     |     |  +--rw ospfv2-key-chain?
          |           |     |     |         key-chain:key-chain-ref
          |           |     |     +--:(auth-key-explicit)
          |           |     |        +--rw ospfv2-key-id?     uint32
          |           |     |        +--rw ospfv2-key?        string
          |           |     |        +--rw ospfv2-crypto-algorithm?
          |           |     |                identityref
          |           |     +--:(ospfv3-auth-ipsec)
          |           |     |      {ospfv3-authentication-ipsec}?
          |           |     |  +--rw sa?                       string
          |           |     +--:(ospfv3-auth-trailer)
          |           |        |  {ospfv3-authentication-trailer}?
          |           |        +--rw (ospfv3-auth-specification)?
          |           |           +--:(auth-key-chain) {key-chain}?
          |           |           |  +--rw ospfv3-key-chain?
          |           |           |          key-chain:key-chain-ref
          |           |           +--:(auth-key-explicit)
          |           |              +--rw ospfv3-sa-id?        uint16
          |           |              +--rw ospfv3-key?          string
          |           |              +--rw ospfv3-crypto-algorithm?
          |           |                      identityref
          |           +--rw cost?               ospf-link-metric
          |           +--rw mtu-ignore?         boolean
          |           |                         {mtu-ignore}?
          |           +--rw prefix-suppression? boolean
          |           |                         {prefix-suppression}?
          |           +--ro state?                 if-state-type
          |           +--ro hello-timer?       rt-types:
          |           |                         rtimer-value-seconds16
          |           +--ro wait-timer?        rt-types:
          |           |                         rtimer-value-seconds16
          |           +--ro dr-router-id?       rt-types:router-id
          |           +--ro dr-ip-addr?         inet:ip-address
          |           +--ro bdr-router-id?      rt-types:router-id
          |           +--ro bdr-ip-addr?        inet:ip-address
          |           +--ro statistics
          |           |  +--ro discontinuity-time?    yang:date-and-time
          |           |  +--ro if-event-count?        yang:counter32
          |           |  +--ro link-scope-lsa-count?  yang:gauge32
          |           |  +--ro link-scope-lsa-cksum-sum?
          |           |                               uint32
          |           |  +--ro database
          |           |     +--ro link-scope-lsa-type*
          |           |        +--ro lsa-type?        uint16
          |           |        +--ro lsa-count?       yang:gauge32
          |           |        +--ro lsa-cksum-sum?   int32
          |           +--ro neighbors
          |           |  +--ro neighbor* [neighbor-router-id]
          |           |     +--ro neighbor-router-id
          |           |                           rt-types:router-id
          |           |     +--ro address?        inet:ip-address
          |           |     +--ro dr-router-id?   rt-types:router-id
          |           |     +--ro dr-ip-addr?     inet:ip-address
          |           |     +--ro bdr-router-id?  rt-types:router-id
          |           |     +--ro bdr-ip-addr?    inet:ip-address
          |           |     +--ro state?          nbr-state-type
          |           |     +--ro dead-timer? rt-types:
          |           |     |                  rtimer-value-seconds16
          |           |     +--ro statistics
          |           |        +--ro discontinuity-time?
          |           |                           yang:date-and-time
          |           |        +--ro nbr-event-count?
          |           |                           yang:counter32
          |           |        +--ro nbr-retrans-qlen?
          |           |                           yang:gauge32
          |           +--ro database
          |           .  +--ro link-scope-lsa-type* [lsa-type]
          |           .     +--ro lsa-type           uint16
          |           .     +--ro link-scope-lsas
          .           .
          .           .
          |           +--rw topologies {ospf:multi-topology}?
          |           |  +--rw topology* [name]
          |           |     +--rw name  -> ../../../../../../../../
          |           |                    ../../../rt:ribs/rib/name
          |           |     +--rw cost? ospf-link-metric
          |           +--rw instance-id?           uint8
          .
          .

2.8. Уведомления OSPF

Эта модель YANG содержит все уведомления, информирующие клиентов YANG о важных событиях при работе протокола. Уведомления включают базовый набор ловушек (trap) из OSPFv2 MIB [RFC4750] и OSPFv3 MIB [RFC5643].

     notifications:
       +---n if-state-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro state?                   if-state-type
       +---n if-config-error
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro packet-source?           yang:dotted-quad
       |  +--ro packet-type?             packet-type
       |  +--ro error?                   enumeration
       +---n nbr-state-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro neighbor-router-id?      rt-types:router-id
       |  +--ro neighbor-ip-addr?        yang:dotted-quad
       |  +--ro state?                   nbr-state-type
       +---n nbr-restart-helper-status-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro neighbor-router-id?      rt-types:router-id
       |  +--ro neighbor-ip-addr?        yang:dotted-quad
       |  +--ro status?                  restart-helper-status-type
       |  +--ro age?                     rt-types:timer-value-seconds16
       |  +--ro exit-reason?             restart-exit-reason-type
       +---n if-rx-bad-packet
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro (if-link-type-selection)?
       |  |  +--:(interface)
       |  |  |  +--ro interface
       |  |  |     +--ro interface?   if:interface-ref
       |  |  +--:(virtual-link)
       |  |  |  +--ro virtual-link
       |  |  |     +--ro transit-area-id?      area-id-type
       |  |  |     +--ro neighbor-router-id?   rt-types:router-id
       |  |  +--:(sham-link)
       |  |     +--ro sham-link
       |  |        +--ro area-id?          area-id-type
       |  |        +--ro local-ip-addr?    inet:ip-address
       |  |        +--ro remote-ip-addr?   inet:ip-address
       |  +--ro packet-source?           yang:dotted-quad
       |  +--ro packet-type?             packet-type
       +---n lsdb-approaching-overflow
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro ext-lsdb-limit?          uint32
       +---n lsdb-overflow
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro ext-lsdb-limit?          uint32
       +---n nssa-translator-status-change
       |  +--ro routing-protocol-name?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol/name
       |  +--ro address-family?
       |  +     -> /rt:routing/control-plane-protocols/
       |  +         control-plane-protocol[rt:name=current()/../
       |  +         routing-protocol-name]/ospf/address-family
       |  +--ro area-id?                 area-id-type
       |  +--ro status?                  nssa-translator-state-type
       +---n restart-status-change
          +--ro routing-protocol-name?
          +     -> /rt:routing/control-plane-protocols/
          +         control-plane-protocol/name
          +--ro address-family?
          +     -> /rt:routing/control-plane-protocols/
          +         control-plane-protocol[rt:name=current()/../
          +         routing-protocol-name]/ospf/address-family
          +--ro status?                  restart-status-type
          +--ro restart-interval?        uint16
          +--ro exit-reason?             restart-exit-reason-type

2.9. Операции OSPF RPC

Модуль ietf-ospf задаёт две операции RPC.

clear-database

Сброс содержимого конкретной базы OSPF LSDB с переводом отношений смежности в состояние DOWN и повторным созданием собственных анонсов LSA.

clear-neighbor

Сброс конкретного соседа или группы соседей OSPF, связанных с интерфейсом OSPF.
     rpcs:
       +---x clear-neighbor
       |  +---w input
       |     +---w routing-protocol-name
       |     +     -> /rt:routing/control-plane-protocols/
       |     +         control-plane-protocol/name
       |     +---w interface?               if:interface-ref
       +---x clear-database
          +---w input
             +---w routing-protocol-name
                   -> /rt:routing/control-plane-protocols/
                       control-plane-protocol/name

3. Модуль YANG OSPF

Модуль YANG ietf-ospf ссылается на [RFC0905], [RFC1765], [RFC1793], [RFC2328], [RFC3101], [RFC3623], [RFC3630], [RFC4552], [RFC4576], [RFC4577], [RFC4915], [RFC4973], [RFC5082], [RFC5185], [RFC5187], [RFC5250], [RFC5286], [RFC5309], [RFC5329], [RFC5340], [RFC5443], [RFC5613], [RFC5642], [RFC5709], [RFC5714], [RFC5838], [RFC5880], [RFC5881], [RFC6565], [RFC6845], [RFC6860], [RFC6987], [RFC6991], [RFC7166], [RFC7474], [RFC7490], [RFC7684], [RFC7770], [RFC7777], [RFC7884], [RFC8177], [RFC8294], [RFC8343], [RFC8349], [RFC8405], [RFC8476], [RFC9314].

   <CODE BEGINS> file "ietf-ospf@2022-10-19.yang"
   module ietf-ospf {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ospf";

     prefix ospf;

     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 ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }

     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }

     import iana-routing-types {
       prefix iana-rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }

     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }

     import ietf-key-chain {
       prefix key-chain;
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     import ietf-bfd-types {
       prefix bfd-types;
       reference
         "RFC 9314: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }

     organization
       "IETF Link State Routing (lsr) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/lsr/> 
        WG List:  <mailto:lsr@ietf.org> 

        Editor:   Derek Yeung
                  <mailto:derek@arrcus.com> 
        Author:   Acee Lindem
                  <mailto:acee@cisco.com> 
        Author:   Yingzhen Qu
                  <mailto:yingzhen.qu@futurewei.com> 
        Author:   Jeffrey Zhang
                  <mailto:zzhang@juniper.net> 
        Author:   Ing-Wher Chen
                  <mailto:ingwherchen@mitre.org>"; 

     description
       "Этот модуль определяет базовую конфигурацию и рабочее состояние
        для протокола OSPF, общие для реализаций всех производителей.
        Предполагается, что производители будут расширять модуль, 
        задавая зависимые от реализации параметры и правила, например,
        карты и политику для маршрутов.

        Эта модель YANG соответствует архитектуре NMDA (RFC 8342).

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

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

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

     revision 2022-10-19 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9129: YANG Data Model for the OSPF Protocol";
     }

     feature multi-topology {
       description
         "Поддержка маршрутизации Multi-Topology (MT).";
       reference
         "RFC 4915: Multi-Topology (MT) Routing in OSPF";
     }

     feature multi-area-adj {
       description
         "Поддержка смежности с несколькими областями (RFC 5185).";
       reference
         "RFC 5185: OSPF Multi-Area Adjacency";
     }

     feature explicit-router-id {
       description
         "Явно задаёт Router ID на уровне экземпляра.";
     }

     feature demand-circuit {
       description
         "Поддержка устройств OSPF demand (RFC 1793).";
       reference
         "RFC 1793: Extending OSPF to Support Demand Circuits";
     }

     feature mtu-ignore {
       description
         "Запрет проверки несоответствия MTU для пакетов OSPF 
          Database Description, описанной в спецификации OSPFv2
          (RFC 2328). Проверка применима и к OSPFv3 (RFC 5340).";
       reference
         "RFC 2328: OSPF Version 2, Section 10.6
          RFC 5340: OSPF for IPv6";
     }

     feature lls {
       description
         "Сигнализация OSPF LLS, определённая в RFC 5613.";
       reference
         "RFC 5613: OSPF Link-Local Signaling";
     }

     feature prefix-suppression {
       description
         "Поддержка подавления префиксов OSPF, описанная в RFC 6860.";
       reference
         "RFC 6860: Hiding Transit-Only Networks in OSPF";
     }

     feature ttl-security {
       description
         "Поддержка проверки безопасности OSPF Time TTL.";
       reference
         "RFC 5082: The Generalized TTL Security Mechanism (GTSM)";
     }

     feature nsr {
       description
         "Поддержка безостановочной маршрутизации (NSR). Функция 
          позволяет маршрутизатору с избыточностью плоскости управления
          (например, с двойными платами RP) поддерживать своё состояние
          и смежности при плановом или неплановом перезапуске экземпляра
          OSPF. Это отличается от аккуратного перезапуска и 
          безостановочной пересылки (NSF) тем, что для восстановления
          состоянии плоскости управления не требуется протокол
          сигнализации или содействие соседей OSPF .";
     }

     feature graceful-restart {
       description
         "Аккуратный перезапуск OSPF в соответствии с RFC 3623 и 5187.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     feature auto-cost {
       description
         "Расчёт стоимости для интерфейса OSPF по эталонной пропускной
          способности.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     feature max-ecmp {
       description
         "Задаёт максимальное число путей ECMP.";
     }

     feature max-lsa {
       description
         "Максимальной число анонсов LSA, воспринимаемых экземпляром.";
       reference
         "RFC 1765: OSPF Database Overflow";
     }

     feature te-rid {
       description
         "Поддержка настройки TE Router ID, т. е. Router Address TLV 
          (параграф 2.4.1 в RFC 3630) или Router IPv6 Address TLV
          (раздел 3 в RFC 5329).";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to
          OSPF Version 2, Section 2.4.1
          RFC 5329: Traffic Engineering Extensions to OSPF Version 3,
          Section 3";
     }

     feature ldp-igp-sync {
       description
         "Синхронизация LDP IGP.";
       reference
         "RFC 5443: LDP IGP Synchronization";
     }

     feature ospfv2-authentication-trailer {
       description
         "Поддержка трейлера аутентификации OSPFv2.";
       reference
         "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication
          RFC 7474: Security Extension for OSPFv2 When
          Using Manual Key Management";
     }

     feature ospfv3-authentication-ipsec {
       description
         "Поддержка IPsec для аутентификации OSPFv3.";
       reference
         "RFC 4552: Authentication/Confidentiality for OSPFv3";
     }

     feature ospfv3-authentication-trailer {
       description
         "Поддержка трейлера аутентификации OSPFv3.";
       reference
         "RFC 7166: Supporting Authentication Trailer for OSPFv3";
     }

     feature fast-reroute {
       description
         "Поддержка IP Fast Reroute (IP-FRR).";
       reference
         "RFC 5714: IP Fast Reroute Framework";
     }

     feature key-chain {
       description
         "Поддержка цепочки ключей для аутентификации.";
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     feature node-flag {
       description
         "Поддержка флагов узла для префиксов OSPF.";
       reference
         "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
     }

     feature node-tag {
       description
         "Поддержка административных флагов узла для экземпляров 
          маршрутизации OSPF.";
       reference
         "RFC 7777: Advertising Node Administrative Tags in OSPF";
     }

     feature lfa {
       description
         "Поддержка Loop-Free Alternate (LFA).";
       reference
         "RFC 5286: Basic Specification for IP Fast Reroute:
          Loop-Free Alternates";
     }

     feature remote-lfa {
       description
         "Поддержка Remote LFA (R-LFA).";
       reference
         "RFC 7490: Remote Loop-Free Alternate (LFA) Fast Reroute
          (FRR)";
     }

     feature stub-router {
       description
         "Поддержка анонсов тупиковых маршрутизаторов OSPF (RFC 6987).";
       reference
         "RFC 6987: OSPF Stub Router Advertisement";
     }

     feature pe-ce-protocol {
       description
         "Поддержка OSPF в качестве протокола PE-CE.";
       reference
         "RFC 4577: OSPF as the Provider/Customer Edge Protocol
          for BGP/MPLS IP Virtual Private Networks (VPNs)
          RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE)
          Routing Protocol";
     }

     feature ietf-spf-delay {
       description
         "Поддержка алгоритма задержки IETF SPF.";
       reference
         "RFC 8405: Shortest Path First (SPF) Back-Off Delay Algorithm
          for Link-State IGPs";
     }

     feature bfd {
       description
         "Поддержка BFD для обнаружения доступности соседей OSPF.";
       reference
         "RFC 5880: Bidirectional Forwarding Detection (BFD)
          RFC 5881: Bidirectional Forwarding Detection
          (BFD) for IPv4 and IPv6 (Single Hop)";
     }

     feature hybrid-interface {
       description
         "Поддержка гибридных интерфейсов OSPF.";
       reference
         "RFC 6845: OSPF Hybrid Broadcast and
          Point-to-Multipoint Interface Type";
     }

     identity ospf {
       base rt:routing-protocol;
       description
         "Любая версия протокола OSPF.";
     }

     identity ospfv2 {
       base ospf;
       description
         "Протокол OSPFv2.";
     }

     identity ospfv3 {
       base ospf;
       description
         "Протокол OSPFv3.";
     }

     identity area-type {
       description
         "Базовый идентификатор для типа области OSPF.";
     }

     identity normal-area {
       base area-type;
       description
         "Обычная область OSPF.";
     }

     identity stub-nssa-area {
       base area-type;
       description
         "Тупиковая или NSSA область OSPF.";
     }

     identity stub-area {
       base stub-nssa-area;
       description
         "Тупиковая область OSPF.";
     }

     identity nssa-area {
       base stub-nssa-area;
       description
         "OSPF NSSA.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity ospf-lsa-type {
       description
         "Базовый идентификатор типов LSA для OSPFv2 и OSPFv3.";
     }

     identity ospfv2-lsa-type {
       base ospf-lsa-type;
       description
         "Типы OSPFv2 LSA.";
     }

     identity ospfv2-router-lsa {
       base ospfv2-lsa-type;
       description
         "OSPFv2 Router-LSA - тип 1.";
     }

     identity ospfv2-network-lsa {
       base ospfv2-lsa-type;
       description
         "OSPFv2 Network-LSA - тип 2.";
     }

     identity ospfv2-summary-lsa-type {
       base ospfv2-lsa-type;
       description
         "Типы OSPFv2 summary LSA.";
     }

     identity ospfv2-network-summary-lsa {
       base ospfv2-summary-lsa-type;
       description
         "OSPFv2 Network summary LSA - тип 3.";
     }

     identity ospfv2-asbr-summary-lsa {
       base ospfv2-summary-lsa-type;
       description
         "OSPFv2 ASBR summary LSA - тип 4.";
     }

     identity ospfv2-external-lsa-type {
       base ospfv2-lsa-type;
       description
         "OSPFv2 External-LSA.";
     }

     identity ospfv2-as-external-lsa {
       base ospfv2-external-lsa-type;
       description
         "OSPFv2 AS-External-LSA - тип 5.";
     }

     identity ospfv2-nssa-lsa {
       base ospfv2-external-lsa-type;
       description
         "OSPFv2 NSSA-LSA - тип 7.";
     }

     identity ospfv2-opaque-lsa-type {
       base ospfv2-lsa-type;
       description
         "Типы OSPFv2 Opaque-LSA.";
       reference
         "RFC 5250: The OSPF Opaque LSA Option";
     }

     identity ospfv2-link-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 Link-Scope Opaque-LSA - тип 9.";
     }

     identity ospfv2-area-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 Area-Scope Opaque-LSA - тип 10.";
     }

     identity ospfv2-as-scope-opaque-lsa {
       base ospfv2-opaque-lsa-type;
       description
         "OSPFv2 AS-Scope Opaque-LSA - тип 11.";
     }

     identity ospfv2-unknown-lsa-type {
       base ospfv2-lsa-type;
       description
         "Неизвестный тип OSPFv2 LSA.";
     }

     identity ospfv3-lsa-type {
       base ospf-lsa-type;
       description
         "Типы OSPFv3 LSA.";
       reference
         "RFC 5340: OSPF for IPv6";
     }

     identity ospfv3-router-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Router-LSA - тип 0x2001.";
     }

     identity ospfv3-network-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Network-LSA - тип 0x2002.";
     }

     identity ospfv3-summary-lsa-type {
       base ospfv3-lsa-type;
       description
         "Типы OSPFv3 summary LSA.";
     }

     identity ospfv3-inter-area-prefix-lsa {
       base ospfv3-summary-lsa-type;
       description
         "OSPFv3 Inter-Area-Prefix-LSA - тип 0x2003.";
     }

     identity ospfv3-inter-area-router-lsa {
       base ospfv3-summary-lsa-type;
       description
         "OSPFv3 Inter-Area-Router-LSA - тип 0x2004.";
     }

     identity ospfv3-external-lsa-type {
       base ospfv3-lsa-type;
       description
         "Типы OSPFv3 External-LSA.";
     }

     identity ospfv3-as-external-lsa {
       base ospfv3-external-lsa-type;
       description
         "OSPFv3 AS-External-LSA - тип 0x4005.";
     }

     identity ospfv3-nssa-lsa {
       base ospfv3-external-lsa-type;
       description
         "OSPFv3 NSSA-LSA - тип 0x2007.";
     }

     identity ospfv3-link-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Link-LSA - тип 0x0008.";
     }

     identity ospfv3-intra-area-prefix-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Intra-Area-Prefix-LSA - тип 0x2009.";
     }

     identity ospfv3-router-information-lsa {
       base ospfv3-lsa-type;
       description
         "OSPFv3 Router-Information-LSA - тип 0x800C, 0xA00C, 0xC00C.";
     }

     identity ospfv3-unknown-lsa-type {
       base ospfv3-lsa-type;
       description
         "Неизвестный тип OSPFv3 LSA.";
     }

     identity lsa-log-reason {
       description
         "Базовый идентификатор для причины записи LSA.";
     }

     identity lsa-refresh {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате приёма обновления LSA.";
     }

     identity lsa-content-change {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате изменения содержимого.";
     }

     identity lsa-purge {
       base lsa-log-reason;
       description
         "Идентификатор записи LSA в результате очистки.";
     }

     identity informational-capability {
       description
         "Базовый идентификатор возможностей маршрутизатора.";
     }

     identity graceful-restart {
       base informational-capability;
       description
         "Маршрутизатор поддерживает аккуратный перезапуск.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     identity graceful-restart-helper {
       base informational-capability;
       description
         "Маршрутизатор способен помогать аккуратному перезапуску.";
       reference
         "RFC 3623: Graceful OSPF Restart
          RFC 5187: OSPFv3 Graceful Restart";
     }

     identity stub-router {
       base informational-capability;
       description
         "Маршрутизатор способен быть тупиковым OSPF stub.";
       reference
         "RFC 6987: OSPF Stub Router Advertisement";
     }

     identity traffic-engineering {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать OSPF TE.";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to
          OSPF Version 2
          RFC 5329: Traffic Engineering Extensions to OSPF Version 3";
     }

     identity p2p-over-lan {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать соединения OSPF «точка-точка»
          через ЛВС.";
       reference
         "RFC 5309: Point-to-Point Operation over LAN in Link State
          Routing Protocols";
     }

     identity experimental-te {
       base informational-capability;
       description
         "Маршрутизатор может поддерживать экспериментальный OSPF TE.";
       reference
         "RFC 4973: OSPF-xTE: Experimental Extension to OSPF for
          Traffic Engineering";
     }

     identity router-lsa-bit {
       description
         "Базовый идентификатор для битов Router-LSA.";
     }

     identity vlink-end-bit {
       base router-lsa-bit;
       description
         "Бит V, указывающий, что маршрутизатор является конечной
          точкой одного или нескольких виртуальных каналов.";
     }

     identity asbr-bit {
       base router-lsa-bit;
       description
         "Бит E, указывающий, что маршрутизатор является ASBR.";
     }

     identity abr-bit {
       base router-lsa-bit;
       description
         "Бит B, указывающий, что маршрутизатор является ABR.";
     }

     identity nssa-bit {
       base router-lsa-bit;
       description
         "Бит Nt, указывающий, что маршрутизатор является граничным для
          NSSA и безусловно транслирует NSSA-LSA в AS-External-LSA.";
     }

     identity ospfv3-lsa-option {
       description
         "базовый идентификатор для опций OSPF LSA.";
     }

     identity af-bit {
       base ospfv3-lsa-option;
       description
         "Бит AF, указывающий поддержку маршрутизатором семейств адресов
          OSPFv3, как описано в RFC 5838.";
       reference
         "RFC 5838: Support of Address Families in OSPFv3";
     }

     identity dc-bit {
       base ospfv3-lsa-option;
       description
         "Бит DC, указывающий поддержку demand-устройств.";
     }

     identity r-bit {
       base ospfv3-lsa-option;
       description
         "Бит R, указывающий активность инициатора.";
     }

     identity n-bit {
       base ospfv3-lsa-option;
       description
         "Бит N, указывающий подключение маршрутизатора к NSSA.";
     }

     identity e-bit {
       base ospfv3-lsa-option;
       description
         "Бит E, описывающий способ лавинной рассылки AS-External-LSA.";
     }

     identity v6-bit {
       base ospfv3-lsa-option;
       description
         "Бит V6, сброс которого исключает маршрутизатор/канал из
          расчётов маршрутизации IPv6.";
     }

     identity ospfv3-prefix-option {
       description
         "Базовый идентификатор для опций префиксов OSPFv3.";
     }

     identity nu-bit {
       base ospfv3-prefix-option;
       description
         "Бит NU, указывающий исключение префикса из расчётов 
          IPv6 unicast.";
     }

     identity la-bit {
       base ospfv3-prefix-option;
       description
         "Бит LA, указывающий, что префикс является адресом IPv6
          интерфейса анонсирующего маршрутизатора.";
     }

     identity p-bit {
       base ospfv3-prefix-option;
       description
         "Бит P, указывающий, что префикс NSSA следует транслировать в
          AS-External-LSA и анонсировать транслирующему граничному
          маршрутизатору NSSA.";
     }

     identity dn-bit {
       base ospfv3-prefix-option;
       description
         "Бит DN, указывающий, что Inter-Area-Prefix-LSA или префикс
          AS-External-LSA анонсируется как префикс L3VPN.";
     }

     identity ospfv2-lsa-option {
       description
         "базовый идентификатор для опций OSPFv2 LSA.";
     }

     identity mt-bit {
       base ospfv2-lsa-option;
       description
         "Бит MT, указывающий что маршрутизатор поддерживает несколько
          топологий, как описано в RFC 4915.";
       reference
         "RFC 4915: Multi-Topology (MT) Routing in OSPF";
     }

     identity v2-dc-bit {
       base ospfv2-lsa-option;
       description
         "Бит DC, указывающий поддержку demand-устройств.";
     }

     identity v2-p-bit {
       base ospfv2-lsa-option;
       description
         "Бит P, используемый только для LSA типа 7 и указывающий, что
          граничному маршрутизатору NSSA следует транслировать LSA типа
          7 в LSA типа 5.";
     }

     identity mc-bit {
       base ospfv2-lsa-option;
       description
         "Бит MC, указывающий поддержку маршрутизатором MOSPF.";
     }

     identity v2-e-bit {
       base ospfv2-lsa-option;
       description
         "Бит E, описывающий способ лавинной рассылки AS-External-LSA.";
     }

     identity o-bit {
       base ospfv2-lsa-option;
       description
         "Бит O, указывающий поддержку опции Opaque LSA (RFC 5250).";
       reference
         "RFC 5250: The OSPF Opaque LSA Option";
     }

     identity v2-dn-bit {
       base ospfv2-lsa-option;
       description
         "Бит DN, который должен устанавливаться при передаче LSA типов
          3, 5, 7 от PE к CE (RFC 4576).";
       reference
         "RFC 4576: Using a Link State Advertisement (LSA) Options Bit
          to Prevent Looping in BGP/MPLS IP Virtual Private Networks
          (VPNs)";
     }

     identity ospfv2-extended-prefix-flag {
       description
         "Базовый идентификатор для флага Extended Prefix TLV.";
     }

     identity a-flag {
       base ospfv2-extended-prefix-flag;
       description
         "Флаг присоединения, указывающий что префикс соответствует
          маршруту, напрямую соединённому с анонсирующим 
          маршрутизатором.";
     }

     identity node-flag {
       base ospfv2-extended-prefix-flag;
       description
         "Флаг узла, указывающий, что префикс служит для представления
          анонсирующего узла (т. е. адреса loopback.";
     }

     typedef ospf-metric {
       type uint32 {
         range "0 .. 16777215";
       }
       description
         "Метрика OSPF. 24-битовое целое число без знака.";
     }

     typedef ospf-link-metric {
       type uint16 {
         range "0 .. 65535";
       }
       description
         "метрика канала OSPF.  16-битовое целое число без знака .";
     }

     typedef opaque-id {
       type uint32 {
         range "0 .. 16777215";
       }
       description
         "Opaque-LSA ID. 24-битовое целое число без знака .";
     }

     typedef area-id-type {
       type yang:dotted-quad;
       description
         "Тип Area ID.";
     }

     typedef route-type {
       type enumeration {
         enum intra-area {
           description
             "Внутриобластной маршрут OSPF.";
         }
         enum inter-area {
           description
             "Межобластной маршрут OSPF.";
         }
         enum external-1 {
           description
             "Внешний маршрут OSPF типа 1.";
         }
         enum external-2 {
           description
             "Внешний маршрут OSPF типа 2.";
         }
         enum nssa-1 {
           description
             "Маршрут OSPF NSSA типа 1.";
         }
         enum nssa-2 {
           description
             "Маршрут OSPF NSSA типа 2.";
         }
       }
       description
         "Тип маршрута OSPF.";
     }

     typedef if-state-type {
       type enumeration {
         enum down {
           value 1;
           description
             "Интерфейс в состоянии Down.";
         }
         enum loopback {
           value 2;
           description
             "Интерфейс в состоянии Loopback.";
         }
         enum waiting {
           value 3;
           description
             "Интерфейс в состоянии Waiting.";
         }
         enum point-to-point {
           value 4;
           description
             "Интерфейс в состоянии Point-to-point.";
         }
         enum dr {
           value 5;
           description
             "Интерфейс в состоянии DR.";
         }
         enum bdr {
           value 6;
           description
             "Интерфейс в состоянии Backup.";
         }
         enum dr-other {
           value 7;
           description
             "Интерфейс в состоянии DR Other.";
         }
       }
       description
         "Тип состояния интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     typedef router-link-type {
       type enumeration {
         enum point-to-point-link {
           value 1;
           description
             "Канал «точка-точка» к другому маршрутизатору.";
         }
         enum transit-network-link {
           value 2;
           description
             "Канал в транзитную сеть, указанную DR.";
         }
         enum stub-network-link {
           value 3;
           description
             "Канал в тупиковую сеть (stub), указанную подсетью.";
         }
         enum virtual-link {
           value 4;
           description
             "Виртуальный канал через транзитную область.";
         }
       }
       description
         "Тип канала маршрутизатора OSPF.";
     }

     typedef nbr-state-type {
       type enumeration {
         enum down {
           value 1;
           description
             "Сосед в состоянии Down.";
         }
         enum attempt {
           value 2;
           description
             "Сосед в состоянии Attempt.";
         }
         enum init {
           value 3;
           description
             "Сосед в состоянии Init.";
         }
         enum 2-way {
           value 4;
           description
             "Сосед в состоянии 2-Way.";
         }
         enum exstart {
           value 5;
           description
             "Сосед в состоянии ExStart (начало обмена).";
         }
         enum exchange {
           value 6;
           description
             "Сосед в состоянии Exchange.";
         }
         enum loading {
           value 7;
           description
             "Сосед в состоянии Loading.";
         }
         enum full {
           value 8;
           description
             "Сосед в состоянии Full.";
         }
       }
       description
         "Тип состояния соседа OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     typedef restart-helper-status-type {
       type enumeration {
         enum not-helping {
           value 1;
           description
             "Состояние помощника в перезапуске not-helping.";
         }
         enum helping {
           value 2;
           description
             "Состояние помощника в перезапуске helping.";
         }
       }
       description
         "Состояние помощника в перезапуске.";
     }

     typedef restart-exit-reason-type {
       type enumeration {
         enum none {
           value 1;
           description
             "Перезапуск не предпринимался.";
         }
         enum in-progress {
           value 2;
           description
             "Перезапуск выполняется.";
         }
         enum completed {
           value 3;
           description
             "Перезапуск завершен.";
         }
         enum timed-out {
           value 4;
           description
             "Тайм-аут при перезапуске.";
         }
         enum topology-changed {
           value 5;
           description
             "Перезапуск прерван из-за изменения топологии.";
         }
       }
       description
         "Описывает результат последней попытки аккуратного перезапуска.
          Локальный маршрутизатор перезапускается или помогает.";
     }

     typedef packet-type {
       type enumeration {
         enum hello {
           value 1;
           description
             "Пакет OSPF Hello.";
         }
         enum database-description {
           value 2;
           description
             "Пакет OSPF Database Description.";
         }
         enum link-state-request {
           value 3;
           description
             "Пакет OSPF Link State Request.";
         }
         enum link-state-update {
           value 4;
           description
             "Пакет OSPF Link State Update.";
         }
         enum link-state-ack {
           value 5;
           description
             "Пакет OSPF Link State Acknowledgment.";
         }
       }
       description
         "Типы пакетов OSPF.";
     }

     typedef nssa-translator-state-type {
       type enumeration {
         enum enabled {
           value 1;
           description
             "NSSATranslatorState enabled.";
         }
         enum elected {
           value 2;
           description
             "NSSATranslatorState elected.";
         }
         enum disabled {
           value 3;
           description
             "NSSATranslatorState disabled.";
         }
       }
       description
         "Тип состояния транслятора OSPF NSSA.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     typedef restart-status-type {
       type enumeration {
         enum not-restarting {
           value 1;
           description
             "Маршрутизатор не перезапускается.";
         }
         enum planned-restart {
           value 2;
           description
             "Маршрутизатор выполняет плановый перезапуск.";
         }
         enum unplanned-restart {
           value 3;
           description
             "Маршрутизатор выполняет неплановый перезапуск.";
         }
       }
       description
         "Тип состояния аккуратного перезапуска OSPF.";
     }

     typedef fletcher-checksum16-type {
       type string {
         pattern '(0x)?[0-9a-fA-F]{4}';
       }
       description
         "16-битовая контрольная сумма Fletcher в форме строки 0xXXXX.";
       reference
         "RFC 905: ISO Transport Protocol Specification ISO DP 8073";
     }

     typedef ospfv2-auth-trailer-rfc-version {
       type enumeration {
         enum rfc5709 {
           description
             "Поддержка трейлера аутентификации OSPF RFC 5709.";
           reference
             "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication";
         }
         enum rfc7474 {
           description
             "Поддержка трейлера аутентификации OSPF RFC 7474.";
           reference
             "RFC 7474: Security Extension for OSPFv2
              When Using Manual Key Management";
         }
       }
       description
         "Поддержка трейлера аутентификации OSPFv2.";
     }

     grouping tlv {
       description
         "Тип-Размер-Значение (Type-Length-Value или TLV).";
       leaf type {
         type uint16;
         description
           "Тип TLV.";
       }
       leaf length {
         type uint16;
         description
           "Размер TLV в октетах.";
       }
       leaf value {
         type yang:hex-string;
         description
           "Значение TLV.";
       }
     }

     grouping unknown-tlvs {
       description
         "Группировка служит для неизвестных TLV и суб-TLV.";
       container unknown-tlvs {
         description
           "Все неизвестные TLV.";
         list unknown-tlv {
           description
             "Неизвестный TLV.";
           uses tlv;
         }
       }
     }

     grouping node-tag-tlv {
       description
         "Группировка OSPF Node Admin Tag TLV.";
       list node-tag {
         leaf tag {
           type uint32;
           description
             "Значение административного тега узла.";
         }
         description
           "Список тегов.";
       }
     }

     grouping router-capabilities-tlv {
       description
         "Группировка для TLV возможностей маршрутизатора OSPF.";
       reference
         "RFC 7770: Extensions to OSPF for Advertising Optional
          Router Capabilities";
       container router-informational-capabilities {
         leaf-list informational-capabilities {
           type identityref {
             base informational-capability;
           }
           description
             "Список идентификаторов поддерживаемых маршрутизатором 
              информационных возможностей.";
         }
         description
           "Определения OSPF Router Informational Flag.";
       }
       list informational-capabilities-flags {
         leaf informational-flag {
           type uint32;
           description
             "Флаг отдельной информационной возможности.";
         }
         description
           "Список флагов информационных возможностей. Возвращаются все
            32-битовые информационные флаги, независимо от их
            известности устройству.";
       }
       list functional-capabilities {
         leaf functional-flag {
           type uint32;
           description
             "Флаг отдельной функциональной возможности.";
         }
         description
           "Список флагов функциональных возможностей. Возвращаются все
            32-битовые функциональные флаги, независимо от их
            известности устройству.";
       }
     }

     grouping dynamic-hostname-tlv {
       description
         "TLV динамического имени хоста.";
       reference
         "RFC 5642: Dynamic Hostname Exchange Mechanism for OSPF";
       leaf hostname {
         type string {
           length "1..255";
         }
         description
           "Динамическое имя хоста.";
       }
     }

     grouping sbfd-discriminator-tlv {
       description
         "S-BFD Discriminator TLV.";
       reference
         "RFC 7884: OSPF Extensions to Advertise Seamless Bidirectional
          Forwarding Detection (S-BFD) Target Discriminators";
       list sbfd-discriminators {
         leaf sbfd-discriminator {
           type uint32;
           description
             "Индивидуальный S-BFD Discriminator.";
         }
         description
           "Список дискриминаторов S-BFD.";
       }
     }

     grouping maximum-sid-depth-tlv {
       description
         "TLV узла для Maximum SID Depth (MSD).";
       reference
         "RFC 8476: Signaling Maximum SID Depth (MSD) Using OSPF";
       list msd-type {
         leaf msd-type {
           type uint8;
           description
             "Тип MSD.";
         }
         leaf msd-value {
           type uint8;
           description
             "Значение MSD для типа.";
         }
         description
           "Список кортежей MSD.";
       }
     }

     grouping ospf-router-lsa-bits {
       container router-bits {
         leaf-list rtr-lsa-bits {
           type identityref {
             base router-lsa-bit;
           }
           description
             "Список битов Router-LSA, содержащий идентификаторы для 
              всех битов, установленных в Router-LSA.";
         }
         description
           "Биты Router-LSA.";
       }
       description
         "Биты Router-LSA. В настоящее время одинаковы для OSPFv2 и
          OSPFv3, но могут быть разделены будущими дополнениями.";
     }

     grouping ospfv2-router-link {
       description
         "Канал маршрутизатора OSPFv2.";
       leaf link-id {
         type union {
           type inet:ipv4-address;
           type yang:dotted-quad;
         }
         description
           "Router-LSA Link ID.";
       }
       leaf link-data {
         type union {
           type inet:ipv4-address;
           type uint32;
         }
         description
           "Данные канала Router-LSA.";
       }
       leaf type {
         type router-link-type;
         description
           "Тип канала Router-LSA.";
       }
     }

     grouping ospfv2-lsa-body {
       description
         "Тело OSPFv2 LSA.";
       container router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv2-router-lsa')" {
           description
             "Применимо только к Router-LSA.";
         }
         description
           "Router-LSA.";
         uses ospf-router-lsa-bits;
         leaf num-of-links {
           type uint16;
           description
             "Число каналов в Router-LSA.";
         }
         container links {
           description
             "Все каналы маршрутизатора.";
           list link {
             description
               "Канал Router-LSA.";
             uses ospfv2-router-link;
             container topologies {
               description
                 "Все топологии для канала.";
               list topology {
                 description
                   "Зависящая от топологии информация.";
                 leaf mt-id {
                   type uint8;
                   description
                     "MT-ID для топологии разрешён на канале.";
                 }
                 leaf metric {
                   type uint16;
                   description
                     "Метрика для топологии.";
                 }
               }
             }
           }
         }
       }
       container network {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv2-network-lsa')" {
           description
             "Применимо только к Network-LSA.";
         }
         description
           "Network-LSA.";
         leaf network-mask {
           type yang:dotted-quad;
           description
             "Маска IP-адреса для сети.";
         }
         container attached-routers {
           description
             "Все присоединённые маршрутизаторы.";
           leaf-list attached-router {
             type inet:ipv4-address;
             description
               "Список маршрутизаторов, присоединённых к сети.";
           }
         }
       }
       container summary {
         when "derived-from(../../header/type, "
            + "'ospfv2-summary-lsa-type')" {
           description
             "Применимо только к summary LSA.";
         }
         description
           "Summary LSA.";
         leaf network-mask {
           type inet:ipv4-address;
           description
             "Маска IP-адреса для сети.";
         }
         container topologies {
           description
             "Все топологии для summary LSA.";
           list topology {
             description
               "Зависящая от топологии информация.";
             leaf mt-id {
               type uint8;
               description
                 "MT-ID для топологии разрешён в summary.";
             }
             leaf metric {
               type ospf-metric;
               description
                 "Метрика для топологии.";
             }
           }
         }
       }
       container external {
         when "derived-from(../../header/type, "
            + "'ospfv2-external-lsa-type')" {
           description
             "Применимо только к AS-External-LSA и NSSA-LSA.";
         }
         description
           "External-LSA.";
         leaf network-mask {
           type inet:ipv4-address;
           description
             "Маска IP-адреса для сети.";
         }
         container topologies {
           description
             "Все топологии для External-LSA.";
           list topology {
             description
               "Зависящая от топологии информация.";
             leaf mt-id {
               type uint8;
               description
                 "MT-ID для топологии разрешён для внешних и
                  NSSA-префиксов.";
             }
             leaf flags {
               type bits {
                 bit E {
                   description
                     "Указывает внешнюю метрику типа 2.";
                 }
               }
               description
                 "Флаги топологии.";
             }
             leaf metric {
               type ospf-metric;
               description
                 "Метрика для топологии.";
             }
             leaf forwarding-address {
               type inet:ipv4-address;
               description
                 "Адрес IPv4 Forwarding.";
             }
             leaf external-route-tag {
               type uint32;
               description
                 "Флаг маршрута для топологии.";
             }
           }
         }
       }
       container opaque {
         when "derived-from(../../header/type, "
            + "'ospfv2-opaque-lsa-type')" {
           description
             "Применимо только для Opaque-LSA.";
         }
         description
           "Opaque-LSA.";

         container ri-opaque {
           description
             "OSPF Router-Information-Opaque-LSA.";
           reference
             "RFC 7770: Extensions to OSPF for Advertising Optional
              Router Capabilities";

           container router-capabilities-tlv {
             description
               "Информационные и функциональные возможности 
                маршрутизатора.";
             uses router-capabilities-tlv;
           }

           container node-tag-tlvs {
             description
               "Все Node Admin Tag TLV.";
             list node-tag-tlv {
               description
                 "Node Admin Tag TLV.";
               uses node-tag-tlv;
             }
           }

           container dynamic-hostname-tlv {
             description
               "OSPF Dynamic Hostname TLV.";
             uses dynamic-hostname-tlv;
           }

           container sbfd-discriminator-tlv {
             description
               "OSPF S-BFD Discriminator TLV.";
             uses sbfd-discriminator-tlv;
           }

           container maximum-sid-depth-tlv {
             description
               "OSPF Node MSD TLV.";
             uses maximum-sid-depth-tlv;
           }
           uses unknown-tlvs;
         }

         container te-opaque {
           description
             "OSPFv2 TE Opaque-LSA.";
           reference
             "RFC 3630: Traffic Engineering (TE) Extensions to
              OSPF Version 2";

           container router-address-tlv {
             description
               "TLV с адресом маршрутизатора.";
             leaf router-address {
               type inet:ipv4-address;
               description
                 "Адрес маршрутизатора.";
             }
           }

           container link-tlv {
             description
               "Описывает один канал и состоит из набора суб-TLV.";
             leaf link-type {
               type router-link-type;
               mandatory true;
               description
                 "Тип канала.";
             }
             leaf link-id {
               type union {
                 type inet:ipv4-address;
                 type yang:dotted-quad;
               }
               mandatory true;
               description
                 "Link ID.";
             }
             container local-if-ipv4-addrs {
               description
                 "Все адреса IPv4 локального интерфейса.";
               leaf-list local-if-ipv4-addr {
                 type inet:ipv4-address;
                 description
                   "Список адресов IPv4 локального интерфейса.";
               }
             }
             container remote-if-ipv4-addrs {
               description
                 "Все адреса IPv4 удалённого интерфейса.";
               leaf-list remote-if-ipv4-addr {
                 type inet:ipv4-address;
                 description
                   "Список адресов IPv4 удалённого интерфейса.";
               }
             }
             leaf te-metric {
               type uint32;
               description
                 "TE metric.";
             }
             leaf max-bandwidth {
               type rt-types:bandwidth-ieee-float32;
               description
                 "Максимальная пропускная способность.";
             }
             leaf max-reservable-bandwidth {
               type rt-types:bandwidth-ieee-float32;
               description
                 "Максимальная резервируемая пропускная способность.";
             }
             container unreserved-bandwidths {
               description
                 "Вся незарезервированная пропускная способность.";
               list unreserved-bandwidth {
                 leaf priority {
                   type uint8 {
                     range "0 .. 7";
                   }
                   description
                     "Приоритет от 0 до 7.";
                 }
                 leaf unreserved-bandwidth {
                   type rt-types:bandwidth-ieee-float32;
                   description
                     "Незарезервированная пропускная способность.";
                 }
                 description
                   "Список значение незарезервированной пропускной
                    способности для разных приоритетов.";
               }
             }
             leaf admin-group {
               type uint32;
               description
                 "Административная группа-Класс ресурсов-Цвет.";
             }
             uses unknown-tlvs;
           }
         }

         container extended-prefix-opaque {
           description
             "Все Extended Prefix TLV в LSA.";
           list extended-prefix-tlv {
             description
               "Extended Prefix TLV.";
             leaf route-type {
               type enumeration {
                 enum unspecified {
                   value 0;
                   description
                     "Не задано.";
                 }
                 enum intra-area {
                   value 1;
                   description
                     "Маршрут внутри области OSPF.";
                 }
                 enum inter-area {
                   value 3;
                   description
                     "Маршрут между областями OSPF.";
                 }
                 enum external {
                   value 5;
                   description
                     "Внешний маршрут OSPF.";
                 }
                 enum nssa {
                   value 7;
                   description
                     "Внешний маршрут OSPF NSSA.";
                 }
               }
               description
                 "Тип маршрута.";
             }
             container flags {
               leaf-list extended-prefix-flags {
                 type identityref {
                   base ospfv2-extended-prefix-flag;
                 }
                 description
                   "Список флагов Extended Prefix TLV, содержащий
                    идентификаторы для флагов префикса, устанавливаемые
                    во флагах расширенного префикса.";
               }
               description
                 "Флаги префикса.";
             }
             leaf prefix {
               type inet:ip-prefix;
               description
                 "Адресный префикс.";
             }
             uses unknown-tlvs;
           }
         }

         container extended-link-opaque {
           description
             "Все Extended Link TLV в LSA.";
           reference
             "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
           container extended-link-tlv {
             description
               "Extended Link TLV.";
             uses ospfv2-router-link;
             container maximum-sid-depth-tlv {
               description
                 "OSPF Node MSD TLV.";
               uses maximum-sid-depth-tlv;
             }
             uses unknown-tlvs;
           }
         }
       }
     }

     grouping ospfv3-lsa-options {
       description
         "Опции OSPFv3 LSA.";
       container lsa-options {
         leaf-list lsa-options {
           type identityref {
             base ospfv3-lsa-option;
           }
           description
             "Список опций OSPFv3 LSA, содержащий идентификаторы
              OSPFv3 LSA Option, устанавливаемых для LSA.";
         }
         description
           "Опции OSPFv3 LSA.";
       }
     }

     grouping ospfv3-lsa-prefix {
       description
         "Префикс OSPFv3 LSA.";

       leaf prefix {
         type inet:ip-prefix;
         description
           "Префикс LSA.";
       }
       container prefix-options {
         leaf-list prefix-options {
           type identityref {
             base ospfv3-prefix-option;
           }
           description
             "Список опций префиксов OSPFv3, содержащий идентификаторы
              опций OSPFv3, устанавливаемых для префикса OSPFv3.";
         }
         description
           "Опции префикса.";
       }
     }

     grouping ospfv3-lsa-external {
       description
         "AS-External-LSA or NSSA-LSA.";
       leaf metric {
         type ospf-metric;
         description
           "Метрика AS-External-LSA или NSSA-LSA.";
       }
       leaf flags {
         type bits {
           bit E {
             description
               "Указывает внешнюю метрику типа 2.";
           }
           bit F {
             description
               "Указывает включение пересылающего адреса в LSA.";
           }
           bit T {
             description
               "Указывает включение тега внешнего маршрута в LSA.";
           }
         }
         description
           "Флаги AS-External-LSA или NSSA-LSA.";
       }

       leaf referenced-ls-type {
         type identityref {
           base ospfv3-lsa-type;
         }
         description
           "Referenced Link State (LS) Type.";
         reference
           "RFC 5340: OSPF for IPv6";
       }
       leaf unknown-referenced-ls-type {
         type uint16;
         description
           "Значение для неизвестного Referenced LS Type.";
       }

       uses ospfv3-lsa-prefix;

       leaf forwarding-address {
         type inet:ipv6-address;
         description
           "Адрес IPv6 Forwarding.";
       }

       leaf external-route-tag {
         type uint32;
         description
           "Тег маршрута.";
       }
       leaf referenced-link-state-id {
         type uint32;
         description
           "Referenced Link State ID.";
         reference
           "RFC 5340: OSPF for IPv6";
       }
     }

     grouping ospfv3-lsa-body {
       description
         "Тело OSPFv3 LSA.";
       container router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-router-lsa')" {
           description
             "Применимо лишь к Router-LSA.";
         }
         description
           "Router-LSA.";
         uses ospf-router-lsa-bits;
         uses ospfv3-lsa-options;

         container links {
           description
             "Все каналы маршрутизатора.";
           list link {
             description
               "Канал Router-LSA.";
             leaf interface-id {
               type uint32;
               description
                 "Interface ID для канала.";
             }
             leaf neighbor-interface-id {
               type uint32;
               description
                 "Interface ID соседа по каналу.";
             }
             leaf neighbor-router-id {
               type rt-types:router-id;
               description
                 "Router ID соседа по каналу.";
             }
             leaf type {
               type router-link-type;
               description
                 "Ти канала: 1 - «точка-точка»
                             2 — транзитная сеть
                             3 — резерв для каналов OSPFv3
                             4 — виртуальный канал.";
             }
             leaf metric {
               type uint16;
               description
                 "Метрика канала.";
             }
           }
         }
       }
       container network {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-network-lsa')" {
           description
             "Применимо только к Network-LSA.";
         }
         description
           "Network-LSA.";

         uses ospfv3-lsa-options;

         container attached-routers {
           description
             "Все присоединённые маршрутизаторы.";
           leaf-list attached-router {
             type rt-types:router-id;
             description
               "Список присоединённых к сети маршрутизаторов.";
           }
         }
       }
       container inter-area-prefix {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-inter-area-prefix-lsa')" {
           description
             "Применимо только к Inter-Area-Prefix-LSA.";
         }
         leaf metric {
           type ospf-metric;
           description
             "Метрика префикса Inter-Area Prefix.";
         }
         uses ospfv3-lsa-prefix;
         description
           "Prefix-LSA.";
       }
       container inter-area-router {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-inter-area-router-lsa')" {
           description
             "Применимо только к Inter-Area-Router-LSA.";
         }
         uses ospfv3-lsa-options;
         leaf metric {
           type ospf-metric;
           description
             "Метрика граничного маршрутизатора AS (ASBR).";
         }
         leaf destination-router-id {
           type rt-types:router-id;
           description
             "Router ID маршрутизатора ASBR из LSA.";
         }
         description
           "Inter-Area-Router-LSA.";
       }
       container as-external {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-as-external-lsa')" {
           description
             "Применимо только к AS-External-LSA.";
         }

         uses ospfv3-lsa-external;

         description
           "AS-External-LSA.";
       }
       container nssa {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-nssa-lsa')" {
           description
             "Применимо только к NSSA-LSA.";
         }
         uses ospfv3-lsa-external;

         description
           "NSSA-LSA.";
       }
       container link {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-link-lsa')" {
           description
             "Применимо только к Link-LSA.";
         }
         leaf rtr-priority {
           type uint8;
           description
             "Приоритет маршрутизатора для выбора DR. Предпочитается
              маршрутизатор с наибольшим значением, 0 указывает, что
              маршрутизатор нежелателен в качестве DR или BDR.";
         }
         uses ospfv3-lsa-options;

         leaf link-local-interface-address {
           type inet:ipv6-address;
           description
             "Адрес link-local интерфейса создавшего анонс 
              маршрутизатора для этого канала.";
         }

         leaf num-of-prefixes {
           type uint32;
           description
             "Число префиксов.";
         }

         container prefixes {
           description
             "Все префиксы для канала.";
           list prefix {
             description
               "Список связанных с каналом префиксов.";
             uses ospfv3-lsa-prefix;
           }
         }
         description
           "Link-LSA.";
       }
       container intra-area-prefix {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-intra-area-prefix-lsa')" {
           description
             "Применимо только к Intra-Area-Prefix-LSA.";
         }
         description
           "Intra-Area-Prefix-LSA.";

         leaf referenced-ls-type {
           type identityref {
             base ospfv3-lsa-type;
           }
           description
             "Referenced LS Type.";
         }
         leaf unknown-referenced-ls-type {
           type uint16;
           description
             "Значение для неизвестного Referenced LS Type.";
         }
         leaf referenced-link-state-id {
           type uint32;
           description
             "Referenced Link State ID.";
         }
         leaf referenced-adv-router {
           type rt-types:router-id;
           description
             "Referenced Advertising Router.";
           reference
             "RFC 5340: OSPF for IPv6";
         }

         leaf num-of-prefixes {
           type uint16;
           description
             "Число префиксов.";
         }
         container prefixes {
           description
             "Все префиксы в этом анонсе LSA.";
           list prefix {
             description
               "Список префиксов в LSA.";
             uses ospfv3-lsa-prefix;
             leaf metric {
               type uint16;
               description
                 "Метрика перфикса.";
             }
           }
         }
       }
       container router-information {
         when "derived-from-or-self(../../header/type, "
            + "'ospfv3-router-information-lsa')" {
           description
             "Применимо только к Router-Information-LSA (RFC 7770).";
           reference
             "RFC 7770: Extensions to OSPF for Advertising Optional
              Router Capabilities";
         }
         container router-capabilities-tlv {
           description
             "Информационные и функциональные возможности 
              маршрутизатора.";
           uses router-capabilities-tlv;
         }
         container node-tag-tlvs {
           description
             "Все Node Admin Tag TLV.";
           list node-tag-tlv {
             description
               "Node Admin Tag TLV.";
             uses node-tag-tlv;
           }
         }
         container dynamic-hostname-tlv {
           description
             "OSPF Dynamic Hostname TLV.";
           uses dynamic-hostname-tlv;
         }

         container sbfd-discriminator-tlv {
           description
             "OSPF S-BFD Discriminator TLV.";
           uses sbfd-discriminator-tlv;
         }

         description
           "Router-Information-LSA.";
         reference
           "RFC 7770: Extensions to OSPF for Advertising Optional
            Router Capabilities";
       }
     }

     grouping lsa-header {
       description
         "LSA для OSPFv2 и OSPFv3.";
       leaf age {
         type uint16;
         mandatory true;
         description
           "Возраст LSA.";
       }
       leaf type {
         type identityref {
           base ospf-lsa-type;
         }
         mandatory true;
         description
           "Тип LSA.";
       }
       leaf adv-router {
         type rt-types:router-id;
         mandatory true;
         description
           "Анонсирующий LSA маршрутизатор.";
       }
       leaf seq-num {
         type uint32;
         mandatory true;
         description
           "Порядковый номер LSA.";
       }
       leaf checksum {
         type fletcher-checksum16-type;
         mandatory true;
         description
           "Контрольная сумма LSA.";
       }
       leaf length {
         type uint16;
         mandatory true;
         description
           "Размер LSA с учётом заголовка.";
       }
     }

     grouping ospfv2-lsa {
       description
         "OSPFv2 LSA. Анонсы LSA однозначно указываются триплетом
          <LSA Type, Link State ID, Advertising Router> с разделением
          экземпляров по порядковым номерам LSA.";
       container header {
         must "(derived-from(type, "
            + "'ospfv2-opaque-lsa-type') and "
            + "opaque-id and opaque-type) or "
            + "(not(derived-from(type, "
            + "'ospfv2-opaque-lsa-type')) "
            + "and not(opaque-id) and not(opaque-type))" {
           description
             "Значение opaque-type и opaque-id применимы лишь 
              к Opaque-LSA.";
         }
         description
           "Декодированные данные заголовка OSPFv2 LSA.";

         container lsa-options {
           leaf-list lsa-options {
             type identityref {
               base ospfv2-lsa-option;
             }
             description
               "Список опций LSA, содержащий идентификаторы 
                установленных опций OSPFv2 LSA.";
           }
           description
             "Опции LSA.";
         }

         leaf lsa-id {
           type yang:dotted-quad;
           mandatory true;
           description
             "Link State ID.";
         }

         leaf opaque-type {
           type uint8;
           description
             "Тип Opaque-LSA.";
         }

         leaf opaque-id {
           type opaque-id;
           description
             "Opaque-LSA ID.";
         }

         uses lsa-header;
       }
       container body {
         description
           "Декодированные данные тела OSPFv2 LSA.";
         uses ospfv2-lsa-body;
       }
     }

     grouping ospfv3-lsa {
       description
         "Декодированный анонс OSPFv3 LSA.";
       container header {
         description
           "Декодированные данные заголовка OSPFv3 LSA.";
         leaf lsa-id {
           type uint32;
           mandatory true;
           description
             "OSPFv3 LSA ID.";
         }
         uses lsa-header;
       }
       container body {
         description
           "Декодированные данные тела OSPF LSA.";
         uses ospfv3-lsa-body;
       }
     }
     grouping lsa-common {
       description
         "Общие поля для представления OSPF LSA.";
       leaf decode-completed {
         type boolean;
         description
           "Тело OSPF LSA было декодировано за исключением
            неизвестных TLV. Типы неизвестных LSA и OSPFv2 Opaque-LSA
            не декодированы. Некорректно сформированные LSA обычно не
            воспринимаются м не включаются в LSDB.";
       }
       leaf raw-data {
         type yang:hex-string;
         description
           "Шестнадцатеричное представление полного анонса LSA, как
            он получен или передан, с сетевым порядком байтов.";
       }
     }

     grouping lsa {
       description
         "OSPF LSA.";
       uses lsa-common;
       choice version {
         description
           "Тело OSPFv2 или OSPFv3 LSA.";
         container ospfv2 {
           description
             "OSPFv2 LSA.";
           uses ospfv2-lsa;
         }
         container ospfv3 {
           description
             "OSPFv3 LSA.";
           uses ospfv3-lsa;
         }
       }
     }

     grouping lsa-key {
       description
         "Ключ OSPF LSA. Ключ базы данных для каждого анонса LSA данного
          типа в базе LSDB.";
       leaf lsa-id {
         type union {
           type yang:dotted-quad;
           type uint32;
         }
         description
           "Link State ID.";
       }
       leaf adv-router {
         type rt-types:router-id;
         description
           "Анонсирующий маршрутизатор.";
       }
     }

     grouping instance-stat {
       description
         "Статистика для экземпляра.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этого экземпляра OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации экземпляра OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании экземпляра OSPF.";
       }
       leaf originate-new-lsa-count {
         type yang:counter32;
         description
           "Число созданных LSA. Разрыв этого счётчика может происходить
            при реинициализации экземпляра OSPF.";
       }
       leaf rx-new-lsas-count {
         type yang:counter32;
         description
           "Число принятых новых LSA.  Разрыв этого счётчика может
            происходить при реинициализации экземпляра OSPF.";
       }
       leaf as-scope-lsa-count {
         type yang:gauge32;
         description
           "Число AS-Scope LSA.";
       }
       leaf as-scope-lsa-chksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для AS-Scope LSA.
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA,
            эквивалентные контрольные суммы не гарантируют совпадения
            LSA, поскольку разные комбинации могут давать одну
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики на уровне AS-Scope LSA.";
         list as-scope-lsa-type {
           description
             "Список статистики AS-Scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип AS-Scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
       uses instance-fast-reroute-state;
     }

     grouping area-stat {
       description
         "Per-area statistics.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этой области OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации области OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании области OSPF.";
       }
       leaf spf-runs-count {
         type yang:counter32;
         description
           "Число запусков внутриобластного алгоритма SPF. Разрыв этого
            счётчика может возникать при реинициализации области OSPF.";
       }
       leaf abr-count {
         type yang:gauge32;
         description
           "Число доступных в области граничных маршрутизаторов (ABR).";
       }
       leaf asbr-count {
         type yang:gauge32;
         description
           "Общее число граничных маршрутизаторов AS (ASBR), доступных
            внутри этой области.";
       }
       leaf ar-nssa-translator-event-count {
         type yang:counter32;
         description
           "Общее число изменения состояния транслятора NSSA. Разрыв 
            счётчика может возникать при реинициализации области OSPF.";
       }
       leaf area-scope-lsa-count {
         type yang:gauge32;
         description
           "Число Area-scope LSA в области.";
       }
       leaf area-scope-lsa-cksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для Area-scope LSA
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA, 
            эквивалентные контрольные суммы не гарантируют совпадения 
            LSA, поскольку разные комбинации могут давать одну 
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики Area-scope LSA.";
         list area-scope-lsa-type {
           description
             "Список статистики Area-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип Area-scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
     }

     grouping interface-stat {
       description
         "Per-interface statistics.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            этого интерфейса OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации интерфейса OSPF,
            узел содержит время инициализации, которое обычно происходит
            при создании интерфейса OSPF.";
       }
       leaf if-event-count {
         type yang:counter32;
         description
           "Число изменений состояния интерфейса или ошибок на нем.
            Разрыв счётчика может возникать при реинициализации
            интерфейса OSPF.";
       }
       leaf link-scope-lsa-count {
         type yang:gauge32;
         description
           "Число Link-scope LSA.";
       }
       leaf link-scope-lsa-cksum-sum {
         type uint32;
         description
           "Сумма по модулю 2^32 контрольных сумм LSA для Link-scope LSA
            Значение при сравнении следует считать беззнаковым. Хотя
            разные контрольные суммы относятся к разным комбинациям LSA, 
            эквивалентные контрольные суммы не гарантируют совпадения 
            LSA, поскольку разные комбинации могут давать одну 
            контрольную сумму.";
       }
       container database {
         description
           "Контейнер для статистики Link-scope LSA.";
         list link-scope-lsa-type {
           description
             "Список статистики Link-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип Link-scope LSA.";
           }
           leaf lsa-count {
             type yang:gauge32;
             description
               "Число LSA этого типа.";
           }
           leaf lsa-cksum-sum {
             type uint32;
             description
               "Сумма по модулю 2^32 контрольных сумм LSA для LSA этого
                типа. Значение при сравнении следует считать 
                беззнаковым. Хотя разные контрольные суммы относятся к 
                разным комбинациям LSA, эквивалентные контрольные суммы
                не гарантируют совпадения LSA, поскольку разные 
                комбинации могут давать одну контрольную сумму.";
           }
         }
       }
     }

     grouping neighbor-stat {
       description
         "Статистика на уровне соседа.";
       leaf discontinuity-time {
         type yang:date-and-time;
         description
           "Время последнего события, когда один или несколько счётчиков
            для этого соседа OSPF столкнулись с разрывом. Если разрывов
            не было с момента последней реинициализации соседа OSPF,
            узел содержит время инициализации, которое обычно происходит
            при динамическом обнаружении соседа OSPF.";
       }
       leaf nbr-event-count {
         type yang:counter32;
         description
           "Число изменений состояния соседа или ошибок для него.
            Разрыв счётчика может возникать при реинициализации
            соседа OSPF.";
       }
       leaf nbr-retrans-qlen {
         type yang:gauge32;
         description
           "Текущий размер очереди на повтор передачи.";
       }
     }

     grouping instance-fast-reroute-config {
       description
         "Эта группа задаёт глобальную конфигурацию 
          IP Fast Reroute (IP-FRR).";
       container fast-reroute {
         if-feature "fast-reroute";
         description
           "Этот контейнер может дополняться глобальными параметрами
            для IP-FRR.";
         container lfa {
           if-feature "lfa";
           description
             "Этот контейнер может дополняться глобальными параметрами
              для Loop-Free Alternate (LFA). Создание контейнера не
              влияет на активацию LFA.";
         }
       }
     }

     grouping instance-fast-reroute-state {
       description
         "Группировка данных состояния IP-FRR.";

       container protected-routes {
         if-feature "fast-reroute";
         config false;
         description
           "Статистика защиты экземпляра.";

         list address-family-stats {
           key "address-family prefix alternate";
           description
             "Сведения о защищённом префиксе на семейство адресов.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf prefix {
             type inet:ip-prefix;
             description
               "Защищённый префикс.";
           }
           leaf alternate {
             type inet:ip-address;
             description
               "Другой next-hop для префикса.";
           }
           leaf alternate-type {
             type enumeration {
               enum equal-cost {
                 description
                   "Вариант на основе ECMP.";
               }
               enum lfa {
                 description
                   "Вариант на основе LFA.";
               }
               enum remote-lfa {
                 description
                   "Вариант на основе Remote-LFA.";
               }
               enum tunnel {
                 description
                   "Вариант на основе туннеля (RSVP-TE или GRE).";
               }
               enum ti-lfa {
                 description
                   "Вариант на основе TI-LFA.";
               }
               enum mrt {
                 description
                   "Вариант на основе MRT.";
               }
               enum other {
                 description
                   "Вариант неизвестного типа.";
               }
             }
             description
               "Тип варианта.";
           }
           leaf best {
             type boolean;
             description
               "Указывает предпочтительность этого варианта.";
           }
           leaf non-best-reason {
             type string {
               length "1..255";
             }
             description
               "Описывает причину того, что вариант не является
                лучшим выбором.";
           }
           leaf protection-available {
             type bits {
               bit node-protect {
                 position 0;
                 description
                   "Доступна защита узла.";
               }
               bit link-protect {
                 position 1;
                 description
                   "Доступна защита канала.";
               }
               bit srlg-protect {
                 position 2;
                 description
                   "Доступна защита SRLG.";
               }
               bit downstream-protect {
                 position 3;
                 description
                   "Доступна защита нисходящего направления.";
               }
               bit other {
                 position 4;
                 description
                   "Доступна иная защита.";
               }
             }
             description
               "Защита обеспечивается вариантом (альтернативой).";
           }
           leaf alternate-metric-1 {
             type uint32;
             description
               "Метрика от точки локального ремонта (PLR) до адресата
                по альтернативному пути.";
           }
           leaf alternate-metric-2 {
             type uint32;
             description
               "Метрика от PLR до альтернативного узла.";
           }
           leaf alternate-metric-3 {
             type uint32;
             description
               "Метрика от альтернативного узла до адресата.";
           }
         }
       }

       container unprotected-routes {
         if-feature "fast-reroute";
         config false;
         description
           "Список незащищённых префиксов.";

         list address-family-stats {
           key "address-family prefix";
           description
             "Статистика незащищённых префиксов на AF.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf prefix {
             type inet:ip-prefix;
             description
               "Незащищённый префикс.";
           }
         }
       }

       list protection-statistics {
         key "frr-protection-method";
         config false;
         description
           "Список статистики методов защиты.";

         leaf frr-protection-method {
           type string;
           description
             "Используемый метод защиты.";
         }
         list address-family-stats {
           key "address-family";
           description
             "Статистика защиты на AF.";

           leaf address-family {
             type iana-rt-types:address-family;
             description
               "Семейство адресов.";
           }
           leaf total-routes {
             type uint32;
             description
               "Общее число префиксов.";
           }
           leaf unprotected-routes {
             type uint32;
             description
               "Общее число незащищённых префиксов.";
           }
           leaf protected-routes {
             type uint32;
             description
               "Общее число защищённых префиксов.";
           }
           leaf linkprotected-routes {
             type uint32;
             description
               "Общее число префиксов с защитой канала.";
           }
           leaf nodeprotected-routes {
             type uint32;
             description
               "Общее число защищённых префиксов.";
           }
         }
       }
     }

     grouping interface-fast-reroute-config {
       description
         "Эта группа определяет конфигурацию интерфейса IP-FRR.";
       container fast-reroute {
         if-feature "fast-reroute";
         container lfa {
           if-feature "lfa";
           leaf candidate-enabled {
             type boolean;
             default "true";
             description
               "Разрешает применять интерфейс как резервный.";
           }
           leaf enabled {
             type boolean;
             default "false";
             description
               "Активирует LFA. Предполагается расчёт LFA на префикс.";
           }
           container remote-lfa {
             if-feature "remote-lfa";
             leaf enabled {
               type boolean;
               default "false";
               description
                 "Активирует Remote LFA (R-LFA).";
             }
             description
               "Конфигурация R-LFA.";
           }
           description
             "Конфигурация LFA.";
         }
         description
           "Конфигурация интерфейса IP-FRR.";
       }
     }

     grouping interface-physical-link-config {
       description
         "Конфигурация стоимости интерфейса, применяемая только к
          физическим (не виртуальным) интерфейсам и и sham-каналам.";
       leaf cost {
         type ospf-link-metric;
         description
           "Стоимость интерфейса.";
       }
       leaf mtu-ignore {
         if-feature "mtu-ignore";
         type boolean;
         description
           "Управляет обходом проверки несоответствия MTU для пакетов
            Database Description (параграф 10.6 в RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2, Section 10.6";
       }
       leaf prefix-suppression {
         if-feature "prefix-suppression";
         type boolean;
         description
           "Подавляет анонсы префиксов, связанных с интерфейсом.";
       }
     }

     grouping interface-common-config {
       description
         "Общая конфигурация для всех типов интерфейсов, включая
          виртуальные и sham-каналы (фиктивные).";

       leaf hello-interval {
         type uint16;
         units "seconds";
         description
           "Интервал между пакетами Hello (в секундах), который должен
            совпадать для всех маршрутизаторов в одной сети. Разные
            реализации и развёртывания применяют разные интервалы Hello.
            Примером значения для ЛВС служит интервал в 10 секунд.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf dead-interval {
         type uint16;
         units "seconds";
         must '../dead-interval > ../hello-interval' {
           error-message "Интервал «умирания» (dead) должен быть "
                       + "больше интервала Hello";
           description
             "Значение должно быть больше hello-interval.";
         }
         description
           "Интервал, после которого сосед считается отключённым 
            (в секундах), если от него нет пакетов Hello. Обычно это
            в 3 - 4 раза больше hello-interval. Типовое значение для
            ЛВС составляет 40 секунд.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf retransmit-interval {
         type uint16 {
           range "1..3600";
         }
         units "seconds";
         description
           "Интервал повтора неподтвержденных анонсов LSA (в секундах).
            Значение должно быть больше RTT между любыми двумя 
            маршрутизаторами в сети. Примером служит значение 5 сек.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf transmit-delay {
         type uint16;
         units "seconds";
         description
           "Оценка времени передачи пакетов обновления состояния канала
            (LSU) на интерфейсе (в секундах). Возраст LSA увеличивается
            на это значение при анонсировании через интерфейс. Примером
            значения является 1 секунда.";
         reference
           "RFC 2328: OSPF Version 2, Appendix C.3";
       }

       leaf lls {
         if-feature "lls";
         type boolean;
         description
           "Управляет поддержкой сигнализации LLS.";
       }

       container ttl-security {
         if-feature "ttl-security";
         description
           "Проверка безопасности TTL.";
         leaf enabled {
           type boolean;
           description
             "Управляет проверкой безопасности TTL.";
         }
         leaf hops {
           type uint8 {
             range "1..254";
           }
           default "1";
           description
             "Максимальное число пересылок (hop), которые пакет OSPF
              может пройти до получения.";
         }
       }
       leaf enabled {
         type boolean;
         default "true";
         description
           "Управляет протоколом OSPF на интерфейсе.";
       }

       container authentication {
         description
           "Конфигурация проверки подлинности.";
         choice auth-type-selection {
           description
             "Опции для настройки аутентификации OSPFv2/OSPFv3.";
           case ospfv2-auth {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv2')" {
               description
                 "Применимо только к OSPFv2.";
             }
             leaf ospfv2-auth-trailer-rfc {
               if-feature "ospfv2-authentication-trailer";
               type ospfv2-auth-trailer-rfc-version;
               description
                 "Поддержка трейлера аутентификации OSPFv2 (RFC 5709
                  и RFC 7474).";
               reference
                 "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication
                  RFC 7474: Security Extension for OSPFv2 When Using
                  Manual Key Management";
             }
             choice ospfv2-auth-specification {
               description
                 "Указание цепочки ключей или явных параметров ключа.";
               case auth-key-chain {
                 if-feature "key-chain";
                 leaf ospfv2-key-chain {
                   type key-chain:key-chain-ref;
                   description
                     "Имя цепочки ключей.";
                 }
               }
               case auth-key-explicit {
                 leaf ospfv2-key-id {
                   type uint32;
                   description
                     "Идентификатор ключа.";
                 }
                 leaf ospfv2-key {
                   type string;
                   description
                     "Ключ аутентификации OSPFv2. Размер ключа может
                      зависеть от применяемого алгоритма.";
                 }
                 leaf ospfv2-crypto-algorithm {
                   type identityref {
                     base key-chain:crypto-algorithm;
                   }
                   description
                     "Криптоалгоритм, связанный с ключом.";
                 }
               }
             }
           }
           case ospfv3-auth-ipsec {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv3')" {
               description
                 "Применимо только к OSPFv3.";
             }
             if-feature "ospfv3-authentication-ipsec";
             leaf sa {
               type string;
               description
                 "Имя защищённой связи (SA).";
             }
           }
           case ospfv3-auth-trailer {
             when "derived-from-or-self(../../../../../../rt:type, "
                + "'ospfv3')" {
               description
                 "Применимо только к OSPFv3.";
             }
             if-feature "ospfv3-authentication-trailer";
             choice ospfv3-auth-specification {
               description
                 "Указание цепочки ключей или явных параметров ключа.";
               case auth-key-chain {
                 if-feature "key-chain";
                 leaf ospfv3-key-chain {
                   type key-chain:key-chain-ref;
                   description
                     "Имя цепочки ключей.";
                 }
               }
               case auth-key-explicit {
                 leaf ospfv3-sa-id {
                   type uint16;
                   description
                 "Имя защищённой связи (SA).";
                 }
                 leaf ospfv3-key {
                   type string;
                   description
                     "Ключ аутентификации OSPFv3. Размер ключа может
                      зависеть от применяемого алгоритма.";
                 }
                 leaf ospfv3-crypto-algorithm {
                   type identityref {
                     base key-chain:crypto-algorithm;
                   }
                   description
                     "Криптоалгоритм, связанный с ключом.";
                 }
               }
             }
           }
         }
       }
     }

     grouping interface-config {
       description
         "Конфигурация для обычных интерфейсов OSPF (не виртуальных
          или фиктивных - sham).";

       leaf interface-type {
         type enumeration {
           enum broadcast {
             description
               "Широковещательная сеть с множественным доступом.";
           }
           enum non-broadcast {
             description
               "Сеть с множественным доступом без широковещания (NBMA).";
           }
           enum point-to-multipoint {
             description
               "Сеть «один со многими» (point-to-multipoint).";
           }
           enum point-to-point {
             description
                "Сеть «точка-точка».";
              "Specifies an OSPF point-to-point network.";
           }
           enum hybrid {
             if-feature "hybrid-interface";
             description
               "Гибридная сеть (широковещание/point-to-multipoint).";
           }
         }
         description
           "Тип интерфейса.";
       }

       leaf passive {
         type boolean;
         description
           "Управляет пассивным интерфейсом. Префикс пассивного
            интерфейса анонсируется, но смежность не создается.";
       }

       leaf demand-circuit {
         if-feature "demand-circuit";
         type boolean;
         description
           "Управляет demand-устройством.";
       }

       leaf priority {
         type uint8;
         description
           "Задаёт приоритет маршрутизатора OSPF. В сети с множественным
            доступом это служит для выбора DR. На интерфейсах других
            типов приоритет игнорируется. Маршрутизатор с высоким 
            приоритетом предпочитается при выборе. Значение 0 указывает,
            что маршрутизатору нежелательно быть DR или BDR.";
       }

       container multi-areas {
         if-feature "multi-area-adj";
         description
           "Контейнер для конфигурации с множеством областей.";
         list multi-area {
           key "multi-area-id";
           description
             "Настраивает смежность между областями OSPF.";
           leaf multi-area-id {
             type area-id-type;
             description
               "Идентификатор области для смежности областей.";
           }
           leaf cost {
             type ospf-link-metric;
             description
               "Стоимость интерфейса для смежности областей.";
           }
         }
       }

       container static-neighbors {
         description
           "Статически заданные соседи.";

         list neighbor {
           key "identifier";
           description
             "Статически заданный сосед OSPF.";

           leaf identifier {
             type inet:ip-address;
             description
               "Router ID, адрес IPv4 или IPv6 у соседа.";
           }

           leaf cost {
             type ospf-link-metric;
             description
               "Стоимость интерфейса. Разные реализации по умолчанию 
                задают разную стоимость, при этом у некоторых стоимость
                обратно пропорциональная значения. Некоторые задают по
                умолчанию 1, считая стоимостью число пересылок (hop).";
           }
           leaf poll-interval {
             type uint16;
             units "seconds";
             description
               "Интервал опроса (в секундах) для отправки пакетов
                OSPF Hello с целью обнаружения соседей в сети NBMA.
                Этот интервал задаёт детализацию поиска новых соседей.
                Примером может служить интервал 120 секунд (2 минуты)
                для унаследованных пакетных сетей (PDN) X.25.";
             reference
               "RFC 2328: OSPF Version 2, Appendix C.5";
           }
           leaf priority {
             type uint8;
             description
               "Приоритет соседа при выборе DR. Маршрутизатор с высоким 
                приоритетом предпочитается при выборе, 0, указывает,
                что маршрутизатору нежелательно быть DR или BDR.";
           }
         }
       }

       leaf node-flag {
         if-feature "node-flag";
         type boolean;
         default "false";
         description
           "Набор префиксов, указывающих анонсирующий маршрутизатор.";
         reference
           "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement";
       }

       container bfd {
         if-feature "bfd";
         description
           "Конфигурация интерфейса BFD.";
         uses bfd-types:client-cfg-parms;
         reference
           "RFC 5880: Bidirectional Forwarding Detection (BFD)
            RFC 5881: Bidirectional Forwarding Detection
            (BFD) for IPv4 and IPv6 (Single Hop)
            RFC 9314: YANG Data Model for Bidirectional Forwarding
            Detection (BFD)";
       }

       uses interface-fast-reroute-config;
       uses interface-common-config;
       uses interface-physical-link-config;
     }

     grouping neighbor-state {
       description
         "Рабочее состояние соседа OSPF.";

       leaf address {
         type inet:ip-address;
         config false;
         description
           "Адрес соседа.";
       }
       leaf dr-router-id {
         type rt-types:router-id;
         config false;
         description
           "Router ID у DR соседа.";
       }

       leaf dr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "Адрес IP у DR соседа.";
       }

       leaf bdr-router-id {
         type rt-types:router-id;
         config false;
         description
          "Router ID у BDR соседа.";
       }

       leaf bdr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "Адрес IP у BDR соседа.";
       }
       leaf state {
         type nbr-state-type;
         config false;
         description
           "Состояние соседа OSPF.";
       }
       leaf cost {
         type ospf-link-metric;
         config false;
         description
           "Стоимость доступа к соседу для сетей point-to-multipoint
            и Hybrid.";
       }
       leaf dead-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента, когда
            сосед будет сочтён «мертвым».";
       }
       container statistics {
         config false;
         description
           "Статистика для соседа.";
         uses neighbor-stat;
       }
     }

     grouping interface-common-state {
       description
         "Базовое рабочее состояние интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2, Section 9";

       leaf state {
         type if-state-type;
         config false;
         description
           "Состояние интерфейса.";
       }

       leaf hello-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента отправки
            через интерфейс следующего сообщения Hello.";
       }

       leaf wait-timer {
         type rt-types:timer-value-seconds16;
         config false;
         description
           "Таймер, отслеживающий оставшееся время до момента выхода
            интерфейса из состояния Waiting.";
       }

       leaf dr-router-id {
         type rt-types:router-id;
         config false;
         description
           "DR Router ID.";
       }

       leaf dr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "IP-адрес DR.";
       }

       leaf bdr-router-id {
         type rt-types:router-id;
         config false;
         description
           "BDR Router ID.";
       }

       leaf bdr-ip-addr {
         type inet:ip-address;
         config false;
         description
           "IP-адрес BDR.";
       }

       container statistics {
         config false;
         description
           "Статистика для интерфейса.";
         uses interface-stat;
       }

       container neighbors {
         config false;
         description
           "Все соседи на интерфейсе.";
         list neighbor {
           key "neighbor-router-id";
           description
             "Список соседей OSPF на интерфейсе.";
           leaf neighbor-router-id {
             type rt-types:router-id;
             description
               "Router ID соседа.";
           }
           uses neighbor-state;
         }
       }
       container database {
         config false;
         description
           "Link-scope LSDB.";
         list link-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF Link-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF Link-scope LSA.";
           }
           container link-scope-lsas {
             description
               "Все Link-scope LSA этого типа.";
             list link-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF Link-scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
     }

     grouping interface-state {
       description
         "Рабочее состояние интерфейса OSPF.";
       reference
         "RFC 2328: OSPF Version 2, Section 9";

       uses interface-common-state;
     }

     grouping virtual-link-config {
       description
         "Состояние конфигурации виртуального канала OSPF.";

       uses interface-common-config;
     }

     grouping virtual-link-state {
       description
         "Рабочее состояние виртуального канала OSPF.";

       leaf cost {
         type ospf-link-metric;
         config false;
         description
           "Стоимость интерфейса виртуального канала.";
       }
       uses interface-common-state;
     }

     grouping sham-link-config {
       description
         "Состояние конфигурации фиктивного канала OSPF.";

       uses interface-common-config;
       uses interface-physical-link-config;
     }

     grouping sham-link-state {
       description
         "Рабочее состояние фиктивного канала OSPF.";
       uses interface-common-state;
     }

     grouping address-family-area-config {
       description
         "Состояние конфигурации области OSPF для семейства адресов.";

       container ranges {
         description
           "Контейнер для сводных (summary) диапазонов.";

         list range {
           key "prefix";
           description
             "Сводка маршрутов, соответствующих адресу и маске.
              Применима лишь для маршрутизаторов ABR.";
           leaf prefix {
             type inet:ip-prefix;
             description
               "Префикс IPv4 или IPv6.";
           }
           leaf advertise {
             type boolean;
             description
               "Аносируется или скрыт.";
           }
           leaf cost {
             type ospf-metric;
             description
               "Анонсируемая стоимость сводного маршрута.";
           }
         }
       }
     }

     grouping area-common-config {
       description
         "Базовое состояние конфигурации области OSPF.";

       leaf summary {
         when "derived-from(../area-type,'stub-nssa-area')" {
           description
             "Сводный анонс в тупиковую область или NSSA.";
         }
         type boolean;
         description
           "Управляет анонсами в тупиковые области или NSSA.";
       }
       leaf default-cost {
         when "derived-from(../area-type,'stub-nssa-area')" {
           description
             "Стоимость LSA принятого по умолчанию маршрута,
              анонсируемого у тупиковую область или NSSA.";
         }
         type ospf-metric;
         description
           "Задаёт сводную стоимость маршрута по умолчанию для
            тупиковой области или NSSA.";
       }
     }

     grouping area-config {
       description
         "Состояние конфигурации области OSPF.";

       leaf area-type {
         type identityref {
           base area-type;
         }
         default "normal-area";
         description
           "Тип области.";
       }

       uses area-common-config;
       uses address-family-area-config;
     }

     grouping area-state {
       description
         "Рабочее состояние области OSPF.";

       container statistics {
         config false;
         description
           "Статистика для области.";
         uses area-stat;
       }

       container database {
         config false;
         description
           "Area-scope LSDB.";
         list area-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF Area-scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF Area-scope LSA.";
           }
           container area-scope-lsas {
             description
               "Все Area-scope LSA.";
             list area-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF Area-scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
     }

     grouping local-rib {
       description
         "Локальная таблица RIB для маршрутов, рассчитанных
          локальным экземпляром маршрутизации OSPF.";
       container local-rib {
         config false;
         description
           "Local RIB.";
         list route {
           key "prefix";
           description
             "Локальные маршруты экземпляра OSPF.";
           leaf prefix {
             type inet:ip-prefix;
             description
               "Префикс адресата.";
           }
           container next-hops {
             description
               "Следующие узлы (next-hop) для маршрута.";
             list next-hop {
               description
                 "Список next-hop для маршрута.";
               leaf outgoing-interface {
                 type if:interface-ref;
                 description
                   "Имя выходного интерфейса.";
               }
               leaf next-hop {
                 type inet:ip-address;
                 description
                   "Адрес next-hop.";
               }
             }
           }
           leaf metric {
             type uint32;
             description
               "Метрика маршрута.";
           }
           leaf route-type {
             type route-type;
             description
               "Тип маршрута.";
           }
           leaf route-tag {
             type uint32;
             description
               "Тег для маршрута.";
           }
         }
       }
     }

     grouping ietf-spf-delay {
       leaf initial-delay {
         type uint32;
         units "milliseconds";
         default "50";
         description
           "Задержка, применяемая в состоянии QUIET (мсек).";
       }
       leaf short-delay {
         type uint32;
         units "milliseconds";
         default "200";
         description
           "Задержка, применяемая в состоянии SHORT_WAIT (мсек).";
       }
       leaf long-delay {
         type uint32;
         units "milliseconds";
         default "5000";
         description
           "Задержка, применяемая в состоянии LONG_WAIT (мсек).";
       }
       leaf hold-down {
         type uint32;
         units "milliseconds";
         default "10000";
         description
           "Таймер для интервала без изменений, когда IGP
            считается стабильным (мсек).";
       }
       leaf time-to-learn {
         type uint32;
         units "milliseconds";
         default "500";
         description
           "Продолжительность изучения всех событий IGP, относящихся
            к одному сетевому событию (мсек).";
       }
       leaf current-state {
         type enumeration {
           enum quiet {
             description
               "Состояние QUIET.";
           }
           enum short-wait {
             description
               "Состояние SHORT_WAIT.";
           }
           enum long-wait {
             description
               "Состояние LONG_WAIT.";
           }
         }
         config false;
         description
           "Текущее состояние алгоритма отсрочки SPF (back-off).";
       }
       leaf remaining-time-to-learn {
         type rt-types:timer-value-milliseconds;
         config false;
         description
           "Время, оставшееся до завершения time-to-learn.";
       }
       leaf remaining-hold-down {
         type rt-types:timer-value-milliseconds;
         config false;
         description
           "Время, оставшееся до завершения hold-down.";
       }
       leaf last-event-received {
         type yang:timestamp;
         config false;
         description
           "Время последнего события-триггера SPF.";
       }
       leaf next-spf-time {
         type yang:timestamp;
         config false;
         description
           "Время следующего запланированного SPF.";
       }
       leaf last-spf-time {
         type yang:timestamp;
         config false;
         description
           "Время последнего расчёта SPF.";
       }
       description
         "Группировка для конфигурации и состояния задержки IETF SPF.";
       reference
         "RFC 8405: Shortest Path First (SPF) Back-Off Delay Algorithm
          for Link-State IGPs";
     }

     grouping node-tag-config {
       description
         "Состояние конфигурации тега узла OSPF.";
       container node-tags {
         if-feature "node-tag";
         list node-tag {
           key "tag";
           leaf tag {
             type uint32;
             description
               "Значение тега узла.";
           }
           description
             "Список тегов узлов.";
         }
         description
           "Контейнер для административных тегов узла.";
       }
     }

     grouping instance-config {
       description
         "Состояние конфигурации экземпляра OSPF.";

       leaf enabled {
         type boolean;
         default "true";
         description
           "Включает и выключает протокол.";
       }

       leaf explicit-router-id {
         if-feature "explicit-router-id";
         type rt-types:router-id;
         description
           "Уникальный 32-битовый идентификатор маршрутизатора
            (RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2";
       }

       container preference {
         description
           "Конфигурация предпочтений для маршрутизатора. Во многих
            реализациях называется административной дистанцией.";
         reference
           "RFC 8349: A YANG Data Model for Routing Management
            (NMDA Version)";
         choice scope {
           description
             "Опции выражения предпочтений одним или несколькими
              значениями.";
           case single-value {
             leaf all {
               type uint8;
               description
                 "Предпочтение для внутриобластных, межобластных
                  и внешних маршрутов.";
             }
           }
           case multi-values {
             choice granularity {
               description
                 "Опции для указания предпочтений внутриобластных
                  и межобластных маршрутов.";
               case detail {
                 leaf intra-area {
                   type uint8;
                   description
                     "Предпочтение для маршрутов внутри области.";
                 }
                 leaf inter-area {
                   type uint8;
                   description
                     "Предпочтение для маршрутов между областями.";
                 }
               }
               case coarse {
                 leaf internal {
                   type uint8;
                   description
                     "Предпочтение для маршрутов внутри и между 
                      областями.";
                 }
               }
             }
             leaf external {
               type uint8;
               description
                 "Предпочтение для маршрутов внешних AS и NSSA.";
             }
           }
         }
       }

       container nsr {
         if-feature "nsr";
         description
           "Состояние настройки безостановочной маршрутизации (NSR).";
         leaf enabled {
           type boolean;
           description
             "Включает и выключает NSR.";
         }
       }

       container graceful-restart {
         if-feature "graceful-restart";
         description
           "Состояние конфигурации аккуратного перезапуска.";
         reference
           "RFC 3623: Graceful OSPF Restart
            RFC 5187: OSPFv3 Graceful Restart";
         leaf enabled {
           type boolean;
           description
             "Управляет аккуратным перезапуском (RFC 3623 для
              OSPFv2 и RFC 5187 для OSPFv3).";
         }
         leaf helper-enabled {
           type boolean;
           description
             "Включает поддержку помощника при аккуратном перезапуске
              маршрутизаторов (раздел 3 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Section 3";
         }
         leaf restart-interval {
           type uint16 {
             range "1..1800";
           }
           units "seconds";
           default "120";
           description
             "Интервал попыток аккуратного перезапуска (в секундах)
              до отказа (Приложение B.1 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Appendix B.1";
         }
         leaf helper-strict-lsa-checking {
           type boolean;
           description
             "Прерывает аккуратный перезапуск при смене топологии LSA
              (Приложение B.2 в RFC 3623).";
           reference
             "RFC 3623: Graceful OSPF Restart, Appendix B.2";
         }
       }

       container auto-cost {
         if-feature "auto-cost";
         description
           "Состояние автоматического расчёта стоимости интерфейса.";
         leaf enabled {
           type boolean;
           description
             "Управляет автоматическим расчётом стоимости интерфейса.";
         }
         leaf reference-bandwidth {
           when "../enabled = 'true'" {
             description
               "Применимо лишь при автоматическом расчёте стоимости.";
           }
           type uint32 {
             range "1..4294967";
           }
           units "Mbits";
           description
             "Эталонная пропускная способность для автоматического
              расчёта стоимости интерфейса (Мбит/с). Это значение
              делится на скорость интерфейса и 1 указывает
              минимальную стоимость.";
         }
       }

       container spf-control {
         leaf paths {
           if-feature "max-ecmp";
           type uint16 {
             range "1..65535";
           }
           description
             "Максимальное число равноценных путей (ECMP).";
         }
         container ietf-spf-delay {
           if-feature "ietf-spf-delay";
           uses ietf-spf-delay;
           description
             "Конфигурация алгоритма задержки IETF SPF.";
         }
         description
           "Управление расчётом SPF.";
       }

       container database-control {
         leaf max-lsa {
           if-feature "max-lsa";
           type uint32 {
             range "1..4294967294";
           }
           description
             "Максимальное число OSPF LSA, принимаемых маршрутизатором";
         }
         description
           "Управление поддержкой базы данных.";
       }

       container stub-router {
         if-feature "stub-router";
         description
           "Задаёт конфигурацию максимальной метрики.";

         choice trigger {
           description
             "Триггеры, разрешающие состояние маршрутизатора-заглушки.";
           container always {
             presence "Разрешает безусловную поддержку stub router.";
             description
               "Безусловное состояние stub router (анонсы транзитных
                каналов с MaxLinkMetric).";
             reference
               "RFC 6987: OSPF Stub Router Advertisement";
           }
         }
       }

       container mpls {
         description
           "Состояние конфигурации OSPF MPLS.";
         container te-rid {
           if-feature "te-rid";
           description
             "Стабильный IP-адрес маршрутизатора OSPF для TE.";
           leaf ipv4-router-id {
             type inet:ipv4-address;
             description
               "Явно заданный TE IPv4 Router ID.";
           }
           leaf ipv6-router-id {
             type inet:ipv6-address;
             description
               "Явно заданный TE IPv6 Router ID.";
           }
         }
         container ldp {
           description
             "Состояние конфигурации OSPF MPLS LDP.";
           leaf igp-sync {
             if-feature "ldp-igp-sync";
             type boolean;
             description
               "Включает синхронизацию LDP IGP.";
           }
         }
       }
       uses instance-fast-reroute-config;
       uses node-tag-config;
     }

     grouping instance-state {
       description
         "Рабочее состояние экземпляра OSPF.";

       leaf router-id {
         type rt-types:router-id;
         config false;
         description
           "32-битовый уникальный идентификатор маршрутизатора
            (RFC 2328).";
         reference
           "RFC 2328: OSPF Version 2";
       }

       uses local-rib;

       container statistics {
         config false;
         description
           "Статистика для экземпляра.";
         uses instance-stat;
       }

       container database {
         config false;
         description
           "AS-Scope LSDB.";
         list as-scope-lsa-type {
           key "lsa-type";
           description
             "Список OSPF AS-Scope LSA.";
           leaf lsa-type {
             type uint16;
             description
               "Тип OSPF AS-Scope LSA.";
           }
           container as-scope-lsas {
             description
               "Все AS-Scope LSA этого типа.";
             list as-scope-lsa {
               key "lsa-id adv-router";
               description
                 "Список OSPF AS-Scope LSA.";
               uses lsa-key;
               uses lsa {
                 refine "version/ospfv2/ospfv2" {
                   must "derived-from-or-self( "
                      + "../../../../../../"
                      + "rt:type, 'ospfv2')" {
                     description
                       "OSPFv2 LSA.";
                   }
                 }
                 refine "version/ospfv3/ospfv3" {
                   must "derived-from-or-self( "
                      + "../../../../../../"
                      + "rt:type, 'ospfv3')" {
                     description
                       "OSPFv3 LSA.";
                   }
                 }
               }
             }
           }
         }
       }
       uses spf-log;
       uses lsa-log;
     }

     grouping multi-topology-area-common-config {
       description
         "Базовое состояние конфигурации области OSPF с несколькими 
          топологиями.";
       leaf summary {
         when "derived-from(../../../area-type, 'stub-nssa-area')" {
           description
             "Сводный анонс в тупиковую область или NSSA.";
         }
         type boolean;
         description
           "Управляет сводными анонсами в топологию тупиковой области
            или NSSA.";
       }
       leaf default-cost {
         when "derived-from(../../../area-type, 'stub-nssa-area')" {
           description
             "Стоимость для LSA маршрута по умолчанию, анонсируемого 
              в тупиковую область или NSSA.";
         }
         type ospf-metric;
         description
           "Задаёт сводный маршрут по умолчанию для тупиковой области
            или NSSA.";
       }
     }

     grouping multi-topology-area-config {
       description
         "Состояние конфигурации области OSPF с разными топологиями.";

       uses multi-topology-area-common-config;
       uses address-family-area-config;
     }

     grouping multi-topology-state {
       description
         "Рабочее состояние OSPF с несколькими топологиями.";

       uses local-rib;
     }

     grouping multi-topology-interface-config {
       description
         "Состояние конфигурации OSPF с несколькими топологиями.";

       leaf cost {
         type ospf-link-metric;
         description
           "Стоимость интерфейса для этой топологии.";
       }
     }

     grouping ospfv3-interface-config {
       description
         "Связанное с интерфейсом состояние конфигурации OSPFv3.";

       leaf instance-id {
         type uint8;
         default "0";
         description
           "Идентификатор экземпляра OSPFv3.";
       }
     }

     grouping ospfv3-interface-state {
       description
         "Связанное с интерфейсом рабочее состояние OSPFv3.";

       leaf interface-id {
         type uint32;
         config false;
         description
           "Идентификатор экземпляра OSPFv3.";
       }
     }

     grouping lsa-identifiers {
       description
         "Параметры, однозначно указывающие LSA.";
       leaf area-id {
         type area-id-type;
         description
           "Area ID.";
       }
       leaf type {
         type uint16;
         description
           "Тип LSA.";
       }
       leaf lsa-id {
         type union {
           type inet:ipv4-address;
           type yang:dotted-quad;
         }
         description
           "Link State ID.";
       }
       leaf adv-router {
         type rt-types:router-id;
         description
           "Анонсирующий LSA маршрутизатор.";
       }
       leaf seq-num {
         type uint32;
         description
           "Порядковый номер LSA.";
       }
     }

     grouping spf-log {
       description
         "Группировка для журнальных записей SPF (log).";
       container spf-log {
         config false;
         description
           "Контейнер с записями SPF.";
         list event {
           key "id";
           description
             "Список записей SPF в форме буфера переноса в обратном
              хронологическом порядке (начиная со старых).";
           leaf id {
             type uint32;
             description
               "Идентификатор события (сугубо внутреннее значение).";
           }
           leaf spf-type {
             type enumeration {
               enum full {
                 description
                   "Расчёт SPF был выполнен для всего SPF.";
               }
               enum intra {
                 description
                   "Расчёт SPF лишь для маршрутов внутри области.";
               }
               enum inter {
                 description
                   "Расчёт SPF для сводных маршрутов между областями.";
               }
               enum external {
                 description
                   "Расчёт SPF лишь для маршрутов внешних AS и NSSA.";
               }
             }
             description
               "Расчёт SPF лишь для для записи журнала SPF.";
           }
           leaf schedule-timestamp {
             type yang:timestamp;
             description
               "Временная метка для запланированного расчёта.";
           }
           leaf start-timestamp {
             type yang:timestamp;
             description
               "Временная метка начала расчёта.";
           }
           leaf end-timestamp {
             type yang:timestamp;
             description
               "Временная метка завершения расчёта.";
           }
           list trigger-lsa {
             description
               "Список LSA, вызвавших расчёт.";
             uses lsa-identifiers;
           }
         }
       }
     }

     grouping lsa-log {
       description
         "Группировка для системного журнала LSA (log).";
       container lsa-log {
         config false;
         description
           "Контейнер со списком записей журнала LSA, включая локальные
            изменения LSA.";
         list event {
           key "id";
           description
             "Список записей LSA в форме буфера переноса в обратном
              хронологическом порядке (начиная со старых).";
           leaf id {
             type uint32;
             description
               "Идентификатор события (сугубо локальное значение).";
           }
           container lsa {
             description
               "Контейнер, описывающий LSA, записанные в журнал.";
             uses lsa-identifiers;
           }
           leaf received-timestamp {
             type yang:timestamp;
             description
               "Временная метка получения LSA. При локальном обновлении
                LSA это будет время создания LSA.";
           }
           leaf reason {
             type identityref {
               base lsa-log-reason;
             }
             description
               "Причина внесения записи в журнал LSA.";
           }
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol" {
       when "derived-from(rt:type, 'ospf')" {
         description
           "Это дополнение пригодно лишь для экземпляра протокола
            маршрутизации OSPF (типа ospfv2 или ospfv3).";
       }
       description
         "Дополнение OSPF control-plane-protocol для модуля 
          ietf-routing.";

       container ospf {
         description
           "Экземпляр протокола OSPF.";

         leaf address-family {
           when "derived-from-or-self(../../rt:type, 'ospfv3')" {
             description
               "Применимо только для OSPFv3.";
           }
           type iana-rt-types:address-family;
           description
             "Семейство адресов для экземпляра.";
         }

         uses instance-config;
         uses instance-state;

         container areas {
           description
             "Все области OSPF.";
           list area {
             key "area-id";
             description
               "Список областей OSPF.";
             leaf area-id {
               type area-id-type;
               description
                 "Area ID.";
             }

             uses area-config;
             uses area-state;

             container virtual-links {
               when "derived-from-or-self(../area-type, 'normal-area') "
                  + "and ../area-id = '0.0.0.0'" {
                 description
                   "Виртуальные каналы должны быть в магистральной 
                    (backbone) области.";
               }
               description
                 "Все виртуальные каналы.";
               list virtual-link {
                 key "transit-area-id router-id";
                 description
                   "Виртуальный канал OSPF.";
                 leaf transit-area-id {
                   type leafref {
                     path "../../../../area/area-id";
                   }
                   must "derived-from-or-self("
                      + "../../../../area[area-id=current()]"
                      + "/area-type, 'normal-area') and "
                      + "../../../../area[area-id=current()]"
                      + "/area-id != '0.0.0.0'" {
                     error-message "Транзитной области виртуального "
                             + "канала недопустимо быть магистральной.";
                     description
                       "Транзитной области виртуального канала 
                        недопустимо быть магистральной (0.0.0.0).";
                   }
                   description
                     "Идентификатор транзитной области виртуального 
                      канала.";
                 }
                 leaf router-id {
                   type rt-types:router-id;
                   description
                     "Router ID удалённой конечной точки виртуального
                      канала.";
                 }

                 uses virtual-link-config;
                 uses virtual-link-state;
               }
             }
             container sham-links {
               if-feature "pe-ce-protocol";
               description
                 "Все фиктивные (sham) каналы.";
               list sham-link {
                 key "local-id remote-id";
                 description
                   "Фиктивный канал OSPF.";
                 leaf local-id {
                   type inet:ip-address;
                   description
                     "Адрес локальной конечной точки фиктивного канала";
                 }
                 leaf remote-id {
                   type inet:ip-address;
                   description
                     "Адрес удалённой конечной точки фиктивного канала";
                 }
                 uses sham-link-config;
                 uses sham-link-state;
               }
             }
             container interfaces {
               description
                 "Все интерфейсы OSPF.";
               list interface {
                 key "name";
                 description
                   "Список интерфейсов OSPF.";
                 leaf name {
                   type if:interface-ref;
                   description
                     "Ссылка на имя интерфейса.";
                 }
                 uses interface-config;
                 uses interface-state;
               }
             }
           }
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf" {
       when "derived-from(../rt:type, 'ospf')" {
         description
           "Это дополнение действительно лишь для OSPF
            (тип ospfv2 или ospfv3).";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации экземпляра OSPF
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии.";
         list topology {
           key "name";
           description
             "Топология OSPF. Семейство адресов топологии OSPF 
              должно совпадать с семейством экземпляра маршрутизации.";
           leaf name {
             type leafref {
               path "../../../../../../rt:ribs/rt:rib/rt:name";
             }
             description
               "Имя таблицы RIB, соответствующей топологии OSPF.";
           }

           uses multi-topology-state;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area" {
       when "derived-from-or-self(../../../rt:type, "
          + "'ospfv2')" {
         description
           "Это дополнение действительно лишь для OSPFv2.";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации области OSPF 
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии для области.";
         list topology {
           key "name";
           description
             "Топология области OSPF.";
           leaf name {
             type leafref {
               path "../../../../../../../../"
                  + "rt:ribs/rt:rib/rt:name";
             }
             description
               "Одна топология разрешена для этой области.";
           }

           uses multi-topology-area-config;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area/interfaces/interface" {
       when "derived-from-or-self(../../../../../rt:type, "
          + "'ospfv2')" {
         description
           "Это дополнение действительно лишь для OSPFv2.";
       }
       if-feature "multi-topology";
       description
         "Дополнение состояния конфигурации интерфейса OSPF 
          с несколькими топологиями.";
       container topologies {
         description
           "Все топологии для интерфейса.";
         list topology {
           key "name";
           description
             "Топология для интерфейса OSPF.";
           leaf name {
             type leafref {
               path "../../../../../../../../../../"
                  + "rt:ribs/rt:rib/rt:name";
             }
             description
               "Одна топология разрешена для этого интерфейса.";
           }

           uses multi-topology-interface-config;
         }
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/ospf/"
           + "areas/area/interfaces/interface" {
       when "derived-from-or-self(../../../../../rt:type, "
          + "'ospfv3')" {
         description
           "Это дополнение действительно лишь для OSPFv3.";
       }
       description
         "Дополнение состояния конфигурации OSPFv3, связанной 
          с интерфейсом.";
       uses ospfv3-interface-config;
       uses ospfv3-interface-state;
     }

     grouping route-content {
       description
         "Эта группировка определяет атрибуты маршрута,
          связанные с OSPF.";
       leaf metric {
         type uint32;
         description
           "Метрика маршрута OSPF.";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Тег маршрута OSPF.";
       }
       leaf route-type {
         type route-type;
         description
           "Тип маршрута OSPF.";
       }
     }

     augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
       when "derived-from(rt:source-protocol, 'ospf')" {
         description
           "Это дополнение действительно лишь для маршрутов,
            полученных от протокола OSPF.";
       }
       description
         "Связанные с OSPF атрибуты маршрута.";
       uses route-content;
     }

     /*
      * RPC
      */

     rpc clear-neighbor {
       description
         "Этот вызов RPC очищает указанный набор соседей OSPF.
          При отказе по внутренним причинам OSPF следует возвращать
          error-tag и error-app-tag, соответствующие ошибке.";
       input {
         leaf routing-protocol-name {
           type leafref {
             path "/rt:routing/rt:control-plane-protocols/"
                + "rt:control-plane-protocol/rt:name";
           }
           mandatory true;
           description
             "Экземпляр протокола OSPF для которого удаляются соседи.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag routing-protocol-instance-not-found.";
         }

         leaf interface {
           type if:interface-ref;
           description
             "Имя экземпляра OSPF, для которого удаляются соседи.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag ospf-interface-not-found.";
         }
       }
     }

     rpc clear-database {
       description
         "Этот вызов RPC очищает указанную базу OSPF Link State. Кроме 
          того, все отношения соседства переводятся в состояние DOWN,
          а самосозданные LSA реорганизуются. При отказе операции по
          внутренним причинам OSPF следует указывать причину в error-tag
          и error-app-tag.";
       input {
         leaf routing-protocol-name {
           type leafref {
             path "/rt:routing/rt:control-plane-protocols/"
                + "rt:control-plane-protocol/rt:name";
           }
           mandatory true;
           description
             "Экземпляр протокола OSPF, для которого очищается LSDB.

              Если указанного экземпляра OSPF нет, эту операцию НУЖНО
              завершать отказом с error-tag data-missing и
              error-app-tag routing-protocol-instance-not-found.";
         }
       }
     }

     /*
      * Уведомления
      */

     grouping notification-instance-hdr {
       description
         "Группировка с описаниями связанных с экземпляром общих
          уведомления OSPF.";

       leaf routing-protocol-name {
         type leafref {
           path "/rt:routing/rt:control-plane-protocols/"
              + "rt:control-plane-protocol/rt:name";
         }
         must "derived-from( "
            + "/rt:routing/rt:control-plane-protocols/"
            + "rt:control-plane-protocol[rt:name=current()]/"
            + "rt:type, 'ospf')";
         description
           "Имя экземпляра протокола маршрутизации OSPF.";
       }

       leaf address-family {
         type leafref {
           path "/rt:routing/"
              + "rt:control-plane-protocols/rt:control-plane-protocol"
              + "[rt:name=current()/../routing-protocol-name]/"
              + "ospf/address-family";
         }
         description
           "Семейство адресов экземпляра OSPF.";
       }
     }

     grouping notification-interface {
       description
         "Группировка для сведений об интерфейсе в связанных с
          интерфейсами уведомлениях OSPF.";

       choice if-link-type-selection {
         description
           "Варианты типов канала.";
         container interface {
           description
             "Обычный интерфейс.";
           leaf interface {
             type if:interface-ref;
             description
               "Интерфейс.";
           }
         }
         container virtual-link {
           description
             "Виртуальный канал.";
           leaf transit-area-id {
             type area-id-type;
             description
               "Area ID.";
           }
           leaf neighbor-router-id {
             type rt-types:router-id;
             description
               "Router ID соседа.";
           }
         }
         container sham-link {
           description
             "Фиктивный канал.";
           leaf area-id {
             type area-id-type;
             description
               "Area ID.";
           }
           leaf local-ip-addr {
             type inet:ip-address;
             description
               "Локальный адрес фиктивного канала.";
           }
           leaf remote-ip-addr {
             type inet:ip-address;
             description
               "Удаленный адрес фиктивного канала.";
           }
         }
       }
     }

     grouping notification-neighbor {
       description
         "Группировка для сведений о соседе в связанных
          с соседями уведомлениях.";

       leaf neighbor-router-id {
         type rt-types:router-id;
         description
           "Router ID соседа.";
       }

       leaf neighbor-ip-addr {
         type inet:ip-address;
         description
           "Адрес соседа.";
       }
     }

     notification if-state-change {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf state {
         type if-state-type;
         description
           "Состояние интерфейса.";
       }
       description
         "Это уведомление передаётся при обнаружении
          смены состояния интерфейса.";
     }

     notification if-config-error {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf packet-source {
         type inet:ip-address;
         description
           "Адрес источника.";
       }

       leaf packet-type {
         type packet-type;
         description
           "Тип пакета OSPF.";
       }

       leaf error {
         type enumeration {
           enum bad-version {
             description
               "Непригодня версия.";
           }
           enum area-mismatch {
             description
               "Несоответствие областей.";
           }
           enum unknown-nbma-nbr {
             description
               "Неизвестный сосед NBMA.";
           }
           enum unknown-virtual-nbr {
             description
               "Неизвестный сосед по виртуальному каналу.";
           }
           enum auth-type-mismatch {
             description
               "Несоответствие типа аутентификации.";
           }
           enum auth-failure {
             description
               "Отказ при аутентификации.";
           }
           enum net-mask-mismatch {
             description
               "Несоответствие маски сети.";
           }
           enum hello-interval-mismatch {
             description
               "Несоответствие интервала Hello.";
           }
           enum dead-interval-mismatch {
             description
               "Несоответствие интервала Dead.";
           }
           enum option-mismatch {
             description
               "Несоответствие опций.";
           }
           enum mtu-mismatch {
             description
               "Несоответствие MTU.";
           }
           enum duplicate-router-id {
             description
               "Дубликат Router ID.";
           }
           enum no-error {
             description
               "Нет ошибок.";
           }
         }
         description
           "Коды ошибок.";
       }
       description
         "Это уведомление передаётся при получении пакета, указывающего
          ошибку настройки интерфейса передающего маршрутизатора OSPF.";
     }

     notification nbr-state-change {
       uses notification-instance-hdr;
       uses notification-interface;
       uses notification-neighbor;

       leaf state {
         type nbr-state-type;
         description
           "Состояние соседа.";
       }

       description
         "Это уведомление передаётся при обнаружении смены состояния
          соседа.";
     }

     notification nbr-restart-helper-status-change {
       uses notification-instance-hdr;
       uses notification-interface;
       uses notification-neighbor;

       leaf status {
         type restart-helper-status-type;
         description
           "Состояние помошника в перезапуске.";
       }

       leaf age {
         type rt-types:timer-value-seconds16;
         description
           "Оставшееся время текущего интервала аккуратного перезапуска
            OSPF, когда маршрутизатор служит помощником для соседа.";
       }

       leaf exit-reason {
         type restart-exit-reason-type;
         description
           "Причина завершения помощника при перезапуске.";
       }
       description
         "Это уведомление передаётся при обнаружении смены состояния
          помощника при перезапуске соседа.";
     }

     notification if-rx-bad-packet {
       uses notification-instance-hdr;
       uses notification-interface;

       leaf packet-source {
         type inet:ip-address;
         description
           "Адрес источника.";
       }

       leaf packet-type {
         type packet-type;
         description
           "Тип пакета OSPF.";
       }

       description
         "Это уведомление передаётся при невозможности анализа пакета
          OSPF, принятого на интерфейсе OSPF.";
     }

     notification lsdb-approaching-overflow {
       uses notification-instance-hdr;

       leaf ext-lsdb-limit {
         type uint32;
         description
           "Максимальное число не заданных по умолчанию AS-External-LSA,
            которые можно сохранить в базе LSDB.";
       }

       description
         "Это уведомление передаётся, когда число LSA в LSDB 
          маршрутизатора превысит 90% от предела ext-lsdb-limit.";
     }

     notification lsdb-overflow {
       uses notification-instance-hdr;

       leaf ext-lsdb-limit {
         type uint32;
         description
           "Максимальное число не заданных по умолчанию AS-External-LSA,
            которые можно сохранить в базе LSDB.";
       }

       description
         "Это уведомление передаётся, когда число LSA в LSDB 
          маршрутизатора превысит предел ext-lsdb-limit.";
     }

     notification nssa-translator-status-change {
       uses notification-instance-hdr;

       leaf area-id {
         type area-id-type;
         description
           "Area ID.";
       }

       leaf status {
         type nssa-translator-state-type;
         description
           "Состояние транслятора NSSA.";
       }

       description
         "Это уведомление передаётся при смене роли маршрутизатора в
          трансляции OSPF NSSA-LSA в OSPF AS-External-LSA.";
     }

     notification restart-status-change {
       uses notification-instance-hdr;

       leaf status {
         type restart-status-type;
         description
           "Состояние перезапуска.";
       }

       leaf restart-interval {
         type uint16 {
           range "1..1800";
         }
         units "seconds";
         default "120";
         description
           "Интервал перезапуска.";
       }

       leaf exit-reason {
         type restart-exit-reason-type;
         description
           "Причина выхода для перезапуска.";
       }

       description
         "Это уведомление передаётся при смене состояния аккуратного
          перезапуска для маршрутизатора.";
     }
   }
   <CODE ENDS>

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

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

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

/ospf

/ospf/areas/

/ospf/areas/area[area-id]

/ospf/virtual-links/

/ospf/virtual-links/virtual-link[transit-area-id router-id]

/ospf/areas/area[area-id]/interfaces

/ospf/areas/area[area-id]/interfaces/interface[name]

/ospf/area/area[area-id]/sham-links

/ospf/area/area[area-id]/sham-links/sham-link[local-id remote-id]

Доступные для записи узлы данных представляют конфигурацию экземпляров, областей, виртуальных каналов, фиктивных (sham) каналов и интерфейсов и соответствуют указанным выше узлам схемы.
Для OSPF возможность изменения конфигурации позволяет скомпрометировать целиком домен OSPF, включая партнерство с несанкционированными маршрутизаторами для нарушения маршрутизации трафика и организацию массированных атак на службы (Denial-of-Service или DoS). Например, активизация OSPF на любом незащищённом интерфейсе позволить организовать смежность OSPF с несанкционированным и враждебным соседом. После организации смежности возможен перехват трафика. Например, может быть организована DoS-атака путём изменения стоимости интерфейса OSPF с введением асимметрии и возникновением жёсткой петли. Как правило, несанкционированное изменение большинства функций OSPF создаёт свой риск безопасности. Следует обратиться к разделу Security Considerations в соответствующих RFC.

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/ospf/database

/ospf/areas/area[area-id]/database

/ospf/virtual-links/virtual-link[transit-area-id router-id]/database

/ospf/areas/area[area-id]/interfaces/interface[name]/database

/ospf/area/area[area-id]/sham-links/sham-link[local-id remote-id]/database

Раскрытие базы состояний каналов (LSDB) будет подробно показывать топологию сети. Имеются отдельные базы LSDB для каждого интерфейса, области, виртуального и фиктивного канала, интерфейса. Соответствующие узлы данных показаны выше.
Раскрытие LSDB включает сведения, выходящие за рамки маршрутизатора OSPF. Это может быть нежелательно, поскольку может приводить к атакам. Кроме того, в случае раскрытия LSDB области можно восстановить целиком топологию IP-сети, а при развёртывании TE — и этой топологии. Операторы могут считать свою топологию конфиденциальной.

Для аутентификации OSPF конфигурация поддерживается через указание цепочек ключей [RFC8177] или прямое указание ключа и алгоритма проверки подлинности. Поэтому настройка аутентификации с использованием варианта (case) auth-key-chain в контейнере ospfv2-auth-specification или ospfv3-auth-specification наследует вопросы безопасности [RFC8177]. Это включает соображения о локальном хранении и обработке ключей аутентификации.

Кроме того, поддерживается локальное задание ключей аутентификации OSPF и связанных с ними алгоритмов для унаследованных реализаций, не поддерживающих цепочки ключей [RFC8177]. реализациям рекомендуется переходить на цепочки ключей, поскольку они обеспечивают (1) бесшовную смену ключей и алгоритмов, (2) задании ключей в шестнадцатеричном формате, повышающем энтропию ключа и (3) шифрование ключей с использованием алгоритма AES Key Wrap с заполнением (Padding) [RFC5649].

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

  • Модуль YANG OSPF поддерживает RPC clear-neighbor и clear-database, компрометация доступа к которым позволяет использовать временные отказы сети для организации DoS-атаки.

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

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

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

   URI:  urn:ietf:params:xml:ns:yang:ietf-ospf
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

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

   Name:  ietf-ospf
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-ospf
   Prefix:  ospf
   Reference:  RFC 9129

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

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

[RFC1765] Moy, J., «OSPF Database Overflow», RFC 1765, DOI 10.17487/RFC1765, March 1995, <https://www.rfc-editor.org/info/rfc1765>.

[RFC1793] Moy, J., «Extending OSPF to Support Demand Circuits», RFC 1793, DOI 10.17487/RFC1793, April 1995, <https://www.rfc-editor.org/info/rfc1793>.

[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>.

[RFC2328] Moy, J., «OSPF Version 2», STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC3101] Murphy, P., «The OSPF Not-So-Stubby Area (NSSA) Option», RFC 3101, DOI 10.17487/RFC3101, January 2003, <https://www.rfc-editor.org/info/rfc3101>.

[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, «Graceful OSPF Restart», RFC 3623, DOI 10.17487/RFC3623, November 2003, <https://www.rfc-editor.org/info/rfc3623>.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, «Traffic Engineering (TE) Extensions to OSPF Version 2», RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.

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

[RFC4552] Gupta, M. and N. Melam, «Authentication/Confidentiality for OSPFv3», RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.

[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, «Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4576, DOI 10.17487/RFC4576, June 2006, <https://www.rfc-editor.org/info/rfc4576>.

[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, «OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4577, DOI 10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, «Multi-Topology (MT) Routing in OSPF», RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.

[RFC4973] Srisuresh, P. and P. Joseph, «OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering», RFC 4973, DOI 10.17487/RFC4973, July 2007, <https://www.rfc-editor.org/info/rfc4973>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, «The Generalized TTL Security Mechanism (GTSM)», RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.

[RFC5185] Mirtorabi, S., Psenak, P., Lindem, A., Ed., and A. Oswal, «OSPF Multi-Area Adjacency», RFC 5185, DOI 10.17487/RFC5185, May 2008, <https://www.rfc-editor.org/info/rfc5185>.

[RFC5187] Pillay-Esnault, P. and A. Lindem, «OSPFv3 Graceful Restart», RFC 5187, DOI 10.17487/RFC5187, June 2008, <https://www.rfc-editor.org/info/rfc5187>.

[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, «The OSPF Opaque LSA Option», RFC 5250, DOI 10.17487/RFC5250, July 2008, <https://www.rfc-editor.org/info/rfc5250>.

[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., «Basic Specification for IP Fast Reroute: Loop-Free Alternates», RFC 5286, DOI 10.17487/RFC5286, September 2008, <https://www.rfc-editor.org/info/rfc5286>.

[RFC5309] Shen, N., Ed. and A. Zinin, Ed., «Point-to-Point Operation over LAN in Link State Routing Protocols», RFC 5309, DOI 10.17487/RFC5309, October 2008, <https://www.rfc-editor.org/info/rfc5309>.

[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., «Traffic Engineering Extensions to OSPF Version 3», RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, «OSPF for IPv6», RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, «OSPF Link-Local Signaling», RFC 5613, DOI 10.17487/RFC5613, August 2009, <https://www.rfc-editor.org/info/rfc5613>.

[RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, «Dynamic Hostname Exchange Mechanism for OSPF», RFC 5642, DOI 10.17487/RFC5642, August 2009, <https://www.rfc-editor.org/info/rfc5642>.

[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, «OSPFv2 HMAC-SHA Cryptographic Authentication», RFC 5709, DOI 10.17487/RFC5709, October 2009, <https://www.rfc-editor.org/info/rfc5709>.

[RFC5714] Shand, M. and S. Bryant, «IP Fast Reroute Framework», RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.

[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, «Support of Address Families in OSPFv3», RFC 5838, DOI 10.17487/RFC5838, April 2010, <https://www.rfc-editor.org/info/rfc5838>.

[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>.

[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, «OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol», RFC 6565, DOI 10.17487/RFC6565, June 2012, <https://www.rfc-editor.org/info/rfc6565>.

[RFC6845] Sheth, N., Wang, L., and J. Zhang, «OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type», RFC 6845, DOI 10.17487/RFC6845, January 2013, <https://www.rfc-editor.org/info/rfc6845>.

[RFC6860] Yang, Y., Retana, A., and A. Roy, «Hiding Transit-Only Networks in OSPF», RFC 6860, DOI 10.17487/RFC6860, January 2013, <https://www.rfc-editor.org/info/rfc6860>.

[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, «OSPF Stub Router Advertisement», RFC 6987, DOI 10.17487/RFC6987, September 2013, <https://www.rfc-editor.org/info/rfc6987>.

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

[RFC7166] Bhatia, M., Manral, V., and A. Lindem, «Supporting Authentication Trailer for OSPFv3», RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.

[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., «Security Extension for OSPFv2 When Using Manual Key Management», RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.

[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, «Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)», RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.

[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, «OSPFv2 Prefix/Link Attribute Advertisement», RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.

[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, «Extensions to OSPF for Advertising Optional Router Capabilities», RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.

[RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, «Advertising Node Administrative Tags in OSPF», RFC 7777, DOI 10.17487/RFC7777, March 2016, <https://www.rfc-editor.org/info/rfc7777>.

[RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, «OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators», RFC 7884, DOI 10.17487/RFC7884, July 2016, <https://www.rfc-editor.org/info/rfc7884>.

[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>.

[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, «YANG Data Model for Key Chains», RFC 8177, DOI 10.17487/RFC8177, June 2017, <https://www.rfc-editor.org/info/rfc8177>.

[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>.

[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>.

[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>.

[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>.

[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>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, «A YANG Data Model for Routing Management (NMDA Version)», RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

[RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, «Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs», RFC 8405, DOI 10.17487/RFC8405, June 2018, <https://www.rfc-editor.org/info/rfc8405>.

[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>.

[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, «Signaling Maximum SID Depth (MSD) Using OSPF», RFC 8476, DOI 10.17487/RFC8476, December 2018, <https://www.rfc-editor.org/info/rfc8476>.

[RFC9314] Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed., Pallagatti, S., and G. Mirsky, «YANG Data Model for Bidirectional Forwarding Detection (BFD)», RFC 9314, DOI 10.17487/RFC9314, September 2022, <https://www.rfc-editor.org/info/rfc9314>.

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

[RFC0905] International Organization for Standardization, «ISO Transport Protocol specification ISO DP 8073», RFC 905, DOI 10.17487/RFC0905, April 1984, <https://www.rfc-editor.org/info/rfc905>.

[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, «OSPF Version 2 Management Information Base», RFC 4750, DOI 10.17487/RFC4750, December 2006, <https://www.rfc-editor.org/info/rfc4750>.

[RFC5443] Jork, M., Atlas, A., and L. Fang, «LDP IGP Synchronization», RFC 5443, DOI 10.17487/RFC5443, March 2009, <https://www.rfc-editor.org/info/rfc5443>.

[RFC5643] Joyal, D., Ed. and V. Manral, Ed., «Management Information Base for OSPFv3», RFC 5643, DOI 10.17487/RFC5643, August 2009, <https://www.rfc-editor.org/info/rfc5643>.

[RFC5649] Housley, R. and M. Dworkin, «Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm», RFC 5649, DOI 10.17487/RFC5649, September 2009, <https://www.rfc-editor.org/info/rfc5649>.

[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>.

[RFC5881] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)», RFC 5881, DOI 10.17487/RFC5881, June 2010, <https://www.rfc-editor.org/info/rfc5881>.

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

Авторы благодарны Yi Yang, Alexander Clemm, Gaurav Gupta, Ladislav Lhotka, Stephane Litkowski, Greg Hankins, Manish Gupta, Michael Darwish, Alan Davey, Renato Westphal за подробные рецензии и полезные замечания.

Спасибо Tom Petch за рецензию Last Call и улучшение организации документа.

Спасибо Alvaro Retana за комментарии AD.

Спасибо Benjamin Kaduk, Suresh Krishnan, Roman Danyliw за комментарии IESG review.

Принадлежность автора к MITRE Corporation указана лишь для идентификации и не означает явного согласия или поддержки корпорацией MITRE высказанных суждений, мнений ил точек зрения. Корпорация MITRE одобрила публикацию этого документа для Public Release, Distribution Unlimited с Public Release Case Number 18-3194.

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

Dean Bogdanovic
Volta Networks, Inc.
Email: dean@voltanet.io
 
Kiran Koushik Agrahara Sreenivasa
Verizon
500 W Dove Rd
Southlake, TX 76092
United States of America
Email: kk@employees.org

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

Derek Yeung
Arrcus, Inc.
2077 Gateway Place, Suite 400
San Jose, CA 95110
United States of America
Email: derek@arrcus.com
 
Yingzhen Qu
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.qu@futurewei.com
 
Jeffrey Zhang
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: zzhang@juniper.net
 
Ing-Wher Chen
The MITRE Corporation
Email: ingwherchen@mitre.org
 
Acee Lindem
Cisco Systems
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee@cisco.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9316 Intent Classification

Internet Research Task Force (IRTF)                                C. Li
Request for Comments: 9316                                 China Telecom
Category: Informational                                         O. Havel
ISSN: 2070-1721                                                A. Olariu
                                                     Huawei Technologies
                                                       P. Martinez-Julia
                                                                    NICT
                                                                J. Nobre
                                                                   UFRGS
                                                                D. Lopez
                                                         Telefonica, I+D
                                                            October 2022

Intent Classification

Классификация намерений

PDF

Аннотация

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

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

Документ является результатом работы исследовательской группы IRTF Network Management Research Group (NMRG).

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы IRTF1. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы Coding for Efficient Network Communications в рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

Оглавление

Исключено в версии HTML

1. Введение

Концепция основанных на намерениях сетей привлекла широкое внимание, поскольку она обещает упростить управления сетям с участием людей. Это достигается простым указанием того, что должно происходить в сети без задания инструкций, как это делать. Такая перспектива побудила многих исследователей и коммуникационные компании изучать это новое представление, а множество органов стандартизации Standards Development Organization или SDO) — предлагать различные модели намерений.

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

Документ представляет согласованный взгляд исследовательской группы по управлению сетями (NMRG). Документ прошёл тщательное рецензирование членами исследовательской группы, активно вовлеченными в разработки и исследование рассматриваемой в документе технологии. Документ не является результатом работы IETF и стандартом.

1.1. Исследования

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

  • Выражение и распознавание намерений ([Bezahaf21], [Bezahaf19], [Jacobs18]). Использование единой классификации может обеспечить согласованное понимание различных предлагаемых и исследуемых форм выражения намерений.

  • Организация (оркестровка) интеллектуальных автономных сетей радиодоступа (radio access network или RAN) [Banerjee21], где намерения классифицируются по их содержимому.

  • Верификация сети намерений [Tian19], где ведётся работа над созданием языка намерений.

Этот документ уже оказался весьма актуальным для сообщества исследователей, поскольку он послужил основой для предложения самогенерируемых систем на основе намерений [Bezahaf19], для продвижения виртуальных сетевых функций (Virtual Network Function или VNF) на основе сетей IBN2, которые полагаются на определения профилей намерений пользователя, соответствующих абстрактным сетевым службам [Leivadeas21], для повышения эффективности решений по предоставлению сетей на основе намерений, создания новых подходов к управлению службами [Davoli21] и даже определения для пользователей грамматики задания высокоуровневых требований к выбору blockchain в форме намерений [Padovan20]. Этот документ был упомянут в исследованиях, посвящённых интеллектуальным автономным сетям на основе намерений [Mehmood21] [Szilagyi21].

В документе также описан пример успешного применения этого предложения в академической среде [POC-IBN] исследователями в сфере программно-определяемых сетей и виртуализации сетевых функций (Software-Defined Networking / Network Function Virtualization или SDN/NFV) для определения сферы действия их проекта. Конкретная задача, которую решают исследователи, состоит в определении способов применения концепции намерений на разных уровнях, соответствующих разным заинтересованным сторонам.

Технический комитет IEEE по эксплуатации и управлению сетями (IEEE Communications Society Technical Committee on Network Operation and Management или IEEE-CNOM), исследовательская группа IRTF Network Management и IFIP WG6.6 разработали таксономию для управления сетями и службами [IFIP-NSM], применяемую исследовательским сообществом в сфере управления и эксплуатации сетей для структурирования сферы исследований с помощью чётко заданного набора ключевых слов и повышения катества обзоров в журнальных публикациях, конференциях и семинарах. Предложенная здесь таксономия намерений может послужить расширением для управления на основе намерений.

1.2. Стандарты и открытый код

Несколько SDO и проектов с открытым кодом, такие как IRTF NMRG, Open Networking Foundation (ONF) [ONF] / Open Network Operating System (ONOS) [ONOS], European Telecommunications Standards Institute (ETSI) / Experiential Networked Intelligence (ENI) и TMF с его автономными сетями, высказали намерения определить набор сетевых операций для декларативного выполнения.

Совсем недавно в IRTF NMRG был выпущен документ «Intent-Based Networking — Concepts and Definitions» [RFC9315], разъясняющий концепцию намерений (Intent) и содержащий обзор связанной с ней функциональности. Цель документа состоит в продвижении единому базовому пониманию терминов, концепций и функциональности, которое может послужить основой для последующего определения связанных исследовательских и инженерных задач и способов их решения.

Данный документ вместе с [RFC9315] предназначен служить основой для будущих дискуссий, связанных с намерениями, применительно к NMRG.

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

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

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

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

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

1.3. Область действия

Основное внимание в этом документе уделено определению критериев, позволяющих классифицировать намерения с точки зрения заинтересованных сторон. Концепции и определения, связанные с IBN представлены в [RFC9315]. Намерения рассмотрены, прежде всего, в контексте сети, однако не исключаются и другие типы намерений, представленные в параграфах 4.4 и 6.2.

Невозможно полностью дифференцировать намерения на основе лишь общих характеристик, за которыми следуют концепции, термины и намерения. В документе разъясняется, что представляют собой намерения для разных заинтересованных сторон путём классификации по различным измерениям, таким как решения, намерения пользователей и типы намерений. Такая классификация обеспечивает единое для всех участников понимание и служит для определения области действия и приоритета отдельных проектов, подтверждения концепций (proof of concept или PoC), исследований и проектов с открытым кодом.

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

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

AI

Artificial Intelligence — искусственный интеллект.

CE

Customer Equipment — клиентское оборудование.

CFS

Customer Facing Service — обслуживание клиентов.

CLI

Command-Line Interface — интерфейс командной строки, командный интерфейс.

DB

Database — база данных.

DC

Data Center — центр обработки данных, ЦОД

ECA

Event Condition Action — действие по событию.

GBP

Group-Based Policy — политика по группам.

GPU

Graphics Processing Unit — графический процессор.

IBN

Intent-Based Network — сеть на основе намерений.

NFV

Network Function Virtualization — виртуализация сетевой функции.

O&M

OAM & Maintenance — OAM и техническое обслуживание (поддержка).

ONF

Open Networking Foundation — фонд открытых сетей.

ONOS

Open Network Operating System — открытая сетевая операционная система (ОС).

PNF

Physical Network Function — функция физической сети.

QoE

Quality of Experience — качество опыта (работы).

RFS

Resource Facing Service — обслуживание ресурсов.

SDO

Standards Development Organization — орган стандартизации.

SD-WAN

Software-Defined Wide-Area Network — программно-управляемая распределенная сеть (WAN).

SLA

Service Level Agreement — соглашение об уровне обслуживания.

SUPA

Simplified Use of Policy Abstractions — упрощенное применение абстракций.

VM

Virtual Machine — виртуальная машина.

VNF

Virtual Network Function — виртуальная сетевая функция.

3. Определения

Единое базовое понимание терминов и определений для IBN представлено в [RFC9315], как показано ниже.

Intent — намерения

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

Intent-Based Network

Сеть, управляемая с использованием намерений.

Policy — правила (политика)

Набор правил, определяющих выбор поведения системы.

Intent User — пользователь намерений

Пользователь, задающий и вносящий запросы намерений для системы управления на основе намерений.

Другие определения, относящиеся к этому документу, такие как область действия намерений (intent scope), сетевая область действия намерений (intent network scope), абстракция намерений (intent abstraction), жизненный цикл намерений (intent life cycle) представлены в разделе 5. Функциональные характеристики и поведение.

4. Абстрактные требования к намерениям

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

4.1. Что такое намерения?

Термин «намерения» (Intent) получил очень широкое распространение в отрасли для разных целей, иногда не согласующихся с общими принципами SDO, отмеченными в разделе 1. В [RFC9315] даны разъяснения относительно того, что считать намерениями и чем намерения отличаются от правил и служб.

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

4.2. Решения и пользователи намерений

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

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

В таблице 1 указаны решения и пользователи намерения, которые необходимо поддерживать сети IBN.

Таблица 1. Решения и пользователи намерений.

Решения

Пользователи намерений

Сети операторов

Сетевые операторы, Разработчики услуг и приложений, операторы услуг, клиенты и подписчики

Сети ЦОД

Администраторы облаков и базовых сетей, разработчики приложений, клиенты и арегдаторы

Сети предприятий

Администраторы корпоративных сетей, разработчики приложений, конечные пользователи

Эти решения и пользователи намерений являются стартовой точкой для классификации и применяются методикой , представленной в параграфе 6.1. Методика классификации намерений.

  • Например, для сетей операторов желание клиента (подписчика) смотреть видео с высоким разрешением ведёт к представлению его намерений преобразованием видеороликов в формат 1080p.

  • Для ЦОД у администраторов имеются свои чёткие намерения для сети, такие как распределение нагрузки. Для всех потоков трафика, требующих цепочки услуг NFV, они могут ограничить максимальную загрузку любого узла/контейнера VNF значением 50%, а для сетевых каналов — не более 70%.

  • Для корпоративных сетей при проведении видеоконференций требуется множественный удалённый доступ. Намерения администратора сети могут быть выражены, например, обеспечить для каждого пользователя этого приложения время доставки голографических объектов в интервал 50 мсек.

4.3. Преимущества намерений для заинтересованных сторон

Современные сетевые API и CLI стали слишком сложными по причине глубокой интеграции с низкоуровневыми концепциями сетей. От клиентов, разработчиков приложений и конечных пользователей не следует требовать установки адресов IP, VLAN, подсетей, портов, тогда как операторы сетей могут хотеть сохранения технического и сетевого контроля. Все заинтересованные стороны получат преимущества от упрощений интерфейсов, таких как:

  • запрос приоритетного (gold) VPN-сервиса между сайтами A, B, C;

  • резервирование CE между сайтами клиента;

  • добавление правил доступа к сетевой служте.

Операторы и администраторы вручную ищут неполадки и исправляют свои сети и службы. Вместо этого они хотят:

  • упрощения и автоматизации сетевых операций;

  • упрошения определений сетевых служб;

  • предоставления простых клиентских API для дополнительных услуг (операторов);

  • информирования об отличии поведения сети или службы от запрошенного;

  • возможности автоматической оптимизации и корректировки для выбранных сценариев;

  • наличия систем, обучающихся на основе исторической информации и поведения.

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

  • выстраивать свои сетевые службы и правила через простые интерфейсы без необходимости технических знаний о сетях;

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

4.4. Типы намерений, которые необходимо поддерживать

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

  • Намерения для обслуживания клиентов

    • самообслуживание клиентов с SLA;

    • заказы операторов служб.

  • Намерения для служб сети и базовой (underlay) сети

    • заказы операторов служб;

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

    • намерения, созданные и представленные администратором базовой сети.

  • Намерения для сети и базовой сети

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

    • увтоматизированное управление жизненным циклом сетевых конфигураций;

    • сетевые ресурсы (коммутаторы, маршрутизаторы, маршрутизация, правила, базовая сеть).

  • Намерения для управления облаком

    • конфигурация ЦОД, VM, серверы баз данных и приложений;

    • связь между VM.

  • Намерения для управления ресурсами облака

    • управление жизненным циклом ресурсов облака (самонастройка по правилам, автоматической масштабирование, восстановление и оптимизация).

  • Стратегические намерения

    • безопасность, QoS, политика приложений, управление трафиком и т. п.;

    • настройка и монитринг правил, генерация сигналов при несоответствии, автоматическое восстановление;

    • создание моделей и правил для сетей и сетевых служб;

    • создание рабочих процессов, моделей и правил для намерений управления эксплуатацией.

  • Намерения для задач эксплуатации

    • перенос сетей;

    • замена устройств;

    • обновление сетевых программ;

    • автоматизация любых задач, часто выполняемых операторами и администраторами.

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

5. Функциональные характеристики и поведение

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

5.1. Абстрагирование намерений

Моделирование намерений можно абстрагировать с помощью триплетов {контекст, возможности, ограничения}.

  • Контекст обосновывает намерение и определяет, уместно ли оно в текущей ситуации, т.е выбирает намерения на основе применимости.

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

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

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

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

5.2. Типы пользователей намерений

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

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

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

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

5.3. Область действия намерений

Намерения служат для управления поведением сетей, в которых они применяются, и все намерения испольняются в конкретной области (scope), такой как:

  • область связности, если намерение создаёт или изменяет соединения;

  • область безопасности/приватности, если намерение меняет защитные характеристики для сети, клиентов, конечных пользователей;

  • область приложения, если намерение задаёт приложение для воздействия;

  • область QoS, когда намерение задаёт характеристики QoS для сети.

Эти области действия намерений применяются методикой, представленной в параграфе 6.1. Методика классификации намерений.

5.4. Намерения для сети

Независимо от типа пользователей намерений, их запросы влияют на сеть или её компоненты, служащие целью намерения. Таким образом, область действия намерения в сети или цель политики (в сфере декларативно политики) может представлять VNF или PNF, элементы физической сети, кампусные сети, SD-WAN, RAN, границы облаков, облака, филиалы и т. п..

5.5. Абстракция намерений

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

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

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

В соответствии с определением термина «намерения» в [RFC9315], низкоуровневые намерения не считаются намерениями. Однако эта классификация сохраняется здесь для идентификации PoC, демонстраций, примеров использования, которые по-прежнему требуют или применяют низкий уровень абстакции для намерений.

5.6. Жизненный цикл намерений

Намерения можно разделить на временные и постоянные (сохраняющиеся).

Transient — временные

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

Persistent — постоянные

Намерение имеет управляемый жизненный цикл. После успешной активации и развёртывания намерения система сохраняет все относящиеся к делу намерения активными, пока они не будут деактивированы или удалены.

5.7. Уровни самоуправления

На разных фазах сетей с самоуправлением [TMF-AUTO] намерения различаются. В зависимости от уровня автономности сети для общего решения могут быть разные требования и типы намерений. Например, на нижних уровнях намерения клиента:

  • автоматически преобразуются в правила конфигурации лишь на более высоких уровнях;

  • охватывают весь жизненный цикл;

  • преобразуются в правила конфигурации и мониторинга;

  • обеспечивают сами себя с помощью AI.

Ниже приведены типовые примеры автономных (самоуправляемых) сетей уровня 0 — 5.

Уровень 0 — традиционная сеть с ручным управлением

Персонал O&M вручную управляет сетью, получая сигналы тревоги и записи системного журнала.
  • Нет намерений.

Уровень 1 — частично автоматизированная сеть

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

Уровень 2 — автоматизированная сеть

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

Уровень 3 — сеть с самооптимизацией

Глубокое понимание состояния сети и автоматическое управление сетью в соответствии с требованиями пользователей намерений в сети.
  • Намерения, основанные на понимании состояния сети.

Уровень 4 — сеть с частичным самоуправлением

В ограниченной среде людям не нужно участвовать в принятии решений и сеть может настраиваться сама.
  • Намерения на основе ограниченного AI.

Уровень 5 — автономная (самоуправляемая) сеть

В разных сетевых средах и условиях сеть может автоматически приспосабливаться и выполнять намерения людей.
  • Намерения на основе AI.

6. Классификация намерений

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

Три классификации в этом документе разработаны с нуля в соответствии с представленной методикой) посредством трёх итераций — для решения в сетях операторов, ЦОД и сетях предприятий. Для каждого из решений указаны конкретные типы намерений и их пользователи. Затем идентифицируется область действия намерений и сети, абстракции и требования жизненного цикла.

Эту классификацию и приведённые таблицы легко расширить. Например для решения в ЦОД указана новая категория «область действия ресурса (resource scope) и соответственно расширена таблица классификации. В будущем, по мере появления новых сценариев, приложений и домено можно будет определить новые классификации и таксономию, следуя предложенной методике.

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

Результатом классификации является таксономия намерений, представленная в параграфах этого раздела.

Таким образом, раздел 6 представляет методику классификации намерений, консолидированную таксономию намерений для трёх решений и конкретные примеры классификации намерений для этих трёх решений (сети операторов, ЦОД и сети предприятий), которые были выведены с использованием предложенной методики и могут быть заполнены для PoC, демонстраций, исследовательских проектов и будущих документов.

6.1. Методика классификации намерений

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

          +------------------------------------------+
          |Знание решений (требования, примеры       |
          |использования, тезнологии, сеть, намерения|
          |пользователей, требования к намерениям)   |
          +----------------+-------------------------+
                           | Ввод              Rx=чтение
                           |                   Ux=обновление 
                  +--------V--------+          (добавить/удалить)
                  |1. Идентификация |
                  |   намерений     +------------+
                  |                 |            |
                  +---------^-+-----+            |
                         R1 | | U1               |
+---------------+ U8        | |    R2         +--v----------------+
|8.Идентификация+---------+ | |   +-----------> 2.Идентификация   |
|  новых        | R8      | | |   | U2        |   типов пользоват.|
|  категорий    <-------- | | |   | +---------+   намерений       |
+--------^------+       | | | |   | |         +-------|-----------+
         |              | | | |   | |                 |
         |             ++-+-v-v---+-v-+               |
+--------+------+ U7   |              | R3     +------v------------+
|7.Идентификация+------> Классификация+--------> 3.Идентификация   |
|  требований   | R7   |  намерений   | U3     |   типа            |
|  жизн. цикла  <------+              <--------+   намерений       |
+--------^------+      +^--^-+--^-+---+        +------|------------+
         |              || | |  | |                   |
         |              || | |  | |                   |
+--------+-----+        || | |  | | R4        +-------v-----------+
|6.Идентификац.| U6     || | |  | +-----------> 4.Идентификация   |
|  абстракций  +---------| | |  |   U4        |   области действия|
|              <---------+ | |  +-------------+   намерений       |
+-------^------+ R6        | |                +-------+-----------+
        |                  | |                        |
        |               U5 | |R5                      |
        |          +-------+-v--------+               |
        |          |5.Идентификация   |               |
        +----------+  области сети    <---------------+
                   +------------------+

Рисунок 1. Методика классификации намерений.


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

  1. Получение сведений из знаний о решении как входных данных для идентификации решения (например, оператор, предприятие, ЦОД). Решения с намерениями проверяются на соответствие имеющейся классификации и могут использоваться (при наличии), добавляться (при отсутствии) или удаляться (при ненужности) из классификации. (R1-U1)

  2. Определяются типы пользователей намерения (клиент, оператор сети или сервиса и т. п.). Просматривается имеющаяся классификация и тип пользователя применяется (при наличии), добавляется (при отсутствии) или удаляется (при ненужности). (R2-U2)

  3. Определяется тип намерения (намерение для сети или обслуживания пользователей и т. п. Просматривается имеющаяся классификация и тип намерения применяется, добавляется или удаляется. (R3-U3)

  4. Определяется область действия намерения (например, связность, приложение) на основе знаний о решении. Просматривается имеющаяся классификация и область действия применяется, добавляется или удаляется. (R4-U4)

  5. Определяются области сети (например, кампус, радидоступ). Просматривается имеющаяся классификация и область применяется, добавляется или удаляется. (R5-U5)

  6. Определяются абстракции (например, технические, нетехнические). Просматривается имеющаяся классификация и абстракции применяются, добавляются или удаляются. (R6-U6)

  7. Определяются требования к жизненному циклу намерения (постоянное, временное). Просматривается имеющаяся классификация и требования применяются, добавляются или удаляются. (R7-U7).

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

6.2. Таксономия намерений

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

Категории сферы намерений на рисунке 2 являются общими для всех 3 решений (операторы, ЦОД, предприятия). Сокращения (Cx) в параграфах 6.3.2 и 6.4.2 указываются в соответствии со столбцами в последующих таблицах.

                             +--------------------------------+
                         +-->|  Оператор   Предприятие   ЦОД  |
                         |   +--------------------------------+
                         |   +--------------------------------+
                         |   |Клиент, подписч., конечн. польз.|
           +----------+  |   |Оператор сети или сервиса       |
         +>+ Решение  +--+   |Разработчик приложений          |
         | +----------+   +->|Администратор предприятия       |
         |                |  |Администратор облака            |
         | +----------+   |  | Администратор базовой сети     |
         +>+Тип       +---+  +--------------------------------+
         | |пользоват.|      +--------------------------------+
         | |намерений |      |Намерения обслуживания клиентов |
         | +----------+      |Стратегические намерения        |
         | +----------+      |Намерения сетевых служб         |
         +>+Тип       +----->|Намерения служб базовой сети    |
+------+ | |намерений |      |Намерения для сети              |
|Намер.+-+ +----------+      |Намерения для базовой сети      |
+------+ |                   |Намерения для эксплуат. задач   |
         | +----------+      |Намерения для управления облаком|
         +>+Сфера     +---+  |Намерения управл. ресурс. облака|
         | |намерений |   |  +--------------------------------+
         | +----------+   |  +--------------------------------+
         |                +->|  Связность   Приложение  QoS   |
         | +----------+      | Безопасность Хранилище Расчёты |
         +>+Сфера     +---+  +--------------------------------+
         | |сети      |   |  +--------------------------------+
         | +----------+   |  |Радиодоступ       Филиал        |
         |                +->|Транспорт. доступ SD-WAN        |
         | +----------+      |Транспорт. агрег. VNF      PNF  |
         +>+Абстракция+----+ |Ядро транспорта   Физическая    |
         | |          |    | |Коай облака       Логическая    |
         | +----------+    | |Ядро облака       Кампус        |
         | +----------+    | +--------------------------------+
         +>+Жизненный |    | +--------------------------------+
           |цикл      +--+ +>|Тезническая       Нетехническая |
           +----------+  |   +--------------------------------+
                         |   +--------------------------------+
                         +-->|Постоянно         Временно      |
                             +--------------------------------+

Рисунок 2. Таксономия намерений.


6.3. Классификация намерений для операторских решений

6.3.1. Пользователи и типы намерений

В этом параграфе выполнены пп. 1 — 3 с рисунка 1, а таблица 2 описывает пользователей и типы намерений в операторских решениях.

Таблица 2. Классификация намерений для операторских решений.

Пользователь

Тип намерения

Описание намерения

Клиент, подписчик

Обслуживание клиентов

Самообслуживание клиента с SLA и дополнительными услугами.
Пример. Всегда поддерживать высокое качество обслуживания и пропускную способность для приоритетных (gold-level) подписчиков.
Описание операций. Измерение состояния перегрузки в сети, задание различных адаптивных параметров для станций с разным приоритетом. Таким образом, при сильной загрузке гарантируется пропускная способность для приоритетных клиентов. В то же время обеспечивается общая загрузка системы и повышается общая пропускная способность.

Стратегические намерения

Клиент создаёт модели и правила для намерений для примеенния в намерениях обслуживание клиентов.
Пример. Запрос надёжного обслуживания в пиковые периоды для видео-приложений.

Сетевой оператор

Намерения сетевой службы

Услуги, предоставляемые оператором сетевой службы клиентам (например, оператор сервиса).
Пример. Запрос сетевого сервиса с гарантиями по задержкам для доступа клиента A.

Намерения для сети

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

Задачи эксплуатации

Оператор сети запрашивает выполнение автоматизированной задачи, отличающейся от намерений для сетевой службы и сети (например, перенос сети, замена сервера или устройства, обновление сетевых программ).
Пример. Запрос переноса всех услуг сети N на резервный путь P.

Стратегические намерения

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

Оператор сервиса

Обслуживание клиентов

Заказы клиентов оператора сервиса, обслуживания клиентов или SLA.
Пример. Обеспечить услугу S с гарантированной пропускной способностью для клиента A.

Намерения для сетевой службы

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

Задачи эксплуатации

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

Стратегические намерения

Оператор сети создаёт модели, намерения политики и рабочие процессы, которые будут применяться намерениями отбслуживания клиентов, намерениями сетевых служб и намерениями эксплуатации. Рабочие процессы могут автоматизировать любые задачи, которые оператор часто выполняет в дополнение к намерениям для сетевых служб и сети.
Пример. Запрос гарантий сетевого обслуживания, позволяющих избежать перегрузок в такие периоды как «Черная пятница» и Рождество.

Разработчик приложений

Обслуживание клиентов

API для намерений обслуживания клиентов, предоставляемый разработчикам приложений.
Пример. API для запроса у сети просмотра HD-видео (4K/8K).

Намерения для сетевой службы

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

Намерения для сети

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

Задачи эксплуатации

API для намерений эксплуатационных задач, предоставляемые разработчикам приложений. Предназначены для доверенных внутренних операторов, сервис-провайдеров, клиентских разработчиков (DevOps).
Пример. API для запроса переноса сервера.

Стратегические намерения

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

6.3.2. Категории намерений

В этом параграфе выполнены пп. 4 — 7 с рисунка 1, а ниже указаны предложенные категории.

Область намерений

C1=связность, C2=безопасность/приватность, C3=приложение, C4=QoS

Область сети

Домен сети

C1=радиодоступ, C2=транспортный доступ, C3=транспортное агрегирование, C4=ядро транспорта, C5=граница облака, C6=ядро облака

Область сетевой функции (NF)

C1=VNF, C2=PNF

Абстракция (ABS)

C1=техническая (с техническим откликом), C2=нетехническая (без технического отклика) (см. параграф 5.2)

Жизненный цикл (L-C)

C1=постоянное (полный жизненный цикл), C2=временное (краткосрочное)

6.3.3. Пример классификации намерений

В этом параграфе дан пример применения методики из параграфа 6.1 для классификации намерений, представленных в демонстрации PoC «A Multi-Level Approach to IBN» [POC-IBN]. Это подтверждения выполнено исследователями в сфере SDN/NFV, решающими задачу применения концепции намерений на разных уровнях, соответствующих различным заинтересованным сторонам. Для исследования применялись два типа намерений — намерения среза (slice) и намерения цепочки услуг (service chain). В PoC [POC-IBN] намерения для среза выражали запрос сетевого среза с 2 типами компонентов — набором виртуальных функций верхнего уровня и набором виртуальных коммутаторов и/или маршрутизаторов L2/ L3 VNF. Намерение для цепочки услуг выражалось запросом услуги, предоставляемой через цепочку компонентов в виртуальных функциях L4-L7.

В соответствии с методикой классификации из параграфа 6.1 можно вывести следующее:

  1. решением для обоих намерений служит сеть оператора;

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

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

  4. областью намерений являются связность и приложение;

  5. областью сети являются VNF, граница и ядро облака;

  6. абстракции возвращают технические сведения для среза и не возвращают для цепочки услуг;

  7. жизненный цикл является постоянным.

На рисунке 3 показано табличное представление этих сведений. X в таблице относится к намерению для среза, Y — для цепочки услуг.

Пользователь

Тип намерений

Область намерений

Обл. NF

Область сети

ABS

L-C

C1

C2

C3

C4

C1

C2

C1

C2

C3

C4

C5

C6

C1

C2

C1

Клиент, подписчик

Обслуживание клиентов

Стратегические намерения

Сетевой оператор

Намерения для сетевой службы

X

X

X

X

X

X

Намерения для сети

Задачи эксплуатации

Стратегические намерения

Оператор сервиса

Намерения клиента

Y

Y

Y

Y

Y

Y

Y

Намерения для сетевой службы

Задачи эксплуатации

Стратегические намерения

Разработчик приложений

Намерения клиента

Намерения для сетевой службы

Намерения для сети

Задачи эксплуатации

Стратегические намерения

Рисунок 3. Пример классификации намерений для операторского решения.

6.4. Классификация намерений для решений ЦОД

6.4.1. Пользователи и типы намерений

В таблице 3 описаны пользователи и типы намерений для решения ЦОД.

Таблица 3. Классификация намерений для ЦОД.

Пользователь

Тип намерения

Описание намерения

Клиент, арендатор

Обслуживание клиентов

Самообслуживание клиентов через портал арендаторов.
Пример. Запрос расчётов на GPU и ресурсов хранилища для поддержки 10 тысяч служб видеонаблюдения.

Стратегические намерения

Намерения для моделей и политики, созданные клиентами/арендаторами, пригодные для повторного использования путём создания экземпляров.
Пример. Запрос динамических ресурсов для расчётов и хранения в указанное время или по дням.

Администратор облака

Управление облаком

Настройка VM, серверов DB, серверов приложений и связи между серверами и VM.
Пример. Запрос связности между VM A, B, C в сети N1.

Намерения управления облачными ресурсами

Самонастройка по правилам, а также восстановление и оптимизация.
Пример. Запрос автоматического управления жизненным циклом облачных ресурсов VM.

Задачи эксплуатации

Администратор облака запрашивает выполнение автоматизированных задач, отличных от намерений по управлению облаком и облачными ресурсами.
Пример. Запрос на обновление операционной системы до версии X на всех VM в сети N1.
Описание операций. Намерение обновить систему может изменить топологию (соединения со службами и партнерами), вызывать обмен данными (обновление содержмого) и придерживаться определённого уровня QoE (выделение достаточных ресурсов). Таким образом, сеть выполняет нужную настройку конфигурации для лучшего исполнения намерения, например, организуются прямые восходящие соединения между трминалами и справедливо выделяются очереди на маршрутизаторах с учётом других сетевых служб.

Стратегические намерения

Администратор облака создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Автоматизация часто выполняемых администратором задач в дополнение к намерениям по управлению жизненным циклом и ресурсами облака.
Пример. При возникноверии угрозы все облачные ресурсы автоматически переносятся в DC2.

Администратор базовой сети

Намерения для базовой сетевой службы

Услуга, создаваемые и предоставляемая администратором базовой сети.
Пример. Запрос базовой службы между DC1 и DC2 с полосой B.

Намерения для базовой сети

Администратор базовой сети запрашивает в масштабе DCN некую конфигурацию базовой сети или её ресурсов.
Пример. Организация и выбеление пула адресов DHCP.

Задачи эксплуатации

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

Стратегические намерения

Администратор облака создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Автоматизация часто выполняемых администратором задач.
Пример. Для потоков трафика, которым нужны цепочки услуг NFV, ограничивается загрузка любого узла или контейнера VNF значением 50%, а максимальная загрузка сетевых каналов — значением 70%.

Разработчик приложений

Управление облаком

API намерений управления облаком для разрабочиков приложений.
Пример. API для запроса конфигурации VM или серверов баз данных.

Управление ресурсами облака

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

Намерения для базовой сетевой службы

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

Намерения для базовой сети

API управления ресурсами базовой сети для разрабочиков приложений.
Пример. API для запроса динамического управления пулами адресов IPv4.

Задачи эксплуатации

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

Стратегические намерения

Разработчик приложений создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Предназначено для внутренних DCN DevOps.
Пример. API для запроса порогов распределения нагрузки.

6.4.2. Категории намерений

Ниже представлены предложенные категории

Область намерений

C1=связность, C2=безопасность/приватность, C3=приложение, C4=QoS, C5=хранилище, C6=расчёты

Область сети

Домен сети

Сеть ЦОД

Область сети DCN (DCN Net)

C1=логическая, C2=физическая

Область ресурса DCN (DCN Res)

C1=виртуальный, C2=физический

Абстракция (ABS)

C1=техническая (с техническим откликом), C2=нетехническая (без технического отклика) (см. параграф 5.2)

Жизненный цикл (L-C)

C1=постоянное (полный жизненный цикл), C2=временное (краткосрочное)

6.4.3. Пример классификации намерений

В этом параграфе приведён пример использования методики из параграфа 6.1 исследовательским сообществом для классификации намерений. Как указано в параграфе 6.3.3, успешное применение предложенной в документе классификации продемонстрировано в PoC «A Multi-Level Approach to IBN» [POC-IBN]. Это подтверждения выполнено исследователями в сфере SDN/NFV, решающими задачу применения концепции намерений на разных уровнях, соответствующих различным заинтересованным сторонам.

Для исследования применялись два типа намерений — намерения среза (slice) и намерения цепочки услуг (service chain). Для решения ЦОД применимы лишь намерения среза. Как указано в параграфе 6.3.3 намерения для среза выражали запрос сетевого среза с 2 типами компонентов — набором виртуальных функций верхнего уровня и набором виртуальных коммутаторов и/или маршрутизаторов L2/ L3 VNF.

В соответствии с методикой классификации из параграфа 6.1 можно вывести следующее:

  1. решением для обоих намерений служит сеть оператора;

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

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

  4. областью намерений являются связность и приложение;

  5. областью сети являются VNF, граница и ядро облака;

  6. абстракции возвращают технические сведения для среза и не возвращают для цепочки услуг;

  7. жизненный цикл является постоянным.

На рисунке 4 показано табличное представление этих сведений. X в таблице относится к намерению для среза.

Пользователь

Тип намерений

Область намерения

DCN Res

DCN Net

ABS

L-C

C1

C2

C3

C4

C5

C6

C1

C2

C1

C2

C1

C2

C1

C2

Клиент, арендатор

Обслуживание клиентов

Стратегические намерения

Администратор облака

Управление облаком

X

X

X

X

X

X

Управление ресурсами облака

Задачи эксплуатации

Стратегические намерения

Администратор базовой сети

Намерения для базовой сети

Намерения для ресурсов базовой сети

Задачи эксплуатации

Стратегические намерения

Разработчик приложений

Управление облаком

Управление ресурсами облака

Намерения для базовой сети

Намерения для ресурсов базовой сети

Задачи эксплуатации

Стратегические намерения

Рисунок 4. Пример классификации намерений для ЦОД.

6.5. Классификация намерений для корпоративных решений

6.5.1. Пользователи и типы намерений

В таблице 4 описаны пользователи и типы намерений для решения в сети предприятия.

Таблица 4. Классификация намерений для корпоративных решений.

Пользователь

Тип намерения

Описание намерения

Конечный пользователь

Обслуживание клиентов

Самообслуживание или приложения конечного пользоватля корпоративной сети. В сети могут быть разные типы конечных пользователей.
Пример. Запрос доступа в VPN. Запрос видеосвязи между пользователями A и B.

Стратегические намерения

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

Администратор корпоративной сети (внутренний или MSP)

Намерения для сетевой службы

Сервис, предоставляемый администраторам конечным пользователям и их приложениям.
Пример. Для всех конечного пользователя приложения X нужно синхронизировать прибытие голографических объектов в интервале 50 мсек. Соединение с VPN управления для типа сервиса A.
Описание операций. Работа сетевого уровня состоит в обеспечении задержки в алгоритме маршрутизации от 50 до 70 мсек. В то же время нужны сетевые ресурсы для обеспечения пропускной способности видеоконференций 4K.

Намерения для сети

Администратор запрашивает настройку в масштабе сети (например, базовой или кампусной) или настроку ресурсов (коммутаторы, маршрутизаторы, правила).
Пример. Настроить на коммутаторах кампусной сети 1 приоритизацию трафика типа A. Настроить YouTube как не имеющий отношения к бизнесу сервис.

Задачи эксплуатации

Администратор запрашивает выполнение автомтизированной задачи, отличной от намерений для сетевой службы или сети.
Пример. Запрос автоматизированных задач защиты, таких как фильтрация web и защита облака от DDoS.

Стратегические намерения

Администратор создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Автоматизация часто выполняемых администратором задач.
Пример. При возникновении угрозы автоматически переместить весь трафика типа A в сеть N.

Разработчик приложений

Намерения конечного пользователя

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

Намерения для сетевой службы

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

Намерения для сети

Сетевой API для разработчиков приложений.
Пример. API для запроса настройки конфигурации сетевого устройства.

Задачи эксплуатации

API намерений для задач эксплуатации, предоставляемый доверенным разработчикам приложение (внутренние DevOps).
Пример. API для запроса автоматического мониторинга и перехвата для защиты сети.

Стратегические намерения

Разработчик приложений создаёт модели, правила намерений и рабочие процессы для применения другими намерениями. Это предназначено для доверенных внутренних DevOps.
Пример. API для стратегических намерений в случае опасности (угрозы).

6.5.2. Категории намерений

Ниже указаны предложенные категории.

Область намерения

C1=связность, C2=безопасность/приватность, C3=приложение, C4=QoS

Область сети (Net)

C1=кампус, C2=филиал, C3=SD-WAN

Абстракция (ABS)

C1=техническая (с техническим откликом), C2=нетехническая (без технического отклика) (see Section 5.2)

Жизненный цикл (L-C)

C1=постоянное (полный жизненный цикл), C2=временное (краткосрочное)

На рисунке 5 приведено табличное представление классификации для решения в сети предприятия.

Пользователь

Тип намерений

Область намерений

Net

ABS

L-C

C1

C2

C3

C4

C1

C2

C3

C1

C2

C1

C2

Конечный пользователь

Обслуживание клиентов

Стратегические намерения

Администратор корпоративной сети

Намерения для сетевой службы

Намерения для сети

Задачи эксплуатации

Стратегические намерения

Разработчик приложений

Намерения конечного пользователя

Намерения для сетевой службы

Намерения для сети

Задачи эксплуатации

Стратегические намерения

Рисунок 5. Категории намерений для корпоративных решений.

7. Заключение

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

Достоинства этого документа о классификации в сообществе исследователей были показаны в реализации PoC [POC-IBN], где концепции документа были применены на разных уровнях, соответствующих различным заинтересованным сторонам.

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

Этот документ указывает безопасность и приватность как категории области действия намерений. Намерения могут быть связаны исключительно с безопасностью или приватностью, а также могут включать безопасность и/или приватность наряду с областями связности, приложений и QoS.

Область безопасности и приватности задаёт характеристики безопасности сети, клиентов или конечных пользователей и приватности клиентов и конечных пользователей.

Более подробные сведения о намерениях защиты (безопасности) будут приведены в будущих документах, задающих архитектуру, функциональность, пользовательские намерения и модели. Анализ вопросов безопасности основанных на намерениях систем в целом приведён в разделе 9 [RFC9315].

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

Документ не требует действий IANA.

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

[Banerjee21] Banerjee, A., Mwanje, S., and G. Carle, «Contradiction Management in Intent-driven Cognitive Autonomous RAN», September 2021.

[Bezahaf19] Bezahaf, M., Hernandez, M., Bardwell, L., Davies, E., Broadbent, M., King, D., and D. Hutchison, «Self-Generated Intent-Based System», 10th International Conference on Networks of the Future (NoF), DOI 10.1109/NoF47743.2019.9015045, October 2019, <https://doi.org/10.1109/NoF47743.2019.9015045>.

[Bezahaf21] Bezahaf, M., Davies, E., Rotsos, C., and N. Race, «To All Intents and Purposes: Towards Flexible Intent Expression», IEEE 7th International Conference on Network Softwarization (NetSoft), DOI 10.1109/NetSoft51509.2021.9492554, July 2021, <https://doi.org/10.1109/NetSoft51509.2021.9492554>.

[Davoli21] Davoli, G., «Programmability and Management of Software-Defined Network Infrastructures», 2021.

[IFIP-NSM] IFIP, «Network and Service Management Taxonomy», <https://www.simpleweb.org/ifip/taxonomy.html>.

[Jacobs18] Jacobs, A., Pfitscher, R., Ferreira, R., and L. Granville, «Refining Network Intents for Self-Driving Networks», Proceedings of the Afternoon Workshop on Self-Driving Networks (SelfDN), DOI 10.1145/3229584.3229590, August 2018, <https://doi.org/10.1145/3229584.3229590>.

[Leivadeas21] Leivadeas, A. and M. Falkner, «VNF Placement Problem: A Multi-Tenant Intent-Based Networking Approach», 24th Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), DOI 10.1109/ICIN51074.2021.9385553, March 2021, <https://doi.org/10.1109/ICIN51074.2021.9385553>.

[Mehmood21] Mehmood, K., Kralevska, K., and D. Palma, «Intent-driven Autonomous Network and Service Management in Future Networks: A Structured Literature Review», DOI 10.48550/arXiv.2108.04560, August 2021, <https://doi.org/10.48550/arXiv.2108.04560>.

[ONF] Open Networking Foundation, «Intent NBI — Definition and Principles», October 2016, <https://opennetworking.wpengine.com/wp-content/uploads/2014/10/TR-523_Intent_Definition_Principles.pdf>.

[ONOS] Koshibe, A., «Intent Framework», 2016, <https://wiki.onosproject.org/display/ONOS/Intent+Framework/>.

[Padovan20] Padovan, S., «Design and Implementation of a Blockchain Intent Management System», November 2020.

[POC-IBN] Martini, B., Cerroni, W., Gharbaoui, M., and D. Borsatti, «A Multi-Level Approach to IBN», IETF 108 Hackathon Report, July 2020, <https://www.ietf.org/proceedings/108/slides/slides-108-nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-ibn-02>.

[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, «Intent-Based Networking — Concepts and Definitions», RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/info/rfc9315>.

[Szilagyi21] Szilágyi, P., «I2BN: Intelligent Intent Based Networks», Journal of ICT Standardization, Volume 9, Issue 2, DOI 10.13052/jicts2245-800X.926, June 2021, <https://doi.org/10.13052/jicts2245-800X.926>.

[Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H., Ye, Q., Wang, C., Wu, X., Ji, Z., Sang, Y., Zhang, M., Yu, D., Tian, C., Zheng, H., and B. Zhao, «Safely and automatically updating in-network ACL configurations with intent language», SIGCOMM ’19: Proceedings of the ACM Special Interest Group on Data Communication, DOI 10.1145/3341302.3342088, August 2019, <https://doi.org/10.1145/3341302.3342088>.

[TMF-AUTO] Boasman-Patel, A., Sun, D., Wang, Y., Maitre, C., Domingos, J., Troullides, Y., Mas, I., Traver, G., and G. Lupo, «Autonomous Networks: Empowering Digital Transformation For The Telecoms Industry», May 2019.

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

Этот документ был подготовлен с учётом рецензий, предложений, комментариев и предложенного текста от указанных в алфавитном порядке людей: Mehdi Bezahaf, Brian E. Carpenter, Laurent Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, Jeff Tantsura.

Спасибо Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide Borsatti за их вклад в демонстрацию PoC «A multi-level approach to IBN» — первую попытку применить методику классификации намерений.

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

Ниже указаны люди, внесшие вклад в создание этого документа.

Написали значительную часть текста:

Xueyuan Sun
China Telecom
 
Will (Shucheng) Liu
Huawei

Написали текст ранних вариантов этого документа:

Ying Chen
China Unicom
 
John Strassner
Huawei
 
Weiping Xu
Huawei
 
Richard Meade
Huawei

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

Chen Li
China Telecom
Xicheng District
No.118 Xizhimennei street
Beijing
100035
China
Email: lichen6@chinatelecom.cn
 
Olga Havel
Huawei Technologies
Ireland
Email: olga.havel@huawei.com
 
Adriana Olariu
Huawei Technologies
Ireland
Email: adriana.olariu@huawei.com
 
Pedro Martinez-Julia
NICT
Japan
Email: pedro@nict.go.jp
 
Jeferson Campos Nobre
Federal University of Rio Grande do Sul (UFRGS)
Porto Alegre-RS
Brazil
Email: jcnobre@inf.ufrgs.br
 
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
28006 Madrid
Spain
Email: diego.r.lopez@telefonica.com

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

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

nmalykh@protokols.ru

1Internet Research Task Force — комиссия по исследовательским задачам Internet.

2Intent-Based Network — сеть на основе намерений. В оригинале ошибочно сказано Internet-Based Network, см. https://www.rfc-editor.org/errata/eid7178. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 9315 Intent-Based Networking — Concepts and Definitions

Internet Research Task Force (IRTF)                             A. Clemm
Request for Comments: 9315                                     Futurewei
Category: Informational                                     L. Ciavaglia
ISSN: 2070-1721                                                    Nokia
                                                         L. Z. Granville
                         Federal University of Rio Grande do Sul (UFRGS)
                                                             J. Tantsura
                                                               Microsoft
                                                            October 2022

Intent-Based Networking — Concepts and Definitions

Сеть на основе намерений — концепции и определения

PDF

Аннотация

Сети на основе намерений (Intent или Intent-Based) берут отрасль штурмом. Однако термины, связанные с такими сетями, часто применяются расплывчато и непоследовательно, во многих случаях перекрываясь и смешиваясь с другими концепциями (например, политика — policy). В этом документе разъяснён термин «намерение» (intent) и дан обзор связанной с ним функциональности. Цель состоит в содействии общему пониманию терминов, концепций и функциональности, которые могли бы послужить основой для дальнейших определений исследовательских и инженерных задач, а также их решения.

Документ является результатом работы группы IRTF Network Management Research Group (NMRG) и отражает согласованное мнение группы, получив множество подробных положительных отзывов от участников группы. Документ публикуется с информационными целями.

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы IRTF1. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы Coding for Efficient Network Communications в рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

Оглавление

Исключено в версии HTML.

1. Введение

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

В прошлом интерес к управлению и операциям в рамках IETF был сосредоточен на характеристиках отдельных сетей и устройств. В стандартизации акцент обычно был смещён на инструменты управления, которые должны предоставляться сетевым устройствам. Ярким примером служит управление на основе SNMP [RFC3411] и более 200 MIB, заданных IETF за эти годы. Более свежие примеры включают определения моделей данных YANG [RFC7950] для таких аспектов, как настройка интерфейсов, списков управления доступом (Access Control List или ACL) и Syslog.

Есть чёткое понимание и реальность того, что управление сетями путём настройки мириадов «кнопок» (nerd knob) для каждого устройства больше не подходит для современных сетевых сред. Возникают серьёзные проблемы при сохранении согласованности конфигураций устройств не только в сети, но и с потребностями служб и функций, которые они должны обеспечивать. Возникают дополнительные проблемы, связанные с возможностью быстрого приспособления сети к потребностям с учётом расширения. В то же время операции должны быть по возможности оптимизированы и автоматизированы не только для снижения операционных расходов, но и для перенастройки сети за доли секунды, а также для гарантированного предоставления ожидаемых функций. Среди прочего, для этого требуется способность воспринимать эксплуатационные данные, выполнять анализ и динамически выполнять действия с учётом контекста и предполагаемых результатов в масштабе времени, близком к реальному.

В соответствии с этим в IETF начали заниматься аспектами сквозного управления, выходящими за рамки отдельных изолированных устройств. Примеры включают задание моделей YANG для топологии сети [RFC8345] или введение моделей служб, применяемых системами оркестровки и контроллерами [RFC8309]. Большой интерес вызвало обсуждение вопросов самоуправления сетей в рабочей группе ANIMA. Такие сети движимы желанием снизить операционные расходы и упростить управление сетью в целом, что вступает в противоречие с необходимостью управлять одним устройством и одной функцией за раз. Хотя самоуправляемые сети предназначены для демонстрации свойств «самоуправления» (self-management), они по-прежнему требуют действий оператора или внешней системы для обеспечения операционных рекомендаций и сведений о целях, задачах и экземплярах служб, которые сеть должна обслуживать.

Эти входные данные и операционные рекомендации обычно называют намерениями (intent), а сеть, позволяющую операторам предоставить свои данные в форме намерений, — сетью на основе намерений (Intent-Based Network или IBN). Сеть, помогающую реализовать намерения, называют основанной на намерениях системой (Intent-Based System или IBS). Такие системы могут по разному проявлять себя, например, как контроллер, система управления, реализованная в виде приложения, которое работает на сервере или группе серверов, или набор распределенных в сети функций, совместно реализующих основанную на намерениях функциональность.

Однако намерения (цель) состоят не только в обеспечении формы взаимодействия оператора с сетью, включающей абстракции более высокого уровня. Речь идёт также о возможности позволить операторам сосредоточиться на том, как они хотят видеть желаемый результат, оставляя детали его достижения IBN (и IBS). Сосредоточение внимания на результате позволяет операторам повысить эффективность и гибкость в более широком масштабе, в более короткие сроки и с меньшей зависимостью от человеческих действий (и связанных с ними ошибок). Это делает сети IBN идеальным кандидатом для методов искусственного интеллекта, которые могут обеспечить следующий уровень автоматизации сетей [CLEMM20].

Такое представление стало популярным в отрасли и привело к разработке множества решений, предлагающий управление на основе намерений (Intent-Based Management), обещающее сервис-провайдерам целостное управление сетями с высоким уровнем абстракций как системой, состоящей из соединённых компонентов, а не набора независимых устройств (соединённых между собой). Такие предложения включают IBN и IBS (с полным жизненным циклом намерений), контроллеры программно управляемых сетей (Software-Defined Network или SDN), обеспечивающие единую точку управления и администрирования для сети, а также системы управления сетью и системы поддержки операций (Operations Support System или OSS).

Давно признано, что комплексные решения для управления не могут работать лишь на уровне отдельных устройств и конфигураций нижнего уровня. В этом смысле представление намерений не является совсем новым. В прошлом модель ITU-T для управления телекоммуникационной сетью (Telecommunications Management Network или TMN) представляла набор уровней управления, определяющий иерархию управления для сетевых элементов, сети, сетевых служб и бизнеса [M3010]. Операционные цели высокого уровня распространяются в модели сверху вниз. Связанная иерархия абстракций имеет решающее значение для разложения комплексного управления на отдельные области задач. Эта иерархия абстракций сопровождается информационной иерархией, которая на нижнем уровне касалась сведений, относящихся к конкретным устройствам, а на верхних уровнях включала, например, экземпляры сквозного сервиса. Аналогично концепция управления на основе правил (Policy-Based Network Management или PBNM) долгое время расхваливала возможность позволить пользователям2 управлять сетями путём задания высокоуровневых правил управления, при этом системы управления автоматически «толковали» (rendering) эти правила, т. е. переводили их в конфигурации нижнего уровня и логику управления.

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

Следует отметить, что формулировка связанных с IBN исследовательских проблем выходит за рамки документа. Однако следует признать, что сети IBN стали важной темой в сообществе исследователей. Согласно IEEE Xplore [IEEEXPLORE] по состоянию на декабрь 2021 г за 10 лет с 2012 г. было опубликовано 1138 с термином intent, из которых 411 конкретно посвящены сетям. Только за период с 2020 г. было опубликовано 316 статей о «намерениях» и 153 — о сетях на основе намерений. Кроме того, проводятся семинары, посвящённые этой теме, такие как IEEE International Workshop on Intent-Based Networking [WIN21], а также специальные выпуски журналов [IEEE-TITS21]. Обзор текущих исследований представлен в [PANG20], где среди наиболее важных исследовательских задач указаны такие вопросы, как трансляция и понимание намерений, интерфейсы и безопасность.

2. Определения и сокращения

ACL

Access Control List — список управления доступом.

API

Application Programming Interface — интерфейс с прикладными программами.

IBA

Intent-Based Analytics — основанная на намерениях аналитика. Аналитика, определённая и выведенная из намерений пользователей и служащая для проверки предусмотренного состояния.

IBN

Intent-Based Network — сеть на базе намерений. Сеть, управляемая с использованием намерений.

IBS

Intent-Based System — система на базе намерений. Система, поддерживающая функции управления с помощью намерений.

Intent — намерения

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

Intent-Based Management — управление на базе намерений

Концепция управления на основе концепции намерений.

PBNM

Policy-Based Network Management — управление сетью на основе правил.

PDP

Policy Decision Point — точка принятия решений по правилам.

PEP

Policy Enforcement Point — точка применения правил (политики).

Policy — правила (политика)

Набор правил, определяющих выбор поведения системы.

Service Model — модель сервиса

Модель, представляющая услугу, которую сеть предоставляет пользователям.

SsoT

Single Source of Truth — единая точка доверия. Функциональный блок системы IBN, нормализующий намерения пользователей и служащий единым источником данных для нижележащих уровней.

Statement of Intent — заявление о намерениях

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

SvoT

Single Version of Truth — единая версия доверия.

User — пользователь

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

3. Концепции

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

3.1. Намерения и управление на их основе

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

Термин intent был впервые введён в контексте самоуправляемых сетей (Autonomic Network), где он был определён как «абстрактная политика высокого уровня, применяемая для работы сети» [RFC7575]. В соответствии с этим определением намерения являются конкретным типом политики, предоставляемым пользователем для обеспечения руководства самоуправляемой сетью, которая в остальном работает без привлечения людей. Однако, чтобы термин «намерения» не рассматривался как синоним политики, нужно чётко указать отличие намерений от иных правил.

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

Управление на основе намерений (IBM) направлено на создание сетей, которые проще поддерживать и эксплуатировать и которые требуют минимального вмешательства извне. Сети (даже самоуправляемые) не являются ясновидящими и не могут автоматически узнавать, какие операционные цели и экземпляры сетевых служб нужно поддерживать. Иными словами, они не знают намерений провайдера, придающих смысл существованию сети. Все ещё требуется указывать сетям, что собой представляют такие намерения. При этом концепция намерений не ограничивается сетями с самоуправлением, такими как сети с автономной (самоуправляемой) плоскостью управления (Autonomic Control Plane) [RFC8994], а применимы к любым сетям.

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

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

  • Функциональная абстракция от конкретной логики поддержки и управления. Пользователям не нужно заботиться даже о способах достижения целей. Указанное является желаемым результатом, при этом IBS автоматически определяет действия (например, с использованием алгоритма или применением набора правил, выведенного из намерений) для достижения результата.

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

  • Направлять трафик от конечных точек одной географической области в сторону от трафика из другой области, если только получатель не находится в этой второй области (указано, что достичь, но не сказано как).

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

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

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

  • Генерировать на месте данные эксплуатации, администрирования и поддержки (Operations, Administration, and Maintenance или OAM) и сетевой телеметрии для последующего автономного анализа при каждом наблюдении значительных флуктуаций задержки на пути (выход за рамки события-условия-действия без задания степени значимости и собираемых данных).

  • Направлять трафик в космической сети (Space Information Network) так, чтобы минимизировать зависимость от стратостатов, если предполагаемым получателем не является самолёт (не задан способ достижения, экстраполяция сценариев из [PANG20]).

  • Для услуги «умный город» обеспечить использование сигналами светофором выделенных и резервируемых «срезов» (slice), чтобы избежать «общей судьбы» (желаемый результат с набором ограничений и дополнительной рекомендацией без указания способа достижения, экстраполяция сценария из [GHARBAOUI21]).

Ниже приведены примеры, не являющиеся выражением намерений (на естественном языке для простоты).

  • Настроить на данном интерфейсе адрес IP (это настройка устройства и манипулирование «кнопками»).

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

  • Настроить VPN с туннелем между A и B по пути P (это настройка сервиса).

  • Запретить трафик к префиксу P1, если он не исходит от префикса P2 (правило доступа или межсетевого экрана, а не намерение).

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

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

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

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

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

Имеются другие определения намерений, такие как [TR523]. Намерения определяются там просто как декларативный интерфейс, обычно предоставляемый контроллером. Это предполагает наличие централизованной функции, преобразующей намерения в правила или инструкции нижнего уровня и организует их в сети. Хотя это и является одним из вариантов реализации, представленное здесь определение имеет более широкий охват и устремления, поскольку оно подчёркивает важность управления сетью путём задания желаемых результатов без указания конкретных шагов по их достижению. API-интерфейс контроллера, который просто обеспечивает абстракцию на уровне сети, более ограничен и не обязательно задаёт намерения. Восприятие и распознавание намерений не обязательно выполняется чрез API, основанный на вызове функций и простых взаимодействиях запрос-отклик, а может включать иные типы взаимодействия человека с машиной, такие как диалог для разъяснения и уточнения запросов.

3.2. Связанные концепции

3.2.1. Модели сервиса

Модель сервиса — это модель, представляющая услугу, обеспечиваемую пользователю сетью. В соответствии с [RFC8309] модель сервиса описывает услугу и её параметры независимым от реализации переносимым способом, который можно применять независимо от оборудования и операционной среды, где реализована услуга. Различают две категории — модель обслуживания клиентов (Customer Service Model) описывает экземпляр предоставляемой клиенту услуги, возможно требующей заказа, а модель предоставления услуги (Service Delivery Model) описывает реализацию услуги в имеющейся сетевой инфраструктуре.

Примерами могут служить услуги L3 VPN [RFC8299], Network Slice [NETWORK-SLICE] или локальный доступ в Internet. Модели сервиса представляют экземпляры служб как самостоятельные сущности. Службы имеют свои параметры, действия и жизненные циклы. Обычно экземпляр службы может быть привязан к конкретным пользователям коммуникационных услуг, которым могут быть выставлены счета за предоставляемые услуги.

Создание службы обычно включает несколько аспектов, указанных ниже.

  • Пользователь (или северная система) определяет и/или запрашивает создание экземпляра службы.

  • Выделяются ресурсы (адреса IP, номера AS, пулы VLAN или VxLAN, интерфейсы, полоса, память).

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

  • Привязки между объектами верхнего и нижнего уровня, которые нужно поддерживать.

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

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

Созданные экземпляры моделей услуг отображаются на низкоуровневые модели сетей и устройств, например, экземпляры путей или конкретных конфигураций портов. Модель сервиса обычно включает также уровня служб и зависимости от нижележащих сетевых ресурсов, требуемых для предоставления услуги. Это упрощает управление, позволяя следовать зависимостям в действиях по устранению неполадок и анализу влияния, когда события в сети оцениваются с точки зрения воздействия на службы и клиентов. Службы обычно организуются и предоставляются «сверху вниз», что также упрощает отслеживание назначения сетевых ресурсов (композиция), а поиск и устранение неполадок выполняется «снизу вверх» (декомпозиция). Модели сервиса могут быть связаны с другими данными, не относящимися к сети, но обеспечивающими бизнес-контекст. Это включает сведения о клиентах (например, информация для выставления счетов), заказы услуг, каталоги служб, тарифы, договоры на обслуживание и соглашения об уровне обслуживания (Service Level Agreement или SLA), включая договорные соглашения по корректирующим действиям.

[SERVICE-MAPPING-YANG] служит примером модели данных, обеспечивающей отображение моделей обслуживания клиентов (например, L3VPN Service Model) на модели организации трафика (Traffic Engineering или TE, например, TE Tunnel или the Abstraction and Control of Traffic Engineered Networks Virtual Network).

Как и намерения, модели служб обеспечивают высокий уровнеь абстракции. Модели сервиса часто дополняются отображениями, учитывающими зависимости между услугой и конфигурацией устройств или сетей. В отличие от намерений, модели сервиса не позволяют задать желаемый «результат», которые будет автоматически поддерживаться IBS. Для управления моделями сервиса от сервис-провайдеров или системных интеграторов требуется разработка изощрённых алгоритмов и управляющей логики.

3.2.2. Политика и управление сетью на её основе

Управление сетью на основе правил (PBNM) — это парадигма управления, разделяющие правила поведения системы и её функциональность. Это обещает снизить расходы на поддержку информационных и коммуникационных систем одновременно повышая гибкость и адаптивность при работе. Сегодня это лежит в основе множества архитектур и парадигм управления, включая основанные на SLA, требованиях бизнеса, самоуправляемые, адаптивные и самоподдерживающиеся [BOUTABA07]. Заинтересованным читателям рекомендуется обратиться к имеющейся литературе, включающей множество ссылок. Здесь представлен лишь краткий обзор.

В основе такого управления лежит концепция правил (политики). Имеется множество определений политики — правила, регулирующие выбор поведение системы [SLOMAN94], набор правил, применяемых для поддержки и управления сменой и поддержанием состояния одного или нескольких объектов [STRASSNER03]. Общим для большинства определений является то, что политика считается «правилом». Обычно определение правила включает событие (которое вызывает правило), набор условий (при выполнении которых происходят фактические действия) и одно или несколько выполняемых действий.

Управление на основе правил можно рассматривать как парадигму императивного управления — политика точно указывает, что, когда и при каких обстоятельствах нужно делать. По сути, управление с использованием политики можно определить как набор простых циклов управления. Это делает его подходящей технологией для реализации автономного поведения со свойствами самоуправления, включая самонастройку, самовосстановление, самооптимизацию и самозащиту. И это возможно, несмотря на то, что управление на основе правил может применять концепцию абстракций (таких как «Боб получает приоритетное обслуживание»), скрывающих от пользователей детали реализации абстракции в конкретном развёртывании.

Политика обычно предполагает некую степень абстракции, чтобы справиться с неоднородностью сетевых устройств. Вместо правил для конкретных устройств, задающих события, условия и действия в терминах зависящих от устройства команд, параметров и моделей данных, политика определяется на более высоком уровне абстракции, включающем каноническую модель систем и устройств, к которым она применяется. Агент политики в контроллере или устройстве последовательно «разбирает» правила, т. е. транслирует каноническую модель в соответствующее устройству представление. Эта концепция позволяет применять одну политику для широкого класса устройств без необходимость создания множества вариантов. Иными словами, определение политики отделено от её реализации и исполнения. Это позволяет расширять операционный масштаб и даёт сетевым операторам и авторам политики возможность использовать абстракции более высокого уровня, нежели специфика устройств, и применять определения высокого уровня в разных сетевых доменах, сетях WAN, центрах обработки данных (ЦОД или DC) облаках общего пользования.

В PBNM обычно применяется выталкивание (push) — правила выталкиваются в устройства, где они разбираются и применяются. Операции выталкивания выполняет менеджер или контроллер, отвечающий за развёртывание политики в сети и отслеживание корректности работы правил. Возможна иная архитектура политики, например, управление на основе правил может включать компонент втягивания (pull) в котором решение о предпринимаемых действиях передаётся точке принятия решений (Policy Decision Point или PDP). PDP может размещаться вне управляемого устройства и обычно имеет глобальную видимость и контекст для принятия решений. Всякий раз при наблюдении устройством события, связанного с политикой, при отсутствии полного определения правила или возможности выбрать действие, устройство обращается к PDP за решением (принимаемым, например, в соответствии с условиями). Затем устройство применяет решение, полученное от PDP, исполняя политику и действуя как точка применения правил (Policy Enforcement Point или PEP). В любом случае архитектура PBNM обычно включает центральный элемент, распространяющий правила по сети или принимающий решения.

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

3.2.3. Различия между намерениями, политикой и моделями служб

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

  • Модель обслуживания является моделью данных, применяемой для описания предоставляемых клиентам экземпляров служб. Модель обслуживания зависит от низкоуровневых моделей (модули устройств и сетей) для описания сопоставления службы с базовой сетью и инфраструктурой IT. Создание экземпляра модели обслуживания требует оркестровки со стороны системы — логика организации/управления/предоставления модели обслуживания и способ её отображения на базовые ресурсы не включается в саму модель.

  • Политика — это набор правил, обычно моделируемый на основе различных событий/условий/действий, служащих для выражения простых циклов управления, которые можно выполнить на устройствах без вмешательства внешних систем. Политика позволяет пользователям указать, что нужно делать в тех или иных обстоятельствах, но не задаёт желаемый результат.

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

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

4. Принципы

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

  1. Единый источник (Single Source of Truth или SSoT) и одна версия (Single Version of Truth или SVoT) доверия. SSoT является важной частью IBS, позволяя выполнять несколько важных операций. В качестве SsoT системы служит набор проверенных выражений намерений. SsoT и записи рабочих состояний позволяют сравнивать предполагаемое/желаемое состояние с фактическим/операционным состоянием системы и определять различия между ними. SSoT и различия служат основой для корректирующих действий. Если в IBS имеются средства прогнозирования состояний, можно дополнительно разрабатывать стратегии предсказания, планирования и упреждающих действий в отношении любых тенденций расхождения с целью минимизации их влияния. Помимо предоставления средств для согласования работы системы, SSoT позволяет улучшить отслеживание для проверки, были ли и насколько хорошо выполнены исходные намерения и связанные с ними бизнес-цели для оценки влияния изменений в параметрах намерений, а также влияния и последствий происходящих в системе событий.

    Единая версия (или представление — View) доверия выводится из SSoT и может служить для выполнения таких операций, как запросы, опросы или фильтрация измеренных или полученных сопоставлением данных для создания так называемых «представлений» (view). Эти представления могут помогать пользователям IBS. Для создания заявления о намерениях как единого источника доверия система IBS должна следовать чётко заданным и хорошо документированным процессам и моделям. SSoT также называют неизменностью намерений [LENROW15].

  2. Одно касание, но не один шаг. В идеальной системе IBS пользователь в той или иной форме выражает намерения, а система выполняет все последующие операции (одно касание). Можно представить и подход «без касания» (zero-touch), если IBS имеет возможности или средства распознавания намерений в любой форме данных. Однако это не должно отвлекать от того, что достижение корректно сформированного и правильного выражения намерений не является одношаговым (one-shot) процессом. Напротив, взаимодействие между пользователем и IBS следует организовывать как итерационный процесс. В зависимости от уровня абстракции выражение намерений исходно может содержать в той или иной степени неявные части, а также неточные или неизвестные параметры и ограничения. Роль IBS заключается в разборе, понимании и уточнении намерений для достижения чётко сформированного и действительного выражения намерений, которое система может использовать для операций исполнения и подтверждения. Процесс уточнения намерений может включать комбинацию итерационных шагов, вовлекающих пользователя в проверку предложенных уточнений и уточнение некоторых параметров и переменных, которые система не может вывести или узнать самостоятельно. Кроме того, IBS потребуется разрешение конфликтов в намерениях, чтобы помочь пользователю сделать верный выбор среди вариантов, которые могут иметь разные последствия.

  3. Автономность и присмотр. Желаемой целью IBS является обеспечения высокого уровня гибкости и свободы для пользователя и сети, например, путём предоставления пользователю возможности выразить намерения своими словами с поддержкой разных форм выражения отдельных намерений и их уточнения для создания корректно сформированных и пригодных для использования выражений. Двойной принцип автономности и присмотра обеспечивает режим работы с требуемым уровнем автономности для выполнения задач и операций без вмешательства пользователя и самостоятельным принятием решений (в рамках сферы ответственности и контроля) в части выполнения задач в соответствии с ожиданиями пользователя с точки зрения производительности и качества. В то же время обеспечивается должный присмотр в соответствии с потребностями пользователя в части отчётности и представления соответствующих результатов.

  4. Обучение. IBS — обучающаяся система. В отличие от императивных систем, таких как правила «событие-условие-действие» (Event-Condition-Action), где пользователь заранее задаёт ожидаемое поведение, в IBS пользователь лишь объявляет предполагаемое поведение системы, не указывая способов его достижения. Таким способом происходит передача рассуждений/рационализма от человека (знание предметной области) к системе. Эта передача когнитивных возможностей подразумевает наличие в IBS способов или средств обучения, рассуждения, а также представления знаний и управления ими. Способности IBS к обучению могут применяться для разных задач, таких как оптимизация разбора и уточнения намерений. Способность IBS к постоянному развитию создаёт условия для постоянного обучения и оптимизации. Другие когнитивные возможности, такие как планирование, также могут применяться в IBS для прогнозирования или предсказания будущих состояний системы и откликов на изменения намерений или условий в сети и соответствующей выработки планов по адаптации к этим изменениям при сохранении стабильности и эффективности системы, а также компромисса между стоимостью и надёжностью операций.

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

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

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

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

  • Абстракция и связанная с ней виртуализация, не зависящие от деталей реализации.

  • Настроенное на человека сетевое взаимодействие. IBN следует «говорить» на языке пользователя, не требуя от него «языка» устройств или сетей.

  • Возможность объяснения как важная функция IBN, обнаружение и разрешение с помощью IBN конфликтов намерений, а также согласование желаний пользователя с фактическими возможностями сети.

  • Встроенная поддержка, верификация и гарантии доверия.

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

5. Функциональность IBN

Сети на основе намерений (IBN) включают широкий спектр функций, которые можно условно разделить на 2 категории.

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

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

В последующих параграфах приведён более детальный обзор этих функций.

5.1. Реализация намерений

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

5.1.1. Восприятие намерений и взаимодействие с пользователями

Первый набор функций связан с восприятием намерений, т. е. их получением через взаимодействие с пользователями. Он представляет функции распознавания намерений из взаимодействия с пользователем, а также функции, позволяющие пользователю уточнить свои намерения и сформулировать их подходящим для IBS способом. Обычно эти функции выходят за рамки API, не основанных на намерениях, хотя некоторые из таких API также могут предоставляться (и требуются для взаимодействия с пользователем без участия человека, т. е. с другой машиной). Во многих случаях включается также набор интуитивно понятных и простых в обращении рабочих процессов, ведущих пользователя на этапе восприятия намерений, гарантируя сбор всех требуемых для моделирования и последовательной трансляции намерений. Они могут поддерживать нетрадиционное взаимодействие человека с машиной, где человек не просто даёт команды, а использует диалог «человек-машина» для разъяснения, указания ветвлений и компромиссов, а также для упрощения корректировок.

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

5.1.2. Трансляция намерений

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

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

5.1.3. Оркестровка намерений

Третий набор функций связан с фактической настройкой и предоставлением, где требуется оркестровка через сеть, определённая на этапе трансляции намерений.

5.2. Обеспечение намерений

Обеспечение намерений (Intent Assurance) связано с функциями, требуемые для гарантии соответствия сети, воспринятым намерениям.

5.2.1. Мониторинг

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

5.2.2. Оценка соответствия намерений

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

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

5.2.3. Действия по обеспечению соответствия

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

5.2.4. Абстракции, агрегирование, отчёты

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

6. Жизненный цикл

Намерения имеют жизненный цикл — они возникают, могут меняться со временем и отзываться в какой-то момент. Этот жизненный цикл тесно связан с функциями взаимодействия в концепции намерений. На рисунке 1 показан жизненный цикл намерений и его основные функции. Указанные в разделе 5 функции разделены (по вертикали) на 2 функциональные плоскости, отражающие различия между исполнением и обеспечением. Каждая плоскость разделена по горизонтали на 3 части, показывающие разные точки зрения и взаимодействие с разными ролями.

  • Пользовательское пространство включает функции, связывающие сеть и IBS с пользователем-человеком. Это функции, позволяющие человеку сформулировать, а IBS — реализовать намерения. Здесь имеются также функции информирования о состоянии сети в части намерений, позволяющие пользователю оценить результат и его соответствие намерениям.

  • Пространство трансляции (IBS) включает функции, служащие мостом между пользователем и сетевой инфраструктурой. Это функции трансляции намерений в действия, алгоритмы, применяемые для планирования и оптимизации этих действий, а также обратной связи и наблюдения за сетью. Здесь работают функции анализа и агрегирования наблюдений за сетью для проверки соответствия намерениям и выполнения корректирующих действий при необходимости. Имеются также функции абстрагирования наблюдений, связывающие их с намерениями для информирования пользователей. Это упрощает функции отчётности в пользовательском пространстве.

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

      Пользовательское   :       Пространство            :  Пространство
      пространство       :      трансляции (IBS)         :  сетевых
                         :                               :  операций
           +----------+  :  +----------+   +-----------+ : +-----------+
Восприятие |распознав.|---> |трансляция|-->|  обучение |-->| настройка/|
           |и генерац.|     |    и     |   |планирован.|   |предоставл.|
           |намерений |<--- |уточнение |   |воспроизвед| : |           |
           +----^-----+  :  +----------+   +-----^-----+ : +-----------+
                |        :                       |       :        |
   .............|................................|................|.....
                |        :                  +----+---+   :        v
                |        :                  |проверка|   :  +----------+
                |        :                  +----^---+ <----| отслежив.|
Обеспечение +---+---+    :  +---------+    +-----+---+   :  |наблюдение|
            | отчет | <---- |абстракц.|<---| анализ  | <----|          |
            +-------+    :  +---------+    |агрегиров|   :  +----------+
                         :                 +---------+   :

Рисунок 1. Жизненный цикл намерений.


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

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

  • «Внешний» контур управления намерениями распространяется на пространство пользователя. Он включает действия пользователя и корректировку намерений на основе наблюдений и обратной связи от IBS.

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

7. Дополнительные соображения

С учётом популярности термина «намерения» (intent) возникает соблазн расширить его использование, включив связанные понятия, что ведёт к «размытию намерений» (intent-washing), представляющему эти концепции в новом свете путём простого применения к ним новой терминологии намерений. Типичным примером служит использование для северного интерфейса контроллера SDN термина «интерфейс намерений» (intent interface). Однако в некоторых случаях такой подход имеет смысл не только как маркетинговый ход, но и как способ лучше связать новые концепции с прежними. В этом смысле уместно различать несколько категорий намерений.

Operational Intent — эксплуатационные намерения

Намерения, связанные с эксплуатационными целями оператора. Это соответствует исходному термину intent и концепциям данного документа.

Rule Intent — намерения для политики

Синоним для правил политики, управляющих действиями при возникновении определённых событий.

Service Intent — намерения для сервиса

Синоним модели обслуживания клиентов [RFC8309].

Flow Intent — намерения для потока

Синоним цели уровня обслуживания (Service Level Objective) для данного потока.

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

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

Этот документ не требует действий IANA.

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

В этом документе описаны концепции и даны определения для основанных на намерениях сетей (Intent-Based Networking). Поэтому приведённые ниже соображения безопасности сохраняют высокий уровень, т. е указаны в виде принципов, рекомендаций или требований. Более подробное рассмотрение будет приведено в документах, задающих архитектуру и функциональность.

Безопасность в IBN имеет несколько аспектов:

  • защита самой системы IBS;

  • смягчение последствий ошибочных, вредных или скомпрометрированных заявления о намерениях;

  • выражение правил или параметров безопасности в заявлениях о намерениях.

Защита IBS нацелена на обеспечения операционной безопасности IBS за счёт внедрения механизмов защиты и применения накопленного опыта. В контексте IBN такие механизмы и методы могут включать проверку намерений, предоставление возможности работать с намерениями лишь проверенным и уполномоченным пользователям, обнаружение фальсифицированных намерений и защиту от них. Такие механизмы могут включать внедрение нескольких уровней намерений. Например, намерения, связанные с защитой сети, следует помещать на «более глубокий» уровень, который при необходимости переопределяет намерения других уровней, а сам не может быть изменён обычными операциями и требует применения защищённых операций. Следует также рассмотреть применение дополнительных механизмов, таких как компоненты разъяснений, описывающие ветвления защиты и компромиссы, которые следует учитывать.

Смягчение последствий ошибочных или скомпрометированных намерений нацелено на обеспечение эксплуатационной безопасности IBS за счёт механизмов проверки и защиты, а также принципов работы. В контексте IBN такие механизмы и принципы могут включать способность автоматически обнаруживать непреднамеренно, враждебное или аномальное поведение, автоматически (и аккуратно) возвращаться к прежнему «безопасному» состоянию, предотвращать или сдерживать усиление ошибок (за счёт комбинации высокого уровня автоматизации и внутренней свободы, неоднозначности или неявной информации, передаваемой в намерениях), наличие динамических уровней присмотра и информирования, предоставляющих пользователям корректные сведения в нужный момент и с подобающим контекстом. Ошибочные и вредоносные намерения могут распространяться по сети и нарушать защиту. Кроме того, скомпрометированные намерения (например, подделанные внутренним злоумышленником) могут саботировать или нарушать работу сетевых ресурсов и делать их уязвимыми для других, более серьёзных атак, например, путём обхода некоторых механизмов защиты.

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

  • управление данными;

  • уровни конфиденциальности при обмене данными;

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

  • уровни шифрования;

  • уполномоченные для выполнения операций.

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

По мере роста уровня понимания технологий IBN потребуется более тщательно анализировать вопросы безопасности.

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

[BOUTABA07] Boutaba, R. and I. Aib, «Policy-Based Management: A Historical Perspective», Journal of Network and Systems Management (JNSM), Vol. 15, Issue 4, DOI 10.1007/s10922-007-9083-8, November 2007, <https://doi.org/10.1007/s10922-007-9083-8>.

[CLEMM20] Clemm, A., Faten Zhani, M., and R. Boutaba, «Network Management 2030: Operations and Control of Network 2030 Services», Journal of Network and Systems Management (JNSM), Vol. 28, Issue 4, DOI 10.1007/s10922-020-09517-0, October 2020, <https://doi.org/10.1007/s10922-020-09517-0>.

[GHARBAOUI21] Gharbaoui, M., Martini, B., and P. Castoldi, «Implementation of an Intent Layer for SDN-enabled and QoS-Aware Network Slicing», 2021 IEEE 7th International Conference on Network Softwarization (NetSoft), pp. 17-23, DOI 10.1109/NetSoft51509.2021.9492643, June 2021, <https://doi.org/10.1109/NetSoft51509.2021.9492643>.

[IEEE-TITS21] Garg, S., Guizani, M., Liang, Y-C., Granelli, F., Prasad, N., and R. R. V. Prasad, «Guest Editorial Special Issue on Intent-Based Networking for 5G-Envisioned Internet of Connected Vehicles», IEEE Transactions on Intelligent Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017, DOI 10.1109/TITS.2021.3101259, August 2021, <https://doi.org/10.1109/TITS.2021.3101259>.

[IEEEXPLORE] IEEE, «IEEE Xplore», <https://ieeexplore.ieee.org/>.

[LENROW15] Lenrow, D., «Intent As The Common Interface to Network Resources», Intent Based Network Summit 2015 ONF Boulder: IntentNBI, February 2015.

[M3010] ITU-T, «Principles for a telecommunications management network», ITU-T Recommendation M.3010, February 2000.

[NETWORK-SLICE] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, «Framework for IETF Network Slices», Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3 August 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-14>.

[PANG20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, «A Survey on Intent-Driven Networks», IEEE Access, Vol. 8, pp.22862-22873, DOI 10.1109/ACCESS.2020.2969208, January 2020, <https://doi.org/10.1109/ACCESS.2020.2969208>.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, «An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks», STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.

[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, «Autonomic Networking: Definitions and Design Goals», RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.

[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>.

[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, «YANG Data Model for L3VPN Service Delivery», RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.

[RFC8309] Wu, Q., Liu, W., and A. Farrel, «Service Models Explained», RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.

[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>.

[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, «An Autonomic Control Plane (ACP)», RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.

[SERVICE-MAPPING-YANG] Lee, Y., Ed., Dhody, Dhruv., Ed., Fioccola, G., Wu, Q., Ed., Ceccarelli, D., and J. Tantsura, «Traffic Engineering (TE) and Service Mapping YANG Data Model», Work in Progress, Internet-Draft, draft-ietf-teas-te-service-mapping-yang-11, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-11>.

[SLOMAN94] Sloman, M., «Policy Driven Management for Distributed Systems», Journal of Network and Systems Management (JNSM), Vol. 2, Issue 4, pp. 333-360, December 1994.

[STRASSNER03] Strassner, J., «Policy-Based Network Management», August 2003.

[TR523] Open Networking Foundation, «Intent NBI — Definition and Principles», ONF TR-523, October 2016.

[WIN21] Ciavaglia, L. and E. Renault, «1st International Workshop on Intent-Based Networking», IEEE International Conference on Network Softwarization, June 2021, <https://netsoft2021.ieee-netsoft.org/program/workshops/win-2021/>.

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

Спасибо членам исследовательской группы IRTF Network Management (NMRG) за полезные дискуссии и отклики. В частности, авторы хотели бы поблагодарить Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu Song, Peter Szilagyi, Csaba Vulkan за отклики и поддержку. Отдельная благодарность Remi Badonnel, Walter Cerroni, Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, Peter Szilagyi, Csaba Vulkan, сделавшим ещё один шаг и предоставившим рецензии.

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

Alexander Clemm
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: ludwig@clemm.org
 
Laurent Ciavaglia
Nokia
Route de Villejust
91620 Nozay
France
Email: laurent.ciavaglia@nokia.com
 
Lisandro Zambenedetti Granville
Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Gonçalves
Porto Alegre-RS
9500
Brazil
Email: granville@inf.ufrgs.br
 
Jeff Tantsura
Microsoft
Email: jefftant.ietf@gmail.com

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

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

nmalykh@protokols.ru

1Internet Research Task Force — комиссия по исследовательским задачам Internet.

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

Рубрика: RFC | Оставить комментарий

RFC 9299 An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

Internet Engineering Task Force (IETF)                       A. Cabellos
Request for Comments: 9299          Universitat Politecnica de Catalunya
Category: Informational                                   D. Saucez, Ed.
ISSN: 2070-1721                                                    Inria
                                                            October 2022

An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

Архитектурное введение в протокол LISP

PDF

Аннотация

Этот документ описывает архитектуру протокола разделения идентификаторов и локаторов (Locator/ID Separation Protocol или LISP), упрощая понимание спецификаций LISP и обеспечивая базу для обсуждения деталей протоколов LISP. Документ служит введением, а подробные сведения приведены в спецификациях RFC 9300 и RFC 9301.

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

Документ не содержит стандарта Internet и публикуется с информациоными целями.

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

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

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

Copyright (c) 2022. Авторские права принадлежат 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).

Оглавление

Исключено в версии HTML

1. Введение

Этот документ описывает архитектуру протокола разделения идентификаторов и локаторов (LISP) [RFC9300] [RFC9301], основные механизмы работы и принципы устройства. По сути, LISP основан на хорошо известной архитектурной идее освобождения от перегрузки семантики адресов IP. Как отметил Noel Chiappa [RFC4984], в настоящее время адреса IP указывают сразу топологическое местоположение точки подключения к сети и идентификацию узлов. Однако требования узлов и маршрутизации принципиально различаются. Системам маршрутизации нужна агрегируемость адресов и их топологическая значимость, а узлам требуется идентификация, независимая от конкретного местоположения [RFC4984].

LISP создаёт два раздельных пространства имён для идентификаторов конечных точек (Endpoint Identifier или EID) и локаторов маршрутизации (Routing Locator или RLOC). Оба пространства синтаксически идентичны современным адресам IPv4 и IPv6. Однако EID служат для однозначной идентификации узлов независимо от их топологического местоположения и обычно маршрутизируются внутри домена. Локаторы RLOC назначаются топологически и обычно маршрутизируются между доменами. С помощью LISP можно логически разделить границу Internet (места подключения узлов) и ядро (где происходит междоменная маршрутизация). Маршрутизаторы с поддержкой LISP соединяют эти логические пространства. LISP поддерживает базу данных, называемую системой сопоставления (Mapping System), для хранения и извлечения сведений о сопоставлении отождествлений и местоположений. Маршрутизаторы с поддержкой LISP обмениваются пакетами через ядро Internet, инкапсулируя их в нужное место.

  • Локаторы RLOC имеют смысл лишь в базовой (underlay) сети, т. е. в ядре маршрутизации.

  • EID имеют смысл лишь в наложенной сети, которая является связующей инкапсуляцией между маршрутизаторами с поддержкой LISP.

  • На границе LISP идентификаторы EID сопоставляются с RLOC.

  • В базовой сети RLOC служат сразу локаторами и идентификаторами.

  • EID внутри сайта LISP служат идентификаторами и локаторами для других узлов этого сайта.

  • EID внутри сайта LISP передаёт идентификатор и ограниченную семантику локатора узлам других сайтов LISP (т. е. достаточно локатора, чтобы понять, что EID является внешним для сайта).

Указанные выше свойства не уникальны для LISP и присущи многим наложенным протоколам.

Исходную мотивацию разработки LISP можно найти в проблеме расширяемости маршрутизации [RFC4984], где при полном развёртывании LISP ядро Internet будет заполнено RLOC, а механизмы организации трафика (Traffic Engineering или TE) будут вынесены в систему сопоставления. В таком варианте локаторы RLOC будут квазистатическими (т. е. меняющимися редко), что делает систему маршрутизации расширяемой [Quoitin], а EID могут перемещаться свободно, «не создавая пены» в базовой системе глобальной маршрутизации. В [RFC7215] рассмотрено влияние LISP на систему глобальной маршрутизации в процессе перехода. Однако разделение местоположения и идентификации, предлагаемое LISP, подходит и для применения в других случаях, таких как TE, многодомные подключения и мобильность узлов.

В этом документе описана архитектура и основные механизмы работы LISP, а также принципы разработки. Важно отметить, что документ не задаёт и не дополняет LISP. Заинтересованным читателям следует обратиться к спецификациям LISP ([RFC9300] и [RFC9301]), а также дополнительным документам ([RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052]) для спецификации протокола и рекомендаций по развёртыванию LISP [RFC7215].

2. Определения терминов

Endpoint Identifier (EID) — идентификатор конечной точки

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

Routing Locator (RLOC) — локатор маршрутизации

Адрес, топологически назаначаемый точке подключения к сети. Обычно маршрутизируется между доменами.

Ingress Tunnel Router (ITR) — входной маршрутизатор туннеля

Поддерживающий LISP маршрутизатор, инкапсулирующий пакеты от сайта LISP в направлении ядра сети.

Egress Tunnel Router (ETR) — выходной маршрутизатор туннеля

Поддерживающий LISP маршрутизатор, декапсулирующий пакеты из ядра сети в направлении сайта LISP.

xTR

Машрутизатор, реализующий функции ITR и ETR.

Map-Request

Сигнальное сообщение LISP, служащее для запроса отображения EID на RLOC.

Map-Reply

Сигнальное сообщение LISP, служащее ответом на Map-Request и содержащее нужное отображение EID на RLOC.

Map-Register

Сигнальное сообщение LISP, служащее для регистрации отображения EID на RLOC.

Map-Notify

Сигнальное сообщение LISP, передаваемое в ответ на Map-Register для подтверждения корректного получения отображения EID на RLOC.

Этот документ описывает архитектуру LISP и не вносит новых терминов. Определения используемых терминов даны в [RFC9300], [RFC9301], [RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052], [RFC7215].

3. Архитектура LISP

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

3.1. Принципы устройства протокола

Архитектура LISP основана на 4 базовых принципах.

Разделение локаторов и идентификаторов

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

Наложение

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

Отделение плоскости данных от плоскости управления

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

Возможность поэтапного развёртывания

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

3.2. Обзор архитектуры

LISP архитектурно отделяет ядро от периметра Internet, создавая два пространства имён — EID и RLOC. Периметр образуют сайты LISP (например, автономные системы — AS), использующие адреса EID. Идентификаторы EID — это адреса IPv4 или IPv6, однозначно указывающие конечные хосты, которые назначаются и настраиваются с использованием механизмов, существовавших на момент разработки протокола. В EID не включаются междоменные топологические данные и поэтому EID обычно маршрутизируются на периферии (внутри сайта LISP), но не в ядре. Взаимодействие сайтов LISP с сайтами и доменами без поддержки LISP в сети Internet описано в параграфе 3.5. Механизмы межсетевого взаимодействия.

Сайты LISP (на периметре) подключаются к межсетевому ядру Internet через поддерживающие LISP маршрутизаторы (например, граничные маршрутизаторы). Сайты LISP соединяются через межсетевое ядро Internet с использованием туннелей между поддерживающими LISP маршрутизаторами. Когда пакет от сайта LISP направлен в сеть ядра, он попадает в инкапсулированный туннель через входной маршрутизатор ITR. Пакеты из ядра сети на сайт LISP выходят из инкапсулированного туннеля через выходной маршрутизатор ETR. XTR — это маршрутизатор, выполняющий функции ITR и ETR. В этом контексте ITR инкапсулируют пакеты, а ETR декапсулируют их, следовательно LISP работает как наложение на имеющееся ядро Internet.

                       /-----------------\                 ---
                       |     Система     |                  |
                       .  сопоставления  |                  |Плоскость
                      -|                 |`,                |управления
                    ,' \-----------------/  .               |
                   /                         |             ---
   ,..,           -        _,....,,          |      ,..,    |
 /     `        ,'      ,-`        `',       |    /     `   |
/        \ +-----+   ,'              `,  +-----+ /        \ |
| Простр.|-| xTR |--/   Пространство  ,--| xTR |-| Простр.| |Плоскость
|  EID   |-|     |--|       RLOC      |--|     |-|  EID   | |данных
\        / +-----+  .                 /  +-----+ \        / |
 `.    .'            `.              ,'           `.    .'  |
   `'-`                `.,        ,.'               `'-`   ---
                          ``'''``
  Сайт LISP (периметр)      Core         Сайт LISP (периметр)

Рисунок 1. Схема архитектуры LISP.


При использовании LISP ядро работает с локаторами RLOC. Локатор RLOC — это адрес IPv4 или IPv6, назначенный интерфейсу маршрутизатора ITR или ETR в сторону ядра.

База данных (обычно распределенная), которую называют системой сопоставления (Mapping System), содержит сопоставления между EID и RLOC. Такие сопоставления связывают идентификаторы устройств, подключённых к сайту LISP (EID), с набором RLOC, настроенных на поддерживающих LISP маршрутизаторах, обслуживающих сайт. Кроме того, сопоставления включают правила TE и могут быть настроены на поддержку многодомности и распределения нагрузки. Система сопоставления LISP концептуально похожа на DNS и организована как распределенная по сети база данных множества организаций. В LISP маршрутизаторы ETR регистрируют сопоставления, а ITR извлекают их.

В архитектуре LISP уделено особое внимание поэтапному развёртыванию. С учётом того, что LISP представляет наложение на текущую архитектуру Internet, конечные хосты, а также внутридоменные и междоменные маршрутизаторы не требуют изменений. В существующей инфраструктуре требуется изменять лишь маршрутизаторы, соединяющие между собой пространства EID и RLOC. Кроме того, LISP требует развёртывания независимой системы сопоставления, такая распределенная база данных является новым элементом сети.

Ниже (Рисунок 2) представлена упрощённая последовательность потока пакетов между парой узлов, подключённых к сайтам LISP. Отметим, что типичные маршрутизаторы с поддержкой LISP — это xTR (ITR и ETR). Клиент HostA на рисунке передаёт пакет серверу HostB.

                         /----------------\
                         |     Система    |
                         |  сопоставления |
                        .|                |-
                       ` \----------------/ `.
                     ,`                       \
                    /                          `.
                  ,'         _,..-..,,           ',
                 /         -`         `-,          \
               .'        ,'              \          `,
               `        '                 \           '
           +-----+     |                   | RLOC_B1+-----+
    HostA  |     |    |    Пространство     |-------|     |  HostB
    EID_A--|ITR_A|----|        RLOC         |       |ETR_B|--EID_B
           |     | RLOC_A1                  |-------|     |
           +-----+     |                   | RLOC_B2+-----+
                        ,                 /
                         \               /
                          `',         ,-`
                             ``''-''``

Рисунок 2. Последовательность потока пакетов в LISP.

  1. HostA извлекает EID_B для HostB, обычно запрашивая DNS и получая запись A или AAAA. Затем он создаёт пакет IP как в Internet. Пакет имеет адрес отправителя EID_A и адрес получателя EID_B.

  2. Пакет пересылается в ITR_A сайта LISP с использованием стандартных внутридоменных механизмов.

  3. ITR_A при получении пакета запрашивает систему сопоставления для получения локатора ETR_B, обслуживающего EID_B сервера HostB. Для этого служит управляющее сообщение LISP, называемое Map-Request. Сообщение содержит EID_B в качестве ключа поиска. В ответ ITR_A получает другое управляющее сообщение LISP — Map-Reply. Это сообщение содержит два локатора RLOC_B1 и RLOC_B2, а также правила TE — приоритет и вес для каждого локатора. Отметим, что при необходимости Map-Reply может включать большее число локаторов. ITR_A может кэшировать сопоставления в локальном хранилище для ускорения пересылки последующих пакетов.

  4. ITR_A инкапсулирует пакет в сторону RLOC_B1 (выбирается в соответствии с приоритетом и весом в сопоставлении). Пакет имеет два заголовка IP. Внешний заголовок указывает RLOC_A1 как источник и RLOC_B1 — как получателя. Во внутреннем исходном заголовке пакета указан адрес источника EID_A и получателя EID_B. Затем ITR_A добавляет заголовок LISP. Более подробно процесс описан в параграфе 3.3.1. Инкапсуляция LISP.

  5. Инкапсулированный пакет пересылается через межсетевое ядро как обычный пакет IP, оставляя EID невидимым для ядра.

  6. При получении инкапсулированного пакета маршрутизатор ETR_B декапсулирует его и пересылает в HostB.

3.3. Плоскость данных

В этом параграфе приведено высокоуровневое описание плоскости данных LISP, детально заданной в [RFC9300]. Плоскость данных LISP отвечает за инкапсуляцию и декапсуляцию пакетов данных и кэширование соответствующего состояния пересылки. Основными элементами плоскости данных являются маршрутизаторы ITR и ETR. Оба типа маршрутизаторов поддерживают LISP и соединяют EID с пространством RLOC (ITR) и наоборот (ETR).

3.3.1. Инкапсуляция LISP

Маршрутизаторы ITR инкапсулируют пакеты данных в направлении ETR. Пакеты данных LISP инкапсулируются с использованием UDP (порт 4341). Порт отправителя ITR обычно выбирает с использованием хэш-значения квинтета (5-tuple) из внутреннего заголовка (для согласованности при спользовании нескольких путей, как в ECMP [RFC2992]) и игнорируется при получении. Пакеты данных LISP часто инкапсулируются в пакеты UDP с нулевой контрольной суммой [RFC6935] [RFC6936], которую нельзя проверить при получении, поскольку внутри пакета LISP имеется транспортный заголовок с проверяемой контрольной суммой. Использование нулевой контрольной суммы UDP при передаче по протоколу IPv6 для всех протоколов туннелирования, подобных LISP, регулируется заявлением о применимости из [RFC6936]. Если пакеты данных LISP инкапсулируются в пакеты UDP с ненулевой контрольной суммой, внешняя контрольная сумма проверяется при получении пакетов UDP как при обычной обработке UDP.

Пакеты с инкапсуляцией LISP включают также заголовок LISP (между внешним заголовком UDP и исходным заголовком IP). Заголовок LISP устанавливают маршрутизаторы ITR и вырезают ETR. Заголовок содержит сведения о достижимости (4.2. Достижимость RLOC) и поле Instance ID, служащее для разделения трафика разных арендаторов на сайте LISP, что позволяет применять на сайтах перекрывающуюся, но логически разделенную адресацию EID.

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

  1. Внешний заголовок IP с RLOC в качестве адресов отправителя и получателя. Этот заголовок создаёт маршрутизатор ITR и вырезает маршрутизатор ETR.

  2. Заголовок UDP (порт 4341), обычно с нулевой контрольной суммой, создаваемый ITR и вырезаемый ETR.

  3. Заголовок LISP со свойствами плоскости пересылки (такими как доступность) и полем Instance ID. Этот заголовок создаёт маршрутизатор ITR и вырезает маршрутизатор ETR.

  4. Внутренний заголовок IP с EID в качестве адресов отправителя и получателя. Этот заголовок создаёт хост-источник и он сохраняется неизменным при обработке в плоскости данных LISP на ITR и ETR.

В некоторых случаях полезна повторная инкапсуляция и/или рекурсивные туннели для выбора конкретного пути через базовую сеть, например, для предотвращения перегрузки или отказа. Туннелирование с повторной инкапсуляцией является последовательным применением туннелей LISP и выполняется при удалении декапсулятором (ETR) заголовка LISP и новой инкапсуляции (ITR) с добавлением другого заголовка. Рекурсивные туннели являются вложенными и реализуются с использованием для пакета неоднократной инкапсуляции LISP. Такие функции реализуются маршрутизаторами с реинкапсуляцией туннелей (Re-encapsulating Tunnel Router или RTR). Маршрутизатор RTR можно считать выступающим сначала в роли ETR для декапсуляции пакетов, затем — в роли ITR с инкапсуляцией пакетов для другого локатора (см. [RFC9300] и [RFC9301]).

3.3.2. Состояние пересылки LISP

В архитектуре LISP маршрутизаторы ITR сохраняют лишь сведения, достаточные для маршрутизации проходящего через них трафика. Иными словами, ITR нужно лишь извлечь из системы сопоставления LISP отображения EID-Prefix (блок EID) на RLOC, применяемые для инкапсуляции пакетов. Такие сопоставления хранятся в локальном кэше, называемом LISP Map-Cache, для последующих пакетов, направляемых в тот же EID-Prefix. Отметим, что в случае перекрытия EID-Prefix маршрутизатор ITR может получить по запросу набор сопоставлений из запрошенного EID-Prefix и более конкретных EID-Prefix (см. параграф 5.5 в [RFC9301]). Отображения включают значения TTL, устанавливаемые ETR. Дополнительные сведения об управлении Map-Cache приведены в параграфе 4.1. Поддержка кэша.

3.4. Плоскость управления

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

3.4.1. Сопоставления LISP

Каждое отображение включает привязки EID-Prefix к набору RLOC, а также правила TE в виде приоритета и веса для RLOC. Приоритет позволяет ETR настроить активную и резервную политику, а вес служит для распределения нагрузки (трафика) между RLOC (по потокам).

Типичное сопоставление в LISP связывает EID в форме префиксов IP с набором RLOC тоде в форме адресов IP. Адреса IPv4 и IPv6 кодируюся с использованием подходящего идентификатора семейства адресов (Address Family Identifier или AFI) [RFC8060]. Однако LISP может поддерживать более общее кодирование адресов на канонического формату LISP (LISP Canonical Address Format или LCAF) [RFC8060]. С помощью такого обобщённого синтаксиса кодирования адресов LISP стремится обеспечить гибкость имеющихся и будущих приложений. Например, LCAF позволяет поддерживать адреса MAC (Media Access Control), географические координаты, имена ASCII и задаваемые приложением данные.

3.4.2. Интерфейс системы сопоставления

LISP задаёт стандартный интерфейс между плоскостями данных и управления в [RFC9301], включающий 2 сущности.

Map-Server — сервер сопоставлений

Компонент сетевой инфраструктуры, изучающий отображения через маршрутизаторы ETR и публикующий их в системе сопоставления LISP Mapping System. Обычно Map-Server не уполномочен отвечать на запросы, поэтому он пересылает их ETR. Однако сервер может работать в режиме посредника (proxy-mode), когда ETR делегирует ему право отвечать на запросы. Это полезно при ограниченности ресурсов ETR (например, CPU или питания).

Map-Resolver — распознаватель сопоставлений

Компонент сетевой инфраструктуры, соединяющий маршрутизатор ITR с системой сопоставления путём посредничества (proxying) для запросов, а иногда и откликов.

Интерфейс определяет 4 управляющих сообщения LISP, передаваемых в дейтаграммах UDP (порт 4342).

Map-Register

Эти сообщения применяются маршрутизаторами ETR для регистрации отображений в системе сопоставления и аутентифицируются с использованием общего для ETR и Map-Server ключа.

Map-Notify

По запросу ETR это сообщение передаёт Map-Server в ответ на сообщение Map-Register для подтверждения корректного получения отображения и передачи последнего состояния Map-Server для отображения EID на RLOC. В некоторых случаях Map-Notify может передаваться для прежних RLOC, если для EID зарегистрирован новый набор RLOC.

Map-Request

Это сообщение применяется маршрутизаторами ITR или распознавателями Map-Resolver для получения сопоставления данного EID.

Map-Reply

Это сообщение передаёт Map-Server или ETR в ответ на Map-Request, указывая найденное сопоставление. Следует отметить, что Map-Reply может содержать негативный отклик, если, например, запрошенный идентификатор EID не входит в пространство LISP EID. В таких случаях ITR обычно пересылает трафик как есть (без инкапсуляции) в сеть Internet. Это определено для поддержки поэтапного развёртывания LISP.

3.4.3. Система сопоставления

LISP архитектурно разделяет плоскости управления и данных с помощью стандартного интерфейса. Интерфейс связывает плоскость данных (маршрутизаторы, отвечающие за пересылку пакетов данных) с системой сопоставления LISP (база данных, отвечающая за хранение отображений). При таком разделении плоскости данных и управления могут иметь разную архитектуру и расширяться независимо. Обычно плоскость данных оптимизируется для маршрутизации пакетов по иерархическим адресам IP. Однако требования плоскости управления могут быть иными, например, за счёт использования преимуществ LCAF система сопоставления может хранить неиерархические ключи (такие как MAC-адреса) и для её расширяемости нужен будет другой подход. Другим важным различием плоскостей данных и управления LISP является то, что за счёт локального кэширования отображений в ITR системе сопоставления не требуется работать со скоростью линии.

При выборе архитектуры системы сопоставления было рассмтрено множество механизмов создания распределенных систем — базы данных на основе графов в форме альтернативной логической топологии LISP (LISP Alternative Logical Topology или LISP-ALT) [RFC6836], иерархические базы данных в форме дерева делегированных баз данных LISP (LISP Delegated Database Tree или LISP-DDT) [RFC8111], монолитные базы данных в форме LISP Not-so-novel EID-to-RLOC Database (LISP-NERD) [RFC6837], плоские базы данных в форме распределенной хэш-таблицы LISP (LISP Distributed Hash Table или LISP-DHT) [LISP-SHDHT] [Mathy], и основанные на групповой передаче базы данных [LISP-EMACS]. Следует отметить, что в некоторых вариантах, таких как приватное развёртывание, система сопоставления может быть логически централизованной и обычно будет включать один Map-Server/Map-Resolver.

В последующих параграфах более подробно рассмотрены две из упомянутых систем сопоставления (LISP-ALT и LISP-DDT), которые были реализованы и развёрнуты.

3.4.3.1. LISP-ALT

LISP-ALT [RFC6836] была первой системой сопоставления, которая бала предложена, разработана и развёрнута в пилотной сети LISP. Она основана на распределенном наложении BGP с участием Map-Server и Map-Resolver. Узлы соединялись с партнёрами через статические туннели. Каждый вовлечённый Map-Server в топологии ALT анонсировал EID-Prefix, зарегистрированные обслуживаемыми ETR, что делало EID маршрутизируемыми в топологии ALT.

Когда маршрутизатору ITR нужно отображение, он передаёт Map-Request распознавателю Map-Resolver, который, используя топологию ALT, пересылает Map-Request в направлении Map-Server, отвечающего за сопоставление. При получении запроса Map-Server пересылает его маршрутизатору ETR, который отвечает напрямую ITR.

3.4.3.2. LISP-DDT

LISP-DDT [RFC8111] концептуально похожа на DNS — иерархический каталог, внутренняя структура которого отражает иерархическую природу адресного пространства EID. Иерархия DDT включает узлы DDT, формирующие дерево, листьями которого служат Map-Server. Наверху структууры размещается корень DDT, являющийся экземпляром узла DDT, соответствующим всему пространству адресов. Как и DNS, система DDT поддерживает множество избыточных узлов DDT и/или корней DDT. Распознаватели Map-Resolver являются клиентами иерархии DDT и могут обращаться к корню и другим узлам DDT.

                        /---------\
                        |         |
                        | DDT Root|
                        |   /0    |
                      ,.\---------/-,
                  ,-'`       |       `'.,
               -'`           |           `-
           /-------\     /-------\    /-------\
           |  DDT  |     |  DDT  |    |  DDT  |
           | Node  |     | Node  |    | Node  |  ...
           |  0/8  |     |  1/8  |    |  2/8  |
           \-------/     \-------/    \-------/
         _.                _.            . -..,,,_
       -`                -`              \        ````''--
+------------+     +------------+   +------------+ +------------+
| Map-Server |     | Map-Server |   | Map-Server | | Map-Server |
| EID-Prefix1|     | EID-Prefix2|   | EID-Prefix3| | EID-Prefix4|
+------------+     +------------+   +------------+ +------------+

Рисунок 3. Схематическое представление дерева DDT.


Префиксы и структура на рисунке 3 представлены лишь для иллюстрации.

Структура DDT на деле не индексирует EID-Prefix, индексируя взамен расширенные префиксы (Extended EID-Prefix или XEID-Prefix), которые являются просто конкатенацией нескольких полей (от старшего бита к младшему): Database-ID, Instance ID, Address Family Identifier и фактических EID-Prefix. Database-ID указывается для возможных в будущем требований повышения уровня иерархии и возможности создания нескольких отдельных деревьев баз данных.

При ответах на запрос LISP-DDT работает подобно DNS, но поддерживает лишь интерактивный поиск. Клиенты DDT (обычно Map-Resolver) создают запросы Map-Request к корневому узлу DDT, получая в ответ новое управляющее сообщение LISP — Map-Referral. Это сообщение содержит список RLOC набора узлов DDT, соответствующих настроенному делегированию XEID. Т. е. сведения в Map-Referral указывают потомка запрашиваемого узла DDT, у которого есть более конкретные сведения об интересующем префиксе XEID-Prefix. Этот процесс повторяется, пока клиент DDT не пройдёт структуру дерева (вниз) и не найдет Map-Server, обслуживающий искомый XEID. В этот момент клиент передаёт Map-Request и получает Map-Reply с сопоставлениями. Важно подчеркнуть, что клиенты DDT могут кэшировать сведения из Map-Referral, т. е. структуру DDT, чтобы сократить время извлечения сопоставлений [Jakab].

Система сопоставления DDT основана на ручной настройке, т. е. на Map-Resolver настраивается набор доступных корневых узлов DDT, а на узлах DDT — соответствующее делегирование XEID. Изменение настроек на узлах DDT требуется лишь при смене структуры дерева и настройки не зависят от динамики EID (выделения RLOC или смены правил TE).

3.5. Механизмы межсетевого взаимодействия

EID обычно идентичны адресам IPv4 или IPv6 и хранятся в системе сопоставления LISP. Однако они обычно не анонсируются в систему маршрутизации за пределами локального домена LISP. Поэтому для LISP нужен механизм межсетевого взаимодействия, позволяющий сайтам LISP взаимодействовать с сайтами, не понимающими LISP (и наоборот). Механизмы межсетевого взаимодействия LISP заданы в [RFC6832].

В LISP заданы две сущности для обеспечения межсетевого взаимодействия.

Proxy Ingress Tunnel Router (PITR) — маршрутизатор-посредник входного туннеля

PITR обеспечивают связность унаследованной сети Internet с сайтами LISP. PITR анонсируют в систему глобальной маршрутизации блоки EID-Prefix (с агрегированием при возможности) для привлечения трафика. Для каждого входящего пакета из источника вне сайта LISP (не EID) PITR использует инкапсуляцию LISP в направлении RLOC подходящего сайта LISP. Влияние PITR на размер таблицы маршрутизации зоны без принятого по умолчанию маршрута (Default-Free Zone или DFZ) в худшем случае похоже на ситуацию без применения LISP. EID-Prefix будут по возможности агрегироваться как PITR, так и системой глобальной маршрутизации.

Proxy Egress Tunnel Router (PETR) — маршрутизатор-посредник выходного туннеля

PETR обеспечивает связность сайта LISP с традиционной сетью Internet. В некоторых случаях сайты LISP не могут передавать инкапсулированные пакеты с локальным адресом EID в качестве источника в традиционную сеть Internet, например, когда краевой маршрутизатор провайдера (Provider Edge или PE) использует индивидуальную пересылку по обратному пути (Unicast Reverse Path Forwarding или uRPF) или промежуточная сеть между сайтом LISP и не понимающим LISP сайтом не поддерживает нужную версию IP (IPv4 или IPv6). В обоих PETR преодолевает такие ограничения за счёт инкапсуляции пакетов. Не существует конкретных правил распространения адресов PETR RLOC маршрутизаторам ITR.

Кроме того, LISP определяет механизмы для работы с приватными EID [RFC1918] через LISP-NAT [RFC6832]. В этом случае xTR заменяет приватное значение EID источника на маршрутизируемое. На момент написания документа продолжалась работа по прохождению через NAT, т. е. размещения xTRs за NAT с использованием немаршрутизируемых RLOC.

PITR, PETR, и LISP-NAT позволяют развёртывать LISP поэтапно, обеспечивая достаточную гибкость размещения временных между частями сети с поддержкой и без поддержки LISP и упрощая перенос этих границ со временем.

4. Механизмы работы LISP

В этом разделе описаны основные рабочие механизмы, определённые в LISP.

4.1. Поддержка кэша

Разделение плоскостей управления и данных в LISP с хранением сопоставлений в плоскости данных и использовании их для пересылки в плоскости управления требует локального кэширования в ITR для снижения сигнальных издержек (Map-Request/Map-Reply) и повышения скорости пересылки. Локальный кэш в ITR называют Map-Cache и применяют для пакетов с инкапсуляцией LISP. Map-Cache индексируется по парам (Instance ID, EID-Prefix) и содержит в основном набор RLOC со связанными правилами TE (приоритет и вес).

Для Map-Cache, как и иных случаев кэширования, нужны механизмы обеспечения когерентности, чтобы сведения оставались актуальными. LISP задает 3 основных механизма поддержки когерентности кэша.

Record Time To Live (TTL) — срок действия записи

Каждая запись сопоставления имеет поле TTL, задаваемое маршрутизатором ETR. По истечении TTL запись не может применяться ITR, пока не будет обновлена отправкой нового Map-Request.

Solicit-Map-Request (SMR) — запрос Map-Request

SMR служит явным механизмом обновеления данных сопоставления. В частности, можно передать специальный тип Map-Request по требованию ETR для запроса обновления сопоставлений. При получении сообщения SMR маршрутизатор ITR должен обновить привязки передавая Map-Request системе сопоставления. Использование SMR описано в [RFC9301].

Map-Versioning — версия сопоставления

Этот необязательный механизм добавляет в конец заголовка LISP пакетов данных номер версии отображения, используемой маршрутизатором xTR. При получении xTR пакета с инкапсуляцией LISP от удалённого xTR, можно узнать, не устарела ли локальная или удалённая версия Map-Cache. Если локальная версия устарела маршрутизатор передает Map-Request для удалённого EID, чтобы получить новое сопоставление. Если же обнаружно устаревание Map-Cache на удалённом xTR, маршрутизатор передаёт SMR для уведомления того о доступности нового сопоставления. Подробное описание процесса приведено в [RFC9302].

В некоторых случаях запись Map-Cache можно обновить заранее с помощью описанных ниже механизмов.

4.2. Достижимость RLOC

В большинстве случаев LISP работает с системой отображения на основе вытягивания (pull), например, DDT. Это обеспечивает сквозную архитектуру вытягивания и состояние сети храниться в плоскости управления, а плоскость данных извлекает его по запросу. Это влияет на распространение сведений о достижимости и живучести xTR, поскольку архитектура вытягивания требует явных механизмов распространения таких данных. Поэтому в LISP задан набор механизмов для информирования ITR и PITR о доступности кэшированных RLOC.

Locator-Status-Bits (LSBs) — биты состояния локатора

Метод LSBs является пассивным. Поле LSB передаётся в заголовках LISP пакетов данных и может устанавливаться маршрутизаторами ETR для указания активных и неактивных (up/down) RLOC сайта ETR. Эти сведения могут служить маршрутизаторам ITR подсказкой о доступности для выполнения дополнительной проверки. LSB не указывают статус доступности пути, а лишь дают подсказки о состоянии RLOC. Поэтому они не должны применяться в общедоступной сети Internet и следует связывать их с Map-Versioning для предотвращения «гонки», где LSB считаются относящимися не к тем RLOC, с которыми они связаны.

Echo-Nonce

Это пассивный метод, который может эффективно работать лишь при двухсторонних потоках данных между двумя взаимодействующими xTR. По сути, ITR добавляет в конце заголовка LISP пакетов данных случайное значение (nonce). Если путь и зондируемый локатор активны, ETR будет добавлять это же случайное значение в следующий пакет данных. Если этого не происходит, ITR может счесть локатор недоступным. При одностороннем трафике или несовпадении принимающего трафик ETR с передающим трафик назад маршрутизатором ITR нужны дополнительные механизмы. Механизм Echo-Nonce должен применяться лишь в доверенных средах, а не в общедоступной сети Internet.

RLOC-Probing — зондирование RLOC

Имеется механизм активного зондирования, когда ITR передают пробные пакеты конкретным локаторам. Это позволяет проверить как локатор, так и путь к нему. В частности, это делается путём отправки Map-Request (с некоторыми флагами) в плоскости данных (пространство RLOC) и ожидания Map-Reply, передаваемого также в плоскости данных. Активная природа RLOC-Probing обеспечивает эффективный механизм определения доступности и (в случае отказа) переключения на другой локатор. Кроме того, механизм обеспечивает полезную оценку RTT для задержек на пути, которую могут использовать другие сетевые алгоритмы.

Следует отметить, что RLOC-Probing и Echo-Nonce могут работать вместе. В частности, если nonce не возвращается, ITR не может определить на каком из направлений возник отказ. В этом случае ITR может использовать RLOC-Probing.

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

Сигналы ICMP

Базовая среда LISP — инфраструктура Internet — использует ICMP для сигналов о недоступности (среди прочего). LISP может использовать это и считать получение сообщений ICMP Network Unreachable или ICMP Host Unreachable подсказкой о возможной недоступности локатора, вызывающей дополнительную проверку.

Базовая маршрутизация

Протоколы BGP и IGP несут сведения о доступности. Маршрутизаторы с поддержкой LISP, имеющие доступ к данным базовой маршрутизации, могут использовать их для проверки доступности локатора.

4.3. Синхронизация ETR

Все ETR, полномочные для конкретного EID-Prefix, должны анонсировать запрашивающим одно и то же сопоставление. Это значит, что ETR должны знать о статусе RLOC в других ETR. Это называют синхронизацией ETR.

На момент написания документа в LISP не был задан механизм синхронизации ETR. Хотя для решения задачи пригодны многие имеющиеся методы, вопрос ещё не решён. Поэтому операторы должны полагаться на согласованную ручную настройку.

4.4. Обработка MTU

Поскольку LISP инкапсулирует пакеты, протоколу приходится иметь дело с превышением размера пакетов над MTU для пути между ITR и ETR. LISP определяет два механизма.

Без учёта состояния

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

С учётом состояния

ITR отслеживают значения MTU на путях к целевым локаторам на основании пакетов ICMP Too Big от промежуточных маршрутизаторов. Маршрутизаторы ITR передают сообщения ICMP Too Big для информирования отправителей об эффективном значении MTU. Кроме того, ITR могут применять механизмы определения MTU для пути (Path MTU Discovery или PMTUD) [RFC1191] или определение MTU на уровне пакетизавции (Packetization Layer Path MTU Discovery или PLPMTUD) [RFC4821] для отслеживания MTU в направлении локаторов.

В обоих случаях при невозможности фрагментировать пакеты (IPv4 с DF=1 или IPv6) ITR отбрасывает пакет и передаёт его отправителю сообщение ICMP Too Big.

5. Мобильность

Разделение локаторов и идентификаторов в LISP подходит для целей TE, где сайты LISP могут менять свои точки присоединения к Internet (т. е. RLOC) не затрацивая конечные точки и ядро Internet. В этом контексте граничные маршрутизаторы используют функциональность xTR, а конечные точки не знают о наличии LISP. Это похоже на Network Mobility [RFC3963], однако данный режим работы не обеспечивает «бесшовной» мобильности конечных точек между разными сайтами LISP, поскольку адрес EID может не маршрутизироваться в посещенном сайте. Тем не менее, LISP можно использовать для бесшовной мобильности IP, когда LISP реализован непосредственно на конечной точке или та перемещается к подключённому xTR. Тогда каждая конечная точка является xTR, а адрес EID — это один из предоставленных сетевому стеку, используемому приложениями, тогда как RLOC берётся из посещенной сети. Это похоже на функциональность Mobile IP ([RFC5944] и [RFC6275]).

При смене устройством своего локатора RLOC маршрутизатор xTR обновляет RLOC в своём локальном сопставлении и регистрирует его на своём Map-Server, обычно с малым значением TTL (1 минута). Чтобы избежать потребности в домашнем шлюзе, ITR также указывает смену RLOC всем удаленным устройствам, имеющим текущую связь с перемещенным устройством Сочетание обоих методов обеспечивает расширяемость системы, поскольку сигнализация строго ограничена Map-Server и хостами, с которыми имеется связь. В случае перемещения EID-Prefix может быть достаточно мелким, вплоть до /32 или /128 (IPv4 и IPv6, соответственно), в зависимости от конкретного применения (например, перенос подсети или одной виртуальной машиы или мобильного узла).

Разделение идентификатора и локатора, обеспечиваемое LISP, позволяет работать с другими решениями для мобильности L2 и L3.

6. Групповая передача

LISP поддерживает доставку групповых пакетов IP, переданных из пространства EID. Требуемые изменения протоколов групповой доставки указаны в [RFC6831].

LISP может создавать состояния групповой рассылки (для приёма и передачи) как в ядре, так и на сайтах. При использовании сигнализации для создания групповой рассылки на сайтах маршрутизаторы LISP инкапсулируют сообщения PIM Join/Prune от получателя к сайтам источников как индивидуальные пакеты. В ядре маршрутизаторы ETR создают новое сообщение PIM Join/Prune, адресованное RLOC маршрутизатора ITR, обслуживающего источник. Упрощённая последовательность приведена ниже.

  1. Конечный хост, желающий присоединиться к групповому каналу передаёт отчёт IGMP. Групповые маршрутизаторы PIM на сайте LISP распространяют сообщения PIM Join/Prune (S-EID, G) в направлении ETR.

  2. Сообщение Join поступает в ETR и маршрутизатор ETR создаёт два сообщения Join. Первое является индивидуальным пакетом с инкапсуляцией LISP для исходного сообщения Join в направлении RLOC обслуживающешл источник маршрутизатора ITR. Это сообщение создаёт групповое состояние (S-EID, G) на сайте источника. Второе сообщение Join содержит в качестве адреса получателя RLOC маршрутизатора ITR, обслуживающего источник (S-RLOC, G) и создаёт состояние групповой рассылки в ядре.

  3. Групповые пакеты данных, созданные источником (S-EID, G) передаются от него к ITR. Маршрутизатор ITR инкапсулирует групповые пакеты в LISP. Внешний заголовок включает его RLOC (S-RLOC) как отправителя и исходный адрес multicast-группы (G) как получателя. Отметим, что групповые адреса являются логическими и не распознаются системой сопоставления. Затем групповые пакеты передаются через ядро в направлении принимающих ETR, которые декапсулируют пакеты и пересылают их по групповому состоянию на сайте.

Отметим, что внутренние и внешние групповые адреса обычно различаются за исключением особых случаев, когда базовый провайдер жёстко контролирует наложение. Спецификации LISP уже поддерживают все режимы PIM modes [RFC6831]. Кроме того, LISP может поддерживать другие механизмы сохранения групповых состояний.

Когда групповые источники и получатели имеются на сайтах LISP, а ядро сети между сайтами не обеспечивает поддержки групповой передачи, можно применять бессигнальный механизм для создания наложения, которое позволит передавать групповой трафик между сайтами и соединить деревья групповой рассылки на разных сайтах [RFC8378]. Регистрации с разных сайтов-получателей будут слиты в системе сопоставления для сборки списка групповой репликации, включающего все RLOC, ведущие к получателям для конкретной группы или группового канала. Список репликации для каждой конкретной групповой записи поддерживается как запись системы сопоставления LISP.

7. Варианты применения

7.1. Организация трафика

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

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

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

7.2. LISP для сосуществования с IPv6

Инкапсуляция LISP позволяет доставлять пакеты, использующие EID из данного пространства адресов (например, IPv6) в пакетах другого семейства адресов (например, IPv4). Отсутствие привязки между семействами адресов RLOC и EID делает LISP подходящим кандидатом, позволяющим, например, развернуть IPv6 через ядро без поддержки IPv6.

Например, два ЦОД, поддерживающие лишь IPv6 можно соединить через традиционную сеть IPv4 (Internet). Если граничные маршрутизаторы поддерживают LISP, передача пакетов между ЦОД выполняется без какой-либо трансляции, поскольку исходные пакеты IPv6 (в пространстве EID) LISP будет инкапсулировать и передавать в пакетах IPv4 традиционной сети Internet через IPv4 RLOC.

7.3. LISP для VPN

Обычно в одной физической инфраструктуре работает несколько виртуальных сетей. В таких ситуациях определение принадлежности пакета к виртуальной сети становится важной задачей и для этого часто применяются теги или метки. При использовании LISP пакеты можно различать по полю Instance ID. Когда ITR инкапсулирует пакет из определённой виртуальной сети (например, известной по VRF3 или VLAN), он помечает инкапсулированный пакет значением Instance ID, соответствующим виртуальной сети. Когда ETR получает пакет с Instance ID, он использует это поле для определения принадлежности пакета.

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

7.4. LISP для мобильности VM в ЦОД

Способ обеспечения бесшовной можильности виртуальных машин (VM) в ЦОД состоит в представлении опорной сети ЦОД как пространства RLOC, а подсетей с серверами, как пространство EID. Маршрутизаторы LISP помещаются на границе между магистралью и каждой подсетью серверов. При перемещении VM в другую подсеть она может (временно) сохранить прежний адрес для продолжения работы без сброса транспортных соединений. Когда xTR обнаруживает адрес источника из другой подсети, он регистрирует адрес в системе сопоставления. Для информирования других маршрутизаторов LISP о переносек виртуальной машины и её новом местоположении, чтобы избежать обходных путей через исходную подсеть, применяются такие механизмы, как сообщения Solicit-Map-Request.

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

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

Обычно плоскость данных реализуется на быстром пути маршрутизаторов для обеспечения высокоскоростной пересылки, тогда как плоскость управления реализуется на медленном пути маршрутизаторов для обеспечения гибкости. Разрыв производительности медленного и быстрого пути может составлять несколько порядков. Поэтому нужно тщательно обдумать способ уведомления плоскости управления о событиях в плоскости данных, чтобы не перегрузить медленный путь, следует также применять ограничение скорости, как указано в [RFC9300] и [RFC9301].

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

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

Сопоставления являются центральным элементом LISP и должны приниматься все меры предосторожности для предотвращения вредоносных манипуляций или использования их злоумышленниками. Использование доверенных серверов Map-Server, строго соответствующих [RFC9301], и механизмов аутентификации, предоставляемых LISP-SEC [RFC9303], снижает риск атак на целостность сопоставлений. В более критических средах могут потребоваться меры защиты. Реализация защиты для данной системы сопоставления сильно зависит от архитектуры этой системы и модели угроз, предполагаемой для развёртывания. Поэтому безопасность системы сопоставления должна рассматриваться в соответствующих документах по архитектуре Mapping System.

Как и в других механизмах туннелирования промежуточные устройства на пути между ITR (или PITR) и ETR (или PETR) должны иметь механизмы снятия инкапсуляции для корректной проверки содержимого пакетов с инкапсуляцией LISP.

Как и другие механизчы инкапсуляции и сопоставления (map-and-encap), LISP разрешает «трехстороннюю» маршрутизацию (т. е. поток пакетов проходит через разные граничные маршрутизаторы в зависимости от направления). Это означает, что у промежуточных устройств может не быть полного представления о трафике, который они инспектируют или обрабатывают. Кроме того, пакеты с инкапсуляцией LISP маршрутизируются по внешним адресам IP (RLOC) и могут быть доставлены маршрутизатору ETR, который не отвечает за EID получателя пакета, или сетевому элементу, не являющемуся ETR. Снижение риска обеспечивается применением подходящих методов фильтрации, на элементах сети, которые могут получать неожиданные пакеты с инкапсуляцией LISP.

Дополнительные сведения о влиянии LISP на безопасность приведены в [RFC7835].

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

Этот документ не требует действий IANA.

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

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

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC2992] Hopps, C., «Analysis of an Equal-Cost Multi-Path Algorithm», RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.

[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, «Network Mobility (NEMO) Basic Support Protocol», RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., «Report from the IAB Workshop on Routing and Addressing», RFC 4984, DOI 10.17487/RFC4984, September 2007, <https://www.rfc-editor.org/info/rfc4984>.

[RFC5944] Perkins, C., Ed., «IP Mobility Support for IPv4, Revised», RFC 5944, DOI 10.17487/RFC5944, November 2010, <https://www.rfc-editor.org/info/rfc5944>.

[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, «Mobility Support in IPv6», RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.

[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, «The Locator/ID Separation Protocol (LISP) for Multicast Environments», RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, «Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites», RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.

[RFC6835] Farinacci, D. and D. Meyer, «The Locator/ID Separation Protocol Internet Groper (LIG)», RFC 6835, DOI 10.17487/RFC6835, January 2013, <https://www.rfc-editor.org/info/rfc6835>.

[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, «Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)», RFC 6836, DOI 10.17487/RFC6836, January 2013, <https://www.rfc-editor.org/info/rfc6836>.

[RFC6837] Lear, E., «NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database», RFC 6837, DOI 10.17487/RFC6837, January 2013, <https://www.rfc-editor.org/info/rfc6837>.

[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, «IPv6 and UDP Checksums for Tunneled Packets», RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.

[RFC6936] Fairhurst, G. and M. Westerlund, «Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums», RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.

[RFC7052] Schudel, G., Jain, A., and V. Moreno, «Locator/ID Separation Protocol (LISP) MIB», RFC 7052, DOI 10.17487/RFC7052, October 2013, <https://www.rfc-editor.org/info/rfc7052>.

[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, «Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations», RFC 7215, DOI 10.17487/RFC7215, April 2014, <https://www.rfc-editor.org/info/rfc7215>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, «Locator/ID Separation Protocol (LISP) Threat Analysis», RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, «LISP Canonical Address Format (LCAF)», RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.

[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, «Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)», RFC 8111, DOI 10.17487/RFC8111, May 2017, <https://www.rfc-editor.org/info/rfc8111>.

[RFC8378] Moreno, V. and D. Farinacci, «Signal-Free Locator/ID Separation Protocol (LISP) Multicast», RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>.

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., «The Locator/ID Separation Protocol (LISP)», RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., «Locator/ID Separation Protocol (LISP) Control Plane», RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, «Locator/ID Separation Protocol (LISP) Map-Versioning», RFC 9302, DOI 10.17487/RFC9302, October 2022, <https://www.rfc-editor.org/info/rfc9302>.

[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, «Locator/ID Separation Protocol Security (LISP-SEC)», RFC 9303, DOI 10.17487/RFC9303, October 2022, <https://www.rfc-editor.org/info/rfc9303>.

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

[Jakab] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, «LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System», IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343, DOI 10.1109/JSAC.2010.101011, October 2010, <https://ieeexplore.ieee.org/document/5586446>.

[LISP-EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, «EID Mappings Multicast Across Cooperating Systems for LISP», Work in Progress, Internet-Draft, draft-curran-lisp-emacs-00, 9 November 2007, <https://www.ietf.org/archive/id/draft-curran-lisp-emacs-00.txt>.

[LISP-SHDHT] Cheng, L. and M. Sun, «LISP Single-Hop DHT Mapping Overlay», Work in Progress, Internet-Draft, draft-cheng-lisp-shdht-04, 15 July 2013, <https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt>.

[Mathy] Mathy, L. and L. Iannone, «LISP-DHT: Towards a DHT to map identifiers onto locators», CoNEXT ’08: Proceedings of the 2008 ACM CoNEXT Conference, ReArch ’08 — Re-Architecting the Internet, DOI 10.1145/1544012.1544073, December 2008, <https://dl.acm.org/doi/10.1145/1544012.1544073>.

[Quoitin] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, «Evaluating the Benefits of the Locator/Identifier Separation», Proceedings of 2nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture, DOI 10.1145/1366919.1366926, August 2007, <https://dl.acm.org/doi/10.1145/1366919.1366926>.

Приложение A. История разделения идентификаторов и локаторов

Архитектура LISP для разделения местоположения и отождествления стала результатом дискуссий во время семинара IAB Routing and Addressing в Амстердаме в октябре 2006 г. [RFC4984].

Сразу после семинара спонтанно сформировалась небольшая группа единомышленников для работы над идеей, возникшей в неформальных дискуссиях на семинаре в различных почтовых конференциях. Первый документ Internet-Draft для LISP появился в январе 2007 г.

В это время начались пробные реализации, а первые пробные развёртывания состоялись в июне 2007 г. Результаты этих экспериментов учитывались при проектировании, занявшем несколько лет. На данный момент LISP представляет собой умеренно зрелую систему, прошедшую длинную цепочку изменений и обновлений.

Протокол LISP перешёл из сферы IRTF в рабочую группу IETF в марте 2009 г. После многочисленных исправления базовые спецификации в начале 2013 г. были выпущены как RFC. Работа по расширению, совершенствованию и поиску новых применений продолжается (и несомненно будет длиться ещё долго). Рабочая группа LISP была в 2018 г. преобразована для продолжения работы над базовым протоколом LISP и создания документов Standards Track.

A.1. Старые модели LISP

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

LISP 1

Все EID появляются в обычных таблицах маршрутизации и пересылки в сети (т. е. являются «маршрутизируемыми»). Это свойство применяется для получения сопоставлений EID с RLOC в процессе начальной загрузки (bootstrapping). Пакеты передаются с EID в качестве адресата во внешнем заголовке и когда ETR видит такой пакет, он передаёт Map-Reply маршрутизатору ITR источника, давая полное сопоставление.

LISP 1.5

LISP 1.5 похож на LISP 1, но маршрутизация EID происходит в отдельной сети.

LISP 2

EID не маршрутизируются, сопоставления EID с RLOC доступны через DNS.

LISP 3

EID не маршрутизируются и их нужно искать в новой базе данных о сопоставлениях EID с RLOC (изачально это была система, использующая распределенные хэш-таблицы). Были возможны два варианта — push-системы, где все отображения распространялись всем ITR, и pull-системы, в которых ITR загружали сопоставления при необходимости.

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

Этот документ инициировал Noel Chiappa и большая часть идей представлена им. Авторы признательны за его важный вклад в работу и благодарны ему.

Спасибо также Dino Farinacci, Fabio Maino, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black.

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

Albert Cabellos
Universitat Politecnica de Catalunya
c/ Jordi Girona s/n
08034 Barcelona
Spain
Email: acabello@ac.upc.edu
 
Damien Saucez (editor)
Inria
2004 route des Lucioles — BP 93
Sophia Antipolis
France
Email: damien.saucez@inria.fr

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3Virtual Routing and Forwarding — виртуальная маршрутизация и пересылка.

Рубрика: RFC | Оставить комментарий

RFC 9318 IAB Workshop Report: Measuring Network Quality for End-Users

Internet Architecture Board (IAB)                            W. Hardaker
Request for Comments: 9318                                              
Category: Informational                                       O. Shapira
ISSN: 2070-1721                                             October 2022

IAB Workshop Report: Measuring Network Quality for End-Users

Отчёт семинара IAB по измерению качества сети для конечных пользователей

PDF

Аннотация

Семинар Measuring Network Quality for End-Users был проведён IAB в виртуальном формате 14-16 сентября 2021 г. В этом документе приведены итоги семинара, рассмотренные вопросы и некоторые предварительные выводы, принятые в конце семинара.

Документ является отчётом о работе семинара. Приведённые здесь взгляды и позиции принадлежат участникам семинара и могут не отражать позиции IAB.

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы Совета по архитектуре Internet (Internet Architecture Board или IAB) и содержит сведения, которые IAB считает нужным сохранить. Документ представляет согласованный взгляд IAB. Документ был одобрен для публикации IAB и не является кандидатом в Internet Standard, см раздел 2 RFC 7841.

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

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

Авторские права (Copyright (c) 2022) принадлежат 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).

Оглавление

Исключено в версии HTML.

1. Введение

IAB время от времени организует семинары по рассмотрению долгосрочной стратегии и проблем Internet, а также по определению направления развития архитектуры Internet. Такое долгосрочное планирования IAB дополняет текущую инженерную работу IETF1.

Семинар по измерению качества сети для конечных пользователей (Measuring Network Quality for End-Users) [WORKSHOP] проводился в виртуальном режиме 14-16 сентября 2021 г. В этом отчёте приведены итоги семинара, обсуждавшиеся темы и некоторые предварительные выводы, сделанные в конце семинара.

1.1. Пространство проблем

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

В то же время некоторые аспекты взаимодействия с конечными пользователями не обрели существенного улучшения. Многие пользователи сталкиваются с задержками соединений на уровне 10-летней давности. Несмотря на значительное повышение надёжности в средах центров обработки данных (ЦОД), конечные пользователи часто сталкиваются с перебоями в обслуживании. Несмотря на алгоритмические улучшения в теории управления, по-прежнему обнаруживается, что задержки в очередях оборудования последней мили превышают совокупные транзитные задержки. Улучшения в транспорте, такие как QUIC, Multipath TCP, TCP Fast Open, в некоторых сетях ещё поддерживаются не полностью. Точно так же не получили широкого распространения усовершенствования в сфере безопасности и приватности конечных пользователей, такие как шифрование DNS для локальных распознавателей.

Одним из основных факторов отсутствия прогресса является распространённое мнение о том, что пропускная способность часто является единственным показателем качества соединений Internet. С учётом этого семинар Measuring Network Quality for End-Users был нацелен на обсуждение указанных ниже тем.

  • Какова задержка для пользователей в типичных условиях работы?

  • Насколько надёжна связь в долгосрочной перспективе?

  • Позволяют ли сети использовать широкий спектр протоколов?

  • Какие службы могут запускать клиенты сети?

  • Какие типы соединения IPv4, NAT, IPv6 предлагаются, применяются ли межсетевые экраны?

  • Какие механизмы защиты доступны для локальных служб, таких как DNS?

  • В какой степени обеспечивается приватность, конфиденциальность, целостность и подлинность пользовательских коммуникаций?

Улучшение этих аспектов качества сети вероятно будет зависеть от измерения и осмысленного представления показателей всем заинтересованным сторонам, включая конечных пользователей. Такие измерения и предоставление правильных показателей позволят поставщикам услуг и операторам сетей сосредоточиться на опыте своих пользователей и одновременно даст пользователям возможность выбрать провайдера (Internet Service Provider или ISP) в соответствии со своими потребностями.

  • Каковы фундаментальные свойства сети, способствующие качественному взаимодействию с пользователем?

  • Какие показатели количественно определяют эти свойства и как их собрать на практике?

  • Каковы наилучшие методы интерпретации этих показателей и их включения в процесс принятия решений?

  • Как лучше всего передать эти свойства поставщикам услуг и операторам сетей?

  • Как эти показатели представить пользователям осмысленным способом?

2. Программа семинара

Семинар Measuring Network Quality for End-Users был разделен по нескольким темам (см. разделы 4 и 5):

  • вводные обзоры и доклад Vint Cerf;

  • показатели;

  • межуровневые вопросы;

  • объединительная часть;

  • выводы.

3. Представленные документы

Ниже указаны документы, представленные участникам семинара. На странице семинара [WORKSHOP] содержится архив статей, презентаций и видеозаписей.

  • Ahmed Aldabbagh. «Regulatory perspective on measuring network quality for end users» [Aldabbagh2021].

  • Al Morton. «Dream-Pipe or Pipe-Dream: What Do Users Want (and how can we assure it)?» [Morton2021].

  • Alexander Kozlov. «The 2021 National Internet Segment Reliability Research».

  • Anna Brunstrom. «Measuring network quality — the MONROE experience».

  • Bob Briscoe, Greg White, Vidhi Goel, and Koen De Schepper. «A Single Common Metric to Characterize Varying Packet Delay» [Briscoe2021].

  • Brandon Schlinker. «Internet Performance from Facebook’s Edge» [Schlinker2019].

  • Christoph Paasch, Kristen McIntyre, Randall Meyer, Stuart Cheshire, and Omer Shapira. «An end-user approach to the Internet Score» [McIntyre2021].

  • Christoph Paasch, Randall Meyer, Stuart Cheshire, and Omer Shapira. «Responsiveness under Working Conditions» [Paasch2021].

  • Dave Reed and Levi Perigo. «Measuring ISP Performance in Broadband America: A Study of Latency Under Load» [Reed2021].

  • Eve M. Schooler and Rick Taylor. «Non-traditional Network Metrics».

  • Gino Dion. «Focusing on latency, not throughput, to provide better internet experience and network quality» [Dion2021].

  • Gregory Mirsky, Xiao Min, Gyan Mishra, and Liuyan Han. «The error performance metric in a packet-switched network» [Mirsky2021].

  • Jana Iyengar. «The Internet Exists In Its Use» [Iyengar2021].

  • Jari Arkko and Mirja Kuehlewind. «Observability is needed to improve network quality» [Arkko2021].

  • Joachim Fabini. «Network Quality from an End User Perspective» [Fabini2021].

  • Jonathan Foulkes. «Metrics helpful in assessing Internet Quality» [Foulkes2021].

  • Kalevi Kilkki and Benajamin Finley. «In Search of Lost QoS» [Kilkki2021].

  • Karthik Sundaresan, Greg White, and Steve Glennon. «Latency Measurement: What is latency and how do we measure it?»

  • Keith Winstein. «Five Observations on Measuring Network Quality for Users of Real-Time Media Applications».

  • Ken Kerpez, Jinous Shafiei, John Cioffi, Pete Chow, and Djamel Bousaber. «Wi-Fi and Broadband Data» [Kerpez2021]

  • Kenjiro Cho. «Access Network Quality as Fitness for Purpose».

  • Koen De Schepper, Olivier Tilmans, and Gino Dion. «Challenges and opportunities of hardware support for Low Queuing Latency without Packet Loss» [DeSchepper2021].

  • Kyle MacMillian and Nick Feamster. «Beyond Speed Test: Measuring Latency Under Load Across Different Speed Tiers» [MacMillian2021].

  • Lucas Pardue and Sreeni Tellakula. «Lower-layer performance not indicative of upper-layer success» [Pardue2021].

  • Matt Mathis. «Preliminary Longitudinal Study of Internet Responsiveness» [Mathis2021].

  • Michael Welzl. «A Case for Long-Term Statistics» [Welzl2021].

  • Mikhail Liubogoshchev. «Cross-layer Cooperation for Better Network Service» [Liubogoshchev2021].

  • Mingrui Zhang, Vidhi Goel, and Lisong Xu. «User-Perceived Latency to Measure CCAs» [Zhang2021].

  • Neil Davies and Peter Thompson. «Measuring Network Impact on Application Outcomes Using Quality Attenuation» [Davies2021].

  • Olivier Bonaventure and Francois Michel. «Packet delivery time as a tie-breaker for assessing Wi-Fi access points» [Michel2021].

  • Pedro Casas. «10 Years of Internet-QoE Measurements. Video, Cloud, Conferencing, Web and Apps. What do we Need from the Network Side?» [Casas2021].

  • Praveen Balasubramanian. «Transport Layer Statistics for Network Quality» [Balasubramanian2021].

  • Rajat Ghai. «Using TCP Connect Latency for measuring CX and Network Optimization» [Ghai2021].

  • Robin Marx and Joris Herbots. «Merge Those Metrics: Towards Holistic (Protocol) Logging» [Marx2021].

  • Sandor Laki, Szilveszter Nadas, Balazs Varga, and Luis M. Contreras. «Incentive-Based Traffic Management and QoS Measurements» [Laki2021].

  • Satadal Sengupta, Hyojoon Kim, and Jennifer Rexford. «Fine-Grained RTT Monitoring Inside the Network» [Sengupta2021].

  • Stuart Cheshire. «The Internet is a Shared Network» [Cheshire2021].

  • Toerless Eckert and Alex Clemm. «network-quality-eckert-clemm-00.4».

  • Vijay Sivaraman, Sharat Madanapalli, and Himal Kumar. «Measuring Network Experience Meaningfully, Accurately, and Scalably» [Sivaraman2021].

  • Yaakov (J) Stein. «The Futility of QoS» [Stein2021].

4. Темы и дискуссии семинара

Программа трехдневного семинара была разбита на 4 части, каждая из которых сыграла свою роль в организации дискуссий. Семинар начался с вводных презентаций и представления пространства проблем (4.1. Введение и обзор), затем обсуждались показатели (4.2. Показатели), межуровневые вопросы (4.3. Межуровневые вопросы) и была проведена общая дискуссия (4.4. Объединительная часть). По завершении этих разделов было проведено обсуждение и сделаны выводы, принятые участниками семинара (5. Выводы).

4.1. Введение и обзор

Семинар начался с широкого обсуждения качества обслуживания (Quality of Service или QoS) и работы (Quality of Experience или QoE) пользователей в современной сети Internet. Цель вводных бесед состояла в подготовке участников семинара к описанию пространства проблем, имеющихся решений и их ограничений.

В презентациях были показаны имеющиеся измерения QoS и QoE, а также их эффективность. Обсуждалось взаимодействие между пользователями в сети, а также между разными уровнями стека протоколов OSI. Vint Cerf выступил с основным докладом, посвященным истории и важности темы.

4.1.1. Основные моменты из доклада Vint Cerf

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

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

Рассмотрим упражнение для определения желаемых свойств. Когда мы рассматриваем пространства параметров, можно отделить «желаемые» свойства от «фундаментальных», например, малую задержку. Примером от Агентства исследовательских проектов (Advanced Research Projects Agency или ARPA) служит желание знать, где находится ракета сейчас, а не где она была. Понимание управляет созданием и выбором конкретных параметров в пространстве проектирования.

Когда значения параметров, таких как связность, сильно меняются, появляются новые решения. Одним из примечательных примеров является межпланетный протокол, где ping бельше не даёт чего-либо полезного. При рассмотрении чувствительности (responsiveness) не следует игнорировать связность.

К сожалению, совместимость с имеющимися решениями болезненна. Работа по проектированию IPv6 для перехода с IPv4 могла бы пройти лучше, если бы не требовалась совместимость с имеющимся протоколом. Для IPv6 уже слишком поздно, но ещё можно учесть этот аспект при решении возможных в будущем проблем.

IPv6 ещё не везде реализован достаточно полно. С момента начала работы в 1996 г. пройден длинный путь, но цель ещё не достигнута. В 1996 г. казалось, что внедрить IPv6 достаточно просто, но практика показала иное. В 1996 г. начался бум dot-com, когда быстро тратились большие деньги и момент не был уловлен вовремя, а рынок расширялся экспоненциально. Это следует считать предостережением.

Ещё одно замечание относится к производительности пересылки через множество этапов (hop) в Internet. Не видно сквозных показателей для её оценки, поскольку довольно сложно измерить производительность сквозь разные сети и бизнес-границы. При разработке новых протоколов следует задавать вопрос о возможности работы протокола через множество узлов пересылки.

Сети с множеством пересылок (multi-hop) постепенно заменяются огромными плоскими сетями с достаточной связностью между операторами, где системы разделяет 1 или 2 этапа пересылки (hop), например, Google, Facebook, Amazon. Фундаментальная архитектура Internet меняется.

4.1.2. Вступительное обсуждение

Internet является общей (shared) сетью на основе протоколов IP, использующей коммутацию пакетов для соединения множества автономных сетей. Отход Internet от технологии соммутации каналов (circuit-switching) позволил выйти за пределы любого другого устройства сети. С другой стороны, отсутствие внутрисетевого регулирования осложняет обеспечение наилучшей работы для каждого пользователя.

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

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

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

Ориентация отрасли на предоставление конечному пользователю большей пропускной способности (полосы) привела к значительным достижениям. Во многих местах по всему миру домашним пользователям ISP предоставляют гигабитную скорость. 10 лет назад такое сочли бы фантастикой. Однако рост пропускной способности был достигнут за счёт пренебрежения другим важным фактором — задержкой. В результате конечным пользователям, на работу которых значительная задержка оказывает негативное влияние, рекомендуют заменить своё оборудование на новое, которое вместо этого даёт большую пропускную способность. В [MacMillian2021] показано, что такое обновление может снизить задержку из-за коммерческих причин перевести клиента на использование более дорогих тарифных планов.

Поскольку в отрасли продолжается предоставление конечным пользователям большей пропускной способности без учёта факторов задержки, при разработке приложений начали применять методы сокрытия задержек и краткосрочных прерываний обслуживания. Например, производительность пользовательских web-браузеров тесно связана с содержимым локального кэша браузера. Хотя применяемые методы могут улучшить взаимодействие с пользователем при возможности использования лежалых (кэшированных) данных, это ещё сильнее отдаляет пользователя от фактических показателей.

За последние 10 лет усилия Dave Taht и сообщества раздувания буферов (bufferbloat) привели к существенному обновлению алгоритмов очередей для снижения задержки под нагрузкой по сравнению с простыми очередями FIFO. К сожалению, производители домашних маршрутизаторов ещё не реализовали эти алгоритмы в основном из соображений маркетинга и стоимости. Большинство производителей домашних маршрутизаторов зависят от успорителей SoC (System on a Chip) для создания продукции с желаемой пропускной способностью. Производители SoC выбирают простейшие алгоритмы и настойчивое (aggressive) агрегирование, считая, что микросхема с более высокой пропускной способностью будет иметь гарантированный спрос. Поскольку потребителям в основном предлагается выбор из высокоскоростных устройств, допущение о том, что рост пропускной способности повышает QoS, продолжает укрепляться.

Домашние маршрутизаторы — не единственное место, где можно получить преимущества от более чёткого указания приемлемой для пользователей производительности. Поскольку пользователи воспринимают Internet через «призму» приложений, важно призвать производителей приложений принять решения с меньшими задержками. К сожалению, скорость отклика измерить сложнее, чем пропускную способность. Многие приложения нашли наборы показателей, которые полезны для них, но не обобщены достаточно и не могут стать универсально применимыми. Кроме того, из-за высокой конкуренции в сфере приложений у производителей могут быть экономические причины не делиться своими полезными показателями.

4.1.3. Ключевые точки

  1. Измерение пропускной способности необходимо, но само по себе недостаточно.

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

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

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

  5. Рынок содержимого Internet отличается высокой конкуренцией и многие приложения разрабатывают свой «секретный соус».

4.2. Показатели

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

4.2.1. Базовые показатели производительности

Полная потеря доступа в Internet, несомненно, является худшим случаем для пользователя. К сожалению, если перезагрузка домашнего маршрутизатора не приведёт к восстановлению связности, пользователь мало что может сделать, кроме обращения к своему поставщику услуг. Тем не менее систематический сбор показателей доступности на стороне клиента полезен и может помочь ISP пользователя в поиске и устранении проблемы, позволяя пользователю выбрать лучшего ISP. Доступность можно оценить напрямую, просто пытаясь соединиться со сторны клиента с интересующими удалёнными местами. Например, Ookla [Speedtest] использует большое число устройств Android для измерения доступности сети и сотовой сязи по всему миру. Ookla собирает данные сотен миллионов точек в день и использует их для точной оценки доступности. Другой подход состоит в выводе доступности по частоте отказов и другим тестам. Например, в [FCC_MBA] and [FCC_MBA_methodology] используются тысячи маршрутизаторов с измерительными программами, разработанными [SamKnows]. Эти маршрутизаторы выполняют множество сетевых тестов и сообщают о доступности на основе успешности тестовых соединений.

Измерение полосы (capacity) может быть полезно для конечных пользователей, но оно ещё важнее для сервис-провайдеров и разработчиков приложений. Видеопотоки с высоким разрешением требуют существенно большей полосы, чем иные типы трафика. На момент проведения семинара видеопотоки составляли 90% всего трафика Internet и приносили 95% доходов от монетизации (подписка, сборы, реклама). В результате службы потокового видео, такие как Netflix, должны постоянно справляться с быстрым изменением доступной полосы. Способность измерения доступной полосы в реальном масштабе времени усиливается за счёт алгоритмов адаптивного сжатия (adaptive bitrate или ABR) для обеспечения наилучшего взаимодействия с пользователями. Измерение совокупной потребности в полосе позволяет ISP быть готовыми к скачкам трафика. Например, в новогодние каникулы глобальный спрос на полосу возрастает в 5-7 раз по отношению к иному времени. Для конечных пользователей знание потребности в полосе может помочь при выборе тарифного плана с учётом предполагаемого использования. Однако во многих случаях у конечных пользователей имеется избыток полосы и повышение пропускной способности не нужно для них. Способность отличать пропускную способность от полезной пропускной способности (goodput) может быть полезна для определения перегрузки в сети.

При измерении качества сети задержка определяется временем прохождения пакета по сетевому пути от одного конца до другого. На момент написания отчёта пользователи во многих местах по миру имели доступ в Internet с достаточной пропускной способностью и доступностью. Для этих пользователей снижение задержки вместо повышения пропускной способности может вести к значительному росту QoE. Показателем задержки является время кругового обхода (round-trip time или RTT), обычно измеряемое в миллисекундах. Однако пользователи часто считают RTT неудобным показателем в отличие от других показателей производительности, поскольку высокое значение RTT указывает большую задержку, а пользователи обычно считают большие значения лучшими. Для решения этой проблемы в [Paasch2021] и [Mathis2021] предложен обратный показатель — число RTT в минуту (Round-trips Per Minute или RPM).

Важно различать задержку при бездействии (idle latency) и задержку в рабочих условиях. Первая измеряется при слабой загрузке сети и отражает наилучший вариант. Вторая измеряется при типичной загрузке сети. До недавнего времени типовые инструменты указывали загрузку при бездействии, что могло вводить в заблуждение. Например, данные, представленные на семинаре, показали, что при бездействии задержка модет быть в 25 раз ниже, чем при типичной загрузке сети. Поэтому важно чётко различать представление этих значений задержки пользователю.

Измерения показывают, что быстрое изменение пропускной способности влияет на задержку. В [Foulkes2021] предпринята попытка количественной оценки частоты возникновения «нестабильности» сети (высокой задержки при очень низкой пропускной способности) при быстром изменении пропускной способности. Такие изменения могут быть вызваны отказами в инфраструктуре, но гораздо чаще связаны с событиями внутри сети, такими как изменение правил организации трафика или быстрые изменения перекрестного трафика (cross-traffic).

Представленные на семинаре данные показывают, что у 36% измеренных линий показатель пропускной способности меняется больше чем на 10% в течение для и нескольких дней. Эти различия связаны с многими переменными, включая локальные методы подключения (Wi-Fi и Ethernet), конкурирующий трафик ЛВС, загрузки и конфигурация устройства, время суток, пропускная способность локального соединения или транспорта. Эти изменения факторов осложняют измерение пропускной способности с использованием лишь устройства конечного пользователя или иного устройства оконечной сети. Маршрутизатор сети, просматривающий агрегированный трафик от нескольких устройств, обеспечивает лучшую точку измерения пропускной способности. Такой тест может учитывать весь локальный трафик и выполнить независимое тестирование пропускной способности. Однако различные факторы все равно могут ограничивать точность такого теста. Для аккуратного измерения пропускной способности нужно множество выборок.

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

Полезно отличать приложения, работающие с «фиксированным бюджетом задержки», от приложений, устойчивых к вариациям задержки. Облако игр служит примером приложения, которому нужен «фиксированный бюджет задержки», овых серверов, поскольку всплеск задержки может определять решение «выигрыш-проигрыш» для игрока. Компании, конкурирующие на прибыльном рынке облачных игр, вкладывают значительные средства в инфраструктуру, такие как создание ЦОД ближе к пользователям. Эти ЦОД подчёркивают экономическую выгоду от снижения числа всплесков задержки, превышающую связанные с этим расходы на развёртывание. С другой стороны, более стойкие к всплескам задержки приложения могут продолжать нормальную работу даже при коротких всплесках. Тем не менее, даже такие приложения могут выиграть от неизменно низкой задержки при изменении загрузки. Например, приложения «видео по запросу» (Video-on-Demand или VOD) могут достаточно хорошо работать при линейном потреблении видеопотока, но при переключении пользователем канала или прокуртке вперёд у пользователя могут возникнуть проблемы, если задержка недостаточно мала.

По мере развития приложений все большее значение приобретают их внутренние показатели. Например, приложения VOD могут оценивать QoE по зависимым от приложения показателям, таким как способность видеопроигрывателя использовать максимально возможное разрешение, определять плавность или «замораживание» изображения и т. п. Разработчики приложений могут эффективно применять эти показатели для определения приоритета будущих работ. Все популярные видео-платформы (YouTube, Instagram, Netflix и пр.) имеют схемы сбора и анализа показателей VOD. Одним из примеров является модель Scuba, применяемая в Meta [Scuba].

К сожалению внутренние показатели приложений могут быть слишком сложными для сравнительных исследований. Во-первых, разные приложения часто используют различные показатели для измерения одних и тех же явлений. Например, приложение A может измерять гладкость видео по среднему времени повторной буферизации, а приложение B может полагаться на вероятность повторной буферизации в течение 1 секунды для тех же целей. Другая проблема с внутренними показателями приложений состоит в том, что VOD является важным источником прибыли для YouTube, Facebook, Netflix, что создаёт препятствия обмену внутренними данными. Ещё одна проблема связана с вопросами приватности, связанными с внутреннеми показателями приложений, которые точно описывают действия и предпочтения конкретных пользователей.

4.2.2. Показатели применимости

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

4.2.3. Показатели пропускной способности

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

Фактическая пропускная способность сетевого соединения определяется оборудованием и линиями на пути через сеть и меняется в течение дня или нескольких дней. Исследования с линиями DSL в Северной Америке показывают, что более 30% этих линий имеют показатели пропускной способности меняющиеся более чем на 10% в течение для или нескольких дней.

Ниже указаны некоторые факторы, влияющие на фактическую пропускную способность.

  1. Наличие конкурирующего тарфика в ЛВС или средах WAN. В ЛВС конкурирующий трафик образует несколько устройств, использующих одно соединение с Internet. В WAN конкурирующий трафик часто возникает из несвязанных сетевых потоков, использующих общий путь через сеть.

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

  3. Активные средства управления трафиком, такие как формователи и ограничители трафика, зачастую применяемые провайдерами.

Имеются и другие факторы, негативно влияющие на фактическую пропускную способность линий.

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

4.2.4. Показатели задержки

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

  1. Задержка распространения, отражающая протяжённость пути и технологии отдельных каналов (например, оптические или спутниковые). Распространение не зависит от загрузки сети, пока путь не меняется.

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

  3. Задержки транспортных протоколов, отражающие время, затраченное на повтор передачи и сборку, а также время, когда транспорт был заблокирован (head-of-line blocked).

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

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

Если измерения проводятся при типичной загрузке сети, результат отражает несколько частей задержки. В отчёте такая задержка называется рабочей (working latency). В других документах применяется термин «задержка под нагрузкой» (latency under load или LUL).

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

Таблица 1.

Направление

Технология

Задержка при работе

Задержка при простое

Разность задержек

Отношение работа/простой

Нисходящее

FTTH

148

10

138

15

Нисходящее

Cable

103

13

90

8

Нисходящее

DSL

194

10

184

19

Восходящее

FTTH

207

12

195

17

Восходящее

Cable

176

27

149

6

Восходящее

DSL

686

27

659

25

Хотя исторически средства измерения задержки были сосредоточены на задержках при бездействии, в отрасли наблюдается тенденция к измерению рабочей задержки (например, в Apple [NetworkQuality]).

4.2.5. Примеры измерений

Участники семинара передложили несколько конкретных методик измерения качества сети для конечных пользователей.

В [Paasch2021] представлена методика измерения рабочей задержки с точки зрения конечного пользователя. Предложенный метод постепенно добавляет сетевые потоки между пользовательским устройством и сервером, пока не возникнет «пробка» (bottleneck). Из этих измерений выводится время кругового обхода, сообщаемое конечному пользователю. Авторы решили выдавать результаты с метрикой RPM. Метод реализован в Apple macOS Monterey.

В [Mathis2021] пременена метрика RPM к результатам более 4 миллиардов тестов загрузки, которые были выполнены M-Lab в 2010-2021 гг. За это время измерительная платформа Mпретерпела несколько обновлений, что позволило команде исследователей сравнить влияние различных механизмов контроля перегрузок TCP (congestion control algorithm или CCA) на измерение сквозной задержки. Исследование показало, что применение кубического CCA ведёт к росту рабочей задержки, связанному с использованием очередей большего размера.

В [Schlinker2019] представлено масштабное исследование с попыткой сопоставить полезную пропускную способность (goodput) и QoE в большой социальной сети. Авторы проводили измерения в нескольких ЦОД из которых передавались сегменты видео заданного размера потоками большому числу конечных пользователей. Авторы применяли показатели полезной и общей пропускной способности для обнаружения перегрузки отдельных путей.

В [Reed2021] представлен анализ измерений рабочей задержки собранных по программе Measuring Broadband America (MBA) Федеральной комиссии по связи (Federal Communication Commission или FCC). FCC не включает рабочую задержку в свои годовые отчёты, но предоставляет её в файлах необработанных данных. Авторы использовали часть необработанных данных для определения важных различий между рабочими задержками у разных ISP.

В [MacMillian2021] представлен анализ измерений рабочей задержки на нескольких уровнях обслуживания. Обнаружено (неудивительно), что пользователи уровня premium сталкиваются с меньшей рабочей задержкой по сравнению с уровнем value. Данные показывают, что рабочая задержка существенно меняется на каждом уровне, одним из возможных объяснений является установка в домах разного оборудования.

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

Ещё одной причиной высоких рабочих задержек являются сетевые маршрутизаторы с перекрестным трафиком. Как показано в [Schlinker2019], они могут насышаться в пиковое время суток. Систематическое тестирование рабочей задержки в нагруженных маршрутизаторах может улучшить понимание задержек и влияния на них развернутой инфраструктуры.

4.2.6. Ключевые точки показателей

Показатели качества сети можно грубо разбить на 4 группы.

  1. Показатели доступности, указывающие возможность доступа пользователя в сеть.

  2. Показатели пропускной способности, указывающие, достаточно ли фактической пропускной способности для удовлетворения потребностей пользователя.

  3. Показатели задержки, указывающие, может ли пользователь получить данные своевременно.

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

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

В презентациях и дискуссиях было указано несколько ключевых точек.

  1. Доступность и пропускная способность являются «гигиеническими» факторами — пока приложение не способно использовать дополнительную пропускную способность, конечные пользователи не увидят преимуществ от применения линий с избыточной скоростью.

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

  3. Метрика RPM является стабильной, большие значения говорят о лучшем качестве и метрика более понятна конечномк пользователю.

  4. Связь между общей и полезной пропускной способностью может быть полезна при поиске точек насыщения не стороне клиента [Paasch2021] и сервера [Schlinker2019].

  5. Рабочая задержка зависит от выбора алгоритмов контроля перегрузок для целевой конечной точки и очередей в маршрутизаторах.

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

4.3. Межуровневые вопросы

В межуровневой части семинара были представлены материалы и прощли дискуссии о точно обнаружении проблемных мест. Обсуждение сосредоточилось на различиях между кабельными и беспроводными соединениями и сложности точного определения проблемных мест в случаях, когда качество зависит от множества разнотипных сегментов сети. Например, в [Kerpez2021] показано, что Wi-Fi 2,4 ГГц с ограниченной пропускной способностью чаще всего создаёт «пробки». С Wi-Fi на частоте 5 ГГц связано лишь 20% наблюдавшихся пробок.

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

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

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

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

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

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

  • Формату обмена данных следует предотвращать манипуляции с данными, чтобы участники обмена не могли обмануть механизмы.

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

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

  • Сопутствующий набор инструментов для анализа данных.

4.3.1. Разделение ответственности

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

  • у субъектов, способных собирать определённые показатели производительности (например, TCP RTT) может не быть контекста, требуемого для осмысленной интерпретации;

  • у субъектов, имеющих контекст и возможности расчётов и хранения для интерпретации показателей, может не быть возможности управлять поведением сети и/или приложений;

  • у контролирующих поведение сетей и/или приложений субъектов может не быть доступа ко всем измеренным данным.

Участники семинара согласились с тем, что важно разделить 3 указанных аспекта, чтобы:

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

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

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

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

4.3.3. Вопросы измерения показателей

  • Указанные ниже показатели протокола TCP сочтены эффективными и доступными для пассивных измерений.

    • Задержка соединения TCP, измеряемая по времени SACK или ACK, а также время между повторными передачами TCP служат хорошими показателями для сквозных измерений RTT.

    • На платформах Linux структура tcp_info является фактическим стандартом для приложений, позволяющим проверить производительность сети в пространстве ядра. Однако в пользовательском пространстве эквивалентного фактического стандарта нет.

  • Протоколы QUIC и MASQUE усложняют пассивные измерения производительности.

    • Для этих протоколов может оказаться более подходящим подход с федеративными измерениями и иерархическим агрегированием.

    • Формат QLOG представляется наиболее подходящим для такого обмена.

4.3.4. Пути улучшения межуровневой наблюдаемости

Владение Internet распределено между множеством административных доменов, что затрудняет получение данных о сквозной производительности. Кроме того, огромный масштаб Internet осложняет их объединение и анализ. В [Marx2021] представлен простой формат ведения журнала, который можно применять для сбора и агрегирования данных от различных уровней.

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

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

4.3.5. Взаимодействие оборудования с транспортными протоколами

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

На момент проведения семинара типичные домашние маршрутизаторы использовали одну очередь FIFO достаточно большого размера для амортизации издержек, связанных с заголовками нижних уровней в различных транспортных PDU. Это хорошо работало с кубическим алгоритмом контроля перегрузок, однако новые алгоритмы способны работать с гораздо меньшими очередями. Чтобы обеспечить задержки меньше 1 мсек, домашний маршрутизатор должен эффективно работать при последовательной передаче всего нескольких сегментов, а не быть оптимизированным для длительных пиков пакетов. Ещё одной конструктивной особенностью домашних маршрутизаторов является агрегирование пакетов для дополнительной амортизации издержек, связанных с заголовками нижних уровней. В частности, несколько дейтаграмм IP объединяются в один большой кадр передачи. Однако такое агрегирование может добавлять к задержке пакетов в устройстве до 10 мсек.

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

4.3.6. Ключевые точки межуровневых измерений

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

  • Выявление проблемных мест затруднено из-за измерений не множестве сегментов пути.

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

  • Для практических результатов требуется подобающий сбор и интерпретация данных.

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

  • Одновременное обеспечение точных измерений и сохранение приватности пользователей затруднего.

  • Пассивные измерения в реализациях протоколов могут предоставить полезные данные.

4.4. Объединительная часть

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

4.4.1. Вопросы измерений и показателей

Важным является вопрос принятия решений и выполнения действий на основе собранных показателей. Измерения нужно объединять с приложениями для того, чтобы те корректно видели перегрузки, поскольку измерения в иной инфраструктуре или через другие приложения могут давать неверные результаты. Перегрузка может быть временной проблемой и стратегия смягчения может меняться в зависимости от её продолжительности. Для краткосрочных перегрузок возникает проблема необходимости постоянных измерений для учёта критических моментов и продолжительных тенденций. Для таких перегрузов участники семинара обсудили вопрос, является ли исчезновение перегрузки проблемой или служит признаком приспособления и самовосстановления.

При определении показателей важно учитывать факторы, влияющие на результат. Это могут быть характеристики отдельных пакетов — для пакетов разного размера задержка обычно зависит от размера линейно. С учтом этого можно выделить задержки из-за протяжённости (географическое разделение), пакетизации и иных переменных факторов (шум). Каждая из этих долей задержки может различаться и измеряться отдельно в каждом сегменте многоэтапного пути. На переменную задержку могут существенно влиять внешние факторы, такие как буферизация, изменение маршрута, распределение нагрузки в сети и другие локальные или удалённые изменения производительности. Сетевые измерения, особенно тесты под нагрузкой, должны быть достаточно продолжительными, чтобы учесть все проблемы, связанные с буферизацией, очередями и т. п. Технологиям измерений следует различать восходящее (от пользователя) и нисходящее направление, а также результаты сквозных и сегментированных измерений.

4.4.2. Представление показателей конечного пользователя

Для определения потребностей конечных пользователей нужны информативные показатели и измерения. Как предоставить пользователю услуги, которые ему нужны? Могут ли пользователи эффективно выразить свои потребности? Пользователи обычно дают лишь простые ответы верхнего уровня, такие как надёжность, пропускная способность, комплексные услуги. Технические требования, понятные оператору, такие как малая задержка или предотвращение перегрузок, непонятны и не применяются конечными пользователями.

Примеры полезных для конечного пользователя показателей включают число поддерживаемых клиентов и приложений или потоков. Примером решения для борьбы с сетевыми проблемами является стратегия управления трафиком на основе стимулов (например, запрос приложением меньшей задержки может восприниматься как готовность принять меньшую пропускную способность). Нужно учитывать воспринимаемую пользователем задержку, а не только задержку в сети — взаимодействие с приложением, задержка на сервере и в сети могут учитывать лишь задержки нижнего уровня. Выбор правильного протокола для измерений очень важен для соответствия пользовательскому опыту (например, пользователь не передаёт данных по протоколу ICMP, хотя это один из важных инструментов измерения).

Измерениям в приложениях следует учитывать тип приложения, например, видеопотоки, обмен файлами, групповая игра или голосовая связь. Возможно, было бы полезно спросить пользователя, на какие компромиссы он готов пойти — например, нужна ему малая задержка или большая пропускная способность? Для игры могут потребоваться иные решения, чем для домашнего офиса или распространения содержимого. Как пользователи могут принять компромисс, не мешая другим пользователям: Имеется противоречие между решением этих проблем и готовностью клиентов к затратам на будущее улучшение.

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

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

4.4.3. Ключевые точки объединения

  • Некоторые предложенные показатели:

    • число круговых обходов в минуту (Round-trips Per Minute или RPM);

    • число пользователей на сеть;

    • задержка;

    • 99% задержки и пропускная способность.

  • Измерения медианного и среднего значения отвлекают от реальных проблем.

  • Сеть с общим доступом существенно влияет на качество.

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

  • Для успешных исследований требуется лучшее финансирование.

  • Конечные пользователи лучше поймут упрощённую систему оценки или ранжирования.

5. Выводы

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

5.1. Общие заявления

  1. Пропускная способность (полоса) необходима, но не достаточна.

  2. Во многих случаях пользователям Internet нужно не больше полосы, а лучшая пропускная способность, т. е. требуются иные улучшения связности.

  3. Нужны активные и пассивные измерения, пассивные могут обеспечить «историческую отладку».

  4. Пассивные измерения (включая надёжность и связность) должны быть непрерывными, архивируемыми и доступными для запроса.

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

  6. Полезные показатели для ценности (goodness) должны фактически стимулировать ценность — хорошим показателям следует быть действенными в плане совершенствования отрасли.

  7. Снижение задержки в Internet принесёт пользу всем конечным пользователям.

5.2. Конкретные заявления о протоколах и методах

  1. Число круговых обходов в минуту (RPM) является полезным и востребованным показателем.

  2. Нужны полезные инструменты, заполняющие зазоры между тестами доступности сети, задержки и скорости.

  3. Конечным пользователям, желающим участвовать в QoS, нужно дать возможность заявить свои потребности.

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

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

  6. Новые измерения и методы QoS и QoE не должны зависеть лишь от заголовков TCP.

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

5.3. Заявления о проблемах и ответственности

  1. Измерения медианного и среднего значения задержки отвлекают от более важных измерений.

  2. Разочаровывает измерение сетевых служб без одновременного роста качества обслуживания.

  3. Заинтересованные стороны не ждут лёгких побед и нужны стимулы для улучшения доступа в общественные сети. Измерения могут быть одним из шагов к созданию конкурентных рыночных стимулов.

  4. Для перспективных сетей важно учитывать влияние на экологию применяемых материалов и энергии.

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

5.4. Утверждения, по которым не достигнуто согласия

Рассмотрены и записаны утверждения, по которым не было выработано единого мнения.

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

  2. Измерения должны поддерживать локализацию отчётов для нахождения проблем.

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

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

  1. Заинтересованные стороны не настроены на лёгкие победы в этом направлении.

6. Последующая работа

На семинаре обсуждались вопросы будущей работы. Предложено часть работ продолжать в имеющихся рабочих группах IETF (например, IPPM, DetNet, RAW), а длительные исследования могут потребовать создания групп IRTF.

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

Этот документ не требует действий IANA.

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

На семинаре обсуждалось несколько связанных с безопасностью тем, включая:

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

  • как сети с превышением трафика (oversubscribed) могут казаться находящимися под DDoS-атакой.

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

[Aldabbagh2021] Aldabbagh, A., «Regulatory perspective on measuring network quality for end-users», September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/2021-09-07-Aldabbagh-Ofcom-presentationt-to-IAB-1v00-1.pdf>.

[Arkko2021] Arkko, J. and M. Kühlewind, «Observability is needed to improve network quality», August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/iab-position-paper-observability.pdf>.

[Balasubramanian2021] Balasubramanian, P., «Transport Layer Statistics for Network Quality», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/transportstatsquality.pdf>.

[Briscoe2021] Briscoe, B., White, G., Goel, V., and K. De Schepper, «A Single Common Metric to Characterize Varying Packet Delay», September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/single-delay-metric-1.pdf>.

[Casas2021] Casas, P., «10 Years of Internet-QoE Measurements Video, Cloud, Conferencing, Web and Apps. What do we need from the Network Side?», August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/net_quality_internet_qoe_CASAS.pdf>.

[Cheshire2021] Cheshire, S., «The Internet is a Shared Network», August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/draft-cheshire-internet-is-shared-00b.pdf>.

[Davies2021] Davies, N. and P. Thompson, «Measuring Network Impact on Application Outcomes Using Quality Attenuation», September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/PNSol-et-al-Submission-to-Measuring-Network-Quality-for-End-Users-1.pdf>.

[DeSchepper2021] De Schepper, K., Tilmans, O., and G. Dion, «Challenges and opportunities of hardware support for Low Queuing Latency without Packet Loss», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Nokia-IAB-Measuring-Network-Quality-Low-Latency-measurement-workshop-20210802.pdf>.

[Dion2021] Dion, G., De Schepper, K., and O. Tilmans, «Focusing on latency, not throughput, to provide a better internet experience and network quality», August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Nokia-IAB-Measuring-Network-Quality-Improving-and-focusing-on-latency-.pdf>.

[Fabini2021] Fabini, J., «Network Quality from an End User Perspective», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Fabini-IAB-NetworkQuality.txt>.

[FCC_MBA] FCC, «Measuring Broadband America», <https://www.fcc.gov/general/measuring-broadband-america>.

[FCC_MBA_methodology] FCC, «Measuring Broadband America — Open Methodology», <https://www.fcc.gov/general/measuring-broadband-america-open-methodology>.

[Foulkes2021] Foulkes, J., «Metrics helpful in assessing Internet Quality», September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/IAB_Metrics_helpful_in_assessing_Internet_Quality.pdf>.

[Ghai2021] Ghai, R., «Using TCP Connect Latency for measuring CX and Network Optimization», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/xfinity-wifi-ietf-iab-v2-1.pdf>.

[Iyengar2021] Iyengar, J., «The Internet Exists In Its Use», August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/The-Internet-Exists-In-Its-Use.pdf>.

[Kerpez2021] Shafiei, J., Kerpez, K., Cioffi, J., Chow, P., and D. Bousaber, «Wi-Fi and Broadband Data», September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Wi-Fi-Report-ASSIA.pdf>.

[Kilkki2021] Kilkki, K. and B. Finley, «In Search of Lost QoS», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Kilkki-In-Search-of-Lost-QoS.pdf>.

[Laki2021] Nadas, S., Varga, B., Contreras, L.M., and S. Laki, «Incentive-Based Traffic Management and QoS Measurements», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/11/CamRdy-IAB_user_meas_WS_Nadas_et_al_IncentiveBasedTMwQoS.pdf>.

[Liubogoshchev2021] Liubogoshchev, M., «Cross-layer Cooperation for Better Network Service», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Cross-layer-Cooperation-for-Better-Network-Service-2.pdf>.

[MacMillian2021] MacMillian, K. and N. Feamster, «Beyond Speed Test: Measuring Latency Under Load Across Different Speed Tiers», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/2021_nqw_lul.pdf>.

[Marx2021] Marx, R. and J. Herbots, «Merge Those Metrics: Towards Holistic (Protocol) Logging», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/MergeThoseMetrics_Marx_Jul2021.pdf>.

[Mathis2021] Mathis, M., «Preliminary Longitudinal Study of Internet Responsiveness», August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Preliminary-Longitudinal-Study-of-Internet-Responsiveness-1.pdf>.

[McIntyre2021] Paasch, C., McIntyre, K., Shapira, O., Meyer, R., and S. Cheshire, «An end-user approach to an Internet Score», September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Internet-Score-2.pdf>.

[Michel2021] Michel, F. and O. Bonaventure, «Packet delivery time as a tie-breaker for assessing Wi-Fi access points», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/camera_ready_Packet_delivery_time_as_a_tie_breaker_for_assessing_Wi_Fi_access_points.pdf>.

[Mirsky2021] Mirsky, G., Min, X., Mishra, G., and L. Han, «The error performance metric in a packet-switched network», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/IAB-worshop-Error-performance-measurement-in-packet-switched-networks.pdf>.

[Morton2021] Morton, A. C., «Dream-Pipe or Pipe-Dream: What Do Users Want (and how can we assure it)?», Work in Progress, Internet-Draft, draft-morton-ippm-pipe-dream-01, 6 September 2021, <https://datatracker.ietf.org/doc/html/draft-morton-ippm-pipe-dream-01>.

[NetworkQuality] Apple, «Network Quality», <https://support.apple.com/en-gb/HT212313>.

[Paasch2021] Paasch, C., Meyer, R., Cheshire, S., and O. Shapira, «Responsiveness under Working Conditions», Work in Progress, Internet-Draft, draft-cpaasch-ippm-responsiveness-01, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01>.

[Pardue2021] Pardue, L. and S. Tellakula, «Lower-layer performance is not indicative of upper-layer success», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Lower-layer-performance-is-not-indicative-of-upper-layer-success-20210906-00-1.pdf>.

[Reed2021] Reed, D.P. and L. Perigo, «Measuring ISP Performance in Broadband America: A Study of Latency Under Load», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Camera_Ready_-Measuring-ISP-Performance-in-Broadband-America.pdf>.

[SamKnows] «SamKnows», <https://www.samknows.com/>.

[Schlinker2019] Schlinker, B., Cunha, I., Chiu, Y., Sundaresan, S., and E. Katz-Basset, «Internet Performance from Facebook’s Edge», February 2019, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Internet-Performance-from-Facebooks-Edge.pdf>.

[Scuba] Abraham, L. et al., «Scuba: Diving into Data at Facebook», <https://research.facebook.com/publications/scuba-diving-into-data-at-facebook/>.

[Sengupta2021] Sengupta, S., Kim, H., and J. Rexford, «Fine-Grained RTT Monitoring Inside the Network», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/Camera_Ready__Fine-Grained_RTT_Monitoring_Inside_the_Network.pdf>.

[Sivaraman2021] Sivaraman, V., Madanapalli, S., and H. Kumar, «Measuring Network Experience Meaningfully, Accurately, and Scalably», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/CanopusPositionPaperCameraReady.pdf>.

[Speedtest] Ookla, «Speedtest», <https://www.speedtest.net>.

[Stein2021] Stein, Y., «The Futility of QoS», August 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/QoS-futility.pdf>.

[Welzl2021] Welzl, M., «A Case for Long-Term Statistics», February 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/iab-longtermstats_cameraready.docx-1.pdf>.

[WORKSHOP] IAB, «IAB Workshop: Measuring Network Quality for End- Users, 2021», September 2021, <https://www.iab.org/activities/workshops/network-quality>.

[Zhang2021] Zhang, M., Goel, V., and L. Xu, «User-Perceived Latency to Measure CCAs», September 2021, <https://www.iab.org/wp-content/IAB-uploads/2021/09/User_Perceived_Latency-1.pdf>.

Приложение A. Программный комитет

Jari Arkko
Olivier Bonaventure
Vint Cerf
Stuart Cheshire
Sam Crowford
Nick Feamster
Jim Gettys
Toke Hoiland-Jorgensen
Geoff Huston
Cullen Jennings
Katarzyna Kosek-Szott
Mirja Kühlewind
Jason Livingood
Matt Mathis
Randall Meyer
Kathleen Nichols
Christoph Paasch
Tommy Pauly
Greg White
Keith Winstein

Приложение B. Руководители семинара

Wes Hardaker
Evgeny Khorov
Omer Shapira

Приложение C. Участники семинара

Ahmed Aldabbagh
Jari Arkko
Praveen Balasubramanian
Olivier Bonaventure
Djamel Bousaber
Bob Briscoe
Rich Brown
Anna Brunstrom
Pedro Casas
Vint Cerf
Stuart Cheshire
Kenjiro Cho
Steve Christianson
John Cioffi
Alexander Clemm
Luis M. Contreras
Sam Crawford
Neil Davies
Gino Dion
Toerless Eckert
Lars Eggert
Joachim Fabini
Gorry Fairhurst
Nick Feamster
Mat Ford
Jonathan Foulkes
Jim Gettys
Rajat Ghai
Vidhi Goel
Wes Hardaker
Joris Herbots
Geoff Huston
Toke Høiland-Jørgensen
Jana Iyengar
Cullen Jennings
Ken Kerpez
Evgeny Khorov
Kalevi Kilkki
Joon Kim
Zhenbin Li
Mikhail Liubogoshchev
Jason Livingood
Kyle MacMillan
Sharat Madanapalli
Vesna Manojlovic
Robin Marx
Matt Mathis
Jared Mauch
Kristen McIntyre
Randall Meyer
François Michel
Greg Mirsky
Cindy Morgan
Al Morton
Szilveszter Nadas
Kathleen Nichols
Lai Yi Ohlsen
Christoph Paasch
Lucas Pardue
Tommy Pauly
Levi Perigo
David Reed
Alvaro Retana
Roberto
Koen De Schepper
David Schinazi
Brandon Schlinker
Eve Schooler
Satadal Sengupta
Jinous Shafiei
Shapelez
Omer Shapira
Dan Siemon
Vijay Sivaraman
Karthik Sundaresan
Dave Taht
Rick Taylor
Bjørn Ivar Teigen
Nicolas Tessares
Peter Thompson
Balazs Varga
Bren Tully Walsh
Michael Welzl
Greg White
Russ White
Keith Winstein
Lisong Xu
Jiankang Yao
Gavin Young
Mingrui Zhang

Члены IAB на момент принятия документа для публикации

Jari Arkko
Deborah Brungard
Lars Eggert
Wes Hardaker
Cullen Jennings
Mallory Knodel
Mirja Kühlewind
Zhenbin Li
Tommy Pauly
David Schinazi
Russ White
Qin Wu
Jiankang Yao

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

Авторы признательны участникам семинара, членам IAB и программному комитету за интересные дискуссии.

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

Спасибо участникам работы над этим документом:

Erik Auerswald
Simon Leinen
Brian Trammell

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

Wes Hardaker
Email: ietf@hardakers.net
Omer Shapira
Email: omer_shapira@apple.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

Рубрика: RFC, Измерения и тестирование | Оставить комментарий

RFC 9308 Applicability of the QUIC Transport Protocol

Internet Engineering Task Force (IETF)                      M. Kühlewind
Request for Comments: 9308                                      Ericsson
Category: Informational                                      B. Trammell
ISSN: 2070-1721                                  Google Switzerland GmbH
                                                          September 2022

Applicability of the QUIC Transport Protocol

Применимость транспортного протокола QUIC

PDF

Аннотация

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

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы являются кандидатами в Internet Standard, см раздел 2 RFC 7841.

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

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

Авторские права (Copyright (c) 2022) принадлежат 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).

Оглавление

Исключено в версии HTML.

1. Введение

Новый транспортный протокол QUIC [QUIC] обеспечивает ряд расширенных функций. Хотя протокол разрабатывался для HTTP, он предоставляет возможности для более широкого круга приложений. QUIC инкапсулируется в UDP. QUIC версии 1 интегрирован с TLS 1.3 [TLS13] для шифрования всего содержимого и большей части данных управления. Версию HTTP, использующую QUIC, называют HTTP/3 [QUIC-HTTP].

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

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

2. Необходимость отката

QUIC использует UDP в качестве основы. Это позволяет реализацию в пользовательском пространстве и обеспечивает прохождение промежуточных устройств (включая NAT) без обновления имеющейся инфраструктуры.

Измерения показывают, что от 3% [Trammell16] до 5% [Swett16] сетей блокируют весь трафик UDP, при этом мало свидетельств других форм систематических недостатков UDP по сравнению с TCP [Edeline16]. Блокировка подразумевает, что все приложения, работающие на основе QUIC, должны быть готовы к отказу в соединениях через такие сети или разработаны с возможностью отката к другому транспортному протоколу. В случае HTTP таким откатом является использование TLS на основе TCP.

Спецификация транспортных служб IETF (Transport Services или TAPS) [TAPS-ARCH] описывает систему с общим API для разных протоколов. Это особенно актуально для QUIC, поскольку решает проблему отката с использованием нескольких протоколов.

В частности, нужно избегать отката к незащищённым протоколам или слабым версиям протоколов с защитой. В общем случае приложениям, реализующим откат, необходимо учитывать влияние тката на безопасность. Откат к TCP и TLS раскрывает управляющую информацию для изменения и манипуляций в сети. Кроме того, откат к TLS версии ниже 1.3, которая применяется в QUIC версии 1, может вести к существенному ослаблению криптографической защиты. Например, результаты согласования протокола [RFC7301] имеют защиту конфиденциальности лишь при использовании TLS 1.3.

Эти приложения должны работать, возможно, с нарушением функциональности при отсутствии обеспечиваемых QUIC функций в резервном (fallback) протоколе. При откате к TLS через TCP наиболее очевидным отличием является отсутствие в TCP мультиплексирования потоков, требующее реализации такого мультиплексирования на уровне приложения. Кроме того, реализации TCP и сетевые пути зачастую не поддерживают опцию TCP Fast Open (TFO) [RFC7413], позволяющую передавать содержимое в первом пакете управления для новых соединений, тогда как возобновление сессий 0-RTT в QUIC позволяет это. Отметим, что имеются свидетельства блокировки данных в SYN даже при успешном согласовании TFO (см. [PaaschNanog]). И даже при сквозной работе Fast Open опция ограничена одним пакетом согласования TLS и данных приложения, в отличие от QUIC 0-RTT.

Хотя шифрование (в данном случае TLS) неразрывно связано с QUIC, согласование TLS через TCP может быть заблокировано. Если TLS через TCP не может поддерживаться, соединение следует прерывать, а затем приложение должно подобающим способом уведомить пользователя о недоступности защищённых коммуникаций.

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

3. 0-RTT

QUIC поддерживает организацию соединений 0-RTT. Хотя такая же возможность обеспечивается в TLS 1.3 с TCP, с механизмом 0-RTT связаны свои возможности и проблемы для приложений, использующих QUIC.

Транспортный протокол, обеспечивающий организацию соединений 0-RTT, качественно отличается от протоколов без 0-RTT с точки зрения использующих протокол приложений. Стоимость закрытия соединения с последующим повторным открытием и попытки сохранить соединение открытым различаются (см. параграф 3.2. Восстановление сессий по сравнению с Keep-Alive).

Приложению нужно сознательно выбирать применение 0-RTT, поскольку с этим механизмом связан риск replay-атак. Для использующих 0-RTT прикладных протоколов требуется профиль, описывающий типы информации, которую можно передавать без опаски. Для HTTP этот профиль описан в [HTTP-REPLAY].

3.1. Replay-атаки

Повторная передача или злонамеренное воспроизведение данных из пакетов 0-RTT может приводить к получению серверной стороной множества копий одних и тех же данных.

Данные приложения, переданные в пакетах 0-RTT, могут обрабатываться неоднократно при их повторном использовании (replay). Приложения должны понимать, что можно безопасно передавать в 0-RTT. Прикладные протоколы, стремящиеся применять 0-RTT, должны тщательно анализировать и описывать возможное содержимое пакетов 0-RTT (см. параграф 5.6 в [QUIC-TLS]).

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

Когда сервер воспринял данные 0-RTT, уже нет способа выборочно отбросить полученные данные. Однако протоколы могут определять способы отклонения определённых действий, которые могут быть небезопасны при повторе.

Некоторые реализации и развёртывания TLS могут обеспечивать частичную и даже полную защиту от replay-атак, которая может служить для контроля рисков.

3.2. Восстановление сессий по сравнению с Keep-Alive

Поскольку QUIC инкапсулируется в UDP, использующие QUIC приложения должны иметь дело с короткими тайм-аутами бездействия сети. Развёрнутые промежуточные устройства с поддержкой состояния обычно создают состояние для потока UDP по первому переданному пакету и сохраняют его в течение периода бездействия значительно более короткого, чем для TCP. В [RFC5382] предложен период бездействия для TCP не менее 124 минуту, хотя в литературе не упоминается о широком применении этого правила. Однако короткий период ожидания для UDP чётко документирован. Согласно исследованию 2010 г. ([Hatonen10]), приложения UDP могут предполагать, что любая привязка NAT или иное состояние могут истекать после 30 секунд бездействия. В параграфе 3.5 [RFC8085] рассмотрены интервалы keep-alive для UDP и требуется минимальное значение 15 секунд с рекомендацией использовать более долгие интервалы или совсем отказаться от keep-alive.

За счёт применения идентификаторов соединений протокол QUIC более устойчив к сменам привязки NAT по тайм-ауту. Однако это помогает лишь в тех случаях, когда конечная точка сохраняет доступность по адресу, известному её партнёру и этот партнёр передаёт данные после тайм-аута.

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

Приложения QUIC могут настраивать период бездействия для контроля риска тайм-аутов. Периоды бездействия и тайм-аут простоя в сети отличаются от тайм-аута бездействия соединения, который определяется меньшим значением тайм-аута бездействия конечных точек (см. параграф 10.1 в [QUIC]). Здесь возможны три варианта.

  • Игнорирование проблемы, если протокол прикладного уровня включает взаимодействия с очень коротким интервалом бездействия или совсем без него или протокол достаточно устойчив к смене привязки NAT.

  • Предотвращение продолжительных интервалов бездействия.

  • Восстановление сессии после долгого бездействия с применением 0-RTT, когда это уместно.

Первый вариант проще всего, но подходит лишь для определённых приложений.

Сервер или клиент в приложении QUIC могут передавать кадры PING для сохранения активности (keep-alive) соединения и состояний на пути от возникновения тайм-аута. Рекомендации по использованию keep-alive зависят от приложения в основном из-за требований к задержке и частоте сообщений. В этом случае прикладное отображение должно указывать, кто отвечает за сохранение соединения — клиент или сервер. Хотя [Hatonen10] предполагается, что 30 секунд будет достаточно для общедоступной сети Internet при наличии в пути NAT, предпочтительней большие значения, если развёртывание может выдерживать смену привязки NAT или известно, что оно размещается в контролируемой среде (например, ЦОД), для снижения загрузки сети и расчётных издержек.

Передача кадров PING с интервалом менее 30 секунд в периоды бездействия может в некоторых случаях приводить к избыточному непродуктивному трафику и неприемлемому расходу батарей в (мобильных) устройствах. Кроме того, тайм-ауты меньше 30 секунд могут затруднять обработку временных перебоев в сети, таких как перенос виртуальных машин (Virtual Machine или VM) или потеря связи в результате перемещения (см. [RFC8085], особенно параграф 3.5).

Клиент (но не сервер) может также использовать восстановление сессий вместо передачи трафика keep-alive. В этом случае клиент, желающий передать серверу данные через соединение, которое бездействовало дольше тайм-аута сервера (доступен через транспортный параметр idle_timeout), может просто подключиться заново. По возможности для этого можно применять восстановление 0-RTT, снижающее задержку, связанную с повторной организацией. Этот подход применим лишь в тех случаях, когда можно безопасно использовать 0-RTT и перезапуск выполняет клиент.

Компромисс между возобновлением и keep-alive следует выбирать отдельно для каждого приложения. В общем случае приложениям следует применять keep-alive лишь в ситуациях, когда непрерывность коммуникаций очень важна, например, [QUIC-HTTP] рекомендует использовать keep-alive только при наличии находящихся в обработке запросов.

4. Использование потоков

Функция мультиплексирования потоков QUIC позволяет приложениям использовать несколько потоков в одном соединении без возникновения конфликтов (блокировка head-of-line) между ними. Данные потоков передаются в кадрах и один пакет QUIC в линии может включать один или несколько кадров потоков.

Потоки могут быть односторонними или двухсторонними и инициировать их может как клиент, так и сервер. В одностороннем потоке данные может передавать лишь его инициатор.

Потоки и соединения могут передать не более 262-1 байтов в каждом направлении из-за ограничений кодирования смещений в потоке и управления потоком данных в соединении. В маловероятном на сегодняшний день случае достижения предела потребуется организовать новое соединение.

Потоки можно открывать и закрывать независимо, аккуратно или жёстко. Приложение может аккуратно закрыть исходящее направление, указав QUIC установку бита FIN в кадре STREAM. Входящее направление нельзя аккуратно закрыть без созданного партнёром FIN (как в TCP). Однако конечная точка может жёстко закрыть исходящее направление или запросить у партнёра жёсткое закрытие входящего направления, эти действия не зависят одно от другого.

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

Отображение данных приложения в потоки зависит от приложения и для HTTP/3 описано в [QUIC-HTTP]. Имеется несколько базовых принципов разработки приложений, использующих потоки.

  • В рамках потока обеспечивается упорядочение. Если приложению нужно передать данные в определённом порядке, их следует направлять в один поток. Порядок передачи, приёма и доставки в разных потоках не гарантируется.

  • Несколько потоков обеспечивают распараллеливание. Данные могут обрабатываться независимо и может возникать блокировка head-of-line (пробка), если принудительно упорядочивать их приём данных, отправленных в разных потоках.

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

Если получатель QUIC открыл максимально разрешённое число одновременных потоков, а отправитель говорит, что нужны ещё потоки, это не ведёт к автоматическому увеличению максимального числа потоков у получателя. Поэтому приложениям следует учитывать максимальное число разрешённых, открытых в данный момент и используемых в данный момент потоков при задании сопоставления данных с потоками.

QUIC выделяет числовой идентификатор (stream ID) для каждого потока. Хотя взаимосвязь между этими идентификаторами и типами потоков чётко задана в QUIC версии 1, будущие спецификации могут поменять её для других версий. Реализациям QUIC следует раскрывать свойства каждого потока (инициатор, число направлений, идентификатор), а приложениям следует запрашивать эти свойства, не пытаясь вывести их из идентификатора потока.

Метод назначения идентификаторов созданным приложением потокам может зависеть от реализации транспорта, поэтому приложениям не следует предполагать, что потоку, который ещё не создан, будет назначен определённый идентификатор. Например, HTTP/3 использует идентификаторы потоков для указания уже созданных потоков и не принимает допущений относительно будущих идентификаторов и способов их назначения (раздел 6 в [QUIC-HTTP]).

4.1. Мультиплексирование потоков

Потоки имеют смысл только для приложений, поскольку информация о потоке передаётся внутри границы шифрования QUIC и пакет не раскрывает сведений о передаваемых в нем потоках. Следовательно, мультиплексирование потоков не предназначено для их дифференцирования с точки зрения обработки в сети. Поэтому трафик приложений, требующий различной обработки в сети, следует передавать с разными квинтетами (5-tuple), т. е. через разные соединения QUIC. С учётом способности QUIC передавать данные приложения в первом RTT соединения (если предыдущее соединение с тем же хостом было организовано для предоставления требуемых свидетельств), стоимость организации нового соединения очень мала.

4.2. Приоритизация

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

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

4.3. Упорядоченная и надёжная доставка

Потоки QUIC обеспечивают упорядоченную и надёжную доставку. Хотя реализация может предоставлять опции использования потоков без полной гарантии или сохранения порядка, большинство реализаций предполагает надёжную доставку с сохранением порядка.

В соответствии с этим допущением конечная точка, получающая данные потока, может не продвигаться вперёд, пока не станут доступными данные, смежные с началом потока. В частности, получатель может приостановить поток данных, пока приложению не будут доставлены непрерывные данные (см. параграф 2.2 в [QUIC]). Для поддержки такой логики приёма конечная точка будет отправлять данные потока, пока они не будут подтверждены, чтобы данные из начала потока были переданы и подтверждены первыми.

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

4.4. Блокировка управления потоком данных

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

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

Размер и частота обновлений кредита управления потоком данных могут влиять на производительность. Использующие QUIC приложения часто имеют потребителя данных, читающего данные из транспортных буферов. У некоторых реализаций могут быть независимые буферы приёма на транспортном и прикладном уровне. Потребление данных не всегда подразумевает их незамедлительную обработку, однако общим методом реализации служит расширение кредита управления потоком данных для отправителя путём отправки кадров MAX_DATA и/или MAX_STREAM_DATA по мере потребления данных. На доставку этих кадров влияет задержка в канале передачи от получателя к отправителю данных. Если кредит своевременно не расширяется, передающее приложение может быть заблокировано, фактически останавливая передачу.

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

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

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

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

Некоторые случаи блокировки можно преодолеть путём отмены затрагиваемых потоков с помощью STOP_SENDING или RESET_STREAM. Отмена некоторых потоков в некоторых протоколах может приводить к обрыву соединения.

4.5. Обязательства по ограничению числа потоков

Конечные точки QUIC отвечают за передачу совокупного предела числа потоков, которые они позволяют открыть партнёру. Исходные ограничения анонсируются в транспортных параметрах initial_max_streams_bidi и initial_max_streams_uni. По мере открытия и закрытия потоков они потребляются и совокупное значение инкрементируется. Пределы можно увеличить с помощью кадров MAX_STREAMS, но механизмов снижения нет. По достижении предельного числа потоков, дополнительные потоки создать невозможно и использующее QUIC приложение не сможет двигаться дальше. В этом случае соединения могут быть прерваны по тайм-ауту или явным закрытием, как описано в разделе 10 10.

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

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

Вместо предотвращения грубого закрытия на основе ограничения числа потоков может применяться механизм аккуратного закрытия на прикладном уровне, чтобы сообщить о намерении закрыть соединение в некоторый будущий момент. В HTTP/3 для этого применяется кадр GOAWAY, при получении которого клиент прекращает создание новых потоков, даже до достижения порога. Вместо этого клиент создаёт новое соединение, в котором будут открываться последующие потоки. Как только все потоки старого соединения будут закрыты, его можно безопасно прервать сразу или по тайм-ауту бездействия (см. 10. Завершение соединений).

5. Пакетизация и задержка

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

По умолчанию многие реализации пытаются упаковать кадры STREAM одного или нескольких потоков в каждый пакет QUIC для минимизации расхода пропускной способности и вычислительных издержек (см. раздел 13 в [QUIC]). Если для заполнения пакета недостаточно данных, реализация может подождать в течение короткого времени для оптимизации пропускной способности за счёт задержки. Эта задержка может настраиваться или устанавливаться динамически на основе наблюдаемой картины передачи данных приложением.

Если приложению нужна малая задержка и передача лишь мелких блоков данных (chunk), может оказаться полезным задать протоколу QUIC незамедлительную передачу всех данных. Если предположение предполагает использовать определённую картину передачи, оно может задать для QUIC время ожидания при сборке кадров в пакет.

Точно так же, приложение обычно не может контролировать размер пакетов QUIC в линии. QUIC предоставляет возможность добавлять кадры PADDING для произвольного увеличения размера пакетов. Заполнение применяется в QUIC для того, чтобы передавать дейтаграммы не меньше согласованного размера (см. параграфы 8.1 и 14.1 в [QUIC]) и проверять путь после переноса соединения (см. параграф 8.2 в [QUIC]), а также для определения PMTU (Datagram Packetization Layer PMTU Discovery или DPLPMTUD, см. параграф 14.3 в [QUIC]).

Заполнение может применяться приложением для сокращения утечки сведений о передаваемых им данных. Реализация QUIC может предоставлять прикладному уровню интерфейс для контроля применением заполнения.

6. Обработка ошибок

QUIC рекомендует конечным точкам информировать партнёра обо всех обнаруженных ошибках. Ошибки могут возникать на транспортном и прикладном уровне. Транспортные ошибки, такие как нарушение протокола, влияют на соединение в целом. Использующее QUIC приложение может определять свои средства обнаружения и сигнализации для ошибок (см., например, раздел 8 в [QUIC-HTTP]). Ошибки приложения влияют на соединение или отдельный поток.

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

Применяющие QUIC приложения определяют своё пространство кодов, независимое от QUIC и других приложений (см., например, параграф 8.1 в [QUIC-HTTP]). Значения кодов ошибок приложения могут совпадать с кодами ошибок на уровне соединения или потока.

Ошибки соединения ведут к его прерыванию. Они передаются с помощью кадров CONNECTION_CLOSE, содержащих поля кода и причины ошибки (может иметь размер 0). Для сигналов о транспортных и прикладных ошибках применяются разные типы кадров CONNECTION_CLOSE.

Ошибки потока ведут к прерыванию потока. Они передаются с помощью кадров STOP_SENDING или RESET_STREAM, содержащих лишь код ошибки.

7. Эффективность подтверждений

В QUIC версии 1 без расширений применяется стратегия подтверждений TCP (см. параграф 13.2 в [QUIC]), т. е. рекомендуется подтверждать каждый второй пакет. Однако для создания и обработки подтверждений QUIC расходуются ресурсы отправителя и получателя. С подтверждениями также связаны расходы на пересылку и расход пропускной способности каналов, что может влиять на производительность в некоторых типах сетей. Приложения могут повысить общую производительность, применяя иную стратегию с меньшей частотой подтверждений. В [QUIC-ACK-FREQUENCY] описано расширение для сигнализации желаемой задержки подтверждений и обсуждаются варианты его применения, а также влияние на контроль перегрузок и восстановление при ошибках.

8. Выбор порта и обнаружение конечных точек приложения

В общем случае номера портов служат для двух целей: «во-первых, они обеспечивают идентификаторы демультиплексирования для различения транспортных сессий между парой конечных точек, во-вторых, они могут указывать прикладной протокол и связанную службу, к которой подключены процессы» (раздел 3 в [RFC6335]). Допущение о возможности идентификации приложения в сети по номеру порта сегодня не так верно по причине инкапсуляции и механизмов динамического назначения портов, как отмечено в [RFC6335].

Поскольку QUIC является транспортным протоколом общего назначения, в нем не задаётся требований по использованию конкретного порта UDP. Для приложений с откатом к TCP, у которых ещё нет альтернативного сопоставления с UDP, обычно целесообразна регистрация (при необходимости) и использование порта UDP, соответствующего уже зарегистрированному для приложения порту TCP. Например, принятым по умолчанию для HTTP/3 [QUIC-HTTP] является порт UDP 443, аналогично HTTP/1.1 и HTTP/2 через TLS по протоколу TCP.

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

Приложения могут определять иной механизм обнаружения конечных точек, позволяющий использовать номера портов, отличные от принятых по умолчанию. Например, HTTP/3 (параграфы 3.2 и 3.3 в [QUIC-HTTP]) задаёт применение HTTP Alternative Services [RFC7838] для источника HTTP, чтобы анонсировать доступность эквивалентной конечной точки HTTP/3 на неком порту UDP путём использования h3 в качестве маркера согласования протокола прикладного уровня (Application-Layer Protocol Negotiation или ALPN) [RFC7301].

ALPN позволяет клиенту и серверу согласовать, какой из нескольких возможных протоколов будет применяться в данном соединении. Следовательно, на одном порту UDP может поддерживаться несколько приложений, разделяемых по маркерам ALPN. Применяющие QUIC приложения должны регистрировать маркер ALPN, используемый в согласовании TLS.

Поскольку QUIC версии 1 не определяет полностью механизм согласования, HTTP/3 требует QUIC версии 1 и определяет маркер ALPN (h3) для применения лишь с этой версией. До сих пор не выбрано единого подхода для управления использованием разных версий QUIC ни в HTTP/3, ни в общем случае. Использующие QUIC прикладные протоколы должны рассматривать управление версиями протокола QUIC. Решения для этих протоколов могут основываться на выборе, сделанном другими протоколами, такими как HTTP/3.

8.1. Выбор порта источника

Некоторые протоколы UDP уязвимы для атак с отражением, где злоумышленник способен использовать сторонний трафик для атаки на службы (denial of service). Например, приведённые ниже номера портов связаны с приложениями, уязвимыми для атак с отражением (часто из-за неверной нестройки серверов).

  • 53 — DNS [RFC1034].

  • 123 — NTP [RFC5905].

  • 1900 — SSDP [SSDP].

  • 5353 — mDNS [RFC6762].

  • 11211 — memcache.

Службы могут блокировать порты источника, связанные со протоколами, уязвимыми для атак с отражением, чтобы избежать издержек на обработку большого числа пакетов. Однако такая практика оказывает негативное влияние на клиентов, не только требуя организации нового соединения, но и приводя к отказу некоторых экземпляров от применения QUIC для службы на некоторое время и откату к отличному от UDP протоколу (2. Необходимость отката).

В результате реализациям клиентов рекомендуется избегать применения портов источника, связанных с протоколами, для которых известно об уязвимости для атак с отражением. Отметим, что в соответствии с общими рекомендациями для реализации клиентов в [RFC6335], приложения будут избегать использования эфемерных портов 49152-65535. Отметим, что другие номера портов также могут применяться для отражения.

9. Перенос соединений

QUIC поддерживает перенос соединений на стороне клиента. Если меняется IP-адрес клиента, конечная точка QUIC по-прежнему связывает пакеты с имеющимся транспортным соединением по полю Destination Connection ID (11. Раскрытие информации и идентификаторы соединений) в заголовке QUIC. Это подходит для случаев, когда адрес меняется, таких как смена привязки NAT, преднамеренная смена локального интерфейса, завершение срока действия временного адреса IPv6 [RFC8981], указание сервером предпочтительного адреса (параграф 9.6 в [QUIC]).

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

Базовая спецификация QUIC версии 1 поддерживает одномоментное использование лишь одного сетевого пути, что позволяет применять варианты аварийного переключения. Требуется проверка пути, чтобы конечные точки могли предотвратить атаки с подменой адресов при смене пути. Проверка пути занимает не менее 1 RTT и при смене пути может сбрасываться контроль перегрузки. Поэтому перенос обычно влияет на производительность.

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

В QUIC версии 1 поддерживается активный перенос лишь для клиентов. Однако серверы могут указать в процессе согласования своё предпочтение переноса соединения на другой адрес после согласования. Это может служить, например, для перехода с адреса, используемого несколькими серверами, на уникальный адрес данного экземпляра. Сервер может представить адрес IPv4 и IPv6 в транспортном параметре при согласовании TLS, а клиент может выбрать один из этих двух адресов (см. параграф 9.6 в [QUIC]).

10. Завершение соединений

Соединения QUIC прерываются одним из 3 способов: неявный тайм-аут простоя, явное незамедлительное закрытие, явный сброс без учёта состояния.

QUIC не предоставляет механизма аккуратного завершения соединений, применяющее QUIC приложение может определить свой процесс аккуратного завершения (см., например, параграф 5.2 в [QUIC-HTTP]).

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

Данные приложений, передаваемые в потоках или дейтаграммах откладывают тайм-аут бездействия QUIC. Приложения со своим механизмом keep-alive будут, таким образом, сохранять соединение QUIC. Приложения без keep-alive могут использовать механизмы транспортного уровня (см. параграф 10.1.2 в [QUIC] и 3.2. Восстановление сессий по сравнению с Keep-Alive). Однако интерфейсы QUIC для управления поведением транспорта могут различаться, что влияет на отказоустойчивость.

Незамедлительное закрытие указывается кадром CONNECTION_CLOSE (см. 6. Обработка ошибок) и приводит к немедленному закрытию всех потоков, что может влиять на приложения (см. 4.5. Обязательства по ограничению числа потоков).

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

11. Раскрытие информации и идентификаторы соединений

QUIC раскрывает в сеть некоторую информацию из нешифрованной части заголовка до организации контекста шифрования или потому, что сведения предназначены для использования в сети. Для получения дополнительной информации об управляемости QUIC см. [QUIC-MANAGEABILITY]. Протокол QUIC использует длинный заголовок, раскрывающий некоторую дополнительную информацию (версия и идентификатор соединения у источника), хотя короткий заголовок раскрывает лишь идентификатор соединения у получателя. В QUIC версии 1 длинный заголовок применяется при организации соединения, а короткий — при передаче данных в имеющемся соединении.

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

Конечная точка, выбравшая идентификатор нулевого размера, будет получать пакеты с идентификатором соединения для получателя нулевого размера. Конечной точке потребуется использовать другие сведения, такие как IP-адрес и номер порта источника и получателя. Это может означать неспособность конечной точки сопоставить дейтаграммы с соединениями, если эти значения меняются, что делает невозможной для соединения смену привязки NAT или перенос на новый путь.

11.1. Создаваемый сервером идентификатор соединения

QUIC поддерживает созданные сервером идентификаторы соединений, передаваемые клиентам при организации соединения (см. параграф 7.2 в [QUIC]). Серверам за балансировщиком нагрузки может потребоваться смена идентификатора соединения в процессе согласования, кодируя отождествление сервера или сведения о пуле балансирования нагрузки, чтобы обеспечить балансировку без поддержки состояния.

Развёртывания серверов с балансировщиками нагрузки и другой инфраструктурой маршрутизации должны гарантировать, что эта инфраструктура согласованно маршрутизирует пакеты экземпляру сервера, который имеет состояние соединения даже при смене адресов, портов или идентификатора соединения. Это может потребовать координации между серверами и инфраструктурой. Одним из методов является кодирование маршрутной информации в идентификаторе соединения. Пример этого метода представлен в [QUIC-LB].

11.2. Снижение возможности привязки путём смены идентификаторов

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

Хотя достаточно надёжные схемы генерации идентификаторов соединений смягчают проблему привязки, они не обеспечивают полной защиты. Анализ сроков действия секстетов (6-tuple — адреса отправителя и получателя, а также перенесённый Connection ID) позволяет выявить связи.

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

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

11.3. Использование серверных пакетов Retry для перенаправления

QUIC поддерживает пакеты Retry, которые сервер может передавать в ответ на пакет Initial от клиента. Сервер может указать в этом пакете новый идентификатор соединения и клиент будут передавать другой пакет Initial с выбранным сервером идентификатором. Этот механизм можно использовать для перенаправления соединения на дугой сервер, например, из соображений производительности или при поэтапном обновлении серверов пула, когда они могут применять разные версии QUIC.

В этом случае предполагается, что все серверы того или иного пула координируются с балансировщиками нагрузки, пересылающими трафик по идентификаторам соединений. Сервер может указать идентификатор соединения в пакете Retry так, что балансировщик перенаправит следующий пакет Initial другому серверу того же пула. Дополнительно балансировщик может напрямую предлагать выгрузку Retry, как описано в [QUIC-RETRY].

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

12. QoS и DSCP

QUIC, как определено в [QUIC], имеет один контроллер перегрузок и обработчик восстановления. Это подразумевает, что все пакеты в соединении QUIC или, по меньшей мере, пакеты с одним квинтетом (5-tuple) {dest addr, source addr, protocol, dest port, source port}, которые имеют один код дифференцированного обслуживания (Diffserv Code Point или DSCP) [RFC2475] будут иметь близкую трактовку в сети, поскольку отклики о потерях или задержке пакетов служат вводом для контроллера перегрузок. Поэтому пакетам одного соединения следует использовать один код DSCP. В параграфе 5.1 [RFC7657] рассматривается взаимодействие Diffserv с протоколами доставки дейтаграмм [RFC7657] (в этом отношении взаимодействие с QUIC похоже на взаимодействие с SCTP).

При мультиплексировании нескольких потоков в одном соединении QUIC выбирать следует значение DSCP, связанное с наибольшим приоритетом среди мультиплексируемых потоков.

Если желательна разная трактовка в сети, например, путём указания разных DSCP, можно использовать несколько соединений QUIC с одним сервером. В общем случае рекомендуется минимизировать число соединений QUIC с одним сервером, чтобы избежать роста издержек и, более важно, конкуренции механизмов контроля перегрузки.

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

13. Согласование версии и криптографии

Версия QUIC может полностью менять поведение протокола за исключением назначения нескольких полей заголовка, объявленных инвариантными [QUIC-INVARIANTS]. Версия QUIC с большим номером не обязательно обеспечивает лучший сервис, но может просто предоставлять иной набор функций. Поэтому от приложений требуется способность выбирать используемую версию QUIC.

Новая версия может применять схему шифрования, отличную от TLS 1.3 и выше. [QUIC] задаёт требования к криптографическому согласованию, реализованному в данное время TLS 1.3 и описанному в отдельной спецификации [QUIC-TLS]. Это разделение предназначено для облегчения управления версиями с разным криптографическим согласованием.

Реестр QUIC Versions, организованный в [QUIC], позволяет выполнять предварительную регистрацию для экспериментов. Регистрация важна для предотвращения конфликтов, в том числе с экспериментальными версиями. Экспериментальные версии не следует использовать в течение длительного времени или регистрировать постоянно, чтобы минимизировать риск взятия отпечатков (fingerprinting) по номеру версии.

14. Развёртывание новых версий

QUIC версии 1 не задаёт механизма согласования версии в базовой спецификации, но [QUIC-VERSION-NEGOTIATION] предлагает расширение, обеспечивающее совместимое согласование версии.

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

Подробности приведены в разделе 5 [QUIC-VERSION-NEGOTIATION].

15. Доставка дейтаграмм по протоколу QUIC без гарантий

[RFC9221] задаёт расширение QUIC для передачи приёма дейтаграмм по протоколу QUIC без гарантий. В отличие от работы напрямую через UDP, приложениям, использующим службу дейтаграмм QUIC, не требуется реализовать свой механизм контроля перегрузок в соответствии с [RFC8085], поскольку для дейтаграмм QUIC обеспечивается контроль перегрузок.

Для дейтаграмм QUIC нет управления потоком данных, поэтому такие блоки данных могут отбрасываться при перегрузке получателя. Тогда как надёжный транспортный сервис QUIC обеспечивает на уровне потока интерфейс для упорядоченной передачи и приёма данных в нескольких потоках QUIC, служба дейтаграмм имеет интерфейс неупорядоченной доставки сообщений. При необходимости может применяться кадрирование прикладного уровня для мультиплексирования раздельных потоков дейтаграмм без гарантий в одном соединении QUIC.

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

Этот документ не требует действий IANA. Однако раздел 8 рекомендует приложениям, которые уже зарегистрировали порт TCP, но хотят задать QUIC в качестве транспорта, регистрировать порт UDP, идентичный заданному для TCP.

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

См. обсуждение вопросов безопасности в [QUIC] и [QUIC-TLS]. Соображения безопасности для базового транспортного протокола применимы и к использующим QUIC приложениям. Вопросы связывания, атак с воспроизведением (replay) и случайных значений, рассмотренные в [QUIC-TLS], следует цчитывать при развёртывании и применении QUIC.

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

Разработчикам приложений следует учитывать, что при любом откате, применяемом при невозможности использовать QUIC по причине блокировки UDP в сети, следует обеспечивать такие же свойства защиты, как в QUIC. Если это невозможно, соединению не следует позволять приложению явно выполнять откат к менее безопасному варианту (см. 2. Необходимость отката).

В [QUIC-HTTP] даны рекомендации по вопросам безопасности для HTTP. Однако такие вопросы, как кросс-протокольные атаки, анализ и заполнение трафика, перенос могут быть актуальны и для других приложений, применяющих QUIC.

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

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

[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., «QUIC: A UDP-Based Multiplexed and Secure Transport», RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[QUIC-INVARIANTS] Thomson, M., «Version-Independent Properties of QUIC», RFC 8999, DOI 10.17487/RFC8999, May 2021, <https://www.rfc-editor.org/info/rfc8999>.

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., «Using TLS to Secure QUIC», RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.

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

[Edeline16] Edeline, K., Kühlewind, M., Trammell, B., Aben, E., and B. Donnet, «Using UDP for Internet Transport Evolution», DOI 10.48550/arXiv.1612.07816, 22 December 2016, <https://arxiv.org/abs/1612.07816>.

[Hatonen10] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, «An Experimental Study of Home Gateway Characteristics», Proc. ACM IMC 2010, November 2010, <https://conferences.sigcomm.org/imc/2010/papers/p260.pdf>.

[HTTP-REPLAY] Thomson, M., Nottingham, M., and W. Tarreau, «Using Early Data in HTTP», RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.

[PaaschNanog] Paasch, C., «Network support for TCP Fast Open», NANOG 67 Presentation, 13 June 2016, <https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf>.

[QUIC-ACK-FREQUENCY] Iyengar, J. and I. Swett, «QUIC Acknowledgement Frequency», Work in Progress, Internet-Draft, draft-ietf-quic-ack-frequency-02, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency-02>.

[QUIC-HTTP] Bishop, M., Ed., «HTTP/3», RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.

[QUIC-LB] Duke, M., Banks, N., and C. Huitema, «QUIC-LB: Generating Routable QUIC Connection IDs», Work in Progress, Internet-Draft, draft-ietf-quic-load-balancers-14, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-14>.

[QUIC-MANAGEABILITY] Kühlewind, M. and B. Trammell, «Manageability of the QUIC Transport Protocol», RFC 9312, DOI 10.17487/RFC9312, September 2022, <https://www.rfc-editor.org/info/rfc9312>.

[QUIC-RETRY] Duke, M. and N. Banks, «QUIC Retry Offload», Work in Progress, Internet-Draft, draft-ietf-quic-retry-offload-00, 25 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-retry-offload-00>.

[QUIC-VERSION-NEGOTIATION] Schinazi, D. and E. Rescorla, «Compatible Version Negotiation for QUIC», Work in Progress, Internet-Draft, draft-ietf-quic-version-negotiation-10, 27 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation-10>.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, «Transport Layer Security (TLS) Session Resumption without Server-Side State», RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.

[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, «NAT Behavioral Requirements for TCP», BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.

[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>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, «Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry», BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC6762] Cheshire, S. and M. Krochmal, «Multicast DNS», RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, «Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension», RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, «TCP Fast Open», RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[RFC7657] Black, D., Ed. and P. Jones, «Differentiated Services (Diffserv) and Real-Time Communication», RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC7838] Nottingham, M., McManus, P., and J. Reschke, «HTTP Alternative Services», RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, «Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6», RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.

[RFC9218] Oku, K. and L. Pardue, «Extensible Prioritization Scheme for HTTP», RFC 9218, DOI 10.17487/RFC9218, June 2022, <https://www.rfc-editor.org/info/rfc9218>.

[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, «An Unreliable Datagram Extension to QUIC», RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/info/rfc9221>.

[SSDP] Donoho, A., Roe, B., Bodlaender, M., Gildred, J., Messer, A., Kim, Y., Fairman, B., and J. Tourzan, «UPnP Device Architecture 2.0», 17 April 2020, <https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf>.

[Swett16] Swett, I., «QUIC Deployment Experience @Google», IETF96 QUIC BoF Presentation, 20 July 2016, <https://www.ietf.org/proceedings/96/slides/slides-96-quic-3.pdf>.

[TAPS-ARCH] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and C. Perkins, «An Architecture for Transport Services», Work in Progress, Internet-Draft, draft-ietf-taps-arch-14, 27 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-14>.

[TLS13] 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>.

[Trammell16] Trammell, B. and M. Kühlewind, «Internet Path Transparency Measurements using RIPE Atlas», RIPE 72 MAT Presentation, 25 May 2016, <https://ripe72.ripe.net/wp-content/uploads/presentations/86-atlas-udpdiff.pdf>.

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

Большое спасибо рецензентам Last Call — Chris Lonvick и Ines Robles.

Эта работа частично поддерживалась в рамках гранта Еврокомиссии Horizon 2020 № 688421 Measurement and Architecture for a Middleboxed Internet (MAMI) и контракта № 15.0268 с Государственным секретариатом Швейцарии по образованию, исследованиям и инновациям. Эта поддержка не предполагает одобрения (endorsement).

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

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

Gorry Fairhurst
Ian Swett
Igor Lubashev
Lucas Pardue
Mike Bishop
Mark Nottingham
Martin Duke
Martin Thomson
Sean Turner
Tommy Pauly

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

Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
 
Brian Trammell
Google Switzerland GmbH
Gustav-Gull-Platz 1
CH-8004 Zurich
Switzerland
Email: ietf@trammell.ch

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9314 YANG Data Model for Bidirectional Forwarding Detection (BFD)

Internet Engineering Task Force (IETF)              M. Jethanandani, Ed.
Request for Comments: 9314                           Xoriant Corporation
Updates: 9127                                             R. Rahman, Ed.
Category: Standards Track                                               
ISSN: 2070-1721                                            L. Zheng, Ed.
                                                     Huawei Technologies
                                                           S. Pallagatti
                                                                  VMware
                                                               G. Mirsky
                                                                Ericsson
                                                          September 2022

YANG Data Model for Bidirectional Forwarding Detection (BFD)

Модель данных YANG для BFD

PDF

Аннотация

Этот документ определяет модель данных YANG, которая может служить для настройки и управления двухсторонним обнаружениям пересылки (Bidirectional Forwarding Detection или BFD).

Модули YANG в этом документе соответствуют архитектуре хранилища данных управления сетью (Network Management Datastore Architecture или NMDA) (RFC 8342). Документ обновляет YANG Data Model for Bidirectional Forwarding Detection (BFD) (RFC 9127).

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

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

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

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

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

Copyright (c) 2022. Авторские права принадлежат 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).

Оглавление

Исключено в версии HTML.

1. Введение

Этот документ определяет модель данных YANG, которая может служить для настройки и управления обнаружением двухсторонней пересылки (BFD) [RFC5880]. Протокол BFD применяется для обнаружения живучести произвольных путей между системами. Некоторые примеры путей, на которых применим протокол BFD указаны ниже.

  1. Две системы, соединённые напрямую по IP. Это называется BFD через один интервал (single-hop) IP, а также BFD для IPv4 и IPv6 [RFC5881].

  2. Две системы, соединённые через несколько интервалов пересылки, как описано в Bidirectional Forwarding Detection (BFD) for Multihop Paths [RFC5883].

  3. Две системы, соединённые по пути с коммутацией по меткам MPLS (MPLS Label Switched Path или LSP), как описано в Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [RFC5884].

  4. Две системы, соединённые через интерфейс группы агрегирования каналов (Link Aggregation Group или LAG), как описано в Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130].

  5. Две системы, соединённые через псевдопровода (PW). Это называют проверкой связности виртуальных устройств (Virtual Circuit Connectivity Verification или VCCV), как описано в Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) [RFC5885]. Данный вариант в документе не рассматривается.

BFD обычно не работает сам по себе. Различные протоколы управления (клиенты BFD) используют услуги BFD для своей работы, как описано в Generic Application of Bidirectional Forwarding Detection (BFD) [RFC5882]. Очевидными кандидатами на использование BFD являются протоколы, не имеющие своих сообщений hello для обнаружения отказов, например, статическая маршрутизация, протоколы маршрутизации, где сообщения hello не поддерживают обнаружение отказов за доли секунды, такие как OSPF и IS-IS.

Модули YANG в этом документе соответствуют архитектуре хранилищ NMDA [RFC8342]. Это значит, что модели данных не имеют контейнеров верхнего уровня или братских (sibling) контейнеров для данных конфигурации и рабочего состояния.

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

В этом документе применяется графическое представление данных, определённое в [RFC8340].

2. Модель данных

Поскольку BFD применяется для определения живучести различных путей пересылки, единого ключа для идентификации сессий BFD нет. В результате модель данных BFD разделена на несколько модулей YANG, каждый из которых соответствует определённому типу путей. Например, BFD для IP с одной пересылкой имеет один модуль YANG, а BFD для MPLS — другой. Основным различием между этими модулями является способ однозначной идентификации сессий BFD для данного пути пересылки. Чтобы избежать дублирования определений BFD, базовые типы и группировки собраны в отдельном модуле.

Пределен новый протокол управления bfdv1 и создан контейнер bfd в control-plane-protocol, заданном в документе A YANG Data Model for Routing Management (NMDA Version) [RFC8349]. Этот новый контейнер bfd дополняется указанными ниже модулями YANG с конкретной информацией.

  1. Модуль ietf-bfd-ip-sh (параграф 2.13) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером ip-sh для сессий BFD с одной пересылкой IP (single-hop).

  2. Модуль ietf-bfd-ip-mh» (параграф 2.14) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером ip-mh для сессий BFD с несколькими пересылками IP (multihop).

  3. Модуль ietf-bfd-lag» (параграф 2.15) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером lag для сессий BFD через LAG.

  4. Модуль ietf-bfd-mpls» (параграф 2.16) дополняет /routing/control-plane-protocols/control-plane-protocol/bfd/ контейнером mpls для сессий BFD через MPLS LSP.

BFD может работать в разном контексте, как указано ниже.

  1. На уровне сетевого устройства.

  2. В логический элементах сети (logical network element или LNE), как описано в YANG Model for Logical Network Elements [RFC8530].

  3. В экземплярах сетей, как описано в YANG Data Model for Network Instances [RFC8529].

При использовании на уровне сетевого устройства модель данных YANG BFD применяется «как есть» (as is). При использовании модели YANG BFD в LNE или экземпляре сети эта модель дополняет имеющуюся модель маршрутизации для LNE или экземпляра сети.

2.1. Модель конфигурации

Модель конфигурации включает в основном параметры, заданные в BFD [RFC5880], например, желаемый минимальный интервал передачи, требуемый минимальный интервал получения, множитель обнаружения.

Клиентами BFD являются приложения, применяющие BFD для быстрого обнаружения отказов. В некоторых реализациях имеется настройка сессии BFD для клиентов BFD, например, для приложений маршрутизации, таких как OSPF, IS-IS, BGP. В других реализациях сессии BFD настраиваются на уровне BFD целиком, т. е. не по клиентам.

Основные параметры BFD, интересующие клиентов, относятся к множителям и интервалам, поскольку эти параметры влияют на время схождения у клиентов BFD при возникновении отказа. Другие параметры, например, аутентификация BFD, не зависят от требований клиентов BFD. Конфигурации BFD для всех клиентов следует быть централизованной. Однако это создаёт проблему для клиентов BFD, автоматически находящих своих партнёров. Например, в IGP адрес партнёра не настраивается, протокол IGP просто включается на интерфейсе и партнёры обнаруживаются автоматически. Таким образом, при настройке BFD для партнёра IGP оператору сначала нужно узнать адрес партнёра. При обнаружении нового партнера будет добавляться конфигурация BFD. Для предотвращения таких проблем задана группировка client-cfg-parms (параграф 2.11) для настройки BFD клиентами — это позволяет клиентами, таким как IGP, иметь конфигурацию (множитель и интервалы) для нужной сессии BFD. Например, при обнаружении нового партнёра IGP для него будет создаваться сессия BFD, а при утере партнёра IGP его сессия будет удаляться. Механизмы создания и удаления сессий BFD выходят за рамки этого документа, но обычно это выполняется с использованием API, реализованного в модуле BFD на системе. В случае клиентов BFD, создающий сессии BFD на основе своей конфигурации, параметры аутентификации (при необходимости) по-прежнему задаются в BFD.

2.1.1. Базовые параметры конфигурации BFD

Ниже перечислены базовые параметры конфигурации BFD.

local-multiplier

Множитель времени обнаружения, как указано в BFD [RFC5880].

desired-min-tx-interval

Желаемый минимальный интервал передачи (Desired Min TX), как указано в BFD [RFC5880].

required-min-rx-interval

Требуемый минимальный интервал получения (Required Min RX), как указано в BFD [RFC5880].

Хотя BFD [RFC5880] разрашает разные интервалы для приёма и передачи, некоторые реализации позволяют пользователю задать лишь один интервал (для приёма и передачи). Модель данных YANG BFD поддерживает оба варианта и можно выбрать min-interval, используемый для приёма и передачи, а также desired-min-tx-interval и required-min-rx-interval. Это поддерживается через группировку base-cfg-parms (2.11. Модуль для типов BFD), применяемую модулями YANG для разных путей пересылки.

Для аутентификации BFD имеется два параметра.

key-chain

Ссылка на key-chain, как задано в YANG Data Model for Key Chains [RFC8177]. Ключи, криптоалгоритмы, сроки действия ключей и т. п. определены в модели key-chain.

meticulous

Включает скрупулёзный (meticulous) режим, заданный в BFD [RFC5880].

2.1.2. IP с одной пересылкой

Для одной пересылки (single-hop) IP задано дополнение в узле данных bfd, как указано в параграфе 2. Узел ip-sh содержит список сессий IP single-hop, каждая из которых однозначно указывается интерфейсом и адресом получателя. Применяются параметры конфигурации, указанные в параграфе 2.1.1. Узел ip-sh содержит также список интерфейсов и служит для задания параметров аутентификации сессий BFD, создаваемых клиентами BFD (2.1. Модель конфигурации).

[RFC5880] и [RFC5881] не задают работу функции Echo непрерывно или по запросу. Поэтому механизм для запуска и остановки функции Echo зависит от реализации и должен задаваться через дополнение, как указано ниже.

  1. Конфигурация. Подходит для непрерывной функции Echo (см. Приложение A. Пример настройки функции Echo).

  2. RPC. Это подходит для функции Echo, работающей по запросам.

2.1.3. IP с множеством пересылок

Для IP с несколькими пересылками (multihop) задано дополнение в узле данных bfd, как указано в параграфе 2.

По причине наличия разных путей может возникать несколько сессий multihop IP между отправителем и получателем. Набор сессий называется session-group. Клюя для session-group состоит из двух элементов.

Source address — адрес отправителя

Адрес, относящийся к локальной системе в соответствии с Bidirectional Forwarding Detection (BFD) for Multihop Paths [RFC5883].

Destination address — адрес получателя

Адрес, относящийся к удаленной системе в соответствии с [RFC5883].

Применяются параметры конфигурации, указанные в параграфе 2.1.1.

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

tx-ttl

TTL в исходящих пакетах управления BFD;

rx-ttl

минимальное значение TTL во входящих пакетах управления BFD.

2.1.4. Пути с коммутацией по меткам MPLS

Здесь рассматриваются пути MPLS LSP, с которых классом эквивалентности пересылки (Forwarding Equivalence Class или FEC) [RFC3031] служит адрес IP. Узел bfd (параграф 2) дополнен узлом mpls со списком сессий, однозначно указываемых префиксомIP. По причине использования разных путей может быть несколько сессий MPLS для MPLS FEC. Набор этих сессий указывается в session-group.

Поскольку эти LSP являются односторонними, на выходном узле нет конфигурации LSP.

Параметры BFD для выходного узла добавляются в иерархию mpls.

2.1.5. Группы агрегирования каналов

В соответствии с Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces [RFC7130] конфигурация BFD для LAG включает микросессии BFD для каждого канала в составе LAG. Поскольку параметры BFD являются атрибутами LAG, им следует находиться в иерархии LAG. Однако модели данных YANG для LAG не существует, поэтому узел lag добавлен к узлу bfd (параграф 2). Конфигурация задаётся на уровне LAG, имеется список групп LAG. IP-адрес получателя в микросессии BFD задаётся для LAG и семейства адресов (IPv4 или IPv6).

2.2. Модель рабочего состояния

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

  1. Фундаментальные сведения о сессии BFD, такие как локальный и удалённый дискриминаторы, способность поддерживать режим Demand (по запросу).

  2. Сведения о работе сессии BFD (session-running), например, удалённый статус BFD и полученный код диагностики. Тругим примером служит фактический интервал передачи управляющих пакетов, который может отличаться от заданного желаемого минимального интервала. Другие примеры включают фактические интервалы между получаемыми пакетами управления и передаваемыми пакетами Echo.

  3. Подробные сведения о сессии, например, время включения-отключения (up/down), продолжительность состояния.

Для некоторых типов путей может быть более одной сессии на виртуальный путь к адресату. Например, в IP multihop и MPLS LSP может быть несколько сессий BFD от источника к одному получателю для тестирования разных путей (ECMP). Это представляется множеством sessions в иерархии каждой группы session-group.

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

Эта модель данных YANG задаёт уведомления для информирования конечных пользователей о важных событиях в процессе работы протокола. Локальный дискриминатор указывает соответствующую сессию BFD в локальной системе, а удалённый дискриминатор — в удалённой. Уведомления также содержат важные детали сессий BFD, например, новое состояние, время в предыдущем состоянии, причина смены состояния сессии BFD. Уведомления определены для каждого типа путей пересылки, го используют группировку с общей информацией.

2.4. Операции RPC

Нет.

2.5. Иерархия верхнего уровня BFD

В узле bfd (иерархия control-plane-protocol) нет данных конфигурации — только данные рабочего состояния, включающие общую статистику сессии BFD, т. е. BFD для вех типов путей пересылки.

   module: ietf-bfd
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol:
       +--rw bfd
          +--ro summary
             +--ro number-of-sessions?              yang:gauge32
             +--ro number-of-sessions-up?           yang:gauge32
             +--ro number-of-sessions-down?         yang:gauge32
             +--ro number-of-sessions-admin-down?   yang:gauge32

2.6. Иерархия BFD IP Single-Hop

Узел ip-sh добавляется в ветвь bfd иерархии control-plane-protocol. Этот узел содержит узлы данных конфигурации и рабочего состояния для каждой сессии BFD IP single-hop.

   module: ietf-bfd-ip-sh
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw ip-sh
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw sessions
          |  +--rw session* [interface dest-addr]
          |     +--rw interface                         if:interface-ref
          |     +--rw dest-addr                         inet:ip-address
          |     +--rw source-addr?                      inet:ip-address
          |     +--rw local-multiplier?                 multiplier
          |     +--rw (interval-config-type)?
          |     |  +--:(tx-rx-intervals)
          |     |  |  +--rw desired-min-tx-interval?    uint32
          |     |  |  +--rw required-min-rx-interval?   uint32
          |     |  +--:(single-interval) {single-minimum-interval}?
          |     |     +--rw min-interval?               uint32
          |     +--rw demand-enabled?                   boolean
          |     |       {demand-mode}?
          |     +--rw admin-down?                       boolean
          |     +--rw authentication! {authentication}?
          |     |  +--rw key-chain?    key-chain:key-chain-ref
          |     |  +--rw meticulous?   boolean
          |     +--ro path-type?                        identityref
          |     +--ro ip-encapsulation?                 boolean
          |     +--ro local-discriminator?              discriminator
          |     +--ro remote-discriminator?             discriminator
          |     +--ro remote-multiplier?                multiplier
          |     +--ro demand-capability?                boolean
          |     |       {demand-mode}?
          |     +--ro source-port?                      inet:port-number
          |     +--ro dest-port?                        inet:port-number
          |     +--ro session-running
          |     |  +--ro session-index?                uint32
          |     |  +--ro local-state?                  state
          |     |  +--ro remote-state?                 state
          |     |  +--ro local-diagnostic?
          |     |  |       iana-bfd-types:diagnostic
          |     |  +--ro remote-diagnostic?
          |     |  |       iana-bfd-types:diagnostic
          |     |  +--ro remote-authenticated?         boolean
          |     |  +--ro remote-authentication-type?
          |     |  |       iana-bfd-types:auth-type {authentication}?
          |     |  +--ro detection-mode?               enumeration
          |     |  +--ro negotiated-tx-interval?       uint32
          |     |  +--ro negotiated-rx-interval?       uint32
          |     |  +--ro detection-time?               uint32
          |     |  +--ro echo-tx-interval-in-use?      uint32
          |     |          {echo-mode}?
          |     +--ro session-statistics
          |        +--ro create-time?
          |        |       yang:date-and-time
          |        +--ro last-down-time?
          |        |       yang:date-and-time
          |        +--ro last-up-time?
          |        |       yang:date-and-time
          |        +--ro down-count?                     yang:counter32
          |        +--ro admin-down-count?               yang:counter32
          |        +--ro receive-packet-count?           yang:counter64
          |        +--ro send-packet-count?              yang:counter64
          |        +--ro receive-invalid-packet-count?   yang:counter64
          |        +--ro send-failed-packet-count?       yang:counter64
          +--rw interfaces* [interface]
             +--rw interface         if:interface-ref
             +--rw authentication! {authentication}?
                +--rw key-chain?    key-chain:key-chain-ref
                +--rw meticulous?   boolean

     notifications:
       +---n singlehop-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro interface?                   if:interface-ref
          +--ro echo-enabled?                boolean

2.7. Иерархия BFD IP Multihop

Узел ip-mh добавлен в ветвь bfd иерархии control-plane-protocol и содержит узлы данных конфигурации и рабочего состояния для каждой сессии BFD IP multihop. В модели рабочего состояния поддерживается множество сессий BFD multihop на удалённый адрес (ECMP), ключом для них служит локальный дискриминатор.

   module: ietf-bfd-ip-mh
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw ip-mh
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw session-groups
             +--rw session-group* [source-addr dest-addr]
                +--rw source-addr                       inet:ip-address
                +--rw dest-addr                         inet:ip-address
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(tx-rx-intervals)
                |  |  +--rw desired-min-tx-interval?    uint32
                |  |  +--rw required-min-rx-interval?   uint32
                |  +--:(single-interval) {single-minimum-interval}?
                |     +--rw min-interval?               uint32
                +--rw demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--rw tx-ttl?                           bfd-types:hops
                +--rw rx-ttl                            bfd-types:hops
                +--ro sessions* []
                   +--ro path-type?              identityref
                   +--ro ip-encapsulation?       boolean
                   +--ro local-discriminator?    discriminator
                   +--ro remote-discriminator?   discriminator
                   +--ro remote-multiplier?      multiplier
                   +--ro demand-capability?      boolean {demand-mode}?
                   +--ro source-port?            inet:port-number
                   +--ro dest-port?              inet:port-number
                   +--ro session-running
                   |  +--ro session-index?                uint32
                   |  +--ro local-state?                  state
                   |  +--ro remote-state?                 state
                   |  +--ro local-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-authenticated?         boolean
                   |  +--ro remote-authentication-type?
                   |  |       iana-bfd-types:auth-type {authentication}?
                   |  +--ro detection-mode?               enumeration
                   |  +--ro negotiated-tx-interval?       uint32
                   |  +--ro negotiated-rx-interval?       uint32
                   |  +--ro detection-time?               uint32
                   |  +--ro echo-tx-interval-in-use?      uint32
                   |          {echo-mode}?
                   +--ro session-statistics
                      +--ro create-time?
                      |       yang:date-and-time
                      +--ro last-down-time?
                      |       yang:date-and-time
                      +--ro last-up-time?
                      |       yang:date-and-time
                      +--ro down-count?
                      |       yang:counter32
                      +--ro admin-down-count?
                      |       yang:counter32
                      +--ro receive-packet-count?
                      |       yang:counter64
                      +--ro send-packet-count?
                      |       yang:counter64
                      +--ro receive-invalid-packet-count?
                      |       yang:counter64
                      +--ro send-failed-packet-count?
                              yang:counter64

     notifications:
       +---n multihop-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref

2.8. Иерархия для BFD через LAG

Узел lag добавлен в ветвь bfd иерархии control-plane-protocol и содержит узлы данных конфигурации и рабочего состояния каждой сессии BFD LAG.

   module: ietf-bfd-lag
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw lag
          +--rw micro-bfd-ipv4-session-statistics
          |  +--ro summary
          |     +--ro number-of-sessions?              yang:gauge32
          |     +--ro number-of-sessions-up?           yang:gauge32
          |     +--ro number-of-sessions-down?         yang:gauge32
          |     +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw micro-bfd-ipv6-session-statistics
          |  +--ro summary
          |     +--ro number-of-sessions?              yang:gauge32
          |     +--ro number-of-sessions-up?           yang:gauge32
          |     +--ro number-of-sessions-down?         yang:gauge32
          |     +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw sessions
             +--rw session* [lag-name]
                +--rw lag-name                          if:interface-ref
                +--rw ipv4-dest-addr?
                |       inet:ipv4-address
                +--rw ipv6-dest-addr?
                |       inet:ipv6-address
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(tx-rx-intervals)
                |  |  +--rw desired-min-tx-interval?    uint32
                |  |  +--rw required-min-rx-interval?   uint32
                |  +--:(single-interval) {single-minimum-interval}?
                |     +--rw min-interval?               uint32
                +--rw demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--rw use-ipv4?                         boolean
                +--rw use-ipv6?                         boolean
                +--ro member-links* [member-link]
                   +--ro member-link       if:interface-ref
                   +--ro micro-bfd-ipv4
                   |  +--ro path-type?              identityref
                   |  +--ro ip-encapsulation?       boolean
                   |  +--ro local-discriminator?    discriminator
                   |  +--ro remote-discriminator?   discriminator
                   |  +--ro remote-multiplier?      multiplier
                   |  +--ro demand-capability?      boolean
                   |  |       {demand-mode}?
                   |  +--ro source-port?            inet:port-number
                   |  +--ro dest-port?              inet:port-number
                   |  +--ro session-running
                   |  |  +--ro session-index?                uint32
                   |  |  +--ro local-state?                  state
                   |  |  +--ro remote-state?                 state
                   |  |  +--ro local-diagnostic?
                   |  |  |       iana-bfd-types:diagnostic
                   |  |  +--ro remote-diagnostic?
                   |  |  |       iana-bfd-types:diagnostic
                   |  |  +--ro remote-authenticated?         boolean
                   |  |  +--ro remote-authentication-type?
                   |  |  |       iana-bfd-types:auth-type
                   |  |  |       {authentication}?
                   |  |  +--ro detection-mode?               enumeration
                   |  |  +--ro negotiated-tx-interval?       uint32
                   |  |  +--ro negotiated-rx-interval?       uint32
                   |  |  +--ro detection-time?               uint32
                   |  |  +--ro echo-tx-interval-in-use?      uint32
                   |  |          {echo-mode}?
                   |  +--ro session-statistics
                   |     +--ro create-time?
                   |     |       yang:date-and-time
                   |     +--ro last-down-time?
                   |     |       yang:date-and-time
                   |     +--ro last-up-time?
                   |     |       yang:date-and-time
                   |     +--ro down-count?
                   |     |       yang:counter32
                   |     +--ro admin-down-count?
                   |     |       yang:counter32
                   |     +--ro receive-packet-count?
                   |     |       yang:counter64
                   |     +--ro send-packet-count?
                   |     |       yang:counter64
                   |     +--ro receive-invalid-packet-count?
                   |     |       yang:counter64
                   |     +--ro send-failed-packet-count?
                   |             yang:counter64
                   +--ro micro-bfd-ipv6
                      +--ro path-type?              identityref
                      +--ro ip-encapsulation?       boolean
                      +--ro local-discriminator?    discriminator
                      +--ro remote-discriminator?   discriminator
                      +--ro remote-multiplier?      multiplier
                      +--ro demand-capability?      boolean
                      |       {demand-mode}?
                      +--ro source-port?            inet:port-number
                      +--ro dest-port?              inet:port-number
                      +--ro session-running
                      |  +--ro session-index?                uint32
                      |  +--ro local-state?                  state
                      |  +--ro remote-state?                 state
                      |  +--ro local-diagnostic?
                      |  |       iana-bfd-types:diagnostic
                      |  +--ro remote-diagnostic?
                      |  |       iana-bfd-types:diagnostic
                      |  +--ro remote-authenticated?         boolean
                      |  +--ro remote-authentication-type?
                      |  |       iana-bfd-types:auth-type
                      |  |       {authentication}?
                      |  +--ro detection-mode?               enumeration
                      |  +--ro negotiated-tx-interval?       uint32
                      |  +--ro negotiated-rx-interval?       uint32
                      |  +--ro detection-time?               uint32
                      |  +--ro echo-tx-interval-in-use?      uint32
                      |          {echo-mode}?
                      +--ro session-statistics
                         +--ro create-time?
                         |       yang:date-and-time
                         +--ro last-down-time?
                         |       yang:date-and-time
                         +--ro last-up-time?
                         |       yang:date-and-time
                         +--ro down-count?
                         |       yang:counter32
                         +--ro admin-down-count?
                         |       yang:counter32
                         +--ro receive-packet-count?
                         |       yang:counter64
                         +--ro send-packet-count?
                         |       yang:counter64
                         +--ro receive-invalid-packet-count?
                         |       yang:counter64
                         +--ro send-failed-packet-count?
                                 yang:counter64

     notifications:
       +---n lag-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro lag-name?                    if:interface-ref
          +--ro member-link?                 if:interface-ref

2.9. Иерархия для BFD через MPLS LSP

Узел mpls добавлен в ветвь bfd иерархии control-plane-protocol и содержит конфигурации для MPLS FEC. В модели рабочего состояния поддерживается множество сессий BFD на MPLS FEC (ECMP), ключом для них служит локальный дискриминатор. Узел mpls можно применять в сетевом устройстве (верхний уровень), а также устанавливать в LNE или экземпляре сети.

   module: ietf-bfd-mpls
     augment /rt:routing/rt:control-plane-protocols
               /rt:control-plane-protocol/bfd:bfd:
       +--rw mpls
          +--ro summary
          |  +--ro number-of-sessions?              yang:gauge32
          |  +--ro number-of-sessions-up?           yang:gauge32
          |  +--ro number-of-sessions-down?         yang:gauge32
          |  +--ro number-of-sessions-admin-down?   yang:gauge32
          +--rw egress
          |  +--rw enabled?                          boolean
          |  +--rw local-multiplier?                 multiplier
          |  +--rw (interval-config-type)?
          |  |  +--:(tx-rx-intervals)
          |  |  |  +--rw desired-min-tx-interval?    uint32
          |  |  |  +--rw required-min-rx-interval?   uint32
          |  |  +--:(single-interval) {single-minimum-interval}?
          |  |     +--rw min-interval?               uint32
          |  +--rw authentication! {authentication}?
          |     +--rw key-chain?    key-chain:key-chain-ref
          |     +--rw meticulous?   boolean
          +--rw session-groups
             +--rw session-group* [mpls-fec]
                +--rw mpls-fec                          inet:ip-prefix
                +--rw local-multiplier?                 multiplier
                +--rw (interval-config-type)?
                |  +--:(tx-rx-intervals)
                |  |  +--rw desired-min-tx-interval?    uint32
                |  |  +--rw required-min-rx-interval?   uint32
                |  +--:(single-interval) {single-minimum-interval}?
                |     +--rw min-interval?               uint32
                +--rw demand-enabled?                   boolean
                |       {demand-mode}?
                +--rw admin-down?                       boolean
                +--rw authentication! {authentication}?
                |  +--rw key-chain?    key-chain:key-chain-ref
                |  +--rw meticulous?   boolean
                +--ro sessions* []
                   +--ro path-type?              identityref
                   +--ro ip-encapsulation?       boolean
                   +--ro local-discriminator?    discriminator
                   +--ro remote-discriminator?   discriminator
                   +--ro remote-multiplier?      multiplier
                   +--ro demand-capability?      boolean {demand-mode}?
                   +--ro source-port?            inet:port-number
                   +--ro dest-port?              inet:port-number
                   +--ro session-running
                   |  +--ro session-index?                uint32
                   |  +--ro local-state?                  state
                   |  +--ro remote-state?                 state
                   |  +--ro local-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-diagnostic?
                   |  |       iana-bfd-types:diagnostic
                   |  +--ro remote-authenticated?         boolean
                   |  +--ro remote-authentication-type?
                   |  |       iana-bfd-types:auth-type {authentication}?
                   |  +--ro detection-mode?               enumeration
                   |  +--ro negotiated-tx-interval?       uint32
                   |  +--ro negotiated-rx-interval?       uint32
                   |  +--ro detection-time?               uint32
                   |  +--ro echo-tx-interval-in-use?      uint32
                   |          {echo-mode}?
                   +--ro session-statistics
                   |  +--ro create-time?
                   |  |       yang:date-and-time
                   |  +--ro last-down-time?
                   |  |       yang:date-and-time
                   |  +--ro last-up-time?
                   |  |       yang:date-and-time
                   |  +--ro down-count?
                   |  |       yang:counter32
                   |  +--ro admin-down-count?
                   |  |       yang:counter32
                   |  +--ro receive-packet-count?
                   |  |       yang:counter64
                   |  +--ro send-packet-count?
                   |  |       yang:counter64
                   |  +--ro receive-invalid-packet-count?
                   |  |       yang:counter64
                   |  +--ro send-failed-packet-count?
                   |          yang:counter64
                   +--ro mpls-dest-address?      inet:ip-address

     notifications:
       +---n mpls-notification
          +--ro local-discr?                 discriminator
          +--ro remote-discr?                discriminator
          +--ro new-state?                   state
          +--ro state-change-reason?         iana-bfd-types:diagnostic
          +--ro time-of-last-state-change?   yang:date-and-time
          +--ro dest-addr?                   inet:ip-address
          +--ro source-addr?                 inet:ip-address
          +--ro session-index?               uint32
          +--ro path-type?                   identityref
          +--ro mpls-dest-address?           inet:ip-address

2.10. Взаимодействие с другими модулями YANG

В документе Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications [RFC8532] описано, как можно расширить независимой от уровня поддержки OAM (Layer-Independent OAM Management in the Multi-Layer Environment или LIME) без организации явных соединений для поддержки BFD.

Работа модели данных BFD зависит также от параметров конфигурации, определённых в других модулях YANG.

2.10.1. Модуль ietf-interfaces

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for Interface Management [RFC8343].

/if:interfaces/if:interface/if:enabled

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

2.10.2. Модуль ietf-ip

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for IP Management [RFC8344].

/if:interfaces/if:interface/ip:ipv4/ip:enabled

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv4.

/if:interfaces/if:interface/ip:ipv4/ip:forwarding

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv4.

/if:interfaces/if:interface/ip:ipv6/ip:enabled

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv6.

/if:interfaces/if:interface/ip:ipv6/ip:forwarding

Если для этой конфигурации задано значение false, интерфейс не будет передавать и принимать пакеты BFD IPv6.

2.10.3. Модуль ietf-mpls

Показанная ниже логическая конфигурация задана в документе A YANG Data Model for MPLS Base [RFC8960].

/rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/mpls:mpls-enabled

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

2.11. Модуль для типов BFD

Этот модуль YANG импортирует определения типов из [RFC6991] и [RFC8177], определения из [RFC5880], [RFC5881], [RFC5883], [RFC5884] и [RFC7130], а также отождествление control-plane-protocol из [RFC8349, и ссылки [RFC9127].

   <CODE BEGINS> file "ietf-bfd-types@2022-09-22.yang"
   module ietf-bfd-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types";
     prefix bfd-types;

     import iana-bfd-types {
       prefix iana-bfd-types;
       reference
         "RFC 9127: YANG Data Model for Bidirectional Forwarding
          Detection (BFD)";
     }
     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 ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing Management
          (NMDA Version)";
     }
     import ietf-key-chain {
       prefix key-chain;
       reference
         "RFC 8177: YANG Data Model for Key Chains";
     }

     organization
       "IETF BFD Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/bfd/> 
        WG List:  <mailto:rtg-bfd@ietf.org> 

        Editor:   Reshad Rahman
                  <mailto:reshad@yahoo.com> 

        Editor:   Lianshu Zheng
                  <mailto:veronique_cheng@hotmail.com> 

        Editor:   Mahesh Jethanandani
                  <mailto:mjethanandani@gmail.com>"; 
     description
       "Этот модуль содержит определения связанных с BFD типов данных
        YANG в соответствии с RFC 5880, а также группировки, применяемые
        совместно с другими модулям YANG BFD.

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

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в со