Правила 

за конверзација при 
управувачката интеракција
доц. д‐р Марко Порјазоски
 Комуникација менаџер ‐ агент
Комуникација менаџер 
• Менацерот и агентот се софтверски апликации
ц р ф р ц
– Менаџерот работи на управувачката станица (управувачки центар)
– Агентот работи на управуваниот уред
• Клиент сервер комуникација
К ј
– Многу клиенти – еден или неколку сервери
• Менаџер –
џ р агент комуникација
у ц ј
– Еден (неколку) менаџери ‐ многу агенти
 Нивовска структура на 
управувачката интеракција
• Слично на комуникациските протоколи, направена е поделба на 
нивоа на интеракцијата (комуникацијата) при управувањето со 
мрежата
 Нивовска структура на 
управувачката интеракција
• Транспортно ниво
– Ги опфаќа сите комуникациски протоколи кои служат за пренос на 
управувачките информации

• Примери за протоколи кои се користат за пренос на пораките во 
управувањето со ТК мрежи:
– User Datagram Protocol (UDP), Transport Control Protocol (TCP), Block 
Extensible Exchange Protocol (BEEP), Secure Shell (SSH), hypertext Transfer 
Protocol (HTTP) итн.
( )
– Иако SSH и HTTP се протколи кои во комуникациките модели се наоѓаат 
на апликациско ниво, во случајт на управувањето се користат за пренос 
на управувачките информации па затоа во овој модел се сместени во 
нивото за транспорт
нивото за транспорт
• При дефинирањето на интерфејсите за управување мора да се 
специфицира кој протокол за транспорт (пренос) е користен
 Нивовска структура на 
управувачката интеракција
• Ниво на работење од далечина
– Се состои од три кмплементарни функционалности кои обезбедуваат услуги на 
слојот на „управувачки операции“ 

• Association control – Воспоставување и раскинување на управувачка 
у р у у р у
сесија
– Постојат други управувачки аспекти за кои комнуникациските протоколи не се 
свесни
– Пример: менаџерот треба да дознае кои се способностите на агентото и да се 
б б
договорат за користење на соодветен профил, или агентото однапред да ги одреди 
функциите кои ќе му бидат дозволени на менаџерот зависно од корисничките 
привилегии
• Remote operation Support – претставено со RPC
– Управување со идентификаторите (ID) на барањата/одговорите
– Фрагментирање и составување на пораките
 Нивовска структура на 
управувачката интеракција
• Потреба од управување со  • Потреба од фрагментирање 
идентификаторите (ID) на  и составување на пораките
барањата/одговорите – Во случај кога PDU од 
– Менаџерот барањата најчесто  управувачките протоколи се 
ги испраќа асинхроно
ќ поголеми од максималниот
поголеми од максималниот 
товар на транспортните 
протоколи 
 Нивовска структура на 
управувачката интеракција
• Ниво на операции за работење од далечина

• Шифрирање на податоците – како податоците се претставуваат во 
товарот на PDU
– целосен опис на пренесените податоци: вреност, тип на податоците, 
целосен опис на пренесените податоци: вреност тип на податоците
– Примери: ASN.1 Basic Encoding Rules или XML
 Нивовска структура на 
управувачката интеракција
• Ниво на управувачки операции
– Ова ниво претставува јадро на управувачкиот протоколен стек
– На ова ниво се дефинирани управувачките примитиви ‐ основни операции кои се 
користат во управувањето со мрежата
• Примитивите
р опфаќаат:
ф
– Управувачки барања,
– Одговори на барањата и
– Настани 
• Кои примитивите
Кои примитивите можат да се користат зависи од протоколот за 
можат да се користат зависи од протоколот за
управување.
• Некои стандардни примитиви опфаќаат:
– Примитиви за читање  (get примитиви) – се користат за преземање на 
управувачките информации
– Примитиви за запишување (set примитиви)  ‐ за промена на управувачките 
информации (операции за креирање, бришење и менување)
– Примитиви за известување за настани од страна на агентите
– Примитиви за извршување акција – га го принудите уредот на направи нешто (на 
пример: само тестирање) 
– Поретко се користат примитиви како известување (не одговор) за одредено 
барање
 Нивовска структура на 
управувачката интеракција
• Управувачки сервиси

