-
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.
-
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.
-
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.