Широкополосный доступ с поддержкой SDN в базовых телекоммуникационных сетях

РЕФЕРАТ

Магистерская диссертация содержит: 86 страниц, 34 рисунков, 16 таблиц, 20 ссылок.

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

Цель. Исследовать принцип работы системы повышения эффективности архитектуры разработки решений для операторского широкополосного доступа Объект исследования : сеть SDN

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

Ключевые слово : SDN, OpenFlow ,маршрутизатор, SEBA

СОДЕРЖАНИЕ

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

API интерфейс прикладного программирование SDN Software Defined Networks/Networking vRouter Virtual Router

NGN Next Generation Network

ASG Агрегация да сервисный шлюз

BBF Broadband Forum

BMC Контроллер управление советом

BNG Широкополосный сетевой шлюз CAP Carrier Automation Platform

CI/CD Непрерывная интеграция/Непрерывная доставка

CORD Центральный офис Перезарегистрирован как центр обработки данных

CUPS управления и разделения плоскости пользователя DOCSIS Data Over Cable Service Interface Спецификация DPU Distribution Point Unit

EPON Пассивная оптическая сеть Ethernet

FCAPS Управление неисправностями, конфигурация, учет, производительность да безопасность

FWA Фиксированный беспроводной доступ

NBI Интерфейс NorthBound

NEM Посредник сетевых краев

NFV Виртуализация сетевой и функции

NG-PON2 Пассивная оптическая сеть следующего поколение 2 OLT Терминал оптической линии OLT

ONAP Открытая платформа автоматизации сети ONOS Открыта сетевая операционная система ONT Оптический сетевой терминал

ONU Оптический сетевой блок

OSS Подсистема операций

PNF Физическая функция сетей

POD Точка доставки

PON Пассивная оптическая сеть

RD Эталонный дизайн

SDN Программно-определенные сети

SEBA Широкополосный доступ с поддержкой SDN

VOLTHA Виртуальная оптическая линия терминала оборудования DSL Цифровая абонентская линия

ВВЕДЕНИЕ

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

Поэтому в течении последних нескольких лет разрастает популярность программно -конфигурирующих сетей с применением протокола OpenFlow.

Главной задачей программно-конфигурирующей сети есть разделение уровня приложений от уровня управление, да разделение уровня управление от уровня передачи данных. Благодаря этом возникает возможность упрощение сложности физических устройств. Выполнение всех логических функций переносится на высший уровень . Такой подход позволяет удешевить физические устройства, улучшить надежность системы и упрощение управления сетью. В программно- конфигурирующих сетях отпадает потребность в использованы маршрутизаторы, ведь эту роль берет на себя мозг сети-контроллер [1]

РАЗДЕЛ 1

АНАЛИЗ НАПРАВЛЕНИЯ РАЗВИТИЯ ТЕЛЕКОММУНИКАЦИОННОЙ СЕТИ

NGN(сеть следующего поколение) - сеть с коммутацией пакетов, пригодна для предоставление телекоммуникационных услуг да использование множества широкополосных транспортных технологий [2].

С развитием телекоммуникационных услуг стали все более популярными обсуждение различных вариантов архитектуры сети NGN, сочетающие в единую структуру сети мобильной связи, ресурсы сети интернет и т.д. Особым чертой модели, предложенной сектором стандартизации электросвязи ITU-T, есть функциональный распределение на два уровни : услуг и транспортный (рис 1.1). Уровень услуг выполняет прикладные функции, например организацию передачи языка, видеоизображения или их комбинации. Транспортный уровень выполняет функции доставки информации разных типов между абонентами сети NGN на данный время большого распространение приобрела четырехуровневая архитектура

NGN, в какой уровень услуг да транспортный уровень заменили такие уровни как:

Традиционная модель (рис. 1.2) предполагает , что платформы для предоставление услуг будут подключаться к сети за помощью стандартных интерфейсов ЗКС№ 7 , SIP, Parlay, H.323

Однако при внедрении сети NGN в эксплуатацию возникнет ряд недостатков таких как :

Именно или , да другие факторы стали главной причиной поиска другого решение реализации сети операторов Серверы обеспечивают само предоставление услуг, которые могут находиться как внутри, так и за пределами самой сети (веб- серверы, серверы, принадлежащие ASP-провайдерам). Важной составляющей уровня управление услугами также есть информационные центры или центры управление услугами (data centers, services control point) - это собственные информационные ресурсы сети, на основе которых осуществляется обслуживание пользователей. У таких центрах может сохраняться информация двух типов:

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

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

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

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

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

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

Сеть доступа, как и NGN в целом, может состоять из нескольких уровней. Коммутаторы, установлены в узлах нижнего уровня , мультиплексируют информацию, что поступает по многочисленных абонентских каналах (что часто называются абонентскими окончаниями, local loop), и передают ее коммутаторам верхнего уровня, чтобы те, в свою очередь, передали ее коммутаторам транспортного уровня Количество уровней сети доступа зависит от ее размера; небольшая сеть доступа может состоять из одного уровня, а большая — из двух- трех. Следующие уровни осуществляют дальнейшее концентрацию трафика, собирая его и мультиплексируя в более скоростные каналы.

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

