CC BY
114ОБЗОР ТЕХНОЛОГИИ «ПРОГРАММНО-КОНФИГУРИРУЕМЫЕ СЕТИ ПКС/SDN»
УДК 004.413.5
А.А. Терешкевич, ПАО «Газпром автоматизация» (Москва, РФ),
A.Tereshkevich@gazauto.gazprom.ru
А.Н. Зубалов, ПАО «Газпром автоматизация» (Москва, РФ), a.zubalov@gazauto.gazprom.ru
В статье определяются понятия ПКС/SDN, дается краткий обзор технологии и области применения, приводятся примеры основных архитектурных подходов реализации SDN. Рассматриваются текущее состояние технологии и предложения на рынке, эффективность внедрения новой технологии, решения проблем традиционных сетей. Также приводятся примеры реализаций SDN на мировом рынке телекоммуникаций.
КЛЮЧЕВЫЕ СЛОВА: ПКС, СЕТИ ПЕРЕДАЧИ ДАННЫХ, ЦОД, SDN, OPENFLOW, API.
Программно-конфигурируемые сети ПКС/SDN (Software Defined Networking) - это новая концепция строительства и эксплуатации сетей передач данных и центров обработки данных, путь к автоматизации, программируемости и открытости сетей. Экспоненциальный рост трафика, эволюция сервисных моделей в центрах обработки данных, резкий всплеск технологий виртуализации трансформируют подходы к строительству и эксплуатации классических сетей передачи данных.
АРХИТЕКТУРА И ПРОБЛЕМЫ ТРАДИЦИОННЫХ СЕТЕЙ
Как выглядит архитектура традиционных, или классических, сетей? Это сети из распределенных автономных сетевых элементов (коммутаторов и маршрутизаторов).
Архитектура классических сетей берет свои корни из военного проекта ARPANET - прообраза современного Интернета. Сеть ARPANET должна была работать даже в случае уничтожения значительной ее части. При такой архитектуре требуются автономность и интеллектуальность сетевого элемента. Эти модули должны самостоятельно вычислять/пересчи-
тывать маршруты при изменении топологии и перенаправлять трафик. В соответствии с этим принципом проектируются, строятся и эксплуатируются сегодняшние традиционные сети. Но,несмотря на довольно простую архитектуру, такие сетевые решения все больше усложняются. К примеру, для обеспечения сервиса L3VPN с функцией трафик-инжиниринга ТЕ требуется одновременная работа четырех отдельных контрольных протоколов (IGP-LDP-MPBGP-RSVP), и это далеко не самая тяжелая конструкция, используемая
в сетях передач данных.Традиционные сети имеют крайне низкую автоматизацию для внедрения/ изменения сетевого сервиса. К примеру, чтобы добавить VLAN или VPN, необходимо произвести изменение конфигурации каждого сетевого элемента, реализующего данный сервис, причем в большинстве случаев настройка оборудования будет производиться через командную строку. Такими сетями сложно управлять, их сложно эксплуатировать и трудно масштабировать. Сложность решений делает сети хрупкими. Сети строятся из
Плоскость управления (management plane)
Плоскость контроля (control plane)
Плоскость передачи (forwarding plane)
Управление устройством е- (CLI, GUI, ...)
Управление трафиком (STP, OSPF, ...)
Передача трафика
Рис. 1. Сетевой элемент традиционной сети
Tereshkevich A.A., Gazprom Avtomatizatsiya, PJSC (Moscow, RF), A.Tereshkevich@gazauto.gazprom.ru Zubalov A.N., Gazprom Avtomatizatsiya, PJSC (Moscow, RF), a.zubalov@gazauto.gazprom.ru
Review of the technology Software-Defined Networks (SDN)
The article defines the term SDN and provides a brief review of the technology and its area of application, presents examples of the main architectural approach to the implementation of SDN. The current state of the technology and market offers, efficiency of the implementation of a new technology, of solving the problems of traditional networks, are discussed. Examples of the implementation of SND in the telecommunications global market are also presented.
KEY WORDS: SDN, DATA TRANSMISSION NETWORKS, DPS, SDN, OPENFLOW, API.
дорогостоящего сетевого оборудования с многофункциональным уровнем управления (control plane), высокопроизводительным и таким же многофункциональным уровнем передачи (forwarding plane). Программное обеспечение сетевого оборудования поддерживает огромное количество протоколов и дополнительных функций, в то время как средний сетевой элемент может использовать 5-10 % своих возможностей, а оплачивается на 100 %. Закрытость программного обеспечения и отсутствие открытого интерфейса на оборудовании нивелируют возможность внедрения своего функционала на сети передачи данных.
Большинство реализованных сегодня сетей передачи данных создано на платформах с глубоко интегрированным программным обеспечением (iOS, JunOS и т. д.), которое управляется в основном через интерфейс командной строки (CLI). Такие сети были эффективны в средах со статическими сетевыми конфигурациями, статическими рабочими нагрузками и невысокой скоростью масштабирования приложений. Современные реалии требуют от сетей передач данных большего.
ПКС^^ПОДХОД
Концепция «Программно-конфигурируемые сети/Software Defined Networking (ПКС/SDN)» родилась в стенах университетов Стэнфорда и Беркли [1]. Основная идея концепции -перейти от управления отдельными экземплярами сетевых
элементов к управлению сетью в целом, реализовать возможность программирования сети и автоматизации. Базовым для SDN считается документ, опубликованный организацией Open Networking Foundation (ONF) [2], занимающейся стандартизацией протокола OpenFlow как одного из ключевых технологических основ SDN. Архитектура SDN (рис. 2) состоит из трех уровней: уровня приложений (application layer), контрольного уровня (control layer) и уровня сетевой инфраструктуры (infrastructure layer).
Уровень сетевой инфраструктуры (infrastructure layer). Отвечает за передачу данных (forwarding) и реализуется на сетевых устройствах.
Контрольный уровень (control layer). Плоскость контроля (control plane) убирается с сетевых устройств и переносится на цен-
тральный контроллер (SDN Control software). SDN-контроллер на основании политик, получаемых от уровня приложений, вычисляет и задает сетевым устройствам правила действий по коммутации/маршрутизации трафика. Наличием контрольного уровня достигается абстракция сети.
Уровень приложений (application layer). Функции более высокого уровня реализуются на приложениях (business application). Приложения на высоком уровне абстракции определяют и задают политики работы сети через централизованный SDN-контроллер - к примеру, передают определенный трафик из точки А в точку Б по самому незагруженному пути. Приложения могут быть запущены, в том числе, и на самом SDN-контроллере, самые простые примеры таких приложений: learning switching, routing и т. п.
APPLICATION LAYER
(УРОВЕНЬ ПРИЛОЖЕНИЙ)
CONTROL LAYER
(КОНТРОЛЬНЫЙ УРОВЕНЬ)
INFRASTRUCTURE LAYER
(СТРУКТУРНЫЙ УРОВЕНЬ)
Network Device
(сетевое устройство)
Business Applications
(бизнес-процессы)
SDN
Control
Software
Control Data Plane Interface (e.g., OpenFlow)
Network Device
(сетевое устройство)
Network Device
(сетевое устройство)
Network Device
(сетевое устройство)
Network Device
(сетевое устройство)
Рис. 2. Архитектура ONF SDN
RESTful API
Коммутатор OpenFlow
(сетевой элемент)
Коммутатор OpenFlow
(сетевой элемент)
Рис. 3. Архитектура Open SDN
Контроллер OpenFlow
Коммутатор OpenFlow
(сетевой элемент)
OpenFlow""]
OpenFlow
JZr
" ' f I OpenFlow]
Коммутатор OpenFlow
(сетевой элемент)
Коммутатор OpenFlow
(сетевой элемент)
Взаимодействие между уровнями реализуется через программные интерфейсы приложений (Application Program Interfaces API). Взаимодействие контрольного уровня с инфраструктурным осуществляется через открытые «южные» протоколы SBI (South Bound Interface), контрольного уровня с уровнем приложений -через открытые «северные» программные API интерфейсы NBI (North Bound Interface).
ВАРИАНТЫ РЕАЛИЗАЦИИ ПКС/SDN
Предложенная архитектура nKC/SDN-сетей обеспечивает определенную гибкость в подходах к реализации SDN-техноло-гии. На сегодняшний день существуют три базовых подхода:
• Open SDN;
• SDN via API;
• SDN via Overlay.
Open SDN реализуется на базе протокола OpenFlow, отсюда и первое слово в названии. Это так называемый академический подход к SDN. Архитектура подхода Open SDN представлена на рис. 3.
Основная концепция Open SDN - полное удаление плоскости контроля (control plane) с сетево-
го оборудования. Плоскость контроля переносится на центральный SDN-контроллер. Передача (forwarding) трафика на сетевом оборудовании осуществляется на основании правил таблиц потоков (flow table). Таблицы потоков загружаются с SDN-контроллера, а он, обладая полным знанием топологии сети и на основании заданных политик от SDN-приложе-ний, формирует таблицы потоков для каждого сетевого элемента. В свою очередь, сетевой элемент, согласно правилам в таблице потоков, осуществляет определенное действие над входящими фреймами/пакетами - пересылает их в определенный порт, сбрасывает и т. п.). Взаимодействие контроллера SDN с сетевыми элементами обеспечивается через «южный» интерфейс (South Bound Interface SBI) по стандартизированному открытому протоколу Openflow. Протокол OpenFlow представляет собой открытый стандарт, поддерживаемый организацией Open Networking Foundation (ONF) [3]. Сообщество ONF был организовано в 2011 г такими ведущими игроками телекоммуникационного рынка, как Deutsche Telekom, Google, Microsoft, Facebook,
Verizon и Yahoo. OpenFlow - это первый стандартизированный интерфейс взаимодействия между плоскостью контроля (control plane) и плоскостью передачи (forwarding plane) в SDN-архи-тектуре и, по сути, являет собой момент зарождения SDN. Над контроллером расположен уровень приложений. Взаимодействие приложений и SDN-кон-троллера осуществляется через «северные» интерфейсы (North Bound Interface) с использованием RESTful API, Java API. Наличие этих интерфейсов позволяет программировать контроллер извне, задавая политики движения трафика, или, иными словами, формировать логическую топологию сети.
Сетевое оборудование для работы в OpenSDN именуется OpenFlow-коммутаторами/марш-рутизаторами. На рынке представлено достаточно большое количество OpenFlow-коммутато-ров, как программных (таких, как Open vSwitch), так и аппаратных. Ведущие производители сетевого оборудования Network Equipment Manufacturers (NEM), такие как Cisco, HP, Juniper, Extreme и др., добавляют OpenFlow-агенты в свое традиционное оборудование, которое может работать в двух режимах: как традиционное сетевое устройство, так и в режиме OpenFlow. Рынок OpenFlow-кон-троллеров представлен широкой линейкой продуктов - как Open Source, так и коммерческих. Из Open Source-контроллеров можно назвать активно развивающиеся проекты OpenDayLight, ONOS и «академические» Floodlight, Nox/ Pox, Ruy, Beacon. Коммерческие решения представлены продукцией компаний NEC, IBM, HP, российские - Brain4Net и Runos от ЦПИКС.
Отличительной особенностью подхода OpenSDN на базе OpenFlow является возможность прямого доступа и изменения плоскости передачи (forwarding plane) на сетевых устройствах.
Контроллер
сетевой I протокол .(управления | устройствами API
Коммутатор (сетевой элемент)
Коммутатор (сетевой элемент)
Коммутатор (сетевой элемент)
протокол J управления устройствами API
Рис. 4. Архитектура SDN via API
Коммутатор (сетевой элемент)
SDN via API. Архитектура подхода SDN via API представлена на рис. 4.
Основное отличие SDN via API от Open SDN заключается в сохранении плоскости контроля (control plane) на сетевых элементах. В данном подходе сетевой элемент - это классический маршрутизатор/коммутатор, в котором присутствуют и уровень контроля, и уровень передачи. «Программирование» сетевой топологии реализуется не через прямое влияние на forwarding plane, как в Open SDN, а либо (первый способ) через управление конфигурацией оборудования, так называемый подход Management plane, либо (второй способ) через влияние на таблицы маршрутизации/ коммутации сетевого элемента -подход Control plane. SDN-кон-троллер взаимодействует с сетевым элементом либо через существующие протоколы (CLI, SNMP, PCEP и т. д.), либо через новые или усовершенствованные протоколы (Netconf/Yang, I2RS). Концепция программируемости контроллера через приложения через «северные» интерфейсы в данном подходе сохраняется.
В качестве примеров можно привести решения MPLS-TE и решения SR, дополненные открытыми протоколами PCEP (Path Computation Element Protocol), BGP-LS (BGP Link State) для взаимодействия между распределенными плоскостями контроля (на маршрутизаторах) и централизованной плоскостью управления (на SDN-контроллере), - подход Control plane, а также протоколом Netconf и языком моделирования данных YANG для взаимодействия между распределенной плоскостью управления (на маршрутизаторах) и централизованной плоскостью управления - подход Management plane.
Одним из показательных примеров реализации данного подхода является SDN-контролер Opendaylight. Opendaylight - это открытый проект, созданный
консорциумом ведущих игроков телекоммуникационного рынка (Cisco, Juniper, Ericson, Microsoft, VMware, NEC и т. д.) [4].
Основное преимущество данного подхода - использование существующего оборудования и возможность реализации концепции SDN на существующих традиционных сетях. К минусам данного подхода можно отнести отсутствие абстракции - необходимость «думать» о каждом элементе сети, а также необходимость синхронизации между плоскостью контроля (control plane) контроллера и распределенными плоскостями контроля каждого сетевого элемента. Подход SDN via API - это попытка защиты сферы своего влияния крупными производителями сетевого оборудования от посягательств радикальных новых технологий. Но это шаг в правильном направлении, движение к централизации и программному конфигурированию сети. Данное решение многими рассматривается как эволюционный переходный процесс от традиционных сетей к OpenSDN.
SDN via Overlay - это одно из самых часто реализуемых решений на базе SDN. Решение SDN
via Overlays, если более точно -SDN via hypervisor-based Overlays, нашло свое применение в дата-центрах, использующих на своей серверной инфраструктуре технологии виртуализации (Virtual Machine VM). Архитектура подхода SDN via Overlay представлена на рис. 5.
Суть подхода заключается в следующем: физическая underlay-сеть реализуется на базе классических коммутаторов/маршрутизаторов, поверх физической сети строятся overlay-сети. Физическая сеть обеспечивает только L2/L3 (модель OSI) связность между гипервизорами (физическими серверами). В качестве аналогии overlay- и underlay-сетей можно привести пример работы Ipsec-туннелей поверх WAN-сети. IPSec-туннели - это виртуальная overlay-сеть, наложенная на физическую underlay WAN-сеть.
Overlay-сеть представляет собой виртуальную топологию из виртуальных же коммутаторов/ маршрутизаторов, соединенных между собой виртуальными каналами «точка-точка» (туннелями). В качестве туннельного механизма в основном используется MAC-in-IP-туннелирование.
Рис. 5. Архитектура SDN via Overlay
В частности, в своих реализациях SDN via Overlays компания Cisco использует VXLAN, Microsoft - NVGRE, Nicira's - STT, Juniper - реализует туннели через MPLSoverGRE. Множественные оверлейные сети могут существовать независимо друг от друга и одновременно работать на одной физической сети (multitenancy).
В качестве виртуальных коммутаторов/маршрутизаторов используются такие решения, как Open vSwitch, vRouter и т. п. Виртуальные коммутаторы/маршрутизаторы именуются virtual tunnel endpoint (VTEP). «Южный» интерфейс (South Bound Interface SBI) взаимодействия между контроллером и виртуальными коммутаторами может быть реализован на таких протоколах, как:
• OpenFlow;
• Extensible Messaging and Presence Protocol (XMPP);
• проприетарные протоколы, к примеру OpenFlex от Cisco.
Подход SDN over Overlay позволяет быстро, динамично, по запросусоздавать произвольные overlay-топологии без внесения изменений в сетевое оборудование. При этом наложенные сети полностью прозрачны для сетевого оборудования. К недостаткам данного подхода относятся существование underlay-сети
SDN Контроллер
вне управления контроллером, по-прежнему ручное конфигурирование, неэффективное использование физической инфраструктуры.
ОБЛАСТИ ПРИМЕНЕНИЯ ТЕХНОЛОГИИ ПКС/SDN И ЭФФЕКТЫ ОТ ВНЕДРЕНИЯ
• Технология SDN находит применение во всех типах сетей передачи данных от уровня предприятий до сетей сервис-провайдеров Л ВС/WiFi/ЦОД/WAN/SP. Архитектуры сетей идентичны, ввиду этого схожи и проблемы:
• большое количество сетевых устройств;
• сложные топологии и схемы коммутации/маршрутизации;
• сложный инжиниринг трафика и балансировки нагрузки;
•многочисленные наборы политик безопасности;
• сложность мониторинга и оптимизации потоков;
• сложность эксплуатации и управления сетью;
•ручная настройка сетевых устройств.
Какие насущные задачи решает SDN в сетях уровня предприятий? В центрах обработки данных (ЦОД) - это автоматизация и гибкость сети, сеть в автоматическом режиме «подстраивается» под используемые приложения. В ЛВС/LAN -
централизованное управление сетевой безопасностью (ACL, Black list), мобильность пользователей, работа коммутатора доступа с функциональностью межсетевого экрана. В распределенных сетях передач данных РСПД/WAN - это решение проблем с утилизацией каналов и автоматизация инжиниринга трафика.
В качестве основных эффектов от внедрения технологии SDN в сетях передачи данных можно перечислить:
•автоматизированное управление сетью. Упрощение эксплуатации;
•автоматизированное внедрение нового сетевого сервиса и быстрота развертывания;
• программируемость. Возможность внедрения новой идеи в сети (сетевого сервиса);
• независимость от производителя. Использование открытых стандартов;
• гибкая модернизация и масштабирование;
• гибкость сети. Эффективное использование аппаратных и канальных ресурсов.
ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ
Технологии SDN уверенно внедряются в сети передачи данных. Крупные игроки телекоммуникационного рынка и активные участники SDN-сообществ, такие как Google, NTT communication, Deutsche Telecom, Facebook, Microsoft, Verizon и многие другие реализуют SDN-решения. По данным из открытых источников, более 1000 крупных площадок ЦОД мира уже работают на SDN-решениях. Приведем несколько примеров реализации и решений технологий SDN.
Inter-DC WAN. Одним из ярких примеров реализации технологии SDN является компания Google. Ее сеть под названием B4 объединяет центры обработки данных ЦОД (DC) по всему миру [5]. Архитектура сети B4 Google представлена на рис. 6.
Overlay network Виртуальная сеть
'тизатор)
Физический сервер
Underlay network Физическая сеть
Рис. 6. Архитектура сети Google B4
Данный подход имеет общее название Inter-DC WAN. Основная проблема, стоящая перед производителями, заключалась в неэффективной утилизации множества трансконнинтальных WAN-каналов при передаче трафика между площадками ЦОД. Архитектура классических сетей не имела возможности решить данную проблему. Реализовав Inter-DC WAN на SDN OpenFlow, компании добились 95%-й утилизации каналов (до внедрения технологии утилизация в среднем была 70 %), также решение обеспечило гибкий инжиниринг трафика в зависимости от типа приложения. Компания реализовала решение на Open SDN-под-ходе. OpenFlow SDN-контроллер в реальном времени собирает показатели утилизации сети (global network view) и требования к пропускной способности от приложений/услуг. Из полученных данных вычисляется оптимальный путь для потоков трафика, затем этот путь программируется в коммутаторы OpenFlow. В случае изменения требований к полосе или изменения сети сервис повторно вычисляет путь и перепрограммирует коммутаторы.
SDN В СЕТЯХ ОПЕРАТОРОВ СВЯЗИ
Проект TeraStream оператора связи Deutsche Telekom предусматривает строительство новой операторской сети на территории Балканских стран на базе техно-
логии SDN. Сеть SDN строится с использованием протоколов OpenFlow и Netconf на базе те-рабитных маршрутизаторов с интеграцией оптической передачи DWDM [6].
SDN VIA API ДЛЯ СЕТЕЙ MPLS TE С ИСПОЛЬЗОВАНИЕМ ПРОТОКОЛА PCEP
Для автоматизации инжиниринга трафика в MPLS-сетях успешно применяется подход SDN via API,
в частности пример stateful PCE для MPLS TE.
Вместо трудоемкого ручного конфигурирования настройки MPLS TE-туннелей, причем для выполнения некоторых задач «человеческий интерфейс» вообще не может быть применен, используется SDN-контроллер. SDN-кон-троллер в реальном времени собирает топологию сети, загрузку каналов,анализирует потребности трафика/приложений и на основании полученных данных вычисляет оптимальные пути прохождения трафика и автоматически инсталлирует их в маршрутизаторы c использованием протокола PCEP. Таким образом реализован так называемый Control plane-подход в SDN via API.
Данное решение дает возможность реализовать следующие сетевые сервисы:
•автоматизацию создания MPLS TE-туннелей;
• автоматизацию балансировки нагрузки;
Рис. 7. Проект TeraStream
Рис. 8. SDN для сетей MPLS TE
• создание непересекающихся туннелей;
• полосу по требованию, полосу по расписанию.
В качестве примера можно привести коммерческий продукт NorthStar Controller компании Juniper.
КОНТРОЛЛЕР SD-WAN
Необходимость управления трафиком (Traffic Engineering) и централизованного управления в распределенных корпоративных сетях через Интернет или операторов связи SP привела к появлению коммерческих решений под общим названием SD-WAN.
Решение основано на подходе SDN-Overlay путем создания виртуальной топологии - туннелей. SD-WAN-контроллер создает наложенную виртуальную топологию overlay (IP/IPSec-туннели). SD-WAN-контроллер обеспечивает централизованное управление, контролирует ее состояние (jitter, delay, drop), обеспечивает распределение потоков трафика на основе определяемых политик и состояния виртуальной сети. Достигается некая условная про-граммируемость наложенной сети и централизованное управление. Как правило, данные решения коммерческие, проприетарные и закрытые.
ЛАБОРАТОРИЯ OPEN SDN
Еще один пример использования продуктов Open Source - это
возможность создания собственной виртуальной сетевой лаборатории (стенда) SDN. Причем для того, чтобы запустить лабораторию, понадобится только стандартный персональный компьютер. Такую возможность дает бесплатная Open Source-про-грамма Mininet [7], создающая виртуальную сетевую топологию пользовательских виртуальных OpenFlow-коммутаторов и виртуальных хостов, управляемых через SDN-контроллер. При этом контроллер можно «запустить» как на платформе Mininet на той же виртуальной машине, так и использовать внешний компьютер.
Таким образом, мы получаем полноценную SDN-сеть с возможностью на практике использовать опыт работы с технологией SDN, запустить и протестировать различные варианты SDN-контрол-леров, создать и протестировать свои приложения для решения задач. Приобретенный опыт
позволяет самостоятельно развернуть полноценную SDN-сеть на аппаратных коммутаторах Open Flow.
ТЕКУЩЕЕ СОСТОЯНИЕ РЫНКА
Появление технологий программно конфигурируемых сетей (SDN) и виртуализации сетевых функций - NFV (Network Functions Virtualization) вызвало волну реструктуризации бизнеса «устоявшихся» производителей. В настоящее время на рынке происходят поглощения и объявляются партнерства для конкурентной борьбы, вкладываются большие инвестиции в изыскательские работы, появляются новые сильные игроки. Начал формироваться рынок SDN-приложений для одноименных сетей. Предложения для контроллеров SDN можно разделить на три направления:
• на базе OpenFlow - как Open Source-продукты, так и коммерческие;
Overlay туннели
SD-WAN контроллер
Рис. 9. Сеть SD-WAN
Кроссплатформенное программное обеспечение - VM (Oracle Virtual Box)
Virtual Host
(Виртуальный хост)
Open Source OpenFlow контроллер POX/Floodlight/OVS C/OpenDaylight/... (SDN-контроллер)
Virtual Host
(Виртуальный хост)
Open vS witch (коммутатор)
Рис. 10. Стенд SDN
Open vS witch (коммутатор)
Open vS witch (коммутатор)
Virtual Host
(Виртуальный хост)
PC (Windows/...)
(внешний компьютер)
• на базе кода OpenDayLight. Проект Linux foundation;
• проприетарные закрытые решения собственных разработок.
Крупный бизнес, участники сообществ SDN (ONF, ODL), ведущие операторы связи активно внедряют и уже используют технологию SDN в своих сетях передачи данных.
Компания Google разработала собственные коммутаторы на базе OpenFlow, реализовала ранее упомянутый InterDC SDN проект B4. Компания Facebook ведет разработки собственных коммутаторов, переводит свои ЦОД на
решения SDN. Японский оператор связи NTT перевел всю свою сетевую инфраструктуру на SDN в 2013 г. Оператор связи AT&T в 2015 г. объявил SDN своим основным стратегическим направлением развития и переориентации на разработку ПО. В нашей стране направление SDN/NFV выделено Правительством РФ как одно из перспективных, ведущие игроки российского телеком-рынка -«Ростелеком», «Билайн», МТС и многие другие - активно тестируют решения для развертывания сетей SDN, принимая деятельное участие в разработках.
ЗАКЛЮЧЕНИЕ
SDN-технология находится еще на раннем этапе своего развития. Очевидно, что на последующих этапах внедрения SDN полностью раскроется его потенциал. SDN кардинально изменит подход к проектированию,развертыванию и управлению сетями. Изменится подход к доставке приложений и сервисов, существенно перекроется сетевой рынок. Масштаб кардинальных изменений в телекоммуникациях можно сравнить на примере качественного перехода от аналоговой телефонной связи к IP-телефонии. ■
ЛИТЕРАТУРА
1. Martin Casado, Teemu Koponeny, Daekyeong Moonz, Scott Shenker. Rethinking Packet Forwarding Hardware.
2. Software-Defined Networking (SDN) Definition. - [Электронный ресурс.] - Режим доступа: www.opennetworking.org/sdn-resources/sdn-definition
3. OpenFlow. - [Электронный ресурс.] - Режим доступа: https://www.opennetworking.org/sdn-resources/openflow
4. Opendaylight. - [Электронный ресурс.] - Режим доступа: www.opendaylight.org
5. Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong и др. B4: Experience with a Globally-Deployed Software Defined WAN. - [Электронный ресурс.] - Режим доступа: https://people.eecs.berkeley.edu/~sylvia/cs268-2014/papers/b4-sigcomm13.pdf
6. TeraStream. - [Электронный ресурс.] - Режим доступа: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf
7. Mininet. - [Электронный ресурс.] - Режим доступа: http://mininet.org
REFERENCES
1. Martin Casado, Teemu Koponeny, Daekyeong Moonz, Scott Shenker. Rethinking Packet Forwarding Hardware.
2. Software-Defined Networking (SDN) Definition. - [Electronic Source.] - See at: www.opennetworking.org/sdn-resources/sdn-definition
3. OpenFlow. - [Electronic Source.] - See at: https://www.opennetworking.org/sdn-resources/openflow
4. Opendaylight. - [Electronic Source.] - See at: www.opendaylight.org
5. Sushant Jain, Alok Kumar, Subhasree Mandal, Joon On, et al. B4: Experience with a Globally-Deployed Software Defined WAN. - [Electronic Source.] - See at: https://people.eecs.berkeley.edu/~sylvia/cs268-2014/papers/b4-sigcomm13.pdf
6. TeraStream. - [Electronic Source.] - See at: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf
7. Mininet. - [Electronic Source.] - See at: http://mininet.org
