Программирование уровня передачи данных в ПКС

Руслан СМЕЛЯНСКИЙ, директор по науке и образованию ЦПИКС, профессор, заведующей лаборатории МГУ им. М.В. Ломоносова, д. ф-м. н.

Александр ШАЛИМОВ, ведущий программист-исследователь ЦПИКС, младший научный сотрудник МГУ им. М.В. Ломоносова, кандидат физико-математических наук

Евгений ЧЕМЕРИЦКИЙ, программист-разработчик ЦПИКС, аспирант МГУ им. М.В. Ломоносова

Программно-конфигурируемые сети и управляющие сетевые приложения

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

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

Сейчас подход ПКС явно не требует последнего пункта об открытости интерфейса управления. Многие вендоры разрабатывают и продвигают свои проприетарные протоколы.

В архитектуре ПКС выделяют три основных уровня (рис. 1):

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

Рис. 1. Архитектура ПКС

Взаимодействие между уровнями осуществляется посредством программного интерфейса (API). Интерфейс взаимодействия между инфраструктурным уровнем и уровнем управления называется южным (SouthBound API), между уровнем управления и уровнем сетевых приложений – северным (NorthBound API). Де-факто стандартом SouthBound API является протокол OpenFlow, обеспечивающий взаимодействие сетевой ОС с OpenFlow совместимым коммутирующим оборудованием и позволяющий ей задавать правила коммутации и собирать статистику по переданным данным. Сейчас этот протокол разрабатывается ассоциацией Open Networking Foundation, состоящей из производителей сетевого оборудования и крупных ИТ-компаний. NorthBound API не стандартизирован и различен для каждой сетевой ОС, что исключает возможность перенести сетевое приложение с одного контроллера на другой. Основная цель данного интерфейса – предоставить удобную программную модель для разработки новых сетевых приложений.

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

Уже сейчас большинство сетевых ОС поддерживает множество сетевых приложений, как традиционных, так и инновационных. Многие из них ранее были доступны только в качестве аппаратных решений: маршрутизация L2/L3 с QOS и многопотоковая маршрутизация, балансировка нагрузки, фильтрация трафика, аутентификация, SPAN-порты, NAT, ARP, DNS, DHCP, BGP.

Кроме того, существует возможность реализовать более продвинутые сервисы, например, в ЦОД использовать функционал централизованного мониторинга сети для отключения незадействованного оборудования. Если мы понимаем, что какое-то сетевое устройство загружено не полностью, то можем его отключить, перераспределив его потоки на другие коммутаторы. Таким образом, в среднем за день можно достигнуть экономии до 60%.

Другим примером приложения для сетевой ОС является разработка интеллектуальных Anti-DDOS-систем. Благодаря централизованному построению маршрутов и контролю всего сетевого трафика подозрительный поток при необходимости может быть отправлен на существующие средства DPI для анализа. Если этот поток действительно не является легитимным, его передачу можно запретить на границе сети, поставив всего лишь одно новое правило.

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

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

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

Рис. 2. Пример графического интерфейса централизованного управления копроративной сетью на основе ПКС

Контроллер

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

Рис. 3. Архитектура сетевой ОС

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

На сегодняшний день существует более 25 OpenFlow-контроллеров, среди которых есть как проприетарные, так и Open Source-контроллеры, причем проприетарные часто разработаны на основе открытых. Например, на базе контроллера с открытым исходным кодом Beacon создан контроллер Floodlight – разработка компании Big Switch Networks. Оба контроллера послужили основой для Cisco One Controller, который позднее мигрировал в OpenDaylight Controller. Часть контроллеров с открытым исходным кодом уже не поддерживается разработчиками, некоторые настолько плохо написаны, что «падают» при небольшой нагрузке. Наиболее широкое применение нашли следующие контроллеры:

NOX – первый OpenFlow-контроллер. Разработан инженерами Nicira Networks параллельно с протоколом OpenFlow;

POX – «младший брат» NOX. Если при разработке NOX основной целью была высокая производительность, то POX предназначен в первую очередь для обучения и исследования. По сути, это платформа для быстрой разработки и прототипирования ПО управления сетью;

Beacon – достаточно быстрый, кросс-платформенный, модульный OpenFlow-контроллер. Используется во многих научно-исследовательских проектах и тестовых внедрениях/развертываниях. Применяется в экспериментальном ЦОД Стэнфорда, где он управляет 100 виртуальными и 20 физическими коммутаторами;

Floodlight – контроллер корпоративного уровня, разработан на основе Beacon компанией Big Switch Networks. Как и другие контроллеры на Java, является модульным, что очень удобно для разработчиков. FloodLight поддерживает широкий спектр виртуальных и физических коммутаторов, способен поддерживать смешанные OpenFlow-сети и сети традиционной архитектуры;

