Усовершенствованный метод обработки потоков в системе SDN

РЕФЕРАТ

Работа содержит 81 страниц, 28 рисунков и 4 таблицы. Было использовано 37 источники.

Цель работы: улучшить эффективность алгоритма избрание внутреннего пути в системе.

Проведено обзор технологии программно-конфигурированных сетей, описана архитектура SDN, описаны OpenFlow протокол, конвейерная обработка пакетов, архитектура Open vSwitch коммутатор, основные функции да требования к OpenFlow контроллеру. Освещены особенности контроллера SDN, преимущества да недостатки наиболее популярных внешних контролеров таких, как: OpenDayLight, POX, Floodlight. Рассмотрены эмулятор Mininet и практически описаны функции Mininet, и развернута собственная топология. Сделано описание развертывания выбранного контроллера OpenDayLight на виртуальную машину в Oracle VM VirtualBox.

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

Ключевые слово: SDN. OpenDayLight, SmartCity, POX, Floodlight, Mininet

СОДЕРЖАНИЕ

ACL API BGP CLI ECMP GNU HTTP IETF IS-IS

JSON LACP MAC NBI

NETCONF ONF

OSGI OSPF OVS OVSDB OXM PCEP PDU

QoS REST SDN SNMP SSL TLS UDP VLAN XML ОС ПКС ПО

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

Access Control List

Application Programming Interface Border Gateway Protocol Command line interface

Equal-cost multi-path routing GNU's Not UNIX

HyperText Transfer Protocol Internet Engineering Task Force

Intermediate System-to-Intermediate System

JavaScript Object Notation

Link Aggregation Control Protocol Media Access Control NorthBound

Network Configuration Protocol Open Networking Foundation Open Services Gateway Initiative Open Shortest Path First

Open vSwitch

Open vSwitch Database OpenFlow Extensible Match fields Path Control Element Protocol Power Distribution Unit

Quality of Service Representational State Transfer Software-defined Networking

Simple Network Management Protocol Secure Sockets Layer

Transport layer security User Datagram Protocol Virtual Local Area Network

eXtensible Markup Language Операционная система

Программно конфигурированные сети Программное обеспечение

ВВЕДЕНИЕ

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

Да есть неудовлетворительный состояние дел может измениться через двух революционных событий: первое, появление на рынке чрезвычайно усложненного, проприетарного, сетевого оборудования, и второе, появление принципиально нового подхода, называемого программноконфигурируемые сетями (ПКС - Software Defined Networks). Соблюдение такого подхода позволит ускорить маршрутизацию в сетях, сделать его удобнее для конфигурации, виртуализации, настройки качества обслуживание, но требует дополнительных исследований и разработок В частности, в области организации сетевых коммутаторов, программных приложений для управление сетью и платформ для их исполнение.

Объект исследование : телекоммуникационная составляющая программно- конфигурируются сетей, что включает каналы связи, контроллер ПКС да сетевое оборудование.

Предмет исследование : методы управление потоками в контроллеры SDN.

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

Теоретический реультат исследования:Исследовано использование среды Mininet и контроллеров SDN для развертывание сети SDN, что разрешает обнаружить да устранить проблемы сети на этапе моделирование.

Практический результат исследование.

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

РАЗДЕЛ 1

SDN СЕТЬ, ОСОБЕННОСТИ И ПЕРЕДАЧА В SDN

Архитектура SDN основывается на логическом и физическом разделении функций уровней сетевых устройств - отделении Control Plane от Data Plane и перенос плоскости управление сетью на выделен SDN контроллер, имеющий точную информацию о структуре и топологии сети. Таким образом, в рамках классической концепции SDN сетевой устройство - передаточный устройство без функций управления[1].

SDN складывается с трех уровней:

Рис 1.1 Архитектура Software-defined network

Описание уровней SDN:

a) уровень инфраструктуры или передачи данных (data plane) – включает в себя набор передающих сетевых устройств, которые доступны через унифицированный интерфейс и выполняющие инструкции таблиц потоков для передачи сетевого трафика. Это могут быть как физические, да и виртуальные коммутаторы, и маршрутизаторы, а также каналы связи [2-3];

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

На данном уровне есть три интерфейса для взаимодействия с другими элементами сетевой инфраструктуры. С помощью этих интерфейсов уровень управления связывает все три плоскости [1-3]:

JSON.

Интерфейс NorthBound (NBI) можно назвать границей между контроллером и прикладным уровнем. Он поддерживает большинство протоколов уровня приложения для взаимодействия, то есть HTTPS, SFTP и т. д. Мы можем управлять контроллером по помощью основных HTTP методов POST, GET, PUT и DELETE;

в) уровень приложений складывается с высокоуровневых приложений, которые взаимодействуют с сетевым контроллером или набором контроллеров, спрашивая и передавая необходимые ресурсы и инструкции с помощью API для реализации конкретных функций, что отвечают требованиям сетевой инфраструктуры Эта взаимодействие осуществляется за помощью такого компонента SDN как Northbound API. Здесь реализуются разные функции обработки сетевого трафика. Примером таких приложений могут служить средства мониторинга (сбор информации о сеть да отправка ее SDN приложений), аналитики балансировка погрузки или бизнес-приложения [2].

