RFC 9316 Intent Classification

Опубликовано 27.10.2022 автором Nikolai Malykh 
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), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

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. Добавьте в закладки постоянную ссылку.													

					


					

					
			




	

		
Добавить комментарий