RFC 8453 Framework for Abstraction and Control of TE Networks (ACTN)

Internet Engineering Task Force (IETF)                D. Ceccarelli, Ed.
Request for Comments: 8453                                      Ericsson
Category: Informational                                      Y. Lee, Ed.
ISSN: 2070-1721                                                   Huawei
                                                             August 2018

Модель абстрагирования и управления в сетях TE (ACTN)

Framework for Abstraction and Control of TE Networks (ACTN)

PDF

Аннотация

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

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

В этом документе представлена модель абстрагирования и управления сетями TE (ACTN2) для поддержки виртуальных сетевых услуг и соединений.

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

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

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

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

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

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

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

1. Введение

Термином «сеть TE» обозначают сети, в которых применяется ориентированная на соединения технология с распределенным или централизованным уровнем управления для поддержки динамического предоставления сквозных соединений. Сети TE имеют множество механизмов, облегчающих разделение уровней данных и управления, включая распределенную сигнализацию для организации и защиты путей, централизованный расчет путей для планирования и организации трафика, протоколы обеспечения для настройки и активирования сетевых ресурсов. Эти механизмы представляют основные технологии построения гибких и динамичных сетей. Примерами сетей, соответствующих этому определению, могут служить сети MPLS-TP5 [RFC5654] и MPLS-TE [RFC2702].

Одним из основных мотивов программно-определяемых сетей (SDN6) [RFC7149] является отделение уровня управления сетью от уровня данных. Такое разделение было достигнуто в сетях TE с развитием MPLS/GMPLS [RFC3945] и PCE7 [RFC4655]. Одним из преимуществ SDN является режим логически централизованного управления, позволяющий получить глобальное представление базовых сетей. Централизованное управление в SDN помогает улучшить использование ресурсов сети по сравнению с распределенным управлением. Для сетей на основе TE элементы PCE могут обеспечивать функции централизованного расчета путей.

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

2. Обзор

Ниже приведены три основных задачи, которые должны быть решены с помощью SDN.

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

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

  • Координация ресурсов множества независимых сетей и разных уровней технологии для сквозного предоставления услуг независимо от использования SDN в этих сетях.

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

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

ACTN может упростить работу виртуальных сетей за счет создания одной виртуализованной сети или единого сервиса. Это позволяет операторам видеть и контролировать разные домены (в любом измерении – топология приложений, административные зоны, фирменные технологические «островки») и представлять своим клиентам виртуализованные сети

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

  • Абстрагирование ресурсов базовой сети для приложений верхнего уровня и клиентов [RFC7926].

  • Виртуализация отдельных базовых ресурсов, критерием выбора которых является предоставление определенному клиенту, приложению или услуге [ONF-ARCH].

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

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

  • Представление сетей клиентам как виртуальной сети с открытым и программируемым интерфейсом.

2.1. Терминология

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

Domain – домен

Домен определен в [RFC4655] как «любой набор сетевых элементов в единой сфере управления адресами или расчета путей». В частности, в этом документе доменом называется часть сети оператора с единым управлениям (т. е. общим оперативным управлением, использующим общие экземпляры инструментов и правил). Элементы сети часто группируются в домены на основе технологии, профилей производителей, пространственной близости.

Abstraction – абстрагирование

Этот процесс определен в [RFC7926].

TE Network Slicing – сегментация сети TE

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

Node – узел

Узлы являются вершинами графа представления топологии TE. В топологии физической сети узел соответствует физическому элементу сети (NE9), таком как маршрутизатор. В топологии абстрактной сети узел (иногда говорят «абстрактный узел») представляется одной вершиной для одного или нескольких физических NE и соединяющих их физических каналов. Концепция узла представляет возможность подключения к данному узлу элемента доступа (окончание канала), соединенного с другим узлом. При этом могут определяться «ограниченные возможности кросс-соединений» для ограничения такой функциональности. Абстракция сети также может служить для ограничения этой функциональности. Абстрагирование сети может быть рекурсивным, поэтому узел в одной топологии может создаваться путем абстрагирования, применяемого к узлам базовой (нижележащей) топологии.

Link – канал, соединение

Канал является ребром графа в представлении топологии TE. Два узла, соединенные каналом, называют смежными (adjacent) в топологии TE. В топологии физической сети канал соответствует физическому соединению. В топологии абстрактной сети, канал (иногда говорят «абстрактный канал») является представлениям возможного соединения пары точек с некими параметрами TE (см. [RFC7926]). Абстрагирование сети может быть рекурсивным, поэтому канал в одной топологии может создаваться путем абстрагирования, применяемого к каналам базовой топологии.

Abstract Topology – абстрактная топология

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

Virtual Network (VN) – виртуальная сеть

VN – это сеть, предоставляемая сервис-провайдером клиенту для использования любым желаемым для клиента способом, как будто это отдельная физическая сеть. Есть два представления VN, указанных ниже.

  • VN может быть абстракцией набора сквозных каналов (VN типа 1), каждый из которых называют членом VN, формируемый как сквозные туннели через базовые сети. Такие туннели можно создавать путем рекурсивного сегментирования или абстрагирования путей в базовых сетях, они включают оконечные точки сети клиента, каналы доступа, а также пути внутри доменов и между доменами.
  • VN может также абстрагироваться как топология виртуальных узлов и виртуальных каналов (VN типа 2). Оператор должен отобразить VN на реальные ресурсы сети, это называют «встраиванием виртуальной сети». Узлы в этом случае включают физические конечные точки, граничные и внутренние узлы, а также абстрагированные узлы. Аналогично, каналы включают физические каналы доступа, междоменные и внутридоменные соединения, а также абстрагированные каналы.

Ясно, что VN типа 1 являются частным случаем VN типа 2.

Access link – канал доступа

Канал между узлом клиента и узлом оператора.

Inter-domain link – междоменный канал

Канал между доменами с разным административным управлением.

Access Point (AP) – точка доступа

