-
HINTERGRUND
DER ERFINDUNG
-
Die
derzeitige Erfindung bezieht sich im Allgemeinen auf die Übertragung
und das Switching von Datenpaketen über Computernetzwerke, wobei die
Vermittlung innerhalb der Bandbreite und von Verzögerungsgrenzwerten
garantiert wird, was für die
meisten Echtzeitanwendungen wie Sprachtelefonie erforderlich ist.
Die Sprachkommunikation ist nur ein Beispiel für Echtzeitkommunikationsanwendungen,
die empfindlich auf Datenverzögerung
und fehlende Daten reagieren, und auf die sich die Anwendung der
derzeitigen Erfindung positiv auswirkt. Derzeit im Internet eingesetzte
Packet-Switches garantieren nicht die Vermittlung von Daten innerhalb
der Grenzwerte, die für
die Sprachkommunikation in hoher Qualität einzuhalten sind. Die derzeitige
Erfindung löst
das Problem mit einer Switchingtechnik, die die zuverlässige Vermittlung
innerhalb der Bandbreite und innerhalb von Verzögerungsgrenzwerten ermöglicht.
-
Wie
allgemein bekannt, dienen Packet-Switches zum Transport von Ethernet-
und Internet Protocol (IP)-Datenpaketen
gemäß eingebetteter
Paketadressen. Der Begriff „eingebettete
Paketadresse" bezieht
sich in diesem Kontext auf eine Paketadresse, die Teil des Paketformats
ist. Ein Packet-Switch ist ein Multiport-Gerät, das eingehende Pakete nur dann
an einen bestimmten Port weiterleitet, wenn dieser mit dem nächsten Ziel
des Pakets verbunden ist. Beim Packet-Switching empfängt ein
Port oder Netzwerksegment keine Pakete, die nicht an einen Host
oder ein Terminal adressiert sind, der bzw. das mit diesem Port
verbunden ist (was z.B. beim Einsatz von Netzwerkbridges der Fall
sein kann). Beim Packet-Switching werden Pakete nicht an alle Ports
des Switches übertragen,
sondern nur an die Ports, die mit den an der relevanten Kommunikationssitzung beteiligten
Hosts verbunden sind. Das Packet-Switching
erhöht
den Gesamtdurchsatz eines Paketnetzwerks, da die verfügbare Bandbreite
eines Segments nicht durch den Paketverkehr anderer Segmente beeinträchtigt wird.
Das Packet-Switching reduziert dementsprechend Paketstaus und erhöht die Performance.
-
Das
Packet-Switching beseitigt jedoch nicht die mit Paketkollisionen
und unterschiedlichen Paketverzögerungen
verbundenen Probleme. Diese Probleme können auch auftreten, wenn ein
Port nicht vollständig
ausgelastet ist. Probleme können
z.B. auftreten, wenn mehrere Anwendungen gleichzeitig um die Ressourcen
eines einzelnen Ports konkurrieren. Die konkurrierenden Anwendungen
behindern sich gegenseitig, was zu unterschiedlichen Verzögerungen
bei der Übertragung
oder beim Empfang von Paketen führt.
-
In
vorhandenen Systemen wurde versucht, diese Probleme durch Zuordnung
von Prioritäten
zu verschiedenen Pakettypen zu lösen.
Bei diesen verwendeten Verfahren wird Paketen mit Echtzeitanforderungen
eine relativ hohe Priorität
zugewiesen, um diese vor Paketen mit einer geringeren Priorität, die nicht
in Echtzeit zu vermitteln sind, zu verarbeiten. Die Verarbeitung
von Paketen mit unterschiedlicher Priorität verbessert leider nicht die
Performance, wenn alle Pakete dieselbe Priorität besitzen. Ein Anwendungsbeispiel,
auf das dieses Szenario zutrifft, ist die Sprachtelefonie. Im Allgemeinen
können
viele Telefonanrufe gleichzeitig über nur eine Portverbindung
geführt
werden. Normalerweise ist nicht bekannt, welchen Paketen mit Daten
von diesen Telefonanrufen eine höhere
Priorität
zuzuordnen ist. Werden auf einem einzelnen Kanal Sprachpakete mit
unterschiedlicher Priorität übertragen,
können
nicht-deterministische Paketstaus und Verzögerungen auftreten, die sich
auf einen Telefonanruf störend
auswirken.
-
Beispiel:
Ein ausschließlich
zur Übermittlung von
Echtzeitdaten mittels Paketen verwendeter Datenkanal kann mit einem
Packet-Switch verbunden sein, der von mehreren Anwendungen über verschiedene
Ports verwendet wird. Der Echtzeitdatenkanal kann von all diesen
Anwendungen, die den Switch verwenden, gemeinsam genutzt werden.
Der Echtzeitdatenkanal kann beispielsweise verwendet werden, um
den Switch mit einem Switch an einem anderen Standort oder mit dem
Telefonanbieter zu verbinden. Beim entsprechenden Kanal kann von
einer Rohdatenkapazität
von Br ausgegangen werden, die in Bit pro Sekunde angegeben wird.
Jede Echtzeitanwendung erfordert eine Bandbreite von Ba, wobei Ba der
kontinuierlichen Bandbreite der Anwendung in Bit pro Sekunde entspricht.
Dementsprechend beträgt die
maximale Anzahl von Echtzeitanwendungen, N, die theoretisch über den
Kanal übertragen
werden können: N = Int[Br/Ba]
-
Alle über einen
vollständig
genutzten Kanal übertragenen
Anwendungen erhalten dieselbe Chance zur Übermittlung eines bestimmten
Datenpakets. In diesem Beispiel wird davon ausgegangen, dass die
Anwendungen gleich sind und Pakete in derselben Größe und Übertragungsrate übermitteln.
Darüber
hinaus wird angenommen, dass in diesem Beispiel alle Anwendungen
die Übertragung
unabhängig voneinander
durchführen
und diese nicht koordinieren. Alle Anwendungen übermitteln Pakete in gleichen
Intervallen gemäß ihren
Anforderungen. Alle Pakete sind für ihre Absender gleich wichtig,
weshalb alle die gleiche Priorität
besitzen. Ein von einer Anwendung über den gemeinsam genutzten
Kanal gesendetes Paket tritt mit einer Wahrscheinlichkeit von Pd
ohne Verzögerung
in den Kanal ein. Diese Wahrscheinlichkeit wird folgendermaßen ausgedrückt: P(d=o) = 1/N
-
Diese
Formel gilt, da ein verfügbares
Fenster im ausgehenden Paketstrom einer bestimmten Anwendung in
einem bestimmten Augenblick in einem vollständig ausgenutzten Kanal nur
mit einer Wahrscheinlichkeit von 1:N auftritt. Ein zum Kanal gesendetes
Paket konkurriert mit den Paketen anderer Anwendung um die Kanalressource.
Andere Pakete kamen möglicherweise
bereits früher
an und warten darauf, übertragen
zu werden. Der Wettbewerb um Positionen im ausgehenden Datenstrom
führt zu
Verzögerungen,
da die Pakete in eine Warteschlange eingereiht und nacheinander
gesendet werden. Die erwartete maximale Verzögerung sollte der Übertragungsdauer
von N Paketen entsprechen. Diese Verzögerung würde auftreten, wenn ein neues
Paket empfangen wird, nachdem Pakete von allen anderen Anwendungen
empfangen wurden. Die tatsächliche Verzögerung variiert
unvorhersehbar zwischen der kleinstmöglichen und der maximal möglichen
Verzögerung.
-
Beim
Schätzen
der Verzögerung
eines Pakets muss auch die Übertragungszeit
berücksichtigt werden.
In diesem Kontext bezieht sich der Begriff „Übertragungszeit" auf die zur Übertragung
eines Pakets zum Kanal benötigte
Zeit. Dementsprechend entspricht die Übertragungszeit (T) der Paketlänge in Bit
(L) dividiert durch die Datenrate in Bit pro Sekunde (R) wie folgt: T = L/R
-
Die
maximale Verzögerung
(Dmax) lautet: Dmax = NT
-
Die
durchschnittliche Verzögerung
(Davg) lautet: Davg = NT/2
-
Diese
variable Verzögerung,
die in herkömmlichen
Packet-Switchingsystemen auftritt, muss im Systemdesign für Echtzeitanwendungen
berücksichtigt
werden. Die tatsächlich
auftretende Paketverzögerung
kann also zwischen Null und Dmax mit einer durchschnittlichen Verzögerung von
Davg. variieren. Die Unterschiede bei der
Verzögerung
werden als „Jitter" bezeichnet und sind
beim Systemdesign zu berücksichtigen.
Die Jitterkompensierung wird durch Pufferung ermöglicht. Dementsprechend muss
eine Anwendung die empfangenen Datenpakete puffern können. Die
Anwendung muss das Paket-zu-Paket-Jitter von bis zu Dmax verarbeiten
können,
um durch Jitter verursachten Paketverlust zu verhindern. Der Jitterpuffer
für empfangene
Pakete kann Pakete in regelmäßigen Intervallen
an die Anwendung senden. Puffert die Anwendung keine eingehenden
Daten, kann ein Über-
oder Unterlauf entstehen. Bei einem Unterlauf kann es passieren,
dass ein Paket durch die vorübergehend
verzögerte
Paketankunft zu spät
zur Verarbeitung und Wiedergabe durch die Empfangsanwendung eintrifft.
Das heißt, der
empfangenden Anwendung stehen u.U. keine zu verarbeitenden Daten
zur Verfügung,
wenn das nächste
Sample ausgegeben werden muss. Bei einer Sprachkommunikationsanwendung,
die mit einem Telefon verbunden ist, muss das Sprachsignal ohne
Unterbrechung an den Hörer
des Benutzers übertragen
werden. Werden aufgrund einer Paketverzögerung keine Daten empfangen,
wird der ausgegebene Sprachfluss unterbrochen. Aus diesem Grund
sollten telefonbasierte Sprachkommunikationsanwendungen mit einem
Jitterpuffer ausgestattet sein. Diese Jitterpuffer für den Paketempfang
erhöhen
die gesamte Systemverzögerung,
da die Pakete einige Zeit im Jitterpuffer gespeichert werden. Ist
jedes Paket wichtig, muss die Größe des Jitterpuffers angepasst
werden, um das maximal mögliche
Jitter abzufangen. Die durch den Jitterpuffer verursachte Zeitverzögerung kann
also größer als
das oder gleich dem maximalen Paket-zu-Paket-Jitter für das System
sein.
-
Das
Paketjitter häuft
sich an, wenn ein Paket ein typisches Kommunikationsnetzwerk passiert.
Die Gesamtverzögerung
wächst,
wenn das Paket vor dem Eintreffen am Ziel mehrere Switches und Kanäle passiert,
was normalerweise der Fall ist. Verzögerungen an einem bestimmten
Switch und Kommunikationskanal korrelieren normalerweise nicht mit
Verzögerungen,
die an aufeinander folgenden Switches auftreten. Die durchschnittliche
und maximale Verzögerung
steigt mit der Anzahl von Switches in einer Route. Dementsprechend
gelten für
M Switch-Hops folgende Verzögerungseigenschaften
für eine
Route:
-
-
Dmax(i) ist die maximale Verzögerung an
jedem Switch im Pfad bis zum Ziel. Die kleinste Switchingverzögerung ist
weiterhin Null, da die Wahrscheinlichkeit, dass ein Paket in der
Route nicht durch das Switching verzögert wird, begrenzt ist. Die maximale
Verzögerung
stimmt also mit der maximalen Verzögerung Dmax(M) überein.
-
In
vorhandenen Packet-Switching-Netzwerken treten sowohl feste Verzögerungen
als auch Paketeinfügeverzögerungen
auf. Diese festen Verzögerungen
haben verschiedene Ursachen. Bei Paketen treten abhängig von
der Entfernung, über
die die Pakete übertragen
werden, Propagierungsverzögerungen
auf. Die Lichtgeschwindigkeit im freien Raum ist eine weitere wesentliche
Einschränkung,
die diesen Verzögerungen
unterliegt. Licht breitet sich in einem physischen Kommunikationsmedium
wie in einem Lichtwellenleiter viel langsamer als im freien Raum aus.
Bei der Echtzeitkommunikation über
weite Entfernungen kann sich die dadurch verursachte Verzögerung merklich
auswirken, insbesondere, wenn ein Paket eine weitschweifige Route
bis zum Ziel zurücklegt.
-
Einfügeverzögerungen
in Bezug auf die Paketlänge
und die erforderliche Übertragungszeit
des Pakets über
einen bestimmten Kanal treten in vorhandenen Kommunikationsnetzwerken
ebenfalls auf. Beispiel: Bei der Echtzeitpaketkommunikation über Modems
kann die Einfügeverzögerung für den Kommunikationskanal
mit relativ geringer Bandbreite sehr hoch sein. Durch räumliche
Entfernung und Modemeinsatz verursachte Verzögerungen können die Sprachkommunikation
in hoher Qualität über ein Netzwerk
unmöglich
machen (Switchingverzögerungen
werden hierbei nicht einmal in Betracht gezogen).
-
Neben
den oben erwähnten
Verzögerungen werden
von vorhandenen Packet-Switching-Geräten eigene
Verzögerungen
verursacht. Die meisten Switches und Router platzieren die empfangenen
Pakete in einer Empfangswarteschlange. Diese Geräte bestimmen daraufhin das
nächste
Ziel von jedem Paket und platzieren jedes empfangene Paket in der
Ausgangswarteschlange des entsprechenden Ports. Das Paket wird übertragen,
wenn es den Anfang der Warteschlange erreicht. Auch wenn dem Paket
eine hohe Priorität
zugewiesen ist und keine Warteschlangenverzögerung wegen anderer Pakete
mit hoher Priorität
auftritt, wird das Paket u.U. durch das Verschieben des Pakets von
Warteschlange zu Warteschlange innerhalb des Switches beträchtlich
verzögert.
-
Verzögerungen
können
auch durch anderen Netzwerkpaketverkehr verursacht werden, auch wenn
dieser eine niedrigere Priorität
hat. In zahlreichen vorhandenen Netzwerken treten viele unterschiedliche
Paketverkehrstypen auf. Aus diesem Grund konkurrieren verschiedene
Paketanwendungen um die verfügbare
Bandbreite im gesamten Netzwerk. Die Zuordnung verschiedener Prioritäten zum
Paketverkehr bietet keine Garantie, dass Pakete mit hoher Priorität ohne Verzögerung gesendet
werden. Es kann sogar das Gegenteil der Fall sein. Beispiel: Ein
Paket mit geringer Priorität
wird direkt vor dem Empfang eines Pakets mit einer höheren Priorität empfangen
und weitergeleitet. Die Übermittlung des
Pakets mit niedriger Priorität
wurde direkt vor dem Empfang des Pakets mit höherer Priorität begonnen.
Das Paket mit der niedrigeren Priorität wird zuerst übertragen,
und das Paket mit der höheren Priorität kann erst
im Anschluss daran gesendet werden. Die Übermittlung des Pakets mit
der niedrigeren Priorität
kann i.d.R. nicht unterbrochen werden, um das Paket mit der höheren Priorität zuerst
zu senden. Das Paket mit der höheren
Priorität
kann an jedem Hop um die Zeit verzögert werden, die zum Übertragen
eines Pakets mit maximaler Länge
und geringer Priorität
benötigt
wird. Aus Effizienzgründen
wird Verkehr mit niedriger Priorität oft zu Paketen mit maximaler
Länge zusammengefasst,
wodurch die potentielle Verzögerung
weiter erhöht
wird. Andererseits sind Pakete mit hoher Priorität oft sehr kurz, um die Einfügeverzögerung im
Netzwerk zu reduzieren. Bei Verwendung des Ethernet-Kommunikationsprotokolls
kann das Verhältnis
zwischen Paketen mit maximaler und geringster Größe höher sein als 20:1. Dies bedeutet,
dass die durch die Übertragung
eines Pakets mit niedriger Priorität an jedem Hop verursachte
Verzögerung
eines Pakets mit höherer
Priorität
selbst bei Switches, die zwischen Prioritäten unterscheiden, mit der
zur Übertragung
von über
20 kleinerer Pakete mit hoher Priorität benötigten Zeit übereinstimmt.
Einige Netzwerke übertragen
jetzt so genannte „Jumbopakete", die noch längere Verzögerungen
verursachen.
-
In
Echtzeitanwendungen können
Pakete abhängig
von den zulässigen
Verzögerungseigenschaften
unterschiedlich groß sein.
Informationen können dementsprechend
in mehreren kleineren Paketen oder einer geringeren Anzahl größerer Pakete
in einer bestimmten Geschwindigkeit übertragen werden. Beim Versenden
einer geringeren Anzahl größerer Pakete
werden Switchingressourcen und die übertragenden und empfangenden
Systeme weniger belastet. Grund: Switchingressourcen beeinflussen
die Geschwindigkeit der Verarbeitung von Paketen nur in begrenztem
Maße.
Die als Sender und Empfänger fungierenden
Hosts müssen über einen
Softwareinterrupt verfügen,
um jedes Paket verarbeiten zu können.
Diese Hosts stoßen
also ebenfalls an Leistungsgrenzen bezüglich der Anzahl von Paketen,
die pro Sekunde verarbeitet werden. Werden auf der anderen Seite
zur Übertragung
derselben Datenmenge weniger größere Pakete
verwendet, müssen
in jedem Paket mehr Daten zusammengefasst werden. Dementsprechend
sind die Verzögerungen
aufgrund der längeren
Paketübertragungszeit,
die in der Gleichung oben durch N angegeben ist, womöglich noch länger.
-
Stellen
Sie sich vor, ein 100-Byte-Sprachpaket mit hoher Priorität wird durch
ein Jumbopaket verzögert.
Einige Jumbopakete sind sechs Mal so groß wie das derzeitige IP-Paket
mit maximaler Länge. Viele
Benutzer bevorzugen Jumbopakete, da kürzere Pakete Netzwerkserver
mit Highspeed-Netzwerkverbindungen
stark belasten. Jumbopakete können
jedoch Echtzeitanwendungen, die die derzeitige Switchtechnologie
verwenden, vollkommen durcheinander bringen. Jumbopakete können ein
einzelnes 100 Byte großes
Sprachpaket mit hoher Priorität
in gleichem Maß verzögern wie
90 andere Sprachpakete.
-
Die
Verzögerung
bei der Einreihung von Paketen mit geringer Priorität in Warteschlangen
wächst beim
Passieren mehrerer Switches. Bei der Übertragung im Netzwerk werden
zwischen Sender und Empfänger
oft 30 oder mehr Switches durchlaufen. Folglich kann in einem perfekt
funktionierenden Netzwerk, in dem zwischen Prioritäten unterschieden
und nur ein Anruf übertragen
wird, durch die Einreihung eines Pakets mit geringer Priorität in eine
Warteschlange eine Verzögerung
verursacht werden, die 2700 Sprachpaketen mit hoher Priorität entspricht.
-
Verzögerungen
und Verzögerungsvarianten sind
jedoch nicht die einzigen Probleme, die in Verbindung mit bisherigen
Packet-Switches auftreten. Echtzeitanwendungen werden oft mit Bandbreitengarantien
bereitgestellt. Genügt
der Netzwerkkanal nicht zur gleichzeitigen Unterstützung der
garantierten Gesamtbandbreite für
alle möglichen
Sitzungen, ist das Netzwerk überbeansprucht.
In bestehenden Systemen kann es leicht passieren, dass die Netzwerkbandbreite
für ein
bestimmtes Segment oder einen Switch zu stark beansprucht wird.
Diese Überbeanspruchung
kann unabhängig
davon auftreten, ob den Paketen verschiedene Prioritäten zugeordnet sind
oder nicht. Bei der Verwendung von Prioritätsschemas kann der Verkehr
mit höherer
Priorität (wahrscheinlich
Sprachverkehr) ungehindert den Kanal passieren, solange der Kanal
nicht durch den Verkehr mit höherer
Priorität überlastet
wird. In diesem Fall kann sich der Verkehr mit höherer Priorität nachteilig
auf die Performance des Verkehrs mit geringerer Priorität auswirken.
In vorhandenen Systemen kann die Bandbreite in solch einer Situation
im Allgemeinen nicht zuverlässig
zugewiesen werden. Dementsprechend kann eine Überbeanspruchung zur vollständigen Unterbrechung
des Verkehrs mit geringer Priorität und in einigen Fällen auch
zur Unterbrechung des Verkehrs mit höherer Priorität führen.
-
Im
Laufe einer einzelnen Echtzeitsitzung kann sich der Grad an Paketstaus
von einem Moment zum nächsten
drastisch ändern.
Beispiel: Ein Telefonanruf wird bei guten Netzwerkverkehrsbedingungen über ein
Paketnetzwerk eingerichtet. Während
des Anrufs ist es leicht möglich,
dass die Anzahl von Paketstaus so ansteigt, dass die Qualität des Anrufs
beeinträchtigt
oder der Anruf sogar unterbrochen wird. Diese Situation ist für die meisten
wichtigen Echtzeitanwendungen, insbesondere die Sprachtelefonie,
nicht tolerierbar. In diesem Fall reicht es nicht, wenn der durchschnittliche
Verkehr die verfügbare Bandbreite
nicht übersteigt.
Zur Vermeidung von Konkurrenzsituationen gehen normalerweise Pakete verloren,
wenn die Engpässe
die Kapazität
des gemeinsamen Kanals auch nur kurzzeitig übersteigen. Aus diesem Grund
muss die gesamte Systembandbreite mindestens der von allen Anwendungen
zu jedem Zeitpunkt benötigten
maximalen Bandbreite entsprechen.
-
Wie
oben beschrieben, reagieren Netzwerke empfindlich auf Verzögerungen
und Verzögerungsvarianten.
Dies gilt selbst unter idealen Umständen, wenn der gesamte Verkehr
charakterisiert ist, keine Überlastung
vorliegt und Prioritätsschemas
verwendet werden. Darüber
hinaus können
mit den vorhandenen Packet-Switches Überlastungen selbst dann leicht
auftreten, wenn Prioritätsschemas
in Verwendung sind. Aus diesen Gründen wird ein Packet-Switch
benötigt,
der Verzögerungen
steuert und minimiert und somit Echtzeitanwendungen in Paketnetzwerken
effektiv unterstützt.
Vorteilhaft wäre
ein System, das während
der Dauer einer Echtzeitsitzung die Bandbreitennutzung garantiert
und diese Bandbreite nach Sitzungsende einer anderen Anwendung zur
Verfügung
stellt. Im Falle von Echtzeitanwendungen wie der Sprachtelefonie
mittels Paketen sollte das System Anrufern eine Sprachverzögerungs-Gesamtperformance
bieten, die ungefähr
der Sprachverzögerungs-Gesamtperformance
des vorhandenen leitungsvermittelten Telefonnetzes entspricht. Die
Anrufer sollten außerdem
zu Beginn eines Anrufs wissen, dass bis zum Ende des Anrufs eine
bestimmte Verbindungsqualität
garantiert ist.
-
Beispiel:
WO 99/65197 enthält
eine Methode zur Übermittlung
und Weiterleitung von Paketen über ein
Packet-Switching-Netzwerk mit Verzögerungsvarianten, die auf einer
gemeinsamen Zeitreferenz basieren, die wiederum zum Definieren periodischer Zeitintervalle
für die Übermittlung
von Paketen verwendet wird. 5 761 430 umfasst eine Lösung für ein Paketkollisionsproblem,
bei dem Pakete auf Zeitreservierungsbasis übertragen werden.
US 5 600 641 umfasst ein Packet-Switching-Netzwerk
zur Sprachbewertung, in dem Datenübertragungspfade unter Verwendung
von Meldungen ausgewählt
werden, die in Computeremulationspaketen enthalten sind und sich
von Datenpaketen unterscheiden. Jeder Switchingknoten im Netzwerk
enthält
einen Leitungsemulationsserver mit einer Vielzahl von Verbindungstabellen,
die Informationen bieten, mit deren Hilfe ein eingehendes Leitungsemulationspaket
zu einer ausgehenden Verbindungsleitung geroutet wird.
-
KURZFASSUNG
DER ERFINDUNG
-
In Übereinstimmung
mit den Grundsätzen dieser
Erfindung handelt es sich hierin um einen Packet-Switch, der fähig ist,
jeder Echtzeitanwendung Bandbreite zuzuordnen, so dass Paketverzögerungen
eingeschränkt
werden und die Paketvermittlung gewährleistet wird. Der beschriebene
Switch ermöglicht
die dynamische Bandbreitenzuordnung, durch die durch den Wettstreit
um Bandbreite ausgelöste Übertragungsprobleme
reduziert werden. Das beschriebene System ordnet die für eine Echtzeit-Kommunikationssitzung
erforderliche Bandbreite zu. Der Betrieb des beschriebenen Systems
zur dynamischen Zuordnung von Bandbreite schwächt nicht die Packet-Switching-Performance
des anderen Paketverkehrs. Es wird lediglich die an den betroffenen Ports
verfügbare
Bandbreite verringert.
-
Die
vorliegende Beschreibung umfasst ein Planungssystem, das einer herkömmlichen
Packet-Switch-Architektur
hinzugefügt
werden kann. Das beschriebene Planungssystem wird auf die Sende- und Empfangsfunktion
von jedem Port eines Switches getrennt angewandt. Mit dem beschriebenen
Planungssystem funktioniert ein Switch gemäß den Anforderungen bestimmter
Anwendungen in Bezug auf garantierte Bandbreite und die eingeschränkte Verzögerung.
In diesem Kontext bezieht sich der Begriff „Paketfluss" auf die einer bestimmten
Anwendung zugewiesenen Pakete. Der Paketfluss bezieht sich außerdem auf
den unidirektionalen Fluss von Paketen einer Anwendung zwischen
einem sendenden und einem empfangenden Host.
-
In
jedem Switch basiert das beschriebene Planungssystem auf vorhandenen
Zeitplänen.
Bei Zeitplänen
handelt es sich um erwartete Zeiträume, in denen Paketflüsse gesendet
und/oder empfangen werden. Für
jeden Switch im Netzwerk gelten eigene Zeitpläne. Ein bestimmter Zeitplan
kann für
die Sende- und Empfangsfunktionen aller Ports eines Switches oder
einer Untergruppe der Sende- und/oder Empfangsfunktionen
von Ports eines Switches gelten. Dementsprechend kann ein bestimmter
Switch auf einem einzelnen Zeitplan basierend oder auf mehreren
Zeitplänen
basierend betrieben werden. Zeitpläne können fortlaufend wiederholt
werden. Alternativ kann jeder Zeitplan explizit von einem Triggerereignis
ausgelöst
werden (Beschreibung siehe unten).
-
Innerhalb
eines Zeitplanintervalls definieren Paketfluss-Offsets den Anfang
von Paketen oder Paketgruppen, die mit Paketflüssen verbunden sind. Ist ein
Paketfluss-Offset mit der Sendefunktion eines Switchports verbunden,
definiert dieser Paketfluss-Offset einen Zeitpunkt in einem Zeitplanintervall,
zu dem die Übertragung
von Datenpaketen für den
verbundenen Paketfluss initiiert werden kann. Ist ein Paketfluss-Offset
mit der Empfangsfunktion eines Switchports verbunden, definiert
dieser Paketfluss-Offset einen Zeitpunkt in einem Zeitplanintervall,
zu dem der Empfang von Datenpaketen für den verbundenen Paketfluss
erwartet werden kann.
-
Für einen
gegebenen Paketfluss werden für jeden
Switch im Pfad zwischen einem sendenden und empfangenden Host verschiedene
Paketfluss-Offsets festgelegt. Die einem Paketfluss für alle Switches
in solch einem Pfad zugewiesenen Offsetwerte definieren den Zeitplan
für diesen
Paketfluss (wird auch als „Paketflusszeitplan" bezeichnet). Ein Paketflusszeitplan
kann auch eine Zeitplanintervall- und
Paketlänge
enthalten. Ein Zeitraum im Zeitplanintervall, das einem gegebenen
Paketflusszeitplan zugewiesen ist, wird als Paketflusszeitplan-Zeitraum bezeichnet.
-
Einzelne
Paketflusszeitpläne
werden basierend auf den Anforderungen der Anwendung, die dem Paketfluss
zugewiesen ist, und einem berechneten Pfad durch das Netzwerk (z.B.
dem optimalen Pfad durch das Netzwerk) festgelegt. Paketflusszeitpläne können abhängig von
den Bandbreitenbeschränkungen
des relevanten Kommunikationskanals jeder Anwendung zugewiesen werden.
Ein Paketflusszeitplan, der einer Anwendung zugewiesen ist, garantiert
dieser Anwendung einen Zeitraum, in dem sie Pakete in einen Übertragungspfad
platzieren kann. Paketflusszeitpläne können jeder Anwendung in jeder
Reihenfolge zugewiesen werden, bis die gesamte Übertragungszeit für diesen
Kanal zugewiesen ist. Alle nicht zugewiesenen Übertragungsmöglichkeiten
können
für den
Transport konventionellen Paketverkehrs, der wie in vorhandenen
Systemen geswitcht und weitergeleitet werden kann, verwendet werden.
-
Wurde
ein Paketfluss hergestellt, wird zwischen den Switches im Pfad zwischen
dem sendenden und dem empfangenden Host für diesen Paketfluss ein zugewiesener
Paketflusszeitplan eingerichtet. Basierend auf diesem Paketflusszeitplan
kann ein bestimmter Switch ein Paket mit einer garantierten Bandbreite
des Paketflusses gemäß Paketflusszeitplan
zum nächsten
Switch im Pfad zum empfangenden Host senden. Außerdem erwartet der nächste Switch
das Eintreffen des Pakets mit einer garantierten Bandbreite zu einem
im Paketflusszeitplan angegebenen Zeitpunkt. Auf diese Weise wird
zwischen jedem Sender und Empfänger(n)
eine dedizierte Bandbreite basierend auf der Formation des Paketflusszeitplans
der Switches im Pfad gewährleistet. Dementsprechend
gilt: Sendet ein Hostsender ein Paket basierend auf dem Paketflusszeitplan,
wird das Paket automatisch und ohne Verzögerung an den Hostempfänger übertragen.
Für jeden
gegebenen Switch ist jeder gegebene Paketflusszeitplan für seine
Verbindung zum Switch in einer Richtung aktiv. Jeder Switchport
kann seine eigenen dedizierten Zeitplanintervalle besitzen, und
zwar eines für
die Sendefunktion und eines für
die Empfangsfunktion. Für
die eingerichtete Echtzeitsitzung überschneiden sich die den gesendeten
Paketen zugewiesenen Paketfluss-Offsets mit den Paketfluss-Offsets,
die empfangenen Paketen zugewiesen sind, an jedem Switch im Pfad.
Der Satz von Paketfluss-Offsets, die auf den Switches im Pfad des
Paketflusses einem gegebenen Paketfluss zugewiesen sind, werden
in diesem Kontext manchmal auch als „Packet Trajectory" bezeichnet. Die
mit dem beschriebenen Planungssystem mit garantierter Bandbreite
gesendeten Pakete werden als „scheduled" Pakete bezeichnet. Die
mit dem Übertragungspfad
und den Switchingsystemen der Switches verbundenen Verzögerungen sind
in der Berechnung von Flusszeitplänen enthalten.
-
Das
beschriebene System setzt voraus, dass der sendende Host seine Übertragungen
mit allen Switches im Pfad zum empfangenden Host koordiniert. Der
Zeitplan von jedem Switch, der ein „scheduled" Paket vermittelt, muss mit dem nächsten Switch
im Pfad zum empfangenden Host für
den zugewiesenen Paketfluss koordiniert sein.
-
Der
empfangende Host setzt keine Aushandlung oder Koordination mit dem
letzten Switch im Pfad voraus. Der letzte Switch im Pfad sendet
die Hostempfängerpakete
gemäß den Paketflusszeitplänen, die
diesem Hostempfänger
zugewiesen sind. Da der Hostempfänger
alle Pakete vom letzten Switch im Pfad empfängt, steuert dieser Switch
die Übermittlung
aller Pakete an den Empfänger.
Der Hostempfänger
muss also die Zeitplaninformationen im Allgemeinen nicht koordinieren.
Der Hostempfänger
empfängt
immer mit garantierter Bandbreite gesendete Pakete zum korrekten
Zeitpunkt. Der Empfänger
kann normalerweise alle zum Planen des Abspielens der in den Echtzeitpaketen
enthaltenen Informationen benötigten
Anwendungszeitinformationen aus den Paketen selbst ableiten. Durch
garantierte Paketzustellzeiten wird die Notwendigkeit großer Paketjitterpuffer
zur Reduzierung von Jitter oder Paketkollisionen und Probleme bei
der Neuübermittlung
deutlich verringert. Da der Empfänger
das nächste
Paket in der Reihenfolge immer rechtzeitig erhält, ist der Jitterpuffer nur
begrenzt notwendig.
-
Der
Echtzeitpaketfluss zwischen den Switches wird durch die Koordination
von Zeitplänen
zwischen Switches ermöglicht.
Diese Koordination zwischen den Switches erfolgt mittels einer speziellen Anwendung,
die die Zeitpläne
zwischen den Switches berechnet und liefert. Diese Anwendung muss die
Zeitplanflüsse,
die Verzögerung
in den Switches und Verbindungen zwischen den Switches, die Verbindungsgeschwindigkeiten
und die Netzwerktopologie kennen. Empfängt die Zeitplananwendung eine Anforderung,
kann sie so einen Zeitplan für
den Paketfluss durch das Switchnetzwerk berechnen. Die Anwendung
berechnet zum Beispiel den Zeitplan für den schnellsten Paketfluss
durch das Switchnetzwerk.
-
KURZE BESCHREIBUNG
DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNG
-
Die
Erfindung wird mithilfe der folgenden ausführlichen Beschreibung in Verbindung
mit der Zeichnung besser verstanden:
-
1 enthält ein Blockdiagramm
eines scheduled Switches für
scheduled Pakete mit zwei verbundenen Hosts (Empfänger und
Sender), wichtige Elemente des Switches und der Signalpfade;
-
2(a), 2(b) und 2(c) enthalten Beispiele von Packet-Switching-Methoden;
-
3 veranschaulicht
ein Netzwerk mit scheduled Switches;
-
4 enthält ein Netzwerk
von scheduled Switches mit einem Signal-Softswitch;
-
5 zeigt
ein Heartbeat-Signal innerhalb eines Zeitplanintervalls und eine
veranschaulichende Heartbeat-Paketstruktur;
-
6 enthält Protokollmeldungen
zur Einrichtung und Terminierung einer bidirektionalen Echtzeitsitzung;
-
7 zeigt
eine Knotenpunktmatrix;
-
8 veranschaulicht
einen auf einem Netzwerkprozessor basierenden scheduled Packet-Switch;
-
9 veranschaulicht
einen Netzwerkprozessor;
-
10 veranschaulicht
die vom Empfänger bei
der Verarbeitung durchgeführten
Schritte;
-
11 veranschaulicht
die vom Sender bei der Verarbeitung durchgeführten Schritte.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ERFINDUNG
-
Das
in 1 dargestellte Blockdiagramm der Erfindung zeigt
die folgenden drei Komponenten: einen Switch (2), ein erstes
Hostterminal (1) und ein zweites Hostterminal (3).
Beide Hostterminals (1) und (3) können Pakete
senden und/oder empfangen.
-
Ein
Paket, das keine garantierte Zustellung und/oder Verzögerungsgarantie
erfordert, wird folgendermaßen
durch Switch (2) geleitet: Hostterminal (1) überträgt das Paket
zuerst über
eine Kommunikationsverbindung (20) an den Switch. Ist das
Hostterminal (1) über
eine Ethernet-Schnittstelle mit dem Switch (2) verbunden,
besteht die Kommunikationsverbindung möglicherweise aus einem vierpaarigen UTP-Kabel
(Unshielded Twisted Pair). Der Switch (2) kann jedoch mit
Schnittstellen für
viele verschiedene Kommunikationskanäle oder Verbindungen dargestellt
werden. Hierzu zählen
u.a. 10 Mbit/s-, 100 Mbit/s-, Gigabit- und 10-Gigabit-Ethernet-Netzwerke. Der
Switch (2) verwendet u.U. auch Schnittstellen, die als „OC", „DS", „T", „E" geläufig sind,
und andere Lichtwellenleiter- oder Drahtlosverbindungen und -kanäle, die
mit den Kommunikationsstandards SONET (Synchronous Optical NETwork)
und SDH (Synchronous Digital Hierarchy) konform sind und sich zur Übermittlung
von Internet- oder Ethernet-Paketen eignen. Das beschriebene System
verwendet dementsprechend keine Schnittstellen zu bestimmten Kommunikationsverbindungen.
Zur Veranschaulichung dient eine Ausführung mit Standard-Ethernet-Schnittstellen,
obwohl ein nach dem beschriebenen System angefertigter Switch auch
andere Arten von Schnittstellen umfassen kann.
-
Die
Schnittstelle, die den Switch (2) mit der Kommunikationsverbindung
zwischen dem Hostterminal (1) und dem Switch (2)
verbindet, kann mit einem Standardanschluss (22), der häufig als RJ-45-Anschluss
bezeichnet und für
die Verbindung mit einem Ethernet-Netzwerk verwendet wird, dargestellt
werden. Nach dem Empfang am Anschluss (22) wird das Paket
zur Receive Control Logic (RCL) (24) weitergeleitet. Die
RCL (24) extrahiert die Zieladresse des Pakets und platziert
den Inhalt des Pakets in der Receive Packet Queue (26).
Die RCL (24) sendet gleichzeitig eine Abfrage an die Switch
Control CPU (SCC) (43), die die Paketzieladresse enthält. Die SCC
(43) verwendet die aus einer Ethernet MAC- (Media Access
Controller) und einer IP-Adresse (Internet Protocol) bestehende
Paketadresse und verwendet diese unter Angabe, an welchen Port das
Paket übertragen
werden soll, zum Bestimmen einer Portnummer. Die SCC (43)
führt diese
Aktionen auf eine von zwei Arten aus: (1) durch Überprüfen einer internen Suchtabelle
oder durch Senden der Paketadresse an den Packet Classifier (PC)
(28). Der Packet Classifier (28) ordnet einem
Port am Switch (2) eine IP- oder Ethernet-MAC-Adresse zu.
Der Packet Classifier (28) verwendet zum Beispiel u.U.
ein Assoziativspeichersystem (CAM), um nach der Angabe einer Paketadresse
schnell eine Portnummer zurückzugeben.
-
Nachdem
die korrekte Portnummer von der SCC (43) identifiziert
wurde, überprüft die SCC
(43) eine interne Speichertabelle, um festzustellen, ob
die Transmit Control Logic (TCL) des Zielports der Crosspoint-Matrix
(32), zum Beispiel Transmit Control Logic (TCL) (30),
nicht für
eine geplante Übermittlung
verwendet wird. Die Zielport-TCL ist u.U. mit dem Empfang eines
Pakets von einer anderen Quelle beschäftigt. Ist die Zielport-TCL
in Verwendung, speichert die SCC (43) die Anforderung in
einer Warteschlange und wartet auf die nächste Anforderung. Ist die
Zielport-TCL der Crosspoint-Matrix
(32) nicht in Verwendung, fordert die SCC (43)
die Crosspoint-Matrix (32) dazu auf, zwischen dem Crosspoint-Matrix-Port,
der mit einem internen Switchausgang der RCL (24) verbunden
ist, und der Crosspoint-Matrix-Verbindung mit dem internen Switcheingang
zur TCL (30) eine Verbindung herzustellen. Nachdem diese
Verbindung hergestellt wurde, sendet die SCC (43) eine
Nachricht an die RCL (24). Diese Nachricht weist die RCL
(24) an, das Paket direkt an die Crosspoint-Matrix (32)
zu senden. Die RCL (24) übermittelt das Paket daraufhin
an die Crosspoint-Matrix (32). Gleichzeitig wird das Paket von
der TCL (30) empfangen. Wird derzeit kein Paket aus der
Transmit Packet Queue (TPQ) (34) übertragen, beginnt die TCL
(30) sofort mit der Übertragung des
eingehenden Pakets an das Hostterminal (3).
-
In 1 wird
die Addition der Receive Control Logic (24), der Receive
Packet Queue (26), der Transmit Control Logic (27)
und der Transmit Packet Queue (29) zum ersten Port von
Switch (2) in Beracht gezogen. Auf gleiche Weise wird die
Addition der Transmit Control Logic (30), der Transmit
Packet Queue (34), der Receive Control Logic (37)
und der Receive Packet Queue (39) zu einem zweiten Port von
Switch (2) in Erwägung
gezogen. Dementsprechend wird der erste Port als Eingangsport oder Quellport
und der zweite Port als Ausgangsport oder Zielport bezeichnet, wenn
ein Paket am ersten Port vom Switch (2) empfangen und zur Übertragung
an den zweiten Port vom Switch (2) weitergeleitet wird. Nach
Abschluss der Übertragung
des Pakets an die Crosspoint-Matrix (32) durch die RCL
(24) weist die RCL (24) die SCC (43)
auf den Abschluss des Vorgangs hin. Die SCC (43) setzt
dann den entsprechenden Eintrag in einer internen Speichertabelle
für den Übertragungsteil
des Ausgangsports auf den Status „clear". Sie gibt damit an, dass die Übertragungsfunktion
des Ausgangsports für
den Empfang eines Pakets von einem anderen Port verfügbar ist.
Die SCC (43) kann dann auch eine bestehende Verbindung zwischen
den zwei Ports trennen.
-
Bei
diesem Vorgang können
alle Pakete vom Switch (2) empfangen, identifiziert und
an den korrekten Zielport weitergeleitet werden. Experten auf dem Gebiet
wissen, dass so genannte „Switch-Fabrics" erhältlich sind,
die einige oder alle SCC (43)-, PC (28)-, Crosspoint
Load Memory (CPLM) (42)- und Crosspoint-Matrix
(32)-Funktionen ausführen.
Solche konventionellen Switch-Fabrics können in Ausführungen
des beschriebenen Scheduling-Packet-Switch verwendet werden.
-
Nun
wird die Übertragung
von Paketen mit Zustell- und Verzögerungslimitgarantie, so genannter Echtzeitpakete,
beschrieben. Diese Pakete können z.B.
mit Echtzeitanwendungen verbunden werden. Die Verbindung zwischen
einem Echtzeitpaket und einer Echtzeitanwendung kann beispielsweise über den
Paketfluss erfolgen. Ein mit einer Echtzeitanwendung verbundener
Paketfluss kann durch einen Satz von Paketheaderfeld-Werten identifiziert
werden, der in allen Paketen im Paketfluss enthalten ist. Echtzeitpakete
können
auch vom Switch (2) abgewickelt werden. Zum Beispiel setzt
die Verarbeitung von Echtzeitpaketen, die vom Host (1)
an den Switch (2) gesendet wurden, voraus, dass der Host
(1) seine garantierte Übertragung
mit dem Switch (2) koordiniert. Der Host (1) sendet
seine Echtzeitpakete außerdem
gemäß eines
vordefinierten zugewiesenen Zeitplans. Zur Ausführung solcher Vorgänge muss der
Host (1) über
eine von seinem Paketsender und dem Paketempfänger im Switch (2)
verwendete gemeinsame Zeitreferenz verfügen. Im beschriebenen System
wird dies anhand des folgenden Prozesses ermöglicht. Zuerst sendet der Switch
(2) ein Ethernet-Paket an den Empfänger (50) im Host
(1). Dieses Paket wird vom Switch (2) als Träger der
Referenzinformationen identifiziert. Der Empfänger (50) im Host (1)
verwendet dann das Referenzpaket, das auch als „Heartbeat-Paket" bezeichnet wird,
um den Beginn eines Zeitplanintervalls zu bestimmen. Der Switch
(2) sendet in ausreichendem Maß regelmäßig das Heartbeat-Paket, so
dass der Empfänger
(50) im Host (1) den Beginn des Zeitplanintervalls
bestimmen kann. Beispiel: Der Empfänger (50) berechnet zur
Referenz den Durchschnitt der Timinginformationen aus dem Empfang
mehrerer Heartbeat-Pakete. Auf diese Weise können die Phasen des Hostsenders
(52) effektiv an eine Referenzquelle vom Switch (2)
gebunden werden. Alle zur Unterstützung des beschriebenen geplanten
Dienstes verwendeten Ports vom Switch (2) können die
Heartbeat-Pakete senden. Die Heartbeat-Pakete müssen nicht in regelmäßigen Intervallen
gesendet werden, da jedes Heartbeat-Paket in seinem Paketdatenfeld
Informationen enthält,
mit denen sich seine Phase in Bezug auf das Zeitplanintervall des
Switches bestimmen lässt.
Die Heartbeat-Pakete werden in der vorliegenden Beschreibung zur
Veranschaulichung als in regelmäßigen Intervallen
auftretend beschrieben. Wie in 1 dargestellt,
kann ein Haupttaktgeber (65) mit Verbindungen (69)
zur gesamten Empfangs- und Sendelogik vom Switch (2) verwendet
werden, um das Zeitplanintervall für die Empfangs- und Sendelogik
vom Switch (2) bereitzustellen. Der Haupttaktgeber (65)
reagiert auf eine externe Taktreferenz (71) wie die oben
beschriebenen Heartbeat-Pakete.
-
Das
Heartbeat-Paket kann auch Verwaltungsinformationen enthalten. Die
Hauptfunktion von Heartbeat-Paketen ist jedoch die Bereitstellung
einer korrekten Taktreferenz. Jeder Host, der das Paket empfängt, passt
seine interne Referenz mit einem Algorithmus zur Durchschnittsberechnung
an. Die Heartbeat-Pakete ermöglichen
einem Host oder Hostnetzwerk die Ableitung einer Taktreferenz von einer
gemeinsamen Quelle. Auf diese Weise erhalten alle lokalen Hosts
oder Ports, die garantierte Daten in Form von Echtzeitpaketen übermitteln
müssen,
einen exakten lokalen Referenzrahmen. Jeder potentielle Hostsender
verwendet also die Switchreferenz. In jeder Gruppe von Switches,
die in diesem Dokument als „Zeitplandomäne" bezeichnet wird,
kann der Heartbeat von einem einzelnen Switch ausgehen. Jeder Switch
im Netzwerk kann dann für
den Empfang des Heartbeats von mindestens einem Port und zum Senden
von Heartbeats über
bestimmte Downstream-Ports konfiguriert werden, und zwar so, dass
die Heartbeat-Pakete über
das Switchnetzwerk in einer Strukturkonfiguration verteilt werden,
in der der Strukturstamm die Heartbeat-Quelle ist.
-
2(a), 2(b) und 2(c) veranschaulichen die drei technischen
Verfahren für
das Switching von Paketdaten. Diese drei technischen Verfahren umfassen
zwei frühere
Methoden und eine neue Methode, und zwar die hier beschriebene Methode.
Im Rahmen dieser Beschreibung wird beim Switching immer vom so genannten „Cut-Through-Switching" ausgegangen. Dies
bedeutet, dass ein Switch sofort beim Empfang eines Pakets mit dem
Weiterleiten des Pakets beginnen kann. Die Pakete müssen nicht
vollständig
empfangen sein, um die Weiterleitung zu beginnen. Cut-Through-Switches
haben den Vorteil, dass die Sendezeiten nicht akkumuliert werden
müssen.
Dies bedeutet, dass ein Paket bereits an sein Ziel übertragen
wird, während
der Empfang des Paketendes über
einen Eingangsport noch läuft.
-
In
früheren
Systemen werden Pakete nach dem FIFO-Verfahren (First In First Out)
geswitcht. Dieses Verfahren ist in 2(a) dargestellt.
FIFO wird heute in den meisten Paketnetzwerken verwendet. 2(a) zeigt einen Packet-Switch (101)
mit drei Paketeingangsströmen.
Im Packet-Switch
(101) werden Pakete in der Reihenfolge gesendet, in der sie
empfangen werden. Wie in 2(a) dargestellt, wird
das zuerst empfangene Paket (105) auch zuerst übertragen
(103). Das zweite empfangene Paket (100) wird
als zweites gesendet usw. Echtzeitpakete, einschließlich Pakete
(104) und (102), werden schattiert angezeigt.
Aufgrund der Reihenfolge, in der die Pakete empfangen wurden, und
der FIFO-Eigenschaften des Switches wird das Echtzeitpaket (104) als
letztes Paket übertragen
(102). Der Grund hierfür liegt
darin, dass alle anderen Pakete vom Switch (101) aus Darstellungsgründen vor
oder gleichzeitig mit dem Paket (102) empfangen wurden.
Entsprechend diesem Verhalten sind Pakete, die über Netzwerke mit Standard-FIFO-Switches übertragen
werden, unvorhersehbaren Verzögerungen
ausgesetzt. Diese Verzögerungen
summieren sich und sind oft sehr lang.
-
Die
am häufigsten
zur Reduzierung solcher Verzögerungen
vorgeschlagene Methode ist in 2(b) dargestellt.
Bei dieser Methode wird jedem Paket ein Prioritätstag oder eine Prioritätsbezeichnung
zugewiesen. Empfängt
der Switch ein Paket, überprüft dieser
das Prioritätstag.
Befindet sich bereits ein Paket mit höherer Priorität in der
Warteschlange, sendet der Switch das Paket mit der höheren Priorität zuerst.
Andernfalls sendet der Switch das älteste Paket mit gleicher Priorität. Auf diese Weise
werden in FIFO-Paketwarteschlangen lange Wartezeiten reduziert.
-
Bei
der auf Prioritäten
basierenden Paketverarbeitung werden Verzögerungen nicht beseitigt. Im
Beispiel von 2(b) wird ein zuerst
empfangenes langes Paket mit geringer Priorität (116) gesendet.
Kurz nach Beginn des Empfangs werden Pakete mit höherer Priorität (110)
und (111) empfangen. Diese Pakete mit höherer Priorität müssen warten,
bis das Paket mit geringerer Priorität übertragen wurde, da die begonnene
Paketübertragung
nicht unterbrochen werden kann. Beachten Sie, dass die Pakete mit
höherer
Priorität
(110, 111 und 115) sich gegenseitig verzögern. Da
sie die gleiche Priorität
besitzen, müssen
sie in einer FIFO-Warteschlange auf andere Pakete warten.
-
Die
aktuelle zeitplanbasierte Verarbeitung ist in 2(c) dargestellt.
Die zeitplanbasierte Verarbeitung ist eine neue Art der Verarbeitung,
die durch das hierin beschriebene Zeitplansystem ermöglicht wird.
In einem zeitplanbasierten System treffen die Echtzeitpakete (125)
nicht gleichzeitig am Switch ein. Die Zeitplanung erfolgt an den
Endpunkten, so dass die Pakete zu unterschiedlichen Zeiten eintreffen. Andere
Pakete treffen wie auch in den anderen Beispielen früher als
das lange Paket (126) ein. Der zeitplanbasierte Switch überträgt das längere Paket (126)
jedoch nicht, da er über
einen Zeitplan für
das Eintreffen eines neuen Echtzeitpakets informiert ist. Der Switch überträgt ein kürzeres empfangenes
Paket (120), das als übermitteltes
Paket (124) dargestellt ist, da er gemäß Zeitplan noch Zeit dafür hat. Das
zuerst empfangene Echtzeitpaket kann dann sofort weitergeleitet
werden, wie anhand des übermittelten
Pakets (123) gezeigt. Mit der beschriebenen zeitplanbasierten
Verarbeitung können
also Pakete ohne Warteschlangenverzögerung weitergeleitet werden.
-
3 enthält eine
typische Zeitplandomäne.
In der in 3 dargestellten Zeitplandomäne ist ein
Switch als „Master" gekennzeichnet.
Der Scheduling-Packet-Masterswitch (6) gibt Heartbeat-Pakete aus.
Die anderen Scheduling-Switches (5), (8) und (9)
empfangen die Heartbeat-Pakete.
-
Die
Scheduling-Switches (5), (8) und (9)
berechnen ihre eigenen Referenzwerte basierend auf der Empfangszeit
und dem Inhalt der Heartbeat-Pakete zum Beispiel unter Verwendung
eines Algorithmus zur Berechnung von Durchschnittswerten, um die
Heartbeat-Pakete anschließend
weiterzuleiten. Der Scheduling-Switch (5) leitet die Heartbeat-Pakete
an den als Internet Packet Telephone (4) dargestellten
Host weiter. Scheduling-Switch (8) leitet die Heartbeat-Pakete
an den Scheduling-Switch (9) weiter usw.
-
Nur
Hosts, die Echtzeitübertragungen
durchführen,
müssen
die empfangenen Heartbeat-Pakete verwenden. Hosts, die nur garantierte
Pakete empfangen müssen,
benötigen
keine Zeitreferenz vom Switch. Diese Hosts können die empfangenen Heartbeat-Pakete
einfach löschen.
Stellt ein Switch fest, dass ein Port nicht über die Fähigkeit zur scheduled Übermittlung
verfügt,
kann dieser entscheiden, die Heartbeat-Pakete nicht über diesen
Port zu senden.
-
3 enthält eine
typische Echtzeitanwendungsumgebung für die hierin gezeigten scheduled Switches.
Bei der in 3 dargestellten Echtzeitanwendung
handelt es sich um paketbasierte Sprachtelefonie. 3 enthält die scheduled
Switches (5), (6), (8) und (9),
Telefoniehosts (4) und (10), Desktopcomputerhost
(11), Server (12) und den Echtzeit-Scheduling-Server
für Telefonie
(7). Der angezeigte Echtzeit-Scheduling-Server (7)
verfügt über eine
Signaling System (SS7)-Verbindung (16). (3) stellt
also ein typisches Netzwerk und eine typische Echtzeitanwendung
dar.
-
Die
Echtzeittelefonieanwendung in (3) unterstützt verschiedene
Sitzungsarten. Erstens: Ein Telefon (4) kann eine Sitzung
mit einem anderen Telefon (10) oder mit anderen Telefonen,
die mit den Switches (5), (6), (8) und
(9) verbunden sind, beginnen. Zweitens: Das Telefon (4)
kann eine Sitzung mit einem nicht im scheduled Switchnetzwerk enthaltenen
Remotetelefon beginnen. Dies wird durch die Einrichtung einer Sitzung
mit der Weitbereichs-Telefonschnittstelle (13) über eine
TDM-Verbindung (18) erreicht.
Die Weitbereichs-Telefonschnittstelle (13) stellt eine
Verbindung zum Remotetelefon her. Drittens: Ein Telefon kann mit
einem anderen Telefon kommunizieren, das mit einem anderen Switch
verbunden ist. Dies wird mit der Inter-Switch-LAN-Verbindung ermöglicht.
Viertens: Ein Telefon kann eine Sitzung mit einem Server (12)
einrichten. Diese Fähigkeit
kann zum Abrufen von Sprachnachrichten oder für den Zugriff auf ein Spracherkennungssystem sinnvoll
sein. Viertens: Ein Telefon kann eine Sitzung mit einem Remotetelefon,
das mit einem Packet-Switched-Datenservice wie dem Internet verbunden
ist, herstellen. Dies wird durch eine Sitzung mit einer Weitbereichs-Internet-oder-Datenschnittstelle
ermöglicht.
Ein Desktopcomputer (11) kann ebenfalls Echtzeitsitzungen
einrichten und annehmen, wenn er mit den entsprechenden Komponenten zur
Unterstützung
der Echtzeitanwendung (z.B. Sprache) ausgestattet ist.
-
Hosts,
wie sie in 3 dargestellt sind, richten
ebenfalls Echtzeitsitzungen ein, indem sie mit dem Echtzeit-Scheduling-Server
(7) kommunizieren. Der Scheduling-Server (7) stellt
alle Zeitplanfunktionen bereit, die zum Steuern der Zusammenwirkung aller
Echtzeithosts erforderlich sind. Die Hosts kommunizieren nicht direkt
mit den Switches (5), (6), (8) und (9).
Der Scheduling-Server (7) ist für die Koordination der Einrichtung
von Echtzeitsitzungen mit den Switches (5), (6),
(8) und (9) verantwortlich.
-
Die
Sitzungen werden in folgender Weise eingerichtet und beendet: Der
Host sendet eine Anforderung in Form einer Nachricht an den Scheduling-Server
(7). Diese Nachricht wird über die konventionelle unscheduled
LAN-WAN-IP-Verbindung gesendet. Der Scheduling-Server (7)
berechnet den Pfad zwischen dem anfragenden Host und dem Paketziel, über den
der neue Paketfluss erfolgt. Der Scheduling-Server (7) übermittelt
dann die Zeitplaninformationen an die Telefone (4) und
(13) und an die Switches (5), (6), (8)
und (9). Die Zeitplaninformationspakete werden von den
Switches (5), (6), (8) und (9)
empfangen und an die entsprechenden Ausgangsports von jedem Switch
weitergeleitet. Die Switchverwaltungs-CPU (64) (1)
verarbeitet den Inhalt der Zeitplaninformationspakete zur Abwicklung
der von jedem Switch gesendeten und empfangenen Echtzeitpakete.
-
Abbildung
enthält
ein Netzwerk mit scheduled Switches, einschließlich einer Signal-Softswitch-Computeranwendung
(14). Die Geräte
in 4 sind die gleichen wie in 3. Es wurde lediglich
die Signal-Softswitch-Computeranwendung (14) hinzugefügt. Die
Softswitch-Computeranwendung
(14) ist eine konventionelle Softwarekomponente, die ein
Anrufsignal zum Herstellen einer Telefonverbindung über das
Internet bereitstellt.
-
Im
in 4 gezeigten Netzwerk werden Sitzungen folgendermaßen eingerichtet
und beendet: Der Host sendet eine Anforderung in Form einer Nachricht
an die Signal-Softswitch-Computeranwendung
(14). Die Signal-Softswitch-Computeranwendung (14)
fordert dann über
den Scheduling-Server (7) einen scheduled Paketfluss an.
Der übrige
Betrieb der in 4 enthaltenen Geräte ist derselbe
wie zu 3 beschriebene Betrieb.
-
5 enthält ein Zeitplanintervall
(182), das von einem Heartbeat-Paket (180) initiiert
wurde, und dem ein zweites Heartbeat-Paket (181) folgt.
In einer typischen Echtzeitanwendung kann ein Heartbeat-Signal wie
die Heartbeat-Pakete (180) und (181) so oft wie
das Zeitplanintervall (182) selbst gesendet werden. Das
Heartbeat-Signal muss jedoch nicht in jedem Intervall gesendet werden,
da von den gültigen
Ankunftszeiten von Heartbeat-Paketen der Durchschnittswert berechnet
werden kann. Diese Durchschnittswertermittlung ermöglicht eine
sehr exakte Ableitung des Zeitplanintervalls.
-
5 veranschaulicht
ein Heartbeat-Paket (189). Das Heartbeat-Paketformat (189)
in 5 verwendet einen Ethernet-Frame mit einem standardmäßigen Ethernet-
oder Internet Protocol (IP)-Paket. Die Abbildung enthält einen
Ethernet-Header (183), dem ein IP-Header (184)
folgt. Außerdem
wird eine Ladung (185) gezeigt, die ein Feld mit der Zeit
des letzten Heartbeats enthält,
und der ein Referenzbyte (186) folgt. 5 enthält außerdem ein
IP-Endfeld (187) und ein Ethernet-Endfeld (188). Das Referenzbyte
(186) kann vom Empfänger verwendet
werden, um aus dem Heartbeat-Paket in 5 Zeitwerte
abzurufen. Wenn also die Receive Control Logic in einem scheduled
Switch ein Heartbeat-Paket abruft, sucht sie nach dem Referenzbyte (186).
Wenn ein scheduled Switch das Referenzbyte (186) abruft,
setzt er seinen Master-Takt (65) (1) mittels
eines von der SCC (43) berechneten Durchschnittswerts zurück. Die
Zeitplaninformationen für
einen scheduled Switch lassen sich auch durch zeitliche Messung
des Endes, des Beginns oder eines anderen Punktes im empfangenen
Heartbeat-Paket (siehe 5) und die anschließende Durchschnittswertberechnung
ableiten. Bei dieser alternativen Methode sind mehr Heartbeat-Pakete
erforderlich, um einen exakten Wert zu erhalten.
-
6 zeigt
einen anormalen Nachrichtenaustausch zwischen einem Schedulingserver
und der SMC (64) in Switch (2) aus 1.
Bei einer Zweiwegesitzung sendet der Scheduling-Server (7) eine erste SesReq-Meldung
(200) an die SMC (64). Die SesReq-Meldung (200)
informiert die SMC (64), dass eine Sitzungszeitplanzuordnung
benötigt
wird. Die SesReq-Meldung (200) enthält Informationen über die
gewünschte
Sitzung wie die Quell- und Zielportnummer, die Quell- und Ziel-MAC-Adresse und die
Quell- und Ziel-IP-Adresse, falls diese verfügbar sind. Die SesReq-Meldung
(200) enthält
außerdem die
gewünschte
Zeitplaninformation für
eine Echtzeitsitzung wie die Anzahl und Größe von Paketen.
-
Die
SMC (64) antwortet auf die SesReq-Meldung mit einer SesReqAck-Meldung
(202). Die SesRegAck-Meldung (202) gibt an, ob
die Sitzungsanforderung akzeptiert wurde. Die Sitzung wird eingerichtet,
wenn die Sitzungsanforderung akzeptiert wird. Für eine Zweiwegesitzung kann
die SesReq-Meldung zweimal, einmal für jede Richtung des Paketflusses,
gesendet werden. Der Scheduling-Server kann alternativ auch eine
einzelne Anforderung für beide
Richtungen akzeptieren. Dementsprechend wird wie in 6 gezeigt
eine zweite SesReq-Meldung (204) von einer zweiten SesRegAck-Meldung (206)
bestätigt.
Der Anruf (208) wird ausgeführt, wenn beide Sitzungspaketflüsse akzeptiert
werden.
-
Sitzungen
werden mit zwei Meldungen vom Scheduling-Server abgebrochen. Zuerst
sendet der Scheduling-Server (7) eine erste SesRel-Meldung (210)
an die SMC (64). Die SesRel-Meldung (210) weist
den Switch darauf hin, dass die im Zeitplan zugewiesene Zeit für den designierten
Paketfluss nicht mehr benötigt
wird. Die SMC (64) antwortet mit einer SesRelAck-Meldung
(212). Die SesRelAck-Meldung (212)
weist den Scheduling-Server (7) darauf hin, dass die der
designierten Sitzung zugewiesenen Zeitplanressourcen jetzt freigegeben
werden. 6 zeigt zwei Sitzungsversionen,
die auf eine Zweiwege-Echtzeitanwendung wie einen normalen Telefonanruf
zutreffen. Dementsprechend ist eine zweite SesRel-Meldung (214)
angezeigt, der eine zweite SesRelAck-Meldung (216) folgt.
-
Jetzt
wird der mit dem Switch (2), der in 1 gezeigt
wird, abgewickelte Transport von Echtzeitpaketen beschrieben. Wie
oben erwähnt, verbindet
der Switch (2) (siehe 1) sowohl
Echtzeit- als auch Nicht-Echtzeitpaketflüsse mittels einer Crosspoint-Matrix
(32). Die Crosspoint-Matrix wird jedoch für Echtzeit-
und Nicht-Echtzeitpakete unterschiedlich eingesetzt. Im Switch (2)
verwaltet die SCC (43) das Crosspoint Load Memory (42).
Das Crosspoint Load Memory (42) enthält den Gesamtstatus der Crosspoint-Matrix
(32). Der Gesamtstatus der Crosspoint-Matrix (32)
spiegelt den Status von jedem Paketflusszeitplan im Zeitplanintervall
wider.
-
7 veranschaulicht
eine Crosspoint-Matrix, die mit der in 1 gezeigten
Crosspoint-Matrix (32) übereinstimmt.
Die Crosspoint-Matrix von 7 wird mit
verschiedenen Switches (284) gezeigt, die mehrere Crosspoint-Eingänge (280)
mit mehreren Crosspoint-Ausgängen
(282) verbinden.
-
Wie
in 7 gezeigt, enthält die Crosspoint-Matrix eine
doppelte Reihe von Sperren, Neu (66) und Aktuell (67),
die die Einstellung der Crosspoint-Switches steuern. Die Crosspoint-Matrix wird
direkt anhand des Status der aktuellen Sperren (67) gesteuert.
Die aktuellen Sperren (67) bestimmen, welche Eingänge der
Crosspoint-Matrix tatsächlich
mit den entsprechenden Ausgängen
der Crosspoint-Matrix
verbunden werden. Die aktuellen Sperren (67) können auf
zwei Arten geladen werden. 1. Die SCC (43) kann direkt
auf eine Sperre zugreifen und ihren Wert jederzeit ändern. 2.
Alle aktuellen Sperren (67) können gleichzeitig aus dem Inhalt
der neuen Sperren (66) geladen werden. Die Daten aus den
neuen Sperren (66) werden basierend auf dem Laststeuerungspin
(68) gleichzeitig in die aktuellen Sperren (67) übertragen.
Das Laststeuerungspin ist mit der SCC (43) verbunden. Die
SCC (43) kann das Laststeuerungspin jederzeit bestätigen. Die
SCC (43) kann außerdem
auf jede neue Sperre zugreifen und diese laden.
-
Für Nicht-Echtzeitpakete
verarbeitet die SCC (43) die Verbindungsanforderung paketweise, und
die SCC (43) stellt Verbindungen durch direkte Anfrage
an die aktuelle Sperre der Crosspoint-Matrix her. Umgekehrt werden
Echtzeitsitzungen durch Laden der neuen Sperren eingerichtet (66).
Zu Beginn jedes neuen Zeitplans werden die neuen Sperren (66)
in die aktuellen Sperren (67) durch Bestätigung des
Laststeuerungspins (68) geladen. Im Verlauf des Zeitplans
wird die CP-Konfiguration zum Einstellen der Switches für den nächsten Paketflusszeitplan
in die neuen Sperren (66) geladen. Der Inhalt der neuen Sperren
(66) beeinflusst den Betrieb der Crosspoint-Matrix erst,
wenn das Laststeuerungspin (68) bestätigt wird. Auf diese Weise
ist die Switchkonfiguration sofort zu Beginn des neuen Zeitplans
einsatzbereit.
-
Sowohl
die aktuellen Sperren (67) als auch die neuen Sperren (66)
besitzen ein Bit für
jede potentielle Verbindung über
die Crosspoint-Matrix. In einer veranschaulichenden Ausführung unterstützt der Switch
(2) 128 Ports. Mehrere externe Ports können von einem einzelnen Port
der Crosspoint-Matrix bedient werden. Wie in 7 gezeigt,
umfasst eine Crosspoint-Matrix 128 Eingänge und 128 Ausgänge. Jeder
Eingang kann mit jedem Ausgang verbunden werden. Für jeden
Ausgang sind 128 SPST (Single Pole Single Throw)-Switches verfügbar. Jeder
der 128 Switches ist mit einem anderen Eingang verbunden. Mit jedem
Ausgang kann jeweils nur ein Eingang verbunden werden. Andernfalls
können
Engpässe auftreten,
und die Crosspoint-Matrix kann beschädigt werden. Es ist möglich, einen
Eingang mit einem Ausgang oder allen Ausgängen zu verbinden. Der für jeden
Ausgang erforderliche Speicher beträgt 128 Bit. Der Ausgang wird
normalerweise in Form von 127 Nullen mit einem „1 "-Bit gespeichert, das den ausgewählten Eingang
angibt. Wird kein Eingang ausgewählt,
sind alle 128 Bit Null. Der für
die 128 Bit erforderliche Platz im Speicher beträgt 16 Byte.
-
Erhält die SCC
(43) eine Verbindungsanforderung von einer Port RCL, muss
diese verschiedene Funktionen ausführen. Zuerst stellt die SCC
(43) fest, ob der Port, zu dem eine Verbindung hergestellt
werden soll, in Betrieb ist. Die SCC (43) überprüft hierzu für jeden
relevanten Zeitplan den Speicher für die Echtzeitverbindung. Sie
muss außerdem
den Speicher für
die Nicht-Echtzeitverbindung überprüfen. Bestehen
keine aktiven Verbindungen, stellt die SCC (43) zunächst den
Speicher für
die Nicht-Echtzeitverbindung ein und ändert anschließend das
entsprechende CP-Register. Die SCC (43) teilt dann der
anfragenden RCL mit, das Paket zu senden. Wenn die SCC (43)
von der RCL darüber
informiert wird, dass das Paket übertragen
wurde, löscht
die SCC den Speicher für
die Nicht-Echtzeitverbindung und setzt die Verbindung über ein
entsprechendes Crosspoint-Matrix-Register zurück. Empfängt die SCC (43) eine
Paketverbindungsanforderung von einer Port-RCL und stellt diese
fest, dass der Port zu dem eine Verbindung angefordert wurde, in
Betrieb ist, wird die Verbindungsanforderung bis Abschluss der Verbindung
in eine Verbindungswarteschlange eingereiht.
-
Ausführung mit
High-Speed-Prozessor
-
Die
Funktionalität
des in 1 dargestellten Switch wird in erster Linie durch
Hardwarekomponenten realisiert. Diese Funktionen können unter Verwendung
von High-Speed-Prozessoren
jedoch auch mittels Soft- oder Firmware bereitgestellt werden. In
solch einer Ausführung
wird der beschriebene Scheduling-Packet-Switch mit der in 8 dargestellten
Architektur implementiert. In solch einer Ausführung wird der beschriebene
Switch mit mehreren High-Speed-Prozessoren
(303), (304) (so genannten Netzwerk- oder Kommunikationsprozessoren),
die zur Verarbeitung von Ethernet- und/oder Internet Protocol-Paketen
optimiert sind, hergestellt. Diese Netzwerkprozessoren (303),
(304) werden zur Leitung des Paketflusses durch den Switch
verwendet.
-
Der
interne Aufbau eines typischen, für diese Anwendung geeigneten
Netzwerkprozessors ist in 9 dargestellt.
Der Netzwerkprozessor (400) ist in 9 als integrierter
Schaltkreis mit verschiedenen Unterkomponenten dargestellt. Der
Ein- und Austritt der Pakete in den bzw. aus dem Netzwerkprozessor
erfolgt üblicherweise über High-Speed-Schnittstellen
(410). Diese Schnittstellen können mittels einer programmierbaren
RISC (Reduced Instruction Set)-Schnittstellenengine (403),
(404), (405), (406) usw. als Ethernet-
oder SONET- oder T-Carrier-Schnittstellen konfiguriert werden.
-
Die
Betriebskonfigurationen der RISC-Engines werden mit der Steuerungs-CPU
(432) festgelegt. Die Steuerungs-CPU (432) lädt beim
Starten des Netzwerkprozessors (400) üblicherweise etwas Microcode
in die RISC-Engine. Die RISC-Engines (403), (404),
(405), (406) formatieren die über die High-Speed-Schnittstelle
eingehenden Daten, um die Paketdaten aus den Framedaten zu extrahieren. Diese
Daten werden an die RISC-Paketprozessoren (420), (421),
(422), (423) usw. gesendet. Auf gleiche Weise
verlassen die Paketdaten bei der Übertragung den RISC-Prozessor
und werden von den Schnittstellen-RISC-Engines (403), (404),
(405), (406) usw. formatiert.
-
Die
Paketprozessoren (420), (421), (422), (423)
usw. werden verwendet, um das Paketziel festzulegen. Sie können ein
Paket in eine Warteschlange einreihen oder an einen anderen Paketprozessor
zur Übertragung
senden. Die Warteschlangen-Engine (430) wird zur Verwaltung
der Warteschlangen verwendet. Jeder Paketprozessor (420, 421, 422, 423 usw.)
kann zum Senden und Empfangen mehrere Warteschlangen besitzen. Der
Paketprozessor bestimmt, in welche Warteschlange das Paket eingereiht
wird. Anschließend
sendet er das Paket zur Speicherung an die Warteschlangen-Engine (430). Die
Warteschlangen-Engine (430) verwendet dann ein externes
High-Speed-RAM über
eine High-Speed-RAM-Schnittstelle (440) zum Speichern des
Pakets.
-
Wenn
der Paketprozessor (420, 421, 422, 423 usw.)
bestimmt, dass das Paket an einen anderen Paketprozessor übertragen
werden soll, überträgt der Paketprozessor
das Paket an den Fabric-Schnittstellencontroller
(431). Diese Schnittstelle überträgt dann das Paket zusammen
mit der Adresse des Zielnetzwerkprozessors und dem Port des Zielnetzwerkprozessors.
Die Switch-Fabric (308) verschiebt dann das Paket in den
Fabric-Schnittstellencontroller (431) des nächsten Netzwerkprozessors.
-
Ein
typischer Switch kann viele Ports (410) an vielen Netzwerkprozessoren
(420, 421, 422, 423 usw.) besitzen.
Die Steuerungs-CPU (432) steuert den Betrieb der Komponenten
des Netzwerkprozessors (400). Hierzu zählen die Schnittstellen-RISC-Engines,
die RISC-Paketprozessoren (420, 421, 422, 423 usw.)
die Warteschlangen-Engine (430) und die Fabric-Schnittstelle
(431). Sie kommuniziert mit einer externen CPU (314, 315 usw.) über einen
Bus (443). Die Steuerungs-CPU nutzt für ihren Betrieb auch das interne
RAM (433) und ROM (434).
-
Im
Switch (300), der in 8 dargestellt
ist, werden zum Verschieben von Paketen in den und aus dem Switch
(300) mehrere Netzwerkprozessoren (303, 304)
mit den Switch-Fabrics (308, 309) verwendet. Pakete
treten im Switch in Geräte
der physikalischen Schicht ein (302). Diese Geräte konvertieren
die Signalpegel, Impedanz und Medien (optisch, elektrisch, symmetrisch,
unsymmetrisch usw.) in Signale, die an die Netzwerkprozessoren (303, 304 usw.)
weitergeleitet werden können.
Die Hosts (301) senden und empfangen Paketdaten an den
bzw. vom Switch (300). Diese Paketdaten sind entweder scheduled
oder unscheduled.
-
Der
Switchbetrieb wird von einer Routing-CPU (307, 310)
gesteuert. Die Routing-CPU (307, 310) kommuniziert
mit anderen Packet-Switches, um sich über die Topologie des Switchnetzwerks
zu informieren. Sie stellt dann Routinginformationen für die Netzwerkprozessoren
(303, 304 usw.) bereit, so dass diese die eingehenden
Pakete an den korrekten Ausgangsport senden können.
-
Der
Switch ist außerdem
in der Lage, ein Versagen der Haupt-Switch-Fabric (308),
der Routing-CPU
(307) und des Taktgebersystems (306) zu überstehen.
Für eine
redundante Switch-Fabric (309), Routing-CPU (310)
und ein redundantes Taktgebersystem (311) wurde gesorgt.
Die Netzwerkprozessoren (303, 304 usw.) können feststellen,
ob das Hauptsystem ausgefallen ist, indem Sie die Antworten vom
Hauptsystem überprüfen. Wird
ein Ausfall festgestellt, können
die Netzwerkprozessoren (303, 304) zur Verwendung
des redundanten Systems umschalten. In einer bevorzugten Ausführung befinden sich
die primären
und die redundanten Prozessoren auf verschiedenen auswechselbaren
Karten. Bei einem Ausfall kann die ausgefallene Karte ohne Betriebsunterbrechung
des Switch (300) ersetzt werden.
-
Die
Paketflusszeitpläne
werden an den Switch mittels Nachrichten an die Routing-CPU (307, 310) übermittelt.
Beide CPUs (die primäre
und die redundante CPU) (307, 310) erhalten die
Zeitplan- und Routinginformationen.
Allerdings reagiert nur die primäre
Routing-CPU (307), wenn nicht die redundante CPU (310)
in Verwendung ist. Die Zeitplaninformationen werden dann an den
entsprechenden Netzwerkprozessor übertragen. Wird ein Zeitplan
entfernt oder abgebrochen, werden die Zeitplaninformationen auf ähnliche
Weise gelöscht.
-
Unscheduled
(„normale") Pakete, die vom Switch
empfangen werden, werden von den Netzwerkprozessoren (303, 304 usw.)
verarbeitet und bei Bedarf in Warteschlangen eingereiht. Die Pakete werden
dann zur Übertragung
an ihr Ziel zurück
an die Netzwerkprozessoren (303, 304 usw.) bzw.
an die Switch-Fabric (308) gesendet. Pakete werden in Wartenschlangen
in der Reihenfolge ihres Eintreffens, nach der Priorität oder nach
Tags wie beim Multi-Protocol Label Switching (MPLS) eingereiht.
Unscheduled Pakete unterliegen den normalen Verzögerungsvarianten, die durch
das Zusammenspiel von Paketströmen
und die verschiedenen Warteschlangensysteme im Switch verursacht
werden.
-
Scheduled
Packets werden auf andere Weise übertragen
(geswitched). Die Routing-CPU (307) teilt dem Netzwerkprozessor
(303, 304 usw.) einen Zeitplan mit. Der Netzwerkprozessor
(303, 304 usw.) überprüft bei jedem Eintreffen eines
neuen Pakets den Zeitplan. Stellt der Netzwerkprozessor (303, 304 usw.)
fest, das ein Zeitplan eingehalten wird, kann er das Paket mit Informationen
für das
Fabric, den Zielnetzwerkprozessor (303, 304) und
den Zielport direkt an die Switch-Fabric weiterleiten. Auf gleiche
Weise überprüft der Netzwerkprozessor
(303, 304 usw.) auf der Übertragungsseite fortlaufend
den Zeitplan. Gilt ein bestimmter Zeitplan, überträgt der Netzwerkprozessor kein
in eine Warteschlange eingereihtes Paket. In diesem Fall leitet
er das derzeit empfangene Paket direkt über die Fabric-Schnittstelle (319)
weiter.
-
Auf
diese Weise werden scheduled Pakete über den Switch auf beschleunigte
und vorhersehbare Weise weitergeleitet. Die Flussdiagramme für diesen
Vorgang sind in 10 und 11 dargestellt. Die
Verarbeitung der für
den Empfang verantwortlichen Seite ist in 10 und
die Verarbeitung der für das
Senden verantwortlichen Seite in 11 beschrieben.
-
Wie
in 10 dargestellt, wartet der Netzwerkprozessor in
seinem erwartenden Paketstatus (500). Wird ein Paket empfangen
(501), fragt der Prozessor den Zeitplan ab, um festzustellen,
ob das empfangene Paket einem Zeitplan unterliegt. Lautet die Antwort „JA", wird das Paket
direkt an die Switch-Fabric weitergeleitet (506). Nach
Abschluss dieser Übertragung überprüft der Prozessor,
ob ein weiteres Paket unterwegs ist (502). Wird kein Paket empfangen
kehrt der Prozessor in den erwartenden Paketstatus (500)
zurück.
Wird ein Paket empfangen, überprüft der Prozessor
wieder die relevanten Zeitplaninformationen in Schritt (503).
Liegt kein Zeitplan vor, stellt der Prozessor in Schritt (504)
fest, ob zur Weiterleitung des nächsten
Pakets genügend Zeit
zur Verfügung
steht. Lautet die Antwort „NEIN", überprüft der Prozessor
wieder die relevanten Zeitplaninformationen in Schritt (503).
Lautet die Antwort „JA", leitet der Prozessor
das keinem Zeitplan unterliegende Paket in Schritt (505)
auf normale Weise weiter. Anschließend kehrt der Prozessor in
den erwartenden Paketstatus zurück
(500). Mithilfe dieses Prozesses gewährleistet die Empfangsverarbeitung die
umgehende Verarbeitung aller scheduled Pakete. Dieser Prozess stellt
außerdem
sicher, dass die Verarbeitung eines unscheduled Pakets nicht die
Verarbeitung eines anstehenden scheduled Pakets verzögert. Und
schließlich
erlaubt dieser Prozess die Übertragung
wartender unscheduled Pakete direkt vor einem unmittelbar bevorstehenden
scheduled Paket.
-
Die
Verarbeitung auf der für
die Übertragung verantwortlichen
Seite wird auf ähnliche
Weise implementiert. 11 veranschaulicht den Sendeprozess.
Der Netzwerkprozessor auf der für
die Übertragung
verantwortlichen Seite überprüft in Schritt 511 fortlaufend,
ob ein Zeitplan vorliegt. Ist ein Zeitplan in Verwendung, wartet
der Übertragungsprozess
auf das Eintreffen des scheduled Pakets von der Fabric (514),
und er überträgt das Paket,
sobald es eintrifft (515). Anschließend kann der Prozessor wieder
feststellen, ob ein Zeitplan vorliegt (511). Ist kein Zeitplan in
Verwendung, kann der Netzwerkprozessor unscheduled Pakete senden.
Zuerst muss er feststellen, ob ein solches Paket vorhanden ist (510).
Ist ein solches Paket vorhanden, muss er überprüfen, zu welchem Zeitpunkt es
gesendet werden soll (513). Kann ein Paket aufgrund seiner
Länge nicht
vor dem nächsten
Zeitplan vollständig
gesendet werden, wartet der Prozessor mit dem Senden. Reicht die
verbleibende Zeit vor einem neuen scheduled Paket zum Senden des
Pakets, kann das Paket normal gesendet werden (512).
-
Ein
einfaches Beispiel einer Echtzeitanwendung, auf die die vorliegende
Erfindung angewendet werden kann, ist die Sprachtelefonie. In diesem
Beispiel wird das Sprachsignal eines herkömmlichen Telefonanrufs zwischen
zwei Telefongeräten über das Telefonnetz übertragen.
Wie allgemein bekannt ist, gewährleisten
Telefonnetze normalerweise eine garantierte Bitrate von 64 Kbit/s
(8000 Acht-Bit-Samples
pro Sekunde) mit einer Fehlerrate von weniger als einem beschädigten Sprachsample
je 12500 Sprachsamples und mit einer festen Verzögerung, die weltweit 100 Millisekunden
nicht übersteigt.
-
Zur Übertragung
von Echtzeit-Sprachsamples über
das beschriebene scheduled Netzwerk werden digitalisierte Sprachsamples
mit einer Rate von 8 kHz zu Paketen zusammengefasst. Ein üblicher
Akkumulationszeitraum beträgt
beispielsweise 20 Millisekunden. In jedem 20-Millisekunden-Zeitraum werden 80
Samples akkumuliert. Diese 80 Samples werden in einem Internetpaket übertragen.
Alle 20 Millisekunden wird ein neues Paket übertragen. Das beschriebene
System koordiniert einen Zeitplan mit einem sendenden Telefon, dem
ersten Switch und jedem nachfolgenden Switch im Pfad bis zum empfangenden
Telefon. Der letzte Switch im Pfad sendet schließlich die Pakete zum empfangenden
Telefon.
-
Der
Paketflusszeitplan für
diesen Telefonanruf kann beispielsweise basierend auf Folgendem definiert
werden: auf einer Zeitplanintervall-Gesamtlänge von 20 Millisekunden, einer
Paketfluss-Offset-Beschreibung,
die den Start eines Pakets im Zeitplanintervall definiert (eine
Zahl zwischen 0 und 20 für
die ausreichende Auflösung),
und eine Paketlänge
(in diesem Fall mehr als 80 Byte, unter Berücksichtigung des Paket- und
IP-Overheads).
-
Dieser
Paketflusszeitplan wird berechnet und an jeden Switch im Pfad bis
zum empfangenden Telefon gesendet. Für jeden Switch gilt ein eigenes Paketfluss-Offset.
Die Zeitplanintervalllänge
bleibt im Allgemeinen immer gleich. Die Paketlänge bleibt ebenfalls gleich.
Die Position des Pakets im Intervall ändert sich von einem Switch
zum nächsten,
da die Übertragung
des Pakets im Netzwerk von Switch zu Switch Zeit benötigt. Switches
sorgen für
Verzögerungen.
Die Übertragung
zwischen den Switches verursacht ebenfalls Verzögerungen. Diese Verzögerungen
müssen
bei der Berechnung des Paketflusszeitplans berücksichtigt werden.
-
Wenn
ein scheduled Telefonanruf initiiert wird, berechnet die Scheduling-Server-Anwendung den
erforderlichen Paketflusszeitplan. Die Zeitplananwendung teilt die
Zeitplaninformationen daraufhin dem sendenden Telefon und allen
Switches im Paket für
diesen Paketfluss mit. Nach Abschluss des Anrufs fordert der Zeitplanserver
alle Switches im Pfad auf, den Zeitplan zu löschen.
-
Ein
wichtiger Vorteil dieser Erfindung ist die Tatsache, dass die Paketverzögerung von
mehreren Switches nicht kumuliert wird. Da mehrere Switches ihre
Zeitpläne
jetzt koordinieren können, können dieselben
Telefonanrufpakete jetzt über
weite Entfernungen über
mehrere Switches übertragen
werden. In diesem Fall werden Verzögerungen nur durch die physische
Entfernung und die Paketweiterleitung verursacht. Dies ist ein eindeutiger
Unterschied zu bestehenden „optimalen
Methoden" oder unscheduled
Packet-Switching-Systemen. Bei der Übertragung von unscheduled
Paketen im Netz können leicht
vorübergehende
Engpässe
oder Warteschlangenüberläufe auftreten,
die zu unvorhersehbaren Verzögerungen
oder Verlusten führen.
-
Experten
auf dem Gebiet werden es zu schätzen
wissen, dass Programme mit den Funktionen der vorliegenden Erfindung
Computern auf verschiedene Weise hinzugefügt werden können. Hier sind einige Beispiele:
(a) Informationen, die auf einem nicht beschreibbaren Speichermedium (ROM-Geräte in einem
Computer oder mit einem CD-ROM-Laufwerk lesbare CD-ROMs) dauerhaft
gespeichert sind; (b) Informationen, die auf einem beschreibbaren
Speichermedium gespeichert sind und geändert werden können (z.B.
Disketten und Festplatten); oder (c) Informationen, die z.B. mittels
Basisband- oder Breitbandmethoden über ein Kommunikationsmedium
auf einen Computer übertragen werden
(z.B. mithilfe eines Modems über
Computer- oder Telefonnetze). Die Erfindung kann jedoch nicht nur
in Form von Computersoftware angewendet werden. Die zum Implementieren
der Erfindung erforderlichen Funktionen können auch zum Teil oder insgesamt
mit Hardwarekomponenten wie Application Specific Integrated Circuits
(ASICs) oder anderer Hardware oder einer Kombination aus Hardwarekomponenten
und Software implementiert werden.