Сети следующего поколение (NGN) представляют собой новую

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

Программно-конфигурированные сети SDN (Software Defined Network) изменяют подход к проектирование и администрирование сетей. Во-первых, SDN отделяет плоскость управление сетью (Control plane), какая занимается маршрутизацией трафика от плоскости передачи данных (Data plane), передающая трафик согласно с правилам, полученным от плоскости управление. Во-вторых , SDN

«консолидирует» плоскость управление, при этом один комплекс управляющих программ на сервере управляет многими устройствами на плоскости данных. Для этого используется стандартизированный интерфейс прикладного программирование API (Application Programming Interface). Это, например, такой интерфейс, как OpenFlow. Соответственно, для того, чтобы построить сеть SDN, на сетевых элементах, прежде за все, коммутаторах и маршрутизаторы, должна быть реализована поддержка OpenFlow. При этом на каждом из них есть таблица, или таблицы, правила маршрутизации. Каждое правило определяет, как маршрутизировать пакеты определенной сессии или потока трафика

Несмотря на то, что концепция SDN стала распространена в последние годы, сама идея довольно ненова, и эволюционирует уже больше 20 лет. Ее следы можно проследить даже в развития ранних телефонных сетей на базе коммутации каналов, когда управление сетью (сигнализация) было отделено от сети канальной коммутации речевого трафика. И это было сделано ровно с той же целью, что и в SDN - чтобы упростить управление и введение новых услуг. Концепция

«программных коммутаторов» Softswitch для телекоммуникационных сетей на базе коммутации пакетов также очень близкая к SDN за функциями и реализации

В основе концепции SDN развивается открытый стандарт OpenFlow - стандарт , определен фондом ONF (открыт фонд сетевых технологий ). Это открытый стандартный протокол связи, какой лежит в основе программно управляемых сетей (SDN). Интерфейс OpenFlow предоставляет доступ и связь между уровнями управления и инфраструктуры архитектуры SDN, как физической , так и виртуальной. Благодаря централизации управление устройствами уровня инфраструктуры OpenFlow упрощает управление сетью и расширяет возможности программирование

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

В теории концепция программно-конфигурирующих сетей имеет много преимуществ:

Выводы :

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

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

РАЗДЕЛ 2

СТРУКТУРА И ОСНОВНЫЕ ЭЛЕМЕНТЫ СЕТЬ SDN

2.1 Структура сети SDN.

Программно-конфигурирующие сети на данное время представляют новую архитектуру постройки сети, которая разделяет в себе управление да передачу трафика . Организация «Open Networking Foundation (ONF)» занимает лидирующее позицию в стандартизации SDN.

Архитектуру сети SDN логично можно разделить на три уровни [7 ]: прикладной уровень, уровень управление и сетевой уровень сетевых служб. Или решение в основном есть программными приложениями, которые взаимодействуют с контроллером. Открытые интерфейсы API ссылаются на программные интерфейсы между программными модулями контроллера и приложениями SDN. Или интерфейсы есть открытыми для клиентов, партнеров да сообщества с открытым выходным кодом для развития да модификации. Прикладной уровень охватывает большую количество приложений для удовольствие различных потребностей клиентов, таких как автоматизация сети, гибкость и программируемость тому подобное. Некоторые домены программ SDN включают инженерию трафика, виртуализацию сети, мониторинг и анализ сети, исследование сетевых служб, контроль доступа тому подобное. Логика управление для каждого экземпляра программы может быть запущена как отдельный процесс непосредственно на аппаратном обеспечении контроллера в каждому домены . Общая архитектура сети SDN .

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

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

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

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

показаны на рис.1.2 да рис.1.3 :

Рис.2.2 Традиционная сеть Рис.2 .3 Сеть по использованию

SDN

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

При построении сети SDN используется ограниченный набор элементов.

Основными есть коммутатор и контроллер.

2.2. Структура контроллера SDN

Контроллеры в программный сети является главным «мозгом» сети. Или приложения, которые выступают в качества стратегического контрольного точки в сети SDN, управляет потоками для коммутаторов, маршрутизаторов приложений и бизнес- логики для развертывание интеллектуальных сетей . В последний время контроллеры получили способность соединять между доменами SDN Controller, используя интерфейсы приложений , такие как открытая база данных коммутаторов да OpenFlow.

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

Одним из наиболее известным протоколом, используемым в сети SDN, есть протокол OpenFlow.

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

на рисунка 2.4 изображено место разных контролеров программн- конфицирующей сети в ее архитектуре .

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

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

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

Следует указать, что канал SDN используется для передачи только управляющей информации . Это может быть, например [3]: заявка от МП-SDN к контроллеру на поиск маршрута для пакета, который нету необходимых данных в таблицы маршрутизации