AP – общий для клиента и оператора логический идентификатор, служащий для указания канала доступа. AP применяется абонентом при запросе услуг виртуальной сети (VNS10). Отметим, что термин «точка завершения канала TE» (TE Link Termination Point), определенный в [TE-TOPO], описывает конечные точки соединений, тогда как AP является идентификатором самого соединения.

VN Access Point (VNAP) – точка доступа в виртуальную сеть

VNAP служит привязкой между AP и данной VN.

Server Network – сеть сервера

В соответствии с определением [RFC7926] сеть сервера является сетью, обеспечивающей подключение для другой сети (сеть клиента) в модели «клиент-сервер».

2.2. Модель виртуальных сетевых услуг для ACTN

Услуги VNS представляют собой соглашение между абонентом и оператором для предоставления VN. Когда VN является просто соединением между двумя точками, различие между VNS и службой соединения размывается. В этом документе определены 3 типа VNS.

  • VNS типа 1 указывает услугу VNS, где абонент может создавать и эксплуатировать VN типа.

  • Типы 2a и 2b указывают VNS, где абонент может создавать и эксплуатировать VN типа 2. В VNS типа 2a сети VN создаются статически во время настройки услуги и клиент не может менять топологию (например, добавлять или удалять абстрактные узлы и каналы). VNS типа 2b отличаются от VNS типа 2a возможностью клиента динамически изменять начальную топологию, заданную при организации услуги.

Операции VN – это функции, которые клиент может выполнять в VN на базе соглашения между клиентом и оператором.

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

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

Тремя основными элементами модели ACTN VNS являются:

  • абоненты (клиенты);

  • сервис-провайдеры;

  • сетевые операторы.

Эти элементы образуют трехуровневую модель, показанную на рисунке 1.

                       +----------------------+
                       |       Абонент        |
                       +----------------------+
                                  |
                  Запрос     ||   |   /\    Отклик
                   VNS       ||   |   ||     VNS
                             \/   |   ||
                       +----------------------+
                       |  Сервис-провайдер    |
                       +----------------------+
                       /          |           \
                      /           |            \
                     /            |             \
                    /             |              \
+------------------+   +------------------+   +------------------+
|Сетевой оператор 1|   |Сетевой оператор 2|   |Сетевой оператор 3|
+------------------+   +------------------+   +------------------+

Рисунок 1. Трехуровневая модель.


Коммерческие роли этих элементов описаны в последующих параграфах.

2.2.1. Абоненты

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

Клиентами с расширенными запросами являются крупные предприятия и государственные структуры. Такие абоненты запрашивают соединения «точка-точка» и многоточечную связность со значительными потребностями в ресурсах и существенно меняющимися с течением времени запросами. Это является одной из причин недостаточности предоставления клиенту пакетных услуг и желательностью предоставления настраиваемых услуг VNS. Такие клиенты могут также менять параметры сервиса в рамках своей виртуализованной среды. Основное внимание в ACTN уделяется таким абонентам.

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

2.2.2. Сервис-провайдеры

В рамках ACTN сервис-провайдеры предоставляют VNS своим клиентам. Сервис-провайдеры могут (не обязательно) иметь свою сетевую инфраструктуру (т. е., могут быть сетевыми операторами, описанными в параграфе 2.2.3). Если сервис-провайдер является также оператором сети, это похоже на имеющиеся модели VPN применительно к одному оператору (такой подход сложно использовать, если клиент охватывает несколько доменов независимых операторов).

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

2.2.3. Сетевые операторы

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

3. Базовая архитектура ACTN

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

Архитектура ACTN основана на трехуровневой эталонной модели и разрешает иерархию и рекурсии. Основная функциональность системы ACTN перечислена ниже.

Междоменная координация

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

Абстрагирование

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

Отображение и трансляция абонентов

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

Координация виртуальных услуг

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

          +---------+           +---------+             +---------+
          |   CNC   |           |   CNC   |             |   CNC   |
          +---------+           +---------+             +---------+
                \                    |                       /
                 \                   |                      /
Граница   ========\==================|=====================/=======
между              \                 |                    /
абонентом           -----------      | CMI  --------------
и оператором сети              \     |     /
                             +---------------+
                             |     MDSC      |
                             +---------------+
                               /     |     \
                   ------------      | MPI  -------------
                  /                  |                   \
             +-------+          +-------+            +-------+
             |  PNC  |          |  PNC  |            |  PNC  |
             +-------+          +-------+            +-------+
                 | SBI            /   |                  /  \
                 |               /    | SBI         SBI /    \
             ---------        -----   |                /      \
            (         )      (     )  |               /        \
            - Физичес.-     ( Физич.) |              /      -----
           (   сеть    )     (сеть )  |             /      (     )
          (   уровня    )     -----   |            /      ( Физич.)
           (управления )            -----        -----     (сеть )
            -         -            (     )      (     )     -----
            (         )           ( Физич.)    ( Физич.)
             ---------             (сеть )      (сеть )
                                    -----        -----

Рисунок 2. Базовая архитектура ACTN.


Базовая архитектура ACTN определяет 3 типа контроллеров и соответствующие интерфейсы между ними (рисунок 2):

  • CNC – контроллер сети абонента;

  • MDSC – многодоменный координатор услуг;

  • PNC – контроллер обеспечивающей сети.

На рисунке 2 также показаны перечисленные ниже интерфейсы.

  • CMI – интерфейс CNC-MDSC.

  • MPI – интерфейс MDSC-PNC.

  • SBI – интерфейс южного моста.

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

3.1. Контроллер в сети абонента

Контроллер в сети клиента (CNC) отвечает за передачу требований клиента к VNS оператору сети через интерфейс CNC-MDSC (CMI). Он знает конечные точки, связанные с VNS (указываются как AP), правила обслуживания и другие данные QoS, относящиеся к сервису.

