Подходы к интеграции неоднородных сетей. Часть 2.
технология LAN Emulation для согласования сетей ATM и традиционных сетевых технологий
Назначение и общие принципы работы
Появление новой технологии АТМ потребовало решения задачи согласования этой технологии с уже существующими традиционными технологиями локальных сетей, такими как Ethernet или Token Ring.
Для решения этой задачи в принципе могут быть использованы все обсуждавшиеся выше подходы к организации работы неоднородных сетей — мультиплексирование, трансляция и инкапсуляция протоколов. Однако мультиплексирование редко применяется для протоколов физического и канального уровней (к которым относится протокол АТМ), так как при этом требуется наличие нескольких сетевых адаптеров в каждом компьютере.
Гораздо чаще для согласования протоколов канального уровня используется трансляция с помощью таких промежуточных устройств, как мосты, коммутаторы и маршрутизаторы. Однако мосты и коммутаторы способны выполнять трансляцию только близких технологий, например, Ethernet и FDDI или Ethernet и Token Ring, а задача трансляции существенно отличающихся технологий локальных и глобальных сетей для устройств этого типа является слишком сложной. Примером таких "плохо совместимых" пар протоколов могут служить Х.25 и Ethernet или frame relay и Ethernet. Поскольку технология ATM близка к технологиям территориальных сетей и плохо совместима с традиционными канальными протоколами локальных сетей, то в этом случае трансляционные возможности мостов и коммутаторов также оказываются недостаточными.
Маршрутизаторы же умеют выполнять трансляцию существенно отличающихся протоколов, используя для этого общий протокол сетевого уровня для всех согласуемых сетей. Для обеспечения совместимости ATM с протоколами канального уровня локальных сетей разработана спецификация Classical IP (RFC 1577), в которой в качестве объединяющего протокола сетевого уровня определен протокол IP. Такое решение хорошо работает, когда локальные сети объединяются с территориальной сетью АТМ, применение же этого подхода в случае, когда технология АТМ используется для построения локальной сети, не всегда оказывается эффективным. Во-первых, необходимость использования маршрутизаторов для локальных сетей не всегда является экономически оправданной. Во-вторых, не все локальные сети поддерживают протокол сетевого уровня — так, например, функции маршрутизации отсутствуют в часто используемом стеке SMB/NetBIOS.
Поэтому возникла необходимость в создании технологии объединения сетей АТМ и традиционных локальных сетей без привлечения маршрутизаторов и протоколов сетевого уровня. Такой технологией и является технология LAN Emulation (LANE), разработанная организацией ATM Forum.
Эта спецификация использует инкапсуляцию кадров канальных протоколов локальных сетей, таких как Ethernet или Token Ring, в ячейки АТМ. Использование инкапсуляции в спецификации LAN Emulation несколько отличается от ее традиционного применения.
Обычно инкапсуляция обеспечивает связь двух сетей одной технологии через промежуточную сеть другой технологии. При этом узлы промежуточной сети недоступны конечным узлам объединяемых сетей, и промежуточная сеть играет роль транзитной сети. LAN Emulation с помощью инкапсуляции решает не только традиционную задачу связи локальных сетей через транзитную сеть АТМ, но и общую задачу связи всех узлов составной сети — связи между узлами локальных сетей и внутренними узлами АТМ-сети.
Рассмотрим последовательно решение этих двух задач, причем для определенности будем предполагать, что сеть АТМ используется для соединения сетей Ethernet.
Объединение локальных сетей через транзитную АТМ-сеть
Итак, пусть сеть ATM используется только в качестве транзитной сети. Сети Ethernet подключаются к сети коммутаторов АТМ с помощью пограничных устройств, названных в спецификации LAN Emulation АТМ-LAN конверторами. Такой конвертор должен иметь ATM-порт, с помощью которого он подключается к АТМ-сети, а также некоторое количество портов для подключения локальных сетей традиционных технологий. Конвертор имеет АТМ-адрес для взаимодействия с другими конверторами по сети АТМ. Кроме того, конвертор должен иметь информацию о МАС-адресах всех узлов каждой из локальных сетей, которые он присоединяет к сети АТМ. Конвертором может быть любое устройство локальной сети, но наиболее подходящим устройством для выполнения этих функций является коммутатор локальной сети, так как он имеет таблицу МАС-адресов всех устройств сети, которые обмениваются через него данными. Поэтому будем далее использовать термины АТМ-LAN конвертор и ATM-LAN коммутатор как синонимы.
В каждый АТМ-LAN коммутатор встроен протокол LAN Emulation (рисунок 2.5), в задачу которого входит передача принятого коммутатором МАС-кадра через АТМ-сеть другому ATM-LAN коммутатору. Так как к АТМ-сети может быть подключено несколько локальных сетей, то при получении из локальной сети кадра с МАС-адресом назначения ATM-LAN коммутатор должен решить, к какому из остальных ATM-LAN коммутаторов относится данный МАС-адрес.
Таким образом, коммутатор для принятия решения о передаче кадра оперирует с двумя таблицами — с локальной, которая устанавливает соответствие МАС-адресов его локальной сети локальным портам, и с транзитной, которая содержит для каждого МАС-адреса составной сети АТМ-адрес пограничного коммутатора. Спецификация LAN Emulation не определяет конкретный вид таблиц ATM-LAN конверторов. Один из возможных вариантов этих таблиц приведен на рисунке 2.6.
Если АТМ-LAN коммутатор в результате просмотра адресных таблиц видит, что кадр нужно передать через АТМ-сеть другому ATM-LAN коммутатору, то он с помощью стека протоколов АТМ устанавливает виртуальное соединение (Virtual Channel Connection, VCC) с этим коммутатором, а затем передает по нему кадр в форме потока ячеек АТМ.
Особенностью инкапсуляции кадров в спецификации LAN Emulation является то, что кадр не упаковывается целиком в ячейку АТМ, а ввиду очень малого размера ее поля данных (48 байт) разбивается на фрагменты, которые затем инкапсулируются в последовательность АТМ-ячеек. Разбиение (сегментация) кадра и последующая его сборка осуществляются стандартными средствами стека АТМ, реализованного в ATM-LAN конверторе.
Для передачи трафика локальных сетей через сеть АТМ выбран класс АТМ-сервиса с неопределенной битовой скоростью, что хорошо соответствует алгоритмам работы протоколов локальных сетей, когда конечному узлу не дается никаких гарантий относительно выделяемой ему пропускной способности. Этот класс сервиса реализован в сетях АТМ подуровнем AAL5 (ATM Adaptaton Layer 5), принимающим запросы на установление соединений от протоколов верхних уровней. Остальные классы сервиса сетей АТМ, гарантирующие некоторую часть пропускной способности своим абонентам, в спецификации LAN Emulation версии 1.0 не используются, хотя потребность в них может возникать при работе в локальной сети приложений реального времени. Эти возможности ожидаются в следующих версиях спецификации LAN Emulation.
Отдельной задачей является автоматическое построение транзитных адресных таблиц АТМ-LAN коммутатора. Поскольку сети АТМ, как и большинство территориальных сетей, не поддерживают широковещательность, то обнаружить через сеть АТМ пограничные коммутаторы с помощью широковещательных запросов (как это делают, например, клиенты и серверы сетей NetWare) невозможно.
Ручное задание АТМ-адресов пограничных коммутаторов может оказаться обременительным занятием для администратора, если таких коммутаторов много и их набор часто претерпевает изменения, что характерно для локальных сетей.
Для автоматического построения транзитных адресных таблиц спецификация LAN Emulation предлагает использовать централизованный подход, то есть возложить решение этой задачи на сервер, присоединенный к сети АТМ (рис. 2.7).
Этот сервер носит название LAN Emulation Server — LES. Та часть протокола спецификации LAN Emulation, которая работает в ATM-LAN коммутаторе, называется LAN Emulation Client — LEC. При своей инициализации LEC АТМ-LAN коммутатора сообщает серверу LES свои МАС- и ATM-адреса. Затем LEC регистрирует в LES все МАС-адреса узлов, которые он узнает при изучении своей локальной сети. Таким же образом поступают все пограничные ATM-LAN коммутаторы, поэтому в сервере LES накапливается общая таблица соответствия МАС-адресов узлов локальных сетей АТМ-адресам их пограничных коммутаторов.
Для взаимодействия с сервером LES каждый клиент LEC устанавливает прямое виртуальное соединение VCC с этим сервером, называемое Control Direct VCC. Это соединение устанавливается еще на стадии присоединения (Join) клиента LEC к эмулируемой сети. Под эмулируемой сетью понимается вся совокупность локальных сетей, взаимодействующих друг с другом через данный сервер LES и пограничные коммутаторы таким образом, как будто они работают в локальной сети, объединенной с помощью обычных повторителей, мостов и коммутаторов.
Каждый ATM-LAN коммутатор должен изначально знать только один адрес — АТМ-адрес сервера адресов LES, чтобы установить с ним виртуальное соединение. Теперь при приходе кадра с неизвестным МАС-адресом пограничный коммутатор может послать запрос серверу LES об АТМ-адресе коммутатора, обслуживающего локальную сеть, в которой имеется узел с данным МАС-адресом. Протокол передачи запроса на разрешение MAC-адреса и получения на него ответа является частью спецификации LAN Emulation и называется LE_ARP (LAN Emulation Address Resolution Protocol).
При получении LE_ARP-запроса сервер LES просматривает свои адресные таблицы, и если находит там зарегистрированный искомый МАС-адрес, то посылает LE_ARP-ответ, в котором указывает АТМ-адрес пограничного ATM-LAN коммутатора, которому нужно переслать кадр с данным МАС-адресом. Если же искомый МАС-адрес отсутствует в таблице сервера, то сервер LES пересылает LE_ARP-запрос всем LEC, присоединившимся к эмулируемой сети.
Пересылать LE_ARP-запрос можно по очереди каждому клиенту LEC по тем индивидуальным виртуальным соединениям Control Direct VCC, которые были созданы при присоединении LEC к LES, но такой способ будет работать медленно при большом числе LEC. Для ускорения работы LES использует специфический механизм мультивещательности, поддерживаемый сетями АТМ. Этот механизм позволяет какому-либо узлу АТМ-сети, называемому корнем, устанавливать виртуальное соединение "один-ко-многим" (point-to-multipoint) и одновременно передавать одни и те же данные всем остальным узлам соединения, называемым листьями.
При этом узлы-листья могут посылать данные только узлу-корню, а между собой обмениваться данными по соединению такого вида им запрещено.
Сервер LES при присоединении к эмулируемой сети нового клиента LEC сразу же добавляет последнего к мультивещательному соединению в качестве нового листа. Такое соединение называется Control Distribute VCC и служит для одновременного распространения LE_ARP-запроса всем LEC эмулируемой сети. Тот LEC, который опознал в запросе МАС-адрес обслуживаемой сети, генерирует LE_ARP-ответ, в котором указывает свой АТМ-адрес. Получив LE_ARP-ответ, сервер LES распространяет его также по мультивещательному VCC, чтобы все LEC сети могли бы кэшировать данную информацию для будущего использования.
После получения информации об АТМ-адресе соответствующего ATM-LAN коммутатора LEC устанавливает с ним прямое виртуальное соединение Data Direct VCC, по которому начинает передавать кадры для данного МАС-адреса.
Так как в задачу спецификации LAN Emulation входит представление эмулируемой составной сети в виде функционального эквивалента традиционной локальной сети, то для конечных узлов такой сети нужно обеспечить свойство широковещательности, когда кадр, посланный с широковещательным адресом, доходит до всех узлов сети.
Эмуляцию широковещательности спецификация LAN Emulation выполняет с помощью уже описанного механизма мультивещательности "один-ко-многим". С этой целью в сети АТМ, кроме сервера LES, создается еще один сервер — Broadcast and Unknown Server, BUS. Сервер BUS организует доставку кадров с широковещательными адресами, а также кадров, ATM-адрес пограничного коммутатора которых неизвестен клиенту LEC, всем узлам эмулируемой сети. Сервер BUS имеет отдельный ATM-адрес, который сообщается сервером LES клиенту LEC при его присоединении к эмулируемой сети. Клиент LEC должен после этого установить с сервером BUS прямое виртуальное соединение Multicast Send VCC, по которому он будет пересылать кадры с широковещательными или неизвестными адресами. Сервер BUS добавляет каждого нового клиента LEC к мультивещательному соединению Multicast Forward VCC в качестве листа. Это соединение используется сервером BUS для одновременной рассылки широковещательных кадров и кадров с неизвестными адресами всем пограничным коммутаторам эмулируемой сети.
Спецификация LAN Emulation рекомендует клиентам LEC делать LE_ARP-запрос серверу LES для кадра с неизвестным адресом и, не дожидаясь ответа, сразу же отправлять этот кадр через сервер BUS. Это делается для ускорения работы эмулируемой сети, так как кадры начнут доходить до узла назначения широковещательным образом еще до того, как будет получен LE_ARP-ответ от сервера LES. После получения LE_ARP-ответа LEC перестает посылать кадры для данного МАС-адреса широковещательно, а устанавливает виртуальное соединение Data Direct VCC с конкретным ATM-LAN коммутатором (или же пользуется уже установленным ранее соединением с этим коммутатором) и передает остальные кадры с данным МАС-адресом уже по прямому каналу.
Организация нескольких эмулируемых сетей
Спецификация LAN Emulation позволяет организовать в рамках одной составной ATM-LAN сети нескольких отдельных эмулируемых сетей. Эти сети полностью отделены друг от друга, так что узлы, входящие в одну эмулируемую сеть, не получают кадры другой эмулируемой сети, какие бы типы МАС-адресов назначения ни применялись: индивидуальные, групповые или широковещательные. Такая концепция хорошо согласуется с концепцией виртуальных сетей, реализованной во многих коммутаторах традиционных протоколов локальных сетей, которые также определяются как наборы узлов сети, где локализуется весь их трафик, включая и широковещательный, вне зависимости от физического расположения узлов.
Для поддержания каждой эмулируемой сети в сети АТМ должна работать собственная пара серверов LES и BUS. АТМ-LAN конвертор может быть присоединен одновременно к нескольким эмулируемым сетям, при этом для работы с каждой сетью он имеет отдельный элемент LEC, который образует с каждым из серверов сети отдельные виртуальные соединения VCC, так что трафики эмулируемых сетей не смешиваются внутри сети АТМ. Аналогично, если два ATM-LAN коммутатора поддерживают несколько эмулируемых сетей, то для обмена данными между собой они образуют для каждой эмулируемой сети отдельное виртуальное соединение Data Direct VCC.
Для автоматического поддержания нескольких эмулируемых сетей в АТМ-сети организуется еще один центральный сервер — LAN Emulation Configuration Server, LECS. Этот сервер хранит список имен эмулируемых сетей, а также значения их основных параметров — АТМ-адреса серверов LES и BUS каждой сети, тип сети (например, Ethernet или Token Ring), максимальный размер кадра, поддерживаемого этой сетью, и т.п. Поэтому каждый LEC при инициализации должен сначала установить соединение с единственным в сети сервером LECS (он должен знать АТМ-адрес этого сервера) и получить от LECS список всех эмулируемых сетей и их параметров.
На основании полученной информации LEC должен выбрать эмулируемую сеть, к которой он желает присоединиться, и известить об этом LECS. Затем LEC выполняет процедуру присоединения к LES выбранной эмулируемой сети, регистрирует там МАС-адреса своих узлов и начинает работать с составной сетью. Протокол взаимодействия клиентской части протокола LAN Emulation, а именно LEC, с серверными частями этой спецификации LECS, LES и BUS называется LAN Emulation User-Network Interface (LUNI).
Если ATM-LAN коммутатор поддерживает со стороны локальной сети несколько виртуальных сетей, то он может отождествить каждую виртуальную сеть с эмулируемой сетью. Поэтому при регистрации МАС-адресов на сервере LES определенной эмулируемой сети коммутатор регистрирует только те МАС-адреса, которые относятся к виртуальной сети, отождествляемой с этой эмулируемой сетью.
Если все пограничные коммутаторы поддерживают несколько виртуальных сетей и администратор хочет, чтобы эти сети работали в масштабах всей составной сети, то отождествление их с определенными эмулируемыми сетями дает хороший способ передачи информации о принадлежности МАС-адреса той или иной сети между разными пограничными коммутаторами.
Спецификация LAN Emulation не определяет способа построения виртуальных сетей пограничными коммутаторами на стороне локальной сети. Эта спецификация дает только стандартный способ информирования других коммутаторов о том, какой виртуальной сети принадлежит передаваемый кадр. В составной сети кадры разных виртуальных локальных сетей передаются по разным виртуальным соединениям и поэтому не смешиваются.
Взаимодействие между разными эмулируемыми сетями в спецификации LAN Emulation не предусматривается. Для организации взаимодействия нужен маршрутизатор, который либо присоединяется к интерфейсам локальных сетей, либо подключается непосредственно к сети АТМ и, поддерживая спецификацию LAN Emulation, присоединяется к каждой из эмулируемых сетей. Маршрутизатор назначает эмулируемым сетям сетевые адреса и производит на основании этих адресов передачу пакетов между сетями.
Организация взаимодействия всех узлов составной сети
Понятно, что узлы, непосредственно присоединенные к АТМ-коммутаторам с помощью АТМ-адаптеров, могут взаимодействовать между собой и без привлечения добавочных протоколов, таких как протоколы спецификации LAN Emulation. Но в таком случае приложения и протоколы прикладного уровня (NCP, SMB, NFS или FTP) должны быть модифицированы, так как они должны научиться поддерживать интерфейс со стеком протоколов АТМ на своем узле, а также не использовать отсутствующие в протоколах АТМ широковещательные рассылки. Кроме того, АТМ-узлы не смогут взаимодействовать с узлами локальных сетей, на которых установлены традиционные стеки протоколов с канальными протоколами Ethernet, Token Ring и т.п.
Спецификация LAN Emulation позволяет превратить АТМ-узлы в узлы, подобные традиционным узлам локальных сетей. Это достигается за счет размещения в АТМ-узле программного обеспечения клиента LEC, выполняющего те же функции, что и LEC пограничных ATM-LAN коммутаторов. На АТМ-узле LEC размещается между АТМ-протоколами драйвера сетевого адаптера АТМ и протоколом LLC (рисунок 2.8) или любым другим протоколом, который рассчитан на работу с протоколом МАС-уровня локальной сети. Протокол LEC предоставляет протоколам верхних уровней того узла, на котором он работает, тот же интерфейс, что и МАС-уровень сети Ethernet или Token Ring.
В отличие от протокола LEC, работающего на ATM-LAN коммутаторе, LEC отдельного АТМ-узла представляет только один МАС-адрес — МАС-адрес данного узла. Остальные действия LEC узла ничем не отличаются от LEC коммутатора. Он точно так же соединяется с сервером LECS, получает от него список эмулируемых сетей и присоединяется к одной из сетей, регистрируя в LES этой сети пару АТМ-адрес/МАС-адрес своего узла. Для присоединения одного и того же узла к нескольким сетям на узле должны работать одновременно несколько копий LEC, по одной на каждую сеть. Сообщения, получаемые от протоколов верхних уровней, LEC узла преобразует с помощью функции SAR в поток ячеек, который передает по виртуальному соединению протоколу LEC других АТМ-узлов. Широковещательный трафик направляется узлам эмулируемой сети через сервер BUS.
Наличие МАС-адреса у узла АТМ-сети позволяет ей взаимодействовать и с узлами присоединенных локальных сетей. При этом LEC узла взаимодействует с LEC пограничного коммутатора, посылая через сеть АТМ-кадр, в котором указывает в качестве адреса назначения МАС-адрес узла локальной сети, а в качестве адреса источника — свой МАС-адрес. Пограничный коммутатор затем передает кадр в соответствии с МАС-адресом назначения и своей адресной таблицей на один из своих локальных портов. Локальный узел, получив кадр, может ответить на него обычным кадром, указав в нем МАС-адрес узла АТМ-сети.
Спецификация LAN Emulation сегодня реализована в устройствах различных типов многих производителей. Серверные части спецификации — серверы LECS, LES и BUS обычно встраиваются в АТМ-коммутаторы или корпоративные АТМ-LAN коммутаторы, а клиентские компоненты LEC — в драйверы сетевых адаптеров и ATM-LAN коммутаторы уровня отдела или рабочей группы.
Недостатки версии LAN Emulation 1.0 и пути ее совершенствования
Наличие единственного серверного элемента в сети всегда является недостатком как в отношении производительности, так и в отношении надежности сети. При большом количестве клиентов LEC трафик к коммутатору, который поддерживает серверы LES и BUS, может быть очень большим, особенно при широком использовании метода группового распространения мультимедийной информации через BUS. Отказ коммутатора, в котором работает пара LES/BUS, будет приводить к останову всей сети.
К тому же производители часто ограничивают возможности серверов LES/BUS по одновременной работе с большим количеством клиентов LEC. Так, коммутатор LANplex компании 3Com поддерживает не более 16 эмулируемых сетей, в каждой из которых должно быть не более 16 клиентов LEC. Это ограничение не такое жесткое, если речь идет о LEC, встроенных в коммутаторы, ведь в этом случае один LEC может представлять несколько сот узлов. Однако при использовании LEC в сетевых адаптерах ATM-узлов такое ограничение является существенным тормозом при создании сети с большим количеством АТМ-узлов.
Спецификация LAN Emulation не запрещает использования в сети нескольких устройств, которые выполняют серверные функции, однако и не описывает механизм их взаимодействия при тиражировании адресных таблиц и выполнении других операций.
Протоколы взаимодействия между несколькими копиями LES/BUS, поддерживающими одну и ту же эмулируемую сеть, должны быть определены в спецификации LAN Emulation 2.0.
Кроме того, версия LAN Emulation 2.0 должна определить работу эмулируемой сети при передаче трафиков различных классов сервиса, а не только класса QoS 0 с неопределенной полосой пропускания. Это необходимо для работы в сети приложений, требующих обработки их кадров в реальном времени, — приложений, организующих видеоконференции, передающих голос и т.п.
инкапсулирующая технология Data Link Switching (DLSw)
Назначение и история создания технологии
Технология Data Link Switching (DLSw) была разработана для организации связи локальных сетей, не использующих сетевые маршрутизируемые протоколы, через транзитные сети TCP/IP. Основная область применения протокола DLSw — это транзитная передача кадров протокола LLC2, используемого в локальных сетях Token Ring архитектуры SNA и в локальных сетях NetBIOS.
Протоколы подуровня LLC (Logical Link Control) разработаны комитетом 802.2 института IEEE для организации логического обмена кадрами данных между двумя конечными станциями локальной сети после того, как МАС-подуровень станции-инициатора обмена получит доступ к среде. Для уровня LLC в стандарте 802.2 определены процедуры трех типов — LLC1, LLC2 и LLC3.
Процедура LLC1 выполняет передачу кадра без предварительного установления соединения, дейтаграммным методом. Основное назначение процедуры LLC1 — это обеспечение интерфейса между МАС-уровнем и вышележащими протоколами. Многие стеки протоколов используют ненадежную процедуру LLC1 на канальном уровне, с тем чтобы обеспечить надежное соединение средствами протоколов верхнего уровня — транспортными (TCP, SPX) или прикладными (NCP).
Процедура LLC2 работает на основе установления соединения между конечными станциями. После установления соединения пересылаемые кадры нумеруются, а для обеспечения надежной доставки кадров используется механизм положительных квитанций с повторными передачами при истечении таймера ожидания квитанции. Процедура LLC2 похожа на протокол LAP-B, используемый в сетях Х.25 для соединения "точка-точка" между конечным узлом и коммутатором сети.
Процедура LLC3 похожа на процедуру LLC1. Она работает без установления соединения, но с уведомлением отправителя о доставке кадра узлу назначения.
Протокол LLC2 используется в двух типах широко распространенных сетей — архитектуры IBM SNA с протоколом Token Ring на нижнем уровне и в сетях с протоколом NetBIOS. Технология DLSw позволяет передавать трафик этих сетей через общий туннельный канал в магистральных сетях TCP/IP, используя для объединения сетей многопротокольные маршрутизаторы.
Протокол DLSw появился в результате большой работы по стандартизации множества частных схем инкапсуляции трафика SNA и NetBIOS в сети TCP/IP, предложенных различными производителями коммуникационного оборудования.
Исторически сети архитектуры SNA выполняли наиболее ответственные корпоративные приложения, такие как обработка деловых транзакций, бухгалтерский учет, поддержка продаж. Но локальные сети SNA не используют традиционные средства маршрутизации локальных сетей. В результате у многих предприятий образовались параллельные корпоративные сети, каждая со своей инфраструктурой, которые не могут разделять общие глобальные линии связи и управляться с помощью общей платформы управления.
Параллельное существование двух типов сетей — SNA и сетей, основанных на маршрутизаторах, объяснялось и техническими причинами. Трафик большинства существующих сетей SNA, то есть сетей SNA, возникших до разработки компанией IBM новой маршрутизируемой технологии APPN (Advanced Peer-to-Peer Networking), могут маршрутизироваться только с помощью специальных сетевых устройств, называемых FEP — Front-End Processors. Процессоры FEP представляют собой достаточно дорогие устройства, которые умеют маршрутизировать только трафик сетей SNA. С другой стороны, маршрутизаторы не умеют маршрутизировать традиционный (не APPN) трафик SNA, а компьютеров IBM, поддерживающих новую технологию APPN, пока еще очень немного.
С течением времени многие корпорации, имеющие разветвленные сети архитектуры SNA, стали искать пути передачи трафика SNA и NetBIOS через получающие все большее распространение глобальные сети на основе маршрутизаторов, в частности, через сети TCP/IP. Многие производители маршрутизаторов в ответ на потребности рынка предложили свои фирменные протоколы, которые разными способами инкапсулировали трафик SNA в многопротокольные магистрали. При этом использовалось два принципиально различных подхода — инкапсуляция кадров LLC2 в кадры канального уровня (например, в кадры сетей Х.25 или frame relay) и инкапсуляция кадров LLC2 в сообщения TCP — протокола транспортного уровня (рисунок 2.9).
Оба подхода имеют свои преимущества и недостатки. В первом случае избыточность служебных заголовков гораздо меньше, чем во втором. Кадры LLC2 быстрее упаковываются и извлекаются из транзитного протокола. Однако в первом случае метод может работать только тогда, когда конечные узлы объединяются транзитной сетью одной технологии, например, только сетью Х.25 или только сетью frame relay. Говорят, что первый метод — это метод "одной транзитной передачи" (one hop).
Метод инкапсуляции в пакеты TCP в этом отношении универсален — он может работать при объединении конечных узлов через большое количество транзитных сетей разных технологий — X.25, frame relay, ATM, Ethernet, если только они связаны через маршрутизаторы, поддерживающие протокол TCP/IP. Протокол DLSw образует туннель через эти сети, пронося через него кадры LLC2, упакованные в сообщения TCP.
В стандартизации второго подхода наряду с другими производителями приняла участие компания IBM. Спонсором работ выступила организация APPN Imlementators Workshop (AIW) и организованный IBM форум производителей. В конце концов протокол DLSw был принят комитетом IETF в качестве стандарта и получил номер RFC 1434. Позже этот стандарт был заменен версией RFC 1795, обратно совместимой с аппаратурой, поддерживающей RFC 1434. Однако маршрутизаторы, поддерживающие версию RFC 1795, могут оказаться несовместимыми с маршрутизаторами, поддерживающими фирменные улучшения версии RFC 1434, например, фирменную версию DLSw+ компании Cisco.
Принципы работы протокола DLSw
Для организации взаимодействия узлов по протоколу DLSw необходимо наличие в каждой из связываемых сетей многопротокольного маршрутизатора, в котором установлено несколько дополнительных программных элементов для реализации протокола DLSw (рисунок 2.12). "Оснащенный" таким образом маршрутизатор называют коммутатором DLSw.
Основной составляющей протокола DLSw является элемент, реализующий протокол "коммутатор DLSw — коммутатор DLSw", называемый протоколом SSP (Switch-to-Switch Protocol).
Протокол SSP взаимодействует с программным обеспечением протокола LLC2, от которого получает исходные кадры, а также с программным обеспечением TCP/IP, с помощью которого передает сообщения модулю SSP в коммутаторе DLSw на другом конце транзитной интерсети.
Другой важной составляющей коммутатора DLSw является элемент "DLC-трансформация", который обеспечивает преобразование протокола SDLC и других, отличных от LLC2 протоколов в протокол LLC2.
Служебные сообщения между двумя элементами SSP, а также переносимые пользовательские данные (кадры LLC2) передаются по соединениям (connections), которые представляют собой дуплексные каналы "точка-точка" между двумя DLSw-коммутаторами.
Канал (circuit) — это LLC2-тунель, соединяющий две конечные станции, которые поддерживают протокол SNA или NetBIOS. Два DLSw-коммутатора могут поддерживать несколько каналов с помощью одного соединения (рисунок 2.13). Такое мультиплексирование повышает эффективность протокола DLSw по сравнению с ранними схемами туннелирования, когда для каждого соединения LLC2 требовалось отдельное TCP-соединение.
Взаимодействие конечных узлов по протоколу DLSw можно упрощенно представить в виде следующей последовательности этапов.
1. Конечная станция посылает запрос на установление LLC2 соединения по своей локальной сети. Узлы, поддерживающие стек SNA, используют для этого служебные кадры LLC, вложенные в МАС-кадры Token Ring. В этом случае узел назначения идентифицируется адресной парой MAC/SAP, где МАС — это МАС-адрес конечного узла, а SAP (Service Access Point) указывает на сервис, с которым нужно установить соединение в узле назначения (для SNA узлов используются значения SAP 0x04, 0x08 или 0x0C). В случае использования протокола NetBIOS станция устанавливает соединение с помощью запроса Name Query, в котором указывается NetBIOS-имя узла назначения.
В любом случае программное обеспечение DLC в маршрутизаторе, выполняющем роль коммутатора DLSw, передает запрос на установление соединения программному обеспечению SSP.
2. Программное обеспечение SSP проверяет в своем кэше, не является ли запрос на установление соединения обращением к локальному узлу. Кэш может создаваться вручную либо автоматически, в зависимости от типа протоколов, работающих в локальной сети. Если SSP не находит пару MAC/SAP или имя NetBIOS в кэше локальных адресов, то он просматривает кэш адресов удаленных станций.
3. Если заданный адрес не найден и в кэше удаленных станций, то DLSw-коммутатор устанавливает соединение со всеми известными ему партнерами — DLSw-коммутаторами. Если же соединение с каким-либо коммутатором уже было установлено ранее, то DLSw-коммутатор пользуется им. По соединениям с коммутаторами-партнерами программное обеспечение передает сообщение протокола SSP, называемое CANUREACH. Все сообщения протокола SSP, инкапсулируемые в сообщения TCP, имеют служебный заголовок, в котором указывается тип сообщения, а также адресная информация — пара MAC/SAP, имя NetBIOS и некоторые дополнительные параметры. Служебным заголовком сопровождаются также и кадры LLC2, которые затем передаются по соединению.
4. Каждый удаленный DLSw-коммутатор, получив запрос CANUREACH, просматривает свой кэш на предмет нахождения там информации о конечном узле с заданным адресом. Если поиск в кэше оказался успешным, то DLSw-коммутатор отвечает по протоколу SSP сообщением ICANREACH, в котором указывает адрес искомого узла. Если в кэше удаленного коммутатора искомого адреса нет, то он должен попытаться произвести поиск в своей локальной сети станции с заданным адресом или именем. Поиск производится по тому протоколу, который поддерживает сеть, например, с помощью запроса TEST_CIRCUT_REQ для сети SNA. Если поиск проходит успешно, то удаленный коммутатор также отвечает сообщением ICANREACH.
5. Как только локальный DLSw-коммутатор принимает сообщение ICANREACH от какого-либо удаленного DLSw-коммутатора, он устанавливает канальное соединение между конечными LLC2-узлами (или узлами, которые выглядят как LLC2-узлы, благодаря элементу DLC-трансформации). После установления LLC2-канала конечные узлы могут обмениваться по нему данными, которые проходят по туннелю в сети TCP/IP. Каждый канал однозначно идентифицируется идентификатором канала в заголовке DLSw-сообщения, поэтому кадры LLC2 внутри общего соединения между коммутаторами не смешиваются.
Локальное подтверждение
Протокол LLC2 был разработан для использования в локальных сетях. Поэтому его разработчики рассчитывали на вполне определенное максимальное время получения положительных квитанций на отправленные кадры. В станциях, поддерживающих этот протокол, используется специальный таймер, называемый таймером Т1, который фиксирует превышение времени получения положительной квитанции на отправленные кадры (протокол LLC2 работает в режиме окна, разрешая отправлять 8 или 128 кадров до получения подтверждения на первый из них). При истечении таймера Т1 станция-отправитель повторяет передачу кадра определенное число раз, а затем считает, что соединение разорвано. В условиях работы через глобальные линии связи это может приводить к разрыву SNA или NetBIOS сессий просто из-за больших задержек в сети.
Для исключения таких ситуаций протокол DLSw использует технику "локальных подтверждений" (local termnation).
При использовании этого метода локальный коммутатор DLSw сам снабжает конечный узел положительными квитанциями. А для надежной передачи кадра между DLSw-коммутаторами используется механизм подтверждений и повторных передач протокола TCP. На удаленном конце транзитной сети коммутатор DLSw организует надежную передачу кадра по локальной сети с помощью механизма подтверждений протокола LLC2.
Метод локального подтверждения является одним из приемов спуффинга (обмана) конечных узлов, программное обеспечение которых рассчитано на работу в локальных сетях, но которые соединены глобальными связями. Технику спуффинга часто используют также для имитации локального соединения серверов и клиентов NetWare, чтобы часто посылаемые ими служебные сообщения подтверждения связи не засоряли медленные глобальные каналы.
Поддержка узлов, не являющихся узлами LLC2
В сетях SNA только часть узлов работает с протоколом LLC2 — это те узлы, которые подключаются к процессорам FEP по протоколу Token Ring. В то же время существует большое количество узлов, работающих на канальном уровне по протоколу SDLC или BSC. Кроме того, SNA трафик может быть представлен трафиком протокола Qualified Ligical Link Control (QLLC), который разработан для передачи трафика SDLC по сетям Х.25.
Протокол DLSw предусматривает поддержку этих видов трафика с помощью программного обеспечения DLC-трансформация, которое отображает команды протоколов, отличающихся от LLC2, в команды протокола LLC2.
Для поддержки трафика SDLC маршрутизаторы, работающие по протоколу DLSw, должны в режиме спуффинга имитировать постоянные опросы (polls) конечной станции процессором FEP. Эта имитация выполняется программным обеспечением DLC-трансформации.
Поддержка дейтаграммного и широковещательного трафика
Протокол NetBIOS может работать не только в режиме с установлением соединения, но и в дейтаграммном режиме. Он использует дейтаграммы для пересылки пользовательских данных, если этого требует приложение, а также для выполнения некоторых своих служебных функций. Кроме того, в этом протоколе используются широковещательные рассылки.
Маршрутизаторы, поддерживающие спецификацию DLSw, позволяют пересылать дейтаграммы без предварительного установления соединения.
Для имитации широковещательности коммутаторы DLSw рассылают такие дейтаграммы всем известным им DLSw-партнерам по IP-сети.
В отличие от спецификации LAN Emulation стандарт DLSw не предусматривает в сети IP централизованного сервера, который бы регистрировал все DLSw-коммутаторы, образующие единую локальную сеть.
Назначение и общие принципы работы
Появление новой технологии АТМ потребовало решения задачи согласования этой технологии с уже существующими традиционными технологиями локальных сетей, такими как Ethernet или Token Ring.
Для решения этой задачи в принципе могут быть использованы все обсуждавшиеся выше подходы к организации работы неоднородных сетей — мультиплексирование, трансляция и инкапсуляция протоколов. Однако мультиплексирование редко применяется для протоколов физического и канального уровней (к которым относится протокол АТМ), так как при этом требуется наличие нескольких сетевых адаптеров в каждом компьютере.
Гораздо чаще для согласования протоколов канального уровня используется трансляция с помощью таких промежуточных устройств, как мосты, коммутаторы и маршрутизаторы. Однако мосты и коммутаторы способны выполнять трансляцию только близких технологий, например, Ethernet и FDDI или Ethernet и Token Ring, а задача трансляции существенно отличающихся технологий локальных и глобальных сетей для устройств этого типа является слишком сложной. Примером таких "плохо совместимых" пар протоколов могут служить Х.25 и Ethernet или frame relay и Ethernet. Поскольку технология ATM близка к технологиям территориальных сетей и плохо совместима с традиционными канальными протоколами локальных сетей, то в этом случае трансляционные возможности мостов и коммутаторов также оказываются недостаточными.
Маршрутизаторы же умеют выполнять трансляцию существенно отличающихся протоколов, используя для этого общий протокол сетевого уровня для всех согласуемых сетей. Для обеспечения совместимости ATM с протоколами канального уровня локальных сетей разработана спецификация Classical IP (RFC 1577), в которой в качестве объединяющего протокола сетевого уровня определен протокол IP. Такое решение хорошо работает, когда локальные сети объединяются с территориальной сетью АТМ, применение же этого подхода в случае, когда технология АТМ используется для построения локальной сети, не всегда оказывается эффективным. Во-первых, необходимость использования маршрутизаторов для локальных сетей не всегда является экономически оправданной. Во-вторых, не все локальные сети поддерживают протокол сетевого уровня — так, например, функции маршрутизации отсутствуют в часто используемом стеке SMB/NetBIOS.
Поэтому возникла необходимость в создании технологии объединения сетей АТМ и традиционных локальных сетей без привлечения маршрутизаторов и протоколов сетевого уровня. Такой технологией и является технология LAN Emulation (LANE), разработанная организацией ATM Forum.
Эта спецификация использует инкапсуляцию кадров канальных протоколов локальных сетей, таких как Ethernet или Token Ring, в ячейки АТМ. Использование инкапсуляции в спецификации LAN Emulation несколько отличается от ее традиционного применения.
Обычно инкапсуляция обеспечивает связь двух сетей одной технологии через промежуточную сеть другой технологии. При этом узлы промежуточной сети недоступны конечным узлам объединяемых сетей, и промежуточная сеть играет роль транзитной сети. LAN Emulation с помощью инкапсуляции решает не только традиционную задачу связи локальных сетей через транзитную сеть АТМ, но и общую задачу связи всех узлов составной сети — связи между узлами локальных сетей и внутренними узлами АТМ-сети.
Рассмотрим последовательно решение этих двух задач, причем для определенности будем предполагать, что сеть АТМ используется для соединения сетей Ethernet.
Объединение локальных сетей через транзитную АТМ-сеть
Итак, пусть сеть ATM используется только в качестве транзитной сети. Сети Ethernet подключаются к сети коммутаторов АТМ с помощью пограничных устройств, названных в спецификации LAN Emulation АТМ-LAN конверторами. Такой конвертор должен иметь ATM-порт, с помощью которого он подключается к АТМ-сети, а также некоторое количество портов для подключения локальных сетей традиционных технологий. Конвертор имеет АТМ-адрес для взаимодействия с другими конверторами по сети АТМ. Кроме того, конвертор должен иметь информацию о МАС-адресах всех узлов каждой из локальных сетей, которые он присоединяет к сети АТМ. Конвертором может быть любое устройство локальной сети, но наиболее подходящим устройством для выполнения этих функций является коммутатор локальной сети, так как он имеет таблицу МАС-адресов всех устройств сети, которые обмениваются через него данными. Поэтому будем далее использовать термины АТМ-LAN конвертор и ATM-LAN коммутатор как синонимы.
В каждый АТМ-LAN коммутатор встроен протокол LAN Emulation (рисунок 2.5), в задачу которого входит передача принятого коммутатором МАС-кадра через АТМ-сеть другому ATM-LAN коммутатору. Так как к АТМ-сети может быть подключено несколько локальных сетей, то при получении из локальной сети кадра с МАС-адресом назначения ATM-LAN коммутатор должен решить, к какому из остальных ATM-LAN коммутаторов относится данный МАС-адрес.
Таким образом, коммутатор для принятия решения о передаче кадра оперирует с двумя таблицами — с локальной, которая устанавливает соответствие МАС-адресов его локальной сети локальным портам, и с транзитной, которая содержит для каждого МАС-адреса составной сети АТМ-адрес пограничного коммутатора. Спецификация LAN Emulation не определяет конкретный вид таблиц ATM-LAN конверторов. Один из возможных вариантов этих таблиц приведен на рисунке 2.6.
Если АТМ-LAN коммутатор в результате просмотра адресных таблиц видит, что кадр нужно передать через АТМ-сеть другому ATM-LAN коммутатору, то он с помощью стека протоколов АТМ устанавливает виртуальное соединение (Virtual Channel Connection, VCC) с этим коммутатором, а затем передает по нему кадр в форме потока ячеек АТМ.
Особенностью инкапсуляции кадров в спецификации LAN Emulation является то, что кадр не упаковывается целиком в ячейку АТМ, а ввиду очень малого размера ее поля данных (48 байт) разбивается на фрагменты, которые затем инкапсулируются в последовательность АТМ-ячеек. Разбиение (сегментация) кадра и последующая его сборка осуществляются стандартными средствами стека АТМ, реализованного в ATM-LAN конверторе.
Для передачи трафика локальных сетей через сеть АТМ выбран класс АТМ-сервиса с неопределенной битовой скоростью, что хорошо соответствует алгоритмам работы протоколов локальных сетей, когда конечному узлу не дается никаких гарантий относительно выделяемой ему пропускной способности. Этот класс сервиса реализован в сетях АТМ подуровнем AAL5 (ATM Adaptaton Layer 5), принимающим запросы на установление соединений от протоколов верхних уровней. Остальные классы сервиса сетей АТМ, гарантирующие некоторую часть пропускной способности своим абонентам, в спецификации LAN Emulation версии 1.0 не используются, хотя потребность в них может возникать при работе в локальной сети приложений реального времени. Эти возможности ожидаются в следующих версиях спецификации LAN Emulation.
Отдельной задачей является автоматическое построение транзитных адресных таблиц АТМ-LAN коммутатора. Поскольку сети АТМ, как и большинство территориальных сетей, не поддерживают широковещательность, то обнаружить через сеть АТМ пограничные коммутаторы с помощью широковещательных запросов (как это делают, например, клиенты и серверы сетей NetWare) невозможно.
Ручное задание АТМ-адресов пограничных коммутаторов может оказаться обременительным занятием для администратора, если таких коммутаторов много и их набор часто претерпевает изменения, что характерно для локальных сетей.
Для автоматического построения транзитных адресных таблиц спецификация LAN Emulation предлагает использовать централизованный подход, то есть возложить решение этой задачи на сервер, присоединенный к сети АТМ (рис. 2.7).
Этот сервер носит название LAN Emulation Server — LES. Та часть протокола спецификации LAN Emulation, которая работает в ATM-LAN коммутаторе, называется LAN Emulation Client — LEC. При своей инициализации LEC АТМ-LAN коммутатора сообщает серверу LES свои МАС- и ATM-адреса. Затем LEC регистрирует в LES все МАС-адреса узлов, которые он узнает при изучении своей локальной сети. Таким же образом поступают все пограничные ATM-LAN коммутаторы, поэтому в сервере LES накапливается общая таблица соответствия МАС-адресов узлов локальных сетей АТМ-адресам их пограничных коммутаторов.
Для взаимодействия с сервером LES каждый клиент LEC устанавливает прямое виртуальное соединение VCC с этим сервером, называемое Control Direct VCC. Это соединение устанавливается еще на стадии присоединения (Join) клиента LEC к эмулируемой сети. Под эмулируемой сетью понимается вся совокупность локальных сетей, взаимодействующих друг с другом через данный сервер LES и пограничные коммутаторы таким образом, как будто они работают в локальной сети, объединенной с помощью обычных повторителей, мостов и коммутаторов.
Каждый ATM-LAN коммутатор должен изначально знать только один адрес — АТМ-адрес сервера адресов LES, чтобы установить с ним виртуальное соединение. Теперь при приходе кадра с неизвестным МАС-адресом пограничный коммутатор может послать запрос серверу LES об АТМ-адресе коммутатора, обслуживающего локальную сеть, в которой имеется узел с данным МАС-адресом. Протокол передачи запроса на разрешение MAC-адреса и получения на него ответа является частью спецификации LAN Emulation и называется LE_ARP (LAN Emulation Address Resolution Protocol).
При получении LE_ARP-запроса сервер LES просматривает свои адресные таблицы, и если находит там зарегистрированный искомый МАС-адрес, то посылает LE_ARP-ответ, в котором указывает АТМ-адрес пограничного ATM-LAN коммутатора, которому нужно переслать кадр с данным МАС-адресом. Если же искомый МАС-адрес отсутствует в таблице сервера, то сервер LES пересылает LE_ARP-запрос всем LEC, присоединившимся к эмулируемой сети.
Пересылать LE_ARP-запрос можно по очереди каждому клиенту LEC по тем индивидуальным виртуальным соединениям Control Direct VCC, которые были созданы при присоединении LEC к LES, но такой способ будет работать медленно при большом числе LEC. Для ускорения работы LES использует специфический механизм мультивещательности, поддерживаемый сетями АТМ. Этот механизм позволяет какому-либо узлу АТМ-сети, называемому корнем, устанавливать виртуальное соединение "один-ко-многим" (point-to-multipoint) и одновременно передавать одни и те же данные всем остальным узлам соединения, называемым листьями.
При этом узлы-листья могут посылать данные только узлу-корню, а между собой обмениваться данными по соединению такого вида им запрещено.
Сервер LES при присоединении к эмулируемой сети нового клиента LEC сразу же добавляет последнего к мультивещательному соединению в качестве нового листа. Такое соединение называется Control Distribute VCC и служит для одновременного распространения LE_ARP-запроса всем LEC эмулируемой сети. Тот LEC, который опознал в запросе МАС-адрес обслуживаемой сети, генерирует LE_ARP-ответ, в котором указывает свой АТМ-адрес. Получив LE_ARP-ответ, сервер LES распространяет его также по мультивещательному VCC, чтобы все LEC сети могли бы кэшировать данную информацию для будущего использования.
После получения информации об АТМ-адресе соответствующего ATM-LAN коммутатора LEC устанавливает с ним прямое виртуальное соединение Data Direct VCC, по которому начинает передавать кадры для данного МАС-адреса.
Так как в задачу спецификации LAN Emulation входит представление эмулируемой составной сети в виде функционального эквивалента традиционной локальной сети, то для конечных узлов такой сети нужно обеспечить свойство широковещательности, когда кадр, посланный с широковещательным адресом, доходит до всех узлов сети.
Эмуляцию широковещательности спецификация LAN Emulation выполняет с помощью уже описанного механизма мультивещательности "один-ко-многим". С этой целью в сети АТМ, кроме сервера LES, создается еще один сервер — Broadcast and Unknown Server, BUS. Сервер BUS организует доставку кадров с широковещательными адресами, а также кадров, ATM-адрес пограничного коммутатора которых неизвестен клиенту LEC, всем узлам эмулируемой сети. Сервер BUS имеет отдельный ATM-адрес, который сообщается сервером LES клиенту LEC при его присоединении к эмулируемой сети. Клиент LEC должен после этого установить с сервером BUS прямое виртуальное соединение Multicast Send VCC, по которому он будет пересылать кадры с широковещательными или неизвестными адресами. Сервер BUS добавляет каждого нового клиента LEC к мультивещательному соединению Multicast Forward VCC в качестве листа. Это соединение используется сервером BUS для одновременной рассылки широковещательных кадров и кадров с неизвестными адресами всем пограничным коммутаторам эмулируемой сети.
Спецификация LAN Emulation рекомендует клиентам LEC делать LE_ARP-запрос серверу LES для кадра с неизвестным адресом и, не дожидаясь ответа, сразу же отправлять этот кадр через сервер BUS. Это делается для ускорения работы эмулируемой сети, так как кадры начнут доходить до узла назначения широковещательным образом еще до того, как будет получен LE_ARP-ответ от сервера LES. После получения LE_ARP-ответа LEC перестает посылать кадры для данного МАС-адреса широковещательно, а устанавливает виртуальное соединение Data Direct VCC с конкретным ATM-LAN коммутатором (или же пользуется уже установленным ранее соединением с этим коммутатором) и передает остальные кадры с данным МАС-адресом уже по прямому каналу.
Организация нескольких эмулируемых сетей
Спецификация LAN Emulation позволяет организовать в рамках одной составной ATM-LAN сети нескольких отдельных эмулируемых сетей. Эти сети полностью отделены друг от друга, так что узлы, входящие в одну эмулируемую сеть, не получают кадры другой эмулируемой сети, какие бы типы МАС-адресов назначения ни применялись: индивидуальные, групповые или широковещательные. Такая концепция хорошо согласуется с концепцией виртуальных сетей, реализованной во многих коммутаторах традиционных протоколов локальных сетей, которые также определяются как наборы узлов сети, где локализуется весь их трафик, включая и широковещательный, вне зависимости от физического расположения узлов.
Для поддержания каждой эмулируемой сети в сети АТМ должна работать собственная пара серверов LES и BUS. АТМ-LAN конвертор может быть присоединен одновременно к нескольким эмулируемым сетям, при этом для работы с каждой сетью он имеет отдельный элемент LEC, который образует с каждым из серверов сети отдельные виртуальные соединения VCC, так что трафики эмулируемых сетей не смешиваются внутри сети АТМ. Аналогично, если два ATM-LAN коммутатора поддерживают несколько эмулируемых сетей, то для обмена данными между собой они образуют для каждой эмулируемой сети отдельное виртуальное соединение Data Direct VCC.
Для автоматического поддержания нескольких эмулируемых сетей в АТМ-сети организуется еще один центральный сервер — LAN Emulation Configuration Server, LECS. Этот сервер хранит список имен эмулируемых сетей, а также значения их основных параметров — АТМ-адреса серверов LES и BUS каждой сети, тип сети (например, Ethernet или Token Ring), максимальный размер кадра, поддерживаемого этой сетью, и т.п. Поэтому каждый LEC при инициализации должен сначала установить соединение с единственным в сети сервером LECS (он должен знать АТМ-адрес этого сервера) и получить от LECS список всех эмулируемых сетей и их параметров.
На основании полученной информации LEC должен выбрать эмулируемую сеть, к которой он желает присоединиться, и известить об этом LECS. Затем LEC выполняет процедуру присоединения к LES выбранной эмулируемой сети, регистрирует там МАС-адреса своих узлов и начинает работать с составной сетью. Протокол взаимодействия клиентской части протокола LAN Emulation, а именно LEC, с серверными частями этой спецификации LECS, LES и BUS называется LAN Emulation User-Network Interface (LUNI).
Если ATM-LAN коммутатор поддерживает со стороны локальной сети несколько виртуальных сетей, то он может отождествить каждую виртуальную сеть с эмулируемой сетью. Поэтому при регистрации МАС-адресов на сервере LES определенной эмулируемой сети коммутатор регистрирует только те МАС-адреса, которые относятся к виртуальной сети, отождествляемой с этой эмулируемой сетью.
Если все пограничные коммутаторы поддерживают несколько виртуальных сетей и администратор хочет, чтобы эти сети работали в масштабах всей составной сети, то отождествление их с определенными эмулируемыми сетями дает хороший способ передачи информации о принадлежности МАС-адреса той или иной сети между разными пограничными коммутаторами.
Спецификация LAN Emulation не определяет способа построения виртуальных сетей пограничными коммутаторами на стороне локальной сети. Эта спецификация дает только стандартный способ информирования других коммутаторов о том, какой виртуальной сети принадлежит передаваемый кадр. В составной сети кадры разных виртуальных локальных сетей передаются по разным виртуальным соединениям и поэтому не смешиваются.
Взаимодействие между разными эмулируемыми сетями в спецификации LAN Emulation не предусматривается. Для организации взаимодействия нужен маршрутизатор, который либо присоединяется к интерфейсам локальных сетей, либо подключается непосредственно к сети АТМ и, поддерживая спецификацию LAN Emulation, присоединяется к каждой из эмулируемых сетей. Маршрутизатор назначает эмулируемым сетям сетевые адреса и производит на основании этих адресов передачу пакетов между сетями.
Организация взаимодействия всех узлов составной сети
Понятно, что узлы, непосредственно присоединенные к АТМ-коммутаторам с помощью АТМ-адаптеров, могут взаимодействовать между собой и без привлечения добавочных протоколов, таких как протоколы спецификации LAN Emulation. Но в таком случае приложения и протоколы прикладного уровня (NCP, SMB, NFS или FTP) должны быть модифицированы, так как они должны научиться поддерживать интерфейс со стеком протоколов АТМ на своем узле, а также не использовать отсутствующие в протоколах АТМ широковещательные рассылки. Кроме того, АТМ-узлы не смогут взаимодействовать с узлами локальных сетей, на которых установлены традиционные стеки протоколов с канальными протоколами Ethernet, Token Ring и т.п.
Спецификация LAN Emulation позволяет превратить АТМ-узлы в узлы, подобные традиционным узлам локальных сетей. Это достигается за счет размещения в АТМ-узле программного обеспечения клиента LEC, выполняющего те же функции, что и LEC пограничных ATM-LAN коммутаторов. На АТМ-узле LEC размещается между АТМ-протоколами драйвера сетевого адаптера АТМ и протоколом LLC (рисунок 2.8) или любым другим протоколом, который рассчитан на работу с протоколом МАС-уровня локальной сети. Протокол LEC предоставляет протоколам верхних уровней того узла, на котором он работает, тот же интерфейс, что и МАС-уровень сети Ethernet или Token Ring.
В отличие от протокола LEC, работающего на ATM-LAN коммутаторе, LEC отдельного АТМ-узла представляет только один МАС-адрес — МАС-адрес данного узла. Остальные действия LEC узла ничем не отличаются от LEC коммутатора. Он точно так же соединяется с сервером LECS, получает от него список эмулируемых сетей и присоединяется к одной из сетей, регистрируя в LES этой сети пару АТМ-адрес/МАС-адрес своего узла. Для присоединения одного и того же узла к нескольким сетям на узле должны работать одновременно несколько копий LEC, по одной на каждую сеть. Сообщения, получаемые от протоколов верхних уровней, LEC узла преобразует с помощью функции SAR в поток ячеек, который передает по виртуальному соединению протоколу LEC других АТМ-узлов. Широковещательный трафик направляется узлам эмулируемой сети через сервер BUS.
Наличие МАС-адреса у узла АТМ-сети позволяет ей взаимодействовать и с узлами присоединенных локальных сетей. При этом LEC узла взаимодействует с LEC пограничного коммутатора, посылая через сеть АТМ-кадр, в котором указывает в качестве адреса назначения МАС-адрес узла локальной сети, а в качестве адреса источника — свой МАС-адрес. Пограничный коммутатор затем передает кадр в соответствии с МАС-адресом назначения и своей адресной таблицей на один из своих локальных портов. Локальный узел, получив кадр, может ответить на него обычным кадром, указав в нем МАС-адрес узла АТМ-сети.
Спецификация LAN Emulation сегодня реализована в устройствах различных типов многих производителей. Серверные части спецификации — серверы LECS, LES и BUS обычно встраиваются в АТМ-коммутаторы или корпоративные АТМ-LAN коммутаторы, а клиентские компоненты LEC — в драйверы сетевых адаптеров и ATM-LAN коммутаторы уровня отдела или рабочей группы.
Недостатки версии LAN Emulation 1.0 и пути ее совершенствования
Наличие единственного серверного элемента в сети всегда является недостатком как в отношении производительности, так и в отношении надежности сети. При большом количестве клиентов LEC трафик к коммутатору, который поддерживает серверы LES и BUS, может быть очень большим, особенно при широком использовании метода группового распространения мультимедийной информации через BUS. Отказ коммутатора, в котором работает пара LES/BUS, будет приводить к останову всей сети.
К тому же производители часто ограничивают возможности серверов LES/BUS по одновременной работе с большим количеством клиентов LEC. Так, коммутатор LANplex компании 3Com поддерживает не более 16 эмулируемых сетей, в каждой из которых должно быть не более 16 клиентов LEC. Это ограничение не такое жесткое, если речь идет о LEC, встроенных в коммутаторы, ведь в этом случае один LEC может представлять несколько сот узлов. Однако при использовании LEC в сетевых адаптерах ATM-узлов такое ограничение является существенным тормозом при создании сети с большим количеством АТМ-узлов.
Спецификация LAN Emulation не запрещает использования в сети нескольких устройств, которые выполняют серверные функции, однако и не описывает механизм их взаимодействия при тиражировании адресных таблиц и выполнении других операций.
Протоколы взаимодействия между несколькими копиями LES/BUS, поддерживающими одну и ту же эмулируемую сеть, должны быть определены в спецификации LAN Emulation 2.0.
Кроме того, версия LAN Emulation 2.0 должна определить работу эмулируемой сети при передаче трафиков различных классов сервиса, а не только класса QoS 0 с неопределенной полосой пропускания. Это необходимо для работы в сети приложений, требующих обработки их кадров в реальном времени, — приложений, организующих видеоконференции, передающих голос и т.п.
инкапсулирующая технология Data Link Switching (DLSw)
Назначение и история создания технологии
Технология Data Link Switching (DLSw) была разработана для организации связи локальных сетей, не использующих сетевые маршрутизируемые протоколы, через транзитные сети TCP/IP. Основная область применения протокола DLSw — это транзитная передача кадров протокола LLC2, используемого в локальных сетях Token Ring архитектуры SNA и в локальных сетях NetBIOS.
Протоколы подуровня LLC (Logical Link Control) разработаны комитетом 802.2 института IEEE для организации логического обмена кадрами данных между двумя конечными станциями локальной сети после того, как МАС-подуровень станции-инициатора обмена получит доступ к среде. Для уровня LLC в стандарте 802.2 определены процедуры трех типов — LLC1, LLC2 и LLC3.
Процедура LLC1 выполняет передачу кадра без предварительного установления соединения, дейтаграммным методом. Основное назначение процедуры LLC1 — это обеспечение интерфейса между МАС-уровнем и вышележащими протоколами. Многие стеки протоколов используют ненадежную процедуру LLC1 на канальном уровне, с тем чтобы обеспечить надежное соединение средствами протоколов верхнего уровня — транспортными (TCP, SPX) или прикладными (NCP).
Процедура LLC2 работает на основе установления соединения между конечными станциями. После установления соединения пересылаемые кадры нумеруются, а для обеспечения надежной доставки кадров используется механизм положительных квитанций с повторными передачами при истечении таймера ожидания квитанции. Процедура LLC2 похожа на протокол LAP-B, используемый в сетях Х.25 для соединения "точка-точка" между конечным узлом и коммутатором сети.
Процедура LLC3 похожа на процедуру LLC1. Она работает без установления соединения, но с уведомлением отправителя о доставке кадра узлу назначения.
Протокол LLC2 используется в двух типах широко распространенных сетей — архитектуры IBM SNA с протоколом Token Ring на нижнем уровне и в сетях с протоколом NetBIOS. Технология DLSw позволяет передавать трафик этих сетей через общий туннельный канал в магистральных сетях TCP/IP, используя для объединения сетей многопротокольные маршрутизаторы.
Протокол DLSw появился в результате большой работы по стандартизации множества частных схем инкапсуляции трафика SNA и NetBIOS в сети TCP/IP, предложенных различными производителями коммуникационного оборудования.
Исторически сети архитектуры SNA выполняли наиболее ответственные корпоративные приложения, такие как обработка деловых транзакций, бухгалтерский учет, поддержка продаж. Но локальные сети SNA не используют традиционные средства маршрутизации локальных сетей. В результате у многих предприятий образовались параллельные корпоративные сети, каждая со своей инфраструктурой, которые не могут разделять общие глобальные линии связи и управляться с помощью общей платформы управления.
Параллельное существование двух типов сетей — SNA и сетей, основанных на маршрутизаторах, объяснялось и техническими причинами. Трафик большинства существующих сетей SNA, то есть сетей SNA, возникших до разработки компанией IBM новой маршрутизируемой технологии APPN (Advanced Peer-to-Peer Networking), могут маршрутизироваться только с помощью специальных сетевых устройств, называемых FEP — Front-End Processors. Процессоры FEP представляют собой достаточно дорогие устройства, которые умеют маршрутизировать только трафик сетей SNA. С другой стороны, маршрутизаторы не умеют маршрутизировать традиционный (не APPN) трафик SNA, а компьютеров IBM, поддерживающих новую технологию APPN, пока еще очень немного.
С течением времени многие корпорации, имеющие разветвленные сети архитектуры SNA, стали искать пути передачи трафика SNA и NetBIOS через получающие все большее распространение глобальные сети на основе маршрутизаторов, в частности, через сети TCP/IP. Многие производители маршрутизаторов в ответ на потребности рынка предложили свои фирменные протоколы, которые разными способами инкапсулировали трафик SNA в многопротокольные магистрали. При этом использовалось два принципиально различных подхода — инкапсуляция кадров LLC2 в кадры канального уровня (например, в кадры сетей Х.25 или frame relay) и инкапсуляция кадров LLC2 в сообщения TCP — протокола транспортного уровня (рисунок 2.9).
Оба подхода имеют свои преимущества и недостатки. В первом случае избыточность служебных заголовков гораздо меньше, чем во втором. Кадры LLC2 быстрее упаковываются и извлекаются из транзитного протокола. Однако в первом случае метод может работать только тогда, когда конечные узлы объединяются транзитной сетью одной технологии, например, только сетью Х.25 или только сетью frame relay. Говорят, что первый метод — это метод "одной транзитной передачи" (one hop).
Метод инкапсуляции в пакеты TCP в этом отношении универсален — он может работать при объединении конечных узлов через большое количество транзитных сетей разных технологий — X.25, frame relay, ATM, Ethernet, если только они связаны через маршрутизаторы, поддерживающие протокол TCP/IP. Протокол DLSw образует туннель через эти сети, пронося через него кадры LLC2, упакованные в сообщения TCP.
В стандартизации второго подхода наряду с другими производителями приняла участие компания IBM. Спонсором работ выступила организация APPN Imlementators Workshop (AIW) и организованный IBM форум производителей. В конце концов протокол DLSw был принят комитетом IETF в качестве стандарта и получил номер RFC 1434. Позже этот стандарт был заменен версией RFC 1795, обратно совместимой с аппаратурой, поддерживающей RFC 1434. Однако маршрутизаторы, поддерживающие версию RFC 1795, могут оказаться несовместимыми с маршрутизаторами, поддерживающими фирменные улучшения версии RFC 1434, например, фирменную версию DLSw+ компании Cisco.
Принципы работы протокола DLSw
Для организации взаимодействия узлов по протоколу DLSw необходимо наличие в каждой из связываемых сетей многопротокольного маршрутизатора, в котором установлено несколько дополнительных программных элементов для реализации протокола DLSw (рисунок 2.12). "Оснащенный" таким образом маршрутизатор называют коммутатором DLSw.
Основной составляющей протокола DLSw является элемент, реализующий протокол "коммутатор DLSw — коммутатор DLSw", называемый протоколом SSP (Switch-to-Switch Protocol).
Протокол SSP взаимодействует с программным обеспечением протокола LLC2, от которого получает исходные кадры, а также с программным обеспечением TCP/IP, с помощью которого передает сообщения модулю SSP в коммутаторе DLSw на другом конце транзитной интерсети.
Другой важной составляющей коммутатора DLSw является элемент "DLC-трансформация", который обеспечивает преобразование протокола SDLC и других, отличных от LLC2 протоколов в протокол LLC2.
Служебные сообщения между двумя элементами SSP, а также переносимые пользовательские данные (кадры LLC2) передаются по соединениям (connections), которые представляют собой дуплексные каналы "точка-точка" между двумя DLSw-коммутаторами.
Канал (circuit) — это LLC2-тунель, соединяющий две конечные станции, которые поддерживают протокол SNA или NetBIOS. Два DLSw-коммутатора могут поддерживать несколько каналов с помощью одного соединения (рисунок 2.13). Такое мультиплексирование повышает эффективность протокола DLSw по сравнению с ранними схемами туннелирования, когда для каждого соединения LLC2 требовалось отдельное TCP-соединение.
Взаимодействие конечных узлов по протоколу DLSw можно упрощенно представить в виде следующей последовательности этапов.
1. Конечная станция посылает запрос на установление LLC2 соединения по своей локальной сети. Узлы, поддерживающие стек SNA, используют для этого служебные кадры LLC, вложенные в МАС-кадры Token Ring. В этом случае узел назначения идентифицируется адресной парой MAC/SAP, где МАС — это МАС-адрес конечного узла, а SAP (Service Access Point) указывает на сервис, с которым нужно установить соединение в узле назначения (для SNA узлов используются значения SAP 0x04, 0x08 или 0x0C). В случае использования протокола NetBIOS станция устанавливает соединение с помощью запроса Name Query, в котором указывается NetBIOS-имя узла назначения.
В любом случае программное обеспечение DLC в маршрутизаторе, выполняющем роль коммутатора DLSw, передает запрос на установление соединения программному обеспечению SSP.
2. Программное обеспечение SSP проверяет в своем кэше, не является ли запрос на установление соединения обращением к локальному узлу. Кэш может создаваться вручную либо автоматически, в зависимости от типа протоколов, работающих в локальной сети. Если SSP не находит пару MAC/SAP или имя NetBIOS в кэше локальных адресов, то он просматривает кэш адресов удаленных станций.
3. Если заданный адрес не найден и в кэше удаленных станций, то DLSw-коммутатор устанавливает соединение со всеми известными ему партнерами — DLSw-коммутаторами. Если же соединение с каким-либо коммутатором уже было установлено ранее, то DLSw-коммутатор пользуется им. По соединениям с коммутаторами-партнерами программное обеспечение передает сообщение протокола SSP, называемое CANUREACH. Все сообщения протокола SSP, инкапсулируемые в сообщения TCP, имеют служебный заголовок, в котором указывается тип сообщения, а также адресная информация — пара MAC/SAP, имя NetBIOS и некоторые дополнительные параметры. Служебным заголовком сопровождаются также и кадры LLC2, которые затем передаются по соединению.
4. Каждый удаленный DLSw-коммутатор, получив запрос CANUREACH, просматривает свой кэш на предмет нахождения там информации о конечном узле с заданным адресом. Если поиск в кэше оказался успешным, то DLSw-коммутатор отвечает по протоколу SSP сообщением ICANREACH, в котором указывает адрес искомого узла. Если в кэше удаленного коммутатора искомого адреса нет, то он должен попытаться произвести поиск в своей локальной сети станции с заданным адресом или именем. Поиск производится по тому протоколу, который поддерживает сеть, например, с помощью запроса TEST_CIRCUT_REQ для сети SNA. Если поиск проходит успешно, то удаленный коммутатор также отвечает сообщением ICANREACH.
5. Как только локальный DLSw-коммутатор принимает сообщение ICANREACH от какого-либо удаленного DLSw-коммутатора, он устанавливает канальное соединение между конечными LLC2-узлами (или узлами, которые выглядят как LLC2-узлы, благодаря элементу DLC-трансформации). После установления LLC2-канала конечные узлы могут обмениваться по нему данными, которые проходят по туннелю в сети TCP/IP. Каждый канал однозначно идентифицируется идентификатором канала в заголовке DLSw-сообщения, поэтому кадры LLC2 внутри общего соединения между коммутаторами не смешиваются.
Локальное подтверждение
Протокол LLC2 был разработан для использования в локальных сетях. Поэтому его разработчики рассчитывали на вполне определенное максимальное время получения положительных квитанций на отправленные кадры. В станциях, поддерживающих этот протокол, используется специальный таймер, называемый таймером Т1, который фиксирует превышение времени получения положительной квитанции на отправленные кадры (протокол LLC2 работает в режиме окна, разрешая отправлять 8 или 128 кадров до получения подтверждения на первый из них). При истечении таймера Т1 станция-отправитель повторяет передачу кадра определенное число раз, а затем считает, что соединение разорвано. В условиях работы через глобальные линии связи это может приводить к разрыву SNA или NetBIOS сессий просто из-за больших задержек в сети.
Для исключения таких ситуаций протокол DLSw использует технику "локальных подтверждений" (local termnation).
При использовании этого метода локальный коммутатор DLSw сам снабжает конечный узел положительными квитанциями. А для надежной передачи кадра между DLSw-коммутаторами используется механизм подтверждений и повторных передач протокола TCP. На удаленном конце транзитной сети коммутатор DLSw организует надежную передачу кадра по локальной сети с помощью механизма подтверждений протокола LLC2.
Метод локального подтверждения является одним из приемов спуффинга (обмана) конечных узлов, программное обеспечение которых рассчитано на работу в локальных сетях, но которые соединены глобальными связями. Технику спуффинга часто используют также для имитации локального соединения серверов и клиентов NetWare, чтобы часто посылаемые ими служебные сообщения подтверждения связи не засоряли медленные глобальные каналы.
Поддержка узлов, не являющихся узлами LLC2
В сетях SNA только часть узлов работает с протоколом LLC2 — это те узлы, которые подключаются к процессорам FEP по протоколу Token Ring. В то же время существует большое количество узлов, работающих на канальном уровне по протоколу SDLC или BSC. Кроме того, SNA трафик может быть представлен трафиком протокола Qualified Ligical Link Control (QLLC), который разработан для передачи трафика SDLC по сетям Х.25.
Протокол DLSw предусматривает поддержку этих видов трафика с помощью программного обеспечения DLC-трансформация, которое отображает команды протоколов, отличающихся от LLC2, в команды протокола LLC2.
Для поддержки трафика SDLC маршрутизаторы, работающие по протоколу DLSw, должны в режиме спуффинга имитировать постоянные опросы (polls) конечной станции процессором FEP. Эта имитация выполняется программным обеспечением DLC-трансформации.
Поддержка дейтаграммного и широковещательного трафика
Протокол NetBIOS может работать не только в режиме с установлением соединения, но и в дейтаграммном режиме. Он использует дейтаграммы для пересылки пользовательских данных, если этого требует приложение, а также для выполнения некоторых своих служебных функций. Кроме того, в этом протоколе используются широковещательные рассылки.
Маршрутизаторы, поддерживающие спецификацию DLSw, позволяют пересылать дейтаграммы без предварительного установления соединения.
Для имитации широковещательности коммутаторы DLSw рассылают такие дейтаграммы всем известным им DLSw-партнерам по IP-сети.
В отличие от спецификации LAN Emulation стандарт DLSw не предусматривает в сети IP централизованного сервера, который бы регистрировал все DLSw-коммутаторы, образующие единую локальную сеть.
Сетевые решения. Статья была опубликована в номере 08 за 2000 год в рубрике технологии