Канал протокола SDN может работать через прямое соединение между сетевым устройством SDN и контроллером SDN или косвенное соединение через множество узлов в сети. Физические соединения, поддерживающие канал SDN, могут быть соединениями LAN, WAN-соединениями, проводными, оптическими или беспроводными соединениями и т.д.

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

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

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

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

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

Рис. 2.6. Основные компоненты коммутатора OpenFlow.

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

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

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

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

Контроллер OpenFlow служит блоком управление для вычисление маршрутов и распределения данных в OpenFlow коммутаторы, отвечающие за переадресацию пакетов на основе полученных записей потоков [7].

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

Рис. 2.7 Составляющие OpenFlow коммутатора.

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

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

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

OpenFlow коммутатор должен поддерживать 3 типа стандартных портов OpenFlow [7]:

с физическими портами, да могут быть реализованы за помощью таких технологий, как агрегация порты, туннельные интерфейсы или loopback-интерфейсы. Коммутаторы OpenFlow подключаются друг к другу логически через порты OpenFlow. Пакеты OpenFlow поступают на входной порт, Дальше пакеты проходят через конвейерную обработку , и могут быть переданы на выходной порт .

Таблица потоков для коммутатора OpenFlow последовательно пронумерована, начиная с 0. Когда пакет передается в первую таблицу потоков, то выбирается соответствие с наивысшим приоритетом, а набор инструкций отвечает, будет направлять пакет к следующей таблицы потоков, и процесс обработки пакета повторится снова (рисунок 2.8). Если инструкция не направляет пакет к следующей таблице, конвейерная обработка останавливается и над пакетом будет выполнена соответствующая действие , если она установлена.

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

Рис. 2.8 Поток пакетов через конвейерную обработку OpenFlow.

Если есть метаданные, определены для обработки следующей таблицей потоков, то пакет будет перенаправлен в следующую таблицу потоков, повторно

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

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

Таблица потоков есть основным элементом протокола OpenFlow. Каждый запись таблицы потоков содержит следующие элементы (рисунок 2.9):

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

Рис. 2.9. Основные компоненты записи потока в таблицы потоков.

Поля match fields и priority используются для идентификации соответствующих записей таблицы потоков.

На сегодняшний день нет однозначного решения о том, какой протокол и где целесообразно использовать OpenFlow или OF-CONFIG? Рассмотрим которые Задача и каким образом или Протоколы решают.

Стандарт OpenFlow, создан в 2008 году, был признан первой архитектурой SDN, какая определила, как элементы управление и плоскости данных будут разделены и взаимодействовать один с одним за помощью протокола OpenFlow. Open Network Foundation (ONF) есть органом , ответственным за управление стандартами OpenFlow, являющимися открытым исходным кодом . Архитектура контроллера OpenFlow составляется с нескольких уровней, каждый с которых отвечает за ряд необходимых функциональных возможностей

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

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

Дополнительно к поле в , уже описанным н а рис.2.12 , заголовок на рис.2.13 включает в себя поле версии протокол в OpenFlow (OFP), какое указа есть, что сообщение ответ есть OFP, а также может указывать версию OFP, используемый в, и поле ID транзакции, которое указа есть номер транзакции для сообщения. Сообщение включается есть в себя полезное нагрузка, что включая есть минимум одно сообщение о состояние системы.

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

Протоколом OFCONFIG (OpenFlow Management and Configuration Protocol) предусмотренные следующие абстракции (Рис 2.14):

Протокол OF-CONFIG используется для решение следующих задач:

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

Протокол OF-CONFIG представляет OpenFlow коммутатор как абстракцию - логический коммутатор (Logical Switch), при этом одно физическое устройство может содержать несколько Logical Switch, которые отвечают за пересылку потока данных различных элементов сети – Logical Switch Capabilities. В общем случае взаимодействие между уровнем управление и уровнем передачи данных осуществляется на основе двух протоколов:

на рис.2.14 представлена схема взаимодействия разных частей системы конфигурации и управление переключателем.

Протокол OpenFlow предполагает, что коммутатор OpenFlow (например, коммутатор Ethernet, поддерживающий протокол OpenFlow) с разными параметрами, такими как IP-адреса контролеров OpenFlow.

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

работает на интервал времени потока , есть пока потоки прилагаются или удаляются. При этом, OF - CONFIG работает на более медленном интервалы времени. Примером есть построение таблиц пересылка и принятие решений о действия пересылка, которые выполняются по протокола Openflow. Или под время включение

/ выключение порта, когда не нужно решать задачу в интервалы времени прохождение потока и, следовательно , может выполняться по протокола - OF - CONFIG.

Выводы :

РАЗДЕЛ 3

СОВРЕМЕННЫЕ ПЛАТФОРМЫ ПОСТРОЕНИЯ СЕТЬ SDN

3.1 Построение сети SDN с использование платформы SEBA

SEBA - это платформа широкополосного доступа на сети SDN.

SEBA поддерживает как жилой доступ, так и беспроводной обратная связь и оптимизирован таким образом, что трафик может проходить по «скорой дорожке» прямо к магистрали, нет требуя обработки VNF на сервере [9].

