1. Удивительно видеть, что посторонний человек гораздо лучше в курсе о том, что у нас происходит, чем мы сами). Открытая версия контроллера развивается по своим направлениям и отлично от коммерческой — много архитектурных решений отличаются от того, что есть в открытом доступе. Версия 1 нашего открытого контроллера появится, когда мы решим ряд алгоритмических научных проблем связанных с новой абстракцией для программирования. В этом и есть ниша и суть открытой версии контроллера. И именно этим она интересна сообществу — 70% пользователей не из России. Коммерческая версия находится на тестировании у потенциальных заказчиков. Есть протоколы тестирования, есть понятные направления развития контроллера дальше, но это уже другая история.
2. По скорости и работы и задержкам мы понимаем ту величину, которая требуется контроллеру для принятия решений. Например, время для пересчета перестроения заданного количества сервисов (от 100 до 1000 сервисов) — время от детектирования критической ситуации в сети до подготовки всех правил на отправку. Мы сравнивали с существующими версиями открытых контроллеров. Разумеется, итоговое время будет зависеть и от способности физического оборудования, но и здесь есть свои успехи при более плотной работе с производителями сетевого оборудования.
3. Juniper OpenContrail заточен на управление виртуальной инфраструктурой. Мы сосредочены на управлении физическим сетевым оборудованием.
4. К сожалению, сравнить с контроллером компании Brain4Net затруднительно в связи с отсутствием материалов в открытых источниках, а также с отсутствием информации о прохождении каких-либо тестов. Нам тоже хотелось узнать, в чем особенность вашего контроллера и почему во времена существования как минимум 4-х популярных открытых контроллеров на Java (ONOS, OpenDaylight, Floodlight, Beacon), вы начали разработку своего контроллера тоже на Java? Если вы не разрабатывали свой контроллер, а просто взяли Beacon и сделали дополнительные настройки по производительности, то тогда логика понятна. Если нет, то поясните, пожалуйста.
1. Главное — это простота работы с сервисами, например, а-ля l2vpn (настройка и автоматизация управления) и интеграция со сторонними система (oss/bss и другие системы). Убеждаем обычно объяснением примеров и демонстрациями.
2. В реальной жизни практически везде нужно in-band управление через канал с данными. При этом возникает много сложностей типа отказ канала, перегрузка канала. Все эти моменты надо учитывать. Первичный набор правил на коммутаторе для inband прописывается через его консоль. Дальше уже управление и всю логику работы подхватывает контроллер.
3. Мы начали разработку контроллера (его разных версий) еще даже до OpenDaylight — делали это осознанно, изучив, как недостатки и достоинства тогда существоваших. Основное преимущество это скорость работы и маленькие задержки. Наш контроллер на C++, в отличии от используемого во всех остальных контроллера языка Java.
конечно, смотрели и ведем соответствующие работы. Но P4 для настройки pipeline сетевого оборудования — кол-во таблиц, связи, поля и действия. OpenFlow все равно расматривается, как основной протокол управления. Подробнее прочитайте здесь.
API по работе с OpenFlow это свойство не протокола OpenFlow, а того контроллера или системы управления, которую вы используете при программировании. У нас в открытой версии контроллера как раз и идут разработки по этой тематике.
OpenFlow вышел из научной лаборатории, все другие протоколы пришли от вендоров, поэтому, скорей всего, наиболее честный SDN со всеми его обещаниями независимости от вендоров, программируемости, централизованности — это OpenFlow. Все другие протоколы развиваются нишево, под узкие задачи управления MPLS (PCEP, segment routing, BGP-LS) и поддерживаются еще реже, чем OpenFlow и, как правило, в дорогостоящих современных устройствах.
Но, мы понимаем, у OpenFlow есть целый ряд недостатков, которые не позволяют полностью удовлетворить потребности заказчиков.
Мы видим, что этот недостаток можно решить двумя способами:
Доработка OpenFlow для поддержки функционала, необходимого нашим заказчикам;
А для заказчиков, сети которых построены с использованием современного оборудования, поддерживающее функционал MPLS, PCEP, нужно добавить соответствующий функционал в контроллер.
У RunOS есть сейчас 2 версии: коммерческая с сервисами для телекомов, которая сейчас проходит пилотирование у нескольких заказчиков, и open-source версия, у которой недавно вышел релиз 0.6.
2. По скорости и работы и задержкам мы понимаем ту величину, которая требуется контроллеру для принятия решений. Например, время для пересчета перестроения заданного количества сервисов (от 100 до 1000 сервисов) — время от детектирования критической ситуации в сети до подготовки всех правил на отправку. Мы сравнивали с существующими версиями открытых контроллеров. Разумеется, итоговое время будет зависеть и от способности физического оборудования, но и здесь есть свои успехи при более плотной работе с производителями сетевого оборудования.
3. Juniper OpenContrail заточен на управление виртуальной инфраструктурой. Мы сосредочены на управлении физическим сетевым оборудованием.
4. К сожалению, сравнить с контроллером компании Brain4Net затруднительно в связи с отсутствием материалов в открытых источниках, а также с отсутствием информации о прохождении каких-либо тестов. Нам тоже хотелось узнать, в чем особенность вашего контроллера и почему во времена существования как минимум 4-х популярных открытых контроллеров на Java (ONOS, OpenDaylight, Floodlight, Beacon), вы начали разработку своего контроллера тоже на Java? Если вы не разрабатывали свой контроллер, а просто взяли Beacon и сделали дополнительные настройки по производительности, то тогда логика понятна. Если нет, то поясните, пожалуйста.
2. В реальной жизни практически везде нужно in-band управление через канал с данными. При этом возникает много сложностей типа отказ канала, перегрузка канала. Все эти моменты надо учитывать. Первичный набор правил на коммутаторе для inband прописывается через его консоль. Дальше уже управление и всю логику работы подхватывает контроллер.
3. Мы начали разработку контроллера (его разных версий) еще даже до OpenDaylight — делали это осознанно, изучив, как недостатки и достоинства тогда существоваших. Основное преимущество это скорость работы и маленькие задержки. Наш контроллер на C++, в отличии от используемого во всех остальных контроллера языка Java.
API по работе с OpenFlow это свойство не протокола OpenFlow, а того контроллера или системы управления, которую вы используете при программировании. У нас в открытой версии контроллера как раз и идут разработки по этой тематике.
Но, мы понимаем, у OpenFlow есть целый ряд недостатков, которые не позволяют полностью удовлетворить потребности заказчиков.
Мы видим, что этот недостаток можно решить двумя способами:
По обоим направлениям мы ведем работу.