DE60303106T2

DE60303106T2 - Kommandozeilenschnittstellen Prozessor mit dynamischer Aktualisierung von Attributabhängigkeiten

Info

Publication number: DE60303106T2
Application number: DE2003603106
Authority: DE
Inventors: Christopher Warren K2C 4E1 Ottawa MURRAY; David K2G 6J9 Nepean WING-CHUNG CHAN; Thomas Vincent K2P 1S9 Ottawa FLYNN
Original assignee: Alcatel Canada Inc
Current assignee: Nokia Canada Inc
Priority date: 2002-08-19
Filing date: 2003-08-12
Publication date: 2006-08-24
Anticipated expiration: 2023-08-13
Also published as: EP1392019A1; DE60303106D1; EP1392019B1

Description

Diese Anmeldung ist eine Verbesserung von und beansprucht die interne Priorität der gleichzeitig anhängigen, gemeinsam übertragenen US-Patentanmeldung 10/115, 900, eingereicht am 05. April 2002, mit dem Titel "Command Line Interface Processor".
Die Erfindung betrifft Fernmeldenetzwerkverwaltung und insbesondere befehlsgesteuerte Verwaltung von Geräten mehrerer Anbieter.
Auf dem Gebiet der Fernmeldenetzwerkverwaltung bestehen Fernmeldenetze aus einer Sammlung von verwalteten Fernmeldenetzwerkgeräten. Fernmeldedienste werde über die verwalteten Fernmeldenetzwerkgeräte bereitgestellt.
Auf einem kompetitiven Markt wird durch eine explosive technologische Entwicklung in letzter Zeit die Aufgabe der Netzwerkverwaltung und Dienstbereitstellung durch viele Faktoren verkompliziert, darunter: eine Vielzahl von FernmeldenetzwerkGeräteanbietern, die mehrere Ansätze bei der Implementierung der Fernmeldenetzwerkgeräte verfolgen; eine Vielzahl von Datentransporttechnologien, wobei jeder Anbieter sich auf eine Untergruppe aus der Vielzahl von Datentransporttechnologien spezialisiert; eine Vielzahl von Netzwerkverwaltungs- und Dienstbereitstellungsprotokollen, wobei jeder Anbieter nur eine Untergruppe aus der Vielfalt von Netzwerkverwaltungs- und Dienstbereitstellungsprotokollen implementiert; eine Vielfalt von Hilfs-Netzwerkverwaltungs- und Dienstbereitstellungsgeräten, die wiederum eine Vielzahl von Netzwerkverwaltungs- und Dienstbereitstellungstechnologien verwenden, etc.
Träger und Dienstanbieter von Fernmeldediensten sind konfron tiert mit einem großen Betriebsaufwand beim Betreiben von Geräten mehrerer Anbieter, müssen aber gleichzeitig Geräte mehrerer Anbieter verwenden, um das mit der installierten Fernmeldeinfrastruktur zusammenhängende Investitionsrisiko im Griff zu behalten.
Kommunikationsnetzwerkgeräte umfassen ohne Einschränkung auf diese: Vermittlungsgeräte, Router, Bridges, Zugangsknoten mit Multiplexfunktion, Fernzugriffs-Server, Verteilerknoten mit Demultiplexfunktion, Vor-Ort-Geräte beim Kunden etc., wobei Fernmeldegeräte der nächsten Generation in Entwicklung sind. Fernmeldenetze umfassen Datentransportnetze sowie vermittelte Netze.
Im Hinblick auf Fernmeldenetzwerkgeräte, zum Beispiel in 1 schematisch gezeigte Vermittlungsknoten, kann ein Anbieter sich entscheiden, eine integrale Vorrichtung 110 mit einem Vermittlungsprozessor und einer Gruppe von Anschlüssen 112 zu implementieren, wohingegen sich ein anderer Anbieter für eine anpassbare Implementierung eines Vermittlungsknotens 120 entscheiden mag, der umfasst: eine Vermittlungsmatrix, ein in Fächer unterteiltes Geräteregal, wobei jedes Fach 122 Slot-Verbinder zum Anschließen an Schnittstellenkarten hat und jede Schnittstellenkarte 124 wenigstens einen Anschluss 112 hat. Obwohl konzeptionsmäßig die zwei Vermittlungsknoten 110 und 120 die gleiche Vermittlungsfunktion bieten, ist jede Implementierung an eine andere Umgebung angepasst: der erste Vermittlungsknoten 110 ist eher angepasst, eine Firmenlösung als privater Fernmeldenetzwerkknoten zu bilden und ist dabei vielleicht ferner angepasst, den Zugang zu öffentlichen Fernmeldediensten zu ermöglichen; der letztere Vermittlungsknoten 120 hingegen ist besser angepasst für hohen Datendurchsatz im Kern von öffentlichen Fernmeldenetzen. Typischerweise implementiert der erstere (110) eine kleine Zahl von Datentransportprotokollen, während für den letzteren (120) Datentransportprotokolle auf Schnittstellenkarten 124 und/oder Anschlüssen 112 implementiert sind, was deren flexible Nutzung ermöglicht. Alle Kommunikationsnetzwerk-Geräte unterliegen Konstruktionsentscheidungen, die notwendigerweise von Anbieter zu Anbieter verschieden sind.
Datentransporttechnologien umfassen: elektrische Übertragung von Daten über Kupferpaare, Koaxialkabel etc.; optische Übertragung von Daten über optische Kabel; optische Freiraumverbindungen etc.; drahtlose Übertragung von Daten über Funkmodems, Richtfunkverbindungen, drahtlose lokale Netze (LAN) etc.; wobei Datentransporttechnologien der nächsten Generation in Entwicklung sind.
Datentransportprotokolle, die zum Befördern von Daten zwischen Datentransportgeräten verwendet werden, umfassen: Internetprotokoll (IP), Ethernet-Technologien, Token-Ring-Technologien, Fiber Distributed Data Interface (FDDI), Asynchronous Transfer Mode (ATM), Synchronous-Optical-NETwork-(SONET)-Übertragungsprotokoll, Frame Relay (FR), X-25, Zeitmultiplex-(TDM)-Übertragungsprotokoll, Packet-Over-Sonet (POS), Multiprotokoll-Label-Switching (MPLS) etc., wobei Datentransportprotokolle der nächsten Generation in Entwicklung sind.
Die oben angesprochenen physikalischen Fernmeldenetzwerkgeräte sind Teil eines größeren Verbundes von verwalteten Fernmeldenetzwerkeinheiten, die die Bereitstellung von Fernmeldediensten ermöglichen. Die Fernmeldenetzwerkeinheiten umfassen ohne Einschränkung auf diese: virtuelle Router, logische Anschlüsse, logische Schnittstellen, End-to-End-(Daten)-Verbindungen, Pfade, virtuelle Schaltungen, virtuelle Pfade etc.
Die Technologien, die die Netzwerkverwaltung und Dienstbereitstellung ermöglichen, umfassen Protokolle, sind aber nicht darauf beschränkt: Simple Network Management Protocol (SNMP), Common Management Information Protocol CMIP), Command Line Interface (CLI) etc., aber auch Geräte: Server mit spezieller Funktion, zentralisierte Datenbanken, verteilte Datenbanken, relationale Datenbanken, Verzeichnisse, Netzwerkverwaltungssysteme etc., wobei Geräte und Technologien der nächsten Generation in Entwicklung sind.
Netzwerkverwaltungs- und Dienstbereitstellungslösungen umfassen Netzwerkverwaltungssysteme (Network Management Systems NMS) 140, die über spezielle Softwareanwendungen ermöglicht werden, die codiert sind, um die oben erwähnten Fernmeldenetzwerkeinheiten zu konfigurieren und zu steuern. Solche Softwareanwendungen haben, ohne Einschränkung darauf, Funktionalitäten wie: Inventarbericht, Konfigurationsverwaltung, Statistikerfassung, Leistungsbericht, Fehlerverwaltung, Netzwerküberwachung, Dienstbereitstellung, Abrechnung und Buchführung, Sicherheit etc.
Es ist eine gewaltige Aufgabe, Netzwerkverwaltungs- und Dienstbereitstellungslösungen zu schaffen, die die Permutationen und Kombinationen der oben dargestellten Elemente berücksichtigen. Herkömmliche Ansätze zum Schaffen von Netzwerkverwaltungs- und Dienstbereitstellungslösungen umfassen das Codieren von Hunderten von Softwareanwendungen in Kenntnis von Hunderten von Datennetzwerkeinheiten, die mehrere zehn Datenübertragungs- und Netzwerkverwaltungsprotokolle verwenden. Manche herkömmliche Lösungen versuchen, allumfassende, große monolithische Netzwerkverwaltungs- und DienstbereitstellungsSoftwareanwendungen zu codieren.
Das Codieren, Warten, Anwenden und Erweitern solcher Softwareanwendungen für die Netzwerkverwaltung und Dienstbereitstellung war und ist ein enormes Unterfangen und eine hochkomplexe Prozedur. Die Schaffung solcher Softwareanwendungen erfordert eine große Zahl von Mann-Stunden, häufig werden sie mit zahlreichen Problemen ausgeliefert und sind schwierig zu verändern oder zu unterstützen. Die Schwierigkeit bei der Schaffung und Unterstützung großer Anwendungen ist in erster Linie begründet durch die Unfähigkeit existierender Softwareentwicklungsparadigmen, eine Vereinfachung des Softwareentwicklungsprozesses zu schaffen. Es wurde gezeigt, dass gemäß gegenwärtigen Codierparadigmen die Komplexität der Softwareanwendungen als eine anwachsende Funktion der Anzahl von verschiedenen Operationen, die durchgeführt werden sollen, zunimmt. Große Programmieranstrengungen leiden an mangelhafter Leistung, Zuverlässigkeit, Entwicklungskosten und vernünftigen Entwicklungszyklen.
Auf dem Feld der Datennetzwerkverwaltung wird versucht, Konfigurations- und Steueraufgaben durch die Einführung des oben erwähnten SNMP-Protokolls zu automatisieren. Typischerweise haben Datennetzwerkelemente eine Elementverwaltungsschnittstelle, die dem SNMP-Protokoll entspricht. Obwohl das SNMP-Protokoll eingeführt worden ist, gibt es Datennetzwerkelemente, die das SNMP-Protokoll nicht unterstützen, sei es konstruktionsbedingt oder weil diese Vorrichtungen vor der Standardisierung des SNMP-Protokolls in Betrieb genommen wurden. Von den Datennetzwerkelementen, die das SNMP-Protokoll unterstützen, unterstützen manche nicht alle SNMP-Fähigkeiten.
Die Fähigkeit, Datennetzwerke unter Verwendung einer Befehlszeilenschnittstelle (Command Line Interface, CLI) über eine CLI-Elementverwaltungsschnittstelle zu konfigurieren, ist verbreiteter. Jede Kommunikationsnetzwerkeinheit hat konfigurierbare Betriebsparameter, die ihr zugeordnet sind. Verwaltete Kommunikationsnetzwerkeinheiten reagieren auf Befehle mit zugeordneten Attributen. Die CLI-Befehle sind typischerweise anbieterspezifisch. Die Befehlzeilenschnittstelle ist eine textbasierte Art der Mensch-Maschine-Interaktion, die auf textbasierte CLI-Befehle reagiert und typischerweise ergänzt ist durch Informationsrückkopplung in Textform. CLI-Schnittstellen werden von einem Analysten verwendet, um manuell CLI-Befehle einzugeben, um ein einzelnes Datennetzwerkelement zur Verwaltung desselben zu konfigurieren und zu steuern, und über dieses Fernmeldenetzwerkdienste bereitzustellen. Die Eingabe von CLI-Befehlen wird als eine zeitaufwendige und fehlerträchtige Prozedur angesehen und ist daher unerwünscht. Außerdem ist die auf menschlicher Interaktion basierende Antwort auf Fernmeldenetzwerkfehler aufgrund des ständig zunehmenden über die Fernmeldenetzwerkgeräte beförderten Durchsatzes unzureichend. Die Industrie hat nach Verfahren gesucht, um CLI-befehlsbasierte Konfigurations- und Steueraufgaben zu automatisieren.
Diverse Hersteller von Datennetzwerkelementen haben eine interaktive Softwareanwendung geschaffen, um ein Datennetzwerkelement über die zugeordnete CLI-Schnittstelle zu konfigurieren. Solche Elementverwaltungs-Softwareanwendungen neigen dazu, proprietär zu sein, und sie neigen dazu, die Konfiguration eines bestimmten Typs von Datennetzwerkelement in der Weise anzugehen, wie es vom Anbieter des Gerätes zur Zeit von dessen Entwicklung für richtig gehalten wurde. Typischerweise sind solche proprietären Lösungen nicht erweiterbar und eignen sich nicht für eine integrierte Verwaltung von Datennetzwerkbetriebsmitteln, was ihre Nützlichkeit sehr einschränkt.
Bekannte Versuche der Konfiguration und Steuerung von Datennetzwerkelementen umfassen eine von CISCO Systems, Inc. vorgeschlagene skriptbasierte Technik. Die verwendeten Verfahren umfassen die manuelle Erzeugung von Stapeldateien-Skripten aus CLI-Befehlen, wobei jedes Skript eine bestimmte Änderung in der Konfiguration eines bestimmten Datennetzwerkelementes anspricht. Ein solches CLI-Befehlsskript wird in das bestimmte Datennetzwerkelement heruntergeladen und ausgeführt, um die gewünschten Änderungen vorzunehmen. Dieser Versuch basiert auf einem angestrebten Ziel, demzufolge alle CISCO-Datennetzwerkelemente eine gemeinsame CLI-Befehlssyntax, auch als CLI-Vokabular und -Grammatik bezeichnet, verwenden. Solche Lösungen neigen dazu, auf Geräte eines bestimmten Anbieters, das heißt, auf CISCO-Router beschränkt zu sein. Ferner werden solche Skripte normalerweise ausgegeben mit der Erwartung, dass die gewünschte Änderung ausgeführt wird.
Von Zeit zu Zeit umfasst, wenn Datennetzwerkelemente aktualisiert werden, die Aktualisierung typischerweise auch Änderungen am CLI-Vokabular oder der -Grammatik. Die Verwendung von komplizierten Skripten neigt dazu, die Konfiguration und Steuerung der Datennetzwerkelemente zu behindern, da auch die Skripten aktualisiert werden müssen, um Änderungen im CLI-Vokabular und/oder -Grammatik wiederzuspiegeln. Auch kleine Änderungen an CLI-Befehlsattributen erfordern Änderungen an solchen Skripten.
Andere Anbieter von Datennetzwerkverwaltungssoftware haben bei der Implementierung von Netzwerkverwaltung andere Ansätze verfolgt. Service Activator von Orchestream Holdings Plc. verwendet eine Gerätetreibersoftware für eine CISCO-datennetzwerkelementspezifische Konfiguration. Jeder Gerätetreiber umfasst spezifischen Anwendungscode zum Verwalten eines spezifischen Typs von Datennetzwerkelement. Der Gerätetreibercode wird verwendet, um einen gegenwärtigen Status eines bestimmten Datennetzwerkelementes zu extrahieren, den gegenwärtig berichteten Zustand mit einem in der Service-Activator-Software gespeicherten virtuellen Zustand zu vergleichen, eine Gruppe von Befehlen zu erzeugen, die notwendig sind, um virtuellen und realen Zustand zu synchronisieren, und die Gruppe von Befehlen zu senden, damit sie von dem Datennetzwerkelement ausgeführt wird. Der Prozess iteriert, bis der berichtete Zustand zu dem virtuellen Zustand passt. Dieser Ansatz berücksichtigt nicht Fehler, die bei der Ausführung von Befehlen erzeugt werden, statt dessen leitet er von Diskrepanzen zwischen dem gegenwärtigen Zustand und dem virtuellen Zustand Warnungen ab. Dieser Ansatz nutzt hartcodierte Gerätetreiber, die maschinenlesbaren Objektcode verwenden, der für einen Analysten, der versucht, einen solchen Devicetreiber zu debuggen, unverständlich ist.
Wenn Fernmeldenetzwerkelemente aktualisiert werden, neigt die Verwendung von Treibern dazu, die Netzwerkelementkonfiguration und -steuerung zu behindern, da auch die Treiber aktualisiert, neu kompiliert und neu aufgespielt werden müssen, um Änderungen in CLI-Vokabular und/oder -Grammatik wiederzuspiegeln. Auch kleine Änderungen an CLI-Befehlsattributen machen die Aktualisierung solcher Gerätetreiber erforderlich.
Diese Bemühungen sind löblich, allerdings leidet die Produktivität der Entwicklung und Wartung solcher komplexen Netzwerkverwaltungs- und Dienstbereitstellungslösungen. Insbesondere erfordert die Unterstützung für neue Datennetzwerkeinheiten, aktualisierte CLI-Vokabulare und/oder CLI-Grammatik die Neukompilierung und Neuaufspielung solcher Lösungen. Es besteht immer eine Gefahr, dass weitere Fehler in existierenden Codes eingebaut werden, wenn mit solchen Lösungen umgegangen wird, so dass ausführliches Regressionstesten erforderlich ist, um die Integrität des bestehenden Codes zu überprüfen. Auch kleine Änderungen an CLI-Befehlsattributen machen die Aktualisierung solcher Lösungen erforderlich.
Technische Entwicklungen umfassen auch die mit anhängige, gemeinsam übertragene US-Patentanmeldung 10/115,900, eingereicht am 05. April 2002, mit dem Titel Command Line Interface Processor" und die entsprechende kanadische Patentanmeldung 2 365 436, eingereicht am 19. Dezember 2001, die ein CLI-System (220) beschreiben, das eingerichtet ist, CLI-Befehlsfolgen für ein bestimmtes Anbietergerät gemäß der anbieterspezifischen CLI-Befehlssyntax zu erzeugen; diese sind hier durch Verweis einbezogen.
Wie in 2 dargestellt, liefert ein Analyst Input über eine Netzwerkverwaltungs- und Dienstbereitstellungssoftwareanwendung 210, die auf dem NMS 140 läuft. Die Softwareanwendungen 210 sind gegen Komplikationen von grundlegenden Technologien durch eine Schnittstelle 218 zu einer verwalteten Objektschicht (Managed Object Layer MOL) 208 abgeschirmt, um die Implementierung von gewünschten generischen Aktionen 262 anzufordern. Die Anforderungen werden dem CLI-System 220 als Ereignisse übermittelt, welches anbieterspezifische CLI-Befehle zum Senden an geeignete Fernmeldenetzwerkelemente (Knoten) erzeugt. Eine Abbildungsfunktion 270 wird beim Abschirmen der Softwareanwendungen 210 von den Komplikationen der dem CLI zugrundeliegenden Technologie verwendet.
Obwohl Netzwerkverwaltungs- und Dienstbereitstellungskonzepte über die Anbietergeräte hinausgehen, ist Wissen über anbieterspezifische CLI-Befehlsattributabhängigkeiten in der MOL 208 für jede unterstützte verwaltete Fernmeldenetzwerkeinheit gespeichert, um die Abbildungsfunktion 270 zu ermöglichen. Betrachten wir das Bereitstellungskonzeptbeispiel der Verwendung von CLI-Befehlen zum Konfigurieren eines Anschlusses. Für den Knoten eines bestimmten Anbieters kann die Erzeugung des erforderlichen CLI-Befehles die Festlegung von zwei Attributen erfordern: Schnittstellenidentität und Netzwerkadresse, während für den Knoten eines anderen Anbieters die Erzeugung des benötigten CLI-Befehles die Festlegung zusätzlicher Parameter wie etwa Schnittstellenkarte und/oder Gerätefachspezifikation erfordern kann. Gemäß dieser Lösung muss bei der Erzeugung von für die CLI-Syntax eines bestimmten Anbieters spezifischen CLI-Befehlen die Abbildungsfunktion 270 Wissen darüber haben, welche Attribute bei der Erzeugung von CLI-Befehlen verwendet werden sollen, um sie dem CLI-System 220 zu liefern. Dieses Wissen ist in der MOL 208 fest codiert. Da die CLI-Attributabhängigkeiten Änderungen unterliegen, muss auch die MOL 208 aktualisiert, neu kompiliert und neu aufgespielt werden.
Ein Ziel der vorliegenden Erfindung ist daher, ein Kommandozeilenschnittstellen-(CLI)-System zur Netzwerkverwaltung und Dienstbereitstellung zu schaffen, das die manuelle CLI-Kommandoeingabe überflüssig macht, Unterstützung für unabhängig entwickelte Geräte unterschiedlicher Anbieter bietet, Kosten der Verwaltung von Kommunikationsnetzwerkeinheiten, Ausfallzeiten und Trainingszeiten für Analysten reduziert und die Notwendigkeit für Softwareanwendungen und die ableitungshierarchieverwaltbare Objekttypen beseitigt, in Kenntnis von Attributabhängigkeiten von CLI-Kommandos für jedes unterstützte Anbietergerät bzw. jeden Gerätetyp fest codiert zu sein.
Genauer gesagt schafft die vorliegende Erfindung ein Kommandozeilenschnittstellensystem CLI nach Anspruch 1.
Die erfindungsgemäße Lösung schafft somit eine automatisierte Konfigurationsverwaltung von verwalteten Fernmeldenetzwerkeinheiten, wenn SNMP keine gangbare Option ist. Die Automatisierung beseitigt die manuelle Eingabe von CLI-Kommandos und bietet Unterstützung für unabhängig entwickelte Geräte unterschiedlicher Anbieter durch Verwendung mehrerer CLI-Kommandovokabulare und von diesen zugeordneten CLI-Kommandolexika. Die Lösung verringert die Datennetzeinheits-Verwaltungskosten, Ausfallzeiten und Trainingszeiten für Analysten. Die Vorteile werden abgeleitet von einer generischen Konstruktion von Softwareanwendungen 210 und verwaltbarem Objekttyp MOL 208, und verringert Betriebsaufwand, indem diese von Aktualisierungen der CLI-Kommandogrammatik und/oder des -Vokabulars abgeschirmt werden. Das hier dargestellte Verfahren beseitigt die Notwendigkeit für Softwareanwendungen 210 und MOL 208, in Kenntnis von Attributabhängigkeiten von CLI-Kommandos für Geräte unterschiedlicher Anbieter fest codiert zu sein. Das Aufspielen von generisch codierten MOL 208 und Softwareanwendungen 210 ist leichter zu entwickeln und zu warten und würde daher von einer weniger kostspieligen Aufspielen profitieren.
Gemäß einem anderen Aspekt der Erfindung wird eine an einer Netzwerkverwaltungs- und Dienstbereitstellungslösung teilnehmende CLI-Client-Einheit nach Anspruch 5 geschaffen.
Die Erfindung schafft eine Netzwerkverwaltungs- und Dienstbereitstellungslösung, bei der eine CLI-Client-Einheit betreibbar ist, um wenigstens eine gemäß De-facto-Benachrichtigungserzeugungsspezifikationen erzeugte Benachrichtigung auszugeben. Ein CLI-System ist betreibbar, um die wenigstens eine Benachrichtigung zu empfangen und basierend auf der wenigstens einen verwalteten Datennetzwerkeinheit zugeordneten CLI-Vokabular- und -Grammatikspezifikationen eine CLI-Kommandofolge zu erzeugen. Ein Validierungsmodul beurteilt die Richtigkeit jeder empfangenen Benachrichtigung und liefert für jede empfangene unrichtig formatierte Benachrichtigung eine Korrekturrückkopplungsausgabe. Ein Lernmodul berichtigt die De-facto-Benachrichtigungserzeugungsspezifikationen basierend auf der Korrekturrückkopplung. Und ein Kommunikationsmodul sendet die CLI-Kommandofolge an die wenigstens eine mit ihr wechselwirkende verwaltete Datennetzwerkeinheit. Das Validierungsmodul und das Lernmodul ermöglichen eine generische Codierung der CLI-Client-Einheit zur Unterstützung einer generischen Netzwerkverwaltungs- und Dienstbereitstellungslösung, die anpassbar ist an Änderungen von CLI-Vokabular- und -Grammatikspezifikationen.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Wechselwirken mit wenigstens einer verwalteten Datennetzwerkeinheit geschaffen. Die Richtigkeit jeder empfangenen Benachrichtigung wird beurteilt. Korrekturrückkopplung wird selektiv für jede unkorrekt formatiert empfangene Benachrichtigung erzeugt. Für jede empfangene Benachrichtigung wird eine Auswahl von CLI- Kommandos aus einer Mehrzahl von CLI-Kommandos festgelegt, um eine CLI-Kommandofolge zum Wechselwirken mit der wenigstens einen verwalteten Datennetzwerkeinheit zu erzeugen, wie in einer entsprechenden Mehrzahl von CLI-Vokabular- und -Grammatikspezifikationen spezifiziert. Ferner wird die CLI-Kommandofolge zur Ausführung an die wenigstens eine verwaltete Datennetzwerkeinheit gesandt. Das selektive Liefern von Korrekturrückkopplung ermöglicht Unterstützung für eine generische Netzwerkverwaltungs- und Dienstbereitstellungslösung, die an Änderungen im CLI-Vokabular und -Grammatik anpassbar ist.
Gemäß der Erfindung ist es möglich, mit der wenigstens einen verwalteten Datennetzwerkeinheit zu wechselwirken. De-facto-Benachrichtigungsspezifikationen werden abgefragt. Wenigstens eine gemäß den De-facto-Benachrichtigungserzeugungsspezifikationen erzeugte Benachrichtigung wird ausgegeben. Die De-facto-Benachrichtigungserzeugungsspezifikationen werden selektiv basierend auf empfangener Korrekturrückkopplung geändert, wenn die De-facto-Benachrichtungsspezifikationen zu wenigstens einer unrichtig formatiert ausgegebenen Benachrichtigung geführt haben. Die selektive Änderung von Benachrichtigungserzeugungsspezifikationen schafft Unterstützung für eine generische Netzwerkverwaltungs- und Dienstbereitstellungslösung, die an Änderungen in CLI-Vokabular und -Grammatik entsprechend der wenigstens einen verwalteten Datennetzwerkeinheit wie durch die Korrekturrückkopplung spezifiziert anpassbar ist.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Konfigurieren einer Netzwerkeinheit nach Anspruch 7 geschaffen.
Merkmale und Vorteile der Erfindung werden deutlicher aus der nachfolgenden detaillierten Beschreibung von bevorzugten Ausgestaltungen unter Bezugnahme auf die beigefügten Diagramme. Es zeigen:
1 ein schematisches Diagramm, das Datennetzwerkelemente zeigt, die verbundene Fernmeldenetze implementieren;
2 zeigt ein schematisches Diagramm, das Elemente zeigt, die eine Netzwerkverwaltungs- und Dienstbereitstellungslösung implementieren;
3 zeigt ein schematisches Diagramm, das miteinander verbundene Komponenten und von den Komponenten durchgeführte Prozessschritte beim Betrieb einer exemplarischen Ausgestaltung der Erfindung zeigt;
4 zeigt ein schematisches Diagramm, das eine Objekthierarchie von verwalteten Einheiten zeigt, die bei der Schaffung der Netzwerkverwaltungs- und Dienstbereitstellungslösung verwendet wird; und
5 zeigt ein schematisches Diagramm, das eine Enthaltenheitshierarchie von verwalteten Einheiten zeigt, die bei der Schaffung der Netzwerkverwaltungs- und Dienstbereitstellungslösung verwendet wird.
Zu beachten ist, dass in den beigefügten Diagrammen gleiche Merkmale entsprechende Zeichen tragen.
1 ist ein schematisches Diagramm, das Datennetzwerkelemente zeigt, die verbundene Datentransportnetzwerke implementieren.
Datennetzwerkknoten 102, 110, 120 sind in dem Datentransportnetz 100 über physikalische Verbindungen 108 physikalisch miteinander verbunden. Datentransportnetzwerke 100 können durch Brücken-Datennetzwerkknoten verknüpft sein, um Datenaustausch zwischen ihnen zu ermöglichen. Verbundene Datentransportnetze 100 können gruppiert werden, wodurch für die Zwecke der Netzwerkverwaltung und Dienstbereitstellung ein Einflussbereich definiert wird.
Physikalische Verbindungen 108 schaffen eine open-Systems-Interconnection-(OSI)-Schicht-1-Konnektivität zwischen den Datennetzwerkknoten 102/104/110/120, die Daten für OSI-Schicht-2-Datenverbindungen zwischen den Knoten 102/110/120 von einem Ende zum anderen befördert. Eine Schicht-2-Datenverbindung kann über wenigstens eine physikalische Datenverbindung 108 bereitgestellt werden, wobei die Folge von verwendeten Datenverbindungen 108 einen OSI-Schicht-3-Pfad 128 darstellt.
Netzwerkverwaltung und Dienstbereitstellung wird typischerweise durchgeführt mit Hilfe von wenigstens einem Netzwerkverwaltungssystem (Network Management System NMS) 140, das an wenigstens einen einem Datentransportnetz 100 zugeordneten Knoten 102 angeschlossen ist.
3 ist ein schematisches Diagramm, das wechselwirkende Elemente und Prozessschritte zeigt, die eine Netzwerkverwaltungs- und Dienstbereitstellungslösung gemäß einer exemplarischen Ausgestaltung der Erfindung zeigen.
Ein Verwaltete-Objekte-Server (Managed Object Server MOS) erleichtert die Implementierung einer Softwareentwicklungsmethodik zum Codieren von komplexen Softwareanwendungen 210 betreffend Netzwerkverwaltung und Dienstbereitstellung.
Der MOS 200 implementiert eine neue Architektur zum Bereitstellen von Netzwerkverwaltungs- und Dienstbereitstellungslösungen. Die neue Architektur kategorisiert die oben dargestellten Elemente in:

