Автор: Жов 24
Неважко відмітити, що завдання інжинірингу трафіку в попередньому пункті вирішувалося в достатньо спрощеній постановці – всі потоки трафіку вважалися рівнозначними, тому що пред’являли однакові вимоги до якості обслуговування.
Користувачів мережі задовольняло, що всі потоки обслуговуються із заданою середньою швидкістю і в умовах, коли завантаження кожного ресурсу не перевищує певного значення, наприклад 0,6. Реальнішою є ситуація, коли у кожного користувача мережі є декілька класів трафіку, і ці класи відрізняються вимогами до якості обслуговування.
Типовим прикладом є розділення всього трафіку, принаймні, на два класи – чутливого і не чутливого до затримок. У перший клас потрапляє, наприклад, трафік IP-телефонії і інших мультимедійних інтерактивних додатків, а також трафік додатків управління технологічними об’єктами. Решту трафіку складає другий клас.
Якщо оператор мережі не розрізнятиме ці два класи в завданнях ТІ, то у нього залишиться два варіанти дій.
У першому випадку він може пропонувати клієнтам мережі гарантовані межі затримок і варіацій затримок пакетів, але тримати ресурси своєї мережі недовантаженими, так щоб коефіцієнт використання кожного ресурсу не перевищував 0,2-0,3- Тоді для пакетів обох класів будуть створені умови для якісної відносно затримок передачі, але такий підхід важко назвати раціональним.
Якщо ж оператор мережі хоче добре завантажити свої ресурси, наприклад, до рівня 0,6-0,7 (залишаючи частину пропускної спроможності для службового трафіку), то він може пропонувати угоду SLA тільки для нечутливого до затримок трафіку, гарантуючи тільки середню швидкість просування.
Залишається ще одна можливість – розрізняти класи трафіку і вирішувати задачу ТІ з урахуванням їх існування. Для цього розширення протоколів маршрутизації повинні враховувати завантаження кожного ресурсу окремо для кожного класу трафіку, так щоб завантаження для чутливого до затримок трафіку не перевищило 0,2-0,3. а завантаження для решти трафіку знаходилося в межах 0,6-0,7.
Якщо при цьому чутливий до затримок трафік обслуговуватиметься в єдиній пріоритетній черзі, а решта трафіку – по схемі кругового обслуговування, то для кожного класу рівень обслуговування відносно затримок буде таким, який і потрібний (мал. 15.14).
Для досягнення такого результату з кожним ресурсом повинні бути зв’язані два лічильники завантаження – один для пріоритетного трафіку і другою для решти (фонового) трафіку.
Коли вирішується завдання ТІ для знаходження шляху пріоритетного трафіку по мережі, то при перевірці можливості проходження шляху через конкретний ресурс середня інтенсивність нового потоку повинна порівнюватися з вільною інтенсивністю ресурсу для пріоритетного трафіку.
Якщо вільну інтенсивність досить і новий потік проходитиме через даний інтерфейс, то значення інтенсивності нового потоку необхідно відняти як з лічильника завантаження пріоритетного трафіку, так і з лічильника завантаження фонового трафіку, оскільки пріоритетний трафік завжди обслуговуватиметься перед фоновим і створить додаткове завантаження і для фонового трафіку.
Якщо ж завдання ТІ вирішується для фонового трафіку, то його інтенсивність порівнюється з вільною інтенсивністю лічильника фонового трафіку і у разі позитивного рішення значення цієї інтенсивності віднімається тільки з лічильника фонового трафіку, оскільки для пріоритетного трафіку фоновий трафік прозорий.
В системі управління знання про підтримувані класи об’єктів і про породжені екземпляри об’єктів повинні зберігатися в якій-небудь формі, зручній для надання модулям системи управління доступу до цієї інформації. 
Керований об’єкт – це уявлення OSI про ресурс в цілях управле-нія. Ресурс може бути описаний як керований об’єкт. Конкретний управляє-мий об’єкт – це екземпляр (instance) деякого класу керованих об’єктів. Модель управління OSI широко використовує об’єктно-орієнтований підхід.