Wojciech Dziunikowski
Akademia Górniczo-Hutnicza
Al. Mickiewicza 30, 30-059 Kraków
dziuniko@agh.edu.pl
ARCHITEKTURA SYSTEMU ZARZĄDZANIA SIECIĄ
TELEKOMUNIKACYJNĄ W OPARCIU O POLITYKI
Streszczenie: W artykule przedstawiono architekturę
systemu zarządzania siecią telekomunikacyjną w oparciu o polityki zapewniającą spójną KONfigurację zarządzanej DOmeny z uwzględnieniem rafinacji polityk (KONDOR). W architekturze uwzględniono mechanizmy umoŜliwiające analizę składniową jak i semantyczną zdefiniowanych reguł, rafinację polityk oraz adaptację polityk do zmieniających się warunków w zarządzanej domenie. Przedstawiono równieŜ sposób weryfikacji zaproponowanej architektury.
WSTĘP
Rosnąca konkurencja na rynku usług
telekomunikacyjnych staje się coraz bardziej
zauwaŜalna. Na rynek usług dotychczas zdominowanych przez duŜych operatorów narodowych zaczynają wchodzić operatorzy lokalni np. sieci telewizji kablowych, które dostarczają pakiety zintegrowanych usług zawierające usługi transmisji głosu, telewizji interaktywnej, transmisji danych, jak równieŜ wielu innych usług dodanych. Sprostanie konkurencji wymaga zastosowania efektywnych systemów zarządzania coraz bardziej skomplikowaną infrastrukturą IT. Wg badań przeprowadzonych w styczniu 2005 roku [1] operatorzy telekomunikacyjni główny nacisk kładą na obniŜenie kosztów utrzymania infrastruktury, oraz zwiększenie zadowolenia klientów, a co za tym idzie zwiększenie przychodów. Znaczącą pozycję na liście kosztów zajmują działania związane z integracją systemów zarządzania dedykowanych do róŜnych zastosowań i pochodzących od róŜnych producentów. Sporym
problemem jest brak ujednoliconego sposobu
reprezentacji wiedzy o zarządzanych zasobach. Jedną z propozycji związanych z usprawnieniem zarządzania
skomplikowaną siecią telekomunikacyjną jest
zbudowanie systemu zarządzania w oparciu o polityki [3][4]. Pierwsze, tego typu propozycje pojawiły się na początku lat 90-tych, a największy rozwój tej tematyki przypada na początek obecnego wieku. Z dostępnej literatury wynika, Ŝe opracowanie kompleksowego systemu zarządzania w oparciu o polityki definiowane przez operatora wymaga rozwiązania wielu zagadnień związanych z reprezentacją wiedzy o zarządzanej domenie, analizą definiowanych polityk, kontrolą wdraŜania polityk. Podobne problemy, jak w przypadku systemów zarządzania, pojawiają się równieŜ przy realizacji koncepcji sieci semantycznej (Semantic Web)
[2][8] oraz architektury zorientowanej na usługi SOA (Service Oriented Architecture) [12]. W ramach prac nad tą koncepcją pojawia się coraz więcej standardów, w których polityki oraz reguły mają zastosowanie w zarządzaniu usługami świadczonymi w sieci Internet.
Zastosowanie tych standardów do zarządzania
infrastrukturą IT i opracowania systemu zarządzania w oparciu o polityki przedstawia się obiecująco.
W artykule przedstawiono ogólne załoŜenia
systemu zarządzania w oparciu o polityki,
zaproponowano architekturę takiego systemu oraz wskazano moŜliwe rozwiązania niektórych problemów związanych np. z rafinacją polityk w oparciu o specyfikacje związane z koncepcją sieci semantycznej oraz architektury SOA.
CHARAKTERYSTYKA SYSTEMU ZARZĄDZANIA W OPARCIU O POLITYKI
System zarządzania w oparciu o polityki PBNM (Policy Based Network Management) [3] [4] umoŜliwia definiowanie reguł ściśle związanych z celami
biznesowymi przedsiębiorstwa, które następnie
automatycznie są wdraŜane do sieci i wymuszają
niezbędne zmiany w konfiguracji zarządzanych
elementów. Polityka moŜe składać się z następujących części [4]:
• zdarzenie - jest to zdarzenie wymuszające
sprawdzenie warunku zapisanego w polityce. W polityce autoryzacyjnej, definiującej zasady kontroli dostępu do zasobów takim zdarzeniem moŜe być np.
nadejście Ŝądania zestawienia połączenia o
gwarantowanej jakości usługi,
• warunek - moŜe być zbiorem warunków, które muszą być spełnione, aby została wykonana określona akcja. MoŜe to być np. sprawdzenie czy profil uŜytkownika zawiera odpowiedni priorytet oraz określone dane uwierzytelniające,
• akcja - jest to zestaw czynności jakie muszą być wykonane, gdy warunek jest spełniony. Mogą to być zarówno proste akcje typu: przyjmij (permit) lub odrzuć (deny) [5], jak równieŜ akcje polegające na
wywołaniu pewnych metod z określonymi
parametrami [6].
Wykorzystanie polityk przy zarządzaniu
infrastrukturą IT niesie ze sobą następujące korzyści:
2006
Poznańskie Warsztaty Telekomunikacyjne• zwiększona skalowalność oraz elastyczność systemu zarządzania - system zarządzania wprowadza warstwę abstrakcji, która ukrywa róŜnice między stosowanymi technikami, jak równieŜ róŜnice w sposobach konfiguracji sprzętu pochodzącego od róŜnych producentów,
• deklaratywny sposób zapisu poŜądanego działania sieci - umoŜliwia łatwiejsze wprowadzanie oraz śledzenie zmian w konfiguracji sieci,
• moŜliwość dynamicznej zmiany zachowania
infrastruktury bez konieczności jej wyłączania, • automatyzacja procesu odwzorowywania wymagań
biznesowych na konfigurację urządzeń.
WaŜnym pojęciem w kontekście systemu
zarządzania w oparciu o polityki jest tzw. ciągłość polityk (policy continuum) [4], która zapewnia
moŜliwość odwzorowania reguł biznesowych
definiowanych z wykorzystaniem abstrakcyjnych pojęć np. uŜytkownik, usługa, jakość usługi, na reguły ściśle związane z wykorzystywaną techniką np. źródłowy adres IP, sesja TCP, kod DSCP, i dalej na komendy
konfiguracyjne specyficzne dla poszczególnych
urządzeń. Ideę ciągłości polityk przedstawiono na Rys. 1.
Rys. 1 Ciągłość polityki [4]
Aby zapewnić taką ciągłość konieczne jest
zdefiniowanie odpowiedniej bazy wiedzy.
BAZA WIEDZY
Aby system zarządzania w oparciu o polityki mógł spełniać załoŜenia opisane we wcześniejszym punkcie niezbędny jest formalny zapis wiedzy, na podstawie której mogą być przeprowadzane następujące akcje: • kontrola składniowa polityki - sprawdzenie czy
zdefiniowane reguły są poprawne składniowo, • kontrola semantyczna polityki - sprawdzenie czy
powiązania między poszczególnymi elementami polityki oraz obiektów opisujących zarządzaną domenę są zgodne z ich znaczeniem np. czy określona akcja moŜe zostać zastosowana do danego obiektu,
• rafinacja polityki - odwzorowanie polityk
zdefinowanych na wysokim poziomie abstrakcji na określone komendy konfiguracyjne,
• kontrola wdroŜeniowa - sprawdzenie czy polityka moŜe być wdroŜona, czy zarządzane zasoby mają
odpowiednie właściwości (capabilities) oraz czy aktualna sytuacja w sieci, np. obciąŜenie rutera, umoŜliwia wdroŜenie polityki.
Niezbędne elementy bazy wiedzy oraz powiązania między nimi przedstawiono na Rys. 2. Poszczególne elementy bazy wiedzy mogą być umieszczone w róŜnych elementach sieci, jak równieŜ mogą być
reprezentowane w róŜny sposób. Na Rys. 2
zamieszczono równieŜ aktorów, oraz ich powiązania z określonym elementem bazy wiedzy. MoŜna wyróŜnić następujących aktorów:
• eksperta dziedzinowego - jest to ekspert posiadający duŜą wiedzę o działaniu określonej domeny, który potrafi zdefiniować zasady umoŜliwiające rafinację polityki,
• projektanta sprzętu - jest to ekspert, który jest odpowiedzialny za sformalizowany zapis właściwości projektowanego sprzętu np. rozmiar pamięci, liczba interfejsów itp., ta wiedza jest wykorzystywana przy kontroli wdroŜeniowej,
• projektanta systemu zarządzania w oparciu o polityki, który jest odpowiedzialny za zdefiniowanie składni zapisu polityk oraz za sposób definiowania informacji o politykach (metapolityki),
• uŜytkownika systemu zarządzania w oparciu o polityki - jest to np. operator sieci, który jest
odpowiedzialny za wprowadzenie danych o
zarządzanej domenie np. adresy urządzeń, funkcje pełnione przez poszczególne urządzenia, a następnie definiuje polityki, które opisują poŜądane działanie systemu. Informacje o zarządzanej domenie mogą być
równieŜ zbierane automatycznie w procesie
wykrywania (discovery).
Rys. 2 Elementy bazy wiedzy systemu zarządzania w oparciu o polityki
Ekspert dziedzinowy wspólnie z inŜynierem wiedzy
definiuje bazę wiedzy o zarządzanej domenie.
Identyfikowane są kluczowe pojęcia charakterystyczne dla danej domeny. Pojęcia te mogą być definiowane na róŜnych poziomach abstrakcji. Baza wiedzy musi
zawierać równieŜ informacje o sposobie
odwzorowywania pojęć abstrakcyjnych na pojęcia specyficzne. W przypadku zarządzania siecią z
Ekspert Dziedzinowy
Projektant systemu zarządzania w oparciu o polityki
Projektant sprzętu
Baza wiedzy systemu zarządzania w oparciu o polityki
Baza wiedzy o
rafinacji polityk Składnia poityk
Informacje o politykach (metapolityki) Baza wiedzy o właściwościach sprzętu Baza wiedzy o zarządzanej domenie Baza danych zawierająca informacje o zarządzanej domenie
UŜytkownik systemu zarządzania w oparciu o polityki Poziom biznesowy Poziom systemowy Poziom sieciowy Poziom urządzenia Poziom instancji
Procesy biznesowe, cele, wytyczne, umowy SLA
Działania niezaleŜne od sprzętu oraz od techniki
Działania niezaleŜne od sprzętu, ale specyficzne dla
danej techniki Działania specyficzne dla
danego sprzętu oraz dla danej techniki Implementacja określonych działań w sprzęcie: MIB, PIB,
zaimplementowaną techniką diffserv moŜna zdefiniować następujące pojęcia abstrakcyjne:
• uŜytkownik, • usługa, • jakość usługi,
oraz odpowiadające im pojęcia specyficzne dla danej techniki:
• źródłowy adres IP, • kod DSCP, • zachowanie PHB.
KaŜde z pojęć jest traktowane jako klasa, która ma przypisane pewne atrybuty oraz zachowania.
Ponadto ekspert dziedzinowy jest odpowiedzialny za zdefiniowanie reguł sterujących procesem rafinacji polityk, czyli tłumaczenia polityk zdefiniowanych na
wysokim poziomie abstrakcji na polityki
niskopoziomowe czy teŜ na konkretne komendy konfiguracyjne. Dla wybranego przykładu zarządzanej domeny baza wiedzy o rafinacji polityk mogłaby zawierać następujący, zapisany w sposób nieformalny, wpis:
user1.grant(service(Gold)) -> configure(accessrouter,
mark(user.sourceip, service(Gold).dscp);
Gdy uŜytkownikowi zostaje przydzielone prawo
korzystania z usługi typu Gold (o podwyŜszonej jakości usługi), naleŜy przeprowadzić rekonfigurację wszystkich ruterów dostępowych, tak aby pakiety ze źródłowym adresem IP odpowiadającym danemu uŜytkownikowi, były znakowane kodem DSCP przypisanym do usługi Gold.
Projektant systemu zarządzania w oparciu o polityki definiuje dozwoloną składnię polityk oraz dozwolone informacje o politykach (metapolityki). Metapolityki zawierają m.in. informacje dotyczące cyklu Ŝycia polityki (aktywna, nieaktywna). Te informacje są
wykorzystywane przy analizie składniowej
zdefiniowanych polityk. W literaturze moŜna znaleźć wiele propozycji dotyczących języków opisu polityk [9][10][11].
Projektant sprzętu buduje bazę wiedzy dotyczącą właściwości projektowanego sprzętu. Baza ta moŜe zawierać pojęcia opisujące szybkość pracy procesora, rozmiar pamięci RAM itp. Na podstawie bazy wiedzy o
właściwościach sprzętu, w kaŜdym urządzeniu
utrzymywana jest równieŜ baza wiedzy o stanie urządzenia. Informacje zawarte w tej bazie są
wykorzystywane przy sprawdzaniu moŜliwości
wdroŜenia określonej polityki w sieci. Jako bazę tego typu w systemie zarządzania moŜna wykorzystać powszechnie stosowane bazy MIB dla protokołu SNMP.
UŜytkownik systemu zarządzania w oparciu o
polityki wypełnia bazę danych, w których
przechowywane są informacje o zarządzanych
elementach dla określonej domeny. Informacje te mogą zawierać m.in. adres IP, wspierany protokół zarządzania, grupę funkcjonalną, do której naleŜy dane urządzenie np. ruter dostępowy, ruter szkieletowy.
PRZEGLĄD PROPOZYCJI LITERATUROWYCH
Największą popularnością w implementacjach komercyjnych cieszy się architektura opracowana przez IETF (Internet Engineering Task Force) i opisana w RFC 2753 [13]. JednakŜe zaproponowana architektura jest bardzo prosta i znajduje zastosowanie głównie w systemach związanych z kontrolą dostępu (access-control). Zaproponowana architektura nie rozwiązuje równieŜ problemów związanych z wykrywaniem konfliktów między politykami, a takŜe rafinacją polityk. Nieco zmodyfikowana propozycja IETF znalazła równieŜ zastosowanie w architekturze SAML (Security Assertion Markup Language) [14] zaproponowanej przez OASIS (Organization for the Advancement of
Structured Information Standards). Architektura
uwzględniająca wyŜej wymienione zagadnienia została zaproponowana przez J. Strassnera w [Strassner2004]. Intensywne prace nad architekturą zarządzania w oparciu o polityki są równieŜ prowadzone w Imperial College of London, gdzie opracowano platformę Ponder [15]. Większość proponowanych rozwiązań nie uwzględnia faktu, Ŝe polityki są formą zapisu konfiguracji sieci, a konfiguracja moŜe ewoluować w czasie. W związku z powyŜszym konieczne jest równieŜ uwzględnienie mechanizmów, które zapewnią kontrolę nad cyklem
Ŝycia polityki. Obecnie rozwijanym obszarem
badawczym jest opracowanie sposobu rafinacji polityk.
Metodologię rozwiązania tego problemu
zaprezentowano w [7].
OGÓLNA ARCHITEKTURA SYSTEMU ZARZĄDZANIA W OPARCIU O POLITYKI
W ramach pracy prowadzonej w Katedrze
Telekomunikacji AGH zaproponowana została
architektura systemu zarządzania w oparciu o polityki
zapewniającego spójną KONfigurację zarządzanej
DOmeny z uwzględnieniem Rafinacji polityk
(KONDOR).
Ogólna architektura systemu KONDOR została przedstawiona na Rys. 3.
UŜytkownik systemu KONDOR przy uŜyciu interfejsu uŜytkownika wprowadza polityki na wysokim poziomie abstrakcji zgodnie ze zdefiniowaną składnią.
W systemie KONDOR wykorzystano podejście
zaproponowane w [16][17]. Nowe polityki są tworzone jako instancje klas zdefiniowanych w ontologii opisującej politykę. Do zapisu ontologii wykorzystano język OWL. Zdefiniowana została równieŜ ontologia opisująca właściwości samych polityk (metapolityki). Następnie polityka zapisana w języku OWL jest przekazywana do usługi kontroli składniowej i
semantycznej, która sprawdza poprawność
zdefiniowanej reguły. Usługa kontroli składniowej i
semantycznej korzysta z wiedzy zapisanej w
repozytorium, do której dostęp jest kontrolowany przez usługę magazynowania. Usługa ta jest odpowiedzialna za wyszukiwanie odpowiednich informacji w bazie polityk oraz bazie wiedzy. Po zakończeniu kontroli poprawności, polityka jest przekazywana do usługi kontroli uruchomieniowej, która sprawdza czy dana polityka moŜe zostać wdroŜona do sieci. Kontrola
obejmuje sprawdzenie moŜliwości zarządzanych elementów (capabilities) oraz dostępnych zasobów (np. obciąŜenie procesora, liczba dostępnych kanałów radiowych itp.). Po pozytywnym zakończeniu kontroli uruchomieniowej polityka moŜe zostać wdroŜona do sieci. Usługa wdroŜenia jest odpowiedzialna za przesłanie odpowiednich komend konfiguracyjnych do zarządzanych urządzeń. Po poprawnym wdroŜeniu
polityki, system KONDOR moŜe otrzymywać
informacje o określonych zdarzeniach w sieci np. o degradacji jakości usługi, i podejmować próby adaptacji polityk zgodnie z wytycznymi zapisanymi w bazie wiedzy. Usługa adaptacji nie będzie implementowana w pierwszej wersji systemu KONDOR.
Rys. 3 Architektura systemu zarządzania KONDOR WERYFIKACJA ZAPROPONOWANEGO
ROZWIĄZANIA
Skuteczność zaproponowanej architektury zostanie sprawdzona dla domeny składającej się z rozbudowanej
sieci punktów dostępowych WLAN. W sieci
korporacyjnej posiadającej wiele punktów dostępowych
WLAN, jednym z kluczowych zagadnień jest
zapewnienie jednolitej polityki związanej z kontrolą
dostępu do sieci bezprzewodowej, zapewnienia
odpowiedniej jakości usługi, zarządzania zasobami
radiowymi, zapewnienia odpowiedniego poziomu
bezpieczeństwa. Zastosowanie systemu zarządzania w oparciu o polityki, w którym będzie moŜliwe definiowanie polityk na wysokim poziomie abstrakcji a następnie odwzorowanie ich na określoną konfigurację punktów dostępowych oraz ruterów umoŜliwi obniŜenie kosztów utrzymania infrastruktury oraz zmniejszenie zagroŜeń związanych z niespójną konfiguracją sieci.
SPIS LITERATURY
[1] IDC'c Dynamic IT Survey, January 2005, http://www.idc.com/
[2] N. Shadbolt, T. Berners-Lee, W. Hall, The Semantic Web Revisited, IEEE Intelligent Systems, May/June 2006
[3] D.C. Verma, Policy-Based Networking:
Architecture and Algorithms, New Riders
Publishing, 2001
[4] Strassner J., Policy Based Network Management, Elsevier 2004
[5] T. Moses (ed.), eXtensible Access Control Markup Language (XACML) Version 2.0, OASIS Standard, 1 February 2005
[6] N. Damianou, A Policy Framework for
Management of Distributed Systems, PhD Thesis, Imperial College of London, 2002
[7] J. Rubio-Loyola, J. Serrat, M. Charalambides, P. Flegkas, G. Pavlou, A Methodological Approach toward the Refinement Problem in Policy-Based Management Systems, IEEE Communications Magazine, October 2006
[8] T. Berners-Lee, J. Hendler, O. Lassila, The Semantic Web, Scientific American, May 2001 [9] J. Lobo, R. Bhatia, S. Naqvi. A Policy Description
Language, 16th National Conf. on Artificial Intelligence, Orlando, USA, July 1999.
[10] N. Damianou, N. Dulay, E. Lupu, M. Sloman: The
Ponder Policy Specification Language. In
proceedings of 2nd IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY 2001), Bristol, January 2001.
[11] Damianou, N., A. Bandara, M. Sloman, E. Lupu (2002b), A Survey of Policy Specification Approaches, Department of Computing, Imperial College of Science Technology and Medicine, London, April 2002
[12] D. Booth (ed.) et al., Web Services Architecture, W3C Working Group Note, 11 February 2004 [13] Yavatkar R., Pendarakis D., Guerin R., A
Framework for Policy-based Admission Control, RFC2753
[14] P. Madsen, E. Maler, SAML V2.0 Executive Overview, Committee Draft 01, 2005, OASIS [15] N. Damianou, N. Dulay, E. Lupu, M. Sloman, T.
Tonouchi, Tools for Domain-based Policy
Management of Distributed Systems, IEEE/IFIP Network Operations and Management Symposium (NOMS2002), Florence 2002.
[16] L. Kagal, T. Finin, A. Joshi, A Policy Language for A Pervasive Computing Environment. In IEEE 4th International Workshop on Policies for Distributed Systems and Networks, June 2003
[17] A. Uszok, J. Bradshaw, R. Jeffers, N. Suri, P. Hayes, M. Breedy, L. Bunch, M. Johnson, S. Kulkarni, J. Lott, KAoS Policy and Domain Services: Toward a Description-Logic Approach to
Policy Representation, Deconfliction, and
Enforcement, Fourth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'03), 2003
System zarządzania KONDOR
Interfejs uŜytkownika Obsługa zdarzeń Zarządzana domena Usługa kontroli składniowej i semantycznej Usługa wdroŜenia Usługa adaptacji zdarzenia polityka polityka polityka polityka komendy konfiguracyjne Usługa magazynowania informacji o politykach oraz baza wiedzy Usługa kontroli uruchomieniowej
informacja o stanie zasobów Ŝądanie zmiany konfiguracji
