В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
Б.Н. Дружинин, директор департамента инновационных проектов компании "РТКОММ", к.т.н.
И.Э. Терехин, директор дирекции сетей доступа и клиентских услуг компании "РТКОММ"
Предоставление услуг телефонии корпоративным клиентам всегда было одним из важнейших направлений деятельности операторов связи. Среди сервисов корпоративного уровня сегодня набирает популярность так называемая услуга виртуальной УАТС - IP Centrex. IP Centrex, как и любой другой VoIP-сервис, предполагает обязательное соблюдение требований к параметрам качества сети. В связи с этим операторы, желающие включить IP Centrex в пакет своих услуг, в качестве мульти-сервисной транспортной сети в основном используют сети с MPLS-протоколом, поддерживающим функции контроля и управления качеством. Сегодня в России многие альтернативные и традиционные операторы развернули или планируют развернуть MPLS-сети, получив тем самым возможность предлагать своим корпоративным клиентам гибкие и удобные распределенные услуги корпоративной IP-телефонии. Абоненты услуг IP Centrex при этом не сталкиваются с такими ключевыми на сегодняшний день проблемами учрежденческой пакетной телефонии, как высокая стоимость обновлений программного обеспечения и несовместимость оборудования. Именно эти факторы были отмечены участниками исследования Voice over IP журнала Informati-onWeek (июль 2006 г.) как основные препятствия для внедрения VoIP-решений в структуру бизнес-коммуникаций. В процессе развертывания услуг IP Centrex операторам приходится решать целый ряд вопросов, связанных с особенностями организации доступа к услугам для различных групп пользователей. В данной статье рассматриваются различные варианты организации предоставления услуг IP Centrex с точки зрения архитектуры сети.
"Двойная природа" Centrex
Традиционно сервисом Centrex (аналоговым Centrex и ISDN Centrex) называются услуги телефонной связи, реализованные для удаленного офиса. Услуги предоставляются на базе телефонного коммутатора, расположенного в сети оператора (CENTRal EXchange), в режиме виртуальной телефонной станции (virtual PBX).
Услуга Centrex была разработана в ответ на регулирующие действия в телекоммуникационной отрасли США, когда в 1968 г. главный поставщик телефонных услуг - компания AT&T - была разделена, и вновь образованным телекоммуникационным компаниям был нужен более гибкий сервис, чем централизованная телефонная станция.
IP Centrex - это услуга Centrex, где в качестве транспортной сети используется сеть на основе IP-протокола. В качестве центрального коммутатора при этом используются либо традиционные АТС со специальными модулями сопряжения с IP-сетью, либо программные коммутаторы (Softswitch).
"Двойственность природы" услуги Centrex, предполагающей концентрацию оборудования и обслуживания на стороне оператора и одновременно распределенную работу виртуальных PBX, при правильной архитектуре доступа позволяет смещать направленность услуги как в сторону централизации, так и в сторону большей распределенности в зависимости от потребностей рынка.
Методы организации доступа к услугам IP Centrex на стороне оператора
Оператору услуги IP Centrex необходимо организовать на своей стороне доступ к ресурсам услуги для различных групп пользователей. По методам доступа к услуге IP Centrex эти группы делятся на две большие категории, одна из которых использует для доступа сеть Интернет, а другая (в основном корпоративные пользователи) желает получать ресурсы услуги внутри собственной виртуальной частной сети (Virtual Private Network - VPN). В настоящее время основной технологией построения VPN для средних и крупных компаний является технология MultiProtocol Label Switching (MPLS) [1]. От "чистых" IP-сетей ее отличает реализация механизмов QoS (качества обслуживания), от сетей ATM/FR - поддержка полносвязных частных виртуальных сетей, обеспечивающая хорошее масштабирование клиентских VPN.
Доступ через Интернет
Архитектура организации услуги Centrex на стороне MPLS-оператора для Интернет-клиентов показана на рис. 1.
На схеме представлены следующие элементы:
Особенностью показанной на рис. 1 архитектуры доступа является наличие единой виртуальной частной сети VPN VoIP, общей для всех клиентов VoIP-услуг.
Основное преимущество единой VPN VoIP - простота формирования такой архитектуры. При подключении нового клиента настройки со стороны оператора выполняются только на PE-коммутаторе (3) (организация доступа) и SS (8) (организация виртуальной PBX). Конфигурации Ethernet-коммутатора (5) и SBC (10) производятся только один раз при первоначальной настройке услуги. Отрицательной стороной является необходимость организации специальной защиты пользователей друг от друга внутри общей VoIP VPN.
В целом это оптимальная схема доступа к услуге Centrex в том случае, если абонентскую базу услуги составляют только Интернет-клиенты. Однако если у MPLS-оператора есть и корпоративные абоненты (а это самая распространенная ситуация, так как сеть MPLS ориентирована именно на бизнес-клиентов), то архитектура услуги требует изменений.
Доступ через Интернет и MPLS VPN
Архитектура доступа к ресурсам услуги Centrex для Интернет- и VPN-клиентов MPLS-сети показана на рис. 2.
По сравнению с предыдущей схемой доступа в этой схеме появились следующие новые элементы:
Схема работы выглядит следующим образом. Клиентский маршрутизатор через стандартное подключение к VPN получает доступ к PE-маршру-тизатору, к которому подключены SS и SBC. На этом маршрутизаторе организуется взаимодействие клиентского VPN и VoIP VPN (VPN Interconnection). Схема доступа из Интернета не меняется.
Описанная архитектура услуги, отличаясь своей простотой, все же имеет определенные недостатки. Один из основных - пересечение Интернет- и VPN-клиентов в одной общей VoIP VPN. Это означает некоторую потерю защищенности VPN-клиентов "на пути" к ресурсам IP Centrex и приводит к конкуренции Интернет- и VPN-клиентов.
Еще один недостаток архитектуры касается корпоративных клиентов, которые используют смешанные методы доступа к ресурсам своей сети: одна часть сотрудников работает через MPLS VPN, а другая входит в корпоративную сеть через криптотуннели, организованные поверх Интернета (сегодня такой метод доступа часто называют IP VPN в отличие от MPLS VPN). Суть проблемы заключается в том, что клиент IP VPN по предлагаемой схеме получает доступ сначала в Интернет, затем должен через специальный шлюз в корпоративной сети попасть в VPN и только после этого получит ресурсы Centrex на общих основаниях. Напрямую через Интернет получить ресурсы клиент не может, так как после формирования криптотуннеля теряет прямой доступ в Интернет. По существу, клиент IP VPN в этой архитектуре должен постоянно переключаться между режимами работы в Интернете и IP VPN (если не получает доступ в Интернет изнутри своей VPN-сети).
Если внутри VPN у клиента есть шлюзы для доступа из Интернета, то их должно быть достаточное количество, чтобы трафику не пришлось проходить длинный путь от точки входа клиента в Интернет до шлюза. Некоторое дальнейшее развитие архитектуры услуги у оператора позволяет исправить эту ситуацию и избавить клиентов от необходимости формирования шлюзов.
Смешанный вариант доступа для VPN-клиентов
Архитектура услуги, учитывающая смешанный метод доступа к ресурсам
корпоративной сети (MPLS VPN и IP VPN), представлена на рис. 3.
По сравнению с предыдущей схемой в ней появился новый элемент - SPE (15).
Это Service PE-маршрутизатор, выполняющий роль шлюза для услуг доступа из Интернета к виртуальным частным сетям. На него удобно перевести также функции Interconnections VPN, освободив от них PE-маршрутизатор (3).
Устройства SPE - это маршрутизаторы с поддержкой функциональности виртуальных частных сетей и их взаимодействия, а также со встроенными функциями firewall. Эти устройства расставляются на узлах сети оператора и дают возможность клиентам IP VPN получать доступ к ресурсам корпоративной сети без продолжительного "путешествия" по Интернету. По существу устройства SPE увязывают методы доступа через IP VPN и MPLS VPN.
Один из принципиальных вопросов в этой схеме - выбор устройств, на которых будут терминироваться IP VPN-туннели. Это можно делать как на специальных серверах внутри корпоративной сети, так и на SPE-устрой-ствах. Во втором случае SPE выступает также в роли сервера терминации криптотуннелей, и оператор должен будет регистрировать и вести у себя всех клиентов IP VPN, которые терминируются на его сети. Это отдельная операторская услуга безопасного доступа к VPN, которая может быть развита далее поддержкой на SPE-устройствах криптотуннелей, работающих по российским алгоритмам шифрования.
Аутсорсинг виртуальных ресурсов
В принципе схема на рис. 3 охватывает все методы доступа к ресурсам услуги Centrex, и, казалось бы, на этом развитие архитектуры услуги могло бы закончиться, но есть несколько причин, по которым схема услуги может измениться. В первую очередь это желание оператора передать управление элементами услуги (виртуальной PBX, ресурсами SBC) в руки специалистов клиента. Такое желание вызвано практической невозможностью быстрой реакции крупного оператора на частые мелкие изменения конфигурации услуги. В свою очередь корпоративные клиенты часто хотят самостоятельно вести распределение ресурсов внутри компании, а не отдавать эти функции оператору.
Для того чтобы такой аутсорсинг виртуальных ресурсов был возможен, оборудование, обеспечивающее функционирование услуги, должно обладать определенными свойствами и в первую очередь должно поддерживать:
Многоуровневая иерархичность в применении к услуге Centrex означает возможность разделения ресурсов на виртуальные независимые части, которые, в свою очередь, могут быть также разделены на несколько составляющих. Подобная организация ресурсов позволяет корпоративному клиенту самостоятельно разделить полученную от оператора виртуальную PBX на более мелкие независимые PBX и отдать их под управление своим подразделениям или клиентам. Процесс такого деления может быть продолжен на определенную глубину. Как показывает опыт, для гибкого предоставления услуг нужно не менее четырех уровней иерархии: оператор -> корпоративные РВХ -> PBX подразделений -> PBX групп пользователей. Для гибкого предоставления услуги необходимо иерархическое разбиение SBC, аналогичное ресурсам PBX.
Под поддержкой распределенного доступа подразумевается в первую очередь возможность организации сетей VLAN на Ethernet-соединениях (6) и (7), то есть поддержка оборудованием SS и SBC транкового протокола 802. 1q.
Архитектура услуги, позволяющая передавать ресурсы услуги Centrex в аутсорсинг, показана на рис. 4.
По сравнению с предыдущей схемой изменения коснулись только устройств SW, SS и SBC. На коммутаторе Ethernet (SW) появились VLAN под каждую VPN и транковые соединения (6) и (7). Никаких особенных требований к SW при этом не возникло: он выполняет стандартные функ-ции Ethernet-коммутатора. От устройств SS и SBC в этой схеме требуются совершенно нетривиальные свойства, о которых речь шла выше: они должны иметь возможность многоуровневой иерархичности и организации доступа к своим виртуальным элементам по Ethernet-транку. Далеко не все вендоры предлагают оборудование с такими свойствами, но развитие техники идет именно в этом направлении.
Еще одно существенное изменение схемы - исчезновение Interconnection VPN на SPE. Ресурсы во все VPN (в том числе и в VoIP VPN) заводятся через транковые соединения (6) и (7). VoIP VPN больше не играет роли общей VPN для подключения всех ресурсов, она используется только клиентами Интернета. IP VPN-клиенты через SPE попадают в свою MPLS VPN и через нее получают доступ к ресурсам.
При реализации этой схемы начальная конфигурация услуги оператором при подключении клиента усложняется: для каждого VPN нужно завести виртуальные ресурсы на SS и SBC, организовать VLAN на SW и вывести его через транковое соединение (6) в соответствующий VRF на PE-марш-рутизаторе (3). Однако одновременно оператор получает полную развязку VPN между собой и возможность управления и мониторинга потоками трафика для каждой VPN отдельно. В схеме на рис. 3 все потоки трафика проходят через общую VoIP VPN, что при большом числе клиентов может существенно ухудшить управляемость услуги.
По сути, схема на рис. 2 отображает архитектуру услуги IP Centrex сегодняшнего дня при небольшом числе клиентов. Рис. 3 - это архитектура услуги дня завтрашнего (которую уже можно предоставлять сегодня). На рис. 4, возможно, отражена архитектура услуги Centrex недалекого будущего, которое зависит от развития оборудования SS и SBC.
Организация доступа к ресурсам IP Centrex со стороны пользователей
Индивидуальные подключения
Услуга IP Centrex ориентирована в первую очередь на рынок бизнес-пользователей. В принципе в предельном случае для индивидуальных пользователей может быть организована виртуальная PBX емкостью в 1-2 номера (схема подключения таких пользователей показана на рис. 5), но при этом клиенты должны будут самостоятельно удаленно настраивать эту маленькую PBX. Ситуация при этом будет несколько сложнее, чем при настройке соединения с услугами Skype, так как пользователь наверняка пожелает организовать сопряжение VoIP-телефонии, появившейся у него от виртуальной PBX, с имеющейся у него линией ТфОП.
На схеме представлены следующие элементы:
Клиент получает по существующей телефонной линии услугу DSL-соединения, при этом существовавшая ранее услуга телефонии сохраняется, и аналоговый аппарат просто переключается на сплиттер (4). Для получения услуг доступа в Интернет и VoIP пользователь должен установить у себя достаточно интеллектуальный модем-маршрутизатор DSL (1). Основные требование к нему: возможность организации нескольких PVC на DSL-соединении (для раздельного предоставления услуг передачи данных, телефонии, а затем и видеотрафика) и возможность приори-тезации трафика реального времени. VoIP-аппарат (2) может быть подключен напрямую к маршрутизатору (1).
Недостатками схемы на рис. 5 являются разделение услуг аналоговой телефонии и VoIP (очевидно, что неудобно иметь дома два аппарата, использующих различные технологии работы), а также ограниченные возможности небольших маршрутизаторов по количеству подключений VoIP-телефонов. Схема, не имеющая этих недостатков, представлена на рис. 6.
Малые офисы
По сравнению с рис. 5 в схеме на рис. 6 появились два новых устройства: Ethernet-коммутатор SW (8) и адаптер аналог-VoIP (9). В небольших сегодняшних маршрутизаторах обычно имеется не менее четырех Ethernet-портов, поэтому SW должен устанавливаться, если клиенту необходимо иметь более четырех различных Ethernet-устройств. Аналог-VoIP-адаптер нужен, если клиент решит оставить у себя свой старый аналоговый телефон (3). Этот адаптер просто превращает аналоговый телефон (3) в VoIP-телефон (при этом VoIP-телефон (2) как отдельный терминал в принципе уже не потребуется).
Кроме этих двух устройств изменилось также соединение FXS-FXO (7), которое со сплиттера заведено напрямую в маршрутизатор CE (разумеется, для этого на маршрутизаторе должен быть порт FXO).
Схема на рис. 6 позволяет клиенту при правильных настройках маршрутизатора использовать один и тот же телефон для организации звонков как в ТфОП, так и в VoIP-сеть.
По схеме на рис. 6 могут подключаться не только индивидуальные клиенты, но и небольшие офисы (при этом соединение FXS-FXO может использоваться в качестве резервного, а также для выполнения местных звонков).
Крупные корпоративные пользователи
Более крупные офисы обычно подключаются к корпоративной VPN по E1-соединениям или Ethernet-интерфейсам. Схема такого корпоративного офиса показана на рис. 7.
На схеме представлены следующие элементы:
Обычно крупный корпоративный клиент заказывает услугу IP Cen-trex (виртуальную PBX) для сокращения расходов при переходе на VoIP-технологию и для сопряжения со своим центральным офисом. Для таких случаев услуга IP Cen-trex наиболее интересна, так как позволяет после получения у оператора виртуальной PBX разделить ее на офисные PBX и без приобретения оборудования сформировать во всех офисах однотипные виртуальные VoIP PBX с единой системой нумерации.
При формировании услуги IP Cen-trex оператор заносит информацию о шлюзе GW в виртуальную PBX, и сотрудники офиса могут делать локальные звонки в местную городскую сеть с VoIP-телефонов и получать вызовы из городской сети.
В схеме на рис. 7 может появиться и собственная местная PBX. Если в таком офисе необходимо сохранить собственную станцию, то возникает задача организации так называемого бизнес -транка между ней и центральным коммутатором Softswitch и формирования единой системы нумерации с центральным офисом. В принципе это уже не услуга IP Centrex: сотрудники офиса получают сервис от собственной станции (в большинстве случаев это сервисы более низкого уровня, чем при работе с SS, в качестве которого используются обычно коммутаторы 5-го класса со всем спектром современных услуг). Такая схема может использоваться при переходе со старой собственной станции на услуги IP Centrex.
При выборе конкретного клиентского оборудования необходимо руководствоваться не только финансовыми возможностями клиента, но и техническими возможностями оператора, предоставляющего услуги. Сегодня на рынке представлены десятки моделей маршрутизаторов, медиашлюзов, IP-телефонов, а также комбинаций этих устройств. Выбор моделей клиентского оборудования должен осуществляться по следующим критериям:
IP Centrex как метод организации услуг
Проанализировав развитие архитектуры сервиса IP Centrex, можно увидеть, что проблемы, требующие изменения структуры услуги от схемы на рис. 1 до рис. 4, являются общими для многих услуг. Сервисы, первоначально ориентированные на доступ Интернет-клиентов, впоследствии трансформируются для доступа клиентов VPN, а при большом числе пользователей у оператора возникает потребность отдать часть функций управления услугами самим клиентам.
Помимо клиентских продуктов такое же развитие архитектуры претерпевают многие внутриоператорские системы, имеющие серверную составляющую, например системы видеоконференций [4], мониторинга [6], биллинга, системы измерения параметров качества [5] и т.д. Клиенты просят организовать для них аналогичные услуги, и у оператора возникает естественное желание виртуализировать такие системы и использовать по единой технологии часть ресурсов для внутренних нужд, а оставшуюся часть предоставлять в пользование клиентам.
Смысл организации продуктов с единой технической архитектурой достаточно очевиден. Если еще раз взглянуть на рис. 4, то становится понятно, что устройства PE (3), SW (5), SPE (15) могут быть без изменений использованы для организации доступа к ресурсам не только IP Centrex. Представленная архитектура обладает также хорошими возможностями масштабирования. При необходимости для организации некоторых услуг могут быть выделены отдельные устройства SPE, SW и даже PE (например, видеоконференции отличаются большими потоками трафика, поэтому для них целесообразно формировать отдельные SPE). Единая архитектура доступа дает также хорошие шансы на дальнейшее успешное внедрение систем OSS/BSS.
Далеко не все оборудование операторов связи сегодня позволяет организовывать услуги с архитектурой, показанной на рис. 4. Даже для наиболее продвинутых услуг типа IP Centrex коммутаторы Softswitch и контроллеры SBC далеко не всех производителей обладают свойствами поддержки многоуровневой иерархичности виртуальных ресурсов и разделенного доступа. Особенно это касается разделенного доступа (поддержки VLAN). По непонятной причине большинство серверных решений не обладают этой технологией. Поддержки VLAN нет даже у наиболее продвинутых решений от фирмы BroadSoft, и этот параметр не упоминается как важный практически ни в одном обзоре по IP РВХ [2]. То же самое можно сказать и о контроллерах SBC [3].
Заключение
Сегодня ведется много споров о жизнеспособности централизованных услуг. Появляется много сервисов, для предоставления которых не требуется специальный централизованный коммутатор. Яркий пример этому -развитие продуктов компании Skype. Кроме того, в сетях операторов активизируется процесс перехода к инфраструктуре следующего поколения, которая должна позволить гибко формировать распределенные услуги и управлять ими. Наиболее эффективно это может быть реализовано в рамках архитектуры IMS, которую можно представить в виде трех уровней:
Для использования в качестве транспортной сети наиболее подходящими являются сети MPLS. Управление вызовами и сеансами выполняется с помощью специальных централизованных серверов. IP-приложения также реализуются на серверных платформах.
В такой ситуации операторам, работавшим до сих пор по централизованной схеме предоставления услуг, необходимо виртуализировать свои продукты и ресурсы, чтобы, с одной стороны, иметь возможность организовать распределенную схему работы, а с другой - обеспечить постепенное развитие IMS. Развитие архитектуры услуги IP Centrex является ярким примером такого процесса и позволяет прогнозировать типовую общую архитектуру доступа к будущим сервисам оператора в рамках архитектуры IMS.
Литература
Опубликовано: Журнал "Технологии и средства связи" #5, 2006
Посещений: 12768
Автор
| |||
Автор
| |||
В рубрику "Решения операторского класса" | К списку рубрик | К списку авторов | К списку публикаций
