USRE39501E1 - Multiple network protocol encoder/decoder and data processor - Google Patents

Multiple network protocol encoder/decoder and data processor Download PDF

Info

Publication number
USRE39501E1
USRE39501E1 US10/093,340 US9334002A USRE39501E US RE39501 E1 USRE39501 E1 US RE39501E1 US 9334002 A US9334002 A US 9334002A US RE39501 E USRE39501 E US RE39501E
Authority
US
United States
Prior art keywords
data
network
module
memory
state machine
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 - Lifetime
Application number
US10/093,340
Inventor
John Shigeto Minami
Ryo Koyama
Michael Ward Johnson
Masaru Shinohara
Thomas C. Poff
Daniel F. Burkes
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.)
Nvidia Corp
Original Assignee
Nvidia Corp
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
Priority claimed from US08/742,085 external-priority patent/US6034963A/en
Application filed by Nvidia Corp filed Critical Nvidia Corp
Priority to US10/093,340 priority Critical patent/USRE39501E1/en
Priority to US10/131,118 priority patent/US8218555B2/en
Priority to DE60238751T priority patent/DE60238751D1/en
Priority to AU2002258974A priority patent/AU2002258974A1/en
Priority to AT02728953T priority patent/ATE493821T1/en
Priority to PCT/US2002/012889 priority patent/WO2002086674A2/en
Priority to JP2002584131A priority patent/JP2005502225A/en
Priority to EP02728953A priority patent/EP1382145B1/en
Assigned to RWI GROUP III, L.P., AS COLLATERAL AGENT reassignment RWI GROUP III, L.P., AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: IREADY CORPORATION
Assigned to NATIONAL SEMICONDUCTOR CORPORATION reassignment NATIONAL SEMICONDUCTOR CORPORATION SECURITY AGREEMENT Assignors: IREADY CORPORATION
Priority to US10/456,871 priority patent/US7535913B2/en
Assigned to TELOS VENTURE PARTNERS II, L.P., AS COLLATERAL AGENT reassignment TELOS VENTURE PARTNERS II, L.P., AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: IREADY CORPORATION
Assigned to LANZA TECHVENTURE, COLLATERAL AGENT reassignment LANZA TECHVENTURE, COLLATERAL AGENT SECURITY AGREEEMENT Assignors: IREADY CORPORATION
Assigned to LANZA TECHVENTURE AS COLLETERAL AGENT reassignment LANZA TECHVENTURE AS COLLETERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: IREADY CORPORATION
Assigned to Glen Patent Group reassignment Glen Patent Group MECHANICS' LIEN Assignors: IREADY CORPORATION
Assigned to IREADY CORPORATION reassignment IREADY CORPORATION TERMINATION OF SECURITY INTEREST IN PATENTS Assignors: TELOS VENTURE PARTNERS II, L.P.
Assigned to IREADY CORPORATION reassignment IREADY CORPORATION TERMINATION OF SECURITY INTEREST IN PATENTS Assignors: RWI GROUP III, L.P., AS COLLATERAL AGENT
Assigned to IREADY CORPORATION reassignment IREADY CORPORATION TERMINATION OF SECURITY INTEREST IN PATENTS Assignors: LANZA TECHVENTURE, AS COLLATERAL AGENT
Assigned to IREADY CORPORATION reassignment IREADY CORPORATION TERMINATION OF SECURITY INTEREST IN PATENTS Assignors: NATIONAL SEMICONDUCTOR CORPORATION
Assigned to NVIDIA CORPORATION reassignment NVIDIA CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: IREADY CORPORATION
Assigned to IREADY CORPORATION reassignment IREADY CORPORATION RELEASE OF MECHANICS' LIEN Assignors: Glenn Patent Group
Assigned to NVIDIA CORPORATION reassignment NVIDIA CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: IREADY CORPORATION
Publication of USRE39501E1 publication Critical patent/USRE39501E1/en
Application granted granted Critical
Priority to JP2008139758A priority patent/JP4916482B2/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12Protocol engines
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/622Queue service order
    • H04L47/6225Fixed service order, e.g. Round Robin
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/622Queue service order
    • H04L47/623Weighted service order
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/901Buffering arrangements using storage descriptor, e.g. read or write pointers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level

