DE10139936A1 - Verfahren und Anordnung zur Steuerung von Datenpaketen - Google Patents

Verfahren und Anordnung zur Steuerung von Datenpaketen

Info

Publication number
DE10139936A1
DE10139936A1 DE10139936A DE10139936A DE10139936A1 DE 10139936 A1 DE10139936 A1 DE 10139936A1 DE 10139936 A DE10139936 A DE 10139936A DE 10139936 A DE10139936 A DE 10139936A DE 10139936 A1 DE10139936 A1 DE 10139936A1
Authority
DE
Germany
Prior art keywords
data packets
data
data packet
host processor
subsystems
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE10139936A
Other languages
English (en)
Other versions
DE10139936B4 (de
Inventor
Merten Guse
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE10139936A priority Critical patent/DE10139936B4/de
Priority to EP02102025A priority patent/EP1284561B1/de
Priority to DE50206134T priority patent/DE50206134D1/de
Priority to US10/218,175 priority patent/US7209485B2/en
Publication of DE10139936A1 publication Critical patent/DE10139936A1/de
Application granted granted Critical
Publication of DE10139936B4 publication Critical patent/DE10139936B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric

Landscapes

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

Abstract

Es wird ein Verfahren sowie eine Anordnung zur Steuerung von Datenpaketen in einem Rechner-Netzwerk vorgestellt. Bei dem erfindungsgemäßen Verfahren werden bestimmte Datenpakete aus der Gesamtheit eines Datenstroms über ein Gateway (10) mit einem Host-Prozessor (12) an Subsysteme (18) zur Weiterverarbeitung weitergeleitet bzw. Datenpakete von den Subsystemen (18) über das Gateway (10) in den Datenstrom eingeleitet. Dabei werden die Datenpakete von einem Datenpaket-Vermittler (16) direkt, d. h. an dem Host-Prozessor (12) vorbei, an die Subsysteme (18) weitergeleitet bzw. die Datenpakete, die von den Subsystemen (18) kommen, werden von dem Datenpaket-Vermittler (16) direkt über eine Schnittstelleneinrichtung (14) in den Datenstrom eingeleitet.

Description

  • Die Erfindung betrifft ein Verfahren zur Steuerung von Datenpaketen in Gateways, insbesondere von RTP(Real Time Transport Protocol)-Datenpaketen, und eine Anordnung hierfür.
  • In einem Rechner-Netzwerk, beispielsweise einem Ethernet, werden heute schon häufig Sprach- und Videodaten übertragen. Gerade bei einer Videokonferenz kommt es auf eine schnelle Übertragung der Daten an, damit die Teilnehmer keine Zeitsprünge und/oder Verzögerungen bemerken, sondern vielmehr eine kontinuierliche Übertragung empfinden. Die Datenpakete für die Sprach- und Videoübertragung sind in der Regel mit einem RT-Protokoll gekennzeichnet.
  • Die über das Ethernet transportierten RTP-Datenpakete werden in einem Gateway zu einem dort angeordneten Host-Prozessor geleitet. Der Host-Prozessor filtert die RTP-Datenpakete aus dem Datenstrom des Ethernet aus und führt die herausgefilterten Pakete zur Weiterverarbeitung Subsystemen zu, beispielsweise Digital-Signal-Prozessoren (DSP). Die Subsysteme können die empfangenen Daten weiterverarbeiten, beispielsweise eine Umkodierung in PCM(Pulse Code Modulation)-Darstellung durchführen, und anschließend in konventioneller Art weiterleiten.
  • In der Gegenrichtung kodieren die DSPs Sprach- und Videosignale in RTP-Datenpakete um und senden sie an einen Host- Prozessor. Dieser wiederum leitet die Datenpakete an die Schnittstelleneinrichtung zum Ethernet weiter, um die Datenpakete in den Ethernet-Datenstrom einzufügen.
  • Der Host-Prozessor ist beim Empfangen und beim Senden von RTP-Daten beteiligt. Das führt gerade bei einem hohen Aufkommen von RTP-Daten zu einer hohen Auslastung des Host-Prozessors, dessen Leistungskapazität nunmehr anderen Prozessen nicht zur Verfügung steht.
  • Aufgabe der vorliegenden Erfindung ist es daher, ein Verfahren und eine Anordnung für die Steuerung von Datenpaketen in einem Gateway anzugeben, durch das der Host-Prozessor erheblich entlastet wird, was wiederum zu einer deutlichen Performancesteigerung bei anderen Aufgaben führt.
  • Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 und eine Anordnung nach Anspruch 5 gelöst.
  • Ein wesentlicher Gedanke der Erfindung besteht darin, daß in dem erfindungsgemäßen Verfahren die RTP-Datenpakete in dem Gateway in Empfangsrichtung an dem Host-Prozessor vorbei an die weiterverarbeitenden Subsysteme geleitet werden. In Senderichtung werden die RTP-Datenpakete von den Subsystemen an dem Host-Prozessor vorbei an die Schnittstelleneinrichtung zur Einspeisung in den netzinternen (Ethernet-)Datenstrom weitergeleitet. Hierfür ist ein Datenpaket-Vermittler der Schnittstelleneinrichtung nachgeordnet, der RTP-Daten an die Subsysteme und andere Datenpakete an den Host-Prozessor weiterleitet. In Gegenrichtung bzw. Senderichtung empfängt der Datenpaket-Vermittler sowohl von den Subsystemen wie dem Host-Prozessor Datenpakete, die er an die Schnittstelleneinrichtung weiterleitet, wobei er RTP-Datenpakete bevorzugt zur Einspeisung in den (Ethernet-)Datenstrom an die Schnittstelleneinrichtung sendet.
  • Eine vorteilhafte Ausführungsform der Erfindung filtert in Empfangsrichtung RTP-Datenpakete aus dem Datenstrom des Netzwerkes und leitet diese herausgefilterten Datenpakete direkt an eine Bank von DSPs zur Weiterverarbeitung weiter.
  • Bevorzugt werden bei dem Herausfiltern die Adressen aller Datenpakete mit Adressen verglichen, die in einem Adressenspeicher abgelegt sind. Der Datenpaketvermittler leitet die Datenpakete mit Adressen, die abgespeichert sind, an die Subsysteme bzw. DSPs weiter. Datenpakete, deren Adressen nicht zu dem abgespeicherten Adressen gehören, können ungehindert den Host-Prozessor erreichen.
  • In einer vorteilhaften Ausführungsform der vorliegenden Erfindung werden in Senderichtung die von den DSPs kodierten Datenpakete in RTP-Datenpakete transformiert. Diese werden anschließend in den Datenstrom des Netzwerkes eingeleitet. Hierbei können die RTP-Datenpakete bevorzugt in das Netzwerk eingeleitet werden, damit die Echtzeitanwendungen für den Benutzer komfortabler durchführbar sind.
  • Vorzugsweise wird die erfindungsgemäße Anordnung in einem Netzwerk realisiert, das ein lokales Netzwerk auf Basis des Ethernet-Protokolls ist.
  • In einer weiteren vorteilhaften Ausführungsform weist die erfindungsgemäße Anordnung eine Bank von DSPs auf, an die der Datenpaket-Vermittler RTP-Datenpakete zur Weiterverarbeitung direkt weiterleitet.
  • In einer besonders vorteilhaften Ausführungsform weist die erfindungsgemäße Anordnung mindestens einen weiteren Datenpaket-Vermittler auf, so daß die unterschiedlichen Datenpaket- Vermittler unterschiedliche Arten von Datenpaketen an entsprechende Subsysteme weiterleiten können.
  • Vorteile und Zweckmäßigkeiten der Erfindung ergeben sich im übrigen aus den Unteransprüchen sowie der nachfolgenden Beschreibung anhand der Figuren.
  • Fig. 1 zeigt schematisch eine herkömmliche Schnittstellen- Prozessor-Anordnung für ein Gateway,
  • Fig. 2 zeigt schematisch eine erfindungsgemäße Anordnung für ein Gateway,
  • Fig. 3 ist eine Skizze für die Signalleitung in Empfangsrichtung,
  • Fig. 4 ist eine Skizze für die Signalleitung in Senderichtung,
  • Fig. 5 zeigt ein Flußdiagramm zur Adreßbestimmung mit Hilfe des Adressenspeichers,
  • Fig. 6 zeigt schematisch die Prozeßsteuerung in einem erfindungsgemäßen Datenpaket-Vermittler und
  • Fig. 7 zeigt schematisch eine zweite Ausführungsform einer erfindungsgemäßen Anordnung für ein Gateway.
  • Fig. 1 zeigt eine herkömmliche Schnittstellen-Prozessor-Anordnung für ein Gateway mit einem Mikroprozessor (Host-Prozessor) 2, der mit einer Schnittstelleneinrichtung (Physical Interface Device) 4 über ein Media Independent Interface (MII) verbunden ist. Weiterhin ist der Host-Prozessor 2 mit einer Bank von Subsystemen 6 verbunden. Die Subsysteme 6 können beispielsweise Digital-Signal-Prozessoren (DSP) sein, die RTP-Datenpakete weiterverarbeiten. Zusätzlich ist der Host- Prozessor 2 mit einem Speicher (SDRAM) 8 verbunden, in dem ankommende Datenpakete zwischengespeichert werden können.
  • Aus der Figur ist deutlich ersichtlich, daß alle Datenpakete aus dem Ethernet-Datenstrom bzw. von der Schnittstelleneinrichtung 4, auch die für die Subsysteme 6 bestimmten, über den Host-Prozessor 2 geleitet werden.
  • Fig. 2 zeigt eine erfindungsgemäße Anordnung 10 für ein Gateway mit einem Host-Prozessor 12, einer Schnittstelleneinrichtung 14 und einem Datenpaket-Vermittler (Packet Router) 16. Die Schnittstelleneinrichtung 14 ist sowohl mit dem Host- Prozessor 12 als auch mit dem Datenpaket-Vermittler 16 mittels MII verbunden. Der Datenpaket-Vermittler 16 ist mit dem Host-Prozessor 12, mit Subsystemen (DSP) 18, einem Zwischenspeicher (SRAM) 20 und einem Adressenspeicher (CAM) 22 verbunden.
  • Der Datenpaket-Vermittler 16 erhält von der Schnittstelleneinrichtung 14 alle für diese Anordnung 10 bestimmten Datenpakete. Er vergleicht die Adressen der Datenpakete mit einer Liste von Adressen, die im Adressenspeicher 22 abgelegt sind. Datenpakete mit einer derartigen Adresse werden von dem Datenpaket-Vermittler 16 direkt an das entsprechende Subsystem 18 weitergeleitet. Datenpakete, deren Adresse nicht mit einer Adresse aus dem Adressenspeicher 22 übereinstimmt, werden von dem Datenpaket-Vermittler 16 an den Mikroprozessor 12 weitergeleitet.
  • Der Adressenspeicher 22 ist ein sogenannter CAM (Content- Adress-Memory) und wird für das Speichern der Verbindungsdaten benötigt. Es ist möglich, einen handelsüblichen CAM einzusetzen. Bei einer Anzahl von 256 und mehr aktiven RTP- Verbindungen ist es erforderlich, schnell eine Entscheidung zu treffen, wohin die Pakete geleitet werden sollen. Die CAM- Funktionalität kann innerhalb des Datenpaket-Vermittlers 16 mit dedizierten RAM-Zellen (Read and Modify Memory) realisiert werden. Der Adressenspeicher 22 muß vom Host-Prozessor 12 verwaltet werden und steht dann für das Verteilen bzw. Routing der RTP-Pakete zur Verfügung. Es ist nicht notwendig den Host-Prozessor 12 mit einem Adressenspeicher 22, der für ein Ethernet geeignet ist, auszustatten.
  • Ein externer Speicher 20 dient als Buffer für die Datenpakete in beiden Richtungen. Je nach Datenaufkommen und Kosten wird ein SRAM- oder DRAM-Interface eingesetzt. Ein SRAM hat die höhere Zugriffsgeschwindigkeit, ist aber ab einer bestimmten Größe wesentlich teurer als ein DRAM. Die Geschwindigkeitsnachteile des DRAM lassen sich durch den Einsatz eines Cache und/oder einer Pipeline minimieren. Der Aufwand für eine geschwindigkeitsoptimierte DRAM-Implementierung ist wesentlich höher als für eine SRAM-Variante. Wird der Speicher 20 mit SRAM realisiert, steht ausreichend schneller Speicher auch für den Austausch zwischen interen Modulen zur Verfügung. Eine Schätzung ergibt einen Bedarf von etwa 2 bis 4 MByte bei 256 Kanälen für den Spezialfall von RTP-Voice-Paketen. Die Datenbusbreite sollte dem Host-Prozessor 12 und den Datenstrukturen angepaßt werden. Die Anzahl der Adreßleitungen richtet sich nach dem Adreßraum, der zur Verfügung gestellt werden muß.
  • Die Register innerhalb des Zwischenspeichers 20, die für die Steuerung der Module notwendig sind, müssen direkt gelesen und beschrieben werden können. Der Datenbereich befindet sich im externen Speicher 20. Für jeden Kanal gibt es Memory- Bereiche, auf die der Host-Prozessor 12 zugreifen kann. Es wäre möglich, daß zuerst eine Kanalnummer eingegeben werden muß und der Datenpaket-Vermittler 16 dann die Daten für den Host-Prozessor 12 bereitstellt oder sie in die jeweilige Speicherstruktur überträgt.
  • Der Host-Prozessor 12 muß Einstellungen in jedem DSP 18 vornehmen können. Es ist aber nicht notwendig, daß er direkt auf den DSP 18 zugreift. Hier kann auch der Zwischenspeicher 20 genutzt werden. Die Struktur kann durch den Datenpaket- Vermittler 16 an die DSPs 18 weitergegeben werden. Die RTP- Pakete einer aktiven Verbindung werden beim Einsatz des Datenpaket-Vermittlers 16 nicht mehr über den Host-Prozessor 12 übertragen.
  • Fig. 3 zeigt skizzenartig Signalleitungen in einer erfindungsgemäßen Anordnung in Empfangsrichtung. Wie bereits aus der Fig. 2 ersichtlich, sind sowohl der Mikroprozessor 12 als auch der Datenpaket-Vermittler 16 mit der Schnittstelleneinrichtung 14 jeweils über ein MII verbunden. Beide MII- Interfaces können auf der gleichen Schnittstelleneinrichtung 14 arbeiten. Der Mikroprozessor 12 oder der Datenpaket- Vermittler 16 signalisiert beispielsweise mit einem RSTRT- Signal den Anfang eines gültigen Ethernet-Paketes.
  • Der Datenpaket-Vermittler 16 "hört" auf der Ethernet-Schnittstelle 14 mit und generiert nach Auswertung aller Informationen das Reject-Signal für den Mikroprozessor 12 oder den eigenen MAC (Media Access Control). Wird das Reject-Signal vor dem Ende des Ethernet-Paketes generiert, werden die verwendeten Buffer-Deskriptoren für neue Pakete verwendet. Die Daten im Buffer werden verworfen. Im Falle einer Implementierung mit einem Motorola PowerPC wird der Prozessorcore nicht mit aufwendigen Adreßvergleichen belastet. Gleich bei Empfang der Daten wird entschieden, ob das Ethernet-Paket jetzt verarbeitet werden muß oder nicht. Das RSTRT-Signal markiert den Start der Empfangsadresse des Ethernet-Paketes. So wird die Kontrolllogik immer neu auf die ankommenden Pakete synchronisiert.
  • Fig. 4 zeigt ebenfalls die Anordnung wie Fig. 3, allerdings mit den Signalleitungen in Senderichtung. In Senderichtung, also vom Mikroprozessor 12 zur Schnittstelleneinrichtung 14, sorgt eine Steuerung der Kollisionssignale für das Synchronisieren beider MACs, des Host-Prozessors 12 und des Datenpaket-Vermittlers 16, auf einer Schnittstelleneinrichtung 14. Diese Steuerung wird von dem Datenpaket-Vermittler 16 übernommen. Ein TX_EN-Signal wird vom Mikroprozessor 12 generiert. Es markiert ein gültiges Daten-Nibble auf dem MI- Interface in Senderichtung. Wenn der Datenpaket-Vermittler 16 gerade ein Datenpaket versendet, wird im Mikroprozessor 12 mit einem CRS(Carrier Receive Sense)-Signal und einem COL(Collision)-Signal signalisiert, daß zur Zeit das Übertragungsmedium verwendet wird. Der MAC des Mikroprozessors 12 geht somit in den Kollisions-Zyklus und wiederholt seine letzte Übertragung.
  • Im Fall einer Kollision aus der Übertragungsstrecke (Schnittstelleneinrichtung 14 signalisiert Kollision), wird diese transparent an den Mikroprozessor 12 weitergeleitet.
  • In Fig. 5 ist ein Flußdiagramm zur Adreßbestimmung mit Hilfe des Adressenspeichers 22 aus Fig. 2 dargestellt. Der Adressenspeicher 22 bietet die Möglichkeit, die ankommenden Adressen mit seinen Einträgen zu vergleichen. Innerhalb kürzester Zeit kann signalisiert werden, ob die Adresse im Adreßspeicher 22 steht oder nicht. Dieser Vergleich ist unabhängig von der Software auf dem Host-Prozessor 12 (aus Fig. 2). Der Adressenspeicher 12 kann beispielsweise ein MCM69C232 von Motorola sein. Dieser kann 4096 Einträge mit je 64 Bit Tiefe verwalten. Die mittlere Zugriffszeit ist 160 ns bei einer Taktrate von 50 MHz. Die Suche nach einer gültigen Adresse muß in drei Schritten erfolgen. Als erstes muß im ankommenden Ethernet-Frame 30 nach einer gültigen Ethernet-Adresse gesucht werden. In der Box 31 wird die Ethernet-Adresse gespeichert. In der Box 32 wird überprüft, ob es sich um eine gültige Adresse handelt. Ist die Adresse nicht korrekt, erfolgtsofort ein Reject 33 für beide MACs. Als nächstes wird in der Box 34 in dem Frame die IP-Adresse herausgefiltert, um diese in der Box 35 auf Gültigkeit zu überprüfen. Stimmt diese nicht, erfolgt das Reject 33 für beide MACs.
  • Da der IP-Header eine variable Länge haben kann, ist die Position des UDP-Destination-Port nicht fix. Das bedeutet, daß der Datenpaket-Vermittler 16 sich bei dem Frame erneut auf die Position des UDP-Destination-Port einstellen muß. Da es sich um viele aktive UDP-Verbindungen handelt, wird zum Auffinden eines gültigen UDP-Destination-Port der Adressenspeicher 22 verwendet. Deshalb wird in der Box 36 die UDP-Adresse herausgefiltert und in der Box 37 an den Adressenspeicher 22 übergeben. Dieser überprüft in der Box 38 die UDP-Adresse, d. h. er vergleicht die übergebene UDP-Adresse mit denen im Adressenspeicher abgelegten Adressen. Wenn der Adressenspeicher 22 keine gültige UDP-Adresse gefunden hat, wird in der Box 39 intern ein Reject-Signal erzeugt. Wenn der Adressen- Zwischenspeicher 22 eine gültige UDP-Destination-Port gefunden hat, wird in der Box 40 ein Reject-Signal für den MAC des Mikroprozessors 12 erzeugt.
  • Da der UDP-Destination-Port nur 32 Bit groß ist und der Adreß-Zwischenspeicher 22 eine Tiefe von 64 Bit hat, können die verbleibenden 32 Bit zum Speichern zusätzlicher Daten, beispielsweise Verbindungsdaten, Port, DSP usw., genutzt werden. Die Match-Daten werden in der Box 41 an die Speicherverwaltung übergeben und der Adressenspeicher 22 bietet die Möglichkeit, diese Match-Daten auszugeben. In der Box 42 wird die Speicheradresse für RTP-Pakete an dem MRC des Datenpaket- Vermittlers übermittelt. Dieser kann die Daten nun zur Weiterverarbeitung nutzen.
  • In Fig. 6 ist schematisch eine Prozeßsteuerung für mehrere Prozesse X0 bis X5 in einem erfindungsgemäßen Datenpaket- Vermittler (16 aus Fig. 2) dargestellt. Die einzelnen Zugriffe auf die unterschiedlichen Teile des Datenpaket-Vermittlers 16 müssen gesteuert werden. Mehrere Prozesse können dabei gleichzeitig auf die Ressourcen zugreifen, beispielsweise müssen auf den Speicher (20 aus Fig. 2) mehrere Prozesse schreiben und lesen können. Es darf hier nicht zu Blockaden, Kollision oder Konflikten kommen. Kollisionen lassen sich beispielsweise durch den Einsatz von Buffern und/oder einer Pipeline vermeiden. Diese liegen innerhalb des Chips, um unnötigen Verkehr auf dem Speicher 20 zu vermeiden. Um eine optimale Performance zu erzielen, sollte der Lesezugriff immer als Burst erfolgen. Geschrieben werden darf nur die erforderliche Menge an Daten. Buffer und interne Strukturen können aber auch so ausgelegt werden, daß hier ein Burst auf dem Speicher 20 möglich ist.
  • Den einzelnen Prozessen X0-X5 werden je nach Datenaufkommen, ein Speicherblock oder mehrere Speicherblöcke zugeordnet. Die Speicherblöcke sind in ihrer Größe nicht variabel. Die Größe entspricht der eines Burst auf dem externen Speicher 20. Eine zusätzliche Priorität wird durch die Pipeline und den Einstiegspunkt erreicht. Die WAIT-Zyklen (T-2, T-4) sind so zu gestalten, daß alle Prozesse X0 bis X5 bedient werden. WAIT-Zyklen werden nur eingefügt, wenn ein Ereignis an dem folgenden Einstiegspunkt ansteht. Die Prozesse X0 und X1 haben sehr niedrige Priorität. Der Prozeß X5 hat die höchste Priorität, aber ein geringes Datenaufkommen. Die Übersicht der Fig. 6 nimmt keine Wertung für die Prioritätenverteilung der einzelnen Module innerhalb des Datenpaket- Vermittlers 16 vor.
  • In der Fig. 7 ist eine zweite Ausführungsform einer erfindungsgemäßen Anordnung mit zwei Datenpaket-Vermittlern 16, 16' dargestellt. Sie unterscheidet sich von der ersten Ausführungsform, die in Fig. 2 beschrieben wurde, durch einen zusätzlichen Datenpaket-Vermittler 16', der ebenfalls (wie der Datenpaket-Vermittler 16) sowohl mit der Schnittstelleneinrichtung 14 als auch mit dem Host-Prozessor 12 verbunden ist. Der Datenpaket-Vermittler 16' weist einen eigenen Adressenspeicher 22' auf, mit dem er verbunden ist. Weiterhin ist der Datenpaket-Vermittler 16' mit einem Speicher 20' verbunden, der zur Zwischenspeicherung von Datenpaketen dient. Eine Bank von weiteren Subsystemen bzw. DSPs 18' ist ebenfalls mit dem Datenpaket-Vermittler 16' verbunden.
  • Wie bereits in Fig. 2 beschrieben, wird der Adressenspeicher 22 vom Host-Prozessor 12 verwaltet. Ebenso wird der Adressenspeicher 22' vom Host-Prozessor 12 verwaltet. Der Host- Prozessor 12 kann in der Anordnung aus Fig. 7 zwei verschiedene Adressenlisten verwalten - eine in dem Adressenspeicher 22, die zweite in dem Adressenspeicher 22'. Deshalb können Datenpakete unterschiedlicher Adressen an unterschiedliche Subsysteme 18 bzw. 18' weitergeleitet werden. Es wäre denkbar, daß der Datenpaket-Vermittler 16 Datenpakete mit Videoinformationen an Videodaten weiterverarbeitende Subsysteme 18 weiterleitet. Auf der anderen Seite kann der Datenpaket- Vermittler 16' beispielsweise Datenpakete mit Sprachinformationen an entsprechende Subsysteme 18' weiterführen, die Voice-Datenpakete weiterverarbeiten.
  • In der dargestellten Anordnung 10' sind die beiden Datenpaket-Vermittler 16 und 16' parallel zueinander angeordnet. Vorteil ist, daß beide Datenpaket-Vermittler 16, 16' ohne Zeitverzögerung jeweils die Datenpakete aus dem Datenstrom herausfiltern können, deren Adresse in dem jeweiligen Adressenspeicher 22 bzw. 22' abgelegt ist. Allerdings erhält der Host-Prozessor 12 dieser Anordnung 10' alle Datenpakete, da er die vom Datenpaket-Vermittler 16 herausgefilterten Datenpakete vom Datenpaket-Vermittler 16' erhält. Ebenso erhält er die vom Datenpaket-Vermittler 16' herausgefilterten Datenpakete vom Datenpaket-Vermittler 16. Vorteilhaft an dieser Anordnung 10' ist lediglich der Umstand, daß die Subsysteme 18 bzw. 18' mit nur einer geringen Zeitverzögerung die für sie bestimmten Datenpakete erhalten. Die Performance-Steigerung des Mikroprozessors bzw. Host-Prozessors 12 wird allerdings dadurch gemindert, daß er nun aus allen ihn erreichenden Datenpakete die herausfiltern muß, die er weiterzuverarbeiten hat bzw. die Datenpakete, die er verwerfen kann.
  • Es ist folglich eine Anordnung möglich (nicht dargestellt), in der mehrere Datenpaket-Vermittler in Serie angeordnet sind. Dann filtert der erste, der Schnittstelleneinrichtung nachgeordnete Datenpaket-Vermittler entsprechend seiner in seinem Adreßspeicher abgelegten Adressenliste Datenpakete aus. Alle nicht herausgefilterten Datenpakete leitet er an den zweiten Datenpaket-Vermittler weiter. Dieser wiederum filtert nun seinerseits alle die Datenpakete aus dem Datenstrom aus, deren Adresse mit einer in seinem Adressenspeicher abgelegten Adressenliste übereinstimmt. Vorteil eines Gateways mit seriell angeordneten Datenpaket-Vermittlern ist wiederum eine deutliche Steigerung des Host-Prozessors 12, da er nur die Datenpakete erhält, die für ihn bestimmt sind und nicht vorher herausgefiltert wurden. Nachteilig ist, daß das Herausfiltern bei dem zweiten Datenpaket-Vermittler mit einer Zeitverzögerung erfolgt. Diese Zeitverzögerung wird bei weiteren in Serie angeordneten Datenpaket-Vermittlern noch größer.
  • Die Ausführung der Erfindung ist nicht auf diese Beispiele sowie die oben hervorgehobenen Aspekte beschränkt, sondern im Rahmen der Ansprüche ebenso in einer Vielzahl von Abwandlungen möglich, die im Rahmen fachgemäßen Handelns liegen.
  • Es wird in den oben beschriebenen Anordnungen zu keiner Zeitverzögerung kommen. Ankommende Pakete werden inpraxi nicht zwischengespeichert sondern sind bis zum Host-Prozessor transparent. Dem Host-Prozessor wird immer signalisiert, ob er das aktuelle Paket verwenden darf oder nicht (im letzteren Falle: REJECT-Signal). Eine parallele Anordnung ist nicht erforderlich und führt in Senderichtung (Host-Prozessor sendet Pakete) zu Problemen. Die Verzögerungszeit bei einer Kastradierung ist nur marginal (infolge Gatterlaufzeiten der Signalverstärker).

Claims (8)

1. Verfahren zur Steuerung von Datenpaketen in einem Rechner- Netzwerk, bei dem bestimmte Datenpakete aus der Gesamtheit eines Datenstromes über ein Gateway (10) mit einem Host- Prozessor (12) an Subsysteme (18) zur Weiterverarbeitung weitergeleitet werden bzw. Datenpakete von den Subsystemen (18) über das Gateway (10) in den Datenstrom eingeleitet werden, dadurch gekennzeichnet,
dass die Datenpakete von einem Datenpaket-Vermittler (16) direkt, d. h. an dem Host-Prozessor (12) vorbei, an die Subsysteme (18) weitergeleitet werden bzw.
die Datenpakete, die von den Subsystemen (18) kommen, von dem Datenpaket-Vermittler (16) direkt in den Datenstrom eingeleitet werden.
2. Verfahren nach Anspruch 1, das in Empfangsrichtung folgende Schritte umfaßt:
- Herausfiltern von RTP(Real Time Transport Protocol)-Datenpaketen aus dem Datenstrom des Netzwerkes,
- Weiterleiten der herausgefilterten RTP-Datenpakete direkt an eine Bank von Digital-Signal-Prozessoren (DSP) (18) zur Weiterverarbeitung.
3. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Schritt des Herausfilterns folgende Teilschritte umfaßt:
- Vergleichen von Adressen aller Datenpakete mit Adressen, die in einem Adressenspeicher (22) abgelegt sind,
- Durchlassen eines Datenpaktes entsprechend dem Vergleichergebnis an einen Host-Prozessor (12), wenn die Adresse des Datenpaketes nicht mit einer der gespeicherten Adressen übereinstimmt bzw. Weiterleiten an die Bank von Digital-Signal- Prozessoren (18), insbesondere noch Zwischenspeicherung, wenn die Adresse des Datenpaketes mit einer der gespeicherten Adressen übereinstimmt.
4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren in Senderichtung folgende Schritte umfaßt:
- Transformieren der von den Digital-Signal-Prozessoren (18) kodierten Datenpakete in RTP-Datenpakete,
- Einleiten der RTP-Datenpakete in den Datenstrom des Netzwerk.
5. Anordnung zur Steuerung von Datenpaketen in einem Gateway (10) eines Rechnernetzwerkes, die folgendes umfaßt:
eine Schnittstelleneinrichtung (14), die dazu dient, die Datenpakete zwischen einem Datenstrom des Netzwerkes und dem Gateway (10) auszustauschen,
einen Host-Prozessor (12),
einen Speicher (10), der als Zwischenspeicher für Datenpakete in Empfangs- und Senderichtung dient, mindestens ein Subsystem (18) zur Verarbeitung von Datenpaketen, insbesondere RTP-Datenpaketen,
gekennzeichnet durch
einen Adressenspeicher (22), der die Adressen bestimmter Verbindungen speichert, und
einen Datenpaket-Vermittler (16), der in Empfangsrichtung die Datenpakete von der Schnittstelle (14) mit Adressen, die im Adressenspeicher (22) gespeichert sind, direkt, d. h. an dem Host-Prozessor (12) vorbei, an ein Subsystem (18) weiterleitet und
in Senderichtung die Datenpakete eines Subsystemes (18) direkt zur Schnittstelleneinrichtung (14) zur Einleitung in den Datenstrom weiterleitet.
6. Anordnung nach Anspruch 5, dadurch gekennzeichnet, dass das Netzwerk ein lokales Netzwerk auf Basis des Ethernet-Protokolls ist.
7. Anordnung nach Anspruch 5 oder 6, gekennzeichnet durch eine Bank von Digital-Signal-Prozessoren (18), an die der Datenpaket-Vermittler (16) RTP-Datenpakete zur Weiterverarbeitung direkt weiterleitet.
8. Anordnung nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass die Anordnung mindestens einen weiteren Datenpaket- Vermittler aufweist, der jeweils unterschiedliche Arten von Datenpaketen an Subsysteme weiterleitet, die die Datenpakete weiterverarbeiten.
DE10139936A 2001-08-14 2001-08-14 Verfahren und Anordnung zur Steuerung von Datenpaketen Expired - Fee Related DE10139936B4 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE10139936A DE10139936B4 (de) 2001-08-14 2001-08-14 Verfahren und Anordnung zur Steuerung von Datenpaketen
EP02102025A EP1284561B1 (de) 2001-08-14 2002-07-11 Verfahren und Anordnung zur Steuerung von Datenpaketen
DE50206134T DE50206134D1 (de) 2001-08-14 2002-07-11 Verfahren und Anordnung zur Steuerung von Datenpaketen
US10/218,175 US7209485B2 (en) 2001-08-14 2002-08-14 Method and arrangement for controlling data packets

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10139936A DE10139936B4 (de) 2001-08-14 2001-08-14 Verfahren und Anordnung zur Steuerung von Datenpaketen

Publications (2)

Publication Number Publication Date
DE10139936A1 true DE10139936A1 (de) 2003-04-24
DE10139936B4 DE10139936B4 (de) 2005-04-28

Family

ID=7695434

Family Applications (2)

Application Number Title Priority Date Filing Date
DE10139936A Expired - Fee Related DE10139936B4 (de) 2001-08-14 2001-08-14 Verfahren und Anordnung zur Steuerung von Datenpaketen
DE50206134T Expired - Lifetime DE50206134D1 (de) 2001-08-14 2002-07-11 Verfahren und Anordnung zur Steuerung von Datenpaketen

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE50206134T Expired - Lifetime DE50206134D1 (de) 2001-08-14 2002-07-11 Verfahren und Anordnung zur Steuerung von Datenpaketen

Country Status (3)

Country Link
US (1) US7209485B2 (de)
EP (1) EP1284561B1 (de)
DE (2) DE10139936B4 (de)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW436491B (en) * 1997-08-22 2001-05-28 Ciba Sc Holding Ag Compositions for use in base-catalysed reactions, a process for curing said compostions and a process for photochemically generating bases in base catalysed polymeriaztion reactions
GB2413872B (en) * 2002-05-13 2006-03-01 Nvidia Corp Method and apparatus for providing an integrated network of processors
US20030212735A1 (en) * 2002-05-13 2003-11-13 Nvidia Corporation Method and apparatus for providing an integrated network of processors
US7397797B2 (en) * 2002-12-13 2008-07-08 Nvidia Corporation Method and apparatus for performing network processing functions
US7913294B1 (en) 2003-06-24 2011-03-22 Nvidia Corporation Network protocol processing for filtering packets
US20070127438A1 (en) * 2005-12-01 2007-06-07 Scott Newman Method and system for processing telephone technical support
GB2434945B (en) * 2006-01-31 2008-04-09 Roke Manor Research A method of filtering high data rate traffic
US20080046966A1 (en) * 2006-08-03 2008-02-21 Richard Chuck Rhoades Methods and apparatus to process network messages
US9325517B2 (en) 2008-10-27 2016-04-26 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8543243B2 (en) 2008-10-27 2013-09-24 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9377768B2 (en) 2008-10-27 2016-06-28 Lennox Industries Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US9268345B2 (en) 2008-10-27 2016-02-23 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8725298B2 (en) 2008-10-27 2014-05-13 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network
US8655490B2 (en) 2008-10-27 2014-02-18 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8762666B2 (en) 2008-10-27 2014-06-24 Lennox Industries, Inc. Backup and restoration of operation control data in a heating, ventilation and air conditioning network
US8452906B2 (en) 2008-10-27 2013-05-28 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8694164B2 (en) 2008-10-27 2014-04-08 Lennox Industries, Inc. Interactive user guidance interface for a heating, ventilation and air conditioning system
US8295981B2 (en) 2008-10-27 2012-10-23 Lennox Industries Inc. Device commissioning in a heating, ventilation and air conditioning network
US8352081B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8255086B2 (en) 2008-10-27 2012-08-28 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8802981B2 (en) 2008-10-27 2014-08-12 Lennox Industries Inc. Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system
US8463443B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US8433446B2 (en) 2008-10-27 2013-04-30 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US9632490B2 (en) 2008-10-27 2017-04-25 Lennox Industries Inc. System and method for zoning a distributed architecture heating, ventilation and air conditioning network
US9651925B2 (en) 2008-10-27 2017-05-16 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US8994539B2 (en) 2008-10-27 2015-03-31 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8615326B2 (en) 2008-10-27 2013-12-24 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9152155B2 (en) 2008-10-27 2015-10-06 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8600559B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. Method of controlling equipment in a heating, ventilation and air conditioning network
US8437877B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8774210B2 (en) 2008-10-27 2014-07-08 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8600558B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8744629B2 (en) 2008-10-27 2014-06-03 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8977794B2 (en) 2008-10-27 2015-03-10 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9678486B2 (en) 2008-10-27 2017-06-13 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8560125B2 (en) 2008-10-27 2013-10-15 Lennox Industries Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8788100B2 (en) 2008-10-27 2014-07-22 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US8442693B2 (en) 2008-10-27 2013-05-14 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9261888B2 (en) 2008-10-27 2016-02-16 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8352080B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8655491B2 (en) 2008-10-27 2014-02-18 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US9432208B2 (en) 2008-10-27 2016-08-30 Lennox Industries Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8463442B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8437878B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8661165B2 (en) 2008-10-27 2014-02-25 Lennox Industries, Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8564400B2 (en) 2008-10-27 2013-10-22 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8874815B2 (en) 2008-10-27 2014-10-28 Lennox Industries, Inc. Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network
US8855825B2 (en) 2008-10-27 2014-10-07 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8452456B2 (en) 2008-10-27 2013-05-28 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8798796B2 (en) 2008-10-27 2014-08-05 Lennox Industries Inc. General control techniques in a heating, ventilation and air conditioning network
US8239066B2 (en) 2008-10-27 2012-08-07 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8892797B2 (en) 2008-10-27 2014-11-18 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8548630B2 (en) 2008-10-27 2013-10-01 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
USD648642S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
USD648641S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
US8260444B2 (en) 2010-02-17 2012-09-04 Lennox Industries Inc. Auxiliary controller of a HVAC system
US10331586B2 (en) * 2015-10-30 2019-06-25 Samsung Electronics Co., Ltd. Nonvolatile memory device for providing fast booting and system including the same

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6157644A (en) * 1997-10-07 2000-12-05 Northern Telecom Limited Method and apparatus for accelerating OSI layer 3 routers
US6678246B1 (en) * 1999-07-07 2004-01-13 Nortel Networks Limited Processing data packets
EP1238489B1 (de) * 1999-12-13 2008-03-05 Broadcom Corporation Sprach-durchgangsvorrichtung mit sprachsynchronisierung in abwärtsrichtung
FI112308B (fi) * 2000-09-14 2003-11-14 Nokia Corp Protokollan käsittelyn jakaminen

Also Published As

Publication number Publication date
DE50206134D1 (de) 2006-05-11
US20030035431A1 (en) 2003-02-20
EP1284561B1 (de) 2006-03-22
EP1284561A2 (de) 2003-02-19
US7209485B2 (en) 2007-04-24
EP1284561A3 (de) 2004-03-24
DE10139936B4 (de) 2005-04-28

Similar Documents

Publication Publication Date Title
EP1284561B1 (de) Verfahren und Anordnung zur Steuerung von Datenpaketen
EP3695577B1 (de) Verfahren zur daten-kommunikation in einem tsn netzwerk, steuerungsverfahren und vorrichtung
DE69917555T2 (de) Vermittlungseinrichtung mit mehrstufiger Warteschlangeschema
DE69737361T2 (de) Schnelle vermittlungsvorrichtung
DE602005003492T2 (de) Verfahren, Vorrichtung und System zum synchronisierten Kombinieren von Paketdaten
EP2882144B1 (de) Verfahren und Filteranordnung zum Filtern von über einen seriellen Datenbus eines Kommunikationsnetzwerks in einem Teilnehmer des Netzwerks eingehenden Nachrichten
EP2847965B1 (de) Verfahren zur übertragung von daten in einem paketorientierten kommunikationsnetzwerk und entsprechend eingerichtetes teilnehmergerät an dem kommunikationsnetzwerk
EP0276776A2 (de) Digitales Koppelnetz für Leitungs- und Paketvermittlung und Koppelfeldbaustein hierzu
DE102007017835A1 (de) Paketvermittlungsvorrichtung und lokales Kommunikationsnetz mit einer solchen Paketvermittlungsvorrichtung
EP0351014A2 (de) Koppelfeld für ein Vermittlungssystem
DE10296700T5 (de) Flusssteuerungssystem zur Verringerung der Speicherpufferanforderungen und zur Herstellung einer Prioritätsbedienung zwischen Netzen
DE69928251T2 (de) Datennetzkommunikationen
DE102022200567A1 (de) Verarbeitung von paketen in ungeordneter reihenfolge
WO2004100498A1 (de) Verfahren zum datenaustausch zwischen netzelementen in netzwerken mit verschiedenen adressbereichen
DE3928481C2 (de) Prioritätsorientiertes dezentrales Busvergabesystem
DE60306645T2 (de) Rückwandleiterplattenarchitektur für einen medienserver
EP1453252B1 (de) Übertragung von Daten in einem schaltbaren Datennetz
WO2000008798A2 (de) Verfahren zur umleitung von datenpaketen auf ein alternatives netz
DE602004011623T2 (de) Elektronische Schaltungsanordnung mit über ein Kommunikationsnetzwerk gekoppelten Verarbeitungseinheiten
DE19935126B4 (de) Verfahren und Vorrichtung zur Vermittlung einer Mehrzahl von paket-orientierten Signalen
WO2004112341A2 (de) Verfahren und vorrichtung zur verarbeitung von echtzeitdaten
EP1358735B1 (de) Einheit zur verteilung und verarbeitung von datenpaketen
DE19741042C2 (de) Cross-Connect-Schalter für den Zeit-Multiplex-Betrieb in einem digitalen Kommunikationsnetz
EP3590235B1 (de) Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk
EP1208678B1 (de) Zellkonfliktauflösungseinheit für eine einrichtung zur vermittlung einer mehrzahl von paket-orientierten signalen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee