Строительство сетевой «Вавилонской» башни

MSF обещает разрешить проблему «многоязычности» общедоступной гетерогенной сети. Не слишком ли это хорошо звучит, чтобы быть правдой?

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

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

Впрочем, в такой интерпретации истории о Вавилонской башне может появиться собственный герой. Созданная в 1998 г. специальная организация разрабатывает архитектуру, появление которой должно ответить на вопрос, как будет работать сеть будущего и как операторы и пользователи смогут воспользоваться ею, вне зависимости от того, с чего они начинают, чем занимаются и какие технологии используют. Эта организация — Форум мультисервисной коммутации (Multiservice Switching Forum, MSF).

MSF возник по необходимости. В конце 1990-х гг. компании British Telecom (BT) и MCI вели переговоры о слиянии, причем, как предполагалось, в арсенале новой глобальной корпорации будет иметься по крайней мере по одному экземпляру каждого из когда-либо проданных сетевых устройств. Специалисты названных компаний-операторов пытались решить, как такого рода сеть — при всем разнообразии ее технологий и требований — можно объединить в единой инфраструктуре, обеспечив конкурентоспособный, разнообразный набор услуг. Они обсудили эти вопросы с рядом ведущих производителей, но данная инициатива постепенно сошла на нет, поскольку сделка так и не состоялась.

Однако цели были слишком заманчивы и логичны, чтобы о них удалось так просто забыть. В 1998 г. на конференции в Орландо был создан MSF — наверное, самый значительный технологический форум нашей эпохи. Цель MSF состояла в разработке мультисервисной архитектуры, причем она не предполагает конвергенции на базе IP или любой другой конкретной технологии, производителя или концепции услуг. Организаторы хотели создать действительно универсальную сеть.

Они считают, что, возможно, им это удалось. Первые результаты деятельности MSF стали известны в прошлом году, и форум рассчитывает, что сможет повлиять на рыночную ситуацию уже в 2002 г.

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

ПРОБЛЕМЫ И ВОЗМОЖНОСТИ MSF

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

Если передача сигналов о сервисе играет важную роль в концепции предоставляемых пользователю услуг, то она имеет критическое значение в контексте функционирования самой сети. Сеть — это совокупность узлов и каналов, где любое полезное перемещение информации, скорее всего, потребует взаимодействия множества устройств и распределения ресурсов между различными путями. В односервисных приложениях подобная проблема легко решаема. Телефонная сеть выполняет телефонные звонки, и каждое сетевое устройство «говорит» на языке телефонии: Signaling System 7 (SS7). На каком языке станут общаться устройства в мультисервисной сети? Будет ли информация о статусе, переданная на «языке» одной службы, отличаться от информации, изложенной иначе? Что способно вызвать ошибки при интерпретации? Можно ли одни и те же ресурсы назначить пользователям различных служб, поскольку одна служба «не видит» другую? Передача сигналов — это «Вавилонская башня» сетевых операций: почти каждый класс устройств, от телефонного коммутатора до маршрутизатора, имеет уникальный набор сигнальных протоколов.

Одно из возможных решений проблемы, детально изученное за последние четыре года, — это конвергенция на основе единой сетевой архитектуры. На роль такой архитектуры претендует IP, что вызвано особенностями Internet, но конвергенция на базе IP не выгодна с экономической точки зрения. Во-первых, трудно финансово оправдать необходимую для реализации каналов IP реструктуризацию существующих сетей. Во-вторых, технические проблемы представляет интеграция отличных от IP сервисов. Обсуждение конвергенции выходит за рамки данной статьи. Достаточно сказать, что Уолл-стрит, по-видимому, больше не проявляет заинтересованности в этом решении, поэтому необходимо найти иные подходы.

Мультисервисную сеть можно рассматривать как ряд структур виртуальной сети, наложенных на физическую сеть, в основе которой используется мультисервисное оборудование. С этой точки зрения каждую такую «сеть» было бы логично представить как оболочку для сервисов и в то же время как применение аппаратных возможностей. Этот «прикладной уровень» можно затем отобразить на реальные сети — во-первых, на уровне транспортировки информации, или коммутационном уровне, и, во-вторых, на уровне протокола управления. Таким образом мы имеем три уровня — прикладной, контрольный и коммутационный. Добавьте четвертую административную плоскость для операционных функций, и вы получите основу подхода MSF.

Цель MSF состояла в том, чтобы сделать максимально общей ту часть сети, которая выполняет обработку информации, а затем объединить ее с серией параллельных плоскостей управления сервисами для создания совокупности услуг. Специфическая для конкретного сервиса часть существующего сейчас «винегрета» технологий будет отделена от сетевого аппаратного обеспечения и размещена на уникальном уровне, или плоскости. Каждый уровень будет состоять из независимых устройств, взаимодействующих друг с другом по правилам стандартных протоколов. Это позволило бы реализовать данный сервис единообразно, вне зависимости от базового аппаратного обеспечения: множество производителей, технологий и бизнес-моделей с единой общей архитектурой.

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

ОБОЛОЧКА MSF

На Рисунке 1 представлена схема оболочки MSF — архитектуры для создания мультисервисных гетерогенных сетей на базе различных технологий. Подход MSF предполагает формирование уровней по типу модели взаимодействия открытых систем (OSI), но взаимосвязи между уровнями организованы скорее на принципах взаимного партнерства, чем фиксированного стека. (Заметим, что MSF использует термин «плоскость» для обозначения структурного уровня.)

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

Ядро оболочки MSF — это концепция независимой коммутирующей плоскости, частью которой может быть любой модуль обработки информации (коммутатор, маршрутизатор, модуль передачи и т. д.), если он способен выполнять мультисервисные функции. Характеристики аппаратного обеспечения, которое могло бы поддерживать эти операции, выделение ресурсов, передачу информации и т. д., определяются в абстрактном «виртуальном устройстве» на этой плоскости. Работа оборудования контролируется путем изменения правил или параметров, управляющих данным виртуальным устройством, поэтому для каждого вида аппаратного обеспечения или сервиса существует свой тип виртуального устройства. Концепция виртуальных устройств достаточно распространена в сетях; простой протокол управления сетью SNMP использует базу управляющей информации (MIB) «виртуальных устройств» для реализации, к примеру, управления аппаратным обеспечением различных производителей. MSF представляет собой расширение данной парадигмы.

Виртуальное устройство связано управляющим соединением с другой плоскостью MSF — плоскостью управления. Она состоит из серии «контроллеров», привязанных к конкретным наборам сервисных протоколов, таким, как голос/SS7, ATM/интерфейс между частными сетями (Private Network-to-Network Interface, PNNI) или IP/многопротокольная коммутация с использованием меток (Multiprotocol Label Switching, MPLS). Контроллеры манипулируют характеристиками виртуального устройства внутри каждого компонента аппаратного обеспечения и тем самым регулируют поведение сетевого оборудования. Благодаря этой связи виртуальных устройств и контроллеров последние могут работать с оборудованием различных производителей единообразно. И опять-таки, описанная концепция аналогична сетевому управлению с помощью SNMP. Одна MIB может быть определена для серии устройств, и способы работы с каждой MIB одинаковы, но реализация MIB в устройстве специфична для устройства.

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

Данным процессом управляет прикладная плоскость, содержащая модель сервисной логики. Это может стать определяющей концепцией MSF. В современных сетях сервисы образуются в результате обращения пользователей к тем или иным возможностям, предоставляемым сетью. Таким образом, сервисы — всего-навсего функции сетей. Но такая модель не совсем подходит для мультисервисных сред или для «не зависящих от сервисов» технологий, например оптики. В подходе MSF интеллектуальный сервисный компонент размещается на высоком функциональном управляющем уровне; он управляет интерпретацией сервисных запросов и распределением ресурсов сети и устройств. Пример «компоновки» интеллектуальной составляющей сервиса можно найти в современной телефонной сети, где архитектура развитой интеллектуальной сети (Advanced Intelligent Network, AIN) определяет «точки контроля сервиса» (Service Control Point, SCP) для добавления сервисной логики. В разрабатываемых сейчас сетях с программной коммутацией новая прикладная логика формируется с помощью таких интерфейсов программирования приложений (Application Programming Interface, API), как Java AIN (JAIN) API, разработанных с участием компании Sun Microsystems.