Рис. 3.1 программное обеспечение SEBA

Как показано на рисунка 3.1, SEBA есть объединением проектов , таких как VOLTHA, ONOS и TRELLIS.

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

Теперь рассмотрим по отдельности три проекта VOLTHA, ONOS и TRELLIS

ONOS

ONOS - контроллер SDN, какой может управлять VOLTHA и Trellis .

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

Рис. 3.2 Архитектура ONOS

VOLTHA - абстракция виртуального оборудование для широкополосного доступа в пределах жилой CORD

VOLTHA: абстрактный PON для поддержки Ethernet, какой может контролироваться контролером.

на рисунку показано, как в VOLTHA, API отображаются на общую модель основных данных с помощью адаптеров к югу. на своей южной стороне, VOLTHA общается с устройствами PON через специальные поставщики или адаптеры OLT да ONU [10].

(общая система контроля да управление, что делится всеми OLT да ONU)

Рис 3.3 Архитектура VOLTHA

VOLTHA имеет адаптеры, адаптеры есть достаточно сложными, полноценными

модулями , что реализуют ядро управление устройствами PON.

В своем северном интерфейсе VOLTHA резюмирует сеть PON, чтобы она отображалась как программируемый переключатель Ethernet на контроллер SDN.

VOLTHA northbound – в своем северном интерфейсе VOLTHA резюмирует сеть PON, чтобы она отображалась как программируемый переключатель Ethernet на контроллер SDN.

VOLTHA southbound adapter - на своей южной стороне VOLTHA общается с аппаратными устройствами PON, используя специфические протоколы протоколов через адаптеры OLT и ONU

Trellis

Trellis предоставляет сетевым оператором ряд преимуществ SDN сравнительно с традиционным сетевым управлением.

Рис 3.4 Архитектура Trellis

Trellis использует контроллер SDN (ONOS), отсоединенный от оборудование аппаратной плоскости. В этом дизайне набор приложений, что работают на ONOS,

реализует все функциональные возможности да функции ткани, такие как коммутация Ethernet, маршрутизация IP, многоадресная передача, тому подобное .[12]

Архитектура Trellis внутренне использует такие понятия маршрутизации сегмента (SR), как глобально значимые метки MPLS(MPLS это метод маркировки пакетов, который устанавливает приоритетность данных), которые присваиваются каждому переключателю листья и позвоночника. Это минимизирует состояние меток в сети по сравнению с традиционными сетями MPLS, где метки, имеющие местное значение, нужно менять на каждом узле. В Trellis переключатели листов выдвигают ярлык MPLS, что обозначает пункт назначение ToR (Leaf) на трафик IPv4 или IPv6.

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

Как показано на рисунка 3.5 SEBA складывается с нескольких программных модулей высокого уровня, включая:

Рис .3.5 Диаграмма целевой архитектуры

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

Диаграмма целевой архитектуры требует соблюдение некоторых принципов и определений:[11]

В SEBA Pod есть оборудование OLT да ONU, управляемое VOLTHA, какое управляет сетью PON, и контроллер SDOS ONOS, какой включает в себя пара api / приложений, которые открывают услуги, что предоставляются PON. Например, OLT подключается к пары выключателей AGG, части ткани или листовой части позвоночника, какими также будет управлять контроллер SDN. Затем оборудование коммутаторов может подключаться к внешних маршрутизаторов да / или BNG, к локальных компьютеров тому подобное.

Одной с особенностей, что делает SEBA отличной от R-CORD, есть то, что трафик платы данных для абонента просто проходит через аппаратное обеспечение и выходит в Интернет. Это создает абонентский трафик "скорым путем" к Интернет. Путь данных остается аппаратным и выходит только для вычисление узлов, когда это необходимо, например, когда для определенных абонентов предоставляются посторонние услуги. Для сравнение , в R-CORD трафик, что поступает от резидентного абонента, проходит через аппаратное обеспечение, но потом он переходил к вычисление узлов через виртуальный коммутатор, как OVS, да посещает контейнер VSG (Virtual Subscriber Gateway), а потом возвращается назад в аппаратное обеспечение да в Интернет

Также можно сказать , что SEBA - это эталонный дизайн, основанный на варианте R-CORD. Рассмотрим , что же себя приставляет R-CORD.

R-CORD

R-CORD – это решение с открытым кодом, основанное на платформе CORD для предоставления сверхширокополосных жилищных услуг. R-CORD превращает край сети оператора в ловкую платформу предоставление услуг , что разрешает оператору

обеспечить лучший опыт для конечных пользователей вместе с инновационными услугами нового поколение. [18]

Хотя для физического подключение абонентов (через GPON, DOCSIS или подобное) необходимое специализированное оборудование для доступа, проект VOLTHA уводит даже это оборудование специального назначение, чтобы сделать его управляемым как управляемый ресурс OpenFlow.

