Инкапсулирующая технология 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.11).

Рис. 2.11. Два метода инкапсуляции кадров LLC2

Оба подхода имеют свои преимущества и недостатки. В первом случае избыточность служебных заголовков гораздо меньше, чем во втором. Кадры 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.

Рис. 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-коммутаторами.

Рис. 2.13. Соединения и каналы протокола 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) (рисунок 2.14).

Рис. 2.14. Локальное подтверждение в каналах LLC2

При использовании этого метода локальный коммутатор 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-коммутаторы, образующие единую локальную сеть.

Предыдущая глава | Оглавление | Следующая глава