На Рисунке 2 показаны модели работы оболочки в условиях реального мира. Они представляют собой сервисную сеть ATM и пакетную передачу речи (Voice over Packet, VoP) (включая IP). Соглашение о реализации (Implementation Agreement) MSF, стандарт на полную интероперабельность, поддерживает последнее приложение, а разработка первого пока находится на концептуальной стадии. Данный рисунок также иллюстрирует общую модель взаимодействия управление/устройство, которая лежит в основе архитектуры MSF. (Для простоты детальная структура административной и адаптационной плоскостей не представлена.)

Передача голоса поверх IP (Voice over IP, VoIP) является примером реализации самых известных концепций. Контроллер шлюза (часть плоскости управления) связывается через принятый стандарт (MEGACO, или Media Gateway Control Protocol, MGCP) со шлюзом голос/мультимедиа (устройство коммутирующей плоскости), обеспечивая преобразование между стандартными сигналами SS7 для абонентов телефонной коммутируемой сети общего пользования и сетевой средой IP. Контроллер считывает сигналы SS7 и передает шлюзу команду на создание перекрестных соединений между входящими звонками (к примеру, от «настоящего» коммутатора Класса 5) и вызовами IP по протоколу инициирования сеансов (Session Initiation Protocol, SIP). Аналогичное преобразование осуществляется и на другом конце. Все это может регулироваться с помощью стандартов на сигнализацию, действующих «над» плоскостью управления — в прикладной плоскости.

В примере с ATM показан контроллер сервиса, или контроллер коммутатора, использующий универсальный протокол управления коммутатором (Generic Switch Management Protocol, GSMP) для контроля над соединениями на коммутаторе ATM (протокол GSMP поддерживает такие функции коммутатора ATM, как установка соединения, управление портами коммутатора и уведомление об ошибке канала). Сеть такой конфигурации может устанавливать виртуальные соединения ATM от одного пользовательского порта до другого через оборудование различных производителей независимо от конкретного механизма установления постоянного виртуального канала (Permanent Virtual Circuit, PVC) и поставщика решений на базе технологии ATM.

Конечно, организовать виртуальные соединения ATM и звонки по IP можно и без MSF. Это одна из сложных задач, с которыми сталкивается архитектура MSF: вряд ли в ближайшее время в сетях будет реализована дополнительная функциональность. Цель MSF — мультисервисная оболочка сети уровня операторов, в которой используется оборудование различных производителей и разнообразные технологии. В ближайшем будущем эта оболочка будет дублировать в «открытой» среде то, что производители уже делают в сетях, построенных на базе оборудования одного производителя.

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

ПЕРЕХОД НА MSF

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

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

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

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

Управление «сетью» на основе подхода MSF для большинства операторов будет означать управление сетевыми узлами — коммутаторами и маршрутизаторами. MSF предложил для этой цели эталонный подход (см. Рисунок 2). Он базируется на GSMP, который нельзя отнести к популярным протоколам. Мы поинтересовались у ведущих производителей коммутаторов ATM операторского класса, поддерживают ли они GSMP, и выяснилось, что ни один из них не предлагает такую поддержку в качестве базовой функции своего продукта. Рабочей группе GSMP, на самом деле, трудно привлечь внимание, получить конкретную помощь или даже убедить принять участие в своих совещаниях.

Но это еще не все. Член MSF, компания Cisco Systems, предлагает собственную архитектуру управления коммутатором — интерфейс виртуального коммутатора (Virtual Switch Interface, VSI). Судя по некоторым признакам, VSI, который для ряда приложений уже реализовали около 50 провайдеров услуг, может повлиять на распространение GSMP и направление разработки соглашений о реализации MSF для управления коммутаторов.