R-CORD также включает в себя виртуальный шлюз абонентов (vSG) и использует основной сетевой сервис - виртуальный маршрутизатор (vRouter); первый реализуется контейнером, какой привязан к каждого абонента, а последний - управляющее приложение ONOS.

Рассмотрим их более подробно:

Аналитика для CORD

Цели этой инициативы:

Основными особенностями A-CORD есть:

Информацию о общую архитектуру можно Найти в A- CORD_Architecture и в примечании проектирования CORD - Служба мониторинга CORD

Служба мониторинга - компоненты программного обеспечение

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

Рис. 3 .6: Служба мониторинга как услуга многопользователя внутри

CORD

Обычно компоненты "Service Controller" запускаются как часть платформы XOS на головном узле, а "Service Examences", которые реализуют Службу, будет инстанцироваться на кластеры CORD Компьютер.

"Контроллер обслуживание" складывается из:

Рис. 3.7: Контроль сервисного контроллера да экземпляров обслуживание

Когда служба мониторинга инициируется через API XOS TOSCA или REST, "Контроллер обслуживание" закручивает экземпляры виртуальных машин службы мониторинга на узле вычисление.

Экземпляры виртуальной машины службы мониторинга запускаются с использованием предварительно встроенного изображения, как определено в "Собственно изображение экземпляра службы мониторинга службы"

Просмотр на высоком уровни разных программных компонентов, что работают в службе мониторинга экземпляра:

Рис. 3.8: Мониторинг компонентов служебного экземпляра

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

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

Модель развертывания

Текущий релиз CORD поддерживает развертывание всех компонентов службы мониторинга в одной машине управления , как показано ниже:

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

M-CORD

M-CORD - это базовое решение с открытым кодом для операторов, что развертывают мобильные беспроводные сети 5G. Это облачное решение, построенное на SDN, NFV да облачных технологиях. Она включает в себя как виртуализацию функций RAN, так и виртуализированное мобильное ядро (vEPC) для обеспечения возможности мобильных приложений да инновационных сервисов за помощью архитектуры микроуслуг.

Текущая мобильная инфраструктура:

независимой масштабируемости

Услуги Edge Multi-Access для индивидуальных служб да улучшенного QoE

ODTN

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

ODTN даст возможность оптимизированной экологической системы

«периферийных устройств», которая позволяет совмещать несколько компонентов да встраивать их в комплексные решение. Поставщики могут сосредоточиться на создании конкретного компонента (например, транспондера), нет строя полного решение, что приводит к ускоренных инноваций да снижение затрат. Операторы будут иметь свободу выбора компонентов лучшего класса да избегать блокировка поставщиков , тем самим получая гибкость в меру рост потребностей их сети.[14]

Рис. 3.9 ODTN Архитектура

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

Используя контроллер ONOS SDN, ODTN автоматически да прозрачно откроет расчлененные компоненты и будет контролировать всю транспортную сеть как единое целое, тем самым давая возможность выбора многих поставщиков. ODTN полагается на открытые отраслевые стандарты, такие как TAPI (транспорт API) и OpenConfig, чтобы достичь действительно нейтрального для поставщиков решения. Проект и ODTN начнется с относительно простых систем открытой линии "точка- точка" к более сложных сетевых сценариев , и закончится сетевым сеть, что складывается с расчлененного оптического оборудования

MININET

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

Mininet предлагает расширяемый API Python для создание сети да экспериментов Он выпускается под разрешительной лицензией BSD Open Source и активно разрабатывается да поддерживается сообществом энтузиастов сетей да SDN.

Сеть Mininet складывается из:

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

Выводы :

РАЗДЕЛ 4

ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ЭЛЕМЕНТЫ

SEBA создана для предоставление шаблона архитектуры для разработки решений для широкополосного доступа носителей.

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

Сфера применения SEBA RD назначена для охват широкого набора беспроводных и фиксированных технологий беспроводного доступа и связанных с ими возможностей Service Edge. До них относятся, но нет ограничиваются: PON, XGS-PON, NG-PON2, EPON, будущие технологии PON, Gfast, Ethernet, фиксированный беспроводной, DOCSIS и xDSL. Сфера применения должна разрешать легко адаптировать новые технологии, новый кремний, что поддерживает или технологии да новые устройства, которые включают или технологии да кремний в элементы, что разворачиваются. Это должно быть Возможно без переписка основных разделов подкомпонентов, которые составляют SEBA и не должны требовать новых фундаментальных взаимодействий на север от платформ автоматизации носителей.

RD поддерживает подход POD, который означает, что все необходимые компоненты для предоставление доступа к услугам покрыты. на приложение к поддержке узлов сети простого доступа , RD также может включать другие элементы, такие как архитектура листового позвоночника. Переключающая ткань обеспечивает функции агрегации да служебного края. RD поддерживает требования операторов, которые хотят предоставлять широкополосные услуги без возможностей Service Edge, а также операторов, что предоставляют IP-услуги, включая возможности обслуживание в пределах POD.