Поскольку CNC напрямую взаимодействует с приложениями, он понимает многочисленные требования приложений и их потребности в обслуживании. Возможности CNC за пределами роли CMI выходят за рамки ACTN и могут быть реализованы разными способами. Например, CNC может, фактически, быть частью контроллера в домене клиента или функциональность CNC может быть реализована как часть портала сервис-провайдера.

3.2. Многодоменный координатор услуг

Многодоменный координатор услуг (MDSC) является функциональным блоком, реализующим все указанные в разделе 4 и описанные в параграфе 4.2 функции ACTN. Две функции MDSC относятся к сети – многодоменная координация и виртуализация/абстрагирование, а две другие функции – отображение/трансляция клиентов и координация виртуального сервиса – относятся к услугам. MDSC размещается в центре модели ACTN между CNC, который выдает запросы на подключение, и контроллерами PNC, управляющими ресурсами сети. Важной особенностью MDSC (и модели ACTN в целом) является отделение управления сетью и услугами от базовой технологии, чтобы помочь клиенту описать свою сеть в соответствии с потребностями бизнеса. MDSC обеспечивает нужную технологию и управление сетью для выполнения требований бизнеса. По сути, он контролирует и управляет примитивами для обеспечения функциональности в соответствии с запросами CNC.

Для координации множества доменов должны быть разрешены взаимодействия 1:N между MDSC и PNC.

В дополнение к этому могут быть возможны взаимодействия M:1 между MDSC и PNC для обеспечения сегментации и совместного использования ресурсов сети множеством клиентов, не обязательно подключенных к одному MDSC (например, клиенты разных сервис-провайдеров), но использующих ресурсы общей инфраструктуры оператора сети.

3.3. Контроллер обеспечивающей сети

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

Функции PNC могут быть реализованы как часть контроллера SDN в домене, системы управления сетью (NMS) или ее элементами (EMS14), активного контроллера на базе PCE [RFC8283] или иным способом для динамического управления набором узлов, реализующих северный интерфейс с точки зрения узлов (выходит за рамки документа). Домен PNC включает все ресурсы, находящиеся под управлением одного PNC. Он может состоять из разных доменов маршрутизации или администрирования, а ресурсы могут поступать с разных уровней. Соединение доменой PNC показано на рисунке 3.

       _______                        _______
     _(       )_                    _(       )_
   _(           )_                _(           )_
  (               )   Граничный  (               )
 (     PNC     ------   канал  ------     PNC     )
(   домена X  |Гранич|========|Гранич|  домена Y   )
(             | узел |        | узел |             )
 (             ------          ------             )
  (_             _)              (_             _)
    (_         _)                  (_         _)
      (_______)                      (_______)

Рисунок 3. Границы домена PNC.


3.4. Интерфейсы ACTN

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

Три интерфейса архитектуры ACTN показаны на рисунке 2 и описаны ниже.

CMI

Интерфейс CNC-MDSC (CMI) реализуется между CNC и MDSC. CMI является бизнес-границей между клиентом и оператором. Он используется для запросов VNS приложениями. Вся информация, связанная с сервисом (тип VNS, топология, пропускная способность и ограничения сервиса), передается через этот интерфейс. Большая часть передаваемой через интерфейс информации не связана с используемой оператором технологией, но в некоторых случаях (например, настройка канала доступа) требуются зависящие от технологии детали.

MPI

Интерфейс MDSC-PNC (MPI) реализуется между MDSC и PNC. Он передает новые запросы на соединения или изменение пропускной способности в физическую сеть. В многодоменных средах MDSC нужно взаимодействовать с множеством PNC, каждый из которых отвечает за свой домен. MPI представляет абстрагированную топологию координатору MDSC, скрывая связанные с технологией аспекты сети и часть топологии в соответствии с правилами.

SBI

Интерфейс южного моста (SBI) выходит за рамки ACTN. Разными органами стандартизации и производителями было определено множество разных SBI для различных сред и технологий. На рисунке 3 они представлены для иллюстрации.

4. Расширенная архитектура ACTN

В этом разделе описаны расширенные конфигурации архитектуры ACTN.

4.1. Иерархия MDSC

Иерархия MDSC может применяться по разным причинам, включая расширяемость, администрирование, объединение в сети разных уровней и технологий. При наличии иерархии MDSC используются обозначения MDSC-H15 и MDSC-L16. Интерфейс между ними является рекурсией MPI. Реализация MDSC-H выполняет запросы на обеспечение обычным путем с помощью MPI, MDSC-L должен обеспечивать возможность получения запросов обычным путем через CMI, а также через MPI. Иерархия MDSC показана на рисунке 4.

Другой вариант реализации может предусматривать использование MDSC-L для всех PNC, относящихся к данной технологии (например, IP/MPLS17), другого MDSC-L для PNC, относящихся к иной технологии (например, OTN18/WDM19), и MDSC-H для их координации.

                +--------+
                |   CNC  |
                +--------+
                     |          +-----+
                     | CMI      | CNC |
               +----------+     +-----+
        -------|  MDSC-H  |----    |
       |       +----------+    |   | CMI
   MPI |                   MPI |   |
       |                       |   |
  +---------+               +---------+
  |  MDSC-L |               |  MDSC-L |
  +---------+               +---------+
MPI |     |                   |     |
    |     |                   |     |
  -----   -----             -----   -----
 | PNC | | PNC |           | PNC | | PNC |
  -----   -----             -----   -----

Рисунок 4. Иерархия MDSC.


Иерархия MDSC может быть рекурсивной, когда MDSC-H выступает в качестве MDSC-L для MDSC-H вышележащего уровня.

4.2. Разделение функций MDSC в координаторах