Интересный подход предлагает компания Marconi, еще один ведущий производитель на рынке операторов ATM и член MSF. Ее представители утверждают, что компания реализует поддержку GSMP посредством программного обеспечения управления сервисом, разработанного тоже членом MSF, компанией CPLANE. Системы управления сервисом (программное обеспечение для поддержки операционных функций мультисервисных сетей) могут сделать понятными друг другу протоколы управления MSF, например GSMP, и разработанные самими производителями системы управления коммутаторами и маршрутизаторами.

Этот подход — преобразование управления сервисом — позволяет понять, как архитектура MSF могла бы быть применена к существующим сетям. На Рисунке 3 изображена система управления сервисом, действующая одновременно и как уровень преобразования, и как «прикладная плоскость», к которой относятся задачи координации сервисов. Хотя архитектуры управления сервисом существовали еще до MSF, ведущие компании на рынке управления сервисом приняли архитектуры, весьма похожие на более высокие уровни MSF (прикладную и управляющие плоскости).

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

Хотя многие провайдеры услуг являются членами MSF, пока никто из них не выдвигал требование соответствия MSF в качестве условия приобретения аппаратного обеспечения. Не ясна ситуация и с поддержкой MSF американскими операторами. Компания MCI/WorldCom участвовала в создании MSF, а SBC Communications и Verizon присоединились к ней вместе с некоторыми другими региональными телефонными компаниями. Между тем, многие операторы по-прежнему не спешат заявлять о своей поддержке. Учитывая размер американского рынка и его роль в стимулировании разработки аппаратного обеспечения, производители начнут предлагать оборудование, соответствующее MSF, не раньше, чем его станут достаточно активно поддерживать американские операторы.

КТО И КОГДА?

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

Когда же это произойдет? Все зависит от соглашения о реализации коммутации. Если оно будет развиваться прежним образом, т. е. ориентируясь на надмножество VSI для стандартов GSMP от Cisco, то по крайней мере 50 операторов будут иметь MSF-совместимые сети. Эти первые реализации на рынке приведут к быстрому росту доверия к MSF со стороны других операторов и гарантируют поддержку Cisco. Если развитие соглашения пойдет в ином направлении, возможно, придется долго ждать, прежде чем MSF накопит критическую массу.

Поддержка операторами подхода, предложенного Cisco, не обязательно станет массовой. VSI не реализован в обобщенных сетях, которые применяются для передачи голоса и данных в Соединенных Штатах Америки, хотя используется в виртуальной частной сети IP корпорации AT&T. Успех VSI на рынке США может зависеть от успеха Cisco среди местных телефонных компаний или от их желания потребовать соответствия MSF в качестве обязательного условия приобретения перспективного оборудования для передачи данных по технологии ATM.

Сейчас прорабатываются возможные решения на базе MSF. По крайней мере, один из членов MSF, региональная телефонная компания Verizon, собирается предложить междугородные сервисы. Как предполагается, в начале 2002 г. Verizon получит разрешение на предоставление таких услуг в последнем из обслуживаемых ею крупных и плотно населенных регионов — в Нью-Джерси. Это позволит Verizon использовать достаточно протяженные соединения в рамках одного региона, чтобы оправдать создание сети для предоставления услуг передачи голоса и данных внутри области локального доступа и передачи (Local Access and Transport Area, LATA). Учитывая текущее состояние рынка, Verizon намерена осуществить это с помощью технологии ATM, и архитектура MSF может оказаться важным фактором при выборе продукта.

Развитие сетей региональными телефонными компаниями способны стать тем тестом, который определит рыночные перспективы MSF. Сейчас Америка переживает период ограниченных инвестиций в сети, что серьезно влияет на прибыль производителей оборудования. Вместе с тем, правительство начинает осуществлять финансовую поддержку инвестиций для облегчения процесса расширения инфраструктуры компаний. Будет ли способствовать эта государственная поддержка и издание соответствующих указов, например о выходе местных телефонных компаний на рынок дальней связи, финансовым вложениям в новые сети прежде, чем MSF сможет направить их в общепринятые соглашения о реализации? Сети дальней связи региональных операторов могли бы продемонстрировать преимущества таких аспектов MSF, как VoP и управление коммутатором, а также проиллюстрировать принципы организации мультисервисных сетей. Но пока неизвестно, продолжат ли телефонные компании продвигать MSF хотя бы еще в течение нескольких месяцев.

