DE60114097T2 - Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies - Google Patents

Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies Download PDF

Info

Publication number
DE60114097T2
DE60114097T2 DE60114097T DE60114097T DE60114097T2 DE 60114097 T2 DE60114097 T2 DE 60114097T2 DE 60114097 T DE60114097 T DE 60114097T DE 60114097 T DE60114097 T DE 60114097T DE 60114097 T2 DE60114097 T2 DE 60114097T2
Authority
DE
Germany
Prior art keywords
connection
tcp
spoofing
internet protocol
tsk
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60114097T
Other languages
English (en)
Other versions
DE60114097D1 (de
Inventor
John Poolesville Border
Ken Burrell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hughes Network Systems LLC
Original Assignee
Hughes Network Systems LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hughes Network Systems LLC filed Critical Hughes Network Systems LLC
Publication of DE60114097D1 publication Critical patent/DE60114097D1/de
Application granted granted Critical
Publication of DE60114097T2 publication Critical patent/DE60114097T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5019Ensuring fulfilment of SLA
    • H04L41/5022Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/14Relay systems
    • H04B7/15Active relay systems
    • H04B7/185Space-based or airborne stations; Stations for satellite systems
    • H04B7/18578Satellite systems for providing broadband data service to individual earth stations
    • H04B7/18582Arrangements for data linking, i.e. for data framing, for error recovery, for multiple access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B7/00Radio transmission systems, i.e. using radiation field
    • H04B7/14Relay systems
    • H04B7/15Active relay systems
    • H04B7/185Space-based or airborne stations; Stations for satellite systems
    • H04B7/18578Satellite systems for providing broadband data service to individual earth stations
    • H04B7/18584Arrangements for data networking, i.e. for data packet routing, for congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/046Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0823Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/083Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for increasing network speed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0896Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/30Routing of multiclass traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • H04L45/306Route determination based on the nature of the carried application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • H04L45/308Route determination based on user's profile, e.g. premium users
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433Allocation of priorities to traffic types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2491Mapping quality of service [QoS] requirements between different networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/40Flow control; Congestion control using split connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/901Buffering arrangements using storage descriptor, e.g. read or write pointers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9042Separate storage for different parts of the packet, e.g. header and payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9084Reactions to storage capacity overflow
    • H04L49/9089Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
    • H04L49/9094Arrangements for simultaneous transmit and receive, e.g. simultaneous reading/writing from/to the storage element
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1466Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/2871Implementation details of single intermediate entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/566Grouping or aggregating service requests, e.g. for unified processing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165Combined use of TCP and UDP protocols; selection criteria therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0866Checking the configuration
    • H04L41/0873Checking configuration conflicts between network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/59Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14Multichannel or multilink protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18Negotiating wireless communication parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/02Communication route or path selection, e.g. power-based or shortest path routing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks

Description

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

Claims (16)

  1. Netzwerk-Vorrichtung (200) zum Ausführen von Funktionen, um die Leistung eines Kommunikationsnetzwerks zu verbessern, mit: einem Spoofing-Modul (280), das ausgelegt ist, um selektiv eine Vielzahl von Verbindungen zu spoofen, die mit einer Vielzahl von Hosts (110) verknüpft sind, basierend auf entsprechenden Spoofingkriterien, und um eine lokale Bestätigung empfangener Nachrichten über die Verbindungen bereitzustellen; einem Verbindungs-Modul (282), das ausgelegt ist, um die Vielzahl von Verbindungen über eine gemeinsame Backbone-Verbindung zu multiplexen; ein Priorisierungs-Modul (284), das ausgelegt ist, um den Zugriff auf die Backbone-Verbindung basierend auf Priorisierungs-Kriterien zu priorisieren; und einem Pfadauswahl-Modul (286), das ausgelegt ist, um einen Pfad unter einer Vielzahl von Pfaden zu bestimmen, um die empfangenen Nachrichten basierend auf Pfadauswahl-Kriterien zu übermitteln, dadurch gekennzeichnet, dass das Spoofing-Modul (280) ausgelegt ist, um einen Verbindungs-Steuerungsblock (1305) unter einer Vielzahl von Verbindungs-Steuerungsblöcken entsprechend einer gespooften Verbindung zu belegen, wobei jeder der Vielzahl von Verbindungs-Steuerungsblöcken Information speichert, die in Bezug zu der Vielzahl von Verbindungen steht, wobei das Spoofing-Modul (280) konfiguriert ist, um mit einem Partner-Spoofing-Modul eine Begrenzung der Anzahl von Verbindungs-Steuerungsblöcken auszuhandeln, die zwischen dem Spoofing-Modul und dem Partner-Spoofing-Modul verwendet werden.
  2. Netzwerk-Vorrichtung nach Anspruch 1, ferner mit einer Mapping-Tabelle (1301), um Verbindungs-Steuerungsblock-Belegungsinformation zu speichern.
  3. Netzwerk-Vorrichtung nach Anspruch 1, ferner mit einer Hash-Funktionslogik (1303), die konfiguriert ist, um Zeiger entsprechend der Vielzahl von Verbindungs-Steuerungsblöcken auszugeben.
  4. Netzwerk-Vorrichtung nach Anspruch 1, wobei die Backbone-Verbindung eine Satellitenverbindung (130) ist.
  5. Netzwerk-Vorrichtung nach Anspruch 1, wobei das entfernte Spoofing-Modul ausgelegt ist, um die Vielzahl von Verbindungen entsprechend dem Transmission-Control-Protokoll zu errichten.
  6. Netzwerk-Vorrichtung nach Anspruch 1, wobei das Spoofingkriterium aufweist: zumindest die Zieladresse, die Quellen-Internet-Protokoll-Adresse; die Übertragungs-Steuerungsprotokoll-Port-Nummern; die Transmission-Control-Protokoll-Optionen; und das Internet Protokoll Differentiated Services Feld.
  7. Netzwerk-Vorrichtung nach Anspruch 1, wobei das Priorisierungskriterium zumindest aufweist: Ziel Internet-Protokoll-Adresse, Quellen-Internet-Protokoll-Adresse, Internet-Protokoll-Next-Protokoll, Transmission-Control-Protokoll-Port-Nummern, Benutzer-Datagram-Port-Nummern und Internet Protokoll Differentiated Services Feld.
  8. Netzwerk-Vorrichtung nach Anspruch 1, wobei das Priorisierungs-Modul (284) ausgelegt ist, um die Priorität einer der empfangenen Nachrichten zu setzen, wobei eine Nachricht ein Internet-Protokollpaket ist, wobei das Pfadauswahl-Kriterium zumindest die Priorität des Internet-Protokollpakets, die Ziel-Internet-Protokoll-Adresse, die Quellen-Internet-Protokoll-Adresse, das Internet-Protokoll-Next-Protokoll, die Transmission-Control-Protokoll-Port-Nummern, die User-Datagram-Port-Nummern und das Internet Protokoll Differentiated Services Feld umfasst.
  9. Verfahren zur Ausführung von Funktionen zur Verbesserung der Leistung eines Kommunikationsnetzwerks, wobei das Verfahren aufweist: Aushandeln einer Grenze der Anzahl von Verbindungs-Steuerungsblöcken, die verwendet werden, um gespoofte Verbindungen mit einem entfernten Spoofing-Modul zu unterstützen, mit einem entfernten Spoofing-Modul; das entfernte Spoofing-Modul selektiv eine der Vielzahl von Verbindungen spooft, die mit einer Vielzahl von Hosts (110) verknüpft sind und von dem entfernten Spoofing-Modul basierend auf entsprechenden Spoofing-Kriterien bedient werden, wobei der Schritt des selektiven Spoofens aufweist: Belegen eines der Verbindungs-Steuerungsblöcke für die eine gespoofte Verbindung, wobei jeder der Vielzahl von Verbindungs-Steuerungsblöcken Information speichert, die Verbindung zu der Vielzahl von Verbindungen steht; Bereitstellen einer lokalen Bestätigung empfangener Nachrichten über die Verbindungen; Multiplexen der Vielzahl von Verbindungen über eine gemeinsame Backbone-Verbindung; Priorisieren des Zugriffs auf die Backbone-Verbindung basierend auf Priorisierungs-Kriterien; und Bestimmen eines Pfads aus einer Vielzahl von Pfaden zur Übertragung der empfangenen Nachrichten basierend auf Pfadauswahl-Kriterien.
  10. Verfahren nach Anspruch 9, ferner mit: Speichern der Verbindungs-Steuerungsblock-Belegungsinformation in einer Mapping-Tabelle (1301).
  11. Verfahren nach Anspruch 9, ferner mit: Ausgeben von Zeigern entsprechend der Vielzahl von Verbindungs-Steuerungsblöcken.
  12. Verfahren nach Anspruch 9, wobei die Backbone-Verbindung in dem Schritt des Multiplexens eine Satelliten-Verbindung (130) ist.
  13. Verfahren nach Anspruch 9, wobei die Vielzahl von Verbindungen in dem Schritt des selektiven Spoofens entsprechend dem Transmission-Control-Protokoll aufgebaut wird.
  14. Verfahren nach Anspruch 9, wobei das Spoofing-Kriterium im Schritt des selektiven Spoofens aufweist: zumindest die Ziel-Internet-Protokoll-Adresse, die Quellen-Internet-Protokoll-Adresse; die Transmission-Control-Protokoll-Port-Nummern; die Transmission-Control-Protokoll-Optionen; und das Internet Protokoll Differentiated Services Feld.
  15. Verfahren nach Anspruch 9, wobei das Priorisierungs-Kriterium im Priorisierungsschritt aufweist: zumindest die Zieladresse, die Quellenadresse, das Internet-Protokoll-Next-Protokoll, die Transmission-Control-Protokoll-Port-Nummern, die User-Datagram-Protokoll-Port-Nummern und das Internet Protokoll Differentiated Services Feld.
  16. Verfahren nach Anspruch 9, ferner mit: Setzen der Priorität einer der empfangenen Nachrichten, wobei die eine Nachricht ein Internet-Protokoll-Paket ist, wobei das Pfadauswahl-Kriterium aufweist: zumindest die Priorität des Internet-Protokoll-Pakets, die Ziel-Internet-Protokoll-Adresse, die Quellen-Internet-Protokoll-Adresse, das Internet-Protokoll-Next-Protokoll, die Transmission-Control-Protokoll-Port-Nummern, die Benutzer-Datagram-Protokoll-Port-Nummern und das Internet Protokoll Differentiated Services Feld.
DE60114097T 2000-07-21 2001-07-20 Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies Expired - Fee Related DE60114097T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US22002600P 2000-07-21 2000-07-21
US220026P 2000-07-21
US22563000P 2000-08-15 2000-08-15
US225630P 2000-08-15

Publications (2)

Publication Number Publication Date
DE60114097D1 DE60114097D1 (de) 2006-03-02
DE60114097T2 true DE60114097T2 (de) 2006-08-10

Family

ID=26914502

Family Applications (8)

Application Number Title Priority Date Filing Date
DE60114942T Expired - Fee Related DE60114942T2 (de) 2000-07-21 2001-07-20 Verfahren und System für das Verwenden eines Kernnetz-Protokolls zur Verbesserung der Netzleistung
DE60117722T Expired - Lifetime DE60117722D1 (de) 2000-07-21 2001-07-20 Netzwerkverwaltung einer leistungssteigernden Proxy-Architektur
DE60117485T Expired - Fee Related DE60117485T2 (de) 2000-07-21 2001-07-20 Verfahren und Vorrichtung zur Pufferverwaltung
DE60118305T Expired - Lifetime DE60118305D1 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbesserung der Netzwerkleistung unter Verwendung von Wegeauswahl, Wegeaktivierung und Netzwerkprofilen
DE60114097T Expired - Fee Related DE60114097T2 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE60116447T Expired - Fee Related DE60116447T2 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbindungsbehandlung
DE60117723T Expired - Lifetime DE60117723D1 (de) 2000-07-21 2001-07-20 Verfahren und system zur Setzung von Verkehrsprioritäten in einem Netz
DE60112674T Expired - Fee Related DE60112674T2 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbesserung der Netzwerkleistung mittels Verbesserung von Proxyarchitektur mit redundantem Gateway

Family Applications Before (4)

Application Number Title Priority Date Filing Date
DE60114942T Expired - Fee Related DE60114942T2 (de) 2000-07-21 2001-07-20 Verfahren und System für das Verwenden eines Kernnetz-Protokolls zur Verbesserung der Netzleistung
DE60117722T Expired - Lifetime DE60117722D1 (de) 2000-07-21 2001-07-20 Netzwerkverwaltung einer leistungssteigernden Proxy-Architektur
DE60117485T Expired - Fee Related DE60117485T2 (de) 2000-07-21 2001-07-20 Verfahren und Vorrichtung zur Pufferverwaltung
DE60118305T Expired - Lifetime DE60118305D1 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbesserung der Netzwerkleistung unter Verwendung von Wegeauswahl, Wegeaktivierung und Netzwerkprofilen

Family Applications After (3)

Application Number Title Priority Date Filing Date
DE60116447T Expired - Fee Related DE60116447T2 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbindungsbehandlung
DE60117723T Expired - Lifetime DE60117723D1 (de) 2000-07-21 2001-07-20 Verfahren und system zur Setzung von Verkehrsprioritäten in einem Netz
DE60112674T Expired - Fee Related DE60112674T2 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbesserung der Netzwerkleistung mittels Verbesserung von Proxyarchitektur mit redundantem Gateway

Country Status (5)

Country Link
US (8) US6993584B2 (de)
EP (8) EP1176788B1 (de)
CA (8) CA2353339A1 (de)
DE (8) DE60114942T2 (de)
IL (8) IL144435A0 (de)

Families Citing this family (346)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110128972A1 (en) 2000-04-17 2011-06-02 Randy Thornton Peer to peer dynamic network link acceleration
US8065399B2 (en) 2000-04-17 2011-11-22 Circadence Corporation Automated network infrastructure test and diagnostic system and method therefor
US8195823B2 (en) 2000-04-17 2012-06-05 Circadence Corporation Dynamic network link acceleration
US8996705B2 (en) 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
US8898340B2 (en) 2000-04-17 2014-11-25 Circadence Corporation Dynamic network link acceleration for network including wireless communication devices
US8510468B2 (en) 2000-04-17 2013-08-13 Ciradence Corporation Route aware network link acceleration
US20020002625A1 (en) 2000-04-17 2002-01-03 Mark Vange System and method for reformatting data traffic
US8024481B2 (en) * 2000-04-17 2011-09-20 Circadence Corporation System and method for reducing traffic and congestion on distributed interactive simulation networks
US7519695B2 (en) * 2000-05-26 2009-04-14 Ipass Inc. Service quality monitoring process
US7111163B1 (en) 2000-07-10 2006-09-19 Alterwan, Inc. Wide area network using internet with quality of service
US6993584B2 (en) * 2000-07-21 2006-01-31 Hughes Network Systems Method and system for improving network performance by utilizing path selection, path activation, and profiles
US7373422B1 (en) * 2000-08-04 2008-05-13 Oracle International Corporation Techniques for supporting multiple devices in mobile applications
US6973097B1 (en) * 2000-08-29 2005-12-06 Nortel Networks Limited Modifying message size indications in communications over data networks
US7406539B2 (en) * 2000-10-17 2008-07-29 Avaya Technology Corp. Method and apparatus for performance and cost optimization in an internetwork
US7336613B2 (en) * 2000-10-17 2008-02-26 Avaya Technology Corp. Method and apparatus for the assessment and optimization of network traffic
IL155355A0 (en) 2000-10-17 2003-11-23 Routescience Technologies Inc Method and apparatus for performance and cost optimization in an internetwork
US7487237B2 (en) * 2000-10-17 2009-02-03 Avaya Technology Corp. Load optimization
US7349994B2 (en) * 2000-10-17 2008-03-25 Avaya Technology Corp. Method and apparatus for coordinating routing parameters via a back-channel communication medium
US8023421B2 (en) * 2002-07-25 2011-09-20 Avaya Inc. Method and apparatus for the assessment and optimization of network traffic
US7720959B2 (en) * 2000-10-17 2010-05-18 Avaya Inc. Method and apparatus for characterizing the quality of a network path
US7756032B2 (en) 2000-10-17 2010-07-13 Avaya Inc. Method and apparatus for communicating data within measurement traffic
US7839890B1 (en) * 2000-11-02 2010-11-23 Fisher-Rosemount Systems, Inc. Multiplexed data transmissions through a communication link
US20020087724A1 (en) * 2000-12-29 2002-07-04 Ragula Systems D/B/A Fatpipe Networks Combining connections for parallel access to multiple frame relay and other private networks
WO2002076038A1 (en) * 2001-03-19 2002-09-26 Bob Tang A method for guaranteeing quality of service on the internet by routing data along nodes without error correction processing capability
US7269157B2 (en) 2001-04-10 2007-09-11 Internap Network Services Corporation System and method to assure network service levels with intelligent routing
FI115271B (fi) * 2001-05-28 2005-03-31 Nokia Corp Menetelmä ja järjestelmä nopean elpymisprosessin toteuttamiseksi lähiverkossa
WO2003015330A2 (en) 2001-08-08 2003-02-20 Flash Networks Ltd. A system and a method for accelerating communication of tcp/ip based content
FI114365B (fi) * 2001-08-31 2004-09-30 First Hop Oy Menetelmä langattomien verkkojen suorituskyvyn optimoimiseksi
US7020716B2 (en) * 2001-08-31 2006-03-28 Adaptec, Inc. Method and system for verifying the hardware implementation of TCP/IP
US7788381B2 (en) * 2001-09-17 2010-08-31 Foundry Networks, Inc. System and method for router keep-alive control
US7613167B2 (en) * 2001-09-27 2009-11-03 Broadcom Corporation Method and system for upstream priority lookup at physical interface
US7127503B2 (en) * 2001-10-10 2006-10-24 Juniper Networks, Inc. Computer networking system, device, and method for improved speed in web page rendering
US7561517B2 (en) 2001-11-02 2009-07-14 Internap Network Services Corporation Passive route control of data networks
US7133365B2 (en) * 2001-11-02 2006-11-07 Internap Network Services Corporation System and method to provide routing control of information over networks
US7222190B2 (en) 2001-11-02 2007-05-22 Internap Network Services Corporation System and method to provide routing control of information over data networks
US7668966B2 (en) * 2001-11-02 2010-02-23 Internap Network Services Corporation Data network controller
ATE422760T1 (de) * 2001-11-12 2009-02-15 Ericsson Telefon Ab L M Verfahren zur bereitstellung von quality-of- service in systemen gemäss ieee 802.11
WO2003043285A2 (en) * 2001-11-13 2003-05-22 Ems Technologies, Inc. Flow control between performance enhancing proxies over variable bandwidth split links
US7221675B2 (en) * 2001-12-07 2007-05-22 Nortel Networks Limited Address resolution method for a virtual private network, and customer edge device for implementing the method
DE60229914D1 (de) * 2002-01-11 2009-01-02 Alcatel Lucent Modemsystem und Ansammlen für Pfade mit unterschiedlichen Übertragungsprofilen
US8090866B1 (en) 2002-01-18 2012-01-03 Cisco Technology, Inc. TCP proxy connection management in a gigabit environment
US8976798B2 (en) * 2002-01-28 2015-03-10 Hughes Network Systems, Llc Method and system for communicating over a segmented virtual private network (VPN)
US7389533B2 (en) * 2002-01-28 2008-06-17 Hughes Network Systems, Llc Method and system for adaptively applying performance enhancing functions
DE60322988D1 (de) * 2002-01-28 2008-10-02 Hughes Network Systems Llc Verfahren und Vorrichtung zur Integration von Funktionen zur Leistungsverbesserung in einem virtuellen Privatnetzwerk (VPN)
US20030172264A1 (en) * 2002-01-28 2003-09-11 Hughes Electronics Method and system for providing security in performance enhanced network
US20030219022A1 (en) * 2002-01-28 2003-11-27 Hughes Electronics Method and system for utilizing virtual private network (VPN) connections in a performance enhanced network
US7730063B2 (en) * 2002-12-10 2010-06-01 Asset Trust, Inc. Personalized medicine service
SE0200696D0 (sv) * 2002-03-06 2002-03-06 Ericsson Telefon Ab L M Method and system of load control
US7103674B2 (en) * 2002-03-28 2006-09-05 International Business Machines Corporation Apparatus and method of reducing dataflow distruption when detecting path maximum transmission unit (PMTU)
KR100453056B1 (ko) * 2002-03-29 2004-10-15 삼성전자주식회사 동적 ip 네트워크 상에서의 pmtu 변경 방법 및 그장치
US7543087B2 (en) * 2002-04-22 2009-06-02 Alacritech, Inc. Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote device
US8140888B1 (en) * 2002-05-10 2012-03-20 Cisco Technology, Inc. High availability network processing system
US20040105445A1 (en) * 2002-06-19 2004-06-03 Jeremy Wyn-Harris Internet protocol for resource-constrained devices
US9088494B2 (en) * 2002-06-26 2015-07-21 Avaya Communication Israel Ltd. Packet fragmentation prevention
US7512120B2 (en) * 2002-07-09 2009-03-31 Ntt Docomo, Inc. Node, correspondent node, mobility anchor point, and home agent in packet communication system, packet communication system, and path MTU discovery method
JP2004056306A (ja) * 2002-07-17 2004-02-19 Ntt Docomo Inc 通信制御システム、通信制御方法、中継装置及び通信制御プログラム
FR2842683B1 (fr) * 2002-07-22 2005-01-14 Cit Alcatel Dispositif de multiplexage, dispositif de multiplexage et systeme de multiplexage/demultiplexage
US7305464B2 (en) * 2002-09-03 2007-12-04 End Ii End Communications, Inc. Systems and methods for broadband network optimization
US7653012B2 (en) * 2002-09-26 2010-01-26 Sharp Laboratories Of America, Inc. Relay transmission of data in a centralized network
US20040081089A1 (en) * 2002-09-26 2004-04-29 Sharp Laboratories Of America, Inc. Transmitting data on scheduled channels in a centralized network
US7542471B2 (en) * 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US8233392B2 (en) * 2003-07-29 2012-07-31 Citrix Systems, Inc. Transaction boundary detection for reduction in timeout penalties
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US7630305B2 (en) * 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
US7949737B2 (en) * 2002-11-04 2011-05-24 Riverbed Technology, Inc. Method and apparatus for grouping nodes based on connection characteristics
US8090809B2 (en) * 2002-11-04 2012-01-03 Riverbed Technology, Inc. Role grouping
CA2506555C (en) * 2002-11-08 2018-08-14 Arbitration Forums, Inc. A system and process for electronic subrogation, inter-organization workflow management, inter-organization transaction processing and optimized web-based user interaction
WO2004056047A1 (en) * 2002-12-13 2004-07-01 Internap Network Services Corporation Topology aware route control
US7295510B2 (en) * 2002-12-17 2007-11-13 At&T Corporation Method of estimating restoration capacity in a network
WO2004064333A1 (ja) * 2003-01-10 2004-07-29 Sharp Kabushiki Kaisha 通信装置、ネットワークシステム、通信管理方法、要求信号、応答信号、プログラム、および、プログラムを記録した記録媒体
WO2004071036A1 (en) * 2003-02-03 2004-08-19 Telefonaktiebolaget Lm Ericsson (Publ) Shared risk group handling within a media gateway
US8605647B2 (en) 2004-02-03 2013-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Shared risk group handling within a media gateway
US6965564B2 (en) 2003-02-14 2005-11-15 America Online, Inc. Wireless datagram transaction protocol system
AU2003214248A1 (en) * 2003-03-20 2004-10-11 Telefonaktiebolaget Lm Ericsson (Publ) Data unit transmission method and device
CN1300986C (zh) * 2003-04-14 2007-02-14 华为技术有限公司 实现快速五七层交换的方法
US20050055371A1 (en) * 2003-06-05 2005-03-10 Singam Sunder Method and system to manage a network connection application
US7248589B2 (en) * 2003-06-05 2007-07-24 International Business Machines Corporation Apparatus for enabling multi-tuple TCP sockets within a computer network
US20040264368A1 (en) * 2003-06-30 2004-12-30 Nokia Corporation Data transfer optimization in packet data networks
US7698453B2 (en) * 2003-07-29 2010-04-13 Oribital Data Corporation Early generation of acknowledgements for flow control
US7656799B2 (en) * 2003-07-29 2010-02-02 Citrix Systems, Inc. Flow control system architecture
US8437284B2 (en) * 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US8432800B2 (en) * 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
WO2005013083A2 (en) 2003-07-29 2005-02-10 Orbital Data Corporation Flow control architecture
US8238241B2 (en) * 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US7286476B2 (en) * 2003-08-01 2007-10-23 F5 Networks, Inc. Accelerating network performance by striping and parallelization of TCP connections
EP1509002B1 (de) * 2003-08-19 2007-10-24 Sony Deutschland GmbH Erweiterung des Radiofrequenzabdeckungsbereiches für ein drahtloses Heimnetzwerksystem
US20080089347A1 (en) * 2003-08-29 2008-04-17 End Ii End Communications Inc. Systems and methods for broadband network optimization
US8285881B2 (en) * 2003-09-10 2012-10-09 Broadcom Corporation System and method for load balancing and fail over
US8417834B2 (en) * 2003-09-10 2013-04-09 Broadcom Corporation Unified infrastructure over ethernet
US7468948B2 (en) * 2003-09-17 2008-12-23 Steven A Rogers Empirical scheduling of network packets using coarse and fine testing periods
US7529247B2 (en) * 2003-09-17 2009-05-05 Rivulet Communications, Inc. Empirical scheduling of network packets
MXPA06003802A (es) * 2003-10-09 2006-06-23 Lg Electronics Inc Metodo para generar plcm para el servicio de difusion/multidifusion y aparato del mismo.
US7339923B2 (en) * 2003-10-31 2008-03-04 Rivulet Communications, Inc. Endpoint packet scheduling system
US7978716B2 (en) 2003-11-24 2011-07-12 Citrix Systems, Inc. Systems and methods for providing a VPN solution
US20060184473A1 (en) * 2003-11-19 2006-08-17 Eder Jeff S Entity centric computer system
US7925754B2 (en) * 2003-11-21 2011-04-12 Microsoft Corporation Method and computer program product to provide synch notifications to client devices
US7508813B2 (en) * 2003-11-25 2009-03-24 Rivulet Communications Local area network contention avoidance
ATE356492T1 (de) * 2003-12-16 2007-03-15 Cit Alcatel Anordnung mit einem terminal, einem zugangsmultiplexer und einem netzwerk
US20050141551A1 (en) * 2003-12-29 2005-06-30 Mcneil Roy Jr. Common LAN architecture and flow control relay
KR100602651B1 (ko) * 2004-02-13 2006-07-19 삼성전자주식회사 Tcp 커넥션 관리 장치 및 방법
US7394813B2 (en) * 2004-05-05 2008-07-01 Sharp Laboratories Of America, Inc. Systems and methods for implementing an acknowledgement mechanism for transmission of a real-time data stream
US7409445B2 (en) * 2004-05-27 2008-08-05 International Business Machines Corporation Method for facilitating monitoring and simultaneously analyzing of network events of multiple hosts via a single network interface
US8739274B2 (en) 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching in a data communication network
US8495305B2 (en) 2004-06-30 2013-07-23 Citrix Systems, Inc. Method and device for performing caching of dynamically generated objects in a data communication network
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private network
US7606902B2 (en) 2004-07-23 2009-10-20 Citrix Systems, Inc. Method and systems for routing packets from an endpoint to a gateway
JP2008507928A (ja) 2004-07-23 2008-03-13 サイトリックス システムズ, インコーポレイテッド ネットワークノード間の通信を最適化するためのシステムおよび方法
US9189307B2 (en) * 2004-08-06 2015-11-17 LiveQoS Inc. Method of improving the performance of an access network for coupling user devices to an application server
CA2549577A1 (en) * 2004-09-09 2006-03-16 Avaya Technology Corp. Methods of and systems for network traffic security
US8024483B1 (en) * 2004-10-01 2011-09-20 F5 Networks, Inc. Selective compression for network connections
US7453885B2 (en) * 2004-10-13 2008-11-18 Rivulet Communications, Inc. Network connection device
EP1813075A1 (de) * 2004-11-15 2007-08-01 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Verfahren zur mss-modifikation
US7610400B2 (en) * 2004-11-23 2009-10-27 Juniper Networks, Inc. Rule-based networking device
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US8549149B2 (en) 2004-12-30 2013-10-01 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
US8700695B2 (en) 2004-12-30 2014-04-15 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary
US7810089B2 (en) 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US20060253605A1 (en) * 2004-12-30 2006-11-09 Prabakar Sundarrajan Systems and methods for providing integrated client-side acceleration techniques to access remote applications
EP1878192B1 (de) 2005-01-06 2011-06-22 Rockwell Automation Technologies, Inc. Firewall-verfahren und vorrichtung für industrielle systeme
US8077632B2 (en) * 2005-01-20 2011-12-13 Citrix Systems, Inc. Automatic LAN/WAN port detection
US7581005B2 (en) 2005-01-20 2009-08-25 Citrix Systems, Inc. Systems and methods for preserving transport layer protocol options
US8255456B2 (en) * 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
US20060209824A1 (en) * 2005-03-01 2006-09-21 The Mitre Corporation Method, apparatus, and computer program product for transmitting and receiving broadcast packets
US7773551B1 (en) * 2005-03-18 2010-08-10 Raytheon Company Data handling in a distributed communication network
US20060242156A1 (en) * 2005-04-20 2006-10-26 Bish Thomas W Communication path management system
US8069250B2 (en) * 2005-04-28 2011-11-29 Vmware, Inc. One-way proxy system
US7657537B1 (en) 2005-04-29 2010-02-02 Netapp, Inc. System and method for specifying batch execution ordering of requests in a storage system cluster
WO2007069095A2 (en) * 2005-07-18 2007-06-21 Broadcom Israel R & D Method and system for transparent tcp offload
US8392684B2 (en) 2005-08-12 2013-03-05 Silver Peak Systems, Inc. Data encryption in a network memory architecture for providing data based on local accessibility
US8095774B1 (en) 2007-07-05 2012-01-10 Silver Peak Systems, Inc. Pre-fetching data into a memory
US8171238B1 (en) 2007-07-05 2012-05-01 Silver Peak Systems, Inc. Identification of data stored in memory
JP2007081678A (ja) * 2005-09-13 2007-03-29 Ntt Docomo Inc データ中継装置及びデータ中継方法
US8335576B1 (en) * 2005-09-22 2012-12-18 Teradici Corporation Methods and apparatus for bridging an audio controller
US20070071026A1 (en) * 2005-09-23 2007-03-29 Rivulet Communications, Inc. Compressed video packet scheduling system
US8250229B2 (en) * 2005-09-29 2012-08-21 International Business Machines Corporation Internet protocol security (IPSEC) packet processing for multiple clients sharing a single network address
US8811431B2 (en) 2008-11-20 2014-08-19 Silver Peak Systems, Inc. Systems and methods for compressing packet data
US8929402B1 (en) 2005-09-29 2015-01-06 Silver Peak Systems, Inc. Systems and methods for compressing packet data by predicting subsequent data
US8489562B1 (en) 2007-11-30 2013-07-16 Silver Peak Systems, Inc. Deferred data storage
CN100401688C (zh) 2005-09-30 2008-07-09 华为技术有限公司 光通信系统的自动恢复检测方法、自动恢复方法及装置
US7773630B2 (en) * 2005-11-12 2010-08-10 Liquid Computing Corportation High performance memory based communications interface
JP4531683B2 (ja) * 2005-11-16 2010-08-25 パナソニック株式会社 無線通信装置およびアドホック経路情報取得方法
EP1793553A1 (de) * 2005-12-02 2007-06-06 Alcatel Lucent TCP-Hostgerät mit einem TCP-Konvergenzmodul
US7940713B2 (en) * 2005-12-08 2011-05-10 Electronics And Telecommunications Research Institute Apparatus and method for traffic performance improvement and traffic security in interactive satellite communication system
US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
JP4984531B2 (ja) * 2006-01-06 2012-07-25 富士通株式会社 サーバ監視プログラム、中継装置、サーバ監視方法
US8199731B2 (en) * 2006-01-25 2012-06-12 Motorola Mobility, Inc. Method and apparatus for facilitating switched packet data services on multiple networks
JP2007206871A (ja) * 2006-01-31 2007-08-16 Toshiba Corp 情報処理装置、および描画制御方法
US8160062B2 (en) * 2006-01-31 2012-04-17 Microsoft Corporation Network connectivity determination based on passive analysis of connection-oriented path information
US7890655B2 (en) * 2006-02-16 2011-02-15 Cisco Technology, Inc. Storage area network port based data transfer acceleration
US8238242B2 (en) 2006-02-27 2012-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Flow control mechanism using local and global acknowledgements
AU2007281084B2 (en) * 2006-03-06 2012-02-02 Marc Timothy Turk Data message management system
US20070226347A1 (en) * 2006-03-23 2007-09-27 Chu Hsiao-Keng J Method and apparatus for dynamically changing the TCP behavior of a network connection
US20070233886A1 (en) * 2006-04-04 2007-10-04 Fan Kan F Method and system for a one bit TCP offload
US8004973B2 (en) 2006-04-25 2011-08-23 Citrix Systems, Inc. Virtual inline configuration for a network device
US7650406B2 (en) * 2006-04-26 2010-01-19 Microsoft Corporation Termination of a security association between devices
US7596628B2 (en) * 2006-05-01 2009-09-29 Broadcom Corporation Method and system for transparent TCP offload (TTO) with a user space library
US7756134B2 (en) 2006-05-02 2010-07-13 Harris Corporation Systems and methods for close queuing to support quality of service
US7894509B2 (en) * 2006-05-18 2011-02-22 Harris Corporation Method and system for functional redundancy based quality of service
US8516153B2 (en) 2006-06-16 2013-08-20 Harris Corporation Method and system for network-independent QoS
US20070291768A1 (en) * 2006-06-16 2007-12-20 Harris Corporation Method and system for content-based differentiation and sequencing as a mechanism of prioritization for QOS
US7990860B2 (en) 2006-06-16 2011-08-02 Harris Corporation Method and system for rule-based sequencing for QoS
US8064464B2 (en) 2006-06-16 2011-11-22 Harris Corporation Method and system for inbound content-based QoS
US7856012B2 (en) 2006-06-16 2010-12-21 Harris Corporation System and methods for generic data transparent rules to support quality of service
US7916626B2 (en) 2006-06-19 2011-03-29 Harris Corporation Method and system for fault-tolerant quality of service
US7908372B2 (en) * 2006-06-19 2011-03-15 Liquid Computing Corporation Token based flow control for data communication
US8730981B2 (en) 2006-06-20 2014-05-20 Harris Corporation Method and system for compression based quality of service
US7769028B2 (en) 2006-06-21 2010-08-03 Harris Corporation Systems and methods for adaptive throughput management for event-driven message-based data
US8300653B2 (en) 2006-07-31 2012-10-30 Harris Corporation Systems and methods for assured communications with quality of service
US8885632B2 (en) * 2006-08-02 2014-11-11 Silver Peak Systems, Inc. Communications scheduler
US8755381B2 (en) 2006-08-02 2014-06-17 Silver Peak Systems, Inc. Data matching using flow based packet data storage
US7907621B2 (en) * 2006-08-03 2011-03-15 Citrix Systems, Inc. Systems and methods for using a client agent to manage ICMP traffic in a virtual private network environment
US8244883B2 (en) 2006-08-03 2012-08-14 Citrix Systems, Inc. Systems and methods of for providing multi-mode transport layer compression
US8312120B2 (en) * 2006-08-22 2012-11-13 Citrix Systems, Inc. Systems and methods for providing dynamic spillover of virtual servers based on bandwidth
US8493858B2 (en) 2006-08-22 2013-07-23 Citrix Systems, Inc Systems and methods for providing dynamic connection spillover among virtual servers
EP1892883A1 (de) * 2006-08-23 2008-02-27 Thomson Telecom Belgium Methode und Vorrichtung zur Identification und Auswahl einer Schnittstelle zur Anbindung an ein Netzwerk
US7933257B2 (en) * 2006-09-20 2011-04-26 Cisco Technology, Inc. Using QoS tunnels for TCP latency optimization
US20080181108A1 (en) * 2006-10-06 2008-07-31 Viasat, Inc. Dynamic Feedback For Outbound Link Rate Adjustment In Multi-Rate Downstream
US8102768B2 (en) * 2006-10-18 2012-01-24 D & S Consultants, Inc. Method and system for traffic flow control in a communication network
EP2084864A1 (de) * 2006-10-24 2009-08-05 Medianet Innovations A/S Verfahren und system zur firewall-freundlichen echtzeit-kommunikation
US7873964B2 (en) 2006-10-30 2011-01-18 Liquid Computing Corporation Kernel functions for inter-processor communications in high performance multi-processor systems
US20090248376A1 (en) * 2006-11-08 2009-10-01 Silva Gabriel A Complex Network Mapping
US7664857B2 (en) 2007-01-26 2010-02-16 Citrix Systems, Inc. Systems and methods of using an IP ID field for automatic WAN/LAN detection
US9344356B2 (en) * 2007-02-28 2016-05-17 Hewlett Packard Enterprise Development Lp Transmitting a packet from a distributed trunk switch
US7865589B2 (en) 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing structured policy expressions to represent unstructured data in a network appliance
US7853679B2 (en) * 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring handling of undefined policy events
US8490148B2 (en) 2007-03-12 2013-07-16 Citrix Systems, Inc Systems and methods for managing application security profiles
US7870277B2 (en) * 2007-03-12 2011-01-11 Citrix Systems, Inc. Systems and methods for using object oriented expressions to configure application security policies
US8631147B2 (en) 2007-03-12 2014-01-14 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US7706266B2 (en) 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
US7853678B2 (en) * 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring flow control of policy expressions
US8009687B2 (en) * 2007-03-28 2011-08-30 Ixia Measurement of network performance in transporting packet streams
US8677479B2 (en) * 2007-04-16 2014-03-18 Microsoft Corporation Detection of adversaries through collection and correlation of assessments
US8606861B2 (en) * 2007-04-27 2013-12-10 Cellco Partnership Method, apparatus, and computer program product for reducing session related message size
US8582966B2 (en) * 2007-09-10 2013-11-12 Cortina Systems, Inc. Method and apparatus for protection switching in passive optical network
US20090083422A1 (en) * 2007-09-25 2009-03-26 Network Connectivity Solutions Corp. Apparatus and method for improving network infrastructure
US8305896B2 (en) * 2007-10-31 2012-11-06 Cisco Technology, Inc. Selective performance enhancement of traffic flows
US8307115B1 (en) 2007-11-30 2012-11-06 Silver Peak Systems, Inc. Network memory mirroring
US8464074B1 (en) 2008-05-30 2013-06-11 Cisco Technology, Inc. Storage media encryption with write acceleration
US20090319531A1 (en) * 2008-06-20 2009-12-24 Bong Jun Ko Method and Apparatus for Detecting Devices Having Implementation Characteristics Different from Documented Characteristics
US10164861B2 (en) 2015-12-28 2018-12-25 Silver Peak Systems, Inc. Dynamic monitoring and visualization for network health characteristics
US9717021B2 (en) 2008-07-03 2017-07-25 Silver Peak Systems, Inc. Virtual network overlay
US10805840B2 (en) 2008-07-03 2020-10-13 Silver Peak Systems, Inc. Data transmission via a virtual wide area network overlay
US8743683B1 (en) 2008-07-03 2014-06-03 Silver Peak Systems, Inc. Quality of service using multiple flows
FR2933834A1 (fr) * 2008-07-11 2010-01-15 Canon Kk Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants.
CN101631065B (zh) * 2008-07-16 2012-04-18 华为技术有限公司 一种无线多跳网络拥塞的控制方法和装置
US8407721B2 (en) 2008-12-12 2013-03-26 Microsoft Corporation Communication interface selection on multi-homed devices
TW201031141A (en) * 2009-02-04 2010-08-16 Univ Nat Taiwan Packets inspection device and method
EP2416532B1 (de) * 2009-03-30 2014-10-08 Nec Corporation Kommunikationsfluss-steuersystem, kommunikationsfluss-steuerverfahren und kommunikationsfluss-verarbeitungsprogramm
FR2950215B1 (fr) * 2009-09-11 2011-11-25 Thales Sa Procede et systeme pour le controle de l'acheminement d'un flux de donnees d'une classe de service a travers un reseau maille et chiffre
SG181616A1 (en) * 2009-12-10 2012-07-30 Royal Bank Of Canada Synchronized processing of data by networked computing resources
US9940670B2 (en) 2009-12-10 2018-04-10 Royal Bank Of Canada Synchronized processing of data by networked computing resources
US8423607B2 (en) * 2010-06-01 2013-04-16 Qualcomm Incorporated Fallback procedures for domain name server update in a mobile IP registration
US8819777B2 (en) * 2010-06-04 2014-08-26 Lockheed Martin Corporation Method and apparatus for preventing and analyzing network intrusion
JP5672779B2 (ja) * 2010-06-08 2015-02-18 ソニー株式会社 送信制御装置、および送信制御方法
US20120005063A1 (en) * 2010-06-30 2012-01-05 NYSE Euronext Fix proxy server
KR20120002424A (ko) * 2010-06-30 2012-01-05 한국전자통신연구원 통신 노드 및 통신 방법
US8875220B2 (en) * 2010-07-01 2014-10-28 Raytheom Company Proxy-based network access protection
US8417812B1 (en) * 2010-07-12 2013-04-09 Vmware, Inc. Methods and systems for detecting anomalies during IO accesses
US8719401B1 (en) 2010-07-12 2014-05-06 Vmware, Inc. Decentralized input/output resource management
US8364812B2 (en) 2010-08-27 2013-01-29 Sandvine Incorporated Ulc Method and system for network data flow management
US8699499B2 (en) * 2010-12-08 2014-04-15 At&T Intellectual Property I, L.P. Methods and apparatus to provision cloud computing network elements
US8929816B2 (en) * 2011-05-13 2015-01-06 Nokia Corporation Multiple apparatus selection via touch
US8929817B2 (en) 2011-05-13 2015-01-06 Nokia Corporation Sensor-based touch inquiry control
US8965285B2 (en) 2011-05-13 2015-02-24 Nokia Corporation Touch inquiry
US8650300B2 (en) * 2011-06-07 2014-02-11 International Business Machines Corporation Transparent heterogenous link pairing
US8732798B2 (en) * 2011-08-03 2014-05-20 Blackberry Limited Automatic disabling of enabled connection profile for wireless network
US9130991B2 (en) 2011-10-14 2015-09-08 Silver Peak Systems, Inc. Processing data packets in performance enhancing proxy (PEP) environment
US9626224B2 (en) 2011-11-03 2017-04-18 Silver Peak Systems, Inc. Optimizing available computing resources within a virtual environment
JP5845462B2 (ja) * 2011-11-07 2016-01-20 パナソニックIpマネジメント株式会社 通信システムおよびそれに用いる伝送ユニット
US8665847B2 (en) 2011-11-08 2014-03-04 Microsoft Corporation Service-assisted network access point selection
WO2013098255A1 (en) * 2011-12-29 2013-07-04 Thomson Licensing A network gateway and a method for transmitting packets of a data stream
TWI459768B (zh) 2011-12-30 2014-11-01 Ind Tech Res Inst 協助tcp封包傳送的通訊系統與方法
US8812542B1 (en) * 2012-03-30 2014-08-19 Emc Corporation On-the-fly determining of alert relationships in a distributed system
CN103390148B (zh) * 2012-05-10 2017-04-26 宏碁股份有限公司 使用条码图案的连线设定方法、系统及其使用者装置
JP6056857B2 (ja) * 2012-06-25 2017-01-11 日本電気株式会社 通信制御装置及び通信制御方法
US8751615B2 (en) * 2012-07-18 2014-06-10 Accedian Networks Inc. Systems and methods of discovering and controlling devices without explicit addressing
EP3897027B1 (de) * 2012-09-28 2024-02-14 Juniper Networks, Inc. Verfahren und vorrichtung zur steuerung von drahtloszugangspunkten
EP2725868B1 (de) * 2012-10-24 2017-10-04 BlackBerry Limited System und Verfahren zur Steuerung des Verbindungs-Timeouts in einem Kommunikationsnetzwerk
JP2014096674A (ja) * 2012-11-08 2014-05-22 Hitachi High-Technologies Corp ネットワーク装置、ネットワーク装置の制御方法及びネットワークシステム
US9769034B2 (en) 2012-12-14 2017-09-19 Futurewei Technologies, Inc. Method and apparatus for policy based routing in information centric networking based home networks
US9398039B2 (en) * 2013-03-15 2016-07-19 Aruba Networks, Inc. Apparatus, system and method for suppressing erroneous reporting of attacks on a wireless network
US10425371B2 (en) * 2013-03-15 2019-09-24 Trane International Inc. Method for fragmented messaging between network devices
EP2984804A1 (de) * 2013-04-08 2016-02-17 Telefonaktiebolaget LM Ericsson (publ) Steuerung des aufbaus mehrerer tcp-verbindungen
US9191843B2 (en) * 2013-06-12 2015-11-17 Honeywell International Inc. Apparatus and method for measuring and reporting redundant wireless connectivity over time
US8896367B1 (en) * 2013-07-18 2014-11-25 Ememory Technology Inc. Charge pump system
US10003536B2 (en) 2013-07-25 2018-06-19 Grigore Raileanu System and method for managing bandwidth usage rates in a packet-switched network
US10432529B2 (en) 2013-09-19 2019-10-01 Connectivity Systems Incorporated Enhanced large data transmissions and catastrophic congestion avoidance over IPv6 TCP/IP networks
US10057302B2 (en) 2013-11-15 2018-08-21 Microsoft Technology Licensing, Llc Context-based selection of instruction sets for connecting through captive portals
US9554323B2 (en) 2013-11-15 2017-01-24 Microsoft Technology Licensing, Llc Generating sequenced instructions for connecting through captive portals
US10382305B2 (en) 2013-11-15 2019-08-13 Microsoft Technology Licensing, Llc Applying sequenced instructions to connect through captive portals
US9369342B2 (en) 2013-11-15 2016-06-14 Microsoft Technology Licensing, Llc Configuring captive portals with a cloud service
CN104754003B (zh) * 2013-12-30 2019-01-08 腾讯科技(深圳)有限公司 传输数据的方法及系统
US10485018B2 (en) * 2014-01-16 2019-11-19 Samsung Electronics Co., Ltd. Apparatus and method for operating user plane protocol stack in connectionless communication system
US9356879B2 (en) * 2014-05-22 2016-05-31 Dell Products L.P. Optimized path maximum transmission unit discovery
US9860297B2 (en) 2014-06-02 2018-01-02 Nokia Technologies Oy Method, apparatus, and computer program product for media selection for moving user
US9635690B2 (en) 2014-06-24 2017-04-25 Nokia Technologies Oy Method, apparatus, and computer program product for improving security for wireless communication
US9338635B2 (en) 2014-07-01 2016-05-10 Nokia Technologies Oy Method, apparatus, and computer program product for device tracking
WO2016013624A1 (ja) * 2014-07-25 2016-01-28 三菱樹脂株式会社 ガスバリア性積層フィルム
US9948496B1 (en) 2014-07-30 2018-04-17 Silver Peak Systems, Inc. Determining a transit appliance for data traffic to a software service
US9875344B1 (en) 2014-09-05 2018-01-23 Silver Peak Systems, Inc. Dynamic monitoring and authorization of an optimization device
JP6179492B2 (ja) * 2014-09-11 2017-08-16 コニカミノルタ株式会社 通信中継装置、プログラム及び通信中継方法
EP3198464B1 (de) * 2014-09-25 2019-02-06 Hughes Network Systems, LLC Anwendungsbewusstes multihoming für datenverkehrsbeschleunigung in datenkommunikationsnetzen
US9265080B1 (en) 2014-10-01 2016-02-16 Nokia Technologies Oy Method, apparatus, and computer program product for multi-device output mode configuration
US10924408B2 (en) 2014-11-07 2021-02-16 Noction, Inc. System and method for optimizing traffic in packet-switched networks with internet exchanges
US10116577B2 (en) * 2014-12-04 2018-10-30 Dell Products Lp Detecting path MTU mismatch at first-hop router
US10798000B2 (en) * 2014-12-22 2020-10-06 Arista Networks, Inc. Method and apparatus of compressing network forwarding entry information
US9755731B2 (en) 2015-01-10 2017-09-05 Hughes Network Systems, Llc Hardware TCP accelerator
US9769070B2 (en) 2015-01-28 2017-09-19 Maxim Basunov System and method of providing a platform for optimizing traffic through a computer network with distributed routing domains interconnected through data center interconnect links
US10171333B2 (en) 2015-02-10 2019-01-01 International Business Machines Corporation Determining connection feasibility and selection between different connection types
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
EP3318102A4 (de) * 2015-04-20 2019-03-20 Shoelace Wireless, Inc. Systeme für verbesserte geschwindigkeit und sicherheit von mobilem internet
US11567962B2 (en) * 2015-07-11 2023-01-31 Taascom Inc. Computer network controlled data orchestration system and method for data aggregation, normalization, for presentation, analysis and action/decision making
US9407585B1 (en) 2015-08-07 2016-08-02 Machine Zone, Inc. Scalable, real-time messaging system
US9602455B2 (en) 2015-08-07 2017-03-21 Machine Zone, Inc. Scalable, real-time messaging system
US10333879B2 (en) 2015-08-07 2019-06-25 Satori Worldwide, Llc Scalable, real-time messaging system
US9319363B1 (en) 2015-08-07 2016-04-19 Machine Zone, Inc. Scalable, real-time messaging system
WO2017062594A1 (en) 2015-10-06 2017-04-13 Casbu, LLC Multi-level constrained communication system
US9319365B1 (en) 2015-10-09 2016-04-19 Machine Zone, Inc. Systems and methods for storing and transferring message data
US9385976B1 (en) 2015-10-09 2016-07-05 Machine Zone, Inc. Systems and methods for storing message data
US9397973B1 (en) 2015-10-16 2016-07-19 Machine Zone, Inc. Systems and methods for transferring message data
US10305960B1 (en) * 2015-10-16 2019-05-28 Sprint Communications Company L.P. Detection of aberrant multiplexed transport connections
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US9602450B1 (en) 2016-05-16 2017-03-21 Machine Zone, Inc. Maintaining persistence of a messaging system
US10404647B2 (en) 2016-06-07 2019-09-03 Satori Worldwide, Llc Message compression in scalable messaging system
US10432484B2 (en) 2016-06-13 2019-10-01 Silver Peak Systems, Inc. Aggregating select network traffic statistics
US10142860B2 (en) 2016-06-14 2018-11-27 Hughes Network Systems, Llc Automated network diagnostic techniques
ES2928551T3 (es) * 2016-06-29 2022-11-21 Beijing Xiaomi Mobile Software Co Ltd Procedimiento de entrega de información, procedimiento de envío de datos, aparato y sistema
US9608928B1 (en) * 2016-07-06 2017-03-28 Machine Zone, Inc. Multiple-speed message channel of messaging system
US10511521B2 (en) 2016-08-03 2019-12-17 Anchorfree Inc. System and method for virtual multipath data transport
US9967203B2 (en) 2016-08-08 2018-05-08 Satori Worldwide, Llc Access control for message channels in a messaging system
US9967056B1 (en) 2016-08-19 2018-05-08 Silver Peak Systems, Inc. Forward packet recovery with constrained overhead
US10374986B2 (en) 2016-08-23 2019-08-06 Satori Worldwide, Llc Scalable, real-time messaging system
US10305981B2 (en) 2016-08-31 2019-05-28 Satori Worldwide, Llc Data replication in scalable messaging system
US9667681B1 (en) 2016-09-23 2017-05-30 Machine Zone, Inc. Systems and methods for providing messages to multiple subscribers
US10594616B2 (en) * 2016-09-30 2020-03-17 Hughes Network Systems, LLC. Data buffering control system and method for a communication network
US10454804B2 (en) 2016-11-07 2019-10-22 Hughes Network Systems, Llc Application characterization using transport protocol analysis
US10205804B2 (en) 2017-02-01 2019-02-12 Hughes Network Systems, Llc Methods and systems for enhanced support of TCP options in a TCP spoofed system
US11044202B2 (en) 2017-02-06 2021-06-22 Silver Peak Systems, Inc. Multi-level learning for predicting and classifying traffic flows from first packet data
US10257082B2 (en) 2017-02-06 2019-04-09 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows
US10892978B2 (en) 2017-02-06 2021-01-12 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows from first packet data
US10771394B2 (en) 2017-02-06 2020-09-08 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows on a first packet from DNS data
WO2018146521A1 (en) * 2017-02-11 2018-08-16 Pismo Labs Technology Ltd. Methods and systems for transmitting information packets through tunnel groups at a network node
US10187278B2 (en) 2017-02-24 2019-01-22 Satori Worldwide, Llc Channel management in scalable messaging system
US10447623B2 (en) 2017-02-24 2019-10-15 Satori Worldwide, Llc Data storage systems and methods using a real-time messaging system
US10270726B2 (en) 2017-02-24 2019-04-23 Satori Worldwide, Llc Selective distribution of messages in a scalable, real-time messaging system
CN107241268B (zh) * 2017-07-20 2020-05-12 北京航空航天大学 基于星基ads-b报文卫星网络的局部多径路由方法和装置
US10581978B2 (en) * 2017-07-31 2020-03-03 Hughes Network Systems, Llc Smart spoofing to improve spoofing performance when resources are scarce
US11212210B2 (en) 2017-09-21 2021-12-28 Silver Peak Systems, Inc. Selective route exporting using source type
US11032257B1 (en) 2017-12-08 2021-06-08 Rankin Labs, Llc Method for covertly delivering a packet of data over a network
US11861025B1 (en) 2018-01-08 2024-01-02 Rankin Labs, Llc System and method for receiving and processing a signal within a TCP/IP protocol stack
WO2019144075A1 (en) 2018-01-22 2019-07-25 John Rankin System and method for generating random numbers
WO2019152573A1 (en) 2018-01-31 2019-08-08 John Rankin System and method for secure communication using random blocks or random numbers
WO2019168978A1 (en) 2018-02-28 2019-09-06 John Rankin System and method for expanding a set of random values
US10637721B2 (en) 2018-03-12 2020-04-28 Silver Peak Systems, Inc. Detecting path break conditions while minimizing network overhead
WO2019183543A1 (en) 2018-03-23 2019-09-26 John Rankin System and method for identifying a speaker's community of origin from a sound sample
US11379279B2 (en) 2018-06-28 2022-07-05 Juniper Networks, Inc. Netlink asynchronous notifications for native and third party application in distributed network systems
US11165625B2 (en) * 2018-06-28 2021-11-02 Juniper Networks, Inc. Network state management
WO2020014354A1 (en) 2018-07-10 2020-01-16 John Rankin System and method for indexing sound fragments containing speech
WO2020033540A1 (en) 2018-08-10 2020-02-13 John Rankin System and method for covertly transmitting a payload of data
US11689543B2 (en) 2018-08-10 2023-06-27 Rankin Labs, Llc System and method for detecting transmission of a covert payload of data
WO2020041390A1 (en) 2018-08-21 2020-02-27 John Rankin System and method for scattering network traffic across a number of disparate hosts
US10819420B2 (en) 2018-10-09 2020-10-27 Hughes Network Systems, Llc Multipath satellite backbone
US11031998B2 (en) * 2018-10-09 2021-06-08 Hughes Network Systems, Llc Bonding and redundancy for satellite transport paths
ES2881255T3 (es) * 2018-10-24 2021-11-29 Acklio Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas
CN109147284B (zh) * 2018-10-30 2020-07-14 宁波三星智能电气有限公司 一种智能电表的上报方法
US10903977B2 (en) 2018-12-19 2021-01-26 Rankin Labs, Llc Hidden electronic file systems
US10848345B2 (en) 2018-12-31 2020-11-24 Hughes Network Systems, Llc Multi-protocol encapsulation traffic acceleration and optimization
US11526357B2 (en) 2019-01-21 2022-12-13 Rankin Labs, Llc Systems and methods for controlling machine operations within a multi-dimensional memory space
US11108671B2 (en) 2019-01-21 2021-08-31 Rankin Labs, Llc Systems and methods for processing network traffic using dynamic memory
WO2020154219A1 (en) 2019-01-21 2020-07-30 John Rankin Systems and methods for controlling machine operations
WO2020214752A1 (en) 2019-04-17 2020-10-22 John Rankin System and method for detecting hidden chemicals within objects in a non-invasive manner
WO2020214757A1 (en) 2019-04-17 2020-10-22 John Rankin Virtual memory pool within a network which is accessible from multiple platforms
US11729184B2 (en) 2019-05-28 2023-08-15 Rankin Labs, Llc Detecting covertly stored payloads of data within a network
US11372773B2 (en) 2019-05-28 2022-06-28 Rankin Labs, Llc Supporting a virtual memory area at a remote computing machine
US11055166B2 (en) 2019-05-28 2021-07-06 Rankin Labs, Llc Covertly storing a payload of data within a network
WO2021025729A1 (en) 2019-08-07 2021-02-11 John Rankin Determining proximity and attraction of objects within a coordinate system
WO2021025728A1 (en) 2019-08-07 2021-02-11 John Rankin System and method for indirect advertising
US11012361B2 (en) 2019-08-29 2021-05-18 Hughes Network Systems, Llc Managing transmission control protocol (TCP) traffic
CN111092645B (zh) * 2019-11-18 2022-04-19 航天恒星科技有限公司 一种卫星通信系统实时监控处理系统
US11863428B2 (en) * 2019-11-22 2024-01-02 Vmware, Inc. Dynamic route configuration and load balancing for edge gateways
US10911134B1 (en) * 2019-12-31 2021-02-02 Hughes Network Systems, Llc System and method for efficient and scalable VSAT real-time monitoring (VRTM)
US11699037B2 (en) 2020-03-09 2023-07-11 Rankin Labs, Llc Systems and methods for morpheme reflective engagement response for revision and transmission of a recording to a target individual
CN112769651B (zh) * 2021-01-13 2022-04-26 杭州迪普科技股份有限公司 一种tcp连接检测方法、装置及电子设备

Family Cites Families (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991004540A1 (en) * 1989-09-08 1991-04-04 Auspex Systems, Inc. Multiple facility operating system architecture
US5367643A (en) * 1991-02-06 1994-11-22 International Business Machines Corporation Generic high bandwidth adapter having data packet memory configured in three level hierarchy for temporary storage of variable length data packets
CA2072169A1 (en) * 1991-06-24 1992-12-25 Lih-Juan L. Danielson In-band/out-of-band alert delivery system
JPH0537456A (ja) * 1991-07-31 1993-02-12 Nec Corp 呼再接続方式
US5309562A (en) * 1991-08-19 1994-05-03 Multi-Tech Systems, Inc. Method and apparatus for establishing protocol spoofing from a modem
EP0574140A1 (de) 1992-05-29 1993-12-15 Hewlett-Packard Company Netadapter der das Netzkopfteil und Daten in verschiedenen Speicherpuffern speichert
US5432932A (en) * 1992-10-23 1995-07-11 International Business Machines Corporation System and method for dynamically controlling remote processes from a performance monitor
US5577105A (en) * 1994-03-11 1996-11-19 U.S. Robotics, Inc. Telephone call routing and switching techniques for data communications
US6658465B1 (en) * 1997-08-25 2003-12-02 Intel Corporation Method and apparatus for monitoring and controlling programs in a network
AU706160B2 (en) * 1994-06-08 1999-06-10 Hughes Electronics Corporation Apparatus and method for hybrid network access
US6701370B1 (en) * 1994-06-08 2004-03-02 Hughes Electronics Corporation Network system with TCP/IP protocol spoofing
BR9607641A (pt) * 1995-03-03 1998-05-26 Qualcomm Inc Método e aparelho para a monitorição de parâmetros de unidades por controle eletrônico para veículo
US5802286A (en) * 1995-05-22 1998-09-01 Bay Networks, Inc. Method and apparatus for configuring a virtual network
US6418324B1 (en) * 1995-06-01 2002-07-09 Padcom, Incorporated Apparatus and method for transparent wireless communication between a remote device and host system
US5987521A (en) * 1995-07-10 1999-11-16 International Business Machines Corporation Management of path routing in packet communications networks
US6618393B1 (en) * 1998-08-26 2003-09-09 3Com Corporation Method and apparatus for transparent support of network protocols with header translation
US5867661A (en) * 1996-02-15 1999-02-02 International Business Machines Corporation Method and apparatus of using virtual sockets for reducing data transmitted over a wireless communication link between a client web browser and a host web server using a standard TCP protocol
US5726979A (en) * 1996-02-22 1998-03-10 Mci Corporation Network management system
US5841980A (en) * 1996-05-15 1998-11-24 Rtime, Inc. Distributed system for communication networks in multi-user applications
US6219708B1 (en) * 1996-05-30 2001-04-17 Multi-Tech Systems, Inc. System for network resource management
US5996022A (en) * 1996-06-03 1999-11-30 Webtv Networks, Inc. Transcoding data in a proxy computer prior to transmitting the audio data to a client
US6039245A (en) * 1996-06-10 2000-03-21 Diebold, Incorporated Financial transaction processing system and method
US5805818A (en) * 1996-09-11 1998-09-08 Novell, Inc. System for acknowledging availability of neighbor node using data packet containing data that is ordinarily fowarded to neighbor node
US6003084A (en) * 1996-09-13 1999-12-14 Secure Computing Corporation Secure network proxy for connecting entities
US5961594A (en) * 1996-09-26 1999-10-05 International Business Machines Corporation Remote node maintenance and management method and system in communication networks using multiprotocol agents
US6038216A (en) * 1996-11-01 2000-03-14 Packeteer, Inc. Method for explicit data rate control in a packet communication environment without data rate supervision
US6012088A (en) * 1996-12-10 2000-01-04 International Business Machines Corporation Automatic configuration for internet access device
US6085243A (en) * 1996-12-13 2000-07-04 3Com Corporation Distributed remote management (dRMON) for networks
US6023456A (en) * 1996-12-23 2000-02-08 Nortel Networks Corporation Dynamic traffic conditioning
US5995830A (en) * 1997-04-09 1999-11-30 At&T Wireless Services Inc. System and method for processing dropped calls
US5949753A (en) * 1997-04-11 1999-09-07 International Business Machines Corporation Redundant internet protocol gateways using local area network emulation
US6134589A (en) 1997-06-16 2000-10-17 Telefonaktiebolaget Lm Ericsson Dynamic quality control network routing
US6151332A (en) * 1997-06-20 2000-11-21 Tantivy Communications, Inc. Protocol conversion and bandwidth reduction technique providing multiple nB+D ISDN basic rate interface links over a wireless code division multiple access communication system
US6081536A (en) * 1997-06-20 2000-06-27 Tantivy Communications, Inc. Dynamic bandwidth allocation to transmit a wireless protocol across a code division multiple access (CDMA) radio link
US6098108A (en) * 1997-07-02 2000-08-01 Sitara Networks, Inc. Distributed directory for enhanced network communication
US6006264A (en) * 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
US6385647B1 (en) * 1997-08-18 2002-05-07 Mci Communications Corporations System for selectively routing data via either a network that supports Internet protocol or via satellite transmission network based on size of the data
EP1016261B1 (de) * 1997-09-16 2003-11-12 TransNexus, Inc. Leitweglenkung-anordnung für internet telefonie
JPH11163947A (ja) * 1997-09-22 1999-06-18 Toshiba Corp ゲートウェイ装置、無線端末装置、ルータ装置および通信ネットワークのゲートウェイ制御方法
US6061341A (en) * 1997-12-16 2000-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Use of transmission control protocol proxy within packet data service transmissions in a mobile network
US6070073A (en) * 1997-12-18 2000-05-30 Nortel Networks Corporation Communication system and method for notification and call routing in a mobile satellite network
US6038594A (en) * 1998-02-02 2000-03-14 Loral Cyberstar, Inc. Internet communication system and method with asymmetric terrestrial and satellite links
US6415329B1 (en) * 1998-03-06 2002-07-02 Massachusetts Institute Of Technology Method and apparatus for improving efficiency of TCP/IP protocol over high delay-bandwidth network
US5987233A (en) * 1998-03-16 1999-11-16 Skycache Inc. Comprehensive global information network broadcasting system and implementation thereof
US6205481B1 (en) * 1998-03-17 2001-03-20 Infolibria, Inc. Protocol for distributing fresh content among networked cache servers
US6836483B1 (en) * 1998-06-24 2004-12-28 Research Investment Network, Inc. Message system for asynchronous transfer
US6640248B1 (en) * 1998-07-10 2003-10-28 Malibu Networks, Inc. Application-aware, quality of service (QoS) sensitive, media access control (MAC) layer
US6862622B2 (en) * 1998-07-10 2005-03-01 Van Drebbel Mariner Llc Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture
US6173324B1 (en) * 1998-07-15 2001-01-09 At&T Corp Method and apparatus for fault detection and isolation in data
US6327626B1 (en) * 1998-09-15 2001-12-04 Alteon Networks, Inc. Method and apparatus for MSS spoofing
US6856676B1 (en) * 1998-10-15 2005-02-15 Alcatel System and method of controlling and managing voice and data services in a telecommunications network
US6487170B1 (en) * 1998-11-18 2002-11-26 Nortel Networks Limited Providing admission control and network quality of service with a distributed bandwidth broker
US6466976B1 (en) * 1998-12-03 2002-10-15 Nortel Networks Limited System and method for providing desired service policies to subscribers accessing the internet
US6434134B1 (en) * 1998-12-11 2002-08-13 Lucent Technologies, Inc. Dynamic address assignment for wireless devices accessing packet-based wired networks
US6934255B1 (en) * 1999-02-02 2005-08-23 Packeteer, Inc. Internet over satellite apparatus
US6789118B1 (en) * 1999-02-23 2004-09-07 Alcatel Multi-service network switch with policy based routing
US6570867B1 (en) * 1999-04-09 2003-05-27 Nortel Networks Limited Routes and paths management
US6275470B1 (en) * 1999-06-18 2001-08-14 Digital Island, Inc. On-demand overlay routing for computer-based communication networks
US6480901B1 (en) * 1999-07-09 2002-11-12 Lsi Logic Corporation System for monitoring and managing devices on a network from a management station via a proxy server that provides protocol converter
US6748439B1 (en) * 1999-08-06 2004-06-08 Accelerated Networks System and method for selecting internet service providers from a workstation that is connected to a local area network
US6598034B1 (en) * 1999-09-21 2003-07-22 Infineon Technologies North America Corp. Rule based IP data processing
US6839355B1 (en) * 1999-12-14 2005-01-04 Stmicroelectronics, Inc. Cable modem link layer bridge
US6829221B1 (en) * 1999-12-27 2004-12-07 Nortel Networks Limited Border gateway protocol manager and method of managing the selection of communication links
US6742043B1 (en) * 2000-01-14 2004-05-25 Webtv Networks, Inc. Reformatting with modular proxy server
US8359405B1 (en) 2000-02-28 2013-01-22 John Border Performance enhancing proxy and method for enhancing performance
US6987741B2 (en) * 2000-04-14 2006-01-17 Hughes Electronics Corporation System and method for managing bandwidth in a two-way satellite system
US6519703B1 (en) * 2000-04-14 2003-02-11 James B. Joyce Methods and apparatus for heuristic firewall
US6823387B1 (en) * 2000-06-23 2004-11-23 Microsoft Corporation System and method for enhancing a server's ability to withstand a “SYN flood” denial of service attack
US6842463B1 (en) * 2000-07-14 2005-01-11 Nortel Networks Limited Automated and adaptive management of bandwidth capacity in telecommunications networks
US6993584B2 (en) * 2000-07-21 2006-01-31 Hughes Network Systems Method and system for improving network performance by utilizing path selection, path activation, and profiles

Also Published As

Publication number Publication date
IL144452A0 (en) 2002-05-23
US20020071436A1 (en) 2002-06-13
EP1175051A2 (de) 2002-01-23
DE60117723D1 (de) 2006-05-04
EP1175042B1 (de) 2006-03-08
EP1175045B8 (de) 2006-02-01
US20020010765A1 (en) 2002-01-24
US7596802B2 (en) 2009-09-29
EP1175064A3 (de) 2003-08-13
US6993584B2 (en) 2006-01-31
EP1175050A2 (de) 2002-01-23
EP1175064A2 (de) 2002-01-23
CA2353332A1 (en) 2002-01-21
CA2353329A1 (en) 2002-01-21
DE60114097D1 (de) 2006-03-02
CA2353295A1 (en) 2002-01-21
CA2353348A1 (en) 2002-01-21
EP1175064B8 (de) 2006-02-01
DE60112674D1 (de) 2005-09-22
DE60114942D1 (de) 2005-12-22
EP1175065B1 (de) 2005-08-17
CA2353345A1 (en) 2002-01-21
IL144429A0 (en) 2002-05-23
US20020013840A1 (en) 2002-01-31
DE60112674T2 (de) 2006-06-14
EP1175065A3 (de) 2003-08-13
EP1175064B1 (de) 2005-10-19
EP1175045B1 (de) 2005-11-16
EP1175042A2 (de) 2002-01-23
US20020038373A1 (en) 2002-03-28
DE60114942T2 (de) 2006-08-17
US20020034173A1 (en) 2002-03-21
EP1175050A3 (de) 2003-08-20
EP1175051A3 (de) 2003-08-13
EP1176788B1 (de) 2006-03-29
DE60117485D1 (de) 2006-04-27
IL144449A0 (en) 2002-05-23
CA2353328A1 (en) 2002-01-21
CA2353339A1 (en) 2002-01-21
EP1175051B1 (de) 2006-03-01
DE60116447T2 (de) 2006-09-28
EP1176788A2 (de) 2002-01-30
EP1175042A3 (de) 2003-08-13
EP1175045A2 (de) 2002-01-23
DE60117485T2 (de) 2006-10-12
EP1175066A3 (de) 2004-05-19
CA2353348C (en) 2008-04-08
IL144432A0 (en) 2002-05-23
EP1176788A3 (de) 2003-08-20
US20020010792A1 (en) 2002-01-24
IL144450A0 (en) 2002-05-23
CA2353325A1 (en) 2002-01-21
IL144453A0 (en) 2002-05-23
US7006480B2 (en) 2006-02-28
EP1175045A3 (de) 2003-08-27
EP1175050B1 (de) 2006-03-08
US7219158B2 (en) 2007-05-15
DE60117722D1 (de) 2006-05-04
EP1175065A2 (de) 2002-01-23
US20020016851A1 (en) 2002-02-07
IL144435A0 (en) 2002-05-23
EP1175066B1 (de) 2006-01-04
EP1175066A2 (de) 2002-01-23
US20020059435A1 (en) 2002-05-16
IL144451A0 (en) 2002-05-23
DE60116447D1 (de) 2006-03-30
DE60118305D1 (de) 2006-05-18
US7213077B2 (en) 2007-05-01

Similar Documents

Publication Publication Date Title
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE69727447T2 (de) Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung
DE112013000398B4 (de) Multisprung-Fehlerbehebung
DE60028897T2 (de) Verfahren und Vorrichtung zur Umschaltung zwischen zwei Netzwerkzugangstechnologien ohne Unterbrechung der aktiven Netzwerkanwendungen
DE602004010703T2 (de) Eine persistente und zuverlässige sitzung, die neztwerkkomponenten unter verwendung eines verkapselungsprotokolls sicher durchläuft
DE69919994T2 (de) Reduzierter paketkopf im drahtlosen nachrichtennetz
DE102013209118B4 (de) Beibehaltung und Änderung von Netzwerküberlastungsbenachrichtigungen während der Übertragung von Netzwerkdaten zwischen einem physischen Netzwerk und einem virtuellen Netzwerk
DE602005003142T2 (de) Vorrichtung und verfahren zur unterstützung von verbindungsherstellung in einem offload der netzwerkprotokollverarbeitung
DE60110974T2 (de) Abfangverfahren und -vorrichtung zur Kompensation nachteiliger Eigenschaften eines Kommunikationsprotokolls
DE19800772C2 (de) Verfahren und Vorrichtung zur Verbindung mit einem Paketaustauschnetz
DE602005005219T2 (de) Paketzusammenführung
DE60023019T2 (de) Verfahren und system zur ablösung oder regeneration von quittierungspaketen in adsl kommunikationen
DE60111551T2 (de) Mechanismus zur vervollständigung von nachrichten im speicher
DE60310645T2 (de) Verhinderung von Paketzerteilung
DE60029879T2 (de) System zur mehrschichtigen Bereitstellung in Computernetzwerken
DE60221557T2 (de) Methode und gerät zur adressenübersetzung für gesicherte verbindungen
DE602004008099T2 (de) Verfahren, system und artikel zur dynamischen echtzeit-stream-aggregation in einem netzwerk
DE60127978T2 (de) System und Verfahren zur Verteidigung gegen Denial-of-Service angriffe auf die Netzwerkknoten
DE602004011638T2 (de) Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem
DE60109959T2 (de) Verfahren um die effizienz eines datenstromes in einem kommunikationssystem zu erhöhen
DE60121755T2 (de) Ipsec-verarbeitung
DE19740547A1 (de) Sicherer Netzwerk-Proxy zum Verbinden von Entitäten
DE10205108A1 (de) System und Verfahren zum Zugreifen auf Softwarekomponenten in einer verteilten Netzwerkumgebung
EP1168753A1 (de) Verfahren und Mittel zur Übertragung von Daten unterschiedlicher Dienstqualität in Internet-Protokoll Datagrammen
DE602004012660T2 (de) System und Verfahren für einen nachrichtenorientierten anpassungsfähigen Datentransport

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee