Формат пакету RIPv1 для IP-застосувань

Рис. 3.53 показує формат RIP-пакету версії 1 (RIPv1) для IP-реалізації, як це визначено RFC 1058 для IP-мереж в Internet. Інші варіанти RIP містять незначні відмінності у форматах і/або назвах полів, але базовий алгоритм раутінгу залишається незмінним.

Рис. 3.53. Формат пакету RIP.

Поля RIP-пакету мають такі значення:

Команда (command) – позначає, чи пакет є запитом, чи відповіддю (1 – запит, 2 – відповідь). Команда-запит запитує систему-відповідач про вислання всієї або частини її таблиці раутінгу. Призначення, від якого очікується відповідь, вказане далі в пакеті. Команда-відповідь є реплікою на запит або, частіше, добровільною регулярною модифікацією раутінгу. У пакет-відповідь система-відповідач включає всю або частину своєї таблиці раутінгу. Регулярні повідомлення про модифікацію раутінгу включають цілу таблицю раутінгу.

Номер версії (version number) – визначає номер реалізованої версії RIP (для RIPv1 –це 1). При можливості багатьох реалізацій RIP в об’єднанні мереж це поле застосовується для сигналізації про різні, можливо несумісні реалізації.

Ідентифікатор сімейства адрес (Address family identifier) – наступне поле після 16-бітового поля, заповненого нулями, яке визначає конкретне сімейство адрес, яке використовується. Для Internet це звичайно сімейство IP-адрес (значення ідентифікатора дорівнює 2), однак можуть бути представлені також інші типи мереж.

IP-адреса мережі k (IP-address k) – слідує за іншим полем, заповненим нулями. Для Internet-реалізацій це поле звичайно містить IP-адресу k- ї мережі, до якої скероване повідомлення.

Метрика (metric) – слідує за двома 32-бітовими полями, заповненими нулями, і визначає лічильник стрибків. Лічильник стрибків для безпосередньо під’єднаного інтерфейсу дорівнює 1, а кожен проміжний раутер збільшує значення лічильника на 1 до максимального значення 15; значення лічильника 16 позначає відсутністьмаршруту до призначення.

В одному RIP-пакеті може міститися до 25 наборів полів від ідентифікатора сімейства адрес до поля метрики, тобто до 25 повідомлень для різних призначень. При 25 маршрутах повідомлення має довжину 25´20+4=504 байти, що відповідає максимальній довжині повідомлення у 512-байтовій данограмі UDP. Для переносу інформації від великих таблиць раутінгу використовуються багаточастинні RIP-пакети.

Подібно до інших протоколів раутінгу, RIP використовує певні таймери для регулювання своїх параметрів:

Таймер модифікації RIP-раутінгу t₁ у загальному випадку встановлюється на 30 с, тобто кожен раутер може вислати повну копію своєї таблиці раутінгу до всіх сусідів кожних 30 секунд.

Таймер нечинного маршруту t₂ визначає, скільки часу повинно минути до того, коли раутер, який обслуговує певний маршрут, сприйме маршрут як недійсний. Типове початкове значення для цього таймера дорівнює 90 с. Коли маршрут позначений як нечинний, то сусіди повідомляються про цей факт. Це повідомлення повинне з’явитися перед вичерпанням таймера вилучення маршруту t₃.

Коли таймер вилучення маршруту t₃ вичерпується, то маршрут видаляється із таблиці раутінгу. Типове початкове значення для цього таймера дорівнює 270 с.

Основні операції

При старті протокол RIP висилає повідомлення до всіх сусідів (через UDP-порт 520), запитуючи про копії таблиць раутінгу сусідів. Це повідомлення є запитом (команда=1) із сімейством адрес 0 та метрикою 16. Сусідні раутери відповідаютьпересиланням копій своїх таблиць раутінгу.

Коли RIP працює в активному режимі, він висилає всю свою таблицю раутінгу або її частину до всіх сусідніх раутерів (через широкомовні повідомлення або висилаючи їх через зв’язки “пункт-пункт”). Це здійснюється кожних 30 с. Таблиця раутінгу висилається як відповідь (команда=2, навіть коли не було запиту).

