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

1. Построение транспортных SDN сетей для
операторов связи
Александр Шалимов
ashalimov@arccn.ru
@alex_shali
@arccnnews

2. • Централизованное управление сетью
 Корректное понятие состояния сети
 Возможность использования математических методов анализа функционирования сети
 Согласованное управление физической и виртуальной инфраструктурой
 Новый взгляд на реализацию политик качества обслуживания
• Снижение уровня зависимости от производителя оборудования
 Единая система управления и мониторинга
 Стандартизация южного интерфейса контроллера
• Повышение уровня безопасности
 Новые возможности по верификации политик в сети
• Снижение стоимости владения сетью
 CAPEX
 OPEX
Зачем операторам связи внедрять SDN:

3. Вариант I: «Greenfield»
• Реализация новой сети на основе SDN решений
• Реализация обособленного SDN блока в сети (Access, Aggregation, Distribution, Core,
Metro segment, Residential network…)
• Нужна ли интеграция с существующей OSS системы или можно задействовать новую?
 Меняется организация технической поддержки.
• Интеграция BSS и SDN контроллера
 Меняется организация обслуживания заказа клиента.
Варианты перехода от традиционной архитектуры сети к
SDN/NFV архитектуре

4. Вариант II: Постепенный переход к централизованному контролю трафика в сети
• Выбор элементов для обновления:
 SDN-коммутаторы в узлах, через которые проходит наибольшее количество потоков.
 SDN-коммутаторы на границе OSPF доменов.
 SDN-коммутаторы в узлах, участвующих в наибольшем количестве циклов.
• Выбор используемых протоколов для обновления:
 PCEP, BGP-LS, Segment Routing
 Netconf, OpFlex
 OpenFlow
• Необходимость интеграции с существующей OSS системой.
 Усложняется процесс технической поддержки.
• Необходимость интеграции с существующей BSS системой.
Варианты перехода от традиционной архитектуры сети к
SDN/NFV архитектуре
Для контроля до 80% сетевого трафика в некоторых случаях требуется обновить 20% сетевой
инфраструктуры

5. Плюсы и минусы различных подходов к внедрению SDN в сети.
Центр прикладных исследований компьютерных сетей
«Greenfield»
Минимизация количества поддерживаемых
протоколов, необходимых для интеграции.
Минимизация затрат на эксплуатацию
фрагмента сети практически с первого дня
Возможность подобрать наиболее
подходящее оборудование
Новая OSS система. Можно обойтись без
интеграции
Необходимость расстаться со старым
оборудованием
Удвоение используемой инфраструктуры на
этапе перехода для работающей сети
Постепенный переход
Возможность постепенной миграции по мере
обновления парка сетевых устройств
Необходимость поддержки всех используемых в
сети протоколов
Выше требования к персоналу. Администратор
сети должен уметь все.
Необходимость интеграции с существующей OSS
подсистемой
Чрезвычайная сложность при обнаружении
неисправности в сети

6. • Проблема выбора коммутатора программного или аппаратного:
 Производительность vs функциональность
 Количество портов и скорость работы портов
 Количество и размерность таблиц, поддерживаемые поля.
 Занимаемое место в стойке
• Различная трактовка производителями протокола (OpenFlow)
• OpenFlow сложный (низкоуровневый) протокол для программирования.
• Необходимость подстройки контроллера и приложений под возможности
коммутаторов
 Слабый Control Plane процессор на аппаратных коммутаторах
 Специфичный pipeline (OFDPA, FPA)
 Поддержка не всех опциональных возможностей протокола (QoS, Meter, GroupFF, GroupSelect..)
 Сложности с поддержкой in-band управления.
• Необходимость проверки совместимости всех компонент решения
 Необходимость лабораторного тестирования
 Необходимость проведения пилотов
• Отсутствие точной оценки экономической эффективности
Дополнительные трудности

7. High level SDN Programming paradigm
Applications
Conflict resolution system
Rules generation system
Hardware dependent rules
modification system
Pure OpenFlow
OpenFlow*
SDN Controller/Compiler
IR
Архитектура SDN контроллера с точки зрения
программирования

8. Система управления транспортной сетью

9. Филиал
SDN/OpenFlow
controller
SDN/OpenFlow
controller
CGNAT BRAS GW DDoS
Telco Cloud/Telco Legacy
DR2DR1
AR7AR1 AR3
AR2AR5 AR6 AR4
AR8
RunDR
Программный Open Flow коммутатор
на базе сетевого процессора для
высокоскоростной передачи трафика
RunAR
Программный Open Flow коммутатор на базе
х86 сервера для агрегации трафика.

10. Сервисы и сервисные модели, обеспечиваемые филиалом
1. Построение сервисных моделей через произвольную топологию AR-DR
2. Обеспечение управления «out of band» для DR и «in band» для AR
3. Отказоустойчивость контроллеров SDN по принципу Active/Standby
4. Транзит L2 трафика B2C и B2B/G абонентов к сервисным устройствам.
5. Транзит L2 трафика между точками присутствия абонентов B2B, B2G (точка-точка, точка-многоточка, многоточка-
многоточка)
6. Резервирование путей движения клиентского трафика по необходимости с минимальным временем восстановления
сервиса.
7. Обеспечение многопараметрической маршрутизации трафика, в том числе и на основании выбора кратчайшего пути.
8. Транзит multicast и VoIP трафика абонентам
9. «Шторм-контроль» для широковещательного трафика
10. Обеспечение параметров QoS для трафика клиентов (PQ,WRR, Policiers, очереди), отдельно управляющего трафика.
11. Поддержка LAG, в том числе с протоколом LACP
12. Отображение статистики в GUI в режиме реального времени.

11. RunOS является отечественным SDN контроллером собственной разработки. RunOS является
самым производительным контроллером в мире, что доказано экспериментально, и имеет
развитый API для разработки новых сетевых приложений.
RunOS с приложениями совместим с коммутаторами многих
вендоров
Сервисы Режимы работы Управление QoS
‐ В2С, VPN (P2P,
MP, GRE, IPSec),
B2B
‐ Multicast
‐ Storm Control
‐ LAG/LACP
‐ InBand
/OutOfBand
‐ VLAN translation
‐ Маршрутизация
по параметрам
‐ Зеркалирование
‐ Active/StandBy
‐ Поддержка
произвольной
топологии
‐ Fast Failover
резервирование
‐ Ручное и
автоматическое
резервирование
маршрутов
‐ Priority
Queuing, WRR
‐ Rate‐Policy,
Ingress QoS,
metering;
‐ Гибкое
управление
очередями
Базовая функциональность контроллера является международным
OpenSource проектом (http://arccn.github.io/runos).
SDN контроллер RunOS с приложениями

12. Графический интерфейс

13. Программный коммутатор RunAR работает на базе
стандартных серверов х86 архитектуры с набором сетевых
карт, поэтому производительность RunAR ограничивается
только возможностями аппаратной платформы, а
использование технологии Intel DPDK гарантирует
максимально возможную производительность.
RunAR поддерживает стандарт OpenFlow 1.3, а так же его
расширения по управлению и настройке QoS, анализа и
оценки качества каналов связи, а так же балансировки
нагрузки.
Стандартные требования к коммутатору агрегации:
• 2‐4х10 GE интерфейса Uplink
• 24х1 GE интерфейсов доступа
Производительность:
• 10 Гбит на ядро процессора CPU
• Использование аппаратного хэша сетевых карт для повышения
производительности
Intel based x86 server
NIC NIC NIC
Linux
RunAR
DPDK
Программный коммутатор RunAR

14. RunDR это первый российский SDN‐коммутатор на базе сетевого процессора. Коммутатор предназначен для построения
высокоскоростных SDN сетей корпоративного и операторского уровня.
Коммутатор полностью поддерживает протокол OpenFlow v1.3, а так же расширения необходимые для реализации
корпоративной сети и сети оператора связи
Основные преимущества RunDR:
• Добавление/изменение функционала через обновление ПО;
• Возможность кастомизации;
• Поддержка WFQ, Strict Priority, WRED, Shaping (CIR, PIR), Per
flow metering, Marking, Policing
Основные технические характеристики:
• Производительность до 240 Гбит/с;
• Поддержка групповых таблиц;
• Сетевые интерфейсы 44х10 Гбит/с или 11х40 Гбит/с
или 4х100 Гбит/с
Коммутатор на базе NPU RunDR

15. Сервисная модель управления транспортной сетью
Управление сетью через
произвольную топологию AR-DR
Обеспечение управления «out of
band» для DR и «in band» для AR
Отказоустойчивость OpenFlow
контроллеров по принципу
Active/Standby

16. Сервисная модель B2C
BRAS 1 BRAS 2
DR2
AR1 AR2
DR1
MAC
Learning
BRAS
PW
туннель
QinQ
DHCP/
PPPOE
сессия
Резервный
сервис
Обеспечение надежного доступа в
Internet и к сервисам, предлагаемым
для абонентов.
CGNA
T

17. Сервисная модель B2B
Обеспечение надежного доступа в Internet и к
сервисам, предлагаемым для абонентов, а так же
связь между точками присутствия абонента.
(МР/Р2Р)
Реализовано с помощью
Технологии «Синтетический МАС»

18. Резервирование путей
Наглядное отображение
основного и запасного
маршрутов для каждого
соединения для
построенного сервиса

19. Многопараметрическая маршрутизация
Разнообразные
критерии
выбора
маршрутов

20. Транзит multicast трафика
Контроль и управление
multicast вещанием

21. Поддержка политик QoS
Конфигурирование, контроль и
визуализация работы политик
качества обслуживания

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

23. Система управления сетью
Отображение
статистики в
GUI в режиме
реального
времени

24. 26