Ryu – поддерживает работу множества протоколов для управления сетевыми устройствами: OpenFlow, Netconf, OF-Config и т. д. Заявлено, что Ryu поддерживает все версии протокола OpenFlow до последней 1.4 и Nicira Extensions;

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

MUL – поддерживает многоуровневый интерфейс для сетевых приложений. Главной задачей при его разработке было обеспечение производительности и надежности, что необходимо при развертывании критически важных сетей. Контроллер с открытым кодом MUL является базой для коммерческого контроллера Kulcloud Networks (Южная Корея).

При выборе контроллера обычно руководствуются следующими критериями:

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

Наиболее совершенные на сегодняшний день контроллеры имеют следующие характеристики:

максимальная производительность – 7 млн потоков в секунду (контроллер Beacon);
минимальное время задержки – от 50 до 75 мкс.

Как показывают проведенные в 2010 г. исследования характеристик потоков данных, возникающих в американских ЦОД, в среднем через коммутатор уровня access (тот, к которому подключаются серверы с виртуальными машинами) проходит от 2 до 30 млн новых потоков в секунду. Таким образом, производительности современных сетевых ОС пока недостаточно.

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

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

Рис. 4. Организация распределенной сетевой ОС

Проблемы программирования управляющих сетевых приложений

Реализация концепции программно-конфигурируемых сетей обеспечивает гранулярный контроль над обработкой передаваемых через сеть потоков данных и широкие возможности для программирования ее логики. Поскольку основная сложность управления сетью при этом переносится с сетевых администраторов на разработчиков управляющих приложений, необходимость в технологиях, упрощающих программирование сетей, резко возрастает. Актуальность и интенсивность данного вектора развития подтверждает появление инструментальных средств, предназначенных специально для формальной верификации (например, NICE) и отладки (OF Rewind, STS, NDB и др.) управляющих приложений контроллера.

Активно ведется и работа по построению эффективного Northbound API – программного интерфейса для взаимодействия между контроллером и приложениями. Существует несколько независимых групп исследователей, целью которых является разработка библиотек, составляющих этот интерфейс функций. Системы Frenetic, Maestro, Procera и Nettle представляют собой специализированные языки программирования (DSL), включающие указанные функции на уровне языковых конструкций. В списке требований к предлагаемым ими примитивам:

поддержка модульного программирования. Большинство современных контроллеров позволяет запускать несколько управляющих приложений одновременно. Однако взаимное влияние приложений обычно не контролируется и, как следствие, не любая их композиция корректна. Грамотно подобранные абстракции позволяют реализовывать отдельные задачи администрирования сети в виде независимых программных модулей с возможностью их автоматического объединения. Таким образом, для реализации произвольной политики маршрутизации достаточно скомпоновать множество модулей с заданными свойствами;
упрощение стандартных операций. Аналогично оберткам над интерфейсами низкоуровневых системных библиотек абстрактные примитивы для работы с командами управления коммутаторами должны упростить реализацию распространенных операций. Например, большинство программ контроллера работает по следующей стандартной схеме: приложение собирает информацию о сети, затем строит маршрут передачи потока через полученный граф топологии и, наконец, устанавливает соответствующие ему правила обработки пакетов в таблицы коммутаторов. Причем каждая из операций может быть в некоторой степени автоматизирована.

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

Список базовых алгоритмов, доступных разработчикам через Northbound API современных контроллеров программно-конфигурируемых сетей, включает:

