Від архітектури ядра до магістралей-партнерів

Розглянемо архітектуру мережі, яка має дві рівнозначні магістралі, сполучені між собою (рис. 3.47).

Рис. 3.47. Дві магістралі-партнери, сполучені раутерами.

Основна концептуальна відмінність такого сполучення від розгляненого вище полягає у наявності багатьох сполучень між магістралями-партнерами. Складність IP-раутінгу при цьому викликана наявністю декількох можливих маршрутів між станціями, під’єднаними до різних магістралей, наприклад, між станціями 1 і 3. У більшості випадків трафік між станціями повинен пересилатися через найкоротший шлях, наприклад, маршрут від станції 1 до станції 3 повинен пролягати через раутер R1. Однак це може бути важко зреалізувати з двох причин. По-перше, хоч стандартний алгоритм IP-раутінгу використовує тільки мережеву частину IP-адреси для вибору маршруту, однак оптимальний раутінг в архітектурі магістралей-партнерів вимагає індивідуальних маршрутів для окремих станцій. Для прикладу на рис. 3.47, станція 3 потребує різних маршрутів до стнцій 1 і 2, хоч обидві ці станції під’єднані до магістралі 1. По-друге мережеві адміністратори цих двох магістралей повинні домовитися про утримання сумісності маршрутів через усі раутери, бо інакше може виникнути петля раутінгу.

Важливо розрізняти мережеву топологію від архітектури раутінгу. Можна, наприклад, мати окрему систему ядра, яка охоплює багато магістральних мереж. Раутери ядра можна запрограмувати так, щоб вони не бачили віддалених архітектурних подробиць і обчислювали найкоротші маршрути. Однак, неможливо розділити систему ядра на підсистеми, кожна з яких утримувала б часткову інформацію без втрати функціональності, як це показано на рис. 3.48. Тут показано розділення архітектури раутінгу ядра на дві підсистеми раутерів, які утримують часткову інформацію і використовують маршрути за замовчуванням. Така архітектура призводить до виникнення петлі раутінгу для данограм, які мають неправильні (відсутні) призначення.

Рис. 3.48. Виникнення петлі раутінгу при поділі системи ядра на дві підсистеми.

Система раутерів ядра достатня, якщо мережа складається з одної магістралі та системи під’єднаних до неї локальних мереж (рис. 3.46). Кожен раутер знає про одну локальну мережу, до якої він під’єднаний і навчається про всі інші мережі, комунікуючись через магістраль з іншими раутерами. Однак, навіть коли всі раутери безпосередньо беруть участь у модифікації маршрутів, протокол діє незадовільно за винятком тривіальних мереж. По-перше, навіть коли кожен вузол (site), під’єднаний до загальної мережі, має тільки одну локальну мережу, архітектура ядра неадекватна, бо вона не може зростати, щоб пристосуватися до довільної кількості вузлів. По-друге, більшість вузлів містять багато локальних мереж і багато раутерів, які сполучають ці мережі. Оскільки раутер ядра повинен бути під’єднаний до одної мережі в кожному вузлі, то ядро знає тільки про одну мережу в цьому вузлі. По-третє, загальна мережа об’єднує систему мереж, керованих незалежними групами. Архітектура раутінгу мусить забезпечити кожній групі спосіб незалежного управління раутінгом і доступом.

Розглянемо архітектуру загальної мережі, яка складається з одної або більше магістральних мереж, охоплених системою раутерів ядра. Система ядра вважається центральним механізмом раутінгу, до якої периферійні раутери висилають данограми для доручення (рис. 3.49).

Рис. 3.49. Проблема надлишкового стрибка.

Відзначимо, що раутери ядра R1 і R2, під’єднані до локальних мереж 1 і 2, можуть досягнути кожну з них. Якщо ж периферійний раутер R3 вибере один з раутерів ядра, R1 або R2, для доручення данограм до мережі, з якою він не сполучений безпосередньо, то у багатьох випадках це спричинить появу надлишкового стрибка через магістральну мережу. Наприклад, вибір раутера R1 і висилання до нього данограми, призначеної для локальної мережі 2 викличе необхідність пересилання цієї данограми від R1 до R2 і далі до мережі 2, тобто надлишковий стрибок. Зауважимо, що переспрямування через протокол ICMP тут неможливе, бо повідомлення ICMP про переспрямування можуть бути вислані тільки до початкового джерела, а не до проміжного раутера. Тому потрібний механізм, який дозволив би периферійним раутерам вивчати маршрути від раутерів ядра, щоб вибрати оптимальний маршрут через магістраль.

Якщо вузол (site) маєбагато локадльних мереж і раутерів, які не під’єднані безпосередньо до ядра, то потрібен додатковий механізм, щоб система ядра знала про це. Розглянемо систему мереж і раутерів, зображену на рис. 3.50. Приймемо, що раутери R2, R3 і R4 мають маршрути до всіх чотирьох локальних мереж і маршрути за замовчуванням до раутера ядра R1. Станції, під’єднані до локальної мережі 4, можуть комунікуватися між собою, і будь-яка станція з мережі може маршрутувати пакети назовні до інших вузлів магістралі. Однак, оскільки раутер R1 під’єднаний тільки до локальної мережі 1, то він не знає про локальну мережу 4. Тому, з точки зору системи ядра, локальна мережа 4 невидима з локальної мережі 1. Тому потрібен механізм, який дозволяв би периферійним раутерам інформувати ядро про невидимі мережі.

Рис. 3.50. Під’єднання багатьох локальних мереж з раутерами до системи ядра.