DE10301963A1 - Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks - Google Patents

Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks Download PDF

Info

Publication number
DE10301963A1
DE10301963A1 DE10301963A DE10301963A DE10301963A1 DE 10301963 A1 DE10301963 A1 DE 10301963A1 DE 10301963 A DE10301963 A DE 10301963A DE 10301963 A DE10301963 A DE 10301963A DE 10301963 A1 DE10301963 A1 DE 10301963A1
Authority
DE
Germany
Prior art keywords
network
management
component
network component
central management
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.)
Withdrawn
Application number
DE10301963A
Other languages
English (en)
Inventor
Michael Conradt
Jürgen Totzke
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE10301963A priority Critical patent/DE10301963A1/de
Priority to EP03104227A priority patent/EP1439663B1/de
Priority to DE50300995T priority patent/DE50300995D1/de
Priority to CNB2003101131083A priority patent/CN1279717C/zh
Priority to US10/759,073 priority patent/US8467299B2/en
Publication of DE10301963A1 publication Critical patent/DE10301963A1/de
Withdrawn legal-status Critical Current

Links

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
    • 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/12—Discovery or management of network topologies

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Bei dem erfindungsgemäßen Verfahren wird, ausgehend von einer zentralen Management-Komponente (M), in einem ersten Schritt überprüft, ob es sich bei einer Netzwerk-Komponente (G-A, G-B, G-C) um eine managementfähige Netzwerk-Komponente (G-A, G-B, G-C) handelt. Falls dies der Fall ist, erfolgt eine Klassifizierung der managementfähigen Netzwerk-Komponente (G-A, G-B, G-C) anhand von durch die managementfähige Netzwerk-Komponente (G-A, G-B, G-C) in der Vergangenheit erbrachten Dienste. Eine Klassifizierung erfolgt dabei in die Klassen Host, Router und Switch.

Description

  • Die folgende Erfindung betrifft ein Verfahren zur Klassifizierung von Netzwerk-Komponenten ausgehend von einer zentralen Management-Komponente – in der Literatur häufig als Manager bezeichnet.
  • In den letzten Jahren ist zu beobachten, dass Kommunikation einen immer größeren Stellenwert erlangt. Diese Kommunikation wird in großem Maße über „klassische" Telefonnetze – in der Literatur auch als „Public Switched Telephone Networks" bezeichnet – abgewickelt. Parallel zu den Telefonnetzen existieren Datennetze, mit ihrem bekanntesten Vertreter, dem Internet. Über derartige IP-orientierte Netzwerke (IP: Internet Protocol) werden derzeit im wesentlichen Text- und Bildnachrichten ausgetauscht. In beiden Welten ist Planung, Installation, Wartung und Betrieb der Netze erforderlich, was zum Teil hohe Kosten verursacht. Sowohl für das IP-orientierte Netzwerk als auch für das Telefonnetz fallen diese Kosten an. Es wäre daher wünschenswert, beide bisher getrennten Netze zusammen zu führen, so dass die anfallenden Kosten nur noch einmal auftreten.
  • Problematisch hierbei ist, dass beide Netze unterschiedliche Eigenschaften aufweisen. Die Telefonnetze bieten verbindungsorientierte, echtzeitfähige Dienste an. In der Internet-Architektur, die die am weitesten verbreitete bei den Datennetzen ist, wird ein verbindungsloser, paket-orientierter Dienst definiert. Die Pakete werden hierbei „hop-by-hop" nach dem sogenannten „best effort"-Prinzip befördert. Das bedeutet, dass die Pakete von den Zwischenstationen im Netzwerk jeweils autonom bis zur nächsten Station geleitet werden (hop-by-hop) und „so gut wie möglich" behandelt werden. Dadurch kann es bei Überlastung oder Fehlkonfiguration einer Station zu Verzögerungen bzw. sogar zum Verlust von Paketen kommen. Für Echtzeit-Verbindungen wie Telefonate oder Video-Konferenzen ist dieses Verhalten jedoch unerwünscht, da es bei Verlust oder Verzögerung von Paketen zu hör- bzw. sichtbaren Störungen kommen kann.
  • Möchte man nun eine Konvergenz der Netze erreichen, so dass alle Dienste in einem gemeinsam genutzten Datennetz erbracht werden, sind Vorkehrungen zu treffen, mit denen, trotz der schlechter geeigneten Architektur des Datennetzes, echtzeitfähige Dienste etabliert werden können. Eine Voraussetzung hierfür ist, im Datennetz eine bestimmte Dienstgüte zusichern zu können. Mit Dienstgüte – in der Literatur auch als „Quality of Service (kurz Qo5)" bezeichnet – werden bestimmte Eigenschaften, wie eine maximale Bandbreite, eine maximale Verzögerung der Pakete oder eine Verlustrate bezeichnet.
  • Bisherige Ansätze zur Verwaltung von QoS-Merkmalen in IPorientierten Netzwerken gehen nach dem Prinzip vor, dass der Weg der Pakete zwischen den beiden Kommunikationsendpunkten zum Zeitpunkt des Verbindungsaufbaus bestimmt wird. Auf jeder einzelnen Verbindungseinrichtung, die die Pakete auf ihrem Weg passieren, wird eine entsprechende Reservierung vorgenommen. Als Beispiel sei hier das Ressource Reservation Protocol (kurz RSVP) genannt. Einer der Nachteile bei dieser Art der Reservierung ist, dass jedes Zwischensystem auf das RSVP-Protokoll vorbereitet sein muss, um lokale Reservierungen überhaupt durchführen zu können. Das bringt bei älteren Netzwerken das Problem mit sich, dass alle Komponenten erweitert oder gar durch neue ersetzt werden müssen. Ein weiteres Problem ist, dass derartige Architekturen schlecht mit der Größe des IP-orientierten Netzwerkes skalierbar sind, da es bei jedem Zwischensystem zu Verzögerungen durch die durchzuführende Reservierung kommt. Gravierender ist jedoch die in den Zwischensystemen durchgeführte Kontrolle der Datenströme, die auch bei einer bereits bestehenden Verbindung zu starken Verzögerungen führt.
  • Ein anderer Ansatz ist der des sogenannten externen QoS-Managements. Hierbei finden die Reservierungen nicht innerhalb des IP-orientierten Netzwerkes statt, sondern außerhalb in einer kontrollierenden Instanz – in der Literatur häufig als Manager bezeichnet. Dieser Manager entscheidet, ob zusätzliche Echtzeit-Verkehre mit gegebener Dienstgüte im IPorientierten Netzwerk noch zulässig sind, oder nicht. Um diese Entscheidung treffen zu können, müssen zwei Voraussetzungen erfüllt sein. Der Manager muss die schon im Netzwerk transportierten Verkehre und deren Merkmale kennen, und er muss genaue Informationen über den Zustand und den Aufbau des IP-orientierten Netzwerkes haben. Die erste Voraussetzung ist schon durch die Vorgehensweise erfüllt. Der externe Manager kennt bereits alle Verkehre im IP-orientierten Netzwerk – sie wurden bei ihm angemeldet und entsprechend zugelassen, oder abgelehnt.
  • Die zweite Voraussetzung, um in IP-orientierten Netzwerken externes QoS-Management etablieren zu können ist, genau deren Topologie und damit den Weg, auf dem einzelne Pakete im Netzwerk transportiert werden, zu kennen. Die Netzwerk-Architektur ist jedoch darauf ausgelegt, alle Entscheidungen lokal und möglichst autonom in den einzelnen Netzwerk-Komponenten zu treffen. Aus diesem Grund ist in IP-orientierten Netzwerken keine Instanz zu finden, die die Topologie des Gesamtnetzes kennt. Um jedoch lokale Entscheidungen treffen zu können, ist es für die Komponenten im IP-orientierten Netzwerke notwendig, Informationen als Basis der Entscheidung zu besitzen. Diese Informationen sind lokale (auf die direkte Umgebung begrenzte) Sichten auf die Gesamt-Topologie. Ein Beispiel hierfür ist die sogenannte „Forwarding Database" einer auf Schicht 2 des OSI-Referenzmodells arbeitenden Kommunikationsanlage – in der Literatur häufig als „Switch" bezeichnet – die einen Teil der lokalen Sicht des Switches auf das Gesamt-Netzwerk darstellt. Mit Hilfe dieser lokalen Topologie-Sichten lässt sich eine globale Sicht auf die Topologie generie ren. Um die lokalen Sichten der Netzwerk-Komponenten abzufragen, wird häufig das weit verbreitete „Simple Network Management Protocol" – kurz SNMP – verwendet. Mit Hilfe dieses Standards ist es möglich, den Zustand, und damit auch die lokale Sicht der Netzwerk-Komponente hersteller-unabhängig abzufragen.
  • Anhand von 1 wird die grundlegende Struktur einer Datennetz Management Architektur veranschaulicht. Diese Architektur besteht aus den vier wesentlichen Komponenten: Ausgehend von einer zentralen Management-Komponente M erfolgt ein Zugriff auf die managementfähigen Netzwerk-Komponenten G-A, G-B, G-C des IP-orientierten Netzwerks DN. Hierfür sind in den managementfähigen Netzwerk-Komponenten G-A, G-B, G-C sogenannte Management-Agenteneinheiten A vorgesehen, die jeweils eine Management-Schnittstelle für die managementfähige Netzwerk-Komponenten G-A, G-B, G-C zur Verfügung stellen. Der Datenaustausch zwischen der zentralen Management-Komponente M und den Management-Agenteneinheiten A erfolgt mittels des bereits angesprochenen Management-Protokolls SNMP. Er kann sowohl von der zentralen Management-Komponente M als auch von den Management-Agenteneinheiten A initiiert werden.
  • Die Management-Agenteneinheiten A dienen des weiteren einer Verwaltung einer in den managementfähigen Netzwerk-Komponenten G-A, G-B, G-C jeweils gespeicherten Management Information Base MIB. Die Management Information Base MIB umfasst eine Mehrzahl von sogenannten „Managed Objects" MO. Ein Managed Object MO ist eine Variable, die den Zustand oder die Historie einer managementfähigen Netzwerk-Komponenten G-A, G-B, G-C beschreibt bzw. festlegt. Welche Informationen in einem Managed Object MO hinterlegt sind, ist unter anderem im Standard RFC 1213; McCloghrie, M. Rose: „Management Information Base for Network Management of TCP/IP-bases Internets: MIB-II", März 1991 festgelegt.
  • Die Menge aller in einer Netzwerk-Komponente G-A, G-B, G-C vorhandenen Managed Objects MO bildet die Management Information Base MIB. Die Management Information Base MIB beschreibt somit die Historie einer managementfähigen Netzwerk-Komponente G-A, G-B, G-C, seinen Zustand und damit auch seine lokale Sicht auf das IP-orientierte Netzwerk DN.
  • Zu Beginn einer Topologie-Erkennung ist es nötig, herauszufinden, welche Netzwerk-Komponenten in einem IP-orientierten Netzwerk vorhanden sind. Da in einem IP-orientierten Netzwerk keine zentrale Einheit vorhanden ist, die alle Teilnehmer kennt, wird an jede im lokalen Subnetz mögliche Adresse ein sogenannter „Ping" gesendet. Eine Netzwerk-Komponente, die einen solchen „Ping" mit ihrer Adresse empfängt, sendet (sofern sie nicht sehr ungewöhnlich konfiguriert ist) ein Anwort-Paket an die den „Ping" aussendende Einheit – im vorliegenden Fall die zentrale Management-Komponente M – zurück. Damit ist es möglich, alle Netzwerk-Komponenten im IP-orientierten Netzwerk zu erkennen, die auf Ping-Anfragen reagieren. Die Adressen der erkannten Netzwerk-Komponenten werden anschließend gespeichert.
  • Der nächste Schritt in der Topologie-Erkennung ist, die erkannten Netzwerk-Komponenten zu klassifizieren. Das heißt, sie in verschiedene Kategorien, wie beispielsweise Host, Router oder Switch zu unterteilen.
  • Als Host wird dabei eine einem Benutzer zugeordnete Netzwerk-Komponente, wie beispielsweise ein Arbeitsplatzrechner oder ein sogenanntes „IP-Phone", verstanden.
  • Als Router werden im allgemeinen Netzwerk-Komponenten mit Vermittlungskapazität in paket-vermittelnden Netzwerken bezeichnet, bei denen eine Vermittlung der Pakete auf Basis der Schicht 3 des OSI-Referenzmodells erfolgt.
  • Als Switch werden dahingegen Netzwerk-Komponenten mit Vermittlungskapazität in paket-vermittelnden Netzwerken bezeichnet, bei denen eine Vermittlung der Pakete auf Basis der Schicht 2 des OSI-Referenzmodells erfolgt.
  • Eine Unterteilung ist notwendig, da von den Netzwerk-Komponenten der einzelnen Kategorien unterschiedliche Informatio= nen abfragbar sind. So hat zum Beispiel ein Router Informationen zu weiteren Subnetzen, die ein Switch oder Host nicht besitzen.
  • Beim Stand der Technik erfolgt die Klassifikation einer Netzwerk-Komponente durch eine Abfrage des entsprechenden zur Klassifizierung vorgesehenen Managed Objects MO in der Management Information Base MIB. In vielen der am Markt befindlichen Produkte werden in die Management Information Base MIB jedoch ungeeignete oder sogar falsche Werte eingetragen. Zusätzlich werden die Managed Objects MO durch eine unklare Definition des Standards uneinheitlich von verschiedenen Herstellern verwendet. Aus diesen Gründen ist es nicht möglich, verschiedene Netzwerk-Komponenten mit Hilfe der, dafür vorgesehenen Inhalte der Management Information Base MIB korrekt zu klassifizieren.
    •
  • Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren anzugeben, mit dem eine korrekte Klassifizierung von Netzwerk-Komponenten ermöglicht wird.
  • Die Lösung dieser Aufgabe erfolgt erfindungsgemäß mit den Merkmalen des Patentanspruchs 1.
  • Hierbei erfolgt eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks ausgehend von einer zentralen Management-Komponente. In einem ersten Schritt wird dabei ermittelt, ob es sich bei einer Netzwerk-Komponente um eine managementfähige Netzwerk-Komponente handelt, oder nicht. Ist dies der Fall, erfolgt eine Klassifizierung der managementfähige Netzwerk-Komponente mit Hilfe von durch die managementfähige Netzwerk-Komponente in der Vergangenheit erbrachten Diensten. Für die Klassifizierung werden die Netzwerk-Komponenten dabei in Host, Switch oder Router unterschieden.
  • Ein wesentlicher Vorteil des erfindungsgemäßen Verfahrens besteht darin, dass das Verfahren mit nur geringem Aufwand in bereits bestehende Systeme implementiert werden kann.
  • Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
  • Ein Vorteil von in den Unteransprüchen definierten Ausgestaltungen der Erfindung besteht unter anderem darin, dass durch ein Heranziehen von standardmäßig zur Verfügung stehenden Informationen und eine Kombination von Eigenschaften und von der Historie einer Netzwerk-Komponente eine herstellerunabhängige Klassifizierung der Netzwerk-Komponente auf einfache Weise ermöglicht wird.
  • Ein Ausführungsbeispiel der Erfindung wird im folgenden anhand der Zeichnung näher erläutert.
  • Dabei zeigen:
  • 1: ein Strukturbild mit den wesentlichen Funktionseinheiten einer Management Architektur in einem paketorientierten Netzwerk; und
  • 2: ein Ablaufdiagramm zur Veranschaulichung der wesentlichen beim erfindungsgemäßen Verfahren ablaufenden Verfahrensschritte.
  • Zur besseren Veranschaulichung des erfindungsgemäßen Verfahrens wird bei der Beschreibung der 2 weiterhin auf die Bezeichnungen und Bezugszeichen der 1 Bezug genommen.
  • Gemäß dem erfindungsgemäßen Verfahren wird ausgehend von der zentralen Management-Komponente M in einem ersten Schritt ermittelt, ob es sich bei einer Netzwerk-Komponente G-A, G-B, G-C um eine managementfähige Netzwerk-Komponente G-A, G-B, G-C handelt. Hierfür wird überprüft, ob auf der Netzwerk-Komponente G-A, G-B, G-C eine der zentralen Management-Komponente M zugeordnete Management-Agenteneinheit A implementiert ist, d.h. ob die Netzwerk-Komponente G-A, G-B, G-C auf die Anfrage der zentralen Management-Komponente M antwortet.
  • Ist auf der Netzwerk-Komponente G-A, G-B, G-C keine Management-Agenteneinheit A implementiert, können von dieser Netzwerk-Komponente G-A, G-B, G-C keine Management-Informationen abgefragt werden. Die Klasse der Netzwerk-Komponente G-A, G-B, G-C ist somit unbekannt. In den meisten Fällen handelt es sich hierbei um Hosts.
  • Wird an der zentralen Management-Komponente M eine Antwort einer Netzwerk-Komponente G-A, G-B, G-C empfangen, wird in einem zweiten Schritt überprüft, ob die Netzwerk-Komponente G-A, G-B, G-C die Schicht 3 des OSI-Referenzmodells unterstützt, und ob bereits Datenpakete zwischen den Schnittstellen der Netzwerk-Komponente G-A, G-B, G-C weitergeleitet wurden.
  • Ob die Netzwerk-Komponente G-A, G-B, G-C die Schicht 3 des OSI-Referenzmodells unterstützt, wird dabei durch Abfrage des Managed Objects „sysServices" ermittelt. Jeder getestete Router meldet, dass die Schicht 3 des OSI-Referenzmodells unterstützt wird, allerdings auch einige Switche, oder als solche konfigurierte Router. Um diese Fälle ausschließen zu können, wird zusätzlich die Historie der Netzwerk-Komponente G-A, G-B, G-C betrachtet.
  • Hierfür wird durch die zentrale Management-Komponente M das Managed Object „ipForwDatagrams" abgefragt. Das Managed Object „ipForwDatagrams" ist als Zähler definiert, der nur dann erhöht wird, wenn eine Vermittlung von Datenpaketen auf Basis von Schicht 3 des OSI-Referenzmodells erfolgt.
  • Somit wird in Fällen, in denen durch das Managed Object „sys-Services" angezeigt wird, dass die Schicht 3 des OSI-Referenzmodells unterstützt wird und in denen das Managed Object „ipForwDatagrams" einen vom Wert 0 unterschiedlichen Wert aufweist, die Netzwerk-Komponente G-A, G-B, G-C als Router klassifiziert.
  • Ein Problem ergibt sich bei Netzwerk-Komponenten G-A, G-B, G-C, die als Router aktiv waren und anschließend als Switch umkonfiguriert wurden. Bei dieser Umkonfiguration wird das Managed Object „ipForwDatagrams" unter Umständen nicht automatisch auf 0 zurückgesetzt. Meldet der Switch in diesem Fall immer noch, dass er die Schicht 3 des OSI-Referenzmodells unterstützt, wird er fälschlicherweise als Router und nicht als Switch klassifiziert. Um dieses Fehlverhalten zu vermeiden, muss dafür Sorge getragen werden, dass bei einer derartigen Umkonfiguration das Managed Object „ipForwDatagrams" manuell zurückgesetzt wird.
  • Wird im zweiten Schritt ein negatives Prüfungsergebnis ermittelt, so wird in einem dritten Schritt zusätzlich die Anzahl der Ports der Netzwerk-Komponente G-A, G-B, G-C ermittelt. Dies erfolgt durch die Abfrage des Managed Objects „ifNumber". In Fällen, in denen die Portanzahl größer 1 ist, wird die Netzwerk-Komponente G-A, G-B, G-C als Switch und in den anderen Fällen als Host klassifiziert.
  • Die in der zentralen Management-Komponente M mittels des erfindungsgemäßen Verfahrens ermittelten Topologie-Informationen können beispielsweise im Rahmen einer Ressourcen-Verwaltung oder zur Annahme-Kontrolle für echtzeit-kritische Netzwerk-Verbindungen eingesetzt werden. Auch ein Einsatz im Rahmen von Netzwerk-Planungswerkzeugen ist möglich.
    •

Claims (10)

  1. Verfahren für eine Klassifizierung von Netzwerk-Komponenten (G-A, G-B, G-C) eines paket-orientierten Netzwerks (DN) ausgehend von einer zentralen Management-Komponente (M), bei dem in einem ersten Schritt ermittelt wird, ob es sich bei einer Netzwerk-Komponente (G-A, G-B, G-C) um eine managementfähige Netzwerk-Komponente (G-A, G-B, G-C) handelt, und falls dies der Fall ist, für die Klassifizierung der managementfähige Netzwerk-Komponente (G-A, G-B, G-C) von der managementfähigen Netzwerk-Komponente (G-A, G-B, G-C) in der Vergangenheit erbrachte Dienste herangezogen werden.
  2. Verfahren nach Patentanspruch 1, dadurch gekennzeichnet, dass für eine Kommunikation zwischen der zentralen Management-Komponente (M) und einer managementfähigen Netzwerk-Komponente (G-A, G-B, G-C) auf dieser eine der zentralen Management-Komponente (M) zugeordnete Management-Agenteneinheit (A) implementiert ist.
  3. Verfahren nach Patentanspruch 2, dadurch gekennzeichnet, dass eine Kommunikation zwischen der zentralen Management-Komponente (M) und der Management-Agenteneinheit (A) mittels des SNMP-Protokolls (Simple Network Management Protocol) erfolgt.
  4. Verfahren nach einem der vorhergehenden Patentansprüche, dadurch gekennzeichnet, dass eine Klassifizierung in die Klassen Host, Router oder Switch erfolgt.
  5. Verfahren nach Patentanspruch 4, dadurch gekennzeichnet, dass überprüft wird, – ob die Netzwerk-Komponente (G-A, G-B, G-C) die Schicht 3 des OSI-Referenzmodells unterstützt, und – ob bereits Datenpakete zwischen den Schnittstellen der Netzwerk-Komponente (G-A, G-B, G-C) weitergeleitet wurden, wobei in Fällen, in denen dies der Fall ist, die Netzwerk-Komponente (G-A, G-B, G-C) als Router klassifiziert wird.
  6. Verfahren nach Patentanspruch 5, dadurch gekennzeichnet, dass in Fällen, in denen ein negatives Prüfungsergebnis ermittelt wird, die Anzahl der Ports der Netzwerk-Komponente (G-A, G-B, G-C) überprüft wird, wobei in Fällen, in denen die Portanzahl größer 1 ist, die Netzwerk-Komponente (G-A, G-B, G-C) als Switch und in den anderen Fällen als Host klassifiziert wird.
  7. Verfahren nach Patentanspruch 5 und 6, dadurch gekennzeichnet, dass die Überprüfungen durch eine Abfrage von Managed Objects (MO) in einer Management Information Base (MIB) der entsprechenden Netzwerk-Komponente (G-A, G-B, G-C) erfolgen.
  8. Verfahren nach Patentanspruch 7, dadurch gekennzeichnet, dass die Management Information Base (MIB) einer Netzwerk-Komponente (G-A, G-B, G-C) durch die in der Netzwerk-Komponente (G-A, G-B, G-C) implementierte Management-Agenteneinheit (A) verwaltet wird.
  9. Zentrale Management-Komponente (M), dadurch gekennzeichnet, dass die Komponente zur Durchführung eines Verfahrens nach einem der Patentansprüche 1 bis 8 konfiguriert ist.
  10. Programm mit einer Befehlsfolge, dadurch gekennzeichnet, dass bei einer Ausführung der Befehlsfolge durch einen Prozessor ein Verfahren nach einem der Patentansprüche 1 bis 8 ausgeführt wird.
