DE69413289T2 - Verfahren zur Verminderung des "SNMP"-Instrumentationsnachrichtenflusses - Google Patents

Verfahren zur Verminderung des "SNMP"-Instrumentationsnachrichtenflusses

Info

Publication number
DE69413289T2
DE69413289T2 DE69413289T DE69413289T DE69413289T2 DE 69413289 T2 DE69413289 T2 DE 69413289T2 DE 69413289 T DE69413289 T DE 69413289T DE 69413289 T DE69413289 T DE 69413289T DE 69413289 T2 DE69413289 T2 DE 69413289T2
Authority
DE
Germany
Prior art keywords
row
instrumentation
agent
subagent
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69413289T
Other languages
English (en)
Other versions
DE69413289D1 (de
Inventor
David De-Hui Cary Nc 27513 Chen
William Frank Jr. Raleigh Nc 27615 Mc Kenzie
Keith Irwin Raleigh Nc 27615 Meyer
Leo Raleigh Nc 27612 Temoshenko
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Application granted granted Critical
Publication of DE69413289D1 publication Critical patent/DE69413289D1/de
Publication of DE69413289T2 publication Critical patent/DE69413289T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0213Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/046Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Description

  • Die vorliegende Erfindung betrifft das Netzmanagement unter Verwendung des einfachen Netzmanagement-Protokolls (SNMP) und im einzelnen ein Verfahren zur Verminderung des Nachrichtenflusses an eine und von einer Instrumentation in einem SNMP- Gerät.
  • Die Datenkommunikation hat sich zu einem wesentlichen Teil der Datenverarbeitung entwickelt. Weltweite Netzwerke sammeln Daten über solch unterschiedliche Themen wie Wetterbedingungen, Ernteerzeugung und Luftverkehr. Diese Netze entwickelten sich als voneinander unabhängige Entitäten ohne die Fähigkeit oder, bis vor kurzem, die Notwendigkeit, miteinander eine Verbindung einzugehen. Neue als "Internetworking" bezeichnete Technologien sind enstanden; mit ihnen ist es möglich, viele physikalisch ungleichartige Netze miteinander zu verbinden, so daß sie als eine koordinierte Einheit funktionieren. Unter Anwendung der Internetworking-Technologien kann zum Beispiel ein Host in einem Netz über viele Netze hinweg mit einem anderen Host in einem anderen Netz kommunizieren.
  • Die Größe eines "Internets" oder einer Gruppe von miteinander verbundenen Netzwerken kann beträchtlich schwanken. Das daraus entstehende Netzwerk kann enorm groß sein, wie zum Beispiel das landesweite Internet DARPA (Defense Advanced Research Projects Agency)/NSF (National Science Foundation), in dem die meisten großen Forschungsinstitute, Universitäten sowie unternehmens- und regierungseigene Laboratorien miteinander verbunden sind. Umgekehrt kann das Netz auch relativ klein sein und nur die lokalen Netze (LANs) einer einzigen Institution umfassen.
  • Unabhängig von der Größe des Netzes ist aber die Aufgabe, das entstandene, miteinander verbundene Netzwerk effektiv zu verwalten, von großer Bedeutung; man hat dieser Aufgabe daher innerhalb der Netzwerkgemeinschaft große Aufmerksamkeit gewidmet. Bei der Verwaltung eines Netzwerks muß der Netzverwalter die Geräte innerhalb der Netzwerke verfolgen, die Netzleistung und die Netzauslastung überwachen sowie Probleme diagnostizieren und korrigieren.
  • Während für die Verwaltung homogener Netze Produkte verfügbar sind, ist die Verwaltung heterogener Netze komplizierter und bis vor kurzem gab es keinen allgemein anerkannten Standard für ihre Verwaltung. Das einfache Netzmanagement-Protokoll (SNMP), das als ein Mittel zur Verwaltung der TCP/IP (Transmission Control Protocol/Internet Protocol) und der Ethernet-Netzwerke entstanden ist, hat sich schnell verbreitet, da seine Überwachungs- und Steuerungstransaktionen von TCP/IP und Ethernet vollständig unabhängig sind. Für SNMP sind lediglich Datagramm-Transportmechanismen erforderlich.
  • Mit SNMP können die Netzverwalter Anfragen und Befehle an Netzknoten und Netzgeräte richten. SNMP überwacht die Netzleistung und den Netzstatus, steuert die Betriebsparameter und hält diese Fehler fest, analysiert und isoliert sie. Diese Funktionen werden von dem Protokoll durch den Transport von Verwaltungsinformationen zwischen den "Verwaltern" und den "Agenten" ausgeführt.
  • SNMP definiert die drei folgenden Grundkomponenten:
  • 1. Einen Agenten, eine in einem verwalteten Netzgerät, beispielsweise einem Host, einem Gateway oder einem Terminal- Server, untergebrachte Komponente. Jeder Agent speichert Verwaltungsdaten und antwortet auf die Anforderungen des Verwalters bezüglich dieser Daten und kann einen "TRAP", einen speziellen freilaufenden SNMP-Befehl, an den Verwalter senden, nachdem eine vorher festgelegte Bedingung erkannt wurde.
  • 2. Einen Verwalter, eine in einer Netzverwaltungsstation untergebrachte Komponente. Der Verwalter übernimmt die Abfrage/Steuerung der Agenten unter Verwendung verschiedener SNMP-Befehle.
  • 3. Eine Management-Informationsbasis (MIB), eine verwaltete Objekt-Datenbank, die den Agenten zugänglich ist und über SNMP für die Netzverwaltungsapplikation manipuliert wird.
  • Um die Aufgaben des Agenten und des Verwalters ausführen zu können, spezifiziert SNMP fünf Befehls- oder Verbarten, genannt Protokolldatenelemente (PDUs): GetRequest, GetNextRequest, SetRequest, GetResponse und Trap. (Die PDUs "SetRequest" und "Trap" stehen in keinem Zusammenhang mit der vorliegenden Erfindung und werden daher nicht beschrieben.) Nachdem sie entweder eine PDU "GetRequest" oder eine PDU "GetNextRequest" von einem Verwalter empfangen haben, prüfen und holen die Agenten die angegebenen Tabellenwerte. Die Verwalter verwenden GetRequest zum Holen einzelner Werte. Die PDU "GetNextRequest" wird von dem Verwalter ausgegeben, um mit einem primitiven Blocktransfer zu beginnen, und der Agent meldet die ausgewählten Daten mit einem GetResponse-Verb zurück.
  • In dem Buch The Simple Book: "An introduction to management of TCP/IP-based internets, Englewood Cliffs, US, Prentice.
  • Hall, Kapitel 5, werden die Vorteile der PDU "Get Next" des SNMP-Protokolls im Vergleich zu der einfachen PDU "Get" beschrieben. Beim Senden eines "Get-Next" vermindert der Verwalter den Netzverkehr, indem er mehrere Anforderungen für dieselbe Operation in einer Anforderung zusammenfügt. Der Netzverkehr muß jedoch noch weiter reduziert werden, wie im folgenden erläutert wird.
  • Konzeptuell verwendet SNMP Tabellen zur Speicherung der Information im MIB. Diese Tabellen bestehen aus Reihen und Spalten. Fig. 1 zeigt eine typische SNMP-Tabelle. Spalten sind Attribute, oder, in Verbindung mit SNMP, Objekttypen, welche die Ressourcen charakterisieren. Jede Reihe stellt eine Instanz der Ressource dar. Ein SNMP-GetRequest oder -GetNextRequest eines einzelnen Objektes erlaubt es einem Verwalter, eine Instanz des Objektes abzurufen. Das SNMP-Element "GetRequest" und "GetNextRequest" erlaubt außerdem das Abrufen einer Gruppe von Objekten mit einer Anforderung. Obwohl SNMP keine Beschränkung dahingehend enthält, welche Objekte in einer PDU angefordert werden sollten, holen die meisten Verwalter ihre Informationen (entweder als Ganzes oder als Teilgruppe) aus einer Reihe. Der Agent behandelt jedes Objekt in der PDU als eine getrennte Anforderung und gibt es an den Subagenten weiter. Dieser Vorgang ist in Fig. 2 zu sehen, wie weiter unten beschrieben wird.
  • Fig. 2 zeigt ein System 20, das einem SNMP entspricht. Um die Verwaltung und Organisation der großen Menge von Daten, die für den Zugriff durch den Verwalter 22 in der Netzverwaltungsstation 24 gesammelt und gepflegt werden müssen, zu unterstützen, kann der Agent 26 des verwalteten Netzgeräts 28 einen oder mehrere Subagenten verwenden (ein Subagent, 30, ist dargestellt), um die Datenelemente in den verschiedenen Tabellen zu manipulieren. Jeder Subagent kann für eine bestimmte Tabelle oder Tabellengruppe verantwortlich sein. Um auf die einzelnen Tabellen zuzugreifen, geben die Subagenten Befehle an die Instrumentation 32 des verwalteten Netzgerätes aus, die die physikalischen Datenelemente letztendlich pflegt.
  • Um alle Datenelemente in einer gegebenen Reihe abzurufen, würde der Verwalter an den Agenten ein "GetRequest" oder "GetNextRequest" ausgeben. Der Befehl würde die spezifische Datenposition angeben, zum Beispiel (Reihe 1, Spalte 1), (Reihe 1, Spalte 2), ... (Reihe m, Spalte n), an der sich die gewünschten Datenelemente befinden, so daß für mehrere Datenelemente eine PDU ausgegeben wird. Der Agent gibt dann individuell eine Anforderung für jedes Datenelement an den Subagenten, der diese wiederum an die Instrumentation weitergibt. Die Instrumentation antwortet für jede Anforderung dem anfordernden Subagenten, der seinerseits dem Agenten antwortet. Der Agent sammelt anschließend alle Ergebnisse und antwortet dem Verwalter unter Angabe der angeforderten Werte der Datenelemente, normalerweise mit einer einzelnen GetResponse- PDU.
  • Dieser Vorgang ist in Fig. 2 dargestellt. Der Verwalter 22 gibt eine einzelne GetRequest-PDU (GetReq 1) für die gewünschten Datenelemente ((1, 1), (1, 2), (1, 3)) aus. (Alternativ kann der Verwalter auch mehrere PDUs ausgeben, in denen die gewünschten Datenelemente angegeben sind.) Der Agent 26 empfängt diese PDU und sendet eine erste Anforderung für das erste Datenelement (Req 1 (1, 11)) an den Subagenten 30, der dieses seinerseits an die Instrumentation 32 weiterleitet. Die Instrumentation ruft das Datenelement aus der Tabelle ab und sendet es an den Subagenten 30 (Resp 1 (1, 1)), der es an den Agenten 26 weiterleitet. Der Agent 26 leitet dann die nächste Anforderung (Req 2 (1, 2)) und ebenso Req 3 (1, 3) an den Subagenten 30, der daraufhin den gleichen Abrufprozeß durchführt. Wenn der Agent 26 alle Datenelemente empfangen hat, sendet er sie über eine einzelne GetResponse-PDU (GetResp 1 (1, 1), (1, 2), (1, 3)) an den Verwalter 22.
  • Dieser Eins-zu-Eins-Austausch zwischen dem Subagenten und der Instrumentation erfordert viel Verarbeitungszeit und ist daher kostspielig. Jede von dem Subagenten an die Instrumentation ausgegebene Anforderung verbraucht Verarbeitungszeit, welche die Instrumentation sonst anderen Aufgaben widmen könnte, beispielsweise dem Routen ankommender Datagramme, wenn es sich bei dem verwalteten Netzgerät beispielsweise um einen Router handeln würde. Wenn zum Beispiel der Verwalter eine Netzgerät-Statustabelle abrufen möchte, die aus 1.000 Reihen und 50 Spalten besteht, um eine graphische Benutzerschnittstelle mit einer Network Map darzustellen, müßte die Instrumentation 50.000 Informationsanforderungen verarbeiten.
  • Eine große Anzahl der Austauschschritte zwischen dem Subagenten und der Instrumentation verlangsamt die Leistung des verwalteten Netzgeräts beträchtlich. In der Zeit, in der die Instrumentation diese Informationsanforderungen verarbeitet, kann zum Beispiel bei einem Router kein Netzverkehr weitergeleitet werden. Das heißt, je mehr das Gerät mit traditionellen Verfahren verwaltet wird, desto weniger ist es in der Lage, seine primären Routing/Networking-Funktionen auszuführen.
  • Wenn durch eine einzige PDU-Anforderung des Verwalters der Austausch einer großen Anzahl einzelner Nachrichten zwischen dem Subagenten und der Instrumentation bewirkt wird, kann darüber hinaus zwischen dem ersten und dem letzten Nachrichtenaustausch viel Zeit vergehen. Während dieser Zeit können sich die von der Instrumentation überwachten Bedingungen ändern. Dies ist ein Problem, weil der Verwalter nicht sicher sein kann, daß er einen "Schnappschuß" der Bedingung zu einem bestimmten Zeitpunkt erhalten hat, da die Bedingung dynamisch oder nicht dynamisch sein kann.
  • Ein weiteres Problem des SNMP-Datenabrufsystems nach dem Stand der Technik besteht ist, daß bei Ausgabe eines "GetNextRequest" an die Instrumentation am Ende einer Datenspalte, das heißt, in der letzten Reihe der Spalte, eine Antwort "noSuchName" erzeugt wird. Es muß ein zweites GetNextRequest ausgegeben werden, um das erste Datenelement der folgenden Spalte abrufen zu können, mit anderen Worten, wenn eine Tabelle "m" Reihen und "n" Spalten hat, wird bei einem GetNextRequest (Reihe m, Spalte x), wobei "x" jede Spaltenzahl ist, die nicht größer als "n" ist, eine Antwort "noSuchName" an den Subagenten zurückgemeldet. Es muß ein weiteres "GetNextRequest" (0, Spalte x + 1) an die Instrumentation ausgegeben werden, um das Datenelement in (Reihe 1, Spalte x + 1) abzurufen. Dieser zusätzliche Nachrichtenaustausch zwischen der Instrumentation und dem Subagenten verschärft das Problem der großen Anzahl von Verarbeitungsanforderungen zusätzlich und hält die Instrumentation weiter von ihren eigentlichen Aufgaben ab.
  • Fig. 3 zeigt ein SNMP-Abrufsystem nach dem Stand der Technik in einem anderen Extremfall. Der Verwalter 22 gibt eine GetRequest-PDU (GetReq 1 (1, 1), (1, 2), (1, 3)) an den Agenten 26 aus, der einzelne Anforderungen für jedes Datenelement an den Subagenten 31 sendet. Der Subagent 31 gibt an die In strumentation 33 einen generischen Req-Befehl aus, die Instrumentation 33 antwortet, indem sie ihre gesamte Datenbank (alle Reihen; alle Spalten) an den Subagenten 31 sendet. Der Subagent 31 sendet die einzelnen Datenelemente zurück an den Agenten 26, in Antwort auf Anforderungen, welcher dieser sammelt, um sie an den Verwalter 22 weiterzuleiten.
  • Zwar wird der individuelle Nachrichtenfluß zwischen dem Subagenten und der Instrumentation vermindert, jedoch ist dieses Verfahren zum Abrufen von Daten von der Instrumentation aus einer Reihe von Gründen ineffizient. Zum einen muß der Subagent über einen großen Internspeicher verfügen, weil bei jeder Datenelementanforderung die Instrumentation dem Subagenten einen kompletten "Daten-Dump" liefert. Zweifache Kopien der gesamten Datenbank werden verwaltet; da die Datenbank riesig sein kann, geht hierfür viel Platz verloren. Zum anderen sind die von der Instrumentation gepflegten Daten oft dynamisch, so daß spätere GetRequests vom Verwalter zu einem ungenauen Datenabruf vom Subagenten führen, da die dort gespeicherten Daten nicht zeitgerecht sind. Schließlich kommt es häufig vor, daß Subagenten gegen alte und falsche Daten schützen, indem sie nach einem vorher festgesetzten Zeitraum ihre gespeicherten Daten aus dem Speicher abziehen. Dies führt bei jeder Anforderung eines Datenelements zu weiteren kompletten Instrumentations-Daten-Dumps.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die Erfindung betrifft ein Verfahren und eine Einrichtung zum Abrufen von Datenelementen in einem mittels einfachem Netzmanagement-Protokoll (SNMP) verwalteten Gerät durch einen Verwalter, welche den Instrumentations-Nachrichtenfluß vermindern. Das Verfahren gemäß der Erfindung dient zum Abrufen von Datenelementen aus einer Tabelle in dem SNMP-verwalteten Gerät und umfaßt einen Agenten oder einen Agenten und einen Subagenten, und eine Instrumentation, wobei die genannte Instrumentation mindestens eine Tabelle hat mit einer Vielzahl von Reihen und einer Vielzahl von Spalten, die genannte mindestens eine Tabelle eine Vielzahl von Datenelementen in entsprechenden Tabellenpositionen hat, definiert durch die genannte Vielzahl von Reihen und die genannte Vielzahl von Spalten, wobei das genannte Verfahren dadurch gekennzeichnet ist, daß es die folgenden Schritte umfaßt:
  • a) der genannte Agent empfängt eine Anforderung, die von dem genannten Verwalter ausgegeben wurde, mindestens ein Datenelement von einer Tabellenstelle abzurufen, die durch eine der genannten Reihen und mindestens eine der genannten Spalten definiert ist;
  • b) das genannte Mittel fordert die genannte Instrumentation auf, alle genannten Datenelemente aus der genannten Tabelle in der genannten einen Reihe abzurufen;
  • c) das genannte Mittel empfängt von der genannten Instrumentation alle genannten Datenelemente in der genannten einen Reihe;
  • d) das genannte Mittel speichert die genannten Datenelemente aus der genannten einen Reihe in einem internen Speicherbereich; und
  • e) das genannte Mittel antwortet mit mindestens einem Datenelement von der genannten Tabellenstelle, die durch die genannte eine Reihe und die genannte mindestens eine Spalte definiert wurde.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die technische Beschreibung enthält im Anschluß die Ansprüche, in denen die Eigenschaften, die als Erfindung betrachtet werden, besonders hervorgehoben und im einzelnen beansprucht werden; die Details eines bevorzugten Ausführungsbeispiels der Erfindung können jedoch einfacher anhand der folgenden technischen Beschreibung in Verbindung mit den beiliegenden Zeichnungen verständlich gemacht werden; es zeigt:
  • Fig. 1 eine Darstellung einer Tabelle, die in einem nach einfachen Netzmanagement-Protokoll (SNMP) verwalteten Gerät verwendet werden kann.
  • Fig. 2 ein Blockdiagramm, das den Nachrichtenaustausch zwischen einem Verwalter, einem Agenten, einem Subagenten und einer Instrumentation während einer traditionellen SNMP- Blocktransferfunktion erläutert.
  • Fig. 3 ein Blockdiagramm eines anderen SNMP-Datenabrufsystems nach dem Stand der Technik, das den Nachrichtenaustausch zwischen einem Verwalter, einem Agenten, einem Subagenten und einer Instrumentation während eines SNMP-Blocktransfers erläutert.
  • Fig. 4 ein Blockdiagramm, das den Nachrichtenaustausch zwischen einem Verwalter, einem Agenten, einem Subagenten und einer Instrumentation während eines SNMP-Datenabrufprozesses der vorliegenden Erfindung erläutert.
  • Fig. 5 ein Blockdiagramm, das den Nachrichtenaustausch zwischen einem Verwalter, einem Agenten, einem Subagenten und einer Instrumentation während eines anderen SNMP-Datenabrufprozesses der vorliegenden Erfindung erläutert.
  • AUSFÜHRLICHE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
  • Das Verfahren der vorliegenden Erfindung wird eingesetzt in einem System, das dem einfachen Netzmanagement-Protokoll (SNMP) entspricht. Durch Verwendung von "Look-ahead"-Algorithmen vermindert das Verfahren während eines Datenabrufs die Anzahl der zwischen dem Instrumentationsteil des verwalteten Netzgeräts und dem Subagententeil des verwalteten Netzgeräts ausgetauschten Meldungen. Insbesondere nutzt das Verfahren der vorliegenden Erfindung den Vorteil der Voraussetzung, daß bei der Verwaltung eines Netzes der Verwalter oft Gruppen von verwandten Datenelementen aus Tabellen in dem verwalteten Netzgerät analysieren muß, und nicht einzelne getrennte Datenelemente. Wenn zum Beispiel die Tabelle mit Datenelementen gepflegt wird, die Fehler in bezug auf das verwaltete Netzgerät anzeigen, das heißt, eine Problembestimmungstabelle, muß der Verwalter alle oder die meisten der Fehleranzeigedaten analysieren, um zu bestimmen, wodurch die verschiedenen Probleme verursacht werden. Wenn der Verwalter also den Abruf eines Datenelements anfordert, wird erwartet, daß er bald den Abruf eines verwandten Datenelementes anfordert. Diese verwandten Datenelemente sind normalerweise in Reihen zusammengefaßt.
  • Die von der Instrumentation gepflegten Daten sind zudem häufig dynamischer Natur. Das Datenabrufsystem muß dies daher berücksichtigen, so daß genaue Daten an den Verwalter zurückgemeldet werden. Ein Verwalter braucht schließlich häufig einen "Schnappschuß" oder ein Bild zu einem bestimmten Zeit punkt aus einer Gruppe von verwandten Elementen, das von ihm angefordert wird unter Anwendung einer einzelnen GetRequest- oder GetNextRequest-PDU. In der vorliegenden Erfindung werden all diese Überlegungen berücksichtigt, indem ein außergewöhnliches System und ein Verfahren zum Abrufen von Daten von einer Instrumentation mit vermindertem Nachrichtenfluß bereitgestellt wird, und gleichzeitig dem Verwalter genaue und zeitgerechte Daten zur Verfügung gestellt werden.
  • Fig. 4 ist ein Blockdiagramm eines SNMP-Systems 34, das den Nachrichtenaustausch zwischen einem Verwalter 22 in einer Netzverwaltungsstation 24 und einem Agenten 36, einem Subagenten 40 und der Instrumentation 42 des verwalteten Netzgeräts 38 im Verlauf eines SNMP-Datenabrufs der vorliegenden Erfindung erläutert. Es handelt sich hier um das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung, obwohl andere äquivalente Konfigurationen gleich gut funktionieren können. Es wird zum Beispiel ein Subagent 40 gezeigt, der als Schnittstelle zwischen dem Agenten 36 und der Instrumentation 42 arbeitet. Der Subagent ist nicht notwendig, aber er wird hier bevorzugt eingesetzt. Das Verfahren und System der vorliegenden Erfindung konzentrieren sich auf die Verminderung des Instrumentations-Nachrichtenflusses, unabhängig davon, ob der Agent direkt mit der Instrumentation korrespondiert oder der Subagent zwischengeschaltet ist.
  • Wie man sieht, gibt der Verwalter 22 ein einzelnes GetRequest-Protokolldatenelement (PDU) für drei Datenelemente ((1, 1), (1, 2), (1, 3)) an den Agenten 36 des verwalteten Netzgeräts 38 aus. Der Agent 36 sendet die Anforderung für das erste Datenelement (Req 1 (1, 1)) an den Subagenten 40. Der Subagent 40 gibt, anstatt die identische Anforderung einfach an die Instrumentation 42 weiterzugeben, eine Anforde rung aus, den gesamten Inhalt der Reihe 1 abzurufen (Req 1 (1, alle Spalten)). Die Instrumentation ruft den Inhalt der Reihe 1 ab und sendet ihn an den Subagenten 40 (Resp 1 (1, alle Spalten)).
  • Der Subagent 40 empfängt den Inhalt der Reihe 1 und speichert ihn in einem internen Speicherbereich, den er zur späteren Verwendung pflegt. Der Subagent 40 sendet dann an den Agenten 36 (Resp 1 (1, 1)) den Inhalt der durch Reihe 1, Spalte 1 definierten Tabellenstelle.
  • Der Agent 36 leitet die Anforderung für das nächste Datenelement an den Subagenten 40 weiter (Req 2 (1, 2)). Nachdem er den Inhalt von Reihe 1 in seinem internen Speicherbereich gespeichert hat, ruft der Subagent 40 die angeforderten Datenelemente ab und sendet sie an den Agenten 36 (Resp 2 (1, 2)). Die dritte Datenelementanforderung vom Agenten 36 wird von dem Subagenten in derselben Weise abgewickelt, bis ein Datenelement aus einer anderen Reihe durch eine GetRequest- PDU angefordert wird. Nachdem der Agent 36 alle Antworten erhalten hat, sendet er diese in einer einzelnen GetResponse- PDU (GetResp 1 (1, 1), (1, 2), (1, 3)) an den Verwalter 22.
  • Wie man sieht, wird durch das von dem Subagenten angewandte Verfahren der Nachrichtenfluß zur und von der Instrumentation beträchtlich vermindert, wenn eine Reihe von Datenelementen während einer einzelnen PDU von dem Verwalter angefordert wird. Hierdurch wird Verarbeitungszeit frei, die die Instrumentation ihren Hauptaufgaben widmen kann, wie zum Beispiel dem Protokoll-Routing, wenn es sich um einen Router handelt. Wenn der Verwalter eine neue GetRequest- oder GetNextRequest- PDU ausgibt, wird von der Instrumentation eine neue Serie von Datenelementen abgerufen, so daß ein "Schnappschuß" eines be stimmten Zustands vorliegt und die an den Agenten gesendeten Datenelemente zeitgerecht und genau sind.
  • Wenn ein Verwalter eine Reihe von GetNextRequests an den Agenten ausgibt und es zu einem Überlauf kommt, das heißt, wenn das Ende der Spalte erreicht ist, wird durch das Verfahren und System der vorliegenden Erfindung der Nachrichtenfluß zwischen dem Subagenten und der Instrumentation, im Vergleich zu den herkömmlichen Verfahren und Systemen, weiter reduziert. Dies ist in Fig. 5 zu sehen. Zunächst fordert der Verwalter das in der letzten Reihe (Reihe m) einer Spalte (als Beispiel wird hier die Spalte 1 verwendet) liegende Datenelement unter Verwendung einer GetNextRequest an, in der die Position des Datenelements angegeben ist (GetNext (m, 1)). Der Agent 36 sendet die GetNextRequest an den Subagenten 40. Der Subagent 40 gibt ein GetNextRequest für die gesamte nächste Reihe (GetNext (m, alle Spalten)) an die Instrumentation 42 aus. Weil die letzte Reihe erreicht ist, gibt es keine "nächste Reihe", die von der Instrumentation 42 abgerufen werden kann. Die Instrumentation 42 meldet dem Subagenten 40 eine Antwort "noSuchName" (wie es auch normalerweise der Fall ist, wenn das Ende einer Spalte erreicht ist). Zusätzlich jedoch sendet er die Datenelemente der ersten Reihe (Resp (1, alle Spalten)) zusammen mit der Antwort "noSuchName" zurück. Dies ermöglicht es dem Subagenten 40, die zweite Spalte der ersten Reihe auszuwählen, und diesen Wert an den Agenten 36 weiterzuleiten, unter Anwendung von Resp (1, 2), und hierdurch wird dann der angeforderte Wert an den Verwalter 22 gesendet. Hierdurch wird der traditionell notwendige Schritt des Subagenten, der die Antwort "noSuchName" an den Agenten sendet, und der einen zusätzlichen Nachrichtenfluß zwischen dem Subagenten und der Instrumentation erfordert, überflüssig.
  • Wie man erkennen kann, wird durch diesen Teil des von dem Subagenten angewandten Verfahrens der Nachrichtenfluß zwischen dem Subagenten und der Instrumentation weiter vermindert, wenn die Reihe der vom Verwalter angeforderten Datenelemente bis in die nächste Spalte hineinreicht. Hierdurch wird weitere Verarbeitungszeit für die Instrumentation und deren eigentliche Aufgaben und Dienste frei.
  • Das Verfahren und das System der vorliegenden Erfindung vermindert also den Instrumentations-Nachrichtenfluß in einem einfachen Netzmanagement-Protokoll (SNMP)-Gerät. Das Verfahren und das System verwenden "Look-ahead"-Algorithmen, wodurch Datenelemente, die noch nicht von dem Agenten angefordert wurden (deren Anforderung jedoch erwartet wird), von der Instrumentation abgerufen werden. Durch das Verfahren und das System wird Verarbeitungszeit in der Instrumentation durch Verminderung des Nachrichtenflusses frei. Außerdem können das Verfahren und das System auf einfache Weise erweitert werden, um mehrere Reihen und nicht nur eine Reihe zurückzusenden, was zu einer noch größeren Verminderung des Nachrichtenflusses zur und von der Instrumentation führen kann. Die Anzahl der zurückgesendeten Reihen wäre direkt abhängig von den GetRequest-PDUs des Verwalters. Für jede neue GetRequest- oder GetNextRequest-PDU vom Verwalter wird eine neue Gruppe von Daten von der Instrumentation empfangen werden. Wenn Datenelemente aus verschiedenen Reihen mit einer einzelnen GetRequest- (oder GetNextRequest-) PDU angefordert werden, können mehrere Reihen, die die Datenelemente enthalten, von der Instrumentation zurückgegeben werden, so daß der Manager einen genauen "Schnappschuß" erhält.
  • Zwar wurde die Erfindung unter Bezugnahme auf bevorzugte Ausführungsbeispiele im einzelnen erläutert und beschrieben, jedoch wird der Fachmann verstehen, daß verschiedene Änderungen in Form und Detail daran vorgenommen werden können, ohne vom Erfindungsumfang abzuweichen.

