CC BY
16
4. Шенк Х. Теория инженерного эксперимента /Х. Шенк/. - М.: Мир, 1972.
- 384 с.
5. Вентцель Е.С. Теория вероятностей. /Е.С. Вентцель/ - М.: Наука, 1969. - 576 с.
6. Справочник по теории вероятностей и математической статистики / [Королюк В.С., Портенко НИ., Скороход А.В., Турбин А.Ф.]. - М.: Наука, 1985. - 640 с.
7. Гмурман В.Е. Руководство к решению задач по теории вероятностей и математической статистике. / Гмурман В.Е. - М.: Высшая школа, 1975.
- 146 с.
8. Статистика: тдручник /А.В. Головач, А.М. Срша, О.В. Козирев та шш; за ред.. А.В. А.В. Головача, А.М. Срино'1, О.В. Козирева. - К.: Вища школа, 1993. -623 с.
Анотацн:
Наведеш методика та результати експериментального дослщження напруги вщпускання аваршних реле зал1знично1 автоматики.
Ключовi слова: реле, напруга выпускания, штервал, допуск.
Представлены методика и результаты экспериментального исследования напряжения отпускания аварийных реле железнодорожной автоматики.
Ключевые слова: реле, напряжение отпускания, интервал, допуск.
Presented methods and results of the experimental study of the voltage of the unhooking emergency relay railway automation.
Keywords: relay, voltage of the unhooking, interval, tolerance.
УДК 656.212.5:681.3
ПАХОМОВА В. М., к.т.н., доцент (ДНУЗТ).
Дослщження запоб^ання нестабшьностям роботи протоколу RIP на програмнш моделi
Вступ
Дистанцшно-векторний протокол RIP (Routing Information Protocol) - один з найбшьш розповсюджених протоколiв внутршньо'1 маршрутизацп в
комп'ютерних мережах, яю дозволяють маршрутизаторам динамiчно оновлювати маршрутну iнформацiю, отримуючи ïï вiд сусщшх маршрутизаторiв. На жаль, пове-дшка дистанцiйно-векторних протоколiв (i зокрема, протоколу RIP) при змЫ топологи системи не завжди коректна та пе-редбачувана. Основна проблема - зацик-лювання, тобто даннi, адресован в певну мережу будуть пересилатися мiж двома
вузлами до тих тр, поки не закiнчиться час життя дейтаграм i вони не будуть знищеш [1]. Для того, щоб уникнути за-циклювання, в алгоритм розсилки векто-рiв вщстаней вносяться наступнi допов-нення: 1) якщо дейтаграми, адресованi в мережу Х, надсилаються через маршрутизатор О, що знаходиться в мережi Ы, то в векторi вщстаней, що розсилаються в ме-режi Ы, вiдстань до мережi Х не вказу-еться; 2) якщо маршрутизатор О оголошуе нову вщстань до мережi Х, то ця вщстань вноситься в таблицi маршру^в вузлiв, вь дправляються дейтаграми в мережу X через О, незалежно вщ того, бшьше вона чи менше вже внесено! в таблиц вiдстанi.
Очевидно, що при виконанш вищевказа-них умов, зациклювання не утворюються та будуються коректш маршрути. Однак, таким чином, усуваються далеко не всi випадки зациклювання.
Анал1з дослщжень та публ1кац1й
Дистанщино-векторт алгоритмы DV (Distance Vector) засноваш на обмЫ дуже незначним обсягом шформацп. Передбачасться, що кожен об'ект (маршрутизатор або хост), який бере участь в обмЫ шформащею, зберiгаe вiдомостi про вах одержувачiв в системi. У загальному випадку iнформацiя про вах пiдключених до одша мережi об'екпв збираеться в единий запис, який описуе маршрут до всiх одержувачiв у данiй мережi [1]. Потрiбно зберiгати для кожного одержувача таю вщомосп: IP-адреса хоста або мережц перший маршрутизатор на шляху до одержувача; фiзичний iнтерфейс, який
використовуеться для зв'язку з першим маршрутизатором; метрика (число, що показуе «вщдаленють» одержувача); таймер (час, який минув з моменту останнього оновлення запису). Ця база даних iнiцiалiзуеться з описом об'ектiв, якi безпосередньо пщключеш до системи, а потсм оновлюеться згiдно з iнформацiею, що одержуеться в повщомленнях вiд найближчих сусвдв. Найбiльш важлива iнформацiя мiж маршрутизаторами передаеться в оновленнях (update message). Кожен об'ект, бере участь у схемi маршрутизацп, передае оновлення, що описують поточний стан свое'1' маршрутно'1' бази даних.
У простих мережах в якосп метрики природно використовувати лiчильник iнтервалiв (хопiв) до одержувача. У бшьш складних мережах метрика може враховувати величину затримки, витрати на доставку та iншi параметри, яю можуть впливати на вибiр маршруту.
Нехай D(i,j) являе метрику кращого маршруту вщ об'екта i до об'екта j (ця метрика повинна бути визначена для кожно'1' пари об'ектiв); d(i,j) представляе вартють окремих крокiв. Припустимо, що d(i,j) являе вартють прямо'1' доставки вщ i до j. Ця вартють буде нескшченою, якщо i та j не е прямими сусщами.
Краща метрика описуеться виразом D(i,i)=0, D(i,j) =min[d(i, k) +D(k,j)] i найкращий маршрут вщ i слiдуе до сусiда k, для якого d(i,k)+D(k,j) мае мЫмальне значення. Вщзначимо, що друге рiвняння вiдноситься до вузла k, що е безпосередшм сусiдом i. Для шших випадкiв значення d(i,k) нескшченне i нiколи не може давати мЫмуму. З наведеного доказу очевидно, що можна побудувати простий алгоритм розрахунку вартостi для будь-якого маршруту. Об'ект i запитуе у свого сусща k його ощнку вiдстаней до адресата i тсля цього до кожного з отриманих значень просто додаеться d(i,k). Пюля цього i може порiвняти значення, отримаш вiд усiх сусiдiв i визначити найбiльш «дешевий» шлях [1].
Робота даного алгоритму заснована на припущенш, що кожен об'ект збер^ае коп11' ощнок, отриманих вiд всiх сусiдiв, i визначае мiнiмальне значення з використанням цих копш. При отриманнi вщомостей про бiльш привабливу метрику до запису вносяться вщповщш корективи. Такий пщхщ дозволяе iстотно скоротити обсяг обчислень i розмiри збережених таблиць [2].
Протокол RIP мютить низку доповнень до базового алгоритму DV. Кожен об'ект, який бере участь в робо^ протоколу, повинен виконувати наступш процедури.
- Пщтримка таблицi з записом для кожного можливого одержувача в системь Запис мютить вщомосп про «вiдстанi» до адресата D i першi маршрутизаторi (G) на шляху до адресата
[3].
- Перюдична розсилка кожному сусiдовi повiдомлень про змшу маршрутiв. Таке оновлення являе собою набiр повiдомлень, що мiстять всю шформащю з маршрутно' таблицi. Оновлення мютить запис для кожного одержувача з зазначенням дистанци до нього.
- Коли приходить оновлення вщ сусща G, до нього додаеться вартють для мережi, пов'язано' з G (це мае бути мережа, через яку прийнято оновлення). Пюля цього обчислюеться результат дистанцп D i проводиться порiвняння iз записами поточно'' таблищ маршрутизаци. Якщо нова дистанщя D' для адресата N менше юнуючого значення D, приймаеться новий маршрут. Таким чином, в запис для адресата N включатиме дистанцiю D' i маршрутизатор G. Якщо маршрутизатор G е тим, з якого починаеться юнуючий маршрут (тобто, G- G), нова метрика D' мае включатися в таблицю навiть у тих випадках, коли вона перевищуе стару.
Передбачаеться, що кожний маршрутизатор, який пщтримуе RIP, мае таблицю маршрутизаци. Ця таблиця мае один запис для кожного адресата, досяжного через систему, яка використовуе RIP. У кожного запису повинш мютитися наступнi вiдомостi: адреса IPv4 для одержувача; метрика, яка представляе загальну вартють доставки дейтаграми вщ маршрутизатора до адресата; адреса IPv4 для наступного маршрутизатора на шляху до адресата (next hop); прапор, який показуе, що шформащя про маршрут була нещодавно змшена (route change flag); рiзнi таймери, пов'язаш з маршрутом. Кожен запис мае мютити також маску пщмережь Маски разом з адресою IPv4 для одержувача дозволяють маршрутизатору
щентифжувати рiзнi пiдмережi в однш мережi, а також враховувати маски вщдалених пiдмереж [4]. Можливо введення додаткових маршрутiв (це маршрути до хоспв чи мереж за межами видимосп системи маршрутизаци), такi
маршрути називають статичними (static route).
В протоколi RIP е два типи повщомлень, якими обмiнюються маршрутизатори: вщповщь (response): розсилка вектору вiдстанi; запит (request): маршрутизатор запрошуе у сусвдв 'х маршрутнi таблицi чи данш про певний маршрут. Формат повщомлень обох титв однаковий, загальний вигляд яких приведений в [4].
Створення таблиць маршрутизаци. Таблицею маршрупв називають таблицю, яка е результатом дiяльностi протоколу RIP, що складаеться з рядюв з полями «Мережа», «Вщстань», «Наступний маршрутизатор». Вектором вiдстаней називаеться набiр пар («Мережа», «Вiдстань до ще'1 мережi»), витягнутий iз таблищ маршрупв; кожну таку пару називають елементом вектора вщстаней
[3].
Кожен маршрутизатор, на якому запущено RIP, перюдично широкомовно поширюе свiй вектор вщстаней. Вектор поширюеться через ва штерфейси маршрутизатора, пiдключених до мереж, що входять до RIP-системи. Кожен маршрутизатор також перюдично отримуе вектори вщстаней вщ iнших маршрутизаторiв. Вщстань в цих векторах збшьшуються на 1, тсля чого порiвнюються з даними в таблищ маршрупв, i, якщо вщстань до яко'сь з мереж в отриманому векторi виявляеться менше вщсташ, вказано' в таблищ, значення з таблищ замщуеться новим (меншим) значенням, а адреса маршрутизатора, що надюлали вектор з цим значенням, записуеться в полi «Наступний маршрутизатор» в цьому рядку таблищ. Пюля цього вектор вщстаней, що розсилаються даними маршрутизатором, вщповщно змшиться.
Цш1 статт1
Ознайомитися з можливими способами передачi маршрутних оновлень
та запропонувати вщповщну формальну модель. Розробити програмну модель RIP, в основi яко'1 запропонована формальна модель. На програмнш моделi провести дослiдження часу перебудови таблиць маршрутизаци за рiзними методами.
Основний матер1ал
Робота 3i змшами топологи. На практищ маршрутизатори та канали ма-ють властивiсть «падати» i вiдновлювати свою працездатнiсть. Для того, щоб вра-ховувати такi особливосп, потрiбно внести в алгоритм деяю змiни. Теоретичний варiант алгоритму використовуе шформа-цiю вiд у ах найближчих сусiдiв. При змiнi топологи змшюеться i набiр сусiдiв. У результат тако'1 змiни при подальшому розрахунку цi змiни будуть враховаш. Однак, як було зазначено вище, в реаль-них програмах використовуеться варiант мiнiмiзацii з урахуванням зростання (incremental version of the minimization), при якому запам'ятовуеться тшьки кра-щий маршрут. Якщо маршрутизатор, включений у цей маршрут «падае», або розриваеться мережне з'еднання, розраху-нок може не вщобразити таких змш. У ре-альних системах алгоритм залежить вiд способу, використовуваного маршрутизатором для передачi повщомлень про змiну топологи. Якщо маршрутизатор припиняе працювати, у нього вже немае можливосп повiдомити сво'1'х сусiдiв про змiну топологи. Для вирiшення ща проблеми прото-коли на основi алгоритмiв DV повинш ви-користовувати поняття тайм-ауту для ма-ршрутизаторiв. Деталi реалiзацii залежать вiд конкретного протоколу.
Так, зокрема, в протоколi RIP кожен маршрутизатор передае оновлення вам сво'1'м сусщам кожнi 30 с. Вщзначимо, що для оголошення маршруту некоректним необхiдно чекати протягом 180 с. Це зроблено для того, щоб позбутися вщ по -милкових тайм-аутовi в результат втрати паке™ при констатаци тайм-ауту в результат вiдсутностi одного повщомлення.
Для шдикаци недоступностi мережi використовуеться спещальне значення метрики (16 в протокш RIP). Це значення зазвичай трактуеться як «нескшченнють», оскiльки воно перевищуе всi iншi зна-чення метрики.
Запобиання нестабшьностям. Алгоритм DV буде завжди забезпечувати маршрутизаторам можливiсть розрахунку ко-ректно'1 таблиц маршрутизаци, однак на практицi тако'1 можливостi виявляеться недостатньо. Алгоритм DV лише гарантуе сходження розрахункiв для таблиць маршрутизаци за кшцевий час, однак немае жодних гарантш, що цей час буде досить малим i незрозумiло, що може вщбутися з метрикою, коли мережа стане недоступною. Математичну сторону алгоритму досить просто розширити для обробки мар-шрулв, що стали недоступними. Запропо-нованi вище угоди дозволяють це зро-бити, просто вказавши досить велике значення метрики для недоступних мереж. Це значення повинне перевищувати будь-яку реально використовувану метрику (значення 16 в якост метрики для недоступних мереж).
Припустимо, що мережа перестала бути доступною. Вс сусщш з нею марш-рутизатори перестануть бачити мережу i тсля тайм-ауту встановлять для не! метрику 16. Для аналiзу можемо припустити, що вс сусщш маршрутизатори отримали пряме з'еднання з мережею, що зникла, щ з'еднання характеризуються метрикою 16. Оскшьки зi зниклою мережею е тiльки одне з'еднання, вс iншi маршрутизатори в системi будуть сходиться до нових марш-рутiв, що проходять через один iз сусiднiх з зниклою мережею маршрутизаторiв. Легко побачити, що тсля сходження розрахунку всi сусщш маршрутизатори отримають для зникло'1 мережi метрику не менше 16. Маршрутизатори, що слщують за найближчими сусщами (1 хоп), отримають метрику не менше 17, що слщують за ними - не менше 18 i т. д. Оскшьки вс щ значення перевищують максимум, метрика буде встановленою 16. Зазвичай системи будуть сходитись на значенш 16
в якост метрики для зникло' мережi. На жаль, питання про час сходження розра-хунюв не настiльки простий.
Найгiрша ситуащя виникае в тих ви-падках, коли мережа стае повнютю недоступно' з яко'сь частини системи. У таких випадках метрика повшьно збшьшуеться, поки не буде обчислено недоступнють, такi ситуаци називаються «обчислення нескiнченностi» (counting to infinity). 3i сказаного можна зрозумiти, чому для «не-скшченно'» метрики вибрано настшьки мале значення. Якщо мережа стае повш-стю недоступною, необхiдно виявити недоступнють якомога скорше. Значення метрики для недоступно' мережi повинно бути бшьше метрики будь-якого реального маршруту, але нщо не вимагае збь льшувати його додатково. Таким чином, вибiр метрики для недоступно' мережi ви-значаеться компромюом мiж розмiром мережi та швидкютю «обчислення нескш-ченностi». Для запоб^ання проблем, по-дiбних до описано'', юнуе кiлька способiв.
Розщеплення горизонту (Split horizon) являе собою схему запоб^ання проблем, викликаних включенням маршруту в оновлення, що передаються маршрутизатору, вщ якого була отримана шфо-рмащя про даний маршрут. Проста схема розщеплення горизонту (Simple split horizon) опускае маршрути, отримаш вщ сусща при передачi оновлень цьому сусь довi. Схема «Split horizon with poisoned reverse» включае там маршрути в оновлення, але встановлюе для них нескш-ченну метрику (анонсування недоступно-сп зворотного маршруту).
Оновлення подгею (Triggered update) е спробою прискорити процес сходження метрики. Для використання Triggered update просто додаеться правило, за яким маршрутизатор, змшюючи метрику на шляху, повинен передати повщомлення про це, не чекаючи часу штатно' передачi оновлення. Промiжок часу, по закшченню якого повинно передаватися таке повщомлення, залежить вщ протоколу.
Припустимо, що шлях вщ маршрутизатора в мережу N проходить через ма-
ршрутизатор G. Якщо оновлення приходить безпосередньо вщ G, який прийняв його, маршрутизатор повинен довiряти отримано' шформаци незалежно вщ знаку змiни метрики. Якщо в результат метрика змiнюеться, прийняв оновлення маршрутизатор буде передавати в зв'язку з щею подiею оновлення (Triggered updates) вам маршрутизаторам, безпосередньо пщклю-ченим до нього. Кожен з вузлiв, що одержали оновлення, може передати його сво'м сусщам. У результатi виникае каскад оновлень. Легко побачити, яю марш-рутизатори будуть залученi в цей каскад. Припустимо, що маршрутизатор G фшсуе тайм-аут для доступу в мережу N. У результат ще' поди G передаватиме оновлення вам сво'м сусщам. Однак довь ряться цьому оновленню тшьки ri марш-рутизатори, чи' маршрути в мережу N проходять через G. Решта маршрутизато-рiв побачать цю iнформацiю про новий маршрут, який вони використовують, i просто про^норують оновлення. Сусiди, чи' маршрути проходять через G, онов-лять свою метрику та вщправлять Triggered update вам сво'м сусщам. I знову щ оновлення будуть сприйня^ лише тими маршрутизаторами, для яких шлях в мережу N проходить через G. Таким чином, оновлення поди назад по вах шляхах, отриманими вщ маршрутизатора G, встановлюють для цього шляху нескш-ченну метрику. Поширення оновлень припиниться, як тшьки вони попадуть в ту частину мереж^ звщки шлях у N йде через iншi маршрутизатори. Якщо система збе-р^ае «спокшний» стан, поки поширю-еться каскад оновлень, «обчислення не-скiнченностi» школ и не буде потрiбно. «Поганi» маршрути завжди будуть не-гайно видалятись i петель в маршрутизацii виникати не може. На жаль, в реальности все складшше. Доки передаються оновлення поди, можуть бути згенероваш та переданi штатнi оновлення. Маршрутизатори, ще не отримали оновлення поди, будуть продовжувати розсилку шформа-ци, яка мютить недоступний маршрут. Можливо також пюля прийому оновлення
поди отримання штатного оновлення вщ маршрутизатора, який ще не отримав оно-влення поди. В результат цього статус недоступного маршруту може бути вщновлений некоректно (як доступного). Якщо оновлення по подiях розсилаються
Формальна модель за протоколом RIP. Розроблена дiаграма сташв за протоколом RIP, що представлена на рис. 1. Робота протоколу починаеться з iнiцiалiзацii (стан «Механiзм маршрутних таблиць»); в кожному маршрутизаторi створюеться мжмальна таблиця маршрутизаци, в якш враховуються тiльки безпосередньо приеднанi мережу а також встановлюються таймер тайм-ауту Ттайм=180 с та таймер розсилки Трозс=30 с.
Якщо мережа, штерфейс та маршрутизатор працездатнi, то вщбуваеться перехiд в стан «Розсилка векторiв», де всiм сво!'м сусiдам вщсилаються повiдомлення RIP, в якому
часто, вiрогiднiсть такох поди стае досить великою. Однак можливють «обчислення нескшченносп» зберiгаеться. Порiвняльна характеристика способiв передачi маршрутних оновлень наведена в табл.1.
мютяться таблицi маршрутизаци. (На першому етат це обмiн мiнiмальними таблицями, в подальшому обмiн оновленими таблицями). Цей етап контролюеться таймером розсилки, при цьому працюе мехашзм часу життя маршруту, кожен запис таблиц маршрутизаци, отриманий по протоколу RIP, мае час життя (TTL). При надходженш чергового RIP-повщомлення, яке тдтверджуе справедливiсть цього запису, таймер TTL встановлюеться в початковий стан, а потсм з нього кожну секунду вщшмаеться одиниця. По закшченню Трозс повернення в стан «Мехашзм маршрутних таблиць».
Таблиця 1. Порiвняльна характеристика способiв передачi
Split horizon Split horizon with poisoned reverse Triggered update
призначення розрив петель мiж парою маршрути-заторiв розрив петель мiж парою маршрутизаторiв розрив петель мiж трьома маршрутизаторами
споаб вилучення маршру-тiв отриманих вiд сусща при передачi йому оновлень анонсування маршрутiв, отриманих вщ сусiда з метрикою 16 додаеться правило, маршрутизатор змь нюючи метрику, повинен це передати
недолiки не вiдображае вах змiн збiльшення об'ему повщомлення зростання об'ему мережного трафшу
коментарi реалiзують в якостi опцш в залежностi вiд потреб, оскшьки обидва способи не е ушверсальними та доповнюють один одного часто використовуеться протягом деякого часу пiсля змш, а потiм вiдключаеться
по зактченню
Т......
по зактченню
T
вихгдне джерело
0<Метрика<15
Метрика > 14
штдництво
ПЕРЕИРКА ДЖЕРЕЛА 1НФОРМАЦП
Рис. 1. Дiаграма сташв за протоколом RIP.
Якщо мае мiсце збiй обладнання, то перехщ в стан «Мехашзм тайм-ауту»; якщо тайм-ауту незавершений (Ттайм>0), то вiдбуваеться перехiд в стан «Очшування приходу повiдомлення», при отриманш якого перехiд в стан «Аналiз повi домлення».
Якщо 1<метрика<15, то перехщ в стан «Механiзм маршрутних таблиць», якщо метрика>14, то перехiд вщбуваеться в стан «Перевiрка джерела шформаци», в якому маршрутизатор повинен
перевiрити, виходить ця «погана» шформащя про мережу вiд того ж маршрутизатора, повщомлення якого послужило в свш час пiдставою для запису про дану мережу в таблицю маршрутизаци. Якщо це той же маршрутизатор, то шформащя вважаеться достовiрною, здшснюеться перехiд в стан «Мехашзм тайм-ауту»; якщо ж
шформащя прийшла не вщ того маршрутизатора, вщ якого вона була отримана рашше, вважаеться що збiй в мережi (шкiдництво) i таке повiдомлення ^норуеться, вiдбуваеться перехiд в стан «Мехашзм маршрутних таблиць» i процес повторюеться.
Програмна модель «RIP». Розроб-лена програмна модель «RIP» мае певш обмеження: мережа складаеться з чоти-рьох маршрутизаторiв; маршрутизатори мають чггко фiксоване положення на ек-раш; мережа, що вийде з строю, задаеться перед запуском модели затримка мiж кро-ками алгоритму залежить вщ апаратного забезпечення. Програмна модель реалiзуе роботу протоколу RIP, що дозволяе вщо-бразити динамiчне оновлювання маршру-тно'1 шформаци, отримуючи й вiд сусiднiх маршрутизаторiв, при цьому вихщ з не-
стабшьних ситуацiй реалiзуеться у двох режимах: тайм-аут та Split horizon.
Мережа мае двi характеристики: IP-адресу та номер маршрутизатора (номер порту, через який зв'язаний з мережею). Маршрутизатор описаний наступними складовими: мережа, ном ери портив вiдносно маршрутизатора та вщносно мережi. При запуску програмно:1 моделi
«RIP» на екранi з'являеться головна форма. Необхщно обрати: мережу, яка вийде з строю в процес моделювання; метод перебудови таблиць маршрутизаци: тайм-аут та Split horizon; режим запуску модели «Результат» (дозволяе отримати кiнцевi даш), «Демонстрацiя» (для поетапного вщображення роботи протоколу).
IIIIIIIIIII1IIIIIIIIIIIIIIIII
Структура таблиц
__1-номер мереж)
2-номер порту в пщмервхв ■ | омвр пор ту Bi дно оно маршрутизатора
4-метрика
L 31
Рис. 2. Результат роботи програмно:1 моделi «RIP» за механiзмом тайм-ауту.
Результуючi дат. Проведена серiя запускiв програмно:1 моделi «RIP» в рiзних режимах та з рiзними початковими даними. Кожний варiант таких даних задавався для пошуку в двох режимах. Результати, що видавались програмною моделлю, проаналiзованi на правильнiсть роботи алгоритму та на кшькють операцiй, що необхщш для побудови таблиць маршрутизаци. Одною з найважливших характеристик протоколiв маршрутизаци е динамiчна модифiкацiя маршрутизаци при змЫ топологи мережi,
яку можна проаналiзувати на основi часу моделювання, кроюв та складностi реалiзацii.
Час моделювання за механiзмом тайм-ауту склад ае 1500 одиниць модельного часу, кшькють кроюв варiюеться вiд 10 до 13, а за методом Split horizon час становить 500 одиниць модельного часу, кшькють кроюв вщ 5 до 7. Зазначимо, що кшькють кроюв першого варiанту значно перевищуе кiлькiсть крокiв в другому. Кшькють кроюв залежить вщ того яка мережа вийшла з
строю: якщо сумiжна, наприклад, 2, 4, 5, 6, то оновлення таблиць та встановлення стабшьно'1 роботи вщбуваеться за меншу кшькють кроив у порiвняннi з крайшми мережами 1, 3, 7, 8.
По складност реалiзащï мехашзм тайм-ауту потребую бiльшоï кiлькостi
На рис. 2-3 пред став лет результати запуску програмно'1' моделi «RlP» при од-накових початкових даних за рiзними методами перебудови таблиць маршрутиза-ци: тайм-аут i Split horizon. При цьому отримаш результати однаковi, що доводить правильнють роботи створено'1' модель Сходження розрахункiв для таблиць маршрутизаци вщбулося за кiнцевий час моделювання.
Висновки
1. За протоколом RIP на основi стандарту RFC 2453 розроблено форма-
обчислювальних операцш, при цьому не вирiшуе вс проблеми; метод Split horizon е дещо простiше в реалiзацГï та значно скорочуе об'ем трафшу, що передаеться, за рахунок технологи розбиття горизонту.
льну модель, що мютить наступш стани: механiзм маршрутних таблиць, розсилка векторiв, механiзм тайм-ауту, очшування повiдомлення, аналiз повiдомлення, пере-вiрка джерела iнформацГï. При стабiльнiй робот мережi застосування механiзму тайм-ауту дае досить добрий результат.
2. Серед способiв передачi маршрутних оновлень розрiзняють: Split horizon, Split horizon with poisoned reverse, Triggered update, основне призначення яких це розрив петель. На програмнш мо-делi «RIP» визначено, що рацiонально ви-користання методу Split horizon, що дае
Рис. 3. Результат роботи програмноï' моделi «RIP» за методом Split horizon.
змогу будувати коректш таблиц маршрутизацп та значно скоротити час !х побу-дови в комп'ютерних мережах.
3. Доцшьно надавати можливiсть вибору режиму розщеплення горизонту (простий або з анонсування недоступностi зворотного шляху) в якосп опци. Допустима реалiзацiя гiбридних схем, коли ано-нсуеться недоступнiсть (метрика 16) лише для частини зворотних маршрутiв. Прикладом такоi схеми буде використання метрики 16 для зворотних маршрупв протя-гом деякого часу тсля змiни маршрутизацп та вщмова вiд таких анонсiв по закш-ченнi часу.
Список лггератури
1. Малкин Ж.. И. Стандарт протоколу RIP RFC 2453 [Текст] / Ж.. И. Малкин. - СПб: Питер, 1998.
2. Семенов Ю. А. Телекомукацион-ные технологии [Електроний ресурс] / Ю. А. Семенов. - http://book.itep.ru
3. Берлин А. Н. Основные протоколы интернет [Електроний ресурс] / А. Н. Берлин. - http://www.intuit.ru
4. Олифер В. Г. Компьютерные сети. Принципы, технологии, протоколы [Текст] / В. Г. Олифер, Н. А. Олифер. -СПб.: Питер, 2006. - 958 с.
Анотацн:
Складена формальна модель роботи протоколу RIP, яка покладена в основу розроблено! програмно! модел1, що дозволяе вщобразити динам1чне оновлювання маршрутно1 шформацп, отримуючи ii в1д суадшх маршрутизатор1в, при цьому вихщ з нестаб1льних ситуацш реал1зуеться за мехашзмом тайм-ауту та
методу Split horizon. Встановлено, що використання методу Split horizon дае змогу будувати коректш таблищ маршрутизацп та значно скоротити час !х побудови в комп'ютерних мережах. Визначено, що доцшьно надавати можливють вибору режиму розщеплення горизонту: простий або з анонсування недоступносл зворотного шляху.
Ключовi слова: метрика, таблиця маршрутизацп, зациклювання, тайм-аут, розщеплення горизонту, оновлення подiею.
Составлена формальная модель работы протокола RIP, которая положена в основу разработанной программной модели,
позволяющей отобразить динамическое обновление маршрутной информации, получая ее от соседних маршрутизаторов, при этом выход из нестабильных ситуаций реализуется по механизму тайм-аута и метода Split horizon. Установлено, что использование метода Split horizon позволяет строить корректные таблицы маршрутизации и значительно сократить время их построения в компьютерных сетях. Определено, что целесообразно предоставлять возможность выбора режима расщепления горизонта: простой или анонсирования недоступности обратного пути.
Ключевые слова: метрика, таблица маршрутизации, зацикливания, тайм-аут, расщепление горизонта, обновление событием.
Compiled formal model RIP protocol, which form the basis of software developed model allows you to display dynamic update of routing information, getting it from the neighboring routers, where the output of volatile situations is realized by the mechanism time-out method and Split horizon. Found that the use of the Split horizon allows you to build the correct routing table and significantly reduce the time of their construction in computer networks. Determined that it is advisable to provide the ability to select the Split horizon: Simple split horizon or Split horizon with poisoned reverse.
Keywords: metric, routing table, looping, timeout, Split horizon, update event.
