Z A R Z Ą D Z A N I E S I E C I A M I T E L E K O M U N I K A C Y J N Y M I

Transkrypt

1 Wykład 11. (nazwa pliku wd_11b.pdf) Z A R Z Ą D Z A N I E S I E C I A M I T E L E K O M U N I K A C Y J N Y M I 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

2 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

3 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.*/.

4 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)

5 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.

6 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.

7 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 potwierdzana tworzy skojarzenie o ustalonym kontekście aplikacyjnym A-RELEASE potwierdzana pozwala rozłączyć skojarzenie bez utraty danych A-ABORT niepotwierdzana uż ywana w warunkach krytycznych i powoduje przerwanie połączenia w warstwach aplikacji, prezentacji i sesji oraz zakończenie skojarzenia; A-P-ABORT 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 RO- RESULT 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).

8 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,

9 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ą 2omunikować.*/ Autorzy niniejszego opracowania: Radosław Drabek Tomasz Grelewicz Patryk Chamuczyński Paweł Jankowski