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

Исторический экскурс


image

Развитие технологий сетей передачи с 1969 года (ARPANET) было направлено на то, чтобы каждый аппаратный компонент был независим от других компонентов. Протоколы взаимодействия работали по принципу обмена контрольной информацией, которая использовалась алгоритмами для анализа топологии и построении моделей взаимодействия между устройствами.

image

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

image

Все разработанные протоколы динамической маршрутизации (RIP, OSPF, IGRP, BGP) и протокол ветвящегося дерева (STP) были построены на этом принципе – устройства как равноправные обмениваются имеющейся информацией о своих соединения с соседями и самоорганизуются в общую топологию, которая работает как единая сеть.

image image

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

image?

Другой проблемой стал тот факт, что сетевые функции (Firewall, Load Balancing, Mirroring), которые реализовывались в определенном физическом месте сети передачи данных могли находится далеко в топологии от того места, где трафик генерировался. Так как трафик должен был быть доставлен до аппаратного устройства и только там быть, например, отфильтрованным, то это приводило к большей утилизации и снижению эффективности, чем если бы трафик был отфильтрован в месте генерации трафика.

SDN


image

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

image

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

NFV


image

Другое преимущество в том, что, обладая информацией о том, какие политики должны быть применены к различным типам трафика в различных точках входа трафика в сеть, есть возможность применить сетевую функцию непосредственно в этой точке сети. Если представить, что сотни сетевых функций можно отделить от аппаратной платформы и реализовать в виде программы, в которую в качестве входных данных поступает управляющая информация (какие политики необходимо применить к трафику) и задать входящий и исходящий интерфейс для трафика, то тогда эту сетевую функцию можно запускать на стандартных операционных системах на x86-серверах. Запуская эти программы в точках генерации либо обмена трафиком, центральный контроллер может программировать коммутаторы для передачи необходимого типа трафика внутрь сетевой функции. Трафик, после обработки сетевой функцией, возвращается в плоскость передачи данных и передается до конечного получателя.

image

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

image

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

image

Сетевые функции сжатия трафика в режиме реального времени (Real-Time Compression, WAN Optimization), перенаправления запросов на ближайшие точки (CDN), балансировки нагрузки между фермой серверов (Load Balancing) требуется развернуть в автоматическом режиме и в нужном масштабе и предоставить к определенному виду трафика. Определить данный тип трафика, запустить виртуальные машины с требуемой функцией и перенаправить в них трафик помогают системы MANO с функциями auto-provisioning, auto-scaling, автоматической настройкой перенаправления трафика.

MANO


image

Оркестраторы (management and operation) данного процесса должны обладать целым набором способностей:

1) Управлять физической инфраструктурой: сетями передачи, хранилищами данных, серверами;
2) Используя платформы виртуализации создавать на основе физической инфраструктуры необходимые инстансы: виртуальные машины, виртуальные LUN, виртуальные сети;
3) Принимать телеметрию от текущих сетевых устройств для проведения анализа и принятия решения о предоставлении дополнительных сетевых функций;
4) Запустить из шаблонов требуемые сетевые функции и загрузить в них конфигурацию, соответствующую требуемой задаче;
5) Анализировать состояние запущенных сетевых функций для принятия оперативных решений в случае отказов, аварий либо перегрузок;
6) Ликвидировать запущенные сетевые функции в случае, когда необходимости в их работе больше нет и делать это на основе автоматических данным из телеметрии либо по запросу администратора;
7) Передать в бизнес ИТ-системы информацию об используемых ресурсах для проведения расчетов биллинга.

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

Enterprise CPE virtualization


image

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

Еще одной возможностью для повышения прибыли для сервис-провайдеров является модель перехода к умным оконечным точкам (CPE). Переход от цифровых модемов к управляемым роутерам позволяет достичь нескольких целей. В данный момент для подключения удаленного филиала заказчика услуг сервис-провайдера требуется устройство подключающее локальную сеть филиала к сети оператора в нужную выделенную сеть, организованную либо посредством технологии MPLS либо в случае legacy провайдеров посредством технологии ATM. В таком случае необходимость совершать различные операции с трафиком заказчика (предоставлять дополнительные сетевые функции) приводила к необходимости доставлять этот трафик от клиента до ядра сети оператора, в котором располагаются устройства, реализующие такую сетевую функцию, и уже на ядре сети обрабатывать трафик по заданным политикам. Это приводило к повышенной утилизации «последней мили» и магистрали оператора тем трафиком, который можно было бы обработать ближе к источнику генерации. С другой стороны устройства оконечных точек являлись всего лишь либо аналогово-цифровыми преобразователями либо достаточно простыми IP-устройствами, без возможности проактивного мониторинга или удаленной настройки.

image

Замена таких устройств на CPE нового поколения позволит решить несколько задач. Дистанционное управление новыми CPE позволит производить zero-touch provisioning с помощью двухфакторного метода, используя активирующие URL. Таким образом, можно будет напрямую с завода-производителя отправлять устройства конечным клиентам, и уже на месте активировать их с нужной конфигурацией, в том числе неквалифицированным персоналом. Помимо этого, реализация на CPE с помощью слоя виртуализации контейнеров или виртуальных машин с нетребовательными к аппаратной платформе сетевыми функциями, позволяющими непосредственно на оконечной точке предоставлять услуги с добавленной стоимостью, даст возможностью клиентам в магазине приложений активировать для своей точки подключения тот функционал, который им требуется: антивирусная защита, фильтрация спама, родительский контроль и так далее. Оператор, взимая дополнительную плату за эти функции, получит широкую возможность наращивать выручку за счет быстрого и бесшовного внедрения новых SDN-приложений.

Для корпоративных заказчиков оперативное развертывание новых офисов в точках присутствия Интернета станет реальностью – не потребуется перенастраивать множество IPSec VPN туннелей на новую адресацию, в том случае если CPE будет автоматически строить наложенные туннели посредством технологий VXLAN или MPLSoGRE между множеством CPE и центральным центром обработки данных. Централизованное управление удаленными офисами позволит оперативно менять программное обеспечение на CPE и централизованно хранить конфигурационные данные. Средства информационной безопасности можно будет активировать из единой консоли управления сразу для всей организации. Администратор информационной безопасности по достоинству оценит отсутствие возможности сотрудников в филиале иметь доступ к консоли роутера, потому как политики могут быть настроены только на SDN-контроллере либо оркестраторе.

Выводы


image

Используя упомянутые тренды – переход на централизованный control plane, замена специализированных устройств с сетевыми функциями на x86-сервера с программными NF, создание системы управления виртуальными ресурсами с передачей управляющих сигналов в различные компоненты системы OSS\BSS, а также автоматизация и виртуализация устройств оконечных подключений приведет к повышению скорости вывода услуг на рынок, создаст экосистему для предоставления сервисов с высокой добавленной стоимостью и повысит привлекательность провайдера для конечных клиентов.
Поделиться с друзьями
-->

Комментарии (14)


  1. ayurtaykin
    08.08.2016 16:55

    С добрым утром, концепцию vCPE похоронили в прошлом году (насколько я знаю — все вендоры).

    На замену предложили SD-WAN.

    Особо умные выпендрились и родили свое, uCPE от Juniper и CloudVPN от Cisco.


    1. wider
      08.08.2016 17:31

      Добрый день, ayurtaykin.

      Насколько я вижу, эти термины располагаются по разную сторону одной концепции. vCPE — это оборудование с виртуализированными сетевыми фукнциями, а SD-WAN — подход, при котором эти vCPE удаленно управляются, обновляются и с помощью которых загружают на них дополнительные SDN-Application из «магазина приложений».
      Так что скорей всего были не «похороны», а интеграция коробок в единую концепцию.


    1. Vramin
      09.08.2016 01:07

      В сети провайдера SD-WAN может позиционироваться как технология обслуживающая ядро сети, прозрачная для пользовательских услуг, т.е. vCPE скорее дополняет SD-WAN чем конкурирует с ним. Что касается популярности vCPE — такие решения сейчас достаточно активно предлагаются на рынке основными поставщиками (Cisco, Huawei, Alcatel/Nokia, Ericsson, HP, etc). У HP есть неплохое обзорное исследование результатов различных PoC по состоянию на Q1 2016 где vCPE занимает не последнее место. Беглый поиск по другим поставщикам подтверждает тезу про актуальность концепции vCPE — достаточно много свежих отчетов о PoC в 2015 году. vCPE сценарии также тестировались на SDNFV Fest под эгидой ONF в Пекине этой весной.
      Действительно интересная и слабо разработанная тема — стандартизация интерфейсов между SND/NFV решениями и традиционными OSS/BSS.


      1. wider
        09.08.2016 13:13

        Действительно, решениями vCPE сейчас как будто бы занимаются все ведущие сетевые вендоры. Лично я начал тестирование продуктов в данной категории с решения Nuage VNS еще пару лет назад. Но со временем обнаружил похожие продукты от Juniper, Cisco, Huawei, HP и других. На презентациях каждый из этих технологических лидеров заверял сервис-операторов, что хватит быть уже экономикой «трубы» и пора переходить на следующий уровень в over-the-top решениях, потому что если не они возглавят этот процесс, то за них это сделает кто-то другой и в таком случае инфраструктурные-провайдеры перейдут на уровень экономики поставщиков электричества. Очевидно, что сейчас идет нешуточная борьба между конкурентами за скорейшую реализацию всего необходимого функционала в этих решениях и вывода на рынок законченного и стабильного решения. На мой взгляд полноценно этим похвастаться не может пока ни один вендор.
        И как правильно заметил Vramin, гораздо больший вызов лежит в плоскости управления всей этой software-defined инфраструктуры. Каким образом можно обеспечить отказоустойчивую, гео-распределенную, событие-ориентированную, управляемую приложениями систему Оркестрации и Управления (orchestration + MANO)? Для это требуется не только описать текущую физическую и виртуальную инфраструктуру в виде моделей на синтаксисе YANG, Ansible, OpenConfig, чтобы влиять на оперативное развертывание новых сервисов, но так же научится принимать от этих элементов управляющие сигналы для реагирования на события.
        Видно, что коллеги из ETSI проделали гигантскую работу в этом направлении для того, чтобы создать абстрактные модели взаимодействия указанных компонентов, но теперь необходимо целой армии разработчиков и продакт-менеджеров воплотить эти абстракции в код.


  1. Tsvetik
    09.08.2016 14:46

    Думаю, что повсеместное внедрение подобных технологий окончательно разрушит сетевой нейтралитет и мы получим все те «прелести», которые встречаются в сотовых сетях.
    Трафик на одни IP будет платным, на другие — бесплатным. Появится роуминг и всякие опции. За TCP трафик будет цена как за холодную воду, за UDP — как за горячую.


  1. DenisMakogon
    09.08.2016 14:51

    Тут вопрос не в том что похоронили vCPE и придумали uCPE или SDN-WAN. А в том, что никто не знает как применять и как использовать NFV в продакшн системах. Большая проблема в том, что софтварные решение сетевых компонентов не дают должной производительности, потому что general-purpose процессоры не справляются с задачами процессоров сетевых устройств.

    Из личного опыта, чаще всего Telco вендоры пытаются определить как же правильно развернуть окружение, если конкретней — OpenStack, так что бы он работал эффективно для нужд NFV, некоторые смотрят в сторону Docker-based NFV решений и все, далее идет анализ телеметрии с каждой NFV путем пинга или перегонки траффика в рамках двух подсетей одного клауда.

    Так же, не стоит забывать, что такое оркестрация NFV. Звучит все круто и ново, прям как Internet of Things, но (!!) это всего лишь конфигурация софта поверх виртуальных машин (и тут у вас сразу должны забегать глаза из-за обилия способов установки и конфигурации софта в современном IT).

    Самым интересным тут является средство оркестрации NFV, который подразумевается в указанном выше MANO, а так же проектах Open-O или Linux OPNFVTOSCA data modeling language.

    Так вот, на данный момент есть только очень маленький сегмент коробочных решений, которые предоставляет возможность оркестрации NFV. Среди указанных проектов (MANO, Linux OPNFV, Open-O) нет ни одного проекта, у которого есть готовое решение, вообще. Но если откинуть NFV и подумать о виртуалках и конфигурации софта, то сразу на ум придет несколько решений, которые могут делать оркестрацию используя TOSCA в качестве языка описания моделей:



    AIOrchestra это Py3.5 либа для построения микросервисов вокруг.
    Имея возможность оркестрировать ресурсы облака остается вопрос упомянутый мною выше — как же наконфигурить OpenStack, так чтобы работал «круто для NFV».

    Вот и весь NFV. Как говорится, стильно, модно, молодежно.


    1. At0mik
      09.08.2016 20:20
      +1

      Долгое время не понимал суть SDN и NFV.

      Вроде и с сетями на «ты»… и с виртуализацией… и программировать вроде как получается. Но никак не понимал как эти абстрактные понятие (SDN/NFV) реализуются в реальном, приземленном, мире.

      В один день решился, и попробовал все это дело в действии. Надеюсь что я не один такой и кому-то будет интересно читать далее: для сисадминов кто хорошо знаком с (старыми) сетевыми технологиями, но не в теме SDN+NFV. Смотрел я на openflow с SDN контроллером ONOS. А также на OPNFV.

      Начнем с SDN.
      1) упрощаем маршрутизаторы до безобразия. Они становятся совсем «тупыми». Единственное что они понимают, это команды типа: «все пакеты с dst ip 10.0.0.1 которые вошли через порт eth0, отправить в порт eth1 попутно изменив 'dst mac' на аа: аа: аа: аа: аа: аа». На этих же маршрутизаторах крутиться маленькая программа которая подключается по TCP к контролеру. Контроллер по этому соединению отправляет команды-правила на добавления/удаления/изменения. Получив новые правила, они «скомпилированны» в ASIC(Application-specific integrated circuit) и далее весь процессинг делаеться на уровне hardware.
      Например, когда новый пакет получен, маршрутизатор ищет правило которое подходит в списке правил. Если находит, правило исполняется. Если нет, пакет можно отправить контролеру по TCP соединению. Он проанализирует пакет и (возможно) отправит новое правило на добавление.
      2) контроллер это просто громадная программа. Например ONOS/Opendaylight написаны на ява. Его задача, воссоздать граф сети в памяти. Наверное многие уже писали алгоритмы для графов в универе. Вот и контроллер крутит всякие алгоритмы чтоб найти кратчайший/лучший путь в сеть. А потом поочередно добавит нужные правила во все маршрутизаторы по пути. Никакой магии :) Вся красота в том что можно добавить какие угодно алгоритмы самому и не надо ждать что CISCO добавит их в IOS.

      Маршрутизаторы также собирают всякую статистику о сети. Например, о своих соседях-маршрутизаторах (используя протокол LLDP). А также, об загруженности соединений. Эти данные они отправляют контроллеру по тому-же TCP соединению. Именно эта информация позволяет воссоздать сеть в память контролера и понять что «интерфейс eth0 у switch2 загружен, надо бы какой-то трафик перевести в обход».

      В случае NFV, все вроде еще проще:
      Вместо того чтоб крутить DHCP/ DNS/ ..../Firewall/..../[new network function] в роутерах, используем магию (в смысле, виртуальную машину/контейнер): на одной запускаем DHCP сервер, на второй BIND, на третей настроим iptables… и так далее. А можно еще купить магическую программу от [крутой организации] и поставить в 4-ую вм. После этого, добавим по правилу через СДН чтоб трафик распределялся по правильным вм.

      Как это сделать? В этом то и вся проблема, а SDN и NFV пока что взлетают, взлетают, да не взлетят. Плохо это? хорошо?: не мне решать.
      Например, OPNFV это ОГРОМНЫЙ монстр. Первое что надо сделать для его установки, это поднять Openstack кластер. Потом, в этом кластере поднимется пара виртуальных машин в которые устанавливается SDN контроллер с «high availability», blackjackom и шл…
      Напомним, SDN контроллер это еще один монстр на пару сотен тысяч линий кода (если не миллионов).

      На данный момент я ужасно боюсь что «это» взлетит и мне придется администрировать его, честно боюсь

      Я ведь только-только привык к DevOps, а тут DevOps в 5-ой степени


      1. satandyh
        09.08.2016 23:12

        Вероятно нам придется узреть картину, когда нашим работадателям в погоне за настоящим/будущем придется нанимать еще парочку другую админов. Потому что вы заметили правильно появилась размытая прослоечка в виде облака, которую надо поддерживать: железо -> OpenStack -> vm со своим внутренним миром.


  1. Am6er
    09.08.2016 15:00

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


    1. DenisMakogon
      09.08.2016 15:13

      Увы, да. Как я описал в своем комментарии — есть 3 организации, которые почти что игнорирует друг друга. А те, кто написал естандарт ETSI MANO игнорируются ввиду изначально неправильно политики унифицирования реализации стандарта (мол, всё, мы написали стандарт — повинуйтесь).


      1. wider
        09.08.2016 18:55

        Не уверен, что технологические вендоры-лидеры будут игнорировать стандарт ETSI MANO. Чтобы это понять достаточно посмотреть на список компаний, в которых работают авторы этого стандарта:
        NEC, Tech Mahindra, Orange, Cisco, Amdocs, Wind River Systems, Alcatel-Lucent, HP, Oracle, Orange, Juniper, ZTE, Intel, Telecom Italia, Wipro, EnterpriseWeb, NSN, Huawei, ASSIA, Telefonica, China Unicom, AT&T, Verizon, Docomo, Deutsche Telekom, Sprint, Vodafone, 6Wind, BT, tech Mahindra, Sonus, Brocade, ETRI, Ooredoo, Fujitsu, Ericsson.


    1. wider
      09.08.2016 18:45

      А долго это один год или пять лет? :)
      Мне видится, что сейчас такое время, когда в ближайшее время могут выстрелить сразу несколько вендоров со своими решениями по «магазину VNF приложений». Cisco аналог показывала где-то год назад в рамках функционала APIC-контроллера. NEC со своим SDN space призывает производителей VNF к сотрудничеству. HP недавно анонсировал открытие SDN app store.
      Возможно прорыва стоит ожидать не сколько от сетевых вендоров, сколько от производителей OSS\BSS систем, в которые сейчас активно интегрируют MANO-компоненты.


      1. Am6er
        09.08.2016 23:44

        Вендоры обязательно пальнут (куда же им деваться), только в разные стороны.
        Можно ли приложить линк на Cisco аналог VNF магазина (если это вдруг не NSO)? Признаться, не слышал о его существовании.
        Согласен, что много работы ложиться на плечи участников процесса REL, ибо здесь мы имеем телекомовскую хотелку, завернутую в ИТ-шное решение. Но я не уверен, что их действия определят направление, так как не их экспертиза является основополагающий.


        1. wider
          10.08.2016 12:01

          На семинаре по Cisco ACI демонстрировали возможности контроллера APIC, в который можно загрузить Device Package — подготовленный образ ВМ от других вендоров для реализации конкретной сетевой функции, в которые по заданному API-интерфейсу передается конфигурация во время применения этого device package к сервисному графу для реализации network function.
          Демонстрация показала как в автоматическом режиме можно сетевые функции применять к трафику. Настраивать в консоле каждую ВМ с сетевой функции не было необходимости.