DE10301963A 2003-01-20 2003-01-20 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks Withdrawn DE10301963A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE10301963A DE10301963A1 (de) 2003-01-20 2003-01-20 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks
EP03104227A EP1439663B1 (de) 2003-01-20 2003-11-17 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks
DE50300995T DE50300995D1 (de) 2003-01-20 2003-11-17 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks
CNB2003101131083A CN1279717C (zh) 2003-01-20 2003-12-22 面向分组的网络的网元的分类方法
US10/759,073 US8467299B2 (en) 2003-01-20 2004-01-20 Method for classifying network components of a packet-oriented network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10301963A DE10301963A1 (de) 2003-01-20 2003-01-20 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks

Publications (1)

Publication Number Publication Date
DE10301963A1 true DE10301963A1 (de) 2004-08-05

Family

ID=32520039

Family Applications (2)

Application Number Title Priority Date Filing Date
DE10301963A Withdrawn DE10301963A1 (de) 2003-01-20 2003-01-20 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks
DE50300995T Expired - Lifetime DE50300995D1 (de) 2003-01-20 2003-11-17 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE50300995T Expired - Lifetime DE50300995D1 (de) 2003-01-20 2003-11-17 Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks

Country Status (4)

Country Link
US (1) US8467299B2 (de)
EP (1) EP1439663B1 (de)
CN (1) CN1279717C (de)
DE (2) DE10301963A1 (de)

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9137115B2 (en) * 2004-12-06 2015-09-15 Bmc Software, Inc. System and method for resource reconciliation in an enterprise management system
EP1667360A1 (de) 2004-12-06 2006-06-07 BMC Software, Inc. Generische Bestimmung für Computernetzwerke
GB2431067B (en) 2005-10-07 2008-05-07 Cramer Systems Ltd Telecommunications service management
GB2432992B (en) * 2005-11-18 2008-09-10 Cramer Systems Ltd Network planning
GB2433675B (en) * 2005-12-22 2008-05-07 Cramer Systems Ltd Communications circuit design
GB2435362B (en) * 2006-02-20 2008-11-26 Cramer Systems Ltd Method of configuring devices in a telecommunications network
US8437877B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8977794B2 (en) 2008-10-27 2015-03-10 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8694164B2 (en) 2008-10-27 2014-04-08 Lennox Industries, Inc. Interactive user guidance interface for a heating, ventilation and air conditioning system
US8600558B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US9632490B2 (en) 2008-10-27 2017-04-25 Lennox Industries Inc. System and method for zoning a distributed architecture heating, ventilation and air conditioning network
US9377768B2 (en) 2008-10-27 2016-06-28 Lennox Industries Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US9268345B2 (en) 2008-10-27 2016-02-23 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8725298B2 (en) 2008-10-27 2014-05-13 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network
US8600559B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. Method of controlling equipment in a heating, ventilation and air conditioning network
US8762666B2 (en) 2008-10-27 2014-06-24 Lennox Industries, Inc. Backup and restoration of operation control data in a heating, ventilation and air conditioning network
US8452906B2 (en) 2008-10-27 2013-05-28 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9678486B2 (en) 2008-10-27 2017-06-13 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8295981B2 (en) 2008-10-27 2012-10-23 Lennox Industries Inc. Device commissioning in a heating, ventilation and air conditioning network
US8352081B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8255086B2 (en) 2008-10-27 2012-08-28 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US9261888B2 (en) 2008-10-27 2016-02-16 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8802981B2 (en) 2008-10-27 2014-08-12 Lennox Industries Inc. Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system
US8463443B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US8615326B2 (en) 2008-10-27 2013-12-24 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9651925B2 (en) 2008-10-27 2017-05-16 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US8994539B2 (en) 2008-10-27 2015-03-31 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8774210B2 (en) 2008-10-27 2014-07-08 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9325517B2 (en) 2008-10-27 2016-04-26 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US9152155B2 (en) 2008-10-27 2015-10-06 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8560125B2 (en) 2008-10-27 2013-10-15 Lennox Industries Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8433446B2 (en) 2008-10-27 2013-04-30 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8655490B2 (en) 2008-10-27 2014-02-18 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8548630B2 (en) 2008-10-27 2013-10-01 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8744629B2 (en) 2008-10-27 2014-06-03 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8543243B2 (en) 2008-10-27 2013-09-24 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8463442B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8892797B2 (en) 2008-10-27 2014-11-18 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8788100B2 (en) 2008-10-27 2014-07-22 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US8442693B2 (en) 2008-10-27 2013-05-14 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8352080B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8655491B2 (en) 2008-10-27 2014-02-18 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US9432208B2 (en) 2008-10-27 2016-08-30 Lennox Industries Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8239066B2 (en) 2008-10-27 2012-08-07 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8437878B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8661165B2 (en) 2008-10-27 2014-02-25 Lennox Industries, Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8564400B2 (en) 2008-10-27 2013-10-22 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8874815B2 (en) 2008-10-27 2014-10-28 Lennox Industries, Inc. Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network
US8855825B2 (en) 2008-10-27 2014-10-07 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8452456B2 (en) 2008-10-27 2013-05-28 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8798796B2 (en) 2008-10-27 2014-08-05 Lennox Industries Inc. General control techniques in a heating, ventilation and air conditioning network
US10831724B2 (en) * 2008-12-19 2020-11-10 Bmc Software, Inc. Method of reconciling resources in the metadata hierarchy
USD648642S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
USD648641S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
US8260444B2 (en) 2010-02-17 2012-09-04 Lennox Industries Inc. Auxiliary controller of a HVAC system
US8712979B2 (en) 2010-03-26 2014-04-29 Bmc Software, Inc. Statistical identification of instances during reconciliation process
US10127296B2 (en) 2011-04-07 2018-11-13 Bmc Software, Inc. Cooperative naming for configuration items in a distributed configuration management database environment
US9158799B2 (en) 2013-03-14 2015-10-13 Bmc Software, Inc. Storing and retrieving context sensitive data in a management system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19526001A1 (de) * 1994-07-19 1996-02-01 Nec Corp Verfahren zur automatischen Ermittlung der Topologie eines ATM-Netzes
US6249814B1 (en) * 1997-09-22 2001-06-19 Compaq Computer Corporation Method and apparatus for identifying devices on a network
US20020032761A1 (en) * 2000-01-31 2002-03-14 Yoshimitsu Aoyagi Method of automatically recognizing network configuration including intelligent packet relay equipment, method of displaying network configuration chart, and system thereof

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3521955B2 (ja) * 1994-06-14 2004-04-26 株式会社日立製作所 階層型ネットワーク管理システム
US6377987B1 (en) * 1999-04-30 2002-04-23 Cisco Technology, Inc. Mechanism for determining actual physical topology of network based on gathered configuration information representing true neighboring devices
US6804712B1 (en) * 2000-06-30 2004-10-12 Cisco Technology, Inc. Identifying link failures in a network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19526001A1 (de) * 1994-07-19 1996-02-01 Nec Corp Verfahren zur automatischen Ermittlung der Topologie eines ATM-Netzes
US6249814B1 (en) * 1997-09-22 2001-06-19 Compaq Computer Corporation Method and apparatus for identifying devices on a network
US20020032761A1 (en) * 2000-01-31 2002-03-14 Yoshimitsu Aoyagi Method of automatically recognizing network configuration including intelligent packet relay equipment, method of displaying network configuration chart, and system thereof

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
McCLOGHRIE, K. , ROSE, M.: Management Information Base for Network Management of TCP/IP-bases internets: MIB-II, März 1991, S. 1-70 *

