9. Динамічний раутінг

   1. Раутінг з частковою інформацією

Проектанти Internet вибрали архітектуру раутінгу, яка складається з малої центральної множини раутерів, які утримують повну інформації про всі можливі призначення, і великої множини віддалених раутерів, які утримують тільки часткову інформацію. Перевага використання часткової інформації у віддалених раутерах полягає у тому, що локальні адміністратори можуть керувати локальні структурні зміни, не впливаючи на решту Internet. Недоліком є те, що виникає можливість порушення цілісності. В найгіршому випадку помилка у віддаленому раутері робить недосяжним віддалений маршрут.

Раутери в ранньому Internet поділяли на дві групи: малу систему раутерів ядра, керованих централізовано, і велику множину периферійних раутерів (noncore router, stub router), керованих окремими групами. Система ядра спроектована для забезпечення надійних, цілісних та авторитетних маршрутів для всіх можливих призначень, що уможливлює універсальність взаємозв’язків. Кожен вузол, якому призначена IP-адреса, може забезпечити оголошення цієї адреси в системі ядра. Раутери ядра комунікуються між собою, що гарантує цілісність спільної інформації. Оскільки центральний орган моніторує і контролює раутери ядра, то вони є високонадійними.

Р ис. 3.45. Система раутерів ядра у магістралі глобальної мережі.

Для кращого зрозуміння системи раутерів ядра розглянемо рис. 3.45, на якому показано магістраль глобальної мережі, до якої через раутери ядра під’єднані локальні мережі. Нехай раутери R1, R2,…, Rn здійснюють побудову марштурів на підставі часткової інформації. Не знаходячи точного маршруту до призначення, кожен з цих раутерів вибирає маршрут за замовчуванням до наступного раутера, як це показано стрілками. З рис. 3.45 видно, що в найгіршому випадку данограма пересилається від джерела до призначення через усі n раутерів, замість того, щоб скеровуватися безпосередньо через магістраль до потрібного раутера.

Щоб уникнути такої неефективності, проектанти Internet організували обмін раутінговою інформацією між усіма раутерами ядра, так що кожен з них має повну інформацію про оптимальні маршрути до всіх можливих призначень. Тоді раутери ядра не потребують використовувати маршрути за замовчуванням. Периферійні раутери G1…Gn утримують інформацію про локальні призначення і використовують маршрути за замовчуванням до раутерів ядра.

Р ис. 3.46. Система ядра і периферійні раутери.

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

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

Розглянемо архітектуру мережі, яка має дві рівнозначні магістралі, сполучені між собою (рис. 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. Під’єднання багатьох локальних мереж з раутерами до системи ядра.