– verwaltbare Datennetzwerkeinheiten, die repräsentativ sind für im Feld installierte, bei der Bereitstellung von Netzwerkverwaltungs- und Dienstbereitstellungslösungen zu konfigurierende und zu steuernde Datennetzwerkeinheiten. Die im Feld installierten Datennetzwerkeinheiten umfassen:
i. im Feld installierte physikalische Datennetzwerkgeräte wie etwa Knoten 102/104, Router, Switches, Hubs, OC-3-Verbindungen 108 etc., und
ii. logische Datennetzwerkeinheiten, die im Feld installierten Datennetzwerkgeräten zugeordnet sind, wie etwa Pfade 128, virtuelle Schaltungen, virtuelle Router etc.;
– Netzwerkverwaltungs- und Dienstbereitstellungssoftwareanwendungen 210, die verwendet werden, um die verwaltbaren Datennetzwerkeinheiten zu konfigurieren und zu steuern. Die Softwareanwendungen 210 umfassen wie oben erwähnt: Inventurberichterstattung 214, Konfigurationsverwaltung 212, Statistikerfassung, Leistungsberichterstattung, Fehlerverwaltung, Netzwerküberwachung, Dienstbereitstellung 216, Abrechnung und Buchführung, Sicherung etc. Mensch-Maschine-Wechselwirkung mit den Softwareanwendungen 210 wird einem Analysten über den wenigstens einen NMS 140 ermöglicht;
– Netzwerkverwaltung ermöglichende Technologien, die Wechselwirkung zwischen verwaltbaren Einheiten und im Feld installierten physikalischen Datennetzwerkeinheiten schaffen. Die ermöglichenden Technologien umfassen:
i. Datennetzwerkverwaltungs- und Dienstbereitstellungsprotokolle: SNMP, CMIP, CLI, DNS etc., und
ii. Datennetzwerkverwaltungs- und Dienstbereitstellungsvorrichtungen: Datenbanken, DNS-Server etc.

