DE60116447T2 - Verfahren und System zur Verbindungsbehandlung - Google Patents

Verfahren und System zur Verbindungsbehandlung Download PDF

Info

Publication number
DE60116447T2
DE60116447T2 DE60116447T DE60116447T DE60116447T2 DE 60116447 T2 DE60116447 T2 DE 60116447T2 DE 60116447 T DE60116447 T DE 60116447T DE 60116447 T DE60116447 T DE 60116447T DE 60116447 T2 DE60116447 T2 DE 60116447T2
Authority
DE
Germany
Prior art keywords
spoofing
tcp
connection
tsk
platform
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
DE60116447T
Other languages
English (en)
Other versions
DE60116447D1 (de
Inventor
John Poolesville Border
Douglas Gaithersburg Dillon
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 DE60116447D1 publication Critical patent/DE60116447D1/de
Application granted granted Critical
Publication of DE60116447T2 publication Critical patent/DE60116447T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

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

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung ist allgemein auf ein Verfahren und ein System zum Verbessern der Leistung eines Netzwerks gerichtet, und insbesondere auf ein Verfahren und ein System, das ein Spoofing ausführt, um die Netzwerkleistung zu verbessern.
  • Beschreibung 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 Service-Provider gestellt, um die Netzwerkleistung kontinuierlich zu verbessern. Um dieser Herausforderung gerecht zu werden, haben Service-Provider stark in die Aufrüstung 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 Service-Provider ebenfalls in die Entwicklung 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 das Augenmerk auf die Optimierung von TCP/IP-basierten Netzwerkabläufen gerichtet.
  • Als der 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 gewonnen.
  • Das Transmission Control Protocol (TCP) ist das dominierende Protokoll, das heutzutage im Internet verwendet wird. TCP wird von dem Internet-Protokoll (IP) getragen und wird in einer Vielzahl von Anwendungen verwendet, einschließlich einer zuverlässigen File-Übertragung und Internet-Webpage-Zugriffsanwendungen. Die vier Schichten des TCP-IP Protokoll-Programmpakets sind in 39 dargestellt. Wie dort dargestellt, umfasst die Verbindungsschicht (oder die Netzwerk-Schnittstellenschicht) 3710 Vorrichtungstreiber im Betriebssystem und entsprechende Netzwerk-Schnittstellenkarten. Zusammen handhaben die Vorrichtungstreiber und die Schnittstellenkarten Handware-Eigenschaften der physikalischen Schnittstellen mit Kabeln oder jeglicher Art von verwendeten Medium. Die Netzwerkschicht (die auch als Internetschicht bezeichnet wird) 3712 handhabt die Bewegung der Pakete im Netzwerk. Das Routen von Paketen bspw. findet in der Netzwerkschicht 3712 statt. IP, das Internet Control Message Protocol (ICMP) und das Internet Group Management Protocol (IGMP) können die Netzwerkschicht in dem TCP/IP-Protokoll-Programmpaket bereitstellen. Die Transportschicht 3714 liefert einen Datenfluss zwischen zwei Hosts für die Anwendungsschicht 3716 darüber.
  • In dem TCP/IP-Protokoll-Programmpaket gibt es zumindest zwei unterschiedliche Transportprotokolle. Das TCP und ein User Datagramm-Protokoll (UDP). TCP, das einen zuverlässigen Datenfluss zwischen zwei Hosts bereitstellt, ist hauptsächlich damit beschäftigt, Daten, die von der Anwendungsschicht 16 kommen, in entsprechend bemessene Segmente für die Netzwerkschicht 3712 darunter zu teilen, mit dem Bestätigen der empfangenen Pakete, dem Einstellen von Timeouts, um sicherzustellen, dass das andere Ende die gesendeten Pakete bestätigt, usw. Deshalb wird durch die Transportschicht 3714 ein zuverlässiger Datenfluss bereitgestellt, so dass die Anwendungsschicht 3716 diese Merkmale ignorieren kann. UDP andererseits stellt einen sehr viel einfacheren Dienst der Anwendungsschicht 3716 zur Verfügung. UDP sendet lediglich Datenpakete, die Datagramme genannt werden, von einem Host zum anderen, wobei es allerdings keine Garantie gibt, dass die Datagramme das andere Ende erreichen. Jede gewünschte Zuverlässigkeit muss durch die Anwendungsschicht 3716 hinzugefügt werden.
  • Die Anwendungsschicht 3716 handhabt die Details der bestimmten Anwendung. Es gibt viele allgemeine TCP/IP An wendungen, die nahezu jede Implementierung bereitstellen. Dies umfasst Telnet für einen entfernten Log-in, das File Transfer Protocol (FTP), das Simple Mail Transfer Protocol (SMTP) oder elektronische Post, das Simple Network Management Protocol (SNMP), das Hypertext Transfer Protocol (HTTP) und viele andere.
  • Wie zuvor beschrieben, stellt TCP eine zuverlässige sequentielle Auslieferung von Daten zwischen zwei IP-Hosts zur Verfügung. Die IP-Hosts bauen eine TCP-Verbindung auf, indem sie ein herkömmliches TCP Drei-Wege-Handshake verwenden und dann Daten übertragen, indem ein Fenster-basiertes Protokoll angesetzt 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.
  • 40 zeigt ein Beispiel des herkömmlichen TCP Drei-Wege-Handshakes zwischen den IP-Hosts 3820 und 3822. Zunächst sendet der IP-Host 3820, der die Übertragung zu dem IP-Host 3822 initiieren möchte, ein Synchronisations-(SYN)-Signal an den IP-Host 3822. Der IP-Host 3822 bestätigt das SYN-Signal von dem IP-Host 3820, indem eine SYN-Bestätigung bzw. Acknowledgement (ACK) gesendet wird. Der dritte Schritt des herkömmlichen TCP Drei-Wege-Handshakes ist die Herausgabe eines ACK-Signals von dem IP-Host 3820 zu dem IP-Host 3822. Der IP-Host 3822 ist nun bereit, Daten von dem IP-Host 3820 (und umgekehrt) zu empfangen. Nachdem die gesamten Daten ausgeliefert wurden, wird ein anderer Handshake (ähnlich dem Handshake, der mit der Initiierung der Verbindung beschrieben wurde) verwendete, 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 Internet-Protokolle 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 auf Kosten 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 Interoparabilität an Flexibilität.
  • Eine Alternative zu einem maßgeschneiderten Protokoll ist die Verwendung von leistungsverbessernden Proxies (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 die lokale Bestätigung von TCP-Datensegmenten, um dafür zu sorgen, dass der TCP-Datensender zusätzlich 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 einfach auf ein Erhöhen des Durchsatzes der TCP-Verbindungen fokussiert, entweder durch Benutzen größerer Fenster über die Verbindung oder durch Verwenden einer Komprimierung, um die Datenmenge zu reduzieren, die gesendet werden muss, oder beider.
  • Viele TCP-PEP-Implementierungen basieren auf einer TCP-ACK-Manipulation. Dies kann ein TCP-ACK-Beabstanden umfassen, wobei ACKs, die zusammengebü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.
  • Zusätzlich kann die Netzwerkleistung verbessert werden, indem Techniken eingesetzt werden, wie bspw. ein Verbindungsaufbau-Spoofing.
  • EP 0903905 A2 beschreibt eine Funkschichtkommunikationsvorrichtung, die die Leistung der Kommunikation verbessert, indem ein selektives Weiterleiten von TCP-Verbindungen in der TCP-Schicht ausgeführt wird.
  • WO 01/65805 A2 (Stand der Technik nach Art. 54(3) EPÜ) beschreibt eine Vorrichtung zur Verbesserung der Leistung eines Netzwerks, in dem ein selektives Spoofing der TCP-Verbindungen ausgeführt wird.
  • Basierend auf dem vorher Gesagten, gibt es ein klares Bedürfnis nach verbesserten Techniken zum Spoofen von Information. Deshalb ist ein Lösungsweg zum Verbessern der Netzwerkleistung unter Einsatz von Techniken, wie bspw. Spoofing, höchst wünschenswert. Insbesondere ist ein Lösungsweg zur Implementierung von Spoofing-Regeln innerhalb einer PEP-Umgebung höchst wünschenswert.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung spricht das zuvor erwähnte Bedürfnis an, ein Kommunikationssystem mit einer leistungsverbessernden Funktionalität bereitzustellen. Eine Spoofing-Vorrichtung kommuniziert mit einer leistungsverbessernden Proxy-(PEP)-Endpunktplattform, um die Plattform zu konfigurieren, indem Profile entsprechend der PEP-Endpunktplattform verwendet werden.
  • Die vorliegende Erfindung ist in den angehängten Ansprüchen definiert.
  • Ein Verfahren zum Routen bzw. Weiterleiten von Information in dem Kommunikationssystem, das eine Plattform und eine Spoofing-Vorrichtung umfasst, die konfiguriert ist, um eine Vielzahl von leistungsverbessernden Funktionen auszuführen, wird bereitgestellt. Das Verfahren umfasst den Empfang von Information von der Plattform und den Empfang von zumindest einem von Spoofing-Auswahlparametern und Spoofing-Parametern, wobei die Spoofing-Vorrichtung ein Profil aufrechterhält, das einen Spoofing-Auswahlparameter und/oder einen Spoofing-Parameter enthält und die Information entsprechend dem Profil weiterleitet.
  • Ein Kommunikationssystem umfasst eine Plattform, die konfiguriert ist, um leistungsverbessernde Funktionen bereitzustellen. Die Plattform umfasst ein Kommunikationssystem mit einer Plattform, die konfiguriert ist, um leistungsverbessernde Funktionen bereitzustellen, wobei die Plattform Information und einen Spoofing-Auswahl- und/oder einen Spoofing-Parameter liefert und wobei eine Spoofing-Vorrichtung mit der Plattform kommuniziert. Die Spoofing-Vorrichtung ist konfiguriert, um die Information und den Spoofing-Auswahlparameter und/oder den Spoofing-Parameter von der Plattform zu empfangen, wobei die Spoofing-Vorrichtung ein Profil besitzt, das die Spoofing-Auswahlparameter und/oder die Spoofing-Parameter spezifiziert, wobei das Kommunikationssystem konfiguriert ist, um die Information entsprechend dem Profil weiterzuleiten.
  • Eine Spoofing-Vorrichtung zum Überwachen eines Kommunikationssystems ist offenbart, die eine Plattform aufweist, die konfiguriert ist, um eine Vielzahl von leistungsverbessernden Funktionen auszuführen. Die Vorrichtung umfasst Mittel zum Empfang der Information und den Spoofing-Auswahlparametern und/oder den Spoofing-Parametern und Mittel zum Aufrechterhalten eines Profils, das die Spoofing-Auswahlparameter und/oder die Spoofing-Parameter enthält und Mittel zum Weiterleiten der Information entsprechend dem Profil.
  • Ein Computer-lesbares Medium, das eine oder mehrere Sequenzen einer oder mehrerer Befehle zum Weiterleiten von Information in einem Kommunikationssystem prägt, ist offenbart, wobei das System eine Plattform aufweist, die konfiguriert ist, um eine Vielzahl von leistungsverbessernden Funktionen aufzuführen. Das Computer-lesbare Medium trägt eine oder mehrere Sequenzen eines oder mehrerer Befehle, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, die Schritte des Empfangens der Information von der Plattform und des Empfangens der Spoofing-Auswahlparameter und/oder der Spoofing-Parameter auszuführen, wobei die Spoofing-Vorrichtung ein Profil aufrechterhält, das die Spoofing-Auswahlparameter und/oder die Spoofing-Parameter enthält und die Information entsprechend dem Profil weiterleitet.
  • Das Verfahren, das Kommunikationssystem, die Spoofing-Vorrichtung und das Computer-lesbare Medium sind ebenfalls in der Lage, maximale Segmentgrößen-Fehlanpassungen auszugleichen. Dieser Ausgleich kann durch ein dynamisches Neubemessen der Datensegmente erreicht werden, die die Information enthalten, die weiterzuleiten ist, oder kann eine Sperre des Drei-Wege-Handshake-Spoofings enthalten.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Eine vollständigere Würdigung der Erfindung und vieler zugehöriger Vorteile wird leicht erhalten und wird viel verständlicher 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-Endpunktplattformumgebung ist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 4 ein Diagramm eines TCP-Spoofing-Kerns (TSK) ist, der in der Umgebung von 2 verwendet wird;
  • 4A und 4B Flussdiagramme des Verbindungsaufbaus mit einem Drei-Wege-Handshake-Spoofing bzw. ohne ein Drei-Wege-Handshake-Spoofing sind;
  • 5 ein Diagramm eines PEP-Paketflusses zwischen zwei PEP-Endpunkten entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 6 ein Diagramm eines IP (Internet Protocol)-Paketflusses 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 verwendet werden;
  • 8 ein Diagramm der Schnittstellen eines PEP-Endpunktes ist, die als IP-Gateway implementiert sind, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 9 ein Diagramm der Schnittstellen eines PEP-Endpunktes ist, die als Multimedia Relay implementiert sind, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 10 ein Diagramm der Schnittstellen eines PEP-Endpunktes ist, der als ein Multimedia VSAT (Very Small Aperture Terminal) implementiert ist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 11 ein Diagramm der Schnittstellen eines PEP-Endpunktes ist, der in einer Bodenstation implementiert ist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 12 ein Diagramm einer TCP-Spoofing-Kernnachricht ist entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 13 ein Diagramm eines TCP-Verbindungsheaders ist entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 14 ein Diagramm von TSK-Partnern ist, die TSK-Backbone-Verbindungsidentifikationen lernen entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 15 ein Diagram ist, das die Zuordnung der TCP-Verbindungsidentifikationen entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 16 ein Diagramm eines TCB-Zugriffs über eine TCB-Abbildungstabelle ist entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 17 ein Diagramm ist, das den CCB-Zugriff über eine CCB-Hash-Funktion darstellt, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 18 ein Diagramm ist, das einen CCB-Zugriff über eine CCB-Abbildungstabelle entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 19 ein Diagramm des Verhältnisses zwischen einem CCB und einer TCB entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 20 ein Diagramm ist, das den Verbindungsaufbau entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 21 ein Diagramm des Starts der gleichen TCP-Verbindung ist, die die gleiche Backbone-Verbindung be nutzt, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 22 ein Diagramm eines Verbindungsaufbaus mit keiner lokalen CCB ist entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 23 ein Diagramm des Verbindungsaufbaus mit keinem Partner CCB entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 24 ein Diagramm des gleichzeitigen Starts ist, indem der letzte CCB verwendet wird, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 25 ein Dia gramm einer fehlenden Antwort von einem Ziel-Host ist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 26 ein Dia gramm einer fehlenden Antwort von einem Quellen-Host ist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 27 ein Diagramm eines gespooften Datenempfangs ist entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 28 ein Diagramm eines normalen Verbindungsabbruchs entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 29 ein Diagramm einer lokalen Host-<RST>-Segmentverbindungsabbruch entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 30 ein Diagramm eines gleichzeitigen normaler Verbindungsabbruchs entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 31 ein Diagramm einer gleichzeitigen <RST>-Segmentverbindungsbeendigung entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 32 ein Diagramm eines vorzeitigen Verbindungsneustarts entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 33 ein Dia gramm ist, das die Verbindungsbeendigung aufgrund fehlender Antwort von einem Host entsprechend einer Ausführungsform der vorliegenden Erf indung darstellt;
  • 34 ein Diagramm des Verhältnisses zwischen PEP-Endpunkten, TCP-Spoofing-Auswahlprofilen und TCP-Spoofing-Parameterprofilen entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 35 ein Diagramm einer selektiven Abbildung von TCP-Spoofing-Regeln auf TCP-Spoofing-Parameterprofile entsprechend einer Ausführungsform der vorliegenden Erfindung ist;
  • 36 ein Diagramm ist, das ein Teilen eines Segments in zwei oder mehrere kleinere Segmente entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 37 ein Diagramm ist, das die Reduzierung der maximalen Segmentgröße entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt;
  • 38 ein Diagramm eines Computersystems ist, das PEP-Funktionen ausführen kann entsprechend einer Ausführungsform der Erfindung;
  • 39 ein Diagramm der Protokollschichten des TCP/IP-Protokoll-Programmpakets ist;
  • 40 ein Diagramm eines herkömmlichen TCP Drei-Wege-Handshakes zwischen IP-Hosts ist.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • In der vorliegenden Beschreibung sind zum Zwecke der Erläuterung spezifische Details ausgeführt, um ein gründliches Verständnis der Erfindung zu liefern. Es versteht sich jedoch, dass die Erfindung ohne diese spezifischen Details ausgeführt werden kann. In einigen Beispielen sind gut bekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um die Erfindung nicht unnötigerweise unverständlich zu machen.
  • Obgleich die vorliegende Erfindung mit Bezug auf das Internet und das TCP/IP-Protokoll-Programmpaket diskutiert wird, ist die vorliegende Erfindung auch auf andere Paket-vermittelte Netzwerke und äquivalente Protokolle anwendbar.
  • 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 (bspw. Funknetzwerke, Mobilfunknetzwerke, etc.) oder ein terrestrisches Kommunikationssystem aufgebaut werden. Das Netzwerk-Gateway 140 ist ferner mit einer zweiten Gruppe von Hosts 150 ebenfalls über TCP-Verbindungen verbunden. 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.
  • Die Netzwerk-Gateways 120, 140 multiplexen ferner mehrere TCP-Verbindungen über eine einzelne Backbone-Verbindung; diese Fähigkeit reduziert die Menge an Verkehr von Bestätigungen bzw. Acknowledgements, der mit den Daten von den mehreren TCP-Verbindungen verknüpft ist, da ein einzelnes Backbone-Verbindungs-Acknowledgement verwendet werden kann. Die Multiplexing-Funktion 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 auszugleichen. 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 stellen einen priorisierten Zugang zu der Backbone-Verbindungskapazität 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; local area network) 220 und Schnittstellen 230 zu einem Wide-Area-Netzwerk (WAN). Bei dem in 1 gezeigten Beispiel 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 Routingmodul 240, ein Puffer-Managementmodul 250, ein Ereignis-Management-Modul 260 und ein Parametermanagement-Modul 270. Wie in 2 dargestellt, umfasst das Netzwerk-Gateway auch einen TCP-Spoofing-Kern (TSK) 280, einen Backbone-Protokoll-Kern (BPK) 282, einen Priorisierungs-Kern (PK) 284 und einen Pfadauswahl-Kern (PSK) 286. Diese vier 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. Das heißt die Plattformumgebung 210 führt Funktionen aus, die verschiedene PEP-Kerne 280, 282, 284, 286 nicht direkt ausführen können, da die Implementierung dieser 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 280, 282, 284, 286 portierbarer gemacht werden. Ein Beispiel einer plattformspezi fischen 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, bspw. die Zuweisung eines Steuerungsblocks für TCP-Spoofing, kann ebenfalls in der Plattformumgebung implementiert sein, um plattformspezifische Details vor dem Kern zu verstecken.
  • Bei einer beispielhaften Ausführungsform stellt die Plattformumgebung 210 den Task- bzw. Aufgaben-Kontext bereit, in dem die PEP-Kerne 280, 282, 284, 286 laufen. Bei einer anderen beispielhaften Ausführungsform laufen alle PEP-Kerne 280, 282, 284, 286 in dem gleichen Task-Kontext aus Effizienzgründen; dies ist jedoch nicht 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 bereitstellen, wie dies in 2 gezeigt ist. 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 und 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 zu einem Routen aller Daten durch die Plattformumgebung 210 (wie in 2 gezeigt).
  • Zusätzlich zu den PEP-Kernen 280, 282, 284 und 286 kann die PEP-Endpunktplattform 210 einen Datenkomprimierungskern (CK) 290 und einen Verschlüsselungskern (EK) 292 verwenden. Diese Kerne 280, 282, 284, 286, 290 und 292, wie zuvor beschrieben, erleichtern eine Kommunikation zwischen zwei Gruppen von Hosts 110, 150 durch Ausführen einer Vielzahl von leistungsverbessernden Funktionen entweder alleine oder in Kombination. Diese leistungsverbessernden Funktionen umfassen ein selektives TCP-Spoofing, ein Drei-Wege-Handshake-Spoofing, ein lokales Daten-Acknowledgement, ein Multiplexen der TCP-Verbindung auf die Backbone-Verbindung, eine Datenkomprimierung/-Verschlüsselung, Priorisierung und Pfadauswahl.
  • Ein selektives TCP-Spoofing wird von dem TSK 280 ausgeführt und umfasst einen Satz von Benutzer-konfigurierbaren Regeln, die verwendet werden, um zu bestimmen, welche TCP-Verbindungen gespooft werden sollten. Ein selektives TCP-Spoofing verbessert die Leistung, indem TCP-Spoofing-bezogene Ressourcen, wie bspw. Pufferplatz, Steuerungsblöcke etc., nicht für TCP-Verbindungen verbraucht werden, für welche TCP-Verbindungen der Benutzer festgelegt hat, dass ein Spoofing nicht vorteilhaft ist oder nicht erforderlich ist, und in dem die Verwendung von angepassten Parametern für TCP-Verbindungen unterstützt wird, die gespooft werden.
  • Insbesondere unterscheidet der TSK 280 unter vielen TCP-Verbindungen basierend auf den Anwendungen, die sie benutzen. Das heißt, dass der TSK 280 unter diesen TCP-Verbindungen unterscheidet, um festzulegen, welche Verbindung gespooft werden sollte, sowie die Art und Weise, in der die Verbindungen gespooft wird; bspw. 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. Im Ergebnis sichert der TSK 280 TCP-Spoofing-Ressourcen nur für jene TCP-Verbindungen, für die ein hoher Durchsatz oder eine 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 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 Port-Nummern jedem Anwendungstyp zugeordnet. Welche TCP-Port-Nummern gespooft und nicht gespooft werden sollten, kann in dem TSK 280 gespeichert werden. Der TSK 280 ist ebenfalls neu konfigurierbar, um es einem Benutzer oder einem Operator zu erlauben, die TCP-Port-Nummern neu zu konfigurieren, die gespooft und nicht gespooft werden sollen. Der TSK 280 erlaubt es auch einem Benutzer oder Operator, zu steuern, welche TCP-Verbindungen gespooft werden sollen, basierend auf anderen Kriterien. Allgemein kann eine Entscheidung, ob eine TCP-Verbindung gespooft wird, auf jedem Feld innerhalb eines TCP-Pakets basieren. Der TSK 280 erlaubt es einem Benutzer, zu spezifizieren, welche Felder geprüft werden sollen und welche Werte in diesen Feldern TCP-Verbindungen identifizieren, die gespooft oder nicht gespooft werden sollen. Ein anderes Beispiel einer möglichen Benutzung dieser Fähigkeit besteht darin, dass der Benutzer oder Operator die IP-Adresse des TCP-Pakets auswählt, um zu steuern, für welche Benutzer-TCP-Spoofing ausgeführt werden soll. Der TSK 280 erlaubt es auch einem Benutzer, mehrere Felder zur gleichen Zeit zu betrachten. Als Ergebnis ermöglicht der TSK 280 einem Benutzer oder Operator, mehrere Kriterien zur Auswahl der zu spoofenden TCP-Verbindungen zu verwenden. Beispielsweise kann durch Auswahl sowohl der IP-Adresse als auch der TCP-Port-Nummernfelder der Systemoperator ein TCP-Spoofing nur für spezifische Anwendungen von spezifischen Benutzern erlauben.
  • Die Benutzer-konfigurierbaren 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-Port-Nummern (die sowohl auf die TCP-Ziel- und Quell-Port-Nummern 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ätzliche zur Unterstützung an der selektiven TCP-Spoofing-Regeln für jedes dieser Kriterien UND-ODER-Kombinationsoperatoren verwendet werden, um die Kriterien miteinander zu verknüpfen. Beispiels weise 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, anwenden, 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 werden, 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 Hochgeschwindigkeitsverbindung ü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 TCP-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 Verbindungsanforderung über die Backbone-Verbindung 130 (1) aufzubauen. Dies erlaubt es dem originären IP-Host (bspw. 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 110 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ötig 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-Webpage-Zugangs- bzw. Zugriffsanwendung. Mit dem Drei-Wege-Handshake-Spoofing kann eine Anforderung eines IP-Hosts, eine Webpage 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 Webpage herunterzuladen.
  • Mit einer lokalen Datenbestätigung bzw. einem lokalen Daten-Acknowledgement bestätigt der TSK 280 in dem Netzwerk-Gateway 120 (bspw.) lokal Datensegmente, die von dem IP-Host 110 empfangen werden. Dies ermöglicht es, dass der sendende IP-Host 110 zusätzliche Daten sofort sendet. Noch wichtiger 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 Acknowledgement-Verkehrs, 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 (bspw. 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 ein Kompressionstyp 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. Beispielhaf te Datenkomprimierungsalgorithmen sind in US-Patenten 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ätswert 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 284 benutzt ebenfalls benutzerdefinierte Regeln, um zu steuern, wie viel der Kapazität der Backbone-Verbindung 130 für jeden Prioritätswert verfügbar ist. Beispielhafte Kriterien, die verwendet werden können, um die Priorität zu bestimmen, umfassen Folgende: Ziel-IP-Adresse; Quell-IP-Adresse; IP next protocol; TCP-Port-Nummern (die sowohl für TCP-Ziel- als auch Quell-Port-Nummern angewendet werden kön nen); UDP-Port-Nummern (die sowohl für die UDP-Ziel- als auch Quell-Port-Nummern 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 verknüpfen. 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 passenden Regel genommen wird. Eine Default-Regel kann ebenfalls eingestellt werden, die die Aktion definiert, die für IP-Pakete zu verwenden ist, die keine der definierten Regeln erfü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 fallen gelassen werden sollen, wenn einer oder mehrere Hauptpfade ausfallen. Pfadauswahlparameter 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 auftrennend 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 dem PK 284 eingestellt (sollte das üblichste Kriterium sein): Ziel-IP-Adresse; Quell-IP-Adresse; IP next protocol; TCP-Port-Nummern (was sowohl auf die TCP-Ziel- als auch Quell-Port-Nummern angewendet werden kann); UDP-Port-Nummern (was sowohl auf die UDP-Ziel- als auch Quell-Port-Nummern angewendet werden kann); und das IP differentiated services (DS) Feld. Ähnlich zu dem selektiven TCP-Spoofing und der Priorisierung kann der PSK 284 einen Pfad bestimmen, indem 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-Daten 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 PSK 286 Regeln anwenden, die von dem Operator spezifiziert sind, wobei die Aktion der ersten passenden Regel herangezogen 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.
  • Rein beispielhaft 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 verallgemei nert werden derart, dass die Pfadauswahlregel bis zu N Pfade auswählen kann, wobei der N-te Pfad 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 beiden 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, wobei die Daten basierend auf den konfigurierten Komprimierungsregeln geeignet komprimiert werden. Die Priorität der TCP-Verbindung wird bestimmt, wenn die Verbindung aufgebaut ist. Der BPK 282 kann die Verbin dung 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 Ressourcen 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 den unterschiedlichen Verbindungen zugewiesen werden; 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 darstellt. 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-Hosts 110 empfängt und Daten zu diesem sendet. Aufgrund der Schichtarchitektur des Protokolls isoliert die TCP-Spoofing-Anwendung 101 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 Netzwerk-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 für die Festlegung der Priorität der IP-Pakete und dann die Belegung der Übertragungsmöglichkeiten basierend auf der Priorität. Der PK 284 kann ebenfalls den Zugriff auf den Pufferplatz steuern, indem die Warteschlangengröße gesteuert wird, die mit dem Senden und Empfangen von IP-Paketen verknüpft ist. Der PSK 286 bestimmt, welchen Pfad ein IP-Paket nehmen soll, um sein Ziel zu erreichen. Der von dem PSK 286 ausgewählte Pfad 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 Hauptpfade ausfallen. Es ist anzumerken, dass die zuvor erwähnte Anordnung rein beispielhaft ist; andere Anordnungen wären für den Fachmann ebenfalls erkennbar.
  • 4A und 4B zeigen Flussdiagramme des Aufbaus einer gespooften TCP-Verbindung, indem ein Drei-Wege-Handshake-Spoofing verwendet wird, bzw. indem kein Drei-Wege-Handshake-Spoofing verwendet wird. Der TCP-Spoofing-Kern 280 baut eine gespoofte TCP-Verbindung auf, wenn ein TCP <SYN>-Segment von dessen lokalem LAN empfangen wird oder wenn eine Connection Request bzw. Verbindungsanforderungsnachricht von dessen TSK-Peer bzw. Partner empfangen wird. Es ist anzumerken, dass das Drei-Wege-Handshake-Spoofing gesperrt werden kann, um einen End-zu-End-Maximum-Segment-Größen(MSS)-Austausch zu unterstützen, der nachfolgend genauer beschrieben werden wird. Zum Zwecke der Erläuterung wird der gespoofte TCP-Verbindungsaufbauprozess mit Bezug auf einen lokalen Host 400, einen lokalen PEP-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 kein CCB gibt, prüft die Umgebung 402, ob das TCP-Segment ein <SYN>-Segment ist, das zu einem lokalen Ziel gesendet werden soll. 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 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 aufzubauen, der verwendet werden sollte, um diese gespoofte TCP-Verbindung zu tragen. In der beispielhaften Ausführungsform wird der Partnerindex 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-(CB)-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 TCP-Verbindungs-Steuerungsblock-(CCB)-Ressourcengrenze liegt. Die CCB-Ressourcengrenze ist der kleinere Wert der lokalen Anzahl der 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 eine eindeutige TCP-Verbindungs-Identifikation (bspw. ein freier CCB-Abbildungstabelleneintragsindex) der Verbindung zu und ruft die Umgebung 210 auf, einen TCP-Verbindungs-Steuerungsblock für die Verbindung zu belegen.
  • Der TSK 280 des PEP-Endpunkts 402 gibt das TCP-<SYN>-Segment zurück an die Umgebung 210, um ungespooft weitergeleitet zu werden, 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. Falls es ferner keinen CCB-Verbindungs-Tabelleneintrag 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 Ope rator 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 alle 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 (bspw. die maximale Segmentgröße, die von dem Host angezeigt wird (falls kleiner als der konfigurierte MSS), die anfängliche Reihenfolgennummer, etc.) aus dem TCP-<SYN>-Segment kopiert und in den CCB gespeichert. Es ist zu bemerken, dass die Quell- und die Ziel-IP-Adresse und die Quell- und die Ziel-TCP-Port-Nummer bereits in den CCB von der Plattformumgebung 402 abgelegt wurden, als der CCB belegt wurde; die Umgebung 402 benutzt diese Information, um CCB-Hash-Funktions-Kollisionen zu verwalten.
  • Nach dem Belegen und dem Einstellen 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 seinen TSK-Partner, der 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, bspw. die Quell- und Ziel-IP-Adressen, die Quell- und Ziel-TCP-Port-Nummern, der MSS-Wert, etc., mit Ausnahme der Felder, die nur lokale Bedeutung haben, wie bspw. die anfängliche Reihenfolgennummer. (Die IP-Adressen und die TCP-Port-Nummer werden in einen TCP-Verbindung-Header 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. TSK 280 des PEP-Endpunkts 402 führt Schritt 405 gleichzeitig mit dem Schritt des Sendens der Connection-Request-Nachricht bzw. der Verbindungs-Anforderungsnachricht (d.h. Schritt 403) aus, falls ein Drei-Wege-Handshake-Spoofing freigegeben ist. Andernfalls 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 gesperrt 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 emp fangen 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 als der MSS-wert ist, 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-Partner 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 (Schritt 413) vor dem Empfang einer CE-Nachricht von dem Partner-TSK des PEP-Endpunkts 404.
  • Jedoch akzeptiert der TSK 280 des PEP-Endpunkts 402 keine Daten von seinem TSK-Partner des PEP-Endpunkts 404 bis die CE-Nachricht emfangen wurde. TSK 280 des PEP-Endpunkts 402 leitet jegliche Daten, die von seinem TSK-Partner des PEP-Endpunkts 404 empfangen wurden, nicht 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) empfangen wurde, belegt der TCP-Spoofing-Kern 280 ein CCB für die Verbindung und speichert dann alle relevanten Informationen aus der CR-Nachricht in den 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, wie in 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, die vom TSK 280 empfangen wurden, an den Host weiter, in 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, in Schritt 427. Gleichzeitig mit dem Acknowledgement werden die Daten an den TSK 280 des PEP-Endpunkts 402 gesendet (Schritt 429).
  • Zu diesem Zeitpunkt ist der TSK 280 bereit, Daten aus jeder Richtung zu empfangen und weiterzuleiten. Der 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 gesetzt und dann gesendet, nachdem das <ACK>-Segment in Antwort auf das <SYN,ACK>-Segment gesendet wurde (wenn es ankommt).
  • Es sei nun auf die 48 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, wie 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 weiter (Schritt 453). Als Nächstes sendet er, in Schritt 455, 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 in Schritt 459 eine CE-Nachricht an den lokalen PEP-Endpunkt 402 weiter, der darauffolgend 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, in Schritt 465. Sobald der PEP-Endpunkt 404 die Daten von dem entfernten Host 404 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 (in Schritt 475).
  • In Antwort auf die empfangenen Daten (in Schritt 473) gibt der lokale PEP-Endpunkt 402 ein <ACK>-Segment in Schritt 477 ab und leitet die Daten in einer TD-Nachricht an den entfernten PEP-Endpunkt 404 in 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, in 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 IP-Pakete, als Beispiel. 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, das in 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-Protokollverbindungen 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 geeignet). 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-Protokollkern 501c gereicht und dann auf die geeignete Backbone-Protokollverbindung gemultiplext. Der Backbone-Protokollkern 501c gewährleistet, dass die Daten über das WAN ausgeliefert werden.
  • Für 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) (wenn geeignet) weitergeleitet. IP-Pakete, die für den Endpunkt 503 adressiert sind, die einen Next-Protocol-Header-Typ „PBP" haben, werden zu dem Backbone-Protokollkern 503c geleitet. Der Backbone-Protokollkern 503c extrahiert die TCP-Daten und leitet sie an den Spoofing-Kern 503b zur Übertragung auf die geeignete gespoofte TCP-Verbindung weiter. Zusätzlich zum Übertragen der TCP-Daten wird die Backbone-Protokollverbindung 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 dem Verbindungsabbruch zu koordinieren.
  • Eine Priorisierung kann an vier Punkten an dem System 500 angewendet werden, nämlich 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 niedere 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 zueinander 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 allgemein und mit Bezug auf das TCP-Spoofing.
  • Auf der Hub (oder lokalen) Seite kann der PEP-Endpunkt 501 in einem Netzwerk-Gateway (bspw. 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, bspw. einem Satellitenterminal, wie bspw. ein Multimedia-Relay, Multimedia-VSAT oder einer Personal Earth Station (PES) Remote.
  • Die Architektur des Systems 400 stellt eine Anzahl von Vorteilen bereit. Zunächst kann ein TCP-Spoofing sowohl in Upstream- als auch in Downstream-Richtung erreicht werden. Zusätzlich unterstützt das System ein Spoofing des TCP-Verbindungsstarts, und ein selektives TCP-Spoofing nur mit aktuell gespooften Verbindungen, die vom Spoofing profitieren können. Ferner ermöglicht das System 500 eine Priorisierung unter den gespooften TCP-Verbindungen für einen Zugriff auf die TCP-Spoofing-Ressourcen (bspw. 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, in dem Kontrollblock-Ressourcenanforderungen minimiert werden und eine effiziente Fehlerentdeckung für verloren gegangene Pakete bereitgestellt wird. Das System 500 liefert ebenfalls einen Feedback-Mechanismus, um maximale Pufferplatzressourceneffizienz zu unterstützen. Ferner stellt das System 500 einen reduzierten Acknowledgment-Verkehr bereit, in dem 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 feststellt, dass die Pakete tatsächlich TCP-Segmente sind, bestimmt dann der TSK 280, ob die TCP-Verbindung gespooft werden soll. Falls jedoch der PEP-Endpunkt 210 feststellt, dass die Pakete keine TCP-Segmente sind, bearbeitet 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 anzumerken, dass der BPK 282 keine ungespooften IP-Pakete verarbeitet; das heißt, dass die Pakete direkt zum PK 284 fließen. Wie in 6 zu sehen, wird der Verkehr, der von der WAN-Schnittstelle 230 empfangen wird, geprüft, um zu erkennen, ob der Verkehr ein richtiges PBP-Segment (Entscheidungspunkt D) für den bestimmten PEP-Endpunkt 210 ist; falls dies bestätigt wird, werden dann die Pakete zu dem BPK 282 und dann dem TSK 280 gesendet.
  • Eine Routing-Unterstü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 Priorisierung 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 Routing-Funktion.
  • 7 zeigt das Verhältnis zwischen den PEP-Endpunkten und den PEP-Endpunktprofilen entsprechend einer Ausführungsform der vorliegenden Erfindung. PEP-Parameter sind hauptsächlich konfiguriert über einen Satz 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, 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 ein Netzwerkmanagementkonstrukt; intern verarbeitet ein PEP-Endpunkt 705 einen Satz von Parametern, die über ein oder mehrere Files bzw. Dateien empfangen werden.
  • Wann immer der PEP-Endpunkt 705 neue Parameter empfängt, vergleicht die Plattformumgebung die neuen Parameter mit den vorhandenen Parametern, findet heraus, ab 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 Vielzahl 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–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–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 verwen deten 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 ein 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 zum 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, beispielsweise über 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 besitzt 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 Hubseite: 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 Hubseite, 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 gleichzeitig, um IP-Pakete zu und von den PEP-Endpunkten auf der Hubseite zu senden und zu empfangen. 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 Hubseite.
  • 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 ein oder mehrere lokale serielle PPP-Schnittstellen kann verwendet werden. Der Multimedia-VSAT 1001 besitzt zwei WAN-Schnittstellen 1005, um IP-Pakete zu den PPP-Endpunkten auf der Hubseite zu senden: 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 Hubseite, der VSAT-Outroute und beiden LAN-Schnittstellen 1003. Eine Multimedia-VSAT 1003 kann die Verwendung von beiden LAN-Schnittstellen 1003 zur gleichen Zeit unterstützen, um IP-Pakete zu und von den PEP-Endpunkten auf der Hubseite 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 Hubseite.
  • 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 Hubseite zu senden, eine ISDN-Inroute, eine LAN-Schnittstelle, eine serielle VADB-Schnittstelle, eine Frame-Relay serielle Schnittstelle und eine IP serielle Schnittstelle, und bis zu fünf vorhandene Schnittstellen zum Empfangen von IP-Paketen von den PEP-Endpunkten auf der Hubseite: 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.
  • Der TSK 280 ist verantwortlich für alle Funktionen, die das TCP-Spoofing betreffen. Der TSK 280 umfasst zumindest zwei Basisteile, einen TCP-Stack 303 und eine TCP-Spoofing-Anwendung 301, die in 3 dargestellt ist. Der TCP-Stack 303 kann dafür verantwortlich sein, mit den TCP-Stacks der IP-Hosts zu interagieren, die mit den LAN-Schnittstellen 803, 903, 1003, 1103 der PEP-Endpunkte verbunden sind. Der TCP-Stack 303 kann auch das TCP-Protokoll implementieren, das die passenden TCP-Zustandsmaschinen aufweist, und die gespooften TCP-Verbindungen abschließen. Die TCP-Spoofing-Anwendung 301 kann auf dem TCP-Stack 303 sitzen und als Anwendung agieren, die Daten von den IP-Host-Anwendungen empfängt und zu diesen sendet. Die TCP-Spoofing-Anwendung 301 kann die Details des TCP-Spoofings gegenüber dem TCP-Stack 303 so weit wie möglich verstecken, was ermöglicht, dass der TCP-Stack 303 so weit wie möglich wie ein Standard-TCP-Stack funktioniert. Die TCP-Spoofing-Anwendung 301 kann ebenfalls für die Kopplung mit dem BPK 282 verantwortlich sein.
  • Die TSK 280 Parameter können über Profile konfiguriert sein. Die Backbone-Verbindungs-Parameter können konfiguriert sein, indem die Verbindungsprofile verwendet werden. Die TCP-Spoofing-Auswahlparameter und die Spoofing-Parameter können in den TCP-Spoofing-Auswahl- bzw. TCP-Spoofing-Parameter-Profilen definiert sein. Die TCP-Spoofing-Auswahl-Profile können definieren, welche TCP-Spoofing-Parameter-Profile verwendet werden sollen. Die anderen TSK 280 Parameter und welche TCP-Spoofing-Auswahl-Profil verwendet werden soll, kann in den PEP-Endpunkt-Profilen 701, 703 definiert sein. Welches PEP-Endpunkt-Profil 701, 703 von einem PEP-Endpunkt 705 verwendet werden soll, kann als Teil einer individuellen spezifischen Konfiguration eines PEP-Endpunkts konfiguriert sein.
  • Profile können ein Netzwerkmanagementkonstrukt sein. Der TSK 280 kann seine Parameter empfangen mit Ausnahme der Parameter, die die Backbone-Verbindungen betreffen, als eine Datenstruktur, die zu dem TSK 280 durch die Plattformumge bung 210 geführt wird. Die Backbone-Verbindungsparameter können zu dem TSK 280 über die Plattformumgebung 210 auf einer Backbone-Verbindungsbasis geleitet werden. Die Plattformumgebung 210 wiederum kann die Parameter über Dateien bzw. Files empfangen, die von einem Netzwerkmanager gesendet werden.
  • Der TSK 280 kann Parameter von der Plattformumgebung 210 beim Start empfangen und wann immer die Plattformumgebung 210 neue Parameter empfängt, die die Änderungen der TSK 280 bezogenen Parameter enthalten. Wenn der TSK 280 neue Parameter empfängt, kann er die neuen Parameter mit den existierenden Parametern vergleichen und dann eine Aktion starten, um die neuen Parameter basierend darauf, welche Parameter verändert wurden, zu installieren. Alle Parameter können dynamisch installiert werden. In einigen Fällen werden die Änderungen nur die neuen TCP-Verbindungen und nicht die TCP-Verbindungen beeinflussen, die ja bereits gespooft werden. Andererseits könnten einige Parameteränderungen, wie beispielsweise das Löschen einer Backbone-Verbindung, erfordern, dass die existierenden gespooften TCP-Verbindungen beendet werden. Falls das TCP-Spoofing gesperrt wird, können die TCP-Verbindungen, die bereits gespooft werden, beendet werden, da alle Backbone-Verbindungen geschlossen werden, wenn die Plattformumgebung 210 die Prozedur zum Herunterfahren des TSK 280 veranlasst.
  • Die TSK-Partner können Nachrichten tauschen, um ihre Spoofing-Funktionen zu koordinieren. 12 zeigt ein beispielhaftes Format einer TSK-Nachricht 1200. Die Tabellen A und B beschreiben beispielhafte Nachrichtenfelder in 12. Andere Nachrichtenformate können verwendet werden, falls von einer bestimmten Anwendung gefordert. Falls beispielsweise ein Partner in einer Umgebung verwendet wird, wo mehr Backbone-Verbindungen existieren können als von einer 16-Bit-Verbindungsidentifikation unterstützt werden, kann eine 32-Bit-Verbindungsidentifikation statt dessen implementiert werden. Die Tabelle C listet beispielhaft Grundcodes auf, die mit verschiedenen Nachrichtentypen verknüpft sind. Grundcodes können über alle Nachrichtentypen eindeutig sein, um eine Problembehebung zu erleichtern.
  • Tabelle A – Beispielhafte TSK-Nachrichten-Feld-Beschreibungen
    Figure 00540001
  • Figure 00550001
  • Tabelle B – Beispielhafte TCP-verbindungsbezogene TSK
    Figure 00550002
  • Figure 00560001
  • Figure 00570001
  • Tabelle C – Beispielhafte Beendigungs-Grundcodes
    Figure 00570002
  • 13 zeigt ein beispielhaftes Format eines TCP-Verbindungs-Headers 1201. Die Tabelle D beschreibt beispielhafte Felder des TCP-Verbindungs-Headers 1201. Ein TCP-Verbindungs-Header 1201 kann die IP-Adressen 1302, 1304 und die TCP-Port-Nummern 1306, 1308 enthalten, die eindeutig eine TCP-Verbindung identifizieren. Die TCP-Verbindungs-Header 1201 können in einer TSK-Nachricht enthalten sein, wenn die TCP- Verbindungs-Identifikation, die als das Zielverbindungs-Identifikationsfeld in der TSK-Nachricht verwendet wird, gleich 0 × FFFF gesetzt ist. Ein TCP-Verbindungs-Header 1201 muss nicht in einer Daten- oder Urgent-Datennachricht verwendet werden, solange nicht die Datensegmentgröße zumindest 12 Bytes (die Größe eines beispielhaften Headers) kleiner ist als die ausgewählte maximale Segmentgröße, die für die TCP-Verbindung benutzt wird. Dies kann gewährleisten, dass der TSK 280 nicht versehentlich eine TSK-Nachricht erzeugt, die größer ist als sie durch den Pfad gehandhabt werden kann, der von der Backbone-Verbindung zu dem TSK-Partner verwendet wird. Die TCP-Verbindungs-Header 1201 können ebenfalls in TSK-Steuerungsnachrichten enthalten sein, um dabei zu helfen, zu gewährleisten, dass eine Steuerungsnachricht auf die richtige TCP-Verbindung abgebildet wird. Dies kann für einige Typen von TSK-Steuerungsnachrichten nicht erforderlich sein, aber das Enthalten des Headers kann die Steuerungsnachrichtverarbeitung vereinfachen und kann auch dabei helfen, Probleme zu suchen.
  • Es gibt zumindest zwei Typen von Verbindungsidentifikationen, die von dem TSK 280 verwendet werden. Eine TSK-Partner-Verbindungsidentifikation (TID) kann jeder TSK-Backbone-Verbindung zugeordnet werden. Eine TCP-Verbindungs-Identifikation (CID) kann jeder gespooften TCP-Verbindung zugeordnet werden. Beispielhafte TIDs und CIDs sind nachfolgend beschrieben.
  • Tabelle D – Beispielhafte TCP-Verbindungs-Header-Feldbeschreibungen
    Figure 00590001
  • 14 zeigt das Lernen der TSK-Backbone-Verbindungs-Identifikationen durch einen TSK-Partner, wie nachfolgend beschrieben.
  • Ein TSK 280, der nicht mehr als einen konfigurierten TSK-Partner hat, kann eine eindeutige lokale TSK-Partner-Verbindungs-Identifikation (TID) ungleich Null verwenden für jeden seiner TSK-Partner. Die TID kann durch die Plattformumgebung 210 zugeordnet werden, um zu ermöglichen, dass sie der Identifikation der Umgebung für den Partner entspricht. Der zugeordnete Wert kann als ein Index in eine Tabelle von TSK- Partner-Steuerungsblockzeigern verwendet werden. Die lokale TID 1402, 1404 kann von dem TSK 280 verwendet werden als Quellverbindungs-ID-Wert in Nachrichten, die nicht mit einem engeren TCP-Verbindung verknüpft sind.
  • Da es eine 1:1-Abbildung zwischen den TIDs und den Backbone-Verbindungen (durch Definition) geben kann, kann der Handle einer Backbone-Verbindung, die von der Plattformumgebung 210 zugeordnet ist, einfach als TID der Backbone-Verbindung benutzt werden. Die TID kann als Index in eine Tabelle der TSK-Backbone-Verbindungs-Steuerungsblock (TCB)-Zeiger verwendet werden, die TCB-Abbildungstabelle 1406. Die lokale ID 1402, 1404 wird von dem TSK als Quellverbindungs-ID-Wert in den Nachrichten verwendet, die nicht mit einer bestimmten TCP-Verbindung verknüpft sind, bspw. TSK-Partner-Parameter (TPP)-Nachrichten. Der TSK 280 lernt die TID, die für die Backbone-Verbindung von seinem TSK-Partner verwendet wird, wenn er eine TPP-Nachricht von seinem Partner empfängt, und benutzt diesen Wert als Zielverbindungs-ID-Wert in Nachrichten, die über die Backbone-Verbindung gesendet werden, die nicht irgendeiner bestimmten TCP-Verbindung zugeordnet sind. (Das Lernen der TID, die von einem TSK-Partner verwendet wird, ist kein kritisches Erfordernis für die Kommunikation. Das Lernen der Partner-TID wird nur als Leistungsoptimierung gemacht, um ein einfaches Abbilden von Nachrichten TCBs zu ermöglichen und für eine leichtere Problemsuche. Es sei angemerkt, dass 0 × FFFF nicht als ein TID benutzt werden sollte, da 0 × FFFF als Zielverbindungs-ID gesendet wird, wenn der TSK 280 noch nicht die lokale TID seines TSK-Partners gelernt hat.
  • Wenn ein TSK 280 eine Nachricht für eine TCP-Verbindung vor dem Erlernen der TCP CID weiterleiten muss, die von seinem TSK-Partner der Verbindung zugeordnet ist, kann der TSK 280 das Zielverbindungs-ID-Feld in der TSK-Nachricht auf 0 × FFFF (beispielhaft) setzen. (Damit ist 0 × FFFF keine gültige TCP CID.) Und falls dies so getan wird, wird die Größe der Nachricht nicht die ausgewählte maximale Segmentgröße der TCP-Verbindung übersteigen, und kann der TSK 280 ebenfalls einen TCP-Verbindungs-Header 1201 enthalten. Es sei angemerkt, dass dies nicht notwendigerweise nur auf die Connection-Request-Nachrichten anwendbar ist. Wenn der Drei-Wege-Handshake gespooft wird, kann der TSK 280 die Datennachrichten an seinen TSK-Partner vor dem Empfangen der Connection-Established-Nachricht weiterleiten müssen. Falls ein Fehler auftritt, muss der TSK 280 eine Connection-Terminated-(CT)-Nachricht an seinen TSK-Partner vor dem Abbruch einer Verbindung senden.
  • Wenn der TSK 280 eine TSK-TCP-Verbindungsbezogene Nachricht mit einer Zielverbindungs-ID von 0 × FFFF empfängt, kann der TSK 280 den TCP-Verbindungs-Header 1201 verwenden, falls vorhanden, und die Quellverbindungs-ID 1212 in der Nachricht, kombiniert mit der Information, die angibt, von welcher Backbone-Verbindung die TSK-Nachricht empfangen wurde (d.h. der Handle, der dem TSK 280 von der BPK 282 mit der Nachricht übergeben wurde), um die geeignete CCB für die Verbindung zu finden. Die Information in dem TCP-Verbindungs-Header 1201 kann verwendet werden, um die CCB zu finden, indem eine Hash-Funktion benutzt wird. Wenn es keinen TCP-Verbindungs-Header 1201 gibt, kann die Quellverbindungs-ID 1212 zusammen mit der aktiven Hash-Liste des TSKs für die Backbone-Verbindung benutzt werden, um den CCB zu finden. Falls es keinen CCB gibt und die TSK-Nachricht eine CR-Nachricht ist, kann ein CCB belegt werden. Falls die Nachricht keine CR-Nachricht ist und es keinen CCB gibt, kann die Nachricht verworfen werden. Diese Verfahren zum Suchen des CCBs einer Nachricht kann weniger effizient sein als das Benutzen der lokalen TCP CID. Aber diese Verfahren können nur für ein paar Nachrichten beim Start einer Verbindung benutzt werden. 15 zeigt die Zuordnung der TCP-Verbindungs-Identifikationen.
  • Beim Start ruft die Plattformumgebung 210 den TSK 280 auf, um jede Backbone-Verbindung zu öffnen, die jeder TSK-Partner benötigt. Ein separater Aufruf kann für jede Backbone-Verbindung durchgeführt werden. Die Plattformumgebung 210 informiert den TCP-Spoofing-Kern 280, wenn die Backbone-Verbindung aktiv wird. Der TSK 280 sollte niemals eine Backbone-Verbindung schließen, solange dies nicht explizit von der Plattformumgebung 210 angefordert wird.
  • Jedes Mal, wenn der TSK 280 informiert wird, dass eine Backbone-Verbindung von geschlossen nach offen geht, sendet der TSK 280 eine TSK-Partner-Parameternachricht an seinen TSK-Partner. Eine TPP-Nachricht wird verwendet, um eine Ressourcenverfügbarkeitsinformation an den PEP-Endpunkt-Partner zu senden. Die nachfolgende Information kann in einer TPP-Nachricht gesendet werden:
    • • Die Größe des Pufferplatzes, der zum Spoofen in WAN-zu-LAN-Richtung für die Backbone-Verbindung verfügbar ist;
    • • Die lokale Anzahl der TCP-Verbindungs-Steuerungsblöcke, die zum Spoofen für diese Backbone-Verbindung verfügbar sind.
  • Diese Werte werden von der Plattformumgebung 210 bereitgestellt, wenn die Backbone-Verbindung geöffnet wird (und in dem TCB der Backbone-Verbindung gespeichert). Bis ein PEP-Endpunkt 705 zumindest eine TCP-Nachricht von seinem Partner für eine vorgegebene Backbone-Verbindung empfangen hat, werden keine gespooften TCP-Verbindungen in der Lage sein, die Verbindung zu benutzen.
  • Falls die Menge des WAN-zu-LAN-Pufferplatzes oder die Anzahl der CCBs, die zum Spoofen auf einer Backbone-Verbindung verfügbar sind, sich ändert, wird die Plattformumgebung 210 den TSK 280 von den Änderungen informieren. Wann immer der TSK 280 eine Anzeige empfängt, dass einer oder beide dieser Parameter sich geändert hat, werden die neuen Werte für die Parameter in dem TCB der Backbone-Verbindung gespeichert und eine TPP-Nachricht wird an den TSK-Partner gesendet.
  • Der TSK 280 benutzt zumindest zwei Typen von Steuerungsblöcken. Die TSK-Backbone-Verbindungs-Steuerungsblöcke werden verwendet, um Information betreffend die Backbone-Verbindungen zu speichern, die zu den TSK-Partnern aufgebaut sind. TCP-Verbindungs-Steuerungsblöcke werden verwendet, um Information bezüglich der TCP-Verbindungen zu speichern, die von dem TSK 280 gespooft werden.
  • Der TSK 280 kann eine Anzahl von Backbone-Verbindungen zu TSK-Partnern unterstützen, bestimmt durch die jeweilige PEP-Endpunktplattform-Software. Allgemein ist die Anzahl gleich der Anzahl der Backbone-Verbindungen, die die PEP-Endpunktplattform als Ganzes unterstützt. Backbone-Verbindungen können für Dinge anders als TCP-Spoofing verwendet werden und deshalb kann der TSK 280 weniger Backbone-Verbindungen unterstützen, als der PEP-Endpunkt 705 als Ganzes unterstützt. Beim Start ruft die Plattformumgebung 210 den TSK 280, um Backbone-Verbindungen zu der Konfiguration des TCP-Spoofing-Kerns hinzuzufügen. Für jede Backbone-Verbindung liefert die Plattformumgebung 210 den Handle, den sie für die Verbindung benutzen wird, erhalten von dem Partnerindex des PEP-Endpunktpartners und der Priorität der Verbindung. Nach dem Start kann die Plattformumgebung 210 den TSK 280 aufrufen, um eine Backbone-Verbindung hinzuzufügen, deren Parameter zu ändern oder sie zu löschen.
  • Wenn die Plattformumgebung 210 den TSK 280 aufruft, eine Backbone-Verbindung zu öffnen (hinzuzufügen), stellt die Umgebung 210 ein TCB für die Backbone-Verbindung bereit. Die Umgebung 210 belegt den TCB, um ein plattformspezifisches Speichermanagement der TCBs zu ermöglichen. Beispielsweise kann ein IP-Gateway 801 entworfen sein, um bis zu 16.000 entfernte PEP-Endpunktpartner (da ein IP-Gateway aktuell bis zu 16.000 entfernte IP-Subnetze unterstützen kann) und 64.000 Backbone-Verbindungen zu unterstützen. Deshalb können bis zu 64.000 TCBs benötigt werden. Andererseits wird ein Multimedia Relay, ein Multimedia VSAT oder ein PES Remote wahrscheinlich nur wenige PEP-Endpunktpartner haben und damit nur wenige TCBs. Deshalb wird die IP-Gateway-Implementierung des TCB-Managements wahrscheinlich komplexer sein als die Implementierung des TCB- Managements für das Multimedia Relay, Multimedia VSAT oder PES Remote.
  • TCBs werden der TSK 280 durch die Plattformumgebung 210 bereitgestellt, wenn Backbone-Verbindungen geöffnet werden. TCBs werden von der TSK 280 an die Plattformumgebung 210 zurückgegeben, wenn die Backbone-Verbindungen geschlossen werden. Wie an anderer Stelle angegeben, wird die Belegung und Freigabe von TCBs durch die Plattformumgebung 210 ausgeführt, um die Benutzung einer Belegungsstrategie (bspw. dynamisch gegenüber statisch) zu ermöglichen, die für die jeweilige Plattform geeignet ist. Eine TCB-Abbildungstabelle, die von dem TSK 280 erzeugt und aufrechterhalten wird, wird verwendet, um auf die belegten TCBs zuzugreifen. Die Größe der Abbildungstabelle (und die Anzahl der erforderlichen TCBs) wird durch den Softwarestand des PEP-Endpunkts 705 bestimmt. Der TSK-Backbone-Verbindung-Handle, der von der Plattformumgebung 210 bereitgestellt wird, wird als Index in die Abbildungstabelle benutzt, wobei der indexierte Tabelleneintrag auf den TCB zeigt. Dies ist in 16 dargestellt. Der Handle 1602 wird von der Umgebung 210 an den TSK 280 gereicht, wenn die Backbone-Verbindung referenziert wird (entweder direkt oder über einen CCB einer TCP-Verbindung). Der Handle wird von der BPK 282 an den TSK 280 ebenfalls gegeben, wann immer eine TSK-Nachricht von der Backbone-Verbindung des Handles empfangen wird. Der Handle wird ebenfalls als TSK-Backbone-Verbindungs-Identifikation (TID) benutzt, die als Quellverbindungs-ID-Wert in TSK-Nachrichten verwendet wird, die an den TSK-Partner gesendet werden.
  • Ein TCB 1606 wird verwendet, um die Konfigurationsinformation zu speichern, die von der Plattformumgebung 210 an den TSK 280 gereicht wird, über die Backbone-Verbindung. Sie umfasst ebenfalls den aktuellen Zustand der Verbindung (OFFEN oder GESCHLOSSEN) und einen Zeiger auf den Kopf und das Ende der verlinkten Liste der CCBs, die zu den TCP-Verbindungen gehören, die momentan von der Backbone-Verbindung benutzt werden. Zugriff auf die Liste der CCBs kann gefordert werden, um die TCP-Verbindungen zu finden, die betroffen sind, wenn die Backbone-Verbindungen ausfallen oder gelöscht werden.
  • Verbindungs-Steuerungsblöcke 1608 können verwendet werden, um Information bezüglich der spezifischen TCP-Verbindungen zu speichern. CCBs 1608 können von der Plattformumgebung 210 verwaltet werden, da viele Details ihrer Verwaltung plattformspezifisch sind. Die Plattformumgebung 210 kann Mechanismen zum Belegen und Freigaben der CCBs und eine Funktion zum Abbilden eines empfangenen TCP-Segments auf sein entsprechendes CCB bereitstellen. Wenn ein TCP-Segment an den TSK 280 geleitet wird, kann die Plattformumgebung 210 einen Zeiger an den geeigneten CCB 1608 von dem TSK 280 zusammen mit dem TCP-Segment leiten. Ein NULL-Zeiger kann weitergegeben werden, falls es keinen CCB 1608 gibt, der momentan mit der einzelnen TCP-Verbindung verknüpft ist. Die Abbildung der empfangenen TSK-Nachrichten auf die CCBs kann jedoch von dem TSK selbst ausgeführt werden.
  • Der TSK 280 kann eine gewisse Anzahl von CCBs 1608 unterstützen, bestimmt durch die Konfiguration und/oder durch Kompilation, wenn geeignet, für die einzelne PEP-Endpunkt 705 Plattform und Software. Um eine TCP-Verbindung zu spoofen, sollte ein CCB 1608 in beiden TSK-Partnern verfügbar sein. Idealerweise wird die Anzahl der CCBs 1608 groß sein, um zu gewährleisten, dass alle TCP-Verbindungen, die der Operator spoofen möchte, gespooft werden können. In der Praxis können die Speicherbeschränkungen einiger PEP-Endpunkt 503 Plattformen die Anzahl der CCBs 1608 einschränken, so dass gelegentlich eine TCP-Verbindung nicht gespooft werden kann, da sein CCB 1608 verfügbar ist. Wenn eine TCP-Verbindung, die gespooft werden soll, nicht gespooft werden kann aufgrund eines fehlenden CCB 1608, wird eine geeignete Statistik inkrementiert und die TCP-Verbindung wird ungespooft getragen. Die TSK-Partner tauschen Information über die Anzahl der CCBs 1608 aus, die für gespoofte TCP-Verbindungen verfügbar sind, indem eine bestimmte Backbone-Verbindung beim Start (und wann immer Parameter sich ändern oder die Backbone-Verbindung neu startet) über TSK-Partner-Parameter-Nachrichten benutzt wird. Der kleinere Wert der beiden TSK-Partner wird dann als Grenzwert für die Backbone-Verbindung benutzt. Beide TSKs 280 verfolgen die Anzahl der CCBs 1608, die momentan belegt sind (pro Backbone-Verbindung). Falls eine TCP-Verbindung erfasst wird, aber die aktuelle Anzahl von CCBs 1608, (für diese Backbone-Verbindung) belegt sind, an ihrer „verhandelten" Grenze ist, behandelt der TSK 280 die Verbidung, als ob kein CCB 1608 verfügbar wäre (selbst wenn einer verfügbar wäre).
  • Aufgrund von Laufzeitverzögerung oder weil der PEP-Endpunkt seinen Pool von CCBs 1608 mit all seinen Partnern teilt, ist es für einen CCB 1608 möglich, verfügbar zu sein, wenn ein TCP<SYN>-Segment von einem TSK 280 empfangen wird, aber für einen entsprechenden CCB 1608 nicht verfügbar ist an dem TSK-Partner. Die Handhabung dieses Fehlerszenarios wird nachfolgend beschrieben.
  • Anders als TCBs 1606, auf die über die TCB-Abbildungstabelle 1604 zugegriffen werden kann, sowohl für TCP-Segmente, die von dem lokalen LAN empfangen werden, als auch für TSK-Nachrichten, die von einer Backbone-Verbindung empfangen werden, können die CCBs 1608 unterschiedliche Mechanismen erfordern, um auf diese über TCP-Segmente gegenüber TSK-Nachrichten zugreifen zu können. Beispielhafte Mechanismen sind nachfolgend beschrieben.
  • Die CCBs 1608, die momentan nicht mit einer TCP-Verbindung verknüpft sind, können von der Plattformumgebung 210 in einem CCB-frei-Pool gespeichert werden. Freie CCBs können gespeichert werden, indem verschiedene plattformabhängige Verfahren benutzt werden. Ein erstes Verfahren ist ein Speicherpool, aus dem CCBs erzeugt werden, indem eine Malloc-Funktion oder Ähnliches benutzt wird. Mit diesem Verfahren kann die Anzahl der freien CCBs 1608 numerisch verfolgt werden oder über die Menge des Pufferplatzes, der zur Benutzung für die Erzeugung der CCBs 1608 bereitgestellt wird. CCBs 1608 können dem freien Pool zurückgegeben werden, indem eine Frei-Funktion oder Ähnliches benutzt wird. Ein zweites Verfahren erfolgt mittels einer FIFO-Warteschlange. Bei diesem Verfahren werden alle CCBs 1608 beim Plattformstart erzeugt und dann zusammen verkettet, indem ihre Zeiger zum nächsten CCB verwendet werden. Der CCB-Nächst-CCB-Zeiger wird nachfolgend beschrieben. Ein CCB 1608 kann belegt werden durch Entfernen aus dem Kopf der FIFO-Warteschlange, und ein CCB 1608 kann freigegeben werden, indem es an das Ende der FIFO-Warteschlange gesetzt wird.
  • Ein CCB 1608, das mit einer TCP-Verbindung verknüpft ist, kann als aktiv betrachtet werden. Aktive CCBs 1608 werden in unterschiedlichen Arten referenziert. Zum Abbilden der TSK-Nachrichten, die von dem TSK-Partner empfangen werden, auf CCBs 1608, kann der TSK 280 eine CCB-Abbildungstabelle benutzen. Die CCB-Abbildungstabelle kann ebenfalls von dem TSK 280 in einer Round-Robin-Weise benutzt werden, um auf CCBs 1608 zuzugreifen, um TCP-Verbindungs-Timeouts zu prüfen. Um TCP-Segmente, die von dem lokalen Host empfangen werden, auf CCBs 1508 abzubilden, kann eine CCB-Hash-Funktion 1702 ebenfalls verwendet werden, um die CCB-Zeiger zu finden. Die CCB-Hash-Funktion 1702 kann ebenfalls in einigen Fällen benutzt werden, um die CCBs für empfangene TSK-Nachrichten zu suchen, wenn die CCB-Abbildungstabelle nicht benutzt werden kann.
  • Um zugreifbar zu sein, wenn ein TCP-Segment von dem lokalen LAN empfangen wird, kann eine Hash-Funktion 1702 verwendet werden. Die Hash-Funktion 1702 produziert einen Index 1704 in eine CCB-Hash-Tabelle 1706. Die CCB-Hash-Tabelle 1706 zeigt auf eine doppelt-verlinkte Liste von CCBs 1708, die auf den Hash-Wert passen. Jedes CCB 1608 kann ein Next-CCB-Zeigerfeld aufweisen, das von der Plattformumgebung 210 benutzt wird, um die verlinkte Liste zu implementieren. 17 zeigt einen CCB-Zugriff über die CCB-Hash-Funktion 1702. Das Aufrechterhalten der CCB-Zeiger 1710, die von der Hash-Funktion benutzt werden, kann in der Verantwortung der Plattformumgebung 210 liegen. Die Plattformumgebung 210 kann einfach einen Zeiger auf den passenden CCB an den TSK 280 zusammen mit einem TCP-Segment reichen, das an den TSK 280 geleitet wird. Die Umgebung 210 kann ebenfalls eine Funktionsaufruf-Schnittstelle bereitstellen, die der TSK 280 aufrufen kann, um die Hash-Funktion selbst zu benutzen. Diese Schnittstelle kann von dem TSK 280 benutzt werden, um ein CCB 1608 zu finden, indem die Informati on in dem TSP-Verbindungs-Header 1201 einer empfangenen TSK-Nachricht 1200 benutzt wird.
  • Die Tatsache, dass die Plattformumgebung 210 für die Verwaltung der CCB-Hash-Tabelle 1706 verantwortlich ist, bedeutet, dass die Plattformumgebung 210 Zugriff auf einige der Felder in dem CCB 1608 haben sollte. Um die Plattformumgebung 210 von der Notwendigkeit abzuhalten, das vollständige Format des CCB 1608 zu kennen, können die Felder in dem CCB 1608, die für die Plattformumgebung 210 zugreif bar sind, in dem CCB 1608 nach vorne gestellt werden. Die Plattformumgebung 210 kann dann zur Aufrechterhaltung der nachfolgenden beispielhaften CCB-Felder verantwortlich sein:
    • • der Nächste- und Vorher-CCB-Zeiger
    • • die IP-Adressen und TCP-Port-Nummern, die eindeutig die TCP-Verbindung identifizieren; und
    • • der Backbone-Verbindungs-Handle, der benutzt wird, um auf das TCP der Backbone-Verbindung abzubilden, die benutzt wird, um diese gespoofte Verbindung zu tragen (d.h. der TID des Partners).
  • Allgemein können die IP-Adressen und TCP-Port-Nummern empfangener TCP-Segmente als Eingang in die CCB-Hash-Funktion 1702 benutzt werden. Allerdings kann die benutzte Hash-Funktion 1702 plattformspezifisch sein. Da bspw. eine große Anzahl von TCP-Verbindungen zu unterschiedlichen entfernten Orten unterstützten wird, sollte die IP-Gateway-801-Hash-Funktion auf den Teilnetzabschnitt der IP-Adressen gerichtet sein. Der Teilnetzabschnitt der IP-Adressen kann jedoch der gleiche sein für alle TCP-Verbindungen, die mit einem bestimm ten entfernten Ort verknüpft sind. Deshalb sollte eine Plattformumgebung 210 an einem entfernten Ort auf den Host-Teil der IP-Adressen stärker gerichtet sein.
  • CCBs 1608 können durch den TSK 280 für Funktionsaufrufe an die Plattformumgebung 210 belegt und freigegeben werden. Eine CCB-Abbildungstabelle 1802, die von dem TSK 280 erzeugt und aufrechterhalten wird, kann benutzt werden, um auf CCBs 1608 zum Zwecke der Zeitverarbeitung zuzugreifen und wenn TSK-Nachrichten von dem BPK 282 empfangen werden. Eine Abbildungstabelle 1802 kann verwendet werden, um die TSK-Partner zu unterstützen. Die Größe der Abbildungstabelle 1802 und die Anzahl der CCBs 1608, die erforderlich sind, kann von der Software des PEP-Endpunkts 705 bestimmt werden. Bei einem vorgegebenen PEP-Endpunkt 705 kann die Anzahl der Einträge in der Abbildungstabelle 1802 und die Anzahl der CCBs 1608, die verfügbar sind, gleich sein, da der TSK 280 keinen CCB 1608 verwenden sollte, auf den er nicht über die Abbildungstabelle 1802 zugreifen kann, und der TSK 280 benötigt keine Abbildungstabellen-Einträge, in die er keinen CCB 1608 setzen kann. Jeder Eintrag in der Abbildungstabelle 1802 hat zumindest zwei Felder:
    • • einen CCB-Zeiger; und
    • • einen Nächster-Eintrag-Index.
  • Der Nächster-Index kann verwendet werden, um verlinkte Listen der CCBs zu implementieren. Zumindest zwei Typen von verlinkten Listen kann aufrechterhalten werden, indem der Nächster-Eintrag-Index verwendet wird:
    • • eine Freier-Eintrag-Liste 1804; und
    • • eine aktive CCB Liste 1806.
  • Die Freie-Eintrag-Liste kann die Liste der freien Abbildungstabellen-Einträge speichern. Der TSK 280 kann einen Zeiger auf den Anfang und das Ende der Liste aufrechterhalten und diese Zeiger benutzen, um eine FIFO-Warteschlange freier Einträge zu implementieren. Wenn ein neuer CCB 1608 belegt wird, kann ein Eintrag aus der Freien-Eintrags-Liste 1804 ebenfalls belegt werden. Der TSK 280 benutzt den Index des Abbildungstabelleneintrags als lokale TCP CID der TCP-Verbindung. Wenn ein CCB 1608 freigegeben wird, kann der Abbildungstabellen-Eintrag 1802 des CCBs in die Freie-Liste 1804 zurückgegeben werden.
  • Aktive CCB-Listen 1806 können verwendet werden, um die CCBs 1608 der TCP-Verbindungen zu verketten, die aktuell aktiv sind. Die CCBs 1608 aller TCP-Verbindungen, die eine bestimmte Backbone-Verbindung teilen, können miteinander verkettet werden. Die Indizes des ersten und des letzten Eintrags einer CCB-verlinkten Liste einer Backbone-Verbindung kann mit dem Backbone-Verbindungszustand in dem TCP gespeichert werden, das mit der Backbone-Verbindung verknüpft ist. Die aktiven CCB-Listen 1806 können als doppelt-verlinkte Listen implementiert sein, um es einfacher zu machen, Einträge aus der Mitte der Liste zu entfernen. Um Platz in der CCB-Abbildungstabelle 1802 zu sparen und die Listen-Aufrechterhaltungssoftware einfacher zu machen, können jedoch einzel-verlinkte Listen 1806 verwendet werden. Aktive CCB-Listen können für zumindest zwei Zwecke benutzt werden:
    • • um alle CCB 1608 zu finden, die von einem Versagen oder einer Löschung einer Backbone-Verbindung beeinflusst werden. Wenn eine Backbone-Verbindung ausfällt oder gelöscht wird, können alle TCP-Verbindungen, die die Backbone-Verbindung benutzen, beendet werden; und
    • • um das passende CCB 1608 zu finden, wenn eine TSK-Nachricht mit einem Ziel-TCP-CID-Wert von 0 × FFFF empfangen wird, aber ohne einen TCP-Verbindungs-Header.
  • Für den letztgenannten Fall kann der TSK 280 die aktive CCB-Liste 1806 der Backbone-Verbindung, von der die TSK-Nachricht empfangen wurde, nach unten wandern, um einen CCB 1608 mit einer Partner-CID zu finden, die der Quellenverbindungs-ID in der TSK-Nachricht entspricht.
  • Ein CCB 1608 kann aus seiner aktiven CCB-Liste 1806 entfernt werden, wenn der CCB freigegeben wird.
  • 18 zeigt die Verwendung der CCB-Abbildungstabelle 1802.
  • Ein CCB 1608 kann belegt werden, wenn eine neue TCP-Verbindung erfasst wird, die gespooft werden soll. Der TSK 280 belegt einen freien Eintrag aus der CCB-Abbildungstabelle 1806 und ruft dann die Plattformumgebung 210 auf, um den CCB 1608 zu belegen, und liefert die IP-Adressen und TCP-Port-Nummern, die die Verbindung eindeutig identifizieren. Die Plattformumgebung 210 kann ein CCB 1608 aus dem freien CCB-Pool belegen und kann die bereitgestellten IP-Adressen und Port-Nummern verwenden, um den richtigen Hash-Tabellen-Eintrag für das CCB 1608 zu bestimmen. Der CCB-Zeiger kann dann der Hash- Tabelle 1706 hinzugefügt werden (verkettet mit dem Ende eines existierenden CCBs, der bereits auf einen Hash-Tabellen-Eintrag abgebildet ist, im Falle einer Hash-Tabellen-Kollision). Schließlich bevor der CCB 1608 an den TSK 280 zurückgegeben wird, kann die Plattformumgebung 210 den TCB-Index-Wert des CCB eintragen. Wenn der TSK 280 den CCB 1608 empfängt, benutzt er den TCB-Index in dem CCB 1608, um den TCB 1606 zu finden. Der CCB 1608 wird dann in die aktive CCB-Liste 1606 für die Backbone-Verbindung verkettet, die mit der Priorität der TCP-Verbindung verknüpft ist. Wenn ein CCB 1608 für eine neue TCP-Verbindung belegt wird, die von dem lokalen LAN erfasst wird, bevor tatsächlich der CCB 1608 in die CCB-Abbildungstabelle gesetzt wird, prüft der TSK 280 zunächst, um sicherzustellen, dass die Backbone-Verbindung besteht. Falls die Backbone-Verbindung nicht besteht, kann die Verbindung nicht gespooft werden und der CCB 1608 für die Verbindung wird der Plattformumgebung 210 zurückgegeben.
  • Wenn ein CCB 1608 freigegeben wird, kann er aus der aktiven CCB-Liste 1806 herausgenommen werden, sein CCB-Abbildungstabellen-Eintrag kann an die freie Eintragliste 1804 zurückgegeben werden und der CCB 1608 kann an die Plattformumgebung 210 zurückgegeben werden. Die Umgebung 210 kann wiederum den CCB 1608 aus der CCB-Hash-Tabelle 1706 entfernen und den CCB 1608 in den freien CCB-Pool zurückgeben.
  • Die Gesamtanzahl der CCBs 1608, die in einer PEP-Endpunktplattform 705 verfügbar sind, ist konfigurierbar. Der Wert kann tatsächlich bezüglich der Anzahl der CCBs 1608 spezifiziert werden, die pro PEP-Endpunkt 705 Partner, als Teil eines PEP-Endpunktprofils 701, 703 verfügbar sind. Jede PEP- Endpunkt 705 Plattformsoftware wird jedoch eine maximale Anzahl von CCBs 1608 haben, die sie unterstützen kann. Falls der Operator die Anzahl der CCBs 1608 größer als die von der Software unterstützte Anzahl konfiguriert, wird die kleinere Anzahl benutzt und ein Ereignis wird ausgegeben, um den Opertor zu alarmieren, dass dies aufgetreten ist. In einem PEP-Endpunkt 501, wo der CCB-Pool mit allen Partnern geteilt wird, kann jedoch der Operator absichtlich die Partner-CCB-Grenze so konfigurieren, dass ein Multiplizieren der Grenze durch die Anzahl der Partner mehr CCBs 1608 erfordern würde als tatsächlich existieren, um die Leistung zu verbessern, indem die CCBs 1608 statistisch geteilt werden.
  • Ist die Anzahl der CCBs 1608 in einem PEP-Endpunkt 705 konfigurierbar, kann der Operator den Punkt steuern, an dem TCP-Verbindungen aufhören, gespooft zu werden. Die Gesamtanzahl der TCP-Verbindungen, die von dem System getragen werden, kann einen Punkt erreichen, wo die Gesamtgröße der Bandbreite dividiert durch die Anzahl der TCP-Verbindungen, die aktiv benutzt werden, kleiner ist als der mögliche Durchsatz für jede TCP-Verbindung ohne TCP-Spoofing. Der Operator kann deshalb wünschen, dass die Anzahl der CCBs 1608 so eingestellt wird, dass ein Spoofing nur auftritt, wenn die Leistung verbessert wird. Allerdings ist die TCP-Spoofing-Leistungsverbesserung nicht nur auf einen hohen Datendurchsatz begrenzt. TCP-Spoofing umfasst das Spoofen des TCP-Drei-Wege-Handshakes wie zuvor mit Bezug auf die 4A diskutiert. Abhängig von den benutzten Anwendungen kann der Operator entscheiden, dass ein Spoofen des Drei-Wege-Handshakes nützlich ist, selbst wenn der Durchsatz durch Vorhandensein einer großen Anzahl von TCP-Verbindungen begrenzt ist. Zusätzlich für gespoofte TCP- Verbindungen, wenn die Ressourcen (bspw. Pufferplatz) niedrig sind, kann eine Flusssteuerung auf die gespooften TCP-Verbindungen angewendet werden (durch Schrumpfen der TCP-Fenster, die von dem PEP-Endpunkt 705 angezeigt werden). Dies ist nicht möglich für ungespoofte TCP-Verbindungen.
  • Zusätzlich zu der Gesamtzahl der PEP-Endpunkt-CCBs-1608 kann der Operator ebenfalls den Prozentsatz der verfügbaren CCBs 1608 konfigurieren, die mit der Backbone-Verbindung für jede Priorität benutzt werden können. Dies ermöglicht dem Operator, CCBs 1608 zur Benutzung durch TCP-Verbindungen höherer Priorität zu reservieren.
  • Wenn ein TCP-Segment von dem lokalen LAN empfangen wird, kann die Plattformumgebung 210 die CCB-Hash-Funktion 1702 benutzen, um den CCB 1608 zu finden, der mit der TCP-Verbindung verknüpft ist, und einen Zeiger an diesen CCB 1608 an den TSK 280 zusammen mit dem TCP-Segment reichen. Ein Index in das TCP-Abbildungsfeld, das in dem CCB 1608 gespeichert ist, kann dann von dem TSK 280 benutzt werden, wenn er den TCB 1606 bezeichnen möchte, der mit der Backbone-Verbindung verknüpft ist, die benutzt wird, um die TCP-Verbindung zu spoofen. Für ein TCP-Segment, das von dem lokalen LAN empfangen wird, sollte der TSK 280 nicht auf den TCB 1606 zuerst zugreifen müssen, um den CCB 1608 der Verbindung zu finden.
  • Wenn eine TSK-Nachricht von dem BPK 282 durch den TSK 280 empfangen wird, kann der TSK 280 die Ziel-TCP-CID aus der TSK-Nachricht extrahieren. Falls die TCP-CID nicht 0 × FFFF ist, kann sie den CCB-Abbildungstabellenindex für den CCB darstellen, der mit der TCP-Verbindung der TSK-Nachricht verknüpft ist. Falls die TCP-CID 0 × FFFF ist, sollte der TSK 280 bestimmen, ob eine neue TCP-CID erforderlich ist (da die TSK-Nachricht eine Connection-Request-Nachricht sein kann), falls die Nachricht einer existierenden TCP-Verbindung gehört, für die der TSK-Partner noch keine TCP-CID empfangen hat, oder falls die Nachricht verworfen werden soll, da keine der vorherigen zwei Bedingungen anwendbar ist. Der TSK 280 kann zunächst die Nachricht überprüfen, um zu sehen, ob es einen TCP Verbindungsheader 1201 gibt, der in der Nachricht enthalten ist. Falls ein TCP-Verbindungsheader 1201 enthalten ist, kann der TSK 280 die Information in dem TCP-Verbindungsheader 1201 als Eingabe in die Hash-Funktion 1702 verwenden, um den CCB 1608 zu finden. Falls kein TCP-Verbindungsheader 1201 in der Nachricht enthalten ist, kann der TSK 280 die Liste aktiver CCBs 1608, die aktuell mit der Backbone-Verbindung verknüpft ist, über die die Nachricht empfangen wurde, durchsuchen, um eine Übereinstimmung mit der Quellen-TCP-CID in der TSK-Nachricht zu finden. Der BPK 282 kann an den TSK 280 den Handle reichen, um die geeignete TCB 1606 zu finden, wenn er die TSK-Nachricht an den TSK reicht. 19 zeigt das Verhältnis zwischen einem CCB 1608 und einem TCB 1606.
  • Die Priorität einer gespooften TCP-Verbindung kann für die Verbindung bestimmt werden zum Zeitpunkt, zu dem die CCB der Verbindung belegt wird. Der TSK 280 benutzt nur die Priorität, um die geeignete Backbone-Verbindung zu bestimmen, um eine gespoofte TCP-Verbindung zu tragen. Nach Durchführung dieser Bestimmung braucht der TSK 280 keine Referenzierung auf die Priorität einer TCP-Verbindung.
  • Für eine belegte CCB 1608 aufgrund des Empfangs einer Connection-Request(CR)-Nachricht wird die Priorität gleich der Priorität der Backbone-Verbindung gesetzt, über die die CR-Nachricht 1506 empfangen wurde, d.h. die Backbone-Verbindung, über die die CR-Nachricht 1506 empfangen wurde, wird als Backbone-Verbindung für die gespoofte TCP-Verbindung benutzt. Für ein CCB 1608, das aufgrund des Empfangs eines TCP-<SYN>-Segments belegt werden wird, ist die Priorität die Priorität, die in dem ausgewählten TCP-Spoofing-Parameter-Profil angezeigt ist. Vor dem tatsächlichen Verwenden einer CCB 1608, die für die Verbindung belegt ist, überprüft jedoch der TSK 280, um sicherzustellen, dass eine Backbone-Verbindung zu dem geeigneten TSK-Partner aktuell mit dem in dem TCP-Spoofing-Parameter-Profil angezeigten Prioritätswert vorhanden ist. Falls die gewünschte Backbone-Verbindung nicht steht (oder nicht vorhanden ist), wird der CCB 1608 nicht belegt und die TCP-Verbindung wird nicht gespooft. Die Priorität einer TCP-Verbindung, die nicht gespooft wird, kann durch Priorisierungsregeln bestimmt werden, die in dem PK 284 implementiert sind.
  • Das Nachfolgende beschreibt das Handling von gespooften TCP-Verbindungen.
  • Der TCP-Spoofing-Kern 280 kann eine gespoofte TCP-Verbindung aufbauen, wenn er ein TCP-<SYN>-Segment von seinem lokalen LAN empfängt, oder er eine Connection-Request-Nachricht von seinem TSK-Partner empfängt. 4A und 4B zeigen den Aufbau einer gespooften TCP-Verbindung mit oder ohne ein Drei-Wege-Handshake-Spoofing. Ein Drei-Wege-Handshake-Spoofing kann gesperrt sein, um einen End-zu-End-MSS-Austausch zu unterstützen.
  • Wenn ein TCP-Segment von dem lokalen LAN empfangen wird, prüft die Plattformumgebung 210, um zu sehen, ob es bereits ein CCB 1608 gibt, das der TCP-Verbindung zugeordnet ist, die mit dem TCP-Segment verknüpft ist. Falls es kein CCB 1608 gibt, prüft die Umgebung, um zu sehen, ob das TCP-Segment ein <SYN>-Segment ist, das an ein nicht lokales Ziel zu senden ist. Falls dies der Fall ist, stellt das <SYN>-Segment einen Versuch dar, eine neue (nicht lokale) TCP-Verbindung aufzubauen und die Umgebung reicht das Segment an den TSK 280, um die Disposition der TCP-Verbindung festzulegen.
  • Wenn ein TCP-<SYN>-Segment von dem lokalen LAN für eine neue TCP-Verbindung empfangen wird, muss der TSK 280 zuerst bestimmen, ob die Verbindung gespooft werden soll. Falls die Verbindung gespooft werden soll, kann der TSK 280 die Priorität benutzen, die in dem ausgewählten TCP-Spoofing-Parameter-Profil angegeben ist, und den Partnerindex (der durch die Umgebung mit dem TCP-<SYN>-Segment bereitgestellt wird), um den Handle der Backbone-Verbindung aufzubauen, der verwendet werden soll, um diese gespoofte TCP-Verbindung zu tragen. Der Backbone-Verbindungs-Handle wird dann benutzt (über die TCB-Abbildungstabelle), um den TCP zu finden, der mit der Backbone-Verbindung verknüpft ist. Der TSK 280 prüft dann, um zu sehen, ob die Backbone-Verbindung aufgebaut ist bzw. steht. Falls die Backbone-Verbindung nicht steht, prüft der TSK 280, um zu sehen, ob die Anzahl der gespooften TCP-Verbindungen, die bereits die ausgewählte Backbone-Verbindung benutzen, immer noch unterhalb der CCB-Ressourcen-Grenze ist. Die CCB-Ressourcen-Grenze ist der kleinere Wert von der lokalen Anzahl der CCBs (die als Parameter von der Plattformumgebung 210 bereitgestellt werden) und der Partneranzahl der CCBs (in der letzten TPP-Nachricht von dem TSK-Partner empfangen), die für diese Backbone-Verbindung verfügbar ist. Falls die Anzahl der Verbindungen immer noch unterhalb der Grenze ist, ordnet der TSK 280 eine eindeutige TCP-Verbindungsidentifikation (beispielsweise einen freien CCB-Abbildungstabellen-Eintrag-Index) der Verbindung zu und ruft die Umgebung auf, um einen TCP-Verbindungs-Steuerungsblock für die Verbindung zu belegen.
  • Der TSK 280 wird das TCP-<SYN>-Segment zurück an die Umgebung 210 geben, um ungespooft weitergeleitet zu werden, falls irgendeine der Prüfungen fehlschlägt. Mit anderen Worten, falls:
    • • die selektiven TCP-Spoofing-Regeln anzeigen, dass die Verbindung nicht gespooft werden sollte;
    • • es keine Backbone-Verbindung für die Priorität gibt, mit der die TCP-Verbindung gespooft werden sollte (durch das Fehlen eines TCB für die Backbone-Verbindung angezeigt);
    • • es eine Backbone-Verbindung gibt, aber die Backbone-Verbindung nicht steht;
    • • die Anzahl der gespooften TCP-Verbindungen, die bereits diese Backbone-Verbindung benutzen, an (oder über) der Grenze liegt; oder
    • • es keinen CCB-Abbildungstabellen-1802-Eintrag gibt, der verfügbar ist, oder es kein CCB 1608 gibt, das aus dem CCB-Freipool verfügbar ist, wird dann die TCP-Verbindung ungespooft weitergeleitet.
  • Für den Fall, bei dem es keine Backbone-Verbindung gibt, kann der TSK 280 ebenfalls ein Ereignis absenden, um den Operator zu alarmieren, dass es eine Fehlanpassung zwischen den konfigurierten TCP-Spoofing-Parameter-Profilen und dem konfigurierten Satz von Backbone-Verbindungen gibt.
  • Falls alle zuvor genannten Prüfungen durchlaufen werden, schreibt der TSK 280 den Backbone-Verbindungs-Handle in den Puffer, der das TCP-<SYN>-Segment 401 hält. Dies wird nicht getan, bis ein CCB 1608 erfolgreich von der Plattformumgebung 210 belegt wird, da die Umgebung 210 den Puffer nicht zählt, solange nicht ein CCB erfolgreich belegt ist). Der TSK 280 kopiert dann die Parameter aus dem ausgewählten TCP-Spoofing-Parameter-Profil in den CCB. Dann wird relevante Information (die maximale Segmentgröße, die von dem Host angegeben wird (falls kleiner als die konfigurierte MSS), die anfängliche Sequenznummer, etc.) aus dem TCP-<SYN>-Segment 401 kopiert und in den CCB 1608 gespeichert. Die Quell- und Ziel-IP-Adresse und die Quell- und Ziel-TCP-Port-Nummern wurden bereits in die CCB von der Plattformumgebung 210 platziert, als der CCB belegt wurde. Die Umgebung 210 benötigt diese Information, um die CCB-Hash-Funktionskollisionen zu verwalten.
  • Nach dem Belegen und Einstellen der CCB 1608 baut der TSK 280 eine Connection-Request-Nachricht 403 auf und sendet diese an den TSK-Partner. Die CR-Nachricht 403 enthält hauptsächlich alle Information, die aus dem TCP-Spoofing-Parameter-Profil und dem TCP-<SYN>-Segment 401 extrahiert wurde und speichert sie in der lokalen CCB 1608, beispielsweise die Quell- und Ziel-IP-Adressen, die Quell- und Ziel-TCP-Port-Nummern, der MSS-Wert, etc., mit Ausnahme von Feldern, wie beispielsweise die anfängliche Reihenfolgen- bzw. Sequenznummer, die nur lokale Bedeutung haben. Die IP-Adressen und TCP-Port-Nummern werden in einen TCP-Verbindungsheader 1201 gesetzt. Mit anderen Worten enthält die CR-Nachricht 403 alle Information, die der Partner-TSK benötigt, um sein eigenes CCB 1608 aufzubauen.
  • 20 zeigt den Abschluss des lokalen Verbindungsaufbaus. 20 ist identisch zu 4A und 4B, wird hier aber aus Klarheitsgründen und zum besseren Verständnis wiederholt. Der TSK 280 muss ein TCP-<SYN,ACK>-Segment 405 in Antwort auf das empfangene <SYN>-Segment 401 senden. Der TSK 280 kann dies gleichzeitig mit dem Senden der CR-Nachricht 403 tun, falls ein Drei-Wege-Handshake-Spoofing freigegeben ist. Anderenfalls muss er auf eine CE-Nachricht 459 von seinem TSK-Partner 404 warten, bevor das <SYN,ACK>-Segment 405 gesendet wird. Der TSK 280 nimmt eine beliebige Anfangssequenznummer (folgend den Richtlinien, die in RFC 793 bereitgestellt werden, deren gesamter Inhalt hiermit durch Bezugnahme aufgenommen wird), um sie zum Senden von Daten zu benutzen. Falls das Drei-Wege-Handshake-Spoofing gesperrt ist, wird der MSS-Wert, der in dem <SYN,ACK>-Segment 461 gesendet wird, gleichgesetzt zu dem MSS-Wert, der in der CE-Nachricht 459 empfangen wurde. Falls jedoch der MSS-Wert größer ist als der konfigurierte MSS-Wert, wird der konfigurierte MSS-Wert statt dessen gesendet werden. Falls das Drei-Wege-Handshake-Spoofing freigegeben ist, wird der MSS-Wert von dem TCP-Spoofing-Parameter-Profil bestimmt, das für die Verbindung ausgewählt wurde. Für diesen Fall muss der TSK 280 dann den MSS-Wert, der in der CE-Nachricht 419 empfangen wurde, wenn sie ankommt, mit dem Wert vergleichen, der dem lokalen Host in der dem TCP-<SYN,ACK>-Segment 405 gesendet wurde. Falls der MSS-Wert, der in der CE-Nachricht 419 empfangen wurde, kleiner ist als der MSS-Wert, der dem lokalen Host gesendet wurde, existiert eine maximale Segmentgrößenfehlanpassung. Das MSS-Fehlanpassungs-Handling wird nachfolgend beschrieben.
  • Nach dem Senden des TCP-<SYN,ACK>-Segments 405 ist der TSK 280 bereit, die Annahme von Daten von dem lokalen Host zu starten. Wenn ein Drei-Wege-Handshake-Spoofing benutzt wird, muss der TSK 280 nicht auf die CE-Nachricht 419 warten, die von seinem TSK-Partner 404 ankommt, bevor die Daten angenommen und weitergeleitet werden. Würde dies getan, würde dies dem Zweck des Spoofens des Drei-Wege-Handshakes entgegenwirken. Der TSK 280 wird jedoch nicht Daten von seinem TSK-Partner 404 annehmen, bis die CE-Nachricht 419 empfangen wurde. Und der TSK 280 wird keine Daten an den lokalen Host 400 weiterleiten, die von seinem TSK-Partner 404 empfangen wurden, bis er das TCP<ACK>-Segment 407 empfangen hat, das anzeigt, dass der lokale Host 400 das <SYN,ACK>-Segment 405 empfangen hat.
  • Wenn eine CR-Nachricht 403 von einem Partner-TSK 280 empfangen wird, kann der TSK 280 ein CCB für die Verbindung belegen und dann alle relevante Information aus der CR-Nachricht 403 in dem CCB 1608 speichern. Die Handhabung des Falls, bei dem kein CCB verfügbar ist, wird nachfolgend beschrieben. Der TSK 280 kann dann diese Information benutzen, um ein TCP-<SYN>-Segment 415 zu erzeugen, um es an den lokalen Host zu senden. Die MSS in dem <SYN>-Segment 415 kann auf den Wert gesetzt werden, der von dem TSK-Partner empfangen wird. Wenn der lokale Host mit einem TCP-<SYN,ACK>-Segment 417 antwortet, kann der TSK 280 eine CE-Nachricht 419 an seinen TSK-Partner 402 senden, wobei in der CE-Nachricht 419 die MSS enthalten ist, die von dem lokalen Host in dem <SYN,ACK>-Segment 417 gesendet wurde. Der TSK 280 kann auch mit einem TCP-<ACK>-Segment 421 antworten, um den lokalen Drei-Wege-Handshake zu vervollständigen. An diesem Punkt ist der TSK 280 bereit, Daten von beiden Richtungen zu empfangen und weiterzuleiten. Falls Daten von seinem TSK-Partner ankommen, bevor eine <SYN,ACK>-Segmentantwort von dem lokalen Host empfangen wird, können die Daten in eine Warteschlange gebracht werden und dann nach dem Senden des <ACK>-Segments in Antwort auf das <SYN,ACK>-Segment gesendet werden (wenn es ankommt).
  • Es gibt viele TCP-Verbindungsaufbau-Fehlerszenarien, die von dem TSK 280 gehandhabt werden können. Das Nachfolgende beschreibt einige beispielhafte Szenarien.
  • Eine TCP-Verbindung kann durch die Kombination der verknüpften Ziel- und Quell-IP-Adressen und der Ziel- und Quell-TCP-Port-Nummern eindeutig identifiziert werden. Es ist für zwei Hosts möglich, zu versuchen, gleichzeitig die gleiche TCP-Verbindung aufzubauen, wobei das TCP-<SYN>-Segment von jedem Host einander durchläuft. Bei einem TCP-Spoofing in der vorliegenden Erfindung kann dies zu zwei CR-Nachrichten 403 führen, die einander durchlaufen. Um diese Situation zu handhaben, wenn der TSK 280 eine CR-Nachricht 403 vor dem Belegen eines CCB 608 für die TCP-Verbindung empfängt, kann er zunächst prüfen, um zu sehen, ob es bereits einen CCB 1608 gibt, der für die TCP-Verbindung belegt wurde (indem die CCB-Hash-Funktion 1702 auf die IP-Adressen und die TCP-Port-Nummern verwendet wird, die in dem TCP-Verbindungsheader 1201 der CR-Nachricht 403 enthalten sind). Falls es bereits einen belegten CCB 1608 gibt, kann dann der TSK 280 die CR-Nachricht 403 so behandeln, als wäre sie eine CE-Nachricht 419, wobei die TCP-CID seines TSK-Partners aus der CE-Nachricht 403 extrahiert wird. 21A zeigt den Start der gleichen TCP-Verbindung von jedem Host.
  • Jeder TSK-Partner sollte in der Lage sein, einen CCB 1608 für jede TCP-Verbindung zu belegen, um die Verbindung spoofen zu können. Wenn ein TCP-<SYN>-Segment 401 für eine neue Verbindung empfangen wird und kein CCB 1608 verfügbar ist (oder die Anzahl der CCBs, die für diesen TSK-Partner belegt wurden, die Grenze erreicht hat), kann das TCP-<SYN>-Segment 401 ungespooft weitergeleitet werden. Dies ist in 22 dargestellt. Aufgrund der Ausbreitungsverzögerung (oder dem möglichen Überbuchen von CCBs, falls sie innerhalb der TSK-Partner geteilt werden), ist es für ein CCB 1608 möglich, verfügbar zu sein, wenn ein TCP-<SYN>-Segment 401 empfangen wird, aber es für ein CCB 1608 möglich ist, dass es an dem TSK-Partner nicht verfügbar ist.
  • Wenn ein CR 403 für eine neue Verbindung empfangen wird und kein CCB 1608 verfügbar ist, kann der TSK 280 auf die CR-Nachricht 403 mit einer No Resource bzw. Keine-Ressource(NR)-Nachricht 439 antworten (mit einem Grund-Code, der anzeigt "Kein CCB verfügbar"). Alle nachfolgenden Datennachrichten, die von dem TSK-Partner entsprechend dieser TCP-Verbindung empfangen werden, können einfach verworfen werden.
  • Wenn ein TSK 280 eine NR-Nachricht 439 mit einem Grund-Code von "Kein CCB verfügbar" in Antwort auf eine CR-Nachricht 403 empfängt, kann der TSK 280 den aktuellen Zustand der TCP-Verbindung auf "Nicht gespooft" setzen und den "Nicht gespooft"-Zeitgeber der Verbindung starten. Ein Zweck des "Nicht gespooft"-Zustands besteht darin, es dem TSK 280 zu ermöglichen, sich zu erinnern, dass er diese Verbindung nicht spoofen konnte, und damit zu ermöglichen, dass die Verbindung ungespooft aufgebaut wird bei einem Neuversuch durch den lokalen Host 400. Falls der TSK 280 ein Nicht-<SYN>-Segment für die TCP-Verbindung im "Nicht gespooft"-Zustand empfängt, bevor er ein <SYN>-Segment 401 empfängt, kann der TSK 280 das Nicht-<SYN>-Segment verwerfen und mit einem <RST>-Segment 437 antworten. Falls der TSK 280 ein TCP-<SYN>-Segment 401 empfängt, während er in dem "nicht gespooften" Zustand ist, kann der TCP das <SYN>-Segment 401 ungespooft weiterleiten und mit dem Warten auf ein Nicht-<SYN>-Segment beginnen (in der Zwischenzeit wird jedes zusätzliche <SYN>-Segment 401, das ungespooft empfangen wird, weitergeleitet). Wenn ein TSK 280 ein Nicht-<SYN>-Segment empfängt, nachdem er ein <SYN>-Segment 401 empfangen hat, kann der TSK 280 annehmen, dass die Verbindung erfolgreich ungespooft aufgebaut sein muss und gibt deshalb den CCB 1608 der Verbindung frei (nachdem er das empfangene Segment ungespooft weitergeleitet hat). In jedem Fall kann der CCB der Verbindung freigegeben werden, wenn der "Nicht gespooft"-Zeitgeber der Verbindung ausläuft. 23 zeigt Verbindungsaufbauszenarien, wenn keine CCBs an dem TSK-Partner verfügbar sind.
  • Aufgrund von Laufzeitverzögerung ist es dem letzten verfügbaren CCB 1608 möglich, von jedem TSK-Partner für unterschiedliche TCP-Verbindungen belegt zu werden, falls ein Host jeder Seite des Netzwerks ein TCP-<SYN>-Segment 401 zur gleichen Zeit sendet. Dies ist in 24 dargestellt. Diese Situation kann dazu führen, dass jede Verbindung ungespooft weitergeleitet wird, selbst wenn es ein CCB 1608 an jedem Ende der Backbone-Verbindung gibt, das verwendet werden könnte, um eine der Verbindungen zu spoofen. Da jedoch dieses Szenario sehr selten ist, wird der verfügbare CCB 1608 einfach verwendet werden, um die nächste TCP-Verbindung zu spoofen.
  • Wenn ein TSK 280 eine CR-Nachricht 403 empfängt und ein TCP-<SYN>-Segment 401 an einen lokalen Host sendet, kann er einen lokalen Antwort-Zeitgeber starten. Falls der Zeitgeber abläuft bevor eine TCP-<SYN,ACK>-Segment-Antwort 405 von dem Host empfangen wird, kann der TSK 280 das <SYN>-Segment 401 neu senden und den Zeitgeber erneut starten. Der TSK 280 wird das <SYN>-Segment 401 N mal neu übertragen, wobei der Neuversuchs-Zähler N entweder eine zusammengestellte Zeitkonstante oder ein vom Operator konfigurierbarer Parameter ist. Falls der TSK 280 keine <SYN,ACK>-Segment-405-Antwort nach N-Versuchen empfängt, kann daraus geschlossen werden, dass der Host nicht erreichbar ist. Er kann ein TCP-<RST>-Segment 437 an den lokalen Host senden für den Fall, dass das Problem nur für den Verkehr von dem lokalen Host existiert, und damit der lokale Host momentan kein <SYN>-Segment 401 empfangen hat, sendet eine CT-Nachricht 435 an seinen TSK-Partner (mit einem Grund-Code, der „keine Antwort vom lokalen Host" anzeigt) und dann die Verbindung schließt, wobei jegliche Datensegmente verworfen werden, die von seinem TSK-Partner empfangen wurden und für eine spätere Auslieferung in eine Warteschlange gesetzt wurden, und wobei die CCB 1608 der Verbindung freigegeben wird.
  • Das Verhalten eines TSK 280, wenn er eine CT-Nachricht 435 empfängt, hängt davon ab, ob der Kern bereits lokal die TCP-Verbindung (d.h. durch Senden des TCP-<SYN,ACK>-Segments) aufgebaut hat oder nicht. Falls der TSK 280 die TCP-Verbindung lokal nicht aufgebaut hat, kann der TSK 280 einfach die Verbindung schließen und den CCB der Verbindung freigeben. Nichts muss mehr an den lokalen Host gesendet werden. Falls der TSK 280 die TCP-Verbindung lokal aufgebaut hat, kann der TSK 280 ein TCP-<RST>-Segment 437 an den lokalen Host senden und dann die Verbindung schließen.
  • Das „Keine-Antwort-vom-Ziel-Host"-Fehlerszenario ist in 25 dargestellt.
  • Wenn der TSK 280 ein TCP-<SYN>-Segment 401 empfängt und ein TCP-<SYN,ACK>-Segment 405 in Antwort darauf sendet, kann er einen lokalen Antwort-Zeitgeber starten. Falls der Zeitgeber abläuft, bevor eine TCP-<ACK>-Segment-405-Antwort von dem Host empfangen wurde, um den Drei-Wege-Handshake zu beenden, kann der TSK 280 das <SYN,ACK>-Segment 405 erneut senden und den Zeitgeber erneut starten. Der TSK 280 kann das <SYN,ACK>-Segment 405 N mal neu übertragen, wobei der Neuversuchs-Zähler N entweder eine zusammengesetzte Zeitkonstante oder ein vom Operator konfigurierbarer Parameter ist. Falls der TSK 280 keine <ACK>-Segment-407-Antwort nach N-Versuchen emfängt, kann er daraus schließen, dass der Host nicht erreichbar ist. Er kann ein TCP-<RST>-Segment 437 an den lokalen Host senden, nur für den Fall, dass das Problem nur für den Verkehr von dem lokalen Host existiert und somit der lokale Host tatsächlich das <SYN,ACK>-Segment 405 nicht empfängt, sendet eine CT-Nachricht 435 an seinen TSK-Partner (mit einem Grund-Code, der „keine Antwort vom lokalen Host" anzeigt) und schließt die Verbindung, wobei jegliche Datensegmente verworfen werden, die von seinem TSK-Partner empfangen worden wären (nachdem die CE-Nachricht 419 von dem TSK empfangen wurde) und für eine spätere Auslieferung in die Warteschlange gesetzt worden wäre, bevor der CCB 1608 der Verbindung freigegeben wurde.
  • Wenn der TSK-Partner die CT-Nachricht 435 empfängt, kann er ein TCP-<RST>-Segment 437 an den lokalen Host senden und die Verbindung schließen. Das „Keine-Antwort-von-dem-Quell-Host"-Fehlerszenario ist in 26 dargestellt.
  • Nachdem eine TCP-Verbindung zwischen einem lokalen Host und dem TSK 280 aufgebaut ist, können der Host und der TSK 280 Daten untereinander senden. Wenn ein Datensegment empfangen wird, wird die Plattformumgebung 210 an den Zeiger auf den CCB 1608 an den TSK 280 zusammen mit dem empfangenen TCP-Segment weitergeben. Die Existenz eines CCBs 1608 für die TCP-Verbindung des Segments (für einen Typ eines TCP-Segments, der nicht ein <SYN>-Segment 401 ist) kann als Zeichen dafür benutzt werden, ob die Verbindung gespooft werden soll oder nicht. Das Vorhandensein eines CCB 1608 garantiert, dass die TCP-Verbindung gespooft werden wird (wie in der vorhergehenden Diskussion bezüglich des „nicht gespooften" Zustands angegeben). Das Fehlen eines CCBs 1608 kann anzeigen, dass die TCP-Verbindung nicht gespooft werden soll.
  • Mit Bezug auf ein Senden von Daten an den Host (und eine Wiedergewinnung aus fallengelassenen Datensegmenten) sollte der TSK 280 all den relevanten Internet-Engineering-Task-Force-(IETF)-Standards folgen, die TCP betreffen, ein schließlich der Standards, die einen langsamen Start und eine Stauvermeidung regeln. Mit Bezug auf den Empfang von Daten von dem Host, kann der TCP ein Empfangsfenster 441 dem Host anzeigen und die Daten lokal bestätigen, die vom Host empfangen werden. Bestätigte Daten können von dem TSK 280 an seinen TSK-Partner weitergeleitet werden. Dies ist in 27 dargestellt.
  • Das Empfangsfenster 441, das von dem TSK 280 dem lokalen Host in jedem gegebenen TCP-<ACK>-Segment 405 angezeigt wird, kann das Minimum der Fenster sein, das durch mehrere Berechnungen bestimmt wurde. Diese Fenster können durch die Empfangsfenstergröße bestimmt werden, die in dem ausgewählten TCP-Spoofing-Profil der TCP-Verbindung konfiguriert ist, durch die vorhergehende angezeigte Fenstergröße und die Menge an Pufferplatz, die für das TCP-Spoofing verfügbar ist.
  • Ein Host wird normalerweise eine TCP-Verbindung durch Senden eines TCP-<FIN>-Segments 443 beenden. Ein <FIN>-Segment 443 zeigt an, dass der Host keine Daten zum Senden mehr hat, aber die Verbindung nicht beendet, bis der andere Host ebenfalls ein <FIN>-Segment 443 gesendet hat, das anzeigt, dass er ebenfalls keine Daten mehr zum senden hat. Wie in einigen Fällen, kann ein Host eine Verbindung durch Senden eines TCP-<RST>-Segments 437 beenden. Ein <RST>-Segment 437 beendet sofort eine TCP-Verbindung. Allgemein wird eine TCP-Verbindung nur beendet, indem ein <RST>-Segment 437 benutzt wird, wenn die Anwendung absichtlich eine Unterbrechung des TCP-Datenflusses wünscht oder die Anwendung sicher ist, dass es keine Daten mehr gibt, die übertragen werden müssen und die Beendigung der TCP-Verbindung schneller wünscht als dies durch Austauschen eines <FIN>-Segments 443 möglich ist. Der TSK 280 handhabt diese Verbindungs-Beendigungsnachrichten wie nachfolgend beschrieben.
  • Wenn ein TSK 280 ein TCP-<FIN>-Segment 443 empfängt, kann er in einen lokalen FIN-Wartezustand gehen, ein TCP-<ACK>-Segment 407 senden, um den Empfang des <FIN>-Segments 443 zu bestätigen und eine Termination-Pending-(TP)-445-Nachricht (Beendigung-Anhängig-Nachricht) an seinen TSK-Partner senden. Nach Empfang des <FIN>-Segments 443 kann der TSK 280 jegliche TCP-Daten verwerfen, die auf der TCP-Verbindung von dem lokalen Host empfangen werden. Der TSK 280 kann jedoch weitermachen, Daten anzunehmen und weiterzuleiten, die er von seinem TSK-Partner empfängt, bis er eine TP-Nachricht 445 von dem TSK-Partner empfängt. Wenn der TSK 280 eine TP-Nachricht 445 von seinem TSK-Partner empfängt, kann er in einen lokalen FIN-Anhängig- bzw. FIN-Pending-Zustand gehen. Der TSK 280 kann dann ein Senden jeglicher Datensegmente fortsetzen, die nicht gesendet und bestätigt wurden. Nachdem alle Daten gesendet und bestätigt wurden, kann der TSK 280 dann ein TCP-<FIN>-Segment 443 an den lokalen Host senden. Falls es keine Daten gibt, die übrig bleiben, wenn die TP-Nachricht empfangen wird, kann das <FIN>-Segment 443 sofort gesendet werden. Wenn der lokale Host das <FIN>-Segment 443 bestätigt, kann der TSK 280 den „Wartezeit"-Zeitgeber der Verbindung starten und in den „Wartezeit"-Zustand gehen.
  • Wenn der TSK 280 eine TP-Nachricht 445 von seinem TSK-Partner empfängt, während er in dem Datenübertragungszustand ist, kann er in einen Partner-FIN-Wartezustand gelangen. Der TSK 280 kann dann ein Senden jeglicher Datensegmente fortsetzen, die noch nicht gesendet und bestätigt wurden. Nach dem alle Daten gesendet und bestätigt wurden, kann der TSK 280 ein TCP-<FIN>-Segment 443 an den lokalen Host senden und in einen Partner-FIN-Anhängig-Zustand gelangen. Falls keine Daten mehr übrig sind, wenn die TP-Nachricht empfangen wird, kann das <FIN>-Segment 443 sofort gesendet werden und der TSK 280 kann in den Partner-FIN-Anhängig-Zustand gehen. Der TSK 280 setzt die Annahme, die Bestätigung und das Weiterleiten von Daten fort, die von seinem lokalen Host empfangen wurden, bis der lokale Host ein TCP-<FIN>-Segment 443 sendet. Wenn der lokale Host das TCP-<FIN>-Segment 443 sendet, während der TSK 280 in dem Partner-FIN-Anhängig-Zustand ist, kann der TSK 280 ein TCP<ACK>-Segment 441 senden, um den Empfang des <FIN>-Segments 443 zu bestätigen und sendet eine TP-Nachricht 445 an seinen TSK-Partner. Der TSK 280 kann dann seinen „Wartezeit"-Zeitgeber starten und in den „Wartezeit"-Zustand gehen. 28 zeigt das Handling des gespooften TCP-Verbindungs-<FIN>-Segments 443.
  • Es ist für das letze Segment, bspw. das <RST>-Segment 437 oder das <ACK>-Segment 433 die in Antwort auf ein <FIN>-Segment 443 gesendet wurden, möglich, gesendet zu werden, um eine Verbindung zu schließen, die verlorenging. Der Zweck des „Wartezeit"-Zustands besteht darin, den CCB 1608 solange wie möglich zu halten, um das letzte Segment neu zu senden, falls irgendwelche neuen Segmente für die gleiche Verbidnung von dem lokalen Host empfangen werden. Bei TCP im Allgemeinen stellt der „Wartezeit"-Zustand ebenfalls einen gewissen Schutz gegen die Ankunft von alten Segmenten bereit, die beim Durchlaufen des Netzwerks signifikant verzögert wurden. Dieses Problem sollte selten sein, aber kann bei Vorhandensein von temporären Routing-Schleifen auftreten,
  • Wenn der „Wartezeit"-Zustand erreicht wird, wird das Segment, das zu dem Zeitpunkt gesendet wurde, an dem der Zustand erreicht wurde, (logisch) in eine Warteschlange gesetzt. Dieses Segment kann in Antwort auf jegliche Segmente (anders als die <SYN>-Segmente 401) neu gesendet werden, die von dem lokalen Host für die Verbindung empfangen werden. Falls kein Segment zum Zeitpunkt des Eintritts in den „Wartezeit"-Zustand gesendet wurde, kann ein TCP-<RST>-Segment 437 gesendet werden in Antwort auf alle nicht-<SYN>-Segmente, die von dem lokalen Host für die Verbindung empfangen werden. Falls ein TCP-<SYN>-Segment 401 empfangen wird, kann der TSK 280 das <SYN>-Segment 401 in gleicher Weise verarbeiten, wie er dies für ein <SYN>-Segment 401 tut, das in dem Geschlossen-„Zustand" empfangen wurde, mit der Ausnahme, dass der TSK 280 eher den existierenden CCB 1608 wieder verwendet als dass er einen neuen CCB 1608 belegt. Es sei angemerkt, dass der „Geschlossen-Zustand" ein logischer Zustand ist, d.h. er repräsentiert den Zustand, wenn es keinen CCB 1608 gibt, der für eine TCP-Verbindung belegt werden kann. Eine Zustandsvariable der TCP-Verbindung wird nicht tatsächlich auf „geschlossen" gesetzt. Der TSK 280 kann nicht annehmen, dass der CCB 1608 (und damit CID), der von seinem TSK-Partner verwendet wird, bereits freigegeben wurde. Selbst wenn die zwei TSK-Partner den gleichen Wert für den „Wartezeit"-Zeitablauf verwenden, macht es die Laufzeitverzögerung wahrscheinlich, dass die zwei TSK-Partner ihre „Wartezeit"-Zeitgeber nicht gleichzeitig starten.
  • Wann immer in den „Wartezeit"-Zustand eingetreten wird, wird der „Wartezeit"-Zeitgeber gestartet. Der „Wartezeit"-Zeitablauf wird als Teil eines ausgewählten TCP-Spoofing-Parameterprofils einer TCP-Verbindung konfiguriert. Wenn der „wartezeit"-Zeitgeber abläuft, kann der CCB 1608 von seiner aktiven CCB-Liste seiner Backbone-Verbindung in den CCB-Freipool bewegt werden.
  • Wenn der TSK 280 ein TCP-<RST>-Segment 437 von einem Host empfängt, kann er die TCP-Verbindung, die gespooft wird, beenden. Die Puffer von Datensegmenten, die nicht bestätigt oder nicht übertragen wurden, können freigegeben werden, eine CT-Nachricht 435 wird an den TSK-Partner gesendet (mit einem Grund-Code, der ein „<RST>-Segment 437 vom lokalen Host empfangen" anzeigt), die Verbindung kann geschlossen werden und der CCB 1608 der Verbindung wird freigegeben.
  • Wenn der TSK-Partner die CT-Nachricht 435 empfängt, kann er Puffer von Datensegmenten freimachen, die weder bestätigt noch übertragen wurden, und sendet ein TCP-<RST> 437 an seinen lokalen Host. Der TSK 280 kann dann die Verbindung schließen und den CCB 1608 der Verbindung freigeben. 29 zeigt die Handhabung eines gespooften TCP-Verbindungs-<RST>-Segments 437.
  • Es gibt viele TCP-Verbindungs-Beendigungsfehlerszenarien, die von dem TSK 280 gehandhabt werden können. Es gibt ebenfalls viele Fehlerszenarien, die zu einer Beendigung der TCP-Verbindungen führen können. Das nachfolgende beschreibt einige dieser beispielhaften Szenarien.
  • Es ist für beide Hosts, die in einer TCP-Verbindung eingebunden sind, möglich, zu entscheiden, die Verbindung zu beenden. Falls dies geschieht, können die TCP-<FIN>-Segmente 443 von jedem Host einander zugeleitet werden. Bei einem TCP-Spoofing in der vorliegenden Erfindung kann dies dazu führen, dass die TP-Nachrichten 445 einander passieren. Dies verursacht keinerlei Probleme, da die TSK-Partner nicht erzählen können, dass die TP-Nachrichten 445 einander passiert haben. Jeder TSK-Partner sieht den Normalfall, nämlich den Empfang einer TP-Nachricht 445 nach dem Senden einer TP-Nachricht 445. 30 zeigt eine simultane normale Verbindungs-Beendigung.
  • Es ist für beide Hosts möglich, die in einer TCP-Verbindung beteiligt sind, zu entscheiden, die Verbindung mit einem (oder beiden) Hosts zu beenden, die ein TCP-<RST>-Segment 437 statt einem <FIN>-Segment 443 senden. Bei einem TCP-Spoofing in der vorliegenden Erfindung kann dies dazu führen, dass eine TP-Nachricht 445 eine CT-Nachricht 435 passiert (oder zwei CT-Nachrichten 435 einander passieren). Dies verursacht ebenfalls keinerlei Probleme. Der TSK 280, der das <RST>-Segment 437 empfängt, kann die Verbindung schließen, wenn er die CT-Nachricht 435 sendet, und kann einfach die TP 445 (oder CT 435) Nachricht verwerfen, wenn er sie empfängt. Ein TSK 280, der ein <FIN>-Segment 443 empfängt, kann ein <RST>-Segment 437 an seinen lokalen Host senden und die Verbindung schließen, wenn er die CT-Nachricht 435 empfängt. 31 zeigt beispielhafte Szenarien, in denen eine Beendigung mit TCP-<RST>-Segmenten 437 beteiligt ist.
  • Nachdem der TSK 280 ein TCP-<FIN>-Segment 443 sowohl gesendet als auch empfangen hat, kann er in den „Wartezeit"-Zustand gelangen. Da es jedoch möglich ist, dass die Auslieferung von Daten zu einem lokalen Host verzögert wird, ist es möglich, dass einer der TSK-Partner den „Wartezeit"- Zustand betritt, während der andere TSK-Partner noch versucht, Daten auszuliefern. In einem Extremfall ist es möglich, dass der „Wartezeit"-Zeitgeber eines TSKs für die TCP-Verbindung abläuft und den CCB 1608 der TCP-Verbindung freigibt, während sein TSK-Partner noch versucht, Daten auszuliefern. Dies kann vermieden werden, indem ein letzter Handshake zwischen den TSK-Partnern gefordert wird, bevor sie den „Wartezeit"-Zustand verlassen. Allerdings ist der zusätzliche Overhead für diesen Handshake nicht wünschenswert, insbesondere unter der Annahme, dass dieses Szenario selten sein sollte. Dies würde noch nicht verhindern, dass der lokale Host, der sowohl gesendet als auch ein <FIN>-Segment 443 empfangen hat, seinen „Wartezeit"-Zustand verlässt.
  • Das Fehlen eines letzten Handshakes kann einige zusätzliche Fehlerszenarien hervorrufen, die von dem TSK 280 gehandhabt werden können. Ein Szenario besteht darin, dass ein CCB 1608 an einem TSK-Partner verfügbar ist, ohne dass er von einem anderen Partner verfügbar wäre. Dies könnte zu einem nicht erfolgreichen Versuch führen, eine TCP-Verbindung zu spoofen. Dies kann jedoch schon aus anderen Gründen durch den TSK 280 gehandhabt werden.
  • Ein etwas komplizierteres Szenario taucht auf, falls der lokale Host versucht, die exakt gleiche TCP-Verbindung neu zu starten, die zuvor existierte. In diesem Fall könnte der TSK-Partner, der nicht in der Lage war, die Verbindung richtig zu beenden, eine CR-Nachricht 403 von einer existierenden Verbindung empfangen, während er noch die Daten von der vorhergehenden Verkörperung der Verbindung ausliefert. Der TSK 280 kann erkennen, dass dies aufgetreten ist, da er die CCB-Hash-Funktion 1702 auf die Information verwendet, die in dem TCP-Verbindungs-Header 1201 der CR-Nachricht 403 geliefert wird, um ein existierenden CCB 1608 zu suchen. Diese Überprüfung kann verhindern, dass der TSK 280 versucht, eine zweite Instanz der gleichen TCP-Verbindung aufzubauen. Wenn ein TSK 280 eine CR-Nachricht 403 vor einer erfolgreichen Beendigung der vorhergehenden Verkörperung einer Verbindung empfängt, kann er die CR-Nachricht 403 durch Senden einer CT-Nachricht 435 an seinen TSK-Partner ablehnen (mit einem Grund-Code, der anzeigt „vorherige Verkörperung dieser Verbindung noch anhängig"). Der TSK-Partner kann dann den Empfang einer CT-Nachricht 435 in Antwort auf eine CR-Nachricht 403 in der gleichen Weise handhaben, wie er dies aus anderen Gründen beim Empfang einer CT-Nachricht 435 tut. Der TSK 280 kann weitermachen, jeden neuen Versuch abzulehnen, die gleiche Verbindung neu zu starten, bis entweder die Daten erfolgreich ausgeliefert sind oder die Verbindung auf Grund eines nicht-wiederherstellbaren Fehlers heruntergezogen wird (bspw. erreicht er die maximale Versuchszahl, während die Neuübertragung eines Datensegments versucht wird). 32 zeigt eine von vielen exemplarischen Versionen des vorzeitigen Verbindungsneustart-Szenarios.
  • Die TSK 280-Ressourcen (bspw. CCBs) sind allgemein sehr wertvoll, da sie begrenzt sind. Somit ist es wünschenswert, dass der TSK 280 in der Lage ist, zu erkennen, wann ein Host gestorben ist, um die Ressourcen freizugeben, die von den TCP-Verbindungen benutzt werden, die mit dem Host verknüpft sind. Wenn der TSK 280 ein TCP-Segment an seinen lokalen Host sendet, der eine Antwort erfordert, kann er deshalb einen Antwort-Zeitgeber starten, um auf die Antwort zu warten. Falls keine Antwort empfangen wird, bevor der Zeitgeber abgelaufen ist, sendet der TSK 280 erneut das TCP-Segment, für das auf eine Antwort gewartet wird. Der TSK 280 kann das TCP-Segment N-mal neu senden, wobei der Versuchszähler N entweder eine zusammengesetzte Zeitkonstante oder ein von einem Operator konfigurierbarer Parameter ist. Falls der TSK 280 keine geeignete Antwort nach N-Versuchen empfängt, kann er daraus schließen, dass der Host nicht erreichbar ist. Er wird dann einen TCP-<RST>-Befehl 437 an den lokalen Host senden und eine CT-Nachricht 435 (mit einem Grund-Code, der anzeigt „keine Antwort vom lokalen Host") an seinen TSK-Partner. Der TSK 280 kann dann den Puffer von jeglichen Datensegmenten befreien, die weder bestätigt noch gesendet wurden, und schließt die Verbindung, wobei der CCB 1608 der Verbindung freigegeben wird.
  • Wenn der TSK-Partner die CT-Nachricht 435 empfängt, kann er ein TCP-<RST>-Segment 437 an seinen lokalen Host senden, falls geeignet den Puffer von den Datensegmenten befreien, die nicht bestätigt und nicht gesendet wurden, und die Verbindung schließen, wobei der CCB 1608 der Verbindung freigegeben wird.
  • 33 zeigt die Handhabung für „keine Antwort vom lokalen Host" für gespoofte TCP-Verbindungen in dem Datenübertragungszustand. 25 und 26, die zuvor diskutiert wurden, zeigen andere Fehlerszenarien für „keine Antwort vom Host an".
  • Der Antwort-Zeitgeber kann einen Mechanismus zum Erfassen bereitstellen, dass ein Host gestorben ist, wenn es ausstehende Daten gibt (oder eine andere Nachricht). Falls jedoch eine TCP-Verbindung im Leerlauf ist, d.h. falls es mo mentan keine zu übertragenden Daten auf der Verbindung gibt, kann der Antwort-Zeitgeber nicht laufen. Der „gestorbene" Host könnte selbst der Grund sein, warum keine Daten übertragen werden. Um zu erkennen, wann mit Leerlaufverbindungen verknüpfte Hosts sterben, kann der TSK 280 einen Keepalive-Zeitgeber laufen lassen, wann immer eine Verbindung im Leerlauf ist. Wenn der Keepalive-Zeitgeber ausläuft, kann der TSK 280 eine Keepalive-Nachricht an den lokalen Host senden. Die Länge des Keepalive-Zeitgebers wird als Teil eines ausgewählten TCP-Spoofing-Parameter-Profils einer Verbindung konfiguriert und kann von Minuten bis Stunden reichen. Das Senden der Keepalive-Nachrichten kann ebenfalls vollständig gesperrt werden. Nach dem Senden einer TCP-Keepalive-Nachricht kann der TSK 280 seinen Antwort-Zeitgeber starten und der Prozedur folgen, um zu erkennen, ob der lokale Host noch „am Leben" ist.
  • Eine TCP-Keepalive-Nachricht kann ein Null-Längen-TCP-Datensegment sein, das mit einer Sequenznummer gesendet wurde, die mit dem letzten Byte übereinstimmt, dass bereits gesendet und bestätigt wurde. Wenn der Host dieses Datensegment empfängt, kann er es verwerfen (da es Daten darstellt, die bereits empfangen und bestätigt sind). Der Host kann jedoch auf dieses Datensegment mit einem <ACK>-Segment antworten, nur für den Fall, dass das Datensegment neu gesendet wurde, da sein letztes <ACK>-Segment verloren wurde. Die TCP-Keepalive-Nachrichten sind in RFC 1122 beschrieben, dessen gesamter Inhalt hiermit durch Bezugnahme aufgenommen wird.
  • Die Backbone-Verbindungen können auf Grund von Verbindungsfehlern zwischen zwei PEP-Endpunkten 705 versagen oder auf Grund eines Fehlers eines PEP-Endpunkts 705 selbst. Falls zu irgendeinem Zeitpunkt der BPK 282 anzeigt (über die Umgebung 210), dass eine Backbone-Verbindung versagt hat, kann der TSK 280 alle TCP-Verbindungen beenden, die mit der ausgefallenen Backbone-Verbindung verknüpft sind. Für jede solche TCP-Verbindung kann der TSK 280 ein TCP-<RST>-Segment 437 an seinen lokalen Host senden, den Puffer von jeglichen Datensegmenten befreien, die nicht bestätigt und nicht gesendet wurden, und die Verbindung schließen, wobei der CCB 1608 der Verbindung freigegeben wird. Der TSK 280 kann ebenfalls die TCP-Verbindungen beenden, die mit einer Backbone-Verbindung verknüpft sind, die aus bestimmten Gründen geschlossen werden muss (bspw. da der Operator sie gelöscht hat).
  • Der TSK 280 kann periodisch bereitgestellt werden über die Plattformumgebung 210 mit einer Background-Verarbeitungsmöglichkeit. Eine der Funktionen, die von dem TSK 280 ausgeführt werden, während der Background-Verarbeitungsmöglichkeit, kann darin bestehen, die TCP-Verbindungs-Zeitabläufe bzw. -Timeouts zu prüfen. Bei einer beispielhaften Ausführungsform kann er die Ablaufzeit des Zeitgebers auf einen Timeout-Wert plus die aktuelle Systemzeit setzen, wann immer der TSK 280 einen Zeitgeber startet. Um zu prüfen, ob ein Zeitgeber abgelaufen ist, kann der TSK 280 die Ablaufzeit des Zeitgebers mit der aktuellen Systemzeit vergleichen, die von der Plattformumgebung 210 bereitgestellt wird. Die Systemzeit kann in Form von Zeitticks dargestellt sein. Die Plattformumgebung 210 wandelt die Timeout-Parameter, (in der Einheit von Dezisekunden) von dem Netzwerkmanager bereitgestellt werden, in Systemtickzähler um, bevor die Parameter zu dem TSK 280 geführt werden.
  • Der TSK 280 kann Gebrauch machen von der CCB-Abbildungstabelle 1802, um CCBs 1608 zu finden, die eine Zeitverarbeitung benötigen. Der TSK 280 kann in einer Round-Robin-Weise durch die Abbildungstabelle 1802 (als ein Array) wandern, um nach gültigen CCB-Zeigern zu suchen. Wenn ein gültiger CCB-Zeiger gefunden ist, kann der TSK 280 den CCB 1608 prüfen, um zu sehen, ob eine Zeitüberschreitung bzw. Timeout aufgetreten ist, und wenn Ja, die Zeitüberschreitungen verarbeiten. Um die CPU nicht zu lange unter der Steuerung zu halten, kann der TSK 280 die Anzahl der CCBs 1608 beschränken, die geprüft werden und die Anzahl der Timeouts, die während jedes Background-Aufrufs verarbeitet werden. Die spezifischen Grenzen können für jede PEP-Endpunktplattform unterschiedlich sein.
  • Die PEP-Endpunktplattformumgebung 210 gibt ein IP-Paket, das von den lokalen LAN-Schnittstellen 803, 903, 1003, 1103 empfangen wurden, die ein TCP-Protokolltyp haben, den TSK 280 weiter, falls das TCP-Spoofing global freigegeben ist, und das TCP-Segment erfüllt eine oder beide der nachfolgenden Bedingungen:
    • • ein TCP-Verbindungs-Steuerungsblock existiert für die TCP-Verbindung, zu der das TCP-Segment gehört;
    • • das TCP-Segment ist ein <SYN>-Segment 401, das für ein nicht lokales Ziel bestimmt ist. (Lokale TCP-Verbindungen bspw., TCP-Verbindungen zwischen Hosts, die lokal zu LAN-Ports eines VSAT liegen, und TCP-Verbindungen, die nicht mit einem bekannten nicht lokalen Ziel-Teilnetz verknüpft sind, werden nicht zum TSK 280 weitergeleitet.)
  • Ein TCP-Segment, das keine der Bedingungen erfüllt, wird entweder lokal weitergeleitet oder ungespooft (wenn geeignet) durch die Plattformumgebung 210 weitergeleitet. Der TSK 280 wendet Auswahlkriterien auf die TCP-<SYN>-Segmente 401 an, um zu bestimmen, ob eine Verbindung gespooft werden sollte oder nicht, Falls ein Verbindungs-Steuerungsblock für die Verbindung existiert, hat dann die Verbindung bereits ein Auswahlkriterium angewendet, für alle TCP-Segmente. Dies umfasst <SYN>-Segmente 401. TCP-<SYN>-Segmente 401 markieren allgemein den Start einer neuen Verbindung, aber aus der Sicht der TCP-Zustandsmaschine, kann ein <SYN>-Segment 401 in der Mitte einer existierenden Verbindung empfangen werden, um die Verbindung neu zu synchronisieren oder neu zu starten. Die TCP-<SYN>-Segmente 401, die durch das Auswahlkriterium fallen, werden zurück zu der Plattformumgebung 210 geführt, um ungespooft weitergeleitet zu werden. Die nachfolgenden TCP-Segmente, die für diese TCP-Verbindungen empfangen werden, werden dann mit keinem vorhandenen CCB 1608 empfangen und werden damit ebenfalls ungespooft weitergeleitet.
  • Es gibt zumindest fünf beispielhafte Kriterien, die von dem Operator in einer selektiven TCP-Spoofing-Regel spezifiziert werden können. Das erste beispielhafte Kriterium ist die Ziel-IP-Adresse. Selektives TCP-Spoofing kann basierend auf den Ziel-IP-Adressen ausgeführt werden. Eine Maske kann mit jeder IP-Adresse verknüpft sein, um eine Mehrfach-Adressübereinstimmung mit einer einzelnen Regel zu unterstützen. Beispielsweise könnte eine Maske 0.0.0.255 mit einer Adresse 0.0.0.1 verwendet werden, um eine IP-Adresse der Form x.x.x.1 auszuwählen, und eine Maske 255.255.255.0 mit einer Adresse 10.1.1.0 könnte verwendet werden, um alle IP-Adressen in dem 10.1.1.0-Teilnetz auszuwählen. Eine Maske 0.0.0.0 stellt einen „Unwichtig"-Wert für das IP-Adressfeld dar, d.h. eine Maske 0.0.0.0 passt auf alle IP-Adressen.
  • Ein zweites beispielhaftes Kriterium ist die Quell-IP-Adresse, Selektives TCP-Spoofing kann basierend auf Quell-IP-Adressen ausgeführt werden. Wie mit Ziel-IP-Adressen kann eine Maske mit jeder IP-Adresse verknüpft werden, um mit einer einzigen Regel eine Mehrfach-Adressübereinstimmung zu unterstützen.
  • Ein drittes beispielhaftes Kriterium ist die TCP-Port-Nummer. Ein selektives TCP-Spoofing kann basierend auf TCP-Port-Nummern ausgeführt werden. TCP-Port-Nummern können den Typ der Anwendung identifizieren, die von einer TCP-Verbindung ausgeführt werden. Aktuell zugeordnete TCP-Port-Nummern können an dem nachfolgenden Ort nachverfolgt werden:
    http://www.isi.edu/in-notes/iana/assignments/port-numbers.
  • Port-Nummern-Regeln können sowohl auf die TCP-Ziel- als auch Quell-Port-Nummern angewendet werden, d.h. eine TCP-Port-Nummern-Regel kann angewendet werden, falls entweder die Ziel- oder die Quell-Port-Nummer übereinstimmt. Ein Wert von 0 wird als „Unwichtig"-Wert für die TCP-Port-Nummern-Felder verwendet, d.h. ein Port-Nummern-Wert von 0 in einer Regel stimmt mit allen TCP-Port-Nummern überein.
  • Ein viertes beispielhaftes Kriterium sind die TCP-Optionen. Ein selektives TCP-Spoofing kann basierend auf den TCP-Optionen ausgeführt werden, die vorhanden sind.
  • Ein fünftes beispielhaftes Kriterium ist das IP-DS-Feld. Selektives TCP-Spoofing kann auf der Basis des Differentiated-Services-(DS)-Feld in dem IP-Header ausgeführt werden. Eine Bit-Maske wird in Verbindung mit einem konfigurierten DS-Feldwert verwendet, um bedeutungsvolle Bits zu spezifizieren. Eine Maske 0 stellt einen „Unwichtig"-wert für das DS-Feld dar, d.h. eine Maske 0 passt auf alle DS-Feldwerte. Die Verwendung des IP-Header-DS-Felds wird in RFCs 2474 und 2475 beschrieben, deren kompletter Inhalt hiermit durch Bezugnahme aufgenommen wird.
  • Zusätzlich zu der Unterstützung selektiver TCP-Spoofing-Regeln für jedes dieser Kriterien, können UND und ODER Kombinationsoperatoren ebenfalls unterstützt werden, um die Kriterien miteinander zu verknüpfen. Beispielsweise kann bei Verwendung des UND-Kombinationsoperators eine Regel definiert werden, um TCP-Spoofing für FTP-Daten (TCP-Port-Nummer 20) zu sperren, die von einem spezifischen Host empfangen werden. Die Reihenfolge, in der die Regeln spezifiziert werden, kann ebenfalls wichtig sein. Es ist möglich, dass eine Verbindung die Kriterien mehrerer Regeln erfüllt. Deshalb kann der TSK 280 die Regeln in der Reihenfolge anwenden, die von dem Operator spezifiziert ist und die Aktion der ersten Regel heranziehen, die passt. Eine Default-Regel kann ebenfalls existieren, die die Aktion definiert, die für die TCP-Verbindungen verwendet wird, die auf keine der definierten Regeln passen.
  • Nach dem Prüfen der selektiven TCP-Spoofing-Regeln, um zu sehen, ob eine TCP-Verbindung gespooft werden soll, können, bevor tatsächlich versucht wird, die Verbindung zu spoofen, einige zusätzliche Prüfungen ausgeführt werden:
    • • Gibt es einen verfügbaren CCB 1608?
    • • Besteht die passende Backbone-Protokollverbindung zu dem Ziel PEP-Endpunkt?
  • Falls es keinen verfügbaren CCB 1608 gibt oder die Backbone-Protokollverbindung zu dem PEP-Endpunkt 705, der mit der Ziel-IP-Adresse dieser Verbindung verknüpft ist, besteht nicht, ist ein Spoofing wahrscheinlich nicht möglich.??
  • Selektive TCP-Spoofing-Regeln können von dem Operator in einem selektive TCP-Spoofing-Auswahlprofil 3402 definiert werden. PEP-Endpunkte 705 können dann definiert werden, um ein bestimmten TCP-Spoofing-Auswahlprofil 3402 zu verwenden. Alle PEP-Endpunkte 705 in einem Netzwerk können konffiguriert sein, um das gleiche Profil zu verwenden. Oder es können unterschiedliche Profile von den unterschiedlichen Teilnetzen der PEP-Endpunkte 705 verwendet werden. Es gibt kein Erfordernis, das das gleiche TCP-Spoofing-Auswahlprofil von den zwei PEP-Endpunkten 705 an den Enden einer Backbone-Verbindung verwendet wird. Die fehlende Notwendigkeit, dass die gleichen Auswahl-TCP-Spoofing-Regeln von jedem PEP-Endpunkt 705 verwendet werden, ermöglicht es dem Operator, noch eine Dimension den Regeln hinzuzufügen. Die hinzugefügte Dimension kann ermöglichen, dass das selektive TCP-Spoofing darauf basiert, von welchem Ende der Backbone-Verbindung die Verbindung ausgeht. Falls beispielsweise eine FTP-TCP-Verbindung von einem entfernten Ort ausgeht, kann dies unterschiedlich behandelt werden als eine FTP-TCP-Verbindung, die von der Hub-Seite ausgeht. Diese Fähigkeit kann nützlich sein, sollte aber mit Sorgfalt verwendet werden, um unerwartete Nebeneffekte zu vermeiden im Hinblick darauf, was und was nicht gespooft wird.
  • Selektive TCP-Spoofing-Regeln können verwendet werden, um ein passendes TCP-Spoofing-Auswahlprofil 3042 auszuwählen. Ein TCP-Spoofing-Parameterprofil 3404 kann anzeigen, ob Verbindungen, die auf das Profil abgebildet sind, gespooft werden sollen, und falls Ja, definiert es die Spoofing-Parameter, die für die Verbindungen angewendet werden sollen, die die Regel erfüllen. Die Parameter des TCP-Spoofing-Parameterprofils 3404 umfassen (sind aber nicht notwendigerweise darauf beschränkt):
    • • Drei-Wege-Handshake-Spoofing – dieser Parameter zeigt an, ob ein Drei-Wege-Handshake-Spoofing freigegeben ist oder gesperrt ist, oder nicht;
    • • Verbindungspriorität – dieser Parameter zeigt die Priorität an, die für dieses Profil ausgewählt werden.
    • • Prioritätsdisposition – dieser Parameter zeigt das passende Handling, das Verwerfen oder das Vorwärtsleiten ungespooft von TCP-Verbindungen an, die auf dieses TCP-Spoofing-Profil abgebildet sind, falls eine Backbone-Verbindung für die angegebene Verbindungspriorität aktuell nicht verfügbar ist;
    • • TCP-Protokoll-bezogene Parameter – diese Parameter sind auf den TCP-Protokoll-Betrieb und insbesondere das Maximum MSS bezogen, das verwendet werden sollte, auf Keepalive, Antwort und Wartezeit-Timeouts, etc.
  • Wie zuvor angegeben, kann ein TCP-Spoofing-Parameterprofil 3404 anzeigen, ob ein TCP-Spoofing freigegeben ist oder nicht. Falls jedoch alle übrigen Parameter des TCP-Spoofing-Parameterprofils bedeutungslos sein können, wenn das TCP-Spoofing gesperrt wird, wird nur ein TCP-Spoofing-Parameterprofil 3404 bei gesperrtem TCP-Spoofing benötigt. Mehr noch als die Notwendigkeit, dass ein solches Profil erzeugt werden soll, kann ein „nicht gespooftes"-Profil immer existieren für die Auswahl durch eine selektive TCP-Spoofing-Regel. Dieser Lösungsweg kann die Notwendigkeit nach einem expliziten TCP-Spoofing Freigegeben- oder Gesperrt-Parameter in dem TCP-Spoofing-Parameterprofil beseitigen. Ein TCP-Spoofing kann immer in jedem TCP-Spoofing-Parameterprofil freigegeben sein mit Ausnahme des „Nicht-Gespooft"-Profils.
  • Ein TCP-Spoofing-Auswahlprofil 3042 kann eine Default-Regel umfassen, die der Operator konfigurieren kann, um das TCP-Spoofing-Parameterprofil 3404 auszuwählen, dass das für TCP-Verbindungen verwendet werden soll, die auf keine der konfigurierten selektiven TCP-Spoofing-Regeln passen. Der Default-Wert kann das „Nicht-Gespooft"-TCP-Spoofing-Parameterprofil auswählen, falls TCP-Verbindungen, die nicht auf eine der selektiven TCP-Spoofing-Regeln passen, nicht gespooft werden sollten.
  • 34 zeigt ein beispielhaftes Verhältnis zwischen PEP-Endpunkten 905, TCP-Spoofing-Auswahlprofilen 3402 und TCP-Spoofing-Parameterprofilen 3402. TCP-Spoofing-Parameter profile 3402 können von dem Operator durch Namen referenziert werden, wenn sie konf figuriert sind, aber die Namen können in Indexnummern zur Verwendung durch den TSK 280 konvertiert werden. Eine Indexnummer von 255 kann verwendet werden, um das „Nicht-Gespooft"-TCP-Spoofing-Parameterprofil 3502 anzuzeigen, Dies ist beispielhaft in 35 angegeben.
  • Wenn ein TSK 280 den Drei-Wege-Handshake spooft, indem auf ein TCP-<SYN>-Segment 401 ohne Warten auf eine Antwort geantwortet wird, die von dem entfernten Host empfangen werden soll, kann er eine vom Operator konfigurierte maximale Segmentgröße an den Host in einer MSS-Option in dem TCP<SYN,ACK>-Segment 403 senden. Später, nachdem sein TSK-Partner seinen lokalen Drei-Wege-Handshake beendet hat, kann der TSK 280 den maximalen Segmentgrößenwert empfangen, der von dem entfernten Host an den TSK-Partner gesendet wurde. Falls der entfernte Host einen MSS anzeigt, der kleiner ist als der MSS, der von dem lokalen Host vom TSK gesendet wurde (bspw. sendet der TSK eine MSS-Option von 1460, während der entfernte Host eine MSS-Option von 536 sendet), existiert eine maximale Segmentgrößenfehlanpassung.
  • Eine maximale Segmentgrößenfehlanpassung kann dazu führen, dass der TSK 280 ein TCP-Datensegment von der Backbone-Verbindung empfängt, das größer ist als die maximale Segmentgröße, die von seinem lokalen Host angegeben wurde. Der TSK 280 könnte es einfach weiterleiten. Und in vielen Fällen würde dies funktionieren, da die Puffergröße des Hosts tatsächlich gleich ist zu der MTU. In einigen Fällen würde jedoch die größere Segmentgröße den Puffer des Hosts überlaufen lassen, was dazu führt, dass das Segment verworfen wird. Jede Neuübertragung des Segments würde in ähnlicher Weise verworfen werden.
  • Um dieses Problem zu verhindern, enthält der TSK 280 eine Fähigkeit, Datensegmente neu zu bemessen, die eher von seinem TSK-Partner empfängt, bevor sie an den lokalen Host gesendet werden. Diese Fähigkeit ist nachfolgend beschrieben. Neu bemessene Segmente benötigen jedoch CPU und können dem TSK 280 Komplexität hinzufügen. Der TSK 280 kann von einer Operatorkonfiguration abhängen, um das Problem zu verhindern. Der Operator konfiguriert den MSS, der für eine Verbindung in einem TCP-Spoofing-Parameterprofil verwendet wird, und benutzt Auswahlregeln, um die Verbindung auf das Profil abzubilden.
  • Während bekannt ist, welche Hosts auf welche MSS-Werte abgebildet werden, scheint es arbeitsintensiv zu sein (es erscheint, dass der Operator benötigt wird, um diesen Wert für alle Hosts des Netzwerks zu bestimmen), ist aber in der Praxis nicht so schwierig. Erstens unterstützen die meisten TCP-Implementierungen (bei denen die Anzahl mit der Zeit ansteigt) einen MSS, der auf der MTU der Pfade basiert, die von der Verbindung benutzt werden, wobei der Default-Wert der MSS (1460 Bytes) ist, der von der Ethernet MTU (1500 Bytes) unterstützt wird. Wenn ein Host eine TCP-Verbindung initiiert, sendet er eine MSS-Option in seinem TCP-<SYN>-Segment 401. Somit lernt der TSK 280 den MSS des initiierenden Hosts, wenn er versucht, eine Verbindung aufzubauen. Es ist nur die MSS des antwortenden Hosts, die von dem TSK 280 „geraten" werden muss, um das TCP-Drei-Wege-Handshake zu spoofen. Ein TSK-Partner, der eine CR-Nachricht 403 empfängt, kann den MSS-Wert in der CR-Nachricht verwenden, um die Verbindung auf seiner Seite der Verbindung zu initiieren. Da die meisten VSAT-basierten Intranet-TCP-Verbindungen von den Anwendungen auf der Client-Seite (bspw. Webbrowser) initiiert werden, bedeutet dies allgemein, dass es nur die Hosts auf der Server-Seite sind, für die der Operator die unterstützten MSS-Werte kennen muss. Da die Hosts auf der Server-Seite dazu tendieren, Server zu sein, unterstützen die Hosts auf der Server-Seite sehr wahrscheinlich den maximalen (für Ethernet) MSS-Wert vn 1460 Byte.
  • Obgleich jedoch das Konfigurieren des MSS nicht schwierig sein sollte, umfasst das Spoofing in der vorliegenden Erfindung einen zusätzlichen Mechanismus, der in Fällen eingesetzt werden kann, in denen der Operator der MSS nicht sicher sein kann. Dieser Mechanismus ist in der Fähigkeit zu sehen, das Drei-Wege-Handshake-Spoofing zu sperren, um damit der MSS eine Verbindung zu ermöglichen, die von Ende zu Ende festgelegt wird. Der Operator kann das Drei-Wege-Handshake-Spoofing über einen Parameter in dem TCP-Spoofing-Parameter in dem TCP-Spoofing-Parameterprofil 3404 sperren. Im Normalfall wird das Drei-Wege-Handshake-Spoofing freigegeben sein, um die Leistungsvorteile zu haben, die es bereitstellt.
  • Wie zuvor angedeutet, kann ein Spoofen des Drei-Wege-Handshakes möglicherweise zu einer MSS-Fehlanpassung führen, falls der PEP-Endpunkt 705 ein größeres MSS in dem TCP<SYN,ACK>-Segment 405 angibt, das er sendet, als der entfernte Host endgültig in seiner <SYN,ACK>-Segment 405 angegeben hat.
  • Um sich von einer MSS-Fehlanpassung dynamisch zu erholen, falls der TSK 280 ein TCP-Datensegment von der Backbone-Verbindung empfängt, das größer ist als die maximale Seg mentgröße, die er an den lokalen Host auf der Verbindung senden kann, könnte der TSK 280 das Segment in mehrere kleinere Segmente aufbrechen, bevor sie zu dem lokalen Host weitergeleitet werden. Dies könnte in der TCP-Schicht geschehen, nicht in der IP-Schicht, d.h. dies wird nicht über IP-Paketfragmentierung getan.
  • Das Aufbrechen eines großen Segments in zwei oder mehrere kleinere Segmente ist in 36 gezeigt. Bei einem freigegebenen Drei-Wege-Handshake-Spoofing wird der TSK 280 auf ein TCP-<SYN>-Segment 401 mit einem TCP-<SYN,ACK>-Segment 461 antworten, das einen MSS-Wert anzeigt, der gleich dem Wert ist, der in dem ausgewählten TCP-Spoofing-Parameterprofil 3404 konfiguriert ist. Falls der entfernte Host 406 auf das TCP-<SYN>-Segment 415 antwortet, dass von dem entfernten PEP-Endpunkt 404 gesendet wurde, mit einem TCP-<SYN,ACK>-Segment 467, das ein MSS hat, das kleiner ist als das von dem lokalen PEP-Endpunkt 402 an den lokalen Host 400 gesendete, kann der lokale Host 400 ein TCP-Datensegment 463 senden, das größer ist als der von dem entfernten Host 406 gesendete MSS. Wenn dies passiert, muss der TSK 280 in dem entfernten PEP-Endpunkt 404 die große TD-Nachricht 465 in mehrere kleinere TCP-Datensegmente 469, 471 aufbrechen, bevor sie an den entfernten Host 406 weitergeleitet werden.
  • Das Aufbrechen großer Segmente in ausreichend kleine Segmente garantiert, dass die Segmente von dem lokalen Host angenommen werden. Aber das Aufbrechen großer Segmente in kleinere Segmente hat für den PEP-Endpunkt 705 einen CPU-Nachteil, der damit einhergeht. Das Ausmaß des CPU-Nachteils für eine einzelne PEP-Endpunktplattform kann abhängig sein von der Pufferstrategie, die in der Plattform verwendet wird. Falls bspw. eine Kette von kleinen physischen Puffern verwendet wird, umfasst das Aufbrechen eines großen Segments in kleine Segmente hauptsächlich das Aufbrechen der Pufferkette in geeignete Plätze und kann ohne Kopieren von Daten ausgeführt werden. Falls jedoch ein einzelner großer physischer Puffer verwendet wird, würde das Aufbrechen eines großen Segments in kleine Segmente ein Datenkopieren umfassen.
  • Während maximale Segmentgrößenfehlanpassungen eine CPU-Strafe bzw. einen Nachteil nach sich ziehen, verbessert das Senden großer Segmente über die Backbone-Verbindung die Bandbreiteneffizienz durch Reduzieren des Header-Überhangs bzw. Overheads. In einigen Fällen kann es wünschenswerter sein, Bandbreite effizienter zu nutzen auf Kosten der Verwendung von CPU in den PEP-Endpunkten 705. Falls ein Segment neu bemessen implementiert ist, kann der Operator die für eine TCP-Verbindung zu verwendende MSS absichtlich größer als die aktuell von dem Host unterstützte MSS konfigurieren.
  • Falls eine MSS-Fehlanpassung auftritt, falls von dem Operator so konfiguriert, könnte der TCP-Spoofing-Kern 280 versuchen, den Host am sendenden Ende dazu zu bringen, die Größe des MSS zu reduzieren, die er verwendet, um Daten über das Wide Area Network zu senden. Ein Mechanismus, der verwendet werden könnte, um dies auszuführen, basiert auf dem Path MTU (PMTU) Discovery-Algorithmus, der in RFC 1191 beschrieben ist, dessen gesamter Inhalt hiermit durch Bezugnahme aufgenommen wird. Die PMTU-Discovery arbeitet, indem das „Nichtfragmentieren"-Bit in dem IP-Header aller IP-Pakete, die gesendet werden, gesetzt wird, einschließlich der TCP-Datensegmente. Falls dann ein Paket von einem Router empfangen wird, das zu groß ist für die MTU des nächsten Sprungs des Pfads, sendet der Router eine ICMP „Datagramm-zu-groß"-Nachricht. Die ICMP „Datagramm-zu-groß"-Nachricht umfasst ein Kennzeichen des nächsten Sprung-MTU. Dies ermöglicht, dass der Host die ursprünglichen TCP-Datensegmente in kleinere Segmente aufbricht und sie nochmals sendet.
  • Um einer maximalen Segmentgrößenfehlanpassung entgegenzutreten, könnte der TSK 280 versuchen, das PMTU-Discovery-Verhalten des End-Hosts aufzurufen. Falls der TSK 280 eine CE-Nachricht 419 von seinem TSK-Partner mit einem MSS empfängt, das kleiner ist als das MSS, das es bereits lokal zu dem End-Host gesendet hat, würde der TSK 280 eine ICMP-„Datagramm-zu-groß"-Nachricht an den Host erzeugen, die an einen MTU-Wert, der mit dem kleineren MSS übereinstimmt. Der Host würde hoffentlich darauf reagieren, indem er kleinere TCP-Datensegmente zu senden beginnt. Falls dies nicht so ist, könnte der TSK-280-Partner dazu gezwungen werden, kontinuierlich größere Segmente in kleinere Segmente aufzubrechen. Aber dies ist nicht anders als wenn keine ICMP-Nachricht gesendet würde. Es sei angemerkt, dass selbst wenn die ICMP-„Datagramm-zu-groß"-Nachricht nicht arbeitet, der End-Host bereits einige größere TCP-Datensegmente gesendet haben kann, die von dem TSK 280 lokal bestätigt werden würden. Diese großen Datensegmente müssten in kleinere Segmente vor dem Senden an den Ziel-Host aufgebrochen werden. Aber die CPU, die dies durchführen muss, würde nur für die ersten paar Datensegmente beansprucht werden.
  • Das Reduzieren der maximalen Segmentgröße, die von dem Host verwendet wird, ist in 37 dargestellt. Wenn der lokale PEP-Endpunkt 402 die CE-Nachricht 473 empfängt, die anzeigt, dass ein kleinerer MSS von dem entfernten Host 406 verwendet wird, als dies von dem lokalen Host 400 angezeigt wurde, kann der TSK 280 eine ICMP-„Datagramm-zu-groß"-Nachricht 475 senden, die anzeigt, dass der MTU des Netzwerks nun gleich dem MSS ist, der von dem entfernten Host 406 gesendet wurde, plus der Größe des IP- und TCP-Headers (40 Byte). Der lokale Host 400 kann dann das Starten der TCP-Datensegmente 477 beginnen, die mit dem MSS übereinstimmen, der von dem entfernten Host 406 verwendet wird.
  • Wie zuvor angegeben, würde der Versuch, die maximale Segmentgröße, die von einem Host gesendet wird, zu reduzieren, von einer Operatorkonfiguration gesteuert. Im Normalfall würde die MSS-Reduktion freigegeben sein. Aber der Operator könnte sie für spezifische Verbindungen mittels der TCP-Spoofing-Parameterprofile, die für die Verbindungen ausgewählt werden, sperren. Der Operator könnte das Abschalten der MSS-Reduktions-ICMP-Nachrichten auswählen, entweder weil einige unvorhergesehene Nebenwirkungen der Benutzung mit bestimmten Hosts eingetreten sind oder wegen einer Entscheidung, die CPU in den PEP-Endpunkten 705 zum Aufbrechen großer Segmente in kleine Segmente einzusetzen, um Bandbreiteneffizienz für das Wide Area Network zu gewinnen, die mit der Verwendung größerer Pakete über das WAN verknüpft ist.
  • Falls aus einem bestimmten Grund ein Host den MSS-Wert ignoriert, der ihm von den TSK gesendet wurde, und ein Segment größer als die konfigurierte MSS an den TSK sendet, kann der TSK das Segment verwerfen. Dies kann möglicherweise dazu führen, dass die TCP-Verbindung fehlschlägt und eine In tervention des Operators erfordert, um dies zu korrigieren. Allerdings könnte das Nichtverwerfen solcher Segmente dazu führen, dass die Backbone-Verbindung ausfällt und ein Backbone-Verbindungsausfall würde viele TCP-Verbindungen anstelle nur einer betreffen.
  • Wenn ein TSK 280 eine Fenstergröße bestimmen muss, um sie in einem TCP-Segment anzugeben, startet er durch Aufruf der Plattformumgebung 210, um die aktuelle LAN zu WAN-Puffergröße zu erhalten, die für die Backbone-Verbindung verfügbar ist, die mit der gespooften TCP-Verbindung verknüpft ist. Der TSK 280 dividiert dann diese Anzahl durch die Anzahl der TCP-Verbindungen, die aktuell die Backbone-Verbindung benutzen (der TSK verfolgt die Anzahl der TCP-Verbindungen, die eine Backbone-Verbindung benutzen, in dem TCB der Backbone-Verbindung und erhöht den Zähler, wann immer ein CCB belegt wird und verringert den Zähler, wann immer ein CCB freigegeben wird.) Der TSK 280 wandelt dann diesen Wert von Puffer in Bytes durch Multiplizieren der Anzahl der Puffer mit dem MSS um, der von dem lokalen Host benutzt wird, um TCP-Segmente an den TSK 280 zu senden. Dieser Wert stellt die mögliche Fenstergröße dar, die angezeigt werden kann. Der TSK muss jedoch zwei zusätzliche Überprüfungen durchführen, bevor er diesen wert verwendet. Der mögliche Wert wird zuerst mit der Fenstergrößen-Grenze verglichen. Falls der mögliche Wert größer ist als die Fenstergrößen-Grenze, wird statt dessen die Fenstergrößen-Grenze angezeigt. Falls der mögliche Wert kleiner ist als die Fenstergrößen-Grenze, prüft der TSK 280 dann, um zu sehen, ob das Anzeigen des möglichen Werts das Fenster auf einen Wert schrumpfen ließe, der kleiner ist als der zuvor angezeigte (d.h. es würde das rechte Ende des drehenden Fensters nach links bewegt). Ein TCP-Empfänger wird das Fenster nicht schrumpfen. Falls deshalb der mögliche Wert das Fenster schrumpfen würde, zeigt der TSK 280 statt dessen das kleinste mögliche Fenster an, das nicht das zuvor angezeigte Fenster schrumpfen würde (d.h. der Wert, der anzeigt, dass das rechte Ende des Fensters an der gleichen Stelle gehalten wird).
  • 38 zeigt ein Compute rsystem 3601, auf dem die Ausführungsform der vorliegenden Erfindung implementiert sein kann. Ein solches Computersystem 3601 kann als Server konfiguriert sein, um den Code auszuführen, der die PEP-Funktionen des PEP-Endpunkts 210, wie zuvor diskutiert, ausführt. Das Computersystem 3601 umfasst einen Bus 3603 oder einen anderen Kommunikationsmechanismus zur Kommunikation von Information, und einen Prozessor 3605, der mit dem Bus 3603 zur Verarbeitung der Information gekoppelt ist. Das Computersystem 3601 umfasst ebenfalls einen Hauptspeicher 3607, wie beispielsweise einen Speicher mit wahlfreiem Zugriff (RAM) oder einer anderen dynamischen Speichervorrichtung, die mit dem Bus 3603 gekoppelt ist, um Information und Befehle zu speichern, die von dem Prozessor 3605 ausgeführt werden. Zusätzlich kann der Hauptspeicher 3607 zum Speichern temporärer Variablen oder anderer Zwischeninformation während der Ausführung der Befehle verwendet werden, die von dem Prozessor 3605 ausgeführt werden. Der Hauptspeicher 3607 kann ebenfalls verwendet werden, um PEP-Steuerungsblöcke und Puffer zu teilen, die Pakete speichern. Das Computersystem 3601 umfasst ferner einen Nur-Lese-Speicher (ROM) 3609 oder eine andere statische Speichervorrichtung, die mit dem Bus 3603 zum Speichern statischer Information und Befehle für den Prozessor 3605 verbunden ist. Eine Speichervorrichtung 3611, wie beispielsweise eine Magnetplatte oder eine optische Platte, ist vorgesehen und mit dem Bus 3603 zum Speichern von Information und Befehlen verbunden.
  • Das Computersystem 3601 kann über den Bus 3603 mit einem Display 3613 gekoppelt sein, wie beispielsweise eine Kathodenstrahlröhre (CRT), um Information einem Computernutzer anzuzeigen. Eine Eingabevorrichtung 3615, die alphanumerische und andere Tasten umfasst, ist mit dem Bus 3603 zur Kommunikation von Information und zur Befehlsauswahl an den Prozessor 3605 verbunden. Ein anderer Typ von Benutzereingabevorrichtung ist die Cursorsteuerung 3617, wie beispielsweise eine Maus, ein Trackball oder Cursorrichtungstasten zur Kommunikation von Richtungsinformation und Befehlsauswahlen an den Prozessor 3605 und zum Steuern der Cursorbewegung auf dem Display 3613.
  • Ausführungsformen werden auf die Benutzung des Computersystems 3601 bezogen, um die PEP-Funktionen des PEP-Endpunkts 210 auszuführen. Entsprechend einer Ausführungsform wird dieser automatische Update-Lösungsweg von dem Computersystem 3601 in Antwort auf den Prozessor 3605 bereitgestellt, der ein oder mehrere Sequenzen einer oder mehrerer Befehle ausführt, die in dem Hauptspeicher 3607 gespeichert sind. Solche Befehle können in den Hauptspeicher 3607 aus einem anderen computerlesbaren Medium, wie beispielsweise eine Speichervorrichtung 3611, gelesen werden. Die Ausführung der Sequenzen von Befehlen, die in dem Hauptspeicher 3607 enthalten sind, lässt den Prozessor 3605 die hier beschriebenen Verfahrensschritte ausführen. Einer oder mehrere Prozessoren in einer Mehrprozessor-Anordnung können ebenfalls verwendet werden, um die Sequenz bzw. Folge von Befehlen auszuführen, die in dem Hauptspeicher 3607 enthalten sind. In alternativen Ausführungsformen kann eine fest verdrahtete Schaltung anstelle oder in Kombination mit Softwarebefehlen verwendet werden. Somit sind die Ausführungsformen nicht auf spezifische Kombinationen von Hardwareschaltung und Software begrenzt.
  • Der Begriff "computerlesbares Medium", wie er hier verwendet wird, betrifft jegliches Medium, das bei der Bereitstellung von Befehlen an den Prozessor 3605 zur Ausführung der PEP-Funktionen des PEP-Endpunkts 210 teilhaben kann. Ein solches Medium kann viele Formen annehmen, einschließlich, aber nicht beschränkend auf nicht flüchtige Medien, flüchtige Medien und Übertragungsmedien. Nicht flüchtige Medien umfassen beispielsweise optische oder magnetische Platten, wie beispielsweise eine Speichervorrichtung 3611. Flüchtige Medien umfassen dynamische Speicher, wie beispielsweise den Hauptspeicher 3607. Übertragungsmedien umfassen Koaxialkabel, Kupferleitungen und Faseroptiken, einschließlich der Drähte bzw. Leitungen des vorhandenen Busses 3603. Das Übertragungsmedium kann ebenfalls die Form akustischer Wellen oder Lichtwellen annehmen, wie beispielsweise jene, die während einer Funkwellen- und Infrarotdatenkommunikation erzeugt werden.
  • Allgemeine Formen von computerlesbaren Medien umfassen beispielsweise eine Floppy Disk, eine flexible Disk, eine Harddisk, Magnetbänder oder andere magnetische Medien, ein CD-ROM, andere optische Medien, Lochkarten, Papierbänder und andere physikalische Medien mit Lochmustern, RAM, PROM, und EPROM, ein FLASH-EPROM oder andere Speicherchips oder Karten, Trägerwellen, wie nachfolgend beschrieben, oder andere Medien, von denen ein Computer lesen kann.
  • Verschiedene Formen computerlesbarer Medien können beteiligt sein, ein oder mehrere Sequenzen einer oder mehrerer Befehle für den Prozessor 3605 zur Ausführung zu tragen. Beispielsweise können die Befehle anfänglich auf einer Magnetplatte eines entfernten Computers liegen. Der entfernte Computer kann die Befehle, die die Ausführung der PEP-Funktionen des PEP-Endpunkts 210 betreffen, in seinen dynamischen Speicher laden, und die Befehle über eine Telefonleitung unter Einsatz eines Modems senden. Ein Modem, das lokal am Computersystem 3601 vorhanden 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 3603 verbunden ist, kann die Daten, die in dem Infrarotsignal getragen werden, empfangen und die Daten auf den Bus 3603 bringen. Der Bus 3603 trägt die Daten zu dem Hauptspeicher 3607, aus dem der Prozessor 3605 die Befehle holt und ausführt. Diese Befehle, die von dem Hauptspeicher 3607 empfangen werden, können optional auf der Speichervorrichtung 3611 entweder vor oder nach der Ausführung durch den Prozessor 3605 gespeichert werden.
  • Das Computersystem ×01 umfasst auch eine oder mehrere Kommunikationsschnittstellen 3619, die mit dem Bus 3603 gekoppelt sind. Die Kommunikationsschnittstellen 3619 bieten eine Zwei-Wege-Datenkommunikation, die die Netzwerkverbindungen 3621 und 3622 koppelt, die mit einem local area network (LAN) 3623 bzw. einem wide area network 3624 verbunden sind. Ein WAN 3624 entsprechend einer Ausführungsform der vorliegenden Erfindung kann ein Satellitennetzwerk sein. Beispielsweise kann die Kommunikationsschnittstelle 3619 eine Netzwerkschnittstellenkarte sein, die mit jedem Paket vermittelten LAN verbunden werden kann. Als weiteres Beispiel kann eine Kommunikationsschnittstelle 3619 eine asymmetrical digital subscriber line (ADSL) Karte sein, eine integrated services digital network (ISDN) Karte sein, ein Kabelmodem oder ein Modem sein, um eine Datenkommunikationsverbindung mit einer entsprechenden Telefonleitung herzustellen. Drahtlose Verbindungen können ebenfalls implementiert sein. Bei einer solchen Implementierung sendet die Kommunikationsschnittstelle 3619 und empfängt elektrische, elektromagnetische oder optische Signale, die digitale Datenströme tragen, die verschiedene Typen von Information darstellen.
  • Die Netzwerkverbindung 3621 stellt typischerweise eine Datenkommunikation über ein oder mehrere Netzwerke zu anderen Datenvorrichtungen bereit. Die Netzwerkverbindung 3621 kann beispielsweise eine Verbindung durch ein Local-area-Netzwerk 3623 zu einem Host-Computer 3625 oder zu einem Datengerät bereitstellen, das von einem Internet Service Provider (ISP) 3627 betrieben wird. Der ISP 3627 stellt wiederum Datenkommunikationsdienste über das Internet 505 bereit. Zusätzlich ist das LAN 3623 mit einem Intranet ×29 verbunden. Das Intranet ×29, das LAN ×23 und das Internet 505 benutzen alle elektrische, elektromagnetische oder optische Signale, die digitale Datenströme tragen. Die Signale durch die verschiedenen Netzwerke und die Signale auf der Netzwerkverbindung 3621 und durch die Kommunikationsschnittstelle 3519, die digitale Daten zu und von dem Computersystem 3601 tragen, sind beispielhafte Formen von Trägerwellen, die Information tragen.
  • Das Computersystem 3601 kann Nachrichten senden und Daten empfangen, einschließlich Programmcode, über das Netzwerk/die Netzwerke, Netzwerkverbindung 3621 und Kommunikationsschnittstelle 3619. Bei dem Internetbeispiel könnte ein Server ×31 einen Anforderungscode für ein Anwendungsprogramm über das Internet 505, ISP 3627, LAN 3623 und Kommunikationsschnittstelle 3619 senden.
  • Der empfangene Code kann von dem Prozessor 3605 bei dessen Empfang ausgeführt werden und/oder in der Speichervorrichtung 3611, oder einem nicht flüchtigen Speicher zur späteren Ausführung gespeichert werden. Auf diese Art und Weise kann das Computersystem 3601 Anwendungscode in Form einer Trägerwelle erhalten.
  • Das Computersystem 3601 kann Mitteilungen senden und Daten empfangen, einschließlich Programmcode, über das Netzwerk/die Netzwerke, die Netzwerkverbindung 3621 und Kommunikationsschnittstellen 3619.
  • Die hier beschriebenen Techniken liefern mehrere Vorteile gegenüber bekannten Lösungen, um die Netzwerkleistung zu verbessern, insbesondere in einem paketvermittelten Netzwerk wie das Internet. Ein lokaler PEP-Endpunkt und ein entfernter PEP-Endpunkt kommunizieren, um den Austausch von Daten über eine TCP-Spoofing-Funktionalität zu optimieren. Eine Vereinfachung der Konfiguration der Endpunkte durch Verwendung von Profilen wird bereitgestellt.
  • Offensichtlich sind zahlreiche Modifikationen und Veränderungen der vorliegenden Erfindung im Lichte der vorherigen Lehren möglich. Es versteht sich deshalb, dass innerhalb des Rahmens der angehängten Ansprüche die Erfindung auch anders als speziell hier beschrieben praktiziert werden kann.

Claims (56)

  1. Verfahren zum Leiten von Informationen in einem Kommunikationssystem (100), das eine Plattform (210) aufweist, die konfiguriert ist, um eine Vielzahl von leistungsverbessernden Funktionen auszuführen, wobei das Verfahren aufweist: Empfangen der Information von der Plattform (210); Empfangen von zumindest einem der Spoofing-Auswahlparameter und der Spoofing-Parameter, wobei die Plattform (210) ein Profil aufrechterhält, das wenigstens die Spoofing-Auswahl oder die Spoofing-Parameter enthält, gekennzeichnet durch: Zuweisen eines Verbindungssteuerungsblocks (1608) an eine Verbindung, die von der Plattform (210) zu einem Host gestützt wird; Speichern der Verbindungsinformation, die die Verbindung in dem Verbindungssteuerungsblock (1608) betrifft; und Lenken der empfangenen Information an eine Partnerplattform über eine Backbone-Verbindung entsprechend dem Profil, falls die Partnerplattform einen entsprechenden Verbindungssteuerungsblock (1608) hat.
  2. Verfahren nach Anspruch 1, ferner mit: Bestimmen eines Pfads, den die Information nimmt, um ihr Ziel basierend auf dem Profil zu erreichen.
  3. Verfahren nach Anspruch 2, ferner mit: Bestimmen des Pfads durch Anwenden von Spoofing-Regeln.
  4. Verfahren nach Anspruch 2, wobei der Pfad basierend auf den zugewiesenen Verbindungssteuerungsblöcken bestimmt wird.
  5. Verfahren nach Anspruch 4, wobei die zugewiesenen Verbindungssteuerungsblöcke zugewiesen werden, indem eine Hash-Funktion verwendet wird.
  6. Verfahren nach Anspruch 4, wobei die zugewiesenen Verbindungssteuerungsblöcke zugewiesen werden, indem eine Abbildungsquelle benutzt wird.
  7. Verfahren nach Anspruch 3, wobei die Spoofing-Regeln auf das Profil abgebildet werden.
  8. Verfahren nach Anspruch 1, ferner mit: Empfangen der Spoofing-Auswahlparameter oder der Spoofing-Parameter als eine Datenstruktur von der Plattform (210).
  9. Verfahren nach Anspruch 1, ferner mit: Empfangen wenigstens der Spoofing-Auswahlparameter oder Spoofing-Parameter von der Plattform (210) beim Start oder wenn die Plattform (210) aktualisierte Spoofing-Auswahl oder Spoofing-Parameter empfängt.
  10. Verfahren nach Anspruch 1, ferner mit: Anwenden mehrerer Spoofing-Regeln, indem Boolesche Operatoren benutzt werden.
  11. Verfahren nach Anspruch 1, ferner mit: Aufteilen der empfangenen Information in ein oder mehrere Datensegmente; und Kompensieren der maximalen Segmentgrößen-Fehlanpassungen.
  12. Verfahren nach Anspruch 11, wobei das Kompensieren ein dynamisches Neubemessen der Datensegmente aufweist, die die Information enthalten, bevor die Datensegmente weiter transportiert werden.
  13. Verfahren nach Anspruch 11, wobei das Profil ferner eine maximale Segmentgröße aufweist.
  14. Verfahren nach Anspruch 11, wobei das Profil ferner einen Parameter zum Sperren des Dreiwege-Handshake-Spoofing aufweist.
  15. Kommunikationssystem (100) mit: einer Plattform (210), die konfiguriert ist, um leistungsverbessernde Funktionen für das Kommunikationssystem (100) bereitzustellen, wobei die Plattform (210) Information und wenigstens Spoofing-Auswahl oder Spoofing-Parameter liefert, wobei die Plattform (210) aufweist: eine Spoofing-Vorrichtung, die konfiguriert ist, um die Information zu empfangen und wenigstens die Spoofing-Auswahl oder die Spoofing-Parameter von der Plattform (210) zu empfangen, dadurch gekennzeichnet, dass die Spoofing-Vorrichtung aufweist: eine Logik zur Zuweisung eines Verbindungssteuerungsblocks (1608) an eine Verbindung, die von der Plattform (210) zu einem Host gestützt wird, wobei der Verbindungssteuerungsblock (1608) die Verbindungsinformation bezüglich der Verbindung spezifiziert, einen Speicher zum Speichern eines Profils, das wenigstens die Spoofing-Auswahl oder die Spoofing-Parameter spezifiziert, und Mittel zum Lenken der Information zu einer Partnerplattform über eine Backbone-Verbindung entsprechend dem Profil, falls die Partnerplattform einen entsprechenden Verbindungssteuerungsblock (1608) hat.
  16. Kommunikationssystem nach Anspruch 15, wobei die Spoofing-Vorrichtung konfiguriert ist, um einen Pfad zu bestimmen, den die Information nimmt, um ihr Ziel zu erreichen.
  17. Kommunikationssystem nach Anspruch 16, wobei die Spoofing-Vorrichtung konfiguriert ist, um den Pfad zu bestimmen, indem Spoofing-Regeln angewendet werden.
  18. Kommunikationssystem nach Anspruch 16, wobei die Mittel zum Lenken ferner ausgelegt sind, um den Pfad zu bestimmen, basierend auf den zugewiesenen Verbindungssteuerungsblöcken.
  19. Kommunikationssystem nach Anspruch 18, wobei die Logik ausgelegt ist, um Verbindungssteuerungsblöcke zuzuweisen, indem eine Hash-Funktion verwendet wird.
  20. Kommunikationssystem nach Anspruch 18, wobei die Logik ausgelegt ist, um die Verbindungssteuerungsblöcke zuzuweisen, indem eine Abbildungstabelle verwendet wird.
  21. Kommunikationssystem nach Anspruch 17, wobei die Spoofing-Vorrichtung konfiguriert ist, um Spoofing-Regeln auf das Profil abzubilden.
  22. Kommunikationssystem nach Anspruch 15, wobei die Spoofing-Vorrichtung konfiguriert ist, um wenigstens die Spoofing-Auswahlparameter oder die Spoofing-Parameter als eine Datenstruktur von der Plattform zu empfangen.
  23. Kommunikationssystem nach Anspruch 15, wobei die Spoofing-Vorrichtung konfiguriert ist, um wenigstens die Spoofing-Auswahlparameter oder die Spoofing-Parameter von der Plattform beim Start zu empfangen, oder wenn die Plattform aktualisierte Spoofing-Auswahl oder Spoofing-Parameter empfängt.
  24. Kommunikationssystem nach Anspruch 15, wobei die Spoofing-Vorrichtung konfiguriert ist, um mehrere Spoofing-Regeln anzuwenden, indem Boolesche Operatoren verwendet werden.
  25. Kommunikationssystem nach Anspruch 15, ferner mit Mittel zum Aufteilen der empfangenen Information in ein oder mehrere Datensegmente; und Mittel zum Kompensieren der maximalen Segmentgrößen-Fehlanpassungen.
  26. Kommunikationssystem nach Anspruch 25, wobei das Mittel zum Kompensieren ferner ausgelegt ist, um die Datensegmente dynamisch neu zu bemessen, die die Information enthalten, bevor die Datensegmente weiter transportiert werden.
  27. Kommunikationssystem nach Anspruch 25, wobei das Profil ferner eine maximale Segmentgröße aufweist.
  28. Kommunikationssystem nach Anspruch 25, wobei das Profil ferner einen Parameter zum Sperren des Dreiwege-Handshake-Spoofings aufweist.
  29. Plattformvorrichtung zur Kommunikation in einem Kommunikationssystem, wobei die Vorrichtung aufweist: Mittel zum Empfangen von Information von einem Host; Mittel zum Aufrechterhalten eines Profils, das wenigstens Spoofing-Auswahl oder Spoofing-Parameter enthält, gekennzeichnet durch: Mittel zum Zuweisen eines Verbindungssteuerungsblocks (1608) zu einer Verbindung, die von der Plattform zu einem Host gestützt wird; Mittel zum Speichern der Verbindungsinformation bezüglich der Verbindung in dem Verbindungssteuerungsblock (1608); und Mittel zum Lenken der empfangenen Information zu einer Partnerplattform über eine Backbone-Verbindung entsprechend dem Profil, falls die Partnerplattform einen entsprechenden Verbindungssteuerungsblock (1608) hat.
  30. Plattformvorrichtung nach Anspruch 29, ferner mit: Mittel zum Bestimmen eines Pfads, den die Information nimmt, um ihr Ziel zu erreichen.
  31. Plattformvorrichtung nach Anspruch 30, ferner mit: Mittel zum Bestimmen des Pfads durch Anwenden von Spoofing-Regeln.
  32. Plattformvorrichtung nach Anspruch 30, wobei das Mittel zum Zuweisen eines Verbindungssteuerungsblocks (1608) konfiguriert ist, um den Pfad basierend auf den Verbindungssteuerungsblöcken zu bestimmen.
  33. Plattformvorrichtung nach Anspruch 32, wobei das Mittel zum Zuweisen eines Verbindungssteuerungsblocks konfiguriert ist, um einen Verbindungssteuerungsblock (1608) durch Verwenden einer Hash-Funktion zuzuweisen.
  34. Plattformvorrichtung nach Anspruch 32, wobei das Mittel zum Zuweisen eines Verbindungssteuerungsblocks (1608) konfiguriert ist, um Verbindungssteuerungsblöcke durch Verwendung einer Abbildungstabelle zuzuweisen.
  35. Plattformvorrichtung nach Anspruch 31, wobei das Mittel zum Bestimmen des Pfads konfiguriert ist, um die Spoofing-Regeln auf das Profil abzubilden.
  36. Plattformvorrichtung nach Anspruch 29, ferner mit: Mittel zum Empfangen wenigstens der Spoofing-Auswahlparameter oder der Spoofing-Parameter als eine Datenstruktur.
  37. Plattformvorrichtung nach Anspruch 29, ferner mit: Mittel zum Empfangen wenigstens der Spoofing-Auswahlparameter oder der Spoofing-Parameter beim Start, oder wenn aktualisierte Spoofing-Auswahl oder Spoofing-Parameter empfangen werden.
  38. Plattformvorrichtung nach Anspruch 29, ferner mit: Mittel zum Anwenden mehrerer Spoofing-Regeln, indem Boolesche Operatoren verwendet werden.
  39. Plattformvorrichtung nach Anspruch 29, ferner mit: Mittel zum Aufteilen der empfangenen Information in ein oder mehrere Datensegmente; und Mittel zum Kompensieren der maximalen Segmentgrößenfehlanpassungen.
  40. Plattformvorrichtung nach Anspruch 39, wobei das Kompensierungsmittel aufweist: Mittel zum dynamischen Neubemessen der Datensegmente, die die Information enthalten, bevor die Datensegmente weiter transportiert werden.
  41. Plattformvorrichtung nach Anspruch 39, wobei das Profil ferner eine maximale Segmentgröße umfasst.
  42. Plattformvorrichtung nach Anspruch 39, wobei das Profil ferner einen Parameter zum Sperren des Dreiwege-Handshake-Spoofings aufweist.
  43. Computerlesbares Medium, das eine oder mehrere Sequenzen von einem oder mehreren Befehlen trägt, um Information in einem Kommunikationssystem zu lenken, das eine Plattform (210) umfasst, die ausgelegt ist, um eine Vielzahl von leistungsverbessernden Funktionen auszuführen, wobei die eine oder die mehreren Sequenzen einen oder mehrere Befehle umfassen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren die Schritte ausführen lassen: Empfangen der Information von der Plattform (210); Empfangen wenigstens der Spoofing-Auswahlparameter oder Spoofing-Parameter, wobei die Spoofing-Vorrichtung ein Profil aufrechterhält, das wenigstens die Spoofing-Auswahl oder die Spoofing-Parameter enthält, gekennzeichnet durch Zuweisen eines Verbindungssteuerungsblocks (1608) an eine Verbindung, die von der Plattform (210) zu einem Host gestützt wird; Speichern der Verbindungsinformation betreffend die Verbindung in dem Verbindungssteuerungsblock (1608); und Leiten der empfangenen Information an eine Partnerplattform über eine Backbone-Verbindung entsprechend dem Profil, falls die Partnerplattform einen entsprechenden Verbindungssteuerungsblock (1608) aufweist.
  44. Computerlesbares Medium nach Anspruch 43, ferner mit: Bestimmen eines Pfads, den die Information nimmt, um ihr Ziel zu erreichen, basierend auf dem Profil.
  45. Computerlesbares Medium nach Anspruch 44, ferner mit: Bestimmen des Pfads durch Anwenden von Spoofing-Regeln.
  46. Computerlesbares Medium nach Anspruch 45, wobei der Pfad bestimmt wird basierend auf den zugewiesenen Verbindungssteuerungsblöcken.
  47. Computerlesbares Medium nach Anspruch 48, wobei die zugewiesenen Verbindungssteuerungsblöcke zugewiesen werden, indem eine Hash-Funktion verwendet wird.
  48. Computerlesbares Medium nach Anspruch 46, wobei die Verbindungssteuerungsblöcke zugewiesen werden, indem eine Abbildungstabelle verwendet wird.
  49. Computerlesbares Medium nach Anspruch 45, wobei die Spoofing-Regeln auf das Profil abgebildet werden.
  50. Computerlesbares Medium nach Anspruch 43, ferner mit: Empfangen wenigstens der Spoofing-Auswahlparameter oder der Spoofing-Parameter als eine Datenstruktur von der Plattform.
  51. Computerlesbares Medium nach Anspruch 43, ferner mit: Empfangen wenigstens der Spoofing-Auswahlparameter oder der Spoofing-Parameter von der Plattform beim Start, oder wenn die Plattform aktualisierte Spoofing-Auswahl oder Spoofing-Parameter empfängt.
  52. Computerlesbares Medium nach Anspruch 43, ferner mit: Anwenden mehrerer Spoofing-Regeln, indem Boolesche Operatoren verwendet werden.
  53. Computerlesbares Medium nach Anspruch 43, ferner mit: Kompensieren der maximalen Segmentgrößenfehlanpassungen.
  54. Computerlesbares Medium nach Anspruch 53, wobei das Kompensieren ein dynamisches Neubemessen der Datensegmente aufweist, die die Information enthalten, bevor die Datensegmente weitergeleitet werden.
  55. Computerlesbares Medium nach Anspruch 53, wobei das Profil ferner eine maximale Segmentgröße enthält.
  56. Computerlesbares Medium nach Anspruch 53, wobei das Profil ferner einen Parameter zum Sperren des Dreiwege-Handshake-Spoof ings enthält.
DE60116447T 2000-07-21 2001-07-20 Verfahren und System zur Verbindungsbehandlung Expired - Fee Related DE60116447T2 (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
DE60116447D1 DE60116447D1 (de) 2006-03-30
DE60116447T2 true DE60116447T2 (de) 2006-09-28

Family

ID=26914502

Family Applications (8)

Application Number Title Priority Date Filing Date
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
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
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
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
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
DE60117723T Expired - Lifetime DE60117723D1 (de) 2000-07-21 2001-07-20 Verfahren und system zur Setzung von Verkehrsprioritäten in einem Netz

Family Applications Before (4)

Application Number Title Priority Date Filing Date
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
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
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
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

Family Applications After (3)

Application Number Title Priority Date Filing Date
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
DE60117723T Expired - Lifetime DE60117723D1 (de) 2000-07-21 2001-07-20 Verfahren und system zur Setzung von Verkehrsprioritäten in einem Netz

Country Status (5)

Country Link
US (8) US7213077B2 (de)
EP (8) EP1175065B1 (de)
CA (8) CA2353325A1 (de)
DE (8) DE60118305D1 (de)
IL (8) IL144432A0 (de)

Families Citing this family (346)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8195823B2 (en) * 2000-04-17 2012-06-05 Circadence Corporation Dynamic network link acceleration
US8024481B2 (en) * 2000-04-17 2011-09-20 Circadence Corporation System and method for reducing traffic and congestion on distributed interactive simulation networks
US20110128972A1 (en) 2000-04-17 2011-06-02 Randy Thornton Peer to peer dynamic network link acceleration
US8898340B2 (en) 2000-04-17 2014-11-25 Circadence Corporation Dynamic network link acceleration for network including wireless communication devices
AU2001255441A1 (en) 2000-04-17 2001-10-30 Circadence Corporation System and method for implementing application -independent functionality within a network infrastructure
US8996705B2 (en) 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
US8065399B2 (en) * 2000-04-17 2011-11-22 Circadence Corporation Automated network infrastructure test and diagnostic system and method therefor
US8510468B2 (en) 2000-04-17 2013-08-13 Ciradence Corporation Route aware network link acceleration
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
US7213077B2 (en) * 2000-07-21 2007-05-01 Hughes Network Systems, Inc. Method and system for providing buffer management in a performance enhancing proxy architecture
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
US7336613B2 (en) * 2000-10-17 2008-02-26 Avaya Technology Corp. Method and apparatus for the assessment and optimization of network traffic
DE60141417D1 (de) 2000-10-17 2010-04-08 Avaya Technology Corp Verfahren und vorrichtung zur optimierung der leistung und des kosten in einem internetzwerk
US7720959B2 (en) * 2000-10-17 2010-05-18 Avaya Inc. Method and apparatus for characterizing the quality of a network path
US7487237B2 (en) * 2000-10-17 2009-02-03 Avaya Technology Corp. Load optimization
US7406539B2 (en) * 2000-10-17 2008-07-29 Avaya Technology Corp. Method and apparatus for performance and cost optimization in an internetwork
US7349994B2 (en) 2000-10-17 2008-03-25 Avaya Technology Corp. Method and apparatus for coordinating routing parameters via a back-channel communication medium
US7756032B2 (en) 2000-10-17 2010-07-13 Avaya Inc. Method and apparatus for communicating data within measurement traffic
US8023421B2 (en) * 2002-07-25 2011-09-20 Avaya Inc. Method and apparatus for the assessment and optimization of network 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
US20050036496A1 (en) * 2001-03-19 2005-02-17 Bob Tang 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
US7668966B2 (en) * 2001-11-02 2010-02-23 Internap Network Services Corporation Data network controller
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
EP1446920B1 (de) * 2001-11-12 2009-02-11 Telefonaktiebolaget LM Ericsson (publ) Verfahren zur bereitstellung von quality-of-service in systemen gemäss ieee 802.11
US20030131079A1 (en) * 2001-11-13 2003-07-10 Ems Technologies, Inc. Performance enhancing proxy techniques for internet protocol traffic
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
US7398552B2 (en) * 2002-01-28 2008-07-08 Hughes Network Systems, Llc Method and system for integrating performance enhancing functions in a 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
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
US8976798B2 (en) * 2002-01-28 2015-03-10 Hughes Network Systems, Llc Method and system for communicating over a segmented virtual private network (VPN)
US20030172264A1 (en) * 2002-01-28 2003-09-11 Hughes Electronics Method and system for providing security in 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 삼성전자주식회사 동적 ｉｐ 네트워크 상에서의 ｐｍｔｕ 변경 방법 및 그장치
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
US20040081089A1 (en) * 2002-09-26 2004-04-29 Sharp Laboratories Of America, Inc. Transmitting data on scheduled channels in a centralized network
US7653012B2 (en) * 2002-09-26 2010-01-26 Sharp Laboratories Of America, Inc. Relay transmission of data in a centralized network
US7542471B2 (en) * 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US7630305B2 (en) * 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
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
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
EP1570392A4 (de) * 2002-11-08 2006-09-27 Arbitration Forums Inc System und prozesszur elektronischen subrogation, arbeitsflussverwaltung zwischen organisationen,transaktionsverarbeitung zwischen organisationen und optimiertenweb-gestützten benutzerinteraktion
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
US20060155856A1 (en) * 2003-01-10 2006-07-13 Sharp Kabushiki Kaisha Communications device, network system, communication management method, request signal, response signal, program, and recording medium containing the program
US8605647B2 (en) 2004-02-03 2013-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Shared risk group handling within a media gateway
DE602004002672T2 (de) * 2003-02-03 2007-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Shared-risk-gruppenhandhabung in einem media-gateway
US6965564B2 (en) 2003-02-14 2005-11-15 America Online, Inc. Wireless datagram transaction protocol system
DE60317108T2 (de) * 2003-03-20 2008-07-31 Telefonaktiebolaget Lm Ericsson (Publ) Verfahren und vorrichtung zur übertragung von dateneinheiten
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
US8238241B2 (en) * 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US8432800B2 (en) * 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
EP1652087B1 (de) * 2003-07-29 2015-07-08 Citrix Systems, Inc. Flusssteuer-architektur
US8437284B2 (en) * 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
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
US7529247B2 (en) * 2003-09-17 2009-05-05 Rivulet Communications, Inc. Empirical scheduling of network packets
US7468948B2 (en) * 2003-09-17 2008-12-23 Steven A Rogers Empirical scheduling of network packets using coarse and fine testing periods
US7848297B2 (en) * 2003-10-09 2010-12-07 Lg Electronics Inc. Method of generating PLCM for broadcast/multicast service and apparatus thereof
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
CN1954574B (zh) 2003-12-08 2011-04-06 美国博通公司 以太网上的统一架构
DE60312347T2 (de) * 2003-12-16 2007-11-15 Alcatel Lucent 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 삼성전자주식회사 Ｔｃｐ 커넥션 관리 장치 및 방법
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
US7757074B2 (en) 2004-06-30 2010-07-13 Citrix Application Networking, Llc System and method for establishing a virtual private 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
JP2008507928A (ja) 2004-07-23 2008-03-13 サイトリックス システムズ， インコーポレイテッド ネットワークノード間の通信を最適化するためのシステムおよび方法
EP2264956B1 (de) 2004-07-23 2017-06-14 Citrix Systems, Inc. Verfahren zur sicherung von zugriff aus der ferne auf private netze
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
EP1790131B1 (de) * 2004-09-09 2012-12-05 Avaya Inc. Verfahren von und systeme für netzwerkverkehrssicherheit
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
US8050186B2 (en) * 2004-11-15 2011-11-01 Telefonaktiebolaget L M Ericsson (Publ) Method for modifying MSS
US7610400B2 (en) * 2004-11-23 2009-10-27 Juniper Networks, Inc. Rule-based networking device
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
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
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
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
US20060253605A1 (en) * 2004-12-30 2006-11-09 Prabakar Sundarrajan Systems and methods for providing integrated client-side acceleration techniques to access remote applications
US7990967B2 (en) * 2005-01-06 2011-08-02 Rockwell Automation Technologies, Inc. Firewall method and apparatus for industrial systems
US7581005B2 (en) 2005-01-20 2009-08-25 Citrix Systems, Inc. Systems and methods for preserving transport layer protocol options
US8077632B2 (en) * 2005-01-20 2011-12-13 Citrix Systems, Inc. Automatic LAN/WAN port detection
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
US8171238B1 (en) 2007-07-05 2012-05-01 Silver Peak Systems, Inc. Identification of data stored in memory
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
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
US8489562B1 (en) 2007-11-30 2013-07-16 Silver Peak Systems, Inc. Deferred data storage
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
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
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
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
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
US8160062B2 (en) * 2006-01-31 2012-04-17 Microsoft Corporation Network connectivity determination based on passive analysis of connection-oriented path information
JP2007206871A (ja) * 2006-01-31 2007-08-16 Toshiba Corp 情報処理装置、および描画制御方法
US7890655B2 (en) * 2006-02-16 2011-02-15 Cisco Technology, Inc. Storage area network port based data transfer acceleration
EP1989852B1 (de) 2006-02-27 2017-05-24 Telefonaktiebolaget LM Ericsson (publ) Flusssteuermechanismus mit lokalen und globalen bestätigungen
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
US7856012B2 (en) 2006-06-16 2010-12-21 Harris Corporation System and methods for generic data transparent rules to support quality of service
US8064464B2 (en) 2006-06-16 2011-11-22 Harris Corporation Method and system for inbound content-based QoS
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
US7916626B2 (en) 2006-06-19 2011-03-29 Harris Corporation Method and system for fault-tolerant quality of service
US7664026B2 (en) * 2006-06-19 2010-02-16 Liquid Computing Corporation Methods and systems for reliable data transmission using selective retransmission
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
US8244883B2 (en) 2006-08-03 2012-08-14 Citrix Systems, Inc. Systems and methods of for providing multi-mode transport layer compression
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
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
EP2074769A2 (de) * 2006-10-06 2009-07-01 ViaSat, Inc. Dynamisches feedback zur anpassung einer rate ausgehender verbindungen in einem multiraten-abwärtsstrom
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
EP2087654A4 (de) * 2006-11-08 2011-06-29 Univ California Abbildung komplexer netzwerke
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
US8631147B2 (en) 2007-03-12 2014-01-14 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US7870277B2 (en) * 2007-03-12 2011-01-11 Citrix Systems, Inc. Systems and methods for using object oriented expressions to configure application security policies
US7853678B2 (en) * 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring flow control of policy expressions
US7706266B2 (en) * 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
US8490148B2 (en) 2007-03-12 2013-07-16 Citrix Systems, Inc Systems and methods for managing application security profiles
US7853679B2 (en) * 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring handling of undefined policy events
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
US10805840B2 (en) 2008-07-03 2020-10-13 Silver Peak Systems, Inc. Data transmission via a virtual wide area network overlay
US9717021B2 (en) 2008-07-03 2017-07-25 Silver Peak Systems, Inc. Virtual network overlay
US10164861B2 (en) 2015-12-28 2018-12-25 Silver Peak Systems, Inc. Dynamic monitoring and visualization for network health characteristics
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
CN102369703B (zh) * 2009-03-30 2014-10-29 日本电气株式会社 通信流控制系统、通信流控制方法和通信流处理程序
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
US8929817B2 (en) 2011-05-13 2015-01-06 Nokia Corporation Sensor-based touch inquiry control
US8929816B2 (en) * 2011-05-13 2015-01-06 Nokia Corporation Multiple apparatus selection via touch
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 パナソニックＩｐマネジメント株式会社 通信システムおよびそれに用いる伝送ユニット
US8665847B2 (en) 2011-11-08 2014-03-04 Microsoft Corporation Service-assisted network access point selection
KR20140110890A (ko) * 2011-12-29 2014-09-17 톰슨 라이센싱 네트워크 게이트웨이 및 데이터 스트림의 패킷들을 전송하기 위한 방법
TWI459768B (zh) 2011-12-30 2014-11-01 Ind Tech Res Inst 協助ｔｃｐ封包傳送的通訊系統與方法
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
EP3531738B1 (de) * 2012-09-28 2021-06-02 Juniper Networks, Inc. Verfahren und vorrichtung zur steuerung von drahtloszugangspunkten
US9692832B2 (en) * 2012-10-24 2017-06-27 Blackberry Limited System and method for controlling connection timeout in a communication network
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
US10425371B2 (en) * 2013-03-15 2019-09-24 Trane International Inc. Method for fragmented messaging between network devices
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
US20140325064A1 (en) * 2013-04-08 2014-10-30 Telefonaktiebolaget L M Ericsson (Publ) Controlling Establishment of Multiple TCP Connections
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
US9369342B2 (en) 2013-11-15 2016-06-14 Microsoft Technology Licensing, Llc Configuring captive portals with a cloud service
US10057302B2 (en) 2013-11-15 2018-08-21 Microsoft Technology Licensing, Llc Context-based selection of instruction sets 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
US9554323B2 (en) 2013-11-15 2017-01-24 Microsoft Technology Licensing, Llc Generating sequenced instructions for connecting through captive portals
CN104754003B (zh) * 2013-12-30 2019-01-08 腾讯科技（深圳）有限公司 传输数据的方法及系统
WO2015108373A1 (en) * 2014-01-16 2015-07-23 Samsung Electronics Co., Ltd. Apparatus and method for operating user plane protocol stack in connectionless communicaton 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
EP3173231B1 (de) * 2014-07-25 2020-03-04 Mitsubishi Chemical Corporation Mehrschichtiger gassperrfilm
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 コニカミノルタ株式会社 通信中継装置、プログラム及び通信中継方法
US10021034B2 (en) * 2014-09-25 2018-07-10 Hughes Network Systems, Llc Application aware multihoming for data traffic acceleration in data communications networks
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
US9749293B2 (en) * 2015-04-20 2017-08-29 Shoelace Wireless, Inc. Systems for improved mobile internet performance and security
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
US9602455B2 (en) 2015-08-07 2017-03-21 Machine Zone, Inc. Scalable, real-time messaging system
US9319363B1 (en) 2015-08-07 2016-04-19 Machine Zone, Inc. Scalable, real-time messaging system
US10333879B2 (en) 2015-08-07 2019-06-25 Satori Worldwide, Llc Scalable, real-time messaging system
US9407585B1 (en) 2015-08-07 2016-08-02 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
BR112018077070A2 (pt) * 2016-06-29 2019-04-02 Beijing Xiaomi Mobile Software Co., Ltd. método e aparelho de emissão de informação, método e aparelho de envio de dados, dispositivo da rede de acesso, terminal, e, sistema de comunicação móvel.
US9608928B1 (en) * 2016-07-06 2017-03-28 Machine Zone, Inc. Multiple-speed message channel of messaging system
US10135720B2 (en) * 2016-08-03 2018-11-20 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
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
US10257082B2 (en) 2017-02-06 2019-04-09 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows
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
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
US10187278B2 (en) 2017-02-24 2019-01-22 Satori Worldwide, Llc Channel management in scalable 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
US10725743B2 (en) 2018-01-22 2020-07-28 John Rankin System and method for generating random numbers
US10574439B2 (en) 2018-01-31 2020-02-25 John Rankin System and method for secure communication using random blocks or random numbers
US11294636B2 (en) 2018-02-28 2022-04-05 Rankin Labs, Llc 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
US11689543B2 (en) 2018-08-10 2023-06-27 Rankin Labs, Llc System and method for detecting transmission of a covert payload of data
WO2020033540A1 (en) 2018-08-10 2020-02-13 John Rankin System and method for covertly transmitting a payload of data
US11652732B2 (en) 2018-08-21 2023-05-16 Rankin Labs, Llc System and method for scattering network traffic across a number of disparate hosts
US11031998B2 (en) * 2018-10-09 2021-06-08 Hughes Network Systems, Llc Bonding and redundancy for satellite transport paths
US10819420B2 (en) 2018-10-09 2020-10-27 Hughes Network Systems, Llc Multipath satellite backbone
EP3644573B1 (de) * 2018-10-24 2021-04-21 Acklio Einfaches kommunikationsprotokoll zur datenübertragung über eingeschränkte netzwerke
CN109147284B (zh) * 2018-10-30 2020-07-14 宁波三星智能电气有限公司 一种智能电表的上报方法
WO2020132173A1 (en) 2018-12-19 2020-06-25 John Rankin 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
US10901739B2 (en) 2019-01-21 2021-01-26 Rankin Labs, Llc Systems and methods for controlling machine operations using stack entries comprising instruction configuration parameters
WO2020214757A1 (en) 2019-04-17 2020-10-22 John Rankin Virtual memory pool within a network which is accessible from multiple platforms
WO2020214752A1 (en) 2019-04-17 2020-10-22 John Rankin System and method for detecting hidden chemicals within objects in a non-invasive manner
WO2020243244A1 (en) 2019-05-28 2020-12-03 John Rankin 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
US11729184B2 (en) 2019-05-28 2023-08-15 Rankin Labs, Llc Detecting covertly stored payloads of data within a network
US11105934B2 (en) 2019-08-07 2021-08-31 Rankin Labs, Llc Determining proximity and attraction of objects within a coordinate system
US11430010B2 (en) 2019-08-07 2022-08-30 Rankin Labs, Llc System and method for influencing a primary target through word-of-mouth interaction with secondary targets
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)
WO2021183421A2 (en) 2020-03-09 2021-09-16 John Rankin Systems and methods for morpheme reflective engagement response
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
JP2945757B2 (ja) * 1989-09-08 1999-09-06 オースペックス システムズ インコーポレイテッド 多重装置オペレーティングシステムのアーキテクチャ
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
EP0765560A1 (de) * 1994-06-08 1997-04-02 Hughes Aircraft Company Verfahren und vorrichtung zum hybridnetzwerkzugriff
US6701370B1 (en) * 1994-06-08 2004-03-02 Hughes Electronics Corporation Network system with TCP/IP protocol spoofing
EP0813479B1 (de) * 1995-03-03 2006-08-30 QUALCOMM Incorporated Verfahren und vorrichtung zur überwachung der parametern von fahrzeugelektronischen steuerungseinheiten
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
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
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
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
WO1999014931A2 (en) * 1997-09-16 1999-03-25 Transnexus, Llc Internet telephony call routing engine
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
US6519703B1 (en) * 2000-04-14 2003-02-11 James B. Joyce Methods and apparatus for heuristic firewall
US6987741B2 (en) * 2000-04-14 2006-01-17 Hughes Electronics Corporation System and method for managing bandwidth in a two-way satellite system
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
US7213077B2 (en) * 2000-07-21 2007-05-01 Hughes Network Systems, Inc. Method and system for providing buffer management in a performance enhancing proxy architecture

Also Published As

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

Similar Documents

Publication Publication Date Title
DE60116447T2 (de) Verfahren und System zur Verbindungsbehandlung
DE60305378T2 (de) Verfahren zum Weitergeben von einem Netzwerkstapel
EP2892189B1 (de) System und verfahren zur umleitung etablierter kommunikationssitzungen
DE602005005724T2 (de) Endpunktadressenänderung in einem Paketnetzwerk
DE69727447T2 (de) Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung
DE60310645T2 (de) Verhinderung von Paketzerteilung
DE60028897T2 (de) Verfahren und Vorrichtung zur Umschaltung zwischen zwei Netzwerkzugangstechnologien ohne Unterbrechung der aktiven Netzwerkanwendungen
DE60127978T2 (de) System und Verfahren zur Verteidigung gegen Denial-of-Service angriffe auf die Netzwerkknoten
JP4506430B2 (ja) アプリケーションモニタ装置
DE60220098T2 (de) Verteiltes Computersystem mit Bestätigungsakkumulation
EP1500249B1 (de) Verfahren und vorrichtung zum übertragen von datenpaketen in einem kommunikationssystem bei verwendung pep und eines ran
CA2874047C (en) System and method for diverting established communication sessions
DE102009022851A1 (de) Netzwerkkomponente und Verfahren zum Überwachen von Kommunikationsverbindungen

Legal Events

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