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