ATM на настольных станциях имеет несколько преимуществ. Во-первых, способность ATM гарантировать для приложений качество обслуживания (QoS) обеспечивает сквозную передачу критичного к задержкам трафика типа видео или голоса. Будучи технологией передачи данных, ATM не только может поддерживать "приложения завтрашнего дня", но и эффективно справляется с сегодняшними задачами. Пользователи задаются двумя основными вопросами - как будут формироваться распределенные сети на базе ATM и какие шаги нужно предпринять, чтобы быть готовым к переходу? Есть три разных варианта включения ATM в архитектуру межсетевого взаимодействия для современных и будущих приложений:
Эмуляция традиционных протоколов ЛВС с использованием оборудования ATM. В этом случае существующие приложения будут продолжать работать как раньше, а ATM-добавит к существующим протоколам новые, специально разработанные для приложений multimedia. Отметим, что слово "новые" в данном контексте отнюдь не означает, что эти протоколы еще не существуют (они скорее еще не стали общепринятыми).
Подключение сервиса ATM напрямую к интерфейсам прикладных программ, используемых сегодня, в обход традиционных протоколов нижних уровней. Для поддержки этого варианта потребуется разработка новых API.
Использование новых API для "новых" приложений и эмуляция традиционных протоколов для существующих приложений.
Поскольку использование ATM обычно начинается с нескольких станций, которым требуются multimedia-приложения, требуется обеспечить эмуляцию традиционных протоколов ЛВС в сетях ATM. Это позволяет обеспечить надежное взаимодействие между новыми станциями на базе ATM и традиционными ЛВС. Для эмуляции ЛВС в системах на базе ATM (ATM LAN emulation) предложены два варианта - ATM Forum LAN Emulation (LANE) и RFC 1577. Говоря здесь об эмуляции, мы имеем в виду оба варианта.
Как LANE, так и RFC 1577 основаны на допущении что пользователи ATM применяют адаптеры, поддерживающие интерфейс ATM UNI. Поскольку этот интерфейс располагается со стороны пользователя, его иногда называют "Private UNI"; существует набор стандартов, определяющих данный интерфейс. Стандарты Private UNI существуют для скоростей 25 Мбит/с (по медному кабелю), 100 Мбит/с (оптический кабель)и 155 Мбит/с (медь и оптика). Оба стандарта эмуляции ЛВС предполагают также, что пользователи подключены к коммутатору ATM. Некоторые ATM-коммутаторы поддерживают также станции других типов (не ATM). Такие коммутаторы обеспечивают взаимодействие между ЛВС Ethernet и token ring и сетями ATM. Коммутаторы также поддерживают порты (для подключения станций и серверов) и транки (для соединения коммутаторов ATM или подключения к магистральным коммутаторам) ATM. Интерфейс между коммутаторами основан на UNI, но включает дополнительно специальные сообщения для маршрутизации и управления состоянием маршрутов. ATM Forum называет этот интерфейс Private Network-to-Network Interface или P-NNI.
Эмуляция ЛВС во всех вариантах состоит из двух программных частей - функции клиента используются на конечных системах, подключенных к эмулируемым ЛВС, а функции сервера - реализуются в каждой группе клиентских станций. Группа клиентов и связанный с ней сервер называются эмулируемой ЛВС (Emulated LAN или ELAN).
Протоколы ЛВС являются многоуровневыми и, следовательно, любой стандарт, обеспечивающий взаимодействие традиционных ЛВС и ATM должен обеспечивать поддержку соответствующих уровней. В этом вопросе существующие стандарты эмуляции ЛВС существенно различаются. ATM LANE (стандарт ATM Forum) предназначен для эмуляции протоколов канального (MAC/LLC) уровня. Поскольку этот протокол занимает самый нижний для ЛВС уровень, LANE можно использовать со всеми протоколами ЛВС вышележащих уровней, включая TCP/IP, NetWare SPX/IPX, IBM SNA/LLC2. RFC 1577, с другой стороны, работает на сетевом уровне (уровень 3) и предназначен для протокола TCP/IP.
Оба варианта эмуляции ЛВС похожи по принципам работы, несмотря на различие уровней. При организации ATM ЛВС клиентские системы пытаются вступить в контакт с сервером и зарегистрировать адресную информацию, которая содержит адрес ATM, а также адреса канального и сетевого уровней. Сервер строит каталог адресной информации для последующего использования. По завершении регистрации клиенты и серверы переходят в режим ожидания пользовательского трафика.
Пользовательские программы, работающие на клиентских и серверных системах, функционируют в среде эмуляции ЛВС как в обычных средах традиционных локальных сетей и только коммуникационные драйверы нижних уровней связаны с ATM. Когда программа генерирует сообщение, это сообщение передается вниз по стеку протоколов программам ATM, прибывая к ним в форме дейтаграммы или сообщения без организации соединения на уровне два (канальном) или уровне 3 (сетевом) в зависимости от способа эмуляции ЛВС. Программы ATM должны обеспечить эмуляцию ЛВС.
Если между отправителем и получателем будет существовать виртуальное устройство, дейтаграммы можно просто помещать в это виртуальное устройство и передавать получателю в исходной форме (дейтаграмма) для обработки на станции получателя программами ATM и приложением. Фактически, каждый клиент ATM поддерживает таблицу адресов канального и сетевого уровня, а же идентификаторов виртуальных устройств ATM (VPI/VCI). Если адрес получателя найден в таблице, дейтаграмма передается соответствующему виртуальному устройству. Проблема возникает когда адрес получателя не найден - в этом случае в игру вступает сервер эмуляции ЛВС.
Клиентская система, не имеющая виртуального устройства ATM, должна организовать его, но дейтаграмма является сообщением ЛВС и не содержит ATM-адреса получателя. Для получения этого адреса клиент посылает сообщение своему серверу, указывая получателя дейтаграммы с помощью адреса сетевого и/или канального уровня и запрашивая соответствующий адрес ATM. Сервер сообщает адрес, после чего клиент организует коммутируемое соединение ATM SVC с адресатом, в которое направляется поток дейтаграмм.
Сервер также обеспечивает поддержку широковещательного и неадресованного (broadcast and unknown) трафика для клиентов, рассылающих широковещательные и групповые (multicast() дейтаграммы. Сервер в таких случаях пересылает принятые дейтаграммы всем зарегистрированным клиентам. Перед организацией SVC клиент может также использовать режим "broadcast and unknown" для рассылки дейтаграмм адресатам, для которых адреса ATM еще не получены.
Устройства традиционных ЛВС должны обмениваться данными со станциями ATM, работающими в эмулируемых ЛВС; коммутаторы обеспечивают функции proxy-клиента от имени станций традиционных ЛВС (не ATM). В этом случае станция ATM, вызывающая станцию ЛВС будет получать от сервера адрес proxy-клиента и организовывать SVC по этому адресу. Proxy-клиент будет в этом случае играть роль моста или маршрутизатора для передачи дейтаграмм нужной станции. На практике такое использование эмуляции является преобладающим, поскольку большинство настольных станций по-прежнему используют Ethernet или token ring.
Это может выглядеть как попытка создания всемирной "плоской" сети, но это не так. RFC 1577 задает ограничение на размер доменов эмуляции ЛВС - не более одной IP-подсети на домен. ATM Forum LANE не содержит такого ограничения, но практический размер домена устанавливается числом генерируемых многоадресных сообщений (с ростом этого числа растет нагрузка на сервер и клиентов). В действительности LANE представляет собой мост, а широковещательный и групповой трафик всегда является ограничивающим фактором для сетей на базе мостов.
Как связать между собой эмулируемые домены ЛВС? Лучшим способом является использование коммутаторов ЛВС. Поскольку коммутатор может одновременно работать с ATM LANE и дейтаграммами традиционных ЛВС, он может обеспечивать связь эмулируемых доменов (как подсетей IP или сегментов ЛВС).
Проблема возникает при использовании маршрутизаторов для соединения устройств ATM, использующих multimedia-приложения. Маршрутизаторы, как устройства, работающие без организации соединений, не могут обеспечивать гарантии качества обслуживания (QoS), предлагаемой коммутаторами ATM. Таким образом, маршрутизатор между двумя станциями ATM существенно ограничивает возможности связи между этими станциями (до уровня станций традиционных ЛВС). Решения на базе коммутаторов позволяют сохранить гибкость и скорость ATM.
Естественные соединения ATM требуют коммутируемого пути между адресатом и отправителем. Если оба устройства подключены к одному коммутатору, проблем не возникает. Также просто организовать связь между устройствами, использующими услуги одного оператора или коммутаторы одного производителя. При соединении устройств в среде с разнотипным оборудованием может потребоваться использование PNNI для организации мостов между двумя или несколькими коммутаторами ATM и в тех случаях, когда ATM-соединение организуется через распределенную сеть (WAN).
Существует три варианта организации "реальных" соединений ATM через распределенную сеть:
Выделенная цифровая линия от оператора (T3, например) служить транком между двумя коммутаторами ATM - эти коммутаторы будут генерировать ячейки, обеспечивать сигнализацию ATM и поддерживать потоки трафика. Фактически, это вариант частной сети ATM.
Оператор ATM может обеспечивать виртуальный путь между парой коммутаторов. В этом случае оператор передает ячейки и принимает участие в управлении трафиком ATM, но соединенные между собой устройства управляются виртуальными устройствами как при использовании соединения по выделенной линии.
Может использоваться предоставляемое оператором коммутируемое соединение ATM SVC.
В первых двух вариантах ATM-коммутаторы принадлежат пользователю и должны выполнять все операции по преобразованию адресов (логические адреса, известные приложениям, конвертируются в реальные адреса ATM). В последнем варианте может потребоваться преобразование адресов оператором или, по крайней мере, использование архитектуры, поддерживающей соединений частных сетей через публичные. Одна из таких архитектур обеспечивается протоколом NHRP (маршрутизация в следующий интервал), предложенным IETF. Поскольку элементы протокола NHRP включены в базовую архитектуру стандарта ATM Forum MPOA, очевидно, что MPOA будет поддерживать управление адресами в больших сетях ATM, подключенных к системам общего пользования.
В долгосрочной перспективе ATM может полностью заменить технологии ЛВС и системы межсетевого взаимодействия в их современном виде. Сети на базе коммутаторов, в результате, будут значительно более гибкими, нежели связанные между собой ЛВС. Стоимость таких решений также может оказаться меньше. Многие пользователи верят в перспективность ATM и даже неизбежность успеха этой технологии. Однако переход к использованию ATM тормозится высокими ценами на оборудование и сложностью его использования.
Эволюция
Большинство организаций входят в одну из трех категорий с точки зрения перспектив использования ATM:
Организации, которые используют приложения сильно выигрывающие в результате перехода на ATM. Примером компаний этого класса являются организации здравоохранения, брокерские фирмы с большими потоками коммерческой информации, компании, занимающиеся производством видеопродукции.
Организации, которые могут перейти на ATM в результате агрессивной ценовой политики поставщиков услуг.
"Оборонительная стратегия" Организации этого типа знают, что технология ATM обеспечит им целый ряд преимуществ, но пока не планируют использовать данную технологию.
Для любой компании первым правилом эволюции ATM является предотвращение потери средств, вложенных на этапе оценки технологии ATM . Это означает, что при покупке сетевого оборудования сегодня нужно принимать во внимание возможность использования этого оборудования в будущей сети на базе ATM. Если от закупаемого сегодня оборудования придется потом отказываться, лучше сразу поискать другое решение.
Это правило наиболее ярко проявляется при выборе сетевых коммутаторов. Приобретаемые сегодня устройства должны обеспечивать возможность использования в системах на базе ATM. Минимальным требованием является возможность использования ATM-транков для связи между коммутаторами. Желательно также иметь в коммутаторе порт (или гнездо для его установки), позволяющий в будущем подключить настольные станции с интерфейсом ATM. Маршрутизаторы, пока не будет найдено более эффективного решения для ATM, должны использоваться как краевые устройства, обеспечивающие возможность подключения устройств традиционных ЛВС к сетям ATM. По крайней мере, такие устройства должны иметь интерфейс proxy-клиента эмуляции ЛВС.
Организации с "оборонной" стратегией, отмеченные в категории три, могут счесть наличие транкового порта ATM в коммутаторе достаточной для ближайших перспектив использования ATM (использовать не будем, но на всякий случай возьмем).
Компании, планирующие для ATM ключевую роль в своей сети, должны выбирать коммутаторы с портами ATM для подключения настольных станций. ATM обеспечивает широкий диапазон скоростей для подключения настольных станций - от 25 до 155 Мбит/с. ATM25 работает с кабельными системами категории 3 - 5 и может использоваться вместо token ring или 10BaseT для станций с высоким уровнем сетевых запросов.
Снижение цен на оборудование ATM для настольных станций играет важную роль, поскольку сегодня приложений, не способных обойтись без возможностей ATM, еще не так много. Скорей всего, пользователи первых станций ATM будут работать с одним из рассмотренных выше вариантов эмуляции ЛВС и большинство приложений будут скорее использовать эмуляцию, нежели естественные ATM API. Адаптеры ATM и коммутационные технологии должны удовлетворять потребности пользователей в течение 5 -8 лет, а скорость отказа от традиционных технологий ЛВС будет в значительной мере определяться темпами расширения числа видеоприложений.
Понимание того, что большинство пользователей не работает с приложениями, требующими возможностей ATM зачастую служит тормозом внедрения ATM, поскольку никому не хочется тратить деньги га приобретение неиспользуемых возможностей. Использование ATM только на части станций избавит от ненужных расходов на модернизацию сети.
Если вы предполагаете начать использование ATM в настольных станциях в течение ближайшей пары лет, вам нужно выбирать коммутаторы с учетом этой перспективы. Коммутаторы должны иметь порты для подключения станций и магистральны порты 155 и 622 Мбит/с для соединения коммутаторов. Порты ATM должны поддерживать эмуляцию ЛВС. Важно также обратить внимание на перспективы реализации в коммутаторах поддержки таких протоколов, как RFC 1577 и MPOA. наконец, транковый интерфейс для связи с другими коммутаторами должен поддерживать стандарт PNNI.
Если оператор ATM предлагает свои услуги по разумным ценам или ваша организация планирует организовать собственную магистраль ATM, следует оценить потребности до покупки оборудования ATM. Остается ответить на вопрос "Какой тип ATM-сервиса использовать?"
Публичные или частные системы ATM будут нормально поддерживать подключение устройств frame relay через специальные преобразователи (ATM DSU/CSU). Если ваше соглашение с оператором ATM требует покупки такого оборудования для подключения других источников трафика к ATM, может оказаться более эффективной реализация сервиса frame relay на базе существующих коммутаторов и их связь с ATM через краевые устройства.
Если для подключения связывающих сети устройств (типа маршрутизаторов) к ATM вам потребуется покупать дополнительные устройства, лучше будет купить интерфейс ATM для коммутатора. Этот интерфейс можно будет использовать и после перехода на ATM, тогда как устройства DSU/CSU после такого перехода станут просто ненужными. Существует три варианта подключения ATM к коммутаторам:
Естественная форма ATM (ячейки) с прямым подключением цифрового транка ATM (обычно T1 или T3) к маршрутизатору. Этот тип интерфейса может поддерживать все типы сервиса ATM (включая multimedia). Такой вариант целесообразно выбирать при планировании перехода от маршрутизаторов к коммутаторам ATM.
DXI-форма ATM - интерфейс на основе кадров, поддерживающий только транспортный сервис ATM, ориентированный на передачу данных. Такой тип подключения хорош для систем, где не планируется замена маршрутизаторов на коммутаторы ATM. Выбирая этот вариант, следует помнить, что некоторые операторы ATM не поддерживают DXI-сервис и может потребоваться покупка ATM DSU/CSU для преобразования DXI в ячейки ATM.
Интерфейс F-UNI, который представляет собой вариант интерфейса frame relay с поддержкой сигнализации ATM. Этот вариант пока распространен недостаточно широко, но может обеспечить просто и недорогой переход для маршрутизаторов, которые уже поддерживают frame relay.
При любом варианте перехода на ATM в первую очередь возникает задача организации магистралей. Организация компактных магистралей (collapsed backbone) без использования технологии ATM в таком случае будет весьма рискованным решением. Магистральные технологии при переходе на ATM приходится менять в первую очередь. Наиболее критичным при переходе на ATM будет первый шаг в сторону от традиционной коммутации ЛВС. В системах коммутации ЛВС без ATM-транков магистрали не используют технологии ATM и, следовательно, модернизация магистралей будет достаточно рискованным шагом. В идеальном случае коммутаторы ЛВС должны поддерживать магистрали ATM и других типов (например, FDDI).
Переход приложений на ATM будет постепенным. На настольных станциях ATM будет поначалу использоваться для эмуляции ЛВС и работы с набором традиционных приложений ЛВС. По мере расширения инфраструктуры ATM станет возможным связать большие группы пользователей в "чистые" сети ATM. Это позволит использовать специальные приложения, рассчитанные на качество обслуживания ATM (видео, multimedia и т.п.) или упростить работу с традиционными потоками данных за счет более высокой производительности ATM.
ATM, по мере реализации, будет делать сеть компании более гармоничной - сначала на уровне магистралей, а потом и для настольных систем. Полный переход на ATM наверняка будет определяться темпами снижения цен на порты для подключения настольных станций и адаптеры, а также реализацией поддержки возможностей в прикладных программах. Использование единой технологии для организации магистралей, подключения настольных станций и распределенных сетей может обеспечить, в конечном итоге, существенную экономию.
В долгосрочной перспективе ATM должна стать единой архитектурой внутрикорпоративных и межкорпоративных коммуникаций. Коммутируемые виртуальные устройства, используемые настольными системами могут быть расширены за счет поддержки соединений SVC операторами публичных сетей, делая ATM универсальной технологией multimedia-сетей. Протоколы типа NHRP являются средством обеспечения универсальной связи, но в конечном итоге набор протоколов ATM для multimedia будет, по-видимому, основан на службах каталогов.
Степень воздействия универсальных multimedia-коммуникаций на бизнес достаточно трудно прогнозировать с учетом отсутствия альтернативных вариантов. Несомненно, ATM будет играть значительную роль в коммерции, здравоохранении, обучении за счет систем распространения информации. Системы ATM основаны на экономичной технологии мультиплексирования, позволяющей преодолеть барьеры, связанные с взрывным характером трафика во многих приложениях.
С учетом всех этих влияний технология ATM остается привлекательной реализацией и очевидно, что множество пользователей будут готовы перейти на ATM в ближайшем будущем. Это означает, что и ваша организация может быстро начать работу с ATM и расширять использование этой технологии для повышения эффективности работы.