Прямая поддержка беспроводного доступа к мобильности, как это определено 3GPP, нет в области этого РД, однако многие в группе операторов выразили желание иметь общий инфраструктурный шар и общие компоненты поддерживают оба , поэтому бдительное глаз отдается координации с будущим проектом (-ами) беспроводного ONF.

SEBA может быть реализован разными способами, в зависимости от оператора и/или ситуации. Наиболее важным в этом плане есть четкое отчуждение и обособление «сервиса» от «инфраструктуры ». Это также предполагает реализацию SEBA на разных инфраструктурных платформах, включая, но не ограничиваясь теми , которые базируются на CORD. Модульность через хорошую функциональную декомпозицию должна обеспечивать широкое повторное использование в решениях ONF, что обеспечивает высокий объем , последовательные, SW сборки, возможны с экосистемы

Рис. 4.1: Подходы к реализации целей

4 .2.1 Платформа автоматизации носителей (CAP)

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

Система оркестрирование да контроля (Service Orchestrator and Controllers) есть рецептурой/политикой, направленной на обеспечение автоматизированной инсталляции сервиса при необходимости да управление требованиями к услуг эластичным образом.

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

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

Устройства в POD включают устройства ASG, вычислительные серверы , OLT или другие устройства, определенные технологией (например, другие типы устройств для решений Wireless или DOCSIS, которые определяются для SEBA).

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

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

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

складывается с физической инвентаризации решение, какое поставщики планируют для доставки, поставщиков решений выполнения агрегировать в цепочке поставок; что инсталляторы размещают и проверяют. Уровень прикладных программ — это ближайший к пользователю уровень взаимосвязи открытых систем (OSI) Этот уровень устанавливает связь между приложениями да пользователем. Примером компонента SEBA на уровне прикладных программ есть клиент SEBA NBI.

Как управляемая виртуализированная среда, SEBA имеет максимально использовать требования безопасности, архитектуру безопасности, лучшие методы безопасности да решение безопасности с открытым кодом от других открытых сообществ. Оператору нужно будет адаптировать SEBA к своих методов безопасности. SEBA может реализовать некоторые основные функции безопасности, которые могут помочь реализовать безопасность на периметрах, таких как API, ОС и Kubernetes.

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

Надежность - это определение вероятности системы или компонента к функционировать в заявленных условиях в течение определенного периода времени. Надежность также определяется в терминах доступности системы или компонента в терминах числа с «9», таких как «пять 9», что указывает на доступность 99,999 %.

Анализ надежности рекомендуется для компонентов POD, и весь POD предусмотреть доступность POD как системы.

Resiliency – это возможность восстановления сервера, сетевого компонента или POD от сбоя (например, отключение питание или сбой оборудование) и быстро резюме операций .

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

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

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

Управление мощностью обеспечивает аналитику и отчетность о ресурсах, необходимы для решение. Он получает измерение мощности с элемента управление производительностью и ресурсов, определяющих мощность элемента решение.

Реализация управление мощностью может происходить в платформе автоматизации оператора (CAP), получающей измерение производительности от POD(ов), и потому коллекция Performance Management требует пересылки в CAP для этой функции.

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

4 .2.7 Управление неисправностями

Управление ошибками применяется на уровне SEBA POD. Платформа автоматизации оператора (CAP), которая подключается к SEBA POD через клиент SEBA NBI, как правило, обеспечивает две функции на уровни предприятия для управление неисправностями : (1) Показывать текущие активные тревоги да (2 )

Показывать историю сигналов и событий.

Для целей этого обсуждение тревожным сигналом может быть также

«постоянное состояние», имеющее состояние установленного/избранного , но сопоставленное на серьезность "не тревожный".

Желательно , чтобы NEM обеспечивал нормализованный коллектор, реализован в Kafka, для всех неисправностей для внешних OSS/Оркестраторов, что двигаются на север, чтобы иметь возможность получать потоки истории неисправностей детерминированным способом. Как потоковая платформа, Kafka предоставляет возможности публиковать и подписываться на потоки записей, сохранять потоки записей в надежный отказоустойчив способ да обрабатывать потоки записей в меру их появления.

Хотя VOLTHA публикует ошибки своей шины Kafka, которые NEM может предоставить своим двигающимся клиентам к северу, другие неисправности могут быть получены от других API в SEBA POD, таких как Redfish для управление устройствами. NEM может разработать «трансформатор», если это необходимо, чтобы экспортировать данные из других API в тему Kafka, и таким образом обеспечить все ошибки через нормализованный коллектор в Kafka.

Северные OSS/Оркестраторы могут реализовать и установить агента как микросервиса в клиенты SEBA NBI, какой подписывается на нормализованный коллектор Kafka и превращает ошибки в нужный формат (например, VES для ONAP, IPFIX для другого OSS и т.д.) для транспортировки к Северного САП. Клиент SEBA NBI для CAP не является частью SEBA, поскольку разные реализации CAP могут использовать разные протоколы управления.

