DE69434330T2 - Übertragungsvorrichtgung und verfahren - Google Patents

Übertragungsvorrichtgung und verfahren Download PDF

Info

Publication number
DE69434330T2
DE69434330T2 DE69434330T DE69434330T DE69434330T2 DE 69434330 T2 DE69434330 T2 DE 69434330T2 DE 69434330 T DE69434330 T DE 69434330T DE 69434330 T DE69434330 T DE 69434330T DE 69434330 T2 DE69434330 T2 DE 69434330T2
Authority
DE
Germany
Prior art keywords
port
packet
packets
network
ports
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 - Lifetime
Application number
DE69434330T
Other languages
English (en)
Other versions
DE69434330D1 (de
Inventor
Manohar Murthy
F. John WAKERLY
I. Arthur LAURSEN
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.)
Ericsson AB
Original Assignee
Marconi Intellectual Property Ringfence Inc
Marconi Intellectual Property US Inc
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 Marconi Intellectual Property Ringfence Inc, Marconi Intellectual Property US Inc filed Critical Marconi Intellectual Property Ringfence Inc
Publication of DE69434330D1 publication Critical patent/DE69434330D1/de
Application granted granted Critical
Publication of DE69434330T2 publication Critical patent/DE69434330T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung betrifft paketorientierte Bridges und Router mit zahlreichen Ports und insbesondere das Überwachen des Paketverkehrs, der an den Bridges und Routern eintrifft oder intern erzeugt wird.
  • BESCHREIBUNG DES STANDS DER TECHNIK
  • Bridges und Router mit zahlreichen Ports erlauben die Verbindung von zwei oder mehr paketgestützten Netzen von möglicherweise unterschiedlichem Typ. In solchen Netzen wird die Information mit Hilfe von Paketen übermittelt, wobei jedes Paket Daten und geeignete Adressinformation enthält. Die Bridge oder der Router dienen dazu, Pakete zwischen Netzsegmenten zu übertragen (ein mit Weiterleiten bezeichneter Vorgang), wodurch an unterschiedliche Netzsegmente angeschlossene Stationen kommunizieren können. Ein Beispiel für ein paketorientiertes Netzprotokoll ist das durch den Ethernet-Standard IEEE 802.3 implementierte Protokoll.
  • Umfangreichere Netze kann man mit Hilfe zahlreicher Bridges, Router und Kombinationen daraus aufbauen. Der Umfang und die Topologie eines Multi-Bridge- oder Multi-Router-Netzes kann einigermaßen kompliziert sein. Selbst kleine Netze mit einer einzigen Bridge können ein komplexes Verhalten zeigen, das die Leistungsfähigkeit, Sicherheit und andere Aspekte des Netzbetriebs beeinflussen kann. Für die Untersuchung solcher Probleme und ihre Korrektur ist in der Regel ein Netzverwalter verantwortlich, der die Übertragungsvorgänge auf dem Netz untersuchen und die Netzparameter einstellen muss.
  • Das Überwachen von Paketnetzen kann mit Überwachungsvorrichtungen erfolgen, beispielsweise SnifferTM von Network General in Menlo Park, Kalifornien oder LANalyzerTM von Novell, Inc. in Provo, Utah. Diese Vorrichtungen werden mit dem Netzmedium verbunden, beispielsweise einem Koaxialkabel, und untersuchen jede Übertragung auf dem Netz unabhängig von der tatsächlichen Bestimmung der Pakete. In der Regel bieten Netzmonitore die Fähigkeit, die untersuchten Übertragungen zu filtern, so dass nur Pakete mit den Netzverwalter interessierenden Eigenschaften erfasst oder dargestellt werden. Normalerweise werden Hilfsmittel zum Sammeln von Statistiken bereitgestellt, beispielsweise für Fehlerraten, Verkehr zwischen Stationen oder Stationsgruppen usw. und über die Pakete selbst. Da große Datenmengen erfasst und analysiert werden müssen und die Filterungen sehr komplex sein können, sind Netzmonitore verglichen mit anderen Netzkomponenten wie Stationen oder Bridges teuer.
  • Eine ernsthafte Einschränkung bei herkömmlichen Netzmonitoren besteht darin, dass der Monitor physikalisch mit dem zu überwachenden Netzabschnitt verbunden sein muss. In einer Multiport-Bridge, bei der mehrere Netzabschnitte über eine Bridge verbunden sind, ist es zu jedem Zeitpunkt nur möglich, einen der angeschlossenen Netzabschnitte zu untersuchen, da die Bridge die physikalischen Medien der Netzabschnitte voneinander isoliert. Eine weitere Beschränkung besteht darin, dass der Netzmonitor nur schwer zwischen Paketen unterscheiden kann, die aus dem angeschlossenen Netzabschnitt stammen, und Paketen, die aus anderen Netzabschnitten stammen, die an die Bridge angeschlossen sind und an den überwachten Netzabschnitt weitergeleitet werden, und zwar insbesondere dann, wenn die Pakete durch Fehler oder Sabotage falsche Adressen aufweisen. Ein Router ersetzt zudem die Quelladresse des Pakets durch die Routeradresse. Dies erschwrt es dem Netzmonitor zusätzlich, festzustellen, woher das Paket stammt. Insbesondere kann es für den Monitor beispielsweise schwierig oder unmöglich sein, alle Pakete abzutrennen, die aus einem ausgewählten Netzabschnitt stammen.
  • Ein herkömmlicher Ansatz zum Beseitigen der Beschränkung, dass der Monitor nur an einen Netzabschnitt angeschlossen ist, ist der Distributed SnifferTM von Network General. Jeder Sniffer ist ein Netzmonitor, der mit einem Verarbeitungselement verbunden ist, das über das Netz kontrolliert werden kann. Sind mehrere Netzabschnitte zu überwachen, die mit einer Bridge verbunden sind, so muss man mit jedem physikalischen Netzabschnitt einen Distributed Sniffer verbinden. Den Betrieb eines derartigen Distributed Sniffers kann man über das Netz von einer mit dem Netz verbundenen Station aus kontrollieren, und zwar mit Hilfe eines Protokolls auf höherer Ebene, beispielsweise TELNET. Mit diesem Ansatz kann eine Station, die sich an irgendeinem beliebigen angeschlossenen Netzabschnitt befindet, die Ergebnisse einsehen, die von allen Distributed Sniffers gewonnen werden. Der offenkundige Nachteil dieses Ansatzes besteht in den Kosten der zahlreichen Sniffer. Ein weiterer Schwachpunkt ist die beschränkte Fähigkeit, Information zu korrelieren, die von verschiedenen Sniffers gesammelt wurde. Im Einzelnen kann es vorkommen, dass ein Sniffer, der ein Paket erkennt, womöglich nicht in der Lage ist, das Netzsegment zu ermitteln, aus dem das Paket stammt, und zwar auch dann nicht, wenn dieser Netzabschnitt mit einem anderen Sniffer verbunden ist, der das Paket erfasst hat, weil es sein kann, dass die beiden Sniffer womöglich nicht feststellen können, ob es sich bei dem von ihnen erfassten Paket um das gleiche Paket oder um zwei unterschiedliche Pakete handelt.
  • Zudem muss jeder Distributed Sniffer einen Teil der Bandbreite des überwachten Netzes dazu verwenden, Information an die Überwachungsstation zu senden. Dadurch wird die Leistungsfähigkeit des überwachten Netzes beeinträchtigt.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Gemäß einem ersten Aspekt der Erfindung wird eine Vorrichtung zum Ermöglichen von Übertragungen zwischen Einheiten bereitgestellt, die mit verschiedenen Netzwerksegmenten verbunden sind, wobei die Vorrichtung folgendes aufweist:
    eine Anzahl an Anschlüssen zur Verbindung mit den Netzwerksegmenten und mit einem oder mehreren Überwachungssystemen; und
    erste Mittel zum Übertragen von Informationspaketen an einen oder mehrere der Anschlüsse, wobei jedes Informationspaket Übermittlungsinformation aufweist, die beim Bestimmen des Bestimmungsortes des Pakets zu verwenden ist;
    wobei die ersten Mittel Mittel zum Übertragen jedes der einen oder mehreren Pakete (a) zu einem oder mehreren Anschlüssen, die aus dem Paketbestimmungsort bestimmt werden, wenn der Bestimmungsort eine von der Vorrichtung verschiedene Einheit umfasst; und, zusätzlich, (b) zu einem oder mehreren Überwachungsanschlüssen umfassen.
  • Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Überwachen eines Netzwerks bereitgestellt, aufweisend eine Vorrichtung, welche eine Anzahl an Netzwerksegmenten miteinander verbindet, von denen zumindest eines einen Netzwerkmonitor umfasst, wobei das Verfahren aufweist:
    • (a) Gewinnen von Übertragungsinformation aus jedem Paket, das von der Vorrichtung empfangen oder erzeugt wurde, welche Übertragungsinformation beim Bestimmen des Paketbestimmungsortes zu verwenden ist;
    • (b) wenn ein Paketbestimmungsort eine Station umfasst, die von der Vorrichtung verschieden ist, Übertragen des Pakets durch die Vorrichtung zu einem oder mehreren der Netzwerksegmente, um das Paket an den Paketbestimmungsort zu übermitteln;
    • (c) wenn ein Paket an einen Netzwerkmonitor zu übermitteln ist, das Paket durch die Vorrichtung auf ein Netzwerksegment übertragen wird, das den Netzwerkmonitor enthält.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Man versteht die genannten Aufgaben, Aspekte und Vorteile der Erfindung und weitere Aufgaben, Aspekte und Vorteile anhand der folgenden ausführlichen Beschreibung der bevorzugten Ausführungsform der Erfindung zusammen mit den beiliegenden Zeichnungen besser.
  • Es zeigt:
  • 1 eine beispielhafte Multiport-Bridge mit sechs angeschlossenen Netzabschnitten;
  • 2 das Format eines Pakets gemäß dem Ethernet-Standard;
  • 3 zwei Formate von Paketbestimmungsadressen;
  • 4 eine Bridging-Tabelle, die zu dem Beispielsystem gehört;
  • 5 die Auswertung einer Custom Filtering Rule;
  • 6 ein Blockdiagramm der beispielhaften Bridge;
  • 7 die Datenstrukturen des gemeinsamen Speichers, die zum Paketempfang und zur Paketübertragung gehören;
  • 8 das Format eines Paketkennzeichners;
  • 9 das Format der XMASK;
  • 10A und 10B den Empfang eines Pakets bzw. die Übertragung eines Pakets;
  • 11 ein Zustandsdiagramm, das die Statusabfolge des Paketkennzeichners erläutert;
  • 12 die Weiterleit-Tabelle für die beispielhafte Bridge;
  • 13 die Broadcast/Multicast-Tabelle für die beispielhafte Bridge;
  • 14 die Management-Tabelle für die beispielhafte Bridge;
  • 15 einen Bridging-Cache;
  • 16 ein Flussdiagramm des Weiterleitalgorithmus;
  • 17A und 17B die Weiterleit-Tabelle und die Broadcast/Multicast-Tabelle jeweils nach einer Abwandlung, die das Überwachen eingehender Pakete unterstützt;
  • 18A und 18B die Weiterleit-Tabelle und die Broadcast/Multicast-Tabelle jeweils nach einer Abwandlung, die das Überwachen weitergeleiteter Pakete unterstützt;
  • 19 die Management-Tabelle nach der Abwandlung, die das Überwachen erzeugter Pakete unterstützt; und
  • 20A und 20B die Weiterleit-Tabelle und die Broadcast/Multicast-Tabelle jeweils nach einer Abwandlung, die das Überwachen von Port-Paaren unterstützt.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Der Zweck der im Weiteren beschriebenen Bridge besteht darin, mehrere paketgestützte Segmente eines Netzes miteinander zu verbinden, so dass eine wirksame Kommunikation zwischen Stationen in jedem Netzabschnitt und ebenso zwischen Stationen möglich ist, die sich in verschiedenen Netzabschnitten befinden, die mit der Bridge verbunden sind. Es ist auch für Stationen auf Netzabschnitten, die nicht mit einer gemeinsamen Bridge verbunden sind, möglich zu kommunizieren, vorausgesetzt dass zwischen den Stationen wenigstens ein Weg von Segment zu Segment vorhanden ist.
  • Als Beispiel ist hier eine Bridge angegeben. Die Arbeitsweise ist jedoch bei Routern ähnlich, und die Erweiterungen für Router sind Fachleuten geläufig.
  • In einigen Ausführungsformen werden auf Netzabschnitten, die mit der Bridge verbunden sind, paketorientierte Kommunikationsprotokolle verwendet, die entweder auf Ethernet oder FDDI beruhen. Es sind auch andere paketorientierte Protokolle möglich. Die Einzelheiten von Ethernet- und FDDI-Protokollen sind bekannt und in Standards dokumentiert, insbesondere im IEEE Standard 802.3 für Ethernet und im ANSI Standard X3T9.5 für FDDI. Der folgende Überblick über die Paketkommunikation soll dazu dienen, einen Begriffsapparat für die weitere Darstellung der bevorzugten Ausführungsform aufzubauen. Dabei wird das Ethernet-Schema als Beispiel verwendet.
  • 1 zeigt ein Beispiel einer Bridge, die die Fähigkeit zur Portüberwachung aufweist. In diesem Beispiel liefert die Bridge 1 Verbindungsdienste für sechs angeschlossene Netzabschnitte 2.0 bis 2.5 über die Ports 3.0 bis 3.5, die mit 0 bis 5 durchnumeriert sind. Die Einzelheit 2.0 zeigt eine übliche Ethernet-Anordnung, die auf der "10Base5-Technik" oder der "10Base2-Technik" beruht, bei der die angeschlossenen Stationen 4 über ein Koaxialkabel 5 geeigneter Bauart angeschlossen sind. Ein derartiges Kabel ist mit einem Abschluss 6 elektrisch abgeschlossen. Eine weitere mögliche Anordnung, in der die "10BaseT-Technik" verwendet wird, ist für den Port 5 dargestellt. In diesem Fall ist jede Station über ein verdrilltes Paar Drähte 7 an einen eigenen Anschluss 8 am Port angeschlossen.
  • Jeder dargestellten Station ist ein eindeutiger Name zugewiesen, der aus einem Buchstaben gefolgt von einer Portnummer besteht. Diese Namensgebung ist willkürlich und dient nur dazu, die Beschreibung zu vereinfachen und die Arbeitsweise der Erfindung zu erläutern.
  • 1 zeigt auch den Anschluss einer Überwachungsvorrichtung 9 an den Überwachungsport 10. Im beispielhaften System und in der folgenden Beschreibung ist der Port 4 der Überwachungsport. In einigen Ausführungsformen ist die Überwachungsvorrichtung 9 die einzige Station auf dem Netzabschnitt, die mit dem Überwachungsport 10 verbunden ist. An die Bridge kann auch ein Aufsichtsterminal 12 angeschlossen sein, das den Zugriff auf die Bridge im Allgemeinen und die Portüberwachungsmerkmale im Besonderen erlaubt. Im beispielhaften System erfolgt der Anschluss über einen Aufsichtsport 11, der unabhängig von den anderen dargestellten Ports ist und nur dem Zugriff auf die Bridge dient. Durch ein geeignetes Protokoll ist es möglich, an jeder der angeschlossenen Stationen 4 einen Zugriff auf die Funktionen des Aufsichtsterminals zu bieten. Im beispielhaften System kann jeder beliebige Port ein überwachter Port sein, und es können auch alle Ports 3 überwacht werden.
  • Zum Vereinfachen der Beschreibung wird vorausgesetzt, dass an allen Ports (mit Ausnahme des Aufsichtsports 11) in der beispielhaften Bridge 1 das Ethernet-Protokoll verwendet wird. Unter diesem Protokoll kommunizieren Stationen 4 durch das Senden und Empfangen von Informationspaketen. 2 zeigt den logischen Aufbau eines einzelnen Pakets 13. Das Paket selbst besteht aus einer veränderlichen Anzahl von Oktetten bzw. 8-Bit-Dateneinheiten, und es ist wie dargestellt in Felder mit einer Anzahl vollständiger Oktette unterteilt. Im Folgenden werden die Bezeichnung und der Zweck der Felder beschrieben.
  • Preamble 14, bezeichnet ein eindeutiges Bitmuster, das zum Synchronisieren des Paketempfangs verwendet wird.
  • Bestimmungsadresse 15; bezeichnet ein Bitmuster, das die Adresse der Station oder der Stationen 4 festlegt, die das Paket empfangen sollen.
  • Quelladresse 16; bezeichnet ein eindeutiges Bitmuster, das die Adresse der Station 4 angibt, die die Übertragung angestoßen hat.
  • Data 17; bezeichnet die Daten, die von der Quellstation 4 zur Bestimmungsstation 4 zu übertragen sind.
  • FCS 18; bezeichnet eine Prüfsequenz für das Paket (mit Ausnahme des Preamble-Felds), das von den Zielstationen dazu verwendet wird, die Gültigkeit des empfangenen Pakets zu beurteilen.
  • In 3 ist der Aufbau der Bestimmungsadresse 15 erläutert, die auch als DA (Destination Address) bezeichnet wird. Zur Erläuterung sei angegeben, dass zwei For men der DA verwendet werden können. Eine Form ist die Non-Broadcast-Form 19, und die andere Form ist die Broadcast-Form 20. Eine DA 15 besteht aus 6 Oktetten oder 48 Bit. Eines dieser Bits, das Broadcast/Multicast-Flag 21 dient dazu, zwischen den beiden DA-Formen zu unterscheiden. Hat das Broadcast/Multicast-Flag den Wert null, so besteht die Bestimmungsadresse aus zwei Komponenten, nämlich einem Vendor-Code 22 und einem Device-Code 23. Diese Codes werden von einer zentralen Behörde zugewiesen, wodurch jede Station eine eindeutige Stationsadresse hat. Die Stationsadresse ist physikalisch mit der Station verbunden und dient zu ihrer Kennzeichnung, und zwar unabhängig davon, wo sie sich im Netz befindet, d. h. entweder in einem Netz mit einem einzigen Segment oder in einem größeren Netz, das aus mehreren Abschnitten aufgebaut ist.
  • Ist das Broadcast/Multicast-Flag 21 auf den Wert Eins gesetzt, so wird das DA-Feld 15 unterschiedlich interpretiert. Sind die restlichen Bits der DA (Broadcast/Multicast-Adresse 24) alle Einsen, so bezeichnet die Bestimmungsadresse alle Stationen im Netz einschließlich der Stationen an anderen Segmenten, die mit der Bridge 1 verbunden sind. Ist das Broadcast/Multicast-Flag 21 auf den Wert Eins gesetzt, und die restlichen Bits der DA 15 haben nicht alle den Wert Eins, so wird ein Multicast-Paket bezeichnet. Die verbleibenden Bits geben nun eine Untermenge an Stationen im Netz an, die Bestimmungsorte sind. Diese Stationen können an irgendein beliebiges Segment oder an verschiedene Segmente angeschlossen sein. Das Kennzeichnungsprotokoll ist von den jeweiligen Anwendungen abhängig und wird hier nicht weiter beschrieben.
  • Das Quelladressen-Feld 16, das auch als SA (Source Address) bezeichnet wird, kennzeichnet die Quellstation, die ein Adressierungsschema verwendet, wie es bei der DA 15 erklärt ist. Im SA-Feld wird das Broadcast/Multicast-Flag nicht verwendet. Damit besteht das Quelladressen-Feld stets nur aus dem Vendor-Code 22 und der Device Number 23 und kennzeichnet damit unverwechselbar die Station, von der das Paket stammt.
  • Innerhalb eines einzigen physikalischen Netzsegments 2, beispielsweise dem Segment, das aus den Stationen A0, B0 und C0 in 1 aufgebaut ist, ist die Wirkungsweise des Paketprotokolls einfach. Die Stationen senden Pakete 13, bei denen die SA 16 ihre eindeutige Stationsadresse enthält und bei denen die DA 15 die Adresse der Station enthält, mit der kommuniziert werden soll. Wahlweise können die Stationen eine DA 15 so ausbilden, dass sie ein Broadcast-Adressenformat 20 aufweist. Damit wird das Paket 13 von allen Stationen empfangen, die an das Segment angeschlossen sind.
  • Jede an das Segment angeschlossene Station beobachtet alle Übertragungen auf diesem Segment und prüft die DA eines jeden Pakets. Ein Paket ist für die Adresse einer Station gedacht, wenn eine Non-Broadcast-DA exakt mit der Stationsadresse übereinstimmt oder eine Broadcast/Multicast-DA empfangen wird. Im Fall einer Broadcast/Multicast-DA 20 empfängt die Station das Paket, falls die Broadcast/Multicast-Adresse 24 gemäß den besonderen Regeln der Anwendung übereinstimmt.
  • ARBEITSWEISE DER BRIDGE
  • Der Zweck der Bridge 1 besteht darin, Stationen auf unterschiedlichen angeschlossenen Netzabschnitten die Kommunikation untereinander zu ermöglichen. Mehrere Vorteile sprechen dafür, eine Bridge zu verwenden und nicht einfach elektronisch ein großes gemeinsames Netz zu bilden. Setzt man eine Bridge ein, so können die Netzabschnitte physikalisch kleiner sein (d. h., jeder Abschnitt kann weniger Stationen enthalten), und man kann die elektrischen Grenzwerte eines jeden Segments leichter einhalten. Unter dem Gesichtspunkt der Leistungsfähigkeit ist die Übertragungsfähigkeit eines Segments beschränkt, und damit ist die Geschwindigkeit beschränkt, mit der Nachrichten zwischen Stationen auf einem Segment übertragen werden können. Unterteilt man ein großes Segment in eine Anzahl kleinerer Segmente, die durch eine Bridge verbunden sind, so wird im Mittel die Gesamtauslastung eines angeschlossenen Segments geringer. Im dargestellten Beispiel (1) können etwa Stationen am Port 2, beispielsweise A2 und C2, gleichzeitig mit der vollen Segmentgeschwindigkeit kommunizieren, und Stationen an einem anderen Port, beispielsweise dem Port 3, können ebenfalls die volle Kapazität ihres angeschlossenen Segments nutzen.
  • Die Bridge 1 kommt ins Spiel, falls eine Station auf einem Segment, etwa A0, mit einer Station (oder Stationen) auf einem anderen Segment kommunizieren muss, beispielsweise C3. In diesem Fall muss die Bridge Pakete für die beiden kommunizierenden Stationen zwischen den entsprechenden Ports übermitteln, in diesem Fall zwischen Port 0 und Port 3. Da eine Station portabel sein kann und sich damit aus einem Segment in ein anderes Segment bewegen kann, muss die Bridge einen adaptiven Algorithmus implementieren. Ein derartiger herkömmlicher Algorithmus ist im US-Patent 4,597,078, mit dem Titel "Bridge Circuit for Interconnecting Networks" beschrieben. Gemäß diesem Algorithmus konstruierte Bridges werden als "lernende Bridges" bezeichnet. Im Folgenden wird die Arbeitsweise von lernenden Bridges kurz beschrieben, da dies der bevor zugte Arbeitsmodus einer Bridge ist, auf den die Erfindung angewendet wird.
  • Der Schlüssel zum Betrieb einer lernenden Bridge besteht darin, dass jede Station 4 eine eindeutige Adresse hat, und dass jedes Paket 13 stets die eindeutige Adresse der Ursprungsstation im SA-Feld 16 enthält. Bei Betrieb untersucht die Bridge alle Paketübertragungen an ihren angeschlossenen Ports 3 und wertet sie aus. Mit Hilfe von Information, die aus diesem Vorgang abgeleitet wird, baut die Bridge eine Bridging-Tabelle 25 auf, siehe 4. Jeder Bridging-Tabelleneintrag 26 besteht aus einem Stationsadressen-Feld 27 und einer zugehörigen Portnummer 28. Für jede Station, die der Bridge derzeit bekannt ist, existiert ein Bridging-Tabelleneintrag 26. Im Bridging-Tabelleneintrag 26 bezeichnet die Portnummer 28 den Port, an den die zugehörige Station angeschlossen ist. 4 zeigt eine Bridging-Tabelle entsprechend der beispielhaften Bridge und Netzanordnung in 1. Im dargestellten Fall sind die Adressen aller an die Bridge angeschlossenen Stationen in der Bridging-Tabelle 25 vorhanden. Da Netze einen dynamischen Charakter haben, sind nicht notwendig alle Stationsadressen-Portnummern-Paare jederzeit im Bridging-Tabelle 25 vorhanden.
  • Bei einer lernenden Bridge wird die Bridging-Tabelle 25 in der Bridge dynamisch aufgebaut, siehe die folgende Beschreibung. Zunächst sei das Merkmal der Portüberwachung noch nicht betrachtet. Die Bridging-Tabelle dient zum Weiterleiten empfangener Pakete an ihre Bestimmungsorte wie folgt.
    • 1. Ist im Bestimmungsadressen-Feld 15 eines empfangenen Pakets das Broadcast/Multicast-Flag 21 auf Eins gesetzt, so wird das Paket mit Ausnahme des Ports, an dem es empfangen wurde, an alle angeschlossenen Ports weitergeleitet.
    • 2. Ist im Bestimmungsadressen-Feld 15 eines empfangenen Pakets das Broadcast/Multicast-Flag 21 auf null gesetzt, so enthält das DA-Feld 15 eine eindeutige Stationsadresse. Mit Hilfe des DA-Felds 15 wird auf die Bridging-Tabelle 25 zugegriffen. Enthält die Bridging-Tabelle 25 einen Eintrag mit einem Stationsadressen-Feld 27, das mit dem DA-Feld 15 des empfangenen Pakets übereinstimmt, so wird das zugehörige Portnummer-Feld 28 geholt. Es sind nun zwei Fälle zu unterscheiden. Ist die geholte Portnummer 28 identisch mit der Portnummer, auf der das Paket empfangen wurde, so ist das Paket für den Netzabschnitt bestimmt, in dem sich auch die Sendestation befindet. In diesem Fall erfolgt keine Handlung, da die Übertragung im richtigen Segment bereits erfolgt ist. Im anderen Fall, in dem die geholte Portnummer 28 nicht mit der Portnummer übereinstimmt, von der das Paket empfangen wurde, wird das Paket zu der Portnummer weitergeleitet, die durch den Eintrag im geholten Bridging-Tabelleneintrag 26 bezeichnet ist.
    • 3. Stimmt beim unter 2. oben beschriebenen Vorgang das Bestimmungsadressen-Feld 15 des empfangenen Pakets mit keinem Stationsadressen-Feld 27 irgendeines Bridging-Tabelleneintrags 26 überein, so wird das Paket mit Ausnahme des Ports, an dem es empfangen wurde, an alle angeschlossenen Ports weitergeleitet. Dadurch wird sichergestellt, dass die Bestimmungsstation, falls sie an irgendeinem mit der Bridge verbundenen Segment vorhanden ist, das Paket empfängt.
  • Bei einer lernenden Bridge wird die Bridging-Tabelle 25 während des Paketempfangs dynamisch aufgebaut. Die Bridge untersucht das Quelladressen-Feld 16 eines jeden Pakets, das an jedem Port empfangen wird. Stimmt die Stationsadresse im Quelladressen-Feld 16 eines empfangenen Pakets mit dem Stationsadressen-Feld 27 eines Eintrags in der Bridging-Tabelle 25 überein, und stimmt die Portnummer, auf der das Paket empfangen wurde, mit dem Portnummer-Feld 28 dieses Eintrags überein, so wird die Bridging-Tabelle nicht verändert. Stimmt die SA 16 eines empfangenen Pakets mit einem Stationsadressen-Feld 27 eines Bridging-Tabelleneintrags 26 überein, jedoch nicht die Portnummer, an der das Paket empfangen wurde, mit dem zugehörigen Portnummer-Feld 28 für diesen Eintrag, so wird das Portnummer-Feld 28 mit der Portnummer überschrieben, auf der das Paket empfangen wurde. Es können noch weitere Vorgänge erforderlich sein, beispielsweise das Entleeren des Bridging-Caches 83. Stimmt jedoch die Quelladresse 16 des empfangenen Pakets nicht mit dem Stationsadressen-Feld 27 irgendeines Bridging-Tabelleneintrags 26 überein, so wird der Bridging-Tabelle 25 ein neuer Eintrag zugefügt. Dieser Eintrag besteht aus einem Stationsadressen-Feld 27, das die SA des empfangenen Pakets enthält, und einem zugehörigen Portnummer-Feld 28, das die Portnummer des Ports enthält, an dem das Paket empfangen wurde.
  • Bein Initialisieren der Bridge ist die Bridging-Tabelle 25 leer. Beim Untersuchen der Pakete auf den angeschlossenen Netzabschnitten werden Bridging-Tabelleneinträge 26 gebildet und der Bridging-Tabelle 25 zugefügt. Durch diesen Vorgang "lernt" die Bridge die Zusammenhänge zwischen den angeschlossenen Stationen und dem Port, an den sie angeschlossen sind. Um sich daran anzupassen, dass sich Netze verändern und Stationen zugefügt, entfernt oder von einem Segment in ein anderes Segment bewegt werden können, enthält die lernende Bridge einen Alterungsalgorithmus, der periodisch Bridging-Tabelleneinträge 26 entfernt, die während einer bestimmten Zeitspanne nicht verwendet wurden.
  • Ein Netzverwalter hat zudem die Möglichkeit, "Dauereinträge" in der Bridging-Tabelle zu konfigurieren. Damit braucht die Bridge diese Einträge nicht mehr zu lernen, und man kann sie auch dazu verwenden, die Netzsicherheit zu verbessern. Man kann die Bridge beispielsweise so konfigurieren, dass sie keine Pakete an irgendeine DA auf einem bestimmten Port weiterleitet, bis die Bridging-Tabelle einen Dauereintrag für diese DA enthält, der mit diesem Port übereinstimmt.
  • Eine weitere Komplikation im Betrieb einer Bridge besteht darin, dass die Bridge 1 in der Regel ein Teil eines umfangreichen Netzes ist, das aus zahlreichen Bridges und ihren zugeschalteten Segmenten besteht. Die Topologie des Netzes könnte Schleifen enthalten, bei denen sich mehr als ein Netzpfad zwischen zwei Bridges befindet. Die kann unbeabsichtigt oder beabsichtigt sein, wenn beispielsweise Redundanz im Netz erforderlich ist. Im Fall von Broadcast-Paketen oder wenn ein empfangenes Paket ein DA-Feld 15 hat, für das kein übereinstimmender Bridging-Tabelleneintrag 26 vorhanden ist, wird das Paket an alle Ports weitergeleitet. Sind Schleifen im Netz vorhanden, so kann dieser Weiterleitvorgang zu einer unbegrenzten Duplizierung und Ausbreitung eines Pakets führen. Um dies zu verhindern implementiert die lernende Bridge einen Algorithmus, der als "Spanning-Tree-Algorithmus" bezeichnet wird und die Ports begrenzt, an die Pakete des angesprochenen Typs weitergeleitet werden können. Dieser Algorithmus ist im IEEE Standard 802.1d definiert. Der Ablauf des Spanning-Tree-Algorithmus erfordert, dass die Bridge 1 eine interne Landkarte des Netzes bildet, an das sie angeschlossen ist. Dies erfolgt durch eine periodische Kommunikation mit anderen Bridges, die an die Segmente angeschlossen sind, die mit der Bridge 1 verbunden sind. Damit können Fälle auftreten, in denen die Bridge selbst Pakete für die Übertragung erzeugt, obwohl sie keinerlei besondere Pakete erhalten hat, die ihr befehlen, dies zu tun.
  • ANGEPASSTE FILTERUNG VON PAKETEN
  • Im beschriebenen Weiterleitvorgang trifft die Bridge Weiterleitentscheidungen lediglich abhängig vom DA-Feld 15 eines Pakets 13. Einen sinnvolleren Bridgebetrieb kann man erhalten, indem man die Weiterleitentscheidung auch von bestimmten Inhalten eines jeden Pakets abhängig macht. Gemäß diesen zusätzlichen Regeln kann das Weiterleiten gewisser Pakete unterdrückt werden (d. h., sie werden ausgefiltert), falls Bedingungen abhängig vom Paketinhalt zutreffen. Diese Bedingungen werden hier als Anpas sungs-Filter-Regeln (CFRs, CFR = Custom Filtering Rule) bezeichnet und durch den Gebrauch von Schablonen 29 implementiert, siehe 5.
  • Eine Schablone 29 besteht aus drei Komponenten, nämlich einem Versatz 30, einer 32-Bit-Maske 31 und einem 32-Bit-Komparator 32. Die Schablone definiert eine Prüfung, der ein Paket gemäß dem folgenden Algorithmus unterworfen werden soll. Zuerst wird der Versatz 30 dazu verwendet, den Beginn eines Felds W aus vier Oktetten 33 des Pakets zu erkennen. Der Versatz 30 wird in Oktetten ab dem Beginn des Bestimmungsfelds 15 ausgedrückt. Das erkannte Feld W, 30, wird nun Bit für Bit logisch mit der 32-Bit-Maske 31 UND-verknüpft. Das 32-Bit-Ergebnis 34 wird nun bei 35.1 logisch (Bit für Bit) mit dem Komparator 32 der Schablone verglichen. Man erhält ein logisches Ergebnis 35, das wahr oder falsch ist. Ist das Ergebnis 35 einer Schablonenauswertung wahr (d. h., das Ergebnis 34 stimmt mit dem Komparator 32 überein), so wird das Paket nicht weitergeleitet (d. h., es wird ausgefiltert). In der bevorzugten Ausführungsform wird der Filteralgorithmus durch Programme umgesetzt. Eine strenge Hardware-Implementierung oder eine gemischte Hardware-Softwate-Implementierung sind jedoch ebenfalls möglich.
  • Es ist daran gedacht, dass die Bridge 1 zahlreiche Schablonen bereitstellt, und dass Einrichtungen vorhanden sind, die es erlauben, eine Vielzahl von Schablonen an einem gegebenen Paket auszuwerten und die Ergebnisse einer solchen Auswertung 35 gemäß den bekannten Regeln der Booleschen Logik zu kombinieren. Damit kann die Filterung eines Pakets auf ziemlich komplizierten Bedingungen beruhen. Diese komplizierten Bedingungen werden im weiteren als "Anpassungs-Filter-Regeln" oder "CFRs" bezeichnet. Durch die geeignete Konstruktion von Schablonen und CFRs ist es möglich, ganz besondere Arten von Paketen auszufiltern. Beispielsweise könnte man alle Apple-Talk-Pakete mit einer Apple Talk-Quelladresse von 15 (Hex) dadurch ausfiltern, dass man einen Versatz von 16 (dezimal), eine Maske FF000000 (Hex) und einen Komparator von 15000000 (Hex) setzt. Man könnte dies dazu verwenden, eine bestimmte Station daran zu hindern, über das Apple Talk-Protokoll mit ausgewählten anderen Stationen zu kommunizieren.
  • Um den Nutzen von CFRs weiter zu steigern, ist daran gedacht, dass die Bridge die Zuordnung von CFRs zu dem Port erlaubt, an dem das Paket empfangen wird, zur SA 16 des empfangenen Pakets, der DA 15 des empfangenen Pakets und zum Bestimmungsport (bzw. den Ports), an die das Paket weitergeleitet wird. Verschiedene Kombinationen derartiger Zuordnungen sind ebenfalls möglich.
  • In der beispielhaften Bridgeimplementierung werden Schablonen 29 und Regeln über das Aufsichtszugangsterminal 12 definiert.
  • ZUSAMMENFASSUNG DER BRIDGEOPERATIONEN
  • Der obigen Beschreibung kann man entnehmen, dass die Bridge diverse Situationen handhaben kann, die die verschiedenen Zustände widerspiegeln, unter denen Pakete erzeugt und weitergeleitet werden. Zusammenfassend gehören dazu:
    • 1. Das Weiterleiten eines Einzelpakets von einem Port an einen anderen Port.
    • 2. Das Weiterleiten von Multicast- und Broadcast-Paketen an mehr als einen Port und möglicherweise alle Ports.
    • 3. Das Weiterleiten von Verwaltungspaketen, die innerhalb der Bridge erzeugt werden.
    • 4. Das Unterdrücken der Paketweiterleitung an bestimmte Ports beispielsweise durch den Einsatz des Spanning-Tree-Algorithmus aus Sicherheitsgründen.
    • 5. Das Filtern (Unterdrücken) der Paketweiterleitung beispielsweise durch die Auswertung von Anpassungs-Filter-Regeln (CFRs).
  • ROUTERBETRIEB
  • Die obige Beschreibung bezieht sich explizit auf Bridges. Die Erfindung ist jedoch auch auf das Routing anwendbar. Das Paket-Routing umfasst den Empfang eines Pakets an einem Port (d. h. aus einem angeschlossenen Netz) und die Übertragung des Pakets an einen anderen Port, und zwar abhängig von der Information, die im Data-Feld 17 enthalten ist. Bei der DA eines weiterzuleitenden Pakets handelt es sich entweder um die Stationsadresse des Routers oder eine Broadcast/Multicast-Adresse. Die SA 16 ist die Stationsadresse der Station oder des Routers, vom der bzw. dem das Paket stammt. Der Router kann physikalisch und/oder logisch in eine Bridge integriert sein. (Vorrichtungen, die die Funktionalität von Routern und Bridges verbinden, heißen "Brouters".) Kommt ein Paket an einem Router an, so wird das Data-Feld 17 zerlegt und untersucht. Für jede weiterzuleitende Paketart sind besondere Protokolle definiert, die durch die Unterfelder im Data-Feld 17 des Pakets bezeichnet sind. Eines der Unterfelder kann eine Netzadresse sein, bei der es sich um eine logische Adresse anstelle einer physikalischen Adresse handelt, die die endgültige Bestimmung des Pakets angibt. Zum Weiterleiten des Pakets verändert der Router die DA 15 so, dass sie auf die nächste Verbindung oder den nächsten Sprung auf dem Weg zeigt und setzt seine eigene Adresse anstelle der SA 16 ein. Es können auch Unterfelder des Data-Felds 17 modifiziert werden. Insbesondere ist in der Regel ein "Sprungzähler" vorhanden, der die größtmögliche Anzahl von Sprüngen angibt, die ein Paket ausführen kann, bevor es als ungültig oder fehlgeleitet betrachtet wird. Weitere Unterfelder von Data 17 können Steueroptionen, Länge, Typ, Seriennummer, Priorität usw. enthalten. Diese Unterfelder dienen dazu, den Weg genauer zu beschreiben.
  • Die CFRs können auf mit dem Router behandelte Pakete so angewendet werden, wie sie auf mit der Bridge bearbeitete Pakete angewendet werden. Es trifft auch zu, dass einige mit dem Router bearbeitete Pakete vom Router einbehalten werden oder möglicherweise intern für die Übertragung zu anderen Routern erzeugt werden. Damit ist zu sehen, dass mit dem Router bearbeitete Pakete Situation bei der Paketweiterleitung erzeugen können, die den Situationen gleichen, die bei Bridges auftreten, siehe die obige Beschreibung im Punkt "Zusammenfassung der Bridgeoperationen".
  • HARDWAREIMPLEMENTIERUNG DER BRIDGE
  • In 6 ist die Hardware der beispielhaften Bridge 1 in Form eines Blockdiagramms erläutert. Das bisher beschriebene Beispiel für die Bridge wird beibehalten; damit sind nur sechs Portcontroller 37.0 bis 37.5 dargestellt. Fachleuten auf dem Gebiet des Hardware-Systementwurfs ist geläufig, dass der Entwurf leicht auf zusätzliche Ports 3 zu erweitern ist. Jeder Port beruht auf dem ILACC 32-Bit Ethernet Controller, der bei Advanced Micro Devices (AMD) in Sunnyvale, Kalifornien, erhältlich ist. Diese Controller besitzen die Fähigkeit, Pakete direkt an einen gemeinsamen Speicher 39 zu senden oder von dort zu empfangen, und zwar über eine Schnittstelle 38 des gemeinsamen Speichers, ohne dass die Haupt-CPU 42 oder die I/O-CPU 43 der Bridge direkt daran beteiligt ist. Diese Abläufe werden im Weiteren erklärt.
  • Die Bridge enthält zwei Prozessoren, deren Hauptaufgabe darin besteht, im gemeinsamen Speicher abgelegte Pakete zu untersuchen und die Tabellen und Datenstrukturen des gemeinsamen Speichers geeignet zu verändern, damit das Weiterleiten erfolgen kann. Die Haupt-CPU 42 beruht auf dem MIPS R3001 Prozessor mit 25 MHz von Integrated Device Technology (IDT) in Santa Clara, Kalifornien. Zum Chip gehört ein Cache-Speicher mit 256 KByte, in dem häufig angesprochene Abschnitte des Echtzeit-Paketweiterleitungscodes und der Kontrolldaten gehalten werden. Ein angeschlossener Programmspeicher 41 enthält bis zu 8 MByte an zusätzlichem Speicherplatz für weniger zeitkritische Programme und Daten, die z. B. zu den Zugriffsfunktionen der Aufsicht gehören. Eine serielle Schnittstelle 45 ist mit der Haupt-CPU verbunden und stellt den Supervisory-Access-Port 11 dar. Mit der Haupt-CPU 42 ist auch eine Floppy Disk 44 verbunden, die eine bequeme Möglichkeit zum Aktualisieren der Systemprogramme und zum Sichern der Konfigurationsinformation darstellt, beispielsweise der Einträge in die permanente Bridging-Tabelle und der CFRs, die beim Systemhochlauf gelesen werden.
  • Ein zweiter Prozessor, die I/O-CPU 43, beruht auf einem MIPS R3051 Prozessor mit 33 MHz, der ebenfalls bei IDT erhältlich ist. Die Hauptaufgabe dieses Prozessors besteht darin, das Senden und Empfangen von Paketen 13 zu beaufsichtigen, Paketpuffer im gemeinsamen Speicher 39 zu verwalten, Paketempfangsfehler zu bearbeiten und ähnlichen Aktivitäten. Dieser Prozessor unterstützt einen Cache 46 auf dem Chip, der den gesamten I/O-CPU-Code enthält, und ist damit besonders leistungsfähig.
  • Die Pakete, die von den Ports empfangen werden, und die im System zur Unterstützung der Verwaltungsfunktionen erzeugten Pakete werden im gemeinsamen Speicher 39 abgelegt, der aus einer SRAM-Anordnung mit 1,5 MByte besteht. Die Struktur eines üblichen gemeinsamen Speichers 39 ist in der Patentschrift "Methods and Apparatus for Data Transfer Between Source and Destination Modules", laufende Nummer 07/304,053, nun US-Patent 5,237,670, beschrieben. Die konfigurierte Anordnung hat eine zusammengefasste Bandbreite von 400 MByte/Sekunde. Der gemeinsame Speicher ist für die Portcontroller 37, die Haupt-CPU 42 und die I/O-CPU 43 über die Schnittstelle 38 des gemeinsamen Speichers zugänglich. Jedem Portcontroller 37 sind 32 KByte gemeinsamer Speicher für empfangene Pakete und 64 KByte gemeinsamer Speicher für gesendete Pakete zugewiesen.
  • FORMAT DES PAKETKENNZEICHNERS
  • Das Weiterleiten eines Pakets ist der Vorgang, bei dem ein empfangenes Paket (oder möglicherweise ein intern erzeugtes Paket) an einen oder mehrere Ports 3 übertragen wird. Die Weiterleitungsentscheidungen erfolgen hauptsächlich in der Haupt-CPU. Die Portcontroller 37 und die I/O-CPU 43 nehmen jedoch an den Weiterleitmechanismen teil.
  • 7 zeigt die Datenstrukturen des gemeinsamen Speichers 39, die am Empfang, Weiterleiten und Übertragen von Paketen beteiligt sind. Teile dieser Datenstrukturen können von den Portcontrollern, der Haupt-CPU und der I/O-CPU manipuliert wer den. Zu verarbeitende Pakete werden in Paketpuffern 47 gespeichert, die im Paketpuffer-Pool 48 gehalten werden. Jeder Paketpuffer 47 ist ein zusammenhängender Bereich im gemeinsamen Speicher, der dazu ausreicht, ein durchschnittlich großes Ethernet-Paket (mit bis zu 256 Oktetten) zu halten. Müssen längere Pakete bearbeitet werden, so werden mehrere Paketpuffer 47 verwendet.
  • Da selbst ein Paket mit der kleinstmöglichen Größe eine beträchtliche Anzahl Bytes (64) enthält, ist es erwünscht, die Pakete indirekt zu handhaben. Dies erfolgt mit Hilfe eines Paketkennzeichners 49, siehe 7 und 8. Ein Paketkennzeichner 49 ist eine Datenstruktur im gemeinsamen Speicher und weist fünf Komponenten auf. Der Paketzeiger 50 zeigt auf die tatsächlichen Paketdaten, die in einem Paketpuffer 47 im Paketpuffer-Pool 48 gehalten werden. Beim Verarbeiten von Paketen kann der Paketkennzeichner 49 kopiert oder verschoben werden. ("Verschieben" bedeutet Kopieren und Löschen des Originals.) Das Paket selbst wird dabei nicht verschoben oder kopiert, sondern es wird nur über den Paketzeiger 50 angesprochen. Mit diesem indirekten Ansatz spart man beträchtlichen Platz im gemeinsamen Speicher und Zugriffsbandbreite ein.
  • Die Flags 51 im Paketkennzeichner bezeichnen verschiedene Zustände bezüglich des Paketstatus, beispielsweise das Vorhandensein von Fehlern und deren Ursachen. Die Paketverarbeitung wird durch das Statusfeld 52 des Paketkennzeichners angewiesen. Einzelheiten zur Paketverarbeitung und Veränderungen des Statusfelds 52 werden im Weiteren beschrieben. Das Längenfeld 53 gibt die Länge des Pakets innerhalb des Paketpuffers 47 an.
  • Im Paketkennzeichner 49 befindet sich der XMASK-Zeiger 54, der auf eine XMASK 55 zeigt, die den Bestimmungsport bzw. die Bestimmungsports (falls vorhanden) angibt, an die das Paket zu übertragen ist. Während des Weiterleitens füllt die Haupt-CPU 42 das XMASK-Zeiger-Feld abhängig vom Weiterleitalgorithmus und von Bedingungen aus, die zu dem Zeitpunkt gelten, zu dem ein Paket verarbeitet wird. Das Abarbeiten des Weiterleitalgorithmus erzeugt eine Datenmenge, die als XMASK 55 bezeichnet wird und in 9 dargestellt ist.
  • XMASK 55 ist einfach ein Bitvektor, in dem jedes Bit einen Port 3 bezeichnet, an den das Paket 13 zu übermitteln ist. Ein Bitwert "0" bedeutet "nicht an den jeweiligen Port übertragen". Ein Bitwert "1" bedeutet "an den jeweiligen Port übertragen". Sind mehrere Bits gesetzt, so wird das Paket an jeden bezeichneten Port übertragen. Sind keine Bits gesetzt, so wird das Paket an keinen Port übertragen (weitergeleitet). Für die Beschreibung und Erläuterung wird XMASK 55 binär dargestellt, wobei das am weitesten rechts stehende Bit das niedrigstwertige Bit ist und den Port 0 bezeichnet. Tabelle I zeigt einige Beispiele von XMASK-Werten für das Beispielsystem mit sechs Ports.
  • Figure 00170001
    Tabelle I: Beispiele für XMASK
  • Ein berechneter Wert für XMASK 55 bezüglich eines Pakets 13 wird im XMASK-Pool 57 gehalten; dies ist eine Datenstruktur im gemeinsamen Speicher 39. Innerhalb des Paketkennzeichners 49 zeigt das XMASK-Zeigerfeld 54 auf die berechnete XMASK 55 im XMASK-Pool 57. Dadurch ist es möglich, dass mehrere Paketkennzeichner 49 auf den Wert für XMASK 55 zeigen. Es wird einfacher, das gleiche Paket 13 an mehre Ports zu übermitteln, wie dies in einer Broadcast/Multicast-Situation erforderlich ist oder dann, wenn die Portüberwachung freigegeben ist.
  • Zum Erklären der Erfindung ist die Form von XMASK 55 etwas vereinfacht worden. Für Fachleute sind gewisse Verbesserungen naheliegend. Bezeichnet XMASK 55 beispielsweise nur einen Bestimmungsport, so kann die Portnummer selbst direkt im XMASK-Zeiger 50 gehalten werden, falls ein Flag bereitgestellt wird, das das andere Format anzeigt. Dies kann auf bestimmten Hardwaresystemen wirksamer sein.
  • VERARBEITUNG DER PAKETE
  • Die Paketverarbeitung wird mit Hilfe eines Beispiels und anhand von 10A und 10B erklärt, die Veränderungen an der Datenstruktur des gemeinsamen Speichers im Verlauf der Paketverarbeitung erläutern. Verwendet wird auch 11, die die Folge der Verarbeitungsschritte darstellt. Während der Paketverarbeitung wird der tatsächliche Paketpuffer 47 nicht in den gemeinsamen Speicher 39 verschoben oder kopiert. Statt dessen wird der zu diesem Paketpuffer gehörende Paketkennzeichner 49 von einer Datenstruktur des gemeinsamen Speichers zur folgenden verschoben und möglicherweise kopiert und/oder verändert. Im Einzelnen wird das Statusfeld 52 des Paketkennzeichners 49 gemäß der in 11 angegebenen Sequenz verändert, wobei ein eingeschlossener Text, beispielsweise 64, 65, 66, 67, 68, 69 und 70 einen Status darstellt. 11 zeigt den normalen Ablauf der Statusverarbeitung, in dem keine Fehler auftreten.
  • In dem angegebenen Beispiel wird vorausgesetzt, dass ein Paket am Port 0 empfangen wird und an die Ports 2 und 4 gesendet wird. Anfänglich ist der Speicher wie in 10A dargestellt konfiguriert. Zu jedem Portcontroller gehört ein Receive Descriptor Ring (RDR) 72 und ein Transmit Descriptor Ring (TDR) 71, die im gemeinsamen Speicher 39 erzeugt werden. In 10A und 10B sind nur der RDR für den Port 0 und die TDRs für die Ports 2 und 4 erläutert. Der Receive Descriptor Ring und der Transmit Descriptor Ring (72 und 71) sind kreisförmige Datenstrukturen mit bekanntem Aufbau und einer festen Größe, die dafür entworfen sind, eine ganzzahlige Anzahl Paketkennzeichner 49 zu halten. Die Größe des Descriptorrings wird beim Entwurf gewählt und hängt von verschiedenen Systemparametern der jeweiligen Implementierung ab.
  • Anfänglich enthält der RDR 72 einen oder mehrere Paketkennzeichner 49 jeweils mit einem Statusfeld 52, das mit "Available for Reception" gekennzeichnet ist und angibt, dass die zugehörigen Paketpuffer dafür verfügbar sind, dass sie der Portcontroller 37 mit empfangenen Paketen füllt. Ein Paketkennzeichner im RDR wird dem nächsten zu füllenden Paket zugewiesen. Jeder Paketkennzeichner 49 mit dem Status "Available for Reception" im RDR zeigt auf einen leeren Paketpuffer 47 im Paketpuffer-Pool 48, der eine Datenstruktur ist, die im gemeinsamen Speicher gehalten wird. Im Statusdiagramm in 11 ist der Paketkennzeichner 49 im Status 64"Available for Reception". Kommt ein Paket am Port 0 an, so überträgt der Controller 37.0 des Ports 0 die empfangenen Daten an den Paketpuffer 47, auf den das Paket-Zeiger-Feld 50 des Paketkennzeichners 49 zeigt. In der bevorzugten Implementierung erfolgt dieser Vorgang gesteuert durch den Portcontroller 37, und zwar unabhängig von anderen Prozessen auf anderen Portcontrollern und von Prozessen auf der Haupt-CPU 42 und der I/O-CPU 43. Natürlich sind andere Ansätze zum Bereitstellen unabhängiger Prozesse möglich.
  • Hat der Controller des Ports 0 das empfangene Paket im Paketpuffer 47 abgelegt, aktualisiert er den Paketkennzeichner 49 durch das Zuführen des richtigen Längenfelds 53, wobei Flags 51 je nach Erfordernis gesetzt werden und der Status auf "Received" 65 gesetzt wird, siehe 11. An dieser Stelle greift der Portcontroller 0 auf den nächsten Paketkennzeichner 49 mit dem Status "Available for Reception" zu, um sich auf den Empfang eines neuen Pakets vorzubereiten.
  • Unabhängig vom Betrieb des Portcontrollers unterstützt die I/O-CPU 43 einen Prozess, der jeden Port-RDR 72 zyklisch abfragt und die Paketkennzeichner 49 überprüft. Wird ein Paketkennzeichner 49 gefunden, der sich im Status "Received" 65 befindet, so verarbeitet die I/O-CPU 43 das Paket, sucht nach Paketfehlern und aktualisiert die Empfangsstatistik (beispielsweise die Anzahl der an diesem Port empfangenen Pakete). Nach dem Abschluss dieses Vorgangs wird das Statusfeld 52 des Paketkennzeichners 49 als "Available for Forwarding" 66 gekennzeichnet.
  • Die Haupt-CPU 42, die unabhängig vom Portcontroller 37 und der I/O-CPU 43 arbeitet, fragt periodisch alle RDRs 72 ab, um festzustellen, ob irgendwelche Pakete in der Warteschlange weitergeleitet werden müssen. Abhängig von den Feldern SA 16 und DA 15 des Pakets 13 und der Portnummer des RDR 72, auf dem das Paket in der Warteschlange steht (RPORT), führt die Haupt-CPU den Forwarding-Algorithm (Weiterleitalgorithmus) gemäß 16 aus. Das Ergebnis dieses Vorgangs ist ein XMASK-Wert 55, der den Port oder die Ports bezeichnet (möglicherweise keinen), an die das Paket 13 weitergeleitet werden muss. Dieser XMASK-Wert 55 wird in einem verfügbaren Eintrag im XMASK-Pool 57 abgelegt, und der passende Zeiger auf den Eintrag wird in das XMASK-Zeiger-Feld 54 des Paketkennzeichners 49 eingetragen. Das Statusfeld 52 des Paketkennzeichners wird nun auf "Forwarded" 67 gesetzt.
  • Die I/O-CPU 43 fragt die RDRs 72 periodisch ab, ob irgendwelche Paketkennzeichner 49 den Status "Forwarded" 67 haben. Wird ein derartiger Paketkennzeichner 49 gefunden, wird er so wie es die gesetzten Bits im zugehörigen XMASK-Wert 55 angeben in jeden TDR 71 (falls vorhanden) kopiert. Das Statusfeld 52 eines jeden in den TDR 71 kopierten Paketkennzeichners 49 wird auf "Available for Transmission" 68 gesetzt. Jeder in einen TDR 71 kopierte Paketkennzeichner 49 enthält einen Paketzeiger 50, der auf das Paket im Paketpuffer-Pool 48 zeigt, und einen XMASK-Zeiger 54, der auf den XMASK-Wert 55 im XMASK-Pool 57 zeigt. Hat die I/O-CPU 43 einen Paketkennzeichner 49 auf die passenden TDRs 71 kopiert, so wird der Paketkennzeichner im RDR 72 als "Available for Reception" 64 markiert und mit einem leeren Paketpuffer 47 aus dem Paketpuffer-Pool 48 verbunden. 10B zeigt die Situation nach dem Weiterleiten des Beispielpakets an die TDRs für die Ports 2 und 4.
  • Die Übertragung der Pakete erfolgt unabhängig durch die Portcontroller 37. Jeder Portcontroller 37 durchsucht seinen zugehörigen TDR 71. Findet er einen Paketkennzeichner 49 mit einem als "Available for Transmission" 68 gekennzeichneten Statusfeld 52, so beginnt er mit dem Übertragen des Pakets 13 aus dem Paketpuffer 47 an seinen zugehörigen Port. Nach dem Abschluss der Übertragung wird das Statusfeld 52 mit "Transmitted" 69 gekennzeichnet. Wird ein Paket an zwei oder mehr Ports gesendet, so kann es zu unterschiedlichen Zeiten übertragen werden, da die Paketübertragung auf einem bestimmten Port vom Status des TDR abhängt, der zu diesem Port gehört, und vom Verkehr, der an diesem Port in der Warteschlange steht.
  • Das Säubern des TDR 71 erfolgt durch die I/O-CPU 43, die periodisch alle TDRs 71 durchsucht. Findet sie einen Paketkennzeichner 49 mit einem Statusfeld 52, das als "Transmitted" 69 gekennzeichnet ist, so setzt sie das Bit in der XMASK 55, das durch den XMASK-Zeiger 54 bezeichnet ist und zu dem überprüften Port gehört, zurück. Ist die XMASK 55 schließlich gelöscht, so gibt es keine ausstehenden Paketkennzeichner 49 mehr, die zum Paket 13 gehören. Damit ist der Paketpuffer 47 frei und kann für eine spätere erneute Verwendung mit einer Position in der Paketpuffer-Freiliste 56 verbunden werden. Der Paketkennzeichner 49 auf dem TDR 71 wird als "Free" 70 gekennzeichnet, wodurch er für eine erneute Verwendung verfügbar ist. In ähnlicher Weise wird die XMASK 55 für eine erneute Verwendung im XMASK-Pool 57 verfügbar.
  • Weitere Fragen der Paketverarbeitung, beispielsweise die Fehlerbehandlung und die Statistikerstellung, werden nicht ausführlich behandelt. Das geeignete Verfahren zum Behandeln derartiger Fragen hängt von der jeweiligen Implementierung ab und ist Fachleuten geläufig.
  • DAS WEITERLEITEN VON DATENSTRUKTUREN
  • Die Hauptverantwortung für das Weiterleiten von Paketen sitzt im Pragramm der Haupt-CPU. Zum Erläutern der Erfindung werden die Datenstrukturen und die Arbeitsweise des Weiterleitalgorithmus im Weiteren beschrieben. Dabei werden nur die Merkmale erklärt, die direkt mit der Portüberwachungseigenschaft zu tun haben. Zunächst wird die Beschreibung auf das normale Weiterleiten beschränkt (d. h. bei abgeschalteter Portüberwachung). Es wird sich zeigen, dass die vorgeschlagenen Datenstrukturen eine rasche Berechnung des XMASK-Werts 55 unterstützen, der zum Steuern des Paketweiterleitens verwendet wird. Nach der Darstellung des Normalfalls werden die Modifikationen an den Datenstrukturen erläutert, die man für die Portüberwachung benötigt. Diese Modifikationen werden sich auch als besonders wirksam für die Implementierung und Ausführung erweisen.
  • Das Weiterleiten eines Pakets 13 beruht auf mehreren Eingaben und erzeugt als Ausgabe einen XMASK-Wert 55. Erforderliche Eingaben für den Algorithmus sind DA 15, die Bestimmungsadresse des empfangenen Pakets, RPORT, die Portnummer auf der das Paket empfangen wurde, SA 16, die Quelladresse des empfangenen Pakets, RSTATE, der Status des Empfangsports (RPORT 85), NG, die Netzgruppen und die derzeit wirksamen CFRs.
  • RSTATE stellt den Status des Empfangsports dar. Es handelt sich dabei um einen portspezifischen Indikator (einer je Port), der angibt, ob Pakete, die an einem Port aus seinem angeschlossenen Segment ankommen, weitergeleitet werden sollen, und ob Pakete von anderen Ports oder die in der Bridge selbst erzeugten Pakete (Verwaltungspakete) an den Port weitergeleitet werden können. Bezogen auf den Empfang von Paketen verändert sich RSTATE für einen Port langsam und bleibt in der Regel über einen längeren Zeitraum statisch. RSTATE ändert sich beispielsweise während der Abarbeitung des Spanning-Tree-Algorithmus, wenn Ports freigegeben und gesperrt werden, um logische Schleifen zu verhindern.
  • Netzgruppen, mit NG bezeichnet, definieren, welche über die Bridge verbundenen Ports kommunizieren dürfen. Die NG-Werte werden von einem Netzverwalter mit Hilfe des Aufsichtsterminals 12 oder einer gleichwertigen netzgestützten Verbindung festgelegt. Wie bei RSTATE bleiben die NG-Werte bezogen auf die Übertragungszeit von Paketen über einen längeren Zeitraum statisch.
  • Da die CFRs (Custom Filtering Rules) die Paketübertragung abhängig vom Paketinhalt und möglicherweise abhängig vom Inhalt des Data-Felds 17 steuern, haben die CFRs, wenn sie festgelegt sind, eine dynamische Auswirkung auf die Paketweiterleitung. D. h., dass jedes an einem Port (RPORT 85) ankommende Paket mit der gleichen SA 16 und DA 15 unterschiedlich weitergeleitet werden kann. Die CFRs müssen für jedes Paket ausgewertet werden, das zwischen Ports und bestimmten Adressen (SA 16 und DA 15) weitergeleitet wird, für die derzeit CFRs definiert sind. In der folgenden Beschreibung wird zunächst davon ausgegangen, dass keine CFRs wirksam sind.
  • Bei Betrieb hängt die Weiterleitung von mehreren Datenstrukturen, der Bridging-Tabelle 25 (4), der Weiterleit-Tabelle 80 (12), der Broadcast/Multicast-Tabelle 81 (13), der Management-Tabelle 82 (14) und dem Bridging-Cache (15) ab. Der Aufbau der Bridging-Tabelle 25 ist bereits beschrieben worden.
  • 12 zeigt die Weiterleit-Tabelle 80. Diese Datenstruktur ist ein zweidimensionales Feld. Ein Index des Felds ist RPORT 85, d. h. die Nummer des Ports, an dem das weiterzuleitende Paket empfangen wurde. Der andere Index ist XPORT 86, d. h. die Nummer des Ports, an den das Paket abhängig vom Feld DA 15 zu senden ist. XPORT 86 wird durch den Zugriff auf die Bridging-Tabelle 25 mit DA 15 und das Holen des entsprechenden Portnummer-Felds 28 ermittelt. Die Einträge in die Weiterleit-Tabelle 80 sind XMASK-Werte 55. Sie stellen die momentane Port-zu-Port-Verbindung der Bridge abhängig von NG und RSTATE dar. Für das normale Weiterleiten (Portüberwachung nicht in Betrieb) ist XMASK 55 entweder null (alle Werte null) oder es gibt einen einzigen Port an. 12 zeigt ein Beispiel einer Weiterleit-Tabelle 80 für eine übliche Situation, in der alle Ports miteinander kommunizieren können. XMASK-Werte von null (alle Werte null) auf der Diagonale der Weiterleit-Tabelle zeigen an, dass das Paket nicht weitergeleitet werden soll, falls RPORT 85 und XPORT 86 gleich sind, da sich die Bestimmungsstation am gleichen Port befindet wie die Quellstation.
  • Im Beispiel für die Weiterleit-Tabelle 80 in 12 wird auch angenommen, dass der Port 4 logisch von allen anderen Ports isoliert ist. In den nachfolgenden Überwachungsbeispielen ist der Überwachungsport 10 der Port 4. In einigen Ausführungsformen ist der Überwachungsport 10 logisch isoliert, so dass nur besonders gekennzeichnete überwachte Pakete auf dem angeschlossenen Netzabschnitt erscheinen. Daher enthalten die "Zeile 4" 59 (d. h. RPORT = 4) und die "Spalte 4" 58 (d. h. XPORT = 4) XMASK-Werte 55 von null.
  • Die Broadcast/Multicast-Tabelle 81 ist in 13 erläutert. Zeigt ein empfangenes Paket eine Broadcast- oder Multicastadresse an (d h., ist das Broadcast/Multicast-Flag 21 gesetzt), so wird die Broadcast/Multicast-Tabelle 81 anstelle der Weiterfeit-Tabelle 80 zum Erzeugen von XMASK 55 verwendet. Die Broadcast/Multicast-Tabelle 81 ist ein eindimensionales Feld, das mit RPORT 85 indiziert ist. Jeder Feldeintrag stellt einen XMASK-Wert 55 dar. 13 zeigt eine Broadcast/Multicast-Tabelle 81, in der alle Ports miteinander kommunizieren dürfen, jedoch mit Ausnahme des Ports 4, der in diesem Beispiel der Überwachungsport ist. Damit hat jeder Eintrag eine 1 an jeder Bitposition in XMASK 55, jedoch mit Ausnahme des Bits 4 (dem Überwachungsport) und des Bits, das RPORT entspricht (dadurch wird ein Senden an den Ursprungsport verhindert).
  • Netzgruppen (NG) beeinflussen die Inhalte der Weiterleit-Tabelle 80 und der Broadcast/Multicast-Tabelle 81. In den Beispielen in 12 und 13 ist unterstellt, dass alle Ports miteinander kommunizieren dürfen. Hat ein Netzverwalter die Kommunikation durch das Definieren von Netzgruppen eingeschränkt, so werden einige der Einträge mit dem Wert "1" in 12 und 13 auf 0 gesetzt. Wird beispielsweise definiert, dass die Ports 0 und 1 zu einer Netzgruppe gehören, und dass die Ports 2, 3, 4, 5 zu einer anderen Netzgruppe gehören, so haben alle Einträge in der Weiterleit-Tabelle in den hervorgehobenen Bereichen 90, 92 in 12 den Wert 000000. In ähnlicher Weise sind die Bits in der Broadcast/Multicast-Tabelle in den hervorgehobenen Bereichen 94, 96 in 13 ebenfalls Nullen. Die nachfolgenden Beispiele zeigen keine Netzgruppen. Bei den später beschriebenen Portüberwachungsvorgängen wird jedoch die Möglichkeit in Betracht gezogen, dass Netzgruppen definiert sind.
  • Für in der Bridge oder dem Router erzeugte Pakete, die die Netzverwaltung und den Routerbetrieb betreffen, wird die Management-Tabelle 82 (14) verwendet. Diese Tabelle ist ein eindimensionales Feld, das mit MPORT 78 indiziert ist, d. h. der Portnummer, an die das verwaltungsbezogene Paket zu senden ist. 14 zeigt ein Beispiel für eine Management-Tabelle 82, in der jeder Port mit Ausnahme des Ports 4, dem Überwachungsport 10, für die Teilnahme an Verwaltungsfunktionen verfügbar ist.
  • Obgleich die Bridging-Tabelle 25 und die Weiterleit-Tabelle 80 dazu ausreichen, XMASK 55 zu berechnen, kann man die Leistung des Weiterleitvorgangs wesentlich verbessern, wenn man eine zusätzliche Datenstruktur einführt, die als Bridging-Cache 83 bezeichnet ist und für die bevorzugte Ausführungsform in 15 dargestellt ist. Dahinter steht die Idee, dass der Bridging-Cache 83 zahlreiche logische Einträge enthält, in denen bestimmte Werte für RPORT 85, SA 16 und DA 15 mit einer XMASK 55 verknüpft sind. Da sich diese Zuordnung langsam ändert, ist es in der Regel möglich, die normale Weiterleitberechnung zu umgehen den Wert für XMASK 55 direkt aus dem Bridging-Cache 83 zu holen. Weitere Faktoren wie NG und RSTATE ändern sich ebenfalls langsam und beeinträchtigen die Arbeit des Bridging-Caches 83 damit nicht über Gebühr.
  • Wird ein XMASK-Wert berechnet, so werden die in der Berechnung verwendeten Werte für RPORT 85, SA 16 und DA 15 zu einem Eintrag zusammengefasst und im Bridging-Cache 83 abgelegt. Trifft ein neues Paket zur Weiterleitung ein, so wird auf den Bridging-Cache 83 zugegriffen, um festzustellen, ob die zum Paket gehörenden Werte von RPORT 85, SA 16 und DA 15 mit den Werten für RPORT 85, SA 16 und DA 15 eines Eintrags im Bridging-Cache übereinstimmen. Findet man eine Übereinstimmung, so kann man den XMASK-Wert 55 aus dem Bridging-Cache 83 verwenden. Andernfalls muss der vollständige Weiterleitalgorithmus ausgeführt werden.
  • In der bevorzugten Ausführungsform ist der Bridging-Cache in getrennte Sub-Caches unterteilt, die jeweils einem RPORT 85 zugeordnet sind. Da die Höchstanzahl der Empfangsports relativ gering ist, stellt dies ein sehr wirksames Verfahren dar, einen Teil der Suche im fache zu handhaben. Auf dem Bridging-Cache wird mit dem Tripel <RPORT, SA, DA> zugegriffen. Abhängig von RPORT 85 wird der geeignete Sub-Cache 77 gewählt, der zum Empfangsport gehört. Nun wird aus dem 96-Bit-Wert, der aus SA 16 mit der angehängten DA 15 besteht, mit bekannten Hash-Verfahren ein Zeiger erzeugt, der auf einen Eintrag 79 im Bridging-Cache im gewählten Sub-Cache 77 zeigt. Die eingegebenen Werte für SA und DA werden nun mit den Werten für SA und DA im gewählten Eintrag 79 des Bridging-Caches verglichen. Stellt man eine Übereinstimmung fest, so wird der XMASK-Wert 55 für diesen Eintrag geholt. Liegt keine Übereinstimmung vor, so wird der folgende Eintrag 79 im Bridging-Cache in gleicher Weise untersucht. Dieser Vorgang wird fortgeführt, bis man eine Übereinstimmung gefunden hat oder eine Höchstzahl von Versuchen erreicht ist. Fachleuten sind andere Ansätze zum Zugreifen auf den Bridging-Cache 83 geläufig, mit denen man das gleiche Ergebnis erzielt.
  • Der Gebrauch des Bridging-Caches 83 macht es überflüssig, die empfangene SA 16 in der Bridging-Tabelle 25 zu bestätigen, nach XPORT 86 in der Bridging-Tabelle 25 zu suchen und die Weiterleit-Tabelle 80 zum Holen von XMASK 55 zu verwenden. RPORT 85 und SA 16 werden beide beim Cachezugriff verwendet, so dass man Veränderungen der Portzuordnung von SA erkennen und sich daran anpassen kann. Dies wird im Folgenden beschrieben.
  • Die Einträge 79 im Bridging-Cache müssen für ungültig erklärt oder entfernt werden, falls sie das Resultat des Bridging-Algorithmus nicht mehr widerspiegeln. Stellt sich beispielsweise der Zusammenhang zwischen SA 16 und RPORT 85 als ungültig heraus, so müssen alle Einträge 79 im Bridging-Cache mit dem entsprechenden Wert von SA 16 im RPORT-Sub-Cache 77 gelöscht werden (siehe den "Entferne-Schritt" in 16). Ereignisse auf Systemebene können ebenfalls ein Entleeren des Caches verursachen. Beispielsweise kann irgendeine Änderung an den CFRs, den Netzgruppen NG oder dem Spanning-Tree-Status dazu führen, dass die Einträge 79 im Bridging-Cache ungültig werden. In diesen Fällen müssen die fehlerhaften Einträge 79 im Bridging-Cache entfernt werden. Falls dies günstiger ist, müssen alle Cache-Einträge für ungültig erklärt werden. Vom Aufsichtszugangsterminal 12 (oder seinem Netzäquivalent) ausgegebene Befehle können auch ein Leeren des Caches verursachen.
  • In einigen Ausführungsformen wird jeglicher Port bzw. jegliche Adresse, auf die eine CFR angewendet wird, aus dem Bridging-Cache 83 ausgeschlossen. In anderen Ausführungsformen enthalten die Einträge 79 im Bridging-Cache zusätzliche Felder, die das Vorhandensein einer CFR sowie ihren Anwendungspunkt (DA, SA, RPORT) anzeigen. In gewissen Implementierungen kann dies auch erlauben, rascher auf CFR-bezogene Information zuzugreifen, und zwar abhängig davon, wie die gewählten Datenstrukturen verwirklicht sind.
  • Fachleuten ist auch bekannt, dass Alternativen zu den Datenstrukturen des Bridging-Caches 83 möglich sind, wobei die leistungssteigernden Merkmale aber erhalten bleiben. Zudem ist es möglich, die beschriebenen Datenstrukturen, etwa die Bridging-Tabelle 25 und den Bridging-Cache 83 mit getrennten CPUs und Speichern zu verknüpfen, wenngleich sie in der bevorzugten Ausführungsform durch Code und Daten in der Haupt-CPU 42 und im Programmspeicher 41 implementiert werden.
  • WEITERLEITALGORITHMUS
  • Pakete, für die ein Weiterleiten erforderlich ist, können an der Bridge ankommende Pakete von ihren Ports 3 sein oder intern erzeugte Verwaltungspakete. Der im Weiteren beschriebene Weiterleitalgorithmus arbeitet in beiden Fällen und ist auch unabhängig davon, ob die Portüberwachung freigegeben oder gesperrt ist. 16 enthält ein Flussdiagramm, das die Erläuterung des Ansatzes unterstützt. Es sei vorausgesetzt, dass der Weiterleitalgorithmus mit den Parametern DA 15, SA 16, RPORT 85 von eingehenden Paketen begonnen wird und mit MPORT 78 bei intern erzeugten Paketen. Das Abarbeiten des Weiterleitalgorithmus erfolgt in der bevorzugten Ausführungsform auf der Haupt-CPU 42.
  • Man kann sehen, siehe 16, dass eine erste Entscheidung bezüglich der Paketquelle bei 160.1 erfolgt. Für erzeugte Pakete, die aus der Bridge stammen, wird einfach bei 160.2 der XMASK-Wert 55 aus der Management-Tabelle 82 geholt.
  • Für eingehende Pakete werden die SA 16 und die DA 15 aus dem Paket und der Wert von RPORT 85, der die Nummer des Ports angibt, an dem das Paket empfangen wurde, bei 160.3 dazu verwendet, auf den Bridging-Cache 83 zuzugreifen. Ist das Tripel <RPORT, SA, DA> im Bridging-Cache 83 enthalten, so wird der XMASK-Wert 55 sofort geholt und der Bridging-Algorithmus ist abgeschlossen. Der Ablauf geht zur Ausführung des Zuweisungsschritts 160.4 über. Wird das Tripel <RPORT, SA, DA> nicht gefunden, muss eine vollständige Verarbeitung der Paketadressen erfolgen. In einigen Ausführungsformen enthält der Bridging-Cache 83 nie einen Eintrag XMASK 55, wenn Broadcast/Multicast-Adressen vorliegen oder wenn eine Custom Filtering Rule auf DA, SA oder ihre zugehörigen Ports anwendbar ist. Mit dieser Einschränkung vermeidet man das Vergeuden von Platz im Bridging-Cache, da Custom Filtering Rules Entscheidungen anhand der Paketdaten und auch der SA 16 und der DA 15 treffen müssen und somit keinen gültigen statischen XMASK-Wert 55 im Bridging-Cache haben können.
  • Zu einer vollständigen Paketverarbeitung (d. h. wenn kein übereinstimmender Cacheeintrag gefunden wird) gehört zuerst eine Prüfung der DA 15 bei 160.5, um festzustellen, ob das Broadcast/Multicast-Flag 21 gesetzt ist. Ist das Flag gesetzt, so wird der XMASK-Wert 55 bei 160.6 direkt mit Hilfe von RPORT 85 aus der Broadcast/Multicast-Tabelle 81 geholt.
  • Ist das Broadcast/Multicast-Bit nicht gesetzt, so dient der folgende Schritt bei 160.7 dem Zugriff auf die Bridging-Tabelle 25 mit Hilfe von SA 16, um festzustellen, ob die Quelladresse und ihr zugeordneter RPORT-Wert 85 bereits vorhanden und korrekt sind. Stellt sich heraus, dass sich der Zusammenhang zwischen SA 16 und RPORT 85 geändert hat oder SA 16 nicht vorhanden ist, so muss die Bridging-Tabelle 25 bei 160.8 aktualisiert werden, damit sie den neuen Zusammenhang wiedergibt. Tritt dies ein, so muss auch der Bridging-Cache 83 durchsucht werden, und alle Einträge mit einem Quelladressen-Feld 16 gleich der SA 16 des empfangenen Pakets 13 müssen ungültig gemacht werden (Schritt 160.9).
  • Zeigt der Zugriff auf die Bridging-Tabelle 25, dass SA 16 vorhanden ist und den korrekten RPORT-Wert hat, so wird bei 160.10 mit Hilfe von DA 15 erneut auf die Bridging-Tabelle 25 zugegriffen und versucht, den XPORT-Wert 15 zu holen, der DA entspricht. Wird ein DA 15 entsprechender Eintrag nicht gefunden, so wird der RPORT-Wert dazu verwendet, auf die Broadcast/Multicast-Tabelle 81 zuzugreifen und eine XMASK 55 zu holen. Diese XMASK gibt Ports an, an die das Paket zu übertragen ist, wenn versucht wird, es in ein Netz zu bringen, in dem sich DA befindet.
  • Ist DA 15 in der Bridging-Tabelle 25 vorhanden, so wird der Wert von XPORT 86 geholt, der den Port angibt, an dem sich DA 15 befindet. Mit Hilfe von RPORT 85 und XPORT 86 wird bei 160.11 auf die Weiterleit-Tabelle 80 zugegriffen und eine XMASK 55 geholt.
  • Nach Abschluss der hier ausführlich beschriebenen Verarbeitung ist ein XMASK-Wert 55 verfügbar, der beim Absenden verwendet wird. In den Fällen, in denen XMASK 55 aus dem Bridging-Cache 83 erhalten wird, kann das Absenden direkt erfolgen. In allen anderen Fällen muss geprüft werden, ob Custom Filtering Rules (Schritte 160.12, 160.13) vorhanden sind. Flags, die das Vorhandensein von Custom Filtering Rules angeben, werden in der Bridging-Tabelle 25 für SA 16 und DA 15 gehalten sowie in eigenen Regeltabellen, die zu jedem Port gehören. Bei Bedarf werden die geeigneten CFRs ausgewertet und anschließend wird XMASK 55 wie erforderlich verändert, damit ein endgültiger Wert erzeugt wird (Schritt 160.14). Dieser Vorgang kann ziemlich kompliziert sein und die Leistungsfähigkeit beträchtlich beeinflussen. Kommt das verarbeitete Paket (kein erzeugtes Paket) mit der DA einer einzigen Station herein (kein Broadcast oder Multicast) und sind keine CFRs anzuwenden, so wird der Bridging-Cache 83 bei 160.15 von <RPORT, SA, DA> aktualisiert, damit er den neuen XMASK-Wert 55 widerspiegelt.
  • In der bevorzugten Ausführungsform werden Pakete mit Broadcast/Multicast-Adressen nicht im Bridging-Cache 83 abgelegt. Es gibt eigentlich keinen Grund, dies zu verhindern; derartige Pakete stellen jedoch einen relativ geringen Teil des gesamten Paketverkehrs dar. Damit kann man den Bridging-Cache 83 besser dadurch nutzen, dass Einträge ausschließlich Einzeladressen-DAs 15 vorbehalten werden. In Situationen mit Verkehrsprofilen, die sich von dieser Ausführungsform unterscheiden, kann es erwünscht sein, Broadcast- und Multicast-Adressen in den Bridging-Cache 83 aufzunehmen.
  • BESCHREIBUNG DES PORTÜBERWACHUNGSMERKMALS
  • Die Portüberwachung ist ein Vorgang, bei dem Pakete, die an der Bridge ankommen oder intern erzeugt werden, an einen oder mehrere Überwachungsports 10 (1) kopiert werden können. Eine an den Überwachungsport 10 angeschlossenen Überwachungsvorrichtung 9 kann dann eine Analyse der überwachten Pakete liefern. In der bevorzugten Ausführungsform kann die Überwachungsvorrichtung 9 beispielsweise ein SniffeTM von Network General oder ein LANalyzerTM von Novell sein. Diese Vorrich tungen analysieren den Paketverkehr auf einem Netz und liefern verschiedene Diagnoseinformationen, die es dem Netzverwalter ermöglichen, Probleme zu finden, die Leistung zu bewerten und geeignete Einstellungen für die Netzparameter zu ermitteln.
  • Die Portüberwachung wird vom Aufsichtszugangsterminal 12 her kontrolliert. Mit Hilfe dieses Terminals kann der Netzmanager überwachte Ports 3 und Überwachungsports 10 kennzeichnen. Ist die Portüberwachung freigegeben, so werden den überwachten Ports 3 zugeordnete Pakete an den Überwachungsport 10 weitergeleitet. In der bevorzugten Implementierung werden diese Pakete nicht wirklich kopiert, sondern das beschriebene Paketverarbeitungsprotokoll wird verwendet, in dem nur die Paketkennzeichner 49 kopiert werden.
  • Die Portüberwachung wird vom Aufsichtszugangsterminal 12 mit Hilfe einer einfachen Befehlszeilensprache kontrolliert. Tabelle II zeigt die Syntax der Befehle. Für jeden Befehl zeigt das Präfix "pm" an, dass es sich um einen Portüberwachungsbefehl handelt. Es gibt drei Grundkommandos, nämlich "view", "viewpair" und "close". Die ersten drei in Tabelle II dargestellten Befehle sind vom Typ "view", der durch das Befehlswort "view" gekennzeichnet ist. Diese Kommandos bezeichnen eine <monitored-port-number> und eine <monitoring-port-number>. Es ist auch ein Feld vorhanden, das die gewünschte Überwachungsart bezeichnet, nämlich entweder "eingehend" oder "weitergeleitet" oder "erzeugt". Eingehende Pakete sind diejenigen Pakete, die an einem bezeichneten überwachten Port 3 ankommen. Weitergeleitete Pakete sind alle diejenigen Pakete, die von irgendeinem anderen Port an den bezeichneten überwachten Port 3 weitergeleitet werden. Erzeugte Pakete sind diejenigen Pakete, die von der Bridge intern erzeugt und an den überwachten Port 3 weitergeleitet werden. Wird der View-Befehl gegeben, so werden alle Pakete des bezeichneten Typs vom Port, der in <monitored-port-number> angegeben ist, zum Port "kopiert", der in <monitoring-port-number> angegeben ist, und zwar zusätzlich zur normalen Weiterbeförderung der Pakete.
  • Ein Befehl "viewpair" legt ein Paar Ports 3 und einen Überwachungsport 10 fest. Pakete, die am Port empfangen werden, der mit <source-monitored-port-number> bezeichnet ist, und die an den Paket weitergeleitet werden, der mit <destination-monitored-port-number> bezeichnet ist, werden zum Port "kopiert", der in <monitoring-port-number> angegeben ist.
  • Zum Beenden der Portüberwachung wird der Befehl "close" gegeben.
  • Es ist beabsichtigt, dass sich die Wirkungen der einzelnen Befehle überlagern, d. h., dass jedes verarbeitete Kommando (mit Ausnahme von "close") eine zusätzliche Portüberwachung freigibt. Die Wirkungen jeglicher Befehle, die nach dem vorausgehenden Kommando "close" gegeben wurden, bleiben unbeeinflusst. Damit kann man durch das wiederholte Anwenden der obigen Befehle mehrere Ports als überwachte Ports bezeichnen, diverse Ports zu Überwachungsports erklären oder unterschiedliche Kombinationen daraus herstellen.
  • Für die Erklärung wurde eine einfache Befehlssprache festgelegt. Natürlich kann man die angegebene Befehlssyntax mit bekannten Vorgehensweisen erweitern und Verbundbefehle bereitstellen, die es erlauben, mehrere überwachte Ports, Überwachungsports und Paketweiterleitungssituationen in einer Befehlszeile oder über andere Arten von Benutzerschnittstellen festzulegen.
  • Figure 00290001
    Tabelle II: Portüberwachungs-Befehlssyntax
  • IMPLEMENTIERUNG DER PORTÜBERWACHUNGSBEFEHLE
  • Bis hierher wurden die Bridge 1 sowie ihre Implementierung und Arbeitsweise nur für den Normalbetrieb dargestellt, in dem keine Portüberwachung stattfindet. Anhand von Befehlen, die vom Aufsichtszugangsterminal 12 abgegeben werden, können zahlreiche Aspekte der Portüberwachung freigegeben werden. In der bevorzugten Ausführungsform umfasst die Portüberwachung das Verändern der besprochenen Datenstrukturen, um den überwachten Port 3 und den Überwachungsport 10 zu bezeichnen. Die Modifikationen werden für jede der Überwachungssituationen: "weitergeleitet", "eingehend", "erzeugt" und "Portpaar" dargestellt.
  • Zum Erläutern der Auswirkungen verschiedener Portüberwachungskommandos auf die Weiterleitungs-Datenstrukturen werden Beispiele angegeben, die auf dem Gebrauch des Ports 4 als bezeichnetem Überwachungsport 10 beruhen. Für die Einzelportüberwachung wird der Port 2 verwendet. Für die Portpaarüberwachung ist der Port 2 der als Quelle überwachte Port und der Port 3 der als Bestimmung überwachte Port.
  • Für alle Beispiele wird unterstellt, dass der Überwachungsport, der Port 4, nur zur Überwachung verwendet wird. Damit werden Pakete nur durch die Freigabe der Portüberwachungsfunktion zum Port 4 weitergeleitet. Dies ist der bevorzugte Arbeitsmodus der Bridge bei freigegebener Portüberwachung, da andere Stationen am Überwachungsport vielleicht nicht in der Lage sind, den Paketverkehr korrekt zu interpretieren, der durch die Portüberwachungsfunktion entsteht.
  • Überwachung der eingehenden Pakete
  • Sollen eingehende Pakete an einem Port überwacht werden, so müssen alle an dem bezeichneten überwachten Port empfangen Pakete an den Überwachungsport kopiert werden. Pakete werden auch dann an den Überwachungsport kopiert, wenn sie an keinen weiteren Port gesendet werden müssen (d. h., wenn sie von der Bridge einbehalten werden). Ist das Überwachen von eingehenden Paketen gefordert, so werden die Weiterleit-Tabelle 80 und die Broadcast/Multicast-Tabelle 81 verändert. Die Management-Tabelle 82 wird nicht verändert, da sie nur die erzeugten Pakete beeinflusst.
  • Zum Freigeben der Überwachung eingehender Pakete auf <monitored-port-number> wird jeder Eintrag in der Weiterieit-Tabelle 80, in dem RPORT 85 gleich der <monitored-port-number> ist, modifiziert. Für jeden derartigen Eintrag wird das XMASK-Bit gesetzt, das <monitoring-port-number> entspricht. 17A zeigt die Ergebnisse, die in der beispielhaften Weiterleit-Tabelle in 12 entstehen, wenn der Befehl "pm view 2 on 4" ausgeführt wird. Da der Port 2 auf Port 4 zu überwachen ist, wird in jedem XMASK-Eintrag 55 in "Zeile 2" 60 das Bit 4 gesetzt.
  • Eine ähnliche Modifikation muss an der Broadcast/Multicast-Tabelle 81 vorgenommen werden. Für den XMASK-Eintrag 55, für den RPORT 85 gleich der <monitored-port-number> ist, wird das XMASK-Bit, das zu <monitoring-port-number> gehört, gesetzt. 17B zeigt die Ergebnisse, die in der beispielhaften Broadcast/Multicast-Tabelle 89 in 13 entstehen, wenn der Befehl "pm view 2 on 4" ausgeführt wird. Durch die Befehlsausführung wird im Eintrag 61 für RPORT = 2 das Bit 4 gemäß dem Überwa chungsport gesetzt. Für die anderen Einträge bleibt das Bit 4 unverändert und gelöscht, da der Port 4 isoliert ist, damit er in der bevorzugten Weise die Portüberwachung unterstützt.
  • Zum Unterstützen der Überwachung der eingehenden Pakete werden an der Management-Tabelle 82 keine Veränderungen vorgenommen, da die XMASK-Werte 55 in der Tabelle nur für Pakete verwendet werden, die die Bridge erzeugt.
  • Das Überwachen von weitergeleiteten Paketen
  • Sollen weitergeleitete Pakete überwacht werden, so müssen die XMASK-Einträge 55 in der Weiterleit-Tabelle 80 und der Broadcast/Multicast-Tabelle 81 so verändert werden, dass jedes Paket, das zu einer bezeichneten <monitored-port-number> weitergeleitet wird, auch an die <monitoring-port-number> "kopiert" wird. Die Management-Tabelle 82 wird nicht verändert.
  • Um eine Überwachung der Pakete zu erreichen, die an <monitored-port-number> weitergeleitet werden, muss das der <monitoring-port-number> entsprechende Bit in der XMASK eines jeden Eintrags in der Weiterleit-Tabelle 80 gesetzt werden, bei dem XPORT gleich <monitored-port-number> ist, jedoch mit Ausnahme des Eintrags, in dem RPORT gleich <monitored-port-number> ist. 18A zeigt das Ergebnis der Ausführung des Befehls "pm view forwarded 2 on 4" auf die beispielhafte Weiterleit-Tabelle 80 in 12. Die modifizierten Einträge sind die "Spalte 2" 73 und geben an, dass die an Port 2 weitergeleiteten Pakete auch an den Port 4 weitergeleitet werden sollen. Der Eintrag bei RPORT = XPORT = 2 hat eine XMASK mit Nullen (000000), da am Port 2 empfangene Pakete nicht an diesen Port weitergeleitet werden sollen.
  • Broadcast/Multicast-Pakete können auch an den überwachten Port 3 weitergeleitet werden; damit ist es erforderlich, die Broadcast/Multicast-Tabelle 81 zu modifizieren. Jeder XMASK-Eintrag in der Broadcast/Multicast-Tabelle 81 wird durch die ODER-Verknüpfung des Bits, das zu <monitored-port-number> gehört, mit dem Bit, das zu <monitoring-port-number> gehört, modifiziert. Das Ergebnis wird im Bit abgelegt, das zu <monitoring-port-number> gehört. 18B zeigt die Ergebnisse der Veränderung der Broadcast/Multicast-Tabelle in 13 gemäß dem obigen Befehl. Dies hat zur Folge, dass die "Bitspalte" 2 62 mit der "Bitspalte" 4 63 ODER-verknüpft wird. Das Ergebnis wird in die Bitspalte 4 63 zurückgeschrieben und zeigt an, dass jedes Broadcast/Multicast-Paket von RPORT, das an den Port 2 weitergeleitet wird, auch an den Port 4 weitergeleitet werden soll.
  • Das Überwachen von erzeugten Paketen
  • Das Überwachen von erzeugten Paketn führt nur zur Veränderung der Management-Tabelle 82. Die Weiterleit-Tabelle 80 und die Broadcast/Multicast-Tabelle 81 bleiben unverändert, da sie keine Auswirkung auf das Weiterleiten von erzeugten Paketen haben, die aus der Bridge selbst stammen.
  • Zum Freigeben der Überwachung von erzeugten Paketen wird jeder XMASK-Eintrag 55 in der Management-Tabelle 82 so abgewandelt, dass das zu <monitored-port-number> gehörende Bit mit dem Bit ODER-verknüpft wird, das zu <monitoring-port-number> gehört. Das Ergebnis wird in dem Bit abgelegt, das zu <monitoring-port-number> gehört.
  • 19 zeigt das Ergebnis des Befehls "pm view generated 2 on 4" angewendet auf die beispielhafte Management-Tabelle in 14. Die "Bitspalte" 2 75, die zum überwachten Port 2 gehört, ist mit der "Bitspalte" 4 76, die den Überwachungsport 4 darstellt, ODER-verknüpft worden. Das Ergebnis ist in die Bitspalte 4 76 zurückgeführt.
  • Überwachung von Portpaaren
  • Ist die Portpaar-Überwachung freigegeben, so werden Pakete, die von einem als Quelle überwachten Port 3 stammen, und an einen als Bestimmung überwachten Port 3 weitergeleitet werden, auch an den Überwachungsport 10 kopiert. Zum Unterstützen dieser Option müssen die Weiterleit-Tabelle 80 und die Broadcast/Multicast-Tabelle 81 modifiziert werden; die Management-Tabelle 82 bleibt jedoch unverändert.
  • Der XMASK-Eintrag 55 in der Weiterleit-Tabelle 80, der mit RPORT = <source-monitored-port-number> und XPORT = <destination-monitored-port-number> bezeichnet ist, wird dadurch abgewandelt, dass das XMASK-Bit gesetzt wird, das zu <monitoring-port-number> gehört. 20A zeigt das Ergebnis, das entsteht, wenn man das Kommando "pm view pair 2 3 on 4" auf die beispielhafte Weiterleit-Tabelle 80 in 12 anwendet. Der modifizierte Eintrag 84 ist hervorgehoben.
  • In der Broadcast/Multicast-Tabelle 81 wird der Eintrag, der zu RPORT = <source-monitored-port-number> gehört, dadurch modifiziert, dass das XMASK-Bit, das zu <destination-monitored-port-number> gehört, mit dem Bit ODER-verknüpft wird, das zu <mo nitoring-port-number> gehört. Das Ergebnis wird in dem Bit abgelegt, das zu <monitoring-port-number> gehört. 20B zeigt das Ergebnis, das entsteht, wenn man das obige Kommando auf die beispielhafte Broadcast/Multicast-Tabelle in 13 anwendet. Es wird nur der Eintrag 61 RPORT = 2, der zum als Quelle überwachten Port gehört, dadurch modifiziert, dass das XMASK-Bit 3 (das zu <destination-monitoredd-port-number> gehört, mit dem Bit 4 ODER-verknüpft wird (das zu <monitoring-port-number> gehört). Das Ergebnis wird im Bit 4 abgelegt. Damit das Überwachen eines Portpaars möglich wird, brauchen keine Veränderungen an der Management-Tabelle 82 vorgenommen werden.
  • Der Close-Befehl
  • Die Auswirkungen der Portüberwachung überlagern sich. Tritt ein Befehl "pm close" auf, so werden die Weiterleit-Tabelle 80, die Broadcast/Multicast-Tabelle 81 und die Management-Tabelle 82 einfach wieder in den Ursprungszustand vor der Anwendung irgendeines der Befehle "pm view" oder "pm viewpair" zurückversetzt.
  • Weitere Fragen im Zusammenhang mit der Portüberwachung
  • Die Portüberwachung arbeitet natürlich mit dem Bridging-Cache 83. Aus der Weiterleit-Tabelle 80 erhaltene XMASK-Werte werden in den Bridging-Cache 83 gelegt, solange keine CFRs wirksam sind, wie dies bei der normalen Verarbeitung zutrifft. Der Betrieb des Bridging-Caches 83 wird von der Portüberwachung nicht beeinflusst.
  • Auf den Überwachungsport 10 können CFRs angewendet werden. In der bevorzugten Ausführungsform ist dies jedoch nicht zulässig, damit die Wirksamkeit steigt.
  • Da die Anwendung von Überwachungsbefehlen die XMASK-Werte 55 verändern kann, ist es wichtig, den Bridging-Cache 83 immer dann zu entleeren, wenn ein Überwachungsbefehl gegeben wird.
  • In einigen Ausführungsformen werden Pakete mit Fehlern und Pakete, die zu groß oder zu klein sind, nicht an den Überwachungsport 10 "kopiert". Falls dies in bestimmten Implementierungen erwünscht ist, kann es jedoch geschehen.
  • Die Ungewissheit bezüglich des Ursprungs-Netzabschnitts der überwachten Pakete wird geringer. In der Tat weiß die Bridge exakt, an welchem Port jedes eingehende Paket empfangen wurde, und zwar auch dann, wenn die SA des Pakets aufgrund von Fehlfunktionen oder Sabotage falsch ist. Damit kann man die an einem oder mehreren präzise ausgewählten Ports empfangenen Pakete auch dann isolieren und an den Netzmonitor weiterleiten, wenn die Pakete falsche Herkunftsadressen haben. Die Fehlersuche in der Bridge wird dadurch erleichtert. Insbesondere sind die Sicherheitsprobleme leichter zu lösen. Die Unsicherheit wird auch in den Router-Ausführungsformen geringer, da der Router ebenfalls den Empfangsport eines Pakets unabhängig von der Paket-SA ermittelt.
  • In manchen Ausführungsformen werden in verschiedenen an die Bridge angeschlossenen Netzabschnitten unterschiedliche Protokolle verwendet. Die Bridge setzt je nach Bedarf Pakete aus einem Protokollformat in ein anderes Format um. Insbesondere wird jedes an den Überwachungsport 10 weitergeleitete Paket bei Bedarf in das Format des Segments umgesetzt, das an den Überwachungsport angeschlossen ist. Die Fähigkeit der Bridge, Pakete umzusetzen, erlaubt die freie Wahl des Netzabschnitts, der mit dem Überwachungsport verbunden ist. Beispielsweise sind in einigen Ausführungsformen diverse nicht am Überwachungsport liegende Segmente FDDI-Segmente, und das an den Überwachungsport angeschlossene Segment ist ein Ethernet-Segment. Der Gebrauch des Ethernet-Segments erlaubt verringerte Netzkosten, da Ethernet-Netzmonitore in der Regel billiger sind als FDDI-Netzmonitore.
  • PORTÜBERWACHUNG IN ROUTERN
  • In Routerimplementierungen treten viele grundlegende Fragen hinsichtlich der Portüberwachung ebenfalls auf. Die Vermittlung der Pakete erfolgt abhängig vom Inhalt des Data-Felds 17. Das Routing beruht auf Datenstrukturen, die den beim Bridging verwendeten Datenstrukturen ähnlich sind. Es kann beispielsweise eine Routing-Tabelle geben, die Netzadressen in Ports und Netz-Bestimmungsorte umsetzt. Es können auch Address-Resolution-Tabellen vorhanden sein, die Router- und Hostziele in tatsächliche Ethernet-Adressen umsetzen, die ihrerseits dazu verwendet werden, die DA 15 des Pakets 13 zu aktualisieren, damit es zur nächsten Verbindung oder zum endgültigen Bestimmungsort geleitet wird. Wie beim Bridging kann man die Leistung verbessern, indem man vor kurzem berechnete Ergebnisse in einen Cache legt. Man kann beispielsweise die Netzadresse, die Ethernet-Adresse und die Portnummer zusammen mit einem XMASK-Wert 55 im Cache ablegen. Da die Weiterleitentscheidung von zahlreichen Faktoren abhängt, beispielsweise dem Routerstatus, dem Status des nächsten Sprungs und dem Status des Pfads, kann man die XMASK 55 nicht direkt statisch berechnen, wie dies beim Bridging möglich ist. Ist die Überwachung freigegeben, wird die aus der Rou ting-Tabelle und der Address-Resolution-Tabelle abgeleitete XMASK 55 mit einem Algorithmus gemäß der derzeit freigegebenen Überwachung modifiziert. Diese XMASK 55 wird nun für folgende Zugriffe im Routing-Cache abgespeichert.
  • Beim Weiterleiten eines eingehenden Pakets verändert ein Router normalerweise einen Teil des Paket-Kopfeintrags. Er ersetzt beispielsweise die SA und DA des empfangenen Pakets durch seine eigene SA und die DA des folgenden Sprungs, und er kann einen Sprungzähler aktualisieren. Ist die Portüberwachung wirksam, so ist das zum Überwachungsport weitergeleitete Paket das modifizierte Paket, und nicht exakt das empfangene Paket.
  • In einigen Ausführungsformen erzeugt der Router eine Kopie der empfangenen Pakets, bevor er es modifiziert, damit er exakt das empfangene Paket an den Überwachungsport weiterleitet. Fachleuten ist geläufig, dass es nicht unbedingt erforderlich ist, das gesamte Paket zu kopieren, sondern nur den modifizierten Teil, falls die Portcontroller 37 mehrere Puffer in einem einzigen Paket für die Übertragung "sammeln" können. In diesen Fall kann man einen eigenen Puffer für den kopierten und modifizierten Teil des Pakets zuweisen, und den ursprünglichen Puffer dazu verwenden, das Paket an den Überwachungsport weiterzuleiten (oder umgekehrt).
  • Die Erfindung wurde anhand einer bevorzugten Implementierung beschrieben, die auf einem bestimmten Beispiel für die Bridge und das Netz beruht. Fachleute können erkennen, dass man die Erfindung innerhalb des Bereichs der beigefügten Ansprüche mit Abwandlungen und Erweiterungen ausführen kann.

Claims (30)

  1. Vorrichtung zum Ermöglichen von Übertragung zwischen Einheiten, die mit verschiedenen Netzwerksegmenten verbunden sind, wobei die Vorrichtung folgendes aufweist: eine Anzahl an Anschlüssen (3, 10) zur Verbindung mit den Netzwerksegmenten und mit einem oder mehreren Überwachungssystemen; und erste Mittel (11, 12) zum Übertragen von Informationspaketen an einen oder mehrere der Anschlüsse (3, 10), wobei jedes Informationspaket Übermittlungsinformation aufweist, die beim Bestimmen des Bestimmungsortes des Pakets zu verwenden ist; wobei die ersten Mittel (11, 12) Mittel zum Übertragen jedes der einen oder mehreren Pakete (a) zu einem oder mehreren Anschlüssen (3), die aus dem Paketbestimmungsort bestimmt werden, wenn der Bestimmungsort eine von der Vorrichtung verschiedene Einheit umfasst; und, zusätzlich, (b) zu einem oder mehreren Überwachungsanschlüssen (10) umfassen.
  2. Vorrichtung nach Anspruch 1, wobei jeder Überwachungsanschluss (10) dafür ausgelegt ist, eine Verbindung zu einem Netzwerksegment zu ermöglichen, welches für einen Netzwerkmonitor (9) zugänglich ist.
  3. Vorrichtung nach einem der vorstehenden Ansprüche, wobei das erste Mittel dafür ausgelegt ist, als Antwort auf eine Anweisung die Übertragung eines Pakets (a) zu einem oder mehreren Anschlüssen, welche basierend auf dem Paketbestimmungsort bestimmt werden, und, zusätzlich, (b) zu einem oder mehreren Überwachungsanschlüssen zu ermöglichen.
  4. Vorrichtung nach einem der vorstehenden Ansprüche, weiter aufweisend zweite Mittel, um den ersten Mitteln anzugeben, welche Pakete zu einem oder mehreren Überwachungsanschlüssen zu übertragen sind, wobei das zweite Mittel dafür ausgelegt ist, solche Pakete zu einem beliebigen Zeitpunkt während des Betriebs der ersten Mittel zu bezeichnen.
  5. Vorrichtung nach einem der vorstehenden Ansprüche, wobei jeder der Anschlüsse dafür ausgelegt ist, die Verbindung zu einem Netzwerksegment zu ermöglichen.
  6. Vorrichtung nach einem der vorstehenden Ansprüche, wobei die Anzahl an Anschlüssen folgendes aufweist: einen Anschluss oder mehrere Anschlüsse zur Verbindung mit einem oder mehreren Netzwerksegmenten unter Einsatz eines ersten Protokollformats; und einen Anschluss oder mehrere Anschlüsse zur Verbindung mit einem oder mehreren Netzwerksegmenten unter Einsatz eines zweiten Protokollformats, das vom ersten Protokollformat verschieden ist; wobei der Überwachungsanschluss oder die Überwachungsanschlüsse einen ersten Überwachungsanschluss zur Verbindung mit einem Netzwerksegment unter Einsatz des ersten Protokollformats aufweist/aufweisen; und wobei das erste Mittel Mittel zum Übertragen der Pakete aus dem zweiten Protokollformat in das erste Protokollformat aufweist, um es zu ermöglichen, dass Pakete, die von einem Netzwerksegment empfangen werden, welches das zweite Protokollformat verwendet, an den ersten Überwachungsanschluss geschickt werden können.
  7. Vorrichtung nach einem der vorstehenden Ansprüche, wobei das erste Mittel einen Speicher zum Speichern einer oder mehrerer Datenstrukturen aufweist, welche es ermöglichen, dass das erste Mittel unter Einsatz einer Versendeinformation eines Pakets alle Anschlüsse, an die das Paket zu übertragen ist, wenn solche vorhanden sind, bestimmt; und wobei die Vorrichtung darüber hinaus Mittel zum Modifizieren der Datenstruktur als Antwort auf Anweisungen umfasst, so dass definiert werden kann, welche Pakete zu welchen Überwachungsanschlüssen zu übertragen sind.
  8. Vorrichtung nach Anspruch 7, wobei die Anweisungen eine Anweisung zum Übertragen von Paketen, die auf einem ausgewählten Anschluss ankommen, zu einem Überwachungsanschluss umfassen.
  9. Vorrichtung nach Anspruch 7 oder 8, wobei die Anweisungen eine Anweisung zum Übertragen von Paketen, welche zu einem ausgewählten Anschluss für die Übertragung weitergeleitet werden, an einen Überwachungsanschluss aufweisen.
  10. Vorrichtung nach Anspruch 7, 8 oder 9, weiter umfassend Mittel zum Erzeugen von Paketen, wobei die Anweisungen eine Anweisung zum Übertragen von Paketen, die vom Erzeugungsmittel erzeugt wurden, an einen Überwachungsanschluss umfassen.
  11. Vorrichtung nach einem der Ansprüche 7 bis 10, wobei die Anweisungen eine Anweisung zum Übertragen von Paketen, welche auf einem ersten ausgewählten Anschluss ankommen und für die Übertragung zu einem zweiten ausgewählten Anschluss weitergeleitet werden, an einen Überwachungsanschluss aufweisen.
  12. Vorrichtung nach einem der vorstehenden Ansprüche, wobei die ersten Mittel Mittel zum Anlegen einer oder mehrerer Filterregeln basierend auf den spezifischen Kontakten jedes Pakets aufweist, um zu bestimmen, welche Pakete zu einem Überwachungsanschluss zu übertragen sind.
  13. Vorrichtung nach einem der vorstehenden Ansprüche, wobei die Pakete eine variable Anzahl an Dateneinheiten umfassen.
  14. Vorrichtung nach einem der vorstehenden Ansprüche, wobei: die Übertragungsinformation jedes Pakets eine Quellenadresse und eine Bestimmungsadresse aufweist; das erste Mittel einen Speicher S1 zum Speichern einer oder mehrerer Einträge der Form (RPORT, SA, DA, XP) aufweist, wobei: RPORT einen Anschluss oder die Anschlüsse bezeichnet; SA eine Quellenadresse ist; DA eine Bestimmungsdresse ist; und XP null Anschlüsse, einen oder mehr als einen Anschluss bezeichnet, an den ein Paket, welches auf dem Anschluss RPORT empfangen wird und eine Quellenadresse SA und eine Bestimmungsadresse DA aufweist, zu übertragen ist; und die Vorrichtung darüber hinaus Mittel M aufweist, um den Speicher beim Empfang eines Pakets nach einem Eingang abzusuchen, dessen RPORT den Anschluss bezeichnet, an dem das Paket empfangen wird, und dessen SA und DA der Quellenadresse bzw. der Bestimmungsadresse des empfangenen Pakets entsprechen, wobei das Mittel M dafür ausgelegt ist, aus XP des aufgefundenen Eingangs jene Anschlüsse herauszufinden, an die das empfangene Paket zu überfragen ist, wenn ein solcher Eingang gefunden wurde.
  15. Vorrichtung nach einem der Ansprüche 1 bis 13, wobei: die Übertragungsinformation jedes Pakets eine Quellenadresse und eine Bestimmungsadresse aufweist; das erste Mittel einen Speicher S2 zum Speichern eines oder mehrerer Eingänge aufweist, von denen jeder ein Triple (SA, DA, XP) aufweist, wobei: SA eine Quellenadresse ist; DA eine Bestimmungadresse ist; und XP null Anschlüsse, eins oder mehr als einen Anschluss, an den ein Paket, welches eine Quellenadresse SA und eine Bestimmungsadresse DA aufweist, zu übertragen ist, bezeichnet; und die Vorrichtung darüber hinaus Mittel M aufweist, um den Speicher S2 beim Empfang eines Pakets nach einem Eingang abzusuchen, dessen SA und DA einer Quellenadresse bzw. einer Bestimmungsadresse des empfangenen Pakets entsprechen, wobei das Mittel M dafür ausgelegt ist, aus XP des aufgefundenen Eingangs jene Anschlüsse zu bestimmen, an die das empfangene Paket zu übertragen ist, wenn ein solcher Eingang aufgefunden wurde.
  16. Vorrichtung nach Anspruch 14 oder 15, wobei XP für jeden Eingang ein Abbild ist, auf dem ein oder mehrere Bits für einen Anschluss angeben, ob Information an jenen Anschluss zu übertragen ist.
  17. Vorrichtung nach einem der vorstehenden Ansprüche, wobei die ersten Mittel folgendes aufweisen: einen Speicher zum Speichern (a) von Informationspaketen in Puffern, (b) einer ersten Datenstruktur für jeden Anschluss P1 der einen oder mehrerer Anschlüsse, um einen oder mehrere Zeiger auf eine oder mehrere Pufferspeicher zu enthalten, welche an dem Anschluss P1 empfangene Pakete speichern, und (c) einer zweiten Datenstruktur für jeden Anschluss P2 der einen oder mehreren Anschlüsse, um einen oder mehrere Zeiger auf einen oder mehrerer Pufferspeicher zu enthalten, welche Pakete speichern, die auf den Anschluss P2 zu übertragen sind; Mittel M2 zum Übertragen von Paketen, welche in Pufferspeichern gespeichert sind, auf welche die Zeiger gerichtet sind, die in der zweiten Datenstruktur des Anschlusses enthalten sind, auf jedem Anschluss, der eine zweite Datenstruktur aufweist; und Mittel zum Kopieren mindestens eines Zeigers aus der ersten Datenstruktur eines ersten Anschlusses auf die zweiten Datenstrukturen eines oder mehrerer zweiter Anschlüsse, um ein Paket, das auf dem ersten Anschluss empfangen wurde, zu dem zweiten Anschluss oder den zweiten Anschlüssen zu übertragen.
  18. Verfahren zum Überwachen eines Netzwerks, aufweisend eine Vorrichtung, welche eine Anzahl an Netzwerksegmenten miteinander verbindet, von denen zumindest eines einen Netzwerkmonitor (9) umfasst, wobei das Verfahren die folgenden Schritte aufweist: (a) Gewinnen von Übertragungsinformation aus jedem Paket, das von der Vorrichtung empfangen oder erzeugt wurde, welche Übertragungsinformation beim Bestimmen des Paketbestimmungsortes zu verwenden ist; (b) wenn ein Paketbestimmungsort eine Station umfasst, die von der Vorrichtung verschieden ist, Übertragen des Pakets durch die Vorrichtung zu einem oder mehreren der Netzwerksegmente, um das Paket an den Paketbestimmungsort zu übermitteln; dadurch gekennzeichnet, dass (c) wenn ein Paket an einen Netzwerkmonitor (9) zu übermitteln ist, das Paket durch die Vorrichtung auf ein Netzwerksegment übertragen wird, das den Netzwerkmonitor (9) enthält.
  19. Verfahren nach Anspruch 18, wobei für mindestens ein Paket, dessen Bestimmungsort eine Station enthält, die von der Vorrichtung verschieden ist, und das an einen Netzwerkmonitor zu übermitteln ist, die Schritte (b) und (c) als Antwort auf eine Anweisung ausgeführt werden.
  20. Verfahren nach Anspruch 18 oder 19, wobei: eines oder mehrere der Netzwerksegmente ein erstes Protokollformat verwenden; eines oder mehrere der Netzwerksegmente ein zweites Protokollformat verwenden, das vom ersten Protokollformat verschieden ist; mindestens ein Netzwerksegment, das einen Netzwerkmonitor umfasst, das erste Protkollformat verwendet; und das Verfahren darüber hinaus das Überfragen eines oder mehrerer Pakete, die auf einem oder merheren Netzwerksegmenten empfangen wurden, welche das zweite Protokollformat verwenden, aus dem zweiten Protokollformat in das erste Protokollformat und das Übermitteln solcher Pakete an ein Netzwerksegment, welches einen Netzwerkmonitor umfasst und das erste Protokollformat verwendet, aufweist.
  21. Verfahren nach einem der Ansprüche 18 bis 20, weiter aufweisend: Speichern einer Datenstruktur oder mehrerer Datenstrukturen zum Bestimmen, unter Verwendung der Übertragungsinformation eines Pakets, aller Netzwerksegmente, an die das Paket zu übertragen ist, falls es solche gibt, in einem Speicher; und Modifizieren der Datenstrukturen als Antwort auf eine Anweisung, um zu definieren, welche Pakete zu welchen Netzwerksegmenten, die Netzwerkmonitore umfassen, zu übertragen sind.
  22. Verfahren nach Anspruch 21, wobei die Anweisung eine Anweisung ist, aus einem ausgewählten Netzwerksegment hereinkommende Pakete an ein Netzwerksegment zu übertragen, welches einen Netzwerkmonitor umfasst.
  23. Verfahren nach Anspruch 21, wobei die Anweisung eine Anweisung ist, Pakete, die in Schritt (b) an ein ausgewähltes Netzwerksegment übertragen wurden, an ein Netzwerksegment zu übertragen, welches einen Netzwerkmonitor umfasst.
  24. Verfahren nach Anspruch 21, weiter umfassend das Erzeugen von Paketen durch die Vorrichtung, wobei die Anweisung eine Anweisung ist, Pakete, die im Erzeugungsschritt erzeugt wurden, an ein Netzwerksegment zu übertragen, welches einen Netzwerkmonitor aufweist.
  25. Verfahren nach Anspruch 21, wobei die Anweisung eine Anweisung ist, Pakete, die von einem ausgewälten erste Netzwerksegment empfangen wurden und in Schritt (b) auf ein zweites ausgewähltes Netzwerksegment übertragen wurden, zu einem Netzwerksegment zu übertragen, welches einen Netzwerkmonitor aufweist.
  26. Verfahren nach einem der Ansprüche 18 bis 25, wobei der Schritt (c) das Anwenden einer oder mehrerer Filterregeln basierend auf den spezifischen Inhalten jedes Pakets aufweist, um zu bestimmen, ob ein Paket an einen Netzwerkmonitor zu übertragen ist.
  27. Verfahren nach einem der Ansprüche 18 bis 26, wobei die Pakete eine variable Anzahl an Dateneinheiten aufweisen.
  28. Verfahren nach einem der Ansprüche 18 bis 27, weiter aufweisend die folgenden Schritte: Speichern von Paketen mit Informationen in Pufferspeichern; und Bereitstellen einer Datenstruktur für jeden Anschluss P2 der Anschlüsse, um einen oder mehrere Zeiger auf einen oder mehrere Pufferspeicher zu enthalten, welche Pakete speichern, die auf dem Anschluss P2 zu übertragen sind, wobei zumindest einer der Schritte (b) und (c) das Übertragen von Paketen, welche in Pufferpeichern gespeichert sind, auf welche die Zeiger in den Datenstrukturen des Anschlusses P2 gerichtet sind, auf jedem Anschluss P2 umfasst.
  29. Verfahren nach Anspruch 28, wobei jeder der Schritte (b) und (c) das Übertragen von Paketen, die in Pufferspeichern gespeichert sind, auf welche Zeiger in den Datenstrukturen des Anschlusses P2 gerichtet sind, auf jedem Anschluss P2 umfasst.
  30. Verfahren nach Anspruch 28 oder 29, weiter aufweisend: Empfangen eines Pakets PC1 auf einem der Anschlüsse; Bestimmen eines Anschlusses oder mehrerer Anschlüsse, an die das Paket PC1 zu übertragen ist; und Einschieben eines Zeigers in einen Pufferspeicher, der zumindest einen Teil des Pakets PC1 speichert, in die Datenstruktur jedes Anschlusses, auf dem das Paket PC1 zu übertragen ist.
DE69434330T 1993-07-19 1994-06-29 Übertragungsvorrichtgung und verfahren Expired - Lifetime DE69434330T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US93397 1993-07-19
US08/093,397 US5515376A (en) 1993-07-19 1993-07-19 Communication apparatus and methods
PCT/US1994/007082 WO1995003659A1 (en) 1993-07-19 1994-06-29 Communication apparatus and methods

Publications (2)

Publication Number Publication Date
DE69434330D1 DE69434330D1 (de) 2005-05-19
DE69434330T2 true DE69434330T2 (de) 2006-03-09

Family

ID=22238695

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69434330T Expired - Lifetime DE69434330T2 (de) 1993-07-19 1994-06-29 Übertragungsvorrichtgung und verfahren

Country Status (6)

Country Link
US (3) US5515376A (de)
EP (1) EP0710415B1 (de)
JP (1) JP3335358B2 (de)
AT (1) ATE293327T1 (de)
DE (1) DE69434330T2 (de)
WO (1) WO1995003659A1 (de)

Families Citing this family (334)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6157621A (en) * 1991-10-28 2000-12-05 Teledesic Llc Satellite communication system
US5515376A (en) 1993-07-19 1996-05-07 Alantec, Inc. Communication apparatus and methods
US6269398B1 (en) * 1993-08-20 2001-07-31 Nortel Networks Limited Method and system for monitoring remote routers in networks for available protocols and providing a graphical representation of information received from the routers
US5857084A (en) * 1993-11-02 1999-01-05 Klein; Dean A. Hierarchical bus structure access system
US5835726A (en) * 1993-12-15 1998-11-10 Check Point Software Technologies Ltd. System for securing the flow of and selectively modifying packets in a computer network
WO1997000471A2 (en) * 1993-12-15 1997-01-03 Check Point Software Technologies Ltd. A system for securing the flow of and selectively modifying packets in a computer network
JP3542159B2 (ja) * 1994-03-17 2004-07-14 株式会社日立製作所 マルチプロセッサ構造のブリッジ
US5666292A (en) * 1994-12-13 1997-09-09 Pitney Bowes Inc. External interface unit having message routing and protocol conversion
US5857075A (en) * 1995-01-11 1999-01-05 Sony Corporation Method and integrated circuit for high-bandwidth network server interfacing to a local area network
US6256313B1 (en) 1995-01-11 2001-07-03 Sony Corporation Triplet architecture in a multi-port bridge for a local area network
US6044400A (en) * 1995-03-25 2000-03-28 Lucent Technologies Inc. Switch monitoring system having a data collection device using filters in parallel orientation and filter counter for counting combination of filtered events
JP2723071B2 (ja) * 1995-03-31 1998-03-09 日本電気株式会社 Ａｔｍ−ｌａｎ接続装置及びａｔｍ−ｌａｎ
US5790799A (en) * 1995-05-17 1998-08-04 Digital Equipment Corporation System for sampling network packets by only storing the network packet that its error check code matches with the reference error check code
JPH08331137A (ja) * 1995-05-31 1996-12-13 Fujitsu Ltd Ｓｍｄｓ交換装置
US20040264402A9 (en) * 1995-06-01 2004-12-30 Padcom. Inc. Port routing functionality
US6418324B1 (en) * 1995-06-01 2002-07-09 Padcom, Incorporated Apparatus and method for transparent wireless communication between a remote device and host system
US5608892A (en) * 1995-06-09 1997-03-04 Alantec Corporation Active cache for a microprocessor
US5691984A (en) * 1995-08-15 1997-11-25 Honeywell Inc. Compact, adaptable brouting switch
US5740175A (en) * 1995-10-03 1998-04-14 National Semiconductor Corporation Forwarding database cache for integrated switch controller
EP0769863B1 (de) * 1995-10-20 2004-01-14 International Business Machines Corporation Brückenvorrichtung zur Verkehrsfilterung in Kommunikationsnetzen
US5835696A (en) * 1995-11-22 1998-11-10 Lucent Technologies Inc. Data router backup feature
US6047321A (en) * 1996-02-23 2000-04-04 Nortel Networks Corporation Method and apparatus for monitoring a dedicated communications medium in a switched data network
US6441931B1 (en) 1996-02-23 2002-08-27 Nortel Networks Limited Method and apparatus for monitoring a dedicated communications medium in a switched data network
US5898837A (en) * 1996-02-23 1999-04-27 Bay Networks, Inc. Method and apparatus for monitoring a dedicated communications medium in a switched data network
US5754791A (en) * 1996-03-25 1998-05-19 I-Cube, Inc. Hierarchical address translation system for a network switch
US6243667B1 (en) 1996-05-28 2001-06-05 Cisco Systems, Inc. Network flow switching and flow data export
US5802054A (en) * 1996-08-15 1998-09-01 3Com Corporation Atomic network switch with integrated circuit switch nodes
US6381632B1 (en) * 1996-09-10 2002-04-30 Youpowered, Inc. Method and apparatus for tracking network usage
CA2218218A1 (en) * 1996-11-08 1998-05-08 At&T Corp. Promiscuous network monitoring utilizing multicasting within a switch
US6044401A (en) * 1996-11-20 2000-03-28 International Business Machines Corporation Network sniffer for monitoring and reporting network information that is not privileged beyond a user's privilege level
US6493347B2 (en) * 1996-12-16 2002-12-10 Juniper Networks, Inc. Memory organization in a switching device
EP0849911A3 (de) * 1996-12-18 1999-02-10 Nortel Networks Corporation Überwachung eines Kommunikationsnetz
US6098110A (en) * 1996-12-30 2000-08-01 Compaq Computer Corporation Network switch with a multiple bus structure and a bridge interface for transferring network data between different buses
US6665733B1 (en) * 1996-12-30 2003-12-16 Hewlett-Packard Development Company, L.P. Network communication device including bonded ports for increased bandwidth
US6201789B1 (en) * 1996-12-30 2001-03-13 Compaq Computer Corporation Network switch with dynamic backpressure per port
US6222840B1 (en) * 1996-12-30 2001-04-24 Compaq Computer Corporation Method and system for performing concurrent read and write cycles in network switch
US6233246B1 (en) 1996-12-30 2001-05-15 Compaq Computer Corporation Network switch with statistics read accesses
US6098109A (en) 1996-12-30 2000-08-01 Compaq Computer Corporation Programmable arbitration system for determining priority of the ports of a network switch
US6173364B1 (en) * 1997-01-15 2001-01-09 At&T Corp. Session cache and rule caching method for a dynamic filter
JPH10207804A (ja) * 1997-01-16 1998-08-07 Alps Electric Co Ltd 偽装端末システムおよび偽装端末装置
US6205147B1 (en) * 1997-02-11 2001-03-20 Newbridge Networks Corporation Virtual network architecture
US6061351A (en) * 1997-02-14 2000-05-09 Advanced Micro Devices, Inc. Multicopy queue structure with searchable cache area
US6094436A (en) * 1997-02-14 2000-07-25 Advanced Micro Devices, Inc. Integrated multiport switch having shared media access control circuitry
US6151316A (en) * 1997-02-14 2000-11-21 Advanced Micro Devices, Inc. Apparatus and method for synthesizing management packets for transmission between a network switch and a host controller
US6487212B1 (en) 1997-02-14 2002-11-26 Advanced Micro Devices, Inc. Queuing structure and method for prioritization of frames in a network switch
US6115387A (en) * 1997-02-14 2000-09-05 Advanced Micro Devices, Inc. Method and apparatus for controlling initiation of transmission of data as a function of received data
US5953335A (en) * 1997-02-14 1999-09-14 Advanced Micro Devices, Inc. Method and apparatus for selectively discarding packets for blocked output queues in the network switch
US6108342A (en) * 1997-02-14 2000-08-22 Advanced Micro Devices, Inc. Management information base (MIB) accumulation processor
US6233244B1 (en) 1997-02-14 2001-05-15 Advanced Micro Devices, Inc. Method and apparatus for reclaiming buffers
US6128654A (en) * 1997-02-14 2000-10-03 Advanced Micro Devices, Inc. Method and apparatus for transmitting multiple copies by replicating data identifiers
US6175902B1 (en) 1997-12-18 2001-01-16 Advanced Micro Devices, Inc. Method and apparatus for maintaining a time order by physical ordering in a memory
US6130891A (en) * 1997-02-14 2000-10-10 Advanced Micro Devices, Inc. Integrated multiport switch having management information base (MIB) interface temporary storage
EP0974218A4 (de) * 1997-04-09 2005-04-13 Alcatel Australia Geschlossene internetbenutzergruppe
US6041042A (en) * 1997-05-27 2000-03-21 Cabletron Systems, Inc. Remote port mirroring system and method thereof
US6324516B1 (en) * 1997-06-11 2001-11-27 Matthew P. Shults System and apparatus for utilization review of medical claims
US6128666A (en) * 1997-06-30 2000-10-03 Sun Microsystems, Inc. Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine
US6044087A (en) * 1997-06-30 2000-03-28 Sun Microsystems, Inc. Interface for a highly integrated ethernet network element
US6021132A (en) * 1997-06-30 2000-02-01 Sun Microsystems, Inc. Shared memory management in a switched network element
US5938736A (en) * 1997-06-30 1999-08-17 Sun Microsystems, Inc. Search engine architecture for a high performance multi-layer switch element
US6081512A (en) * 1997-06-30 2000-06-27 Sun Microsystems, Inc. Spanning tree support in a high performance network device
US6044418A (en) * 1997-06-30 2000-03-28 Sun Microsystems, Inc. Method and apparatus for dynamically resizing queues utilizing programmable partition pointers
US6081522A (en) * 1997-06-30 2000-06-27 Sun Microsystems, Inc. System and method for a multi-layer network element
US6052738A (en) * 1997-06-30 2000-04-18 Sun Microsystems, Inc. Method and apparatus in a packet routing switch for controlling access at different data rates to a shared memory
US6088356A (en) * 1997-06-30 2000-07-11 Sun Microsystems, Inc. System and method for a multi-layer network element
US6119196A (en) * 1997-06-30 2000-09-12 Sun Microsystems, Inc. System having multiple arbitrating levels for arbitrating access to a shared memory by network ports operating at different data rates
US6246680B1 (en) 1997-06-30 2001-06-12 Sun Microsystems, Inc. Highly integrated multi-layer switch element architecture
US5920566A (en) * 1997-06-30 1999-07-06 Sun Microsystems, Inc. Routing in a multi-layer distributed network element
US6049528A (en) * 1997-06-30 2000-04-11 Sun Microsystems, Inc. Trunking ethernet-compatible networks
US6014380A (en) * 1997-06-30 2000-01-11 Sun Microsystems, Inc. Mechanism for packet field replacement in a multi-layer distributed network element
US6016310A (en) * 1997-06-30 2000-01-18 Sun Microsystems, Inc. Trunking support in a high performance network device
US6094435A (en) * 1997-06-30 2000-07-25 Sun Microsystems, Inc. System and method for a quality of service in a multi-layer network element
US6347089B1 (en) * 1997-07-02 2002-02-12 Advanced Communication Devices Corp. Simplified ethernet frame switching system architecture without local buffer requirement
US6154462A (en) 1997-08-21 2000-11-28 Adc Telecommunications, Inc. Circuits and methods for a ring network
US6331985B1 (en) * 1997-08-21 2001-12-18 Adc Telecommunications, Inc. Telecommunication network with variable address learning, switching and routing
US6449273B1 (en) * 1997-09-04 2002-09-10 Hyundai Electronics America Multi-port packet processor
US6442168B1 (en) * 1997-09-17 2002-08-27 Sony Corporation High speed bus structure in a multi-port bridge for a local area network
US6446173B1 (en) 1997-09-17 2002-09-03 Sony Corporation Memory controller in a multi-port bridge for a local area network
US6308218B1 (en) 1997-09-17 2001-10-23 Sony Corporation Address look-up mechanism in a multi-port bridge for a local area network
US6301256B1 (en) 1997-09-17 2001-10-09 Sony Corporation Selection technique for preventing a source port from becoming a destination port in a multi-port bridge for a local area network
US6363067B1 (en) * 1997-09-17 2002-03-26 Sony Corporation Staged partitioned communication bus for a multi-port bridge for a local area network
US6744728B1 (en) 1997-09-17 2004-06-01 Sony Corporation & Sony Electronics, Inc. Data pipeline timing optimization technique in a multi-port bridge for a local area network
US6617879B1 (en) 1997-09-17 2003-09-09 Sony Corporation Transparently partitioned communication bus for multi-port bridge for a local area network
US6157951A (en) * 1997-09-17 2000-12-05 Sony Corporation Dual priority chains for data-communication ports in a multi-port bridge for a local area network
US6128296A (en) * 1997-10-03 2000-10-03 Cisco Technology, Inc. Method and apparatus for distributed packet switching using distributed address tables
US5926463A (en) * 1997-10-06 1999-07-20 3Com Corporation Method and apparatus for viewing and managing a configuration of a computer network
US6049824A (en) * 1997-11-21 2000-04-11 Adc Telecommunications, Inc. System and method for modifying an information signal in a telecommunications system
GB2333428B (en) * 1997-11-28 2002-10-16 3Com Technologies Ltd Congestion control in a management port
GB9725374D0 (en) 1997-11-28 1998-01-28 3Com Ireland Port mirroring and security in stacked communication devices
GB9725372D0 (en) 1997-11-28 1998-01-28 3Com Ireland Trunking in stacked communication devices
US6128729A (en) * 1997-12-16 2000-10-03 Hewlett-Packard Company Method and system for automatic configuration of network links to attached devices
US6084856A (en) * 1997-12-18 2000-07-04 Advanced Micro Devices, Inc. Method and apparatus for adjusting overflow buffers and flow control watermark levels
US6084878A (en) * 1997-12-18 2000-07-04 Advanced Micro Devices, Inc. External rules checker interface
US6080203A (en) * 1997-12-18 2000-06-27 Advanced Micro Devices, Inc. Apparatus and method for designing a test and modeling system for a network switch device
US6084877A (en) * 1997-12-18 2000-07-04 Advanced Micro Devices, Inc. Network switch port configured for generating an index key for a network switch routing table using a programmable hash function
US6075721A (en) * 1997-12-18 2000-06-13 Advanced Micro Devices, Inc. Random access memory having bit selectable mask for memory writes
US6091707A (en) * 1997-12-18 2000-07-18 Advanced Micro Devices, Inc. Methods and apparatus for preventing under-flow conditions in a multiple-port switching device
US6230271B1 (en) * 1998-01-20 2001-05-08 Pilot Network Services, Inc. Dynamic policy-based apparatus for wide-range configurable network service authentication and access control using a fixed-path hardware configuration
JPH11249823A (ja) * 1998-02-27 1999-09-17 Hitachi Ltd バス制御システム
ATE545261T1 (de) * 1998-03-12 2012-02-15 Whale Comm Ltd Verfahren zur absicherung von datenvermittlungsnetzwerken
US6901075B1 (en) * 1998-03-12 2005-05-31 Whale Communications Ltd. Techniques for protection of data-communication networks
US6876654B1 (en) * 1998-04-10 2005-04-05 Intel Corporation Method and apparatus for multiprotocol switching and routing
US6392996B1 (en) * 1998-04-13 2002-05-21 At&T Corp. Method and apparatus for frame peeking
US6175868B1 (en) * 1998-05-15 2001-01-16 Nortel Networks Limited Method and apparatus for automatically configuring a network switch
US6272133B1 (en) * 1998-05-21 2001-08-07 Inviscid Networks, Inc. Packet filtering method
US6389030B1 (en) 1998-08-21 2002-05-14 Adc Telecommunications, Inc. Internet access over a ring network
US6539546B1 (en) 1998-08-21 2003-03-25 Adc Telecommunications, Inc. Transport of digitized signals over a ring network
US6570880B1 (en) 1998-08-21 2003-05-27 Adc Telecommunications, Inc. Control data over a ring network
US6871229B2 (en) * 1998-08-26 2005-03-22 Sts Software Systems Ltd. Method for storing on a computer network a portion of a communication session between a packet source and a packet destination
US6381218B1 (en) 1998-09-11 2002-04-30 Compaq Computer Corporation Network controller system that uses directed heartbeat packets
US6229538B1 (en) 1998-09-11 2001-05-08 Compaq Computer Corporation Port-centric graphic representations of network controllers
US6272113B1 (en) 1998-09-11 2001-08-07 Compaq Computer Corporation Network controller system that uses multicast heartbeat packets
US6347087B1 (en) * 1998-10-05 2002-02-12 Packet Engines Incorporated Content-based forwarding/filtering in a network switching device
EP0993156B1 (de) * 1998-10-05 2007-01-03 Alcatel Netzwerkvermittlungseinrichtung mit auf der Basis von Benutzung verteilten Umleitungsdatenbanken
US8060656B2 (en) * 1998-10-09 2011-11-15 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7293107B1 (en) 1998-10-09 2007-11-06 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7778260B2 (en) 1998-10-09 2010-08-17 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US8078727B2 (en) 1998-10-09 2011-12-13 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US7136645B2 (en) 1998-10-09 2006-11-14 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US6611891B1 (en) * 1998-11-23 2003-08-26 Advanced Micro Devices, Inc. Computer resource configuration mechanism across a multi-pipe communication link
AU2617399A (en) * 1999-01-14 2000-08-01 Nokia Networks Oy Interception method and system
EP1022875B1 (de) * 1999-01-25 2005-06-01 Nippon Telegraph and Telephone Corporation Push-Netzwerk
US6636523B1 (en) 1999-01-27 2003-10-21 Advanced Micro Devices, Inc. Flow control using rules queue monitoring in a network switching system
US6463032B1 (en) 1999-01-27 2002-10-08 Advanced Micro Devices, Inc. Network switching system having overflow bypass in internal rules checker
US6546010B1 (en) 1999-02-04 2003-04-08 Advanced Micro Devices, Inc. Bandwidth efficiency in cascaded scheme
US6466580B1 (en) 1999-02-23 2002-10-15 Advanced Micro Devices, Inc. Method and apparatus for processing high and low priority frame data transmitted in a data communication system
US6393028B1 (en) 1999-02-25 2002-05-21 Advanced Micro Devices, Inc. Method and apparatus for providing EOF for frame modification
US6769055B1 (en) 1999-03-08 2004-07-27 Advanced Micro Devices, Inc. Two-part memory address generator
AU3889300A (en) * 1999-03-15 2000-10-04 Smartsan Systems, Inc. System and method of zoning and access control in a computer network
AU3529500A (en) 1999-03-17 2000-10-04 Broadcom Corporation Network switch
US7366171B2 (en) 1999-03-17 2008-04-29 Broadcom Corporation Network switch
US7643481B2 (en) 1999-03-17 2010-01-05 Broadcom Corporation Network switch having a programmable counter
US6515990B1 (en) 1999-03-31 2003-02-04 Advanced Micro Devices, Inc. Dequeuing logic architecture and operation in a multiport communication switch
US6490280B1 (en) 1999-03-31 2002-12-03 Advanced Micro Devices, Inc. Frame assembly in dequeuing block
US6731596B1 (en) 1999-04-01 2004-05-04 Advanced Micro Devices, Inc. Network switch having system for automatically detecting change in network node connection
US6487199B1 (en) 1999-04-07 2002-11-26 Advanced Micro Devices, Inc. Method and apparatus for maintaining randomly accessible copy number information on a network switch
DE19916490A1 (de) * 1999-04-13 2000-10-26 Alcatel Sa Überwachung der Übertragungsqualität in einem digital Nachrichtenübertragungsnetz
US7369550B1 (en) 1999-04-22 2008-05-06 Advanced Micro Devices Method and apparatus for locking a table in a network switch
US6336156B1 (en) 1999-04-22 2002-01-01 Advanced Micro Devices, Inc. Increased speed initialization using dynamic slot allocation
US6405258B1 (en) 1999-05-05 2002-06-11 Advanced Micro Devices Inc. Method and apparatus for controlling the flow of data frames through a network switch on a port-by-port basis
US6345371B1 (en) 1999-05-05 2002-02-05 Advanced Micro Devices Inc. Method of performing diagnostic procedures on a queue structure
US6480490B1 (en) 1999-05-05 2002-11-12 Advanced Micro Devices, Inc. Interleaved access to address table in network switching system
DE19921589C2 (de) * 1999-05-05 2002-10-24 Siemens Ag Verfahren zum Betrieb eines Datenübertragungssystems
US6895015B1 (en) * 1999-05-05 2005-05-17 Advanced Micro Devices, Inc. Dynamic time slot allocation in internal rules checker scheduler
US6335938B1 (en) 1999-05-05 2002-01-01 Advanced Micro Devices, Inc. Multiport communication switch having gigaport and expansion ports sharing the same time slot in internal rules checker
US6701489B1 (en) 1999-05-07 2004-03-02 Advanced Micro Devices, Inc. Method and apparatus for changing register implementation without code change
US6483844B1 (en) 1999-05-13 2002-11-19 Advanced Micro Devices, Inc. Apparatus and method for sharing an external memory between multiple network switches
US6625157B2 (en) 1999-05-20 2003-09-23 Advanced Micro Devices, Inc. Apparatus and method in a network switch port for transferring data between buffer memory and transmit and receive state machines according to a prescribed interface protocol
US6563818B1 (en) 1999-05-20 2003-05-13 Advanced Micro Devices, Inc. Weighted round robin cell architecture
US20060023716A1 (en) * 1999-05-20 2006-02-02 Advanced Micro Devices, Inc. Bit bucket
US6597693B1 (en) 1999-05-21 2003-07-22 Advanced Micro Devices, Inc. Common scalable queuing and dequeuing architecture and method relative to network switch data rate
US6529503B1 (en) 1999-05-21 2003-03-04 Advanced Micro Devices, Inc. Apparatus and method for storing header information in a network switch
US6618390B1 (en) 1999-05-21 2003-09-09 Advanced Micro Devices, Inc. Method and apparatus for maintaining randomly accessible free buffer information for a network switch
US6477170B1 (en) 1999-05-21 2002-11-05 Advanced Micro Devices, Inc. Method and apparatus for interfacing between systems operating under different clock regimes with interlocking to prevent overwriting of data
US7027437B1 (en) 1999-05-21 2006-04-11 Advanced Micro Devices, Inc. Network switch multiple-port sniffing
US6725270B1 (en) 1999-05-21 2004-04-20 Advanced Micro Devices, Inc. Apparatus and method for programmably modifying a limit of a retry counter in a network switch port in response to exerting backpressure
US6904043B1 (en) 1999-05-21 2005-06-07 Advanced Micro Devices, Inc. Apparatus and methods for storing and processing header information in a network switch
US6574231B1 (en) 1999-05-21 2003-06-03 Advanced Micro Devices, Inc. Method and apparatus for queuing data frames in a network switch port
US6563790B1 (en) 1999-05-21 2003-05-13 Advanced Micro Devices, Inc. Apparatus and method for modifying a limit of a retry counter in a network switch port in response to exerting backpressure
US6463478B1 (en) 1999-05-21 2002-10-08 Advanced Micro Devices, Inc. Method and apparatus for identifying runt data frames received by a network switch
US6816488B1 (en) 1999-05-21 2004-11-09 Advanced Micro Devices, Inc. Apparatus and method for processing data frames in a network switch
US6813266B1 (en) 1999-05-21 2004-11-02 Advanced Micro Devices, Inc. Pipelined access to address table in a network switch
US6504846B1 (en) 1999-05-21 2003-01-07 Advanced Micro Devices, Inc. Method and apparatus for reclaiming buffers using a single buffer bit
US6577636B1 (en) 1999-05-21 2003-06-10 Advanced Micro Devices, Inc. Decision making engine receiving and storing a portion of a data frame in order to perform a frame forwarding decision
US6507564B1 (en) * 1999-05-21 2003-01-14 Advanced Micro Devices, Inc. Method and apparatus for testing aging function in a network switch
US6553027B1 (en) 1999-05-21 2003-04-22 Advanced Micro Devices, Inc. Apparatus and method for cascading multiple network switch devices
US6535489B1 (en) 1999-05-21 2003-03-18 Advanced Micro Devices, Inc. Method and apparatus in a network switch for handling link failure and link recovery in a trunked data path
US6680945B1 (en) 1999-05-24 2004-01-20 Advanced Micro Devices, Inc. Method and apparatus for support of tagging and untagging per VLAN per port
US7031305B1 (en) 1999-05-24 2006-04-18 Advanced Micro Devices, Inc. Apparatus and method for programmable memory access slot assignment
US6584106B1 (en) 1999-05-24 2003-06-24 Advanced Micro Devices, Inc. Backbone forwarding scheme for multiport network switch
US6442137B1 (en) 1999-05-24 2002-08-27 Advanced Micro Devices, Inc. Apparatus and method in a network switch for swapping memory access slots between gigabit port and expansion port
US6775290B1 (en) 1999-05-24 2004-08-10 Advanced Micro Devices, Inc. Multiport network switch supporting multiple VLANs per port
US6501734B1 (en) 1999-05-24 2002-12-31 Advanced Micro Devices, Inc. Apparatus and method in a network switch for dynamically assigning memory interface slots between gigabit port and expansion port
US6401147B1 (en) 1999-05-24 2002-06-04 Advanced Micro Devices, Inc. Split-queue architecture with a first queue area and a second queue area and queue overflow area having a trickle mode and an overflow mode based on prescribed threshold values
GB2350530B (en) 1999-05-25 2001-05-30 3Com Corp Port mirroring across a trunked stack of multi-port communication devices
US6717914B1 (en) * 1999-05-27 2004-04-06 3Com Corporation System for probing switched virtual circuits in a connection oriented network
US6658015B1 (en) 1999-05-28 2003-12-02 Advanced Micro Devices, Inc. Multiport switch with plurality of logic engines for simultaneously processing different respective data frames
US6721277B1 (en) 1999-05-28 2004-04-13 Advanced Micro Devices, Inc. Generic register interface for accessing registers located in different clock domains
US6625146B1 (en) 1999-05-28 2003-09-23 Advanced Micro Devices, Inc. Method and apparatus for operating a network switch in a CPU-less environment
US6515993B1 (en) 1999-05-28 2003-02-04 Advanced Micro Devices, Inc. Method and apparatus for manipulating VLAN tags
US6697371B1 (en) * 1999-06-01 2004-02-24 Advanced Micro Devices, Inc. Network switch with on-board management information based (MIB) counters
US6760332B1 (en) * 1999-06-03 2004-07-06 Fujitsu Network Communications, Inc. ATM multicasting system and method
US6501758B1 (en) 1999-06-03 2002-12-31 Fujitsu Network Communications, Inc. Hybrid ATM/TDM transport over a common fiber ring
US6658006B1 (en) 1999-06-03 2003-12-02 Fujitsu Network Communications, Inc. System and method for communicating data using modified header bits to identify a port
US6785285B1 (en) * 1999-06-03 2004-08-31 Fujitsu Network Communications, Inc. Method and system for providing broadcast channels over an emulated subnetwork
US6665301B1 (en) 1999-06-03 2003-12-16 Fujitsu Network Communications, Inc. Transmission slot allocation method and map for virtual tunnels in a transmission line
AU5461600A (en) * 1999-06-03 2000-12-28 Fujitsu Network Communications, Inc. Method and system for transmitting traffic in a virtual tunnel of a transmission line
US7882247B2 (en) * 1999-06-11 2011-02-01 Netmotion Wireless, Inc. Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
US6907036B1 (en) * 1999-06-28 2005-06-14 Broadcom Corporation Network switch enhancements directed to processing of internal operations in the network switch
US7315552B2 (en) * 1999-06-30 2008-01-01 Broadcom Corporation Frame forwarding in a switch fabric
US6542512B1 (en) 1999-07-02 2003-04-01 Jenny Liu Fischer Architecture and method for flushing non-transmitted portions of a data frame from a transmitted FIFO buffer
US6731601B1 (en) 1999-09-09 2004-05-04 Advanced Micro Devices, Inc. Apparatus and method for resetting a retry counter in a network switch port in response to exerting backpressure
US6952421B1 (en) * 1999-10-07 2005-10-04 Cisco Technology, Inc. Switched Ethernet path detection
GB2356110B (en) * 1999-11-02 2001-10-03 3Com Corp Stacked network devices including a protocol engine and distributed trunk ports and method of operating same
FR2801454B1 (fr) * 1999-11-18 2004-04-30 Cit Alcatel Reseau x25 et procede de transmission de donnees
US7239633B1 (en) * 1999-12-29 2007-07-03 Winbond Electronics Corp. Ethernet switch and method of switching
DE10000237A1 (de) * 2000-01-05 2001-07-19 Siemens Ag Netzwerk-Kopplungseinrichtung und Datennetz mit Netzwerk-Kopplungseinrichtung
US6697870B1 (en) * 2000-01-28 2004-02-24 Networks Associates Technology, Inc. Method and apparatus for real-time protocol analysis using an auto-throttling front end process
US6732184B1 (en) 2000-01-31 2004-05-04 Advanced Micro Devices, Inc. Address table overflow management in a network switch
US6873600B1 (en) * 2000-02-04 2005-03-29 At&T Corp. Consistent sampling for network traffic measurement
WO2001061898A2 (en) * 2000-02-18 2001-08-23 Bridgeco Ag Reference time distribution over a network
AU2001245335A1 (en) * 2000-02-22 2001-09-03 Top Layer Networks, Inc. System and method for flow mirroring in a network switch
US6751219B1 (en) 2000-04-20 2004-06-15 Aztech Partners, Inc. Multicast packet duplication at random node or at egress port with frame synchronization
JP4436960B2 (ja) * 2000-05-16 2010-03-24 日本電気株式会社 パケット通信システムおよび移動通信システム
US7054272B1 (en) * 2000-07-11 2006-05-30 Ciena Corporation Upper layer network device including a physical layer test port
FI4638U1 (fi) * 2000-05-26 2000-09-29 Fulcrum Lab Ag Tiedonsiirtoverkko
EP1168727B1 (de) * 2000-06-19 2006-05-03 Broadcom Corporation Speicherverwaltungseinheit für eine Vermittlungsstelle
US6671739B1 (en) * 2000-07-10 2003-12-30 International Business Machines Corporation Controlling network access by modifying packet headers at a local hub
US6944127B1 (en) * 2000-08-07 2005-09-13 Bbnt Solutions Llc System for detecting spurious network traffic
US6982976B2 (en) * 2000-08-11 2006-01-03 Texas Instruments Incorporated Datapipe routing bridge
US8619793B2 (en) * 2000-08-21 2013-12-31 Rockstar Consortium Us Lp Dynamic assignment of traffic classes to a priority queue in a packet forwarding device
US7143185B1 (en) * 2000-08-29 2006-11-28 Advanced Micro Devices, Inc. Method and apparatus for accessing external memories
US8087064B1 (en) 2000-08-31 2011-12-27 Verizon Communications Inc. Security extensions using at least a portion of layer 2 information or bits in the place of layer 2 information
US6850495B1 (en) * 2000-08-31 2005-02-01 Verizon Communications Inc. Methods, apparatus and data structures for segmenting customers using at least a portion of a layer 2 address header or bits in the place of a layer 2 address header
US7315554B2 (en) 2000-08-31 2008-01-01 Verizon Communications Inc. Simple peering in a transport network employing novel edge devices
US6857027B1 (en) * 2000-11-14 2005-02-15 3Com Corporation Intelligent network topology and configuration verification using a method of loop detection
CA2329097A1 (en) * 2000-12-20 2002-06-20 Nortel Networks Limited Apparatus and method for signal recognition within wdm optical nodes
US7024479B2 (en) * 2001-01-22 2006-04-04 Intel Corporation Filtering calls in system area networks
ATE331250T1 (de) * 2001-03-01 2006-07-15 Storeage Networking Technologi Sicherheit für ein san (storage area network)
JP2002290399A (ja) * 2001-03-26 2002-10-04 Fujitsu Ltd 加入者終端装置およびパケット処理方法
JP2002319957A (ja) * 2001-04-23 2002-10-31 Furukawa Electric Co Ltd:The ネットワーク中継装置、ポートのモニタリング方法、およびその方法をコンピュータが実行するためのプログラム
US7644171B2 (en) * 2001-09-12 2010-01-05 Netmotion Wireless, Inc. Mobile networking system and method using IPv4 and IPv6
JP2003099341A (ja) * 2001-09-20 2003-04-04 Canon Inc ネットワークデバイス管理装置、管理システム及び管理方法、並びにネットワークデバイス
US7072970B2 (en) * 2001-10-05 2006-07-04 International Business Machines Corporation Programmable network protocol handler architecture
US7574597B1 (en) 2001-10-19 2009-08-11 Bbn Technologies Corp. Encoding of signals to facilitate traffic analysis
US20030084219A1 (en) * 2001-10-26 2003-05-01 Maxxan Systems, Inc. System, apparatus and method for address forwarding for a computer network
US7240123B2 (en) * 2001-12-10 2007-07-03 Nortel Networks Limited Distributed routing core
US7145914B2 (en) 2001-12-31 2006-12-05 Maxxan Systems, Incorporated System and method for controlling data paths of a network processor subsystem
US7085846B2 (en) * 2001-12-31 2006-08-01 Maxxan Systems, Incorporated Buffer to buffer credit flow control for computer network
FR2834848B1 (fr) * 2002-01-15 2005-02-04 France Telecom Procede d'observation d'un reseau de communication et systeme pour la mise en oeuvre de ce procede
US20030210696A1 (en) * 2002-04-25 2003-11-13 Globespanvirata Incorporated System and method for routing across segments of a network switch
US7274698B2 (en) * 2002-03-15 2007-09-25 Broadcom Corporation Multilevel parser for conditional flow detection in a network device
US20030179754A1 (en) * 2002-03-20 2003-09-25 Broadcom Corporation Two stage egress scheduler for a network device
US7307995B1 (en) 2002-04-05 2007-12-11 Ciphermax, Inc. System and method for linking a plurality of network switches
US7379970B1 (en) 2002-04-05 2008-05-27 Ciphermax, Inc. Method and system for reduced distributed event handling in a network environment
US7295561B1 (en) 2002-04-05 2007-11-13 Ciphermax, Inc. Fibre channel implementation using network processors
US7406038B1 (en) 2002-04-05 2008-07-29 Ciphermax, Incorporated System and method for expansion of computer network switching system without disruption thereof
US20030195956A1 (en) * 2002-04-15 2003-10-16 Maxxan Systems, Inc. System and method for allocating unique zone membership
US20030200330A1 (en) * 2002-04-22 2003-10-23 Maxxan Systems, Inc. System and method for load-sharing computer network switch
US20030202510A1 (en) * 2002-04-26 2003-10-30 Maxxan Systems, Inc. System and method for scalable switch fabric for computer network
US8165114B2 (en) * 2002-06-13 2012-04-24 Nice Systems Ltd. Voice over IP capturing
US7660297B2 (en) * 2002-06-13 2010-02-09 Nice Systems Ltd. Voice over IP forwarding
GB2389736B (en) * 2002-06-13 2005-12-14 Nice Systems Ltd A method for forwarding and storing session packets according to preset and/or dynamic rules
US8498234B2 (en) 2002-06-21 2013-07-30 Qualcomm Incorporated Wireless local area network repeater
JP3996010B2 (ja) 2002-08-01 2007-10-24 株式会社日立製作所 ストレージネットワークシステム、管理装置、管理方法及びプログラム
US20040030766A1 (en) * 2002-08-12 2004-02-12 Michael Witkowski Method and apparatus for switch fabric configuration
US6823383B2 (en) * 2002-09-10 2004-11-23 Capital One Financial Corporation Stealth network
US7936688B2 (en) * 2002-09-16 2011-05-03 Jds Uniphase Corporation Protocol cross-port analysis
US8058371B2 (en) * 2002-09-20 2011-11-15 Exxonmobil Chemical Patents Inc. Super-solution homogeneous propylene polymerization
JP2004118250A (ja) * 2002-09-24 2004-04-15 Hitachi Ltd 計算機管理システム、管理プログラム
US8885688B2 (en) 2002-10-01 2014-11-11 Qualcomm Incorporated Control message management in physical layer repeater
AU2003274992A1 (en) 2002-10-11 2004-05-04 Widefi, Inc. Reducing loop effects in a wireless local area network repeater
ATE402527T1 (de) * 2002-10-15 2008-08-15 Qualcomm Inc Wlan-repeater mit automatischer verstärkungsregelung für erweiterte netzabdeckung
US8078100B2 (en) 2002-10-15 2011-12-13 Qualcomm Incorporated Physical layer repeater with discrete time filter for all-digital detection and delay generation
CN1706117B (zh) * 2002-10-24 2010-06-23 高通股份有限公司 具有带内控制信道的无线局域网中继器
US7230935B2 (en) * 2002-10-24 2007-06-12 Widefi, Inc. Physical layer repeater with selective use of higher layer functions based on network operating conditions
JP2006506897A (ja) * 2002-11-15 2006-02-23 ワイデファイ インコーポレイテッド 無線ローカルエリアネットワーク検出中継器
US20050102497A1 (en) * 2002-12-05 2005-05-12 Buer Mark L. Security processor mirroring
AU2003300938A1 (en) * 2002-12-16 2004-07-29 Widefi, Inc. Improved wireless network repeater
US7782784B2 (en) 2003-01-10 2010-08-24 Cisco Technology, Inc. Port analyzer adapter
US7899048B1 (en) 2003-01-15 2011-03-01 Cisco Technology, Inc. Method and apparatus for remotely monitoring network traffic through a generic network
US8503437B2 (en) * 2003-03-13 2013-08-06 Verizon Business Global Llc Integrated customer premises equipment device
US7710867B1 (en) * 2003-05-23 2010-05-04 F5 Networks, Inc. System and method for managing traffic to a probe
US8130661B2 (en) * 2003-08-01 2012-03-06 Opnet Technologies, Inc. Systems and methods for intelligent probe testing
US7474666B2 (en) 2003-09-03 2009-01-06 Cisco Technology, Inc. Switch port analyzers
US8165136B1 (en) 2003-09-03 2012-04-24 Cisco Technology, Inc. Virtual port based SPAN
US8769164B2 (en) * 2003-09-18 2014-07-01 International Business Machines Corporation Methods and apparatus for allocating bandwidth for a network processor
US7159051B2 (en) * 2003-09-23 2007-01-02 Intel Corporation Free packet buffer allocation
US9614772B1 (en) 2003-10-20 2017-04-04 F5 Networks, Inc. System and method for directing network traffic in tunneling applications
US7672318B2 (en) * 2003-11-06 2010-03-02 Telefonaktiebolaget L M Ericsson (Publ) Adaptable network bridge
JP4516306B2 (ja) 2003-11-28 2010-08-04 株式会社日立製作所 ストレージネットワークの性能情報を収集する方法
US7474653B2 (en) * 2003-12-05 2009-01-06 Hewlett-Packard Development Company, L.P. Decision cache using multi-key lookup
US7690040B2 (en) 2004-03-10 2010-03-30 Enterasys Networks, Inc. Method for network traffic mirroring with data privacy
US8027642B2 (en) 2004-04-06 2011-09-27 Qualcomm Incorporated Transmission canceller for wireless local area network
US7436832B2 (en) 2004-05-05 2008-10-14 Gigamon Systems Llc Asymmetric packets switch and a method of use
US7606230B1 (en) * 2004-05-10 2009-10-20 Marvell International Ltd. Link aggregation for routed ports
EP1745567B1 (de) 2004-05-13 2017-06-14 QUALCOMM Incorporated Frequenzloser überträger mit detektion und medienzugangssteuerung
US7554990B2 (en) * 2004-05-13 2009-06-30 Micrel, Inc. Static address reservation protocol in a data network
KR20070026558A (ko) * 2004-06-03 2007-03-08 위데피, 인코포레이티드 저가의 고성능 국부 발진기 구조를 갖는 주파수 변환반복기
EP1782293A2 (de) * 2004-08-20 2007-05-09 Enterasys Networks, Inc. System, verfahren und vorrichtung für verkehrsspiegelaufbau, service und sicherheit in kommunikationsnetzwerken
US7623535B2 (en) * 2004-09-09 2009-11-24 Cisco Technology, Inc. Routing protocol support for half duplex virtual routing and forwarding instance
US8000324B2 (en) * 2004-11-30 2011-08-16 Broadcom Corporation Pipeline architecture of a network device
US7583588B2 (en) * 2004-11-30 2009-09-01 Broadcom Corporation System and method for maintaining a layer 2 modification buffer
US20060161689A1 (en) * 2005-01-18 2006-07-20 Hewlett-Packard Development Company, L.P. Apparatus and systems for monitoring communication
US8059727B2 (en) * 2005-01-28 2011-11-15 Qualcomm Incorporated Physical layer repeater configuration for increasing MIMO performance
US20060187948A1 (en) * 2005-02-18 2006-08-24 Broadcom Corporation Layer two and layer three virtual private network support in a network device
US7948896B2 (en) * 2005-02-18 2011-05-24 Broadcom Corporation Weighted-fair-queuing relative bandwidth sharing
US7630306B2 (en) * 2005-02-18 2009-12-08 Broadcom Corporation Dynamic sharing of a transaction queue
US7463630B2 (en) * 2005-02-18 2008-12-09 Broadcom Corporation Multi-part parsing in a network device
US20060187924A1 (en) * 2005-02-18 2006-08-24 Broadcom Corporation Ingress handling of data in a network device
US20060203824A1 (en) * 2005-02-18 2006-09-14 Song-Huo Yu Passing values through a memory management unit of a network device
US20060187936A1 (en) * 2005-02-18 2006-08-24 Broadcom Corporation Table searching techniques in a network device
US20060187832A1 (en) * 2005-02-18 2006-08-24 Broadcom Corporation Filter based range check in a network device
US7522622B2 (en) * 2005-02-18 2009-04-21 Broadcom Corporation Dynamic color threshold in a queue
US7254768B2 (en) * 2005-02-18 2007-08-07 Broadcom Corporation Memory command unit throttle and error recovery
US20060187923A1 (en) * 2005-02-18 2006-08-24 Broadcom Corporation Dynamic filter processor key generation based on packet type
US7802148B2 (en) * 2005-02-23 2010-09-21 Broadcom Corporation Self-correcting memory system
US8842127B1 (en) * 2005-04-25 2014-09-23 Apple Inc. Text rendering with improved glyph cache management
US8108673B2 (en) 2005-04-29 2012-01-31 Cisco Technology, Inc. Configuring interfaces of a switch using templates
CN100411388C (zh) * 2005-05-24 2008-08-13 华为技术有限公司 一种交换系统中实现镜像的方法
US20070016637A1 (en) * 2005-07-18 2007-01-18 Brawn John M Bitmap network masks
US7787361B2 (en) 2005-07-29 2010-08-31 Cisco Technology, Inc. Hybrid distance vector protocol for wireless mesh networks
US8418233B1 (en) 2005-07-29 2013-04-09 F5 Networks, Inc. Rule based extensible authentication
US8533308B1 (en) 2005-08-12 2013-09-10 F5 Networks, Inc. Network traffic management through protocol-configurable transaction processing
US7660318B2 (en) * 2005-09-20 2010-02-09 Cisco Technology, Inc. Internetworking support between a LAN and a wireless mesh network
US20070110024A1 (en) * 2005-11-14 2007-05-17 Cisco Technology, Inc. System and method for spanning tree cross routes
US7869411B2 (en) * 2005-11-21 2011-01-11 Broadcom Corporation Compact packet operation device and method
US8565088B1 (en) 2006-02-01 2013-10-22 F5 Networks, Inc. Selectively enabling packet concatenation based on a transaction boundary
JP4652285B2 (ja) * 2006-06-12 2011-03-16 株式会社日立製作所 ゲートウェイ選択機能を備えたパケット転送装置
US9003292B2 (en) * 2006-07-06 2015-04-07 LiveAction, Inc. System and method for network topology and flow visualization
JP4791301B2 (ja) 2006-09-13 2011-10-12 株式会社オートネットワーク技術研究所 車載ｌａｎシステム
US8559379B2 (en) 2006-09-21 2013-10-15 Qualcomm Incorporated Method and apparatus for mitigating oscillation between repeaters
WO2008057290A1 (en) 2006-10-26 2008-05-15 Qualcomm Incorporated Repeater techniques for multiple input multiple output utilizing beam formers
JP4680866B2 (ja) * 2006-10-31 2011-05-11 株式会社日立製作所 ゲートウェイ負荷分散機能を備えたパケット転送装置
US20080107109A1 (en) * 2006-11-03 2008-05-08 General Instrument Corporation Method and Apparatus for Managing Multicast Traffic in a Network at the Data Link or Level 2 Layer
US9106606B1 (en) 2007-02-05 2015-08-11 F5 Networks, Inc. Method, intermediate device and computer program code for maintaining persistency
US8238344B1 (en) 2007-03-30 2012-08-07 Juniper Networks, Inc. Multicast load balancing
US9832069B1 (en) 2008-05-30 2017-11-28 F5 Networks, Inc. Persistence based on server response in an IP multimedia subsystem (IMS)
US7957273B2 (en) * 2008-06-06 2011-06-07 Redpine Signals, Inc. Packet re-transmission controller for block acknowledgement in a communications system
US9130846B1 (en) 2008-08-27 2015-09-08 F5 Networks, Inc. Exposed control components for customizable load balancing and persistence
JP5251457B2 (ja) * 2008-11-27 2013-07-31 富士通株式会社 データ伝送装置
US8934495B1 (en) 2009-07-31 2015-01-13 Anue Systems, Inc. Filtering path view graphical user interfaces and related systems and methods
US8098677B1 (en) 2009-07-31 2012-01-17 Anue Systems, Inc. Superset packet forwarding for overlapping filters and related systems and methods
US8018943B1 (en) 2009-07-31 2011-09-13 Anue Systems, Inc. Automatic filter overlap processing and related systems and methods
US8463928B2 (en) 2009-10-27 2013-06-11 Verisign, Inc. Efficient multiple filter packet statistics generation
JP5328754B2 (ja) * 2010-11-22 2013-10-30 三菱電機株式会社 電文収集解析装置、電文収集解析方法及びプログラム
US9094318B2 (en) * 2012-03-29 2015-07-28 Avaya Inc. Remote mirroring
US9467385B2 (en) 2014-05-29 2016-10-11 Anue Systems, Inc. Cloud-based network tool optimizers for server cloud networks
US9781044B2 (en) 2014-07-16 2017-10-03 Anue Systems, Inc. Automated discovery and forwarding of relevant network traffic with respect to newly connected network tools for network tool optimizers
US10050847B2 (en) 2014-09-30 2018-08-14 Keysight Technologies Singapore (Holdings) Pte Ltd Selective scanning of network packet traffic using cloud-based virtual machine tool platforms
US10355964B2 (en) * 2014-10-31 2019-07-16 At&T Intellectual Property I, L.P. Method and system to capture selected network data
US9992134B2 (en) 2015-05-27 2018-06-05 Keysight Technologies Singapore (Holdings) Pte Ltd Systems and methods to forward packets not passed by criteria-based filters in packet forwarding systems
US10116528B2 (en) 2015-10-02 2018-10-30 Keysight Technologies Singapore (Holdings) Ptd Ltd Direct network traffic monitoring within VM platforms in virtual processing environments
US10652112B2 (en) 2015-10-02 2020-05-12 Keysight Technologies Singapore (Sales) Pte. Ltd. Network traffic pre-classification within VM platforms in virtual processing environments
US10142212B2 (en) 2015-10-26 2018-11-27 Keysight Technologies Singapore (Holdings) Pte Ltd On demand packet traffic monitoring for network packet communications within virtual processing environments

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NO123200B (de) 1967-11-23 1971-10-11 Svenska Handelsbanken
US3938144A (en) * 1973-11-28 1976-02-10 Johnson Service Company Digital multiplexing system remote scanning of a plurality of monitoring points
JPS58134554A (ja) * 1982-02-03 1983-08-10 Nec Corp 伝送路監視装置
JPS59198043A (ja) 1983-04-25 1984-11-09 Fujitsu Ltd 呼量情報収集方式
US4817080A (en) * 1987-02-24 1989-03-28 Digital Equipment Corporation Distributed local-area-network monitoring system
US4920529A (en) * 1987-02-27 1990-04-24 Hitachi, Ltd. Network control method and apparatus therefor
US5088032A (en) * 1988-01-29 1992-02-11 Cisco Systems, Inc. Method and apparatus for routing communications among computer networks
US5097469A (en) * 1989-05-19 1992-03-17 Concord Communications, Inc. Passive monitor for broadcast communication network
JPH03123137A (ja) 1989-10-05 1991-05-24 Fujitsu Ltd Ｍａｃブリッジのルーティングテーブルにおけるマニュアル登録方式
JPH03270532A (ja) * 1990-03-20 1991-12-02 Fujitsu Ltd フィルタリング制御方式
US5165021A (en) * 1991-01-18 1992-11-17 Racal-Datacom, Inc. Transmit queue with loadsheding
US5274631A (en) * 1991-03-11 1993-12-28 Kalpana, Inc. Computer network switching system
JPH05114905A (ja) 1991-04-08 1993-05-07 Digital Equip Corp <Dec> 単一アドレス及びプロトコール・テーブル・ブリツジを使用したメツセージの処置フイルタリング
US5321695A (en) * 1991-05-01 1994-06-14 Hewlett-Packard Company Port arrival identification for computer network packets
US5420862A (en) * 1991-06-14 1995-05-30 Digital Equipment Corporation Router using remote address resolution to enable bridge like data forwarding
JP3123137B2 (ja) 1991-08-20 2001-01-09 チッソ株式会社 光学活性３−置換−２−ノルボルナノンの製造法
US5515376A (en) 1993-07-19 1996-05-07 Alantec, Inc. Communication apparatus and methods

Also Published As

Publication number Publication date
JP3335358B2 (ja) 2002-10-15
EP0710415A1 (de) 1996-05-08
WO1995003659A1 (en) 1995-02-02
EP0710415A4 (de) 2002-03-27
EP0710415B1 (de) 2005-04-13
ATE293327T1 (de) 2005-04-15
DE69434330D1 (de) 2005-05-19
US6545982B1 (en) 2003-04-08
JPH09500774A (ja) 1997-01-21
US5515376A (en) 1996-05-07
US5610905A (en) 1997-03-11

Similar Documents

Publication Publication Date Title
DE69434330T2 (de) Übertragungsvorrichtgung und verfahren
DE69825596T2 (de) System und verfahren für ein vielschicht-netzelement
DE69837272T2 (de) Mechanismus zum ersetzen eines paketfelds in einem mehrschicht-vermittlungsnetzelement
DE69834122T2 (de) Verbindingsunterstützung in einer hochleistungsnetzwerkvorrichtung
DE60031274T2 (de) Mehrfachanschlussverfahren und -gerät für vituelle ports
DE69433126T2 (de) Verfahren zum Einrichten von virtuellen Mehrfachsendeverbindungen
DE69933417T2 (de) Vorrichtung und Verfahren zur routerfreien Schicht 3 Wegelenkung in einem Netz
DE60009819T2 (de) Netzwerkgerätskonfigurationsverfahren und Vorrichtung
DE69634916T2 (de) Verfahren und vorrichtung zur filterung von mehradresspaketen in einem lokalen netz durch ein transparentes zwischensystem
DE69908295T2 (de) Virtuelles lokales netz mit mehrfachsendeschutz
DE69827201T2 (de) Verfahren und system zur server-netzwerkvermittlung-mehrverbindung
DE69433860T2 (de) System zur umgekehrten adressenauflösung für entfernte netzwerkvorrichtung
DE60024228T2 (de) Dynamische zuweisung verkehrsklassen an einer prioritätswarteschlange in einer paketbeförderungsvorrichtung
DE69826680T2 (de) Hochintegrierte mehrschichtige Vermittlungsstellenelementarchitektur
DE60318878T2 (de) Verfahren und systeme zum austausch von erreichbarkeitsinformationen und zum umschalten zwischen redundanten schnittstellen in einem netzwerkcluster
DE69533225T2 (de) Vorrichtung zur bereitstellung eines lokalen netzemulationsdienstes über ein öffentliches, verbindungsloses atm-netz
DE60100927T2 (de) Verbesserter Internet Protocolpaketrouter
DE60300354T2 (de) Methode zur Rekonstruktion paketisierter Nachrichten, die über ein oder mehrere Netzwerke verschickt wurden
DE69937185T2 (de) Verfahren und vorrichtung zum paketbeförderungsnachschlagen mit einer reduzierten anzahl von speicherzugriffen
EP0632617A2 (de) Verfahren und Einrichtung zur Unterstützung des Netzwerkmanagements
DE60112011T2 (de) Verfahren und Vorrichtung zum Filtern von Paketen basierend auf Datenströme unter Verwendung von Addressentabellen
DE60015186T2 (de) Verfahren und system für rahmen- und protokollklassifikation
DE60133175T2 (de) Kommunikationsnetz
DE102019114309A1 (de) Verfahren zum Routen von Telegrammen in einem Automatisierungsnetzwerk, Datenstruktur, Automatisierungsnetzwerk und Netzwerkverteiler
DE69833206T2 (de) Netzwerkkontrolle zum verarbeiten von statusproblemen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: ERICSSON AB, STOCKHOLM, SE