Definitions

  • the invention relates to network protocols and data packets. More particularly, the invention relates to the decoding of network protocols and processing of packet data during packet reception without the time-consuming overhead of software or software/hardware implementations. In addition, the invention allows one pass parsing of the data, eliminating the buffering of data packets for different stacks, and thus minimizing the memory usage.
  • Computer networks necessitate the provision of various communication protocols to transmit and receive data.
  • a computer network comprises a system of devices such as computers, printers and other computer peripherals, communicatively connected together. Data are transferred between each of these devices through data packets which are communicated through the network using a communication protocol standard.
  • IP Internet Protocol
  • IPX Internetwork Packet Exchange
  • SPX Sequenced Packet Exchange
  • TCP Transmission Control Protocol
  • PPPP Point to Point Protocol
  • Each network device contains a combination of hardware and software that translates protocols and process data.
  • An example is a computer attached to a Local Area Network (LAN) system, wherein a network device uses hardware to handle the Link Layer protocol, and software to handle the Network, Transport, and Communication Protocols and information data handling.
  • the network device normally implements the one Link Layer protocol in hardware, limiting the attached computer to only that particular LAN protocol.
  • the higher protocols, e.g. Network, Transport, and Communication protocols, along with the Data handlers, are implemented as software programs which process the data once they are passed through the network device hardware into system memory.
  • the advantage to this implementation is that it allows a general purpose device such as the computer to be used in many different network setups and support any arbitrary network application that may be needed.
  • Consumer products that do not fit in the traditional models of a network device are entering the market.
  • a few examples of these products are pagers, cellular phones, game machines, smart telephones, and televisions. Most of these products have small footprints, 8-bit controllers, limited memory or require a very limited form factor. Consumer products such as these are simplistic and require low cost and low power consumption.
  • the previously mentioned protocol implementations require too much hardware and processor power to meet these requirements. The complexity of such implementations are difficult to incorporate into consumer products in a cost effective way. If network access can be simplified such that it may be easily manufactured on a low-cost, low-power, and small form-factor device, these products can access network services, such as the Internet.
  • the invention provides a low-cost, low-power, easily manufacturable, small form-factor network access module which has a low memory demand and provides a highly efficient protocol decode.
  • the invention comprises a hardware-integrated system that both decodes multiple network protocols in a byte-streaming manner concurrently and processes packet data in one pass, thereby reducing system memory and form factor requirements, while also eliminating software CPU overhead.
  • the preferred embodiment of the invention comprises a network protocol layer, data handler, O.S. State Machine, and memory manager state machines implemented at a hardware gate level.
  • Network packets are received from a physical transport level mechanism by the network protocol layer state machine.
  • the protocol state machine decodes network protocols such as TCP, IP, User Datagram Protocol (UDP), PPP, and Raw Socket concurrently as each byte is received.
  • Each protocol handler parses, interprets, and strips header information immediately from the packet, requiring no intermediate memory.
  • the resulting data are passed to the next protocol layer or data handler for which the latter case consists of data state machines that decode data formats such as email, graphics, Hypertext Transfer Protocol (HTTP), Java, and Hypertext Markup Language (HTML).
  • HTML Hypertext Markup Language
  • Each data state machine reacts accordingly to the pertinent data, and any data that are required by more than one data state machine are provided to each state machine concurrently. Any data that are required more than once by a specific data state machine, are placed in a specific memory location with a pointer designating such data (thereby ensuring minimal memory usage). Resulting display data are immediately passed preformatted to a display controller. Any outgoing network packets are created by the data state machines and passed through the network protocol state machine which adds formats to the packet, and checksums the information header information, and forwards the resulting network packet via a physical transport level mechanism.
  • the preferred embodiment does not necessarily require a CPU and software to process the network packets, thereby greatly reducing system cost.
  • the hardware gate level implementation provides a modular, embeddable design whereupon the designer may pick and choose the functionality that the particular application requires and still retain a low cost, low power, small form factor.
  • FIG. 1 is a high-level data flow diagram of the core system according to the invention.
  • FIG. 2 is a high-level block diagram of a system according to the invention.
  • FIG. 3 is a functional block diagram of a complete system implementation according to the invention.
  • FIG. 3A is a functional block diagram of the UMA memory controller according to the invention.
  • FIG. 4 is a time comparison chart illustrating data task time requirements for a traditional architecture and the invention.
  • FIG. 5 illustrates the possible progression of applications according to the invention
  • FIG. 6 illustrates the concept of an Internet Tuner according to the invention
  • FIG. 7 illustrates two implementations according to the invention
  • FIG. 8 illustrates Network PC implementations according to the invention
  • FIG. 9 illustrates Handheld Devices implementations according to the invention.
  • FIG. 10 illustrates Smart Telephone implementations according to the invention
  • FIG. 11 illustrates Smart Television, cable-box, Video Cassette Recorder (VCR), Digital Video Disc (DVD) and game machine implementations according to the invention.
  • VCR Video Cassette Recorder
  • DVD Digital Video Disc
  • FIG. 12 is a timing diagram sharing a received packet according to the invention.
  • FIG. 13 is a block schematic diagram showing signal flow for the packet of claim 12 according to the invention.
  • the invention comprises a Network Protocol Layer 101 , a Data Handler 102 , a Memory Control module 103 , and an Operating System (O.S.) State Machine module 104 , each implemented at the hardware gate level.
  • the Network Protocol Layer 101 decodes incoming and encodes outgoing network packets.
  • the Network Protocol Layer 101 comprises a plurality of state machines representing different network protocol stacks (i.e. PPP, TCP, IP, UDP, and Raw Socket) which simultaneously decode incoming network packets.
  • PPP network protocol stacks
  • the Data Handler 102 comprises a plurality of state machines, each of which process a specific data type (i.e. HTTP, email formats (Post Office Protocol (POP3), Internet Message Access Protocol (IMAP4), Simple Mail Transfer Protocol (SMTP)), graphics standards (Joint Photographic Experts Group (JPEG), Graphics Interchange Format (GIF)), Java, and HTML).
  • the gate level implementation of the data handlers enable the invention to concurrently process received data in real time and is especially suitable for applications which handle streams of data as they are received, i.e. Java, HTML, POP3 email, and audio and video applications.
  • Any data that are required by more than one data state machine are provided in a concurrent manner. Any data required more than once by a specific data state machine are placed in a specific memory location with a pointer designating them. All memory accesses are arbitrated through the Memory Control module 103 . Any resulting display data are also routed through the Memory Control module 103 .
  • the O.S. State Machine 104 acts as an arbitrator between all of the state machines for resource control, system, and user interface. Any user input is interpreted by the O.S. State Machine and routed to the Data Handler 102 .
  • HTML format contains character strings known as tags, which control the formatting of a subsequent block of text when displayed on a video output device. These tags may be efficiently decoded by generating a CRC number for a given tag and using said number to enable a formatting instruction.
  • CRC Cyclic Redundancy Check
  • the invention is represented in a high-level block diagram. This diagram describes the operational task of each module in a full implementation of the invention.
  • the O.S. State Machine 208 contains the system “glue” logic, and the device control interface, and acts as a “traffic cop” between the state machines of the other modules.
  • the Network Protocol Layer 207 contains state machines for TCP/IP, UDP, Raw Socket, and PPP protocols.
  • the Memory Control module 206 contains the logic for the Unified Memory Architecture (UMA) which allows the system and video display memory to reside in the same memory area.
  • UMA Unified Memory Architecture
  • a Display Controller 205 provides control of a VGA, television standard, or other type of display. Four data handlers are used in this implementation.
  • An Email data handler 201 interprets both POP3 and IMAP4 formats.
  • Interpreters 202 are implemented which decode JPEG and GIF formats (commerce and telephony standards may also be decoded).
  • a Java Machine 203 is also included which interprets the Java language byte codes.
  • the World-Wide Web (WWW) Browser 204 contains an HTML decoder/accelerator, HTTP Data handler and an integrated email state machine.
  • an incoming JPEG image packet is traced through the system, assuming a MODEM physical transport.
  • the request starts with the user indicating a desire to download a given JPEG image by typing on keyboard 321 .
  • This input is interpreted by the keyboard interface 316 and passed to the O.S. State machine 315 .
  • O.S. State machine 315 processes the input and passes it as a command to the HTTP client 311 .
  • the HTTP client creates a request packet and passes it via the Port Decoder 309 to the TCP Layer 308 .
  • the TCP Layer prepends the appropriate TCP header and passes it to the IP Layer 307 .
  • the IP layer then prepends the appropriate IP header and passes the packet to the PPP layer 306 .
  • the PPP Layer prepends the appropriate header, appends an FCS, and passes the data to the Physical Transport Interface 305 .
  • the Physical Transport Interface serializes the data into a bit stream and sends the packet to the MODEM unit 304 .
  • the data are first received by the MODEM 304 which indicates to the Physical Transport Interface 305 that data are present.
  • the Physical Transport interface then reads the bit serial data from the MODEM, converts it to a parallel byte data, and indicates to the PPP Layer 306 that data are present.
  • the PPP Layer reads in the received bytes. When it detects a valid start byte, it begins to parse the incoming bytes.
  • the PPP Layer decodes it, and in this example decodes the embedded packet as being of type IP.
  • the PPP Layer enables the IP Layer 307 and indicates to it that IP data are being received. All further data bytes received are now passed directly to the IP Layer.
  • the IP Layer then begins to parse the incoming data bytes. When it comes to the IP header protocol field, it determines which higher protocol to enable. In this example, the IP Layer decodes the protocol field as being of type TCP. At this point, the IP Layer enables the TCP Layer 308 and indicates to it when TCP data are being received.
  • IP Layer needs the data bytes to complete checksum calculations.
  • the TCP Layer then begins to parse the incoming data bytes. When it comes to the TCP header destination port field, it determines which data handler to enable. In this example, the PORT field decodes to the HTTP client 311 . At this point, the PORT decoder enables the HTTP client and indicate to it that HTTP requested data are being received. The HTTP client then begins to parse received data bytes. When the HTTP client determines that the packet is of type JPEG image, the HTTP client enables the JPEG decoder 313 .
  • the JPEG decoder then receives all further incoming data bytes and processes them accordingly.
  • the resulting decoded image is sent to the display memory via the Memory Controller 312 to be processed by the Display Controller 324 for output to display device 326 .
  • various layers need access to a shared memory resource. All memory accesses are arbitrated by a single memory controller. This memory controller determines which layer or handler has access at any given cycle to the unified memory buffer. This memory controller is needed due to the fact that all system and display memory buffers are shared within a single memory buffer unit.
  • the unified memory controller 312 takes read and write requests from the various layers, arbitrates the requests based on a dynamic rotating arbitration scheme with fixed priority weighting. This algorithm is depicted in FIG. 3 A. If, in the pictured configuration, device D 2 302 A and device D 3 303 A both request memory access at the same time, then the arbitor 307 A awards the cycle to the device that has not had the most recent memory access.
  • the arbitor 307 A then passes its memory request to the A input arbitor 309 A. If the B input on arbitor 309 A is idle, then the request is passed up to the B input of arbitor 310 A. If the A input to the arbitor 310 A is idle, then the request is made to the memory unit. All arbitration determinations are performed using combinatorial logic, thereby eliminating any wait states to any device if no other memory requests are being made. Priority weighting is assigned by configuring the arbitration tree structure. In FIG. 3A , Device DO 300 A and Device D 1 301 A each have 25% priority weighting meaning that if all devices requested constant memory usage, they would each win the arbitration 25% of the time.
  • Devices D 2 302 A, D 3 303 A, D 4 304 A, and D 5 305 A each have 12.5% priority weighting.
  • the memory controller design is simplified by having each of the individual arbitration units having the same logic structure. In this scheme, the number of requesting devices, and their priority weighting can easily be configured by adding and arranging arbitor units.
  • FIG. 4 the speed advantages that the invention offers are much higher than the traditional architecture currently in use.
  • the figure represents the time needed to complete each task.
  • the total time required for these tasks is shown for the traditional architecture 408 and the invention (iReady architecture) 409 .
  • the invention 409 is significantly faster for these tasks than the traditional architecture 408 .
  • FIG. 5 the progression of applications for this type of network access is shown.
  • the traditional model of the network client is being used, namely the computer 501 .
  • the consumer appliance concepts of the Network PC 502 , handheld devices 503 , smart telephones 504 , set-top appliances 505 , and smart televisions 506 are now becoming a reality.
  • the invention provides these products with a cost-effective, space, speed, and power conscious network access.
  • the invention operates much like a television 602 or radio tuner 611 —the signals (packets) are processed immediately without delay and sent to a display or audio output.
  • the term Internet Tuner 608 is used to describe the invention as an analogy to such signal processing devices.
  • the Internet Tuner 608 acts as the interface between the Internet signals 609 and application products such as smart televisions 604 , set-top appliances 605 , smart telephones 606 , and handheld devices 607 . It processes Internet signals 609 in real-time as do television 602 and radio tuners 611 .
  • FIG. 7 illustrates that a full implementation of the invention using the O.S. State Machine 701 , Network Protocol Layer 702 , Memory Control 703 , Display Controller 704 , email data handler 708 , Interpreters 707 , Java Machine 706 , and WWW Browser 705 may be separated into two separate modules.
  • the modularity of the invention allows functions such as the data handlers 713 (email data handler 717 , Interpreters 716 , Java Machine 715 , and WWW Browser 714 ) to be separated and placed into a high-level ROM code for certain applications.
  • FIG. 8 demonstrates the possible configurations of the invention for a Network PC.
  • One variation includes the O.S. State Machine 801 , Network Protocol Layer 802 , Memory Control 803 , Display Controller 804 , email data handler 808 , Interpreters 807 , Java Machine 806 , and the WWW Browser 805 .
  • This can be varied by placing the data handlers for email 817 .
  • Interpreters 816 , Java Machine 815 , and WWW Browser 814 code into high-level ROM running on a microprocessor 813 .
  • the microprocessor 813 communicates through the O.S. State Machine 809 for network and display functions.
  • a third variation allows a microprocessor 822 running off of a 3rd Party ROM 823 to interpret the data coming from the Network Protocol Layer 819 and O.S. State Machine 818 .
  • the microprocessor 822 displays data through the Display Controller 821 .
  • a handheld device may use only the Network Protocol Layer 901 and interface it to a custom Transport Mechanism 902 and Existing Microcontroller 904 .
  • Email functions may be added by including the email data handler 905 in the configuration.
  • the Network Protocol Layer 911 and Java Machine 910 may be added to a handheld device, thereby allowing it to process Java applets.
  • smart telephones may add email capabilities by implementing the O.S. State Machine 1001 , Network Protocol Layer 1002 , Memory Control 1003 , email data handler 1006 , and Display Controller 1004 .
  • the Display Controller 1004 is capable of controlling Light Emitting Diode (LED), Liquid Crystal Display (LCD) displays, or big-mapped displays.
  • a Physical Transport Control 1005 may optionally be added, depending on the connectivity requirements of the smart telephone.
  • the O.S. State Machine 1007 , Network Protocol Layer 1008 , and Memory Controller 1009 may be added to smart telephones with an existing microcontroller 1010 .
  • the microcontroller 1010 performs email functions using a 3rd Party email client code 1011 .
  • FIG. 11 smart televisions, cable-boxes, Video Cassette Recorders (VCRs), Digital Video Disc (DVD) players, and game machines can take advantage of the network accessibility offereNety the invention.
  • the O.S. State Machine 1102 , Network Protocol Layer 1103 , Memory Controller 1104 , WWW Browser 1107 , Java Machine 1106 , and (optionally) the Display Controller 1105 are interfaced to an existing controller 1101 . If a controller 1101 is not present, the Display Controller 1105 is used.
  • Email 1115 functions are easily added due to the modularity of the invention.
  • the data handlers for email 1124 , Interpreters 1123 , Java Machine 1122 , and WWW Browser 1121 code are optionally placed into high level ROM running on a microprocessor 1120 .
  • the microprocessor 1120 communicates through the O.S. State Machine 1116 for network and display functions.
  • FIG. 12 depicts a received network packet.
  • the packet contains the following items as shown from left to right:
  • the line labeled PPP LAYER ENABLE is activated when a valid start byte is detected, and is generated within the PPP block in FIG. 13 . Once this line goes high, the rest of the PPP block is activated.
  • Within the PPP header is a field indicating the type of protocol that the PPP packet is encapsulating. In an uncompressed PPP header, these are bytes 4 and 5 (counting the start byte 0 ⁇ 7e). In FIG. 12 , these bytes are 0 ⁇ 00 and 0 ⁇ 21 indicating that the encapsulated data is an IP packet. After decoding this field, the PPP block activates the IP LAYER ENABLE and PPP DATA FIELD signals, which together enable the IP block in FIG. 13 .
  • the IP LAYER ENABLE line is decoded from the PPP protocol field, and the PPP DATA FIELD line indicates that the incoming data byte stream is in the data field portion of the network packet. These two lines must be active for the IP block to be enabled. Once the IP block is enabled, it starts to parse the incoming data bytes. Referring back to FIG. 12 , the data immediately following the PPP header is the IP header. Within the IP header is a field indicating the type of data that is encapsulated within the IP packet. In FIG. 12 , this field is shown to be 0 ⁇ 06 indicating that the encapsulated data is a TCP packet. The TCP LAYER ENABLE line is activated in response to the IP block decoding this field.
  • the IP DATA FIELD line goes active a couple of bytes later, because there are some bytes that come between the IP header protocol field and the start of the IP data field.
  • the IP DATA FIELD signal indicates that the incoming data byte streams is in the data field portion of the network packet.
  • Both the TCP LAYER ENABLE and IP DATA FIELD lines must be active in order for the TCP block in FIG. 13 to be enabled. Once the TCP block is enabled, it starts to parse incoming data bytes. Referring back to FIG. 12 , the data immediately following the IP header is the TCP header. Within the TCP header is a 2 byte field for the destination port. This field indicates which application or data handler the encapsulated data is meant for. In FIG.
  • port 3 is designated as the HTTP port.
  • the HTTP ENABLE line is activated.
  • the TCP DATA FIELD line is activated a couple of bytes later because there are some intermediate bytes between the destination port field and the start of the TCP data field.
  • Both the HTTP ENABLE and TCP DATA FIELD lines must be active for the HTTP/PORT 3 block in FIG. 13 to be enabled.

Abstract

A multiple network protocol encoder/decoder comprising a network protocol layer, data handler, O.S. State machine, and memory manager state machines implemented at a hardware gate level. Network packets are received from a physical transport level mechanism by the network protocol layer state machine which decodes network protocols such as TCP, IP, User Datagram Protocol (UDP), PPP, and Raw Socket concurrently as each byte is received. Each protocol handler parses and strips header information immediately from the packet, requiring no intermediate memory. The resulting data are passed to the data handler which consists of data state machines that decode data formats such as email, graphics, Hypertext Transfer Protocol (HTTP), Java, and Hypertext Markup Language (HTML). Each data state machine reacts accordingly to the pertinent data, and any data that are required by more than one data state machine is provided to each state machine concurrently, and any data required more than once by a specific data state machine, are placed in a specific memory location with a pointer designating such data (thereby ensuring minimal memory usage). Resulting display data are immediately passed to a display controller. Any outgoing network packets are created by the data state machines and passed through the network protocol state machine which adds header information and forwards the resulting network packet via a transport level mechanism.

Description

BACKGROUND OF THE INVENTION
1. Technical Field
The invention relates to network protocols and data packets. More particularly, the invention relates to the decoding of network protocols and processing of packet data during packet reception without the time-consuming overhead of software or software/hardware implementations. In addition, the invention allows one pass parsing of the data, eliminating the buffering of data packets for different stacks, and thus minimizing the memory usage.
2. Description of the Prior Art
Computer networks necessitate the provision of various communication protocols to transmit and receive data. Typically, a computer network comprises a system of devices such as computers, printers and other computer peripherals, communicatively connected together. Data are transferred between each of these devices through data packets which are communicated through the network using a communication protocol standard. Many different protocol standards are in current use today. Examples of popular protocols are Internet Protocol (IP), Internetwork Packet Exchange (IPX), Sequenced Packet Exchange (SPX), Transmission Control Protocol (TCP), and Point to Point Protocol (PPP). Each network device contains a combination of hardware and software that translates protocols and process data.
An example is a computer attached to a Local Area Network (LAN) system, wherein a network device uses hardware to handle the Link Layer protocol, and software to handle the Network, Transport, and Communication Protocols and information data handling. The network device normally implements the one Link Layer protocol in hardware, limiting the attached computer to only that particular LAN protocol. The higher protocols, e.g. Network, Transport, and Communication protocols, along with the Data handlers, are implemented as software programs which process the data once they are passed through the network device hardware into system memory. The advantage to this implementation is that it allows a general purpose device such as the computer to be used in many different network setups and support any arbitrary network application that may be needed. The result of this implementation, however, is that the system requires a high processor overhead, a large amount of system memory, complicated configuration setup on the part of the computer user to coordinate the different software protocol and data handlers communicating to the computer's Operating System (O.S.) and computer and network hardware.
This high overhead required in processing time is demonstrated in U.S. Pat. No. 5,485,460 issued to Schrier et al on Jan. 16, 1996, which teaches a method of operating multiple software protocol stacks implementing the same protocol on a device. This type of implementation is used in Disk Operating System (DOS) based machines running Microsoft Windows. During normal operation, once the hardware verifies the transport or link layer protocol, the resulting data packet is sent to a software layer which determines the packets frame format and strips any specific frame headers. The packet is then sent to different protocol stacks where it is evaluated for the specific protocol. However, the packet may be sent to several protocols stacks before it is accepted or rejected. The time lag created by software protocol stacks prevent audio and video transmissions to be processed in real-time; the data must be buffered before playback. It is evident that the amount of processing overhead required to process a protocol is very high and extremely cumbersome and lends itself to applications with a powerful Central Processing Unit (CPU) and a large amount of memory.
Consumer products that do not fit in the traditional models of a network device are entering the market. A few examples of these products are pagers, cellular phones, game machines, smart telephones, and televisions. Most of these products have small footprints, 8-bit controllers, limited memory or require a very limited form factor. Consumer products such as these are simplistic and require low cost and low power consumption. The previously mentioned protocol implementations require too much hardware and processor power to meet these requirements. The complexity of such implementations are difficult to incorporate into consumer products in a cost effective way. If network access can be simplified such that it may be easily manufactured on a low-cost, low-power, and small form-factor device, these products can access network services, such as the Internet.
SUMMARY OF THE INVENTION
The invention provides a low-cost, low-power, easily manufacturable, small form-factor network access module which has a low memory demand and provides a highly efficient protocol decode. The invention comprises a hardware-integrated system that both decodes multiple network protocols in a byte-streaming manner concurrently and processes packet data in one pass, thereby reducing system memory and form factor requirements, while also eliminating software CPU overhead.
The preferred embodiment of the invention comprises a network protocol layer, data handler, O.S. State Machine, and memory manager state machines implemented at a hardware gate level. Network packets are received from a physical transport level mechanism by the network protocol layer state machine. The protocol state machine decodes network protocols such as TCP, IP, User Datagram Protocol (UDP), PPP, and Raw Socket concurrently as each byte is received. Each protocol handler parses, interprets, and strips header information immediately from the packet, requiring no intermediate memory. The resulting data are passed to the next protocol layer or data handler for which the latter case consists of data state machines that decode data formats such as email, graphics, Hypertext Transfer Protocol (HTTP), Java, and Hypertext Markup Language (HTML). Each data state machine reacts accordingly to the pertinent data, and any data that are required by more than one data state machine are provided to each state machine concurrently. Any data that are required more than once by a specific data state machine, are placed in a specific memory location with a pointer designating such data (thereby ensuring minimal memory usage). Resulting display data are immediately passed preformatted to a display controller. Any outgoing network packets are created by the data state machines and passed through the network protocol state machine which adds formats to the packet, and checksums the information header information, and forwards the resulting network packet via a physical transport level mechanism.
The preferred embodiment does not necessarily require a CPU and software to process the network packets, thereby greatly reducing system cost. The hardware gate level implementation provides a modular, embeddable design whereupon the designer may pick and choose the functionality that the particular application requires and still retain a low cost, low power, small form factor.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a high-level data flow diagram of the core system according to the invention;
FIG. 2 is a high-level block diagram of a system according to the invention;
FIG. 3 is a functional block diagram of a complete system implementation according to the invention;
FIG. 3A is a functional block diagram of the UMA memory controller according to the invention;
FIG. 4 is a time comparison chart illustrating data task time requirements for a traditional architecture and the invention.
FIG. 5 illustrates the possible progression of applications according to the invention;
FIG. 6 illustrates the concept of an Internet Tuner according to the invention;
FIG. 7 illustrates two implementations according to the invention;
FIG. 8 illustrates Network PC implementations according to the invention;
FIG. 9 illustrates Handheld Devices implementations according to the invention;
FIG. 10 illustrates Smart Telephone implementations according to the invention;
FIG. 11 illustrates Smart Television, cable-box, Video Cassette Recorder (VCR), Digital Video Disc (DVD) and game machine implementations according to the invention; and
FIG. 12 is a timing diagram sharing a received packet according to the invention; and
FIG. 13 is a block schematic diagram showing signal flow for the packet of claim 12 according to the invention.
DETAILED DESCRIPTION OF THE INVENTION
Referring to FIG. 1, the invention comprises a Network Protocol Layer 101, a Data Handler 102, a Memory Control module 103, and an Operating System (O.S.) State Machine module 104, each implemented at the hardware gate level. The Network Protocol Layer 101 decodes incoming and encodes outgoing network packets. The Network Protocol Layer 101 comprises a plurality of state machines representing different network protocol stacks (i.e. PPP, TCP, IP, UDP, and Raw Socket) which simultaneously decode incoming network packets. The implementation of the protocol stacks in gate level logic allows the real time decoding of the network packet as the packet is received, thereby requiring no temporary memory storage. After all of the packet header information is stripped out and verified by the state machines, the resulting data is passed to the Data Handler 102. The Data Handler 102 comprises a plurality of state machines, each of which process a specific data type (i.e. HTTP, email formats (Post Office Protocol (POP3), Internet Message Access Protocol (IMAP4), Simple Mail Transfer Protocol (SMTP)), graphics standards (Joint Photographic Experts Group (JPEG), Graphics Interchange Format (GIF)), Java, and HTML). The gate level implementation of the data handlers enable the invention to concurrently process received data in real time and is especially suitable for applications which handle streams of data as they are received, i.e. Java, HTML, POP3 email, and audio and video applications. Any data that are required by more than one data state machine are provided in a concurrent manner. Any data required more than once by a specific data state machine are placed in a specific memory location with a pointer designating them. All memory accesses are arbitrated through the Memory Control module 103. Any resulting display data are also routed through the Memory Control module 103. The O.S. State Machine 104, acts as an arbitrator between all of the state machines for resource control, system, and user interface. Any user input is interpreted by the O.S. State Machine and routed to the Data Handler 102.
As an example, a data handler that interprets HTML format could decode the HTML tags using a Cyclic Redundancy Check (CRC) calculation. HTML format contains character strings known as tags, which control the formatting of a subsequent block of text when displayed on a video output device. These tags may be efficiently decoded by generating a CRC number for a given tag and using said number to enable a formatting instruction. Such a decoding algorithm is suited for gate level implementation and provides for an HTML encoded document to be displayed on a video output device much more quickly than is currently possible.
Although the invention is described as being at the hardware gate level, one skilled in the art can readily appreciate that these functions may be implemented in many other ways such as Programmable Array Logic (PALs), General Array Logic (GALs), Read Only Memory (ROMs), and software. Additionally, specific protocols and data types have been indicated and one skilled in the art can readily appreciate that the modularity of the invention does not limit it to those specific protocols or data types.
Turning to FIG. 2, the invention is represented in a high-level block diagram. This diagram describes the operational task of each module in a full implementation of the invention. The O.S. State Machine 208, contains the system “glue” logic, and the device control interface, and acts as a “traffic cop” between the state machines of the other modules. The Network Protocol Layer 207, contains state machines for TCP/IP, UDP, Raw Socket, and PPP protocols. The Memory Control module 206 contains the logic for the Unified Memory Architecture (UMA) which allows the system and video display memory to reside in the same memory area. A Display Controller 205 provides control of a VGA, television standard, or other type of display. Four data handlers are used in this implementation. An Email data handler 201 interprets both POP3 and IMAP4 formats. Interpreters 202 are implemented which decode JPEG and GIF formats (commerce and telephony standards may also be decoded). A Java Machine 203 is also included which interprets the Java language byte codes. The World-Wide Web (WWW) Browser 204, contains an HTML decoder/accelerator, HTTP Data handler and an integrated email state machine.
As an example, an incoming JPEG image packet is traced through the system, assuming a MODEM physical transport. The request starts with the user indicating a desire to download a given JPEG image by typing on keyboard 321. This input is interpreted by the keyboard interface 316 and passed to the O.S. State machine 315. O.S. State machine 315 processes the input and passes it as a command to the HTTP client 311. The HTTP client creates a request packet and passes it via the Port Decoder 309 to the TCP Layer 308. The TCP Layer prepends the appropriate TCP header and passes it to the IP Layer 307. The IP layer then prepends the appropriate IP header and passes the packet to the PPP layer 306. The PPP Layer prepends the appropriate header, appends an FCS, and passes the data to the Physical Transport Interface 305. The Physical Transport Interface serializes the data into a bit stream and sends the packet to the MODEM unit 304. When the request is accepted by the host server, it sends the requested JPEG image back to the client system. The data are first received by the MODEM 304 which indicates to the Physical Transport Interface 305 that data are present. The Physical Transport interface then reads the bit serial data from the MODEM, converts it to a parallel byte data, and indicates to the PPP Layer 306 that data are present. The PPP Layer reads in the received bytes. When it detects a valid start byte, it begins to parse the incoming bytes. When the byte stream reaches the PPP protocol field, the PPP Layer decodes it, and in this example decodes the embedded packet as being of type IP. In response to this protocol byte, the PPP Layer enables the IP Layer 307 and indicates to it that IP data are being received. All further data bytes received are now passed directly to the IP Layer. The IP Layer then begins to parse the incoming data bytes. When it comes to the IP header protocol field, it determines which higher protocol to enable. In this example, the IP Layer decodes the protocol field as being of type TCP. At this point, the IP Layer enables the TCP Layer 308 and indicates to it when TCP data are being received. When this indicator goes active, all further data bytes in the received packets are sent to both the IP and TCP Layers (IP Layer needs the data bytes to complete checksum calculations). The TCP Layer then begins to parse the incoming data bytes. When it comes to the TCP header destination port field, it determines which data handler to enable. In this example, the PORT field decodes to the HTTP client 311. At this point, the PORT decoder enables the HTTP client and indicate to it that HTTP requested data are being received. The HTTP client then begins to parse received data bytes. When the HTTP client determines that the packet is of type JPEG image, the HTTP client enables the JPEG decoder 313. At this point, all data bytes are now routed to the JPEG decoder. The JPEG decoder then receives all further incoming data bytes and processes them accordingly. The resulting decoded image is sent to the display memory via the Memory Controller 312 to be processed by the Display Controller 324 for output to display device 326.
As also noted in FIG. 3, various layers need access to a shared memory resource. All memory accesses are arbitrated by a single memory controller. This memory controller determines which layer or handler has access at any given cycle to the unified memory buffer. This memory controller is needed due to the fact that all system and display memory buffers are shared within a single memory buffer unit. The unified memory controller 312 takes read and write requests from the various layers, arbitrates the requests based on a dynamic rotating arbitration scheme with fixed priority weighting. This algorithm is depicted in FIG. 3A. If, in the pictured configuration, device D2 302A and device D3 303A both request memory access at the same time, then the arbitor 307A awards the cycle to the device that has not had the most recent memory access. The arbitor 307A then passes its memory request to the A input arbitor 309A. If the B input on arbitor 309A is idle, then the request is passed up to the B input of arbitor 310A. If the A input to the arbitor 310A is idle, then the request is made to the memory unit. All arbitration determinations are performed using combinatorial logic, thereby eliminating any wait states to any device if no other memory requests are being made. Priority weighting is assigned by configuring the arbitration tree structure. In FIG. 3A, Device DO 300A and Device D1 301A each have 25% priority weighting meaning that if all devices requested constant memory usage, they would each win the arbitration 25% of the time. Devices D2 302A, D3 303A, D4 304A, and D5 305A each have 12.5% priority weighting. The memory controller design is simplified by having each of the individual arbitration units having the same logic structure. In this scheme, the number of requesting devices, and their priority weighting can easily be configured by adding and arranging arbitor units.
Turning to FIG. 4, the speed advantages that the invention offers are much higher than the traditional architecture currently in use. The figure represents the time needed to complete each task. For a series of packets that require an HTML download 401, decode of the HTML 402, JPEG download 403, decode of the JPEG 404, JAVA download 405, decode of the JAVA bytes 406, and streaming audio 407, the total time required for these tasks is shown for the traditional architecture 408 and the invention (iReady architecture) 409. The invention 409 is significantly faster for these tasks than the traditional architecture 408.
Turning to FIG. 5, the progression of applications for this type of network access is shown. Presently, the traditional model of the network client is being used, namely the computer 501. The consumer appliance concepts of the Network PC 502, handheld devices 503, smart telephones 504, set-top appliances 505, and smart televisions 506 are now becoming a reality. The invention provides these products with a cost-effective, space, speed, and power conscious network access.
Referring to FIG. 6, the invention operates much like a television 602 or radio tuner 611—the signals (packets) are processed immediately without delay and sent to a display or audio output. The term Internet Tuner 608 is used to describe the invention as an analogy to such signal processing devices. The Internet Tuner 608 acts as the interface between the Internet signals 609 and application products such as smart televisions 604, set-top appliances 605, smart telephones 606, and handheld devices 607. It processes Internet signals 609 in real-time as do television 602 and radio tuners 611.
FIG. 7 illustrates that a full implementation of the invention using the O.S. State Machine 701, Network Protocol Layer 702, Memory Control 703, Display Controller 704, email data handler 708, Interpreters 707, Java Machine 706, and WWW Browser 705 may be separated into two separate modules. The modularity of the invention allows functions such as the data handlers 713 (email data handler 717, Interpreters 716, Java Machine 715, and WWW Browser 714) to be separated and placed into a high-level ROM code for certain applications.
The following application examples further illustrate the versatility of the modular design of the invention.
FIG. 8 demonstrates the possible configurations of the invention for a Network PC. One variation includes the O.S. State Machine 801, Network Protocol Layer 802, Memory Control 803, Display Controller 804, email data handler 808, Interpreters 807, Java Machine 806, and the WWW Browser 805. This can be varied by placing the data handlers for email 817. Interpreters 816, Java Machine 815, and WWW Browser 814 code into high-level ROM running on a microprocessor 813. The microprocessor 813 communicates through the O.S. State Machine 809 for network and display functions. A third variation allows a microprocessor 822 running off of a 3rd Party ROM 823 to interpret the data coming from the Network Protocol Layer 819 and O.S. State Machine 818. The microprocessor 822 displays data through the Display Controller 821.
Turning to FIG. 9, a handheld device may use only the Network Protocol Layer 901 and interface it to a custom Transport Mechanism 902 and Existing Microcontroller 904. Email functions may be added by including the email data handler 905 in the configuration. Further demonstrating the modularity of the invention, the Network Protocol Layer 911 and Java Machine 910 may be added to a handheld device, thereby allowing it to process Java applets.
Referring to FIG. 10, smart telephones may add email capabilities by implementing the O.S. State Machine 1001, Network Protocol Layer 1002, Memory Control 1003, email data handler 1006, and Display Controller 1004. The Display Controller 1004 is capable of controlling Light Emitting Diode (LED), Liquid Crystal Display (LCD) displays, or big-mapped displays. A Physical Transport Control 1005 may optionally be added, depending on the connectivity requirements of the smart telephone. The O.S. State Machine 1007, Network Protocol Layer 1008, and Memory Controller 1009 may be added to smart telephones with an existing microcontroller 1010. The microcontroller 1010 performs email functions using a 3rd Party email client code 1011.
Turning finally to FIG. 11, smart televisions, cable-boxes, Video Cassette Recorders (VCRs), Digital Video Disc (DVD) players, and game machines can take advantage of the network accessibility offereNety the invention. The O.S. State Machine 1102, Network Protocol Layer 1103, Memory Controller 1104, WWW Browser 1107, Java Machine 1106, and (optionally) the Display Controller 1105 are interfaced to an existing controller 1101. If a controller 1101 is not present, the Display Controller 1105 is used. Email 1115 functions are easily added due to the modularity of the invention. As noted previously, the data handlers for email 1124, Interpreters 1123, Java Machine 1122, and WWW Browser 1121 code are optionally placed into high level ROM running on a microprocessor 1120. The microprocessor 1120 communicates through the O.S. State Machine 1116 for network and display functions.
Example of Packet Reception
FIG. 12 depicts a received network packet. The packet contains the following items as shown from left to right:
PPP header
IP header
TCP header
JPEG Data
PPP FCS (Field Checksum)
The line labeled PPP LAYER ENABLE is activated when a valid start byte is detected, and is generated within the PPP block in FIG. 13. Once this line goes high, the rest of the PPP block is activated. Within the PPP header is a field indicating the type of protocol that the PPP packet is encapsulating. In an uncompressed PPP header, these are bytes 4 and 5 (counting the start byte 0×7e). In FIG. 12, these bytes are 0×00 and 0×21 indicating that the encapsulated data is an IP packet. After decoding this field, the PPP block activates the IP LAYER ENABLE and PPP DATA FIELD signals, which together enable the IP block in FIG. 13. The IP LAYER ENABLE line is decoded from the PPP protocol field, and the PPP DATA FIELD line indicates that the incoming data byte stream is in the data field portion of the network packet. These two lines must be active for the IP block to be enabled. Once the IP block is enabled, it starts to parse the incoming data bytes. Referring back to FIG. 12, the data immediately following the PPP header is the IP header. Within the IP header is a field indicating the type of data that is encapsulated within the IP packet. In FIG. 12, this field is shown to be 0×06 indicating that the encapsulated data is a TCP packet. The TCP LAYER ENABLE line is activated in response to the IP block decoding this field. The IP DATA FIELD line goes active a couple of bytes later, because there are some bytes that come between the IP header protocol field and the start of the IP data field. The IP DATA FIELD signal indicates that the incoming data byte streams is in the data field portion of the network packet. Both the TCP LAYER ENABLE and IP DATA FIELD lines must be active in order for the TCP block in FIG. 13 to be enabled. Once the TCP block is enabled, it starts to parse incoming data bytes. Referring back to FIG. 12, the data immediately following the IP header is the TCP header. Within the TCP header is a 2 byte field for the destination port. This field indicates which application or data handler the encapsulated data is meant for. In FIG. 12, this field decodes to port 0×0003. In FIG. 13, port 3 is designated as the HTTP port. After decoding the destination port field within the TCP header, the HTTP ENABLE line is activated. The TCP DATA FIELD line is activated a couple of bytes later because there are some intermediate bytes between the destination port field and the start of the TCP data field. Both the HTTP ENABLE and TCP DATA FIELD lines must be active for the HTTP/PORT3 block in FIG. 13 to be enabled. Once the HTTP block is enabled, it starts to parse incoming data bytes. When it decodes the JPEG header, it enables the JPEG decoder block in FIG. 13. Once the JPEG decoder is enabled, it starts to process incoming bytes. The JPEG enable line is the only line needed to enable the JPEG block.
Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the Claims included below.

