Breitbandnetzwerke: optische Galsfernetze und ATM.
Neue Software Technologine: Client/Server Paradigma, Objektorintiertheit, Middleware Plattformen
Neues Equipment: Multimedia PCs, Mobiltelphone, Mikroelektronik-Equipment
Der zunehmende Einsatz von Netzwerken (Ethernet, FDDI, DQDB).
Die Bewegung zu zunehmend heterogenen Hard- und Softwareinstalltionen.
Kooperative Strukturen.
Networks (IN, VPN, Corporate, MAN, LAN, WAN)
Functional Areas (Fault, Configuration, Accounting, Performance, Security)
Life Cycle (Changes, Operation, Installation, Planing)
Communication Services (Multimedia, Video, Speech, Data Services)
Classes of Management (Enterprise-, Service-, Application-, System-, Network-Management)
Top down Ansatz: Voraussetzungsanalyse des gesamten Systems; buisness: die wichtigstens Dinge fürs Buisness (Rollen) -> DATA; functional: Prozesse (Service) die ausgeführt wernde -> FUNCTIONS; networking: wo das Buisness operiert -> COMMUNICATIONS
Partitioning: service oriented (signaling network, packet switched network); functional areas (FCAPS); OSI-RM layers (N-layer management) -> vertical; TMN layers (buisness, service, network, network element) -> vertical; geographical -> horizontal
Wozu: Managemenet Architekturen ermöglichen hohe Abstraktionslevel für Designer, und sind hilfreich für den Entwurf von Management Prokollen und Services
Bestandteile: Konzepte (Einfachheit, Offenheit); Regeln, wie die Konzepte angewandt werden; Modelle visualisieren wie Konzepte und Regeln zu System zusammengebaut werden könne
Architectural Concepts + Architectural Rules => Architectural Modells => Management Services and Protocols => Real network systems
Manager sind Programmteile die mit den Agenten kommunizieren, um deren Status abzufragen und zu verändern, Daten in DBs speichern, und all diese Informationen dem Administrator oder weiteren Management Systemen zur Verfügung stellen.
Agenten laufen auf den Hardwarekomponenten, überwachen deren Status und können Einstellungen daran vornehmen. Sie kommunizieren mit den Managern.
MOs representiern eine Abstraktion einer physische oder logische Resource in einem gemanagten Netzwerk.
Objektorintierte Datenbanken die die Informationen über MOs speichern nennt man MIBs
Information Model: besteht aus Elemente von gemangten Komponeten (MOs), die sich aus attributes, actions, notifications, behaivior, und encapsulation zusammensetzen, und über definierte Schnittstellen mainipuliert werden können.
Functional Model: unterteilt das Management in funktionale Gebiete, mit definierten Funktionalitäten und Services die diese Funktionalitäten anbieten.
Communication Model: spezifiziert wie die Einheiten zu kommunizieren haben, wie die Einheiten identifiziert werden können, und die Syntax und Semantik der Kommunikation.
Organization Model: ermöglicht die Anpassung an die Organisationsstrukture der Benutzer, indem es Einteilung in Domains ermöglicht und Rollen und Beziehungen zwischen Manager und Agenten festlegt.
Das wichtigste Konzept für SNMP ist Einfachheit (simplicity). Das Rahmenwerk von SNMP soll möglichst konstengünstige Software und resourcenschonende Agenten ermöglichen, um alle Arten von IP-basierten Geräten zu managemen. Je höher die Versionnummer desto mehr Features wurden eingebaut, desto komplexer wird SNMP aber auch.
Allgemein: Attribute, Aktionen, Verhalten, Benachrichtigungen und encapsulation
In SNMP konkret:
Syntax: ein ObjectType der in ASN.1 definiert sein muss.
Definition: eine textuale Beschreibung des Objektes.
Access: read-only, read-write, write-only, oder not-accessible.
Status: mandatory, optional, oder obsolete.
Name: der Indentifier innerhalb der Baumstruktur der MIB.
Abstract Syntax Notation One (ASN.1)
Bei den Object Indetifier handelt es sich um eine Reihe von Zahlen, die dazu dienen den Baum in der MIB zu traversieren.
Wobei es jeweils eine Object-ID gibt (z.B. 1.1) und eine Instanze des Objects (1.1.0) der dann erst den Wert bzw. den Namen enthält. In Tabellen gibt man die Spalte an, und alles danach folgende, wird als Index für die vorherigen Spalten benutzt.
Es benutzt das verbindungslosen Prokoll UDP, wobei der Manager Requests an den Angeten schickt die dieser mit Responses beantwortet. Einzige Ausnahme hierbei ist die Trap, bei der der Agent den Manager über den Eintritt eines Ereignisse informiert, woraufhin dieser anfängt, die gewünschten Daten zu pollen (trap directed polling).
Die Kommunikation erfolgt mit Nachrichten, die Varaiblen auslesen oder veränder, und entweder komplett erfolgreich oder nicht erfolgreich sind.
GetRequest: wird vom Manager gesendet um das Attribute-Value-Pair zu einem Attribute zu bekommen.
GetNextRequest: wird vom Manager gesendet um das lexikographisch nächste Attribute-Value-Pair zu bekommen.
GetResponse : wird vom Agenten gesendet um die Antwort auf ein Get(Next)/Set zu liefern.
SetRequest: wird vom Manager gesendet um den Inhalt bzw. den Value einer Instanz zu ändern.
Traps: wird vom Agenten gesendet um den Manager über den Eintritt eines Ereignisses zu informieren.
Die Community dient der Authentification. Nur wenn Manager und MO in der gleichen Community sind ist eine Kommunikation zwischen ihnen möglich.
Party-based Security: der oder die Agenten und der Manager bilden eine Party (eine logische Gruppe). Zu jeder Party gibt es dann ein MO welches den Name, Verschlüsselung, Authentication, Transportprotokol etc enthält. -> Komplexe Kofiguration, langsame und komplexe Synchronisation der Uhren notwendig.
User-based Security: hierbei erfolgt die Authentication über eine Username, Passwort Kombination. Im Agenten müssen diese Informationen gespeichert werden. -> Einfache Konfiguration, effiziente Zeit-Synchronisation, kein neues Messageformat.
Dispatcher: sendet und empfängt Nachrichten von der Protocol und Netzwerkeinheit, stellt die SNMP Version fest und startet das entsprechende Message Processing, bietet ein Interface zum versenden von SNMP Messages.
Message Processing: baut Nachrichten entsprechend dem Protkoll zusammen und auseinander. Pro Prokol jeweils eine vorhanden.
Security: kümmert sich um Authentication und Verschlüsselung und eventuelle Security Models.
Access Control: bietet einen Authentication Service anhand von einem oder mehreren Access Control Models.
Weil es nur ein Rahmenwerk bietet, indem einzelne Subsystem ausgetauscht oder hinzugefügt werden können. So kann z.B. Kompabilität zu v1 und v2 hergestellt werden indem entsprechende Message Processing Subsystem bereit gestellt werden.
Im Prinzip alle, denn es hängt nur davon ab, welche Transportprotokolle dem Dispatcher an der Transport Mapping Schnittstelle zur Verfügung stehen. Aus Kompatibilitätsgründen dürfte UDP immer unterstützt werden.
Das OSI Directory Model X.500 sieht ein grosses globales Directory vor, in dem alle Daten hierarchisch in einer Datenbank gespeichert werden. Jeder Eintrag enthält ein Attribut und jedes Attribut hat einen Type und mindestens einen Wert. Die Definitionen für das ganze werden mal wieder in ASN.1 gemacht.
Object Klassen werden in ASN.1 beschrieben. Darin wird angegeben von welcher Klasse die Klasse die Subklasse ist (alle Klassen sind Erben von der Klasse top), welche Attribute zwingenden notwendig sind, und welche Attribute optional sind.
Jedes Object hat einen Relative Distinguished Name (RDN), der aus einem Attribut Type und dem zugehörigen Value besteht. Der Distinguished Name (DN) ist der global eindeutige Identifier für das Object, und setzt sich aus der Kette von RDN seiner Superklassen und seinem eigenen RDN zusammen. Der RDN von Root ist leer, und der DN von ist nur eine geschweifte Klammer { }.
Der DUA ist das Stück Software, welches mit dem Benutzer interagiert. Der DUA leitet die Anfragen mit Hilfe des Directoy Access Procols (DAP) an seinen lokalen Directory System Agent (DSA) weiter. Sofern dieser die Anfrage nicht selber beantworten kann befragt er selber den nächsten DSA mit Hilfe des Directory System Protocol (DSP), oder er gibt den DUA eine Referenz auf den DSA der nächster zu befragen ist. So hangeln sich der DUA oder DSA durch den Baum, bis die Antwort gefunden ist.
attributes: Eigenschaften die das MO von allen anderen unterscheiden.
operations: Aktionen die auf dem MO ausgeführt werden können.
behaviour: Reaktionen auf die Operationen und Zwänge (constraints).
notifications: Reports die das MO bei Events verschickt.
create, delete, und action
Abstract Syntax Notation One = ASN.1
Containment Relationen bestehen nur zwischen Instanzen, wärend Inheritance zwischen Klassen auftreten. Jeder Instanz einer Superklasse contained die Instanzen ihrer Subklassen. Die Vererbung läuft aber genau anders herum, die Subklasse erbt alles (attribute, operationen, behaviour) und erweitert dieses dann um ihren eigenen ``Dinge''.
Containment bedeutet, dass die Instanz einer Klasse komplet in der Instanz einer anderen Klasse enthalten ist. Dies geht nur bei Instanzen, und soll reale Verhältnisse abbilden können (Teil X besteht aus den Bauteilen Y und Z).
Name Binding ist die Relation auf die übergeordnete Objekt Klasse, aus der sich der Name des Objektes ergibt.
Relative Distinguished Name ist die Attribute Value Kombination die dem Objekt seinen Namen gibt.
Distinguished Name ist der eindeutige Name innerhalb eines Management Systems der sich aus dem RDN des Objektes und den RDNs seiner Container ergibt.
Die funktionale Bereiche umfassen zum einen die Rollen Manager und Agent, und zum anderen die allseits beliebten FCAPS (Fault, Configuration, Accounting, Performance, Security).
system management, (N)-layer management, und (N)-layer operations. System Management ist die Möglichkeit über Layer-Grenzen hinweg und unabhängig vom Layer Management zu betreiben. Beim (N)-layer management wird speziell ein Layer gemanaged. Und (N)-layer operations sind dazu da, dass der Layer selber sich regulieren kann. Damit sind alle Möglichkeiten im Layer-Modell abgedeckt, ausser von unten nach oben, was aber keinen Sinn machen würde.
Protokolle dienen der Kommunikationen von Entitäten auf gleicher Layer-Ebene, wärend Service vom niedrigeren Layer an den höheren Layer angeboten werden. Der Common Management Information Service (CMIS) wird als Service von den offenen Management Application genutzt um die Objekte zu managen. Der CMIS benutzt bei der Ausführung seiner Services zur Kommunikation wiederum das Common Management Informatio Protocol (CMIP).
CMIP und es unterstützt:
CMIP ist Verbindungsorientiert, kann dynamisch den Zielbereich auswählen, ist Eventbasiert und erfordert recht viel Aufwand im Agent. SNMP dagegen ist Verbindunglos, die Management-Applikation ist verantwortlich für Security und Zuverlässigkeit, trap directed polling und erheblich mehr Aufwand beim Manager.
Beim OSI Management hat man mehr Möglichkeiten, da eine volle Vererbung gegeben ist, und man vollen gebrauch von ASN.1 machen kann. Auch die Bennenung ist bei OSI flexibler, da sie nur vom Containment abhängig ist.
TMN soll beim Management von Telekomunikationsnetzwerken und Services hilfreich sein. Dazu ist in TMN ein Framewrok definiert, der die Planung, Installation, den Betrieb und die Wartung von Services unterstützen soll. Dies wird erreicht durch standardisierte Protokolle und Interfaces.
Das sind die Grundeinheiten bzw. Teile des Netzwerks mit denen und zwischen denen Management mit TMN betrieben wird.
Allgemein durch interoperable Interfaces. Im Detail durch die Vorgabe der Strukture der Management Informationen, eine formale MIB Spezifikation, durch Management Protkolle und einen allgemeine drunterliegenden unterstützenden Protokoll Stack. Die konkrete Implementierung wird nicht vorgegeben.
Es gibt:
In der Abstract View ist die Real Resource innerhalb des MOs, wärend es in der Real World View ausserhalb des MOs liegt und nur mit diesem interagiert. Generell wird das MO durch operations angesprochen, und kann notifications auf sich aufmerksam machen.
Die Referenzpunkte werden zu Interfaces, allerdings nur wenn sie gebraucht werden, und es werden Building Blocks definiert die genau den fuktionalen Blöcken entsprechen. Die Interface werden definiert durch den zu benutzenden Protokoll Stack und das jeweilige information model (Interface=protcol stack+object model).
s.o. Ein Interface ist definiert eine Prokoll Suite und einem Set of messages.
Applications Paradigms: event driven, polling based, event-directed polling
Communication Paradigms: connection oriented, connectionless, connectionless with guaranteed delivery
Weil nur dieser die genauen statischen Daten über die Nutzung der einzelnen Network Elements vorhalten muss, und nur für deren Erstellung die MF benötigt wird. ???
Ja dies ist möglich, da die vorgegebene Layer Struktur nicht umbedingt den Layern in der Realität entsprechen muss, und daher auch ein Zugriff über mehrere Layer möglich sein muss. Und weil man eventuell/im Zweifelsfall Zugriff von Service auf den Element Layer braucht.
Agenten arbeiten dezentralisiert, d.h. mit ihnen kann mehr Logik direkt vor Ort in das zu managende Objekt (oder zumindest in dessen Nähe) gebracht, werden. Dieser Agent kann auftretende Probleme versuchen zu lösen, und erst im Notfall sich beim zentralen Management melden und auf das Problem hinweisen.
Die MA können die Service lokal, d.h. so nah wie möglich am benötigten Einsatzort, liefern. Dies wiederum kann man noch mit zeitbasiertem anbieten, load balacing, und voll automatischen service on demand kombinieren.
Management by Delegation heisst, man verändert nicht mehr eine MIB-Variable nach der anderen von zentraler Stelle aus, sonder delegiert solche Wartungsausfgaben an einen Agenten, der sich auf den Weg durchs Netz macht, vor Ort die geforderten Änderunge vor nimt (die natürlich auch komplexer sein können, als nur einen Variable-Wert zu ändern), und dann weiter wandert, bis er schliesslich wieder nach Hause zurück kehrt.
Das Management gestaltet sich schwieriger da man nicht immer sicher sein kann wo sich ein Objekt gerade befindet bzw. ob es überhaupt noch existiert. Beim zustellen von Notifications ergeben sich Adressierungsprobleme und bei Transaktionen ist schwierig sicher zu stellen, dass diese auch ausgeführt worden sind, bzw. wieder rückgängig gemacht werden (können).
Indem man ihre bestehenden Interface um ein weiteres Management-Interface erweitert.
Lokale Manager kümmern sich nur um die Aufgaben im ihrem Bereich und müssen daher nicht mehr über das gesamte globale Wissen eines globalen Managers verfügen.
Man benutzt Adressierungslisten in denen der Zielagent und auch die Agenten auf dem Weg zum Ziel angegeben sind. Um nicht riesige Listen mit eventuellen Doppeltnennungen entstehen zu lassen kann mit dem RecursivelyFlag angezeigt werden, dass die Operation für alle Agenten/MOs unterhalb des Ziel ebenfalls gemeint sind.
Um die Kommunikationsbeziehungen auch nach der Bewegung bzw. Ersetzung von Agenten konsistent zu halten.
Die Content-related Analysis liefert Aufschluss darüber welche Daten im System genutzt werden (wie lange, wie häufig, etc.). Die System-related Analysis hingegen liefert Daten darüber welche Objekte im System benutzt werden. Beides wird gemacht um herauszufinden wo bzw. wie man am besten mit einem Management ansetzt, d.h. wo und ob es sich lohnt die Dinge mit einem Management zu überwachen und zu regeln.
This document was generated using the LaTeX2HTML translator Version 2002-2 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir27104JuxJjj/lyx_tmpbuf2/Management_Zusammenfassung.tex
The translation was initiated by Nils Ohlmeier on 2003-07-22