DE69413289T2 - Verfahren zur Verminderung des "SNMP"-Instrumentationsnachrichtenflusses - Google Patents
Verfahren zur Verminderung des "SNMP"-InstrumentationsnachrichtenflussesInfo
- 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
Links
- 238000000034 method Methods 0.000 title claims description 35
- 230000008569 process Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 230000004044 response Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000012272 crop production Methods 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network 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.
- 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.
- 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.
- 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.
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)
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)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS60230247A (ja) * | 1984-04-27 | 1985-11-15 | Panafacom Ltd | デイスク制御装置 |
-
1994
- 1994-02-09 DE DE69413289T patent/DE69413289T2/de not_active Expired - Fee Related
- 1994-02-09 EP EP94480010A patent/EP0621705B1/de not_active Expired - Lifetime
- 1994-03-01 JP JP6031255A patent/JP2579433B2/ja not_active Expired - Fee Related
Cited By (2)
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 |