В конце прошлого года был опубликован отчет агентства RaynoReport, посвященный рынку решений Lifecycle Service Orchestration (LSO). Мы решили подробнее рассказать о том, что представляет из себя концепция LSO в видении консорциума MEF и как она может повлиять на развитие систем OSS/BSS.

В этой статье:

— Что такое Lifecycle Service Orchestration в подходе MEF? Предпосылки появления концепции;

— Взгляд зарубежных операторов связи и консорциума MEF на LSO;

— Общие требования к LSO системам;

— Взаимосвязь MEF LSO с архитектурами SDN и NFV.

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

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

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

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

Целью архитектурных подходов SDN и NFV является изменить текущее положение дел – создать гибкую архитектуру сети, которая будет построена на открытых системах, которые могут взаимодействовать друг с другом, вне зависимости от производителя. Это также влияет и на развитие систем OSS/BSS.

По данным того же отчета, проведенного среди 75 крупных сервис-провайдеров, операторы готовы к серьезным изменениям в области OSS/BSS. Более половины опрошенных считают, что их системы устарели и недостаточно гибки.

Ответом на подобные потребности стала концепция Lifecycle Service Orchestration (LSO). LSO – программный уровень управления жизненным циклом сервисов, тесно интегрированный с архитектурами SDN и NFV, целью которого является автоматизация подключения, управления и контроля качества сервисов. Концепция предполагает, что пользователь сможет в любое время просмотреть статус своих услуг с помощью личного кабинета и «на лету» внести изменения или заказать новые услуги, вместо того, чтобы проходить весь длительный административный процесс.

LSO можно рассматривать как «соединительный элемент», который консолидирует существующие OSS/BSS системы, новые технологии (SDN, NFV и др.) и «устаревшую» часть инфраструктуры. LSO – это, своего рода, новая программная платформа, которая сможет обеспечить обработку клиентского заказа, выполнить подключение сервиса, а также отслеживать качество и выполнять мониторинг клиентских услуг. При этом, система является единой централизованной точкой управления всеми сервисами (см. рисунок ниже).

MEF-LSO-OSSBSS-transformation_snblog.ru

Однако, существующие операторские системы не смогут быть заменены в один момент. Это просто не представляется возможным! Поэтому LSO должна определенным образом интегрироваться с традиционными OSS/BSS оператора, которые зачастую являются проприетарными или «самописными» и не имеют необходимых API для интеграции с новыми открытыми платформами. Эта задача является одной из основных для MEF – консорциума, который предложил концепцию LSO и занимается её описанием.

Взгляд операторов на LSO

Прежде чем углубиться в конкретные кейсы применения и решения LSO, давайте сначала разберемся, зачем вообще нужны какие-то изменения? По данным отчета Rayno Report, операторы указывают на недостатки своих систем управления сетью и поддержки бизнеса. Часто они описываются как набор разрозненных систем, которые не могут взаимодействовать друг с другом или даже не знают, что происходит в других частях сети. Провайдеры говорят, что управление проприетарными системами, их интеграция с другими платформами и объединение различных частей инфраструктуры в единое целое – комплексная и дорогостоящая задача.

Но самая главная трудность заключается в следующем: если сервис-провайдер тратит недели или месяцы на реконфигурацию сети для запуска нового сервиса, он теряет деньги!

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

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

Лучшая аналогия – это то, как вы сегодня можете управлять своими мобильными услугами с помощью личного кабинета или СМС, без необходимости общения с представителем оператора. Именно такого же уровня взаимодействия провайдеры стремятся достичь в предоставлении B2B услуг.

В таблице ниже представлены основные проблемы, с которыми сталкиваются сервис-провайдеры при необходимости внедрения подобных услуг.

MEF-LSO-SP-challenges-survey-results_snblog.ru
Источник: MEF & Rayno Report  — Emerging Dynamic “Third Network” Services & Role of LSO (Q1 2015)

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

Почему же большинство сервис-провайдеров не может до сих пор это сделать? Корень проблемы заключается в OSS/BSS системах оператора и в том, как они построены. Эти системы – часть большой категории платформ оператора, называемых ИТ-системами. Они строились в течение многих лет, часто с привлечением различных не интегрированных между собой технологических платформ, а также собственных разработок, и «заточены» эти платформы под специфичные услуги.

Главный вопрос в том, верят ли операторы, что их OSS/BSS системы готовы к инновационным технологиям? Опрос показывает, что нет. Более 54% опрошенных называют свои системы «устаревшими», а 60% считают, что им не хватает возможностей для быстрого и эффективного запуска новых услуг.

Взгляд MEF «Third Network»

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

В сотрудничестве с другими организациями, занимающимися разработкой стандартов, в рамках программы UNITE, консорциум MEF (Metro Ethernet Forum) обозначил необходимые требования к LSO системам и поддерживаемым ими API для автоматизации жизненного цикла сервисов наиболее эффективным образом. Согласно MEF, LSO связывает все части инфраструктуры в единой точке управления, которая координирует действия при подключении услуги, осуществляет контроль качества, соответствия требованиям безопасности и SLA. На рисунке ниже приведена концептуальная модель MEF LSO.

MEF-LSO-Conceptual
Источник: Сайт MEF

По определению MEF, основные функции систем нового поколения включают:

  • Подключение услуги;
  • Управление;
  • Производительность;
  • Соответствие параметрам SLA и мониторинг;
  • Контроль использования сервиса;
  • Безопасность;
  • Аналитика;
  • Политики.

Разберем эти функции более подробно. Чтобы не сильно искажать информацию, мы приводим адаптированый перевод части документа The Third Network: Lifecycle Orchestration Vision (стр.7-8), описывающего эти функции.

Подключение услуги

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

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

Когда клиент заказывается услугу у провайдера, к ней привязываются так называемые SLS (Service Level Specification). SLS могут определять первоначальную конфигурацию услуги, динамические сервисные политики, пулы ресурсов, а также показатели производительности. Конфигурация услуги осуществляется на основе этих SLS в рамках как собственной инфраструктуры, так и потенциально возможного использования ресурсов оператора – партнера. С момента подключения услуги, пользователь может гибко управлять ей в рамках возможностей конкретной LSO системы.

Во время создания нового экземпляра сервиса, LSO должна предоставить средства для верификации сервисных компонент – поиск и согласование выделения ресурсов, топологии и прочих параметров сетевого подключения, связанных с услугой.

Управление

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

Пользователю также может предоставляться возможность управления полосой пропускания, связанной с определенными подключениями, на основе классов сервиса (CoS). В рамках управления окончеными точками (endpoints), клиент может добавить/удалить/переместить endpoint в другое место и мигрировать соответствующие компоненты услуги.

Производительность

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

LSO также должна включать аналитические средства для оценки запаса ресурсов, улучшения качества сервиса и traffic engineering.

Соответствие параметрам SLA и мониторинг

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

Контроль использования сервиса

LSO должна предоставлять возможность сбора информации об использовании сервиса – измерение трафика, изменения параметров услуги (например, временное изменения полосы пропускания). Система собирает и анализирует эту информацию, предоставляя оператору отчеты о превышении лимита использования ресурсов, заявленных в SLS.

Безопасность

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

Аналитика

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

Политики

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

Более подробно о функциях LSO можно ознакомиться на сайте MEF.

Новые стандарты и взаимосвязь MEF LSO с SDN/NFV

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

Стандартизация подобной архитектуры влечет за собой необходимость взаимодействия различных организаций по стандартизации и сообществ, включая открытые комьюнити, разрабатывающие протоколы взаимодействия в SDN и NFV. Среди этих организаций необходимо отметить MEF (Metro Ethernet Forum), ONF (Open Networking Foundation), ETSI, IETF, Open Daylight, OpenStack и TM Forum.

Группа ETSI NFV ISG взяла на себя роль разработки стандартов и описания архитектуры NFV. Представленная группой модель MANO (Management And Orchestration) на данный момент является рефернсной архитектурой реализации NFV, на которую ссылаются многие производители (хотя, фактически, ни один вендор не реализует модель в том виде, в котором она представлена в ETSI, прим. SDNBLOG).

В модели ETSI MANO определены три основные функции – NFV Orchestrator, VNF Manager и Virtualized Infrastructure Manager (VIM). Эти подсистемы должны взаимодействовать друг с другом посредством открытых программных интерфейсов (API). Однако, это всего лишь часть всей инфраструктуры.

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

MEF LSO является неким связующим звеном между двумя вышеописанными архитектурами (см. схему ниже).

MEF-LSO-vs.-MANO_sdnblog.ru

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

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

Компания Tail-f стала одной из первых, кто применил Netconf и YANG в качестве основы платформы для оркестрации мульти-вендорных сетей. Позднее компания была приобретена Cisco Systems.

Более подробно о YANG и Netconf читайте тут. Если вам интересна эта тема, напишите в комментариях, и мы постараемся глубже осветить её в будущих статьях.

Заключение

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

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

Подобная архитектура должна предоставить массу преимуществ как сервис-провайдерам, так и конечным пользователям. Операторы связи смогут быстро запускать новые гибкие услуги, при этом максимально автоматизировать процесс их внедрения. А клиенты получат возможность управлять заказанными сервисами и приобретать новые посредством WEB-портала, вместо прохождения длительных административных процедур взаимодействия с провайдером. Конечно, в России есть определенная специфика работы B2B, и административные моменты могут стать стоп-фактором для максимальной автоматизации процессов.

Пока что концепция Lifecycle Service Orchestration находится на ранних стадиях развития и, по прогнозам, более-менее зрелые решения появятся на рынке не раньше 2017-2018г.

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

Но, мы можем предположить, что индустрию ожидает новый виток эволюции OSS/BSS систем! И, кто из сервис-провайдеров раньше подготовится к нему, тот станет победителем в будущем…

SDNBLOGGER
SDNBLOGGER - команда SDNBLOG, которая занимается поиском наиболее интересных новостей из мира SDN и NFV, а также публикует статьи по тематике. В команду входят ведущие российские специалисты в области технологий SDN и NFV.

НЕТ КОММЕНТАРИЕВ

ОСТАВЬТЕ КОММЕНТАРИЙ