• Во принцип управувачките примитиви се доволни за извршување на 
основните управувачки функции
• Нивото на управувачките сервиси не е обврзувачко, но внесуваат 
дополнителни опции:
дополнителни опции:
– Опции за претплата на управувачките апликации на извештаи за одреден тип на 
настани
– Опции за самоанализа , овозможува управувачката апликација да дознае каков 
ф
формат на информации и функции поддржува управуваниот уред
ф ф
– Распределување на управувачки операции на уреди кои периодично извршуваат 
одредена функција, без притоа управувачката апликација да генерира нови 
барања. 
 Интеракција иницирана од 
менаџерот – Барање и одговор
• Основната комуникациска шема помеѓу менаџер и агент  се состои од 
размена на барања и соодветни одговори:

• Менаџерот испраќа барање со одредена цел:
– Да
Да преземе дел од управувачките информации од уредот;
преземе дел од управувачките информации од уредот;
– Да измени некои конфигурациски параметри
– Да предизвика одредена акција кај управуваниот уред како на пример 
себе‐тестирање (self‐test).
• Агентот испраќа одговор (за успешни извршување на задачата или 
грешка)
• Оваа шема уште е позната и како трансакциона интеракција
 Интеракција иницирана од 
менаџерот – Барање и одговор
• Типично барање од менаџерот вклучува:
– Тип на барање
– Управувачка информација на која се однесува барањето
– Дополнителни информации – идентификатор на барањето или безбедносни 
акредитиви за автентикација
• Агентот проверува дали барањето е валидно
– Дали го разбира
– Дали безбедносните акредитиви на менаџерот се валидни
– Д
Дали менаџерот е овластен да испрати такво барање
џ р д р р
– Ако барањето не е валидно – негативен одговор
– Во спротивно го спроведува барањето и испраќа одговор со резултати до 
менаџерот
• Минимум информации што ги содржи одговорот:
Минимум информации што ги содржи одговорот:
– Код за успешност на барањето 
– Резултати од извршеното барање (некоја информација која е побарана)
– Дополнителни информации, на пр. идентификатор на оригиналното барање за да 
може менаџерот да ги спари барањето и одговорот
може менаџерот да ги спари барањето и одговорот.
 Преземање информации ‐Прозивање и 
управување базирано на прозивање
б
• Наједноставен облик на интеракција:
– Менаџерот испраќа барање за добивање одредена управувачка информација
– Агентот ја проверува валидноста на пораката
– Агентот одговара со бараната вредност или
– Со порака за грешка во која ја објаснува природата на грешката
• Овој основен принцип се прилагодува  и оптимизира во зависност од  
типот на бараната управувачка информација односно типот на 
задачата од управувањето
• Ќ
Ќе разгледаме неколку сцанарија:
ј
– Барање на конфигурациска информација
– Барање на оперативни податоци и информации за состојбата
– Обемни барања и инкрементални  (растечки) операции
– Историски информации
 Преземање информации ‐Прозивање и 
управување базирано на прозивање
б
• Барање на конфигурациска информација
– Промените во конфигурацијата се случуваат многу ретко
ф
– Ретко ќе бидат испраќани барања за добивање конфигурациски 
информации
– Најчесто конфигурациските податоци се менуваат преку самата 
управувачка апликација, па таа знае за промените
– Ненадејни промени се известуваат преку  известувања  за сменета 
конфигурација
• Придобивки
р д
– Намален управувачки сообраќај
– Намалено оптоварување на уредите со непотрбни барања
– Подобрени перформанси на управувачката апликација (избегнување на 
непотрбни доцнења при пренос)
р д ц р р )
• Конфигурациски информации се барааат под следните услови:
– При прво иницијално вчитување на конфигурациксите информации од 
управувачката апликација
– Кога постои сомнеж дека во базата на конфигурацики податоци се чуваат 
Кога постои сомнеж дека во базата на конфигурацики податоци се чуваат
стари информации (поради испад или неочекувани проемни во конф.)
– Пред воспоставување на услуги  ‐ да се увериме за конфигурацијата на 
уредите преку кои ќе се воспостави услугата
 Преземање информации ‐Прозивање и 
управување базирано на прозивање
б
• Барање на оперативни податоци и информации за состојбата
– Овие податоци се менуваат  често во самиот уред
– Не се од круцијална вежност за работата на управувачката апликација
– Пример: број на испратени бајти на еден интерфејс/линк
• Вакви барања се испраќаат во следните сценарија:
Вакви барања се испраќаат во следните сценарија:
– Оператор/корисник на управувачак апликација сака да направи преглед на уредот 
во реално време, да ја има најсвежата информација за уредот
– Дијагностика и отстранување на грешка
– Ако уредот е под специјален надзор  и се следи негоото однесување одредн 
Ако уредот е под специјален надзор и се следи негоото однесување одредн
временски интервал 
• Уредите не треба да се преоптоварат со одговарање на 
управувачки барања
управувачки барања
• Негова основна цел се комуникациските задачи
 Преземање информации ‐Прозивање и 
управување базирано на прозивање
б
• Барање на оперативни податоци и информации за состојбата
– Постојаното барање на информации за состојбара може да биде 
неефикасно:
• Целосно испуштање битни настани
• Доцнење во известувањето 
Доцнење во известувањето
на некој битен настан
• Поефикасни начини на испраќање
„слика“ за уредот се следните:
а) чување „слики“ на уредот и нивно 
испраќање по барање на менаџерот б) автоматско испраќање на „сликите“
 Преземање информации ‐Прозивање и 
управување базирано на прозивање
б
• Обемни барања и инкрементални  (постепени) операции
– Инкрементални операции – се бараат поединечни управувачки 
б
информации една по една
– Обемни барања – барања за група инфоамции кои задоволуваат 
одреден критетиум
одреден критетиум
– Ако управувачките информации се организирани во облик на дрво 
постои можност да се побара одеднаш цело под‐дрво, односно 
група на информации
• В
Во пракса ретко уредите поддржуваат
работа со група (опсег) на информации
поради релативно сложената 
ц ј
имплементација на агентите
• Во случај на барање конфигурациски 
информации, може да се повлече 
целиот конфигурацики фајл без потреба
од групирање на информациите
од групирање на информациите
 Преземање информации ‐Прозивање и 
управување базирано на прозивање
б
• Историски информации
– Најчесто управувачки информации за перформансите кои се коритат во анлизи
– Начинот на кој управувачките апликации ги користат овие информации влијае врз 
начинот на нивно превземање од уредот
• Прв начин –
р за секое преземање менаџерот испраќа барање
р џ р р р
– Недостатоци:
• Преоптоварување на уредите од периодичо повикување/прозивање
• Нарушена стабилност на управувачката апликацијата; ако дојде до некаков 
прекин во работата на апликацијата (рестарт,
р р ц ј (р р,
губење на конективност) ќе иам дупка 
во податоците за анализа
• Калибрација на врменскиот интервал –
не може да се гарантира точното време 
д р р р
(периода) на преземање на податоците 
поради променливи доцнења во мрежата.
• Синхронизација на почетокот на
врменскиот интервал –
р р невозможно е сите 
уреди во мрежата да бидат повикани во ист 
момент
 Преземање информации ‐Прозивање и 
управување базирано на прозивање
б
• Историски информации
• Втор начин – автоматско снимање на податоците на уредите
– Агентото остава можност менаџерот да избер кои податоци и на кој временси 
интервал ќе се снимаат
– Чувањето на податоците може да биде во MIB или во фајл
у д ц д д ф ј
– Фајловите едноставно може да се превземаат со FTP
– Најчесто фајлови се отвараат секои 24 часа а во нив има по 96 снимки на 
перформансите правени на секои 15 минути
• Се избегнува испраќање голем број барања
Се избегнува испраќање голем број барања
• Не е испуштено ниту едно мерење
• Калибрирацијата и синхронизацијата на временските интервали е 
скоро совршена
р р
• Еднинствен недостаток е што не сите уреди го поддржуваат овој 
начин на прибирање на историските податоци
 Конфигурациски операции
Конфигурациски операции
• Целта е да се сменат одредени конфигурациски параметри
• Интеракцијата ја следи шемата на поставување барање и добивање 
одговор но секако ќе се разликува од интеракцијата при прибирање 
на податоци
• Сценарија:
– Опоравување од испад/грешка
– Големина на одговор и групирање на барања
– Работа со конфигурациски фајлови
 Конфигурациски операции
Конфигурациски операции

• Опоравување од испад/грешка
р у д д/ р
– Менаџерот треба да добие потврда од агентот за успешно 
извршената операција
– Што се случува ако не добие потврда?
– Можни се следните сценарија:
• Уредот не го примил барањето – Менаџерот треба да го препрати 
барањето
• Изгувена потврда/одговор за извршената операција
Изгувена потврда/одговор за извршената операција
• Сеуште се извршува операцијата
– Решенија:
• Агентот да дава можност менаџерот да 
д д џ р д
го дознае статусот/прогресот на 
операцијата
• Пред да испрати ново барање
менаџерот да провери дали
менаџерот да провери дали 
претходното барање имало ефект, 
односно параметрите се сменети
 Конфигурациски операции
Конфигурациски операции

• Големина на одговор и групирање на барања
о е а а од о ор ру ра е а бара а
– Одговорот што го испраќа агентот  во случај на конфигурациски 
операции е многу помал од одговорот што се добива при 
чотање/повлекување информации
– Групирање на барања со цел да се имплентира истите 
конфигурацики опции едновремено (на пример на сите порти од 
еден уред)
 Конфигурациски операции
Конфигурациски операции

• Работење со конфигурациски фајлови
ф ур ц ф ј
– Незавосно во кој формат на конфигурациксите информации, најчесто тие се 
сместени во одреден фајл
– Соодветно едно барање за конфигурациска операција може да биде олеснето со 
користење конфигурациски фајлови:
• Се потготвува конфигурацискиот фајл
С ф ф ј
• Се префрла фајлот на уредот
• На уредот му се назначува да ја преземе конфигурацијата од новиот фајл
– Работата со конфигурациски фајлови овозможува:
• Лесна
Лесна имплементација на чување резевни копии и  брзо опоравување по 
имплементација на чување резевни копии и брзо опоравување по
испад (back‐up and recovery)
• Чување повеќе различни конфигурации
• Олеснето конфигурирање на повеќе исти уреди низ мрежата
– Пример
Пример за принциппот на работа на реални системи (Cisco, ZTE, 
за принциппот на работа на реални системи (Cisco, ZTE,
Marconi/Ericsson)
• Хибриден пристап прио конфигурирањето
• Барањето за промена конфигурацијата не бара експлицитно ракување со 
ф ј
фајлови
• Промените ќе се имплементираат во постојната работна конфигурација
• Меѓутоа ако  се рестартира уредот промените ќе бидат изгубени
• Корисникот/операторот треба специфично да побара промените да бидат 
зачувани во sturt‐up конфигурацискиот фајл
 Предизвикување акција
Предизвикување акција
• Одредена интеракција на менаџерот со агентото може да бара 
преземање одредан акција:
– Рестартирање на уредот
– Стартување на себе‐тестирање
– Pingg на некој друг уред во мрежата и слично.
ј дру ур д р
• Оваа интеракција е директна се испраќа барање и се чека одговор 
како резултат на барањето
• Што ако задачата што треба да се изврши трае долго? Дали натанала 
грешка? Дали менаџерот да испрати ново барање?
 Предизвикување акција
Предизвикување акција
• Решение – да се подели интеракцијата на делови
– Иницијалнаиот одговор – информација дека барањето е примено
– Следните барања /одговори се однесуваат на статусот на задачата дали е завршена 
или сеуште се извршува
 Управувачки трансакции
Управувачки трансакции
• Наместо едно по едно понекогаш е подобро барањата да се испраќаат во 
група
• Пример воспсотавување на DSL услуга
• Задачи:
– Да се поврзе DSLAM (Network facing port)
р gp
со агрегацискиот рутер
– Да се поврзе Customer Facing Port со
Network Facing Port од DSLAM
• Конфигурациските беарања ќе се 
Конфигурациските беарања ќе се
испратат во група т.н. 
трансакција
 Управувачки трансакции
Управувачки трансакции
• Уптравувачките апликации за да се заштитат од несакани појави како 
интерфернција со други методи на конфигурирање (на пример CLI)
интерфернција со други методи на конфигурирање (на пример CLI) 
– Настанале промени додека се извршиле сите операции испратени со трансакцијата
• Чекори за избегнување на вакви појави:
– Верификација на операцијата  пред да се изврши операцијата (пример проверка на синтакса)
– Валидација – проверка дали операцијата ја постигнала саканата цел
– Враќање на претходна состојба ако настане проблем
 Интеракција иницирана од Агент‐ Настани и 
управување базирано на настани
б
• Агентот без да биде прашан испраќа пораки доколку  настане одредена 
промена во уредот/мрежата
промена во уредот/мрежата
• Поделба на настаните:
– Аларми
– Настани предизвикани од промена на конфигурацијата
– Предупредување за надминување на одреден праг
– Евидентирање на одредни активности што се случуваат во мрежата (logging 
events):
• Активности на операторот
Активности на операторот
• Активности на системот
• Активности во мрежата и услугите
– Информативни настани
• Информации вклучени во пораките генерирани од настан:
Информации вклучени во пораките генерирани од настан:
– Системот од кој потекнува настанот
– Време кога се појавил настанот
– Тип на настан
– Д
Дополнителни информации за настанот
ф
 Аларми
• Порака која сигнализира неочекувано однесување во мрежата
– Не работи картичка во рутер
– Превисока темперратура со можност за оштетување на опремата
Превисока темперратура со можност за оштетување на опремата
– Детекција на неочекуван прекин на конекцијата на одредена порта
• Алармот мора да ги содржи следните информации:
– Тип на аларм
– Сериозност на алармот (препорака ITU
Сериозност на алармот (препорака ITU‐TT X.733)
X 733)
• Критичен (Critical)
• Значаен (Major)
• Малку значаен (Minor)
• Предупредување (Warning)
• Нео ре е (Indeterminate)
Неодреден (Indeterminate)
• Решен /Избришан (Cleared)
– По можност, поширока категорија на алармот (X.733)
• Комуникациски аларм
• QoS аларм
Q р
• Аларм за грешка во процесирањето
• Аларм за опрема
• Аларм за околина
– Има и други информации кои може да бидат од корист но не се 
имплементираат:
• Предложено решени
• Листа на други аларми предизвикани од истиот проблем
• Дополнителни информации како помош за разрешување на проблемот
 Настани предизвикани од промена во 
кокфигурацијата
ф ј
• Во најдобар случај пораката испратена при промена на конфигурацијата 
треба да вклучуваат:
– Промеи кои се направени во конфигурацијата
– Изворот на барањето за промена на конфигурацијата
– Идентификатор на барањето
• Не секогаш пораките ги содржат овие информации
Не секогаш пораките ги содржат овие информации
• Споредба на методата на 
известување за промените со 
пораки и методата на проверка на
пораки и методата на проверка на 
конфигурацијата со периодично 
повикување
 Предупредувања за преминување на 
одреден праг
• Порака која известува дека некоја MIB
Порака која известува дека некоја MIB објект или управувачка 
објект или управувачка
проемнлива преминала одредена предефинирана вредност – праг.
 Предупредувања за преминување на 
одреден праг
• Пример за TCA
Пример за TCA
– Искористувањето на линкот надминува 80%
• Многу поефикасно решение отколку менаџерот периодично да испраќа 
барања за состојбата на мрежата
• TCA се особено важни за проактивното решавање на проблемите во 
мрежата
• Пожелно е TCA да ги содржи следните информации:
– Името
Името на прагот или MIB
на прагот или MIB променливата која е следена
променливата која е следена
– Вредноста на поставениот праг
– Информација дали прагот е 
надминат или предупредувањето 
завршило
• За да се избегне пинг понг ефект 
при вариации на ппроменливата 
околу прагот, се дефинира втор 
у р , д ф р р
(помал) ‐хистерезисен праг за кој 
опасноста се смета за избегната
 Критериуми за избор на управување 
базирано на настани или на повикување
• Број на потребни пораки за да се изврши задачата
• Д
Дали информацијата треба да биде достапна во рално време или близу‐
ф ј б б б
до реално време или надвор од реално врема
• Процесирачките способности на управуваниот уред
• Пренесување на мал процент непотребни информации
Пренесување на мал процент непотребни информации
• Расположивиот опсег доделен за управувањето
• Колку лесно менаџерот може да дојде до бараната информација
 Доверливост на настаите
Доверливост на настаите

• Користење на доверливи транспортни протоколи
• Д
Ддоавање на број на секвенца на алармите за да може доколку е 
б ј
потребно да се одговори на истите
• Да се потврдува приемнот на пораките генерирани од настани 
 Пример 1
• Претпоставете имате 1000 уреди и 1500 линкови. Апликацијата за управување со 
перформасите бара 18 параметри за перформансите на секој линк и 7 параметри 
за секој уред. Со секвенцијални барања може едновремено мпде да се добијат 5 
парамери Од вас се бара да направите база во која ќе се чува историјата на овие
парамери. Од вас се бара да направите база во која ќе се чува историјата на овие 
параметри со периода на читање 15 минути. 
Која брзина на барања и одговори во секунда треба да ја поддржува вашата 
паликација?
Ако се потребни 5 секунди да се прими еден одговор од уред, со колку барања 
едновремено треба да се прави вашата апликација?

• Решение

• 2 барања за парамтерите на секој урет
• 4 барања за параметрите на ској линк
р р р ј
• Тоа значи : 1500x4+1000x2 = 8000 барања на секои 15 минути
• 8000/(15*60)= 8.88 барања/секунда 
• Ако претпоставиме дека некое берање ќе треба да се препрати тогаш ќе 
заокружине на 10 барања/секунда  
• 10 [барања/секунда] x 5 секунди за секое одговор = 50 едновремени 
одговори кои треба да се налаизираат