Підходи до інтеграції неоднорідних мереж, Локальні мережі, статті

Комп’ютерна газета

Технологія 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-комутатори, що утворюють єдину локальну мережу.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*