Сквозная ATM-парадигма для сетей
ATM на настольных станциях имеет несколько преимуществ. Во-первых, способность ATM гарантировать для приложений качество обслуживания (QoS) обеспечивает сквозную передачу критичного к задержкам трафика типа видео или голоса. Будучи технологией передачи данных, ATM не только может поддерживать "приложения завтрашнего дня", но и эффективно справляется с сегодняшними задачами. Пользователи задаются двумя основными вопросами - как будут формироваться распределенные сети на базе ATM и какие шаги нужно предпринять, чтобы быть готовым к переходу? Есть три разных варианта включения ATM в архитектуру межсетевого взаимодействия для современных и будущих приложений:
Поскольку использование 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 через распределенную сеть:
В первых двух вариантах ATM-коммутаторы принадлежат пользователю и должны выполнять все операции по преобразованию адресов (логические адреса, известные приложениям, конвертируются в реальные адреса ATM). В последнем варианте может потребоваться преобразование адресов оператором или, по крайней мере, использование архитектуры, поддерживающей соединений частных сетей через публичные. Одна из таких архитектур обеспечивается протоколом NHRP (маршрутизация в следующий интервал), предложенным IETF. Поскольку элементы протокола NHRP включены в базовую архитектуру стандарта ATM Forum MPOA, очевидно, что MPOA будет поддерживать управление адресами в больших сетях ATM, подключенных к системам общего пользования.
В долгосрочной перспективе ATM может полностью заменить технологии ЛВС и системы межсетевого взаимодействия в их современном виде. Сети на базе коммутаторов, в результате, будут значительно более гибкими, нежели связанные между собой ЛВС. Стоимость таких решений также может оказаться меньше. Многие пользователи верят в перспективность ATM и даже неизбежность успеха этой технологии. Однако переход к использованию ATM тормозится высокими ценами на оборудование и сложностью его использования.
