-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft ein Kommunikationssystem, und insbesondere
betrifft es eine Proxyarchitektur zur Verbesserung der Netzwerkleistung.
-
Diskussion
des allgemeinen Standes der Technik
-
Die
Verankerung von Datennetzwerken in die Routinen der modernen Gesellschaft,
wie dies durch die Vorherrschaft des Internet, insbesondere des
World Wide Web, zum Tragen kommt, hat zunehmend wachsende Anforderungen
an die Serviceprovider gestellt, um die Netzwerkleistung kontinuierlich zu
verbessern. Um diese Herausforderung zu erfüllen, haben Serviceprovider
stark in das Aufrüsten
ihrer Netzwerke investiert, um die Systemkapazität (d.h. die Bandbreite) zu
erhöhen.
Unter vielen Umständen
sind solche Aufrüstungen
bzw. Aktualisierungen nicht unbedingt ökonomisch realisierbar, oder physikalische
Beschränkungen
des Kommunikationssystems erlauben kein einfaches "Aufrüsten". Demgemäß haben
Serviceprovider ebenfalls in die Ent wicklung von Techniken investiert,
um die Leistung ihrer Netzwerke zu verbessern. Da viele der heutigen
Netzwerke entweder mit dem Transmission Control Protocol/Internet
Protocol (TCP/IP) arbeiten oder eine Schnittstelle dazu benötigen, wurde
der Fokus auf die Optimierung von TCP/IP-basierten Netzwerkabläufen gerichtet.
-
Als
Netzwerkstandard für
das globale Internet hat TCP/IP eine hohe Akzeptanz innerhalb der
Industrie aufgrund seiner Flexibilität und seines Erbes in der Forschungsgemeinschaft
erhalten. Das Transmission Control Protocol (TCP) ist das dominierende Protokoll,
das heutzutage im Internet verwendet wird. TCP wird von dem Internet
Protocol (IP) getragen und wird in einer Vielzahl von Anwendungen
verwendet, einschließlich
einem zuverlässigen
File-Transfer bzw. File-Übertragung
und Internet Web Page-Zugangsanwendungen. Die vier Schichten des
TCP/IP Protocol sind in 17 dargestellt.
Wie dargestellt, umfasst die Verbindungsschicht (oder Netzwerkschnittstellenschicht) 10 Vorrichtungstreiber
in das Betriebssystem und jede entsprechende Netzwerk-Schnittstellenkarte.
Zusammen handhaben die Vorrichtungstreiber und die Schnittstellenkarten Hardware-Eigenschaften
der physikalischen Schnittstellen mit Kabeln oder jeglicher Art
von Medium, das verwendet wird. Die Netzwerkschicht (ebenfalls als Internetschicht
bezeichnet) 12 handhabt die Bewegung der Pakete im Netzwerk.
Das Routen bzw. Leiten der Pakete findet beispielsweise in der Netzwerkschicht 12 statt.
IP, Internet Control Massage Protocol (ICMP) und das Internet Group
Management Protocol (IGMP) können
die Netzwerkschicht in dem TCP/IP Protocol bereitstellen. Die Transportschicht 14 stellt
einen Datenstrom zwischen zwei Hosts bereit, für die Anwendungsschicht 16 zuvor.
-
In
dem TCP/IP Protocol gibt es zumindest zwei unterschiedliche Transportprotokolle,
TCP und ein User Datagram Protocol (UDP). TCP, das einen zuverlässigen Datenstrom
zwischen zwei Hosts bereitstellt, ist hauptsächlich mit dem Teilen der Daten beschäftigt, die
von der Anwendungsschicht 16 zu diesem gelangt, in geeignet
bemessene Segmente für
die Netzwerkschicht 12 darunter, mit dem Bestätigen empfangener
Pakete, dem Setzen von Timeouts, um sicherzustellen, dass das andere
Ende Pakete bestätigt,
die gesendet wurden, usw. Da dieser zuverlässige Datenstrom von der Transportschicht 14 bereitgestellt
wird, ist die Anwendungsschicht 16 von diesen Merkmalen
isoliert. UDP auf der anderen Seite stellt einen sehr viel einfacheren
Service der Anwendungsschicht 16 zur Verfügung. UDP
sendet nur Datenpakete, die Datagramme genannt werden, von einem
Host zum anderen, ohne Garantie, dass die Datagramme ihr Ziel erreichen
werden. Jede gewünschte
Zuverlässigkeit
bzw. Sicherheit muss durch eine höhere Schicht hinzugefügt werden,
wie beispielsweise die Anwendungsschicht 16.
-
Die
Anwendungsschicht 16 handhabt die Details der bestimmten
Anwendung. Es gibt viele allgemeine TCP/IP-Anwendungen, die nahezu
jede Implementierung bereitstellen, einschließlich Telnet für einen
Zugang aus der Ferne, das File Transfer Protocol (FTP), das Simple
Mail Transfer Protocol (SMTP) oder Electronic Mail bzw. elektronische
Post, das Simple Network Management Protocol (SNMP), das Hypertext
Transfer Protocol (HTTP) und viele andere.
-
Wie
erwähnt,
stellt TCP eine zuverlässige sequentielle Übertragung
von Daten zwischen zwei IP Hosts bereit. Die IP Hosts bauen eine
TCP-Verbindung auf, indem ein herkömmlicher TCP- Drei-Wege-Handshake
verwendet wird, und übertragen
dann Daten, indem ein Fenster-basiertes Protokoll eingesetzt wird,
wobei die erfolgreich empfangenen Daten bestätigt werden.
-
Um
zu verstehen, wo Optimierungen ausgeführt werden können, ist
es lehrreich, einen typischen TCP-Verbindungsaufbau zu betrachten. 18 zeigt ein
Beispiel eines herkömmlichen
PCT-Drei-Wege-Handshake
zwischen den IP Hosts 20 und 22. Zunächst sendet
der IP Host 20, der die Übertragung zu dem IP Host 22 initiieren
möchte,
ein Synchronisations- (SYN-) Signal an den IP Host 22.
Der IP Host 22 bestätigt
das SYN-Signal von dem IP Host 20 durch Senden einer SYN-Bestätigung bzw.
Acknowledgement (ACK). Der dritte Schritt des herkömmlichen TCP-Drei-Wege-Handshakes
besteht in der Herausgabe eines ACK-Signals von dem IP Host 20 zu
dem anderen IP Host 22. Jetzt ist der IP Host 22 bereit, Daten
von dem IP Host 20 zu empfangen (und umgekehrt). Nachdem
alle Daten ausgeliefert wurden, wird ein anderer Handshake (ähnlich zu
dem beschriebenen Handshake zur Auslösung der Verbindung) verwendet,
um die TCP-Verbindung zu schließen.
-
TCP
wurde entwickelt, um sehr flexibel zu sein und über ein weites Gebiet von Kommunikationsverbindungen
zu arbeiten, einschließlich
langsamer als auch schneller Verbindungen, Verbindungen mit hoher
Latenz und Verbindungen mit geringen und hohen Fehlerraten. Während jedoch
TCP (und andere Protokolle höherer
Schicht) mit vielen unterschiedlichen Verbindungsarten arbeiten,
ist die TCP-Leistung, insbesondere der Durchsatz, der über die TCP-Verbindung
möglich
ist, beeinträchtigt
durch die Eigenschaften der Verbindung, in der es eingesetzt wird.
Es gibt viele Verbindungsschichtdesign-Überlegungen, die berücksichtigt
werden sollten, wenn ein Verbindungsschichtservice entwickelt wird,
der dazu gedacht ist, Internetprotokolle zu unterstützen. Jedoch
können
nicht alle Eigenschaften durch Wahl des Verbindungsschichtdesigns
kompensiert werden. TCP wurde entwickelt, um sehr flexibel mit Bezug
auf die Verbindungen zu sein, die es durchquert. Eine solche Flexibilität wird zu
Lasten eines suboptimalen Betriebs in einer Anzahl von Umgebungen
gegenüber
dafür maßgeschneiderten
Protokollen erreicht. Die maßgeschneiderten
Protokolle, die üblicherweise
proprietär
sind, können
optimaler sein, ihnen fehlt es jedoch bezüglich Netzwerkumgebungen und
der Interoperabilität
an Flexibilität.
-
Eine
Alternative zu einem maßgeschneiderten
Protokoll ist die Verwendung von leistungsverbessernden Proxys (PEPs),
um eine allgemeine Klasse von Funktionen auszuführen, die als "TCP Spoofing" bezeichnet werden,
um die TCP-Leistung über
gestörte
Verbindungen zu verbessern (d.h. Verbindungen mit hoher Latenz oder
hoher Fehlerrate). TCP Spoofing enthält eine Zwischennetzwerkvorrichtung
(der leistungsverbessernde Proxy (PEP)), die abfängt und ändert durch das Hinzufügen und/oder Löschen von
TCP-Segmenten und damit das Verhalten der TCP-Verbindung ändert, um
damit einen Versuch zu unternehmen, die Leistung zu verbessern.
-
Herkömmliche
TCP Spoofing Implementierungen umfassen das lokale Bestätigen von
TCP-Datensegmenten, um dafür
zu sorgen, dass der TCP-Datensender zusätzliche Daten früher sendet, als
dies der Fall wäre,
wenn Spoofing nicht ausgeführt
würde,
so dass der Durchsatz der TCP-Verbindung verbessert wird. Allgemein
haben sich herkömmliche
TCP Spoofing Implementierungen auf ein einfaches Erhöhen des
Durchsatzes der TCP-Verbindungen fokussiert, entweder durch Verwendung
größerer Fenster über der
Verbindung oder durch Verwenden von Komprimierung, um die Datenmenge
zu reduzieren, die gesendet werden muss, oder beidem.
-
Viele
TCP PEP Implementierungen basieren auf einer TCP ACK Manipulation.
Dies kann ein TCP ACK Beabstanden umfassen, wobei ACKs, die zusammen
gebündelt
sind, getrennt und beabstandet werden als lokale TCP ACKs, lokale
TCP Rückübertragungen
und TCP ACK Filterung und Neuaufbau. Andere PEP-Mechanismen umfassen
das Tunneln, Komprimieren und das prioritätsbasierte Multiplexen.
-
Basierend
auf dem Vorhergesagten gibt es ein klares Bedürfnis nach verbesserten Lösungen zur Optimierung
der Netzwerkleistung, während
Flexibilität
erreicht wird. Es gibt ebenfalls ein Bedürfnis nach einer Verbesserung
der Netzwerkleistung ohne kostspielige Infrastrukturinvestitionen.
Es gibt ebenfalls ein Bedürfnis,
netzwerkleistungsverbessernde Mechanismen zu verwenden, die mit
existierenden Standards übereinstimmen,
um eine schnelle Entwicklung zu erleichtern. Es gibt ebenfalls ein
Bedürfnis,
das Empfängerdesign
zu vereinfachen. Deshalb ist eine Lösung zur Optimierung der Netzwerkleistung,
indem eine Proxyarchitektur verwendet wird, höchst wünschenswert.
-
WO
01/65805 diskutiert das Spoofing von Netzwerkverbindungen, um die
Leistung eines Netzwerks zu verbessern.
-
EP 0 903 905 A2 beschreibt
eine Netzwerk-Gateway-Vorrichtung, die die Netzwerkverbindungen
entsprechend den Protokolldaten in den empfangenen Datenpaketen
trennt.
-
Baras,
J.S. et al. beschreibt in "Fast
Asymmetric Internet over Wireless Satellite-Terrestial Networks", Center for Satellite
and Hybrid Communication Networks, University of Maryland, XP000799704, ISBN:
0-7803-4250-X Verbindungssteuerungsblöcke, die für jede Netzwerkverbindung verwendet
werden, die gespooft wird.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
vorliegende Erfindung spricht die zuvor ausgeführten Bedürfnisse an, indem ein leistungsverbessernder
Proxy (PEP) bereitgestellt wird, der eine Anzahl von netzwerkleistungsverbessernden Funktionen
ausführt.
-
Die
vorliegende Erfindung ist in den angehängten Ansprüchen definiert.
-
Eine
Netzwerkvorrichtung zum Ausführen von
Funktionen, um die Leistung eines Kommunikationsnetzwerks zu verbessern,
wird bereitgestellt. Die Netzwerkvorrichtung umfasst ein Spoofing-Modul, das konfiguriert
ist, um selektiv eine Vielzahl von Verbindungen zu spoofen, die
mit einer Vielzahl von Hosts verknüpft sind, basierend auf entsprechenden Spoofing-Kriterien,
und um eine lokale Bestätigung empfangener
Nachrichten über
die Verbindungen bereitzustellen. Zusätzlich umfasst die Netzwerkvorrichtung
ein Verbindungsmodul, das konfiguriert ist, um die Vielzahl von
Verbindungen über
eine gemeinsame Backbone-Verbindung
zu multiplexen, und ein Priorisierungsmodul, das ausgelegt ist,
um den Zugang zu der Backbone-Verbindung basierend auf den Prioritätskriterien
zu priorisieren. Ferner umfasst die Netzwerkvorrichtung ein Pfadauswahlmodul,
das ausge legt ist, um einen Pfad aus einer Vielzahl von Pfaden zu
bestimmen, um die empfangenen Nachrichten basierend auf den Pfadauswahlkriterien
zu übertragen.
Das Spoofing-Modul ist ausgelegt, um einen Verbindungssteuerungsblock
aus einer Vielzahl von Verbindungssteuerungsblöcken entsprechend einer gespooften
Verbindung zu belegen. Jede der Vielzahl von Verbindungssteuerungblöcken speichert
Information betreffend die Vielzahl von Verbindungen. Die vorherige
Anordnung liefert vorteilhafterweise eine verbesserte Systemleistung.
-
Ein
Verfahren zum Ausführen
von Funktionen, um die Leistung eines Kommunikationsnetzwerks zu
verbessern, wird bereitgestellt. Das Verfahren umfasst das selektive
Spoofen einer Vielzahl von Verbindungen, die mit einer Vielzahl
von Hosts basierend auf entsprechenden Spoofing-Kriterien verknüpft sind,
und umfasst das Bereitstellen einer lokalen Bestätigung empfangener Nachrichten über die Verbindungen.
Der Schritt des selektiven Spoofens umfasst das Belegen eines Verbindungssteuerungsblocks
aus einer Vielzahl von Verbindungssteuerungsblöcken entsprechend einer gespooften
Verbindung. Jeder der Vielzahl von Verbindungssteuerungsblöcken speichert
Information, die die Vielzahl von Verbindungen betrifft. Das Verfahren
umfasst ebenfalls das Multiplexen der Vielzahl von Verbindungen über eine
gemeinsame Backbone-Verbindung, den priorisierten Zugang zu der
Backbone-Verbindung basierend auf den Prioritätskriterien und Bestimmen eines
Pfads aus einer Vielzahl von Pfaden, um die empfangenen Nachrichten
basierend auf den Pfadauswahlkriterien zu übertragen. Die vorherige Anordnung
verbessert vorteilhafterweise den Systemdurchsatz und die Systemflexibilität eines
Kommunikationssystems.
-
Eine
Netzwerkvorrichtung zur Ausführung von
Funktionen, um die Leistung eines Kommunikationsnetzwerks zu verbessern,
ist offenbart. Die Netzwerkvorrichtung umfasst Mittel zum selektiven
Spoofen einer Vielzahl von Verbindungen, die mit einer Vielzahl
von Hosts verknüpft
sind, basierend auf entsprechenden Spoofing-Kriterien. Das Spoofing-Mittel umfasst
ein Mittel zum Belegen eines Verbindungssteuerungsblocks aus einer
Vielzahl von Verbindungssteuerungsblöcken entsprechend einer gespooften
Verbindung. Jeder der Vielzahl von Verbindungssteuerungsblöcken speichert
Information, die die Vielzahl von Verbindungen betrifft. Die Netzwerkvorrichtung
umfasst ebenfalls ein Mittel zum Bereitstellen einer lokalen Bestätigung bzw.
Acknowledgement der empfangenen Nachrichten über die Verbindungen, ein Mittel
zum Multiplexen der Vielzahl von Verbindungen über eine gemeinsame Backbone-Verbindung
und Mittel zum Priorisieren des Zugangs zu der Backbone-Verbindung
auf der Basis der Prioritätskriterien.
Ferner umfasst die Netzwerkvorrichtung ein Mittel zum Bestimmen
eines Pfads aus einer Vielzahl von Pfaden, um die empfangenen Nachrichten basierend
auf den Pfadauswahlkriterien zu übertragen.
Die vorherige Anordnung liefert vorteilhafterweise eine verbesserte
Systemleistung.
-
Ein
computerlesbares Medium, das ein oder mehrere Sequenzen eines oder
mehrerer Befehle zur Ausführung
von Funktionen zur Verbesserung der Leistung eines Kommunikationsnetzwerks
trägt, ist
offenbart. Die eine oder mehreren Sequenzen einer oder mehrerer
Instruktionen bzw. Befehle umfassen Befehle, die, wenn sie von einem
oder mehreren Prozessoren ausgeführt
werden, den einen oder die mehreren Prozessoren veranlassen, den
Schritt des selektiven Spoofens einer Vielzahl von Verbindungen auszuführen, die
mit einer Vielzahl von Hosts verknüpft sind, basie rend auf entsprechenden
Spoofing-Kriterien. Der Schritt des selektiven Spoofens umfasst
das Belegen eines Verbindungssteuerungsblocks aus einer Vielzahl
von Verbindungssteuerungsblöcken
entsprechend einer gespooften Verbindung. Jeder der Vielzahl von
Verbindungssteuerungsblöcken
speichert Information, die die Vielzahl von Verbindungen betrifft.
Andere Schritte umfassen das Bereitstellen einer lokalen Bestätigung empfangener
Nachrichten über
die Verbindungen, ein Multiplexen der Vielzahl von Verbindungen über eine
gemeinsame Backbone-Verbindung, den priorisierten Zugang zu der
Backbone-Verbindung auf der Basis von Prioritätskriterien, ein Bestimmen
eines Pfads aus einer Vielzahl von Pfaden, um die empfangenen Nachrichten
auf der Basis der Pfadauswahlkriterien zu übertragen. Die vorherige Anordnung
minimiert in vorteilhafter Weise die Netzwerk-Latenz.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Eine
umfassendere Würdigung
der Erfindung und der vielen zugehörigen Vorteile ergeben sich
leicht durch Bezugnahme auf die nachfolgende detaillierte Beschreibung
unter Berücksichtigung
der begleitenden Zeichnungen, wobei:
-
1 ein
Diagramm eines Kommunikationssystems ist, in dem der leistungsverbessernde
Proxy (PEP) der vorliegenden Erfindung implementiert ist;
-
2 ein
Diagramm einer PEP Endpunkt-Plattformumgebung entsprechend einer
Ausführungsform
der vorliegenden Erfindung ist;
-
3 ein
Diagramm eines TCP Spoofing Kernel (TSK) ist, der in der Umgebung
von 2 verwendet wird;
-
4A und 4B Flussdiagramme
des Verbindungsaufbaus mit Drei-Wege-Handshake-Spoofing bzw. ohne
Drei-Wege-Handshake-Spoofing
zeigen;
-
5 ein
Diagramm eines PEP-Paketstroms zwischen zwei PEP-Endpunkten entsprechend einer Ausführungsform
der vorliegenden Erfindung ist;
-
6 ein
Diagramm eines IP (Internet Protocol) Paketstroms durch einen PEP-Endpunkt
entsprechend einer Ausführungsform
der vorliegenden Erfindung ist;
-
7 ein
Diagramm von PEP-Endpunktprofilen ist, die in der Plattform von 2 eingesetzt werden;
-
8 ein
Diagramm der Schnittstellen eines PEP-Endpunkts ist, der als IP-Gateway
implementiert ist, entsprechend einer Ausführungsform der vorliegenden
Erfindung;
-
9 ein
Diagramm der Schnittstellen eines PEP-Endpunkts ist, der als Multimedia
Relay implementiert ist, entsprechend einer Ausführungsform der vorliegenden
Erfindung;
-
10 ein
Diagramm der Schnittstellen eines PEP-Endpunkts ist, der als Multimedia
VSAT (Very Small Aperture Terminal) implementiert ist, entsprechend
einer Ausführungsform
der vorliegenden Erfindung;
-
11 ein
Diagramm der Schnittstellen eines PEP-Endpunkts ist, der in einer
Bodenstation implementiert ist, entsprechend einer Ausführungsform der
vorliegenden Erfindung;
-
12 ein
Diagramm eines TSK-Steuerungsblocks- (TCB-) Zugriffs über eine
TCB-Abbildungs- bzw. Mappingtabelle ist, entsprechend einer Ausführungsform
der vorliegenden Erfindung;
-
13 ein
Diagramm eines TCP-Verbindungssteuerungsblocks- (CCB-) Zugangs über eine CCB Hash-Funktion
ist, entsprechend einer Ausführungsform
der vorliegenden Erfindung;
-
14 ein
Diagramm einer CCB Mapping-Tabelle entsprechend einer Ausführungsform der
vorliegenden Erfindung ist;
-
15 ein
Diagramm der Abbildung zwischen CCBs und TCBs entsprechend einer
Ausführungsform
der vorliegenden Erfindung ist;
-
16 ein
Diagramm eines Computersystems ist, das die PEP-Funktionen ausführen kann, entsprechend einer
Ausführungsform
der vorliegenden Erfindung;
-
17 ein
Diagramm der Protokollschichten des TCP/IP Protocol ist; und
-
18 ein
Diagramm eines herkömmlichen TCP
Drei-Wege-Handshakes
zwischen IP Hosts ist.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
In
der nachfolgenden Beschreibung sind zum Zwecke der Erläuterung
spezifische Details ausgeführt,
um ein gründliches
Verständnis
der Erfindung zu ermöglichen.
Es ist jedoch klar, dass die Erfindung ohne diese spezifischen Details
ausgeführt werden kann.
Beispielsweise sind gut bekannte Strukturen und Vorrichtungen in
Blockdiagrammform dargestellt, um zu verhindern, dass die Erfindung
unnötig
verfälscht
wird.
-
Obgleich
die Erfindung mit Bezug auf das Internet und das TCP/IP Protocol
diskutiert wird, kann die vorliegende Erfindung auch bei anderen
paketvermittelten Netzwerken und äquivalenten Protokollen angewendet
werden.
-
1 zeigt
ein beispielhaftes Netzwerk 100, in dem der leistungsverbessernde
Proxy (PEP) der vorliegenden Erfindung verwendet werden kann. Das Netzwerk 100 in 1 umfasst
einen oder mehrere Hosts 110, die mit einem Netzwerk-Gateway 120 über TCP-Verbindungen
verbunden sind. Das Netzwerk-Gateway 120 ist mit einem
anderen Netzwerk-Gateway 140 über eine Backbone-Verbindung auf einer
Backbone-Verbindung 130 verbunden. Wie in 1 zu
sehen ist, ist die Backbone-Verbindung 130 in einer beispielhaften
Ausführungsform
als eine Satellitenverbindung gezeigt, die über einen Satelliten 101 aufgebaut
ist; für
einen Durchschnittsfachmann ist jedoch ersichtlich, dass andere
Netzwerkverbindungen implementiert werden können. Beispielsweise können diese
Netzwerkverbindungen über
ein drahtloses Kommunikationssystem im Allgemeinen (beispielsweise
Funknetzwerke, Mobilfunknetzwerke etc.) oder ein terrestrisches
Kommunikationssystem aufgebaut werden. Das Netzwerk-Gateway ist
ferner mit einer zweiten Gruppe von Hosts 150 verbunden,
ebenfalls über
TCP-Verbindungen. In der in 1 dargestellten
Anordnung erleichtern die Netzwerk-Gateways 120, 140 eine
Kommunikation zwischen den Gruppen der Hosts 110, 150.
-
Die
Netzwerk-Gateways 120, 140 erleichtern eine Kommunikation
zwischen zwei Gruppen von Hosts 110, 150 durch
Ausführen
einer Anzahl von leistungsverbessernden Funktionen. Diese Netzwerk-Gateways 120, 140 können ein
selektives TCP Spoofing ausführen,
das eine flexible Konfiguration der bestimmten TCP-Verbindungen
ermöglicht,
die gespooft werden sollen. Zusätzlich
verwenden Gateways 120, 140 einen TCP-Drei-Wege-Handshake, bei
dem die TCP-Verbindungen an ihrem Ende der Backbone-Verbindung 130 abgeschlossen
sind. Lokale Datenbestätigungen
werden von den Netzwerk-Gateways 120, 140 verwendet,
um damit den TCP-Fenstern zu ermöglichen,
die lokalen Geschwindigkeiten zu erhöhen.
-
Das
Netzwerk-Gateway 120, 140 multiplext ferner mehrere
TCP-Verbindungen über eine
einzelne Backbone-Verbindung; diese Fähigkeit reduziert die Menge
von Acknowledgement- bzw. Bestätigungsverkehr,
der mit den Daten von den mehreren TCP-Verbindungen verknüpft ist, da ein einzelnes Backbone-Verbindungs-Acknowledgement
eingesetzt werden kann. Die Multiplexingfunktion liefert auch eine
Unterstützung
für TCP-Verbindungen
mit hohem Durchsatz, wobei das Backbone-Verbindungsprotokoll für die jeweilige
Backbone-Verbindung optimiert ist, die verwendet wird. Die Netzwerk-Gateways 120, 140 unterstützen ebenfalls
eine Datenkomprimierung über
die Backbone-Verbindung 130, um die Menge an zu sendendem
Verkehr zu reduzieren, und um ferner die Fähigkeiten der Backbone-Verbindung
zu beeinflussen. Ferner verwenden die Netzwerk-Gateways 120, 140 eine
Datenverschlüsselung
bei der Datenübertragung über die Backbone-Verbindung 130,
um den Datenschutz zu bewahren, und stellt einen priorisierten Zugang
zu der Backbone-Verbindungskapazit auf einer TCP-Verbindungsbasis
bereit. Jedes der Netzwerk-Gateways 120, 140 kann
einen bestimmten Pfad für
die Daten wählen,
der mit einer Datenflussverbindung verknüpft ist. Die zuvor genannten
Fähigkeiten
der Netzwerk-Gateways 120, 140 werden vollständiger nachfolgend
beschrieben.
-
2 zeigt
einen leistungsverbessernden Proxy (PEP) 200, der in einem
Netzwerk-Gateway 120, 140 entsprechend einer Ausführungsform
der vorliegenden Erfindung implementiert ist. Bei dieser Ausführungsform
hat der PEP 200 eine Plattformumgebung 210, die
die Hardware und das Software-Betriebssystem umfasst. Der PEP 200 umfasst
ebenfalls Schnittstellen zu einem lokalen Netzwerk (LAN) 220 und
Schnittstellen 230 zu einem Wide Area Netzwerk (WAN). Bei
dem Beispiel in 1 kann das Netzwerk-Gateway 120 die
TCP-Verbindungen mit den IP Hosts 110 über eine lokale LAN-Schnittstelle 220 errichten
und kann eine Backbone-Verbindung mit
dem Netzwerk-Gateway 140 über eine WAN-Schnittstelle 230 errichten.
Die PEP-Plattformumgebung 210 kann ebenfalls allgemeine
Funktionsmodule umfassen: ein Routing-Modul 240, ein Puffermanagement-Modul 250,
ein Ereignismanagement-Modul 260 und
ein Parametermanagement-Modul 270. Wie in 2 dargestellt,
umfasst das Netzwerk-Gateway auch einen TCP Spoofing Kernel bzw.
Kern (TSK) 280, einen Backbone Protocol Kernel (BPK) 282,
einen Priorisierungs-Kernel (PK) 284 und einen Pfadauswahl-Kernel
(PSK) 286. Diese vier Kernels bzw. Kerne machen im Wesentlichen
die Funktionalität
des leistungsverbessernden Proxys 200 aus.
-
Die
Plattformumgebung 210 führt
eine Anzahl von Funktionen aus. Eine solche Funktion besteht darin,
die verschiedenen PEP-Kerne 280, 282, 284, 286 gegenüber der
Implementierung bestimmter Einschränkungen abzuschirmen. D.h.
die Plattformumgebung 210 führt Funktionen aus, die verschiedene
PEP-Kerne 280, 282, 284, 286 nicht
direkt ausführen
können,
da die Implementierung der Funktion plattformspezifisch ist. Diese
Anordnung hat den vorteilhaften Effekt, dass plattformspezifische
Details gegenüber
den PEP-Kernen 280, 282, 284, 286 versteckt
werden, so dass die PEP-Kerne portierbarer gemacht werden. Ein Beispiel
einer plattformspezifischen Funktion ist die Belegung bzw. Zuweisung
eines Puffers. Bei manchen Plattformen werden Puffer erzeugt, wenn
sie benötigt
werden, während
in anderen Plattformen Puffer beim Start erzeugt werden und in verknüpften Listen
für eine
spätere
Benutzung organisiert sind. Es ist anzumerken, dass plattformspezifische
Funktionen nicht auf Funktionen beschränkt sind, die allen Kernen 280, 282, 284, 286 gemein sind.
Eine Funktion, die für
einen bestimmten Kern spezifisch ist, beispielsweise die Zuweisung
eines Steuerungsblocks für
TCP Spoofing, kann ebenfalls in der Plattformumgebung implementiert
sein, um plattformspezifische Details vor dem Kern zu verstecken.
-
Zusätzlich kann
die Plattformumgebung 210 den Aufgaben- bzw. Task-Kontext
bereitstellen, in dem die PEP-Kerne 280, 282, 284, 286 laufen.
Bei einer beispielhaften Ausführungsform
können
alle PEP-Kerne 280, 282, 284, 286 aus
Effizienzgründen in
dem gleichen Task-Kontext ablaufen. Dies ist jedoch nicht unbedingt
notwendig.
-
Ferner
stellt die Plattformumgebung 210 bei einer beispielhaften
Ausführungsform
eine Schnittstelle zwischen der PEP-Funktionalität (in den Kernen 280, 282, 284, 286 verkörpert) und
der anderen Funktionalität
des Netzwerk-Gateways 120, 140 bereit. Die Plattformumgebung 210 kann
die Schnittstelle zwischen der PEP-Funktionalität und der Routing-Funktion 240 be reitstellen,
wie in 2 gezeigt. Es ist anzumerken, dass die plattformspezifischen Funktionen,
die in 2 gezeigt sind, Beispiele sind und nicht als abschließende Liste
betrachtet werden dürfen.
Es ist ferner anzumerken, dass die PEP-Kerne, die in 2 als einander
berührend
gezeigt sind (280, 282, 284, 286),
eine direkte Prozessschnittstelle zueinander haben können. Ferner
können
die Kerne 280, 282, 284, 286 direkte
Schnittstellen umfassen, um die Leistung zu verbessern, im Gegensatz zum
Routen durch die Plattformumgebung 210 (in 2 gezeigt).
-
Zusätzlich zu
den PEP-Kernen 280, 282, 284 und 286 kann
die PEP-Endpunktplattform 210 einen Datenkomprimierungs-Kernel
(CK) 290 und einen Verschlüsselungs-Kernel bzw. -Kern
(EK) 292 verwenden. Diese Kerne 280, 282, 284, 286, 290 und 292,
wie zuvor beschrieben, erleichtern eine Kommunikation zwischen den
zwei Gruppen von Hosts 110, 150 durch Ausführen einer
Vielzahl von leistungsverbessernden Funktionen, entweder einzeln
oder in Kombination. Diese leistungsverbessernden Funktionen umfassen
ein selektives TCP Spoofing, ein Drei-Wege-Handshake Spoofing, ein
lokales Datenacknowledgement, ein Multiplexen der TCP-Verbindung auf die
Backbone-Verbindung, eine Datenkomprimierung/-verschlüsselung,
Priorisierung und Pfadauswahl.
-
Ein
selektives TCP Spoofen wird von dem TSK 280 ausgeführt und
umfasst einen Satz von benutzerkonfigurierbaren Regeln, die verwendet
werden, um zu bestimmen, welche TCP-Verbindungen gespooft werden
sollten. Ein selektives TCP-Spoofen verbessert die Leistung, indem
TCP Spoofing-bezogene Ressourcen, wie beispielsweise Pufferplatz, Steuerungsblöcke etc.,
nicht für
TCP-Verbindungen gekoppelt
werden, für
welche TCP-Verbindungen der Benutzer festgelegt hat, dass ein Spoofing
nicht vorteilhaft ist oder nicht erforderlich ist, und indem die Verwendung
von angepassten Parametern für TCP-Verbindungen
unterstützt
werden, die gespooft werden.
-
Insbesondere
unterscheidet der TSK 280 unter den vielen TCP-Verbindungen basierend
auf den Anwendungen, die sie benutzen. Das heißt der TSK 280 unterscheidet
unter diesen TCP-Verbindungen, um
festzulegen, welche Verbindung gespooft werden sollte, sowie die
Art und Weise, in der die Verbindung gespooft wird; beispielsweise
ob der Drei-Wege-Handshake gespooft werden soll, die bestimmten Timeout-Parameter
für die
gespooften Verbindungen, etc. TCP Spoofing wird dann nur für jene TCP-Verbindungen ausgeführt, die
mit der Anwendung verknüpft
sind, für
die ein hoher Durchsatz oder reduzierte Verbindungs-Startlatenz
(oder beides) erforderlich sind. Erhält der TSK 280 die
TCP Spoofing-Ressourcen nur für
diese TCP-Verbindungen, für
die hoher Durchsatz oder reduzierte Verbindungs-Startlatenz (oder
beides) erforderlich ist. Ferner erhöht der TSK 280 die
Gesamtzahl der TCP-Verbindungen, die aktiv sein können, bevor
die TCP-Spoofing-Ressourcen ausgehen, da jede aktive TCP-Verbindung,
die keinen hohen Durchsatz benötigt,
nicht zugewiesene bzw. belegte Ressourcen sind.
-
Ein
Kriterium zur Identifizierung von TCP-Anwendungsverbindungen, für die TCP
Spoofing ausgeführt
und nicht ausgeführt
werden sollte, ist das TCP-Port-Nummern Feld, das in den zu sendenden TCP-Paketen
enthalten ist. Allgemein werden die eindeutigen Portnummern jedem
Anwendungstyp zugeordnet. Welche TCP-Portnummern gespooft und nicht
gespooft werden sollten, kann in dem TSK 280 gespeichert
werden. Der TSK 280 ist eben falls neu konfigurierbar, um
es einem Benutzer oder einem Operator zu erlauben, die TCP-Portnummern neu
zu konfigurieren, die gespooft und nicht gespooft werden sollten.
Der TSK 280 erlaubt ebenfalls einem Benutzer oder Operator,
zu steuern, welche TCP-Verbindungen gespooft werden sollten, basierend
auf anderen Kriterien. Allgemein kann eine Entscheidung, ob eine
TCP-Verbindung gespooft werden soll, auf jeglichem Feld innerhalb
eines TCP-Pakets basieren. Der TSK 280 erlaubt es einem
Benutzer, zu spezifizieren, welche Felder zu prüfen sind und welche Werte in
diesen Feldern TCP-Verbindungen identifizieren, die gespooft oder
nicht gespooft werden sollen. Ein anderes Beispiel einer möglichen Verwendung
dieser Fähigkeit
besteht für
den Benutzer oder Operator darin, die IP-Adresse des TCP-Pakets auszuwählen, um
zu steuern, für
welche Benutzer das TCP-Spoofing
ausgeführt
wird. Der TSK 280 erlaubt es ebenfalls einem Benutzer,
eine Vielzahl von Feldern zur gleichen Zeit zu betrachten. Daraus ergibt
sich, dass es der TSK 280 einem Benutzer oder Operator
erlaubt, mehrere Kriterien zur Auswahl von TCP-Verbindungen, die
zu spoofen sind, zu verwenden. Beispielsweise kann der Systemoperator durch
Auswahl sowohl der IP-Adresse
als auch der TCP-Port-Nummer Felder ein TCP-Spoofing nur für spezifische
Anwendungen von spezifischen Benutzern ermöglichen.
-
Diese
benutzerkonfigurierbaren Regeln können fünf beispielhafte Kriterien
umfassen, die von dem Benutzer oder Operator beim Erzeugen einer selektiven
TCP Spoofing-Regel spezifiziert werden können: Ziel IP-Adresse; Quell-IP-Adresse; TCP-Portnummern
(die sowohl auf die TCP-Ziel- und Quellportnummern anwendbar sind);
TCP-Optionen; und IP-differenzierte Services (DS) Feld.
-
Allerdings
können,
wie zuvor ausgeführt,
andere Felder innerhalb des TCP-Pakets benutzt werden.
-
Wie
zuvor diskutiert, können
zusätzlich
zur Unterstützung
der selektiven TCP Spoofing-Regeln für jedes dieser Kriterien UND- und ODER-Kombinationsoperatoren
verwendet werden, um die Kriterien miteinander zu verknüpfen. Beispielsweise
kann eine Regel, indem der UND-Kombinationsoperator verwendet wird,
definiert werden, um ein TCP Spoofing für FTP-Daten zu sperren, die
von einem speziellen Host empfangen werden. Ebenfalls kann die Reihenfolge,
in der die Regeln spezifiziert sind, wesentlich sein. Es ist für eine Verbindung
möglich,
dass sie die Kriterien mehrerer Regeln erfüllt. Deshalb kann der TSK 280 Regeln
in der Reihenfolge, die vom Operator spezifiziert wird, angewendet
werden, indem die Aktion der ersten zutreffenden Regel genommen wird.
Eine Default-Regel kann ebenfalls gesetzt werden, die die Aktion
definiert, die für
TCP-Verbindungen genommen werden soll, die auf keine der definierten
Regeln passt. Der Satz von Regeln, die von dem Operator ausgewählt wird,
kann in einem selektiven TCP Spoofing Auswahlprofil definiert werden.
-
Als
Beispiel sei angenommen, dass ausreichend Pufferplatz zugewiesen
wurde, um fünf TCP-Verbindungen
zu spoofen; falls vier Anwendungen mit geringer Geschwindigkeit
(d.h. Anwendungen, die von ihrer Natur aus keine hohen Geschwindigkeiten
erfordern) zusammen mit einer Hochgeschwindigkeitsanwendung Verbindungen
aufbauen, hat die Hochgeschwindigkeitsverbindung Zugriff auf nur
1/5 des verfügbaren
Spoofing-Pufferplatzes. Falls fünf
Verbindungen mit niedriger Geschwindigkeit aufgebaut werden, vor
der Hochgeschwindigkeitsverbindung, kann die Hochgeschwin digkeitsverbindung überhaupt
nicht gespooft werden. Indem der selektive Spoofing-Mechanismus
des TSK 280 verwendet wird, belegen die Verbindungen mit
niedriger Geschwindigkeit keinen Spoofing-Pufferplatz. Deshalb hat
die Hochgeschwindigkeitsverbindung immer Zugriff auf den gesamten
Pufferplatz, was dessen Leistung verbessert im Vergleich zu einer
Implementierung ohne das selektive PCT-Spoofing-Merkmal des TSK 280.
-
Der
TSK 280 erleichtert auch ein Spoofing des herkömmlichen
Drei-Wege-Handshakes. Ein Drei-Wege-Handshake-Spoofing umfasst ein
lokales Antworten auf eine Verbindungsanfrage, um eine TCP-Verbindung parallel
mit dem Weiterleiten der Verbindungsanforderungen über die
Backbone-Verbindung 130 (1) aufzubauen.
Dies erlaubt es dem originären
IP Host (beispielsweise 110), den Punkt zu erreichen, an
dem er in der Lage ist, die Daten zu senden, die er mit lokalen
Geschwindigkeiten senden muss, d.h. Geschwindigkeiten, die unabhängig von
der Latenz der Backbone-Verbindung 130 sind.
Ein Drei-Wege-Handshake-Spoofing ermöglicht es den Daten, die der
IP Host senden muss, dass sie zu dem Ziel-IP Host 150 gesendet
werden, ohne auf einen End-zu-End-Aufbau
der TCP-Verbindung zu warten. Für
Backbone-Verbindungen 130 mit
hoher Latenz reduziert dies die Zeit wesentlich, die benötigt wird,
um die TCP-Verbindung aufzubauen und insbesondere die Gesamtzeit,
die benötigt
wird, um eine Antwort (von einem IP Host 150) auf die Daten
zu erhalten, die der IP Host 110 sendet.
-
Ein
spezifisches Beispiel, bei dem diese Technik nützlich ist, betrifft eine Internet
Web Page Zugangsanwendung. Mit dem Drei-Wege-Handshake-Spoofing kann eine Anforderung
eines IP Hosts, eine Web Page zu erhalten, auf dem Weg zu einem Web
Server sein, ohne auf den End-zu-End-Aufbau der TCP-Verbindung warten
zu müssen,
wodurch die Zeit reduziert wird, die benötigt wird, um die Web Page
herunterzuladen.
-
Mit
einer lokalen Datenbestätigung
bzw. Local Data Acknowledgement bestätigt der TSK 280 in dem
Netzwerk-Gateway 120 (beispielsweise) lokale Datensegmente,
die von dem IP Host 110 empfangen werden. Dies ermöglicht es,
dass der sendende IP Host 110 zusätzliche Daten sofort sendet.
Insbesondere benutzt das TCP empfangene Bestätigungen als Signale zur Erhöhung der
aktuellen TCP-Fenstergröße. Im Ergebnis
ermöglicht
das lokale Senden von Bestätigungen,
dass der sendende IP Host 110 sein TCP-Fenster mit einer viel schnelleren Geschwindigkeit
erhöht
als dies durch End-zu-End-TCP-Bestätigungen unterstützt würde. Der
TSK 280 (der Spoofer) nimmt die Verantwortung für eine zuverlässige Auslieferung
der Daten an, die er bestätigt
hat.
-
In
dem BPK 282 werden mehrere TCP-Verbindungen auf eine einzelne
Backbone-Verbindung gemultiplext und von dieser getragen. Dies verbessert
die Systemleistung, indem die Daten für mehrere TCP-Verbindungen
durch ein einzelnes Backbone-Verbindungs-Acknowledgement (ACK) bestätigt werden
können,
was die Anzahl des Bestätigungsverkehrs,
der zur Aufrechterhaltung eines hohen Durchsatzes über die
Backbone-Verbindung 130 erforderlich ist, wesentlich reduziert.
Zusätzlich
wählt der
BPK 282 ein Backbone-Verbindungsprotokoll aus, das optimiert
wird, um einen hohen Durchsatz für
die jeweilige Verbindung bereitzustellen. Unterschiedliche Backbone-Verbindungsprotokolle
können
von dem BPK 282 bei unterschiedlichen Backbone-Verbindungen
eingesetzt werden, ohne die grundlegende TCP Spoofing-Implementierung
zu verändern.
Das Backbone-Verbindungsprotokoll, das von dem BPK 282 ausgewählt wurde,
liefert eine passende Unterstützung
für eine
zuverlässige
Hochgeschwindigkeitsauslieferung von Daten über die Backbone-Verbindung 130,
wobei die Details der Beeinträchtigung
(beispielsweise hohe Latenz) der Verbindung gegenüber der
TCP Spoofing-Implementierung versteckt werden.
-
Das
Multiplexen durch den BPK 282 ermöglicht die Verwendung eines
Backbone-Verbindungsprotokolls, das individuell zur Benutzung mit
der bestimmten Verbindung maßgeschneidert
ist und eine Technik zur Anhebung der Leistung des Backbone-Verbindungsprotokolls
ist, mit einer viel geringeren Abhängigkeit von der einzelnen
Leistung der TCP-Verbindungen, die gespooft werden, als bei herkömmlichen
Verfahren. Ferner macht die Fähigkeit, das
Backbone-Protokoll für
unterschiedliche Backbone-Verbindungen maßzuschneidern, die Anwendung
der Erfindung bei unterschiedlichen Systemen möglich.
-
Der
PEP 200 kann optional einen Datenkomprimierungskern 290 zum
Komprimieren der TCP-Daten und einen Verschlüsselungskern 292 zum
Verschlüsseln
der TCP-Daten aufweisen. Die Datenkomprimierung erhöht die Datenmenge,
die über
die Backbone-Verbindung getragen werden kann. Unterschiedliche Kompressionsalgorithmen können von
dem Datenkomprimierungskern 290 unterstützt werden, und mehr als einer
der Kompressionstypen kann zur gleichen Zeit unterstützt werden. Der
Datenkomprimierungskern 290 kann optional eine Komprimierung
auf einer TCP-Verbindungsbasis anwenden, bevor die TCP-Daten mehrerer TCP-Verbindungen
auf die Backbone-Verbindung gemultiplext
werden, oder auf einer Backbone-Verbindungsbasis,
nachdem die TCP-Daten der mehreren TCP-Verbindungen auf die Backbone-Verbindung
gemultiplext wurden. Welche Option verwendet wird, wird dynamisch
basierend auf den benutzerkonfigurierten Regeln und den spezifischen
Kompressionsalgorithmen festgelegt, die verwendet werden. Beispielhafte
Datenkomprimierungsalgorithmen sind in US-Patent Nr. 5, 973,630;
5,955,976 offenbart. Der Verschlüsselungskern 292 verschlüsselt die TCP-Daten
für eine
sichere Übertragung über die Backbone-Verbindung 130.
Die Verschlüsselung kann
mit jeder herkömmlichen
Technik ausgeführt werden.
Es versteht sich, dass die entsprechenden Spoofer (in dem zuvor
ausgeführten
Beispiel das Netzwerk-Gateway 140) geeignete Kerne zur
Dekomprimierung und Entschlüsselung
aufweisen, wobei beide mit jeder herkömmlichen Technik ausgeführt werden
können.
-
Der
PK 284 liefert einen priorisierten Zugang zu der Backbone-Verbindungskapazität. Beispielsweise
kann die Backbone-Verbindung in N (N > 1) unterschiedliche Teilverbindungen
aufgetrennt werden, wobei jede einen unterschiedlichen Prioritätspegel bzw.
-wert besitzt. Bei einer beispielhaften Ausführungsform können vier
Prioritätswerte
unterstützt werden.
Der PK 284 benutzt benutzerdefinierte Regeln, um unterschiedliche
Prioritäten
zuzuweisen, und damit unterschiedliche Teilverbindungen der Backbone-Verbindung,
auf unterschiedliche TCP-Verbindungen. Es versteht sich, dass der
PK 284 auch nicht TCP-Verkehr priorisieren kann (beispielsweise
UDP (User Datagram Protocol) Verkehr), bevor der Verkehr über die
Backbone-Verbindung 130 gesendet wird.
-
Der
PK 282 benutzt ebenfalls benutzerdefinierte Regeln, um
zu steuern, wie viel der Kapazität der
Backbone-Verbindung 130 für jeden Prioritätspegel
verfügbar
ist. Beispielhafte Kriterien, die verwendet werden können, um
die Priorität
zu bestimmen, umfassen Folgendes: Ziel-IP-Adresse; Quell-IP-Adresse;
IP Next Protocol; TCP Portnummern (die sowohl für TCP-Ziel- als auch Quellportnummern
angewendet werden können);
UDP Portnummern (die sowohl für
die UDP Ziel- als Quellportnummern angewendet werden können); und
das IP Differentiated Services (DS) Feld. Der Datentyp in den TCP-Datenpaketen
kann ebenfalls als Kriterium verwendet werden. Beispielsweise könnte Videodaten
die höchste
Priorität
gegeben werden. Übertragungskritische
Daten könnten
ebenfalls mit einer hohen Priorität versehen werden. Wie beim
selektiven TCP Spoofing kann jedes Feld in dem IP-Paket von dem PK 284 verwendet
werden, um die Priorität
zu bestimmen. Es ist jedoch anzumerken, dass bei bestimmten Szenarien
die Folge der Verwendung eines solchen Feldes darin bestehen kann,
dass unterschiedliche IP-Pakete des gleichen Stroms (beispielsweise
TCP-Verbindung) unterschiedliche Prioritäten zugewiesen bekommen; diese
Szenarien sollten vermieden werden.
-
Wie
zuvor erwähnt,
können
zusätzlich
zur Unterstützung
selektiver Priorisierungsregeln für jedes dieser Kriterien UND-
und ODER-Kombinationsoperatoren verwendet werden, um die Kriterien
miteinander zu verbinden. Beispielsweise kann die Verwendung des
UND-Kombinationsoperators eine Regel definieren, um eine Priorität für SNMP-Daten
zuzuweisen, die von einem bestimmten Host empfangen werden. Ebenfalls
kann die Reihenfolge, in der die Regeln spezifiziert werden, wesentlich
sein. Es ist für
eine Verbindung möglich,
Kriterien mehrerer Regeln zu erfüllen.
Deshalb kann der PK 284 Regeln in der Reihenfolge anwenden,
die von dem Operator spezifiziert sind, wobei die Aktion der ersten
Regel genommen wird, die passt. Eine Default-Regel kann ebenfalls
eingestellt werden, die die Aktion definiert, die für IP-Pakete zu verwenden
ist, die keine der definierten Regeln er füllen. Der Satz von Regeln,
der von dem Operator ausgewählt
wird, kann in einem Priorisierungsprofil definiert werden.
-
Im
Hinblick auf die Pfadauswahl-Funktionalität ist der PSK 286 verantwortlich
für die
Bestimmung, welcher Pfad ein IP-Paket nehmen soll, um sein Ziel
zu erreichen. Der von dem PSK 286 ausgewählte Pfad
kann festgelegt werden, indem die Pfadauswahlregeln angewendet werden.
Der PSK 286 bestimmt ebenfalls, welche IP-Pakete weitergeleitet werden
sollen, indem ein alternativer Pfad verwendet wird, und welche IP-Pakete
fallengelassen werden sollen, wenn einer oder mehrere Hauptpfade
ausfallen. Pfadausfallparameter können ebenfalls konfiguriert
werden, indem Profile verwendet werden. Die Pfadauswahlregeln können gestaltet
werden, um Flexibilität
mit Bezug auf die Zuweisung von Pfaden bereitzustellen, während sichergestellt
wird, dass alle Pakete, die den gleichen Verkehrsstrom betreffen (beispielsweise
die gleiche TCP-Verbindung), den gleichen Pfad nehmen (obgleich
es möglich
ist, Segmente der gleichen TCP-Verbindung über unterschiedliche
Pfade zu senden, wobei dieses Segment-"Auftrennen" negative Nebenwirkungen haben kann).
Beispielhafte Kriterien, die verwendet werden können, um einen Pfad auszuwählen, umfassen
die folgenden: Priorität
des IP-Pakets, wie
von der PK 284 eingestellt (sollte das üblichste Kriterium sein); Ziel-IP-Adresse;
Quell-IP-Adresse; IP Next Protocol; TCP-Portnummern (was sowohl
auf die TCP-Ziel- als auch Quell-Portnummern angewendet werden kann); UDP-Portnummern
(was sowohl auf die UDP-Ziel- als auch Quellportnummern angewendet
werden kann); und das IP Differentiated Services (DS) Feld. Ähnlich zu
dem selektiven TCP-Spoofing und unter Priorisierung kann der PSK 284 einen
Pfad bestimmen, in dem ein beliebiges Feld in dem IP-Paket verwendet
wird.
-
Wie
bei den Priorisierungskriterien (Regeln) können die UND- und ODER-Kombinationsoperatoren
verwendet werden, um Kriterien miteinander zu verknüpfen. Beispielsweise
kann unter Verwendung des UND-Kombinationsoperators eine Regel definiert
werden, um einen Pfad für
SNMP-baten auszuwählen,
die von einem spezifischen Host empfangen werden. Ebenfalls ist
die Reihenfolge, in der die Regeln spezifiziert werden, wesentlich.
Es ist für
eine Verbindung möglich,
das Kriterium mehrerer Regeln zu erfüllen. Deshalb kann der PCK 286 Regeln
in der Reihenfolge anwenden, die von dem Operator spezifiziert sind,
wobei die Aktion der ersten passenden Regel genommen wird. Eine
Default-Regel kann ebenfalls eingestellt werden, die die Aktion
definiert, die eingesetzt werden soll für IP-Pakete, die auf keine
der definierten Regeln passen. Der Satz von Regeln, die von dem
Operator ausgewählt
werden, kann in einem Pfadauswahlprofil definiert werden.
-
Beispielsweise
kann eine Pfadauswahlregel den Pfad basierend auf jeder der nachfolgenden Pfadinformationen
auswählen,
in der IP-Pakete die Regel erfüllen:
ein Hauptpfad, ein Zweitpfad und ein Drittpfad. Der Hauptpfad wird
in jeder Auswahlregel spezifiziert. Der Zweitpfad wird nur verwendet,
wenn der Hauptpfad ausgefallen ist. Falls der Zweitpfad nicht spezifiziert
ist, können
jegliche IP-Pakete, die die Regel erfüllen, verworfen werden, wenn
der Hauptpfad ausgefallen ist. Der Drittpfad wird nur spezifiziert,
falls ein Zweitpfad spezifiziert ist. Der Drittpfad wird ausgewählt, falls
sowohl der Haupt- als auch der Zweitpfad ausgefallen sind. Falls
kein Drittpfad spezifiziert ist, werden jegliche IP-Pakete, die die
Regel erfüllen,
verworfen, wenn sowohl der Haupt- als auch der Zweitpfad ausgefallen
sind. Die Pfadauswahl kann verallgemeinert werden, derart, dass die
Pfadauswahlregel bis zu N Pfade auswählen kann, wobei der N-te Pfad
nur verwendet wird, falls der (N – 1)-te Pfad ausgefallen ist.
Die zuvor angegebenen Beispiele, in denen N = 3 ist, sind rein beispielhaft,
obgleich N typischerweise eine ziemlich kleine Zahl ist.
-
Beispielhaft
wird der Betrieb des Systems 100 nachfolgend beschrieben.
Zuerst wird eine Backbone-Verbindung zwischen den PEPs 200 der
zwei Netzwerk-Gateways 120, 140 (d.h. den zwei
Spoofern) errichtet, die an jedem Ende der Backbone-Verbindung 130 angeordnet
sind, für
die das TCP-Spoofing gewünscht
wird. Wann immer ein IP-Host 110 eine TCP-Verbindung initiiert, überprüft der TSK 280 des
PEP 200, der lokal zu dem IP Host 110 liegt, seine
konfigurierten selektiven TCP Spoofing-Regeln. Falls die Regeln
anzeigen, dass die Verbindung nicht gespooft werden soll, ermöglicht der
PEP 200, dass die TCP-Verbindung von Ende zu Ende ungespooft erfolgt.
Falls die Regeln anzeigen, dass die Verbindung gespooft werden soll,
antwortet der Spoofing PEP 200 lokal auf den TCP Drei-Wege-Handshake des
IP Hosts. Parallel dazu sendet der Spoofing PEP 200 eine
Nachricht über
die Backbone-Verbindung 130 an sein Partner-Netzwerk-Gateway 140,
um ihn zu bitten, ein TCP Drei-Wege-Handshake mit dem IP Host 150 auf
dessen Seite der Backbone-Verbindung 130 zu initiieren.
Daten werden dann zwischen dem IP Host 110, 150 mit
dem PEP 200 des Netzwerk-Gateways 120 ausgetauscht,
die empfangenen Daten werden lokal bestätigt und über die Backbone-Verbindung 130 über die
Hochgeschwindigkeits-Backbone-Verbindung weitergeleitet, die Daten werden
basierend auf den konfigurierten Komprimierungsregeln geeignet komprimiert.
Die Priorität
der TCP-Verbindung wird bestimmt, wenn die Verbindung aufgebaut
ist. Der BPK 282 kann die Verbindung mit anderen empfangenen
Verbindungen über eine
einzelne Backbone-Verbindung multiplexen, der PK 284 bestimmt
die Priorität
der Verbindung, und der PSK 286 bestimmt den Pfad, den
die Verbindung nehmen soll.
-
Der
PEP 200, wie zuvor beschrieben, verbessert vorteilhafterweise
die Netzwerkleistung, indem TCP Spoofing-bezogene Quellen belegt
werden, wie beispielsweise Pufferplatz, Steuerungsblöcke etc.,
nur für
TCP-Verbindungen, für
die Spoofing vorteilhaft ist; indem der Drei-Wege-Handshake gespooft
wird, um die Datenantwortzeiten zu verringern; indem die Anzahl
der ACKs reduziert wird, die übertragen
werden, indem ein lokales Acknowledgement ausgeführt wird, und indem mehrere
TCP-Verbindungen mit einem einzelnen ACK bestätigt werden; indem eine Datenkomprimierung
erfolgt, um die Datenmenge zu erhöhen, die übertragen werden kann; indem
Prioritäten
zugewiesen werden auf unterschiedliche Verbindungen; und indem mehrere Pfade
für herzustellende
Verbindungen definiert werden.
-
3 zeigt
einen beispielhaften Stack, der das Verhältnis zwischen dem TCP Stack
und den PEP-Kernen 280, 282, 284, 286 der
vorliegenden Erfindung darstellen. Der TSK 280 ist hauptsächlich verantwortlich
für die
Funktionen, die das TCP Spoofing betreffen. Der TSK 280 umfasst
in einer beispielhaften Ausführungsform
zwei Basiselemente: eine Transportschicht, die einen TCP Stack 303 und
einen IP Stack 305 einschließt; und eine TCP Spoofing-Anwendung 301.
Die Transportschicht ist verantwortlich für die Interaktion mit den TCP
Stacks (beispielsweise 303) der IP Hosts 110,
die mit einer lokalen LAN-Schnittstelle 220 eines
PEP 210 verbunden sind.
-
Der
TSK 280 implementiert das TCP-Protokoll, das die geeigneten
TCP-Zustandsmaschinen umfasst und die gespooften TCP-Verbindungen
abschließt.
Die TCP-Spoofing-Anwendung 301 sitzt auf der Transportschicht
und wirkt als die Anwendung, die Daten von den Anwendungen des IP
Host 110 empfängt
und Daten zu diesem sendet. Aufgrund der Schichtarchitektur des
Protokolls isoliert die TCP-Spoofing-Anwendung 301 die
Details des TCP-Spoofing gegenüber
der Transportschicht, so dass die Transportschicht in der Standardform
arbeiten kann.
-
Wie
in 3 gezeigt, kann die TCP-Spoofing-Anwendung 301 ebenfalls
mit dem BPK 282 gekoppelt sein, der mit den WAN-Schnittstellen 230 verknüpft ist.
Der BPK 282 führt
eine Backbone-Protokoll-Aufrechterhaltung aus, und implementiert
das Protokoll, mit dem die Netzwerke-Gateways 120, 140 (in 1)
kommunizieren. Der BPK 282 stellt eine zuverlässige Auslieferung
von Daten bereit, verwendet eine relativ kleine Menge an Bestätigungsverkehr und
unterstützt
eine allgemeine Backbone-Verwendung
(d.h. die Verwendung, die nicht spezifisch für TSK ist); ein solches Beispiel
ist das zuverlässige
Datenprotokoll bzw. reliable data protocol (RDP).
-
Der
BPK 282 liegt entsprechend einer beispielhaften Ausführungsform über dem
PK 284 und dem PSK 286. Der PK 284 ist
verantwortlich zur Festlegung der Priorität der IP-Pakete und dann zur
Belegung der Übertragungsmöglichkeiten
basierend auf der Priorität.
Der PK 284 kann ebenfalls den Zugriff auf den Pufferraum
steuern, indem die Warteschlangengröße gesteuert wird, die mit
dem Senden und Empfang von IP-Paketen verknüpft ist. Der PSK 286 bestimmt,
welchen Pfad ein IP-Paket nehmen soll, um sein Ziel zu erreichen.
Der Pfad, der von dem PSK 286 ausge wählt ist, kann bestimmt werden,
indem Pfadauswahlregeln angewendet werden. PSK 286 kann
ebenfalls festlegen, welches IP-Paket
weitergeleitet werden soll, indem ein alternativer Pfad verwendet
wird, und welche Pakete fallen gelassen werden sollen, wenn einer
oder mehrere Pfade ausgefallen sind.
-
4A und 4B zeigen
Flussdiagramme des Aufbaus einer gespooften TCP-Verbindung, in dem
ein Drei-Wege-Handshake-Spoofing
verwendet wird, bzw. ohne ein Drei-Wege-Handshake-Spoofing. Der TCP-Spoofing-Kern 180 errichtet
eine gespoofte TCP-Verbindung, wenn ein TCP <SYN>-Segment von
dessen lokalem LAN empfangen wird oder eine Verbindungsanforderungsnachricht
von dessen TSK-Netz. Es ist anzumerken, dass das Drei-Wege-Handshake-Spoofing
gesperrt werden kann, um einen End-zu-End-Maximum-Segmentgrößen(MSS)-Austausch zu unterstützen, der
nachfolgend deutlicher beschrieben werden wird. Zum Zwecke der Erläuterung
wird der gespoofte TCP-Verbindungsaufbauprozess mit Bezug auf einen
lokalen Host 400, einen lokalen PIP-Endpunkt 402,
einen entfernten PEP-Endpunkt 404 und einen entfernten Host 406 beschrieben.
Wie zuvor ausgeführt,
liefert der TSK 280 innerhalb jedes PEP-Endpunkts 402 und 404 die
Spoofing-Funktionalität.
-
In
Schritt 401 sendet der lokale Host 400 ein TCP <SYN>-Segment an den lokalen
PEP-Endpunkt 402 an einer lokalen LAN-Schnittstelle 220.
Wenn ein TCP-Segment von der lokalen LAN-Schnittstelle 220 empfangen
wird, bestimmt die Plattformumgebung 402, ob es bereits
einen TCP-Verbindungs-Steuerungsblock (CCB) gibt, der der TCP-Verbindung
zugeordnet ist, die mit dem TCP-Segment verknüpft ist. Falls es keinen CCB
gibt, prüft
die Umgebung 402, ob das TCP-Segment ein <SYN>-Segment ist, das zu
einem nicht lokalen Ziel gesendet wurde. Falls dies der Fall ist,
stellt das <SYN>-Segment einen Versuch
dar, eine neue (nicht lokale) TCP-Verbindung aufzubauen, und die
Umgebung 402 reicht das Segment an den TCP-Spoofing-Kern 280 weiter,
um die Disposition der TCP-Verbindung festzulegen. Wenn ein TCP <SYN>-Segment von der lokalen LAN-Schnittstelle 220 für eine neue
TCP-Verbindung empfangen wird, bestimmt der TCP-Spoofing-Kern 280 zuerst,
ob die Verbindung gespooft werden soll. Falls die Verbindung gespooft
werden soll, verwendet der TSK 280 (in einer beispielhaften
Ausführungsform)
die Priorität,
die in dem ausgewählten TCP-Spoofing-Parameterprofil
angegeben ist und den Partnerindex (der von der Umgebung 210 mit dem
TCP <SYN>-Segment bereitgestellt wird), um den
Handle der Backbone-Verbindung
zu konstruieren, der verwendet werden sollte, um diese gespoofte
TCP-Verbindung zu tragen. In der beispielhaften Ausführungsform
wird der Partner-Index in den höheren
14 Bits des Handles angegeben, und die Priorität wird in den zwei niedrigeren
Bits des Handles angegeben. Der Backbone-Verbindungs-Handle wird dann
eingesetzt (über
die TSK-Steuerungsblock (TCB)-Abbildungstabelle), um den TCB zu
finden, der mit der Backbone-Verbindung verknüpft ist. Der TSK 280 des
PEP-Endpunkts 402 überprüft dann,
ob die Backbone-Verbindung steht. Falls die Backbone-Verbindung
steht, bestimmt der TSK 280, ob die Anzahl der gespooften
TCP-Verbindungen, die bereits die ausgewählte Backbone-Verbindung verwenden,
noch immer unter der CCB-Ressourcengrenze liegt. Die CCB-Ressourcengrenze
ist der kleinere Wert der lokalen Anzahl von CCBs (der als Parameter
von der Plattformumgebung 210 bereitgestellt wird) und
der Partner-Anzahl von CCBs (die in der neuesten TSK-Partnerparameter
(TPP)-Nachricht von dem TSK-Partner empfangen wurde), die für diese
Backbone-Verbindung verfügbar
sind. Falls die Anzahl der Verbindungen noch unter der Grenze liegt,
weist der TSK 280 des PEP-Endpunkts 402 einen
eindeutigen TCP-Verbindungsidentifizierer (beispielsweise ein freier
TCB-Abbildungstabelleneintragsindex) der Verbindung zu und ruft
die Umgebung 210 auf, einen TCP-Verbindungssteuerungsblock
für die
Verbindung zu belegen.
-
Der
TSK 280 des PEP-Endpunkts 402 gibt das TCP <SYN>-Segment zurück an die
Umgebung 210, das ungespooft weitergeleitet wird, falls
einer der vorgenannten Überprüfungen fehlschlägt. Mit
anderen Worten führen
die folgenden Bedingungen dazu, dass die TCP-Verbindung ungespooft
ist. Erstens, falls die selektiven TCP-Spoofing-Regeln anzeigen,
dass die Verbindung nicht gespooft werden soll. Ebenfalls wenn es
keine Backbone-Verbindung für
die Priorität
gibt, mit der die TCP-Verbindung gespooft werden soll (angezeigt
durch Fehlen eines TCB für
die Backbone-Verbindung). Kein Spoofing wird ausgeführt, falls
die Backbone-Verbindung heruntergefahren ist. Zusätzlich,
falls die Anzahl der gespooften TCP-Verbindungen, die bereits von
der Backbone-Verbindung benutzt werden, einen vorbestimmten Schwellenwert
erreicht oder überschreitet, wird
dann kein Spoofing ausgeführt.
Ferner, falls es keinen CCB-Verbindungstabelleneintrag gibt, der verfügbar ist
oder es keinen CCB gibt, der von dem CCB-Freipool verfügbar ist,
wird die TCP-Verbindung ungespooft weitergeleitet. Für den Fall,
bei dem es keine Backbone-Verbindung gibt, kann der TSK 280 des
PEP-Endpunkts 402 ebenfalls ein Ereignis absenden, um den
Operator zu alarmieren, dass es eine Fehlanpassung zwischen den
konfigurierten TCP-Spoofing-Parameterprofilen
und dem konfigurierten Satz von Backbone-Verbindungen gibt.
-
Das
Beispiel sei nun fortgeführt.
Falls all die zuvor genannten Prüfungen
bestanden werden, schreibt der TSK 280 des PEP-Endpunkts 402 den Backbone-Verbindungs-Handle
in den Puffer, der das TCP <SYN>-Segment hält. Es ist
anzumerken, dass dies nicht getan wird, bis ein CCB von der Plattformumgebung 402 erfolgreich
belegt wird, da die Umgebung den Puffer nicht zählt, solange nicht ein CCB
erfolgreich belegt ist. TSK 280 kopiert dann die Parameter
von dem ausgewählten
TCP-Spoofing-Parameterprofil
in den CCB. Folglich wird relevante Information (beispielsweise
die maximale Segmentgröße, die
von dem Host angezeigt wird (falls kleiner als der konfigurierte
MSS), die anfängliche Reihenfolgennummer,
etc.) aus dem TCB <SYN>-Segment kopiert und
in dem TCB gespeichert. Es ist zu bemerken, dass die Quell- und Ziel-IP-Adressen
und Quell- und Ziel-TCP-Portnummern
bereits in den CCB von der Plattformumgebung 402 abgelegt
wurden, als der CCB belegt wurde; die Umgebung 402 benutzt
diese Information, um CCB-Hash-Funktion-Kollisionen zu verwalten.
-
Nach
dem Belegen und Setzen des CCB baut der TCP-Spoofing-Kern 280 des
PEP-Endpunkts 402 eine Connection Request (CR)-Nachricht per
Schritt 403 auf und sendet diese an sein TSK-Netz, das
mit dem entfernten PEP-Endpunkt 404 verknüpft ist.
Die CR-Nachricht
enthält
hauptsächlich
all die Information, die aus dem TCP-Spoofing-Parameterprofil und
dem TCP <SYN>-Segment extrahiert
wurde, und wird in dem lokalen CCB gespeichert, beispielsweise die
Quell- und Ziel-IP-Adressen, die Quell- und Ziel-TCP-Portnummern,
der MSS-Wert, etc., mit Ausnahme der Felder, die nur lokale Bedeutung
haben, wie beispielsweise die anfängliche Reihenfolgennummer.
(Die IP-Adressen und die TCP-Portnummern
werden in einen TCP-Verbindungsheader gesetzt.) Mit anderen Worten
enthält
die CR-Nachricht all die Information, welche der Partner-TSK des
PEP-Endpunkts 404 für
den Aufbau seiner eigenen CCB benötigt. Um den lokalen Verbindungsaufbau
zu vervollständigen,
sendet der TCP-Spoofing-Kern 280 des lokalen PEP-Endpunkts 402 ein
TCP <SYN, ACK>-Segment an den lokalen Host 400 in
Antwort auf das <SYN>-Segment, das empfangen
wurde in Schritt 405. Der TSK 280 des PEP-Endpunkts 402 führt den
Schritt 405 gleichzeitig mit dem Schritt des Sendens der
Connection Request-Nachricht bzw. der Verbindungsanforderungsnachricht
(d.h. Schritt 403) aus, falls ein Drei-Wege-Handshake-Spoofing freigegeben
ist. Anderenfalls wartet der TSK 280 von 402 auf
eine Verbindungsaufbau(CE)-Nachricht bzw. Connection Established-Nachricht
von seinem TSK-Partner des entfernten PEP-Endpunkts 404,
bevor das <SYN, ACK>-Segment gesendet wird.
Bei einer beispielhaften Ausführungsform
wählt der
TSK 280 des PEP-Endpunkts 402 eine zufällige anfängliche
Reihenfolgennummer aus (wie in IETF (Internet Engineering Task Force)
RFC 793 bereitgestellt), um sie für das Senden von Daten zu verwenden.
-
Falls
ein Drei-Wege-Handshake-Spoofing nicht freigegeben ist, wird der
MSS-Wert, der in dem <SYN,
ACK>-Segment gesendet
wurde, auf den MSS-Wert gesetzt, der in der CE-Nachricht empfangen
wurde. Falls das Drei-Wege-Handshake-Spoofing freigegeben ist, wird
der MSS-Wert aus dem TCP-Spoofing-Parameterprofil bestimmt, das
für die Verbindung
ausgewählt
wurde (und die konfigurierte Pfad-Maximum-Übertragungseinheit (MTU)).
Für diesen
Fall vergleicht dann der TSK 280 des PEP-Endpunkts 402 den
MSS-Wert, der in
der Connection Established-Nachricht empfangen wurde, wenn diese
ankommt, mit dem Wert, der zu dem lokalen Host in dem TCP <SYN, ACK>-Segment gesendet wurde.
Falls der MSS-Wert, der in der CE-Nachricht empfangen wurde, kleiner
ist als der MSS-Wert, der von dem lokalen Host gesendet wurde, existiert
eine Fehlanpassung einer maximalen Segmentgröße. (Falls eine MSS-Fehlanpassung existiert,
muss der TSK die Größe der TCP-Datensegmente
vor deren Senden einstellen). Nach dem Senden des TCP <SYN, ACK>-Segment (Schritt 405)
ist der TSK 280 des lokalen PEP-Endpunkts 402 bereit,
um die Annahme von Daten von dem lokalen Host 400 zu starten.
In Schritt 407 sendet der lokale Host 400 ein <ACK>-Segment an den TSK 280 des PEP-Endpunkts 402;
danach leitet der lokale Host in Schritt 409 ebenfalls
Daten an den TSK 280 des PEP-Endpunkts 402. Wenn
das Drei-Wege-Handshake-Spoofing verwendet wird, muss der TSK 280 nicht
auf die Connection Established-Nachricht warten, die von dessen
TSK-Peer ankommt, bevor die Daten angenommen und weitergeleitet
werden. Wie in 4A zu sehen, sendet der TSK 280 des
lokalen PEP-Endpunkts 402 in Schritt 411 ein <ACK>-Segment an den lokalen
Host und sendet gleichzeitig die TCP-Daten (TD) von dem lokalen
Host 400 an den Partner-TSK des PEP-Endpunkts 404 (in
Schritt 413) vor dem Empfang einer CE-Nachricht von dem
Partner-TSK des PEP-Endpunkts 404.
-
Der
TSK 280 des PEP-Endpunkts 402 akzeptiert jedoch
keine Daten von seinem TSK-Partner des PEP-Endpunkts 404 bis
nach dem die CE-Nachricht empfangen wurde. TSK 280 des
PEP-Endpunkts 402 leitet jegliche Daten nicht weiter, die
von seinem TSK-Partner des PEP-Endpunkts 404 empfangen
wurden, zu dem lokalen Host 400 weiter, bis er das TCP <ACK>-Segment empfangen
hat, das anzeigt, dass der lokale Host das <SYN, ACK>-Segment empfangen hat (wie in Schritt 407).
-
Wenn
eine Connection Request-Nachricht von einem Partner-TSK (Schritt 403)
umfangen wurde, belegt der TCP-Spoofing-Kern 280 ein CCB
für die
Verbindung und speichert dann alle relevanten Informationen aus
der CR-Nachricht in dem CCB. TSK 280 des PEP-Endpunkts 404 benutzt
dann diese Information, um ein TCP <SYN>-Segment zu erzeugen,
wie in Schritt 415, um dies zu dem entfernten Host 406 zu
senden. Das MSS in dem <SYN>-Segment wird auf den
Wert gesetzt, der von dem TSK-Partner des PEP-Endpunkts 404 empfangen wurde.
Wenn der entfernte Host mit einem TCP <SYN, ACK>-Segment antwortet (Schritt 417),
sendet der TSK 280 des PEP-Endpunkts 402 eine
Connection Established-Nachricht an seinen TSK-Partner des entfernten
PEP-Endpunkts 404 (Schritt 419), die die CE-Nachricht
des MSS enthält,
die von dem lokalen Host in dem <SYN,
ACK>-Segment gesendet wurde.
Der TSK 280 des PEP-Endpunkts 402 antwortet ebenfalls
als Schritt 421 mit einem TCP <ACK>-Segment,
um den lokalen Drei-Wege-Handshake zu vervollständigen. Der Partner TSK des PEP-Endpunkts 404 leitet
dann die Daten weiter, die vom TSK 280 empfangen wurden,
an den Host, per Schritt 423. Gleichzeitig sendet in Schritt 425 der
entfernte Host 406 Daten an den Partner-TSK des PEP-Endpunkts 404,
der den Empfang der Daten bestätigt,
indem ein <ACK>-Segment an den entfernten PEP-Endpunkt 404 abgegeben
wird, per Schritt 427. Gleichzeitig mit der Bestätigung werden
die Daten an den TSK 280 des PEP-Endpunkts 402 gesendet (Schritt 429).
-
An
diesem Punkt ist TSK 280 bereit, Daten aus jeder Richtung
zu empfangen und weiterzuleiten. TSK 280 leitet die Daten,
wie in Schritt 431, an den lokalen Host weiter, der wiederum
ein <ACK>-Segment sendet (Schritt 433).
Falls die Daten von seinem TSK-Partner vor einer <SYN, ACK>-Segment Antwort von
dem lokalen Host empfangen werden, werden die Daten in eine Warteschlange
gebracht und dann gesendet, nachdem das <ACK>-Segment in
Antwort auf das <SYN,
ACK>-Segment gesendet wurde
(wenn es ankommt).
-
Es
sei nun auf 4B Bezug genommen. Eine gespoofte
TCP-Verbindung wird
aufgebaut, wobei das Drei-Wege-Handshake-Spoofing gesperrt bzw. nicht freigegeben
ist. Bei diesem Szenario sendet der lokale Host 400 ein
TCP <SYN>-Segment in Schritt 451 an
den TSK 280 innerhalb des lokalen PEP-Endpunkts 402.
Im Gegensatz zu dem TCP-Verbindungsaufbau von 4A antwortet
der lokale PEP-Endpunkt 402 nicht auf ein TCP <SYN>-Segment mit einem <SYN, ACK>-Segment, sondern leitet
lediglich eine CR-Nachricht
an den entfernten PEP-Endpunkt 404 (Schritt 453).
Als Nächstes
in Schritt 455 sendet er ein TCP <SYN>-Segment an
den entfernten Host 406. In Antwort darauf übermittelt
der entfernte Host 406 ein TCP <SYN, ACK>-Segment zurück an den entfernten PEP-Endpunkt 404 (in
Schritt 457). Danach leitet der entfernte PEP-Endpunkt 404 als
Schritt 459 eine CE-Nachricht an den lokalen PEP-Endpunkt 402,
der darauf folgend ein <SYN,
ACK>-Segment an den
lokalen Host 400 in Schritt 461 abgibt. Gleichzeitig
mit Schritt 459 gibt der entfernte PEP-Endpunkt 404 ein <ACK>-Segment an den entfernten Host 406 (Schritt 463)
ab.
-
Beim
Empfang des <ACK>-Segments kann der
entfernte Host 406 mit der Datenübertragung beginnen, als Schritt 465.
Sobald der PEP-Endpunkt 404 die
Daten von dem entfernten Host 406 empfängt, überträgt gleichzeitig der entfernte
PEP-Endpunkt 404 in Schritt 467 die TD-Nachricht
an den lokalen PEP-Endpunkt 402 und sendet ein <ACK>-Segment an den entfernten
Host 406, um den Empfang der Daten zu bestätigen (Schritt 469).
-
Da
der lokale Host 400 ein <SYN, ACK>-Segment von dem lokalen
PEP-Endpunkt 402 empfangen hat, bestätigt der lokale Host 400 die Nachricht
in Schritt 471. Danach sendet der lokale Host 400 Daten
an den lokalen PEP-Endpunkt 402. Bevor der lokale PEP-Endpunkt 402 in
diesem Beispiel die Daten von dem lokalen Host 400 empfängt, leitet
der lokale PEP-Endpunkt 402 die Daten weiter, die von dem
entfernten Host 406 stammen, über die TD-Nachricht (Schritt 467)
an den lokalen Host 400, als Schritt 475.
-
In
Antwort auf die empfangenen Daten (in Schritt 473) gibt
der lokale PEP-Endpunkt 402 ein <ACK>-Segment
als Schritt 477 ab und leitet die Daten in einer TD-Nachricht
an den entfernten PEP-Endpunkt 404 als Schritt 479 weiter.
Der lokale Host 400 antwortet auf die empfangenen Daten
von Schritt 475 mit einem <ACK>-Segment
zu dem lokalen PEP-Endpunkt 402 (Schritt 481).
Der entfernte PEP-Endpunkt 404 sendet die Daten von dem
lokalen Host 400 als Schritt 483 beim Empfang
der TD-Nachricht. Nach Empfang der Daten bestätigt der entfernte Host 406 den
Empfang durch Senden eines <ACK>-Segments zurück an den
entfernten PEP-Endpunkt 404,
als Schritt 485.
-
5 zeigt
den Strom der Pakete mit der PEP-Architektur entsprechend einer
Ausführungsform
der vorliegenden Erfindung. Wie gezeigt umfasst ein Kommunikationssystem 500 einen PEP-Endpunkt 501 auf
einer Hub-Seite (oder lokal), der mit einem PEP-Endpunkt 503 an
einem entfernten Ort über
eine Backbone-Verbindung verbunden ist. Auf der Hub-Seite bzw. dem
Hub-Ort (oder dem lokalen Ort) und an jedem entfernten Ort handhaben die
PEP-Endpunkte 501 und 503 beispielhaft IP-Pakete.
PEP-Endpunkt 501 umfasst ein internes IP-Paket Routingmodul 501a,
das lokale IP-Pakete
empfängt
und diese Pakete mit einem TSK 501b und einem BPK 501c austauscht.
In gleicher Weise umfasst der entfernte PEP-Endpunkt 503 ein
internes IP-Paket Routingmodul 503a, dessen Kommunikation
mit einem TSK 503b und einem BPK 503c steht. Mit
Ausnahme der Tatsache, dass der PEP-Endpunkt 501 auf der
Hub-Seite sehr viel mehr Backbone-Protokoll-Verbindungen unterstützen kann
als ein PEP-Endpunkt 503 auf der entfernten Seite, sind
die PEP-Verarbeitungen auf der Hub- und der entfernten Seite symmetrisch.
-
Für einen
Verkehr von lokal zu WAN (d.h. Upstream-Richtung) empfängt der
PEP-Endpunkt 501 IP-Pakete von seiner lokalen Schnittstelle 220 (2).
Nicht-TCP-IP-Pakete werden zu der WAN-Schnittstelle 230 (2)
weitergeleitet (wenn gewünscht).
TCP-IP-Pakete werden intern zur TSK 501b weitergeleitet.
TCP-Segmente, die zu Verbindungen gehören, die nicht gespooft werden,
werden von dem Spoofing-Kern 501b zu dem Routingmodul 501a gereicht,
um unverändert
zu der WAN-Schnittstelle 230 geleitet zu werden. Für gespoofte TCP-Verbindungen
schließt
der TCP-Spoofing-Kern 501a lokal die TCP-Verbindung ab.
TCP-Daten, die von einer gespooften Verbindung empfangen werden,
werden von dem Spoofing-Kern 501a zu dem Backbone-Protokoll-Kern 501c gereicht
und dann auf die geeignete Backbone-Protokoll-Verbindung gemultiplext.
Der Backbone-Protokoll-Kern 501c gewährleistet,
dass die Daten über
das WAN ausgeliefert werden.
-
Bei
einem Verkehr von WAN zu lokal (d.h. Downstream-Richtung) empfängt der
entfernte PEP-Endpunkt 503 IP-Pakete von seiner WAN-Schnittstelle 230 (2).
IP-Pakete, die nicht an den Endpunkt 503 adressiert sind,
werden einfach an die lokale Schnittstelle 220 (2)
(geeignet) weitergeleitet. IP- Pakete,
die für
den Endpunkt 503 adressiert sind, die einen Next Protocol
Header-Typ von "PBP" haben, werden zu
dem Backbone-Protokoll-Kern 503c geleitet. Der Backbone-Protokoll-Kern 503c extrahiert
die TCP-Daten und leitet sie an den TCB-Spoofing-Kern 503b zur Übertragung
auf die geeignete gespoofte TCP-Verbindung weiter. Zusätzlich zum Übertragen
der TCP-Daten wird die Backbone-Protokoll-Verbindung von dem TCP-Spoofing-Kern 501b benutzt,
um Kontrollinformation zu seinem Partner-TCP-Spoofing-Kern 503b in dem entfernten
PEP-Endpunkt 503 zu senden, um den Verbindungsaufbau und
den Verbindungsabbruch zu koordinieren.
-
Eine
Priorisierung kann an vier Punkten an dem System 500 angewendet
werden innerhalb des Routingmoduls 501a und dem TSK 501b des PEP-Endpunkts 501 und
innerhalb des Routingmoduls 503a und dem TSK 503b des
PEP-Endpunkts 503. In Upstream-Richtung werden Prioritätsregeln auf
die Pakete der einzelnen TCP-Verbindungen am Eintrittspunkt zu dem
TCP-Spoofing-Kern 501 angewendet. Diese Regeln ermöglichen
es einem Kunden, zu steuern, welche gespooften Anwendungen höhere und
niederere Prioritätszugriffe
auf die Spoofing-Ressourcen haben. Eine Upstream-Priorisierung wird
ebenfalls vor dem Weiterleiten der Pakete zu dem WAN angewendet.
Dies ermöglicht
es einem Kunden, die relative Priorität der gespooften TCP-Verbindungen
mit Bezug auf die ungespooften TCP-Verbindungen und Nicht-TCP-Verkehr
zu steuern (sowie die relative Priorität dieser anderen Typen von
Verkehr mit Bezug aufeinander zu steuern). Auf der Downstream-Seite
wird die Priorisierung verwendet, um den Zugriff auf den Pufferplatz
zu steuern und auf andere Ressourcen in dem PEP-Endpunkt 503 allgemein
und mit Bezug auf das TCP-Spoofing.
-
Auf
der Hub- (oder lokalen) Seite kann der PEP-Endpunkt 501 in
einem Netzwerk-Gateway (beispielsweise ein IP-Gateway) implementiert
sein entsprechend einer Ausführungsform
der vorliegenden Erfindung. Auf der entfernten Seite kann der PEP-Endpunkt 503 in
der Komponente der entfernten Seite implementiert sein, beispielsweise
einem Satellitenterminal, wie beispielsweise einem Multimedia-Relay,
Multimedia-VSAT oder einer Personal Earth Station (PES) Remote.
-
Die
Architektur des Systems 500 stellt eine Anzahl von Vorteilen
bereit. Zunächst
kann ein TCP-Spoofing sowohl in Upstreamals auch in Downstream-Richtung
erreicht werden. Zusätzlich unterstützt das
System ein Spoofing des TCP-Verbindungsstarts, und ein selektives
TCP-Spoofing nur mit Verbindungen, die vom Spoofing profitieren
können.
Ferner ermöglicht
das System 500 eine Priorisierung der gespooften TCP-Verbindungen
für einen Zugriff
auf die TCP-Spoofing-Ressourcen (beispielsweise verfügbare Bandbreite
und Pufferplatz). Diese Priorisierung wird für alle Typen von Verkehr verwendet,
die nach Systemressourcen ringen.
-
Mit
Bezug auf die Backbone-Verbindung ist das System 500 zur
Anwendung in einem Satellitennetzwerk als WAN geeignet. Das heißt, dass
das Backbone-Protokoll für
Satellitenverwendung optimiert ist, indem Kontrollblockressourcenanforderungen
minimiert werden und eine effiziente Fehlerentdeckung für verloren
gegangene Pakete bereitstellt. Das System 500 liefert ebenfalls
einen Feedback-Mechanismus, um maximale Pufferplatzressourceneffizienz
zu unterstützen.
Ferner stellt das System 500 einen reduzierten Bestätigungsverkehr bereit,
indem ein einzelnes Backbone-Protokoll ACK verwendet wird, um die
Daten mehrerer TCP-Verbindungen zu bestätigen.
-
6 zeigt
den Fluss der IP-Pakete durch einen PEP-Endpunkt entsprechend einer
Ausführungsform
der vorliegenden Erfindung. Wenn IP-Pakete in der lokalen LAN-Schnittstelle 220 empfangen werden,
bestimmt der PEP-Endpunkt 210 (wie durch den Entscheidungspunkt
A gezeigt), ob die Pakete für
einen Host bestimmt sind, der lokal liegt; falls dies der Fall ist,
werden die IP-Pakete
zu der passenden lokalen LAN-Schnittstelle 220 geleitet.
Falls die IP-Pakete für
einen entfernten Host bestimmt sind, entscheidet dann der PEP-Endpunkt 210 am
Entscheidungspunkt B, ob der Verkehr ein TCP-Segment ist. Falls
der PEP-Endpunkt 210 festlegt, dass die Pakete tatsächlich TCP-Segmente
sind, bestimmt dann der TSK 280, ob die TCP-Verbindung gespooft
werden sollte. Falls jedoch der PEP-Endpunkt 210 bestimmt,
dass die Pakete keine TCP-Segmente sind, verarbeitet dann der BPK 282 den
Verkehr zusammen mit dem PK 284 und dem PSK 286 für eine mögliche Übertragung
in das WAN. Es ist zu bemerken, dass der BPK 282 keine
ungespooften IP-Pakete verarbeitet; d.h., dass die Pakete direkt
zum PK 284 strömen.
Wie in 6 zu sehen, wird der Verkehr, der von der WAN-Schnittstelle 230 empfangen
wird, geprüft,
um zu bestimmen, ob der Verkehr ein richtiges PBP-Segment (Entscheidungspunkt
D) für
den bestimmten PEP-Endpunkt 210 ist; falls
die Bestimmung dies bestätigt,
werden dann die Pakete zu dem BPK 282 und dann dem TSK 280 gesendet.
-
Eine
Routingunterstützung
umfasst das Routen zwischen den Ports des PEP-Endpunkts 210 (2),
beispielsweise von einem Multimedia VSAT LAN-Port zu einem anderen.
Hinsichtlich der Architektur passen die Funktionalitäten des
TCP-Spoofings, der Prio risierung und der Pfadauswahl zwischen die
IP-Routing-Funktionalität
und das WAN. Die PEP-Funktionalität muss nicht auf IP-Pakete angewendet
werden, die von einem lokalen Port zu einem lokalen Port innerhalb
des gleichen PEP-Endpunkts 210 geroutet werden. TCP-Spoofing,
Priorisierung und Pfadauswahl werden auf IP-Pakete angewendet, die
von einer lokalen PEP-Endpunkt-Schnittstelle
empfangen werden, die dazu bestimmt wurden, für eine andere Seite bzw. einen
anderen Ort als Ziel zu dienen, durch die Routingfunktion.
-
7 zeigt
das Verhältnis
zwischen den PEP-Endpunkten und den PEP-Endpunkt-Profilen entsprechend
einer Ausführungsform
der vorliegenden Erfindung. PEP-Parameter sind hauptsächlich konfiguriert über eine
Menge von Profilen 701 und 703, die mit einem
oder mehreren PEP-Endpunkten 705 verknüpft sind. Bei einer beispielhaften
Ausführungsform
sind die PEP-Parameter konfiguriert auf einer PEP-Endpunkt-Basis,
so als ob TCP-Spoofing global
freigegeben ist. Diese Parameter werden in den PEP-Endpunkt-Profilen 701 und 703 konfiguriert. Es
ist anzumerken, dass Parameter, die auf spezifische PEP-Kerne angewendet
werden, konfiguriert werden können über andere
Typen von Profilen. Profile 701 und 703 sind eine
Netzwerkmanagementkonstruktion; intern verarbeitet ein PEP-Endpunkt 705 einen
Satz von Parametern, die über
ein oder mehrere Files empfangen werden.
-
Wann
immer der PEP-Endpunkt 705 neue Parameter empfängt, vergleicht
die Plattformumgebung die neuen Parameter mit den vorhandenen Parametern,
findet heraus, ob die PEP-Kerne durch die Parameteränderungen
betroffen sind und reicht dann die neuen Parameter an die betroffenen
Kerne. Bei einer beispielhaften Ausführungsform sind alle Parameter
dynamisch installiert. Mit Ausnahme der Parameter, die komponentenspezifisch
sind (wie beispielsweise die IP-Adressen einer Komponente) können alle
Parameter mit Default-Werten definiert werden.
-
Wie
zuvor erwähnt,
kann der PEP-Endpunkt 210 in einer Anzahl von unterschiedlichen
Plattformen implementiert sein, entsprechend den verschiedenen Ausführungsformen
der vorliegenden Erfindung. Diese Plattformen können ein IP-Gateway, ein Multimedia
Relay, ein Multimedia VSAT (Very Small Aperture Terminal) (Terminal
mit sehr kleiner Antennenapertur) und ein Personal Earth Station
(PES) Remote umfassen, wie in 8 bis 11 gezeigt. Allgemein
und wie in 2 diskutiert, definiert der PEP-Endpunkt 210 eine
lokale LAN-Schnittstelle 220, eine Schnittstelle, durch
die der PEP-Endpunkt 210 mit IP-Hosts verbunden ist, die
an dem Ort platziert sind. Eine WAN-Schnittstelle 230 ist
eine Schnittstelle, über
die der PEP-Endpunkt 210 mit anderen Orten verbunden ist.
Es ist anzumerken, dass eine WAN-Schnittstelle 230 physisch
ein LAN-Port sein kann. 8 bis 11 beschreiben
nachfolgend die spezifischen LAN- und
WAN-Schnittstellen der verschiedenen spezifischen PEP-Endpunkt-Plattformen.
Die bestimmten LAN- und WAN-Schnittstellen, die verwendet werden,
hängen ab
von den verwendeten PEP-Endpunkten am entfernten Ort, von der Konfiguration
des Hubs und der PEP-Endpunkte am entfernten Ort und von den Pfadauswahlregeln,
die konfiguriert sein können.
-
8 zeigt
die Schnittstellen des PEP-Endpunkts, der als IP-Gateway implementiert ist, entsprechend
einer Ausführungsform
der vorliegenden Erfindung. Beispielhaft hat ein IP-Gateway 801 eine einzelne
lokale LAN-Schnittstelle, die eine Unternehmensschnittstelle 803 ist.
Das IP-Gateway 803 verwendet zwei WAN- Schnittstellen 805 zum Senden und
Empfangen von IP-Paketen zu und von den PEP-Endpunkten am entfernten
Ort: Eine Backbone-LAN-Schnittstelle
und eine wide area access (WAA)-LAN-Schnittstelle.
-
Die
Backbone-LAN-Schnittstelle 805 wird verwendet, um IP-Pakete
zu PEP-Endpunkten am entfernten Ort zu senden über beispielsweise ein Satelliten-Gateway
(SGW) und eine VSAT-Outroute. Eine VSAT-Outroute kann direkt von
Multimedia Relays (9) und Multimedia VSATs (10)
empfangen werden (und ist der Hauptpfad, der mit diesen Endpunkten
verwendet wird); IP-Pakete können
jedoch zu einem PES Remote (11) über eine VSAT-Outroute gesendet
werden.
-
9 zeigt
eine Multimedia Relay-Implementierung eines PEP-Endpunkts entsprechend einer Ausführungsform
der vorliegenden Erfindung. Ein Multimedia Relay hat zwei oder drei
lokale LAN-Schnittstellen 903.
Ein Multimedia Relay 901 hat bis zu zwei WAN-Schnittstellen 905 zum
Senden von IP-Paketen zu den PEP-Endpunkten
auf der Hub-Seite: Eine seiner LAN-Schnittstellen und eine serielle
PPP-Schnittstelle, und vier oder fünf Schnittstellen zum Empfang
von IP-Paketen von den PEP-Endpunkten auf der Hub-Seite, einer VSAT
Outroute, alle LAN-Schnittstellen und eine serielle PPP-Schnittstelle.
Es ist anzumerken, dass eine serielle PPP(Punkt-zu-Punkt-Protokoll)-Schnittstelle und
eine LAN-Schnittstelle allgemein nicht gleichzeitig benutzt werden
sollen.
-
Ein
Multimedia Relay 901 unterstützt die Verwendung aller LAN-Schnittstellen 903 zur
gleichen Zeit, um IP-Pakete zu und von den PEP-Endpunkten auf der
Hub-Seite zu senden und zu empfan gen. Ferner unterstützt ein
Multimedia Relay 905 die Verwendung einer VADB (VPN Automatic
Dial Backup) seriellen Schnittstelle zum Senden und Empfangen von IP-Paketen
zu und von den PEP-Endpunkten auf der Hub-Seite.
-
10 zeigt
eine Multimedia VSAT-Implementierung des PEP-Endpunkts entsprechend einer Ausführungsform
der vorliegenden Erfindung. Ein Multimedia VSAT 1001 in
einer beispielhaften Ausführungsform
besitzt zwei lokale LAN-Schnittstellen 1003. Die Unterstützung für eine oder
mehrere lokale serielle PPP-Schnittstellen
kann verwendet werden. Der Multimedia VSAT 1001 besitzt
zwei WAN-Schnittstellen 1005 zum Senden von IP-Paketen
zu den PEP-Endpunkten auf der Hub-Seite: Eine VSAT inroute und eine
der LAN-Schnittstellen. Die Multimedia VSAT 1001 hat damit
drei Schnittstellen zum Empfang von IP-Paketen von den PEP-Endpunkten
auf der Hub-Seite, der VSAT outroute und beiden LAN-Schnittstellen 1003.
Eine Multimedia VSAT 1003 kann die Verwendung von beiden LRN-Schnittstellen 1003 zur
gleichen Zeit unterstützen,
um IP-Pakete zu und von den PEP-Endpunkten auf der Hub-Seite zu
senden und zu empfangen. Der Multimedia VSAT 1003 unterstützt ferner
die Verwendung einer VADB-seriellen Schnittstelle zum Senden und
Empfangen von IP-Paketen zu und von den PEP-Endpunkten auf der Hub-Seite.
-
11 zeigt
eine PES Remote Implementierung eines PEP-Endpunkts entsprechend
einer Ausführungsform
der vorliegenden Erfindung. Ein PES Remote 1101 kann eine
lokale LAN-Schnittstelle und/oder mehrere lokale IP (beispielsweise
PPP, SLIP, etc.) serielle Schnittstellen aufweisen, die gemeinsam
als LAN-Schnittstellen 1103 bezeichnet werden.
Die einzelnen LAN-Schnittstellen 1103 hängen von
der spezifischen PES Remote Plattform ab. PES Remote 1101 besitzt
in einer beispielhaften Ausführungsform
bis zu fünf
WAN-Schnittstellen 1105, um IP-Pakete zu den PEP-Endpunkten auf der Hub-Seite
zu senden, eine ISDN inroute, eine LAN-Schnittstelle, eine VADB
serielle Schnittstelle, eine Frame Relay serielle Schnittstelle
und eine IP serielle Schnittstelle, und bis zu fünf vorhandene Schnittstellen
zum Empfang von IP-Paketen von den PEP-Endpunkten auf der Hub-Seite:
eine ISBN outroute, eine LAN-Schnittstelle, eine VADB serielle Schnittstelle,
eine Frame Relay serielle Schnittstelle, und eine IP serielle Schnittstelle.
Die physische serielle Frame Relay-Schnittstelle kann mehrere Permanent
Virtual Circuits (PVCs) unterstützen;
einige davon sind äquivalent
zu lokalen Schnittstellen 1103 und einige davon sind WAN-Schnittstellen 1105.
-
12 zeigt
ein Diagramm eines TCB-Zugriffs über
eine TCB-Abbildungstabelle
entsprechend einer Ausführungsform
der vorliegenden Erfindung. Der TCB-Spoofing-Kern 280 entsprechend
einer Ausführungsform
der vorliegenden Erfindung benutzt zwei Typen von Steuerungsblöcken: TSK-Backbone-Verbindungssteuerungsblöcke (TCBs)
und TCP-Verbindungssteuerungsblöcke
(CCBs). TCBs werden verwendet, um Information betreffend Backbone-Verbindungen zu speichern,
die zu TSK-Partnern aufgebaut sind. CCBs werden verwendet, um Information
betreffend TCP-Verbindungen zu speichern, die von dem TSK 280 gespooft
werden. TCBs werden dem TCP-Spoofing-Kern 280 von der Plattformumgebung 210 bereitgestellt,
wenn Backbone-Verbindungen geöffnet
sind. TCBs werden vom TSK 280 an die Umgebung 210 zurückgegeben, wenn
die Backbone-Verbindungen geschlossen werden. Die Belegung und Freigabe
von TCBs wird von der Plattformumgebung 210 ausgeführt, um
die Verwendung einer Belegungsstrategie zu ermögli chen (beispielsweise dynamisch
gegenüber
statisch) passend für
die einzelne Plattform. Eine TCB-Abbildungstabelle 1201,
die vom TSK 280 erzeugt und aufrecht erhalten wird, wird
verwendet, um auf belegte TCBs 1203 zuzugreifen. Die Größe der Abbildungstabelle 1201 (und
die Anzahl der erforderlichen TCBs) wird von der Software bestimmt,
die in dem PEP-Endpunkt 210 eingebaut ist. Der TSK-Backbone-Verbindungs-Handle 1205,
der von der Plattformumgebung 210 bereitgestellt wird,
wird als Index in die Abbildungstabelle 1201 verwendet,
wobei der indizierte Tabelleneintrag auf den TCB 1203 zeigt.
-
Der
TCP-Spoofing-Kern 280 kann eine Anzahl von Backbone-Verbindungen
zu TSK-Partnern unterstützen,
wie von der einzelnen PEP-Endpunkt-Plattform-Software
bestimmt. Allgemein ist diese Anzahl gleich der Anzahl von Backbone-Verbindungen,
die die PEP-Endpunkt-Plattform
insgesamt unterstützt.
In einer beispielhaften Ausführungsform
unterstützen
alle internen Softwarekomponenten die gleiche Anzahl von Backbone-Verbindungen.
Da jedoch die Backbone-Verbindungen für Dinge außer TCP-Spoofing verwendet
werden können,
kann der TSK 280 weniger Backbone-Verbindungen unterstützen, als
durch den PEP-Endpunkt 210 insgesamt unterstützt sind.
Beim Start ruft die Plattformumgebung 210 den TSK 280 auf,
um Backbone-Verbindungen zu der Konfiguration des TCP-Spoofing-Kerns 280 hinzuzufügen. Für jede Backbone-Verbindung
liefert die Plattformumgebung 210 den Handle 1205,
den sie für
die Verbindung benutzen wird, der aus dem PEP-Endpunkt-Partner-Index und
der Priorität
der Verbindung erhalten wird.
-
Als
Teil dieser Konfiguration empfängt
ein PEP-Endpunkt 210 eine Liste von PEP-Endpunkt-Partnern,
mit denen der PEP-Backbone(PDP)-Verbindungen errichten soll. In
einer beispielhaften Ausführungsform
kann ein PEP-Endpunkt 501 auf der Hub-Seite bis zu 16.000
Partner haben, zu denen er Backbone-Verbindungen aufbauen soll.
Für jeden
PEP-Endpunkt-Partner werden Parameter geliefert, um für jede Priorität anzuzeigen,
ob eine Backbone-Verbindung
für die
gegebene Priorität erzeugt
werden soll. Beim Start durchläuft
die PEP-Endpunkt-Plattformumgebung 210 die Liste der Partner,
mit denen sie Backbone-Verbindungen errichten soll. Für jeden
Partner belegt die Umgebung 210 einen Partner-Index. Beim
PEP-Endpunkt 503 auf der entfernten Seite kann der Partner-Index
auf Null gesetzt werden (falls es nur einen Partner gibt). Bei einem
PEP-Endpunkt 501 auf der Hub-Seite ist der Partner-Index
der gleiche Index, der für
den Partner von einem IP Subnetz Hash 1207 zurückgegeben wird,
der verwendet wird, um zu bestimmen, ob ein Ziel-IP Subnetz als
nicht lokal bekannt ist. Der Partner-Index ist der gleiche Wert,
der von der PEP-Endpunkt 210 Routingfunktion verwendet
wird, um die Information zu finden, die tatsächlich verwendet wird, um IP-Pakete zu dem Ziel-IP-Subnet
zu senden. Die Plattformumgebung 210 belegt dann einen
Satz von Backbone-Verbindungs-Handles für den Partner, beispielsweise
indem für
den Partner-Index die höherwertigen
14 Bits des Handles verwendet werden und für die Priorität der Backbone-Verbindung
die zwei niederwertigen Bits.
-
Falls
das TCP-Spoofing global gesperrt ist, sind keine Backbone-Verbindungen
im TSK 82 oder BPK 282 geöffnet. Nach dem Start kann
die Plattformumgebung 210 den TSK 280 aufrufen,
um eine Backbone-Verbindung hinzuzufügen, die Parameter davon zu ändern oder
die Backbone-Verbindung zu löschen.
Wenn die Plattformumgebung 210 den TSK 280 ruft,
um eine Backbone-Verbindung zu öffnen (hinzuzufügen), liefert
die Umgebung 210 ein TCB für die Backbone-Verbindung.
Die Umgebung 210 belegt den TCB, um eine plattformspezifische
Speicherverwaltung des TCBs zu erlauben. Beispielsweise kann ein
IP-Gateway bis zu 16.000 PEP-Endpunkt-Partner auf der entfernten
Seite unterstützen (da
ein IP-Gateway momentan
bis zu 16.000 entfernte IP-Subnetze unterstützen kann) und 64.000 Backbone-Verbindungen.
Deshalb sind bis zu 64.000 TCBs erforderlich. Andererseits wird
ein Multimedia Relay, Multimedia VSAT oder PES Remote wahrscheinlich
nur einige wenige PEP-Endpunkt-Partner haben und damit nur wenige
TCBs. Deshalb ist die IP-Gateway-Implementierung der TCB-Verwaltung wohl
komplexer als die Implementierung der Multimedia Relay, Multimedia
VSRT oder PES Remote-Implementierung der TCB-Verwaltung.
-
Der
Handle 1205 wird von der Umgebung 210 an den TSK 280 gereicht
(2), wenn die Backbone-Verbindung referenziert
wird (entweder direkt oder mittels einer TCB-Verbindungs-CCB). Der Handle 1205 wird
ebenfalls zum TSK 280 über
den PEP-Backbone-Protokoll-Kern 282 gereicht, wann immer
eine TSK-Nachricht von der Backbone-Verbindung des Handles empfangen
wird. Der Handle wird ebenfalls verwendet als TSK-Backbone-Verbindungs-Identifizierer (TID),
der als Quellverbindungs-ID-Wert in den TSK-Nachrichten verwendet wird,
die an den TSK-Partner gesendet werden. Ein TCB 1203 wird
verwendet, um die Konfigurationsinformation zu speichern, die an
den TCB-Spoofing-Kern 280 von der Plattformumgebung 210 gereicht
wird über
die Backbone-Verbindung.
Er umfasst ebenfalls den aktuellen Zustand der Backbone-Verbindung
(EIN oder AUS) und einen Zeiger auf den Kopf oder das Ende der verlinkten
Liste der CCBs, die zu den TCP-Verbindungen gehört, die momentan die Backbone-Verbindung
benutzen. Zugriff auf die Liste der CCBs ist erforderlich, um die TCP-Verbindungen
zu finden, die betroffen sind, wenn die Backbone-Verbindungen fehlschlagen
oder gelöscht
werden.
-
Wie
zuvor erwähnt,
werden die Verbindungssteuerungsblöcke (CCBs) verwendet, um Information betreffend
die spezifischen TCP-Verbindungen zu speichern. CCBs werden von
der Plattformumgebung 210 verwaltet, da viele Details ihrer
Verwaltung plattformspezifisch sind. Die Plattformumgebung liefert
Mechanismen zum Belegen und Freigeben von CCBs und eine Funktion
zur Abbildung eines empfangenen TCP-Segments auf sein entsprechendes CCB.
Wenn ein TCP-Segment zu dem TCP-Spoofing-Kern 280 gereicht
wird, reicht die Umgebung 210 einen Zeiger auf die passende
CCB an den TSK zusammen mit dem TCP-Segment. Die Abbildung der empfangenen
TSK-Nachrichten auf CCBs wird jedoch vom TSK selbst durchgeführt.
-
Um
eine TCP-Verbindung zu spoofen, muss ein CCB in beiden TSK-Partnern verfügbar sein.
Idealerweise wird die Anzahl der CCBs groß genug sein, um zu gewährleisten,
dass alle TCP-Verbindungen, die der Operator spoofen möchte, gespooft
werden können.
In der Praxis können
Speicherbeschränkungen
einer PEP-Endpunkt-Plattform
die Anzahl der CCBs begrenzen, so dass gelegentlich eine TCP-Verbindung
nicht gespooft werden kann, da kein CCB verfügbar ist. Wenn eine TCP-Verbindung, die
gespooft werden sollte, nicht gespooft werden kann aufgrund des
Fehlens eines CCB, wird eine geeignete Statistik erhöht und die
TCP-Verbindung wird ungespooft
getragen. Die TSK-Partner tauschen Information über die Anzahl für gespoofte
TCP-Verbindungen verfügbaren
CCBs aus, indem eine bestimmte Backbone-Verbindung beim Start verwendet
wird (und wann immer Parameter sich ändern oder die Backbone-Verbindung
neu startet) über
die TSK-Partner- Parameter-Nachrichten.
Der kleinere Wert der zwei TSK-Partner wird dann als Grenzwert für die Backbone-Verbindung
verwendet. Beide TSKs verfolgen die Anzahl der CCBs, die momentan belegt
sind (pro Backbone-Verbindung). Falls eine neue TCP-Verbindung erfasst
wird, aber die aktuelle Anzahl von belegten CCBs (für diese
Backbone-Verbindung) an ihrem "verhandelten" Limit ist, behandelt der
TCP-Spoofing-Kern 280 die Verbindung, als wäre kein
CCB verfügbar
(selbst wenn einer verfügbar
wäre).
Aufgrund der Ausbreitungsverzögerung
oder weil der PEP-Endpunkt sein Pool von CCBs unter all seinen Partnern
teilt, ist es für
ein CCB möglich,
verfügbar
zu sein, wenn ein TCP <SYN>-Segment von einem
TCP-Spoofing-Kern 280 empfangen wird, aber für ein entsprechendes
CCB an dem TSK-Partner nicht verfügbar ist.
-
Im
Gegensatz zu TCBs 1203, auf die über die TCB-Abbildungstabelle 1201 für TCP-Segmente zugegriffen
werden können,
die von dem lokalen LAN empfangen werden und für TSK-Nachrichten, die von einer
Backbone-Verbindung empfangen werden, erfordern Verbindungssteuerungsblöcke unterschiedliche
Messmechanismen, um über
TCP-Segmente gegenüber
TSK-Nachrichten zugreifbar zu sein. CCBs, die momentan nicht mit
einer TCP-Verbindung verknüpft
sind, werden von der Plattformumgebung 210 in einem CCB-Frei-Pool gespeichert.
-
Freie
CCBs werden gespeichert, indem ein oder zwei plattformabhängige Verfahren
eingesetzt werden. Das erste Verfahren ist ein Pool von Speicher,
aus dem CCBs erzeugt werden, indem eine Malloc()-Funktion oder ein Äquivalent
verwendet wird. Mit diesem Verfahren wird die Anzahl der freien CCBs
einfach numerisch überwacht
oder über
die Anzahl des Pufferplatzes, der zur Verwendung beim Erzeugen von
CCBs gesetzt wird. CCBs werden an den freien Pool zurückgegeben,
indem eine Free()-Funktion oder ein Äquivalent verwendet wird. Das
zweite Verfahren betrifft das Mittel einer FIFO-Warteschlange. Bei
diesem Verfahren werden alle CCBs beim Plattformstart erzeugt und
dann miteinander verkettet, indem sie ihre "Nächster CCB"-Zeiger verwendet
wird. Ein CCB wird belegt, indem es aus dem Kopf der FIFO-Warteschlange entfernt
wird und ein CCB wird freigegeben, indem es an das Ende der FIFO-Warteschlange
gesetzt wird. Ein CCB, das mit einer TCP-Verbindung verknüpft ist, wird
als aktiv betrachtet.
-
13 zeigt
ein Diagramm eines CCB-Zugriffs über
eine CCB-Hash-Funktion
entsprechend einer Ausführungsform
der vorliegenden Erfindung. Aktive CCBs werden auf zwei Weisen bezeichnet. Zum
Abbilden von TSK-Nachrichten, die von ihrem TSK-Partner empfangen
werden, auf CCBs, verwendet TSK 280 eine CCB-Abbildungstabelle 1301.
Die CCB-Abbildungstabelle 1301 wird ebenfalls von TSK 280 in
einer Round-Robin-Weise verwendet, um auf CCBs zuzugreifen, um auf
TCP-Verbindungszeitunterbrechungen zu prüfen. Zum Abbilden der TCP-Segmente,
die von dem lokalen Host empfangen werden, auf CCBs wird eine CCB-Hash-Funktion 1303 verwendet,
um die CCB-Zeiger zu finden. Die CCB-Hash-Funktion 1303 wird
ebenfalls verwendet in einigen Fällen,
um CCBs 1305 für
empfangene TSK-Nachrichten zu finden, wenn die CCB-Abbildungstabelle 1301 nicht
verwendet werden kann.
-
Wenn
ein TCP-Segment von dem lokalen LAN empfangen wird, wird die CCB
Hash-Funktion 1303 verwendet, um das CCB zu bestimmen,
das mit der TCP-Verbindung des Segments verknüpft ist. Die Hash-Funktion 1303 erzeugt
einen Index in die CCB Hash-Tabelle 1301. Die CCB Hash-Tabelle 1301 zeigt
zu einer doppelverlinkten Liste von CCBs 1305, die auf
den Hash-Wert passen. Jeder CCB 1305 umfasst ein „nächstes CCB"-Zeigerfeld und ein
vorhergehendes CCB-Zeigerfeld, die von der Plattformumgebung 210 verwendet
werden, um die doppelverlinkte Liste beispielsweise zu implementieren.
Eine doppelverlinkte Liste wird eingesetzt, um ein Entfernen von
CCBs aus der Mitte einer Hash-Funktionskette wirksam zu unterstützen.
-
Das
Aufrechterhalten der CCB-Zeiger, die von der Hash-Funktion 1303 verwendet
werden, liegt in der Verantwortlichkeit der Plattformumgebung 1303.
Die Plattformumgebung 210 reicht einfach einen Zeiger auf
die richtige CCB 1305 an den TCP Spoofing-Kern 280 zusammen
mit einem TCP-Segment, das sie an den TSK 280 reicht. Die
Umgebung 210 stellt ebenfalls eine Funktionsaufrufschnittstelle bereit,
dessen TSK 280 aufrufen kann, die Hash-Funktion 1303 selbst
zu benutzen. Diese Schnittstelle wird von dem TSK 280 verwendet,
um ein CCB zu finden, indem die Information in dem TCP-Verbindungsheader
einer empfangenen TSK-Nachricht
verwendet wird. Die Tatsache, dass die Plattformumgebung 210 verantwortlich
ist für
die Verwaltung der CCB Hash-Tabelle 1301,
zeigt an, dass die Umgebung 210 Zugriff auf einige der
Felder in dem CCB 1305 haben muss. Um die Umgebung davon
frei zu halten, das gesamte Format des CCB 1305 zu kennen,
werden die Felder in dem CCB, auf die von der Umgebung 210 zugegriffen
wird, an den Anfang des CCB 1305 gesetzt. Die Umgebung 210 ist
verantwortlich für
das Aufrechterhalten der nachfolgenden CCB-Felder: der nächste und
der vorhergehende CCB-Zeiger;
die IP-Adressen und die TCP-Portnummern, die eindeutig die TCP-Verbindung
identifizieren; und der Backbone-Verbindungshandle, der verwendet
wird, um auf das TCP der Backbone-Verbindung abzubilden, die verwendet wird,
um diese gespoofte TCP-Verbindung zu tragen, das heißt das TID
des Partners. Der nächste
und der vorhergehende CCB-Zeiger können von der Plattformumgebung 210 in
einem Header gehalten werden, der an das CCB vorgestellt wird, um
sie vom TSK 280 zu verstecken. Die TCP Verbindungs-IP-Adressen und
Portnummern und das TID werden in das CCB 1305 durch die
Umgebung 210 geschrieben. TSK 280 liest diese
Werte aus dem CCB 1305 aber schreibt diese Werte nicht
in das CCB 1305.
-
Allgemein
werden die IP-Adressen und TCP-Portnummern der empfangenen TCP-Segmente
als Eingang in die CCB Hash-Funktion 1303 verwendet. Allerdings
ist die verwendete Hash-Funktion 1303 plattformspezifisch.
Da eine große
Anzahl von TCP-Verbindungen zu unterschiedlichen entfernten Orten
unterstützt
werden kann, benötigt
beispielsweise die IP-Gateway-Hash-Funktion 1303, dass
der Subnetzabschnitt der IP-Adressen besonders beachtet wird. Der
Subnetzabschnitt der IP-Adressen ist jedoch etwa gleich für alle TCP-Verbindungen,
die mit einem bestimmten entfernten Ort verknüpft sind. Deshalb muss einer
Plattformumgebung an einem entfernten Ort mehr Beachtung im Hinblick
auf den Host-Teil der IP-Adressen gegeben werden.
-
CCBs
werden belegt und freigegeben von dem TCP Spoofing-Kern 280 über Funktionsaufrufe zu
der Plattformumgebung 210. Die CCB-Abbildungstabelle 1301,
die vom TSK 280 erzeugt und aufrechterhalten wird, wird
eingesetzt, um auf CCBs zuzugreifen zum Zwecke der Zeitverarbeitung
und wenn TSK-Nachrichten von dem PEP Backbone-Protocol-Kern 282 empfangen
werden. Eine einzelne Abbildungstabelle 1301 wird verwendet,
um alle TSK-Partner
zu unterstützen.
Die Größe der Abbildungstabelle 1301 (und
die Anzahl der benötigten CCBs)
wird von der eingebauten Software des PEP-Endpunkts 210 bestimmt.
Bei einem vorgegebenen PEP-Endpunkt 210 sollte die Anzahl
der Einträge
in die Abbildungstabelle 1301 und die Gesamtanzahl der
verfügbaren
CCBs 1305 gleich sein, da TSK 280 kein CCB verwenden
kann, das es nicht über
die Abbildungstabelle 1301 erreichen kann, und TSK 280 benötigt keine
Abbildungstabelleneinträge, in
die es keine CCBs eintragen kann. Zu einer beispielhaften Ausführungsform
umfasst jeder Eintrag in der Abbildungstabelle 1301 zwei
Felder: einen CCB-Zeiger und einen Nächster-Eintrag-Index. Der Nächste-Eintrag-Index
wird verwendet, um eine verlinkte Liste von CCBs zu implementieren.
Ein Indexwert von 0xFFFF wird als äquivalent für einen NULL-Zeiger verwendet.
Zwei Typen von verlinkten Listen werden aufrechterhalten, indem
der Nächste-Eintrag-Index verwendet
wird: eine freie Eintragsliste und eine aktive CCB-Liste. Die freie
Eintragsliste speichert die Liste der freien Abbildungstabelleneinträge. TSK 280 hält einen
Zeiger auf den Anfang und das Ende der Liste aufrecht und verwendet
diese Zeiger, um eine FIFO-Warteschlange mit freien Einträgen zu implementieren.
Wenn ein neues CCB belegt wird, wird ebenfalls ein Eintrag aus der
freien Eintragsliste belegt. TSK 280 verwendet den Index
des Abbildungstabelleneintrags als lokales TCP CID der TCP-Verbindung.
Wenn ein CCB freigegeben wird, wird der Abbildungstabelleneintrag
des CCBs an die freie Liste zurückgegeben.
-
Aktive
CCB-Listen werden verwendet, um die CCBs von aktiven TCP-Verbindungen
miteinander zu verketten. Die CCBs 1305 aller TCP-Verbindungen,
die mit einer einzelnen Backbone-Verbindung geteilt werden, werden
miteinander verkettet bzw. verknüpft.
Die Indices für
den ersten und den letzten Eintrag der CCB verlinkten Liste einer
Backbone-Verbindung werden mit dem Back bone-Verbindungszustand in
dem TCP gespeichert, der der Backbone-Verbindung zugeordnet ist.
(Obgleich die aktiven CCB-Listen als einzelverknüpfte Listen implementiert beschrieben
werden, um den CCB-Abbildungstabellenplatz 1301 zu sparen,
können
alternativ doppelverlinkte Liste implementiert werden, um ein einfaches
Entfernen von Einträgen
aus der Mitte der Liste zu ermöglichen.
-
Aktive
CCB-Listen werden für
eine Reihe von Zwecken benutzt. Die CCB-Listen werden erstens dazu
benutzt, alle CCBs 1305 zu finden, die von einem Fehler
oder einem Löschen
einer Backbone-Verbindung
beeinflusst werden. Wenn eine Backbone-Verbindung ausfällt oder
gelöscht
wird, müssen
alle TCP-Verbindungen, die von der Backbone-Verbindung verwendet
werden, beendet werden. Ein anderer Zweck besteht darin, das geeignete CCB
zu finden, wenn eine TSK-Nachricht empfangen wird mit einem Ziel
TCP CID-Wert von
0xFFFF aber ohne einen TCP-Verbindungsheader. Für den letztgenannten Fall durchquert
der TSK 280 die CCB-Liste der Backbone-Verbindung, aus
der die TSK-Nachricht empfangen wurde und sucht nach einem CCB 1305 mit
einem Partner CID, das gleich der Quellverbindungs-ID in der TSK-Nachricht
ist. Ein CCB 1305, das aus seiner aktiven CCB-Liste entfernt
ist, wenn der CCB 1305 freigegeben wird.
-
14 zeigt
ein Diagramm einer CCB-Abbildungstabelle entsprechend einer Ausführungsform der
vorliegenden Erfindung. Wie zuvor diskutiert, wird ein CCB belegt,
wenn eine TCP-Verbindung erfasst wird, die gespooft werden soll.
Der TCP Spoofing-Kern 280 belegt einen freien Eintrag aus
der CCB-Abbildungstabelle 1301 und ruft dann die Plattformumgebung 210 auf,
das CCB zu belegen, indem die IP-Adressen und TCP-Portnummern geliefert werden,
die die Verbindung eindeutig identifizieren. Die Plattformumgebung 210 belegt
ein CCB aus dem freien CCB-Pool und verwendet die gelieferten IP-Adressen
und Portnummern, um den richtigen Hash-Table-Eintrag für das CCB
zu bestimmen. Der CCB-Zeiger
wird dann zu der Hash-Tabelle 1301 hinzuaddiert (an das
Ende eines bestehenden CCBs angehängt, der bereits aus diesem
Hash-Tabelleneintrag abgebildet ist im Falle einer Hash-Tabellenkollision).
Schließlich
füllt die
Umgebung 210 den TCB-Indexwert
des CCBs ein, bevor der CCB zurück zum
TSK 280 gereicht wird. Wenn der TSK 280 das CCB 1305 empfängt, verwendet
der TSK 280 den TCB-Index in dem CCB, um den TCB zu finden.
Der CCB 1305 wird dann in die aktive CCB-Liste für die Backbone-Verbindung verknüpft, die
der Priorität
der TCP-Verbindung zugeordnet ist. Wenn ein CCB 1305 für eine neue
TCP-Verbindung belegt wird, die von dem lokalen LAN erfasst wird, überprüft zuerst
der TSK 280, um sicherzustellen, dass die Backbone-Verbindung auf ist,
bevor tatsächlich
der CCB 1305 in das CCB-Abbildungsarray
gesetzt wird. Falls die Backbone-Verbindung zu ist, kann die Verbindung
nicht gespooft werden und der CCB 1305 für die Verbindung
wird an die Umgebung 210 zurückgegeben. Wenn ein CCB 1305 freigegeben
wird, wird er aus der Warteschlange seiner aktiven CCB-Liste herausgenommen,
sein CCB-Abbildungstabelleneintrag
wird an die freie Eintragsliste zurückgegeben und der CCB 1305 wird
an die Umgebung 210 zurückgegeben.
Die Umgebung 210 entfernt wiederum das CCB 1305 aus
der CCB Hash-Tabelle 1301 und gibt das CCB 1301 an
den freien CCB-Pool
zurück.
-
Die
Gesamtanzahl der CCBs 1305, die in einer PEP-Endpunktplattform 210 verfügbar sind,
ist konfigurierbar. Der Wert kann im Hinblick auf die Anzahl der
CCBs spezifiziert sein, die pro PEP-Endpunktpartner verfügbar sind,
als Teil eines PEP-Endpunktprofils. Allerdings besitzt jede PEP-Endpunktplattform-Software
eine gewisse maximale Anzahl von CCBs, die unterstützt werden
können.
Zwei Modelle des CCB-Poolhandlings
können
verwendet werden: ein geteiltes CCB-Poolmodell und ein dediziertes CCB-Poolmodell.
Das geteilte Modell umfasst das Teilen des CCB-Pools unter allen
Partnern, während
das dezidierte Modell einen einzelnen CCB-Pool pro Partner bereitstellt.
Unter dem dezidierten CCB-Poolmodell wird die kleinere Anzahl verwendet,
falls der Operator die Anzahl der CCBs 1305 größer als
die Anzahl konfiguriert, die von der Software unterstützt wird.
Mit Bezug auf das geteilte Modell kann der Operator anfänglich das
Pro-Partner-CCB-Limit derart konfigurieren, dass ein Multiplizieren
des Limits durch die Anzahl der Partner mehr CCBs erfordern würde als
tatsächlich
existierten, um die Leistung zu verbessern, indem die CCBs statistisch
geteilt werden. Ist die Anzahl der CCBs in einem PEP-Endpunkt konfigurierbar,
kann der Operator den Punkt steuern, an dem TCP-Verbindungen aufhören, gespooft
zu werden. Die gesamte Zahl von TCP-Verbindungen, die von dem System
getragen werden, kann einen Punkt erreichen, an dem die Gesamtzahl der
Bandbreite dividiert durch die Anzahl der TCP-Verbindungen, die
aktiv benutzt werden, geringer ist als der mögliche Durchsatz für jede TCP-Verbindung
ohne TCP-Spoofing. Deshalb kann der Operator wünschen, dass die Anzahl der
CCBs so eingestellt wird, dass das Spoofen nur auftritt, wenn die Leistung
verbessert wird.
-
(Allerdings
ist eine TCP-Spoofing-Leistungsverbesserung nicht begrenzt auf nur
hohe Datendurchsätze.
TCP-Spoofing kann ein Spoofen des TCP-Drei-Wege-Handshakes umfassen.
Abhängig von
den benutzten Anwendungen kann der Operator entscheiden, dass das
Spoofen des Drei-Wege-Handshakes nützlich ist, selbst wenn der
Durchsatz durch das Vorhandensein oder großen Anzahl von TCP-Verbindungen begrenzt
ist. Für
gespoofte TCP-Verbindungen, wenn Ressourcen (beispielsweise Pufferplatz)
gering sind, kann zusätzlich
eine Steuerung des Stroms auf die gespooften TCP-Verbindungen (durch Schrumpfen der TCP-Fenster,
die von dem PEP-Endpunkt angegeben werden) angewendet werden. (Dies
ist nicht für
ungespoofte TCP-Verbindungen möglich.)
Zusätzlich
zu der Gesamtzahl der PEP-Endpunkt-CCBs kann der Operator auch den
Prozentsatz der verfügbaren
CCBs konfigurieren, die mit jeder Prioritäts-Backbone-Verbindung verwendet
werden können.
Dies ermöglicht, dass
der Operator CCBs zur Benutzung durch TCP-Verbindungen höherer Priorität reserviert.
-
15 zeigt
die Abbildung bzw. das Mapping zwischen CCBs und TCBs entsprechend
einer Ausführungsform
der vorliegenden Erfindung. Wenn ein TCP-Segment von dem lokalen
LAN empfangen wird, verwendet die Plattformumgebung 210 die
CCB Hash-Funktion 1303, um den CCB zu finden, der der TCP-Verbindung
zugeordnet ist, und gibt einen Zeiger auf dieses CCB 1305 an
den TCP Spoofing-Kern 280 zusammen
mit dem TCP-Segment weiter. Ein Index in die TCB-Abbildungsgruppe,
die in dem CCB gespeichert ist, wird dann von dem TSK 280 verwendet,
wenn es notwendig ist, das TCB 1203 zu refenzieren, das
mit der Backbone-Verbindung verknüpft ist, die zum Spoofen der
TCP-Verbindung benutz wird. Für
ein TCP-Segment,
das von dem lokalen LAN empfangen wird, braucht das TSK 280 zunächst nicht
auf das TCB 1203 zuzugreifen, um das 1305 der
Verbindung zu finden. Wenn eine TSK-Nachricht von dem Backbone-Protocol-Kern 282 vom
TSK 280 empfangen wird, extrahiert TSK 280 die Ziel-TCP-CID
aus der TSK-Nachricht. Falls die TCP CID nicht 0xFFFF ist, stellt
es den CCB-Abbildungstabellenindex für das CCB dar, das mit der
TCP-Verbindung der TSK-Nachricht
verknüpft
ist. Falls das TCP CID 0xFFFF ist, muss TSK 280 festlegen,
ob ein neues TCP CID erforderlich ist (da die TSK-Nachricht eine
Connection-Request-Nachricht ist), falls die Nachricht zu einer
existierenden TCP-Verbindung gehört,
für die
der TSK-Partner noch kein TCP CID empfangen hat, oder falls die
Nachricht verworfen werden soll, da keiner der vorherigen zwei Bedingungen
anwendbar ist. TSK überprüft zunächst die Nachricht,
um zu sehen, ob es einen TCP-Verbindungsheader gibt, der in der
Nachricht enthalten ist. Falls ein TCP-Verbindungsheader enthalten
ist, verwendet TSK die Information in dem TCP-Verbindungsheader als Eingang in die
CCB Hash-Funktion, um den CCB zu finden. Falls kein TCP-Verbindungsheader
in der Nachricht enthalten ist, durchsucht TSK 280 die
Liste der aktiven CCBs, die momentan der Backbone-Verbindung zugeordnet
ist, von der die Nachricht empfangen wurde, sucht nach einer Übereinstimmung
mit der Quell-TCP CID in der TSK-Nachricht. BPK gibt den Handle,
der zum Auffinden des geeigneten TCB erforderlich ist, an TSK weiter,
wenn es die TSK-Nachricht an TSK leitet.
-
16 zeigt
ein Computersystem 1601, auf dem eine Ausführungsform
gemäß der vorliegenden Erfindung
implementiert sein kann. Ein solches Computersystem 1601 kann
als Server konfiguriert sein, um Code auszuführen, der die PEP-Funktionen
des PEP-Endpunkts 210, die zuvor diskutiert wurden, ausführt. Das
Computersystem 1601 umfasst einen Bus 1603 oder
einen anderen Kommunikationsmechanismus zur Kommunikation von Information,
und einen Prozessor 1605, der mit einem Bus 1603 zur Verarbeitung
der Information verbunden ist. Das Computersystem 1601 umfasst
ebenfalls einen Hauptspeicher 1607, wie beispielsweise einen
Speicher mit wahlfreiem Zugriff (RAM) oder eine andere dynamische
Speichervorrichtung, die mit dem Bus 1603 zum Speichern
von Information und Befehlen verbunden ist, die auf dem Prozessor 1605 ausgeführt werden
sollen. Zusätzlich
kann der Hauptspeicher 1607 zum Speichern temporärer Variablen
oder anderer Zwischeninformation während der Ausführung von
Instruktionen bzw. Befehlen verwendet werden, die von dem Prozessor 1605 ausgeführt werden sollen.
Es ist anzumerken, dass die PEP-Steuerungsblöcke in dem
Hauptspeicher 1607 gespeichert werden können. Das Computersystem 1601 umfasst ferner
einen Nur-Lesespeicher
(ROM) 1609 oder eine andere statische Speichervorrichtung,
die mit dem Bus 1603 zum Speichern von statischer Information
und von Befehlen für
den Prozessor 1605 verbunden ist. Eine Speichervorrichtung 1611,
wie beispielsweise eine Magnetplatte oder eine optische Platte sind
vorgesehen und mit dem Bus 1603 zum Speichern der Information
und der Befehle verbunden.
-
Das
Computersystem 1601 kann über einen Bus 1603 mit
einer Anzeige 1613 verbunden sein, wie beispielsweise eine
Kathodenstrahlröhre
(CRT), um Information einem Computerbenutzer darzustellen. Eine
Eingabevorrichtung 1615 einschließlich alphanumerischer und
anderer Tasten, ist mit dem Bus 1603 verbunden, um Information
und eine Befehlsauswahl an den Prozessor 1605 zu kommunizieren. Eine
andere Art von Benutzereingabevorrichtung ist die Cursorsteuerung 1617,
wie beispielsweise eine Maus, ein Trackball oder Cursor-Richtungstasten zum Übertragen
der Richtungsinformation und Befehlsauswahlen an einen Prozessor 1605 und
zum Steuern der Cursorbewegung auf der Anzeige 1613.
-
Ausführungsformen
werden auf die Benutzung des Computersystems 1601 bezogen,
um die PEP-Funktionen des PEP-Endpunkts 210 auszuführen. Entsprechend
einer Ausführungsform
ist dieser automatische Aktualisierungslösungsweg von dem Computersystem 1601 bereitgestellt
in Antwort auf den Prozessor 1605, der eine oder mehrere
Sequenzen einer oder mehrerer Befehle ausführt, die in dem Hauptspeicher 1607 enthalten
sind. Solche Befehle können
in den Hauptspeicher 1607 aus einem anderen computerlesbaren
Medium gelesen werden, wie beispielsweise eine Speichervorrichtung 1611.
Das Ausführen
der Sequenzen von Befehlen, die im Hauptspeicher 1607 enthalten
sind, bringen den Prozessor 1605 dazu, die Prozessschritte
auszuführen, die
zuvor beschrieben wurden. Einer oder mehrere Prozessoren in einer
Multiprozessoranordnung können
ebenfalls eingesetzt werden, um die Befehlssequenzen auszuführen, die
in dem Hauptspeicher 1607 enthalten sind. Bei einer alternativen
Ausführungsform
kann stattdessen eine hartverdrahtete Schaltung auch in Kombination
mit Softwarebefehlen eingesetzt werden. Somit sind Ausführungsformen nicht
beschränkt
auf irgendeine spezifische Kombination aus Hardwareschaltung und
Software.
-
Der
Begriff „computerlesbares
Medium", wie er
hier verwendet wird, betrifft ein Medium, das beim Bereitstellen
von Befehlen an den Prozessor 1605 zur Ausführung der
PEP-Funktionen am PEP-Endpunkt 210 teilnimmt.
Ein solches Medium kann in vielen Formen vorliegen, einschließlich aber
nicht beschränkt
auf nichtflüchtige
Medien, flüchtige
Medien und Übertragungsmedien.
Nicht-flüchtige
Medien umfassen beispielsweise optische oder magnetische Platten,
wie beispielsweise die Speichervorrichtung 1611. Flüchtige Medien
umfassen dynamische Speicher, wie beispielsweise der Hauptspeicher 1607. Übertragungsmedien
umfassen Koaxialkabel, Kupferdrähte
und Glasfaser einschließlich
Drähten,
die den Bus 1603 umfassen. Übertragungsmedien können ebenfalls
die Form von akustischen Wellen oder Lichtwellen annehmen, wie jene,
die mit Radiowellen und Infrarotdatenkommunikationen erzeugt werden.
-
Allgemeine
Formen computerlesbarer Medien umfassen beispielsweise eine Floppy-Disk,
eine flexible Disk, eine Festplatte, ein Magnetband oder jedes andere
magnetische Medium, eine CD-ROM, jedes
andere optische Medium, Lochkarten, Papierbänder, jegliches andere physikalische
Medium mit Lochmuster, RAM, PROM und EPROM, FLASH-EPROM, jeglichen
anderen Speicherchip oder Speicherkarte, Trägerwellen wie nachfolgend erläutert, oder
jegliches andere Medium, von dem ein Computer lesen kann.
-
Verschiedene
Formen computerlesbarer Medien können
beim Tragen einer oder mehrerer Sequenzen eines oder mehrerer Befehle
zu dem Prozessor 1605 zur Ausführung beteiligt sein. Beispielsweise
können
Befehle anfänglich
auf einer Magnetplatte für
einen entfernten Computer gehalten werden. Der entfernte Computer
kann die Befehle betreffend die Ausführung der PEP-Funktionen des PEP-Endpunkts 210 in
seinem dynamischen Speicher laden und die Befehle über eine
Telefonleitung übertragen,
in dem ein Modem verwendet wird. Ein Modem, das lokal am Computersystem 1601 ist, kann
die Daten auf der Telefonleitung empfangen und einen Infrarotsender
benutzen, um die Daten in ein Infrarotsignal umzuwandeln. Ein Infrarotdetektor, der
mit dem Bus 1603 verbunden ist, kann die Daten empfangen,
die vom Infrarotsignal getragen werden und kann die Daten auf den
Bus 1603 bringen, Der Bus 1603 trägt die Daten
zu dem Hauptspeicher 1607, von dem der Prozessor 1605 die
Befehle erhält und
ausführt.
Die Befeh le, die durch den Hauptspeicher 1607 empfangen
werden, können
optional in einer Speichervorrichtung 1611 entweder vor
oder nach der Ausführung
durch den Prozessor 1605 gespeichert werden.
-
Das
Computersystem 1601 umfasst ebenfalls ein oder mehrere
Kommunikationsschnittstellen 1619, die mit dem Bus 1603 verbunden
sind. Kommunikationsschnittstellen 1619 liefern eine Zwei-Wege-Datenkommunikationsverbindung
zu den Netzwerkverbindungen 1621 und 1622, die
mit einem Local-Area-Network (LAN) 1623 beziehungsweise
einem Wide-Area-Network (WAN) 1624 verbunden sind. Das
WAN 1624 entsprechend einer Ausführungsform der vorliegenden
Erfindung kann ein Satellitennetzwerk sein. Die Kommunikationsschnittstelle 1619 kann
in einer Netzwerkschnittstellenkarte sein, die in jedem paketvermittelten
LAN angebracht ist. In einem anderen Beispiel kann die Kommunikationsschnittstelle 1619 eine
Asymmetrical-Digital-Subscriber-Line (ADSL)-Karte sein, eine Integrated-Services-Digital-Network
(ISDN)-Karte, ein Kabelmodem oder ein Modem, um eine Datenkommunikationsverbindung über einen
entsprechenden Typ von Telefonleitung bereitzustellen. Drahtlose
Verbindungen können
ebenfalls implementiert werden. In jeder Implementierung sendet
die Kommunikationsschnittstelle 1619 elektrische, elektromagnetische oder
optische Signale und empfängt
diese, wobei die Signale digitale Datenströme tragen, die verschiedene
Typen von Information darstellen.
-
Die
Netzwerkverbindung 1621 stellt typischerweise eine Datenkommunikation über ein
oder mehrere Netzwerke zu anderen Datenvorrichtungen bereit. Beispielsweise
kann die Netzwerkverbindung 1621 eine Verbindung über ein
Local-Area-Network 1623 zu einem Host-Computer 1625 bereitstellen oder
zu einem Datengerät,
das von einem Internet-Service-Provider (ISP) 1627 betrieben
wird. ISP 1627 wiederum stellt Datenkommunikationsdienstleistungen über das
Internet 505 bereit. Zusätzlich wird das LAN 1623 mit
einem Intranet 1629 verbunden. Das Intranet 1629,
das LAN 1623 und das Internet 505 verwenden alle
elektrische, elektromagnetische oder optische Signale, die digitale
Datenströme tragen.
Die Signale durch die verschiedenen Netzwerke und die Signale auf
der Netzwerkverbindung 1621 und durch Kommunikationsschnittstellen 1619, die
die digitalen Daten zu und von dem Computersystem 1601 tragen,
sind beispielhafte Formen von Trägerwellen,
die Information transportieren.
-
Das
Computersystem 1601 kann Nachrichten senden und Daten empfangen,
einschließlich Programmcode, über das
Netzwerk/die Netzwerke, die Netzwerkverbindung 1621 und
die Kommunikationsschnittstelle 1619. In dem Internet-Beispiel
könnte
ein Server 1631 einen angeforderten Code für ein Anwendungsprogramm über das
Internet 505, den ISP 1627, das LAN 1623 und
die Kommunikationsschnittstelle 1619 senden. Der empfangene
Code kann von dem Prozessor 1605 ausgeführt werden, wenn er diesen
empfängt,
und/oder in der Speichervorrichtung 1611 gespeichert werden,
oder einem anderen nicht-flüchtigen
Speicher zur späteren
Ausführung.
Auf diese Weise kann das Computersystem 1601 Anwendungscode
in Form von Trägerwellen
erhalten. Das Computersystem 1601 kann Meldungen senden
und Daten empfangen, einschließlich
Programmcode, über
das Netzwerk/die Netzwerke, die Netzwerkverbindung 1621 und
die Kommunikationsschnittstelle 1619.
-
Die
hier beschriebenen Techniken bieten viele Vorteile gegenüber bekannten
Lösungen,
um die Netzwerkleistung zu verbessern, insbesondere in einem paketvermittelten
Netzwerk, wie dem Internet. Ein lokaler PEP-Endpunkt und ein entfernter PEP-Endpunkt kommunizieren,
um den Austausch von Daten über
eine TCP-Spoofing-Funktionalität
zu optimieren. Diese Anordnung verbessert vorteilhafterweise die
Leistung des Kommunikationsnetzwerks.
-
Offensichtlich
sind verschiedene Modifikationen und Variationen der vorliegenden
Erfindung im Lichte der vorherigen Lehren möglich. Es versteht sich deshalb,
dass die Erfindung innerhalb des Umfangs der angehängten Ansprüche ausgeführt werden
kann, auch anders als hier speziell beschrieben.