Claims (44)

1. An apparatus for decoding and encoding network protocols and data, comprising:
a network protocol layer module for receiving and transmitting network packets and for encoding and decoding network packets bytes which comprise packet data;
a data handler module for exchanging said packet data with said network protocol layer module and for processing a at least one specific data type or protocol;
a memory control module in communication with said data handler module for arbitrating memory accesses and for providing display data ; and
an operating system (o.s.)at least one state machine module that is optimized for a single selected network protocol, said o.s.at least one state machine module in communication with said data handler module and providing resource control and system and user interfaces ;
wherein said network protocol layer module, said data handler module, said memory control module, and said operating system (o.s.) at least one state machine module comprise corresponding dedicated hardware structures that are implemented in hardware gate level circuitry.
2. The apparatus of claim 1, wherein said network protocol layer module comprises a plurality of state machines representing different network protocols stacks.
3. The apparatus of claim 2 1, wherein said network protocol layer module implements one or more of the following network protocols: Point to Point Protocol (PPP), Internetwork Packet (IP), Transmission Control Protocol (TCP), Raw Socket, and/or User Datagram Protocol (UDP).
4. The apparatus of claim 2 1, wherein said network packets bytes are processed in real time.
5. The apparatus of claim 2 1, wherein said network packets bytes are processed concurrently.
6. The apparatus of claim 2 1, wherein said network packets bytes are processed byte- serially.
7. The apparatus of claim 1, wherein any data required more than once by a specific said state machine is placed in a specific memory location with a pointer designating said memory location.
8. The apparatus of claim 1, wherein said data handler module comprises at least one state machine which processes a specific data type.
9. The apparatus of claim 8, wherein said data handler module processes one or more of the following protocols: Hypertext Transfer Protocol (HTTP), Hypertext Markup Language (HTML), Post Office Protocol (POP3), Internet Message Access Protocol (IMAP4), Simple Mail Transfer Protocol (SMTP), Joint Photographic Experts Group (JPEG), Graphics Interchange Format (GIF), and/or Java language.
10. The apparatus of claim 8, wherein said data type is processed in real time.
11. The apparatus of claim 8, wherein said data type is processed concurrently.
12. The apparatus of claim 8, wherein said data type is processed byte serially.
13. The apparatus of claim 8, wherein any data shared by said at least one state machine or required more than once by a specific said state machine is placed in a specific memory location with a pointer designating said memory location.
14. The apparatus of claim 8, wherein any data shared by said at least one state machine is provided to said state machine(s) concurrently.
15. The apparatus of claim 1, wherein said memory control module arbitrates all memory accesses.
16. The apparatus of claim 1, wherein said memory control module contains a Unified Memory Architecture (UMA) which allows a system memory and a video memory to reside in a same memory area.
17. The apparatus of claim 1, wherein said memory control module is comprised of one or more arbiter logic blocks where an arbiter block arbitrates according to a dynamic rotating algorithm between two devices.
18. The apparatus of claim 1, wherein said memory control module is comprised of one or more arbiter logic blocks arranged in such a manner as to give a fixed weighted priority to each of a plurality of devices for memory access based on a given arbiter tree structure.
19. The apparatus of claim 1, wherein said o.s. further comprising an arbitrator state machine that acts as an arbitrator between said network protocol layer module, said data handler module, and said memory control module for resource control, system and user interface.
20. The apparatus of claim 1, further comprising:
a display controller.
21. The apparatus of claim 20, wherein said display controller controls one of the following types of displays: VGA, television, Liquid Crystal Display (LCD), or Light Emitting Diode (LED).
22. The apparatus of claim 1, wherein said apparatus acts as an interface between Internet signals and application products by processing Internet signals in real-time and sending said processed Internet signals to said application products.
23. A process for decoding and encoding network protocols and data, said process comprising the steps of:
providing a network protocol layer module for receiving and transmitting network packets and for encoding and decoding network packets bytes which comprise packet data;
providing a data handler module for exchanging said packet data with said network protocol layer module and for processing a at least one specific data type or protocol;
providing a memory control module in communication with said data handler module for arbitrating memory accesses and for providing display data ; and
providing an operating system (o.s.) at least one state machine module that is implemented in hardware and that is optimized for a single selected network protocol, said o.s. at least one state machine module in communication with said data handler module and providing resource control and system and user interfaces ;
wherein said network protocol layer module, said data handler module, said memory control module, and said operating system (o.s.) at least one state machine module comprise corresponding dedicated hardware structures that are implemented in hardware gate level circuitry.
24. The process of claim 23, wherein said step of encoding and decoding network packet bytes network protocol layer module further comprises the step of:
representing different network protocols stacks using a plurality of state machines.
25. The process of claim 24, wherein said step of encoding and decoding network packet bytes network protocol layer module further comprises the step of:
encoding and decoding one or more of the following network protocols: Point to Point Protocol (PPP), Internetwork Packet (IP), Transmission Control Protocol (TCP), Raw Socket, and/or User Datagram Protocol (UDP).
26. The process of claim 23, wherein said network protocol layer module step of encoding and decoding network packet bytes further comprises the step of:
processing network packets bytes in real time.
27. The process of claim 23, wherein said step of encoding and decoding network packet bytes network protocol layer module further comprises the step of:
processing network packets bytes concurrently.
28. The process of claim 23, wherein said step of encoding and decoding network packet bytes network protocol layer module further comprise the steps of:
processing network packet bytes packets in a byte serial fashion.
29. The process of claim 23, wherein said step of processing packet data bytes data handler module further comprises the step of:
processing specific data type(s) using at least one state machine.
30. The process of claim 29, wherein said step of processing packet data bytes data handler module further comprises the step of:
use of a CRC algorithm to decode data fields.
31. The process of claim 29, wherein said step of processing packet data bytes data handler module further comprises the step of:
processing one or more of the following protocols: Hypertext Transfer Protocol (HTTP), Hypertext Markup Language (HTML), Post Office Protocol (POP3), Internet Message Access Protocol (IMAP4), Simple Mail Transfer Protocol (SMTP), Joint Photographic Experts Group (JPEG), Graphics Interchange Format (GIF), and/or Java language.
32. The process of claim 29, wherein said step of processing packet data bytes data handler module further comprises the step of:
processing packet data bytes in real time.
33. The process of claim 29, wherein said step of processing packet data bytes data handler module further comprises the step of:
processing packet data bytes concurrently.
34. The process of claim 29, wherein said step of processing packet data bytes data handler module further comprises the step of:
processing packet data bytes in a byte serial fashion.
35. The process of claim 29, wherein said step of processing packet data bytes data handler module further comprises the step of:
placing any data more than once by a specific one of said at least one state machine in a specific memory location with a pointer designating said memory location.
36. The process of claim 23, wherein said step of controlling memory accesses further comprises the step of: memory control module arbitrating es all memory accesses.
37. The process of claim 23, wherein said step of controlling memory accesses further comprises the step of: memory control module allowing s a system memory and a video memory to reside in a same memory area using a Unified Memory Architecture (UMA).
38. The process of claim 23, wherein said step of controlling state machine sequencing further comprises ing the step of:
arbitrating between said step of encoding and decoding network packet bytes network protocol layer module, said step of processing packet data bytes data handler module, and said step of controlling memory accesses memory control module for resource control, system and user interface.
39. The process of claim 23, wherein said step of controlling state machine sequencing further comprises ing the step of:
interpreting system and user input for the purpose of controlling data handler modules and network protocol layer modules.
40. The process of claim 23, further comprising the step of:
displaying output data.
41. The process of claim 40, wherein said step of displaying output data further comprises the step of:
controlling one of the following types of displays: VGA, television, Liquid Crystal Display (LCD), or Light Emitting Diode (LED).
42. The process of claim 23, wherein said process is used to implement an interface between Internet signals and application products by processing Internet signals in real-time and sending said processed Internet signals to said application products.
43. The apparatus of claim 1, wherein said memory control module provides display data.
44. The process of claim 23, wherein said memory control module provides display data.
US10/093,340 1996-10-31 2002-03-06 Multiple network protocol encoder/decoder and data processor Expired - Lifetime USRE39501E1 (en)

Priority Applications (10)

Application Number Priority Date Filing Date Title
US10/093,340 USRE39501E1 (en) 1996-10-31 2002-03-06 Multiple network protocol encoder/decoder and data processor
US10/131,118 US8218555B2 (en) 2001-04-24 2002-04-23 Gigabit ethernet adapter
JP2002584131A JP2005502225A (en) 2001-04-24 2002-04-24 Gigabit Ethernet adapter
AU2002258974A AU2002258974A1 (en) 2001-04-24 2002-04-24 Gigabit ethernet adapter
AT02728953T ATE493821T1 (en) 2001-04-24 2002-04-24 GIGABIT ETHERNET ADAPTER
PCT/US2002/012889 WO2002086674A2 (en) 2001-04-24 2002-04-24 Gigabit ethernet adapter
DE60238751T DE60238751D1 (en) 2001-04-24 2002-04-24 GIGABIT ETHERNET ADAPTER
EP02728953A EP1382145B1 (en) 2001-04-24 2002-04-24 Gigabit ethernet adapter
US10/456,871 US7535913B2 (en) 2002-03-06 2003-06-05 Gigabit ethernet adapter supporting the iSCSI and IPSEC protocols
JP2008139758A JP4916482B2 (en) 2001-04-24 2008-05-28 Gigabit Ethernet adapter

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US08/742,085 US6034963A (en) 1996-10-31 1996-10-31 Multiple network protocol encoder/decoder and data processor
US10/093,340 USRE39501E1 (en) 1996-10-31 2002-03-06 Multiple network protocol encoder/decoder and data processor
US86212504A 2004-06-04 2004-06-04

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US08/742,085 Reissue US6034963A (en) 1996-10-31 1996-10-31 Multiple network protocol encoder/decoder and data processor

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10/131,118 Continuation-In-Part US8218555B2 (en) 2001-04-24 2002-04-23 Gigabit ethernet adapter
US10/456,871 Continuation-In-Part US7535913B2 (en) 2002-03-06 2003-06-05 Gigabit ethernet adapter supporting the iSCSI and IPSEC protocols

Publications (1)

Publication Number Publication Date
USRE39501E1 true USRE39501E1 (en) 2007-03-06

Family

ID=42719254

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/093,340 Expired - Lifetime USRE39501E1 (en) 1996-10-31 2002-03-06 Multiple network protocol encoder/decoder and data processor

Country Status (1)

Country Link
US (1) USRE39501E1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8135842B1 (en) 1999-08-16 2012-03-13 Nvidia Corporation Internet jack

Citations (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5012489A (en) * 1988-11-07 1991-04-30 Hayes Microcomputer Products, Inc. Method for sending a plurality of data channels over a single communications line
US5161193A (en) * 1990-06-29 1992-11-03 Digital Equipment Corporation Pipelined cryptography processor and method for its use in communication networks
US5303344A (en) 1989-03-13 1994-04-12 Hitachi, Ltd. Protocol processing apparatus for use in interfacing network connected computer systems utilizing separate paths for control information and data transfer
US5307413A (en) * 1991-07-19 1994-04-26 Process Software Corporation Method and apparatus for adding data compression and other services in a computer network
US5426694A (en) * 1993-10-08 1995-06-20 Excel, Inc. Telecommunication switch having programmable network protocols and communications services
US5430727A (en) * 1990-09-04 1995-07-04 Digital Equipment Corporation Multiple protocol routing
US5440551A (en) * 1993-01-05 1995-08-08 Nec Corporation Multimedia packet communication system
US5495480A (en) 1993-06-21 1996-02-27 Nec Corporation Packet transmission system having timer for circuit disconnection
US5499353A (en) * 1993-03-30 1996-03-12 Ast Research, Inc. Cache address strobe control logic for stimulated bus cycle initiation
US5519704A (en) * 1994-04-21 1996-05-21 Cisco Systems, Inc. Reliable transport protocol for internetwork routing
US5566170A (en) 1994-12-29 1996-10-15 Storage Technology Corporation Method and apparatus for accelerated packet forwarding
US5577105A (en) * 1994-03-11 1996-11-19 U.S. Robotics, Inc. Telephone call routing and switching techniques for data communications
US5577237A (en) 1995-01-23 1996-11-19 Tandem Computers, Incorporated Protocol timer and method of using same
US5577172A (en) 1994-07-01 1996-11-19 Lasermaster Corporation High-capacity protocol for packet-based networks
US5598410A (en) 1994-12-29 1997-01-28 Storage Technology Corporation Method and apparatus for accelerated packet processing
US5619650A (en) 1992-12-31 1997-04-08 International Business Machines Corporation Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message
US5625825A (en) 1993-10-21 1997-04-29 Lsi Logic Corporation Random number generating apparatus for an interface unit of a carrier sense with multiple access and collision detect (CSMA/CD) ethernet data network
US5625678A (en) * 1995-05-24 1997-04-29 Microsoft Corporation Method and system for allowing switched voice and data communication among multiple application programs
US5634015A (en) 1991-02-06 1997-05-27 Ibm Corporation Generic high bandwidth adapter providing data communications between diverse communication networks and computer system
US5636371A (en) * 1995-06-07 1997-06-03 Bull Hn Information Systems Inc. Virtual network mechanism to access well known port application programs running on a single host system
US5640394A (en) * 1994-08-19 1997-06-17 Microsoft Corporation System and method for running multiple incompatible network protocol stacks
US5663951A (en) 1993-11-24 1997-09-02 Intel Corporation Delayed transmission of data packets over networks
US5666362A (en) * 1995-07-25 1997-09-09 3Com Corporation Method and apparatus for asynchronous PPP and synchronous PPP conversion
US5675507A (en) * 1995-04-28 1997-10-07 Bobo, Ii; Charles R. Message storage and delivery system
US5687314A (en) 1989-06-02 1997-11-11 Tele Digital Development, Inc. Method and apparatus for assisting data bus transfer protocol
US5696899A (en) 1992-11-18 1997-12-09 Canon Kabushiki Kaisha Method and apparatus for adaptively determining the format of data packets carried on a local area network
US5699350A (en) 1995-10-06 1997-12-16 Canon Kabushiki Kaisha Reconfiguration of protocol stacks and/or frame type assignments in a network interface device
US5701316A (en) 1995-08-31 1997-12-23 Unisys Corporation Method for generating an internet protocol suite checksum in a single macro instruction
US5727149A (en) 1994-12-22 1998-03-10 Hitachi, Ltd. Network interface apparatus and data transmission control method thereof
US5734865A (en) * 1995-06-07 1998-03-31 Bull Hn Information Systems Inc. Virtual local area network well-known port routing mechanism for mult--emulators in an open system environment
US5748905A (en) * 1996-08-30 1998-05-05 Fujitsu Network Communications, Inc. Frame classification using classification keys
US5754540A (en) * 1995-07-18 1998-05-19 Macronix International Co., Ltd. Expandable integrated circuit multiport repeater controller with multiple media independent interfaces and mixed media connections
US5790546A (en) * 1994-01-28 1998-08-04 Cabletron Systems, Inc. Method of transmitting data packets in a packet switched communications network
US5790676A (en) * 1994-11-23 1998-08-04 Hughes Electronics Corporation Radio port controller in a wireless personal communications system
US5802306A (en) * 1995-10-31 1998-09-01 International Business Machines Corporation Supporting multiple client-server sessions from a protocol stack associated with a single physical adapter through use of a plurality of logical adapters
US5802278A (en) * 1995-05-10 1998-09-01 3Com Corporation Bridge/router architecture for high performance scalable networking
US5802287A (en) * 1993-10-20 1998-09-01 Lsi Logic Corporation Single chip universal protocol multi-function ATM network interface
US5805816A (en) 1992-05-12 1998-09-08 Compaq Computer Corp. Network packet switch using shared memory for repeating and bridging packets at media rate
US5809235A (en) * 1996-03-08 1998-09-15 International Business Machines Corporation Object oriented network event management framework
US5815516A (en) 1996-04-05 1998-09-29 International Business Machines Corporation Method and apparatus for producing transmission control protocol checksums using internet protocol fragmentation
US5818935A (en) * 1997-03-10 1998-10-06 Maa; Chia-Yiu Internet enhanced video system
US5826032A (en) 1996-02-12 1998-10-20 University Of Southern California Method and network interface logic for providing embedded checksums
US5870549A (en) * 1995-04-28 1999-02-09 Bobo, Ii; Charles R. Systems and methods for storing, delivering, and managing messages
US5872919A (en) 1997-05-07 1999-02-16 Advanced Micro Devices, Inc. Computer communication network having a packet processor with an execution unit which is variably configured from a programmable state machine and logic
US5894557A (en) * 1996-03-29 1999-04-13 International Business Machines Corporation Flexible point-to-point protocol framework
US5909546A (en) 1996-03-08 1999-06-01 Mitsubishi Electric Information Technology Center America, Inc. (Ita) Network interface having support for allowing remote operations with reply that bypass host computer interaction
US5920732A (en) 1996-07-01 1999-07-06 Apple Computer, Inc. System for preallocating additional larger buffer sizes in accordance with packet sizes of discarded packets that can't be stored in existing preallocated buffer sizes
US5935268A (en) 1997-06-03 1999-08-10 Bay Networks, Inc. Method and apparatus for generating an error detection code for a modified data packet derived from an original data packet
US5937169A (en) 1997-10-29 1999-08-10 3Com Corporation Offload of TCP segmentation to a smart adapter
US5941988A (en) 1997-01-27 1999-08-24 International Business Machines Corporation Session and transport layer proxies via TCP glue
US5943481A (en) 1997-05-07 1999-08-24 Advanced Micro Devices, Inc. Computer communication network having a packet processor with subsystems that are variably configured for flexible protocol handling
US5974518A (en) 1997-04-10 1999-10-26 Milgo Solutions, Inc. Smart buffer size adaptation apparatus and method
US5999974A (en) 1997-08-29 1999-12-07 International Business Machines Corporation Internet protocol assists for high performance LAN connections
US6014699A (en) 1997-08-29 2000-01-11 International Business Machines Corporation Internet protocol assists for high performance LAN connections
US6061742A (en) 1997-10-10 2000-05-09 Nortel Networks Corporation Computer network adaptor
US6076115A (en) 1997-02-11 2000-06-13 Xaqti Corporation Media access control receiver and network management system
US6081846A (en) 1997-05-08 2000-06-27 Microsoft Corporation Method and computer program product for reducing intra-system data copying during network packet processing
US6092229A (en) 1996-10-09 2000-07-18 Lsi Logic Corporation Single chip systems using general purpose processors
US6092110A (en) 1997-10-23 2000-07-18 At&T Wireless Svcs. Inc. Apparatus for filtering packets using a dedicated processor
US6098188A (en) 1992-02-14 2000-08-01 Lucent Technologies Inc. Packet framer
US6101543A (en) 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US6151625A (en) 1997-09-10 2000-11-21 Schneider Automation Inc. Internet web interface including programmable logic controller for controlling output devices based on status of input devices
US6157955A (en) 1998-06-15 2000-12-05 Intel Corporation Packet processing system including a policy engine having a classification unit
US6173333B1 (en) 1997-07-18 2001-01-09 Interprophet Corporation TCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocols
US6172990B1 (en) 1997-06-19 2001-01-09 Xaqti Corporation Media access control micro-RISC stream processor and method for implementing the same
US6172980B1 (en) 1997-09-11 2001-01-09 3Com Corporation Multiple protocol support
US6182228B1 (en) 1998-08-17 2001-01-30 International Business Machines Corporation System and method for very fast IP packet filtering
US6230193B1 (en) * 1996-10-31 2001-05-08 3Com Corporation Method and apparatus supporting network communications

Patent Citations (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5012489A (en) * 1988-11-07 1991-04-30 Hayes Microcomputer Products, Inc. Method for sending a plurality of data channels over a single communications line
US5303344A (en) 1989-03-13 1994-04-12 Hitachi, Ltd. Protocol processing apparatus for use in interfacing network connected computer systems utilizing separate paths for control information and data transfer
US5687314A (en) 1989-06-02 1997-11-11 Tele Digital Development, Inc. Method and apparatus for assisting data bus transfer protocol
US5161193A (en) * 1990-06-29 1992-11-03 Digital Equipment Corporation Pipelined cryptography processor and method for its use in communication networks
US5430727A (en) * 1990-09-04 1995-07-04 Digital Equipment Corporation Multiple protocol routing
US5634015A (en) 1991-02-06 1997-05-27 Ibm Corporation Generic high bandwidth adapter providing data communications between diverse communication networks and computer system
US5307413A (en) * 1991-07-19 1994-04-26 Process Software Corporation Method and apparatus for adding data compression and other services in a computer network
US6098188A (en) 1992-02-14 2000-08-01 Lucent Technologies Inc. Packet framer
US5805816A (en) 1992-05-12 1998-09-08 Compaq Computer Corp. Network packet switch using shared memory for repeating and bridging packets at media rate
US5696899A (en) 1992-11-18 1997-12-09 Canon Kabushiki Kaisha Method and apparatus for adaptively determining the format of data packets carried on a local area network
US5619650A (en) 1992-12-31 1997-04-08 International Business Machines Corporation Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message
US5440551A (en) * 1993-01-05 1995-08-08 Nec Corporation Multimedia packet communication system
US5499353A (en) * 1993-03-30 1996-03-12 Ast Research, Inc. Cache address strobe control logic for stimulated bus cycle initiation
US5495480A (en) 1993-06-21 1996-02-27 Nec Corporation Packet transmission system having timer for circuit disconnection
US5546453A (en) * 1993-10-08 1996-08-13 Excel, Inc. Telecommunication switch having programmable network protocols and communications services
US5426694A (en) * 1993-10-08 1995-06-20 Excel, Inc. Telecommunication switch having programmable network protocols and communications services
US5802287A (en) * 1993-10-20 1998-09-01 Lsi Logic Corporation Single chip universal protocol multi-function ATM network interface
US5625825A (en) 1993-10-21 1997-04-29 Lsi Logic Corporation Random number generating apparatus for an interface unit of a carrier sense with multiple access and collision detect (CSMA/CD) ethernet data network
US5663951A (en) 1993-11-24 1997-09-02 Intel Corporation Delayed transmission of data packets over networks
US5790546A (en) * 1994-01-28 1998-08-04 Cabletron Systems, Inc. Method of transmitting data packets in a packet switched communications network
US5761281A (en) * 1994-03-11 1998-06-02 3Com Corporation Telephone call routing and switching techniques for data communications
US5577105A (en) * 1994-03-11 1996-11-19 U.S. Robotics, Inc. Telephone call routing and switching techniques for data communications
US5519704A (en) * 1994-04-21 1996-05-21 Cisco Systems, Inc. Reliable transport protocol for internetwork routing
US5577172A (en) 1994-07-01 1996-11-19 Lasermaster Corporation High-capacity protocol for packet-based networks
US5640394A (en) * 1994-08-19 1997-06-17 Microsoft Corporation System and method for running multiple incompatible network protocol stacks
US5790676A (en) * 1994-11-23 1998-08-04 Hughes Electronics Corporation Radio port controller in a wireless personal communications system
US5727149A (en) 1994-12-22 1998-03-10 Hitachi, Ltd. Network interface apparatus and data transmission control method thereof
US5598410A (en) 1994-12-29 1997-01-28 Storage Technology Corporation Method and apparatus for accelerated packet processing
US5566170A (en) 1994-12-29 1996-10-15 Storage Technology Corporation Method and apparatus for accelerated packet forwarding
US5577237A (en) 1995-01-23 1996-11-19 Tandem Computers, Incorporated Protocol timer and method of using same
US5675507A (en) * 1995-04-28 1997-10-07 Bobo, Ii; Charles R. Message storage and delivery system
US5870549A (en) * 1995-04-28 1999-02-09 Bobo, Ii; Charles R. Systems and methods for storing, delivering, and managing messages
US5802278A (en) * 1995-05-10 1998-09-01 3Com Corporation Bridge/router architecture for high performance scalable networking
US5625678A (en) * 1995-05-24 1997-04-29 Microsoft Corporation Method and system for allowing switched voice and data communication among multiple application programs
US5734865A (en) * 1995-06-07 1998-03-31 Bull Hn Information Systems Inc. Virtual local area network well-known port routing mechanism for mult--emulators in an open system environment
US5636371A (en) * 1995-06-07 1997-06-03 Bull Hn Information Systems Inc. Virtual network mechanism to access well known port application programs running on a single host system
US5754540A (en) * 1995-07-18 1998-05-19 Macronix International Co., Ltd. Expandable integrated circuit multiport repeater controller with multiple media independent interfaces and mixed media connections
US5666362A (en) * 1995-07-25 1997-09-09 3Com Corporation Method and apparatus for asynchronous PPP and synchronous PPP conversion
US5701316A (en) 1995-08-31 1997-12-23 Unisys Corporation Method for generating an internet protocol suite checksum in a single macro instruction
US5699350A (en) 1995-10-06 1997-12-16 Canon Kabushiki Kaisha Reconfiguration of protocol stacks and/or frame type assignments in a network interface device
US5802306A (en) * 1995-10-31 1998-09-01 International Business Machines Corporation Supporting multiple client-server sessions from a protocol stack associated with a single physical adapter through use of a plurality of logical adapters
US5826032A (en) 1996-02-12 1998-10-20 University Of Southern California Method and network interface logic for providing embedded checksums
US5809235A (en) * 1996-03-08 1998-09-15 International Business Machines Corporation Object oriented network event management framework
US5909546A (en) 1996-03-08 1999-06-01 Mitsubishi Electric Information Technology Center America, Inc. (Ita) Network interface having support for allowing remote operations with reply that bypass host computer interaction
US5894557A (en) * 1996-03-29 1999-04-13 International Business Machines Corporation Flexible point-to-point protocol framework
US5815516A (en) 1996-04-05 1998-09-29 International Business Machines Corporation Method and apparatus for producing transmission control protocol checksums using internet protocol fragmentation
US5920732A (en) 1996-07-01 1999-07-06 Apple Computer, Inc. System for preallocating additional larger buffer sizes in accordance with packet sizes of discarded packets that can't be stored in existing preallocated buffer sizes
US5748905A (en) * 1996-08-30 1998-05-05 Fujitsu Network Communications, Inc. Frame classification using classification keys
US6092229A (en) 1996-10-09 2000-07-18 Lsi Logic Corporation Single chip systems using general purpose processors
US6101543A (en) 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US6230193B1 (en) * 1996-10-31 2001-05-08 3Com Corporation Method and apparatus supporting network communications
US5941988A (en) 1997-01-27 1999-08-24 International Business Machines Corporation Session and transport layer proxies via TCP glue
US6076115A (en) 1997-02-11 2000-06-13 Xaqti Corporation Media access control receiver and network management system
US5818935A (en) * 1997-03-10 1998-10-06 Maa; Chia-Yiu Internet enhanced video system
US5974518A (en) 1997-04-10 1999-10-26 Milgo Solutions, Inc. Smart buffer size adaptation apparatus and method
US5872919A (en) 1997-05-07 1999-02-16 Advanced Micro Devices, Inc. Computer communication network having a packet processor with an execution unit which is variably configured from a programmable state machine and logic
US5943481A (en) 1997-05-07 1999-08-24 Advanced Micro Devices, Inc. Computer communication network having a packet processor with subsystems that are variably configured for flexible protocol handling
US6081846A (en) 1997-05-08 2000-06-27 Microsoft Corporation Method and computer program product for reducing intra-system data copying during network packet processing
US5935268A (en) 1997-06-03 1999-08-10 Bay Networks, Inc. Method and apparatus for generating an error detection code for a modified data packet derived from an original data packet
US6172990B1 (en) 1997-06-19 2001-01-09 Xaqti Corporation Media access control micro-RISC stream processor and method for implementing the same
US6173333B1 (en) 1997-07-18 2001-01-09 Interprophet Corporation TCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocols
US6014699A (en) 1997-08-29 2000-01-11 International Business Machines Corporation Internet protocol assists for high performance LAN connections
US5999974A (en) 1997-08-29 1999-12-07 International Business Machines Corporation Internet protocol assists for high performance LAN connections
US6151625A (en) 1997-09-10 2000-11-21 Schneider Automation Inc. Internet web interface including programmable logic controller for controlling output devices based on status of input devices
US6172980B1 (en) 1997-09-11 2001-01-09 3Com Corporation Multiple protocol support
US6061742A (en) 1997-10-10 2000-05-09 Nortel Networks Corporation Computer network adaptor
US6092110A (en) 1997-10-23 2000-07-18 At&T Wireless Svcs. Inc. Apparatus for filtering packets using a dedicated processor
US5937169A (en) 1997-10-29 1999-08-10 3Com Corporation Offload of TCP segmentation to a smart adapter
US6157955A (en) 1998-06-15 2000-12-05 Intel Corporation Packet processing system including a policy engine having a classification unit
US6182228B1 (en) 1998-08-17 2001-01-30 International Business Machines Corporation System and method for very fast IP packet filtering

Non-Patent Citations (61)

* Cited by examiner, † Cited by third party
Title
C. Brendan S. Traw, nd Jonathan M. Smith; Hardware/Software Organization of a High-Performance ATM Host Interface; 1993; IEEE.
Chan Kim, Jong-Arm Jun, Kyou-Ho Lee, Hyup-Jong Kim; Design and Implementation of an ATM Segmentation Engine with PCI Interface; IEEE 1998.
Chan Kim, Jong-Arm Jun, Yeong-Ho Park, Kyu-Ho Lee, Hyup-Jong Kim; Design and Implementation of a High-Speed ATM Host Interface Controller.
Chris Dalton, Greg Watson, David Banks, Costas Calamvokis, Aled Edwards, and John Lumley; Afterburner; A network-independent card provides architectural support for high-performance protocols; IEEE Network; Jul. 1993.
Dave Chiswell; Implementation Challenges for 155Mbit ATM Adapters.
David Banks, and Michael Prudence; A High-Performance Network Architecture for a PA-RISC Workstation; IEEE Journal on Selected Areas in Communications, vol. 11, No. 2; Feb. 1993.
David C. Feldmei;er, Anthony McAuley, Jonathan M. Smith, Deborah S. Bakin, William S. Marcus, and Thomas M. Raleigh; Protocol Boosters; IEEE Journal on Selected Areas in Communications, vol. 16, No. 3; Apr. 1998.
David D. Calrk, Van Jacobson, John Romkey, and Howard Salwen; An Analysis of TCP Processing Overhead; IEEE Communications magazine; Jun. 1989.
David D. Clark, John Romkey, and Howard Salwen;An Analysis of TCP Processing Overhead; 1988 IEEE.
David J. Preston; Internet Protocols Migrate to Silicon for Networking Devices-Moving Internet standards tOnto ASOCs will bring the "Internet Toaster" to a Variety of Consumer Applications; E;ectrical Design; Apr. 14, 1997.
Deborah F. Kornblum; Protocol Implementation and Other Performance Issues for Local and Metropolitan Area Networks; IEEE; 1988.
Erich Rutsche; The Architecture of aGb/s Multimedia Protocol Adapter, Computer ACM SIGCOMM Communication Review.
F. Mora, and A. Sebastia; Electronic Design of a High Performance Interface to thje SCI Network, IEEE 1998.
Fed Eady; Embedded Internet Part 2: TCP/IP and a 16-Bit Compiler, Embedded PC; Jun. 1999.
G. Chesson, et al.; XTP-Protocol Engine VLSI for Real-Time LANs; 1988; EFOC/LAN-88: The Sixth European Fibre Optic Communications and Local Area Networks Exposition.
George Orphano, Alexios Birbas, Nikos Petrellis, Ionnis Moutzouris, Andreas Malataras, Angus Goldfinch, John Brosnan, and Uros Janko; Compensating for Moderate Effective Throughput at the Desktop; IEEE communications Magazine; Apr. 2000.
Gerald w. Neufeld, Mabo Robert Ito, Murray Goldberg, Mark J. McCutcheon, and Stuart Ritchie; Parallel Host Interface for an ATM Network; Host systems will not be able to take advantage of very-high-speed networks without parallel protocol systems; IEEE Network; Jul. 1993.
Girish P. Chandranmenon and George Varhese; Trading Packet Headers for Packet Processing; IEEE/ACM Transactions on Networking; vol. 4; Apr. 1996.
Gr.A. Doumenis, D.I. Reisis, G.I. Stassinopoulos; Efficient Implementation of the SAR Sublayer and the ATM Layer in High Speed Broadband ISDN Data Terminal Adapters; 1993 IEEE.
Gr.A. Doumenis, G.E. Konstantoulakis, D.I. Reisis, G.I. Stassinopoulos; A Personal Computer Hosted Terminal Adapter for the Braodband Integrated Services Digital Network and Applications.
Greg Chesson; Protocol Engine Design; Proceedings of the Summer 1987 USENIX Conference.
Greg Chesson; The Protocol Engine; Sep. 1987; UNIX Review.
Hanafy E. Meleis, and Dimitrios N. Serpanos; Designing communication Subsystems for High-Speed Networks; IEEE Network; Jul. 1992.
Hemant Kanakia, and David R. Cheriton; The VMP Netwrok Adapter Board (NAB) High-Performance Network Communication for Multiprocessors; 1988 ACM.
IReady Product Data Sheet, Internet Turner. *
Jau-Hsiung Huang, and Chi-Wen Chen; On Performance Measurements of TCP/IP and its Device Driver 1992 IEEE.
John Legg; Choosing and Implementing an Embedded TCP/IP Stack; Electronic Product Design Jan. 1999.
Johnson et al, "Internet Tuner", New Media News, <http://www.newmedianews.com/020197/ts_Inettuner.html>, Jan. 1997. *
Jonathan M. Smith and C. Brendan S. Traw; Giving Applicatiosn Access to Gb/s Networking; Design tradeoffs in an ATM to Gb/s host interface and its operating-system support have profound implications for applications performance; IEEE Network; Jul. 1993.
K. K. Ramakrishnan; Performance Considerations in Designing Network Interfaces; IEEE Journal on Selected Areas in Communications, vol. 11, No. 2; Feb. 1993.
K. Maly, S. Khanna, R. Mukkamala, C.M. Overstreet, R. Yerraballi, E.C. Foudriat, and B. Madan; Parallel TCP/IP for Multiprocessor Workstations; Oct. 29, 1992.
Kan Toyoshima, Kazuhiro Shirakawa, and Kazuhiro Hayashi; Programmable ATM Adapter: Rapid Prototyping of Cell Processing Equipment fpr ATM Network; 1997 IEEE.
Kelly, T., "Cheap Internet Hardware that Fits in Everything", ZDNet, <http://www.zdnet.co.uk/news/1998/44/ns-5998.html>, Nov. 1998. *
Kenneth G. Yocum; Jeffery S. Chase, Andrew J. Gallatin, and Alvin R. Lebeck; Cut-Through Delivery in Trapeze: An Exercise in Low-Latency Messaging, 1997 IEEE.
Kittadeya et al., "Matsushita Launches WebTV Internet Connection Terminal", <http://www.mei.co.jp/corp/news/official.data/data.dir/en981112-1/en981112-1.html>, Nov. 1998. *
Kjersti Moldeklev, Espen Klovning, and Oivind Kure; The Effect of End System Hardware and Software on TCP/IP Throughout Performance Over a Local ATM Network.
Larry D. Wittie and Fanyuan Ma; A TCP/IP Communication Subsystem in Micros; 1987 IEEE.
Lucas Womack, Ronald Mraz, and Abraham Mendelson; A study of Virtual Memory MTU Reassembly Within the PowerPC Architecture; 1997 IEEE.
Martin Siegel, Mark Williams, and George Robler; Overcoming Bottlenecks in High-Speed Transport Systems; 1991 IEEE.
Matthias A. Blumrich, Cezary Dubnicki, Edward W. Felten, and Kai Li; Protected User-Level DMA for the SHRIMP Network Interface; 1996 IEEE.
Michael J.K. Nielsen; TURBOchannel; 1991 IEEE.
Michael Yang and Ahmed Tantawy; A Design Methodology for Protocol Processors; 1995 IEEE.
Mohammad Mansour and Ayman Kayssi; FPGA-Based Inernet Protocol Version 6 Router, 1998 IEEE.
P. Camarda, F. Pipio, and G. Piscitelli; Performance Evaluation of TCP/IP Protocol Implementations in End Systems; IEEE Proc.-Computing Digit. Tech., vol. 146, No. 1, Jan. 1999.
Pankaj Gupta and Nick McKeown; Algorithms for Packet Clasification; IEEE Network; Mar./Apr. 2001.
Peter a. Steenkiste; A Systematic Approach to Host Interface Design for High-Speed Networks; IEEE Mar. 1994.
Peter Druschel, Mark B. Abbott, Michael a. Pagels, and Larry L. Peterson; Network Subsystem Design; IEEE Network; Jul. 1993.
Peter Steenkiste; A High-Speed Network Interface for Distributed-Memory Systems: Architecture and Applications; ACM Transactions on Computer Systems; vol. 15, No. 1; Feb. 1997.
Peter Steenkiste; Design, Implementation, and Evaluation of a Single-copoy Protocol Stack; Spftware-Practice and Experience, vol. 28; Jun. 1998.
Piyush Shivam; Pete Wyckoff; Dhableswar Panda; EMP: Zero-Coopy OS-Bypass NIC-Driven Gigabit Ethernet Message Passing; SC 2001; Nov. 2001.
Richard Ames; Building an Embedded Web Server from Scratch; Circuit Cellar INK; Issue 91; Feb. 1998.
Ronald P. Luijten; An OC-12 ATM Switch Adapter Chipset; 1998 IEEE.
S. Varada, Y. Yang, and D. Evans; Data and Buffer Management in ATM Systems.
T. V. Lakshman, and U. Madhow; Performance Analysis of Window-Based Flow Control Using TCP/IP: Effect of High Bandwidth-Delay Products and Random Loss; High Performance Networking, 1994 IFIP.
Takahiko Nagata, Yasuhiro Hosada and Hiroyuki Yamashita; High-Performance TCP/IP/ATM Communications Board; NTT Review; vol. 9, No. 6; Nov. 1997.
V.S. Inanov-Loshkanov, S.F. Sevast'yanov, M.N. Semenov, I.M. Timofeev, V.A. Fogel, and A.M. Frenkel; Network Microprocessor Adapter; Avtomatika I Vychislitel'naya Tekhnika, vol. 17, No. 5; 1983.
W.K. Giloi and P. Behr; AN IPC Protocol and its Hardware Realization for a High-Speed Distributed Multicomputer System; 1981 IEEE.
William Frederick Jolitz; High-Speed Nettworking; Header prediciton and forward-error correction for very high-speed data transfer, Dr. Dobb's Journal; Aug. 1992.
William S. Marcus, Ilija Hadzic, Anthony J. McAully, and Jonathan M. Smith; Protocol Boosters: Applying Programmability to Network Infrastructures; IEEE Communications Magazine; Oct. 1998.
Wright; Intelligent Ethernet Boards; EDN; Jun. 23, 1988.
Zubin D. Dittia, Guru M. Parulkar, and Jerome R. Cox, Jr.; The APIC Approach to High Performance Network Interface Design: Protected DMA and Other Techniques; 1997 IEEE.

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8135842B1 (en) 1999-08-16 2012-03-13 Nvidia Corporation Internet jack

Similar Documents

Publication Publication Date Title
US6034963A (en) Multiple network protocol encoder/decoder and data processor
EP1131930B1 (en) Partitioning of file for emulating streaming
JP5220974B2 (en) Apparatus and method for acceleration of hardware execution or operating system functions
US8359411B2 (en) Data filtering using central DMA mechanism
US20070030861A1 (en) System, method, and computer program product for an offload engine with DMA capabilities
EP0597262B1 (en) Method and apparatus for gradually degrading video data
US20020046221A1 (en) Method, system, and apparatus for providing data regarding the operation and monitoring of a control system
US20060259582A1 (en) System and method for storing and processing data for display on a display device
US20030188054A1 (en) Data transfer apparatus and method
EP0594024A1 (en) Method and apparatus for enabling data paths on a remote bus
WO2008115344A1 (en) Presentation of media in an application
KR20020019435A (en) Method and apparatus for re-formatting web pages
US8843969B2 (en) Inflight entertainment system
US20120166585A1 (en) Apparatus and method for accelerating virtual desktop
WO1999027456A1 (en) Apparent network interface for and between embedded and host processors
TW447205B (en) Multiple network protocol encoder/decoder and date processor
USRE39501E1 (en) Multiple network protocol encoder/decoder and data processor
CN101060447A (en) IP network-based method and system for realizing the multi-media communication
US7370078B1 (en) Determining a remote device name
US20120219070A1 (en) System and method for a thin-client terminal system with a local screen buffer using a serial bus
KR100760025B1 (en) Method for providing from user information requested via ubiquitous robotics companion and ubiquitous robotics companion of enabling the method
KR20000076490A (en) Tct/ip/ppp modem
CN115278366B (en) Data processing method and device for video stream of virtual machine and electronic equipment
JP4025533B2 (en) Stream video reception control method, stream video distribution system, and stream video reception device
JP4064626B2 (en) Communication protocol

Legal Events

Date Code Title Description
AS Assignment

Owner name: RWI GROUP III, L.P., AS COLLATERAL AGENT, CALIFORN

Free format text: SECURITY INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:013447/0460

Effective date: 20030228

Owner name: NATIONAL SEMICONDUCTOR CORPORATION, CALIFORNIA

Free format text: SECURITY AGREEMENT;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:013447/0365

Effective date: 20030228

AS Assignment

Owner name: TELOS VENTURE PARTNERS II, L.P., AS COLLATERAL AGE

Free format text: SECURITY AGREEMENT;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:014128/0994

Effective date: 20031114

AS Assignment

Owner name: LANZA TECHVENTURE, COLLATERAL AGENT, CALIFORNIA

Free format text: SECURITY AGREEEMENT;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:014409/0910

Effective date: 20040311

AS Assignment

Owner name: LANZA TECHVENTURE AS COLLETERAL AGENT, CALIFORNIA

Free format text: SECURITY INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:014428/0212

Effective date: 20040311

AS Assignment

Owner name: GLEN PATENT GROUP, CALIFORNIA

Free format text: MECHANICS' LIEN;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:015215/0490

Effective date: 20040414

AS Assignment

Owner name: IREADY CORPORATION, CALIFORNIA

Free format text: TERMINATION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:TELOS VENTURE PARTNERS II, L.P.;REEL/FRAME:014556/0326

Effective date: 20040415

Owner name: IREADY CORPORATION, CALIFORNIA

Free format text: TERMINATION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:RWI GROUP III, L.P., AS COLLATERAL AGENT;REEL/FRAME:014556/0316

Effective date: 20040415

Owner name: IREADY CORPORATION, CALIFORNIA

Free format text: TERMINATION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:LANZA TECHVENTURE, AS COLLATERAL AGENT;REEL/FRAME:014556/0307

Effective date: 20040415

Owner name: IREADY CORPORATION, CALIFORNIA

Free format text: TERMINATION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:NATIONAL SEMICONDUCTOR CORPORATION;REEL/FRAME:014556/0265

Effective date: 20040415

AS Assignment

Owner name: NVIDIA CORPORATION,CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:015320/0112

Effective date: 20040421

Owner name: NVIDIA CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:015320/0112

Effective date: 20040421

AS Assignment

Owner name: IREADY CORPORATION, CALIFORNIA

Free format text: RELEASE OF MECHANICS' LIEN;ASSIGNOR:GLENN PATENT GROUP;REEL/FRAME:014615/0943

Effective date: 20040505

AS Assignment

Owner name: NVIDIA CORPORATION,CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:015377/0829

Effective date: 20040421

Owner name: NVIDIA CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:015377/0829

Effective date: 20040421

FEPP Fee payment procedure

Free format text: PAT HOLDER NO LONGER CLAIMS SMALL ENTITY STATUS, ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: STOL); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 8

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 12