Also Published As

Publication number Publication date
EP1439663A2 (de) 2004-07-21
US8467299B2 (en) 2013-06-18
DE50300995D1 (de) 2005-09-22
EP1439663A3 (de) 2004-09-15
EP1439663B1 (de) 2005-08-17
CN1518280A (zh) 2004-08-04
CN1279717C (zh) 2006-10-11
US20040146008A1 (en) 2004-07-29

Similar Documents

Publication Publication Date Title
EP1439663B1 (de) Verfahren für eine Klassifizierung von Netzwerk-Komponenten eines paket-orientierten Netzwerks
DE60031776T2 (de) Verfahren und vorrichtung für ein kommunkationsnetz
DE60102367T2 (de) Netzoptimierungsmethode
EP3035634B1 (de) Telekommunikationsanordnung und verfahren zum herstellen einer rtc-verbindung zwischen einem ersten endpunkt und einem zweiten endpunkt
DE60029879T2 (de) System zur mehrschichtigen Bereitstellung in Computernetzwerken
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
DE602004001470T2 (de) Verfahren zum Bereitstellen von Diensten mit garantierter Dienstqualität in einem IP-Zugangsnetz
DE60316745T2 (de) Erleichterung der beschleunigten Verarbeitung von Nachrichten des Internet Group Management Protokolls
DE112011100339B4 (de) System zum Gegensteuern bei Netzwerk-Datenüberlastungen
EP0632617A2 (de) Verfahren und Einrichtung zur Unterstützung des Netzwerkmanagements
DE60303691T2 (de) Verfahren und System zu richtliniengestützten Steuerung in einem verteilten Netzwerk
DE602004008618T2 (de) System und verfahren zum einheitlichen weiterleiten von paketen über drahtlose und verdrahtete netzwerke
EP1428361A2 (de) Verkehrsbegrenzung mittels zulässigkeitsprüfung für ein paketorientiertes verbindungsloses netz mit qos niveau übertragung
DE102014219472A1 (de) Verfahren zum Übertragen von Daten, Netzknoten und Netzwerk
DE60205501T2 (de) Verwaltung von informationen über subskriptionen der dienstleistungen von dritten
EP1761081A1 (de) Kommunikationssystem, Vermittlungsknoten-Rechner und Verfahren zur Bestimmung eines Kontrollknotens
EP1629642A1 (de) Verfahren für eine Verkehrsverteilung mittels Hash-Codes entsprechend einer Soll-Verkehrsverteilung in einem paketorientierten Netz mit Mehrwege-Routing
EP1398907B1 (de) Verfahren zur Kontrolle von Übertragungsressourcen eines paketorientierten Kommunikationsnetzes bei Topologieänderungen
DE102014006038A1 (de) Verfahren und Vorrichtung zur Übermittlung und Adaption von Daten, Computerprogramm, Softwareprodukt und Digitales Speichermedium
EP1317820B1 (de) Verfahren zum aufbau von verbindungen mit vorgegebener dienstgüte für ein paketorientiertes kommunikationsnetz mit einem resourcenmanager
DE60313026T2 (de) Verfahren und gerät zur verteilung von datenpaketen von einem computer zu einem clustersystem
EP2686995B1 (de) Verfahren zum aufbau einer kommunikationsverbindung
EP1119216A1 (de) Verfahren und Vorrichtung zur Zugangssteuerung eines Kommunikationsnetzes
DE60302865T2 (de) Bandbreitenmakler für ein Telekommunikationssystem
EP1371236B1 (de) Verfahren zur selektiven und gesammelten weiterleitung von meldungen in einem tmn-netzwerk

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8130 Withdrawal