мониторинг функционирования сети. Практически каждый современный контроллер содержит средства для автоматического построения и периодического обновления топологии сети. Программно-конфигурируемые сети позволяют реализовать эффективные средства мониторинга загруженности сетевой инфраструктуры, а также оценить характеристики качества сервиса, предоставляемого отдельным потокам данных. Например, средство OpenTM обеспечивает возможность оперативного наблюдения за пропускной способностью соединений между каждой парой сетевых устройств, затрачивая на этом минимальное количество ресурсов сети. Не менее актуальной представляется разработка методов и средств измерения сквозной задержки;
построение маршрутов с заданными свойствами. Целостность и высокая степень детализации представления сети, доступного для прикладных приложений, позволяют им управлять передачей потоков данных и распределением ресурсов сетевой инфраструктуры более эффективно. Благодаря построению множества дублирующих маршрутов средство FatTire способно обеспечить мгновенное переключение потока на дополнительный маршрут передачи данных в случае выхода из строя его основного маршрута. Известны алгоритмы для быстрого построения маршрутов с субоптимальными характеристиками, интересных при одноранговой маршрутизации в сетях большого размера. Перспективной исследовательской задачей является разработка методов многопоточной маршрутизации, при которой отправляемые через одно и то же сетевое соединение данные балансируются между несколькими маршрутами. Решения для многопоточной передачи данных имеются и в традиционных сетях, однако они либо осуществляют балансировку на уровне целых сессий и не способны повысить уровень качества отдельного соединения (ECMP Routing), либо работают на уровне конечных узлов и не способны оказывать прямое воздействие на работу сетевых устройств (MP TCP);
генерация содержимого таблиц коммутации. Построение такого множества правил коммутации, которое бы соответствовало политикам маршрутизации сети, является нетривиальной задачей даже при заданных маршрутах передачи данных. Каждое правило коммутации может оказывать влияние сразу на несколько потоков, и новое правило может, например, повлиять на маршрут передачи одного из существующих потоков. На сегодняшний день разработано несколько средств верификации корректности построенной конфигурации сети относительно заданного множества политик маршрутизации (NetPlumber, Veriflow, AntEater, AP Verifier). Ограниченный размер таблиц правил коммутационных устройств делает актуальными и вопросы минимизации количества хранящихся в них правил;
модификация таблиц коммутации. Асинхронное по своей природе функционирование сети исключает возможность мгновенного проведения сколько-нибудь значимых модификаций ее конфигурации. Поэтому в процессе обновления сеть неминуемо оказывается в состоянии, когда в таблицах могут одновременно находиться правила как из прежней, так и из новой конфигурации. Такая несогласованность способна привести к проблемам сразу нескольких типов: в сети могут появиться циклы, а некоторые узлы могут стать недостижимыми; часть сетевого трафика может пройти по небезопасному маршруту; может произойти нарушение качественных требований передаваемых потоков.

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

Оценка рынка ПКС решений

Рынок ПКС только формируется, на нем доминируют технически продвинутые клиенты (новаторы), которые проводят исследования новых технологий, занимаются перспективными разработками или пилотными внедрениями. Технологии ПКС пока не готовы к массовому внедрению, сейчас проходит стадия так называемого раннего рынка.

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

Рынок ПКС-решений только движется от лабораторных исследований к рыночной продукции, четких стандартов до сих пор не существует. Аналитическое агентство Markets& Marketsпрогнозирует, что объем рынка ПКС-продуктов к 2016 г. превысит 2 млрд долл. (прогноз включает в себя оценку не только рынка коммутаторов и маршрутизаторов, но и рынка сервисов и программного обеспечения). Агентство Dell’OroGroup предполагает, что в период 2010–2016 гг. общая сумма расходов компаний на ПКС возрастет более чем в 17 раз. В соответствии с отчетом Dell’OroGroup почти все производители сетевого оборудования к 2016 г. будут поддерживать ПКС и предлагать продукты на основе этой технологии, однако ее потенциал будет использован лишь частично.

Консалтинговая корпорация Forrester предполагает, что пройдет не менее пяти лет, прежде чем решения и продукты на основе ПКС достигнут требуемой степени готовности для их массового применения в бизнесе. Предстоит большая работа по совмещению всех разрозненных компонентов, интеграции их в существующие системы управления, оркестровке программного обеспечения, управлению решений на основе гипервизора и обеспечению сервисов на уровнях сети L4-L7.

Год назад был опубликован маркетинговый отчет агентства SDNCentral, компании Plexxi и венчурного агентства LightspeedVentures, который резко увеличил прогнозируемый объем рынка. С учетом последних тенденций размер рынка ПКС к 2018 г. может достичь объема в 35 млрд долл.

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

В последние годы наблюдается увеличение объема продаж ПКС-технологий (2007 г. – 10 млн долл., 2012 г. – 252 млн долл.). Компании обращаются к новым программным технологиям контроля компьютерных сетей, тем самым выходя за рамки традиционной сетевой инфраструктуры.
Развитие рынка ПКС поддерживается ростом венчурных инвестиций в ПКС-ориентированные компании.

В марте 2011 г. было объявлено о создании некоммерческой организации «Фонд открытых сетевых технологий» (OpenNetworkingFoundation), которая нацелена на продвижение и стандартизацию ПКС-подхода. Управляющий совет OpenNetworkingFoundation сформирован из шести компаний-учредителей: DeutscheTelekom, Facebook, Google, Microsoft, Verizon, и Yahoo. Сейчас в Фонде свыше 100 традиционных лидеров сетевой индустрии.

Большинство ведущих ИТ-компаний, занимающихся технологиями ПКС, в марте 2013 г. заявили о поддержке проекта OpenDaylight, в рамках которого будет создаваться платформа для ПКС с открытым кодом. Среди прочих в проекте решили участвовать Cisco, VMware, JuniperNetworks, IBM, HP, Dell, Intel и Ericsson, а организацией работы занимается LinuxFoundation. В рамках проекта будет создан ПКС-контроллер с интерфейсами для сетевых приложений и сетевого оборудования, а также другие приложения и компоненты сетей ПКС.

Появление рынка ПКС-технологий стимулируется венчурными инвестициями в компании, ориентированными на ПКС. С 2007 по 2012 г. объем венчурных инвестиций вырос с 10 млн до 454 млн долл. Венчурные инвесторы отмечают, что сильные технические команды покидают компании-лидеры сетевой индустрии с целью инициировать собственные проекты и создавать революционные технологии.

Таблица. Перспективные стартапы в сфере ПКС

Стартап	Год основания, страна	Сфера деятельности	Объем инвестиций, млн долл.	Инвесторы
Embrane	2009, США	Решения для ЦОД	27[i]	New Enterprise Associates, Lightspeed Venture Partners, North Bridge Venture Partners
Plumgrid	2011, США	Решения для ЦОД	10,7	Hummer Winblad Venture Partners, US Venture Partners
Pica8	2009, США	РешениядляЦОД	6,6	н/д
ConteXtream	2006, США	Облачныетехнологии	23,6	Gemini Israel Funds, Sofinnova Ventures, Benhamou Global Ventures, Norwest Venture Partners
Midokura	2010, Япония-США	Облачныетехнологии	17,3	Innovation Network Corporation of Japan, NTT Investment Partners L.P., Innovative Ventures Fund Investment L.P., Sun Bridge Global Venture L.L.P
Pertino	2011, США	Облачныетехнологии	28,9	Jafco Ventures, Norwest Venture Partners, Lightspeed Venture Partners
Cyan	2006, США	Телекоммуникации	30,8	Norwest Venture Partners, Azure Capital Partners, Tenaya Capital, Focus Ventures, TDF Fund
Vello Systems	США	Телекоммуникации	25	н/д
LineRate Systems	2008, США	Enterprise	4,75	Boulder Ventures
vArmour	2011, США	Безопасность	6	Highland Capital Partners
NoviFlow	2012, Канада	РешениядляЦОД	н/д

Венчурные фонды, инвестирующие в ПКС-стартапы:

IndexVentures (венчурный фонд объемом в 2 млрд евро, штаб-квартиры в Швейцарии, Англии и США) инвестировал в 2011 и 2012 г. 18,8 млн и 25 млн долл. соотвественно в стартап BigSwitchNetworks;
NewEnterpriseAssociates, NEA (венчурный фонд объемом 11 млрд долл., штаб-квартира в Калифорнии) инвестировал в 2011 г. в стартап Embrane[1] 18 млн долл., в Nicira– 26 млн долл., в 2013 г. в стартап PluribusNetworks– 44 млн долл.[ii];
KoshlaVentures (венчурный фонд объемом 1,3 млрд долл., штаб-квартира в Калифорнии) инвестировал в 2012 г. в ContrailSystems 10 млн долл.;
MenloVentures(венчурный фонд объемом 420 млн долл., штаб-квартира в Калифорнии) в 2013 г. вложил 44 млн долл. в стартап PluribusNetworks;
LightspeedVenturePartners(венчурный фонд объемом 2 млрд долл., штаб-квартира в Калифорнии) в 2011 г. и 2012 г. вложил по 20 млн долл. в стартап Plexxi, в 2012 г. и 2013 г. 8,85 млн долл. и 20 млн долл. соответственно в старт Pertino.

Среди стартапов наибольший объем венчурных инвестиций привлек проект PluribusNetworks, который предлагает программную сетевую платформу для виртуализации сети частных облаков и ЦОД. Общий объем привлеченных средств превысил 60 млн долл. от фондов NEA, MenloVentures и др.[iii] Стартапы Plexxi[iv] (запущен в 2010 г., предлагает ПКС-коммутаторы со встроенной частью контроллера, которые используют протокол собственной разработки (не OpenFlow) и BigSwitchNetworks[v] (основан в 2010 г., предлагает решения для виртуализации сетей ЦОД) привлекли соответственно 48 и 45 млн долл. венчурных инвестиций.

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

[i]Embranehttp://www.businessinsider.com/software-defined-networking-startups-2013-1?op=1

[ii]New Enterprise Associateshttp://www.crunchbase.com/financial-organization/new-enterprise-associates

[iii]Pluribus Networkshttp://www.crunchbase.com/company/pluribus-networks

[iv]Plexxihttp://www.crunchbase.com/company/plexxi

[v]Big Switch Networkshttp://www.crunchbase.com/company/big-switch-networks

Следите за нашими новостями в Телеграм-канале Connect