Southbound и Northbound интерфейсы представлены на рисунка 1.2.

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

Рис. 1.2 Southbound и Northbound интерфейсы

Наиболее перспективным и активно развивающимся стандартом для SDN есть OpenFlow (OpenFlow версия 1.3) – открытый стандарт, в котором описываются требования, предъявляемые к коммутатору, поддерживающему протокол OpenFlow для удаленного управление[4].

За помощью современных маршрутизаторов обычно решаются две основные задачи: передача данных (forwarding) – продвижение пакета от входящего порта на определенный выходной порт и управление данным - обработка пакета и принятие решения о том, куда его передавать дальше, на основе текущего состояния маршрутизатора [4] .

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

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

Согласно со спецификацией 1.3 стандарта OpenFlow, взаимодействие контроллера с коммутатором осуществляется за помощью протокола OpenFlow - каждый коммутатор должен содержать одну или более таблиц потоков (flow tables), групповую таблицу (group table) и поддерживать канал (OpenFlow channel) для связи с удаленным контролером - сервером[4].

Рис. 1.3 Традиционные сети и SDN

Спецификация не регламентирует архитектуру контроллера и API для него приложений. Каждая таблица потоков в коммутаторе содержит набор записей (flow entries) о потоки или правила. Каждая такой запись складывается с полей- признаков (match fields), счетчиков (counters) и набора инструкций (instructions) [4].

Механизм работы коммутатора OpenFlow достаточно простой. В каждого пакета, что пришел «вырезается» заголовок (битовая строка определенной длины).

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

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

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

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

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

Разработчики коммутаторов могут быть свободны в реализации их внутренней начинки, однако процедура просмотра пакетов и семантика инструкций должны быть для всех одинаковы. К примеру, в то время как поток может использовать все группы для пересылки в некоторое множество портов, разработчик коммутатора может выбрать для реализации этого единственную битовую маску внутри аппаратной таблицы маршрутизации Другой пример – это процедура просмотра таблиц: конвейер физически может быть реализован с помощью разного количества аппаратных таблиц. Установка, обновление да удаление правил в таблицах потоков коммутатора осуществляются контроллером. Правила могут устанавливаться реактивно (в ответ на пришедшие пакеты) или проактивно (заранее, к прихода пакетов) [4].

Управление данным в OpenFlow осуществляется нет на уровни отдельных пакетов, а на уровни их потоков. Правило в коммутаторы OpenFlow устанавливается с участием контроллера только для первого пакета, а затем все другие пакеты потока его используют [4].

OpenFlow коммутатор - сетевой устройство Data Plane, что поддерживает работу по протокола OpenFlow и выполняет функции перенаправление данных согласно с инструкциями SDN контроллера. Задача - передача да обработка пакетов соответственно к таблицы сетевых потоков и правил, сформированной контролером на основании определенных критериев кадра или пакета. Устройства лишены функции управление и могут только передавать статистику и обращаться за новыми правилами потоков к внешнему SDN-контроллеру [3]. Согласно со спецификацией стандарта, OpenFlow - каждый коммутатор должен содержать одну или больше таблиц потоков (flow tables), групповую таблицу (group table) и поддерживать канал (OpenFlow channel) для связи судаленным контролером по протокола OpenFlow [1]. Компоненты OpenFlow коммутатора представлены на рисунка 1.4 [3], [5-6].

Рис. 1.4 Компоненты OpenFlow коммутатора

Канал OpenFlow (OpenFlow Channel) – интерфейс, который соединяет каждый логический коммутатор OpenFlow с контроллером Для каждого контролера, что подключается к коммутатору, устанавливается отдельный канал [5-6].

Выделяют два подходы к постройки такого канала:

а) Оut-of-band - передача сообщений протокола по физически независимого канала (используется отдельный порт коммутатора), нет используя сеть передачи данных. Обеспечивает более высокую надежность и безопасность за счет отсутствия влияния переданного по сети трафика на управляющий трафик и исключение физического доступа к сети управления из стороны узлов в сети передачи данных;

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

Формат записей в таблице сетевых протоколов коммутатора OpenFlow представлен на рисунка 1.5.

Формат заголовка Flow table представлен на рисунка 1.6.

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

Рис. 1.5 Формат записей в таблицы сетевых протоколов OpenFlow

коммутатора

Рис. 1.6 Формат заголовка Flow table

Обработка пакетов на основе таблицы представлена на рисунка 1.7.

Записи в таблицы сетевых протоколов OpenFlow коммутатора:

Соответствующая запись определяется по полям сравнения (поле «protocol») и приоритета. При совпадении полей выбирается запись с наибольшим приоритетом. Соответственно к нее будет обрабатываться пакет [3]. Процесс обработки пакета представлен на рисунке.

Рис. 1.7 Обработка пакетов на основе таблицы