Die Netzwerkverwaltungs- und Dienstbereitstellungslösung kann sowohl kommandogesteuert sein, wie durch die Softwareanwendung 210 spezifiziert, als auch ereignisgesteuert, wenn sich ein gegenwärtiger Zustand des verwalteten Datentransportnetzwerks (oder der Netzwerke) im Einflussbereich der Verwaltungs- und Dienstbereitstellungslösung ändert.
Der MOS 200 schirmt die Softwareanwendungen 210 ab vor Komplikationen der ermöglichenden Technologien.
Die ermöglichenden Technologien umfassen Unterstützung für ein als "Persistenz" bezeichnetes Konzept. Wie oben erwähnt, ist jeder Datenerzeugungseinheit, die ein Datennetzwerkgerät enthält, eine Gruppe von Parametern zugeordnet. Diese Parameter haben entweder eine Wirkung auf den Betrieb der Datennetzwerkeinheit, oder sie etikettieren die Datennetzwerkeinheit. Das Persistenzkonzept umfasst die Speicherung von, Zugriff auf, Lesen, Schreiben, Verändern, Synchronisieren/Vereinbaren etc. von Persistenzparametern, um den Betrieb der Datennetzwerkeinheiten zu steuern.
Die Persistenzparameter können in einer Netzwerkverwaltungs- und Dienstbereitstellungsdatenbank sowie in Registern, die den im Feld installierten verwalteten physikalischen Datennetzwerkgeräten zugeordnet sind, gespeichert sein. Der Persistenzzugriff auf, Lesen von, Schreiben von, Ändern von diesen Parametern wird bereitgestellt über die ermöglichenden Technologien, unter denen sich ohne Einschränkung darauf die oben erwähnten Datennetzwerkverwaltungs- und Dienstbereitstellungsprotokolle befinden. Persistenz-Abstimmung und Synchronisierung werden zum Beispiel zwischen einer Persistenzdatenbank und einem Persistenzwert in einem flüchtigen Register durchgeführt, was eine korrekte Aufzeichnungsführung desselben, schnellen Zugriff auf die persistierende Information und deren Sicherungsspeicherung gewährleistet. Die Speicherung von Persistenzinformation wird auch beim Rekonfigurieren von Datennetzwerkgeräten nach Netzwerkstörungen verwendet. Persistenzabstimmung und Synchronisierung sind denkbar zwischen End-Kommunikationsnetzwerkgeräten, die zum Beispiel einer physikalischen Verbindung, einer Datenverbindung, einem Pfad, einem Dienst etc. zugeordnet sind.
Das Persistenzkonzept umfasst auch spezielle Persistenztypen wie etwa konstante Persistenz, die nur initialisiert aber anschließend nicht geändert oder überschrieben werden kann, sowie abgeleitete Persistenz, die nicht gespeichert wird, sondern bei Bedarf aus anderen Persistenzwerten berechnet wird.
Gemäß der bevorzugten Ausgestaltung der vorliegenden Erfindung ermöglichen zur Unterstützung der bevorzugten Softwareentwicklungsmethodik verwendete Codiertechniken das Laden von ermöglichender Technologieunterstützung bei Bedarf. Diese Codiertechniken implementieren, was auf dem Gebiet als Softwareanwendungs-Persistenzeinheiten-Plug-Ins bekannt ist, wie etwa, ohne Einschränkung darauf: SNMP-ermöglichende Technologie-Plug-Ins, CMIP-ermöglichende Technologie-Plug-Ins, CLI-ermöglichende Technologie-Plug-Ins, Datenbank-Plug-Ins etc. Diese Plug-Ins ermöglichen Persistenz. Die Persistens-Plug-Ins erfassen Daten und Verfahren, die notwendig sind, um mit tatsächlichen Persistenzeinheiten (Datenbanken, Register etc.) zu wechselwirken. Jedes Persistenz-Plug-In umfasst eine gemeinsam genutzte Bibliotheksdatei (.so), die eine codierte Beschreibung der Funktionalität enthält, die es liefern kann.
Gemäß der bevorzugten Softwareentwicklungsmethodik sind die Persistenz-Plug-Ins allgemein codiert, ohne speziell auf die verwaltbaren Datennetzwerkeinheiten oder die Softwareanwendungen 210 zu verweisen. Die Persistenz-Plug-Ins sollen nicht in den Objektcode der Softwareanwendungen 210 eingelinkt werden. Vorzugsweise werden Persistenz-Plug-Ins als gemeinsam genutzte Objektcodebibliotheksdateien (.so) bereitgestellt, die beim MOS 200 zum Laden nach Bedarf registriert werden.
Gemäß der bevorzugten Softwareentwicklungsmethodik sind auch die Softwareanwendungen 210 auf eine allgemeine Weise codiert, die die bereitgestellte Funktionalität implementiert und dabei nur auf verwaltbare Datennetzwerkeinheiten (über Richtlinien) in einer abstrakten Implementierung auf hoher Ebene der bereitgestellten Funktionalität verweist. Weitere Details der Softwareentwicklungsmethodik betreffend den Zugriff der Softwareanwendung 210 auf Instanzen von verwaltbaren Datennetzwerkeinheiten sind zu finden in: der mitanhängigen gemeinsam übertragenen Patentanmeldung, eingereicht am 19. Dezember 2001 beim US-Patent und Markenamt durch den Anmelder mit dem Titel "Network Management System Architecture" mit der laufenden Nummer 10/021,080, die hier durch Verweis einbezogen ist, und die mitanhängige gemeinsam übertragene Patentanmeldung, eingereicht am 19. Dezember 2001 beim US-Patent und Markenamt durch den Anmelder mit dem Titel "Method of Invoking Polymorphic Operations in a Statically Typed Language" mit der laufenden Nummer 10/021,629, die hier durch Verweis einbezogen ist.
Spezielle Information betreffend verwaltbare Datennetzwerkeinheiten ist über den MOS 200 verfügbar, der zur Laufzeit Instanzen von verwalteten Objekteinheiten instanziiert und Wechselwirkung 204 mit diesen bereitstellt. Insbesondere registrieren 218 sich die Softwareanwendungen 210 beim MOS 200, der deren Funktionalität vermehrt durch Makeln des Zugriffs 204 auf Instanzen von spezifischen verwaltbaren Einheiten und diesen zugeordnete Methoden.
Die verwalteten Objekteinheiten-Instanzen existieren in einer verwalteten Objektschicht (Managed Object Layer, MOL) 208, die dem MOS 200 zugeordnet ist.
Die Gesamtwechselwirkung 218/204 zwischen den Softwareanwendungen 210 und den verwalteten Objekttyp-Instanzen ändert den Datennetzwerkzustand und/oder liefert eine Aktualisierung des Datennetzwerkzustandes durch Verwendung von ermöglichenden Technologien.
Die Instanziierung der verwalteten Objekttypen (300) wird nach der Entdeckung der verwalteten Datennetzwerkeinheiten im Einflussbereich der Netzwerkverwaltungs- und Dienstbereitstellungslösung durchgeführt. Die Entdeckung der physikalischen verwalteten Einheiten wird bereitgestellt über Softwareanwendungen 210 wie etwa die Inventarberichterstattungs-Softwareanwendung 214. Die Instanziierung von verwalteten Einheitsobjekten kann auch das Ergebnis der Wechselwirkung eines Analysten mit der MNS 140 über die Softwareanwendungen 210 sein.
Die MOL 208 verwendet eine verwaltete Einheitsobjekt-Ableitungshierarchie 300, die in 4 gezeigt ist, beim Instanziieren von verwalteten Einheitsobjekten. Die verwaltbaren Einheitsobjektinstanzen definieren eine in 5 dargestellte Enthaltenheitshierarchie 400 von verwalteten Objekteinheiten. Die Enthaltenheitshierarchie 400 mag nur als eine Kombination von Zuordnungen zwischen Instanzen von verwalteten Objekteinheiten existieren (ist aber nicht hierauf beschränkt).
Wie oben erwähnt, kann eine spezifische ermöglichende Technologie verwendet werden, um Persistenzunterstützung zu schaffen, wenn die im Feld installierte physikalische Datennetzwerkeinheit diese spezielle ermöglichende Technologie implementiert und sie aktiviert hat. CLI-ermöglichende Technologieunterstützung ist der Schwerpunkt der vorliegenden Beschreibung. Wie oben erwähnt, sind Befehlzeilenschnittstellen zwar nicht zwischen Geräten unterschiedlicher Anbieter standardisiert, nicht einmal für von einem bestimmten Anbieter hergestellte Geräte, sind aber verbreiteter als standardisierte SNMP-Unterstützung, standardisierte CMIP-Unterstützung etc.
Ein CLI-System 220 wird bereitgestellt. Das CLI-System 220 bietet Befehlzeilenschnittstellenkonfigurations-(das heißt Persistenz-)Unterstützung für verwaltete Einheitsobjektinstanzen und durch Erweiterung auch für Softwareanwendungen 210.
Auch bei den einfachsten verwalteten Datentransportnetzwerken neigt die Menge an Konfiguration und/oder Überwachung von persistenter Information dazu, sehr groß zu sein. Gemäß einer bevorzugten Ausgestaltung der Erfindung konsolidiert das CLI-System 220 die Persistenzunterstützung für verwaltete Datennetzwerkeinheiten sowohl für Geräte mehrerer Anbieter als auch für mehrere anbieterspezifische Gerätetypen. Das CLI-System 220 kann eine Kombination von Hardware und Softwareanwendungscode umfassen, ist aber nicht hierauf beschränkt.
Bei der Wechselwirkung 218/204 fordert eine Softwareanwendung 210 wenigstens eine Aktion 262 an, die an einer verwalteten Einheitsobjektinstanz aufgerufen werden soll, um Betriebsparameter zu ändern sowie um Betriebsparameter der entsprechenden im Feld installierten verwalteten Kommunikationsnetzwerkeinheit zu ändern. Diverse derartige Aktionen 262 können verwendet werden, von denen jede jeweils eine "Grundaktion" darstellen oder in eine Gruppe von Grundaktionen zerlegt werden kann. Eine nicht erschöpfende Liste von Grundaktionen 262 umfasst: Erzeugungs-, Aktualisierungs-, Lese-, Löschaktionen etc. Gemäß der bevorzugten Softwareentwicklungsmethodik transzendieren die Implementierungen der Grundaktionen 262 eine jede der beim MOS 200 registrierten Softwareanwendungen 210, was zu einer generischen Lösungsimplementierung führt.
Gemäß der Erfindung wird die Bereitstellung der CLI-Konfiguration von verwalteten Datennetzwerkeinheiten ermöglicht durch spezielle CLI-Attribute 264 und Verfahren, die durch die verwaltbaren Einheitsobjekte implementiert sind (300). Die speziellen Verfahren umfassen CLI-spezifische Nebenwirkungsaktionen 266 wie etwa, ohne Einschränkung darauf, CLI-Erzeugungs-, CLI-Lösch-, CLI-Lese-, CLI-Aktualisierungsaktionen etc.
Eine Abbildungsfunktion 270 wird zwischen Grundaktionen 262 und CLI-Aktionen 266 durchgeführt, um die Softwareanwendungen 210 vor den Komplikationen der ermöglichenden Technologien, in diesem Fall der CLI-ermöglichenden Technologie, abzuschirmen. CLI-Abbildungsspezifikationen werden von der Abbildungsfunktion 270 abgefragt, wenn die Implementierung von Grundaktionen 262 CLI-Persistenzunterstützung erfordert. Manche Grundaktionen 262 können lediglich CLI-Attribute 264 ändern. Die Änderung von CLI-Attributen 264 kann wiederum CLI-Aktionen 266 auslösen. Die Implementierung der Lösung nutzt spezielle CLI-Abbildungsattribute 265, die Abbildungsspezifikationen enthalten.
Die Abbildungsfunktion 270 ist auch erforderlich, da die Grundaktionen 262 für die Softwareanwendungen 210 atomar sein können und gleichzeitig die Grundaktionen 262 Aktionen einer hohen Ebene darstellen, die über atomare CLI-Aktionen 266 zu implementieren sind.
Die Entsprechung zwischen einer bestimmten verwalteten Einheitsobjektinstanz und der entsprechenden verwalteten Datennetzwerkeinheit wird geschaffen über ein eindeutiges CLI-Identifizierungsattribut (CLIid). Verwaltete Einheitsobjektinstanzen wie etwa physikalische Verbindungen 108, Pfade 128 etc. haben jeweils zwei zugeordnete Enden. Die Konfiguration von physikalischen Verbindungen 108, Pfaden 128 etc. wird ausschließlich durch Konfigurieren von deren Enden durchgeführt. Weitere Information betreffend CLIid-Spezifikation ist in der oben erwähnten anhängigen gemeinsam übertragenen US-Patentanmeldung 10/115,900 zu finden.
Andere CLI-Attribute 264 können umfassen: CLIreadUserID, CLIReadPassword, CLIwriteUserID, CLIwritePassword, internetAdress etc., wobei relevante CLI-Aktionen 266 die CLI-Attribute 264 als Parameter wie über CLI-Abbildungsattribute 265 spezifiziert verwenden können.
Zur Schaffung von Persistenzunterstützung kann die Wechselwirkung zwischen dem MOS 200 und dem CLI-System 220 implementiert werden über ausgetauschte Nachrichten, die CLI-Aktionen 266 anfordern, die bei der Durchführung von Änderungen an den Betriebsparametern von verwalteten Datennetzwerkeinheiten auszuführen sind. Zu diesem Zweck registriert sich das CLI-System 220 beim MOS 200, um die Persistenzunterstützung zu schaffen. Änderungen an verwalteten Einheitsobjektinstanzen werden dem CLI-System 220 als Ereignis mitgeteilt.
Das CLI-System 200 umfasst: einen CLI-Prozessor 520 (CLIP), ein CLI-Wörterbuch 530 und ein CLI-Kommunikationsmodul 540 (CLICOM).
Gemäß der Codierungsmethodik der bevorzugten Lösung wird das CLI-System generisch codiert und ist eingerichtet, um in Laufzeit .grammar-Dateien 226 zu laden. Jede .grammar-Datei 226 enthält Spezifikationen eines CLI-Vokabulars und einer zugeordneten Grammatik, die zum Konfigurieren und Steuern wenigstens einer bestimmten verwalteten Datennetzwerkeinheit (zum Schaffen von Persistenzunterstützung) zu verwenden ist. Grammatik und Vokabular spezifizieren u.a. ohne Einschränkung darauf: CLI-Kommandonamen, zugeordnete Parameter, gültige Parameterbereiche, Parametertyepenfestlegungsregeln, Parameterumwandlungen, Parametereinheitenspezifikationen, Parametereinheitenumwandlungen sowie Kontexte, in denen die CLI-Kommandos erteilt werden können.
Gemäß der bevorzugten Softwareentwicklungsmethodik ermöglicht die Verwendung von .grammar-Dateien 226 eine generische Codierung des CLI-Systems 220 – das Laden 228 von aktualisierten .grammar-Dateien 226 ermöglicht die Änderung der Wechselwirkung mit Datennetzwerkeinheiten mit vorzugsweise wenig und letztenendes keinen Änderungen am Code des CLI-Systems 220.
Das CLI-Vokabular und die Grammatik, die in den .grammar-Dateien 226 beschrieben sind, werden in das CLI-Wörterbuch 530 kompiliert. Das CLI-Wörterbuch 530 codifiziert ferner die CLI-Kommandos, die Beziehungen zwischen CLI-Kommandos und wie sich die CLI-Kommandos auf verwaltete Datennetzwerkeinheiten beziehen. Einrichtungen wie etwa ein persistenter Speicher können zum Speichern und Laden des CLI-Wörterbuches 530 zwischen Neustarts des CLI-Systems 220 vorgesehen werden.
Der CLI-Prozessor 520 empfängt Benachrichtigungen 500 vom MOS 200, die durchzuführende angeforderte CLI-Aktionen 266 umfassen. Wenn er eine Benachrichtigung 500 empfangen hat, verwendet der CLI-Prozessor 520 CLI-Abbildungsattribute 265, um in dem CLI-Wörterbuch 530 gespeicherte CLI-Wörterbucheinträge abzufragen 504.
Das CLI-System 220 wechselwirkt 542 mit der (den) im Feld installierten verwalteten Datennetzwerkeinheit(en) über das CLICOM-Modul 540 für jede CLI-Aktion 266 sowie wenn eine bestimmte Änderung eines CLI-Attributs 264 Persistenzunterstützung erfordert.
Eine CLI-Kommandofolge wird erzeugt, um die spezifische CLI-Aktion 266 (CLIcreate, CLIupdate, CLIread, CLIdelete etc.) basierend auf der in entsprechenden CLI-Wörterbucheinträgen spezifizierten Grammatik zu implementieren, um auf die verwaltete Datennetzwerkeinheit einzuwirken.
Das CLICOM-Modul 540 sendet 542 jede CLI-Kommandofolge an die entsprechende verwaltete Datennetzwerkeinheit zur Ausführung. Weitere Details über das CLICOM-Modul 540 sind dargestellt in der oben erwähnten anhängigen gemeinsam übertragenen Patentanmeldung 10/115,900.
Die verwaltete Datennetzwerkeinheit 510 führt jedes CLI-Kommando in einer empfangenen CLI-Kommandofolge aus.
Eine Verringerung des Betriebsaufwandes wird angestrebt unter Beibehaltung von Investitionsrisiko-Vorteilen, die erreicht werden durch Verwendung von Geräten mehrerer Anbieter. Die Automatisierung der Befehlzeilenschnittstellen-(CLI)-kommandobasierten Konfiguration und Steueraufgaben stellt einen der Wege dar, auf denen eine solche Verringerung des Betriebsaufwandes erreichbar ist.
Obwohl die oben erwähnte mit anhängige gemeinsam übertragene Patentanmeldung 10/115,900 große Fortschritte bei der Automatisierung von CLI-basierter Netzwerkverwaltung und Dienstbereitstellung durch Erzeugen von CLI-Kommandofolgen gemäß CLI-Grammatik- und -Vokabularspezifikationen unterschiedlicher Geräteanbieter macht, schirmt die Lösung nur die Softwareanwendungen 210 von der Komplexität und Diversität der CLI-ermöglichenden Technologie ab. Die Lösung erreicht noch keine Abschirmung der MOL 208 von den Komplikationen der CLI-ermöglichenden Technologie wie etwa Attributabhängigkeiten, die der MOL 208 bei der Implementierung solcher Lösungen bekannt sein müssen. In der vorherigen Lösung muss die Abbildungsfunktion 270 über Wissen über anbieterspezifische CLI-Kommandoattribute verfügen, da Werte von diesen an das CLI-System 220 geliefert werden müssen, um CLI-Kommandos zu erzeugen und an verwaltete Datennetzwerkeinheiten auszugeben. Insbesondere werden Attributabhängigkeiten über die CLI-Abbildungsattribute 265 für jeden anbieterspezifischen Gerätetyp spezifiziert. Dies stellt ein Problem dar, da die verwaltbare Objektableitungshierarchie 300, da sie mit anbieterspezifischen Attributen codiert ist, bei jeder anbieterspezifischen Änderung von CLI-Vokabular und/oder Grammatik aktualisiert, neu kompiliert und neu aufgespielt werden muss. Es ist wünschenswert, diesen Betriebsaufwand, der durch Aktualisierungen von Attributabhängigkeiten verursacht ist, zu verringern.
Deshalb ist es wünschenswert, die MOL 208 auch von Änderungen an der anbieterspezifischen CLI-Kommandosyntax abzuschirmen, um deren Aktualisierung zu minimieren.
Gemäß einer exemplarischen Ausgestaltung der Erfindung ist anbieterspezifische Information in dem CLI-System, insbesondere in dem CLI-Wörterbuch 530, gespeichert, der CLI-Prozessor 520 ist mit einer neuen Funktionalität, Attributüberprüfung 810, versehen, um benötigte Attribute zu überprüfen und die MOL 208 über in der Benachrichtigung (den Benachrichtigungen) 500 fehlende Attribute zu informieren 820.
Wenn der CLI-Prozessor 520 ein CLI-Kommando erzeugt, prüft 504 er die Kommandosyntax (Vokabular und Grammatik) für das bestimmte Kommando und den Anbieter, die im CLI-Wörterbuch 530 gespeichert ist, um zu bestimmen, ob alle benötigten Attribute geliefert worden sind. Wenn Attribute fehlen, informiert 820 der CLI-Prozessor 520 die MOL 208 über deren Fehlen in Verbindung mit der bestimmten angeforderten CLI-Aktion 266 und durch Erweiterung in Verbindung mit der empfangenen Ereignisbenachrichtigung 500.
Ein Beispiel ist die Konfiguration eines Anschlusses 112. In Abhängigkeit von der Zuordnung des Anschlusses 112 zu einem Knoten 110 (Anbieter 1) oder einem Knoten 120 (Anbieter 2), Fach 122 und Schnittstellenkarte 124 können Spezifikationen erforderlich sein. Es kann nötig sein, Attribute bereitzustellen, die Informationen über Fach 122 und Schnittstellenkarte 124 spezifizieren.
Gemäß der exemplarischen Ausgestaltung der Erfindung ist die MOL 208 ausgestattet mit einer neuen Attributlernfunktionalität 830, um vom CLI-Prozessor 520 bereitgestellte Attributanforderungen zu lernen und zu verfolgen. Wenn der CLI-Prozessor 520 die MOL 208 über fehlende Attribute für eine bestimmte CLI-Aktion 266 für einen Knoten eines bestimmten Anbieters informiert, zeichnet die MOL 208 zur zukünftigen Verwendung auf, welche Attribute benötigt werden. Diese Funktion fügt zwar etwas Komplexität zur MOL 208 hinzu, beseitigt aber die Notwendigkeit, CLI-Attributabhängigkeiten in der verwaltbaren Objektableitungshierarchie 300 fest zu codieren, und verringert so Betriebsaufwand, der mit der Aktualisierung der zugeordneten CLI-Kommandosyntax zusammenhängt. Wenn die CLI-Attributabhängigkeiten sich ändern, passt sich die MOL 208 einfach den Änderungen basierend auf der vom CLI-Prozessor 520 gelieferten 820 Information an und schafft so eine dynamische Bestimmung von CLI-Attributabhängigkeitsaktualisierungen.
Gemäß einer exemplarischen Ausgestaltung der Erfindung sind die verwaltbaren Objekttypen der verwaltbaren Objektableitungshierarchie 300 generisch codiert. Die generische Codierung ist ferner ermöglicht durch eine Etikettierung CLIattribute 263, die jeder instanziierten verwalteten Objekteinheit zugeordnet ist, den eine Anbieter-/Gerätetypspezifikation enthält, um Unterstützung für anbieter-/gerätetypspezifische Attributvalidierung zu liefern. Das Etikettierungs-CLIattribute 263 kann bevölkert werden beim Instanziieren der verwalteten Objekthierarchie. Das CLIid-Attribut kann die Anbieter-/Gerätetypspezifikation enthalten. Wenn das CLIid-Attribut verwendet wird, um die Anbieter-/Gerätetypspezifikation zu spezifizieren, kann die Anbieter-/Gerätetypspezifikation abgeleitet werden beim Ableiten des CLIid-Attributs unter Verwendung von Verfahren wie in der oben erwähnten mit anhängigen gemeinsam übertragenen Patentanmeldung 10/115,900 beschrieben. Nicht nur schirmt die vorgeschlagene Lösung die MOL 208 von Änderungen an anbieterspezifischen CLI-Syntaxänderungen ab, sondern vor Anbieterspezifika allgemein, Syntaxkomplexitäten und Abweichungen der CLI-Kommandos zwischen Geräten unterschiedlicher Anbieter.
Gemäß einer exemplarischen Wechselwirkung zwischen MOL 208 und CLI-Prozessor 520 verwendet die MOL 208 ein reaktives Verfahren des Ausgebens von Ereignisbenachrichtigungen 500. Die MOL 208 gibt eine Ereignisbenachrichtigung 500 mit Attributen basierend auf generischen, plausiblen, De-facto- etc. Benachrichtigungserzeugungsspezifikationen (CLI-Abbildungsattribute 265) aus, die zuvor von dem Abbildungsprozess 270 verwendet wurden. Die Ereignisbenachrichtigung 500 umfasst die entsprechende CLIid und Anbieter-/Gerätetypspezifikation. Die Attributüberprüfungsfunktion 810 nutzt die CLIid und Anbieter-/Gerätetypspezifikation, um die Einträge des Wörterbuches 530 abzufragen 504. Wenn Diskrepanzen erfasst werden, schlägt die Implementierung der ausgegebenen Benachrichtigung 500 fehl, und der CLI-Prozessor 520 liefert 820 an die MOL 208 eine Korrekturrückkopplung einschließlich der korrekten erforderlichen CLI-Attribute. Die Lernfunktion 830 empfängt die Korrekturrückkopplung und speichert Wissen über alle neu erforderlichen CLI-Attribute 264 in entsprechenden CLI-Abbildungsattributen 265. Die Abbildungsfunktion 270 wird so aktualisiert. Die MOL 208 sendet die Ereignisbenachrichtigung 500 mit den benötigten CLI-Attributen 264.
Bei der Implementierung einer bestimmten CLI-Aktion 266 kann es möglich sein, dass der CLI-Prozessor 520 eine lange Folge von CLI-Kommandos erzeugen muss. Jedes CLI-Kommando benötigt möglicherweise zusätzliche CLI-Attribute 264. Die Ereignisbenachrichtigung 500 kann daher so lange scheitern, bis die gesamte CLI-Kommandofolge, die die notwendige CLI- Aktion 266 implementiert, erfolgreich erzeugt ist. Dadurch kann es anfangs zu einem signifikant großen Verarbeitungsaufwand kommen. Da jedoch CLI-Syntaxänderungen selten sind, profitieren anschließende Implementierungen der gleichen CLI-Aktion 266 von dem einmaligen Lernen.
Gemäß einer anderen exemplarischen Wechselwirkung zwischen MOL 208 und CLI-Prozessor 520 verwendet die MOL 208 ein proaktives Verfahren des Ausgebens von Ereignisbenachrichtigungen 500. Die MOL 208 fragt zunächst den CLI-Prozessor 520 nach benötigten CLI-Attributen 264 bei der Implementierung einer bestimmten CLI-Aktion 266 auf einer bestimmten verwalteten Kommunikationsnetzwerkeinheit mit einer CLIid und einer Anbieter-/Gerätetypspezifikation ab (500). Der CLI-Prozessor 520 befragt 504 das CLI-Wörterbuch 530 und liefert der MOL 208 Korrekturrückkopplung, die die zum Implementieren der Ereignisbenachrichtigung/CLI-Aktion 266 erforderliche Gruppe von CLI-Attributen 264 spezifiziert. Die Lernfunktion 830 speichert Wissen über alle neu erforderlichen CLI-Attribute 264 in entsprechenden CLI-Abbildungsattributen 265. Dadurch wird der Abbildungsprozess 270 aktualisiert. Die MOL 208 sendet anschließend eine voll qualifizierte Ereignisbenachrichtigung 500 an den CLI-Prozessor 520, die Persistenzunterstützung anfordert.
Da CLI-Syntaxänderungen selten sind, kommt es zu einem ständigen Verarbeitungsaufwand, da nachfolgende gleiche CLI-Aktionen 266 nicht von nachfolgenden Anfragen 500 profitieren, in denen die Notwendigkeit erforderlicher Attribute bereits gelernt worden ist. Allerdings wird der beim Lernen 830 der korrekten Attributabhängigkeiten auftretende Verarbeitungsaufwand minimiert, da Korrekturrückkopplung nur einmal für jede Ereignisbenachrichtigung 500 geliefert wird.
Es versteht sich, dass gemäß der oben beschriebenen Implementierung die MOL 208 eine Konsolidierung von Kommunikationsnetzwerkverwaltungsinformation für Netzwerkverwaltung und Dienstbereitstellung erreicht. Gemäß einer anderen Ausgestaltung der Erfindung interagieren Netzwerkverwaltungs- und Dienstbereitstellungssoftwareanwendungen 210 direkt mit dem CLI-Prozessor 520. Bei solchen Implementierungen sind die generische verwaltbare Objektableitungshierarchie 300 und die Lernfunktion 830 jeder Softwareanwendung 210 zugeordnet. In diesem Sinn stellen die MOL 208 und Softwareanwendungen 210 die CLI-Client-Einheiten dar, die von dem CLI-System 220 mit CLI-ermöglichender Technologieunterstützung bedient werden.
Gemäß einer bevorzugten Implementierung der Erfindung werden mehrfache CLI-Aktionen 266 vorzugsweise parallel von dem CLI-System 220 verarbeitet. Bei der Codierung solcher Implementierungen muss darauf geachtet werden, dass Konfigurationskonflikte beseitigt werden. Die Beseitigung von Konfigurationskonflikten sowie die Priorisierung von Konfigurationsänderungen kann implementiert werden durch Erzeugen einer Warteschlange von durch das CLI-System 220 zu verarbeitenden CLI-Aktionen 266. Die Parallelverarbeitung erfordert die Verwendung von Multi-Threading und Multi-Tasking-Codiertechniken, die Fachleuten bekannt und anderswo beschrieben sind.
Die vorliegende Erfindung automatisiert die Aufgabe, CLI-Kommandos einzugeben, in einer Netzwerkverwaltungs- und Dienstbereitstellungsumgebung, die aus diversen Datennetzwerkeinheiten besteht, von denen jeder ein CLI-Vokabular zugeordnet ist. Ein CLI-Kommandowörterbuch 530 konsolidiert alle datennetzwerkeinheitsspezifischen CLI-Vokabulare und bedient das CLI-System 220 mit anbieter-/gerätetypspezifischen CLI-Kommandos zum Erzeugen von CLI-Kommandofolgen. Die Attributüberprüfungsfunktion 810, ausgetauschte Diskrepanzinformation 820 und die Lernfunktion 830 ermöglichen einen generischen Einsatz von Netzwerkverwaltungs- und Dienstbereitstellungslösungen.