Реализация может разделить функции MDSC на две группы, одна из которых связана с услугами, другая – с сетью. Это позволяет реализовать оркестратор (координатор) услуг, который обеспечит связанные с сервисом функции MDSC, и координатор сети, который будет поддерживать связанные с сетью функции MDSC. Такое разделение согласуется с архитектурой модели YANG для сервиса, описанной в [RFC8309]. На рисунке 5 показан этот вариант и отображение интерфейсов ACTN на модели данных YANG.

                +--------------------+
                |           Абонент  |
                |   +-----+          |
                |   | CNC |          |
                |   +-----+          |
                +--------------------+
                         CMI | Модель обслуживания клиента
                             |
        +---------------------------------------+
        |                          Оркестратор  |
********|***********************   услуг        |
* MDSC  |  +-----------------+ *                |
*       |  |   Связанные с   | *                |
*       |  |сервисом функции | *                |
*       |  +-----------------+ *                |
*       +----------------------*----------------+
*                              *  |  Модель предоставления
*                              *  |  услуг
*       +----------------------*----------------+
*       |                      *   Оркестратор  |
*       |  +-----------------+ *   сети         |
*       |  |   Связанные с   | *                |
*       |  |  сетью функции  | *                |
*       |  +-----------------+ *                |
********|***********************                |
        +---------------------------------------+
                         MPI |  Модель настройки
                             |  сети
               +------------------------+
               |            Контроллер  |
               |  +------+  домена      |
               |  | PNC  |              |
               |  +------+              |
               +------------------------+
                         SBI |  Модель настройки
                             |  устройства
                         +--------+
                         |Устройст|
                         +--------+

Рисунок 5. Архитектура ACTN в контексте моделей YANG для сервиса.


5. Методы абстрагирования топологии

Абстрагирование топологии описано в [RFC7926]. В этом разделе рассматриваются факторы, типы и контекст абстрагирования в архитектуре ACTN.

Абстрагирование в ACTN выполняется PNC при представлении доступной топологии координатору MDSC или MDSC-L при представлении MDSC-H. Эта функция отличается от создания VN (в частности, VN типа 2), которая является не абстракцией, а конструкцией из виртуальных ресурсов.

5.1. Факторы абстрагирования

Как указано в [RFC7926], абстрагирование связано с правилами сетей. Например, в соответствии с операционной политикой PNC не будет передавать связанные с технологией детали (например, оптические параметры для WSON20) в абстрактную топологию, предоставляемую MDSC. Аналогично, политика сетей может определять тип абстрагирования, как описано в параграфе 5.2.

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

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

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

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

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

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

  • В некоторых случаях от PNC требуется скрывать важные данные внутренней топологии MDSC. Такая конфиденциальность может быть достигнута с помощью абстрагирования.

5.2. Типы абстракций

В этом параграфе описаны три перечисленных ниже типа абстракции.

  • Естественная (белая) топология (параграф 5.2.1).

  • Черная топология (параграф 5.2.2).

  • Серая топология (параграф 5.2.3)

5.2.1. Естественная (белая) топология

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

5.2.2. Черная топология

   .....................................
   : Домен PNC                         :
   :  +--+     +--+     +--+     +--+  :
------+  +-----+  +-----+  +-----+  +------
   :  ++-+     ++-+     +-++     +-++  :
   :   |        |         |        |   :
   :   |        |         |        |   :
   :   |        |         |        |   :
   :   |        |         |        |   :
   :  ++-+     ++-+     +-++     +-++  :
------+  +-----+  +-----+  +-----+  +------
   :  +--+     +--+     +--+     +--+  :
   :....................................

                +----------+
             ---+          +---
                |Абстрактн.|
                |   узел   |
             ---+          +---
                +----------+

Рисунок 6. Естественная топология и черная топология, представленная абстрактным узлом.


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

5.2.3. Серая топология

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

Выделены два типа серой топологии, указанных ниже.

  • В топологии типа A граничные узлы соединены полносвязной сетью каналов TE (рисунок 7).

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

   .....................................
   : Домен PNC                         :
   :  +--+     +--+     +--+     +--+  :
------+  +-----+  +-----+  +-----+  +------
   :  ++-+     ++-+     +-++     +-++  :
   :   |        |         |        |   :
   :   |        |         |        |   :
   :   |        |         |        |   :
   :   |        |         |        |   :
   :  ++-+     ++-+     +-++     +-++  :
------+  +-----+  +-----+  +-----+  +------
   :  +--+     +--+     +--+     +--+  :
   :....................................

            ....................
            : Абстрактная сеть :
            :                  :
            :   +--+    +--+   :
         -------+  +----+  +-------
            :   ++-+    +-++   :
            :    |  \  /  |    :
            :    |   \/   |    :
            :    |   /\   |    :
            :    |  /  \  |    :
            :   ++-+    +-++   :
         -------+  +----+  +-------
            :   +--+    +--+   :
            :..................:

Рисунок 7. Естественная топология с соответствующей серой топологией.


5.3. Методы построения серой топологии

В этом параграфе рассмотрены два способа построения серой топологии:

  • автоматическая генерация абстрактной топологии по конфигурации (параграф 5.3.1);

  • генерация по запросу дополнительной топологии по запросам и откликам расчета пути (параграф 5.3.2).

5.3.1. Автоматическая генерация абстрактной топологии по конфигурации

Автоматическая генерация основана на абстрагировании/обобщении всего домена контроллером PNC и его анонсами на MPI. Уровень абстракции может быть выведен из параметров конфигурации PNC (например, «предоставлять возможные соединения между PE и любым ASBR в сети MPLS-TE»).

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

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

5.3.2. Генерация дополнительной топологии по запросам и откликам PC

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

Анонсы абстрактной топологии от PNC дают MDSC информацию о граничных узлах и каналах для каждого домена. В этом сценарии, когда MDSC нужно создать новую сеть VN, он может передать запрос расчета пути контроллерам PNC с ограничениями, соответствующими запросу VN, как описано в [ACTN-YANG]. Пример этого показан на рисунке 8, где MDSC создает P2P VN между AP1 и AP2. MDSC может использовать два разных междоменных канала из домена X в домен Y, но для выбора наилучшего сквозного пути ему нужно знать, что могут предложить домены X и Y в плане связности и ограничений между узлами PE и граничными узлами.

         -------                 --------
        (       )               (        )
       -      BrdrX.1------- BrdrY.1      -
      (+---+       )          (       +---+)