Вторым элементом записи таблицы является сопоставляемое «действие» (action) каждой записи в таблице потоков, применяется к пакетам, принадлежащим данном потоке и определяет обработку пакетов потока [5-6]. Основными действиями являются: пересылка на определенный порт или несколько портов, отвержение всех пакетов конкретного потока, преобразования пакета (модификация заголовка пакета) - инкапсуляция и передача пакетов на контроллер ПКС по безопасному каналу Кроме того, «стандартная» обработка, разрешает разделить потоки данных на потоки, управляемые OpenFlow, и потоки, управляемые другими механизмами (существующие протоколы маршрутизации). Предоставляет возможность изолировать экспериментальный трафик, используя общую инфраструктуру.

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

Функционал GROUPS расширяет возможности пересылка пакетов. Например, позволяет реализовать ECMP Load Balancing – «отправка на одно подмножество с группы» - для балансировка нагрузка в LAG или ECMP.

Таблица групп (group table) содержит записи о группах, содержащих список контейнеров действий со специальной семантикой в зависимости от типа группы.

Механизм работы OpenFlow коммутатора достаточно прост. Начиная с версии 1.3 OpenFlow поддерживает множественные таблицы потоков. Для обработки потоков, коммутатором используется механизм конвейерной обработки (pipeline) - обработка пришедшего пакета начинается до окончания обработки предыдущего [3], [5-6].

Рис. 1.8 Конвейерная обработка пакета

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

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

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

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

на данный момент существует три наиболее популярных виртуальных коммутатора – VMware virtual switch (standard и distributed), Cisco Nexus 1000v и Open vSwitch.

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

Поддерживает наиболее популярные Гипервизор, включая KVM, Virtual Box, Xen и XenServer. Open vSwitch состоит из службы-коммутатора (user- space) и сопровождающего модуля ядра (kernelspace), управляющего процессом поточной (flowbased) коммутации.

Open vSwitch поддерживает широкий набор технологий, включая NetFlow, sFlow, port mirroring, VLAN, LACP, TLS /SSL.

В рамках классической модели SDN для управления OVS (формирование FIB) применяются посторонние компоненты. например, плагин для OpenStack Neutron или SDN-контроллер OpenDayLight.

Также OVS можно использовать в режиме стандартного коммутатора, без внешнего управляющего элемента и применять MAC learning для формирование таблиц коммутации.

1.4.1Структура Open vSwitch

Open vSwitch – это виртуальный многоуровневый (multilayer) маршрутизатор разрабатывается под лицензией Apache 2.0

Open vSwitch условно можно разделить на две части - user-space и kernel-space.

Рис. 1.9 Структура Open vSwitch (www.openvswitch.org)

User-space состоит из нескольких наиболее важных компонентов: это демоны (daemons), которые реализуют свитч с таблицей потоков, ядро Open vSwitch, и набор утилит, позволяющих конфигурировать свитч, его базу данных (ovsdb) и непосредственно посылать сообщение в ядро.

Openvswitch service запускает три демона: ovs-vswitchd - сохраняет и отвечает за изменение конфигурации маршрутизатора, а также сохраняет состояние в базу данных (ovsdb), ovsdb-server – манипулирует базой данных, конфигурацией и на- бором потоков, ovs-brcompatd - создает совместимость Open vSwitch со обычными Linux мостами (которые создаются командой brctl).

Демон ovs-vswitchd – единственная компонента, связанная с kernel-space через протокол netlink, также меняет конфигурацию Open vSwitch и сохраняет ее в базу данных (ovsdb), какая управляется за помощью демона ovsdb-server (коммуникация ovs-vswitchd и ovsdb-server осуществляется за помощью сокетов)

Стоит отметить, что Open vSwitch является гибридным маршрутизатором - кроме поддержки OpenFlow маршрутизатор поддерживает специализированные команды (Nicira Extensions) (L2 routing, QoS, tunneling и.т.д), но самый большой интерес он представляет как проект что поддерживает протокол OpenFlow (на данный момент есть поддержка OpenFlow 1.0 и тестовые версии с поддержкой OpenFlow 1.3).

SDN Контроллер - управляющий центр сети, что включает центральную сетевая операционная система и управляющие программы. Отвечает за построение и отображение топологии, программирование сетевых устройств и служит единственной точкой управление всей сетью. SDN контроллер предоставляет возможность объединять несколько контроллеров, и устанавливать иерархические связи между ими [1–2]. SDN контроллер реализуется в качества ПО для управление плоскостью пересылка.

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

Таблица 1.1

Основные функции контроллера

Открытый программный интерфейс API (от англ. Application Programming Interface), разрешает разрабатывать программы и программные расширения, реализующие логику, необходимую для определения, обновления и адаптации правил потоков.

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

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

Рис. 1.10 Выделение потока трафика на основе общих признаков Контроллер статически или динамически программирует и устанавливает правила

соответствия для потоков Правила потока определяют базовые инструкции, которые регулируют пересылка, изменение или удаление каждого пакета, какой попадает в SDN-коммутатор [1-2][7]. Установка правил передачи пакетов контроллером для новых потоков может осуществляться двумя способами [2- 3][8]:

Реактивный - устройства передачи спрашивают контроллер, а контроллер

формирует одно правило и устанавливает его на отправившее устройство передачи запрос.

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

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

На сегодняшний день на рынке представлено множество SDN контроллеров таких как: OpenDayLight ONOS Floodlight Runos и другие. Но все они должны отвечать основным требованиям (табл.1.2), сформированным в ходьбе разработки и внедрение контроллеров в эксплуатацию.

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

Основные требования к контроллера представлены в таблицы 2.

Таблица 1.2

Основные требования к контроллера

Выводы

РАЗДЕЛ 2

СУЩЕСТВУЮЩИЕ РЕШЕНИЯ ДЛЯ РАЗРАБОТКИ ПРИЛОЖЕНИЙ КАК ИСПОЛЬЗУЮТСЯ В SDN

Как уже упоминалось ранее, SDN разделяет плоскость данных и плоскость управление. по сущности, интеллект сети перемещается к контроллера; все вычисления выполняются там, и много приложений и функций можно добавить за потребности. Основные модули обсуждаются в [9], где предлагается легкий контроллер несущего качества. К основным модулям относятся: модуль обнаружения ссылок, модуль топологии, модуль хранение данных, модуль создание стратегии, модуль таблицы потоков и модуль управляющих данных. По сути, два модули отвечают за предоставление услуги маршрутизации: менеджер топологии и модули поиска ссылок Модуль Link Discovery отвечает за обнаружение и поддержку состояния физических ссылок в сети. Существует два типа обнаружения ссылок: обнаружение ссылок между узлами OpenFlow (переключатели OpenFlow) за помощью традиционного протокола обнаружение слоев ссылок, LLDP (802.1AB) и обнаружение ссылок между узлом Edge OpenFlow и хостом. Эта процедура запускается контролером, когда любой неизвестный трафик поступает в домен OpenFlow. Таким образом, информация, собранная модулем Link Discovery, используется для постройки базы данных соседей в контроллеры, что фиксирует всех соседей OpenFlow. Поэтому менеджер топологии создает и поддерживает информацию о топологии в контроллере и вычисляет маршруты в сети. Этот модуль использует базу данных соседей для вычисление топологической сети на основе полученной информации из модуля Link Discovery. Менеджер топологий создает глобальную базу данных топологии на контроллеры, какая содержит информацию о кратчайший (и альтернативный) путь к любого узла или хоста OpenFlow.

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

Протокол OpenFlow есть ключевым фактором, что способствует программно определенным сетям. Это был первый стандартизированный интерфейс на юг. Это позволяет непосредственно манипулировать плоскостью пересылки. переключателей OpenFlow [10]. Выбирая контроллер OpenFlow, мы должны понимать функциональность OpenFlow, которую поддерживает контроллер, а также план развития для внедрения новых версий OpenFlow, таких как v1.3 или v1.4. Одной с причин необходимости учитывать это есть то, что такая важна функциональность, как поддержка IPv6, например, не является частью OpenFlow v1.0, а есть частью стандарта OpenFlow v1.3.

Сетевая программируемость – это важнейшее преимущество ввода SDN для решения беспрецедентных сложностей управления в современной сети взрывом количества подключенных устройств да развертыванием новых служб. Использование парадигмы «от устройства к устройства» для управление масштабными будущими сетями будет невозможным. Старый статический

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

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

API Southbound разрешает эффективно контролировать сеть. Или API используются контроллером для динамического внесения изменений в правила переадресации, установленных на устройствах плоскости данных, состоящих из: коммутаторов, маршрутизаторов и т.д. Хотя OpenFlow является наиболее известным из протоколов SDN для API на юг, это не единственный один доступный или в разработке. NETCONF (стандартизированный IETF), OF-Config (поддерживается Open Network Foundation (ONF)), Opflex (поддерживается Cisco) да другие есть

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

сетевыми устройствами. Кроме того, некоторые протоколы маршрутизации, такие как IS-IS, OSPF, BGP, также разрабатываются как интерфейсы на юг у некоторых контроллерах с целью поддержки гибридных сетей (SDN да нет SDN) или применение традиционных сетей в программном обеспечении способом [13].

Northbound Interfaces используются прикладным уровнем для связи с контроллером. Они есть наиболее важной частью в архитектуре контроллера SDN, поскольку ценность SDN связана с инновационными программами, которые она может поддерживать и активировать. Поскольку они настолько важные, API, что присоединяются к севера, должны поддерживать широкий спектр программ. Или API позволяют также соединяться с автоматизированными стеками, такими как OpenStack или CloudStack, используемые для управления облаком. Недавно Open ONF сосредоточился на API SDN на север после работы со стандартизации интерфейса к югу (OpenFlow). Они создали рабочую группу, которая будет писать код, разрабатывать прототипы и искать создание стандартов[14]. В настоящее время протокол REST (Представительский государственный трансфер), кажется, является наиболее используемым интерфейсом к северу, и большинство контролеров реализуют его.