Claims

Kommandozeilenschnittstellensystem (CLI 220) für ein Netzwerkverwaltungssystem (NMS 140), um eine verkäuferspezifische verwaltete Datennetzwerkeinheit (110, 120) in die Lage zu versetzen, eine von einem verwalteten Objektserver (MOS 200) benötigte Aktion auszuführen, mit: a) einem Validierungsmodul (810) zum Einschätzen der Korrektheit jeder durch das Kommandozeilenschnittstellensystem von dem verwalteten Objektserver empfangenen Benachrichtigung (500) und Bereitstellen (820) einer Korrektiv-Rückkopplungsausgabe für jede inkorrekte Benachrichtigung; b) einem Prozessor (520) zum Erzeugen einer Folge von CLI-Kommandos, die zum Durchführen der Aktion erforderlich sind, unter Verwendung einer Mehrzahl von CLI-Kommandos, wie durch eine entsprechende Mehrzahl von CLI-Vokabular- und Grammatikspezifikationen spezifiziert; und c) einem Kommunikationsmodul (540) zum Senden der CLI-Kommandofolge zur Ausführung an die Datennetzwerkeinheit (110, 120), wobei die Korrektiv-Rückkopplungsausgabe den verwalteten Objektserver in die Lage versetzt, einen korrekten Satz von von der Datennetzwerkeinheit zum Durchführen der Aktion verwendeten Attributen zu lernen.
Kommandozeilenschnittstellensystem nach Anspruch 1, bei dem die CLI-Vokabular- und Grammatikspezifikation in einem CLI-Lexikon (530) bereitgestellt sind, das eine Mehrzahl von Lexikoneinträgen zum Enthalten von CLI-Vokabular- und Grammatikspezifikationen entsprechend einer Mehrzahl von von der Datennetzwerkeinheit erkannten CLI-Kommandos aufweist.
Kommandozeilenschnittstellensystem nach einem der Ansprüche 1 oder 2, ferner mit einem Parser (222) zum Bevölkern der Lexikoneinträge mit den aus einer Mehrzahl von Grammatikdateien (226) für besagte Datennetzwerkeinheit und andere von dem Netzwerkverwaltungssystem verwaltete Netzwerkeinheiten extrahierten CLI- Vokabular- und Grammatikspezifikationen.
Kommandozeilenschnittstellensystem nach einem beliebigen der vorhergehenden Ansprüche, bei dem das Validierungsmodul eine Attributüberprüfung durchführt, welche alle erforderlichen Attribute für jedes CLI-Kommando aus der Folge von Kommandos prüft und den verwalteten Objektserver über jedes fehlende Attribut informiert.
CLI-Client-Einheit (200, 208, 830) zum Wechselwirken mit dem Kommandozeilenschnittstellensystem (220) nach einem der Ansprüche 1 bis 4, zum Steuern einer verwalteten Datennetzwerkeinheit, mit: a) einem Benachrichtigungsgenerator zum Bereitstellen, an das Kommandozeilenschnittstellensystem, der von der verwalteten Datennetzwerkeinheit auszuführenden Benachrichtigung; b) einem lernenden Modul (830), das betreibbar ist, um die Benachrichtigungserzeugungsspezifikationen basierend auf der Korrektiv-Rückkopplung zu korrigieren, wenn die Benachrichtigung inkorrekt ist.
Kommandozeilenschnittstellensystem nach Anspruch 2, dadurch gekennzeichnet, dass die Lexikoneinträge ferner CLI-Kommandoattribute für entsprechende CLI-Kommandos spezifizieren.
Verfahren zum Konfigurieren einer Netzwerkeinheit (110, 120) von einem Netzwerkverwaltungssystem (NMS 140) aus unter Verwendung eines Kommandozeilenschnittstellensystems (CLI 220) wobei das Netzwerkverwaltungssystem einen verwalteten Objektserver (200) und die CLI aufrecht erhält, dadurch gekennzeichnet, dass es folgende Schritte umfasst: a) Senden einer Ereignisbenachrichtigung (500), die die Ausführung einer spezifischen CLI-Aktion (266) durch die Netzwerkeinheit beantragt, von dem verwalteten Objektserver (200) an das Kommandozeilenschnittstellensystem; b) versorgen des verwalteten Objektservers mit einer Korrektiv-Rückkopplung, um den verwalteten Objektserver in die Lage zu versetzen, den Satz von Attributen zu aktualisieren; c) Bilden einer Folge von für die Netzwerkeinheit spezifischen CLI-Kommandos in dem Kommandozeilenschnittstellensystem basierend auf einer spezifischen CLI-Aktion unter Verwendung eines von dem Kommandozeilenschnittstellensystem aufrecht erhaltenen CLI-Lexikons (530); und d) Übertragen der Folge von CLI-Kommandos an die Netzwerkeinheit, um die Netzwerkeinheit in die Lage zu versetzen, die Operation wie in dem CLI-Kommando angeordnet auszuführen.
Verfahren nach Anspruch 7, bei dem Schritt c) umfasst: – Erzeugen der Folge von CLI-Kommandos durch Abbilden von CLI-Kommandos auf einen entsprechenden zum Durchführen der Aktion erforderlichen Satz von Attributen; – Zugreifen auf das CLI-Lexikon, um die Kompleanz von von jedem Kommando der Folge von CLI-Kommandos verwendetem Vokabular und Syntax mit dem Typ der Netzwerkeinheit zu überprüfen; und – Überprüfen, mit dem CLI-Lexikon, der Genauigkeit des dem Typ von Netzwerkeinheit entsprechenden Satzes von Attributen.
Verfahren nach einem der Ansprüche 7 oder 8, das ferner das Benachrichtigen (820) des verwalteten Objektservers (200) über fehlende Attribute in dem Satz von Attributen umfasst.
Verfahren nach einem beliebigen der Ansprüche 7 bis 9, bei welchem das CLI-Lexikon CLI-Vokabular- und Grammatikspezifikationen enthält, wobei das Verfahren ferner einen Schritt des Bevölkerns der Lexikoneinträge mit CLI-Vokabular- und Grammatikspezifikationen für jede neu zu den Netzwerken hinzugefügte Netzwerkeinheit, die durch das NMS verwaltbar ist, umfasst.