-+---( |PE1| Dom.X  )        (  Dom.Y |PE2| )---+-
 |    (+---+       )          (       +---+)    |
AP1    -      BrdrX.2------- BrdrY.2      -    AP2
        (       )               (        )
         -------                 --------

Рисунок 8. Пример с множеством доменов.


MDSC передает запрос расчета пути контроллеру PNC.X, выясняя возможную связность между PE1 и граничным узлом BrdrX.1, а также между PE1 и BrdrX.2 с определяемыми задачей функциями и метрическими ограничениями TE. Похожий запрос связности от граничного узла в домене Y к узлу PE2 будет передан PNC.Y. MDSC объединяет результаты для расчета оптимального сквозного пути, включающего междоменные каналы. MDSC может использовать результат этого расчета для запроса у PNC предоставления базовой сети, а затем MDSC может использовать сквозной путь в качестве виртуального канала в VN, предоставляемой абоненту.

5.4. Пример абстракции иерархической топологии

В этом параграфе показано, как абстракция топологии работает на разных уровнях иерархии MDSC (рисунок 9).

                          +-----+
                          | CNC |  CNC хочет организовать VN
                          +-----+  между CE A и CE B
                             |
                             |
                 +-----------------------+
                 |         MDSC-H        |
                 +-----------------------+
                       /           \
                      /             \
              +---------+         +---------+
              | MDSC-L1 |         | MDSC-L2 |
              +---------+         +---------+
                /    \               /    \
               /      \             /      \
            +----+  +----+       +----+  +----+
  CE A o----|PNC1|  |PNC2|       |PNC3|  |PNC4|----o CE B
            +----+  +----+       +----+  +----+

                Виртуальная сеть, предоставленная CNC

                  CE A o==============o CE B

                Топология, обслуживаемая MDSC-H

               CE A o----o==o==o===o----o CE B

Топология, обслуживаемая MDSC-L1     Топология, обслуживаемая MDSC-L2
               _        _                       _        _
              ( )      ( )                     ( )      ( )
             (   )    (   )                   (   )    (   )
    CE A o--(o---o)==(o---o)==Дом.3   Дом.2==(o---o)==(o---o)--o CE B
             (   )    (   )                   (   )    (   )
              (_)      (_)                     (_)      (_)

                           Реальная топология
             ___          ___          ___          ___
            (   )        (   )        (   )        (   )
           (  o  )      (  o  )      ( o--o)      (  o  )
          (  / \  )    (   |\  )    (  |  | )    (  / \  )
CE A o---(o-o---o-o)==(o-o-o-o-o)==(o--o--o-o)==(o-o-o-o-o)---o CE B
          (  \ /  )    ( | |/  )    (  |  | )    (  \ /  )
           (  o  )      (o-o  )      ( o--o)      (  o  )
            (___)        (___)        (___)        (___)

           Домен 1      Домен 2      Домен 3      Домен 4

     o   узел
     --- канал
     === граничный канал

Рисунок 9. Абстракция иерархической топологии.

В примере на рисунке 9 4 домена находятся под управлением PNC – PNC1, PNC2, PNC3, PNC4. MDSC-L1 управляет PNC1 и PNC2, а MDSC-L2 – PNC3 и PNC4. Каждый из PNC предоставляет серую абстракцию топологии, которая включает лишь краевые узлы, а также внутридоменные и междоменные каналы. Абстрактная топология с которой работает MDSC-L1, является комбинацией топологии от PNC1 и PNC2. Аналогично, абстрактная топология, с которой работает MDSC-L2, показана на рисунке 9. MDSC-L1 и MDSC-L2 представляют черную абстракцию топологии для координатора MDSC-H, в которой каждый домен PNC представлен одним виртуальным узлом. MDSC-H объединяет две топологии для создания абстрактной топологии, с которой будет работать. MDSC-H видит сети всех четырех доменов как 4 виртуальных узла, соединенных виртуальными каналами.

5.5. Рекурсия VN с сетевыми уровнями

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

Как показано на рисунке 10, клиент запрашивает сквозное соединение между CE A и CE B (виртуальную сеть). Клиентский CNC передает запрос MDSC оператора 1. MDSC определяет, какие сетевые ресурсы нужно настроить, и передает инструкции соответствующим PNC. Однако канал между Q и R является виртуальным каналом, предоставленным оператором 2 (оператор 1 является клиентом оператора 2).

Для поддержки этого оператор 1 имеет CNC, который взаимодействует с MDSC оператора 2. Отметим, что CNC оператора 1 на рисунке 10 является необязательной для реализации функциональной компонентой (может быть встроен в PNC).

Виртуальная CE A o===============================o CE B
сеть

                              -----    CNC хочет создать VN
Абонент                      | CNC |   между CE A и CE B
                              -----
                                :
         ***********************************************
                                :
Оператор 1         ---------------------------
                  |           MDSC            |
                   ---------------------------
                    :           :           :
                    :           :           :
                  -----   -------------   -----
                 | PNC | |     PNC     | | PNC |
                  -----   -------------   -----
                    :     :     :     :     :
Вышележащий         v     v     :     v     v
сетевой    CE A o---P-----Q===========R-----S---o CE B
уровень                   |     :     |
                          |     :     |
                          |   -----   |
                          |  | CNC |  |
                          |   -----   |
                          |     :     |
         ***********************************************
                          |     :     |
Оператор 2                |  ------   |
                          | | MDSC |  |
                          |  ------   |
                          |     :     |
                          |  -------  |
                          | |  PNC  | |
                          |  -------  |
                           \ :  :  : /