Вопрос о том, кто выиграет или проиграет от внедрения MSF, имеет критически важное значение для оценки долговременных перспектив этого подхода. Десятилетиями стандарты рассматривались как способ поддержки открытого рынка с активной конкуренцией и ограничения рыночных инноваций. Не случится ли так, что сверхстандарт, наподобие разрабатываемого MSF, ограничит возможности производителей в предложении решений, выделяющихся на фоне других продуктов? Будет ли он полезен новым компаниям в той же степени, как полезен тем, кто уже утвердился на рынке? Список производителей-членов MSF напоминает отраслевой справочник «Кто есть кто». В частности, в него входят Alcatel, Cisco, Lucent Technologies, Marconi и Nortel Networks, а также молодые компании: Calix, Mahi Networks и General Bandwidth. Чем руководствуются эти компании при поддержке данного форума: финансированием со стороны операторов, попыткой открыть новые возможности для себя или стремлением к реальному прогрессу?

Cisco и Marconi активно работают над поддержкой оболочки MSF в обширных приложениях мультисервисных сетей. Cisco удалось достичь особых результатов в развертывании сетей, которые, возможно, не полностью поддерживают стандарты MSF, но соответствуют ему на уровне сетевой архитектуры. Если стандарты MSF действительно будут приняты, то Cisco, скорее всего, окажется в выигрыше благодаря успеху своих VSI.

Главная задача — «добиться действительно широкого распространения» MSF. В конечном итоге судьбу MSF, вероятно, решит рынок. Если операторы и их пользователи будут настаивать на гибких, тактических, недорогих сервисах, внедрение оболочки MSF почти неизбежно. Если же давление со стороны общественности и покупателей окажется недостаточным, то противодействие производителей может помешать распространению MSF. А такой сценарий возможен, поскольку отрасль все еще переживает неудачу с вопросом о конвергенции и озабочена последствиями ужасных событий сентября 2001 г. Операторов в 2002 г. больше всего станет волновать новый виток конкурентной борьбы между традиционными операторами местной связи (Incumbent Local Exchange Carriers, ILEC) и владельцами линий дальней связи (Interexchange Carriers, IXC), что вряд ли будет способствовать обсуждению целей MSF. Не затеряются ли эти цели в суете?

Мы так не думаем. SONET/SDH добилась успеха благодаря тем, кто ее поддержал; MSF имеет такую же поддержку. Вдобавок, вне зависимости от того, какой будет судьба MSF, ее архитектуру, вероятно, ждет в будущем большая популярность. Движущие силы бизнеса и другие факторы, влияющие на развитие рынка, требуют намного больших возможностей от сетей, чем способны предоставить старые, монолитные, ориентированные на конкретные службы структуры. Не зависящая от сервиса оптическая технология по мере ее развертывания потребует переосмысления принципов организации сети. MSF предлагает, вероятно, единственный логичный способ для решения такой задачи. В конечном итоге сети операторов и даже корпоративные сети будут отражать подход MSF, точно так же как SONET/SDH когда-то способствовала внедрению оптических сетей. Это всего лишь вопрос времени.

Ресурсы Internet

Форум мультисервисной коммутации (MSF) предлагает исчерпывающий обзор архитектуры MSF и ее планов по адресу: http://www.msforum.org/techinfo/ msf_roadmap_2001.ppt.

Обширная информация об универсальном протоколе управления переключением (GSMP) представлена на Web-сайте IETF http://www.ietf.org/ids.by.wg/gsmp.html.

Более подробную информацию о протоколе Media Gateway Control Protocol (MGCP) можно найти по адресу: http://www.networkmagazine.com/ article/NMG20001004S0013.