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

Сегодня поддержка провайдером тех или иных услуг зависит от происхождения провайдера и природы услуг. Традиционные операторы (такие, как региональные операторы Bell и крупные операторы межстанционной связи) имеют высокоразвитую структуру заказа и поддержки услуг, собирательно называемую системой обеспечения функционирования (Operations Support System, OSS).

Системы же управления провайдеров услуг передачи данных, таких, как провайдеры Internet, опираются на протокол SNMP и соответствующие приложения. Небольшие провайдеры иногда даже используют Microsoft Access или Excel для ведения картотеки о своих клиентах.

Отсутствие согласованной структуры заказа и поддержки услуг передачи данных уже вызывает недовольство некоторых заказчиков, а ведь расходы на передачу данных составляют только около 20% расходов на связь в Соединенных Штатах. Ввиду увеличения важности и роста затрат на услуги передачи данных отсутствие согласованной структуры (и, как следствие, недовольство пользователей) может еще более усугубить ситуацию.

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

ЭВОЛЮЦИЯ УСЛУГ И ИХ ПОДДЕРЖКИ

Современные сети связи общего пользования создавались для поддержки голосовых услуг, и базовые параметры и элементы этих услуг - от канала на 64 Кбит/с до скорости передачи 8000 кадров в секунду в SONET - выбирались, исходя из требований передачи речи. Коммутация, транспорт и услуги были объединены в одной сети. Неудивительно поэтому, что процессы OSS также был привязаны к поддержке голосовой телефонии. В случае голосовых услуг предоставление услуги означает выделение пар проводов или квантов времени. Биллинг означает запись подробностей о звонке и выставление счета за сделанный звонок.

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

Виртуальная сетевая услуга - это такая услуга, когда провайдер не гарантирует ни определенной фиксированной скорости передачи (как в случае выделенной линии), ни выделенного соединения (как в случае телефонного звонка), а обеспечивает лишь возможность взаимодействия между группой узлов с предопределенным уровнем QoS. Этот уровень QoS соответствует усредненным характеристикам обслуживания в периоды пиковой нагрузки и выражается в таких величинах, как средняя скорость, средняя задержка и вероятность потери или удаления трафика из сети.

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

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

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

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

Те, кто занимается Internet/IP, считают, что гарантии на услуги можно реализовать благодаря сочетанию большого количества дешевой пропускной способности и введения ряда предопределенных классов сервиса в масштабах сети. Ресурсы выделяются каждому классу сервиса, и трафик из пользовательской сети просто направляется по маршрутам, где поддерживается соответствующий ему класс сервиса. Это подход без установления соединения.

В сетях, соответствующих модели с установлением соединения, для создания предопределенных путей требуется реализовать более сложную логику; тогда как в сетях без установления соединения требуется только направить трафик на нужный маршрут. Какая модель предпочтительнее? Большинство современных услуг передачи данных ориентировано на установление соединения, в то время как большинство новых приложений не предполагает установления соединения, так что выбирайте!

Другую проблему составляет поддержка. Если выделенная линия выходит из строя, то провайдеру услуг достаточно просто отследить маршрут соединения вдоль проводов с учетом выделенных квантов времени, пока он не наткнется на место сбоя, а затем пустить маршрут в обход отказавшего компонента. Когда же проблемы возникают с виртуальной услугой, отказ может произойти из-за временной перегрузки сети, и к тому времени, когда провайдер попытается выяснить его причины, затор уже давным-давно рассосется. Большинство провайдеров виртуальных сетевых услуг используют оборудование с поддержкой автоматической маршрутизации в обход проблемных мест, так что операторы видят только катастрофические сбои - как те, с которыми в 1999 году столкнулись MCI WorldCom и AT&T.

Все это вызывает обеспокоенность, но еще хуже то, что эти новые услуги будут сосуществовать с ориентированными на соединение услугами по крайней мере до 2010 года, так что провайдеры услуг и пользователи будут вынуждены в своих взаимоотношениях опираться на дикую смесь прежних (на базе OSS) и новых (на базе виртуальных сетей) вариантов систем поддержки услуг. Так что же могут сделать операторы для наведения порядка в грозящем хаосе и какова будет ваша как пользователя роль в этом?

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

НА СЦЕНУ ВЫХОДИТ VPNOSS

Рисунок 1. Поддержка операций по порядку.

На Рисунке 1 показан вероятный поток информации и схема создания и поддержки виртуальных сетевых услуг. Так как, с точки зрения заказчика, эти услуги выглядят как ориентированная на передачу данных виртуальная частная сеть, то я буду использовать термин "VPNOSS" в отношении связанных с ними OSS.

Как видно из рисунка, VPNOSS опирается на модель сервиса (Service Model, SM), представляющую собой совокупность характеристик услуги, за которую пользователь платит деньги. На рисунке SM представлена как виртуальный маршрутизатор с исходящими виртуальными соединениями до каждого из узлов пользователя. Такая конфигурация виртуальной услуги типична для VPN на базе IP.

SM определяется в результате диалога между представителем отдела по работе с клиентами в офисе провайдера услуг и уполномоченным покупателем услуг в штаб-квартире компании. Получив звонок от потенциального заказчика, представитель генерирует окно "новой услуги" в VPNOSS и зачитывает пользователю с экрана ряд вопросов для выяснения таких важных деталей относительно услуги, как ожидаемое QoS, местонахождение офисов клиента и требования в отношении других характеристик. Изображенная на рисунке схема создавалась в предположении, что наряду с VPN заказчик покупает поддержку DNS для IP.

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

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

Некоторые производители, в том числе Cisco Systems, включают в свое программное обеспечение для VPNOSS мощный инструментарий моделирования. Такой инструментарий позволяет быстро определить возможность предоставления сетью новой услуги без использования дополнительного оборудования или каналов. Другие производители (и их, по всей видимости, большинство) осуществляют пробное предоставление услуги в целях определения необходимых для этого ресурсов. В принципе, производители могут поддерживать оба подхода.

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

Использование SM для создания услуги составляет, вероятно, наиболее сложную процедурную часть VPNOSS. Для этого VPNOSS должна иметь карту физической инфраструктуры сети, карту запрашиваемых заказчиком услуг (параметры SM) и набор правил для контроля за выделением ресурсов под услуги. Правила могут, например, предусматривать "использование этого канала только для услуг с требуемым QoS больше x".

Процесс предоставления услуги состоит в "расчленении" SM и распределении между сетевыми устройствами определенных ролей в реализации каждой составляющей услуги. В частности, предоставление полной услуги frame relay может потребовать создания отдельных виртуальных каналов (Virtual Circuit, VC). Для этого через интерфейсы управления каждому устройству необходимо будет подать команду об открытии VC определенного типа. Таким образом, VPNOSS не заменяет собой имеющееся программное управление сетью, а является надстройкой над ним.

Еще один вопрос в области поддержки услуг касается содержания баз управляющей информации SM. Предоставление пользователю возможности чтения параметров услуги имеет ограниченную пользу. Лучше было бы, если бы пользователям была предоставлена возможность посмотреть, в какой мере услуга в данный конкретный момент соответствует требованиям к QoS, указанным в соглашении об уровне сервиса (Service Level Agreement, SLA). Если бы база управляющей информации SM позволяла клиенту быстро определить соответствие услуги и ее характеристик ожидаемым, тогда администраторы сетей имели бы информацию о новых сетевых услугах, по крайней мере, такого же качества, как в частных сетях, а провайдерам услуг не понадобилось бы разрешать пользователям обращаться с запросами напрямую к устройствам, тем более что это может составлять серьезную проблему с точки зрения защиты.

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

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

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

Суммируя сказанное, отметим, что хорошая VPNOSS должна давать пользователю возможность создавать с помощью представителя провайдера модель виртуальной услуги. Эта модель должна быть тарифицируема и проверяема на соответствие возможностям сети во избежание каких-либо накладок. После введения в действие услуга будет представлена в виде объекта базы управляющей информации SM в системе управления пользователя (или в виде таблицы в системе управления на базе Web), а значения MIB будут отражать текущие характеристики услуги.

ИНТЕГРАЦИЯ VPNOSS И OSS

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

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

Рисунок 2. Три варианта эволюции системы обеспечения функционирования (Operations Support System, OSS).

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

Первый способ создания унифицированной структуры VPNOSS/OSS состоит в объединении всех услуг в новой сетевой инфраструктуре. Этой новой сетевой инфраструктурой будет управлять VPNOSS, и со временем OSS будет полностью устранена от управления. Такой подход вполне логичен в предположении, что сеть будущего очень быстро вытеснит существующую сеть - в течение четырех лет или даже за меньший срок. Большинство сторонников конвергенции (т. е. будущей инфраструктуры с доминированием IP) предлагают именно такой "скоростной" подход к интеграции поддержки услуг.

Второй взгляд на унифицированную структуру VPNOSS/OSS, менее зависимый от быстроты внедрения инфраструктуры нового поколения, предполагает постепенное поглощение (см. тот же Рисунок 2). В этом случае VPNOSS имеет интерфейс обслуживания и поддержки как для персонала провайдера услуг, так и (факультативно) для конечного пользователя.

Если в первом случае обеспечивающее приложение VPNOSS действует через интерфейсы управления сетью имеющихся сетевых устройств для осуществления настройки при создании услуги, то при втором подходе программное обеспечение VPNOSS используется для управления имеющимися приложениями OSS. Относящаяся к унаследованным услугам и их обеспечению часть требований заказчика будет преобразовываться в надлежащий формат для использования с имеющимися OSS, но общее управление взаимосвязями сервиса будет осуществляться с помощью новой VPNOSS.

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

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

Цель стратегии упаковки состоит в создании нового уровня поддержки услуг в виде программного обеспечения и процедур, охватывающего и VPNOSS, и OSS для выделенных линий и голосовых услуг. В результате заказчики получат одну общую инстанцию для обращения по поводу проблем с услугами, а сервисные агенты смогут анализировать SM MIB заказчика и управлять процессом нахождения и исправления сбоев.

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

Однако пользователи могут оказаться не особенно заинтересованы в объединении счетов. Например, крупные компании по-прежнему распределяют получаемые от провайдеров услуг счета между подразделениями, отвечающими за приложения, сети и компьютерные системы, использующие услуги, за которые выставлен счет. Таким образом, счет за использование услуг frame relay может направляться в центр обработки данных SNA, потому что эта услуга оплачивается из его бюджета. В такой ситуации совокупный счет только усложнит задачу покупателя.

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

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

Все расширяющееся использование браузеров, HTML или XML, и апплетов Java должно решить эту проблему, так как оно значительно упрощает создание прикладного интерфейса для человека-оператора. Инструментарий на базе Web позволяет производить любую необходимую настройку отображаемых экранов, а все приложения на базе браузеров имеют стандартный интерфейс, поэтому операторы могут не без основания рассчитывать, что интерфейсы приложений OSS и VPNOSS при управлении через Web будут вести себя аналогично. Инструментарий Web может также использоваться для создания специализированных или составных дисплеев для нескольких приложений, что позволило бы интегрировать старые и новые исполнительные приложения более эффективным образом.

Кроме того, инструментарий Web будет, скорее всего, тем средством, с помощью которого пользователи получат доступ к исполнительным системам провайдера услуг. Возможность увидеть объект SM будет, несомненно, полезна администратору сети для диагностики проблем, но вряд ли она пригодится при заказе услуги, выверке счетов и для других рутинных задач.

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

ЗА КЕМ ПОСЛЕДНЕЕ СЛОВО?

В современных унаследованных сетях и унаследованных услугах доминирующее положение занимают традиционные производители, такие, как Lucent Technologies и Nortel Networks, и традиционные архитектуры OSS, например разрабатываемая и продвигаемая Telcordia (ранее Bellcore). Данная комбинация дает свыше 95% всех доходов от услуг по предоставлению несущей, а это почти все услуги, которые сегодня покупают пользователи.

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

В международном масштабе интерес к созданию и поддержке сетей и услуг следующего поколения проявляют многие компании и страны. Одна из них, сеть управления телекоммуникациями (Telecommunications Management Network, TMN), обеспечивает базис для управления услугами, не сильно отличающийся от трех подходов, изображенных на Рисунке 2: управление услугами на верхнем уровне, управление сетью на промежуточном уровне и управление устройствами на нижнем уровне.

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

Традиционные производители OSS приспосабливаются к новому рынку. Telcordia приняла новую модель поддержки и управления заказчиками, а ее конкурент Convergys (ранее Cincinnati Bell Information System) также реструктуризировал свои предложения. Оба эти игрока придерживаются теперь более обобщенного клиент-серверного подхода с новыми приложениями в качестве внешнего интерфейса, унифицирующими представление бюджета пользователя независимо от услуги. Эти поставщики будут, вероятно, иметь наибольшее влияние, однако все зависит от того, в какой мере на требованиях к VPNOSS и OSS в будущем скажется необходимость поддержки сегодняшних услуг, заказчиков и оборудования.

Взаимосвязь этих новых архитектур с VPNOSS остается, однако, недоказанной. Очевидно, что провайдеры с небольшими объемами продаж традиционных услуг или вообще их не предоставляющие не станут брать на вооружение модель традиционной OSS. Аналогично, провайдерам, интегрировавшим свои собственные услуги передачи данных с оптовыми голосовыми услугами, поддержка унаследованных OSS будет не нужна. В обоих названных случаях требования сети передачи данных к OSS будут доминирующими. Это обстоятельство благоприятствует производителям оборудования более, чем новым игрокам, претендентам на разработку VPNOSS. Ввиду отсутствия стандартов управления в области VPN сколько-нибудь ощутимо VPNOSS на поведение сети повлиять не могут - если только это не окажется производитель оборудования, составляющего сеть.

Ответ на то, каким образом будут предоставляться сервисные и административные функции в будущем, должны, вероятно, дать производители оборудования. VPNOSS являются необходимыми элементами архитектур VPN, и все основные игроки (Cisco, Lucent, Nortel), и полные надежд их конкуренты (Alcatel, Ericsson, Siemens) должны в конечном итоге взять на вооружение (возможно, неявным образом) одну из интеграционных моделей, показанных на Рисунке 2.

Новые поставщики средств управления, такие, как Syndesis и Micromuse, также начинают заниматься VPNOSS, предлагая независимый от производителя комплект управления, удовлетворяющий определенной части требований к VPNOSS. Весьма возможно, что "поставщики комплектов" преуспеют в той мере, в какой они смогут создать партнерские отношения с производителями оборудования VPN, чей контроль над новыми применениями сетей передачи данных может помочь им проникнуть в ключевые бюджеты операторов.

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

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

Том Нолле - президент консалтинговой компании в области стратегического планирования технического развития CIMI. С ним можно связаться по адресу: tnolly@cimicorp.com.