Поскольку клиент SEBA NBI может обнаружить или повторно подключиться к SEBA POD в любой время, оно может зависеть от кэшированных сигналов и событий в SEBA POD и повторно синхронизироваться с этой дополнительной историей, чтобы правильно обновить его «Показать текущий «Активные сигналы», если и только тогда, когда клиент SEBA NBI может повторно синхронизироваться с фактической последней тревоги или события с предыдущего подключение к SEBA POD.

Реализация шины Kafka в SEBA должна разрешить клиенту SEBA NBI

определить, может ли он синхронизироваться с последним известным состоянием управления неисправностью SEBA POD. Если клиент SEBA NBI не может синхронизироваться с последним известным состоянием, у него будут отсутствовать сигналы тревоги и события. В в этом случае SEBA POD имеет обеспечивать функцию «Получить все активные сигналы с SEBA POD». SEBA предоставляет абстрактные интерфейсы конфигурации для предоставление услуг на уровне абонента. SEBA можно использовать у многих средах развертывание. Каждая реализация должна обеспечивать простые, простые в использовании API, что обеспечивают минимально необходимы параметры

4 .2.8 Управление жизненным циклом программного обеспечение

SEBA предоставляет API, способны управлять программным обеспечением для компонентов POD. Для типа PON AN это включает в себя физическое оборудование резидента в POD, а также все устройства ONT, подключены к портов PON.

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

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

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

Мероприятия, что влияют на обслуживание клиентов, выполняются в техническому обслуживании периоды, обычно от 2 к 4 часов. Ожидаемая перерыв в обслуживании абонентов меньше 5 минут.

4 .2.9 Управление производительностью

VOLTHA публикует данные мониторинга производительности на своей шине Kafka, которую NEM может преобразовывать в массовые коллекции данных (например, организованные за интервалом сбора).

NEM также может опрашивать другие данные мониторинга производительности для других функций в SEBA POD, например, используя Redfish API для мониторинга производительности устройства. NEM может разработать «трансформатор» за потребности с другого API на тему Kafka, и таким образом обеспечить весь мониторинг производительности через нормализованный коллектор в Kafka.

Северные OSS/Оркестраторы могут реализовать и установить агент как микросервис в SEBA POD, который подписывается на нормализованный коллектор Kafka и превращает коллекции мониторинга производительности в нужный формат (например, VES для ONAP, IPFIX для другого OSS и т.д.) для транспортировки к северного OSS/ оркестратора.

SEBA NB API должно предоставлять API для получения всех данных и показателей PM для "текущих" интервалов (например, 15 минут и каждый день).

Если Возможно, чтобы платформа автоматизации оператора (CAP) была несинхронизированная с коллекцией исторических интервалов PM SEBA POD после обнаружение или повторного подключения к SEBA POD, тогда требуется механизм для повторной синхронизации CAP с шины Kafka подлежат определению да реализации.

4.2 .10 Инвентаризация

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

4.2.11 Телеметрия, мониторинг, аналитика да функции политики

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

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

Обратите внимание, что проект SEBA в настоящее время не включает или не планирует включать Аналитический двигатель в рамках SEBA, такой как описано в предложенной аналитике для проекта CORD (A-CORD). При отсутствии движителя Analytics с A-CORD проектом, оператор может разрабатывать собственные приложения Analytics в POD, какой может взаимодействовать с SEBA Monitoring and Logging инфраструктура.

Обратите внимание, что вместо постройки приложений аналитики в POD оператор может строить централизованные функции аналитики и политики при этом северогерманском КЕП. CAP получит неисправности , телеметрию да мониторинг производительности от NEM адаптеры (см. также разделы выше для управление неисправностями да Мониторинг производительности), которые подписываются на автобус Кафка и трансформаторы в SEBA Monitoring & Logging Infrastructure, для того, чтобы обеспечить централизованную обработку для управление неисправностями, производительности Управление, телеметрия и любые функции аналитики да политики.

4 .2.12 Автоматизация да управление (включает в себя Наружные API)

В типичном сценарии развертывание будет к тысяч SEBA установлено POD.

Рис.4.2 Серверные системы поставщика услуг для многих POD SEBA

SEBA имеет быть автономным и иметь возможность работать в любому среде поставщика услуг. Чтобы достичь этих целей, нам нужно иметь внешнюю панель адаптации, какая расположена этаж SEBA Northbound API и может быть размещена удаленно. Оператор может создать экземпляр клиента SEBA NBI в SEBA POD.

Рис. 4.3 Роль клиента SEBA NBI

Клиент SEBA NBI тесно связан с серверной частью поставщика услуг и будет зависеть от поставщика услуг.

Рис.4.4: SP Backend, SEBA NBI Client (per SP) да SEBA NB API

SEBA должен быть автономным и нет влиять на будь -которые изменения, которые может возникать в среде развертывание.

Рис.4.5: Пример - Нету изменений к SEBA NB API

Аналогично, обновление версии SEBA нет влияют на внутренние системы.

Как показано на рисунке ниже версия SEBA NB API может измениться. Релизы SEBA должны определять версию NB API с документированным каталогом API да примечаниями к выпуска.

API, каталог и версия SEBA NB должны объединять API всех служб NBI. Например, SEBA NBI имеет включать VOLTHA NB API, SADIS (Subscriber / Access Device Information Service) NB APIs да другие услуги NBI в SEBA.API API SEBA NB имеет оставаться обратно совместимым. Вызов API может быть обратно совместимым, только добавив параметры или значения параметров. Чтобы предложить заменить API, имеет быть определено новый API, какой заменит текущий API. Только после подтверждение отсутствия пользователей API, которые нужно заменить, можно Удалить бывший API. Примечания к выпуска новой версии API должны документировать все улучшение API, новые API, API, которые предлагаются заменить, и удалены API.

Интерфейсы управление SEBA могут воспользоваться стандартизированным моделированием устройств и технологий доступа с использованием моделей YANG от организаций по разработке стандартов (SDO) – см. каталог github для SDO В этом каталоги github широкополосный форум (BBF)поддерживает опубликованы модели YANG для ITU-T PON (на BBF TR-385), FTTdp для G.fast и G.hn (TR-355) и Common YANG (BBF TR-383). При разработке SEBA NB API следует учитывать соответствие этим стандартизированным моделям YANG для интеграции в Carrier Automation Platform (CAP).

Рис 4.6: Пример - Нету изменений в SP Backend

Адаптер должен вызвать соответствующие методы в SEBA NB API и реализует набор API обратного вызова для вызова SEBA. Удаленный вызов осуществляется через gRPC.

Рис 4.7: API обратного вызова SEBA

Управление устройствами

Интерфейс управление устройствами (DM) должен поддерживать модели данных да API, определены сообществом SEBA/VOLTHA. DM имеет включать необходимые механизмы для выполнения действий, перечисленных ниже .

Выводы:

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

РАЗДЕЛ 5

РАЗРАБОТКА СТАРТАП ПРОЕКТА

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

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

Таблица 5.1

Описание идеи стартап-проекту

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

Технологическая выполнимость идеи проекта Таблица 5.2

Для реализации проекта доступна SEBA, которая связана с несколькими зрелыми проектами в ONF, включая ONOS, VOLTHA, XOS и R-CORD. Поскольку эта работа взаимодействует с существующими выпущенными работами в активных сообществах ONF, в полной мере вероятно, что некоторые процессы, определены для нормальной новой работы RD, Возможно, нужно будет откорректировать, чтобы обеспечить, чтобы существующие сообщества и их работа не были лишены прав.

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

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

Таблица 5.3 Предыдущая характеристика потенциального рынка стартап-проекту

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

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

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

внедрению проекта, да факторов что ему препятствуют.

Характеристика потенциальных клиентов стартап-проекту

Таблица 5.4

Таблица 5 .5

Факторы угроз

В дальнейшем проведен анализ предложения: определены общие характеристики конкуренции на рынке (табл. 5.6 )

Таблица 5.6

Ступенчатый анализ конкуренции на рынке

Таблица 5 .7

Анализ конкуренции в отрасли за М . Портером

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

Таблица 5 .8

Обоснование факторов конкурентоспособности

Таблица 5.9 Сравнительный анализ сильных да слабых сторон системы повышение

лояльности.

Таблица 5.10 Альтернативы рыночного внедрения стартап-проекту

Базовые стратегии в избранных сегментах рынке представлены в таблицы 5.11

Таблица 5.11

Определение базовой стратегии развития

Продолжение Таблицы 5.11

В результате анализа выбираем стратегию дифференциации Следующим шагом есть выбор стратегии конкурентной поведения (таблица 5 .12)

Таблица 5.12 Определение базовой стратегии конкурентной поведения

Определим стратегию позиционирование (таблица 5.13 )

Определение стратегии позиционирование

Таблица 5.13

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

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

Таблица 5.14 Определение ключевых преимуществ концепции потенциального товара

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

Таблица 5:15

Описание трех уровней модели товара

Продолжение Таблицы 5:15

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

Таблица 5.16

Концепция маркетинговых коммуникаций

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

Выводы:

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

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

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

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

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

ОБЩИЕ ВЫВОДЫ ПО РАБОТЕ

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

02/%D0%94 %D0%B8%D0%BF%D0%BB%D0%BE%D0%BC_%D0%9A%D0

%BB%D0%B5%D1%86%D1%8C.pdf

13 .Stratum[Electronic resource]// – Mode of access: https://www.opennetworking.org/stratum/

%D0%98%D0%A3-323%20full.pdf

25 . Руководство по SDN и NFV [Электронный ресурс ] // Алексей Шалагинов.

– – Режим доступа к ресурсу: https://shalaginov.com/2018/01/16/%D1%80 %D1%83%D0%BA%D0%BE%D0

%B2%D0%BE%D0%B4%D1%81 %D1%82%D0%B2%D0%BE-

%D0%BF%D0%BE-sdn-%D0%B8-nfv-1/