Находясь под присмотром должного партнерство, контроллер SDN будет иметь шансы на длительное время поддерживать и совершенствовать [11]. Опыт работы в сети и компьютерных доменах, а также экономический потенциал организации партнера есть основными критериям предупреждение доверия да использование продуктов. Cisco, Linux Foundation, Intel, IBM, Juniper и т.д. примеры надежных организаций, которые выходят на рынок SDN и участвуют в разработке контролеров.

За предыдущие два годы было проведено несколько опросов [15-21], которые

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

Одним с контролеров с поддержкой OpenFlow есть OpenDayLight контроллер. OpenDayLight - Open-source проект с гибкой модульной платформой MD-SAL для встраивание разных плагинов с поддержкой нескольких протоколов и обеспечение согласованных услуг для модулей и приложений. Модельный уровень абстракции сервиса (MD-SAL) – это среда OpenDayLight, для создание новых функций в виде служб и драйверов протоколов. SAL предоставляет такие базовые сервисы как Device Discovery (обнаружение сетевых устройств в сети и подключение к ним), который в свою очередь используются такими модулями как Topology Manager (хранение, обновление информации о топологии сети) и и т.д.

Проект разрабатывается под лицензией EPL v1.0 (Eclipse public license) по поддержки Linux Foundation. Разрабатывается на языке Java и является кроссплатформенным [22].

Контроллер OpenDayLight реализован исключительно в программном обеспечении и сохраняется в его собственной виртуальной машине Java (JVM).

OpenDayLight построен из пакетов OSGi и платформы сборки - Java Karaf на основе инфраструктуры Apache Felix Framework или Eclipse Equinox OSGi использует Maven как инструмент сборки.

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

OSGi - Java-специфическое среда, какая улучшает способ взаимодействия Java-классы в рамках одной JVM. Используется для запуска приложений и позволяет динамически подключать плагины для использования и связи разных Southbound протоколов.

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

Архитектурные принципы OpenDayLight:

Архитектура OpenDayLight представлена на рисунке 2.1.

Рис. 2.1 Архитектура OpenDayLight

Последний релиз Oxygen полностью поддерживает протокол OpenFlow 1.3, BGP-LS, протокол OVSDB, PCEP, SNMP. Есть дополнительная поддержка OVSDB

protocol, следовательно, может использовать все особенности и расширение Open vSwitch[22].

Функциональный обзор

The OSGi framework разрешает динамически подключать плагины для использование новых Southbound протоколов. SAL предоставляет такие базовые сервисы, как Device Discovery (обнаружение сетевых устройств в сети и подключение к них), которые в свою очередь используются такими модулями как Topology Manager (хранение, обновление информации о топологии сети) и.т.д. Основываясь на запросе сервиса - SAL маппируэт нужный плагин и использует наиболее подходящий southbound протокол.

Рис. 2.2 структура OpenDaylight( www.opendaylight.org )

Одним с важных преимуществ OpenDaylight есть поддержка распределенной версии (High Avalability Model), позволяет развертывать контроллер на нескольких физических серверах, гарантируя тем самым отказоустойчивость и балансировку погрузки.

POX контроллер - open-source проект, разрабатываемый на Python под лицензией GNU Лицензия (официально поддерживает Windows, Mac OS, Linux)

POX сейчас поддерживает OpenFlow 1.0 (отчасти поддерживает под Openflow 1.1), также есть поддержка Open vSwitch / Nicira extensions (специальное расширение протокола OpenFlow, что разрешает создавать более гибкие настройка маршрутизаторов, пример: action = normal - flow какой заставляет обрабатывать совпавший пакет, как обычный L2 Linux bridge, ставить числовые метки на пакеты, которые идут по forwarding pipeline и таким образом контролировать обработку).

POX сам по себе никак не управляет трафиком – функциональность контроллера с- сдается запуском отдельных компонент вместе с контроллером (components), следовательно тельно целевая аудитория проекта POX - разработчики, которые хотят реализовать свои проекты. Стандартный дистрибутив включает в себя набор базовых компонентов.

Разработка компонент

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

def launch (args ..):

// код компоненты

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

POX API

POX содержит объект – "ядро (core)", реализующий основу POX's API. Основная цель данного объекта - коммуникация между запущенными компонентами. При запуске указанные компоненты регистрируются на этом объекте и всяческие Пересылки между компонентами реализуются через его использование. Если необходимо "зарегистрировать" компонент в "ядре" необходимо выполнить следующие две команды:

core.register(component_class) core.registerNew(component_class)

В итога "ядро" (core) и стандартные компоненты библиотеки pox предоставляют на- дующее API's:

POX в основном используется для исследований ПКС, поэтому что предоставляет простой и удобный Northbound API для небольших задач. Основная цель этого проекта - разработка и исследование парадигмы ПКС, для полноценных коммерческих приложений этот проект не подходит из-за ограниченного API и медленной работы (т.к. Написан на Python)

