4.4. Впровадження інтерфейсних рівнів до стандартної системи маршрутизації

Для організації взаємодії магістральних маршрутизаторів мережі Інтернет використовується спеціальний протокол BGP. Цей протокол реалізує складну систему автоматичної побудови зв’язків між магістральними маршрутизаторами, з елементами відмовостійкості та у відповідності до пірінгових угод між операторами зв’язку. Детальний огляд протоколу BGP виходить за межі даної роботи, тому ми лише відзначимо його ключові характеристики, важливі в контексті визначення локальності.

По-перше, основною функцією протоколу BGP є обчислення таблиці маршрутизації — спеціального зведення, яке задає комплексні правила пересилання транзитних пакетів трафіку на інтерфейси роутеру чи мережні шлюзи. Хоча сама таблиця маршрутизації оперує адресами з простору IPv4 та IPv6, вихідні дані для обчислень беруться у вигляді анонсів від автономних систем, які надають інформацію щодо доступних через таку систему діапазонів адресного простору IP та інших автономних систем доступних через дану. Можна відзначити, що за своєю функцією протокол BGP подібний до таблиці db-route в БД реєстрів з тією різницею, що оновлення вихідних даних щодо анонсованих автономними системами адрес та шляхів відбувається в реальному часі, тоді як в БД РРІ — щоденно. Ця інформація може бути використана для оцінки локальності вузлів по відношенню до даного шляхом визначення приналежності кожної адреси до автономної системи та подальшого пошуку відповідного шляху серед відомих між автономними системами. До певної міри інформація щодо таких шляхів дозволяє достовірно оцінювати топологічну структуру мережі на рівні операторів першого рівня (Tier 1).

По-друге, з огляду на вузький сектор його застосування та критичність для коректної роботи мережі Інтернет в цілому, до глобальної системи маршрутизації Інтернет за протоколом BGP мають доступ лише ті вузли мережі, які є пограничними маршрутизаторами операторів зв’язку другого рівня (Tier 2) та деякі multi-homed корпоративні мережі, управління якими здійснюється через власну зареєстровану автономну систему (Tier 3). Кінцеві користувачі, навіть у випадку великої мережі, які не мають потреби в гнучких правилах маршрутизації на єдиному зовнішньому каналі, або у яких для мережі відсутня автономна система, не підключаються до інфраструктури BGP, оскільки кожен зв’язок в ній повинен налаштовуватися явно обома сторонами пірінгової угоди.

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

Деякі проекти, такі як RouteViews та PlanetLab використовують інформацію, отриману з інфраструктури BGP для науково-дослідницьких цілей та власної оптимізації. Але для кінцевих користувачів, які складають переважну більшість оверлейних однорангових мереж, маршрутизація трафіку в Інтернет виконується абсолютно прозоро, а знання деталей поточного стану інфраструктури BGP не потрібні.

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

Автори [5] експериментально доводять, що застосування такої системи зменшує в 2-3 рази час затримки відповіді на запит даних в розподіленій хеш-таблиці, середню кількість переходів між автономними системами на кожен виклик та об’єм сумарного пробного трафіку.

Але в роботі [5] не приділено достатньої уваги питанню практичної реалізації доступу кінцевих користувачів до інформації з інфраструктури BGP — як один з практичних варіантів вказано науково-дослідницьку систему PlanetLab. З огляду на стрімкий розвиток ІТ на основі розосереджених мереж можна прогнозувати, що буде і відповідна кількість користувачів, зайнятих в таких мережах. Об’єми службового трафіку, що будуть згенеровані при постійній необхідності перевірки локальності для кожного вузла, що приєднується до мережі, можуть значно перевищити можливості будь-якої наглядової інфраструктури.

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