Claims (10)

1. Ein Verfahren zum Abrufen von Datenelementen aus einer Tabelle in einem Gerät mit einfachem Netzmanagement- Protokoll (SNMP) durch einen Verwalter, wobei das genannte Gerät Mittel (36, 40) umfaßt, die einen Agenten oder einen Agenten und einen Subagenten umfassen, und eine Instrumentation (42), wobei die genannte Instrumentation mindestens eine Tabelle mit einer Vielzahl von Reihen und einer Vielzahl von Spalten hat, die genannte mindestens eine Tabelle eine Vielzahl von Datenelementen an entsprechenden Tabellenstellen hat, die durch die genannte Vielzahl von Reihen und die genannte Vielzahl von Spalten definiert werden, wobei das genannte Verfahren dadurch gekennzeichnet ist, daß es die folgenden Schritte umfaßt:
a) der genannte Agent (36) empfängt eine Anforderung, die von dem genannten Verwalter ausgegeben wurde, mindestens ein Datenelement von einer Tabellenstelle abzurufen, die durch eine der genannten Reihen und mindestens eine der genannten Spalten definiert ist;
b) das genannte Mittel fordert die genannte Instrumentation auf, alle genannten Datenelemente aus der genannten Tabelle in der genannten einen Reihe abzurufen;
c) das genannte Mittel empfängt von der genannten Instrumentation alle genannten Datenelemente in der genannten einen Reihe;
d) das genannte Mittel speichert die genannten Datenelemente aus der genannten einen Reihe in einem internen Speicherbereich; und
e) das genannte Mittel antwortet mit mindestens einem Datenelement von der genannten Tabellenstelle, die durch die genannte eine Reihe und die genannte mindestens eine Spalte definiert wurde.
2. Das Verfahren nach Anspruch 1, bei dem das genannte Mittel (36, 40) ein Agent (36) sind.
3. Das Verfahren nach Anspruch 1, bei dem das genannte Mittel (36, 40) einen Agenten (36) und einen Subagenten (40) umfaßt, wobei das genannte Verfahren dadurch gekennzeichnet ist, daß:
- es zwischen Schritt a und Schritt b den folgenden Teilschritt umfaßt:
der genannte Agent sendet eine Anforderung an den genannten Subagenten, ein Datenelement von einer Tabellenstelle abzurufen, die durch die genannte eine Reihe und eine der genannten mindestens einen Spalte definiert ist;
- Schritt b von dem genannten Subagenten ausgeführt wird;
- Schritt c von dem genannten Subagenten ausgeführt wird;
- Schritt d von dem genannten Subagenten ausgeführt wird;
wobei das genannte Verfahren weiter dadurch gekennzeichnet ist, daß
- es zwischen Schritt 4 und Schritt S den folgenden Teilschritt umfaßt:
der genannte Subagent sendet an den genannten Agenten das genannte eine Datenelement von der genannten Tabellenstelle, die durch die genannte eine Reihe und die genannte eine Spalte definiert wurde;
- Schritt e von dem genannten Agenten ausgeführt wird.
4. Das Verfahren nach Anspruch 3, weiter folgende Schritte umfassend:
- der genannte Subagent empfängt von dem genannten Agenten eine zweite Anforderung, ein Datenelement von einer durch die genannte eine Reihe und eine weitere der genannten Spalten definierten Tabellenstelle abzurufen
- der genannte Agent ruft aus dem internen Speicherbereich des genannten Subagenten das genannte Datenelement von der genannten Tabellenstelle ab, die durch die genannte erste Reihe und die genannte weitere Spalte definiert wird;
- der genannte Subagent sendet an den genannten Agenten das genannte Datenelement von der genannten Tabellenstelle, die durch die genannte erste Reihe und die genannte weitere Spalte definiert wird.
5. Das Verfahren nach Anspruch 2 oder Anspruch 4, wobei die genannte mindestens eine Tabelle erste bis letzte Reihen und erste bis letzte Spalten hat, das genannte Verfahren weiter für den genannten Agenten nach Anspruch 2 oder den genannten Subagenten nach Anspruch 4 die folgenden Schritte umfaßt:
- Empfangen einer Anforderung, das nächste Datenelement, das auf das Datenelement in einer Tabellenstelle folgt, die durch eine der genannten Spalten und die genannte letzte Reihe definiert wird, abzurufen;
- Auffordern der genannten Instrumentation, die Datenelemente in der nächsten Reihe abzurufen;
- von der genannten Instrumentation die Datenelemente in der genannten ersten Reihe empfangen;
- Antworten durch das Datenelement in der Tabellenstelle, die durch die genannte erste Reihe und die nächste Spalte definiert wird.
6. Ein Gerät mit einfachem Netzmanagementprotokoll (SNMP), umfassend einen Agenten (36) und eine Instrumentation (42), wobei die genannte Instrumentation mindestens eine Tabelle mit einer Vielzahl von Reihen und einer Vielzahl von Spalten hat, die genannte mindestens eine Tabelle eine Vielzahl von Datenelementen an entsprechenden Tabellenstellen hat, die durch die genannte Vielzahl von Reihen und die genannte Vielzahl von Spalten definiert sind, der genannte Agent zum Abrufen der genannten Datenelemente aus der genannten Tabelle gekennzeichnet ist durch:
- Mittel zum Empfangen der genannten von dem genannten Manager ausgegebenen Anforderung, mindestens ein Datenelement von der Tabellenstelle abzurufen, die durch eine erste der genannten Vielzahl von Reihen und mindestens eine der genannten Spalten definiert ist;
- Mittel, um die genannte Instrumentation aufzufordern, alle genannten Datenelemente aus der genannten Tabelle in der genannten ersten Reihe abzurufen;
- Mittel, um von der genannten Instrumentation alle der genannten Datenelemente in der genannten ersten Reihe zu empfangen;
- einen internen Speicherbereich zum Speichern der genannten Datenelemente aus der genannten ersten Reihe; und
- Mittel, um das genannte mindestens eine Datenelement von der genannten Tabellenstelle, die durch die genannte erste Reihe und die genannte mindestens eine Spalte definiert wurde, zu senden.
7. Ein Gerät nach Anspruch 6, gekennzeichnet durch einen Subagenten zwischen dem genannten Agenten und der genannten Instrumentation, wobei der genannte Subagent mit der Instrumentation korrespondiert und die folgenden Mittel umfaßt:
- Mittel zum Empfangen einer Anforderung von dem genannten Agenten zum Abrufen eines Datenelements von einer Tabellenstelle, die durch eine erste der genannten Vielzahl von Reihen und eine der genannten Spalten definiert wurde;
- Mittel, um die genannte Instrumentation aufzufordern, alle genannten Datenelemente aus der genannten Tabelle in der genannten ersten Reihe abzurufen;
- Mittel, um von der genannten Instrumentation alle der genannten Datenelemente in der genannten ersten Reihe zu empfangen;
- einen internen Speicherbereich zum Speichern der genannten Datenelemente aus der genannten ersten Reihe; und
- Mittel zum Senden der genannten Datenelemente von der genannten durch die genannte erste Reihe und die genannte eine Spalte definierten Tabellenstelle an den genannten Agenten.
8. Ein Gerät, nach Anspruch 6, dadurch gekennzeichnet, daß der genannte Subagent folgende Mittel umfaßt:
- Mittel, um von dem genannten Agenten eine zweite Anforderung zu empfangen, von einer durch die genannte erste Reihe und eine andere der genannten Spalten definierten Tabellenstelle ein Datenelement abzurufen;
- Mittel, um aus dem internen Speicherbereich des genannten Subagenten das genannte Datenelement von der genannten durch die genannte erste Reihe und die genannte andere Spalte definierten Tabellenstelle abzurufen;
- und Mittel, um an den genannten Agenten das genannte Datenelement von der genannten Tabellenstelle zu senden, die durch die genannte erste Reihe und die genannte andere Spalte definiert wird.
9. Ein Gerät nach Anspruch 8, wobei die genannte mindestens eine Tabelle erste bis letzte Reihen und erste bis letzte Spalten aufweist, das genannte durch den genannten Subagenten gekennzeichnete Gerät folgende Mittel umfaßt:
- Mittel zum Empfangen einer Anforderung, ein Datenelement von einer durch die genannte letzte Reihe und eine der genannten Spalten definierten Tabellenstelle abzurufen;
- Mittel, um durch das genannte Datenelement von der genannten, durch die genannte letzte Reihe und die genannte eine Spalte definierten Tabellenstelle zu antworten;
- Mittel zum Empfangen einer Anforderung zum Abrufen des nächsten Datenelements;
- Mittel, mit dem die genannte Instrumentation aufgefordert wird, die Datenelemente in der nächsten Reihe abzurufen;
- Mittel, um von der genannten Instrumentation die Datenelemente in der ersten Reihe zu empfangen; und
- Mittel, um durch das genannte Datenelement von der genannten durch die genannte erste Reihe und die genannte folgende Spalte definierten Tabellenstelle zu antworten.
10. Ein Gerät nach Anspruch 8, bei dem das genannte Gerät ein Router ist.
DE69413289T 1993-03-22 1994-02-09 Verfahren zur Verminderung des "SNMP"-Instrumentationsnachrichtenflusses Expired - Fee Related DE69413289T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US3406893A 1993-03-22 1993-03-22