Нижележащий                 \v  v  v/
сетевой                      X--Y--Z
уровень

--- канал
=== виртуальный канал

Рисунок 10. Рекурсия VN с сетевыми уровнями.

6. Точки доступа и точки доступа виртуальных сетей

Для отображения идентификации соединений между сайтами клиента и сетями TE, а также охвата связности, запрошенной в VNS элементы CNC и MDSC указывают соединения с использованием AP, как показано на рисунке 11.

                 -------------
                (             )
               -               -
+---+ X       (                 )      Z +---+
|CE1|---+----(                   )---+---|CE2|
+---+   |     (                 )    |   +---+
       AP1     -               -    AP2
                (             )
                 -------------

Рисунок 11. AP с точки зрения клиента.


Рассмотрим в качестве примера вариант, показанный на рисунке 11. CE1 подключается к сети через канал 10 Гбит/с, а CE2 – через канал 40 Гбит/с. До создания какой-либо VN между AP1 и AP2 представление клиента можно описать рисунком 12.

      +----------+------------------------+
      | Endpoint | Полоса канала доступа  |
+-----+----------+----------+-------------+
|AP id| CE,port  | MaxResBw | AvailableBw |
+-----+----------+----------+-------------+
| AP1 |CE1,portX | 10 Гбит/с|  10 Гбит/с  |
+-----+----------+----------+-------------+
| AP2 |CE2,portZ | 40 Гбит/с|  40 Гбит/с  |
+-----+----------+----------+-------------+

Рисунок 12. AP с точки зрения клиента.


Топология с точки зрения оператора оператора показана на рисунке 13.

          -------            -------
         (       )          (       )
        -         -        -         -
   W  (+---+       )      (       +---+)  Y
-+---( |PE1| Dom.X  )----(  Dom.Y |PE2| )---+-
 |    (+---+       )      (       +---+)    |
 AP1    -         -        -         -     AP2
         (       )          (       )
          -------            -------

Рисунок 13. AP с точки зрения оператора.


Его можно представить в виде таблицы, показанной на рисунке 14.

      +----------+------------------------+
      | Endpoint | Полоса канала доступа  |
+-----+----------+----------+-------------+
|AP id| PE,port  | MaxResBw | AvailableBw |
+-----+----------+----------+-------------+
| AP1 |PE1,portW | 10 Гбит/с|  10 Гбит/с  |
+-----+----------+----------+-------------+
| AP2 |PE2,portY | 40 Гбит/с|  40 Гбит/с  |
+-----+----------+----------+-------------+

Рисунок 14. AP с точки зрения оператора.


Точка доступа виртуальной сети (VNAP) должна определяться как привязка между AP и VN. Это позволяет разным VN начинаться в одной AP, а также обеспечивает возможность организации трафика на каналах доступа и/или междоменных каналах (например, отслеживание выделенной полосы). В AP создаются свой VNAP для каждой сети VN.

В этом простом варианте предположим создание двух виртуальных сетей. Первая VN с идентификатором 9 между AP1 и AP2 имеет пропускную способность 1 Гбит/с, а вторая VN с идентификатором 5 между теми же AP1 и AP2 имеет полосу 2 Гбит/с.

Представление оператора будет меняться, как показано на рисунке 15.

          +----------+------------------------+
          | Endpoint | Канал доступа/VNAP Bw  |
+---------+----------+----------+-------------+
|AP/VNAPid| PE,port  | MaxResBw | AvailableBw |
+---------+----------+----------+-------------+
|AP1      |PE1,portW | 10 Гбит/с|   7 Гбит/с  |
| -VNAP1.9|          |  1 Гбит/с|       -     |
| -VNAP1.5|          |  2 Гбит/с|       -     |
+---------+----------+----------+-------------+
|AP2      |PE2,portY | 40 Гбит/с|   37 Гбит/с |
| -VNAP2.9|          |  1 Гбит/с|       -     |
| -VNAP2.5|          |  2 Гбит/с|       -     |
+---------+----------+----------+-------------+

Рисунок 15. Представление оператора для AP и VNAP после создания VNS.

6.1. Двудомный вариант

Зачастую используется двудомное соединение между CE и парой PE. Этот вариант должен поддерживаться определением VN, AP и VNAP. Предположим, что CE1 подключен к двум PE в домене оператора через AP1 и AP2, а клиенту нужна пропускная способность 5 Гбит/с между CE1 и CE2 (рисунок 16).

                ____________
        AP1    (            )    AP3
       -------(PE1)      (PE3)-------
    W /      (                )      \ X
+---+/      (                  )      \+---+
|CE1|      (                    )      |CE2|
+---+\      (                  )      /+---+
    Y \      (                )      / Z
       -------(PE2)      (PE4)-------
        AP2    (____________)

Рисунок 16. Двудомный вариант.

В этом случае клиент будет запрашивать VN между AP1, AP2 и AP3 указывая двудомное подключение CE1 через AP1 и AP2. В результате между AP1 и AP2 трафик передаваться не будет. Двудомное подключение будет отображаться на VNAP (поскольку другие VN также могут использовать AP1 и AP2 в качестве конечных точек).

Клиентское представление показано на рисунке 17.

          +----------+------------------------+
          | Endpoint | Канал доступа/VNAP Bw  |
+---------+----------+----------+-------------+-----------+
|AP/VNAPid| CE,port  | MaxResBw | AvailableBw | Двудомный |
+---------+----------+----------+-------------+-----------+
|AP1      |CE1,portW | 10 Гбит/с|   5 Гбит/с  |           |
| -VNAP1.9|          |  5 Гбит/с|      -      | VNAP2.9   |
+---------+----------+----------+-------------+-----------+
|AP2      |CE1,portY | 40 Гбит/с|   35 Гбит/с |           |
| -VNAP2.9|          |  5 Гбит/с|      -      | VNAP1.9   |
+---------+----------+----------+-------------+-----------+
|AP3      |CE2,portX | 50 Гбит/с|  45 Гбит/с  |           |
| -VNAP3.9|          |  5 Гбит/с|      -      |   нет     |
+---------+----------+----------+-------------+-----------+

