|
|
Автор: Жов 29
Більшість вживаних методів оптимізації роботи мережі до недавніх пір були направлені на перерозподіл ресурсів окремого маршрутизатора між різними потоками, що протікали через нього. Саме цю задачу вирішують методи, об’єднані під загальною назвою Quality of Service (QOS).
В той же час такий могутній засіб, як вибір шляхів проходження трафіку, через мережу традиційно використовувався в багатьох типах мереж дуже примітивно. Адже від шляхів проходження трафіку (при його фіксованій інтенсивності) в першу чергу залежить завантаження маршрутизаторів і каналів, а значить, і ефективність використання мережі.
Далі ми розглянемо недоліки підходів вибору шляху, заснованих на критерії найкоротшої відстані до точки призначення, на прикладі IP-мереж як найбільш популярних в даний час.
Відоме, що всі протоколи маршрутизації, зокрема дистанційно-векторні, такі як RIP, і стани зв’язків, такі як OSPF і IS-IS, вибирають для трафіку, направленого в певну мережу, найкоротший маршрут відповідно до деякої метрики.
Вибраний шлях може бути раціональнішим, наприклад, якщо в розрахунок приймається номінальна пропускна спроможність каналів зв’язку або затримки, що вносяться ними, або менш раціональним, якщо враховується тільки кількість проміжних маршрутизаторів (хопов) між початковою і кінцевою мережами. Проте у будь-якому випадку вибирається єдиний маршрут, навіть якщо існує декілька альтернативних шляхів.
Класичним прикладом неефективності такого підходу є так звана «риба» – мережа з топологією, приведеною на мал. 15.9.
Не дивлячись на те що між маршрутизаторами А і Е існує два шляхи – верхній, через маршрутизатор В, і ніжній – через маршрутизатори З і D, – весь трафік від маршрутизатора А до маршрутизатора Е відповідно до принципів маршрутизації, прийнятих в IP-мережах, прямує по верхньому шляху.
Тільки тому, що нижній шлях небагато, на один хоп гірше, ніж верхній, він ігнорується, хоча він міг би працювати «паралельно» з верхнім шляхом.
Читать далее »
маршрут, мережа, метод, ресурс, трафік, час, шлях,
Автор: Жов 28
Одним з могутніх, але не використовуваних раніше в IP-мережах методів впливу на ефективне використання ресурсів мережі є технологія інжинірингу трафіку (Traffic Engineering, ТІ).
У вузькому сенсі, найбільш відповідному назві, під ТІ розуміються методи і механізми, які дозволяють досягти збалансованого завантаження всіх ресурсів мережі шляхом раціонального вибору шляхів проходження трафіку через мережу.
Початковими даними для вибору шляхів є, по-перше, характеристики мережі, що передає, – її топологія, а також продуктивність складових її маршрутизаторів і каналів зв’язку (мал. 15.10), а по-друге, зведення про навантаження мережі, тобто про потоки трафіку, які мережа повинна передати між своїми прикордонними маршрутизаторами (мал. 15.11).
Читать далее »
мережа, потік, протокол, рішення, ресурс, трафік, шлях,
Автор: Жов 24
Неважко відмітити, що завдання інжинірингу трафіку в попередньому пункті вирішувалося в достатньо спрощеній постановці – всі потоки трафіку вважалися рівнозначними, тому що пред’являли однакові вимоги до якості обслуговування.
Користувачів мережі задовольняло, що всі потоки обслуговуються із заданою середньою швидкістю і в умовах, коли завантаження кожного ресурсу не перевищує певного значення, наприклад 0,6. Реальнішою є ситуація, коли у кожного користувача мережі є декілька класів трафіку, і ці класи відрізняються вимогами до якості обслуговування.
Типовим прикладом є розділення всього трафіку, принаймні, на два класи – чутливого і не чутливого до затримок. У перший клас потрапляє, наприклад, трафік IP-телефонії і інших мультимедійних інтерактивних додатків, а також трафік додатків управління технологічними об’єктами. Решту трафіку складає другий клас.
Якщо оператор мережі не розрізнятиме ці два класи в завданнях ТІ, то у нього залишиться два варіанти дій.
У першому випадку він може пропонувати клієнтам мережі гарантовані межі затримок і варіацій затримок пакетів, але тримати ресурси своєї мережі недовантаженими, так щоб коефіцієнт використання кожного ресурсу не перевищував 0,2-0,3- Тоді для пакетів обох класів будуть створені умови для якісної відносно затримок передачі, але такий підхід важко назвати раціональним.
Якщо ж оператор мережі хоче добре завантажити свої ресурси, наприклад, до рівня 0,6-0,7 (залишаючи частину пропускної спроможності для службового трафіку), то він може пропонувати угоду SLA тільки для нечутливого до затримок трафіку, гарантуючи тільки середню швидкість просування.
Залишається ще одна можливість – розрізняти класи трафіку і вирішувати задачу ТІ з урахуванням їх існування. Для цього розширення протоколів маршрутизації повинні враховувати завантаження кожного ресурсу окремо для кожного класу трафіку, так щоб завантаження для чутливого до затримок трафіку не перевищило 0,2-0,3. а завантаження для решти трафіку знаходилося в межах 0,6-0,7.
Якщо при цьому чутливий до затримок трафік обслуговуватиметься в єдиній пріоритетній черзі, а решта трафіку – по схемі кругового обслуговування, то для кожного класу рівень обслуговування відносно затримок буде таким, який і потрібний (мал. 15.14).
Для досягнення такого результату з кожним ресурсом повинні бути зв’язані два лічильники завантаження – один для пріоритетного трафіку і другою для решти (фонового) трафіку.
Коли вирішується завдання ТІ для знаходження шляху пріоритетного трафіку по мережі, то при перевірці можливості проходження шляху через конкретний ресурс середня інтенсивність нового потоку повинна порівнюватися з вільною інтенсивністю ресурсу для пріоритетного трафіку.
Якщо вільну інтенсивність досить і новий потік проходитиме через даний інтерфейс, то значення інтенсивності нового потоку необхідно відняти як з лічильника завантаження пріоритетного трафіку, так і з лічильника завантаження фонового трафіку, оскільки пріоритетний трафік завжди обслуговуватиметься перед фоновим і створить додаткове завантаження і для фонового трафіку.
Якщо ж завдання ТІ вирішується для фонового трафіку, то його інтенсивність порівнюється з вільною інтенсивністю лічильника фонового трафіку і у разі позитивного рішення значення цієї інтенсивності віднімається тільки з лічильника фонового трафіку, оскільки для пріоритетного трафіку фоновий трафік прозорий.
Читать далее »
інтенсивність, завантаження, затримка, клас, мережа, ресурс, трафік,
Автор: Вер 30
 Керований об’єкт – це уявлення OSI про ресурс в цілях управле-нія. Ресурс може бути описаний як керований об’єкт. Конкретний управляє-мий об’єкт – це екземпляр (instance) деякого класу керованих об’єктів. Модель управління OSI широко використовує об’єктно-орієнтований підхід.
Клас керованих об’єктів – це набір властивостей, які можуть бути обяза-тільними або умовними. Шляхом опису одного класу керованих об’ек-тов, наприклад комутаторів, можна створити інший клас керованих об’ек-тов, наприклад комутаторів, що підтримують технікові VLAN, успадкувавши всі властивості класу комутаторів, але додавши нові атрибути.
Читать далее »
дані, клас, комутатор, обєкт, опис, ресурс, управління,
|