Publications (2)

Publication Number Publication Date
DE69413289D1 DE69413289D1 (de) 1998-10-22
DE69413289T2 true DE69413289T2 (de) 1999-06-02

Family

ID=21874106

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69413289T Expired - Fee Related DE69413289T2 (de) 1993-03-22 1994-02-09 Verfahren zur Verminderung des "SNMP"-Instrumentationsnachrichtenflusses

Country Status (3)

Country Link
EP (1) EP0621705B1 (de)
JP (1) JP2579433B2 (de)
DE (1) DE69413289T2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6944631B2 (en) 2001-11-13 2005-09-13 Siemens Aktiengesellschaft Method and system for network configuration discovery

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2780587B1 (fr) * 1998-06-25 2004-06-04 Bull Sa Agent de communication entre un administrateur de systeme et un systeme de ressources distribuees et procede de traitement d'une requete sur un attribut multi-instanciable
FR2780589B1 (fr) 1998-06-30 2000-12-01 Bull Sa Agent de communication entre un administrateur de systeme informatique et un systeme de ressources distribuees et outils de creation d'un tel agent
GB2344262A (en) * 1998-10-02 2000-05-31 Gen Datacomm Adv Res Retrieval of network management information
US7062550B1 (en) * 1999-01-20 2006-06-13 Bindview Corporation Software-implemented method for identifying nodes on a network
GB2352942B (en) 1999-08-04 2001-10-03 3Com Corp Method and apparatus for fetching sparsely indexed MIB tables in managed network systems
KR100349670B1 (ko) * 1999-12-24 2002-08-22 한국전자통신연구원 통합액세스노드시스템에서의 표준관리동작처리 오류 방지방법

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60230247A (ja) * 1984-04-27 1985-11-15 Panafacom Ltd デイスク制御装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6944631B2 (en) 2001-11-13 2005-09-13 Siemens Aktiengesellschaft Method and system for network configuration discovery
DE10251911B4 (de) * 2001-11-13 2006-10-12 Siemens Ag Verfahren für das Konfigurationsmanagement und Netzwerk

