DE60031274T2

DE60031274T2 - Mehrfachanschlussverfahren und -gerät für vituelle ports

Info

Publication number: DE60031274T2
Application number: DE60031274T
Authority: DE
Inventors: Tomoyuki Kanagawa-ken SUGIHARA
Original assignee: Allied Telesyn International Corp
Current assignee: Allied Telesyn International Corp
Priority date: 1999-07-09
Filing date: 2000-07-06
Publication date: 2007-05-24
Anticipated expiration: 2020-07-07
Also published as: DE60040700D1; EP1760936A9; EP1750392B1; WO2001005101A1; EP2088712B1; US6385197B1; EP2088712A1; EP1760936B1; EP1750392A3; EP1750392A2; ATE413037T1; EP1760936A1; JP3740060B2; JP2003504961A; WO2001005101A9; ATE342622T1; DE60031274D1; EP1192760A1; EP1192760B1; AU6198500A

Description

Hintergrund der Erfindung
Die vorliegende Erfindung betrifft im Allgemeinen das Management von Netzwerk-Switches und im Besonderen einen Mechanismus zur Vereinfachung der Verwaltung der Ports eines Netzwerk-Switchs.
Netzwerkmanagement wird als Management der Netzwerkkomponenten, wie Workgroup-Hubs, Switches, Router, Bridges, etc., sowie als Management der diese miteinander verbindenden Leitungen definiert. 1 stellt ein herkömmliches Netzwerkmanagementmodell 100 dar. Die diesem zugrundliegende Basis besteht aus den Netzwerkmanagementanwendungen 110, die zur Verwaltung des Netzwerks eingesetzt werden. Diese Managementanwendungen sollten dieselbe Endbenutzeroberfläche und vorzugsweise ein Befehlsdaten-Repository aufweisen. Es versteht sich von selbst, dass die Benutzeroberfläche intuitiv vom Benutzer erschließbar, benutzerfreundlich, auf Kundenwünsche zuschneidbar und mit allen Anwendungen kompatibel zu sein hat. Ein herkömmliches Befehlsdaten-Repository 120 sollte das Duplizieren von Daten verhindern und den Zugang aller Anwendungen zu gespeicherten Informationen ermöglichen. Außerdem sollten Netzwerkmanagementanwendungen 110 problemlos mit Desktopmanagement- und geschäftlichen Anwendungen zusammenarbeiten können.
Die ersten Standardisierungsversuche im Bereich Netzwerkmanagement führten zu einer Spezifikation, die als SNMP (Simple Network Management Protocol) bekannt wurde. Diese basiert auf dem TCP/IP-Protokollstapel und wurde unter der von der Internet Engineering Task Force (IETF) zugeteilten RFC-Nummer 1067 bekannt. Die Arbeitslast der SNMP-Spezifikation liegt auf der Management Information Base (MIB). Die MIB ist eine Sammlung von Informationen (oder Objekten) über die verwaltete Komponente. Obwohl der Ausdruck MIB für verschiedenste Bedeutungsnuancen stehen kann, werden im Folgenden darunter die tatsächlichen, in einer SNMP-Komponente oder in der Datenbeschreibung gespeicherten Daten verstanden. Diese MOB-Objekte sind in einer Komponentenklasse standardisiert, so kann eine Managementstation alle Objektinformationen aus verschiedenen Komponenten abfragen oder eine Aktion bei einem Agenten durch Manipulation dieser Objekte auslösen. Die Konfigurationseinstellung einer Komponente kann ebenfalls mithilfe dieses Verfahrens geändert werden.
Durch Einbetten des SNMP in die Datenkommunikationskomponenten können Multivendor-Managementsysteme diese Komponenten von einer zentralen Position aus verwalten und die Informationen graphisch erfassen. Die vielen, heute erhältlichen SNMP-Managementanwendungen laufen üblichweise auf den meisten aktuellen Betriebssystem, wie UNIX, Windows^TM 98 und Windows NT^TM 5.0. Die meisten hochwertigen Produkte werden so entwickelt, dass sie mit relativ großen Netzwerken umgehen und daher auf leistungsstarken Rechnern, die das skalierbare UNIX-Betriebssystem verwenden, laufen können.
Das SNMP-Betriebsmodell beruht auf vier Elementen: der Managementstation, dem Managementagenten, dem Netzwerkmanagementprotokoll und der Management Information Base (MIB). Die Managementstation dient den verwalteten Elementen des Netzwerks als Oberflächenwerkzeug. Die Managementstation umfasst herkömmlicherweise eine graphische Benutzeroberfläche, die zur Überwachung und Kontrolle des Netzwerks mittels einer Netzwerkkarte (NIC) eingesetzt wird.
2 stellt ein Netzwerksystem 200 dar, welches einen Netzwerkmanager und einen Netzwerkagenten 220 umfasst. In diesem Beispiel wird das zur Interkommunikation zwischen der Managementstation und den Agenten verwendete Netzwerkmanagementprotokoll tatsächlich als SNMP bezeichnet und umfasst die folgenden, definierten Funktionen:

1. Get ermöglicht der Managementstation die Erfassung der Informationsobjekte beim Agenten.
2. Set ermöglicht der Managementstation die Festlegung der Werte der Managementobjekte beim Agenten.
3. GetNext ermöglicht der Managementstation, die nächste, darauffolgende Information in den Managementobjekten vom Agenten abzufragen.
4. Trap ist eine unaufgeforderte Nachricht des Agenten an die Managementstation zur Benachrichtigung der Managementstation bezüglich wichtiger Ereignisse.