Контроллер разрабатывается на Java 1.7+ под лицензией Apache 2.0. Поддерживает только топологию без циклов между различными компонентами связности. Имеет модульную структуру, есть перед запуском в специальный конфигурационный файл прилагаются названия сервисов, которые будут использованы. Поддерживает следующие сервисы:

Рис. 2.3 Структура Floodlight (www.docs.projectfloodlight.org)

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

Для разработки приложений на базе данного контроллер, предоставляется Restful Java

API.

Итоги обзора

OpenDaylight controller огромно быстро развивается проект спонсируется такими крупными организациями как: Cisco, IBM, Red Hat. С преимуществ можно выделить: работает на JVM, то есть работает везде, где есть Java; модульность - работает с многими Northbound APIs (Рест API, OSGi frameowork) и Southbound APIs которые между собой независимые (важная особенность, что модули можно загружать прямо под время работыконтроллера. Есть дополнительная поддержка OVSDB protocol, следовательно , может использовать все особенности и расширение Open vSwitch.

Таблица 2.1

Обзор контролеров

В целом можно сказать, что POX контроллер используется для проверки эффективности ПКС на разных топологиях сетей и тестирование протокола OpenFlow. Floodlight и OpenDaylight можно объединить в одну категорию, как два проекта, разрабатываемых на языке Java. Хотя Floodlight можно назвать переходным между POX и OpenDaylight, поэтому что последний поддерживает любые топологии сетей, большая количество протоколов маршрутизации, является более гибким и лучше подходит для решения реальных бизнес-задач.

Среди рассматриваемых проектов сильно выделяется OpenDaylight. Есть поддержка распределенной модели, OSGi фреймворк разрешает загружать модули без перезагрузки контроллера, активная поддержка Linux сообщества (спонсоры: IBM, Cisco, Nicira, OpenFlow Network Foundation и т.д.) много интерфейсов на Southbound (HTTP, COAP, PCEP, LACP, OpFlex, SNMP да др.) Да внедрены новые модули (посредник данных IoT (IoTDM), унифицированный защищенный канал USC тому подобное). Таким образом, это первый контроллер, что входит в домен IoT. Поддерживая широкий спектр Southbound интерфейсов и распределенной парадигмы управления, кажется, он является контролером Интернета будущего. Поддержка плагина OpenStack Neutron в его архитектуре также имеет чрезвычайно важное значение при развертывании программно определенных краев в ответ на распространение вычислений Edge.

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

Выводы

РАЗДЕЛ 3

РАЗРАБОТКА СЕГМЕНТА СЕТИ SDN

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

Виртуальные сети должны быть:

оператор, от тех механизмов, как или политика реализуется;

Виртуальные сети состоят из двух компонентов: узлов и ребер. Сами физические узлы должны быть виртуализировать. Один с возможных способов Виртуализация узла представляет собой виртуальную машину. Этот способ виртуализации узла использует виртуальное среда, да у как VServer или Jail. Гипервизор или другая технология разрешает виртуальном среде эффективно предоставлять физическое оборудование, чтобы обеспечить иллюзию нескольких гостевых узлов. Примеры виртуализации узла: среда виртуальной машины, таких как Xen или VMware; виртуализация на уровне ОС или виртуальные среды, таких как Linux VServer. В виртуальной сети необходимо соединить или виртуальные машины. Каждая виртуальная машина или виртуальное среда имеет свой собственный вид сетевого стека. Нужно обеспечить видимость того, что эти узлы соединены друг с другом через 2-й уровень OSI, даже если они на самом деле разделены несколькими IP-сетями. Один из возможных способов сделать это заключается в инкапсуляции Ethernet-кадра когда он покидает пределы VM в IP-пакете. В пункте назначения IPпакет де-инкапсулируется и передает исходный Ethernet- кадр к ВМ или виртуальном среде. Каждый с одной этих физических хостов, может на самом деле, разместить несколько виртуальных машин или виртуальных сред, что создает необходимость в виртуальном коммутаторе, который находится на физическом узле. Этот виртуальный коммутатор соединяет в виртуальную сеть 2-го уровня OSI все ВМ. Linux-мост, OpenVSwitch есть примерами программных коммутаторов, которые могут выполнять этот тип функции.

Начиная с версии 2.6.24 ядром Linux поддерживаются механизмы виртуализации и изоляции - Cgroups, которые позволяют обеспечить сетевыми интерфейсами, таблицами маршрутизации и ARP-таблицами процессы в рамках одной операционной системы Это один из видов виртуализации на уровне ОС, что позволяет запустить множество однотипных процессов в изолированном и ограниченном по ресурсов окружении. Дану технологию использует среда для моделирование MiniNet, какая разрешает создать виртуальную сеть на маломощном оборудовании. При запуска Mininet за помощью сценария

«mn», каждый хост в виртуальной сети представляет собой bash-процесс c собственной сетью пространства имен, фактически это виртуализация на уровне ОС (рис.3.1).

Рис.3.1 Архитектура MiniNet

Да, каждый из этих виртуальных узлов, имеют свой собственный сетевой стек. Корневое пространство имен управляет связью между этими разными виртуальными узлами, а также выполняет роль коммутатора, какой соединяет или узлы в созданную вами топологию. Виртуальным парам Ethernet предназначены два пространства имен. Например, S1 eth1 назначается интерфейс в сетевом пространству H2, S1 eth2 присваивается сетевому пространству имен H3. Коммутатор OpenFlow эффективно выполняет переадресацию между интерфейсами в корневом. просторные имена. Но поскольку интерфейсы парные, мы получаем иллюзию. отправки трафика между h2 и h3. Когда мы вносим изменения в коммутаторы OpenFlow через контроллер, мы фактически это делаем в корневом пространстве имен. Подобные техники позволяют Mininet создавать в пространстве ядра или пользователя коммутаторы, OpenFlow-контроллеры и хосты и взаимодействовать в рамках моделируемой сети. В качестве виртуальных коммутаторов используется адаптирована реализация Open vSwitch.

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

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

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

Мининет:

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

В сетях Mininet работает реальный код, какой включает в себя стандартные сетевые приложения Unix / Linux, а также реальное ядро Linux и сетевой стек (да содержит любые расширение ядра, к которых вы имеете доступ, конечно если они совмещаются с сетевыми пространствами имен).

С этой причины код, какой вы разрабатываете и запускаете на Mininet, для

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

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

По сравнению с подходами, основанными на полной виртуализации системы, Mininet:

Mininet имеет преимущества перед аппаратными тестовыми системами, а именно:

Разработка сегмента SDN проводилась c помощью технологии виртуализации - Oracle VM VirtualBox (VB). VirtualBox - это универсальный полнофункциональный виртуализатор для оборудование x86, предназначенный для использование на сервере, настольном компьютере и встроенных системах [25].

Таблица 3.1

Обзор возможностей Oracle VM VirtualBox

Продолжение таблицы 3.1

С помощью следующей команды отображаются параметры _ запуска Mininet:

Для создание минимальной топологии прописать следующую команду:

Топология за по умолчанию - это минимальная топология, какая складывается с одного коммутатора ядра OpenFlow, подключенного к двум хостам, и контрольный контроллер OpenFlow. Эта же топология также может быть указана в командном строке как --topo=minimal. Также другие топологии доступны за по умолчанию. Все четыре объекты (2 хоста, 1 коммутатор, 1 основной контроллер) теперь работают в виртуальной машины.

Если не было передано никакого специального теста в качестве параметра, появится интерфейс командного строки Mininet.(CLI)

Для показа команд интерфейса командного строки Mininet существует следующая команда:

Команда nodes выдает список узлов в сети:

Для полной информации о каждый узел нужно ввести команду:

Вы увидите коммутатор и два хоста.

Если имя хоста, коммутатора или контроллера, будет набрано первое в CLI Mininet, то команды будут выполняться на этом узле. Пример команды в хостовом процессе:

Вы можете увидеть интерфейсы h1-eth0 и loopback (lo) хоста. Обратите

внимание, что первичная система Linux не может увидеть интерфейс (h1-eth0) при запуска ifconfig, поскольку он принадлежит для сетевого пространства имен хост- процесса.

А коммутатор, наоборот работает за по умолчанию в корневом сетевом просторные имен, поэтому исполнение команды на «коммутаторы» аналогично запуску его со обычного терминала:

Команда покажет интерфейсы коммутатора, и подключение (eth0).

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

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

Результаты будут одинаковые.

Убедимся, что можем выполнить команду ping от хоста 0 к хоста 1:

Вы увидите управляемый трафик OpenFlow. Первый узел посылает ARP- адрес для MAC-адреса второго, что вызывает передачу packet_in сообщение на контроллер. Затем контроллер присылает packet_out сообщения для рассылки широковещательного пакета на другие порты коммутатора (именно в этом примере – единственный другой порт данных). Второй хост видит запрос ARP и отправляет ответ. Этот ответ отправляется контролеру, который отправляет ее первом хоста да толкает вход потока..

На данный момент, первый хост знает MAC-адрес второго и может отправить свой запрос(ping) через ICMP Echo Request. Этот запрос вместе с соответствующим ему ответом от второго хоста, направляются к контроллера и приводит к отправки записи потока вниз (вместе с фактическими отправленными пакетами).

В сети созданной Mininet, команда ping не является единственной командой, которая может быть запуститься на хосты. Хосты имеют право запускать команды, программу, которая имеется в доступе для базовой системы Linux (или VM) и ее файловой системы. Кроме того, можно ввести любую bash команду, в поэтому числе управление работой (&, jobs, killи т.д..)

Для запуска простого сервера HTTP на h1 вводится команда, какая изображена ниже, сделав запрос от h2, да выключим сервер на h1:

Для выхода с CLI:

За помощью Mininet вы можете создать кастомную топологию со своими параметрам. Костомно топология создается за помощью кода Python выбирает основные параметры для создания топологий. А также ее можно будет использовать для последующих экспериментов.

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

Основные методы, функции, классы, переменные которые встречаются в приведенном выше коде:

().

Также Mininet к базовым поведенческим сетям, дополнительно имеет возможность обеспечить ограничение производительности и имеет возможность изолировать через классы CPULimitedHost и TCLink.

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

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

Программный код , через какой описывается топология имеет такой вид:

После запуска программного кода имеем следующий результат:

Информацию о узлы да элементы можем получить за помощью следующих команд:

Команда nodes, показывает список всех узлов нашей топологии:

Команда links, показывает все связи между хостами и коммутаторами. Также

она выводит информацию о состоянии подключение:

mininet> links

Команда ifconfig, показывает подробную информацию о любой элемент в созданной сети. За пример, можем рассмотреть элемент h1:

Реализована топология имеет такой вид:

Рис 3.2. Реализована топология

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

За помощью функции apt-get update

Заходим на официальный сайт https://www.opendaylight.org/ и переходим в раздел DOWNLOAD HERE

Дальше OpenDaylight Alluminium Zip.

Рис 3.3. OpenDaylight Alluminium Zip

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

Обязательно нужно поставить отметку в check-box Автоподключение.

Рис 3.4.настройки общих папок Результат можно увидеть в проводнику системы.

Рис 3.5. Проводник системы

Архитекторы OpenDaylight разработали OpenDaylight для экосистемы Java. OpenDaylight требует для работы среды выполнения Java (JRE). OpenDaylight может использовать или автономную JRE, или JRE, что входит в комплект Java Software Development Kit.

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

Рис 3.6.Папка с контролером

Рис 3.7. Команда указание JAVA_HOME

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

Рис 3.9. Контроллер запущен

Контроллер OpenDayLight прослушивает порт 6633 OpenFlow для подключение к его узлам. Команда netstat-a | grep 6633 увидеть состояние порта. Проверка состояния OpenFlow порта контроллера представлена на рисунке 4.10.

Как описано выше Mininet запускает кастомные топологии.

Рис 3.10. Запуск топологии с внешним контроллером

Как видим эмулятора нет удалось связаться с пультом дистанционного управление за адресом 192.168.254.3:6653 и 192.168.254.3:6633.

Поэтому посмотрим которые порты слушает контроллер:

Рис 3.11. Порты которые слушает контроллер

Рис 3.12. Порты которые слушает контроллер

Как видим контроллер нет имеет такой портов для прослушивание.

Рис 3.13.Сетевые настройка Mininet

Рис 3.14 Команда установка сетевого пакета

.

Выводы

Рис 3.15.Сетевые настройка контроллеру

РАЗДЕЛ 4

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

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

Таблица 5.1 Описание идеи стартап-проекта

Таблица 5.2

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

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

Таблица 5.4 Факторы угроз

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

Таблица 5.6

Выбор целевых групп потенциальных потребителей

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

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

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

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

Таблица 5.11 Определение границ установка цены

Таблица 5.12 Формирование системы сбыта

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

Выводы

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

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

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

Рассмотрен виртуальный коммутатор Open vSwitch - наиболее

универсальное решение, поддерживает наиболее популярные гипервизоры, включая KVM, Virtual Box, Xen да XenServer. Open vSwitch складывается со службы - коммутатора (user-space) и сопровождающего модуля ядра (kernelspace), который управляет процессом поточной (flowbased) коммутации. Open vSwitch поддерживает широкий набор технологий, включая NetFlow, sFlow, port mirroring, VLAN, LACP, TLS / SSL. Описана структура коммутатору, какую условно можно разделить на две части – user-space и kernel-space.

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

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

https://www.opennetworking.org/images/stories/downloads/sdnresources/t echnical- reports/TR_SDN_ARCH_1.0_06062014.pdf ,

1.0 December 12, 2013.

https://www.opennetworking.org/images/stories/downloads/sdnresources/technic al- reports/SDN-architecture-overview-1.0.pdf ,

1.5.1 (Protocol version 0x06) March 26, 2015 ONF TS-025. https://www.opennetworking.org/wp- content/uploads/2014/10/openflow- switchv1.5.1.pdf ,

https://www.opennetworking.org/images/stories/downloads/sdnresources/white- papers/wp-sdn-newnorm.pdf ,

https://www.osp.ru/netcat_files/userfiles/Ethernet_2015/Smelyansky_R.pdf ,

https: // w w.sdxcentral.com/resources/sdn/southbound- interface-api/.

Rothenberg, S. Azodolmolky and S. Uhlig, '"Software- Defined Networking: A Comprehensive Survey," Действия из IEEE , vol. 103, no. 1, pp. 14- 76.

- Addison-Wesley Professional; 1 edition ,March 12, 2016

OpenFlow Switch Консортиум, Тех. Rep, 2009

http://www.tik.ee.ethz.ch/file/9ee69e89be779fd1448a7356d79ddb18/openflow

_sec. pdf _