Also Published As

Publication number Publication date
JP2579433B2 (ja) 1997-02-05
EP0621705A3 (en) 1996-02-07
EP0621705B1 (de) 1998-09-16
JPH076109A (ja) 1995-01-10
DE69413289D1 (de) 1998-10-22
EP0621705A2 (de) 1994-10-26

Similar Documents

Publication Publication Date Title
DE69413104T2 (de) Anordnung und Verfahren zur Überwachung von Tafeln von einfachen Netzverwaltungsprotokollen
DE69938160T2 (de) Verfahren und Vorrichtung zur Verwaltung von Netzwerken und Anlagen
DE60031274T2 (de) Mehrfachanschlussverfahren und -gerät für vituelle ports
DE69832946T2 (de) Verteiltes System und Verfahren zur Steuerung des Zugriffs auf Netzmittel und Ereignismeldungen
DE69931473T2 (de) Eingang/ausgang scanner für ein steuersystem mit gleichrangiger ermittlung
DE69712678T2 (de) Verfahren zur Echtzeitüberwachung eines Rechnersystems zu seiner Verwaltung und Hilfe zu seiner Wartung während seiner Betriebsbereitschaft
DE69636914T2 (de) Verfahren und Vorrichtung für Netzwerkverwaltung
EP0825524B1 (de) Verfahren zur Verwaltung der Benennung von Objekten
DE69916928T2 (de) Zugriffsverfahren und Server für Netzwerkverzeichnis
DE69132280T2 (de) System und Verfahren zur Modellierung eines Computer-Netzwerks
DE69628718T2 (de) Netzwerk - Topologie-Verwaltungssystem
DE69911681T2 (de) Verfahren zum Verfolgen von Konfigurationsänderungen in Netzwerken von Rechnersystemen durch historische Überwachung des Konfigurationsstatus der Vorrichtungen im Netzwerk
DE69416399T2 (de) Allgemeines modell von verwalteten objekten für den lan-bereich
DE69410304T2 (de) Datenverarbeitungssystem zur Verwaltung von Objekten
DE69637142T2 (de) Netzwerkverwaltung mit Erfassung von formatierten Abzugdaten aus einem Fernprozess
EP0632617A2 (de) Verfahren und Einrichtung zur Unterstützung des Netzwerkmanagements
DE602004004991T2 (de) Automatisierte Installation von Netzgeräten mit Informationen über Regeln, Authentifizierung und gerätespezische Daten
DE19924261B4 (de) Netzmanagementverfahren und System
DE102016203598A1 (de) Gemeinschaftliche sammlung von diagnosedaten von softwareprogrammen
DE60302605T2 (de) Verfahren und Vorrichtung zur Generierung und Übertragung von Fehlercodes in Agent X
DE69413289T2 (de) Verfahren zur Verminderung des "SNMP"-Instrumentationsnachrichtenflusses
DE102004030781A1 (de) SCADA-System und Verfahren zum Betreiben eines solchen Systems
EP1198143A2 (de) Netzwerk-Management System
DE10332360A1 (de) Verfahren und System zur Ereignisübertragung
DE19813883B4 (de) Verfahren, Computerprogrammprodukt und Dokumentenmanagementsystem zum Zugriff auf Internet-Informationen für geschlossene Benutzergruppen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee