ang. Agent

Transkrypt

ang. Agent
Wykład 11. (nazwa pliku wd_11b.pdf)
ZARZĄ D ZANIE
SIECIAMI TELEKOMUNIKACYJNYMI
Temat wykładu: Architektura informacyjna TMN.
Architektura TMN – przypomnienie.
FC
(ang. Functional
Component)
składnik
funkcjonalny
FB
(ang. Function
Błock) blok funkcjonalny
BB (ang. Building Block)
blok fizyczny
M (ang. Manager)
zarządca
A (ang. Agent) agent
MO (ang. Management
Object)
zarządzany
obiekt
(ang. reference point)
punkt odniesienia
(ang.interface) interfejs
Elementami architektury informacyjnej są: zarządca M (ang. Manager), agent A (ang. Agent) i obiekt
zarządzany MO (ang. Management Object). Wspó łpraca między nimi odbywa się za pomocą
protokołu CMP.
Architektura informacyjna TMN opisuje sposó b modelowania wymiany informacji zarządzania.
Wykorzystano w niej następujące mechanizmy:
- wymiana informacji zarządzania oparta na modelu zarządca – agent i w druga stronę,
mianowicie agent – zarzadcza;
- sposó b modelowania zarządzanych zasobó w wykorzystujący technikę obiektową/*buduje się
pewien model badawczy, na którym dokonuje się doś wiadczeń , a nastę pnie przenosi się to na model fizyczny*/ .
Obiekt to abstrakcyjny element łączący dane i funkcje, np. obiekt zarządzany MO. Obiekty
moż na łączyć w klasy obiektó w zarządzanych MOC (ang. Managed Object Class), któ ra
moż e obejmować np. centrale abonenckie. Te klasy mogąmieć wydzielone podklasy, któ re
określamy przez wystąpienie zarządzanego obiektu MOI (ang. Managed Object Instance), co
moż e obejmować np. centrale abonenckie z dostępem PRA
Każ dy obiekt ma swojądefinicję, któ ra powinna zawierać : atrybuty obiektu (ang. attributes),
operacje (ang. operations), meldunki (ang. notifications) i zachowania (ang. behaviour).
Zostanąone poniż ej przedstawione.
Poprzez atrybuty obiektu rozumiemy:
- jego nazwę np. centrala abonencka;
- typ atrybutu np. tekstowy;
- wartości (zbió r wartości - dla atrybutu wielowartościowego). np. czynna,
wyłączona;
- zmiany wartości atrybutu /*np. gdy centrala przechodzi ze stanu „czynna” do stanu
„nieczynna” , lub zmieniają się jakieś jej parametry, np. ze wzglę du na temperaturę */;
- pobudzenie wewnętrzne /*np. przekroczenie ustalonych parametrów, choć by temperatury*/;
- pobudzenie zewnętrzne /*np. decyzja dyspozytora, element niesprawny nie może pozostawać
w działają cym systemie, jeś li pojawi się alarm, np. z powodu niezapewnienia odpowiedniej jakoś ci,
to znacznie lepiej jest, gdy dyspozytor wyłą czy centralę , niż gdyby ona miała działać
niewłaś ciwie*/.
Operacje - przykłady.
Operację dotyczące zarządzanych obiektó w.
Create
utworzenie nowego obiektu w danej klasie
Delete
usunięcie danego obiektu
Action
zlecenie obiektowi wykonania akcji; akcja - czynność , któ rądany obiekt wykonuje na
sobie lub na innych obiektach; efektem wykonania akcji przez obiekt moż e być
modyfikacja wartości atrybutó w obiektó w;
Operacje dotyczące atrybutó w zarządzanych obiektó w.
Get Value
odczyt bież ącej wartości atrybutu obiektu /*sprawdzenie, czy atrybuty są takie, jakich
oczekujemy, np. czy jakoś ć jest właś ciwa, czy nie*/;
Repleace Value
zmiana bież ącej wartości atrybutu /*np. zmiana progów jakoś ciowych, jest to ważne,
ponieważ dą ży się do centralizacji zarzą dzania i obsługi*/;
Repleace with
zmiana bież ącej wartości atrybutu na wartość domyślną /*przywró cenie podstawowej
default Value
konfiguracji urzadzenia*/ ;
Add Member
dodanie wartości do zbioru wartości atrybutu wielowartościowego /*atrybuty
wielowartościowe mogąobejmować kategorię abonenta, odpowiadające mu parametry
łącza fizycznego, itp.*/ ;
Remove Memeber
usunięcie wartości ze zbioru wartości atrybutu wielowartościowego.
/*W architekturze informacyjnej operuje się na pewnym modelu. Dołą czenie nowego abonenta, czy łą cza nie ma
żadnych skutków fizycznych, dopóki to działanie nie zostanie to „wykreowane” w tym modelu.*/
Zachowania obejmują:
- reakcję zarządzanego obiektu na przeprowadzonąna nim operację /*np. jeśli chcemy
jakiś obiekt np. włączyć , to ten obiekt musi to działanie wykonać */;
- znaczenie atrybutó w, operacji, meldunkó w i innych elementó w definicji obiektu;
- zależ ności między wartościami atrybutó w i warunki spó jności atrybutó w;
- warunki, któ re musząbyć spełnione przed i po wykonaniu operacji oraz wysłaniu
meldunku /*system powinien bronić się przez niewłaś ciwymi decyzjami operatora, przed którymi
jest zabezpieczony*/ ;
- efekty oddziaływań z innymi obiektami /*np. nie można wprowadzać zmian tylko w
-
jednym, z dwóch połą czonych ze sobą wę złów, zmiany w jednym wę źle muszą pocią gną ć za sobą
odpowiednie zmiany w wę złach z nim są siadują cych*/;
atrybuty, któ rych wartość nie ulega zmianie na czas istnienia obiektu /*czyli atrybuty
stałe*/.
Meldunki obejmują:
- meldunek jest wysyłany przez zarządzany obiekt w celu poinformowania o
zdarzeniu dotyczącym obiektu lub zaobserwowanym przez obiekt /*np. gdy obiekt
wykona jakieś działanie, czy zdarzy się coś nieprzewidzianego, np. wzroś nie stopa błę dów
transmisji*/;
warunki, przy któ rych mogąbyć wysyłane meldunki, zależ ąściśle od kryterió w
zdefiniowanych w dyskryminatorze przychodzących zdarzeń zawartym
(opisanych) w rekomendacji X.734.
Z architekturą- modelem informacyjnym sązwiązane pewne bazy danych zwane Bazami
Informacji Zarządzania – MIB (ang. Management Information Base). Sątam przechowywane
obiekty (informacje o nich) zarządzane.
Identyfikacja zarządzanych obiektó w w bazie MIB jest realizowana na podstawie drzewa
zarządzania.
-
Przykład drzewa zarządzania /*w bardzo dużym przybliżeniu*/.
/*Mamy
jedną
sieć
telekomunikacyjną , ale sieci
utrzymaniowe mogą być różne i
mogą
mieć
różnych
właś cicieli*/.
Domeny zarządzania.
Ze względó w organizacyjnych, zarządzane obiekty mogą być grupowane w domenach
zarządzania. Do obiektó w danej domeny stosuje się jednolity sposó b zarządzania. Kryterium
włączania obiektu do domeny (i podziału domen) obejmuje:
- położ enie geograficzne;
- funkcje jakie obiekt pełni /*np. domena obiektów zawią zanych z zarzą dzaniem konfiguracją ,
komutacją , teletransmisją */.
Obiekt moż e należ eć do wielu domen. /*Podział na domeny nie musi być sztywny. Niektó re domeny
mogąobejmować kilka godzin dnia, np. od 7 do 15, a inne mogąobejmować np. godziny nocy, inne domeny
mogąbyć przeznaczone dla świąt. Wszystko to w celu zmniejszenia kosztó w, ale przy odpowiedniej jakości,
wykorzystania systemu telekomunikacyjnego*/.
Szczegó lnym rodzajem domeny jest administracyjna domena zarządzania (ang. management
administrative domain), któ ra zajmuje się administrowaniem domenami jej podległymi
(nadzó r nad domenami, zmiana ich granic). /*Tutaj zawierają się wszelkie funkcje zwią zane z
bezpieczeń stwem, jak wydawanie odpowiednich kluczy, haseł, zarzą dzanie fakturowaniem szkoleniami, itd.*/.
Filtrowanie.
Z przesyłaniem informacji, czyli meldunkó w, zachowań, musi być wiązane filtrowanie
informacji. /*W systemie telekomunikacyjnym powstaje bardzo wiele danych, ale nie wszystkie one musza by ć
przesyłane na bieżą co do najwyższego szczebla zarzą dzają cego. Duża ich czę ś ć zostaje na niższych poziomach. Z
wydzieleniem informacji dla odpowiednich poziomów jest właś nie zwią zane filtrowanie.*/.
Atrybuty filtrowania:
- filtrowanie nie dopuszcza do sytuacji przesyłania duż ej ilości informacji o małym
znaczeniu między procesami zarządzania;
- filtrowanie pozwala wybrać podzbió r zarządzanych obiektó w na postawie ich
atrybutó w;
- kryterium wyboru jest spełnienie określonej zależ ności przez atrybut lub obecności
atrybutu w definicji danego obiektu;
- elementarne kryteria filtrowania moż na łączyć w bardziej złoż one (nazywane
filtrami) poprzez stosowanie operatoró w logicznych (I, LUB, NIE);
-
filtrowanie moż e odnosić się zaró wno do operacji jak i meldunkó w. Filtr moż e
określać , jakich obiektó w ma dotyczyć dana operacja oraz jakie meldunki
(pochodzące od jakich obiektó w) mają być przekazywane procesowi
zarządzającemu.
Przykład filtrowania.
Jeśli w sieci telekomunikacyjnej centrala jest wyposaż ona w złoż one mechanizmy
zaż egnujące sytuacje przeciąż enia, to wiadomości o przeciąż eniu centrali mogąbyć
filtrowane przed wysłaniem ich do centrum zarządzania, co powoduje, ż e wysyłane sątylko
informacje o bardzo poważ nym przeciąż eniu.
Zakres określa podzbió r zarządzanych obiektó w na podstawie ich miejsca w drzewie
nazywania, czyli na podstawie ich nazwy.
/*Do obiektu zarzą dzane-go
nie docierają wszyst-kie
operacje a do zarzą dcy nie
docierają
wszystkie
meldunki*/.
Podając zakres moż na określić , któ rego z obiektó w będzie dotyczyć dana operacja lub
meldunki któ rych obiektó w mogąbyć odbierane przez agenta.
Model wymiany informacji według OSI (X.200)
AP – (ang. Application Process) proces aplikacyjny.
AE – (ang. Application Entity) segment aplikacyjny.
ASE – (ang. Application Service Element) aplikacyjny element usługowy.
/*Jest to przykład wymiany informacji. Proces aplikacyjny zarzą dza
segmentami. Wymiana informacji miedzy warstwami odbywa się w sposób
hierarchiczny. Wymiana informacji w danej warstwie odbywa się zgodnie z
jednym protokołem, a wymiana informacji miedzy warstwami już zgodnie z
innym protokołem.*/
Uż ytkownicy MIS (ang.
Management Information
Services - Users) - aplikacje, któ re przetwarzająinformacje zarządzania i komunikująsię na
poziomie zarządzania systemami. SMAP (ang. Systems Management Application Process) proces aplikacyjny zarządzania systemami. SMAE (ang. Systems Management Application
Entity) -segment aplikacyjny zarządzania systemami. MIB (ang. Management Information
Base) - baza informacji zarządzania, LE (ang. Layer Entity) - segment warstwy, LME (ang.
Layer Management Entity) segment zarządzania warstwą.
Model informacyjny systemu zarządzania bazuje na modelu zarządca – agent.
/*Jest
to
model
o
strukturze
hierarchicznej. Zarzą dca jest wyżej w
hierarchii niż agent.*/.
Funkcja zarządcy lub funkcja
agenta nie jest trwale związana z
danym uż ytkownikiem MIS - ten
sam uż ytkownik moż e w jednej
sytuacji pełnić rolę agenta, a w
innej - rolę zarządcy
Funkcje agenta:
- zarządza obiektami w obszarze swojego środowiska lokalnego;
- wykonuje operacje na zarządzanych obiektach na polecenie zarządcy;
- przesyła zarządcy meldunki o zdarzeniach dotyczących zarządzanych obiektó w
(zdarzenie będzie rozumiane jako dowolna zmiana stanu zarządzanych obiektó w).
Funkcje zarządcy:
- odpowiedzialny jest za realizację jednego bądź kilku zadań w obszarze
zarządzania systemem;
- wydaje procesowi agenta polecenia wykonania operacji zarządzania na
zarządzanych obiektach.
Wspó lna wiedza zarządzania
Wymiana informacji między zarządcą i agentem, któ re znajdują się w ró ż nych systemach
otwartych /*czyli takich, w których pozostawia się dużą możliwoś ć rozwoju*/, jest moż liwa gdy zostanie
uzgodniona tzw. wspó lna wiedza zarządzania SMK (ang. Shared Management Knowledge).
/*Przykład wystę powania wspólnej wiedzy zarzą dzania.*/.
Wspó lna wiedza zarządzania obejmuje między innymi znajomość :
- protokołu zarządzania (wersja, składnia jednostek, profil funkcjonalny);
- zasad opisywania zarządzanych obiektó w;
- definicji zarządzanych obiektó w, któ rych dotyczy wymiana informacji między
procesami;
- zasad nazywania obiektó w;
- adresó w segmentó w aplikacyjnych systemó w zarządzania i ich punktó w dostępu
do usług;
- jednostek funkcjonalnych wybranych aplikacyjnych elementó w usługowych oraz
jednostek funkcjonalnych stosowanych w kolejnych warstwach danej
implementacji modelu OSI;
- zasad odtwarzania połączenia między procesem zarządzającym i procesem agenta.
Uzgadnianie wspó lnej wiedzy zarządzania moż e odbywać się na dwa sposoby:
- trwałe uzgodnienie między systemami, wiedza wykorzystywana jest w czasie
trwania każ dej wymiany danych między systemami;
- uzgadnianie wspó lnej wiedzy zarządzania w czasie ustanawiania połączenia
między systemami i ewentualne rozszerzanie jej już w czasie trwania tego
połączenia.
Warstwa aplikacji zarządzania systemami
Sąsiedni rysunek przedstawia aplikacyjny
segment zarządzania systemami i kolejne
procesy w nim zawarte, a mianowicie:
SMAE (Systems Management Application
Entity) - aplikacyjny segment zarządzania
systemami.
SMASE (Systems Management Application
Service Element) – aplika-cyjny element
usługowy zarządzania systemami.
ASE (Application Service Element) –
aplikacyjny element usługowy.
ACSE (Association Control Service Element) - element usługowy sterowania skojarzeniem.
CMISE (Common Management Information Service Element) - element usługowy wspó lnej
informacji zarządzania.
ROSE (Remote Operations Service Element) - element usługowy zdalnych operacji.
ACSE (element usługowy sterowania skojarzeniem) pozwala ustanowić i rozłączyć niezbędne
przy wymianie danych skojarzenie. Oferuje on następujące usługi
A-ASSOCIATE
A-RELEASE
A-ABORT
A-P-ABORT
potwierdzana
potwierdzana
niepotwierdzana
tworzy skojarzenie o ustalonym kontekście aplikacyjnym
pozwala rozłączyć skojarzenie bez utraty danych
uż ywana w warunkach krytycznych i powoduje przerwanie połączenia
w warstwach aplikacji, prezentacji i sesji oraz zakończenie skojarzenia;
jest inicjowana przez usługobiorcę; w jej wyniku moż e dojść
służ y do przerwania skojarzenia w warunkach krytycznych, ale
inicjowana jest przez usługodawcę (warstwę prezentacji)
Usługa potwierdzana - usługa, któ rej operacja elementarna (ż ądanie) musi zostać
potwierdzona operacjąelementarną(odpowiedź lub potwierdzenie).
Pojęcie „skojarzenie aplikacyjne" (ang. Application Association) rozumiane jest jako
zależ ność , któ ra pozwala przekazywać dane między dwoma segmentami AE (pośrednio
między procesami aplikacyjnymi). Jeden segment AE moż e utrzymywać ró wnocześnie wiele
skojarzeń z segmentami AE w innych systemach otwartych /*np. systemy komórkowe i systemy
stacjonarne maja różnych właś cicieli, ale muszą one mimo to ze sobą współpracować , przez to w wielu
kwestiach „nachodzą na siebie” */ . Przy zestawieniu skojarzenia zostają uzgodnione przez
segmenty AE zasady, któ rymi rządzi się skojarzenie zwane kontekstem aplikacyjnym (ang.
Application Context).
Danemu skojarzeniu odpowiada tylko jeden kontekst, któ ry moż e być modyfikowany w
czasie trwania skojarzenia. Kontekst określa, jakie elementy usługowe (ASE) wykorzystuje
się w danym skojarzeniu, w jaki sposó b wspó łpracują ze sobą oraz jaka jest syntaktyka
wymiany danych. Kontekst moż e zawierać dodatkowe informacje takie jak zasady
modyfikowania kontekstu w czasie trwania skojarzenia.
ROSE (element usługowy zdalnych operacji) umoż liwia procesowi aplikacyjnemu jednego
systemu otwartego (proces wywołujący) przesłanie ż ądania wykonania pewnej operacji
procesowi aplikacyjnemu innego systemu otwartego (proces wykonujący). Operacje te
nazywane sąoperacjami zdalnymi. Proces wykonujący pró buje zrealizować to ż ądanie i zdaje
sprawozdanie dotyczące jego wykonania. Poniż ej przedstawiam przykłady realizowanych w
nim funkcji:
RO-INVOKE
RO-RESULT
RO-ERROR
RO-REJECT-U
RO-REJECT-P
proces wywołujący ż ąda wykonania operacji od procesu wykonującego
odpowiedź na RO-INVOKE, jeśli wykonanie zadanej operacji zakończyło się sukcesem
odpowiedź na RO-INVOKE, jeśli wykonanie zadanej operacji zakończyło się poraż ką
usługobiorca usług ROSE odrzuca ż ądanie RO-INVOKE lub odpowiedź w postaci RORESULT lub RO-ERROR (np. jeśli zawierają one parametry o niedozwolonych
wartościach);
usługodawca (warstwa prezentacji) sług ROSE odrzuca ż ądanie RO-INVOKE lub
odpowiedź w postaci RO-RESULT lub RO-ERROR
CMISE (element usługowy wspó lnej informacji zarządzania) jest uż ywany przez proces
aplikacyjny do celó w zarządzania systemami poprzez wymianę informacji i komend
zarządzania. Element usługowy CMISE korzysta np. z protokołu wspó lnej informacji
zarządzania CMIP (ang. Common Management Information Protocol) oraz elementó w
usługowych: ACSE (ustanowienie skojarzenia) i ROSE (operacje zdalne).
Protokoł
y zarządzania siecią
W telekomunikacji posługujemy się najczęściej dwoma protokołami zarządzania, a
mianowicie:
SNMP - (Simple Network Management Protocol) /*przeznaczony głowinie do sieci z komutacja
pakietów, czyli np. sieci internetowej*/
CMIP - (Common Management Information Protocol )
Protokó ł SNMP.
Organizacja warstwy aplikacji – protokó ł SNMP.
/*Jak widać , wyróżniamy trzy piony, a
mianowicie:
- aplikacje generatora komend,
- aplikacje wysyłania powiadomień ,
- aplikacje odbierania powiadomień .
I zawarte w nich bloki-podsystemy:
- blok nadawczy,
podsystem
przetwarzania
wiadomoś ci,
- podsystem bezpieczeń stwa.*/
Protokó ł SNMP występuje w trzech wersjach:
- pierwsza wersja nie zapewniała dostatecznego bezpieczeństwa, wymaganego w
dzisiejszych sieciach;
- druga wprowadzała pewne nowe mechanizmy i rozszerzała zbió r przesyłanych
wiadomości, nie weszła jednak do powszechnego uż ycia;
- obecnie uż ywana jest trzecia wersja protokołu i dopiero ona zapewnia poziom
bezpieczeństwa wymagany w komercyjnych zastosowaniach. Specyfikacja wersji
trzeciej polegała na dodaniu nowych mechanizmó w do wersji drugiej.
Typy komunikató w protokołu SNMP:
get-request - pobierz wiadomość ,
get-next-request - pobierz następnąwiadomość w ramach tego samego kontekstu,
get-bulk-request - pobierz kilka wiadomości na raz (wsadowo),
response - odpowiedź na pakiety typu get, set i inform-request,
set-request - zapisz wartość ,
inform-request - służ y do przekazywania powiadomień między jednostkami zarządcó w ,
snmpV2-trap - pułapka; służ y agentom do powiadamiania zarządcy o zmianie
wartości w bazie MIB,
report – niezdefiniowany.
Przykład wykorzystania protokołu SNMP (między zarządcą, a sieciąagentó w)
/*Jeden zarzą dca może
komunikować
się
z
kilkoma
agentami.
Zarzą dcy
mogą
się
mię dzy
sobą
komunikować .*/
Autorzy niniejszego opracowania:
Radosław Drabek
Tomasz Grelewicz
Patryk Chamuczyński
Paweł Jankowski