Коли RIP виявляє зміну метрики, він повідомляє про це інші раутери.

Коли RIP приймає відповідь, контролюється правильність повідомлення і локальна таблиця раутінгу при потребі модифікується. Для покращення характеристик і надійності RIP визначає, що як тільки раутер (або станція) отримав маршрут від іншого раутера, то він повинен зберігати цей маршрут, доки не отримає кращий (із строго меншою вартістю). Це запобігає коливаннм маршрутів між двома або більше шляхами з однаковою вартістю.

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

Маршрути RIP, отримані від інших раутерів, стають нечинними, якщо вони не будуть повторно оголошені протягом 180 с (6 циклів широкомовних повідомлень RIP. Коли маршрут стає нечинним, то його метрика встановлюється рівною 16 (невизначена), нечинність маршруту повідомляється сусідам даного раутера і після наступних 60 с маршрут видаляється із локальної таблиці раутінгу.

Обмеження протоколу RIPv1

Протокол RIPv1 має такі особливі обмеження:

Максимальне значення метрики дорівнює 16, що означає недосяжність мережі. Тому RIP є неадекватним протоколом для великих мереж, тобто таких, де лічильник стрибків може перевищувати значення 15.

RIPv1 не підтримує мережеві маски змінної довжини. У повідомленнях RIPv1 нема параметра, який визначав би мережеву маску, пов’язану з IP-адресою.

RIPv1 не має властивостей для того, щоб модифікації таблиць раутінгу походили від авторизованих раутерів. Він не є захищеним протоколом.

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

Протокол залежить від підрахунку до безмежності при розв’язанні певних непридатних ситуацій. Як описано раніше, розв’язання петель може вимагати великого часу (якщо частота модифікацій обмежена) або більшої ширини смуги (якщо модифікації пересилаються при виявленні змін). При збільшенні області раутінгу нестабільність алгоритму “вектор-відстань” при змінах топології виявляється все більше. RIP визначає механізми для мінімізації проблеми підрахунку до безмежності (що описане нижче), що дозволяє застосовувати RIP у більших областях раутінгу, але існує можливість, що цей протокол може бути нездатний вирішити це завдання. Не існує визначеної верхньої межі, але практичний максимальний розмір області раутінгу залежить від частоти змін у топології, її деталей і визначається максимальним прийнятним часом для стабілізації раутінгу.

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

Обмеження лічильника стрибків. RIP обмежує максимальне значення лічильника стрибків до 15. Кожне призначення, яке потребує понад 15 стрибків, позначається як недосяжне. Це максимальне значення лічильника стрибків дуже обмежує використання RIP у великих об’єднаннях мереж, але запобігає проблемі, відомій як підрахунок до безмежності при появі петель раутінгу. Проблема підрахунку до безмежності ілюстрована на 3.54.

Рис. 3.54. Проблема підрахунку до безмежності.

Розглянемо випадок, коли зв’язок a між раутером 1 та мережею A відмовив. Раутер R1 перевіряє свою інформацію і встановлює, що раутер R2 має сполучення із одним стрибком до мережі A. Оскільки R1 знає, що він безпосередньо сполучений із R2, то R1 інформує про двострибковий шляхдо мережі A і починає маршрутувати весь трафік до мережі A через R2. Це створює петлю раутінгу, бо R2 бачить, що R1 може з’єднатися із мережею A через два стрибки і модифікує вхід у власній таблиці раутінгу так, що він вказує на тристрибковий шлях до мережі A. Цей процес може продовжуватися в петлі раутінгу до безмежності або доки не досягнеться зовнішнє граничне обмеження. Таким зовнішнім обмеженням є максимальне значення лічильника стрибків. При перевищення значення 15 маршрут позначається як недосяжний, а потім видаляється із таблиці.

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

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

Розділення горизонту. Розділення горизонту випливає з факту непридатності пересилання інформації щодо маршруту в напрямку, зворотньому до того, звідки вона прийшла. Наприклад, розглянемо 3.55.

Рис. 3.55. Розділення горизонту.

Правило розділення горизонту допомагає запобігти виникненню петлі раутінгу мвж двома вузлами. Наприклад, розглянемо випадок, коли зв’язок через інтерфейс R1 до мережі A перерваний. Без розділення горизонту R2 продовжує інформувати R1, що R2 може пересилати інформацію до мережі A через R1. Якщо R1 не має достатнього інтелектуального забезпечення, то він може тепер спийняти маршрут від R2 як альтернативний до його перерваного безпосереднього зв’язку, викликавши цим появу петлі раутінгу. Хоч закріплення може запобігти цьому, однак розділення горизонту забезпечує додаткову стабільність алгоритму.

Заборона зворотніх модифікацій. Якщо розділення горизонту може запобігти виникненню петлі раутінгу між суміжними раутерами, то заборона зворотніх модифікацій (poison reverse updates) введена для виключення довгих петель раутінгу. Ідея полягає в збільшенні метрики, яка вказує на петлі раутінгу. Такі модифікаційні повідомлення висилаються для вилучення таких маршрутів і закріплення цього.

Розділення горизонту із забороною зворотніх модифікацій. Як вказано вище, проблема підрахунку до безмежності обумовлена тим фактом, що раутери A і C втягнені у взаємний обман. Кожен раутер вважає, що він здатний досягнути раутер D через другий. Цьому можна запобігти через більш дбайливе ставлення до того, яка інформація висилається. Зокрема, ніколи не варто вимагати досяжності мережі призначення через сусіда, від якого отриманий маршрут (тобто не використовувати зворотні маршрути). Схема розділення горизонту із забороною зворотніх модифікацій включає маршрути у модифікації, які висилаються до раутера, від якого ці маршрути були отримані, але встановлює їх метрику на безмежність. Якщо два раутери мають маршрути, які вказують раутери один на одного, то оголошення зворотніх маршрутів з метрикою 16 негайно перериває маршрутну петлю. Якщо зворотні маршрути просто не оголошуються (цю схему називають простим розділенням горизонту), то помилкові маршрути можуть бути вилучені через очікування на блокування за часом (timeout). Заборона зворотніх модифікацій має недолік: вона збільшує обсяг повідомлень раутінгу.

Модифікації із зовнішнім запуском. Розділення горизонту із забороною зворотніх модифікацій може запобігти виникненню будь-якої петлі раутінгу, яка включає тільки два раутери. Однак, все ще можлива схема, коли три раутери втягнені у взаємний обман. Наприклад, раутер A може вважати, що він має маршрут через раутер B, B через C і C через A. Ця ситуація не може бути розв’язана з використанням розділення горизонту. Така петля може бути розв’язана тільки тоді, коли метрика досягне значення “безмежність” і мережа або станція використають це, оголосивши про недосяжність. Модифікації із зовнішнім запуском повинні прискорити цю збіжність. Коли раутери змінюють метрику для маршрутів, то вимагається, щоб вони негайно висилали модифікаційні повідомлення, навіть коли ще не наступив момент висилання регулярного повідомлення. Протокол RIP визначає малий час затримки в межах 1..5 секунд з метою уникнення надлишкового мережевого трафіку, викликаного модифікаціями із зовнішнім запуском.

Формат пакету RIPv2

RIPv2 – це проект стандартного протоколу із статусом опційного. Він описаний у RFC 1723. RIPv2 розширює можливості RIPv1. Він менш потужний, ніж інші відповідні протоколи IGP, наприклад, OSPF або IS-IS, однак має переваги – простоту впровадження і менший обсяг службової інформації. RIPv2 опрацьований із наміром заміщення RIPv1 у мережах малого або середнього розміру, коли застосовується поділ на підмережі (subnetting) або на надмережі (supernetting), зокрема при застосуванні безкласового раутінгу (CIDR). RIPv2 може співпрацювати з RIPv1. Формат RIP-повідомлень для версії 2 розширений у порівнянні з версією 1, як це показано на 3.56, за рахунок використання полів, зарезервованих (заповнених нулями) для RIPv1. Перший від у повідомленнях може бути автентифікаційним входом, як показано на рисунку, або бути маршрутом, як у повідомленнях RIPv1. Якщо перший вхід автентфікаційний, то в повідомлення можуть бути включені до 24 маршрутів, в іншому випадку їх може бути до 25.

Значення полів у повідомленні RIPv2 аналогічні до таких у RIPv1, за вийнятком наступних:

Номер версії (version number) – дорівнює 2; інформує раутери, які підтримують RIPv1 про те, що вони повинні ігнорувати поля пакету, які для RIPv1 заповнені нулями.

Ідентифікатор сімейства адрес (Address family identifier) – може дорівнювати X’FFFF’ тільки для першого входу і позначає, що цей вхід – автентифікаційний.

Тип автентифікації (Autentification Type) – визначає, як повинні використовуватися наступні 16 байтів. Якщо тип автентифікації дорівнює 0, то це означає відсутність автентифікації, а тип автентифікації 2 означає, що наступні 4 поля містять дані пароля.

Дані автентифікації (Authentification Data) – пароль, який має довжину до 16 байтів, містить звичайний текст у коді ASCII, вирівняний вліво і доповнений (при потребі) нулями коду ASCII (X’00’).

Перший від у повідомленнях може бути автентифікаційним входом, як показано на рисунку, або бути маршрутом, як у повідомленнях RIPv1. Якщо перший вхід автентфікаційний, то в повідомлення можуть бути включені до 24 маршрутів, в іншому випадку їх може бути до 25.

Рис. 3.56. Формат пакету RIPv2.

Значення полів у повідомленні RIPv2 аналогічні до таких у RIPv1, за вийнятком наступних:

Номер версії (version number) – дорівнює 2; інформує раутери, які підтримують RIPv1 про те, що вони повинні ігнорувати поля пакету, які для RIPv1 заповнені нулями.

Ідентифікатор сімейства адрес (Address family identifier) – може дорівнювати X’FFFF’ тільки для першого входу і позначає, що цей вхід – автентифікаційний.

Тип автентифікації (Autentification Type) – визначає, як повинні використовуватися наступні 16 байтів. Якщо тип автентифікації дорівнює 0, то це означає відсутність автентифікації, а тип автентифікації 2 означає, що наступні 4 поля містять дані пароля.

Дані автентифікації (Authentification Data) – пароль, який має довжину до 16 байтів, містить звичайний текст у коді ASCII, вирівняний вліво і доповнений (при потребі) нулями коду ASCII (X’00’).

Позначка маршруту (Route Tag) – поле, впроваджене для комунікаційної інформації про джерело раутінгової інформації для взаємодії між RIP та іншими протоколами раутінгу. Впровадження RIPv2 повинні зберігати це поле, однак RIPv2 не визначає, як воно використовується далі.

Мережева маска (Subnet Mask) – пов’язана із підмережею, яка відноситься до даного входу.

Наступний стрибок (Next Hop) – рекомендація щодо наступного стрибка, який може використоати раутер для висилання данограми до підмережі або станції, вказаної у даному вході.

Для забезпечення взаємодії з RIPv1 документ RFC 1723 визначає такі обмеження на інформацію, яку висилають раутери RIPv2 для раутерів RIPv1:

інформація, внутрішня відносно однієї мережі, ніколи не повинна оголошуватися в іншій мережі;

інформація щодо більш специфічної підмережі не може оголошуватися, якщо раутери RIPv1 розглядають її як маршрут до станції;

маршрути до надмереж не повинні оголошуватися, якщо вони можуть бути неправильно інтерпретовані раутерами RIPv1.

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

 

Протокол OSPF

Протокол Open Shortest Path First – OSPF (“ відкритий - першим найкоротший шлях”) – це протокол раутінгу, опрацьований для IP-протоколу робочою групою внутрішніх шлюзових протоколів (Interior Gateway Protocol - IGP) IETF. OSPF опрацьований для використання в Internet та інших великих об’єднаннях мереж, оскільки протокол RIP нездатний обслуговувати великі неоднорідні (гетерогенні) мережі.

Як це випливає із назви, OSPF має дві основні особливості. Перша полягає в тому, що протокол є відкритим, тобто його спеціфікації є загальнодоступні та опубліковані в документі RFC 1247. Другою принциповою особливістю є те, що цей протокол базується на алгоритмі shortest path first (SPF), запропонованому Дійкстрою (Dijkstra).

Протокол OSPF описаний у RFC 1583, який замінив застарілий RFC 1247. OSPF є внутрішнім роаутінговим протоколом (IGP), але він спроектований для взаємодії із придатним зовнішнім протоколом раутінгу, наприклад, із BGP. OSPF – це значно складніший стандарт від RIP: його опис у RFC 1583 займає 216 сторінок порівняно із 33 сторінками для RFC 1058 (RIP) і 9 сторінками для RIP-2 (КАС 1723). Більша складність OSPF є наслідком окремих цілей: досягнення того, щоб топологічні бази даних були ідентичними для всіх раутерів всередині області. Оскільки база даних є основою для всіх рішень щодо раутінгу, то коли раутери мають незалежні бази даних, то вони можуть приймати взаємно протирічиві рішення.

OSPF здійснює комунікацію через протокол IP (номер протоколу 89).

Основи технології

OSPF є протоколом раутінгу з використанням метрики “зв’язок-стан”. Тому він запитує про оголошення стану зв’язків (Link State Advertisement - LSA) всі інші раутери всередині тієї самої ієрархічної області. До LSA включена інформація про під’єднані інтерфейси, використані метрики та інші змінні. Коли раутери OSPF нагромадять інформацію про стан зв’язків, то вони застосовують алгоритм SPF для обчислення найкоротшого шляху до кожного вузла.

Як протокол раутінгу з використанням стану зв’язків, OSPF відрізняється від RIP та IGRP, які є протоколами з використанням метрики “вектор-відстань”. Раутери, які вживають алгоритм “вектор-відстань”, висилають цілу таблицю раутінгу або її частину у повідомленнях модифікації раутінгу, але тільки до своїх безпосередніх сусідів.

Ієрархія раутінгу. На відміну від RIP, OSPF може діяти в ієрархічній структурі. Найбільшим об’єктом в ієрархії є автономна система (Autonomous System - AS). AS є множиною мереж під спільним адмініструванням, яка спільно використовує загальну стратегію раутінгу. OSPF є протоколом раутінгу всередині автономної системи (тобто внутрішньошлюзовим протоколом), хоч він здатний до приймання маршрутів від інших автономних систем та до пересилання маршрутів до них.

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

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

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

Магістраль (backbone) OSPF відповідальна за розподіл інформації раутінгу між областями. Вона складається із всіх граничних раутерів областей, мереж та під’єднаних до них раутерів, які не повністю містяться в будь-якій області. Рис. 3.57 показує приклад об’єднання мереж з декількома областями. На цьому рисунку раутери 4, 5, 6, 10, 11 і 12 утворюють магістраль. Якщо станція (гост) H3 в області 3 хоче вислати пакет до станції H2, то пакет висилається до раутера 13, який пересилає пакет до раутера 12, а він – до раутера 11. Раутер 11 пересилає пакет через магістраль до граничного раутера області 10, який висилає пакет через два внутрішньообласні раутери (раутер 9 і раутер 7) для доручення його станції H2.

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

Області можуть бути визначені таким чином, що частини магістралі не є суміжними. У цьому випадку зв’язність магістралі повинна бути відновлена через віртуальні зв’язки. Віртуальні зв’язки конфігуруються між довільними раутерами магістралі, які спільно використовують зв’язок із немагістральною областю, і діють аналогічно до безпосереднього зв’язку. Граничні раутери автономної системи, які використовують OSPF, вивчають зовнішні маршрути через зовнішній шлюзовий протокол (Exterior Gateway Protocol - EGP), граничний шлюзовий протокол (Border Gateway Protocol -BGP) або через конфігураційну інформацію.

Рис. 3.57. Ієрархічне об’єднання мереж для OSPF.

Нижче наведені окремі означення, необхідні для розуміння послідовності операцій, описаних нижче.

Область (Area) – множина мереж всередині окремої автономної системи, які можуть згруповані разом. Топологія області невидима для решти автономної системи і кожна область має окрему топологічну базу даних. Раутінг всередині автономної системи здійснюється на двох рівнях, залежно від того, чи джерело і призначення пакету розташовані в тій самій області (внутрішньообласний раутінг – intra-area routing), чи в різних областях (міжобласний раутінг – inter-area routing).

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

Міжобласний раутінг завжди здійснюється через магістраль.

Магістраль (Backbone) – складається із мереж, які не містяться всередині жодної області, раутерів, під’єднаних до них, а також із раутерів, які належать до багатьох областей. Магістраль мусить бути логічно цілісною. Якщо вона не цілісна фізично, то окремі компоненти повинні бути сполучені із використанням віртуальних зв’язків. Магістраль відповідає за розподіл раутінгової інформації між областями. Сама магістраль має всі властивості області; її топологія відокремлена від топології областей.

Граничний раутер області(Area Border Router) – раутер, під’єднаний до багатьох областей. Граничний раутер області має копії топологічних баз даних кожної області, до якої він під’єднаний. Він завжди є частиною магістралі. Граничні раутери областей призначені для поширення інформації для внутрішньообласного раутінгу в областях, до яких вони під’єднані.

Внутрішній раутер (Internal Router) – це раутер, який не є граничним раутером області.

Граничний раутер автономної системи (AS Border Router – ASBR) – раутер, якій здійснює обмін раутінговою інформацією з раутерами, розташованими в інших автономних системах. Всі раутери в AS знають шлях до всіх ASBR. Граничний раутер автономної системи може бути граничним раутером області або внутрішнім раутером. Він не мусить бути частиною магістралі.

Примітка. Назви раутерів цього типу різні. RFC 1583, який описує OSPF, використовує назву AS Boundary Router. RFC 1267 і RFC 1268, які описують BGP, вживають термін Border Router і Border Gateway. RFC 1340, який описує взаємодію між протоколами OSPF і BGP, використовує термін AS Border Router.

Віртуальний зв’язок (Virtual Link) – це частина магістралі. Його кінцеві пункти – це два граничні раутери областей, які спільно використовують немагістральну область. Зв’язок розглядається подібно до зв’язку “пункт-пункт” з метрикою, рівною міжобласній метриці між кінцевими пунктами зв’язку. Раутінг через віртуальний зв’язок здійснюється з використанням звичайного внутрішньообласного раутінгу.

Транзитна область (Transit Area) – область, через яку фізично сполучений віртуальний зв’язок.

Область-відгалуження (Stub Area) – область, сконфігурована для використання раутінгу за замовчуванням при раутінгу між автономними системами. Область-відгалуження може бути конфігурована, якщо вона має тільки один вихід із області, або якщо жодний вихід не може бути використаний без переваги для раутінгу до призначення поза автономною системою. За замовчуванням маршрути між AS копіюються до всіх областей, так що використання областей-відгалужень може скоротити вимоги до запам’ятовуючих пристроїв раутерів всередині таких областей для тих автономних систем, для яких визначені маршрути між AS.

Мережа з багатьма доступами (Multiaccess Network) – фізична мережа, яка підтримує зв’єязки із багатьма раутерами. Кожна пара раутерів у такій мережі вважається здатної до прямої комунікації.

Протокол Hello (Hello Protocol) – частина протоколу OSPF, яка використовується для встановлення і обслуговування відносин між сусідами.

Сусідні раутери (Neighboring Routers) – два раутери, які мають інтерфейси до спільної мережі. У мережі з багатьма доступами сусіди динамічно виявляються протоколом Hello. Кожен сусід описаний машиною станів, яка описує переговори між цим раутером і його сусідами. Короткий виклад значень станів наведено нижче.

Зупинений (down) – початковий стан переговорів між сусідами. Він означає, що вони не мають нової інформації, прийнятої від сусіда.

Спроба (attempt) – сусід неширокомовної мережі зупинений і намагається встановити контакт із нею через висилання регулярного пакету Hello.

Початок (init) – пакет Hello недавно прийнятий від сусіда, однак двостороння комунікація із сусідом ще не встановлена, тобто сам раутер ще не з’явився в пакеті Hello від сусіда.

Двошляховий (2-way) – у цьому стані комунікація між двома раутерами двостороння. Суміжність встановлена і сусіди у цьому стані або у вищих можуть бути вибрані як призначені (або резервні) раутери.

ExStart – два сусіди біля створення суміжності.

Обмін (exchange) – два сусіди повідомляють один одного про вміст своїх топологічних баз даних.

Завантаження (Loading) – два сусіди синхронізують свої топологічні бази даних.

Повний (full) – два сусіди тепер повністю суміжні; їх бази даних синхронізовані. Різні події обумовлюють зміну стану. Наприклад, якщо раутер приймає пакет Hello від сусіда, який зупинений (down), то стан сусіда змінюється на початок (init) і таймер неактивності стартує. Якщо таймер вичерпаний (тобто не прийняті подальші пакети OSPF перед вичерпанням таймера), то сусід може повернутися до стану зупинений.

Суміжність (adjacenty) – відношення, сформоване між вибраними сусідніми раутерами з метою обміну раутінговою інформацією. Не будь-яка пара сусідніх раутерів може здобути суміжнісь. Зокрема, не кожна пара раутерів може бути зсинхронізована. Якщо всі сусіди зсинхронізовані, то кількість зсинхронізованих пар у мережі з багатьма доступами, наприклад, у LAN, може становити n(n-1)/2, де n -кількість раутерів у LAN. У великих мережах трафік синхронізації може перевантажити мережу, зменшуючи її придатність. Концепція суміжності використовується для обмеження кількості пар, які синхронізуються, до 2n-1, завдяки чому обсяг трафіку синхронізації стає керованим.

Оголошення стану зв’язку (Link State Advertisiment) – відновисться до локального стану раутера або мережі. Включає стан інтерфейсів раутерів і суміжностей. Кожен стан зв’язку поширюється через домен раутінгу. Об’єднання оголошень стану зв’язку для всіх раутерів і мереж формує топологічну базу даних області.

Поширення (Flooding) – процес досягнення того, що кожне оголошення стану зв’язку пересилається між суміжними раутерами, щоб досягнути кожен раутер в області. Процедура поширення є надійною.

Призначений раутер (Designated Router) – кожна мережа із багатьма доступами, яка має щонайменше два під’єднані раутери, має призначений раутер. Призначений раутер генерує оголошення стану зв’язку для мережі з багатьма доступами. Призначений раутер вибирається протоколом Hello. Він отримує суміжність із усіма іншими раутерами у мережі. Оскільки топологічні бази даних всіх раутерів синхронізуються через суміжності, то призначений раутер відіграє головну роль у процесі синхронізації.

Резервний призначений раутер (Backup Designated Router) – щоб зробити перехід до нового призначеного раутера плавнішим, у кожній мережі із багатьма доступами використовують резервний призначений раутер. Резервний призначений раутер також суміжний з усіма раутерами в мережі і стає призначеним раутером, якщо попередній призначений раутер відмовив. Оскільки суміжності завжди існують між резервним призначеним раутером та всіма іншими раутерами, під’єднаними до мережі, то не потрібно формувати нові суміжності, коли резервний призначений раутер заміщає призначений раутер, скорочуючи необхідний час. Резервний призначений раутер вибирається протоколом Hello.

Інтерфейс (Interface) – сполучення між раутером та одною із під’єднаних до нього мереж. Кожен інтерфейс має інформацію стану, пов’яззану з ним, яка використовується підпорядкованими протоколами нижчих рівнів, а також самим протоколо OSPF. Короткий опис кожного стану наведений нижче:

Зупинений (down) – інтерфейс недоступний. Це початковий стан інтерфейсу.

Зворотна петля (loopback) – інтерфейс раутера, замкнений на нього ж. Не може вживатися для регулярного трафіку даних.

Очікування (waiting) – раутер має труднощі із визначенням призначеного раутера або резервного призначеного раутера.

Пункт-пункт (point-to-point) – інтерфейс є мережею пункт-пункт або віртуальним зв’язком. Раутер формує суміжність з раутером на іншому кінці.

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

Інший призначений раутер (DR Other) – це інтерфейс до мережі з багатьма доступами, однак цей раутер не є ані призначеним раутером, ані резервним призначеним раутером.

Резерв (Backup) – це резервний призначений раутер. Він стає призначеним раутером, якщо актуальний призначений раутер відмовив.

DR – це призначений раутер.

Метрики типу послуг (Type of Service metrics) – у кожному типі оголошень стану зв’язку можуть бути оголошені різні метрики для кожного типу послуг IP (Type of Service – TOS). Метрика для TOS 0, завжди повинна бути визначена; якщо це не так, то ці метрики приймаються рівними метриці, визначеній для TOS 0.

База даних стану зв’язку (Link State Database) – також називається спрямованим графом або топологічною базою даних; створюється із оголошень стану зв’язку, генерованих раутерами в області.

Примітка. RFC 1583 вживає термін Link State Database переважно до топологічних баз даних. Старий термін має ту перевагу, що він описує змість бази даних, новий є більш описовим стосовно завдань бази даних – опису топології області. З цих міркувань туту переважно вживається термін топологічна база даних, однак при розгляді подробиць операцій OSPF на неї посилаються як на базу даних стану зв’язку.

Дерево найкоротших шляхів (Shortest Path Tree) – кожен раутер виконує алгоритм Shortest Path First (SPF) длябази даних станів зв’язку, отримуючи дерево найкоротших шляхів. Дерево дає маршрут до будь-якої мережі-призначення або станції-призначення до меж області. Вони вживаються для побудови таблиці раутінгу.

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

Таблиця раутінгу (Routing Table) – містить входи для всіх призначень: мереж, підмереж і станцій. Для кожного призначення є інформація для одного або більше типів послуг (TOS). Для кожної комбінації призначення і типу послуг існують входи для одного або більше оптималдьних шляхів, які можна використати.

Ідентифікатор області (Area ID) – 32-бітове число, яке ідентифікує конкретну область. Магістраль має ідентифікатор області 0.

Ідентифікатор раутера (Router ID) – 32-бітове число, яке ідентифікує конкретний раутер. Кожен раутер всередині AS має окремий ідентифікатор. Можливим впровадженням є використання найменшої IP-адреси, яка належить раутеру, як ідентифікатора раутера.

Пріоритет раутера (Router Priority) – 8-бітове число без знаку, яке конфігурується через інтерфейс і вказує на пріоритет цього раутера при виборі (резервного) призначеного раутера. Пріоритет рактера 0 вказує, що цей раутер небажаний як призначений раутер.

Алгоритм SPF

Алгоритм раутінгу SPF є основою операцій OSPF. Коли SPF-раутер увімкнений, то він ініціює свої структури даних протоколу раутінгу та очікує на знаки від протоколів нижчих рівнів про те, що їх інтерфейси справні. Як тільки раутер встановить чинність інтерфейсів, він використовує протокол OSPF Hello для досягнення сусідів. Сусідами є раутери з інтерфейсами до спільної мережі. Раутер висилає пакети Hello до сусідів і приймає їх пакети Hello. Крім допомоги в осягненні сусідів, пакети Hello також діють як чергові, які дають раутерам знати про те, що інші раутери вс