Eine verwaltete Komponente umfasst einen Managementagenten, der auf Informationsanfragen antwortet und Aktionen von der Managementstation anfordert. Dieser Agent kann die Managementstation durch Traps auch mit unaufgeforderten Information versorgen. Hauptnetzwerkkomponenten, wie Hubs, Router und Bridges, müssen daher diesen Managementagenten (oft als SNMP-Agent oder als SNMP-fähig bezeichnet) für sich selbst bereitstellen, um mittels SNMP-Managementstation verwaltet werden zu können.
Im Allgemeinen ist eine standardisierte Weise zur Beschreibung der in einer MIB enthaltenen Objekte vorhanden. Damit eine Managementstation jedoch die Objekte der verschiedenen Komponenten verstehen und darauf zugreifen kann, müssen bestimmte Ressourcen an jedem Knoten im Netzwerk in gleicher Art und Weise vorhanden sein. Die Struktur der Managementinformation, die im RFC 1155 spezifiziert ist, definiert den allgemeinen Rahmen innerhalb jeder MIB, kann generisch definiert werden und ist so gestaltet, dass Konsistenz sichergestellt ist. Außerdem kann jedes Unternehmen seine eigenen, spezifischen MIBs zur Bereitstellung detaillierterer Informationen über die speziellen, verwalteten Komponenten definieren. Das Problem einer generischen MIB ist, dass die darin definierten Objekte zum eingehenden Management der speziellen Netzwerkkomponenten manchmal nicht ausreichen. Dies ist besonders bei den neuen Layer-2/3-Switches der Fall, die eigene MIB ist bei diesen Komponenten wichtig, da jeder Anbieter mit seinem Switch anders kommuniziert. Dies bedeutet, dass jeder Anbieter ausführliche Informationen über die unternehmensspezifische, eigene MIB zu liefern hat. Managementanwendungen verwenden spezifische MIBs zur Bereitstellung ausführlicher, erweiterter Ansichten der Komponenten, zum Mapping der Netzwerktypologien auf den Managementplattformen und zur Konfiguration und Kontrolle der geswitchten Umgebungen, die virtuelle LANs (VLANs) und Segmentierung enthalten.
Wie oben erwähnt, stellt die grundlegende SNMP-Fähigkeit allein dem Benutzer nicht genügend brauchbare Informationen über das LAN als Ganzes, sondern vielmehr Informationen über die Komponenten des LAN zur Verfügung. Daher ist die RMON-Fähigkeit eine wichtige Erweiterung zum SNMP. Es ist hierbei anzumerken, dass RMON besonders nützlich zur Überwachung und Verwaltung von LANs ist.
RMON wurde durch die IETF erstellt und wurde 1992 als Standard unter der RFC-Nummer 1271 festgelegt. Die RMON-Spezifikation wurde entwickelt, um Datenübertragungsstatistiken und -analysen vieler Netzwerkparameter zur umfassenden Netzwerkfehlerdiagnose, -planung und -leistungsabstimmung bereitzustellen. Das Ethernet war der ursprüngliche Schwerpunkt und wird im RFC 1271 beschrieben, die Fernüberwachungsfunktionen wurden jedoch 1993 auch auf den Token-Ring unter der RFC-Nummer 1513 ausgeweitet.
RMON stellt einen standardisierten Satz MIBs zur Verfügung, die ausführliche, statistische Netzwerkinformationen sammeln, die durch einfache SNMP-MIBs nicht verfügbar wären. Diese Information stellt im Grunde alle Angaben dar, die es in Bezug auf Switches zu wissen gilt, deshalb ist sie für das Management von Netzwerksystemen von besonderer Bedeutung. RMON ermöglicht die Durchführung proaktiver Netzwerkdiagnosen durch die Verwendung seiner leistungsstarken Alarm-Gruppe. Die Alarm-Gruppe ermöglicht die Festlegung von Grenzwerten für kritische Netzwerkparameter zur automatischen Weitergabe von Alarmsignalen an die zentral positionierten Managementkonsolen. Dies ist besonders wichtig, wenn Gigabit-Ethernet-Switches verwaltet werden, da das Volldraht-Management bei maximaler Geschwindigkeit bei einer solchen Geschwindigkeit so gut wie nicht durchführbar ist.
RMON ist von besonderer Bedeutung bei der Verwaltung von Switches von einer weiter entfernten Position aus, da ein Switch eine komplette MIB-Information pro Port statt pro Komponente aufweist. Wenn ein regelmäßiges SNMP zur Überwachung ei nes Switch von Port zu Port verwendet werden würde, würde dies zu großen Mengen übertragener SNMP-Daten führen. Durch die in den Switch integrierte RMON-Unterstützung kann dies zu einer schnell durchzuführenden und einfachen Aufgabe werden. Ein Switch mit RMON wird zum Sammeln der und Arbeiten mit den eigenen Daten, sowie zum Weiterleiten von Informationen an eine zentrale Managementstation eingesetzt.
Bei gemeinsam benutzten Segmenten findet sich der Datenverkehr an einem Hub bei allen Ports wieder. Dadurch entstehen in Bezug auf eine RMON-Sonde (Probe) an einem der Ports keine Probleme: alle Daten werden durch die RMON-Sonde erfasst und analysiert. In einem Switch gibt es jedoch nur Datenverkehr von einem Port zum anderen Port. Wenn der Client von Switch 1 mit dem am Server angebrachten Port 3 kommuniziert, kann beispielsweise die mit Port 5 verbundene Sonde diesen Datenverkehr nicht erfassen, wenn sich nicht ein integrierter Switchmechanismus in Position befindet. Dieser Mechanismus wird oft als Port-Spiegelung bezeichnet und wird vom Switch selbst implementiert. Der Benutzer kann die verschiedenen Kriterien für die zum Überwachungsport geleiteten Daten selbst einstellen.
Eine der wichtigsten, vom Netzwerkmanagement durchgeführten Funktionen ist das Konfigurationsmanagement des Systems.
Das Konfigurationsmanagement besteht aus zwei Hauptelementen. Eines ist das Erfassen der physikalischen und logischen Konfiguration des Netzwerks und die zweite betrifft die Konfiguration sowie die Aktualisierung und Updaten der Netzwerkkomponenten, etwa der Hubs, Switches und Router.
Konfigurationsmanagement der physikalischen und logischen Typologie ist wahrscheinlich einer der wichtigsten Bestandteile des Netzwerkmanagements bei denen der Benutzer ein Netzwerk nicht akkurat verwalten kann, wenn der Benutzer nicht auch die Konfiguration des Netzwerks verwalten kann. Dies wird oft mithilfe eines leistungsstarken Netzwerkkonfigurationswerkzeugs durchgeführt. Einige Netzwerkkonfigurationswerkzeuge ermöglichen die Erstellung sowohl einer physikalischen als auch einer logischen Netzwerkversion und zeichnet alle Hinzufügungen, Bewegungen und Veränderungen des Netzwerks auf. Diese Aufzeichnungen werden dann besonders wichtig, wenn der Übergang von gemeinsam benutzten Medien zur einer Switch-Umgebung erfolgt. Ein Zurückgehen zur vorherigen Konfiguration kann von Vorteil sein, wenn es Probleme mit der neuen geben sollte, so dass sichergestellt werden kann, dass oft eine Sicherung der wertvollen Daten durchgeführt wird. Veränderungen, Hinzufügungen und Löschungen im Netzwerk benötigen die dynamische Aktualisierung der Datenbank der Konfigurationsanwendung, um die Beständigkeit zwischen dem Mapping des tatsächlichen Netzwerks und dem sicherzustellen, das durch die Anwendung repräsentiert wird.
Es ist weiters nützlich eine Anwendung zu haben, die zuerst automatisch die Konfiguration des Netzwerks erkennt. Dies ist traditionell eine anbieterspezifische Eigenschaft jeder Managementsoftware, aber neuere Standardisierungen haben gezeigt, dass sich die Industrie auch in diesem Bereich einander annähert. In der Desktop Management Task Force (DMTF) definieren die Arbeitsgruppen der Industrie einen Standard zur Durchführung der Attributierung eines verwalteten Objekts, wie etwa eines Routers, eines Switchs, eines Hubs oder einer NIC, zu einem speziellen Datenbankschema. Das Datenbankschema wird dann diese Information zum Mapping der Netzwerkobjekte, der Personal Computer und der Server zu einer Gesamtkonfiguration verwenden. Der Vorteil dieses Verfahrens liegt darin, dass die Konfiguration automatisch aktualisiert wird, wenn sich die Position oder Konfiguration einer Netzwerkkomponente ändert.
Leistungsmanagement ist von großer Bedeutung für die Bestimmung, ob der Benutzer ein existierendes Netzwerk auf ein geswitchtes oder ein Fast-Ethernet aufrüsten sollte. Leistungsmanagement sollte jedoch ein ständig durchzuführender Vorgang sein. Leistungsmanagement kann ebenfalls bei der Identifizierung der Bereiche dienen, an denen die Switching- oder Fast-Ethernet-Technologie nicht in vollem Umfang eingesetzt werden kann.
Zur Bestimmung des Leistungspegels eines Switch kann der Benutzer entweder die Managementstation so konfigurieren, dass diese Daten abgefragt werden, oder einige Grenzwerte im Switch festlegen und dann die Rechnungen durchführen lassen, um die Leistung dieses Segments mit einigen vorbestimmten Werten zu vergleichen. Es ist wichtig hier eine Vorstellung davon zu haben, wie die Basiszahlen auszusehen haben, um vernünftige Entscheidungen treffen zu können. Einige Anwendungen können für einen Zeitabschnitt zur Überwachung der Segmente eingesetzt werden und dann Empfehlungen für Grenzwertzahlen abgeben. Datenverkehrsmuster können somit von einem Segment zu andern variieren und beruhen im Allgemeinen auf einer gründlichen Kenntnis des Netzwerks und der Vorstellung, wie dieses sich verhalten sollte.
In einem herkömmlichen Netzwerk, welches die Port-Bündelung unterstützt, wird jedoch eine große Menge an redundanten Port-Bündelungs-Informationen benötigt, um vom Netzwerkmanager verwaltet und/oder verarbeitet werden zu können. In einer Bündel-Gruppierung mit fünf Bündelungsverbindungen, welche die fünf Ports des Knoten 1 und die fünf Ports des Knoten 4 miteinander verbinden, werden Portinformationen von allen fünf Bündel-Ports des Knoten 1 und des Knoten 4 benötigt, damit diese im Netzwerkmanager gespeichert werden. Die Konfigurationsdaten von allen 10 Ports (5 Ports von Knoten 1 und 5 Ports von Knoten 2) werden vom Netzwerkmanager verwaltet. Durch die Bündel-Definition sind die Portinformationen jedes Bündel-Ports auf den jeweiligen Knoten einander sehr ähnlich und redundant. Weiters werden, damit auf diese Bündel-Gruppierung zugegriffen werden kann, wiederholt redundante SNMP-Anfragen vom SNMP-Manager an jeden der fünf Bündel-Ports an Knoten 1 und Knoten 4 geschickt. Aufgrund dieser Redundanzen ist ein verbessertes und effizienteres Verfahren sowie eine verbesserte und effizientere Vorrichtung zur Adressierung der Vielzahl an Bündel-Ports erwünscht.
Das IBM Technical Disclosure Bulletin, Vol. 36, Nr. 6A, 145–146, 1. Juni 1993 offenbart ein Verfahren einer dynamischen Bandbreitenzuordnung zum Aufnehmen und Auffinden von Gruppierungen in einem geswitchten Netzwerk.
Zusätzliche Objekte, Eigenschaften und Vorteil der verschiedenen Aspekte der vorliegenden Erfindung werden durch die folgende Beschreibung der bevorzugten Ausführungsformen ersichtlich, wobei die Beschreibung in Bezug auf die beigefügten Zeichnungen zu lesen ist.
Zusammenfassung der Erfindung
Es ist daher ein Ziel der vorliegenden Erfindung ein neues Verfahren zur Adressierung mehrerer Ports in einem mit einem Netzwerkmanager verbundenen Knoten zu offenbaren.
Es ist ein weiteres Ziel der vorliegenden Erfindung, ein Verfahren zur Unterstützung von Port-Bündelung zwischen einer Vielzahl an Kunden bereitzustellen.
Es ist ein weiteres Ziel der vorliegenden Erfindung eine effiziente Methode zur Adressierung mehrerer Parts in einer Switching-Einheit für den Netzwerkmanager bereitzustellen.
Es ist ferner ein Ziel der vorliegenden Erfindung ein logisches Adressierverfahren zum Verweisen auf mehrere Ports in einer Switching-Einheit anzuwenden.
Die vorliegende Erfindung offenbart ein neues virtuelles Portverfahren und eine neue virtuelle Portvorrichtung zur Anwendung bei der Kommunikation zwischen mehreren Knoten in einem Netzwerksystem. Besonders das virtuelle Portkonzept wird in einer eine Vielzahl an physikalischen Ports umfassenden Switching-Einheit implementiert. Gemäß der vorliegenden Erfindung kann zumindest ein virtueller Port durch den Benutzer definiert werden, um eine entsprechende Gruppierungsnummer der physikalischen Ports darzustellen. In diesem Fall kann eine einzelne virtuelle Portidentifizierung von einem Netzwerkmanager zur Identifizierung aller physikalischen Ports einer Bündel-Gruppierung verwendet werden. Durch die Verwendung einer virtuellen Portidentifizierungsadresse anstatt einer Gruppierung physikalischer Portadressen, kann eine erhebliche Verringerung des Verarbeitungsaufwands des Netzwerkmanagers erzielt werden.
Kurzbeschreibung der Zeichnungen
1 veranschaulicht ein herkömmliches Netzwerkmanagementmodell.
2 stellt ein herkömmliches Netzwerksystem mit einem Netzwerkmanager und einem Netzwerkagenten dar.
3 zeigt ein vereinfachtes Netzwerkkontrollsystem, umfassend einen Netzwerkmanager und eine Vielzahl an Netzwerkknoten, die mit dem Netzwerkmanager verbunden sind.
4 stellt eine Port-Mapping-Tabelle gemäß der vorliegenden Erfindung dar.
5 zeigt eine virtuelle Porttabelle, die die Portzuordnung für die in den 3 und 4 abgebildeten Beispiele darstellt.
6 veranschaulicht eine virtuelle Porttabelle einer anderen bevorzugten Ausführungsform gemäß der vorliegenden Erfindung.
7 ist ein Flussdiagramm zur Darstellung der Abläufe an der Knoten-Seite zur Abwicklung der Anfragen vom Netzwerkmanager.
8 zeigt ein Blockdiagramm einer bevorzugten Ausführungsform einer Switching-Einheit gemäß der vorliegenden Erfindung.
Detaillierte Beschreibung der Erfindung
3 zeigt ein vereinfachtes Netzwerkkontrollsystem, welches einen Netzwerkmanager 310 und eine Vielzahl an Netzwerkknoten, die mit dem Netzwerkmanager 310 verbunden sind, umfasst. In diesem Beispiel sind nur drei der vielen Netzwerkknoten abgebildet: Knoten 1 320, Knoten 5 330 und Knoten 3 340. Zur besseren Veranschaulichung stellen die Knoten 1, 3 und 5 drei separate Switching-Einheiten dar. Jeder der Knoten 1, 2 und 3 ist mit anderen Knoten und/oder Endbenutzern verbunden. Die Switching-Einheiten 320, 330, 340 werden vom Netzwerkmanager 310 mithilfe einer Gruppe von Kontrollsignalen 350a, b, c überwacht. Diese Kontrollsignale 350a, b, c können tatsächlich in die Kommunikationskanäle zwischen dem SNMP-Manager 310 und den Switching-Einheiten 320, 330, 340 im Netzwerksystem eingebettet werden. In dieser bevorzugten Ausführungsform ist der Netzwerkmanager für die Verwaltung des gesamten Netzwerks zuständig. Der SNMP-Manager 310 verwaltet und speichert Netzwerkdaten und -informationen über das gesamte Netzwerk und jeder der damit verbundenen Einheiten. Diese Informationen enthalten beispielsweise Netzwerk- und Knotenkonfigurationsdaten und Leistungsinformationen. Im Besonderen enthalten die Konfigurationsdaten die individuellen Portinformationen jedes Knoten im Netzwerk. Diese Portinformationen, Bündelungs- und Spanning-Tree-Informationen jedes Knoten werden vom SNMP-Manager 310 verwaltet.
Wie oben beschrieben sind die Knoten 1, 3 und 5 Switching-Einheiten (Switch 1, Switch 2, Switch 3). Jede dieser Switching-Einheiten 320, 330, 340 unterstützt eine Vielzahl an Kommunikationsports zur Netzwerkkommunikation mit anderen Knoten und/oder Endbenutzern. Im abgebildeten Beispiel ist jeder Port 1, 2, 3, 7, 8 und 22 des Switch 1 320 einzeln mit einem anderen Knoten oder Endbenutzer im Netzwerk verbunden. Demgegenüber werden zwei Portgruppierungen in einem Switch 1 320 zusammen gebündelt, um die Netzwerkkommunikation zwischen Switch 1 320 und Switch 3 340 zu betreiben. In der zweiten Bündel-Gruppierung 361 werden die Ports 13 und 14 miteinander gebündelt, um die Netzwerkkommunikation zwischen Switch 1 320 und Switch 5 330 auszuführen.
Im Besonderen eine Bündel-Gruppierung ist eine logische Sammlung physikalischer Ports, die als einzelne Einheit für Weiterleitungs- und Filterungszwecke eingesetzt wird. Im Allgemeinen spezifiziert IEEE 802.3ad eine Datenendeinrichtung (DTE) an einer logischen Datenendeinrichtungsverbindung (DTE-Verbindung), die aus N paral lelen Instanzen eines 802.3 Punkt-zu-Punkt-Verbindungssegments besteht. Die logische Verbindung unterstützt den bestehenden 802.3 MAC-Client. 802.3ad definiert die notwendigen Managementobjekte und -protokolle zur Unterstützung der Verbindungsaggregation, einschließlich der Identifizierung, der Hinzufügung und dem Löschen von Verbindungssegmenten in und von der logischen Verbindung. Grundsätzlich liegt der Zweck der Bündelung darin, die Verbindungsverfügbarkeit und die Bandbreite zwischen den DTEs durch Spezifizieren der nötigen Mechanismen zur parallelen Verbindungssegmentaggregation anzuheben.
Damit solche Netzwerkmanagmentfunktionen wie das oben erwähnte Konfigurations- und das oben genannte Leistungsmanagement bereitgestellt werden können, hat der Netzwerkmanager 310 herkömmlicherweise über das Wissen in Bezug auf alle Portdefinitionen und die Zuordnungen zu jedem Port, welcher zu jedem Knoten im Netzwerk gehört, zu verfügen. Daher verwaltet der SNMP-Manager 310 üblicherweise eine Datenbank, die alle Portinformationen jedes mit dem Netzwerksystem verbundenen Knoten zeigt. Der SNMP-Manager 310 verwaltet beispielsweise eine Datenbank mit folgenden Informationen: Anzahl der Knoten im Netzwerk; Identifikation (Portinformation) jedes Ports in jedem Knoten. In dem in 3 abgebildeten Netzwerksystem, umfasst beispielsweise der Netzwerkmanager Informationen, dass Switch 1 320 26 Ports mit den Ziffern 1 bis 26 enthält. Außerdem hat der Netzwerkmanager in einem herkömmlichen Netzwerksystem die Informationen zu verwalten, dass die Ports 3, 4, 7 des Switch 1 320 zusammen als erste Bündel-Gruppierung 360 gebündelt sind und die Ports 13 und 14 von Switch 1 320 als zweite Bündel-Gruppierung zusammen gebündelt sind.
Demgegenüber ist es, gemäß der vorliegenden Erfindung, nicht notwendig, dass der Netzwerkmanager 310 alle Portinformationen jedes Netzwerkknotens verwalten muss. Am wichtigsten ist hierbei, dass der Netzwerkmanager nur eine einzelne virtuelle Portinformation für eine gesamte Bündel-Gruppierung zu verwalten hat. Besonders mehrere Ports werden gemeinsam gruppiert, um einen virtuellen Port zu bilden, so dass der Netzwerkmanager sich auf diesen virtuellen Port zur Adressierung der gesamten Gruppierung an Bündel-Ports beziehen kann. Diese virtuelle Portrepräsen tation mehrerer Ports ist besonders wichtig für Port-Bündelungszwecke, da jeder dieser verschiedenen Ports ähnliche Netzwerkfunktionen (etwa die Kommunikation zwischen zwei einzelnen Ports) durchführt.
In der bevorzugten Ausführungsform umfasst Switch 1 320 26 physikalische Ports. Unter diesen 26 physikalischen Ports sind die Ports 1 bis 24 gewöhnliche 10 BASE-T/100 BASE-TX Kommunikationsports und die Ports 25, 26 sind Gigabit-Parts, die hauptsächlich zum Uplinking verwendet. Daher ist es möglich, dass jeder dieser 26 physikalischen Ports mit anderen Knoten oder Endbenutzern verbunden ist. In einigen Fällen können einige dieser Ports offen und unbenützt gelassen werden.
In 4 wird eine Port-Mapping-Tabelle 400 gemäß der vorliegenden Erfindung dargestellt. Wie in der Figur abgebildet, umfasst die Port-Mapping-Tabelle 400 drei Abschnitte: den ersten Abschnitt (PP 410), den zweiten Abschnitt (VP 420) und den dritten Abschnitt (LP 430). Jeder dieser drei Abschnitte stellt eine unterschiedliche Portzuordnung eines Switch 1 320 im Netzwerksystem, wie in 3 zu sehen, dar. Besonders der erste Abschnitt 410 stellt die physikalische Portzuordnung eines Switch 1 320 dar. Der zweite Abschnitt 420 stellt die virtuelle Portzuordnung von Switch 1 320 dar. Schließlich stellt der dritte Abschnitt 430 die logische Portzuordnung des Switchs 1 320 dar.
In der oben beschriebenen Port-Mapping-Tabelle, steht der erste Abschnitt 410 für alle physikalischen Ports, die im Switch 1 320 zur Verfügung stehen. Im vorliegenden Beispiel umfasst Switch 1 320 26 physikalische Ports, die als Port 1 bis 26 bezeichnet werden. Wie in 3 zu sehen, ist Port 1 von Switch 1 320 mit Port 23 von Knoten 2 verbunden. Port 22 von Switch 1 ist mit Port 13 von Knoten 7 verbunden (Knoten 7 ist in 3 nicht abgebildet). Wie im vorherigen Paragraphen erläutert, umfassen die beiden Bündel-Gruppierungen (also die erste Bündel-Gruppierung 360 und die zweite Bündel-Gruppierung 361) die Ports 3, 4 bzw. die Ports 13 und 14.
Der zweite Abschnitt 420 von 4 veranschaulicht das virtuelle Portkonzept gemäß der vorliegenden Erfindung. In diesem Beispiel sind für den zweiten Abschnitt 420 anstatt der lediglich 26 physikalischen Ports noch zusätzlich vier virtuelle Ports abgebildet: Port 27, Port 28, Port 29 und Port 30. Jeder dieser vier virtuellen Ports (also Port 27, Port 28, Port 29 und Port 30) können einzeln zur Darstellung einer Bündel-Gruppierung von Switch 1 320 verwendet werden. In der bevorzugten Ausführungsform kann einem der vier virtuellen Ports Ziffern (etwa 27 bis 30) zugeordnet werden, um die gesamte Bündel-Gruppierung darzustellen. Durch die Verwendung einer virtuellen Portnummer zur Repräsentation einer Bündel-Gruppierung von Ports, sieht der SNMP-Manager 310 die gesamte Gruppe an Verbindungen als einen einzelnen Port an, der eine aggregierte Kommunikationskapazität aufweist. Im abgebildeten Beispiel wird der virtuelle Port 27 vom SNMP-Manager 310 als einzelner, mit dem Knoten 3 verbundener Port angesehen, der eine kombinierte Netzwerkkapazität der Ports 3, 4 und 7 hat. Gemäß der vorliegenden Erfindung, sieht der SNMP-Manager 310 die gesamte Bündel-Gruppierung als einen einzigen Port an. Die Auflösung dieses virtuellen Ports in seine Portbestandteile der physikalischen Ports 3, 4 und 7 wird lediglich in der Switching-Einheit durchgeführt. Daher wird der gesamte Bündelungsvorgang für den Netzwerkmanager 310 transparent.
Es ist hierbei anzumerken, dass es von Sicht des Netzwerkmanagers 310 aus, keine Unterschiede zwischen physikalischen Ports und virtuellen Ports gibt, da der Netzwerkmanager 310 den virtuellen Port einfach als einen Port behandelt, der eine höhere Bandbreite aufweist. Die vom Netzwerkmanager 310 verwalteten Portkonfigurationsinformationen und -daten beziehen sich auf logische Portnummern anstatt auf physikalische Portnummern im herkömmlichen Systemen. Aufgrund der durch die Kombination mehrerer physikalischer Ports zu virtuellen Ports entstehenden Reduktion an Portnummern werden die vom Netzwerkmanager 310 ausgeführten Portmanagementfunktionen erheblich reduziert.
Der dritte Abschnitt 430 der in 4 abgebildeten Portzuordnungstabelle zeigt die gesamte, logische Portzuordnung für den Switch 1 320 gemäß der vorliegenden Erfindung. Wie zu sehen ist, umfassen die logischen Ports, wie in dieser Ausführungsform definiert, sowohl physikalische als auch virtuelle Ports. In diesem Beispiel sind die physikalischen Ports von 1 bis 26 durchnummeriert, während die virtuellen Ports mit den Ziffern 27 bis 30 gekennzeichnet sind. In diesem Beispiel wird der virtuelle Port 27 als erste Bündel-Gruppierung, die die physikalischen Ports 3, 4 und 7 umfasst, und der virtuelle Port 28 als zweite Bündel-Gruppierung definiert, welche die physikalischen Ports 13 und 14 enthält. In dieser bevorzugten Ausführungsform werden die Ports 3, 4 und 7, aufgrund der Zuordnung derselben als erste Bündel-Gruppierung, dann in der logischen Porttabelle versteckt. In ähnlicher Weise werden die Ports 13 und 14, aufgrund der Zuordnung des virtuellen Ports 28, in der logischen Porttabelle versteckt.
So wie der Figur entnommen werden kann, umfasst die gesamte, logische Portzuordnung von Switch 1 320 die Ports 1–2, 5–6, 8–12, 15–28, worin die Ports 1–2, 5–6, 8–12, 15–26 den physikalischen Ports und die Ports 27–28 den logischen Ports entsprechen. Mit anderen Worten, Ports 1–2, 5–6, 8–12, 15–26 von Switch 1 320 sind die nach der Bündelung übrigbleibenden, physikalischen Ports. Port 27 ist ein virtueller Port, der die erste Bündel-Gruppierung der physikalischen Ports 3, 4 und 7 darstellt. Port 28 ist ein weiterer virtueller Port, der die physikalischen Ports 13 und 14 darstellt.
In diesem Beispiel umfasst die Portzuordnung von Switch 1 320, so wie sie vom Netzwerkmanager 310 gesehen wird, lediglich 23 logische Ports: 1–2, 5–6, 8–12, 15–28. im Vergleich zu den 26 physikalischen Ports, wie sie im ersten Abschnitt der Tabelle gezeigt werden, ist die Anzahl der Ports aufgrund der Zuordnung der beiden virtuellen Ports gemäß der vorliegenden Erfindung um drei reduziert. Durch Kombination mehrerer physikalischer Ports in einem virtuellen Port ist der Netzwerkmanager 310 weniger überlastet, was die Verwaltung der Konfigurationsdaten anbelangt. Außerdem ist weniger Kontrolle des Netzwerkdatenverkehrs zwischen dem Netzwerkmanager und dem Knoten nötig, da es nicht nötig ist, die Anzahl der Bündel-Ports in der Gruppierung zu kontrollieren.
In einer bevorzugten Ausführungsform gemäß der vorliegenden Erfindung wird eine Switching-Einheit 320 einen unternehmensspezifischen Trap an den Netzwerkmanager 310 senden, um diesem zu verstehen zu geben, dass die Switching-Einheit 320 einige Veränderungen im Status eines virtuellen Ports in der Switching-Einheit 320 erfasst. Diese Veränderungen umfassen unter anderem Statusinformationen über einen der Ports und Hinzufügungen oder Löschungen eines oder mehrerer physikalischer Ports von einem der virtuellen Ports (etwa Port 27 und Port 28).
In 5 wird eine Tabelle 510 zur Veranschaulichung der virtuellen Portzuordnung zu dem in den 3 und 4 abgebildeten Beispiel dargestellt. In der bevorzugten Ausführungsform wird diese Tabelle 510 vom Switch verwaltet, der die virtuelle Portfunktion unterstützt. Die Tabellenumwandlung mithilfe der virtuellen Porttabelle wird im Switch durchgeführt, so dass die Verwaltung der Portkonfigurationsdaten im Netzwerkmanager weniger wird. In dieser bevorzugten Ausführungsform ist, wie abgebildet, die Switching-Einheit 1 320 dazu in der Lage, bis zu 4 virtuelle Ports zu überwachen. Die Anzahl an 4 virtuellen Ports wurde jedoch lediglich aus Veranschaulichungszwecken ausgewählt. Andere Anzahlen an virtuellen Ports können in ähnlicher Weise implementiert werden. In diesem Beispiel ist der virtuelle Port 27 als Port zur Darstellung der ersten Bündel-Gruppierung, umfassend die physikalischen Ports 3, 4 und 7 der Switching-Einheit 1 320, in Verwendung. Der virtuelle Port 28 ist als Port zur Darstellung der Bündel-Gruppierung, umfassend die physikalischen Ports 13 und 14 von Switchting-Einheit 1 320, zugeteilt. In diesem Beispiel werden den virtuellen Ports 29 und 30 keine physikalischen Ports vom Benutzer zugeordnet.
In 6 ist eine virtuelle Porttabelle 600 einer anderen bevorzugten Ausführungsform gemäß der vorliegenden Erfindung abgebildet. Diese Tabelle 600 ist ähnlich der in Fig. dargestellten Tabelle 500. Der Unterschied liegt in der zusätzlichen, dritten Spalte. Diese dritte Spalte von 6 veranschaulicht ein weiteres Merkmal der vorliegenden Erfindung und zwar, dass die vorliegende Erfindung auch mit gestapelten Switching-Systemen umgehen kann. Besonders ein gestapeltes Switching-System ist eine Gruppe individueller Switches, die miteinander als eine gestapelte Switching-Einheit verbunden sind. In einem Beispiel gemäß der vorliegenden Erfindung wird ein neues Switching-System mit der gleichzeitig anhängigen Patentanmeldung mit dem Titel „Intelligent Stacked Switching System" vom gleichen Erfinder Tomoyuki Sugiha ra, eingereicht am 24. Juni 1999 offenbart, welche hierin unter Verweis in ihrer Gesamtheit aufgenommen wird.
In der virtuellen Portzuordnungstabelle, wie in 6 zu sehen, umfasst die Tabelle eine zusätzliche „gestapelte ID-Spalte", die die IDs der gestapelten Einheiten entsprechend der physikalischen, zu bündelnden Ports. In einem ersten Eintrag ist beispielsweise die gesamte virtuelle Portinformation des virtuellen Ports 27 zu sehen. In diesem Beispiel wird dem virtuellen Port 27 die erste Bündel-Gruppierung zugeteilt. Gemäß dieser Tabelle umfasst der virtuelle Port 27 die physikalischen Ports 3, 4 und 7 einer ersten gestapelten Einheit (also S1).
In ähnlicher Weise steht der zweite Eintrag der Tabelle für alle virtuellen Portinformationen des virtuellen Ports 28. In diesem Beispiel wird dem virtuellen Port 28 die zweite Bündel-Gruppierung zugeordnet. Die zweite Bündel-Gruppierung umfasst physikalische Portelemente 13 und 14 der ersten gestapelten Einheit (also S1).
Es ist hierbei anzumerken, dass die physikalischen Portelemente jedes virtuellen Ports sich nicht in derselben gestapelten Switchting-Einheit befinden müssen. Mit anderen Worten, in verschiedenen, gestapelten Switching-Einheiten befindliche Portelemente können in einem virtuellen Port gruppiert werden. In einem nicht abgebildeten Beispiel kann der virtuelle Port 27 einer gestapelten Switching-Einheit 1 physikalische Ports 1, 5 einer ersten gestapelten Switching-Einheit und Ports 8, 14 einer zweiten gestapelten Switching-Einheit umfassen. In diesem Fall werden die Informationen über die Portelemente in jedem virtuellen Port, neben den in 6 abgebildeten Portnummern, noch die gestapelten Einheitennummern umfassen. So kann beispielsweise der virtuelle Port 27 der gestapelten Switching-Einheit 1 die folgenden Informationen enthalten: 0101, 0105, 0208, 0214 (worin die ersten beiden Zahlen sich auf die gestapelte Einheitennummer und die letzten beiden Zahlen sich auf die physikalischen Portnummern, etwa in einem „uupp-Format", beziehen). Damit dieses Design implementiert werden kann, wird eine anspruchsvollere Stapelkontrolleinheit benötigt, um sowohl die IDs der gestaplten Einheit und die physikalischen Portnummern zu interpretieren.
7 ist ein Flussdiagramm, welches die Abläufe an der Knoten-Seite zeigt, die Anfragen vom Netzwerkmanager abwickelt. Schritt 710 stellt den Beginn dieser Vorgänge dar. In Schritt 720 wird eine SNMP-Anfrage vom Knoten empfangen. In Schritt 730 wird die Bestimmung durchgeführt, um festzustellen, ob die SNMP-Anfrage eine virtuelle Portanfrage oder eine physikalische Portanfrage ist. Diese Bestimmung kann im Agenten durch Vergleichen der angefragten Portnummer mit einer Portzuordnungstabelle, wie in den 5 oder 6 dargestellt, durchgeführt werden. Wenn das Portziel uupp anzeigt, dass ein virtueller Port angefragt wird, wird die entsprechende Umwandlung gemäß der Portzuordnungstabelle durchgeführt, so dass die angefragte Information von den entsprechenden physikalischen Ports in Schritt 740 abgerufen wird. Die angefragten Informationen werden dann in Schritt 760 zum SNMP-Netzwerkmanager zurückgebracht. Wenn das uupp anzeigt, dass ein physikalischer Port angefragt wird, wird hingegen in Schritt 750 auf den entsprechenden physikalischen Port zugegriffen. Die angefragten Informationen werden dann in Schritt 770 zum SNMP-Netzwerkmanager zurückgebracht. Nachdem die angefragten Informationen wieder beim SNMP-Netzwerkmanager angelangt sind, enden diese Abläufe mit Schritt 780.
In 8 ist ein Blockdiagramm einer bevorzugten Ausführungsform jedes Switchs gemäß der vorliegenden Erfindung abgebildet.
Wie in der Figur zu sehen, umfasst jede Switching-Einheit 800 gemäß der vorliegenden Erfindung eine Switching-Matrix 810 mit acht Busports 811a, b, c, d e, f, g, h: In der abgebildeten, bevorzugten Ausführungsform sind drei der acht Busports Ethernetports 811a, b, c und zwei der acht Busports sind Gigabit-Uplink-Ports 811d, e. Die verbleibenden drei Busports 811f, g, h sind für die Stapelverbindungen zwischen den Switching-Einheiten vorgesehen. In der bevorzugten Ausführungsform unterstützt jeder der drei Ethernetports 811a, b, c acht Ethernetports, welche 10 Base-T/100 Base-TX Ethernetports sind. Jeder umfasst acht schnelle MII-Internetports und ist mit zwei Quadmagnetvorrichtungen verbunden. Diese Quadmagnetvorrichtungen werden zum Isolieren der Internetports von den RJ45-Steckern verwendet. Außerdem wird jede dieser Ethernetport-Kontrollvorrichtungen beim Speichern der Datenmana gementinformationen, wie etwa Adressenverweisdaten und Eingabe-/Ausgabe-Pufferdaten, von zwei getrennten Speicherports unterstützt. Einzelne Benutzer können mithilfe eines dieser 24 Ethernetports mit der Switching-Einheit verbunden werden. Es ist hierbei anzumerken, dass die vorliegende Erfindung entweder in Halb-Duplex- oder in Voll-Duplex-Verbindungen verwendet werden kann. Weiters wird, so wie in der bevorzugten Ausführungsform zu sehen, jeder der beiden Gigabit-Uplink-Ports 811d, e beim Speichern der Adressenverweisdaten und des Pufferdatenpakets von drei Speichermodulen unterstützt.
Wie oben erwähnt, sind die drei verbleibenden Ports 811f, g, h der Switching-Matrix 810 ausschließlich für Stapelzwecke vorgesehen. Durch Verbinden eines oder mehrerer dieser drei Ports 811f, g, h mit den Stapelports einer oder mehrerer anderer Switching-Einheiten entsteht ein gestapeltes Switching-System.
Gemäß der vorliegenden Erfindung werden die drei Sätze an 10 BASE-T/100 BASE-TX Ports, wie in der Figur abgebildet, als Ports 1 bis 24 beziffert. Ports 25 und 26 sind zwei Gigabitports, die für Uplink-Zwecke eingesetzt werden. Daher können in der bevorzugten Ausführungsform jegliche Portkombination, die aus den Ports 1 bis 26 ausgewählt werden, als virtuelle Ports 27, 28, 29 oder 30 angesehen werden.
Es ist hierbei zu verstehen, dass, während die Erfindung im Vorangehenden in Bezug auf die bevorzugten, spezifischen Ausführungsformen beschrieben wurde, die Beschreibung und die Beispiele der Veranschaulichung dienen und den Schutzumfang der Erfindung, welcher in den beigefügten Patentansprüchen näher definiert ist, in keiner Weise einschränken.

Claims

Netzwerk-Switch, umfassend: eine Vielzahl an physikalischen Ports; und eine Port-Mapping-Tabelle (400), in der Folgendes spezifiziert ist: physikalische Eingangsports (410) und virtuelle Eingangsports (420), umfassend einen virtuellen Port, der einen Satz physikalischer Portgruppen definiert, dadurch gekennzeichnet, dass in der Port-Mapping-Tabelle Folgendes spezifiziert ist: logische Eingangsports (430), umfassend physikalische Eingangsports und einen virtuellen Eingangsport, wobei der virtuelle Eingangsport den Satz physikalischer Portgruppen definiert und die physikalischen Eingangsports die einzelnen physikalischen Ports, die nicht gruppiert sind, definiert.
Netzwerk-Switch nach Anspruch 1, worin der Netzwerk-Switch den virtuellen Port als Bündel-Gruppierung sieht, die eine logische Sammlung von physikalischen Ports umfasst, welche zu Weiterleitungszwecken als einzelne Einheit behandelt werden.
Netzwerk-Switch nach Anspruch 1, worin der Netzwerk-Switch den virtuellen Port als Bündel-Gruppierung sieht, die eine logische Sammlung von physikalischen Ports umfasst, welche zu Filterzwecken als einzelne Einheit behandelt werden.
Netzwerk-Switch nach Anspruch 1 in Kombination mit einem Netzwerk-Manager, wobei der Netzwerk-Manager nur virtuelle Portinformationen für den Satz physikalischer Portgruppen verwaltet.
Netzwerk-Switch nach Anspruch 4, worin der Netzwerk-Manager den genannten virtuellen Port als einzelnen Port mit aggregierter Kommunikationskapazität sieht, die der des Satzes physikalischer Portgruppen entspricht.
Netzwerk-Switch nach Anspruch 5, worin der Netzwerk-Switch den virtuellen Port als Antwort auf einen Befehl vom Netzwerk-Manager in seine physikalischen Portbestandteile auflöst.
Netzwerk-Switch nach Anspruch 1, worin in der Port-Mapping-Tabelle eine Identifizierung einer gestapelten Einheit spezifiziert ist, die dem virtuellen Port entspricht.
Verfahren zum Betrieb eines Netzwerk-Switches, umfassend: das Empfangen eines Befehls von einem Netzwerk-Manager; das Mapping des Befehls in eine Port-Mapping-Tabelle (400), in der Folgendes spezifiziert ist: physikalische Eingangsports (410) und virtuelle Eingangsports (420), umfassend einen virtuellen Port, der einen Satz physikalischer Portgruppen definiert, dadurch gekennzeichnet, dass in der Port-Mapping-Tabelle Folgendes spezifiziert ist: logische Eingangsports (430), umfassend physikalische Eingangsports und einen virtuellen Eingangsport, wobei der virtuelle Eingangsport den Satz physikalischer Portgruppen definiert und die physikalischen Eingangsports die einzelnen physikalischen Ports, die nicht gruppiert sind, definiert; und das Antworten auf den Befehl auf Basis des Mapping.
Verfahren nach Anspruch 8, worin das Mapping das Mapping des Befehls zum virtuellen Port und danach das Behandeln des virtuellen Ports als Bündel-Gruppierung umfasst, die eine logische Sammlung von physikalischen Ports umfasst, welche zu Weiterleitungszwecken als einzelne Einheit behandelt werden.
Verfahren nach Anspruch 8, worin das Mapping das Mapping des Befehls zum virtuellen Port und danach das Behandeln des virtuellen Ports als Bündel- Gruppierung umfasst, die eine logische Sammlung von physikalischen Ports umfasst, welche zu Filterzwecken als einzelne Einheit behandelt werden.
Verfahren nach Anspruch 8, worin das Mapping das Auflösen des virtuellen Ports in seine physikalischen Portbestandteile umfasst.
Verfahren nach Anspruch 8, worin das Mapping das Mapping des virtuellen Ports zu einer entsprechenden Identifizierung einer gestapelten Einheit umfasst.