Рисунок 17. Представление клиентом двудомного случая после создания VN.

7. Расширенное применение ACTN для множества клиентов

Более сложным приложением ACTN является выбор центра обработки данных (DC21), когда клиент должен выбрать DC на основе состояния сети (это называется Multi-Destination Service [ACTN-REQ]). С точки зрения ACTN контроллер CNC может запросить VNS между AP на стороне отправителя и получателя и отправить ее в сеть (MDSC) для выбора AP на стороне отправителя и получателя, используемых при организации VNS. Список AP-кандидатов определяется CNC (или иным элементом вне ACTN) на основе критериев, выходящих за рамки ACTN.

На основе выбора AP сделанного и возвращенного сетью (MDSC), CNC (или элемент вне ACTN) должен принять решение о последующих действиях, таких как координация или требования к организации сервиса. Эти действия выходят за рамки ACTN.

Рассмотрим пример, показанный на рисунке 18, где доступны три DC, но клиенту нужно выбрать между ними на основе состояния сети и организации соединения между AP1 (CE1) и одним из получателей (AP2 (DC-A), AP3 (DC-B), AP4 (DC-C)). MDSC (вместе с PNC) будет выбирать лучшую целевую AP на основе ограничений, критериев оптимизации, политики и т. п., а затем организовывать соединение (виртуальную сеть).

                -------            -------
               (       )          (       )
              -         -        -         -
+---+        (           )      (           )        +----+
|CE1|---+---(   Домен X   )----(   Домен Y   )---+---|DC-A|
+---+   |    (           )      (           )    |   +----+
         AP1  -         -        -         -    AP2
               (       )          (       )
                ---+---            ---+---
                   |                  |
               AP3-+              AP4-+
                   |                  |
                +----+              +----+
                |DC-B|              |DC-C|
                +----+              +----+

Рисунок 18. Выбор конечной точки на основе состояния сети.

7.1. Запланированный перенос конечной точки

Кроме того, в случае выбора DC клиент может запросить выбор резервного DC, чтобы в случае отказа он мог обеспечить защиту в режиме «горячего резервирования». Как показано на рисунке 19, DC-C выбран резервным для DC-A. Таким образом, следует организовать VN с помощью MDSC для создания основного соединения между AP1 (CE1) и AP2 (DC-A), а также резервного соединения между AP1 (CE1) и AP4 (DC-C).

                 -------            -------
                (       )          (       )
               -         -    __  -         -
+---+         (           )      (           )        +----+
|CE1|---+----(   Домен X   )----(   Домен Y   )---+---|DC-A|
+---+   |     (           )      (           )    |   +----+
        AP1    -         -        -         -    AP2    |
                (       )          (       )            |
                 ---+---            ---+---             |
                    |                  |                |
                AP3-|              AP4-|         HOT STANDBY
                    |                  |                |
                 +----+             +----+              |
                 |DC-D|             |DC-C|<-------------
                 +----+             +----+

Рисунок 19. Запланированный перенос конечной точки.


7.2. Перемещение конечной точки «на лету»

По сравнению с запланированным переносом конечной точки выбор точки «на лету» происходит динамически в том смысле, что он не планируется заранее, а определяется условиями в сети. В этом случае MDSC будет отслеживать состояние сети (на основе VN SLA) и информировать CNC, если следует выбрать другую целевую AP в соответствии с параметрами сети. CNC следует инструктировать MDSC, когда переключать VN на другую AP, если этот требуется.

8. Вопросы управляемости

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

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

  • управление внешними протоколами ACTN;

  • управление внутренними интерфейсами и протоколами ACTN;

  • администрирование и мониторинг компонент ACTN;

  • настройка правил для применения в системе ACTN.

Схема и интерфейсы ACTN определены для обеспечения возможности организации трафика виртуальных сетевых служб и услуг связности. Операторы могут иметь другие задачи OAM22 для поддержки сервиса, оптимизации и гарантий за пределами организации трафика. Реализация OAM за пределами абстракции и управления сетями TE не рассматривается в этом документе.

8.1. Правила

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

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

  • Локальная политика может ограничивать число, тип, размер и планирование виртуальных сетей, которые клиент может запросить через свой CNC. Этот тип политики реализуется локально в MDSC.

  • Глобальная политика может ограничивать некоторых клиентов (или приложения) использованием лишь определенных MDSC, а также ограничивать типы физических сетей, управляемые PNC. Этими правилами будет управлять агент глобальной политики.

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

8.2. Правила, применяемые к контроллеру сети абонента

Услуги виртуальных сетей для клиентских приложений будет запрашивать CNC в соответствии с потребностями приложения и конкретного сервиса, включая пропускную способность, тип трафика и живучесть. Кроме того, доступ приложения и тип услуг VN, запрошенные CNC, должны будут соответствовать определенной политике доступа.

8.3. Правила, применяемые к многодоменному координатору услуг

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

После разрешения услуга VN организуется через интерфейс CNC-MDSC (CMI) и будет отражать запросы клиентских приложений и связности, а также конкретные требования к доставке сервиса. У CNC и MDSC будут согласованные конечные точки и их использование следует выражать правилами при организации или добавлении услуг VN. Гарантия того, что разрешенные конечные точки определены до CNC и приложений будет требовать от MDSC поддержки реестра разрешенных точек подключения для CNC и типов приложений.

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

8.4. Правила, применяемые к контроллеру обеспечивающей сети

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

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

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

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

Описанная здесь модель ACTN определяет основные компоненты и интерфейсы для управляемых сетей TE. Защита запросов и контроля ресурсов, конфиденциальность информации и доступность функций должны быть важными аспектами безопасности при развертывании и эксплуатации платформ ACTN.

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

Дальнейшее обсуждение вопросов безопасности ACTN разделено на две категории, описанные ниже.

  • Интерфейс между CNC и MDSC (интерфейс CNC-MDSC или CMI).

  • Интерфейс между MDSC и PNC (интерфейс MDSC-PNC или MPI).

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

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

9.1. Интерфейс CNC-MDSC (CMI)

Данные, хранящиеся в MDSC, могут раскрывать детали услуг VN, а также использования ресурсов клиентами, приложениями и CNC. Поэтому целесообразно рассмотреть вопрос шифрования таких данных.

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

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

9.2. Интерфейс MDSC-PNC (MPI)

Когда MDSC должен взаимодействовать с множеством (распределенных) PNC, предлагается использовать механизмы на основе PKI, такие как организация соединений TLS или HTTPS между MDSC и PNC для обеспечения доверия между компонентами уровня управления физической сетью и MDSC. Доверенные привязки для PKI можно настроить на применение меньшего (потенциально не пересекающегося) набора удостоверяющих центров (CA), нежели в Web PKI.

MDSC, куда PNC экспортирует топологические данные, и уровень детализации (полные или абстрагированные) также следует аутентифицировать и настроить соответствующие ограничения доступа и представления топологии или задавать их на основе правил.

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

Этот документ не требует действий со стороны IANA

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

[ACTN-REQ] Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, “Requirements for Abstraction and Control of TE Networks”, Work in Progress, draft-ietf-teas-actn-requirements-09, March 2018.

[ACTN-YANG] Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., Yoon, B., Wu, Q., and P. Park, “A Yang Data Model for ACTN VN Operation”, Work in Progress, draft-ietf-teas-actn-vn-yang-01, June 2018.

[ONF-ARCH] Open Networking Foundation, “SDN Architecture”, Issue 1.1, ONF TR-521, June 2016.

[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J. McManus, “Requirements for Traffic Engineering Over MPLS”, RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>.

[RFC3945] Mannie, E., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture”, RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.

[RFC4655] Farrel, A., Vasseur, J., and J. Ash, “A Path Computation Element (PCE)-Based Architecture”, RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile”, RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.

[RFC7149] Boucadair, M. and C. Jacquenet, “Software-Defined Networking: A Perspective from within a Service Provider Environment”, RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, “Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks”, BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>.

[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, “An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control”, RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>.

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

[TE-TOPO] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, “YANG Data Model for Traffic Engineering (TE) Topologies”, Work in Progress, draft-ietf-teas-yang-te-topo-18, June 2018.

Приложение A. Пример функций MDSC и PNC в оркестраторе

Абонент
            +-------------------------------+
            |    +-----+                    |
            |    | CNC |                    |
            |    +-----+                    |
            +-------|-----------------------+
                    |
Оркестратор         | CMI
сервиса/сети        |
            +-------|------------------------+
                    |    +------+   MPI   +------+   |
                    |    | MDSC |---------| PNC2 |   |
                    |    +------+         +------+   |
                    +-------|------------------|-----+
                            | MPI              |
Контроллер домена   |                  |
            +-------|-----+            |
            |   +-----+   |            | SBI
            |   |PNC1 |   |            |
            |   +-----+   |            |
            +-------|-----+            |
                    v SBI              v
                 -------            -------
                (       )          (       )
               -         -        -         -
              (           )      (           )
             (   Домен 1   )----(   Домен 2   )
              (           )      (           )
               -         -        -         -
                (       )          (       )
                 -------            -------


В этом приложении представлен пример возможного варианта развертывания, где координатор сервиса/сетей (Service/Network Orchestrator) может включать функциональность PNC для домена 2 и функциональность MDSC.

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

Adrian Farrel

Old Dog Consulting

Email: adrian@olddog.co.uk

Italo Busi

Huawei

Email: Italo.Busi@huawei.com

Khuzema Pithewan

Peloton Technology

Email: khuzemap@gmail.com

Michael Scharf

Nokia

Email: michael.scharf@nokia.com

Luyuan Fang

eBay

Email: luyuanf@gmail.com

Diego Lopez

Telefonica I+D

Don Ramon de la Cruz, 82

28006 Madrid

Spain

Email: diego@tid.es

Sergio Belotti

Nokia

Via Trento, 30

Vimercate

Italy

Email: sergio.belotti@nokia.com

Daniel King

Lancaster University

Email: d.king@lancaster.ac.uk

Dhruv Dhody

Huawei Technologies

Divyashree Techno Park, Whitefield

Bangalore, Karnataka 560066

India

Email: dhruv.ietf@gmail.com

Gert Grammel

Juniper Networks

Email: ggrammel@juniper.net

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

Daniele Ceccarelli (редактор)

Ericsson

Torshamnsgatan, 48

Stockholm

Sweden

Email: daniele.ceccarelli@ericsson.com

Young Lee (редактор)

Huawei Technologies

5340 Legacy Drive

Plano, TX 75023

United States of America

Email: leeyoung@huawei.com


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

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

nmalykh@protokols.ru

1Traffic Engineered.

2Abstraction and Control of TE Networks.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

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

6Software-Defined Networking.

7Path Computation Element – элемент расчета пути.

8Abstraction and Control of TE Networks – абстрагирование и управление в сетях TE.

9Network element.

10Virtual Network Service.

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

12Operations Support System – система поддержки операций.

13Network Management System – система управления сетью.

14Element Management System – система управления элементами сети.

15Higher-level MDSC – MDSC верхнего уровня.

16Lower-level MDSC – MDSC нижнего уровня.

17Multiprotocol Label Switching – многопротокольная коммутация по меткам.

18Optical Transport Network – оптическая транспортная сеть.

19Wavelength Division Multiplexing – мультиплексирование по длине волны.

20Wavelength Switched Optical Network – сеть с коммутацией по длине волны.

21Data center.

22Operations, Administration, and Maintenance – операции, администрирование и поддержка.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.