DE60117485T2 - Verfahren und Vorrichtung zur Pufferverwaltung - Google Patents

Verfahren und Vorrichtung zur Pufferverwaltung Download PDF

Info

Publication number
DE60117485T2
DE60117485T2 DE60117485T DE60117485T DE60117485T2 DE 60117485 T2 DE60117485 T2 DE 60117485T2 DE 60117485 T DE60117485 T DE 60117485T DE 60117485 T DE60117485 T DE 60117485T DE 60117485 T2 DE60117485 T2 DE 60117485T2
Authority
DE
Germany
Prior art keywords
buffer
tcp
header
tsk
field
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
DE60117485T
Other languages
English (en)
Other versions
DE60117485D1 (de
Inventor
John Poolesville Border
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
Application granted granted Critical
Publication of DE60117485D1 publication Critical patent/DE60117485D1/de
Publication of DE60117485T2 publication Critical patent/DE60117485T2/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 betrifft ein Kommunikationssystem und betrifft genauer eine Proxy-Architektur zur Verbesserung der Leistungsfähigkeit eines Netzwerks.
  • Erörterung des technischen Hintergrunds
  • Die Einbeziehung von Datennetzwerken in die Abläufe der modernen Gesellschaft, wie durch die Verbreitung des Internet, insbesondere des World Wide Web, augenfällig, stellt immer höhere Anforderungen an Service-Provider, die Leistungsfähigkeit des Netzwerks ständig zu verbessern. Um dieser Herausforderung gewachsen zu sein, investieren Service-Provider massiv in die Aufrüstung ihrer Netzwerke, um die Systemleistung (z.B. die Bandbreite) zu verbessern. Unter vielen Umständen sind solche Aufrüstungen möglicherweise ökonomisch nicht machbar, oder die physischen Beschränkungen des Kommunikationssystems erlauben ein einfaches „Aufrüsten" nicht. Dementsprechend investieren Service-Provider auch in Entwicklungstechnologien, um die Leistungsfähigkeit ihrer Netzwerke zu optimieren. Da viele der heutigen Netzwerke mit der Transmission Control Protocol/Internet Protocol (TCP/IP)-Reihe arbeiten oder diese als Schnittstelle benutzen müssen, konzentrieren sich die Bemühungen auf die Optimierung von TCP/IP-basierten Netzwerkoperationen.
  • Als Netzwerkstandard für das globale Internet hat TCP/IP diese Akzeptanz in der Industrie erlangt, weil es flexibel ist und unter Forschern eine lange Tradition hat. Das Transmission Control Protocol (TCP) ist heute das im Internet vorherrschend verwendete Protokoll. TCP basiert auf dem Internet Protocol (IP) und wird in einer Vielfalt von Anwendung, einschließlich der zuverlässigen Datenübertragung und von Internet Web- Seiten-Zugriffsanwendungen, verwendet. Die vier Schichten der TCP/IP-Protokollreihe sind in 31 erläutert. Wie dargestellt, schließt die Verknüpfungsschicht (oder die Netzschnittstellenschicht) 10 Gerätetreiber im Betriebssystem und etwaige entsprechende Netzschnittstellenkarten ein. Gemeinsam handhaben der Gerätetreiber und die Schnittstellenkarten Hardware-Details der physischen Schnittstellenverbindung mit einem Kabel oder jeder anderen Art von Medium, die verwendet wird. Die Netzwerkschicht (auch als Internetschicht bezeichnet) 12 handhabt die Bewegung von Paketen im Netzwerk. Die Wegewahl bzw. das Routing von Paketen beispielsweise findet in der Netzwerkschicht 12 statt. IP, Internet Control Message Protocol (ICMP) und Internet Group Management Protocol (IGMP) können die Netzwerkschicht in der TCP/IP Protokollreihe bereitstellen. Die Transportschicht 14 sorgt für einen Datenfluss zwischen zwei Hosts für die obige Anwendungsschicht 16.
  • In der TCP/IP Protokollreihe gibt es mindestens zwei verschiedene Transportprotokolle, TCP und ein User Datagram Protocol (UDP). TCP, das für einen zuverlässigen Datenfluss zwischen zwei Hosts sorgt, ist in erster Linie mit dem Aufteilen von Daten, die ihm von der Anwendungsschicht 16 geliefert werden, in Segmente von geeigneter Größe für die darunter liegende Netzwerkschicht 12, mit der Bestätigung für empfangene Pakete, mit dem Festsetzen von Time-Outs, um sicherzustellen, dass das andere Ende den Empfang der versandten Pakete bestätigt, usw. befasst. Da dieser zuverlässige Datenfluss von der Transportschicht 14 bereitgestellt wird, ist die Anwendungsschicht 16 nicht mit diesen Details befasst. UDP sorgt andererseits für einen wesentlichen einfacheren Dienst für die Anwendungsschicht 16. UDP sendet einfach Datenpakete, die Datagramme genannte werden, von einem Host zum anderen, ohne Garantie, dass die Datagramme ihren Zielort erreichen. Jede gewünschte Zuverlässigkeit muss von einer höheren Schicht, wie der Anwendungsschicht 16, hinzugefügt werden.
  • Die Anwendungsschicht 16 handhabt die Details der jeweiligen Anwendung. Es gibt viele gemeinsame TCP/IP-Anwendungen, die fast jede Implementierung bereitstellt, einschließlich Telnet für Remote 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 gesagt, stellt TCP eine zuverlässige Datenübermittlung in Reihenfolge zwischen zwei IP-Hosts bereit. Die IP-Hosts stellen eine TCP-Verbindung mit Hilfe eines konventionellen TCP-Dreiwege-Verbindungsaufbaus und eine anschließende Datenübertragung unter Verwendung eines auf Fenstern beruhenden Protokolls mit den erfolgreich empfangenen und bestätigten Daten bereit.
  • Um zu verstehen, wo Optimierungen durchgeführt werden können, ist es lehrreich, eine typische TCP-Verbindungseinrichtung zu betrachten. 32 stellt ein Beispiel für den konventionellen TCP-Dreiwege-Verbindungsaufbau zwischen IP-Hosts 20 und 22 dar. Zuerst schickt der IP-Hosst 20, der eine Übertragung mit dem IP-Host 22 initiieren will, ein Synchronisierungssignal (SYN) an den IP-Host 22. Der IP-Host 22 bestätigt das SYN-Signal vom IP-Host 20 durch Senden einer SYN-Bestätigung (ACK). Der dritte Schritt des konventionellen TCP-Dreiwege-Verbindungsaufbaus ist die Ausgabe eines ACK-Signals vom IP-Host 20 an den anderen IP-Host 22. Nun ist der IP-Host 22 bereit, die Daten vom IP-Host 20 zu empfangen (und umgekehrt). Nachdem alle Daten versendet wurden, wird ein weiterer Verbindungsaufbau (ähnlich dem Verbindungsaufbau, der beschrieben wurde, um die Verbindung zu initiieren) verwendet, um die TCP-Verbindung zu schließen.
  • TCP wurde für große Flexibilität und für die Arbeit über eine große Vielfalt von Kommunikationsverknüpfungen hinweg entworfen, einschließlich von langsamen und schnellen Verbindungen, Verbindungen mit langer Latenz und Verbindungen mit niedrigen und hohen Fehlerraten. Obwohl TCP (und andere Hochschicht-Protokolle) mit vielen verschiedenen Verbindungsarten funktionieren, wird die TCP-Leistung, insbesondere der mögliche Durchsatz durch die TCP-Verbindung, durch die Eigenschaften der verwendeten Verknüpfung beeinflusst. Es müssen viele Verknüpfungsschicht-Designs in Betracht gezogen werden, wenn ein Verknüpfungsschichtdienst entworfen wird, der Internetprotokolle unterstützen soll. Jedoch können nicht alle Eigenschaften durch die Wahl des Verknüpfungsschicht-Designs kompensiert werden. TCP ist dafür entworfen worden, sehr flexibel in Bezug auf die Verknüpfungen zu sein, die es durchläuft. Diese Flexibilität wird auf Kosten eines im Vergleich zu einem maßgeschneiderten Protokoll suboptimalen Betriebs in einer Reihe von Umgebungen erreicht. Dem maßgeschneiderten Protokoll, das in der Regel von proprietärer Natur ist, fehlt die Flexibilität im Hinblick auf Netzwerkumgebungen und Interoperabilität.
  • Eine Alternative zu einem maßgeschneiderten Protokoll ist die Verwendung von leistungsverstärkenden Proxies (PEPs), um eine allgemeine Klasse von Funktionen, die „TCP-Spoofing" genannt werden, auszuführen, um die TCP-Leistung gegenüber beeinträchtigen Verknüpfungen (d.h. mit langer Latenz oder hoher Fehlerrate) zu verbessern. TCP-Spoofing schließt eine Zwischen-Netzwerkeinrichtung (den leistungsverstärkenden Proxy (PEP)) ein, die durch Unterbrechen und Abändern, durch die Hinzufügung und/oder Weglassung von TCP-Segmenten das Verhalten der TCP-Verbindung in dem Versuch, deren Leistung zu verbessern, ändert.
  • Konventionelle TCP-Spoofing-Implementierungen schließen die lokale Empfangsbestätigung für TCP-Datensegmente ein, damit der Sender der TCP-Daten weitere Daten früher sendet, als es der Fall wäre, wenn kein Spoofing durchgeführt würde, wodurch der Durchsatz der TCP-Verbindung verbessert wird. Im Allgemeinen konzentrieren sich konventionelle TCP-Spoofing-Implementierungen auf die Steigerung des Durchsatzes von TCP-Verbindungen durch entweder die Verwendung größerer Fenster in der Verknüpfung oder durch die Verwendung einer Kompression, um die Datenmenge, die verschickt werden muss, zu verringern, oder beides.
  • Viele TCP-PEP-Implementierungen beruhen auf TCP-ACK-Manipulation. Dies kann TCP-ACK-Spacing, wo ACKs, die zusammengepackt sind, voneinander getrennt werden, lokale TCP-ACKs, lokale TCP-Rückübertragungen und TCP-ACK-Filterung und -Rekonstruktion einschließen. Andere PEP-Mechanismen schließen Tunneling, Kompression und auf Priorität beruhendes Multiplexing ein.
  • Wie aus den obigen Ausführungen hervorgeht, besteht ein klarer Bedarf an verbesserten Ansätzen für die Optimierung der Netzwerkleistung bei Erreichung einer Netzwerkflexibilität. Es besteht auch die Notwendigkeit, die Leistungsfähigkeit des Netzwerks ohne eine kostspielige Invenstition in die Infrastruktur zu verbessern. Es besteht auch die Notwendigkeit, einen Mechanismus, der die Leistungsfähigkeit eines Netzwerks erhöht, zu verwenden, der mit bestehenden Standards kompatibel ist, um eine schnelle Verbreitung zu erleichtern. Außerdem besteht die Notwendigkeit zur Vereinfachung des Empfänger-Designs. Deshalb ist ein Ansatz zum Optimieren der Leistungsfähigkeit eines Netzwerks mit Hilfe einer Proxy-Architektur sehr wünschenswert.
  • EP 0 903 905 A2 beschreibt eine Netzwerk-Gateway-Vorrichtung, die eine Vielzahl von Kommunikationsschnittstellen zum Empfangen von Nachrichten und eine Vielzahl von Modulen, die dafür konfiguriert sind, die Nachrichten zu verarbeiten, um leistungsverbessernde Funktionen zu bewirken, einschließt.
  • EP 0 574 140 A1 beschreibt einen Netzwerkadapter, der ein Kopffeld bzw. einen Header und Paketdaten in einem Netzwerkpaket in zwei verschiedene Speichersegmente teilt. Der Header enthält Paddaten, um sicherzustellen, dass die Paketdaten an einer festen Stelle im Netzwerkpaket lokalisiert werden.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung erfüllt die oben genannten Notwendigkeiten durch Bereitstellen einer Netzwerkvorrichtung, die leistungssteigernde Proxy (PEP)-Funktionen bereitstellt. Die Netzwerkvorrichtung schließt mehrere Puffer ein, die Kommunikationsschnittstellen entsprechen und die von leistungssteigernden Proxy (PEP)-Kernels genutzt werden. Die Puffer weisen eine Datenstruktur auf, die ein erweiterbares Feld bereitstellt, das sich an verschiedene Nachrichtenarten anpasst.
  • Die verschiedenen Aspekte der vorliegenden Erfindung sind in den beigefügten Ansprüchen definiert.
  • Es wird eine Netzwerkvorrichtung zur Bereitstellung von Verbesserungen in einem Kommunikationsnetz bereitgestellt. Die Netzwerkvorrichtung schließt eine Vielfalt von Kommunikationsschnittstellen ein, die so konfiguriert sind, dass sie Nachrichten entsprechend einem vorgeschriebenen Protokoll empfangen und weiterleiten. Die Netzwerkvorrichtung schließt auch eine Vielzahl von Modulen ein, die so konfiguriert sind, dass sie die Nachrichten verarbeiten, um leistungssteigernde Funktionen zu bewirken. Ferner schließt die Netzwerkvorrichtung eine Vielzahl von Puffern ein, die so konfiguriert sind, dass sie die empfangenen Nachrichten und Nachrichten, die von einem der vielen Module erzeugt werden, speichern. Ein Teil der Vielzahl von Puffern wird von der Vielzahl von Modulen aufgrund der Durchführung einer der leistungssteigernden Funktionen gemeinsam genutzt. Jeder der Vielzahl von Puffern weist eine Datenstruktur auf, die einen erweiterbaren Header einschließt, um an verschiedene Nachrichtenarten angepasst werden zu können. Dieser Ansatz stellt auf vorteilhafte Weise eine effiziente Pufferverwaltung innerhalb einer Netzwerkkomponente bereit.
  • Es wird ein Verfahren zur Bereitstellung von Leistungsverbesserungen für ein Kommunikationsnetz offenbart. Das Verfahren beinhaltet den Empfang von Nachrichten gemäß einem vorgeschriebenen Protokoll, die Verarbeitung der Nachrichten über eine Vielzahl von Modulen, um leistungssteigernde Funktionen zu bewirken, und die Speicherung der empfangen Nachrichten und von Nachrichten, die von einem von der Vielzahl von Modulen erzeugt wurden, in einer Vielzahl von Puffern. Ein Teil der Vielzahl von Puffern wird von der Vielzahl von Modulen aufgrund der Ausführung einer speziellen Leistungsverbesserungsfunktionen gemeinsam genutzt, wobei jeder von der Vielzahl von Puffern eine Datenstruktur hat, die einen erweiterbaren Header einschließt, um sich an verschiedene Nachrichtenarten anpassen zu können. Die oben genannte Anordnung verbessert vorteilhaft die Systemeffizienz.
  • Eine Netzwerkvorrichtung zur Bereitstellung von Leistungsverbesserungen für ein Kommunikationsnetz schließt Mittel zum Empfang von Nachrichten entsprechend einem vorgeschriebenen Protokoll und Mittel zum Verarbeiten der Nachrichten, um leistungsverbessernde Funktionen zu bewirken, ein. Die empfangenen Nachrichten und Nachrichten, die von Vearbeitungseinrichtungen erzeugt werden, werden in einer Vielzahl von Puffern gespeichert. Ein Teil der Vielzahl von Puffern wird von den Verarbeitungseinrichtungen aufgrund der Ausführung einer speziellen Leistungsverbesserungsfunktion gemeinsam genutzt. Jeder der Vielzahl von Puffern weist eine Datenstruktur auf, die einen erweiterbaren Header einschließt, um an verschiedene Nachrichtenarten angepasst werden zu können. Die oben genannte Anordnung stellt auf vorteilhafte Weise eine wirksame Pufferverwaltung bereit.
  • Ein computerlesbares Medium, das eine oder mehrere Sequenzen aus einem oder mehreren Befehlen zur Bereitstellung von Leistungsverbesserungen eines Kommunikationsnetzes überträgt, wird offenbart. Die eine oder die mehreren Sequenzen aus einem oder mehreren Befehlen schließen Befehle ein, die, wenn sie von einem oder mehreren Rechnern ausgeführt werden, bewirken, dass der eine oder die mehreren Rechner den Schritt des Empfangs von Nachrichten gemäß einem vorgeschriebenen Protokoll ausführen. Andere Schritte beinhalten die Verarbeitung der Nachrichten, um leistungsverbessernde Funktionen zu bewirken, über eine Vielzahl von Modulen und die Speicherung der empfangenen Nachrichten und von Nachrichten, die von einem der Vielzahl von Modulen erzeugt werden, in einer Vielzahl von Puffern. Ein Teil der Vielzahl von Puffern wird von der Vielzahl von Modulen aufgrund der Ausführung einer der leistungssteigernden Funktion gemeinsam genutzt. Jeder der Vielzahl von Puffern weist eine Datenstruktur auf, die einen erweiterbaren Header einschließt, um an verschiedene Nachrichtenarten angepasst werden zu können. Dieser Ansatz stellt auf vorteilhafte Weise eine verbesserte Netzwerkleistung bereit.
  • Ein Speicher zum Speichern von Informationen für die Bereitstellung von Leistungsverbesserungen in einem Kommunikationsnetz wird offenbart. Der Speicher weist eine Datenstruktur auf, die ein spezielles Header-Feld einschließt, in dem platt formspezifische Informationen gespeichert werden. Die Datenstruktur schließt auch ein allgemeines Header-Feld ein, in dem Informationen gespeichert werden, die der Vielzahl von Modulen bekannt sind, und ein Nutzinhaltfeld. Mit diesem Ansatz wird eine effiziente Pufferverwaltung erreicht.
  • Kurze Beschreibung der Zeichnung
  • Ein vollständigeres Verständnis der Erfindung und viele der damit zusammenhängenden Vorteile ergibt sich ohne weiteres durch Bezugnahme auf die folgende ausführliche Beschreibung in Zusammenschau mit der begleitenden Zeichnung, worin:
  • 1 ein Diagramm eines Kommunikationssystems ist, in dem der leistungsverbessernde Proxy (PEP) der vorliegenden Erfindung implementiert ist;
  • 2 ein Diagramm einer PEP-Endpunkt-Plattformumgebung gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 3 ein Diagramm eines TCP-Spoofing-Kernel (TSK) ist, der in der Umgebung von 2 verwendet wird;
  • 4A und 4B Ablaufschemata der Verbindungseinrichtung mit Dreiwege-Verbindungsaufbau-Spoofing bzw. ohne Dreiwege-Verbindungsaufbau-Spoofing sind;
  • 5 ein Diagramm eines PEP-Paketflusses zwischen zwei PEP-Endpunkten gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 6 ein Diagramm eines IP (Internetprotokoll)-Paketflusses durch einen PEP-Endpunkt gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 7 ein Diagramm von PEP-Endpunktprofilen, die in der Plattform von 2 verwendet werden, ist;
  • 8 ein Diagramm der Schnittstellen eines PEP-Endpunkts ist, der als IP-Gateway implementiert ist, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 9 ein Diagramm der Schnittstellen eines als Multimedia-Relais implementierten PEP-Endpunkts gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 10 ein Diagramm der Schnittstellen eines als Multimedia-VSAT (Very Small Aperture Terminal) implementierten PEP-Endpunkts gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 11 ein Diagramm der Schnittstellen eines in einer Bodenstation implementierten PEP-Endpunkts gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 12 ein Diagramm des Flusses von TCP-Spoofing-Puffern durch einen erfindungsgemäßen PEP-Endpunkt gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 13 ein Diagramm der Pufferverwaltung für nicht-gespoofte bzw. nicht-bandbreitenbedarfsreduzierte TCP-Verbindungen und für Nicht-TCP-Verkehr gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 14 ein Diagramm eines Grundformats der Puffer, die verwendet werden, um die PEP-Funktionalität zu implementieren, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 15 ein Diagramm eines IP-Pakets ist, das im System von 1 verwendet wird;
  • 16 ein Diagramm eines Formats des allgemeinen PEP-Puffer-Headers gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 17 ein Diagramm einer Header-Anpassung für empfangenen TCP-Datensegmente gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 18 ein Diagramm eines empfangenen TCP-Datensegments mit einem TCP-Verbindungs-Header gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 19 ein Diagramm einer Header-Anpassung an eine empfangene TSK-Nachricht gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 20 ein Diagramm einer Header-Anpassung an eine empfangene TSK-Nachricht mit einem TCP-Verbindungs-Header gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 21 ein Diagramm eines generierten TCP-Segments gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 22 ein Diagramm eines generierten PBP-Segments gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 23 ein Diagramm einer generierten TSK-Nachricht gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 24 ein Diagramm ist, das die Wiederverwendung eines TCP-Segmentpuffers für eine TSK-Nachricht gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 25 ein Diagramm der Wiederverwendung eines TSK-Nachrichtenpuffers für ein TCP-Segment gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 26 ein Diagramm eines Beispiels für eine Kernelverwendung des eigentümer- bzw. inhaberspezifischen „Headers" gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 27 ein Diagramm eines Verfahrens zum Einsetzen eines allgemeinen PEP-Puffer-Headers in einen kleinen Puffer gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 28 ein Diagramm eines Verfahrens zum Hinzufügen eines allgemeinen PEP-Puffer-Headers zu einem kleinen Puffer gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 29 ein Diagramm eines gleitenden Fenstermechanismus, der im System von 1 verwendet wird, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 30 ein Diagramm eines Computersystems, das PEP-Funktionen ausführen kann, gemäß einer Ausführungsform der vorliegenden Erfindung ist;
  • 31 ein Diagramm der Protokollschichten der TCP/IP-Protokollreihe ist; und
  • 32 das Diagramm eines konventionellen TCP-Dreiwege-Verbindungsaufbaus zwischen IP-Hosts ist.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • In der folgenden Beschreibung sind für den Zweck der Erklärung bestimmte Details ausführlich dargestellt, um ein gründliches Verständnis der Erfindung zu ermöglichen. Jedoch kann die Erfindung natürlich auch ohne diese speziellen Details ausgeführt werden. In einigen Fällen sind bekannte Strukturen und Geräte in Blockdiagrammform dargestellt, um zu vermeiden, dass das Verständnis der Erfindung unnötigerweise erschwert wird.
  • Obwohl die vorliegende Erfindung mit Bezug auf das Internet und die TCP/IP-Protokollreihe erörtert wird, kann die vorliegende Erfindung auch auf andere paketvermittelte Netzwerke und äquivalente Protokolle angewendet werden.
  • 1 stellt ein Beispielsnetzwerk 100 dar, in dem der leistungssteigernde Proxy (PEP) der vorliegenden Erfindung verwendet werden kann. Das Netzwerk 100 in 1 schließt einen oder mehrere Hosts 110 ein, die über TCP-Verbindungen mit einem Netzwerk-Gateway 120 verbunden sind. Das Netzwerk-Gateway 120 ist mit einem anderen Netzwerk-Gateway 140 über eine Rückgrat- bzw. Backbone-Verbindung auf einem Backbone-Link 130 verbunden. Wie in 1 dargestellt, ist der Backbone-Link 130 in einem Ausführungsbeispiel als Satellitenverknüpfung dargestellt, die über einen Satelliten 101 eingerichtet ist; der Fachmann weiß jedoch, dass auch andere Netzwerkverbindungen implementiert werden können. Zum Beispiel können diese Netzwerkverbindungen im Allgemeinen über ein drahtloses Kommunikationssystem (z.B. Rundfunknetz, Mobilfunknetze usw.) oder ein terrestrisches Kommunikationssystem eingerichtet werden. Das Netzwerk-Gateway 140 ist ferner mit einer zweiten Gruppe von Hosts 150 verbunden, ebenfalls über TCP-Verbindungen. In der in 1 dargestellten Anordnung erleichtern die Netzwerk-Gateways 120, 140 die Kommunikation zwischen den Gruppen von Hosts 110, 150.
  • Die Netzwerk-Gateways 120, 140, erleichtern die Kommunikation zwischen den beiden Gruppen von Hosts 110, 150 durch Ausführen einer Reihe von leistungssteigernden Funktionen. Diese Netzwerk-Gateways 120, 140 können ein selektives TCP-Spoofing ausführen, was die flexible Konfiguration der speziellen TCP-Verbindungen, deren Bandbreitenbedarf reduziert werden soll, ermöglicht. Außerdem verwenden die Gateways 120, 140 einen TCP-Dreiwege-Verbindungsaufbau, bei dem die TCP-Verbindungen an jedem Ende des Backbone-Link 130 enden. Von den Netzwerk-Gateways 120, 140 werden lokale Daten-Empfangsbestätigungen verwendet, wodurch die TCP-Fenster auf lokale Geschwindigkeit beschleunigen können.
  • Das Netzwerk-Gateway 120, 140 multiplext ferner mehrere TCP-Verbindungen über eine einzelne Backbone-Verbindung; diese Fähigkeit reduziert das Maß an Empfangsbestätigungsverkehr im Zusammenhang mit den Daten von mehreren TCP-Verbindungen, da eine einzige Backbone-Verbindungs-Empfangsbestätigung verwendet werden kann. Die Multiplexfunktion unterstützt außerdem TCP-Verbindungen mit hohem Durchsatz, in denen das Backbone-Verbindungsprotokoll für den speziellen verwendeten Backbone-Link optimiert ist. Die Netzwerk-Gateways 120, 140 unterstützen außerdem die Datenkompression über dem Backbone-Link 130, um das Maß an zu sendendem Verkehr zu reduzieren, was die Leistung der Backbone-Verbindung weiter verstärkt. Weiter verwenden die Netzwerk-Gateways 120, 140 eine Datenverschlüsselung bei der Datenübertragung über den Backbone-Link 130, um die Datensicherheit zu gewährleisten, und stellen die Fähigkeit zum priorisierten Zugang zum Backbone-Link 130 auf Basis einer TCP-Verbindung bereit. Jeder der Netzwerk-Gateways 120, 140 kann einen besonderen Pfad wählen, auf dem die Daten, die mit einer Verbindung assoziiert sind, fließen. Die oben genannten Fähigkeiten der Netzwerk-Gateways 120, 140 sind nachstehend ausführlicher beschrieben.
  • 2 stellt einen leistungssteigernden Proxy (PEP) 200 dar, dar in einem Netzwerk-Gateway 120, 140 entsprechend einer Ausführungsform der vorliegenden Erfindung implementiert ist. In dieser Ausführungsform weist der PEP 200 eine Plattformumgebung 210 auf, welche das Hardware- und Software-Betriebssystem einschließt. Der PEP 200 schließt auch lokale Netzwerk (LAN)-Schnittstellen 220 und Weitverkehrsnetzwerk (WAN)-Schnittstellen 230 ein. Im Beispiel von 1 kann der Netzwerk-Gateway 120 die TCP-Verbindungen mit den IP-Hosts 110 über eine lokale LAN-Schnittstelle 220 einrichten und kann die Backbone-Verbindung mit dem Netzwerk-Gateway 140 über eine WAN-Schnittstelle 230 einrichten. Die PEP-Plattformumgebung 210 kann auch allgemeine funktionelle Module einschließen: ein Routingmodul 240, ein Pufferverwaltungsmodul 250, ein Ereignisverwaltungsmodul 260 und ein Parameterverwaltungsmodul 270. Wie in 2 dargestellt, schließt der Netzwerk-Gateway auch einen TCP-Spoofing-Kernel (TSK) 280, einen Backbone-Protokoll-Kernel (BPK) 282, einen Priorisierungs-Kernel (PK) 284 und einen Pfadauswahl-Kernel (PSK) 286 ein. Diese vier Kernels machen im Wesentlichen die Funktionalität des leistungsverbessernden Proxy 200 aus.
  • Die Plattformumgebung 210 führt eine Anzahl von Funktionen aus. Eine dieser Funktion ist die Abschirmung der verschiedenen PEP-Kernels 280, 282, 284 gegen die Implementierung spezifischer Beschränkungen. Das heißt, die Plattformumgebung 210 führt Funktionen aus, die die verschiedenen PEP-Kernels 280, 282, 284, 286 nicht direkt ausführen können, weil die Implementierung der Funktion plattformspezifisch ist.
  • Diese Anordnung hat den Vorteil, plattformspezifische Details vor den PEP-Kernels 280, 282, 284, 286 zu verbergen, wodurch die PEP-Kernels portierbarer werden. Ein Beispiel für eine platformspezifische Funktion ist die Zuweisung eines Puffers. In einigen Plattformen werden Puffer nach Bedarf geschaffen, während in anderen Plattformen Puffer zu Beginn geschaffen werden und für die spätere Verwendung in verknüpften Listen organisiert werden. Es sei darauf hingewiesen, dass plattformspezifische Funktionen nicht auf Funktionen beschränkt sind, die für alle Kernels 280, 282, 284, 286 auswählbar sind. Es kann auch eine Funktion, die für einen bestimmten Kernel spezifisch ist, beispielsweise die Zuweisung eines Steuerblocks für das TCP-Spoofing, von der Plattformumgebung implementiert werden, um plattformspezifische Details vor dem Kernel zu verbergen.
  • Außerdem kann die Plattformumgebung 210 den Aufgabenkontext liefern, in dem die PEP-Kernels 280, 282, 284, 286 arbeiten. In einem Ausführungsbeispiel können alle PEP-Kernels 280, 282, 284, 286 aus Gründen der Effizienz in demselben Aufgabenkontext arbeiten. Jedoch ist dies nicht erforderlich.
  • Ferner liefert die Plattformumgebung 210 eine Schnittstelle zwischen der PEP-Funktion (ausgeführt in den Kernels 280, 282, 284, 286) und den anderen Funktionen des Netzwerk-Gateways 120, 140. Zum Beispiel kann die Plattformumgebung 210 die Schnittstelle zwischen der PEP-Funktionalität und der Routing-Funktion 240 bereitstellen, wie in 2 dargestellt. Es sei darauf hingewiesen, dass die in 2 dargestellten plattformspezifischen Funktionen Beispiele sind und nicht als vollständige Liste anzusehen sind. Es sei ferner darauf hingewiesen, dass die dargestellten PEP-Kernels, die einander in 2 berühren (280, 282 und 284, 286), eine direkte prozedurale Schnittstelle miteinander haben können. Weiter können die Kernels 280, 282, 284, 286 direkte Schnittstellen einschließen, um die Leistung zu verbessern, anstatt alles durch die Plattformumgebung 210 zu führen (wie in 2 dargestellt).
  • Zusätzlich zu den PEP-Kernels 280, 282, 284 und 286 kann die PEP-Endpunkt-Plattform 210 einen Datenkompressions-Kernel (CK) 290 und einen Verschlüsselungs- Kernel (EK) 292 verwenden. Wie oben beschrieben, erleichtern diese Kernels 280, 282, 284, 286, 290 und 292 die Kommunikation zwischen den zwei Gruppen von Hosts 110, 150 durch die Ausführung einer Vielfalt von leistungsverbessernden Funktionen entweder einzeln oder in Kombination. Diese leistungsverbessernden Funktionen schließen selektives TCP-Spoofing, Dreiwege-Verbindungsaufbau-Spoofing, lokale Datenempfangsbestätigung, Multiplexing von TCP-Verbindung zu Backbone-Verbindung, Datenkompression/-verschlüsselung, Priorisierung und Pfadauswahl ein.
  • Das selektive TCP-Spoofing wird vom TSK 280 ausgeführt und schließt einen Satz von durch den Anwender konfigurierbaren Regeln ein, die verwendet werden, um zu bestimmen, welche TCP-Verbindungen bandbreitenbedarfsreduziert werden sollen. Das selektive TCP-Spoofing verbessert die Leistung durch Nicht-Einbeziehen von mit TCP-Spoofing in Beziehung stehenden Ressourcen, wie dem Pufferplatz, Steuerblöcken usw., für TCP-Verbindungen, für die der Anwender bestimmt hat, dass ein Spoofing nicht von Vorteil oder nicht erforderlich ist, und durch Unterstützen der Verwendung von maßgeschneiderten Parametern für bandbreitenbedarfsreduzierte TCP-Verbindungen.
  • Genauer unterscheidet der TSK 280 die verschiedenen TCP-Verbindungen aufgrund der Anwendungen, welche diese verwenden. Das heißt, TSK 280 unterscheidet diese TCP-Verbindungen, um zu bestimmen, welche Verbindung bandbreitenbedarfsreduziert werden soll, ebenso wie die Art, auf die die Verbindung bandbreitenbedarfsreduziert wird; z.B. ob der Bandbreitenbedarf des Dreiwege-Verbindungsaufbaus reduziert wird, die speziellen Zeitüberschreitungsparameter für die bandbreitenbedarfsreduzierten Verbindungen usw. Dann wird das TCP-Spoofing nur für jene TCP-Verbindungen ausgeführt, die Anwendungen zugeordnet sind, für die ein hoher Durchsatz oder eine reduzierte Anfangslatenz der Verbindung (oder beides) erforderlich ist. Infolgedessen hebt sich der TSK 280 TCP-Spoofing-Ressourcen nur für die TCP-Verbindungen auf, für die ein hoher Durchsatz oder eine reduzierte Anfangslatenz der Verbindung (oder beides) erforderlich ist. Ferner erhöht der TSK 280 die Gesamtzahl von TCP-Verbindungen, die aktiv sein können, bevor die TCP-Spoofing-Ressourcen aus gehen, da aktive TCP-Verbindungen, die keinen hohen Durchsatz erfordern, nicht zugeordnete Ressourcen sind.
  • Ein Kriterium zum Identifizieren von TCP-Verbindungen von Anwendungen, für die ein TCP-Spoofing ausgeführt werden sollte und nicht ausgeführt werden sollte, ist das in den verschickten TCP-Paketen enthaltene TCP-Port-Nummernfeld. Im Allgemeinen sind jeder Art von Anwendung eindeutige Port-Nummern zugeteilt. Welche TCP-Port-Nummern bandbreitenbedarfsreduziert werden sollen und welche nicht, kann im TSK 280 gespeichert werden. Der TSK 280 ist auch umkonfigurierbar, um einem Anwender oder einem Operator zu ermöglichen, die TCP-Port-Nummern, die bandbreitenbedarfsreduziert und die nicht bandbreitenbedarfsreduziert werden sollen, neu zu konfigurieren. Der TSK 280 erlaubt es einem Anwender oder einem Operator außerdem, aufgrund von anderen Kriterien zu steuern, welche TCP-Verbindungen bandbreitenbedarfsreduziert werden sollen. Im Allgemeinen kann eine Entscheidung darüber, ob eine TCP-Verbindung bandbreitenbedarfsreduziert werden soll, auf jedem Feld innerhalb des TCP-Pakets beruhen. Der TSK 280 erlaubt es einem Anwender, anzugeben, welche Felder zu prüfen sind und welche Werte in diesen Feldern TCP-Verbindungen identifizieren, die bandbreitenbedarfsreduziert werden sollen oder die nicht bandbreitenbedarfsreduziert werden sollen. Ein weiteres Beispiel für einen potentiellen Nutzen dieser Fähigkeit ist, dass der Anwender oder Operator die IP-Adresse des TCP-Pakets wählen kann, um zu steuern, für welche Anwender das TCP-Spoofing ausgeführt wird. Der TSK 280 ermöglicht es einem Anwender außerdem, mehrere Felder gleichzeitig zu betrachten. Infolgedessen ermöglicht es der TSK 280 einem Anwender oder Operator, mehrere Kriterien zu verwenden, um die TCP-Verbindungen, deren Bandbreitenbedarf reduziert werden soll, zu wählen. Zum Beispiel kann der Systemoperator durch Wählen sowohl der IP-Adresse als auch der TCP-Port-Nummernfelder ein TCP-Spoofing nur für bestimmte Anwendungen von bestimmten Anwendern ermöglichen.
  • Die vom Anwender konfigurierbaren Regeln können fünf Beispielskriterien einschließen, die vom Anwender oder Operator festgelegt werden können, um eine selektive TCP-Spoofing-Regel zu erzeugen: Ziel-IP-Adresse; Quell-IP-Adresse; TCP- Portnummern (die sowohl die TCP-Ziel- aus auch die -Quell-Portnummern betreffen können); TCP-Optionen und nach IP unterschiedenes Dienst (DS)-Feld. Wie oben angegeben, können jedoch auch andere Felder innerhalb des TCP-Pakets verwendet werden.
  • Wie oben erörtert, können zusätzlich zur Unterstützung von selektiven TCP-Spoofing-Regeln für jedes dieser Kriterien UND- und ODER-Kombinationsoperatoren verwendet werden, um Kriterien miteinander zu verknüpfen. Zum Beispiel kann durch Verwenden des UND-Kombinationsoperators eine Regel definiert werden, um das TCP-Spoofing für FTP-Daten, die von einem bestimmten Host erhalten werden, nicht zuzulassen. Auch kann die Reihenfolge, in der die Regeln festgelegt sind, wichtig sein. Es ist möglich, dass eine Verbindung den Kriterien mehrerer Regeln genügt. Deshalb kann der TSK 280 Regeln in der Reihenfolge anwenden, die vom Operator festgelegt wurde, wobei er die Aktion der ersten Regel nimmt, die passt. Es kann auch eine Voreinstellungs- bzw. Default-Regel festgesetzt werden, welche die Aktion definiert, die für TCP-Verbindungen ergriffen wird, die zu keiner der definierten Regeln passen. Der vom Operator ausgewählte Regelsatz kann in einem selektiven TCP-Spoofing-Auswahlprofil definiert werden.
  • Angenommen, es wurde ausreichend Pufferspeicherplatz zugewiesen, um beispielsweise den Bandbreitenbedarf von fünf TCP-Verbindungen zu reduzieren, und wenn vier langsame Anwendungen (d.h. Anwendungen, die von Natur aus keine hohe Geschwindigkeit erfordern) Verbindungen zusammen mit einer schnellen Anwendung errichten, dann hat die schnelle Anwendung Zugriff auf nur 1/5 des verfügbaren Pufferspeicherplatzes. Falls fünf langsame Verbindungen vor der schnellen Verbindung zustande kommen, kann der Bandbreitenbedarf der schnellen Verbindung gar nicht reduziert werden. Unter Verwendung des selektiven TSK 280-Spoofingmechanismus wird den langsamen Verbindungen keinerlei Spoofing-Pufferplatz zugewiesen. Daher hat die schnelle Verbindung immer Zugriff auf den Pufferplatz, was ihre Leistung im Vergleich zu einer Implementierung ohne das selektive TCP-Spoofing-Merkmal des TSK 280 verbessert.
  • Der TSK 280 erleichtert auch das Spoofing des konventionellen Dreiwege-Verbindungsaufbaus. Ein Dreiwege-Verbindungsaufbau-Spoofing beinhaltet lokale Antworten auf eine Verbindungsanfrage, um eine TCP-Verbindung zustande zu bringen, parallel zur Sendung der Verbindungsanfragen über den Backbone-Link 130 (1). Dadurch wird es dem Ursprungs-IP-Host (beispielsweise 110) möglich, den Punkt zu erreichen, wo er in der Lage ist, die Daten, die er verschicken muss, mit lokalen Geschwindigkeiten zu verschicken, d.h. Geschwindigkeiten, die unabhängig von der Latenz des Backbone-Links 130 sind. Das Dreiwege-Verbindungsaufbau-Spoofing macht es möglich, die Daten, die der IP-Host 110 verschicken muss, zum Ziel-Host 150 zu schicken, ohne auf die durchgehende bzw. Ende-zu-Ende-Einrichtung der TCP-Verbindung zu warten. Für Backbone-Links mit hoher Latenz reduziert dies erheblich die Zeit, die nötig ist, um die TCP-Verbindung zustande zu bringen, und was am wichtigsten ist, die Zeit, die es insgesamt dauert, um eine Antwort (von einem IP-Host 150) auf die Daten zu erhalten, die der IP-Host 110 schickt.
  • Ein spezifisches Beispiel, in dem diese Technik von Nutzen ist, betrifft eine Internet-Web-Seiten-Zugriffsanwendung. Beim Dreiwege-Verbindungsaufbau-Spoofing kann die Anfrage eines IP-Host nach Zugriff auf eine Web-Seite unterwegs zum Web-Server sein, ohne auf die Ende-zu-Ende-Einrichtung der TCP-Verbindung warten zu müssen, wodurch die Zeit, die der Download der Web-Seite benötigt, verkürzt wird.
  • Mit Local Data Acknowledgement bestätigt der TSK 280 im Netzwerk-Gateway 120 (beispielsweise) lokal den Empfang von Datensegmenten, die vom IP-Host 110 erhalten wurden. Dadurch kann der IP-Host 110 sofort weitere Daten verschicken. Noch wichtiger ist, dass TCP eingegangene Empfangsbestätigungen als Signale zur Erhöhung der aktuellen TCP-Fenstergröße nutzt. Infolgedessen ermöglicht die lokale Empfangsbestätigung es dem versendenden IP-Host 110, das TCP-Fenster wesentlich rascher zu vergrößern als dies durch Ende-zu-Ende-Empfangsbestätigungen unterstützt wird. Der TSK 280 (der Spoofer) übernimmt Verantwortung für die zuverlässige Zustellung der von ihm bestätigten Daten.
  • Im BPK 282 werden mehrere TCP-Verbindungen auf einer einzigen Backbone-Verbindung gemultiplext und übertragen. Dadurch wird die Systemleistung verbessert, da die Daten für mehrere TCP-Verbindungen von einer einzigen Backbone-Verbindungs-Empfangsbestätigung (ACK) bestätigt werden können, was die Menge des Empfangsbestätigungsverkehrs, der erforderlich ist, um einen hohen Durchsatz durch den Backbone-Link 130 aufrechtzuerhalten, erheblich reduziert. Darüber hinaus wählt der BPK 282 ein Backbone-Verbindungsprotokoll aus, das dafür optimiert ist, einen hohen Durchsatz für die spezielle Verknüpfung bereitzustellen. Unterschiedliche Backbone-Verbindungsprotokolle können vom BPK 282 mit verschiedenen Backbone-Links verwendet werden, ohne die grundlegende TCP-Spoofing-Implementierung zu ändern. Das vom BPK 282 ausgewählte Backbone-Verbindungsprotokoll stellt eine ausreichende Unterstützung für die zuverlässige, schnelle Sendung von Daten über den Backbone-Link 130 bereit, wobei die Details der Behinderungen (beispielsweise hohe Latenz) der Verknüpfung gegenüber der TCP-Spoofing-Implementierung verborgen bleiben.
  • Das Multiplexen durch den BPK 282 ermöglicht die Verwendung eines Backbone-Link-Protokolls, das individuell auf die Verwendung mit der speziellen Verknüpfung zugeschnitten ist und eine Technik zur Verstärkung der Leistung des Backbone-Link-Protokolls mit wesentlich weniger Abhängigkeit von der Einzelleistung der bandbreitenbedarfsreduzierten TCP-Verbindungen bereitstellt als herkömmliche Methoden. Ferner macht die Fähigkeit, das Backbone-Protokoll für verschiedene Backbone-Links maßzuschneidern, die vorliegende Erfindung auf unterschiedliche Systeme anwendbar.
  • Der PEP 200 kann optional einen Datenkompressions-Kernel 290 zum Komprimieren von TCP-Daten und einen Verschlüsselungs-Kernel 292 zum Verschlüsseln von TCP-Daten einschließen. Die Datenkompression erhöht die Datenmenge, die über die Backbone-Verbindung übertragen werden kann. Verschiedene Kompressionsalgorithmen können vom Datenkompressions-Kernel 290 unterstützt werden, und mehr als eine Kompressionsart kann gleichzeitig unterstützt werden. Der Datenkompressions- Kernel 290 kann optional eine Kompression auf TCP-Verbindungsbasis anwenden, bevor die TCP-Daten mehrerer TCP-Verbindungen auf der Backbone-Verbindung oder aufgrund einer Backbone-Verbindung gemultiplext werden, nachdem die TCP-Daten verschiedener TCP-Verbindungen auf der Backbone-Verbindung gemultiplext wurden. Welche Option genutzt wird, wird dynamisch nach vom Anwender konfigurierten Regeln und den spezifischen genutzten Kompressionsalgorithmen bestimmt. Beispiele für Datenkompressionsalgorithmen sind in den US-Patenten Nr. 5,973,630, 5,955,976 offenbart, deren gesamter Inhalt durch Bezugnahme hierin aufgenommen ist. Der Verschlüsselungs-Kernel verschlüsselt die TCP-Daten für die sichere Übertragung über den Backbone-Link 130. Die Verschlüsselung kann anhand jeder herkömmlichen Technik durchgeführt werden. Es ist auch klar, dass der entsprechende Spoofer (in dem oben ausgeführten Beispiel der Network-Gateway 140) geeignete Kernel für die Dekompression und Verschlüsselung einschließt, die beide anhand von beliebigen herkömmlichen Techniken durchgeführt werden können.
  • Der PK 284 stellt einen priorisierten Zugang zur Backbone-Link-Leistung bereit. Beispielsweise kann die Backbone-Verbindung tatsächlich in N (N > 1) unterschiedliche Unterverbindungen geteilt werden, von denen jede eine andere Prioritätshöhe aufweist. In einem Ausführungsbeispiel können vier Prioritätshöhen unterstützt werden. Der PK 284 nutzt anwenderdefinierte Regeln, um verschiedenen TCP-Verbindungen verschiedene Prioritäten und somit unterschiedliche Unterverbindungen der Backbone-Verbindung zuzuweisen. Es sei darauf hingewiesen, dass PK 284 auch Nicht-TCP-Verkehr (z.B. UDP (User Datagram Protocol)-Verkehr) priorisieren kann, bevor er den Verkehr über den Backbone-Link 130 schickt.
  • Der PK 284 nutzt auch anwenderdefinierte Regeln zur Steuerung der Menge der Leistung des Backbone-Link 130, die jeder Prioritätshöhe zur Verfügung steht. Beispiele für Kriterien, die verwendet werden können, um die Priorität zu bestimmen, schließen die folgenden ein: Ziel-IP-Adresse; Quell-IP-Adresse; nächstes IP-Protokoll; TCP-Portnummern (was sowohl die TCP-Ziel- als auch -Quell-Portnummern betreffen kann); UDP-Portnummern (was sowohl die UDP-Ziel- als auch die -Quell-Port nummern betreffen kann); und IP-DiffServ (DS)-Feld. Die Art der Daten in den TCP-Datenpaketen kann ebenfalls als Kriterium genommen werden. Beispielsweise könnten Videodaten die höchste Priorität erhalten. Zielkritische Daten könnten ebenfalls die höchste Priorität erhalten. Wie beim selektiven TCP-Spoofing kann jedes Feld im IP-Paket vom PK 284 verwendet werden, um die Priorität zu bestimmen. Es sei jedoch darauf hingewiesen, dass unter solchen Szenarios die Folge der Verwendung eines solchen Felds bewirken könnte, das verschiedene IP-Pakete des gleichen Flusses (z.B. TCP-Verbindung) unterschiedliche Prioriäten erhalten können; diese Szenarios sollten vermieden werden.
  • Wie oben angegeben, können zusätzlich zur Unterstützung selektiver Priorisierungsregeln für jedes dieser Kriterien UND- und ODER-Kombinationsoperatoren verwendet werden, um Kriterien miteinander zu verknüpfen. Zum Beispiel kann unter Verwendung des UND-Kombinationsoperators eine Regel definiert werden, um eine Priorität für SNMP-Daten, die von einem bestimmten Host empfangen werden, zuzuordnen. Auch die Reihenfolge, in der die Befehle festgelegt werden, kann von Bedeutung sein. Es ist möglich, dass eine Verbindung den Kriterien mehrerer Regeln entspricht. Daher kann der PK 284 Regel in der vom Operator festgelegten Reihenfolge anwenden, wobei er die erste Regel ausführt, die passt. Es kann auch eine Default-Regel festgesetzt werden, die definiert, welche Aktionen für IP-Pakete ausgeführt werden sollen, die keiner der definierten Regeln entsprechen. Der vom Operator ausgewählte Regelsatz kann in einem Priorisierungsprofil definiert werden.
  • Was die Pfadauswahlfunktionalität betrifft, so ist der PSK 286 verantwortlich für die Bestimmung, welchen Weg ein IP-Paket einschlagen soll, um sein Ziel zu erreichen. Der vom PSK 286 ausgewählte Weg kann durch Anwenden von Wegauswahlregeln bestimmt werden. Der PSK 286 bestimmt auch, welche IP-Pakete unter Verwendung eines alternativen Wegs versendet werden sollen und welche IP-Pakete fallen gelassen werden sollen, wenn einer oder mehrere primäre Wege ausfallen. Pfadauswahlparameter können auch anhand von Profilen konfiguriert werden. Die Pfadauswahlregeln können so ausgelegt sein, dass sie Flexibilität im Hinblick auf die Zuordnung von Pfaden ver leihen, während sie sicherstellen, dass alle Pakete, die zum gleichen Verkehrsfluss (z.B. der gleichen TCP-Verbindung) gehören, den gleichen Pfad nehmen (obwohl es auch möglich ist, Segmente der gleichen TCP-Verbindung auf unterschiedlichen Wegen zu verschicken, könnte dieses Segment-„Splitting" negative Nebenwirkungen haben). Beispiele für Kriterien, die verwendet werden können, um einen Pfad auszuwählen, schließen die folgenden ein: Priorität des IP-Pakets wie vom PK 284 eingestellt (sollte das üblichste Kriterium sein), Ziel-IP-Adresse; Quell-IP-Adresse; nächstes IP-Protokoll; TCP-Portnummern (was sich sowohl auf die TCP-Ziel- als auch die -Quell-Portnummern beziehen kann); UDP-Portnummern (was sich sowohl auf die UDP-Ziel- als auch die -Quell-Portnummern beziehen kann); und IP-DiffServ (DS)-Feld. Ähnlich wie beim selektiven TCP-Spoofing und Priorisierung kann der PSK 284 einen Pfad unter Verwendung jedes beliebigen Felds im IP-Paket bestimmen.
  • Was die Priorisierungskriterien (Regeln) betrifft, so können die UND- und ODER-Kombinationsoperatoren verwendet werden, um Kriterien miteinander zu verknüpfen. Beispielsweise kann anhand des UND-Kombinationsoperators eine Regel definiert werden, um einen Pfad für SNMP-Daten auszuwählen, die von einem bestimmten Host empfangen werden. Auch kann die Reihenfolge wichtig sein, in der die Regeln festgelegt sind. Es ist möglich, dass eine Verbindung den Kriterien mehrerer Regeln entspricht. Daher kann der PSK 286 Regeln in der vom Operator festgelegten Reihenfolge anwenden, wobei er die erste passende Regel ausführt. Es kann auch eine Default-Regel festgesetzt werden, die definiert, welche Aktionen für IP-Paketen durchgeführt werden sollen, die keiner der definierten Regeln entsprechen. Der vom Operator ausgewählte Regelsatz kann in einem Pfadauswahlprofil definiert sein.
  • Beispielsweise kann eine Pfadauswahlregel den Pfad aufgrund der folgenden Pfadinformationen wählen, in denen die IP-Pakete die folgende Regel erfüllen: in einem primären Pfad, einem sekundären Pfad, einem tertiären Pfad. Der primäre Pfad wird in jeder Pfadauswahlregel festgelegt. Der sekundäre Pfad wird nur benutzt, wenn der primäre Pfad ausgefallen ist. Falls kein sekundärer Pfad festgelegt wurde, können beliebige IP-Pakete, die der Regel entsprechen, fallen gelassen werden, wenn der primäre Pfad ausfällt. Der tertiäre Pfad wird nur festgelegt, wenn ein sekundärer Pfad festgelegt wurde. Der tertiäre Pfad wird ausgewählt, wenn sowohl der primäre Pfad als auch der sekundäre Pfad ausgefallen sind. Falls kein tertiärer Pfad festgelegt wurde, können beliebige IP-Pakete, die der Regel entsprechen, fallen gelassen werden, wenn sowohl der primäre als auch der sekundäre Pfad ausfallen. Die Pfadauswahl kann verallgemeinert werden, so dass die Pfadauswahlregel bis zu N Pfade auswählen kann, wobei der N. Pfad nur ausgewählt wird, wenn der (N – 1). Pfad ausfällt. Das obige Beispiel, wo N = 3, dient nur als Beispiel, obwohl N in der Regel eine ziemlich kleine Zahl ist.
  • Anhand eines Beispiels wird die Betriebsweise des Systems 100 wie folgt beschrieben. Zunächst wird eine Backbone-Verbindung zwischen den PEPs von zwei Netzwerk-Gateways 120, 140 (d.h. den beiden Spoofern), die sich an den jeweiligen Enden des Backbone-Link 130, für den ein TCP-Spoofing gewünscht ist, befinden, eingerichtet. Sobald ein IP-Host 110 eine TCP-Verbindung initiiert, überprüft der TSK 280 des PEP 200, der am IP-Host 110 vor Ort ist, seine konfigurierten TCP-Spoofing-Regeln. Falls die Regeln anzeigen, dass der Bandbreitenbedarf der Verbindung nicht reduziert werden soll, erlaubt der PEP 200 den durchgehend nicht-bandbreitenbedarfsreduzierten Fluss der Verbindung. Falls die Regeln anzeigen, dass der Bandbreitenbedarf der Verbindung reduziert werden soll, antwortet der bandbreitenbedarfsreduzierende PEP 200 lokal auf den TCP-Dreiwege-Verbindungsaufbau des IP-Hosts. Parallel dazu schickt der PEP 200 eine Nachricht über den Backbone-Link 130 zu seinem Partner-Netzwerk-Gateway 140 und bittet diesen, einen TCP-Dreiwege-Verbindungsaufbau mit dem IP-Host 150 an dessen Seite des Backbone-Link 130 zu initiieren. Dann werden Daten zwischen dem IP-Host 110, 150 mit dem PEP 200 des Network-Gateway 120 ausgetauscht, der die empfangenen Daten lokal bestätigt und diese über den Backbone-Link 130 durch die schnelle Backbone-Verbindung schickt, wobei er die Daten komprimiert wie aufgrund der konfigurierten Komprimierungsregeln angemessen. Die Priorität der TCP-Verbindung wird bestimmt, wenn die Verbindung eingerichtet ist. Der BPK 282 kann die Verbindung mit anderen empfangenen Verbindungen über eine einzige Backbone-Verbindung multiplexen, der PK 284 bestimmt die Priorität der Verbindung und der PSK 286 bestimmt den Pfad, den die Verbindung einschlagen soll.
  • Wie oben beschrieben, verbessert der PEP 200 auf vorteilhafte Weise die Netzwerkleistung durch Zuordnen von mit TCP-Spoofing in Beziehung stehenden Ressourcen, wie Pufferspeicherplatz, Steuerblöcken usw., nur zu TCP-Verbindungen, für die ein Spoofing Vorteile bringt; durch Spoofing des Dreiwege-Verbindungsaufbaus zum Verkürzen der Datenantwortzeit; durch Reduzieren der Zahl von ACKs, die durch Ausführen einer lokalen Empfangsbestätigung übertragen werden, und durch Bestätigen von mehreren TCP-Verbindungen mit einem einzigen ACK; durch Durchführen einer Datenkomprimierung, um die Datenmenge, die übertragen werden kann, zu erhöhen; durch Zuordnen von Prioritäten zu verschiedenen Verbindungen und durch Definieren von mehreren Pfaden für einzurichtende Verbindungen.
  • 3 zeigt ein Beispiel für einen Stapel, der die Beziehung zwischen dem TCP-Stapel und den PEP-Kernels 280, 282, 284, 286 der vorliegenden Erfindung zeigt. Der TSK 280 ist in erster Linie verantwortlich für Funktionen im Zusammenhang mit TCP-Spoofing. Der TSK 280 schließt in einem Ausführungsbeispiel zwei Grundelemente ein: eine Transportschicht, die einen TCP-Stapel 303 und einen IP-Stapel 305 umfasst; und eine TCP-Spoofing-Anwendung 301. Die Transportschicht ist verantwortlich für die Interaktion innerhalb der TCP-Stapels (z.B. 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-Statusmaschinen einschließt und beendet bandbreitenbedarfsreduzierte TCP-Verbindungen. Die TCP-Spoofing-Anwendung 301 sitzt auf der Transportschicht auf und dient als Anwendung, die Daten von Anwendungen der IP-Hosts 110 empfängt und an diese verschickt. Aufgrund der Schichtarchitektur des Protokolls isoliert die TCP-Spoofing-Anwendung 301 die Details des TCP-Spoofing gegenüber der Transportschicht, wodurch die Transportschicht auf Standardweise arbeiten kann.
  • Wie in 3 dargestellt, kann die TCP-Spoofing-Anwendung 301 auch eine Verknüpfung mit der BPK 282 eingehen, die mit den WAN-Schnittstellen 230 in Ver bindung steht. Der BPK sorgt für die Aufrechterhaltung des Backbone-Protokolls, wobei er die das Protokoll, mit dem die Netzwerk-Gateways 120, 140 (in 1) kommunizieren, implementiert. Der BPK 282 sorgt für eine zuverlässige Sendung von Daten, nutzt einen relativ kleinen Umfang an Bestätigungsverkehr und unterstützt die Verwendung von ausgewählten Backbones (d.h. eine Verwendung, die nicht spezifisch für die TSK 280 ist); eines dieser Beispiele ist das Reliable Data Protocol (RDP).
  • Der BPK 282 liegt gemäß einem Ausführungsbeispiel über dem PK 284 und dem PSK 286. Der PK 284 ist dafür verantwortlich, die Priorität von IP-Paketen zu bestimmen und dann aufgrund der Priorität Übertragungsmöglichkeiten zuzuordnen. Der PK 284 kann auch den Zugriff auf Pufferspeicherpuffer steuern, indem er die Warteschlangengröße, die mit dem Verschicken und Empfangen von Paketen assoziiert ist, steuert. Der PSK 286 bestimmt, welchen Weg ein IP-Paket nehmen soll, um sein Ziel zu erreichen. Der Pfad, der vom PSK 286 ausgewählt wird, kann durch Anwenden von Pfadauswahlregeln bestimmt werden. Der PSK 286 kann auch bestimmen, welches IP-Paket unter Verwendung eines alternativen Pfads weitergegeben werden soll und welche Pakete fallen gelassen werden sollen, wenn einer oder mehrere primäre Pfade ausfallen.
  • Die 4A und 4B zeigen Ablaufschemata der Einrichtung einer bandbreitenbedarfsreduzierten TCP-Verbindung unter Verwendung von Dreiwege-Verbindungsaufbau-Spoofing bzw. ohne Dreiwege-Verbindungsaufbau-Spoofing. Der TCP-Spoofing-Kernel 280 richtet eine bandbreitenbedarfsreduzierte TCP-Verbindung ein, wenn ein TCP <SYN>-Segment von seinem lokalen LAN oder eine Connection Request-Nachricht von seinem TSK-Peer empfangen wird. Es sei darauf hingewiesen, dass das Dreiwege-Verbindungsaufbau-Spoofing außer Funktion gesetzt werden kann, um einen Austausch mit maximaler Ende-zu-Ende-Segmentgröße (MSS) zu unterstützen, wie nachstehend ausführlicher beschrieben. Für den Zweck der Erläuterung wird das Verfahren zum Einrichten einer bandbreitenbedarfsreduzierten TCP-Verbindung mit Bezug auf einen lokalen Host 400, einen lokalen PEP-Endpunkt 402, einen entfernten PEP-Endpunkt 404 und einen entfernten Host 406 beschrieben. Wie bereits erwähnt, stellt der TSK 280 innerhalb der einzelnen PEP-Endpunkte 402 und 404 die Spoofing-Funktion bereit.
  • In Schritt 401 überträgt 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 bereits ein TCP-Verbindungs-Steuerblock (CCB) der zu dem TCP-Segment gehörenden TCP-Verbindung zugeordnet ist. Falls kein CCB vorhanden ist, überprüft die Umgebung 402, ob das TCP-Segment ein <SYN>-Segment ist, das an ein nicht-lokales Ziel geschickt wird. Falls dies der Fall ist, stellt das <SYN>-Segment einen Versuch dar, eine neue (nicht lokale) TCP-Verbindung zustande zu bringen, und die Umgebung 402 gibt das Segment an den TCP-Spoofing-Kernel 280 ab, um die Disposition der TCP-Verbindung zu bestimmen. Wenn ein TCP <SYN>-Segment von der lokalen LAN-Schnittstelle 220 für eine neue TCP-Verbindung empfangen wird, bestimmt der TCP-Spoofing-Kernel 280 zuerst, ob der Bandbreitenbedarf der Verbindung reduziert werden soll. Falls der Bandbreitenbedarf der Verbindung reduziert werden soll, nutzt der TSK 280 (in einem Ausführungsbeispiel) die in dem ausgewählten TCP-Spoofing-Parameterprofil angezeigte Priorität und den Peer-Index (der von der Umgebung 210 mit dem TCP <SYN>-Segment bereitgestellt wird), um den Handle der Backbone-Verbindung zu konstruieren, der verwendet werden soll, um diese bandbreitenbedarfsreduzierte TCP-Verbindung zu befördern. In dem Ausführungsbeispiel wird der Peer-Index als die 14 Bits höherer Ordnung des Handle verwendet, und die Priorität wird als die beiden Bits niederer Ordnung des Handle verwendet. Der Backbone-Verbindungs-Handle wird dann (über die TSK-Steuerblock (TCB)-Mappingtabelle) verwendet, um den TCB zu finden, der mit der Backbone-Verbindung assoziiert ist. Der TSK 280 des PEP-Endpunkts 402 überprüft dann, ob die Backbone-Verbindung aktiv ist. Falls die Backbone-Verbindung aktiv ist, bestimmt der TSK 280 ob, die Zahl der bandbreitenbedarfsreduzierten TCP-Verbindungen, die bereits die ausgewählte Backbone-Verbindung nutzen, immer noch unter dem CCB-Ressourcen-Limit liegt. Das CCB-Ressourcen-Limit ist die kleinere von der lokalen Zahl der CCBs (bereitgestellt als Parameter durch die Plattformumgebung 210) und der Peer-Zahl der CCBs (empfangen in der letzten TSK-Peerparameter (TPP)-Nachricht vom TSK-Peer), die für diese Backbone-Verbindung zur Verfügung steht. Falls die Zahl der Verbindungen noch immer unter dem Limit liegt, ordnet der TSK 280 des PEP-Endpunkts 402 der Verbindung einen einzigartigen TCP-Verbindungsidentifizierer (z.B. einen freien CCB-Mappingtabellen-Eintragsindex) zu und ruft die Umgebung 210, um einen TCP-Verbindungssteuerblock für die Verbindung zuzuordnen.
  • Der TSK 280 des PEP-Endpunkts 402 schicht das TCP <SYN>-Segment zurück zur Umgebung 210, um nicht-bandbreitenbedarfsreduziert weitergeschickt zu werden, falls die obigen Prüfungen versagen. Anders ausgedrückt führen die folgenden Bedingungen dazu, dass die TCP-Verbindung nicht bandbreitenbedarfsreduziert ist. Zuerst, wenn die selektiven TCP-Spoofing-Regeln anzeigen, dass die Verbindung nicht bandbreitenbedarfsreduziert werden soll. Auch besteht keine Backbone-Verbindung für die Priorität, bei der der Bandbreitenbedarf der TCP-Verbindung reduziert werden sollte (angezeigt durch die Anwesenheit eines TCB für die Backbone-Verbindung). Kein Spoofing wird durchgeführt, wenn die Backbone-Verbindung nicht aktiv ist. Außerdem wird, wenn die Zahl der bandbreitenbedarfsreduzierten TCP-Verbindungen, die bereits die Backbone-Verbindung nutzen, einen vorgegebenen Schwellenwert erreicht oder übertrifft, dann kein Spoofing durchgeführt. Falls kein CCB-Mapping-Tabelleneintrag verfügbar ist oder wenn kein CCB aus dem freien CCB-Pool verfügbar ist, dann wird die TCP-Verbindung ohne Reduzierung des Bandbreitenbedarfs weitergegeben. In dem Fall, dass keine Backbone-Verbindung besteht, kann der TSK 280 des PEP-Endpunkts 402 auch ein Ereignis posten, um den Operator zu warnen, dass ein Missverhältnis zwischen den konfigurierten TCP-Spoofing-Parameterprofilen und dem konfigurierten Satz an Backbone-Verbindungen besteht.
  • Wenn man das Beispiel fortführt, so schreibt der TSK 280 des PEP-Endpunkts 402, falls alle obigen Prüfungen bestanden werden, den Backbone-Verbindungs-Handle in den Pufferspeicher, in dem das TCP <SYN>Segment hinterlegt ist. Es sei darauf hingewiesen, dass dies nicht geschieht, solange kein CCB erfolgreich von der Plattformumgebung 402 zugeordnet wurde, da diese Umgebung die Pufferspeicher nicht zählt, bis ein CCB erfolgreich zugeordnet wurde. Der TSK 280 kopiert dann die Parameter von dem ausgewählten TCP-Spoofing-Parameterprofil in den CCB. Als Folge davon werden relevante Informationen (z.B. die maximale Segmentgröße, die von dem Host geboten wird (falls kleiner als die konfigurierte MSS), die Anfangssequenznummer usw.) aus dem TCP <SYN>-Segment kopiert und in dem CBB gespeichert. Es sei darauf hingewiesen, dass die Quell- und Ziel-IP-Adressen und Quell- und Ziel-TCP-Portnummern von der Plattformumgebung 402 bereits in den CCB eingegeben wurden, als der CCB zugeordnet wurde; die Umgebung 402 nutzt diese Informationen, um CCB-Hash-Funktionkollisionen zu handhaben.
  • Nach Zuordnen und Festsetzen des CCB konstruiert der TCP-Spoofing-Kernel des PEP-Endpunkts 402 eine Connection Request (CR)-Nachricht in Schritt 403 und schickt diese zu seinem TSK-Peer, der mit dem entfernten PEP-Endpunkt 404 assoziiert ist. Die CR-Nachricht enthält im Grunde alle Informationen, die aus dem TCP-Spoofing-Parameterprofil und dem TCP <SYN>-Segment extrahiert wurden und die im lokalen CCB gespeichert wurden, z.B. die Quell- und Ziel-IP-Adressen, die Quell- und Ziel-TCP-Portnummern, den MSS-Wert usw., mit der Ausnahme von Feldern, die nur lokale Bedeutung haben, wie die Anfangssequenznummer. (Die IP-Adressen und TCP-Portzahlen werden in einen TCP-Verbindungs-Header eingegeben.) Anders ausgedrückt, die CR-Nachricht enthält alle Informationen, die der Peer-TSK des PEP-Endpunkts 404 braucht, um seinen eigenen CCB einzurichten. Um die Einrichtung der lokalen Verbindung zu beenden, schickt der TCP-Spoofing-Kernel 280 des lokalen PEP-Endpunkts 402 in Schritt 405 ein TCP <SYN,ACK>-Segment an den lokalen Host 400 als Antwort auf das erhaltene <SYN>-Segment. Der TSK 280 des PEP-Endpunkts 402 führt Schritt 405 gleichzeitig mit dem Schritt des Versendens der Connection Request-Nachricht (d.h. Schritt 403) durch, falls ein Dreiwege-Verbindungsaufbau-Spoofing möglich ist. Ansonsten wartet der TSK 280 von 402 auf eine Connection Established (CE)-Nachricht von seinem TSK-Peer vom entfernten PEP-Endpunkt 404, bevor er das <SYN,ACK>-Segment versendet. In einem Ausführungsbeispiel wählt der TSK 280 des PEP-Endpunkts 402 eine zufällige Anfangssequenznummer (wie in der IETF (Internet Engineer ing Task Force) RFC 793 bereitgestellt, die hierin in ihrer Gesamtheit durch Bezugnahme aufgenommen ist), die zum Versenden von Daten verwendet wird.
  • Falls das Dreiwege-Verbindungsaufbau-Spoofing nicht möglich ist, ist der MSS-Wert, der im <SYN,ACK>-Segment verschickt wird, gleich dem MSS-Wert, der in der CE-Nachricht erhalten wird. Falls ein Dreiwege-Verbindungsaufbau-Spoofing möglich ist, wird der MSS-Wert aus dem TCP-Spoofing-Parameterprofil bestimmt, das für die Verbindung (und die konfigurierte maximale Pfadübertragungseinheit (MTU)) gewählt wurde. Für diesen Fall vergleicht der TSK 280 des PEP-Endpunkts 402 dann den MSS-Wert, der in der Connection Established-Nachricht erhalten wird, wenn er ankommt, mit dem Wert, der zum lokalen Host im TCP <SYN,ACK>-Segment geschickt wird. Falls der MSS-Wert, der in der CE-Nachricht erreicht wird, kleiner ist als der MSS-Wert, der zum lokalen Host geschickt wird, liegt ein Missverhältnis der maximalen Segmentgröße vor. (Falls ein MSS-Missverhältnis vorliegt, kann es notwendig sein, dass der TSK die Größe von TCP-Datensegmenten anpasst, bevor er sie versendet.) Nach Versenden des TCP <SYN,ACK>-Segments (Schritt 405) ist der TSK 280 des lokalen PEP-Endpunkts 402 bereit, Daten von dem lokalen Host 400 zu empfangen. In Schritt 407 überträgt der lokale Host 400 ein <ACK>-Segment an den TSK 280 des PEP-Endpunkts 402; danach schickt der lokale Host, wie in Schritt 409, auch Daten an den TSK 280 des PEP-Endpunkts 402. Wenn ein Dreiwege-Verbindungsaufbau-Spoofing angewendet wird, muss der TSK 280 nicht darauf warten, dass die Connection Established-Nachricht von seinem TSK-Peer ankommt, bevor er Daten empfängt und weiterschickt. Wie in 4A dargestellt, schickt 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 zum Peer-TSK des PEP-Endpunkts 404 (in Schritt 413), bevor er eine CE-Nachricht vom TSK des PEP-Endpunkts 404 empfängt.
  • Der TSK 280 des PEP-Endpunkts 402 nimmt jedoch keine Daten von seinem TSK-Peer vom PEP-Endpunkt 404 an, bis die CE-Nachricht empfangen wurde. Der TSK 280 des PEP-Endpunkts 402 schickt keine Daten, die er von seinem TSK-Peer des PEP-Endpunkts 404 empfangen hat, zum 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 Peer-TSK empfangen wird (Schritt 403), ordnet der TCP-Spoofing-Kernel 280 einen CCB für die Verbindung zu und speichert dann alle relevanten Informationen aus der CR-Nachricht im CCB. Der TSK 280 des PEP-Endpunkts 404 nutzt dann diese Informationen, um ein TCP <SYN>-Segment zu erzeugen, wie in Schritt 415, um es zum entfernten Host 406 zu schicken. Die MSS im <SYN>-Segment wird auf den Wert eingestellt, der vom TSK-Peer des PEP-Endpunkts 404 erhalten wurde. Wenn der entfernte Host mit einem TCP <SYN,ACK>-Segment antwortet (Schritt 417) schickt der TSK 280 des PEP-Endpunkts 402 eine Connection Established-Nachricht an seinen TSK-Peer des entfernten PEP-Endpunkts 404 (Schritt 419), wobei er in der CE-Nachricht die MSS, die von dem lokalen Host in dem <SYN,ACK>-Segment geschickt wird, einschließt. Der TSK 280 des PEP-Endpunkts 402 antworte ebenfalls, wie in Schritt 421, mit einem TCP <ACK>-Segment, um den lokalen Dreiwege-Verbindungsaufbau zu vervollständigen. Der Peer-TSK des PEP-Endpunkts 404 schickt dann in Schritt 423 die Daten, die er vom TSK 280 empfangen hat, zum Host weiter. Gleichzeitig schickt der entfernte Host 406 in Schritt 425 Daten an den Peer-TSK vom PEP-Endpunkt 404, der in Schritt 427 den Empfang der Daten durch Ausgabe eines <ACK>-Segments an den entfernten PEP-Endpunkt 404 bestätigt. Gleichzeitig mit der Bestätigung werden die Daten an den TSK 280 des PEP-Endpunkts 402 geschickt (Schritt 429).
  • An diesem Punkt ist der TSK 280 bereit, Daten aus jeder Richtung zu empfangen und weiterzusenden. Der TSK 280 schickt die Daten, wie in Schritt 431, an den lokalen Host weiter, der seinerseits ein <ACK>-Segment verschickt (Schritt 433). Falls die Daten von ihrem TSK-Peer ankommen, bevor eine <SYN,ACK>-Segment-Antwort vom lokalen Host erhalten wird, werden die Daten in die Warteschlange gestellt und dann verschickt, nachdem das <ACK>-Segment als Antwort auf ein <SYN,ACK>-Segment verschickt wird (wenn dieses ankommt).
  • Wie in 4B dargestellt, wird eine bandbreitenbedarfsreduzierte TCP-Verbindung eingerichtet, wenn ein Dreiwege-Verbindungsaufbau-Spoofing nicht möglich ist. In diesem Szenario übermittelt der lokale Host 400 ein TCP <SYN>-Segment, wie in Schritt 451, an den TSK 280 im lokalen PEP-Endpunkt 402. Anders als bei der TCP-Verbindungseinrichtung von 4A antwortet der lokale PEP-Endpunkt 402 auf das TCP <SYN>-Segment nicht mit einem <SYN,ACK>-Segment, sondern schickt einfach eine CR-Nachricht an den entfernten PEP-Endpunkt 404 (Schritt 453). Als Nächstes wird in Schritt 455 ein TCP <SYN>-Segment an den entfernten Host 406 geschickt. Als Antwort darauf übermittelt der entfernte Host 406 ein TCP <SYN,ACK>-Segment zurück an den entfernten PEP-Endpunkt 404 (in Schritt 457). Danach schickt der entfernte PEP-Endpunkt 404, wie in Schritt 459, eine CE-Nachricht an den lokalen PEP-Endpunkt 402, der anschließend in Schritt 461 ein <SYN,ACK>-Segment an den lokalen Host 400 ausgibt. Gleichzeitig mit Schritt 459 gibt der entfernte PEP-Endpunkt 404 ein <ACK>-Segment an den entfernten Host 406 aus (Schritt 463).
  • Sobald er das <ACK>-Segment empfängt, kann der entfernte Host 406 in Schritt 465 mit der Datenübertragung beginnen. Sobald der PEP-Endpunkt 404 die Daten vom entfernten Host 406 empfängt, übermittelt der entfernte PEP-Endpunkt 404 gleichzeitig, wie in Schritt 467, die TD-Nachricht an den lokalen PEP-Endpunkt 402 und übermittelt ein <ACK>-Segment an den entfernten Host 406, um den Datenempfang zu bestätigen (Schritt 469).
  • Da der lokale Host 400 ein <SYN,ACK>-Segment vom lokalen PEP-Endpunkt 402 empfangen hat, bestätigt der lokale Host 400 die Nachricht in Schritt 471. Danach übermittelt der lokale Host 400 Daten an den lokalen PEP-Endpunkt 402. In diesem Beispiel schickt der lokale PEP-Endpunkt 402, bevor er die Daten vom lokalen Host 400 empfängt, die Daten, die vom entfernten Host 406 stammen, in Schritt 475 über die TD-Nachricht (Schritt 467) an den lokalen Host 400.
  • Als Antwort auf die empfangenen Daten (in Schritt 473) gibt der lokale PEP-Endpunkt 402 ein <ACK>-Segment aus, wie in Schritt 477, und schickt die Daten in Schritt 479 in einer TD-Nachricht an den entfernten PEP-Endpunkt 404. Der lokale Host 400 antwortet auf die in Schritt 475 empfangenen Daten mit einem <ACK>-Segment an den lokalen PEP-Endpunkt 402 (Schritt 481). Der entfernte PEP-Endpunkt 404 schickt die Daten vom lokalen Host 400, wie in Schritt 483, nachdem er die TD-Nachricht empfangen hat. Nach Empfang der Daten bestätigt der entfernte Host 406 den Empfang durch Zurücksenden eines <ACK>-Segments an den entfernten PEP-Endpunkt 404 in Schritt 485.
  • 5 zeigt den Fluss von Paketen mit der PEP-Architektur gemäß einer Ausführungsform der vorliegenden Erfindung. Wie dargestellt, schließt ein Kommunikationssystem 500 einen Hub-Site- (oder lokalen) PEP-Endpunkt 501 ein, der eine Konnektivität mit einem Fern-Site-PEP-Endpunkt 503 über eine Backbone-Verbindung hat. Beispielsweise handhaben an der Hub-Site (oder der lokalen Site) und an jeder entfernten Site PEP-Endpunkte 501 und 503 IP-Pakete. Der PEP-Endpunkt 501 schließt ein Internal IP-Paket-Routing-Modul 501a ein, das lokale IP-Pakete empfängt und diese Pakete mit einem TSK 501b und einem BPK 501c tauscht. Ebenso schließt der entfernte PEP-Endpunkt 503 ein internes IP-Paket-Routing-Modul 503a ein, das mit einem TSK 503b und einem BPK 503c kommuniziert. Abgesehen von der Tatsache, dass der Hub-Site PEP-Endpunkt 501 mehr Backbone-Protokoll-Verbindungen unterstützen kann als ein Fern-Site-PEP-Endpunkt 503, ist die Hub- und die Fern-Site-PEP-Verarbeitung symmetrisch.
  • Für den Lokal-zu-WAN-Verkehr (d.h. in Aufwärtsrichtung), empfängt der PEP-Endpunkt 501 IP-Pakete von seiner lokalen Schnittstelle 220 (2). Nicht-TCP-IP-Pakete werden an die WAN-Schnittstelle 230 weitergeschickt (nach Bedarf) (2). TCP-IP-Pakete werden intern an den TSK 501b weitergeschickt. TCP-Segmente, die zu Verbindungen gehören, die nicht bandbreitenbedarfsreduziert werden, werden vom Spoofing-Kernel 501b zum Routing-Modul 501a zurückgeschickt, um unmodifiziert an die WAN-Schnittstelle 230 weitergeschickt zu werden. Für bandbreitenbedarfsreduzierte TCP-Verbindungen beendet der TCP-Spoofing-Kernel 501a die TCP-Verbindung lokal. TCP-Daten, die von einer bandbreitenbedarfsreduzierten Verbindung empfangen werden, werden vom Spoofing-Kernel 501a zum Backbone-Protokoll-Kernel 501c weitergegeben und dann auf der geeigneten Backbone-Protokollverbindung gemultiplext. Der Backbone-Protokoll-Kernel 501c stellt sicher, dass die Daten über das WAN zugestellt werden.
  • Für WAN-zu-Lokal-Verkehr (d.h. in Abwärtsrichtung) 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 (nach Bedarf) an die lokale Schnittstelle 220 (2) weitergeschickt. IP-Pakete, die an den Endpunkt 503 adressiert sind und die einen nächsten Protokoll-Header-Typ „PBP" aufweisen, werden zum Backbone-Protokoll-Kernel 503c weitergeschickt. Der Backbone-Protokoll-Kernel 503c extrahiert die TCP-Daten und schickt diese an den TCP-Spoofing-Kernel 503b für die Übertragung an die geeignete bandbreitenbedarfsreduzierte TCP-Verbindung weiter. Zusätzlich zum Transport der TCP-Daten wird die Backbone-Protokoll-Verbindung vom TCP-Spoofing-Kernel 501b verwendet, um Steuerinformationen zu seinem Peer-TCP-Spoofing-Kernel 503b im entfernten PEP-Endpunkt 503 zu schicken, um Verbindungseinrichtungen und Verbindungsbeendigungen zu koordinieren.
  • Eine Priorisierung kann an vier Punkten im System 500 innerhalb des Routings 501a und TSK 501b vom PEP-Endpunkt 501 und innerhalb des Routing 503a und TSK 503b vom PEP-Endpunkt 503 vorgenommen werden. In Aufwärtsrichtung werden Prioritätsregeln an die Pakete einzelner TCP-Verbindungen am Zugangspunkt zum TCP-Spoofing-Kernel 501b angewendet. Diese Regeln erlauben es dem Anwender, zu steuern, welche Anwendungen höheren oder niedrigen Prioritätszugang zu Spoofing-Ressourcen haben. Eine aufwärtsgerichtete Polarisierung wird ebenfalls durchgeführt, bevor die Pakete an das WAN weitergeschickt werden. Dies ermöglicht es dem Kunden, die relative Priorität von bandbreitenbedarfsreduzierten TCP-Verbindungen im Vergleich zu nicht-bandbreitenbedarfsreduzierten TCP-Verbindungen und Nicht-TCP-Verkehr zu steuern (ebenso wie die Steuerung der relativen Priorität dieser anderen Verkehrsarten in Beziehung zueinander). Auf der abwärtsgerichteren Seite wird die Priorisierung verwendet, um den Zugriff auf Pufferspeicherplatz und andere Ressourcen im PEP-Endpunkt 503 allgemein und im Hinblick auf TCP-Spoofing zu steuern.
  • An der Hub- (oder der lokalen) Site kann der PEP-Endpunkt 501 in einem Netzwerk-Gateway (z.B. einem IP-Gateway) gemäß einer Ausführungsform der vorliegenden Erfindung implementiert sein. An der entfernten Site kann der PEP-Endpunkt 503 in der Fern-Site-Komponente, z.B. einem Satellitentermial wie einem Multimedia-Relais, einem Multimedia-VSAT oder einem Personal Earth Station (PES) Remote, implementiert sein.
  • Die Architektur des Systems 500 stellt eine Reihe von Vorteilen bereit. Zunächst kann das TCP-Spoofing sowohl in Aufwärts- als auch in Abwärtsrichtung durchgeführt werden. Außerdem unterstützt das System das Spoofing des TCP-Verbindungsstarts und ein selektives TCP-Spoofing, bei dem nur der Bandbreitenbedarf von Verbindungen, die von einem Spoofing profitieren, tatsächlich reduziert wird. Ferner ermöglicht das System 500 die Priorisierung unter bandbreitenbedarfsreduzierten TCP-Verbindungen für den Zugriff auf TCP-Spoofing-Ressourcen (z.B. die verfügbare Bandbreite und den verfügbaren Pufferspeicherplatz). diese Priorisierung wird für alle Arten von Verkehr verwendet, die um Systemressourcen konkurrieren.
  • Im Hinblick auf die Backbone-Verbindung eignet sich das System 500 für die Anwendung in einem Satellitennetzwerk, wie dem WAN. Das heißt, das Backbone-Protokoll ist für die Satellitenanwendung optimiert, da Steuerblock-Ressourcenanforderungen minimiert sind, und eine wirksame Fehlerentdeckung für fallen gelassene Pakete bereitgestellt wird. Das System 500 stellt auch einen Feedback-Mechanismus bereit, um die maximale Pufferspeicherplatz-Ressourceneffizienz zu unterstützen. Ferner stellt das System 500 einen verringerten Bestätigungsverkehr durch Verwenden eines einzigen Backbone-Protokolls ACK zur Bestätigung der Daten von mehreren TCP-Verbindungen bereit.
  • 6 stellt den Fluss von IP-Paketen durch einen PEP-Endpunkt gemäß einer Ausführungsform der vorliegenden Erfindung dar. Wenn IP-Pakete an der lokalen LAN-Schnittstelle 220 empfangen werden, bestimmt der PEP-Endpunkt 210 (wie vom Entscheidungspunkt A dargestellt), ob die Pakete für einen Host bestimmt sind, der sich vor Ort befindet; falls dies der Fall ist, werden die IP-Pakete zur richtigen lokalen LAN-Schnittstelle 220 weitergeschickt. Falls die IP-Pakete für einen entfernten Host bestimmt sind, dann entscheidet der PEP-Endpunkt 210 am Entscheidungspunkt B, ob der Verkehr ein TCP-Segment ist. Falls der PEP-Endpunkt 210 bestimmt, dass die Pakete tatsächlich TCP-Segmente sind, dann bestimmt der TSK 280, ob der Bandbreitenbedarf der TCP-Verbindung reduziert werden soll. Falls der PEP-Endpunkt 210 bestimmt, dass die Pakete keine TCP-Segmente sind, dann verarbeitet der BPK 282 den Verkehr zusammen mit dem PK 284 und dem PSK 286 für die letztendliche Übertragung an das WAN. Es sei darauf hingewiesen, dass der BPK 282 keine nicht-bandbreitenbedarfsreduzierten IP-Pakete verarbeitet; d.h. die Pakete fließen direkt zum PD 284. Wie in 6 dargestellt, wird Verkehr, der von der WAN-Schnittstelle 230 empfangen wird, untersucht, um zu bestimmen, ob der Verkehr ein richtiges PBP-Segment (Entscheidungspunkt D) für den speziellen PEP-Endpunkt 210 ist; falls die Entscheidung positiv ausfällt, dann werden die Pakete zum BPK 282 und dann zum TSK 280 geschickt.
  • Die Routing-Unterstützung schließt ein Routing zwischen den Ports des PEP-Endpunkts 210 (2) ein, z.B. von einem Multimedia VASAT LAN-Port zu einem anderen. Architektonisch passen die Funktionen des TCP-Spoofing, der Priorisierung und der Pfadauswahl zwischen die IP-Routing-Funktion und das WAN. Die PEP-Funktion muss nicht auf IP-Pakete angewendet werden, die von lokalem Port zu lokalem Port innerhalb des gleichen PEP-Endpunkts 210 geführt werden. TCP-Spoofing, Priorisierung und Pfadauswahl werden auf IP-Pakete angewendet, die von einer lokalen PEP-Endpunktschnittstelle empfangen werden und die von der Routing-Funktion als für eine andere Site bestimmt bestimmt wurden.
  • 7 zeigt die Beziehung zwischen PEP-Endpunkten und PEP-Endpunktprofilen gemäß einer Ausführungsform der vorliegenden Erfindung. PEP-Parameter werden in erster Linie über einen Satz von Profilen 701 und 703 konfiguriert, die mit einem oder mehreren PEP-Endpunkten 705 assoziiert sind. In einem Ausführungsbeispiel werden PEP-Parameter auf einer PEP-Endpunktbasis konfiguriert, so als ob TCP-Spoofing global möglich wäre Diese Parameter werden in den PEP-Endpunktprofilen 701 und 703 konfiguriert. Es sei darauf hingewiesen, dass Parameter, die sich auf bestimmte PEP-Kernels beziehen, über andere Arten von Profilen konfiguriert werden können. Die Profile 701 und 703 sind ein Netzwerkverwaltungskonstrukt; intern verarbeitet ein PEP-Endpunkt 705 einen Satz Parameter, die über eine oder mehrere Dateien empfangen werden.
  • Sobald der PEP-Endpunkt 705 neue Parameter empfängt, vergleicht die Plattformumgebung die neuen Parameter mit den vorhanden Parametern, findet heraus, welche der PEP-Kernels von den Parameteränderungen beeinflusst werden und gibt dann die neuen Parameter an die beeinflussten Kernels weiter. In einer Beispielsumgebung werden alle Parameter dynamisch installiert. Mit Ausnahme von Parametern, die komponentenspezifisch sind (wie die IP-Adressen einer Komponente), können alle Parameter mit Default-Werten definiert werden.
  • Wie bereits erwähnt, kann der PEP-Endpunkt 210 in einer Reihe von verschiedenen Plattformen gemäß den verschiedenen Ausführungsformen der vorliegenden Erfindung implementiert werden. Diese Plattformen schließen ein IP-Gateway, ein Multimedia-Relais, einen Multimedia VSAT (Very Small Aperture Terminal) und eine Personal Earth Station (PES) Remote ein, wie jeweils in den 8–11 dargestellt. Im Allgemeinen definiert der PEP-Endpunkt 210, wie in 2 dargestellt, eine lokale LAN-Schnittstelle 220, durch welche Schnittstelle der PEP-Endpunkt 210 die IP-Hosts, die an der Site angesiedelt sind, miteinander verbindet. Eine WAN-Schnittstelle 230 ist eine Schnittstelle, durch die der PEP-Endpunkt 210 Verbindungen zu anderen Sites herstellt. Es sei darauf hingewiesen, dass eine WAN-Schnittstelle 230 physisch ein LAN-Port sein kann. Die 8–11 beschreiben nachstehend spezifische LAN- und WAN-Schnittstellen der verschiedenen PEP-Endpunktplattformen. Welche LAN- und WAN-Schnittstellen jeweils verwendet werden, hängt davon ab, welche Fern-Site-PEP-Endpunkte verwendet werden, welche Konfiguration der Hub und die Fern-Site-PEP-Endpunkte haben und welche Pfadauswahlregeln konfiguriert den können.
  • 8 zeigt die Schnittstellen des PEP-Endpunkts, der als ein IP-Gateway implementiert ist, gemäß einer Ausführungsform der vorliegenden Erfindung. Beispielsweise weist ein IP-Gateway 801 eine einzige lokale LAN-Schnittstelle auf, bei der es sich um eine Unternehmensschnittstelle 803 handelt. Das IP-Gateway 803 verwendet zwei WAN-Schnittstellen 805, um IP-Pakete von Fern-Site-PEP-Endpunkten zu empfangen und an diese zu senden: eine Backbone-LAN-Schnittstelle und eine Wide Area Access (WAA)-Lan-Schnittstelle.
  • Die Backbone-LAN-Schnittstelle 805 wird verwendet, um beispielsweise über ein Satelliten-Gateway (SGW) und eine VSAT-Outroute IP-Pakete an Fern-Site-PEP-Endpunkte zu senden. Eine VSAT-Outroute kann direkt von Multimedia-Relais (9) und Miltimedia-VSATs (10) empfangen werden (und ist der vorherrschende Pfad, der mit diesen Endpunkten verwendet wird); jedoch können IP-Pakete auch über eine VSAT-Outroute an ein PES Remote (11) geschickt werden.
  • 9 zeigt eine Multimedia-Relais-Implementierung eines PEP-Endpunkts gemäß einer Ausführungsform der vorliegenden Erfindung. Ein Multimedia-Relais weist zwei oder drei lokale LAN-Schnittstellen 903 auf. Zusätzlich weist das Multimedia-Relais 901 bis zu zwei WAN-Schnittstellen 905 auf, um IP-Pakete an Hub-Site-PEP-Endpunkte zu schicken: eine seiner LAN-Schnittstellen und eine PPP-Serienportschnittstelle, und vier oder fünf Schnittstellen zum Empfangen von IP-Paketen von Hub-Site-PEP-Endpunkten, einer VSAT-Outroute, allen seinen LAN-Schnittstellen und einer PPP-Serienport-Schnittstelle. Es sei darauf hingewiesen, dass eine PPP (Punkt-zu-Punkt-Protokoll)-Serienportschnittstelle und eine LAN-Schnittstelle im Allgemeinen nicht gleichzeitig verwendet werden.
  • Ein Multimedia-Relais 901 unterstützt die Verwendung aller seiner LAN-Schnittstellen 903, um gleichzeitig IP-Pakete von Hub-Site-Endpunkten zu senden und von diesen zu empfangen. Ferner unterstützt ein Multimedia-Relais 905 die Verwendung einer VADB (VPN Automatic Dial Backup)-Serienportschnittstelle zum Senden und Empfangen von IP-Paketen an die und von den Hub-Site-PEP-Endpunkten.
  • 10 zeigt eine Multimedia-VSAT-Implementierung des PEP-Endpunkts gemäß einer Ausführungsform der vorliegenden Erfindung. Ein Multimedia-VSAT 1001 weist in einem Ausführungsbeispiel zwei lokale LAN-Schnittstellen 1003 auf. Es kann Unterstützung für eine oder mehrere lokale PPP-Serienportschnittstellen verwendet werden. Der Multimedia-VSAT 1001 weist zwei WAN-Schnittstellen 1005 zum Versenden von IP-Paketen zu Hub-Site PEP-Endpunkten auf: eine VSAT-Inroute und eine ihrer LAN-Schnittstellen. Der Multimedia-VSAT 1001 weist somit drei Schnittstellen zum Empfangen von Daten von Hub-Site-PEP-Endpunkten auf, die VSAT-Outroute und ihre beiden LAN-Schnittstellen 1003. Ein Multimedia VSAT 1003 kann die gleichzeitige Verwendung seiner beiden LAN-Schnittstellen 1003 zum Senden und Empfangen von IP-Paketen an die und von den Hub-Site-PEP-Endpunkte(n) unterstützen. Der Multimedia VSAT 1003 unterstützt ferner die Verwendung einer VADB-Serienportschnittstelle zum Senden und Empfangen von IP-Paketen an die und von den Hub-Site-PEP-Endpunkte(n).
  • 11 zeigt eine PES-Remote-Implementierung eines PEP-Endpunkts gemäß einer Ausführungsform der vorliegenden Erfindung. Ein PES-Remote 1101 kann eine lokale LAN-Schnittstelle und/oder mehrere lokale IP (z.B. PPP, SLIP usw.) Serienportschnittstellen aufweisen, die zusammen als LAN-Schnittstellen 1103 bezeichnet werden. Die jeweiligen LAN-Schnittstellen 1103 hängen von der speziellen PES-Remote-Plattform ab. Der PES-Remote 1101 weist in einem Ausführungsbeispiel bis zu fünf WAN-Schnittstellen 1105 zum Senden von IP-Paketen an Hub-Site-Endpunkte, eine ISBN-Inroute, eine LAN-Schnittstelle, eine VADB-Serienportschnittstelle, eine Frame-Relais-Serienportschnittstelle und eine IP-Serienport-Schnittstelle, und bis zu fünf vorhandene Schnittstellen zum Empfangen von IP-Paketen von Hub-Site-PEP-End punkten auf: eine ISBN-Outroute, eine LAN-Schnittstelle, eine VADB-Serienportschnittstelle, eine Frame-Relais-Serienportschnittstelle und eine IP-Serienportschnittstelle auf. Die physische Frame Relais-Serienportschnittstelle kann mehrere permanente virtuelle Verbindungen bzw. Permanent Virtual Circuits (PVCs) unterstützen, von denen einige zu lokalen Schnittstellen 1103 äquivalent sind und von denen einige WAN-Schnittstellen sind.
  • 12 zeigt den Fluss von TCP-Spoofing-Puffern durch einen PEP-Endpunkt gemäß einer Ausführungsform der vorliegenden Erfindung. In diesem Bespiel sind sechs logische Puffer-Pools mit dem Empfangen, Verarbeiten und Weitersenden von TCP-Segmenten für bandbreitenbedarfreduzierte TCP-Verbindungen befasst: ein LAN-zu-WAN (L2W)-Puffer-Pool 1201; ein WAN-zu-LAN (W2L)-Puffer-Pool 1203; ein LAN-Empfangs- (LAN Rx-) Puffer-Pool 1205; ein LAN-Übermittlungs- (LAN Tx-) Puffer-Pool 1207; ein WAN-Empfangs- (WAN Rx-) Puffer-Pool 1209 und ein WAN-Übermittlungs- (WAN Tx-) Puffer-Pool 1211.
  • Die in 12 dargestellten Schnittstellen und Puffer-Pools sind logische Instanzen. Es sei darauf hingewiesen, dass der in 12 dargestellte Pufferfluss in manchen Fällen zum Zwecke der Erläuterung vereinfacht ist; beispielsweise kann „ein Puffer" aus mehreren physischen Puffern bestehen. Physisch können mehr als eine LAN- oder WAN-Schnittstelle vorhanden sein, und in manchen Fällen kann für manche Plattformen die gleiche physische Schnittstelle sowohl als LAN-Schnittstelle 1213 als auch als WAN-Schnittstelle 1215 verwendet werden. Die Puffer-Pools 1201, 1203, 1205, 1207, 1209 und 1211 sind insofern logisch, als der gleiche physische Puffersatz verwendet werden kann, um mehr als einen der Puffer-Pools zu implementieren, entweder um die Implementierung zu erleichtern oder weil die LAN- und WAN-Schnittstellen 1213, 1215 die gleiche physische Schnittstelle sind. Einzelheiten über die plattformspezifische physische Implementierung von logischen Puffer-Pools 1201, 1203, 1205, 1207, 1209 und 1211 sind nachstehend beschrieben.
  • Wenn ein IP-Paket von dem lokalen LAN ankommt, empfängt die LAN-Schnittstelle 1213 das Paket in einem Pufferspeicher vom LAN Rx-Puffer-Pool 1205 und gibt das Paket an die Plattformumgebung 210 weiter. Die Plattformumgebung 210 kopiert das IP-Paket aus dem LAN Rx-Puffer 1205 in einen LAN-zu-WAN-Puffer 1201 und schickt dann den LAN Rx-Puffer 1205 zur LAN-Schnittstelle 1213 zurück. In einer Plattform, wo der LAN-Rx-Puffer 1205 und der LAN-zu-WAN-Puffer 1201 physisch identisch sind, kann die Umgebung 210 das Kopieren vermeiden und einfach einen LAN-zu-WAN-Puffer 1201 gegen den LAN Rx-Puffer 1205 tauschen. Ob nun tatsächlich eine Kopie erstellt wird oder nicht, falls kein LAN-zu-WAN-Puffer verfügbar ist, wird das IP-Paket verworfen (durch Zurückschicken des ursprünglichen LAN Rx-Puffers 1205 an die LAN-Schnittstelle 1213) und muss von dieser auf die gleiche Weise aufgenommen werden als würde das IP-Paket das LAN durchlaufen.
  • Die Umgebung 210 gibt IP-Pakete, die bandbreitenbedarfreduzierte TCP-Segmente enthalten, an den TCP-Spoofing-Kernel 280 weiter (wenn ein TCP-Spoofing möglich ist). Der LAN-zu-WAN-Puffer 1201, der IP-Pakete handhabt, die keine TCP-Segmente enthalten, ist nachstehend beschrieben. Die Umgebung 210 erkennt ein TCP-bandbreitenbedarfsreduziertes TCP-Segmente durch die Anwesenheit eines CCB für das Segment. Die Umgebung 210 gibt auch TCP <SYN>-Segmente an den TSK 280 weiter, um zu bestimmen, ob der Bandbreitenbedarf einer neuen Verbindung reduziert werden soll. Falls das TCP <SYN>-Segment nicht zu einer TCP-Verbindung gehört, deren Bandbreitenbedarf reduziert werden soll, schickt der TSK 280 das IP-Paket mit einem Hinweis, das TCP-Segment ohne Bandbreitenbedarfsreduzierung weiterzuschicken, zurück zur Umgebung 210. Es gibt auch Umstände, unter denen der TSK 280 ein TCP-Segment zurückschickt, um es ohne Bandbreitenbedarfsreduzierung weiterschicken zu lassen, wenn ein CCB für die TCP-Verbindung vorhanden ist. Falls das TCP-Segment zu einer TCP-Verbindung gehört, deren Bandbreitenbedarf gerade reduziert wird (oder gleich reduziert werden soll), verarbeitet der TSK 280 das TCP-Segment und schickt dann entweder den Inhalt des TCP-Segments zu seinem TSK 280-Peer oder verwirft ihn und schickt den Puffer des Segments zur Plattformumgebung 210 zurück. Die Plattformumgebung 210 schickt ihrerseits den Puffer zum LAN-zu-WAN-Puffer-Pool zu rück. In einigen Fällen muss der TSK 280 das empfangene TCP-Segment nicht weiterschicken, sondern muss nur eine TSK-Nachricht (als Folge des Empfangs des TCP-Segments) an seinen TSK-Peer schicken. Wenn beispielsweise ein TCP <SYN>-Segment empfangen wird, wird das <SYN>-Segment nicht an den TSK-Peer weitergeschickt, sondern es kann sein, dass eine Connection Request-Nachricht an den TSK-Peer geschickt werden muss). Wenn dies der Fall ist, benutzt der TSK 280 einfach den Puffer erneut, indem das TCP-Segment empfangen wurde, statt den Puffer des TCP-Segments zu verwerfen und dann um einen neuen Puffer zu bitten, um die zu versendende TSK-Nachricht zu erzeugen.
  • In Fällen, wo der TSK 280 eine TSK-Nachricht an seinen Peer asynchron zum Empfang eines TCP-Segments verschicken muss, fordert der TSK 280 einen LAN-zu-WAN-Puffer 1201 von der Plattformumgebung 210 an und nutzt diesen Puffer 1201, um die Nachricht zu konstruieren. Um eine Daten- oder Steuer-TSK-Nachricht an seinen TSK-Peer zu schicken, gibt der TCP-Spoofing-Kernel 280 den Puffer der Nachricht (zusammen mit einem Hinweisen, welche Backbone-Verbindung zum Senden der Nachricht benutzt werden soll) an den Backbone Protocol Kernel 282 weiter. Sobald eine Nachricht an den BPK 282 geschickt wurde, übernimmt der BPK 282 das Eigentum bzw. die Inhaberschaft über den LAN-zu-WAN-Puffer 1201 der Nachricht. TSK-Nachrichten werden vom BPK 282 zu seinem BPK-Peer als PBP-Segmente geschickt. Um ein PBP-Segment zu verschicken, gibt der BPK 282 das Segment als IP-Paket an die Plattformumgebung 210 weiter, um es an die geeignete WAN-Schnittstelle 1215 zu übermitteln. Die Umgebung 210 gibt das IP-Paket an die geeignete WAN-Schnittstelle 1215 weiter, wobei der LAN-zu-WAN-Puffer 1201 in einen WAN Tx-Puffer 1211 kopiert wird.
  • Weil der BPK 282 für die garantierte Zustellung von TSK-Nachrichten sorgen muss, muss der BPK 282 jede TSK-Nachricht, die er übermittelt, zurückholen und für eine potentielle erneute Sendung aufbewahren. Daher muss die Plattformumgebung 210 (wenn über eine Flagge bzw. ein Flag, das mit der Schnittstelle verwendet wird, aufgefordert) ein an sie geschicktes IP-Paket nach dessen Übermittlung zurück zum BPK 282 schicken. Es sei darauf hingewiesen, dass, wenn die Umgebung 210 IP-Pakete für eine bestimmte Backbone-Verbindung zum BPK 282 zurückschickt, die Umgebung die IP-Pakete in der Reihenfolge, in der sie sie vom BPK 282 erhalten hat, an diesen zurückschicken muss. Gemäß einem Ausführungsbeispiel kann dies automatisch durch Ausführen einer sofortigen Kopie in einen WAN Tx-Puffer geschehen. Alternativ dazu kann dies durch Verwendung eines Queuing-Mechanismus geschehen, um sicherzustellen, dass die Pakete in der richtigen Reihenfolge zurückgeschickt werden. In einer Plattform 210, die einen LAN-zu-WAN-Puffer 1201 und einen WAN Tx-Puffer 1211 nutzt, die kompatibel sind, muss die Umgebung 210 auch gar keine Kopie erstellen, falls der BPK 282 das IP-Paket nicht zurückfordert. Falls die Puffer 201 und 1211 kompatibel sind, kann der zugeordnete WAN Tx-Puffer 1211 zum LAN-zu-WAN-Puffer-Pool 1201 zurückgeschickt werden, wobei der LAN-zu-WAN-Puffer 1201 als WAN Tx-Puffer 1211 weitergeschickt wird.
  • Der Backbone Protocol Kernel 282 kann auch Segmente erzeugen, die an seinen BPK-Peer geschickt werden sollen, ohne eine Nachricht vom TSK 280 zu empfangen, z.B. um eine Bestätigung für empfangene PBP-Segmente zu verschicken. Um ein solches Segment zu verschicken, ordnet der BPK 282 einen Puffer aus dem LAN-zu-WAN-Puffer-Pool 1201 (über die Plattformumgebung 210) zu, konstruiert das PBP-Segment, das er senden muss und schickt dann das Segment als IP-Paket auf die gleiche Weise wie er PBP-Segmente, die TSK-Nachrichten enthalten, versendet, an die Plattformumgebung 210. Es sei darauf hingewiesen, dass die Zuordnung von Puffern, um PBP-Bestätigungen zu verschicken, unabhängig von dem Empfang von PBP-Segmenten stattfindet. Der BPK 282 verarbeitet auch dann jedes empfangene PBP-Segment, wenn kein LAN-zu-WAN-Puffer 1201 verfügbar ist, um eine Antwort an das Segment zu schicken. Das Fehlen eines Puffers, um eine Antwort zu verschicken, wird einfach auf die gleiche Weise gehandhabt, als wenn das Segment erfolgreich übermittelt worden wäre, aber beim Durchgang durch das WAN verloren gegangen wäre. Nachdem der Backbone-Kernel mit einem von ihm übertragenen Segment fertig ist, z.B. eine Bestätigung für das Segment von seinem BPK-Peer erhalten hat, gibt er den Puffer des Segments an den LAN-zu-WAN-Puffer-Pool zurück.
  • Der Verlust eines empfangenen oder übertragenen TCP-Segments oder PBP-Segments, weil kein Puffer verfügbar ist, ist nicht kritisch. Das verlorene IP-Paket kann auf die gleiche Weise wiedererlangt werden als wenn das IP-Paket während des Durchgangs durch das LAN oder WAN verloren gegangen wäre. Das Unvermögen, eine TSK-Nachricht zu senden, weil kein Puffer zur Verfügung steht, ist jedoch eine ernstere Situation. Der TSK 280 nimmt an, dass Nachrichten in der Leitung, die zwischen ihm und seinem Peer durch das PEP-Backbone-Protokoll bereitgestellt werden, nicht verloren gehen können. Daher ist ein spezielles Handeln erforderlich, wenn der TSK 280 versucht, eine TSK-Nachricht von Grund auf zu erzeugen und dies nicht tun kann. In manchen Fällen, beispielsweise beim Erzeugen einer TSK-Peer-Parameternachricht, besteht die angemessene Reaktion im Starten eines Zeitnehmers und dem erneuten Versuch, die Nachricht zu versenden, wenn der Zeitnehrmer abgelaufen ist. In anderen Fällen, beispielsweise bei Unfähigkeit, eine Connection Terminated-Nachricht zu versenden, könnte die angemessene Reaktion die Ignorierung des Ereignisses sein, das ein Versenden der CT-Nachricht erfordert hat. Wenn die Nachricht beispielsweise aufgrund eines Time-Out verschickt wird, kann der Zeitgeber mit irgendeinem kleinen Wert erneut gestartet werden und neu verarbeitet werden, wenn dieser wieder abgelaufen ist.
  • Wenn ein IP-Paket vom WAN ankommt, empfängt die WAN-Schnittstelle 1215 das Paket in einem Puffer vom WAN Rx-Puffer-Pool 1209 und gibt es an die Plattformumgebung 210 weiter. Die Plattformumgebung 210 kopiert das IP-Paket aus dem WAN-Rx-Puffer 1209 in einen WAN-zu-LAN-Puffer 1203 und schickt dann den WAN Rx-Puffer 1209 an die WAN-Schnittstelle 1215 zurück. In einer Plattform 210, in der der WAN Rx-Puffer 1209 und der WAN-zu-LAN-Puffer 1203 physisch identisch sind, kann die Umgebung 210 das Kopieren vermeiden und einfach einen WAN-zu-LAN-Puffer 1203 gegen den WAN Rx-Puffer 1209 tauschen. Ob es nun zu einer tatsächlichen Kopie kommt oder nicht, das IP-Paket wird verworfen (durch Zurückschicken des originalen WAN Rx-Puffers 1209 an die WAN-Schnittstelle), wenn kein WAN-zu-Lan-Puffer verfügbar ist, und muss auf die gleiche Weise wiederhergestellt werden als wenn das IP-Paket beim Durchqueren des WAN verloren gegangen wäre. Die Umgebung 210 gibt alle IP-Pakete, die PBP-Segmente (adressiert an diesen PEP-Endpunkt 210) enthalten, an den Backbone Protocol Kernel 282 zurück. Der WAN-zu-LAN-Puffer, der andere Arten von IP-Paketen handhabt, ist nachstehend beschrieben.
  • Wie der BPK mit PBP-Segmenten umgeht, hängt von der Art des PBP-Segments ab. Was den Umgang mit Puffern betrifft, so gibt es zwei Arten von PBP-Segmenten: (1) PBP-Segmente, die sofort verarbeitet und verworfen werden können, d.h. PBP-Steuersegmente; und (2) PBP-Segmente, die zum TCP-Spoofing-Kernel 280 weitergeschickt werden müssen, d.h. TSK-Nachrichten. Für ein PBP-Steuersegment, z.B. ein PBP-Segment, das verwendet wird, um Backbone-Verbindungen einzurichten, kann der Backbone Protocol Kernel 282 jede vom Segment benötigte Aktion durchführen und den Puffer des Segments dann zum WAN-zu-LAN-Puffer-Pool 1203 zurückschicken. Der BPK 282 schickt empfangene TSK-Nachrichten an den TCP-Spoofing Kernel 280. Sobald der BPK 282 eine Nachricht an den TSK 280 geschickt hat, übernimmt der TSK 280 die Inhaberschaft über den WAN-zu-LAN-Puffer 1203 der Nachricht. Der Umgang des TSK mit dem WAN-zu-LAN-Puffer ist nachstehend beschrieben. Es sei darauf hingewiesen, dass ein Segment, das eine TSK-Nachricht enthält, nicht unbedingt sofort an den TSK 280 weitergeschickt werden muss. Segmente mit der falschen Reihenfolge werden vom BPK 282 in einer Resequenzierungs-Warteschlange gehalten, während der BPK 282 auf die fehlenden Elemente wartet. (Der BPK muss TSK-Nachrichten in der richtigen Reihenfolge an den TCP-Spoofing-Kernel schicken). Außerdem erzeugt der Backbone Protocol Kernel keine Nachrichten, um Informationen (z.B. Backbone-Verbindungs-Resets) an den TCP-Spoofing-Kernel zu schicken. Jede Information, die der BPK 282 zum TSK 280 weiterschicken muss, wird anhand einer prozeduralen Schnittstelle verschickt. Daher muss der BPK 282 niemals einen WAN-zu-LAN-Puffer 1203 für sich selbst reservieren.
  • Der TCP-Spoofing-Kernel 280 empfängt zwei Arten von Nachrichten von seinem TSK-Peer: Steuernachrichten (z.B. Connection Request-Nachrichten) und Datennachrichten (z.B. TCP-Data-Nachrichten). Beide Nachrichtenarten können in manchen Fällen sofort von der TSK 280 fallen gelassen werden (beispielsweise nach Empfang einer TCP-Nachricht für eine Verbindung, die nicht mehr besteht). Dies wird dadurch bewerkstelligt, dass der Puffer der Nachricht einfach zum WAN-zu-LAN-Puffer-Pool 1203 zurückgeschickt wird. Im Allgemeinen ist jedoch eine Verarbeitung für eine Nachricht, die von einem TSK-Peer erhalten wird, notwendig. Steuernachrichten können die Erzeugung eines entsprechenden TCP-Segments, das an einen lokalen Host geschickt wird, erfordern. Beispielsweise hat der Empfang einer Connection Request-Nachricht im Allgemeinen zur Folge, dass ein TCP <SYN>-Segment an einen lokalen Host geschickt wird. Der Empfang einer Connection Established-Nachricht führt jedoch nicht dazu, dass ein TCP <SYN,ACK>-Segment zu einem lokalen Host geschickt wird, wenn der TSK 280 das <SYN,ACK>-Segment bereits verschickt hat. Wenn eine Steuernachricht verlangt, dass ein TCP-Segment an einen lokalen Host geschickt wird, speichert der TSK 280 sämtliche Informationen, die er benötigt, aus der Steuernachricht und nutzt dann den WAN-zu-LAN-Puffer 1203 der Steuernachricht, um das TCP-Segment zu konstruieren, das versendet werden muss. Abgesehen davon, dass sie effizienter ist, vermeidet die Wiederverwendung des WAN-zu-LAN-Puffers 1203 Fehlerszenarios, wo kein zusätzlicher WAN-zu-LAN-Puffer 1203 für das TCP-Segment, das erzeugt werden muss, zur Verfügung steht. Für eine Datennachricht muss der TCP-Spoofing-Kernel zuerst die TSK-Nachricht in ein TCP-Datensegment umwandeln. Dies wird in erster Linie durch Ersetzen der PBP- und TSK-Puffer-Header mit einem geeigneten TCP-Header 1515 unter Verwendung des nachstehend beschriebenen Mechanismus bewerkstelligt.
  • Nachdem der TCP-Spoofing-Kernel 280 eine TSK-Nachricht in ein TCP-Segment umgewandelt hat, schickt der TSK 280 das TCP-Segment an einen lokalen Host, indem er das Segment als IP-Paket an die Plattformumgebung 210 zur Übertragung an die geeignete LAN-Schnittstelle 1213 schickt. Die Umgebung 210 schickt das IP-Paket zur Übertragung an die LAN-Schnittstelle 1213; dies wird durch Zuordnen eines LAN Tx-Puffers 1207 und anschließendes Kopieren des IP-Pakets aus dem WAN-zu-LAN-Puffer 1203 in den LAN-Tx-Puffer 1207 bewerkstelligt. Eine Kopie wird erstellt, weil der TSK 280 für eine garantierte Zustellung der TCP-Datensegmente sorgen muss und daher viele der TCP-Datensegmente, die der TSK 280 überträgt, für eine mögliche Neuübertragung zurückholen und halten muss. Daher schickt die Umgebung 210 (wenn über ein mit der Schnittstelle verwendetes Flag aufgefordert) die IP-Pakete, die ihr zugeschickt wurden, zu TSK 280 zurück, nachdem diese Pakete übermittelt wurden. Das Kopieren des IP-Pakets in einen LAN Tx-Puffer 1207 erlaubt es der Umgebung 210, dies sofort durchzuführen. Falls die Umgebung 210 keinen LAN Tx-Puffer 1207 zuordnen kann, um das IP-Paket in diesen zu kopieren, muss die Umgebung 210 das IP-Paket zum TSK 280 zurückschicken, als ob das IP-Paket übermittelt worden wäre. Der TSK 280 gleicht diesen Fehler dann auf die gleiche Weise aus als wenn das Paket beim Durchgang durch das lokale LAN verloren gegangen wäre. Es sei darauf hingewiesen, dass, wenn die Umgebung 210 IP-Pakete für eine bestimmte Verbindung an den TSK 280 zurückschickt, die Umgebung 210 die IP-Pakete in der Reihenfolge, in der sie ihr vom TSK 280 zugeschickt wurden, an den TSK 280 zurückschicken muss. Die sofortige Kopie macht die Erfüllung dieser Forderung einfach.
  • Der TCP-Spoofing-Kernel 280 kann auch TCP-Segmente erzeugen, die zu einem lokalen Host geschickt werden sollen, ohne eine Nachricht von seinem TSK-Peer zu empfangen, z.B. um eine Bestätigung für empfangene TCP-Datensegmente zu verschicken. Um ein solches Segment zu versenden, reserviert der TSK 280 einen Puffer von einem WAN-zu-LAN-Puffer-Pool 1203, konstruiert das TCP-Segment, das der TSK 280 versenden muss und schickt dann das Segment auf die gleiche Weise, wie er TCP-Segmente, die von einer TSK-Nachricht erzeugt werden, die er von seinem TSK-Peer empfangen hat, als IP-Paket an die Plattformumgebung 210. Es sei darauf hingewiesen, dass die Reservierung von Puffern, um TCP-Datenbestätigungen zu versenden, unabhängig vom Empfang von TCP-Segmenten abläuft. Der TSK verarbeitet auch dann alle empfangenen TCP-Segmente, einschließlich von Datensegmenten, wenn kein WAN-zu-LAN-Puffer verfügbar ist, um eine Antwort auf das Segment zu schicken. Das Fehlen eines Puffers, um eine Antwort zu senden, wird einfach auf dieselbe Weise überwunden als ob das Segment erfolgreich übertragen worden wäre, aber beim Durchgang durch das LAN verloren gegangen wäre. Nachdem der TCP-Spoofing-Kernel mit einem Segment, das er übertragen hat, fertig ist, z.B. eine Bestätigung für das Segment vom lokalen Host empfangen hat, schickt er den Puffer des Segments zum WAN-zu-LAN-Puffer-Pool zurück.
  • 13 zeigt ein Diagramm des Puffer-Managements für nicht-bandbreitenbedarfsreduzierte TCP-Verbindungen und für Nicht-TCP (z.B. UDP)-Verkehr gemäß der vorliegenden Erfindung. Das Puffer-Management im Fall ohne Reduzierung des Bandbreitenbedarfs ähnelt dem Puffer-Management für bandbreitenbedarfsreduzierte TCP-Verbindung, ist aber viel einfacher. Wie in 13 dargestellt, kopiert in der LAN-nach-WAN-Richtung die Plattformumgebung 210 empfangene IP-Pakete aus LAN Rx-Puffern 1205 in LAN-zu-WAN-Puffer 1201. Nicht-TCP-IP-Pakete werden direkt an die WAN-Schnittstelle 1215 weitergeschickt, ohne durch den TCP-Spoofing-Kernel oder den Backbone Protocol Kernel fließen zu müssen. Nicht-bandbreitenbedarfsreduzierte TCP-IP-Pakete werden wie Nicht-TCP-IP-Pakete weitergeschickt, nachdem der TSK 280 sie „zurückweist". (Falls das Spoofing global nicht möglich ist, macht sich die Umgebung 210 nicht die Mühe, die TCP-IP-Pakete durch den TSK 280 zu schicken.) In der Richtung von WAN nach LAN ist das Verfahren ähnlich. Die Plattformumgebung 210 kopiert empfangene IP-Pakete aus WAN Rx-Puffern 1209 in WAN-zu-LAN-Puffer 1203 und schickt dann, bei allen IP-Paketen, die keine PBP-IP-Pakete sind, die eine der IP-Adressen der Plattform als Zieladresse haben, die Pakete an die (geeignete) LAN-Schnittstelle 1213, wobei sie die IP-Pakete in LAN Tx-Puffer 1207 kopiert. In einigen Plattformen kann es möglich sein, dass die Plattformumgebung 210 die IP-Pakete direkt aus WAN Rx- in LAN Tx-Puffer kopiert. Diese Pakete müssen nicht von einem PEP-Kernel verarbeitet werden.
  • Die Backbone-Verbindung, die mit einem Puffer assoziiert ist, wird im Puffer gespeichert. Wenn keine Backbone-Verbindung mit dem Puffer assoziiert ist, wird ein Wert 0 × FFFF verwendet. Zum Zwecke der Fehlerbeseitigung (und um den Pufferbehandlungs-Code symmetrisch zu halten) kann die Plattformumgebung 210 die Zahl der aktuell zugeordneten Puffer, die mit „Backbone-Verbindung" 0 × FFFF assoziiert sind, verfolgen.
  • 14 ist ein Diagramm eines Grundformats des Puffers, der verwendet wird, um die PEP-Funktion zu implementieren, gemäß einer Ausführungsform der vorliegenden Erfindung. Ein Puffer 1400 schließt einen Puffer-Header 1401 ein, der plattformspezifische Pufferfelder enthält, falls solche Felder vorhanden sind. Das Format (und selbst die Existenz) dieser Felder ist nur der Plattformumgebung 210 bekannt. An den plattformspezifischen Puffer-Header 1401 schließt sich ein allgemeiner PEP-Puffer-Header 1403 an, der in einem Ausführungsbeispiel eine Länge von etwa 30 bis 44 Byte aufweist. Die Felder in diesem Header 1403 sind den PEP-Kernels bekannt und werden von diesen genutzt. Der Puffer 1400 schließt auch einen Abschnitt ein, der für das IP-Paket 1405 vorgesehen ist, und der zusätzlich zum allgemeinen PEP-Puffer-Header 1403 den „Nutzinhalt" des Puffers 1400 darstellt.
  • Die Puffer 1400 werden über einen Zeiger auf den Anfang des allgemeinen PEP-Puffer-Headers 1401 von der Umgebung 210 zu einem Kernel weitergegeben, von einem Kernel zu einem anderen Kernel und von einem Kernel zur Umgebung 210. Etwaige Zeigeranpassungen, die nötig sind, um einem plattformspezifischen Puffer-Header 1401 gerecht zu werden, werden von der Plattformumgebung 210 vorgenommen.
  • Die Plattformumgebung 210 stellt gemäß einem Ausführungsbeispiel den Aufgabenkontext bereit, in dem die PEP-Kernels arbeiten. Unter dem Gesichtspunkt des plattformspezifischen Puffer-Managements ist daher die Plattformumgebung 210 der ausdrückliche Inhaber aller Puffer, die der Verwendung für die PEP-Funktion zugeordnet sind. Puffer-Behandlungsformalitäten in Bezug auf (explizite) Inhaberschaft über die Puffer (falls eine für eine bestimmte Plattform existiert) tauchen an dem Punkt auf, wo die Plattformumgebung 210 einen Puffer von außerhalb des PEP-Kontext empfängt oder dorthin schickt. Innerhalb des Kontexts der Aufgabe der Plattformumgebung 210 wird angenommen, dass ein Puffer von dem Kernel innegehabt wird, der ihn gerade besitzt. Es muss jedoch kein formaler Pufferinhaberschaftstransfer stattfinden. Der Inhaberschaftstransfer kann implizit sein. Wenn beispielsweise der TCP-Spoofing-Kernel 280 eine TSK-Nachricht an den Backbone Protocol Kernel 282 für eine Übertragung über eine Backbone-Verbindung sendet, übergibt der TSK 280 die Inhaberschaft am Puffer implizit an den BPK 282. In einem Ausführungsbeispiel darf nur der implizite Inhaber eines Puffers auf den Puffer zugreifen. Abgesehen von dem Fall, in dem der spezifische Kontext einer Schnittstelle so definiert ist, dass er es zulässt, sollte ein Kernel nicht annehmen, dass Felder in einem Puffer nicht verändert wurden, falls der Kernel einen Puffer außerhalb seines eigenen Kontexts weitergibt und diesen dann zurückbekommt.
  • 15 zeigt ein Diagramm eines IP-Pakets, das in dem System von 1 verwendet wird. Ein IP-Paket 1500 weist einen IP-Header 1501 (wie in EETF RFC 791 definiert, das hierin in seiner Gesamtheit durch Bezugnahme aufgenommen ist), gefolgt von einem Nutzinhalt 1503 auf. Der IP-Header 1501 weist im Allgemeinen eine Länge von 20 Byte auf. Der IP-Header 1501 kann länger als 20 Byte sein, wenn IP-Header-Optionen verwendet werden.
  • Die Größe des IP-Paket-Nutzinhalts 1503 wird durch die Größe der Maximum Transmission Unit (MTU) des Netzwerks, das verwendet wird, um das IP-Paket zu befördern, bestimmt. Beispielsweise ist die MTU einer Ethernet-Verknüpfung 1500 Byte, was einen IP-Paketnutzinhalt 1503 von bis zu 1480 Byte unterstützt. Wie in 15 dargestellt, trägt die IP-Paketnutzlast im Allgemeinen eine „Nachrichteneinheit" eines Protokolls einer höheren Schicht. Diese Protokolle höherer Schichten können User Datagram Protocol (UDP) 1505, TCP 1507 und das PEP-Merkmal PBP 1509 einschließen. UDP 1505 schließt einen UDP-Header 1511 und einen Nutzinhalt 1513 (der die Daten enthält) ein. Auf ähnliche Weise stellt der TCP 1507 einen TCP-Header 1515 und einen Datenabschnitt 1517 bereit. In dem PBP 1509-Format sind beispielsweise eine TSK-Nachricht 1518 mit einem TSK-Header 1519 und Daten 1521 untergebracht. Die TSK-Nachricht 1518 stellt ihrerseits den Nutzinhalt, oder die Daten, 1523 eines PBP-Segments dar. Das PBP 1509 schließt auch einen Header 1525 ein.
  • Die Puffer werden zwischen der Umgebung 210 und den PEP-Kernels als IP-Pakete weitergegeben. An der TSK/BPK-Schnittstelle werden Puffer zwischen TSK 280 und BPK 282 als TSK-Nachrichten weitergegeben. Der gemeinsame PEP-Puffer-Header 1403, der nachstehend ausführlicher beschrieben ist, wird verwendet, um die geeignete Puffer-Nutzlast an jede Schnittstelle weiterzugeben.
  • 16 zeigt ein Diagramm eines Formats des gemeinsamen PEP-Puffer-Headers gemäß einer Ausführungsform der vorliegenden Erfindung. Der gemeinsame Puffer-Header 1403 hat drei Zwecke: (1) um einen Mechanismus zum Weitergeben von Puffern zwischen einer Umgebung 210 und den PEP-Kernels und zwischen den verschiedenen PEP-Kernels selbst bereitzustellen; (2) um einen Mechanismus bereitzustellen, der die Fähigkeit für IP, TCP, PBP und TSK-Header, zu wachsen (und zu schrumpfen), ohne eine Verschiebung der Daten in einem IP-Paket zu benötigen, unterstützt, wodurch die Leistung durch Vermeiden von Datenkopien deutlich verbessert wird; und (3) um Platz für inhaberspezifische Pufferfelder zu schaffen (die Notwendigkeit, separate Pufferdatenstrukturen zuzuordnen, abzuschaffen). Es sei darauf hingewiesen, dass die Grenze zwischen dem inhaberspezifischen „Header" und dem Header-Wachstums-„Header" etwas willkürlich ist, da der Kernel, falls erforderlich, inhaberspezifische Felder in den Header-Wachstumsplatz (und umgekehrt) eingeben kann, falls sie passen. Dies kann jedoch nur innerhalb eines Kernels passieren. Die Grenze zwischen den beiden „Headers" muss von einem Kernel respektiert werden, wenn er einen Puffer zur Umgebung oder zu einem anderen Kernel weitergibt.
  • Der allgemeine PEP-Puffer-Header 1403 schließt ein Flags+Offset-Feld 1601 ein, das (beispielsweise) 2 Byte lang ist, wodurch 4 Bit einem Flags-Feld 1601a zugeordnet sind und die restlichen 12 Bit für das Nutzinhalt-Offset-Feld 1601 bereitgestellt sind. Was das Flags-Feld 1601a betrifft, so hält das erste (bedeutendste Bit) Flag-Bit das Richtungs- (DIR-) Flag. Das Richtungs-Flag zeigt an, ob dieser spezielle Puffer in der LAN-zu-WAN-Richtung (DIR = 0) oder der WAN-zu-LAN-Richtung (DIR = 1) zugeordnet wurde. Das letzte (unbedeutendste Bit) Flag-Bit ist für die Verwendung durch die Plattformumgebung 210 reserviert. Die beiden mittleren Flag-Bits sind reserviert. Was das Nutzinhalt-Offset-Feld 1601b betrifft, so spezifiziert das Feld 1601b in Bytes den aktuellen Stand des Puffer-Nutzinhalts (z.B. des IP-Pakets). Der Header-Wachstums platz im Puffer ermöglicht es, diesen Wert sowohl nach oben als auch nach unten anzupassen. Es muss jedoch darauf geachtet werden, den Nutzinhalt-Offset bzw. -Versatz nicht über die Grenze zwischen dem inhaberspezifischen Feld 1605 und dem Header-Wachstumsfeld 1607 hinaus zu verändern.
  • Das Verbindungs-Handle-Feld 1603, das 2 Byte lang ist, spezifiziert den Handle der Backbone-Verbindung, dem dieser Puffer zugeordnet wurde. Der Verbindungs-Handle kann beispielsweise in Puffern, die keine bandbreitenbedarfsreduzierten TCP-Segmente oder PBP-Segmente enthalten, und in Puffern, für die die Plattformumgebung 210 noch nicht die richtige Backbone-Verbindung, der der Puffer zugeordnet werden soll, bestimmt hat, auf 0 × FFFF eingestellt werden. Letzteres trifft auf TCP <SYN>-Segmente zu, die vom lokalen LAN empfangen werden.
  • Das 24 Byte große inhaberspezifische „Header"-Feld 1605 sorgt für die Verschiebung des Inhalts eines Puffers, um unterschiedliche Header-Größen aufnehmen zu können, die die CPU benötigt. Falls der Nutzinhalt des Puffers klein ist, muss die benötigte CPU nicht bedeutend sein. Wenn jedoch der Nutzinhalt groß ist, z.B. wenn der Puffer Anwenderdaten enthält, kann die benötigte CPU sehr bedeutend sein. Und da das Befördern von Anwenderdaten der eigentliche Zweck eines Netzwerks ist (und idealerweise den überwiegenden Teil des Verkehrs ausmacht) ist eine Optimierung für den Fall von großen Anwenderdatennachrichten wünschenswert. Die Größe eines empfangenen IP-Headers 1501 und die eines übertragenen IP-Headers 1051 sind im Allgemeinen gleich, d.h. 20 Byte. Daher erfordert der Austausch eines IP-Headers 1501 mit einem Anderen in der Regel kein spezielles Puffer-Management. Dagegen unterscheidet sich die Größe eines TCP-Headers 1515 von der Größe eines PBP-Header 1525 und sogar von der Größe von kombinierten PBP- und TSK-Headers. Ein TCP-Header 1515 ist im Algemeinen 20 Byte groß. Die Verwendung von TCP-Optionen kann die Größe des TCP-Headers 1515 vergrößern. Wie derzeit definiert, hat ein PBP-Header 1525 12 Byte, wenn das PBP-Segment einen TSK-Nachricht einschließt. In den meisten Fällen hat ein TSK-Header 1519 (15) für eine Datennachricht 6 Byte. Für die Ausnahmen ist der TSK-Header 1519 18 Byte groß. Daher sind die kombinierten PBP- und TSK-Headers 1525 und 1519 für eine Datennachricht meistens 18 Byte groß.
  • An der Oberfläche kann es so aussehen, als ob das Austauschen entweder des PBP-Headers 1525 oder des TSK-Headers 1519, so dass die kombinierten Headers 20 Bytes haben, um der Größe des TCP-Headers 1515 angepasst zu sein, die Puffer-Managementleistung verbessert (um den Preis der Verschwendung einiger Bytes im Overhead, wenn PBP-Segmente durch das WAN verschickt werden). Zusätzlich zur Verringerung der Flexibilität in Bezug auf den Umgang mit TCP-Optionen zeigt sich jedoch, dass dies nicht der Fall ist. Der Grund dafür ist, dass TSK- und BPK-Puffer-Management unabhängig voneinander stattfinden. Der TSK 280 kennt die Größe des PBP-Headers 1525 nicht und sollte sie auch nicht kennen. Und andererseits kennt der BPK 282 nicht die Größe des TSK-Headers und sollte sie auch nicht kennen. Wenn die Kernel die Header-Größe des jeweils anderen kennen würden, würde dies ihre Protokollschichtbeziehung stören und eine unbeabsichtigte Abhängigkeit zwischen den Kernels erzeugen. Das Verfahren, mit diesem Problem umzugehen, ist die Verwendung von extra Platz im vorderen Teil des Puffers zusammen mit einem „Zeiger" (d.h. einem Verschiebezähler) für den Puffernutzinhalt (d.h. den aktuellen Anfang des IP-Pakets). Dieses Verfahren macht es möglich, dass die Daten an Ort und Stelle bleiben und nur die Puffer-Header umherbewegt werden. Und es zieht Vorteil aus der Tatsache, dass die PEP-Kernels im Allgemeinen den Platz für die Header nur neu verwenden. Felder in einem Header bleiben kaum unverändert und daher erfordert eine Verschiebung des Orts eines Headers einfach eine Änderung des Orts, an dem ein Kernel Felder füllen muss, nicht eine tatsächliche Verschiebung des Header-Inhalts. Beispielsweise enthält der IP-Header 1501, der vom TCP-Spoofing-Kernel 280 benötigt wird, um TCP-Daten an den lokalen Host zu schicken und von diesem zu empfangen, keine Feldwerte, die er mit dem IP-Header 1501, den der Backbone Protocol Kernel 282 benötigt, um die gleichen Daten durch das WAN zu senden und zu empfangen, gemeinsam hat. Und der TCP-Header 1515, der verwendet wurde, um Daten zum lokalen Host zu schicken und von diesem zu empfangen, wird vollständig durch die PBP- und TSK-Header 1519 und 1509 ersetzt, die verwendet werden, um die gleichen Daten über das WAN zu senden und zu empfangen (und umgekehrt). In einem Ausführungsbeispiel kann in einem Puffer, der noch keine Header-Anpassungen erfahren hat, der Nutzinhalt-Offset am Anfang eines IP-Pakets 44 Byte in den Puffer hinein zeigen (weil der Puffer in diesem Beispiel mit 16 Byte Header-Wachstumsplatz initialisiert wird). Falls ein Header eingesetzt werden muss, der kleiner ist als der Header, den er ersetzt, dann verschiebt der Kernel, der die Anpassung vornimmt, die Header nach rechts, wodurch das Nutzinhaltfeld im Puffer aktualisiert wird. Falls ein Header eingesetzt werden muss, der größer ist als der Header, den er ersetzt, dann verschiebt der Kernel, der die Anpassung vornimmt, den Header nach links, wodurch wiederum das Nutzinhalt-Offset-Feld 1601b im Puffer aktualisiert wird. Natürlich können, wie oben angegeben, selbst dann, wenn keine Header-Anpassungen erforderlich sind, Nutzinhalt-Offset-Anpassungen erforderlich sein, weil IP-Pakete nicht die Puffer-„Einheit" sind, die an allen Schnittstellen weitergegeben werden. Genauer sind TSK-Nachrichten die Puffer-„Einheit", die zwischen dem TCP-Spoofing-Kernel 280 und dem Backbone Protocol Kernel 282 weitergegeben wird.
  • Die 17 bis 20 zeigen die Verwendung des Header-Wachstumsplatzes für TCP-Datensegmente gemäß einer Ausführungsform der vorliegenden Erfindung. In 17 wird ein Puffer, der ein TCP-Datensegment enthält, das er vom lokalen LAN empfangen hat, von der Plattformumgebung 210 zum TCP-Spoofing-Kernel 280 weitergegeben. Der TSK 280 entfernt den 20 Byte-IP-Header 1501 und den 20 Byte-TCP-Header 1515 und fügt einen 6 Byte-TSK-Header 1519 hinzu, wobei der Nutzinhalt-Offset 1601b von 44 auf 78 aktualisiert wird (was den Größenunterschied zwischen dem ursprünglichen und dem neuen Header darstellt), und gibt dann den Puffer als TSK-Nachricht an den Backbone Protocol Kernel 282 weiter. Der BPK 282 fügt einen 20 Byte-IP-Header 1501 und einen 12 Byte-PBP-Header 1525 zu der TSK-Nachricht hinzu, wodurch der Nutzinhalt-Offset 1601b von 78 auf 46 aktualisiert wird, und gibt den Puffer dann an die Plattformumgebung 210 für die Weitersendung an das WAN weiter.
  • 18 stellt den gleichen Pufferfluss für den Fall dar, dass der TSK 280 einen 12 Byte-Verbindungs-Header 1515 für das TCP-Datensegment zusätzlich zum TSK-Header 1519 einsetzen muss.
  • In 19 wird ein Puffer, der eine TSK-Datennachricht, die er vom WAN erhalten hat, enthält, von der Plattformumgebung 210 zum BPK 282 weitergegeben. Der BPK 282 entfernt den 20 Byte-IP-Header 1501 und den 12 Byte-PBP-Header 1525, wobei er den Nutzinhalt-Offset 1601b von 44 auf 76 aktualisiert, und gibt dann den Puffer an den TSK 280 weiter. Der TSK 280 entfernt den 6 Byte-TSK-Header 1519 und fügt einen 20 Byte-IP-Header 1501 und einen 20 Byte-TCP-Header 1515 hinzu, um die TSK-Datennachricht in ein TCP-Datensegment umzuwandeln, wodurch der Nutzinhalt-Offset 1601b von 76 auf 46 aktualisiert wird, und gibt dann den Puffer an die Plattformumgebung 210 für die Weitersendung an das WAN weiter.
  • 20 stellt den gleichen Pufferfluss für den Fall dar, dass der TSK 280 zusätzlich zum TSK-Header 1519 auch einen 12 Byte-TCP-Verbindungs-Header 1515 von der TSK-Datennachricht entfernen muss.
  • Eine Anfangsgröße von 16 Byte kann ausgewählt werden, da ein 16 Byte-Header-Wachstums-„Header" 4 Byte für eine Ausrichtung bereitstellt und eine Reserve für nicht vorhergesehene Header-Wachstumsanforderungen bereitstellt. In einer bestimmten Plattform kann die Plattformumgebung 210 jedoch so gewählt werden, dass sie eine Anfangs-Header-Wachstumsplatzgröße von über 16 Byte nutzt. Dies kann beispielsweise erwünscht sein, um Platz für einen Ethernet-MAC-Header zu schaffen, wodurch möglicherweise die Nutzung eines allgemeinen physischen Puffer-Pools, der von allen logischen Puffer-Pools gemeinsam verwendet wird, möglich ist.
  • Es sei darauf hingewiesen, dass nicht alle TCP-Segmente, die von dem TCP-Spoofing-Kernel verschickt werden, von TSK-Nachrichten stammen, die von einem TSK-Peer empfangen werden. Der TSK muss häufig „ganz von Grund auf" ein TCP-Segment (z.B. eine Bestätigung für ein empfangenes TCP-Datensegment) erzeugen, um es zu einem lokalen Host zu senden. Wie bereits angegeben, ruft der TSK 280, wenn er solch ein TCP-Segment erzeugen muss, die Plattformumgebung 210 auf, einen WAN-zu-LAN-Puffer 1203 zuzuordnen. Der Puffer 1203, der von der Umgebung 210 bereit gestellt wird, wird initialisiert, wobei sein Nutzinhalt-Offset 1601b auf das erste Byte jenseits des Default-Header-Wachstums-„Header" der Plattform zeigt (z.B. 44 Byte in den Puffer hinein). Da keine Header vor den Headern eingesetzt werden müssen, die vom TSK 280 eingesetzt werden (abgesehen von dem LAN MAC-Header, der für alle IP-Pakete eingesetzt wird), muss der TSK 280 sich nicht damit befassen, Platz für zusätzliche Header im Puffer frei zu lassen. Der TSK 280 kann einen IP-Header 1501 und einen TCP-Header 1515 an dem Ort, der von der Plattformumgebung 210 bereitgestellt wird, einsetzen. Dies ist in 21 dargestellt.
  • Ebenso stammen nicht alle PBP-Segmente, die vom Backbone Protocol Kernel 282 verschickt werden, von TSK-Nachrichten, die vom TSK 280 weitergeschickt werden. Der BPK 282 muss häufig „von Grund auf" ein PBP-Segment (z.B. eine Bestätigung für ein empfangenes PBP-Datensegment) erzeugen, um es an einen BPK-Peer zu schicken. Wenn der BPK 282 ein solches PBP-Segment erzeugen muss, ruft der BPK 282 die Plattformumgebung 210 auf, um einen Lan-zu-Wan-Puffer 1201 zuzuordnen. Der von der Umgebung bereitgestellte Puffer wird initialisiert, wobei sein Nutzinhalt-Offset auf das erste Byte jenseits des Default-Header-Wachstums-„Header" der Plattform zeigt (z.B. 44 Byte in den Puffer). Da keine Header vor den vom BPK 282 eingesetzten Headern eingesetzt werden müssen (abgesehen von einem etwaigen WAN MAC-Header, der für alle IP-Pakete eingesetzt wird), muss sich der BPK 282 nicht damit aufhalten, Platz für zusätzliche Header im Puffer frei zu lassen, und kann einen IP-Header 1501 und einen PBP-Header 1525 an dem Ort einsetzen, der von der Umgebung 210 bereitgestellt wird. Dies ist in 22 dargestellt.
  • Der BPK 282 muss niemals Nachrichten für einen lokalen Host (über TSK 280) erzeugen. Jedoch muss der TSK 280 TSK-Nachrichten (z.B. eine Connection Terminated-Nachricht, wenn eine Verbindung aufgrund von Rückübermittlungsfehlern beendet wird) erzeugen, um sie zu TSK-Peers zu schicken (über BPK 282). Wenn der TSK 280 eine TSK-Nachricht erzeugen muss, ruft der TSK 280 die Plattformumgebung 210 auf, einen LAN-zu-Wan-Puffer 1201 zuzuordnen. Wie in den anderen oben beschriebenen Fällen wird der von der Umgebung bereitgestellte Puffer initialisiert, wobei sein Nutzinhalt-Offset 1601b auf das erste Byte jenseits des Default-Header-Wachstums-„Header" der Plattform zeigt (z.B. 44 Byte in den Puffer). Da eine TSK-Nachricht über BPK 282 verschickt wird, muss der TSK 280 in diesem Fall jedoch Platz für den BPK 282 lassen, um PBP- und IP-Header einzusetzen; dies erfordert jedoch nicht, dass der TSK 280 etwas über die Größe des PBP-Headers 1525 weiß. Der TSK 280 kann einfach den TSK-Header 1519 (und, falls nötig, den TCP-Verbindungs-Header 1515) an den Orten hinzufügen, wo er dies getan hätte, wenn der Puffer mit einem IP-Header 1501 und einem TCP-Header 1515 darin empfangen worden wäre, wie in 23 dargestellt.
  • Es sei darauf hingewiesen, dass das Szenario in 23, wodurch TSK 280 den Puffer so einstellt, dass ein IP-Header 1501 und ein TCP-Header 1515 eingeschlossen werden, so dass der Puffer gleich aussieht als wäre der Puffer von dem lokalen LAN empfangen worden, nur der Erläuterung dient. Diese Implementierung kann beispielsweise sofort den TSK-Header 1519 an der richtigen Stelle einwechseln, indem der richtige Wert zum Nutzinhalt-Offset 1601b addiert wird. Wenn der TSK 280 und der BPK 282 die Umgebung aufrufen, einen Puffer zuzuordnen, stellen sie die Größe des Puffers bereit, den sie zuordnen wollen. Die angegebene Größe reflektiert jedoch nur die Größe des Segments oder der Nachricht, die sie erzeugen wollen (einschließlich der relevanten Protokoll-Header). Die Größe schließt nicht den PEP-Puffer-Header oder einen etwaig benötigten plattformspezifischen Puffer-Header ein. Die Umgebung 210 passt die angeforderte Größe dementsprechend an. Diese Anpassung wird aus zwei Gründen der Umgebung überlassen. Zunächst wissen der TSK 280 und der BPK 282 nichts über plattformspezifische Puffer-Header. Zweitens könnte eine bestimmte Umgebung 210 einen größeren Header-Wachstumsplatz als das erforderliche Minimum nutzen wollen.
  • Es gibt ein weiteres Puffernutzungsszenario, das den TCP-Spoofing-Kernel einschließt, wobei eine „Nachricht" empfangen und nicht weitergesendet wird, aber der Empfang der „Nachricht" es erfordert, dass eine andere „Nachricht" in der gleichen Richtung (LAN-zu-WAN oder WAN-zu-LAN) wie die ursprüngliche „Nachricht" erzeugt wird. Zum Beispiel wird ein empfangenes TCP <RST>-Segment nicht weiter gesendet, kann aber die Notwendigkeit bewirken, eine Connection Terminated-TSK-Nachricht zu senden, und umgekehrt. Wenn dies der Fall ist, nutzt TSK 280 erneut den Puffer der ursprünglichen „Nachricht", um die neue „Nachricht" zu erzeugen, anstatt den empfangenen Puffer freizugeben und einen neuen zuzuordnen. Dies erfordert jedoch keinerlei spezielle Handhabung aufgrund der Tatsache, dass der TSK 280 die Header von TCP-Segmenten und TSK-Nachrichten, die er empfängt, vor dem Weitersenden bereits vollständig austauscht. Die gleichen Puffernutzinhalt-Offset-Anpassungen, die für weitergeschickte Daten-„Nachrichten" durchgeführt werden, funktionieren auch bei der erneuten Verwendung eines Puffers. Dies ist in den 24 und 25 dargestellt, die zeigen, dass die gleiche Header-Anpassung, die in den 18 und 20 dargestellt ist, verwendet werden kann; der einzige Unterschied ist, dass keine Daten in dem Puffer sind, die für den Wiederverwendungsfall behalten werden müssen.
  • Wie bereits angegeben, spezifizieren der TSK 280 oder der BPK 282 die benötigte Puffergröße, wenn sie einen Puffer zuweisen, um ein zu verschickendes IP-Paket zu konstruieren. Der BPK 282 erzeugt keine IP-Pakete, die in Richtung des lokalen LAN weitergeleitet werden müssen (mittels des TSK 280), und daher ist er nicht damit befasst, Platz für den TSK 280 zu lassen, um Daten in den zugeordneten Puffer einzusetzen. Jedoch erzeugt der TSK 280 TSK-Nachrichten, die zum WAN weitergeleitet werden sollen (mittels des BPK 282). Wenn der TSK 280 einen Puffer für den Zweck des Verschickens einer Nachricht zuordnet, muss der TSK 280 daher Platz für den PBP-Header 1525 lassen. Jedoch setzt der BPK 282 den PBP-Header 1525 vor dem TSK-Header 1519 ein, wobei er die TSK-Nachricht wie Daten behandelt.
  • Solange ein TSK 280 der obigen Strategie des „Einsetzens" von Platz für den IP-Header 1501 und den TCP-Header 1415 folgt, bleibt die Größe des zugeordneten Puffers die richtige. Die Größe eines Puffers kann jedoch nicht mehr die richtige sein, wenn er erneut verwendet wird. Beispielsweise wird ein empfangenes TCP <SYN>-Segment in der Regel ein 40 Byte-IP-Paket sein. Aber das IP-Paket, das für die TSK CR-Nachricht verwendet wird, die als Folge des Empfangs des TCP <SYN>-Segments verschickt werden muss, wird größer sein als 40 Byte. Falls eine Strategie für eine variable, exakte Puffergröße in der PEP-Endpunktplattform 210 verwendet wird, bleibt kein Platz im Puffer, um die CR-Nachricht zu erstellen. Es gibt zwei Möglichkeiten, dieses Problem zu lösen. Die erste Möglichkeit ist die Nicht-Zulassung der Wiederverwendung eines Puffers in diesem Fall. Der TSK 280 könnte gezwungen werden, den ursprünglichen Puffer freizugeben und einen neuen, größeren Puffer zuzuordnen. Die zweite Möglichkeit ist, eine Plattformumgebung 210 dazu zu bringen, immer einen Puffer von mindestens einer gewissen Mindestgröße zuzuordnen, wenn ein Puffer erforderlich ist oder wenn die Umgebung 210 ein empfangenes TCP- oder PBP-Segment aus einem LAN Rx-Puffer 1205 oder einem WAN Rx-Puffer 1209 in einen LAN-zu-WAN-Puffer 1201 oder einen WAN-zu-LAN-Puffer 1203 kopiert. Dies ist der Ansatz, der den PEP-Kernel-Code vorteilhafterweise vereinfacht.
  • Selbst wenn eine Plattform eine Festgrößenpuffer-Strategie verwendet, besteht trotzdem die Notwendigkeit, eine minimale Puffergröße zu erzwingen. In diesem Fall ist die minimale Puffergröße erforderlich, um sicherzustellen, dass alle Felder, auf die von einem PEP-Kernel zugegriffen wird, sich im ersten Puffer befinden, der ein IP-Paket enthält.
  • Dies schließt alle Protokoll-Header und die Daten für TSK-Steuernachrichten ein. Dies trifft zu, wenn die Pufferstrategie darin besteht, einzelne Festgrößenpuffer zu verwenden, da dies die Verwendung großer Puffer erfordert. Falls jedoch eine Speicherverkettung angewendet wird, dann muss der erste Puffer in der Kette groß genug sein, um alle Informationen aufzunehmen, auf die von den PEP-Kernels zugegriffen werden muss. Beispielsweise kann die minimale Puffergröße als 100 Byte festgelegt sein; d.h. eine Plattformumgebung 210 darf keinen Puffer zuordnen, der kleiner ist als 100 Byte. Der minimale Wert kann konfiguriert werden. Eine Plattformumgebung 210 kann auch eine minimale Puffergröße von mehr als 100 Byte verwenden, falls gewünscht; beispielsweise um die Pufferausrichtungsleistung zu verbessern. Die Erzwingung einer minimalen Puffergröße ist die Aufgabe der Plattformumgebung 210. Die Tatsache, dass der Puffer, der von der Umgebung zurückgeschickt wird, größer sein kann als angefordert, ist für den TSK 280 und BPK 282 erkennbar.
  • Die verschiedenen PEP-Kernels müssen häufig Pufferreihen miteinander verketten, um Warteschlangen zu implementieren. Dies kann durch Zuordnen eines kleinen, separaten Pufferdeskriptorblocks und anschließende Verwendung von Feldern im Pufferdeskriptor, um auf einen Puffer zu zeigen und um Pufferdeskriptoren miteinander zu verknüpfen, implementiert werden. Da jedoch im Grunde eine eins-zu-eins-Beziehung zwischen der Zahl der erforderlichen Pufferdeskriptoren und der Zahl der erforderlichen Puffer besteht, ist ein alternativer Ansatz die grundsätzliche Einbettung des Pufferdeskriptors in den Puffer selbst. Dies ist der Zweck des inhaberspezifischen Teils 1605 des allgemeinen PEP-Puffer-Headers 1403. Der inhaberspezifische „Header" 1605 steht dem aktuellen Inhaber eines Puffers zur Verfügung, um mit einer kernelspezifischen Pufferdeskriptorarchitektur überschrieben zu werden. Der Inhaberkernel kann dann den Pufferdeskriptor verwenden, um Puffer miteinander zu verknüpfen. Darüber hinaus (oder sogar als Alternative) kann der Inhaberkernel den inhaberspezifischen „Header" nutzen, um kernelspezifische Informationen, die mit dem Puffer in Beziehung stehen (beispielsweise einen Zeitnehrmer, der mit dem Puffer assoziiert ist) zu speichern. 26 zeigt ein Beispiel dafür, wie ein Kernel den inhaberspezifischen „Header" 1403 verwenden könnte. Wie bereits erörtert, gibt ein Kernel die implizite Inhaberschaft an einem Puffer auf, wenn er diesen an die Umgebung 210 oder einen anderen Kernel weitergibt. Daher sollte ein Kernel nicht annehmen, dass irgendwelche Felder in Sätzen im inhaberspezifischen Teil des allgemeinen PEP-Puffer-Headers 1403 sich in einem Puffer, der diesen abgibt und dann zurückbekommt, nicht verändern, solange die Semantik der speziellen Schnittstelle spezifisch so definiert ist, dass sie diese Annahme zulässt. Wenn der Backbone Protocol Kernel 282 beispielsweise ein PBP-Segment an die Plattformumgebung 210 für die Übertragung weitergibt, sollte der BPK 282 nicht annehmen, dass irgendwelche Felder, die er im inhaberspezifischen „Header" definiert hat, sich nicht verändert haben, wenn er den Puffer zurückbekommt, solange die Definition der spezifischen prozeduralen Schnittstelle nicht angibt, dass diese Annahme gültig ist.
  • Da sowieso eine Kopie erforderlich ist (aufgrund der Art, wie die verschiedenen LAN- und WAN-„Treiber" arbeiten), nutzt ein IP-Gateway (d.h. ein PEP-Endpunkt 210) die vorhandene Implementierung für den LAN Rx-Puffer 1205, den LAN Tx-Puffer 1207, den WAN Rx-Puffer 1209 und den WAN Tx-Puffer 1211. Ein einziger physischer Speicher-Pool wird sowohl für die LAN-zu-WAN- als auch für die WAN-zu-LAN-Puffer-Pools 1201 und 1203 verwendet. Das IP-Gateway 210 kann den Ansatz eines einzelnen Puffers variabler Größe zum Zuordnen von PEP-Puffern anwenden. Einzelner Puffer bezieht sich auf die Tatsache, dass nur ein physischer Puffer erforderlich ist, um ein ganzes IP-Paket aufzunehmen. Variable Größe bezieht sich auf die Tatsache, dass die Größe des zugeordneten Puffers (abgesehen von der Einschränkung einer minimalen Puffergröße, wie oben beschrieben) für die Größe des IP-Pakets exakt passen wird (wobei Platz für die verschiedenen Puffer-Header bleibt). Die malloc()- und free()-Funktionen verfolgen die exakte Größe der Puffer. Daher muss die IP-Gateway-Implementierung des PEP-Endpunkts 210 keinen plattformspezifischen Puffer-Header benötigen.
  • Im Hinblick auf die anderen PEP-Endpunkt-Implementierungen sind das Multimedia VSAT-Puffermanagement und das Multimedia Relay-Puffermangagement dem IP-Gateway-Puffermanagement ähnlich. Genauer implementieren die VSATs ihren LAN-zu-WAN-Pufferpool 1203 und ihren WAN-zu-LAN-Pufferpool 1203 als Pools von Speichern mit Puffern, die anhand von malloc() zugeordnet und anhand von free() freigegeben werden. Ein einziger physischer Speicherpool wird sowohl für den LAN-zu-WAN-Puffer 1201 als auch für den WAN-zu-LAN-Pufferpool 1203 verwendet. Ein Ansatz für einzelne Puffer variabler Größe zum Zuordnen von PEP-Puffern wird angewendet. Anders als beim IP-Gateway-Ansatz schließen die VSATs jedoch einen plattformspezifischen Puffer-Header in jedem Puffer ein.
  • Was die PES Remote PEP-Plattformumgebung 210 betrifft, so ist die Verwendung von Verkettungen kleiner Puffer erforderlich, um IP-Pakete aufzunehmen. Um die Tatsache, dass verkettete kleine Puffer verwendet werden, vor den PEP-Kernels zu verbergen, muss die PES Remote-Plattformumgebung 210 sicherstellen, dass alle Header, einschließlich des allgemeinen PEP-Puffer-Headers, in den ersten Puffer einer Pufferkette passen, und nicht nur die Protokoll-Header. Um diese Anforderung zu erfüllen, führt die PES Remote-Umgebung folgendes für ein IP-Paket durch, das von dem lokalen LAN oder dem WAN empfangen wird. Falls die Länge (oder der Inhalt) des ersten Puffers in der Kette klein genug ist, damit der allgemeine PEP-Puffer-Header 1403 in den Puffer eingesetzt werden kann, wird der Inhalt des Puffers nach rechts verschoben, um Platz dafür zu machen. Im Allgemeinen werden Pufferketten empfangen, deren Puffer alle voll sind, abgesehen vom letzten Puffer. Daher werden diese Bedingungen, wiederum im Allgemeinen, nur dann erfüllt, wenn das gesamte IP-Paket in einen einzigen kleinen Puffer passt. Diese Möglichkeit ist in 27 dargestellt. Falls die Länge des ersten Puffers zu groß ist, um zu ermöglichen, dass der gemeinsame PEP-Puffer-Header eingesetzt wird, ordnet die Umgebung 210 einen extra Puffer zu und stellt ihn der Pufferkette voran. Falls kein Puffer verfügbar ist, wird das IP-Paket fallen gelassen und muss wiederhergestellt werden als wäre es beim Durchgang durch das LAN oder WAN verloren gegangen. Der gemeinsame PEP-Puffer-Header wird in den extra Puffer eingegeben und dann werden alle Protokoll-Header im ursprünglichen ersten Puffer in den Puffer kopiert. Schließlich werden jegliche Daten, die im ursprünglichen ersten Puffer zurückgeblieben sind, nach links verschoben (nach vorne im Puffer). Diese Möglichkeit ist in 28 dargestellt. Obwohl diese Kopien zusätzlichen Platzbedarf darstellen, ist eine gewisse Art von Kopieren unabdingbar und dieser Ansatz sollte den Umfang des Kopierens auf ein Minimum beschränken. Darüber hinaus können im PES Remote für den LAN Rx-Pufferpool 1205, den LAN-zu-WAN-Pufferpool 1201 und den (Inroute) WAN Tx-Pufferpool 1211 tatsächlich die gleichen Puffer verwendet werden. Und die gleichen Puffer 1201, 1205 und 1211 können auch für den (Outroute) WAN Rx-Pufferpool 1209, den WAN-zu-LAN-Pufferpool 1203 und den LAN Tx-Pufferpool 1207 verwendet werden. Somit kann die PES Remote-Plattformumgebung 210 beispielsweise vermeiden, dass einige der Kopien, die in anderen Arten von PEP-Endpunkt-Plattformen 210 erforderlich sind, Daten von einer Pufferart zu einer anderen bewegen, wodurch der CPU-Nachteil, der von den oben beschriebenen Kopien auferlegt wurde, wegfällt. In einem PES Remote kann die Größe eines LAN Rx-Puffers 1205, eines LAN-zu-WAN-Puffers 1201 und eines (Inroute) WAN Tx-Puffers 1211 entweder 146 Byte oder 246 Byte betragen (je nach dem speziellen Software-Bau). Die Größe anderer Arten von Puffern beträgt 246 Byte. Auch mit dem gemeinsamen PEP-Puffer-Header 1403 stellen 146 Byte ausreichend Platz für die meisten IP-Pakete (z.B. TCP-Bestätigungen) und für viele Daten-IP-Pakete (z.B. HTTP GETs) bereit. Insbesondere stellen 146 Byte ausreichend Platz bereit, um jedes Segment oder jede Nachricht unterzubringen, die vom TSK 280 oder vom BPK 282 (von Grund auf) erzeugt werden muss.
  • Die Plattformumgebung 210 verfolgt die Menge des Pufferplatzes, der in jeder Richtung für jede Backbone-Verbindung verwendet wird. Diese Verfolgung wird für die Zwecke der Aufteilung von Pufferplatzressourcen in Hinblick auf Bekanntmachungen von TCP- und PBP-Fenstern durchgeführt. Zumindest in der Anfangsausgabe des PEP-Merkmals stützt die Umgebung 210 Entscheidungen im Hinblick auf die Zuordnung eines Puffers nicht auf die Menge an verwendetem Pufferplatz. Wenn sich die Notwendigkeit ergibt, einen Puffer zuzuordnen, ordnet die Umgebung 210 den Puffer zu, falls ein Puffer aus dem geeigneten Pufferpool verfügbar ist. Diese Vorgehensweise wirft keinerlei Probleme dahingehend auf, dass erwartet wird, dass TCP- und PBP-Sender (d.h. lokale TCP-Hosts und PEP-Endpunkt-Peers) keine Pakete über das hinaus befördern, was durch die bekannt gemachten Empfangsfenster, die sie von einem PEP-Endpunkt 210 erhalten, zugelassen ist. Diese Vorgehensweise vereinfacht das Fehlermanagement im Zusammenhang mit der Zuordnung von Puffern, um Steuernachrichten zu schicken, wenn der Pufferplatz ausgeht, erheblich. Die folgenden Abschnitte beschreiben die Verfolgung und Verwendung der Pufferplatzverfügbarkeit, um TCP- und PBP-Fenster zu berechnen.
  • Sowohl TCP als auch PBP verwenden Fenster, die vom Datenempfänger an den Datensender geschickt werden, um zu steuern, wie viele Daten vom Sender zum Empfänger übermittelt werden können. Generell ermöglicht ein größeres Fenster einen höheren Durchsatz. Der Durchsatz ist jedoch von der Größe der kleinsten Verknüpfung der Leitung, durch die die Daten fließen, beschränkt, deshalb erhöht jenseits eines bestimmten Punkts eine Vergrößerung des Fensters den Durchsatz nicht weiter. Um sicherzustellen, dass die übermittelten Daten vom Empfänger nicht verworfen werden, wenn sie ankommen, beschränkt der Empfänger im Allgemeinen das Fenster, das er bekannt gibt, aufgrund der Menge an Pufferplatz, die gegenwärtig zur Verfügung steht, um Daten zu empfangen. Um die Menge an verfügbarem Pufferplatz als Beschränkung der Fenstergröße verwenden zu können, muss der Empfänger jedoch wissen, wie viel Platz zur Verfügung steht. Um die Berechnung der Fenstergröße aufgrund des verfügbaren Pufferplatzes zu unterstützen, verfolgt die Plattformumgebung 210 die Menge an LAN-zu-WAN- und WAN-zu-LAN-Pufferplatz, der für jede Backbone-Verbindung verwendet wird (im Umgebungssteuerblock der Backbone-Verbindung (ECB)). Sobald die Umgebung 210 ein empfangenes TCP-Segment aus einem LAN Rx-Puffer 1205 in einen LAN-zu-WAN-Puffer 1201 kopiert, inkrementiert die Umgebung 210 die Menge an Pufferplatz, der für die Backbone-Verbindung verwendet wird, um den Bandbreitenbedarf der TCP-Verbindung, zu der das TCP-Segment gehört, zu reduzieren. Die Umgebung 210 bestimmt, welche Backbone-Verbindung gerade verwendet wird, indem sie in den CCB der TCP-Verbindung schaut. Für den Fall, dass ein TCP <SYN>-Segment empfangen wird, ohne dass bisher ein CCB für die TCP-Verbindung zugeordnet wurde, zählt die Umgebung 210 den Puffer des TCP <SYN>, wenn der TCP-Spoofing-Kernel 280 den CCB zuordnet. Die Umgebung 210 inkrementiert auch die LAN-zu-WAN-Pufferplatzzählung, sobald der TSK 280 einen LAN-zu-WAN-Puffer 1201 zuordnet, um eine TSK-Nachricht von Grund auf zu erzeugen, und sobald der Backbone Protocol Kernel 282 einen LAN-zu-WAN-Puffer 1201 zuordnet, um ein PBP-Segment von Grund auf zu erzeugen.
  • Die WAN-zu-LAN-Pufferbuchung funktioniert ähnlich wie die LAN-zu-WAN-Pufferbuchung. Wenn die Umgebung 210 ein empfangenes PBP-Segment von einem WAN Rx-Puffer 1209 in einen WAN-zu-Lan-Puffer 1203 kopiert, inkrementiert die Umgebung 210 die Menge an Pufferplatz, der für die Backbone-Verbindung verwendet wird, von der das PBP-Segment empfangen wurde. In einem Ausführungsbeispiel der Erfindung bestimmt die Umgebung 210 den Handle der Backbone-Verbindung durch Kombinieren des Peer-Index, der der Quell-IP-Adresse in dem IP-Paket zugeordnet ist, mit der Priorität der Verbindung (angezeigt durch di PBP-Portnummer). Die Umgebung 210 inkrementiert auch die WAN-zu-LAN-Pufferplatzzählung, wenn der TSK 280 einen WAN-zu-LAN-Puffer 1203 zuordnet, um ein TCP-Segment von Grund auf zu erzeugen. Die Umgebung dekrementiert die LAN-zu-WAN- oder WAN-zu-LAN-Pufferplatzzählung nach Bedarf, sobald ein Puffer freigegeben wird. Der Backbone-Verbindungs-Handle, der verwendet wird, um den geeigneten ECB zu finden, und ein LAN-zu-WAN versus WAN-zu-LAN-Flag werden in dem Puffer untergebracht, um die Buchung der des freigegebenen Puffers zu vereinfachen. Wie nachstehend beschrieben, wird Pufferplatz intern hinsichtlich der Nummer der verwendeten Puffer verfolgt, nicht anhand des verwendeten Pufferplatzes.
  • In einem Ausführungsbeispiel beeinflussen vier Arten von Parametern, die für einen PEP-Endpunkt 210 konfiguriert sind, die Verwendung von Pufferplatz, um die Bekanntgabe von Fenstergrößenwerte zu bestimmen: (1) Pufferplatz pro Peer, (2) TCP-Verbindungssteuerblöcke pro Peer, (3) Prozentanteil Ressourcen pro Verbindung und (4) Fenstergrößen-Obergrenze. Wie in 5 dargestellt, wird jeder PEP-Endpunkt 501, 503 mit der Menge an Pufferplatz (angegeben in Kilobyte-Einheiten) konfiguriert (über sein PEP-Endpunktprofil), den er für WAN-zu-LAN-Verkehr verwenden sollte, der von jedem seiner PEP-Endpunkt-Peers empfangen wird. Dies ist die Gesamtmenge an WAN-zu-LAN-Pufferplatz in einem Fern-Site-PEP-Endpunkt 503 (der nur einen Peer hat). Dies ist der WAN-zu-LAN-Pufferplatz pro Peer in einem Hub-Site-PEP-Endpunkt 501. Wenn beispielsweise der Wert, der im PEP-Endpunktprofil des Hub-Site-PEP-Endpunkts konfiguriert wird, 500 kB beträgt, ist der WAN-zu-LAN-Pufferpool 1203 für jeden der Peers 500 kB. Falls 100 Peers vorhanden sind, dann ist die Gesamtmenge an WAN-zu-LAN-Pufferplatz 50 MB. Beim Konfigurieren des WAN-zu-LAN-Pufferplatzwerts muss der Operator die Gesamtmenge an verfügbarem Pufferplatz, die Zahl der Peers, die sich den Gesamtpool teilen müssen, und die Menge an Pufferplatz, die in LAN-zu-WAN-Richtung erforderlich ist, berücksichtigen. Die Menge an Pufferplatz, die in LAN-zu-WAN-Richtung erforderlich ist, ist nominal die Summe aller WAN-zu-LAN-Pufferplatzwerte aller PEP-Endpunkt-Peers. Der Operator kann jedoch tatsächlich den Pufferplatz überbuchen; d.h. der Operator ist nicht darauf beschränkt, die Menge an zu verwendendem Pufferplatz so zu konfigurieren, dass die Gesamtsumme, wenn alle Puffer verwendet würden, unter der tatsächlich verfügbaren Menge liegt. Der Operator könnte dies tun, um zu bewirken, dass größere Fenster bekannt gegeben werden, um den Durchsatz zu verbessern (jedoch auf Kosten des Risikos eines Paketverlusts) oder um sich Kenntnisse hinsichtlich dieser Anwendungen zunutze zu machen. Beispielsweise könnte der Operator wissen, dass diese Anwendungen am Tag mehr LAN-zu-WAN-Pufferplatz brauchen und in der Nacht mehr WAN-zu-LAN-Pufferplatz brauchen. Insbesondere wird der Operator den Pufferplatz im Hub-Site-PEP-Endpunkt 501 in der Regel überbuchen, weil es statistisch sehr unwahrscheinlich ist, dass Verkehr gleichzeitig zu jedem Peer geschickt wird. Pufferplatz wird in Byte vom Operator angegeben, da die Menge an Speicher (in Byte) das ist, was dem Operator bekannt ist.
  • Intern wandelt ein PEP-Endpunkt 501, 503 den konfigurierten WAN-zu-LAN-Pufferplatz pro Peer aus der Byte-Zahl in die Pufferzahl um, um die Puffer zu verfolgen. Dies wird durch Teilen der Zahl der Bytes durch die Größe eines Puffers, der in der Lage ist, ein IP-Paket maximaler Größe unterzubringen (z.B. 1500 Byte plus die Größe des gemeinsamen PEP-Puffer-Headers plus die Größe eines etwaigen plattformspezifischen Headers) durchgeführt. Dies wird aus zwei Gründen getan. Erstens gibt der PBP Fenster ausgedrückt in Paketen, nicht in Byte, bekannt und muss annehmen, dass jedes Paket, das er empfängt, ein Paket maximaler Größe ist. Zweitens werden alle Pufferplatzberechnungen unter der Annahme eines IP-Pakets maximaler Größe gemacht, um Annahmen über die verwendete Pufferstrategie in einem PEP-Endpunkt-Peer zu eliminieren. Wenn beispielsweise ein PEP-Endpunkt eine variable Strategie eines Puffers mit exakter Größe anwendet und Bytes aufgrund von tatsächlichen IP-Paketgrößen zählt, aber sein Peer eine Festgrößen-Pufferstrategie anwendet, wird die Byte-Zählung die Menge an verwendetem Speicher in dem Peer nicht exakt wiedergegeben, solange nicht alle IP-Pakete die maximale Größe haben. Ebenso sorgt die Tatsache, dass die Menge an Pufferplatz überbucht werden kann, für ein großes Maß an Flexibilität im Hinblick auf die Leistungssteigerung. Und sie stellt einen Spielraum zum Kompensieren von Annahmen, die für ein bestimmtes Kundennetzwerk nicht zutreffen, bereit. Falls beispielsweise die maximale IP-Paketgröße in einem bestimmten Netzwerk 1000 Byte statt 1500 Byte ist und der Kunde nur PEP-Endpunktplattformen verwendet, die eine variable Exaktgrößen-Pufferstrategie anwenden, kann der Operator den WAN-zu-LAN-Pufferplatzparameter um 50 % erhöhen, um die Verwendung von IP-Paketen geringerer Größe zu kompensieren.
  • Die Zahl der TCP-Verbindungssteuerblöcke, die pro PEP-Endpunkt-Peer verwendet werden können, kann auch konfiguriert werden. Der Wert wird in erster Linie verwendet, um zu bestimmen, ob ein CCB in einem TSK 280-Peer verfügbar ist, um den Bandbreitenbedarf einer neu entdeckten TCP-Verbindung zu reduzieren. Dieser Wert beeinflusst jedoch auch Pufferplatzberechnungen im Zusammenhang mit Fenstergrößen, da der Pufferplatz, der für eine Backbone-Verbindung zur Verfügung steht, auf alle TCP-Verbindungen verteilt werden muss, die die Backbone-Verbindung nutzen. Die Pufferpoolgrößen-Berechnungen sind wie folgt: S = SO + 1500 nb = Nb/S,wobei SO die Puffer-Overhead-Größe in Byte (z.B. gemeinsamer PEP-Puffer-Header und etwaiger plattformspezifischer Puffer-Header) ist, S die Puffergröße in Byte ist, Nb der konfigurierte Pufferplatz in Byte ist und nb der Pufferplatz in einer Reihe von Puffern ist.
  • Mit Priorisierung bestehen möglicherweise mehrere Backbone-Verbindungen zwischen PEP-Endpunkt-Peers. Daher muss der Operator, zusätzlich zur Angabe der Menge an Pufferplatz (und der Zahl der CCBs) zur Verwendung für einen bestimmten PEP-Endpunkt-Peer, die Zuordnung dieser Ressourcen zu den verschiedenen Backbone-Verbindungen spezifizieren. Dies wird durch die Konfiguration von Ressourcen-Prozentanteilen, die jeder Priorität einer Backbone-Verbindung zugeschrieben werden, im Konnektivitätsprofil, das verwendet wird, um die Verbindungen zu definieren, durchgeführt. Für jede Priorität schreibt der Operator einen Ressourcen-Prozentanteil im Bereich von 0 5 bis 100 % zu (wobei 0 % verwendet wird, um anzuzeigen, dass bei dieser Priorität keine Backbone-Verbindung erforderlich ist). Der Operator kann Ressourcen durch Zuschreiben von Prozentanteilen, die sich auf mehr als 100 % summieren, überbuchen. Der Operator kann Ressourcen durch Zuschreiben von Prozentanteilen, die sich auf unter 100 % summieren, auch unterbuchen; dies könnte von Nutzen sein, um Pufferplatz für die Verwendung von nicht-bandbreitenbedarfsreduziertem Verkehr (z.B. UDP) zu reservieren. Die Umgebung 210 verwendet die vom Operator konfigurierten Prozentanteile, wenn die Backbone-Verbindungen geöffnet werden. Die Menge an WAN-zu-LAN-Pufferplatz, der einer Backbone-Verbindung zugeschrieben wird, wird gleich dem WAN-zu-LAN-Pufferplatz pro Peer gesetzt, multipliziert mit dem Ressourcen-Prozentanteil, der dieser Backbone-Verbindung zugeschrieben ist. Ebenso wird die Zahl der CCBs, die mit dieser Backbone-Verbindung genutzt werden können, gleich der Zahl der CCBs pro Peer, multipliziert mit dem gleichen Ressourcen-Prozentanteil gesetzt. In einem Ausführungsbeispiel können Pufferplatz und CCBs unterschiedliche Prozentzahlen zugeschrieben werden; alternativ dazu kann ein einziger Parameter für beide verwendet werden. Die WAN-zu-LAN-Pufferplatz- und CCB-Grenzen-Berechnungen sind wie folgt: Bpi W2L = nb &·Xpi CCBpi = CCBe &·Xpi,wobei Xpi der Ressourcen-Prozentanteil für die Backbone-Verbindung zum Peer „p" bei Priorität „i" ist, Bpi WZL die WAN-zu-LAN-Pufferplatzgrenze für die Backbone-Verbindung zum Peer „p" bei Priorität „i" ist, CCBpi die CCB-Grenze für die Backbone-Verbindung zum Peer „p" bei Priorität „i" ist und CCBe die konfigurierte PEP-Endpunkt-CCB-Grenze ist. Es sei darauf hingewiesen, dass die CCB-Grenze die lokale Grenze ist. Die Grenze, die verwendet wird, ist kleiner als die lokale CCB-Grenze und die CCB-Grenze des PEP-Endpunkt-Peers.
  • Obwohl im Allgemeinen ein TCP- oder PBP-Sender eigentlich mit einem TCP- oder PBP-Empfänger umgehen kann, der sein bekannt gegebenes Fenster verkleinert (d.h. ein neues Fenster sendet, das kleiner ist als das vorherige Fenster, minus etwaiger Daten, die in dem Fenster verschickt werden), arbeitet das Protokoll ineffizient, wenn dies der Fall ist. Daher werden TCP- und PBP-Empfänger durch ihre Protokolldefinitio nen so eingeschränkt, dass sie ein zuvor bekannt gegebenes Fenster nicht verkleinern dürfen. Angesichts dieses Falles sollte ein TCP- oder PBP-Empfänger im Allgemeinen sein Empfangsfenster nicht auf die Gesamtmenge an verfügbarem Pufferplatz setzen, da andere Anwender dieses Pufferplatzes bewirken können, dass die Menge an Pufferplatz so weit schrumpft, dass sie nicht mehr der Steuerung der jeweiligen TCP- oder PBP-Verbindung unterliegt. Anders ausgedrückt, das Verschicken eines großen Fensters reduziert die Flexibilität in Bezug auf die Fähigkeit, auf eine reduzierte Pufferverfügbarkeit durch Verlangsamung des TCP- oder PBP-Senders zu reagieren. Daher ist es wünschenswert, dass maximale bekannt gegebene TCP- und PBP-Fenstergrößengrenzen erzwungen werden. Diese Grenzen stellen das größte Fenster dar, das ein TCP- oder PBP-Empfänger dem Sender in jedem Segment, das zu dem Sender geschickt wird, bekannt gibt. Es sei jedoch darauf hingewiesen, dass, falls der verfügbare Pufferplatz klein ist, kleinere Fenster (einschließlich 0) verschickt werden können. Dagegen ist es wichtig, dass, wenn ausreichend Pufferplatz zur Verfügung steht, das Fenster, das von einem TCP- oder PBP-Empfänger bekannt gegeben wird, groß genug ist, um die Bandbreite * Verzögerungsprodukt (d.h. die Größe der Leitung dividiert durch die Umlaufzeit der Leitung), welche auf die Verbindung zutrifft, abzudecken (damit der TCP- oder PBP-Sender die Verbindungsleitung voll halten). Da die Umlaufzeit von Netzwerk zu Netzwerk unterschiedlich sein könnte, ist die Verwendung von fest codierten Werten für die Fenstergrößen-Obergrenzen unerwünscht. Daher können diese Grenzen als Teil eines PEP-Endpunktprofils eines PEP-Endpunkts konfiguriert werden.
  • Das PEP-Endpunktprofil kann eine TCP-Fenstergrößen-Obergrenze und eine PBP-Fenstergrößen-Obergrenze einschließen. Da die meisten TCP-Verbindungen lokal für den PEP-Endpunkt 210 sind (verbunden über Ethernet), kann eine niedrige TCP-Fenstergrößen-Obergrenze die Umlaufzeit für die meisten Fälle abdecken. Daher könnte in diesem Fall die maximale TCP-Fenstergrößen-Voreinstellung auf 8 KB gesetzt werden. Aufgrund der Vielfalt von möglichen Verknüpfungsgeschwindigkeiten, die für PBP-Verbindungen möglich sind, ist ein Voreinstellungswert, der für die meisten Situationen passt, nicht möglich.
  • Die folgende Erörterung beschreibt die Berechnungen, die von der Plattformumgebung 210, dem TCP-Spoofing-Kernel 280 und dem Backbone-Protocol-Kernel 282 durchgeführt werden, um verfügbaren Pufferplatz in bekannt gegebene Empfangsfenstergrößen umzuwandeln. Für jede Backbone-Verbindung leitet die Plattformumgebung 210, wie oben gezeigt, die Menge an Pufferplatz, die in WAN-zu-LAN-Richtung für die Verbindung genutzt werden kann, durch Multiplizieren des WAN-zu-LAN-Pufferplatzwerts pro Peer mit dem Prozentanteil der Ressourcen pro Peer, die dieser Backbone-Verbindung zugeteilt wurden, ab. Der resultierende Wert wird dann als die Obergrenze für den WAN-zu-LAN-Pufferplatz für diese Backbone-Verbindung verwendet. Da die WAN-zu-LAN-Pufferplatzwerte pro Peer sich für jeden Peer unterscheiden können, kann die Plattformumgebung 210 die entsprechende Grenze für die Menge an LAN-zu-WAN-Pufferplatz nicht direkt berechnen, obwohl die PEP-Endpunkt-Peers sich den gleichen Prozentanteil an Ressourcenparametern teilen können; stattdessen wird der Wert vom TCP-Spoofing-Kernel 280 bereitgestellt. Die Umgebung 210 stellt dem TSK 280 die WAN-zu-LAN-Puffergrenze (und die Grenze für die lokale Zahl der CCBs) bereit, wenn die Backbone-Verbindung geöffnet wird. Der TSK 280 schickt dann die Grenze an seinen TSK-Peer in einer TSK-Peer-Parameternachricht. Wenn der TSK 280 eine TPP-Nachricht erhält, extrahiert er die WAN-zu-LAN-Pufferplatzgrenze des Peers aus der Nachricht und gibt sie an seine Umgebung weiter. Die Umgebung nutzt die WAN-zu-LAN-Pufferplatzgrenze des Peers als ihre lokale LAN-zu-WAN-Pufferplatzgrenze. Wenn eine Backbone-Verbindung das erste Mal geöffnet wird, werden während des Wartens auf den Empfang einer TPP-Nachricht vom Peer die LAN-zu-WAN-Pufferplatzgrenze und die Grenze der Zahl der CCBs bei 0 initialisiert. Dies verhindert, dass der Bandbreitenbedarf von TCP-Verbindungen reduziert wird, bis gültige Peer-Parameterinformationen empfangen werden. Wie bereits beschrieben, zählt die Plattformumgebung die Zahl der LAN-zu-WAN-Puffer 1201 und der WAN-zu-LAN-Puffer 1203, die sie jeder Backbone-Verbindung zugewiesen hat, im ECB der Backbone-Verbindung. Wenn ein Puffer zugewiesen wird, wird die angemessene Verwendungszählung inkrementiert. Wenn ein Puffer freigegeben wird, wird der Backbone-Verbindungs-Handle, der von der Umgebung in dem Puffer gespeichert wurde, verwendet, um die richtige Verwendungszählung für die Dekrementierung zu finden. Wenn vom TSK 280 oder vom BPK 282 aufgefordert, schickt die Umgebung 210 den gerade verfügbaren LAN-zu-WAN- oder WAN-zu-LAN-Pufferplatz für eine Backbone-Verbindung zurück. In einer Plattform (z.B. der PES Remote), wo kleine, verkettete Puffer verwendet werden, muss die Plattformumgebung 210 ihre Pufferzählung mit der Zahl der Puffer, die benötigt sind, um ein IP-Paket maximaler Größe aufzunehmen, normalisieren. TSK 280 und BPK 282 verwenden diese Werte, um Fenstergrößen wie folgt zu berechnen: Api W2L = Bpi W2L – Upi W2L Api L2W = Bpi L2W – Upi L2W,wobei Bpi W2L die berechnete WAN-zu-LAN-Pufferplatzgrenze für die Backbone-Verbindung zum Peer „p" bei Priorität „i" ist, Bpi L2W die erlernte LAN-zu-WAN-Pufferplatzgrenze für die Backbone-Verbindung zum Peer „p" bei Priorität „i" ist, Upi W2L der WAN-zu-LAN-Pufferplatz ist, der für die Backbone-Verbindung zum Peer „p" bei Priorität „i" verwendet wird, Upi L2W der LAN-zu-WAN-Pufferplatz ist, der für die Backbone-Verbindung zum Peer „p" bei Priorität „i" verwendet wird, Api W2L der WAN-zu-LAN-Pufferplatz ist, der für die Backbone-Verbindung zum Peer „p" bei Priorität „i" zur Verfügung steht, und Api W2L der LAN-zu-WAN-Pufferplatz ist, der für die Backbone-Verbindung zum Peer „p" bei Priorität „i" zur Verfügung steht.
  • Zusätzlich zur Menge des verfügbaren Pufferplatzes kann es für einen PEP-Endpunkt 210 wünschenswert sein, andere Faktoren in Betracht zu ziehen, wenn die bekannt zu gebenden Fenstergrößen bestimmt werden. Insbesondere kann die aktuelle Latenz (im Allgemeinen anhand der Länge der Warteschlange) für die WAN-Schnittstelle 1215 ein wichtiger Faktor sein, da diese Schnittstelle 1215 ein Multiplexing-Punkt für den Verkehr vieler konkurrierender Flüsse ist, insbesondere im Hub. Tatsächlich schließt die PEP-TCP-Spoofing-Implementierung die Fähigkeit zur Überwachung der Warteschlangenlatenz und zur Anpassung von TCP-Fenstergrößenbekanntgaben ein, wenn die Warteschlangenlatenz zunimmt und abnimmt. Wenn vom Operator ermöglicht, kann die Umgebung 210 die Warteschlangenlatenz verfolgen und diesen Wert verwenden, um einen aktuellen Flusssteuerungsfaktor zu bestimmen. In einem Ausführungsbeispiel kann der Flusssteuerungsfaktor als Prozentanteil von 0 % bis 100 % verfolgt werden. Wenn die Latenz um einen bestimmten, vom Operator definierten Wert zunimmt, kann die Umgebung 210 den Flusssteuerungsfaktor verkleinern. Wenn die Latenz um einen bestimmten, vom Operator definierten Wert abnimmt, kann die Umgebung 210 den Flusssteuerungsfaktor vergrößern. Nominal können Inkremente von 5 % verwendet werden, um den Flusssteuerungsfaktor nach unten und nach oben anzupassen. Die exakten Inkrementierungseinheiten sind jedoch nicht besonders wichtig. Sobald die Plattformumgebung 210 eine Anforderung für die Menge an verfügbarem Pufferplatz in LAN-zu-WAN-Richtung empfängt, multipliziert sie das Ergebnis (bestimmt wie oben) mit dem Flusssteuerungsfaktor, wie nachstehend dargestellt. Api L2W = F·Api L2W,wobei F der aktuelle Flusssteuerungsfaktor, ausgedrückt als Prozentanteil, ist. Dies führt zu einem verringerten Input vom TCP-Host, der zum PEP-Endpunkt lokal ist, wenn die Latenz zunimmt.
  • Die Verwendung der Latenz, um Fenstergrößen anzupassen, kann auf PBP-Fenster angewendet werden. Insbesondere können Warteschlangenlatenzen, die mit der Verschickung von Verkehr in WAN-zu-LAN-Richtung in Beziehung stehen, verwendet werden, um die Fenster anzupassen, die vom PBP bekannt gegeben werden.
  • 29 zeigt ein Gleitfenster, das vom PBP verwendet wird, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie der TCP verwendet der PBP ein gleitendes Fenster 2901, um den aktuellen akzeptablen Bereich von Sequenznummern zu bestimmen. Wie dargestellt, ist der linke Rand im Sender die letzte bestätigte Sequenznummer plus eins (Snd_Una). Der rechte Rand ist gleich dem linken Rand plus die vom Empfänger bekannt gegebenen Fenstergröße. Der Sender kann das Fenster 2901 füllen und nach Füllen des Fensters 2901 muss er auf eine Bestätigung warten, um neue Pakete übertragen zu können. Falls das Fenster voll ist und der Sender neue Daten zum Versenden erhält, muss er diese Daten für die spätere Übermittlung nach Gleiten des Fensters 1901 in die Warteschlange stellen. Der Empfänger betrachtet das Fenster mittels Rcv_Nxt für den linken Rand anstelle von Snd_Una. Falls ein empfangenes Paket eine Sequenznummer innerhalb des Fensters aufweist, wird es bestätigt. Falls es dem linken Rand des Fensters 2901 entspricht, wird ein kumulativer ACK verwendet, der das Fenster 2901 um 1 nach unten schiebt.
  • Wenn der TCP-Spoofing-Kernel (TSK) 280 eine Fenstergröße bestimmen muss, um ein TCP-Segment bekannt zu geben, beginnt der TSK 280 durch Aufrufen der Plattformumgebung 210, um die Verfügbarkeit des aktuellen LAN-zu-WAN-Pufferplatzes für die Backbone-Verbindung zu erhalten, die mit der bandbreitenbedarfsreduzierten TCP-Verbindung assoziiert ist. Der TSK 280 teilt dann diese Zahl durch die Zahl der TCP-Verbindungen, die derzeit die Backbone-Verbindung nutzen. Der TSK 280 verfolgt die Zahl der TCP-Verbindungen, die eine Backbone-Verbindung nutzen, im TCB der Backbone-Verbindung, wobei er die Zählung inkrementiert, sobald ein CCB zugeordnet wird, und die Zählung dekrementiert, sobald ein CCB freigegeben wird. Der TSK 280 wandelt diesen Wert dann durch Multiplizieren der Zahl der Puffer mit den vom lokalen Host verwendeten MSS von Puffern in Byte um, um TCP-Segmenten an den TSK 280 zu schicken. Dieser Wert stellt die mögliche Fenstergröße dar, die bekannt gegeben werden kann. Der TSK 280 muss jedoch zwei zusätzliche Überprüfungen vornehmen, bevor er diesen Wert verwendet. Zuerst wird der mögliche Wert mit der Fenstergrößengrenze verglichen. Falls der mögliche Wert größer ist als die Fenstergrößengrenze, wird stattdessen die Fenstergrößengrenze bekannt gegeben. Falls der mögliche Wert kleiner ist als die Fenstergrößengrenze, führt der TSK 280 dann eine Überprüfung durch, um zu bestimmen, ob eine Bekanntgabe des möglichen Werts das Fenster auf einen Wert schrumpfen lassen würde, der kleiner als der zuvor bekannt gegebene ist (d.h. der den rechten Rand des rotierenden Fensters nach links verschieben würde). Wie bereits angegeben, sollte ein TCP-Empfänger sein Fenster 2901 nicht verkleinern; falls der potentielle Fensterwert das Fenster 2901 schrumpfen lassen würde, gibt der TSK 280 daher stattdessen das kleinste mögliche Fenster 2901 bekannt, welches das zuvor bekannt gegebene Fenster nicht schrumpfen lässt (d.h. den Wert, der dafür steht, den rechten Rand des Fensters 2901 an Ort und Stelle zu lassen). Die Berechnung des bekannt gegebenen TCP-Fensters 2901 ist wie folgt: WTC = Api L2W/Kpi·MSS WTA = MAX(MIN(WTC, WTL), WTR),wobei Kpi die aktuelle Zahl von TCP-Verbindung ist, die die Backbone-Verbindung zum Peer „p" bei Priorität „i" nutzt, WTC das berechnete TCP-Fenster 2901 ist, WTR das TCP-Fenster ist, das von dem Platz dargestellt wird, der vom zuvor bekannt gegebenen Fenster bleibt (d.h. aufgrund des letzten bekannt gegebenen „rechten Rands"), WTL die konfigurierte bekannt gegebene TCP-Fenster-Obergrenze ist, WTA das TCP-Fenster ist, das tatsächlich bekannt gegeben wird, und MSS die TCP-Verbindungs-MSS ist.
  • Die PBP-Fensterberechnungen gleichen den TCP-Fensterberechnungen, abgesehen davon, dass keine Notwendigkeit zum Umwandeln des Fensters in Byte bestehen muss. Wenn der Backbone-Protokoll-Kernel 282 eine Fenstergröße zur Bekanntgabe in einem PBP-Segment bestimmen muss, beginnt der BPK mit dem Aufruf der Plattformumgebung 210, um die aktuelle Verfügbarkeit des WAN-zu-LAN-Pufferplatzes für die Backbone-Verbindung zu erhalten. Dieser Wert stellt die mögliche Fenstergröße dar, die bekannt gegeben werden kann. Jedoch muss der BPK zwei zusätzliche Überprüfungen durchführen, bevor dieser Wert verwendet wird. Zuerst wird der mögliche Wert mit der Fenstergrößengrenze verglichen. Falls der mögliche Wert größer ist als die Fenstergrößengrenze, wird stattdessen die Fenstergrößengrenze bekannt gegeben. Falls der mögliche Wert kleiner ist als die Fenstergrößengrenze, fuhrt der BPK 282 dann eine Überprüfung durch, um zu bestimmen, ob der mögliche Wert das Fenster auf einen Wert schrumpfen lässt, der kleiner ist als der zuvor bekannt gegebene (d.h. ob er den rechten Rand des sich drehenden Fensters nach links bewegen würde). Wie oben beschrieben, sollte ein PBP-Empfänger sein Fenster 2901 nicht verkleinern. Wenn der potentielle Fensterwert das Fenster 2901 schrumpfen lassen würde, gibt der BPK 282 stattdessen das kleinste mögliche Fenster 2901 bekannt, das das zuvor bekannt gegebene Fenster 2901 nicht schrumpfen lässt (d.h. den Wert, der die Beibehaltung des rechten Rands des Fensters an Ort und Stelle darstellt). Die Berechnung des bekannt gegebenen PBP-Fensters ist wie folgt: WPC = Api W2L WPA = MAX(MIN(WPC,WPL), WPR)wobei WPC das berechnete PBP-Fenster 2901 ist, WPR das PBP-Fenster ist, das durch den Platz dargestellt wird, der vom zuvor bekannt gegebenen Fenster bleibt (d.h. aufgrund des letzten bekannt gegebenen „rechten Rands"), WPL die konfigurierte bekannt gegebene PBP-Fenster-Obergrenze ist und WPA das PBP-Fenster ist, das tatsächlich bekannt gegeben wird.
  • 30 stellt ein Computersystem 3001 dar, mit dem eine Ausführungsform gemäß der vorliegenden Erfindung implementiert werden kann. Ein solches Computersystem 3001 kann als Server konfiguriert sein, um einen Code auszuführen, der die PEP-Funktionen des PEP-Endpunkts 210 durchführt wie vorstehend erörtert. Das Computersystem 3001 schließt einen Bus 3003 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen und einen Prozessor 3005 ein, der mit dem Bus 3003 verkoppelt ist, um diese Informationen zu verarbeiten. Das Computersystem 3001 schließt auch einen Hauptspeicher 3007, wie einen Schreib/Lese-Speicher (RAM) oder eine andere dynamische Speichereinrichtung ein, der mit dem Bus 3003 gekoppelt ist, um Informationen und Befehle zu speichern, die vom Prozessor 3005 ausgeführt werden sollen. Darüber hinaus kann der Hauptspeicher 3007 zum Speichern vorübergehender Variablen oder anderer Zwischeninformationen während der Ausführung der Befehle, die vom Prozessor 3005 ausgeführt werden sollen, verwendet werden. Insbesondere können PEP-Steuerblöcke im Hauptspeicher 3007 gespeichert werden. Das Computersystem 3001 schließt ferner einen Festwertspeicher (ROM) 3009 oder eine andere statische Speichereinrichtung ein, die mit dem Bus 3003 gekoppelt ist, um statische Informationen und Befehle für den Prozessor 3005 zu speichern. Eine Speichereinrichtung 3011, wie eine Magnetplatte oder eine optische Platte, wird bereitgestellt und mit dem Bus 3003 gekoppelt, um Informationen und Instruktionen zu speichern.
  • Das Computersystem 3001 kann über einen Bus 3003 mit einer Anzeige 3013, wie einer Kathodenstrahlröhre (CRT) zum Anzeigen von Informationen für den einen Computernutzer gekoppelt werden. Eine Eingabeeinrichtung 3015, die alphanumerische oder andere Tasten aufweist, ist mit dem Bus 3003 verkoppelt, um Informationen und Befehlsauswahlen an den Prozessor 3005 zu übermitteln. Eine andere Art von Anwender-Eingabeeinrichtung ist eine Cursor-Steuerung 3017, wie eine Maus, ein Trackball oder Cursor-Lenkungstasten zum Übermitteln von Lenkungsinformationen und Befehlsauswahlen an den Prozessor 3005 und zum Steuern der Cursorbewegung auf der Anzeigen 3013.
  • Ausführungsformen sind auf die Verwendung eines Computersystems 3001 bezogen, um die PEP-Funktionen des PEP-Endpunkts 210 auszuführen. Gemäß einer Ausführungsform wird dieser automatische Aktualisierungsansatz durch ein Computersystem 3001 als Antwort darauf bereitgestellt, dass der Prozessor 3005 eine oder mehrere Sequenzen eines oder mehrerer Befehle, die im Hauptspeicher 3007 enthalten sind, ausführt. Diese Befehle können von einem anderen computerlesbaren Medium, wie einer Speichereinrichtung 3011 in den Hauptspeicher eingelesen werden. Die Ausführung der Befehlssequenzen, die im Hauptspeicher 3007 enthalten sind, bewirkt, dass der Prozessor 3005 die hierin beschriebenen Prozessorschritte ausführt. Ein oder mehrere Prozessoren in einer Multiprozessor-Umgebung können ebenfalls verwendet werden, um die Befehlssequenzen auszuführen, die im Hauptspeicher 3007 enthalten sind. In alternativen Ausführungsformen können fest verdrahtete Schaltungen anstelle von oder in Kombination mit Software-Befehlen verwendet werden. Somit sind die Ausführungsformen nicht auf eine bestimmte Kombination von Hardware-Verdrahtung und Software beschränkt.
  • Der Ausdruck „computerlesbares Medium", wie hierin verwendet, bezieht sich auf jedes Medium, das an der Bereitstellung von Befehlen an den Prozessor 3005 für die Ausführung der PEP-Funktionen des PEP-Endpunkts 210 beteiligt sind. Diese Medien können viele Formen haben, einschließlich von nicht-flüchtigen Medien, flüchtigen Medien und Übertragungsmedien, aber nicht darauf beschränkt. Nicht-flüchtige Medien schließen beispielsweise optische oder magnetische Scheiben, wie eine Speichervorrichtung 3011 ein. Flüchtige Medien schließen dynamische Speicher, wie einen Hauptspeicher 3007 ein. Übertragungsmedien schließen Koaxialkabel, Kupferdraht und Faser optik, einschließlich der Drähte, aus denen der Bus 3003 besteht, ein. Übertragungsmedien können auch die Form von akustischen oder von Lichtwellen haben, so wie diejenigen, die während Radiowellen- und Infrarotdatenübertragungen erzeugt werden.
  • Übliche Formen solcher computerlesbarer Medien schließen beispielsweise eine Floppy Disk, eine flexible Disk, eine Hard Disk, ein Magnetband oder ein anderes magnetisches Medium, eine CD-ROM, ein anderes optisches Medium, Lochkarten, Papierband, jedes andere physische Medium mit Lochmustern, einen RAM, einen PROM und einen EPROM, einen FLASH-EPROM, jeden anderen Speicherchip oder jede andere Speicherkassette, eine Trägerwelle, wie nachstehend beschrieben, oder jedes andere Medium, das ein Computer lesen kann, ein.
  • Es können verschiedene Formen von computerlesbaren Medien an der Beförderung einer oder mehrerer Sequenzen eines oder mehrerer auszuführender Befehle an den Prozessor 3005 beteiligt sein. Beispielsweise können sich die Befehle auf einer Magnetplatte oder einem entfernten Computer befinden. Der entfernte Computer kann die Befehle, die sich auf die Ausführung der PEP-Funktionen des PEP-Endpunkts 210 beziehen, in seinen dynamischen Speicher laden und die Befehle über eine Telefonleitung unter Verwendung eines Modems verschicken. Ein Modem, das sich lokal an einem Computersystem 3001 befindet, kann die Daten über die Telefonleitung empfangen und einen Infrarotüberträger verwenden, um die Daten in ein Infrarotsignal umzuwandeln. Ein Infrarotdetektor, der mit dem Bus 3003 gekoppelt ist, kann die Daten, die vom Infrarotsignal übermittelt werden, empfangen und die Daten auf den Bus 3003 übertragen. Der Bus 3003 übermittelt die Daten an den Hauptspeicher 3007, von dem der Prozessor 3005 die Befehle ermittelt und ausführt. Die Befehle, die vom Hauptspeicher 3007 empfangen werden, können optional in der Speichereinrichtung 3011 gespeichert werden, entweder vor oder nach Ausführung durch den Prozessor 3005.
  • Das Computersystem 3001 schließt auch eine oder mehrere Kommunikationsschnittstellen 3019 ein, die mit dem Bus 3003 gekoppelt sind. Die Kommunikationsschnittstellen 3019 stellen eine Zweiwege-Datenkommunikationskopplung an Netz werkverknüpfungen 3021 und 3022 bereit, die mit einem Local Area Network (LAN) 3023 bzw. einem Wide Area Network (WAN) 3024 verbunden sind. Das WAN 3024 kann gemäß einer Ausführungsform der vorliegenden Erfindung, ein Satellitennetz sein. Die Kommunikationsschnittstelle 3019 kann eine Netzschnittstellenkarte sein, die an einem beliebigen paketvermittelten LAN angebracht wird. Als weiteres Beispiel kann eine Kommunikationsschnittstelle 3019 eine asymmetrische digitale Teilnehmerleitungs- (ADSL-) Karte, eine dienstintegrierende digitale Netzwerk- (ISDN-) Karte, ein Kabelmodem oder ein Modem, das für Datenübertragungsverbindungen mit einer entsprechenden Art von Telefonleitung sorgt, sein. Es können auch drahtlose Verknüpfungen implementiert werden. In jeder dieser Implementierungen verschickt und empfängt die Kommunikationsschnittstelle 3019 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übermitteln, welche verschiedene Arten von Informationen darstellen.
  • Die Netzwerkverknüpfung 3021 stellt in der Regel Datenübermittlungen über eines oder mehrere Netzwerke an andere Datenvorrichtungen bereit. Beispielsweise kann die Netzwerkverknüpfung 3021 eine Verbindung durch ein lokales Netze 3023 zu einem Host-Computer 3025 oder einer Datenausrüstung, die von einem Internet-Dienstanbieter (ISP) 3027 betrieben wird, bereitstellen. Der ISP 3027 seinerseits stellt Datenübermittlungsdienste über das Internet 505 bereit. Darüber hinaus ist das LAN 3023 mit einem Intranet 3029 verknüpft. Das Intranet 3029, das LAN 3023 und das Internet 505 nutzen sämtlich elektrische, elektromagnetische oder optische Signale, welche die digitalen Datenströme übermitteln. Die Signale durch die verschiedenen Netzwerke und die Signale auf der Netzwerkverknüpfung 3021 und durch die Kommunikationsschnittstelle 3019, welche die digitalen Daten zum und vom Computersystem 3001 übermitteln, sind Beispiele für Formen von Trägerwellen, die die Informationen transportieren.
  • Das Computersystem 3001 kann über das bzw. die Netzwerk(e), die Internet-Verknüpfung 3021 und die Kommunikationsschnittstelle 3019 Nachrichten versenden und Daten, einschließlich von Programm-Code, versenden und empfangen. In dem Internetbeispiel könnte ein Server 3031 einen angeforderten Code für ein Anwendungs programm durch das Internet 505, den ISP 3027, das LAN 3023 und die Kommunikationsschnittstelle 3019 übermitteln. Der empfangene Code kann vom Prozessor 3005 wie empfangen ausgeführt werden und/oder in einer Speichervorrichtung 3011 oder einem anderen nicht-flüchtigen Speicher für die spätere Ausführung gespeichert werden. Auf diese Weise kann das Computersystem 3001 einen Anwendungs-Code in Form einer Trägerwelle erhalten. Das Computersystem 3001 kann über das bzw. die Netzwerk(e), die Netzwerkverknüpfung 3021 und die Kommunikationsschnittstelle 3019 Benachrichtigungen übermitteln und Daten, einschließlich von Programm-Code, empfangen.
  • Die hierin beschriebenen Verfahren bieten mehrere Vorteile gegenüber Versuchen des Standes der Technik, die Netzwerkleistung zu verbessern, insbesondere in einem paketvermittelten Netzwerk wie dem Internet. Ein lokaler PEP-Endpunkt und ein entfernter PEP-Endpunkt kommunizieren, um den Austausch von Daten durch eine Backbone-Verbindung durch die Nutzung von leistungsverbessernden Funktionen zu optimieren. Dieser Ansatz minimiert auf vorteilhafte Weise die Netzwerklatenz.
  • Natürlich können zahlreiche Modifikationen und Variationen der vorliegenden Erfindung angesichts der obigen Lehren durchgeführt werden. Es ist daher selbstverständlich, dass innerhalb des Bereichs der beigefügten Ansprüche die Erfindung auch auf andere Weise als hierin speziell beschrieben ausgeführt werden kann.

Claims (24)

  1. Netzwerkeinrichtung zur Erzeugung von Betriebsverbesserungen eines Kommunikationsnetzwerkes (100), wobei die Netzwerkeinrichtung folgendes enthält: Mittel zum Empfang von Nachrichten gemäß einem vorgeschriebenen Protokoll; Mittel zur Anpassung an unterschiedliche Nachrichtentypen mit veränderlichen Kopffeldlängen durch Verbrauch des Raumes eines ausdehnbaren Kopffeldbereiches (1607); Mittel zum Ausdehnen der Größe des ausdehnbaren Kopffeldbereiches (1607), wenn das Kopffeld der empfangenen Nachrichten nicht durch die vorliegende Größe des ausdehnbaren Kopffeldbereiches (1607) aufgenommen werden kann; Mittel zur Verarbeitung der Nachrichten zur Erzeugung der Betriebsverbesserungsfunktion; eine Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211), welche so konfiguriert sind, daß sie die empfangenen Nachrichten und die Nachrichten speichern, welche durch die Verarbeitungsmitttel erzeugt worden sind, wobei ein Teil der Mehrzahl der Puffer (1201, 1203, 1205, 1207, 1209, 1211) durch die Verarbeitungsmittel basierend auf der Durchführung einer bestimmten der die Betriebsverbesserung bewirkenden Funktionen anteilig benutzt werden.
  2. Netzwerkeinrichtung nach Anspruch 1, bei welcher die Mittel zum Empfang der Nachrichten eine Mehrzahl von Kommunikationsschnittstellen (3019) enthalten, welche so konfiguriert sind, daß sie Nachrichten gemäß dem vorbestimmten Protokoll empfangen und weitergeben.
  3. Netzwerkeinrichtung nach Anspruch 2, bei welcher eine Anzahl von Modulen (280, 282, 284, 286, 290, 292) ein Vortäuschungsmodul oder Spoofingmodul (280), welches zur Durchführung einer selektiven Vortäuschung konfiguriert ist, ein Verbindungsmodul, das zur Multiplexverteilung einer Mehrzahl von Verbindungen über eine gemeinsame Rückgratverbindung, ein Prioritäts-Zuteilungsmodul zur Prioritätszuteilung des Zuganges zu der Rückgratverbindung und ein Übertragungswegauswahlmodul enthält, das zur Bestimmung eines Übertragungsweges unter einer Mehrzahl von Übertragungswegen zur Übertragung der empfangenen Nachrichten ausgebildet ist.
  4. Netzwerkeinrichtung nach Anspruch 3, bei welcher die Kommunikationsschnittstellen eine Lokalbereichsnetzwerk-Schnittstelle und eine Weitbereichsschnittstelle enthalten, wobei einer der Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211) als Puffer zwischen dem Lokalbereichsnetzwerk und dem Weitbereichsnetzwerk ausgebildet ist, welcher die empfangenen Nachrichten in der Richtung vom Lokalbereichsnetzwerk zum Weitbereichsnetzwerk speichert, während ein anderer der Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211) als ein Puffer vom Weitbereichsnetzwerk zum Nahbereichsnetzwerk ausgebildet ist, der die empfangenen Nachrichten mit Bezug auf eine Richtung von dem Weitbereichsnetzwerk zu dem dem Lokalbereichsnetzwerk speichert.
  5. Netzwerkeinrichtung nach Anspruch 4, wobei das Weitbereichsnetzwerk ein Satellitennetzwerk (100) ist.
  6. Netzwerkeinrichtung nach Anspruch 2, bei welcher jede der erzeugten Nachrichten folgendes enthält: ein spezifisches Kopffeld (1401), welches plattformspezifische Information speichert; ein allgemeines Kopffeld (1403), welches Informationen speichert, die der Mehrzahl von Modulen (280, 282, 284, 286, 290, 292) bekannt sind; ein Nutzdatenfeld (1503); und ein Versatzfeld (1601b), welches den Start des Nutzdatenfeldes (1503) anzeigt.
  7. Netzwerkeinrichtung nach Anspruch 6, bei welchem das allgemeine Kopffeld (1403) folgendes enthält: ein Flaggenfeld oder Markenfeld (1601), welches die Richtung des Nachrichtenflusses anzeigt; ein Verbindungshandhabungsfeld (1603), das die Handhabung einer Rückgratverbindung bezeichnet; und ein eigentümerspezifisches Feld (1605), das eine eigentümerspezifische Kopffeldinformation speichert.
  8. Netzwerkeinrichtung nach Anspruch 2, bei welcher das bestimmte Protokoll das Transmission Controll Protocoll (TCP) ist.
  9. Verfahren zur Erzeugung von Betriebsverbesserungen eines Kommunikationsnetzwerkes (100), wobei das Verfahren folgendes umfasst: Empfangen von Nachrichten gemäß einem vorgeschriebenen Protokoll; Anpassung an unterschiedliche Nachrichtentypen mit veränderlichen Kopffeldlängen durch Verbrauch des Raumes eines ausdehnbaren Kopffeldbereiches (1607) entsprechend einem aus einer Anzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211); Ausdehnen der Größe des ausdehnbaren Kopffeldbereiches (1607), wenn die Kopffelder der empfangenen Nachrichten nicht durch die augenblickliche Größe des ausdehnbaren Kopffeldbereiches (1607) aufgenommen werden können; Verarbeiten der Nachrichten zur Erzielung der Betriebsverbesserungsfunktionen über eine Anzahl von Modulen (280, 282, 284, 286, 290, 292); und Speichern der empfangenen Nachrichten und der Nachrichten, welche durch einen der Mehrzahl von Modulen (280, 282, 284, 286, 290, 292) erzeugt worden sind, in einer Anzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211), wobei der Anteil der Anzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211) durch die Anzahl von Modulen (280, 282, 284, 286, 290, 292) basierend auf der Durchführung einer bestimmten der die Betriebsverbesserung bewirkenden Funktionen anteilmäßig benutzt wird.
  10. Verfahren nach Anspruch 9, welches weiter folgendes umfasst: Durchführen einer selektiven Spoofing-Funktion; Multiplexverarbeitung einer Mehrzahl von Verbindungen über eine gemeinsame Rückgratverbindung; Prioritätsverteilung des Zuganges zu der Rückgratverbindung; und Bestimmung eines Übertragungsweges aus einer Mehrzahl von Übertragungswegen zur Übertragung der empfangenen Nachrichten.
  11. Verfahren nach Anspruch 9, bei welchem der Schritt des Empfangens durch eine Kommunikationsschnittstelle durchgeführt wird, welche eine Lokalbereichsnetzwerkschnittstelle und/oder eine Weitbereichsnetzwerkschnittstelle, einen der Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211), welche als Puffer vom Lokalbereichsnetzwerk zum Weitbereichsnetzwerk ausgebildet sind, wobei der Puffer die empfangenen Nachrichten in der Richtung vom Lokalbereichsnetzwerk zum Weitbereichsnetzwerk speichert, einen anderen der Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211), welcher als Puffer vom Weitbereichsnetzwerk zum Lokalbereichsnetzwerk ausgebildet ist, der die empfangenen Nachrichten mit Bezug auf eine Richtung vom Weitbereichsnetzwerk zum Nahbereichsnetzwerk ausgebildet ist, enthält.
  12. Verfahren nach Anspruch 11, wobei das Weitbereichsnetzwerk ein Satellitennetzwerk (100) ist.
  13. Verfahren nach Anspruch 9, bei welchem jede der erzeugten Nachrichten folgendes umfasst: ein spezifisches Kopffeld (1401), welches plattformspezifische Information speichert; ein allgemeines Kopffeld (1403), welches Informationen speichert, die für die Mehrzahl von Modulen (280, 282, 284, 286, 290, 292) bekannt sind; ein Nutzdatenfeld (1503); und ein Versatzfeld (1601b), welches den Beginn des Nutzdatenfeldes (1503) anzeigt.
  14. Verfahren nach Anspruch 13, bei welchem das allgemeine Kopffeld (1403) folgendes enthält: ein Flaggenfeld (1601), das die Richtung des Nachrichtenflusses anzeigt; ein Verbindungshandhabungsfeld (1603), das die Handhabung einer Rückgratverbindung beschreibt; und Ein eigentümerspezifisches Feld (1605), das eigentümerspezifische Kopfdaten speichert.
  15. Verfahren nach Anspruch 9, bei welchem das vorbestimmte Protokoll in dem Schritt des Empfangens das Transmission Controll Protocoll (TCP) ist.
  16. Computerlesbares Medium, welches eine Folge oder mehrere Folgen von einem Befehl oder mehreren Befehlen zur Erzeugung von Betriebsverbesserungen eines Kommunikationsnetzwerkes (100) trägt, wobei die eine Folge oder die mehreren Folgen von einem oder mehreren Befehlen Befehle enthält bzw. enthalten, welche bei Durchführung durch einen oder mehrere Prozessoren diesen bzw. diese zu folgenden Schritten veranlassen: Empfang von Nachrichten gemäß einem vorgeschriebenen Protokoll; Anpassung an unterschiedliche Nachrichtentypen mit veränderlicher Kopffeldlänge durch Aufbrauch des Raumes eines ausdehnbaren Kopffeldbereiches (1607) entsprechend einem einer Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211); Ausdehnen der Größe des ausdehnbaren Kopffeldbereiches (1607), wenn die Kopffelder der empfangenen Nachrichten nicht durch die gegenwärtige Größe des ausdehnbaren Kopffeldbereiches (1607) aufgenommen werden können; Verarbeiten der Nachrichten zur Erzeugung der Verarbeitungsverbesserungsfunktionen über eine Mehrzahl von Modulen (280, 282, 284, 286, 290, 292), wobei die Nachrichten ein Kopffeld veränderlicher Länge enthalten; und Speichern der empfangenen Nachrichten und der Nachrichten, welche durch einen der Mehrzahl von Modulen (280, 282, 284, 286, 290, 292) erzeugt werden, in einer Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211), wobei ein Anteil der Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211) durch die Mehrzahl von Modulen (280, 282, 284, 286, 290, 292) basierend auf der Durchführung einer bestimmten der die Betriebsweise verbessernden Funtktionen anteilsmäßig benutzt wird.
  17. Computerlesbares Medium nach Anspruch 16, wobei der eine oder die mehreren Prozessoren weiter folgende Schritte durchführen: Durchführen einer selektiven Spoofing-Funktion; Multiplexverarbeitung einer Mehrzahl von Verbindungen über eine gemeinsame Rückgratverbindung; Prioritätsverteilung des Zugriffes zu der Rückgratverbindung; und Bestimmen eines Übertragungsweges aus einer Mehrzahl von Übertragungswegen zur Übertragung der empfangenen Nachrichten.
  18. Computerlesbares Medium nach Anspruch 16, wobei der Schritt des empfangens durch eine Kommunikationsschnittstelle durchgeführt wird, welche eine Lokalbereichsschnittstelle (LAN) und/oder eine Weitbereichsschnittstelle (WAN), ferner einen aus einer Mehrzahl von Puffern (1201, 1203, 1205, 1207, 1209, 1211), der als ein LAN-zu-WAN-Puffer bezeichnet ist, welcher die empfangenen Nachrichten mit Bezug auf eine LAN-zu-WAN-Richtung speichert, einen anderen aus der Mehrzahl von Puffern Puffern (1201, 1203, 1205, 1207, 1209, 1211), der als ein WAN-zu-LAN-Puffer bezeichnet ist, welcher die empfangenen Nachrichten in der WAN-zu-LAN-Richtung speichert, enthält.
  19. Computerlesbares Medium nach Anspruch 18, wobei das weitbereichsnetzwerk (WAN) ein Satelitennetzwerk (100) ist.
  20. Computerlesbares Medium nach Anspruch 16, bei welchem jede der erzeugten Nachrichten folgendes enthält: Ein spezifisches Kopffeld (1401), das plattformspezifische Information speichert; Ein allgemeines Kopffeld (1403), welches Information speichert, die für eine Mehzahl von Modulen (280, 282, 284, 286, 290, 292) bekannt ist; Ein Nutzdatenfeld (1503); und ein Versatzfeld (1601b), welches den Beginn des Nutzdatenfeldes (1503) anzeigt.
  21. Computerlesbares Medium nach Anspruch 20, bei welchem das allgemeine Kopffeld (1403) folgendes umfaßt: ein Flaggenfeld oder Markenfeld (1601), welches die Richtung des Nachrichtenflusses anzeigt; ein Verbindungshandhabungsfeld (1603), welches die Handhabung einer Rückgratverbindung beschreibt; und ein eigentümerspezifisches Feld (1605), welches eine eigentümerspezifische Kopfinformation speichert.
  22. Computerlesbares Medium nach Anspruch 16, bei welchem, das vorgeschriebene Protokoll in dem Empfangsschritt das Transmission Control Protocol (TCP) ist.
  23. Ein Digitalsignal zur Vermittlung von Information zur Erzeugung einer Betriebsverbesserung in einem Kommunikationsnetzwerk (100), wobei das Signal eine Struktur aufweist, welche ein Kopfteil mit veränderlicher Länge besitzt und die Struktur folgendes enthält: ein spezifisches Kopffeld (1401), welches eine plattformspezifische Information speichert; ein allgemeines Kopffeld (1403), das Information speichert, welche für eine Mehrzahl von Modulen (280, 282, 84, 86, 89) bekannt ist; ein Nutzdatenfeld (1503); ein Versatzfeld (1601b), welches den Beginn des Nutzdatenfeldes (1503) anzeigt; und einen ausdehnbaren Kopffeldbereich (1607), welcher sich der veränderlichen Länge der Kopfdateninformation anpaßt.
  24. Digitalsignal nach Anspruch 23, bei welchem das allgemeine Kopffeld (1403) folgendes umfaßt: ein Flaggenfeld oder Markenfeld (1601), das die Richtung des Nachrichtenflusses anzeigt; ein Verbindungshandhabungsfeld (1603), welches die Handhabung einer Rückgratverbindung beschreibt; und ein eigentümerspezifisches Feld (1605), welches eine eigentümerspezifische Kopfinformation speichert.
DE60117485T 2000-07-21 2001-07-20 Verfahren und Vorrichtung zur Pufferverwaltung Expired - Fee Related DE60117485T2 (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
DE60117485D1 DE60117485D1 (de) 2006-04-27
DE60117485T2 true DE60117485T2 (de) 2006-10-12

Family

ID=26914502

Family Applications (8)

Application Number Title Priority Date Filing Date
DE60117485T Expired - Fee Related DE60117485T2 (de) 2000-07-21 2001-07-20 Verfahren und Vorrichtung zur Pufferverwaltung
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
DE60117723T Expired - Lifetime DE60117723D1 (de) 2000-07-21 2001-07-20 Verfahren und system zur Setzung von Verkehrsprioritäten in einem Netz
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
DE60116447T Expired - Fee Related DE60116447T2 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbindungsbehandlung
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
DE60117722T Expired - Lifetime DE60117722D1 (de) 2000-07-21 2001-07-20 Netzwerkverwaltung einer leistungssteigernden Proxy-Architektur

Family Applications After (7)

Application Number Title Priority Date Filing Date
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
DE60117723T Expired - Lifetime DE60117723D1 (de) 2000-07-21 2001-07-20 Verfahren und system zur Setzung von Verkehrsprioritäten in einem Netz
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
DE60116447T Expired - Fee Related DE60116447T2 (de) 2000-07-21 2001-07-20 Verfahren und System zur Verbindungsbehandlung
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
DE60117722T Expired - Lifetime DE60117722D1 (de) 2000-07-21 2001-07-20 Netzwerkverwaltung einer leistungssteigernden Proxy-Architektur

Country Status (5)

Country Link
US (8) US20020038373A1 (de)
EP (8) EP1175042B1 (de)
CA (8) CA2353332A1 (de)
DE (8) DE60117485T2 (de)
IL (8) IL144435A0 (de)

Families Citing this family (346)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2001253613A1 (en) * 2000-04-17 2001-10-30 Circadence Corporation System and method for shifting functionality between multiple web servers
US8024481B2 (en) * 2000-04-17 2011-09-20 Circadence Corporation System and method for reducing traffic and congestion on distributed interactive simulation networks
US8996705B2 (en) 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
US8195823B2 (en) * 2000-04-17 2012-06-05 Circadence Corporation Dynamic network link acceleration
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
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
US20020038373A1 (en) * 2000-07-21 2002-03-28 John Border Method and system for improving network performance enhancing proxy architecture with gateway redundancy
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
US7349994B2 (en) * 2000-10-17 2008-03-25 Avaya Technology Corp. Method and apparatus for coordinating routing parameters via a back-channel communication medium
US8023421B2 (en) * 2002-07-25 2011-09-20 Avaya Inc. Method and apparatus for the assessment and optimization of network traffic
US7756032B2 (en) 2000-10-17 2010-07-13 Avaya Inc. Method and apparatus for communicating data within measurement traffic
US7487237B2 (en) * 2000-10-17 2009-02-03 Avaya Technology Corp. Load optimization
US7336613B2 (en) * 2000-10-17 2008-02-26 Avaya Technology Corp. Method and apparatus for the assessment and optimization of network traffic
ATE459154T1 (de) 2000-10-17 2010-03-15 Avaya Technology Corp Verfahren und vorrichtung zur optimierung der leistung und des kosten in einem internetzwerk
US7406539B2 (en) * 2000-10-17 2008-07-29 Avaya Technology Corp. Method and apparatus for performance and cost optimization in an internetwork
US7720959B2 (en) * 2000-10-17 2010-05-18 Avaya Inc. Method and apparatus for characterizing the quality of a network path
US7839890B1 (en) * 2000-11-02 2010-11-23 Fisher-Rosemount Systems, Inc. Multiplexed data transmissions through a communication link
US20020087724A1 (en) * 2000-12-29 2002-07-04 Ragula Systems D/B/A Fatpipe Networks Combining connections for parallel access to multiple frame relay and other private networks
WO2002076038A1 (en) * 2001-03-19 2002-09-26 Bob Tang A method for guaranteeing quality of service on the internet by routing data along nodes without error correction processing capability
US7269157B2 (en) 2001-04-10 2007-09-11 Internap Network Services Corporation System and method to assure network service levels with intelligent routing
FI115271B (fi) * 2001-05-28 2005-03-31 Nokia Corp Menetelmä ja järjestelmä nopean elpymisprosessin toteuttamiseksi lähiverkossa
EP1415232B1 (de) * 2001-08-08 2015-01-14 Flash Networks Ltd. SYSTEM UND VERFAHREN ZUr BESCHLEUNIGUNG DER ÜBERMITTLUNG VON INHALT AUF TCP/IP-BASIS
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
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
US7561517B2 (en) 2001-11-02 2009-07-14 Internap Network Services Corporation Passive route control of data networks
US7668966B2 (en) * 2001-11-02 2010-02-23 Internap Network Services Corporation Data network controller
CN100518108C (zh) * 2001-11-12 2009-07-22 艾利森电话股份有限公司 在ieee802.11系统中提供服务质量的方法
WO2003043285A2 (en) * 2001-11-13 2003-05-22 Ems Technologies, Inc. Flow control between performance enhancing proxies over variable bandwidth split links
US7221675B2 (en) * 2001-12-07 2007-05-22 Nortel Networks Limited Address resolution method for a virtual private network, and customer edge device for implementing the method
EP1328091B1 (de) * 2002-01-11 2008-11-19 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
US7389533B2 (en) * 2002-01-28 2008-06-17 Hughes Network Systems, Llc Method and system for adaptively applying performance enhancing functions
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)
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
US20030219022A1 (en) * 2002-01-28 2003-11-27 Hughes Electronics Method and system for utilizing virtual private network (VPN) connections in a performance enhanced network
US7730063B2 (en) * 2002-12-10 2010-06-01 Asset Trust, Inc. Personalized medicine service
SE0200696D0 (sv) * 2002-03-06 2002-03-06 Ericsson Telefon Ab L M Method and system of load control
US7103674B2 (en) * 2002-03-28 2006-09-05 International Business Machines Corporation Apparatus and method of reducing dataflow distruption when detecting path maximum transmission unit (PMTU)
KR100453056B1 (ko) * 2002-03-29 2004-10-15 삼성전자주식회사 동적 ｉｐ 네트워크 상에서의 ｐｍｔｕ 변경 방법 및 그장치
US7543087B2 (en) * 2002-04-22 2009-06-02 Alacritech, Inc. Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote device
US8140888B1 (en) * 2002-05-10 2012-03-20 Cisco Technology, Inc. High availability network processing system
US20040105445A1 (en) * 2002-06-19 2004-06-03 Jeremy Wyn-Harris Internet protocol for resource-constrained devices
US9088494B2 (en) * 2002-06-26 2015-07-21 Avaya Communication Israel Ltd. Packet fragmentation prevention
US7512120B2 (en) * 2002-07-09 2009-03-31 Ntt Docomo, Inc. Node, correspondent node, mobility anchor point, and home agent in packet communication system, packet communication system, and path MTU discovery method
JP2004056306A (ja) * 2002-07-17 2004-02-19 Ntt Docomo Inc 通信制御システム、通信制御方法、中継装置及び通信制御プログラム
FR2842683B1 (fr) * 2002-07-22 2005-01-14 Cit Alcatel Dispositif de multiplexage, dispositif de multiplexage et systeme de multiplexage/demultiplexage
US7305464B2 (en) * 2002-09-03 2007-12-04 End Ii End Communications, Inc. Systems and methods for broadband network optimization
US7653012B2 (en) * 2002-09-26 2010-01-26 Sharp Laboratories Of America, Inc. Relay transmission of data in a centralized network
US20040081089A1 (en) * 2002-09-26 2004-04-29 Sharp Laboratories Of America, Inc. Transmitting data on scheduled channels in a centralized network
US7542471B2 (en) * 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US8233392B2 (en) * 2003-07-29 2012-07-31 Citrix Systems, Inc. Transaction boundary detection for reduction in timeout penalties
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
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
US8090809B2 (en) * 2002-11-04 2012-01-03 Riverbed Technology, Inc. Role grouping
US7949737B2 (en) * 2002-11-04 2011-05-24 Riverbed Technology, Inc. Method and apparatus for grouping nodes based on connection characteristics
CA2506555C (en) * 2002-11-08 2018-08-14 Arbitration Forums, Inc. A system and process for electronic subrogation, inter-organization workflow management, inter-organization transaction processing and optimized web-based user interaction
WO2004056047A1 (en) * 2002-12-13 2004-07-01 Internap Network Services Corporation Topology aware route control
US7295510B2 (en) * 2002-12-17 2007-11-13 At&T Corporation Method of estimating restoration capacity in a network
WO2004064333A1 (ja) * 2003-01-10 2004-07-29 Sharp Kabushiki Kaisha 通信装置、ネットワークシステム、通信管理方法、要求信号、応答信号、プログラム、および、プログラムを記録した記録媒体
EP1595372B1 (de) * 2003-02-03 2006-10-04 Telefonaktiebolaget LM Ericsson (publ) Shared-risk-gruppenhandhabung in einem media-gateway
US8605647B2 (en) 2004-02-03 2013-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Shared risk group handling within a media gateway
US6965564B2 (en) 2003-02-14 2005-11-15 America Online, Inc. Wireless datagram transaction protocol system
US7490163B2 (en) * 2003-03-20 2009-02-10 Telefonaktiebolaget L M Ericsson (Publ) Data unit transmission method and device
CN1300986C (zh) * 2003-04-14 2007-02-14 华为技术有限公司 实现快速五七层交换的方法
US7248589B2 (en) * 2003-06-05 2007-07-24 International Business Machines Corporation Apparatus for enabling multi-tuple TCP sockets within a computer network
US20050055371A1 (en) * 2003-06-05 2005-03-10 Singam Sunder Method and system to manage a network connection application
US20040264368A1 (en) * 2003-06-30 2004-12-30 Nokia Corporation Data transfer optimization in packet data networks
WO2005013083A2 (en) 2003-07-29 2005-02-10 Orbital Data Corporation Flow control architecture
US7698453B2 (en) * 2003-07-29 2010-04-13 Oribital Data Corporation Early generation of acknowledgements for flow control
US8238241B2 (en) * 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US7656799B2 (en) 2003-07-29 2010-02-02 Citrix Systems, Inc. Flow control system architecture
US8432800B2 (en) * 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
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
US7468948B2 (en) * 2003-09-17 2008-12-23 Steven A Rogers Empirical scheduling of network packets using coarse and fine testing periods
US7529247B2 (en) * 2003-09-17 2009-05-05 Rivulet Communications, Inc. Empirical scheduling of network packets
BRPI0415333A (pt) * 2003-10-09 2006-12-05 Lg Electronics Inc método e aparato para geração de plcm para serviços de radiodifusão/multidifusão
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
WO2005057880A2 (en) 2003-12-08 2005-06-23 Broadcom Corporation Interface between ethernet and storage area network
EP1545059B1 (de) * 2003-12-16 2007-03-07 Alcatel Anordnung mit einem Terminal, einem Zugangsmultiplexer und einem Netzwerk
US20050141551A1 (en) * 2003-12-29 2005-06-30 Mcneil Roy Jr. Common LAN architecture and flow control relay
KR100602651B1 (ko) * 2004-02-13 2006-07-19 삼성전자주식회사 Ｔｃｐ 커넥션 관리 장치 및 방법
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
EP1771979B1 (de) 2004-07-23 2011-11-23 Citrix Systems, Inc. Verfahren und system zur sicherung von zugriff aus der ferne auf private netze
EP1771998B1 (de) 2004-07-23 2015-04-15 Citrix Systems, Inc. Systeme und verfahren zur kommunikationsoptimierung zwischen netzwerkknoten
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
WO2006029399A2 (en) * 2004-09-09 2006-03-16 Avaya Technology Corp. Methods of and systems for network traffic security
US8024483B1 (en) 2004-10-01 2011-09-20 F5 Networks, Inc. Selective compression for network connections
US7453885B2 (en) * 2004-10-13 2008-11-18 Rivulet Communications, Inc. Network connection device
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
US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary
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
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
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
US20060253605A1 (en) * 2004-12-30 2006-11-09 Prabakar Sundarrajan Systems and methods for providing integrated client-side acceleration techniques to access remote applications
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
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
US8064459B2 (en) * 2005-07-18 2011-11-22 Broadcom Israel Research Ltd. Method and system for transparent TCP offload with transmit and receive coupling
US8392684B2 (en) 2005-08-12 2013-03-05 Silver Peak Systems, Inc. Data encryption in a network memory architecture for providing data based on local accessibility
US8095774B1 (en) 2007-07-05 2012-01-10 Silver Peak Systems, Inc. Pre-fetching data into a memory
US8171238B1 (en) 2007-07-05 2012-05-01 Silver Peak Systems, Inc. Identification of data stored in memory
JP2007081678A (ja) * 2005-09-13 2007-03-29 Ntt Docomo Inc データ中継装置及びデータ中継方法
US8335576B1 (en) * 2005-09-22 2012-12-18 Teradici Corporation Methods and apparatus for bridging an audio controller
US20070071026A1 (en) * 2005-09-23 2007-03-29 Rivulet Communications, Inc. Compressed video packet scheduling system
US8250229B2 (en) * 2005-09-29 2012-08-21 International Business Machines Corporation Internet protocol security (IPSEC) packet processing for multiple clients sharing a single network address
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
US8301839B2 (en) 2005-12-30 2012-10-30 Citrix Systems, Inc. System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
US7921184B2 (en) 2005-12-30 2011-04-05 Citrix Systems, Inc. System and method for performing flash crowd caching of dynamically generated objects in a data communication network
JP4984531B2 (ja) * 2006-01-06 2012-07-25 富士通株式会社 サーバ監視プログラム、中継装置、サーバ監視方法
US8199731B2 (en) * 2006-01-25 2012-06-12 Motorola Mobility, Inc. Method and apparatus for facilitating switched packet data services on multiple networks
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
US8238242B2 (en) 2006-02-27 2012-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Flow control mechanism using local and global acknowledgements
AU2007281084B2 (en) * 2006-03-06 2012-02-02 Marc Timothy Turk Data message management system
US20070226347A1 (en) * 2006-03-23 2007-09-27 Chu Hsiao-Keng J Method and apparatus for dynamically changing the TCP behavior of a network connection
US20070233886A1 (en) * 2006-04-04 2007-10-04 Fan Kan F Method and system for a one bit TCP offload
US8004973B2 (en) * 2006-04-25 2011-08-23 Citrix Systems, Inc. Virtual inline configuration for a network device
US7650406B2 (en) * 2006-04-26 2010-01-19 Microsoft Corporation Termination of a security association between devices
US7596628B2 (en) * 2006-05-01 2009-09-29 Broadcom Corporation Method and system for transparent TCP offload (TTO) with a user space library
US7756134B2 (en) 2006-05-02 2010-07-13 Harris Corporation Systems and methods for close queuing to support quality of service
US7894509B2 (en) * 2006-05-18 2011-02-22 Harris Corporation Method and system for functional redundancy based quality of service
US20070291768A1 (en) * 2006-06-16 2007-12-20 Harris Corporation Method and system for content-based differentiation and sequencing as a mechanism of prioritization for QOS
US7990860B2 (en) 2006-06-16 2011-08-02 Harris Corporation Method and system for rule-based sequencing for QoS
US8064464B2 (en) 2006-06-16 2011-11-22 Harris Corporation Method and system for inbound content-based QoS
US8516153B2 (en) 2006-06-16 2013-08-20 Harris Corporation Method and system for network-independent QoS
US7856012B2 (en) 2006-06-16 2010-12-21 Harris Corporation System and methods for generic data transparent rules to support quality of service
CA2655880A1 (en) * 2006-06-19 2007-12-27 Liquid Computing Corporation Methods and systems for reliable data transmission using selective retransmission
US7916626B2 (en) 2006-06-19 2011-03-29 Harris Corporation Method and system for fault-tolerant quality of service
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
CN101573922A (zh) * 2006-10-06 2009-11-04 维尔塞特公司 用于多速率下行数据流中出站链路速率调整的动态反馈
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
CA2674361A1 (en) * 2006-11-08 2008-05-15 The Regents Of The University Of California Complex network mapping
US7664857B2 (en) * 2007-01-26 2010-02-16 Citrix Systems, Inc. Systems and methods of using an IP ID field for automatic WAN/LAN detection
US9344356B2 (en) * 2007-02-28 2016-05-17 Hewlett Packard Enterprise Development Lp Transmitting a packet from a distributed trunk switch
US7870277B2 (en) * 2007-03-12 2011-01-11 Citrix Systems, Inc. Systems and methods for using object oriented expressions to configure application security policies
US7706266B2 (en) 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
US7853679B2 (en) * 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring handling of undefined policy events
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
US8490148B2 (en) 2007-03-12 2013-07-16 Citrix Systems, Inc Systems and methods for managing application security profiles
US7853678B2 (en) * 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring flow control of policy expressions
US8631147B2 (en) 2007-03-12 2014-01-14 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
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
US8743683B1 (en) 2008-07-03 2014-06-03 Silver Peak Systems, Inc. Quality of service using multiple flows
US10164861B2 (en) 2015-12-28 2018-12-25 Silver Peak Systems, Inc. Dynamic monitoring and visualization for network health characteristics
US9717021B2 (en) 2008-07-03 2017-07-25 Silver Peak Systems, Inc. Virtual network overlay
US10805840B2 (en) 2008-07-03 2020-10-13 Silver Peak Systems, Inc. Data transmission via a virtual wide area network overlay
FR2933834A1 (fr) * 2008-07-11 2010-01-15 Canon Kk Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants.
CN101631065B (zh) * 2008-07-16 2012-04-18 华为技术有限公司 一种无线多跳网络拥塞的控制方法和装置
US8407721B2 (en) 2008-12-12 2013-03-26 Microsoft Corporation Communication interface selection on multi-homed devices
TW201031141A (en) * 2009-02-04 2010-08-16 Univ Nat Taiwan Packets inspection device and method
EP2416532B1 (de) * 2009-03-30 2014-10-08 Nec Corporation Kommunikationsfluss-steuersystem, kommunikationsfluss-steuerverfahren und kommunikationsfluss-verarbeitungsprogramm
FR2950215B1 (fr) * 2009-09-11 2011-11-25 Thales Sa Procede et systeme pour le controle de l'acheminement d'un flux de donnees d'une classe de service a travers un reseau maille et chiffre
US9940670B2 (en) 2009-12-10 2018-04-10 Royal Bank Of Canada Synchronized processing of data by networked computing resources
SG10201704581VA (en) 2009-12-10 2017-07-28 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
US8719401B1 (en) 2010-07-12 2014-05-06 Vmware, Inc. Decentralized input/output resource management
US8417812B1 (en) * 2010-07-12 2013-04-09 Vmware, Inc. Methods and systems for detecting anomalies during IO accesses
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
US8965285B2 (en) 2011-05-13 2015-02-24 Nokia Corporation Touch inquiry
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
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
EP2798797B1 (de) * 2011-12-29 2016-04-06 Thomson Licensing Netzwerk-gateway und verfahren zur übertragung von paketen eines datenstroms
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
CN108601043B (zh) * 2012-09-28 2022-01-14 瞻博网络公司 用于控制无线接入点的方法和设备
EP2725868B1 (de) * 2012-10-24 2017-10-04 BlackBerry Limited System und Verfahren zur Steuerung des Verbindungs-Timeouts in einem Kommunikationsnetzwerk
JP2014096674A (ja) * 2012-11-08 2014-05-22 Hitachi High-Technologies Corp ネットワーク装置、ネットワーク装置の制御方法及びネットワークシステム
US9769034B2 (en) 2012-12-14 2017-09-19 Futurewei Technologies, Inc. Method and apparatus for policy based routing in information centric networking based home networks
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
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
US9369342B2 (en) 2013-11-15 2016-06-14 Microsoft Technology Licensing, Llc Configuring captive portals with a cloud service
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 腾讯科技（深圳）有限公司 传输数据的方法及系统
CN105917599B (zh) * 2014-01-16 2020-01-10 三星电子株式会社 无连接通信系统中操作用户面协议栈的装置和方法
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
US10280273B2 (en) * 2014-07-25 2019-05-07 Mitsubishi Chemical Corporation Gas barrier multilayer film
US9948496B1 (en) 2014-07-30 2018-04-17 Silver Peak Systems, Inc. Determining a transit appliance for data traffic to a software service
US9875344B1 (en) 2014-09-05 2018-01-23 Silver Peak Systems, Inc. Dynamic monitoring and authorization of an optimization device
JP6179492B2 (ja) * 2014-09-11 2017-08-16 コニカミノルタ株式会社 通信中継装置、プログラム及び通信中継方法
EP3198464B1 (de) * 2014-09-25 2019-02-06 Hughes Network Systems, LLC Anwendungsbewusstes multihoming für datenverkehrsbeschleunigung in datenkommunikationsnetzen
US9265080B1 (en) 2014-10-01 2016-02-16 Nokia Technologies Oy Method, apparatus, and computer program product for multi-device output mode configuration
US10924408B2 (en) 2014-11-07 2021-02-16 Noction, Inc. System and method for optimizing traffic in packet-switched networks with internet exchanges
US10116577B2 (en) * 2014-12-04 2018-10-30 Dell Products Lp Detecting path MTU mismatch at first-hop router
US10798000B2 (en) * 2014-12-22 2020-10-06 Arista Networks, Inc. Method and apparatus of compressing network forwarding entry information
US9755731B2 (en) * 2015-01-10 2017-09-05 Hughes Network Systems, Llc Hardware TCP accelerator
US9769070B2 (en) 2015-01-28 2017-09-19 Maxim Basunov System and method of providing a platform for optimizing traffic through a computer network with distributed routing domains interconnected through data center interconnect links
US10171333B2 (en) 2015-02-10 2019-01-01 International Business Machines Corporation Determining connection feasibility and selection between different connection types
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
WO2016172252A1 (en) * 2015-04-20 2016-10-27 Shoelace Wireless, Inc. Systems for improved mobile internet speed 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
US10203862B2 (en) 2015-10-06 2019-02-12 Casbu, LLC Multi-level constrained communication system
US9385976B1 (en) 2015-10-09 2016-07-05 Machine Zone, Inc. Systems and methods for storing message data
US9319365B1 (en) 2015-10-09 2016-04-19 Machine Zone, Inc. Systems and methods for storing and transferring 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
CN106134247A (zh) * 2016-06-29 2016-11-16 北京小米移动软件有限公司 信息下发方法、数据发送方法、装置及系统
US9608928B1 (en) * 2016-07-06 2017-03-28 Machine Zone, Inc. Multiple-speed message channel of messaging system
US10511521B2 (en) 2016-08-03 2019-12-17 Anchorfree Inc. System and method for virtual multipath data transport
US9967203B2 (en) 2016-08-08 2018-05-08 Satori Worldwide, Llc Access control for message channels in a messaging system
US9967056B1 (en) 2016-08-19 2018-05-08 Silver Peak Systems, Inc. Forward packet recovery with constrained overhead
US10374986B2 (en) 2016-08-23 2019-08-06 Satori Worldwide, Llc Scalable, real-time messaging system
US10305981B2 (en) 2016-08-31 2019-05-28 Satori Worldwide, Llc Data replication in scalable messaging system
US9667681B1 (en) 2016-09-23 2017-05-30 Machine Zone, Inc. Systems and methods for providing messages to multiple subscribers
US10594616B2 (en) * 2016-09-30 2020-03-17 Hughes Network Systems, LLC. Data buffering control system and method for a communication network
US10454804B2 (en) 2016-11-07 2019-10-22 Hughes Network Systems, Llc Application characterization using transport protocol analysis
US10205804B2 (en) 2017-02-01 2019-02-12 Hughes Network Systems, Llc Methods and systems for enhanced support of TCP options in a TCP spoofed system
US10892978B2 (en) 2017-02-06 2021-01-12 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows from first packet data
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
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
US10187278B2 (en) 2017-02-24 2019-01-22 Satori Worldwide, Llc Channel management in scalable messaging system
US10270726B2 (en) 2017-02-24 2019-04-23 Satori Worldwide, Llc Selective distribution of messages in a scalable, real-time messaging system
US10447623B2 (en) 2017-02-24 2019-10-15 Satori Worldwide, Llc Data storage systems and methods using a real-time messaging system
CN107241268B (zh) * 2017-07-20 2020-05-12 北京航空航天大学 基于星基ads-b报文卫星网络的局部多径路由方法和装置
US10581978B2 (en) * 2017-07-31 2020-03-03 Hughes Network Systems, Llc Smart spoofing to improve spoofing performance when resources are scarce
US11212210B2 (en) 2017-09-21 2021-12-28 Silver Peak Systems, Inc. Selective route exporting using source type
US11032257B1 (en) 2017-12-08 2021-06-08 Rankin Labs, Llc Method for covertly delivering a packet of data over a network
US11861025B1 (en) 2018-01-08 2024-01-02 Rankin Labs, Llc System and method for receiving and processing a signal within a TCP/IP protocol stack
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
WO2019168978A1 (en) 2018-02-28 2019-09-06 John Rankin System and method for expanding a set of random values
US10637721B2 (en) 2018-03-12 2020-04-28 Silver Peak Systems, Inc. Detecting path break conditions while minimizing network overhead
WO2019183543A1 (en) 2018-03-23 2019-09-26 John Rankin System and method for identifying a speaker's community of origin from a sound sample
US11165625B2 (en) * 2018-06-28 2021-11-02 Juniper Networks, Inc. Network state management
US11379279B2 (en) 2018-06-28 2022-07-05 Juniper Networks, Inc. Netlink asynchronous notifications for native and third party application in distributed network systems
US11341985B2 (en) 2018-07-10 2022-05-24 Rankin Labs, Llc System and method for indexing sound fragments containing speech
US10728220B2 (en) 2018-08-10 2020-07-28 John Rankin System and method for covertly transmitting a payload of data
US11689543B2 (en) 2018-08-10 2023-06-27 Rankin Labs, Llc System and method for detecting transmission of a covert payload of data
US11652732B2 (en) 2018-08-21 2023-05-16 Rankin Labs, Llc System and method for scattering network traffic across a number of disparate hosts
US10819420B2 (en) 2018-10-09 2020-10-27 Hughes Network Systems, Llc Multipath satellite backbone
US11031998B2 (en) * 2018-10-09 2021-06-08 Hughes Network Systems, Llc Bonding and redundancy for satellite transport paths
ES2881255T3 (es) * 2018-10-24 2021-11-29 Acklio Protocolo de comunicación simple para la transmisión de datos a través de redes limitadas
CN109147284B (zh) * 2018-10-30 2020-07-14 宁波三星智能电气有限公司 一种智能电表的上报方法
US10903977B2 (en) 2018-12-19 2021-01-26 Rankin Labs, Llc Hidden electronic file systems
US10848345B2 (en) 2018-12-31 2020-11-24 Hughes Network Systems, Llc Multi-protocol encapsulation traffic acceleration and optimization
US11526357B2 (en) 2019-01-21 2022-12-13 Rankin Labs, Llc Systems and methods for controlling machine operations within a multi-dimensional memory space
WO2020154223A1 (en) 2019-01-21 2020-07-30 John Rankin Systems and methods for processing network traffic using dynamic memory
WO2020154219A1 (en) 2019-01-21 2020-07-30 John Rankin Systems and methods for controlling machine operations
US10908133B2 (en) 2019-04-17 2021-02-02 Rankin Labs, Llc System and method for detecting hidden chemicals within objects in a non-invasive manner
US11487674B2 (en) 2019-04-17 2022-11-01 Rankin Labs, Llc Virtual memory pool within a network which is accessible from multiple platforms
US11729184B2 (en) 2019-05-28 2023-08-15 Rankin Labs, Llc Detecting covertly stored payloads of data within a network
US11055166B2 (en) 2019-05-28 2021-07-06 Rankin Labs, Llc Covertly storing a payload of data within a network
WO2020243244A1 (en) 2019-05-28 2020-12-03 John Rankin Supporting a virtual memory area at a remote computing machine
WO2021025728A1 (en) 2019-08-07 2021-02-11 John Rankin System and method for indirect advertising
US11105934B2 (en) 2019-08-07 2021-08-31 Rankin Labs, Llc Determining proximity and attraction of objects within a coordinate system
US11012361B2 (en) 2019-08-29 2021-05-18 Hughes Network Systems, Llc Managing transmission control protocol (TCP) traffic
CN111092645B (zh) * 2019-11-18 2022-04-19 航天恒星科技有限公司 一种卫星通信系统实时监控处理系统
US11863428B2 (en) * 2019-11-22 2024-01-02 Vmware, Inc. Dynamic route configuration and load balancing for edge gateways
US10911134B1 (en) * 2019-12-31 2021-02-02 Hughes Network Systems, Llc System and method for efficient and scalable VSAT real-time monitoring (VRTM)
US11699037B2 (en) 2020-03-09 2023-07-11 Rankin Labs, Llc Systems and methods for morpheme reflective engagement response for revision and transmission of a recording to a target individual
CN112769651B (zh) * 2021-01-13 2022-04-26 杭州迪普科技股份有限公司 一种tcp连接检测方法、装置及电子设备

Family Cites Families (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0490980B1 (de) * 1989-09-08 1999-05-06 Auspex Systems, Inc. Betriebssystemaufbau mit mehreren verarbeitungseinheiten
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
US6701370B1 (en) * 1994-06-08 2004-03-02 Hughes Electronics Corporation Network system with TCP/IP protocol spoofing
WO1995034153A1 (en) 1994-06-08 1995-12-14 Hughes Aircraft Company Apparatus and method for hybrid network access
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
CA2304214C (en) * 1997-09-16 2006-05-23 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
US20020038373A1 (en) * 2000-07-21 2002-03-28 John Border Method and system for improving network performance enhancing proxy architecture with gateway redundancy

Also Published As

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

Similar Documents

Publication Publication Date Title
DE60117485T2 (de) Verfahren und Vorrichtung zur Pufferverwaltung
DE112013000398B4 (de) Multisprung-Fehlerbehebung
DE60305378T2 (de) Verfahren zum Weitergeben von einem Netzwerkstapel
EP0885505B1 (de) Verfahren zur übertragung eines datenpakets im ethernet von einer ersten anordnung zu mindestens einer zweiten anordnung
DE19983404B4 (de) Verfahren und Vorrichtung zur Verwendung bei der Einstellung eines TCP Gleitfensters
DE60307032T2 (de) Steuerungs-Verfahren und -Vorrichtung zur Datenübertragung
DE69727447T2 (de) Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung
EP1232628B1 (de) Verfahren zur Verbesserung von Leistung
DE60108324T2 (de) System und Verfahren zur Erhöhung von Nachrichtendurchsatz in einem Funknetzwerk
DE60318252T2 (de) Verfahren und vorrichtungen zur datenübertragung zwischen speichernetzwerken
DE69921183T2 (de) Schnurloses teilnehmeranschluss-system und hierfür nützliches verfahren
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
EP3840303B1 (de) Datenübertragungseinrichtung, datenempfangseinrichtung und sendeverfahren zum übertragen von datenpaketen durch einen tunnel
DE10218811B4 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem funkgestützten Kommunikationssystem bei Verwendung eines PEP
EP1357719A1 (de) Verfahren und Vorrichtung zum Übertragen von Datenpaketen in einem Kommunikationssystem bei Verwendung PEP und eines RAN
DE10305456A1 (de) Vorrichtung und Verfahren zur Optimierung einer Datenübertragung und von Speicheranforderungen in einer Anordnung mit Client-Einrichtung und Server-Einrichtung

Legal Events

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