US20060221953A1 - Method and apparatus for blind checksum and correction for network transmissions - Google Patents

Method and apparatus for blind checksum and correction for network transmissions Download PDF

Info

Publication number
US20060221953A1
US20060221953A1 US11/097,055 US9705505A US2006221953A1 US 20060221953 A1 US20060221953 A1 US 20060221953A1 US 9705505 A US9705505 A US 9705505A US 2006221953 A1 US2006221953 A1 US 2006221953A1
Authority
US
United States
Prior art keywords
packet
checksum
header
blind
value
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.)
Abandoned
Application number
US11/097,055
Inventor
Claude Basso
Jean Calvignac
Chih-Jen Chang
Philippe Damon
Ronald Fuhs
Natarajan Vaidhyanathan
Fabrice Verplanken
Colin Verrilli
Scott Willenborg
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.)
International Business Machines Corp
Original Assignee
International Business Machines 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
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/097,055 priority Critical patent/US20060221953A1/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BASSO, CLAUDE, CALVIGNAC, JEAN LOUIS, DAMON, PHILIPPE, FUHS, RONALD EDWARD, VAIDHYANATHAN, NATARAJAN, WILLENBORG, SCOTT MICHAEL, CHANG, CHIH-JEN, VERPLANKEN, FABRICE JEAN, VERRILLI, COLIN BEATON
Publication of US20060221953A1 publication Critical patent/US20060221953A1/en
Priority to US12/200,985 priority patent/US8225188B2/en
Abandoned 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/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
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0041Arrangements at the transmitter end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0061Error detection codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0072Error control for data other than payload data, e.g. control data
    • 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

Definitions

  • the present invention relates to network transmissions for computer devices, and more particularly to error detection using checksums in network transmissions.
  • Computer systems communicate over networks by establishing and using network connections.
  • data may be lost during network transmission, and various techniques are used to ensure that data is not lost in transit.
  • An additional concern is the risk that errors will be introduced in data from transmission over the network.
  • One technique for detecting network transmission errors in data uses what is known as a checksum.
  • the basic technique of a checksum is to take a string of data bytes (or other unit of storage) and add them together, then send this sum with the data stream and have the receiver check the sum using the same method used to create the sum. If the receiver's calculated sum matches the sum in the data stream, then no errors have been introduced during transmission.
  • TCP Transmission Control Protocol
  • TCP provides basic protection against errors in transmission by including a 16-bit Checksum field in the header of each data packet.
  • a standard algorithm is used to calculate the checksum which is slightly different than a conventional checksum algorithm.
  • a 12-byte TCP pseudo header is created prior to checksum calculation. This header includes information taken from fields in both the TCP header and the IP datagram into which the TCP segment will be encapsulated.
  • the TCP pseudo header includes a source Internet Protocol (IP) address of the originator (taken from the IP header), destination IP address of the intended recipient (taken from the IP header), a reserved field, a protocol field for specifying the protocol used, and a TCP length field specifying the length of the TCP segment including header and data (body) (which is calculated by the originator).
  • IP Internet Protocol
  • the formed pseudo header is placed in a buffer, followed by the TCP segment, and the checksum is computed over this set of data (pseudo header plus TCP segment).
  • the value of the checksum is placed into the Checksum field of the TCP header, and the pseudo header is discarded, since it is not an actual part of the packet and is not transmitted.
  • the packet is transmitted over the network, and the receiver performs the same calculation by forming the pseudo header performing the checksum (ignoring the Checksum value in the header field to replicate the original condition). If there is a mismatch between its calculation and the value in the Checksum field, this indicates that an error of some sort occurred, and the packet can then be discarded or the error noted.
  • the checksum thus protects against errors in the TCP segment fields and against incorrect segment delivery (if there is a mismatch in the Source or Destination Address), incorrect protocol, and incorrect segment length.
  • TCP checksum generation is often performed in hardware to achieve faster performance. Since the TCP checksum field is in the packet header, which is transmitted before the packet data, true “on-the-fly” checksum generation is not provided. The packet data must be stored in transmission data buffers, and once the entire packet is received, the checksum can be generated and placed in the header, and then the packet can then start to be transmitted.
  • This packet transmission method requires random access to the data buffers storing the packet, so that the checksum field can be accessed and written to with the determined checksum value.
  • This random access capability to a large output buffer adds expense to the system and is slow and sequential, adding latency to the system.
  • the determination of the checksum value can add processing time to the transmission process, since the checksum value is determined only after the packet is fully stored in the data buffer.
  • portions of the packets to be transmitted are often stored in different configurations.
  • the header of a packet might be stored in an area of memory easily retrieved with a descriptor, but the body of the packet may be stored elsewhere in memory. Or the header may be stored with the body.
  • a method for determining a checksum for a packet to be transmitted on a network includes retrieving packet information from a storage device, the packet information to be included in the packet to be transmitted. A blind checksum value is determined based on the retrieved packet information, the blind checksum value is adjusted to a protocol checksum based on descriptor information describing the structure of the packet. The protocol checksum is inserted in the packet before the packet is transmitted.
  • an apparatus for determining a checksum for a packet to be transmitted on a network includes a memory access unit that retrieves packet information from a storage device, the packet information to be included in the packet to be transmitted.
  • An accumulator determines a blind checksum value based on the retrieved packet information, and a transmission unit adjusts the blind checksum value to a protocol checksum based on descriptor information describing the structure of the packet.
  • the transmission unit inserts the protocol checksum in the packet and outputs the packet for transmission on the network.
  • the present invention provides a method and apparatus that allows efficient checksum determination and transmission of packets having a checksum by determining a blind checksum, if necessary, and adjusting that blind checksum on-the-fly and without random accesses to data buffers.
  • the invention allows low-latency checksum determination and packet transmission and flexibility in handling multiple packet information storage configurations.
  • FIG. 1 is a block diagram of an example of a system suitable for use with the present invention
  • FIGS. 2 a , 2 b , and 2 c are block diagrams illustrating different packet transmission systems that process packets and outputs them on a connection line to a network;
  • FIG. 3 is a block diagram illustrating a packet transmission system of the present invention which can handle the different situations illustrated in FIGS. 2 a - 2 c;
  • FIG. 4 is a flow diagram illustrating a method of the present invention for providing a checksum for a packet to be transmitted over a network
  • FIGS. 5 a and 5 b are flow diagrams illustrating a method of the present invention for adjusting and determining a checksum value.
  • the present invention relates to network transmissions for computer devices, and more particularly to error detection using checksums in network transmissions.
  • the following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements.
  • Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art.
  • the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
  • the present invention is mainly described in terms of systems provided in particular implementations. However, one of ordinary skill in the art will readily recognize that this method and system will operate effectively in other implementations.
  • the system architectures and network configurations usable with the present invention can take a number of different forms.
  • the present invention will also be described in the context of particular methods having certain steps. However, the method and system operate effectively for other methods having different and/or additional steps not inconsistent with the present invention.
  • FIGS. 1 through 5 b To more particularly describe the features of the present invention, please refer to FIGS. 1 through 5 b in conjunction with the discussion below.
  • the present invention is described in the context of a TCP/IP protocol network system; however, other protocols (such as User Datagram Protocol (UDP), etc.) and configurations can be used in other embodiments.
  • UDP User Datagram Protocol
  • FIG. 1 is a block diagram of a system 10 suitable for use with the present invention.
  • System 10 is a computer system such as a server, mainframe, desktop client computer, workstation, or other computer or electronic device.
  • System 10 can communicate with various other computer systems 12 over a network 14 .
  • System 10 can run one or more applications 16 , which are processes running on the system.
  • an application 16 can provide data that is to be sent out over the network to one or more computer systems 12 .
  • System 10 includes one or more TCP/IP stacks 20 to manage network communications to and from the system 10 .
  • the stack 20 is process code in an operating system or user software space running on the server which handles the incoming and outgoing data to and from the network connections 14 .
  • the TCP/IP stack can establish a new network connection to a server application 16 , provide packets to an existing connection, etc.
  • Each application 16 may have one or more connections.
  • the stack 20 (and/or other components) can provide data from application 16 as TCP/IP network packets to destination ports and addresses over the network 14 .
  • the stack 20 also receives network packets provided by other computer devices 12 on the network and provides the packets to the application 16 via network connections.
  • the TCP/IP stack 20 can access main storage 22 of the system 10 to store packets intended to be sent out on the network 14 .
  • Storage 22 can be any suitable type of memory provided on a computer system, as is well known.
  • One or more device drivers 18 is running on the system 10 and can interface with the main memory 22 as well as the network adapter 24 .
  • the device driver 18 can, for example, write a packet descriptor into the main storage 22 with some parameters given by the TCP/IP stack 20 or even by an application 16 .
  • the packet descriptor (“descriptor”) includes characteristics for a packet to be transmitted and instructions as to what actions to take for the packet, which may be stored elsewhere in main storage 22 , such as in buffers, and a pointer or address of where portions of the packet is stored in main storage 22 , if applicable.
  • a network adapter 24 is used to provide the physical connection point between the system 10 and other computer systems 12 connected to the network 14 .
  • Adapter 24 can be, for example, a hardware network interface adapter.
  • the adapter can take packets provided in main storage 22 and process them for transmission on the network, and send out the packets, as well as receive packets from the network 14 .
  • the adapter 14 includes processing components so that the adapter can determine a TCP checksum that is added to each TCP/IP data packet before it is output on the network 14 . This is detailed below with respect to FIGS. 2 a - c and FIG. 3 .
  • a checksum value is added to the header of each TCP packet using a particular method so that a receiver of the packet can use the same checksum method to generate its own checksum value and compare with the checksum value in the packet to determine if the packet has any transmission errors.
  • a “packet”, as referenced herein, is an entire TCP/IP packet, including an Ethernet header (including a Media Access Control (MAC) address), followed by an Internet Protocol (IP) header, followed by a TCP header, and followed by a body (data).
  • IP Internet Protocol
  • the TCP segment is the TCP header and the body.
  • the terms apply analogously to other protocols used in other embodiments, such as UDP.
  • a packet for transmission may be split such that different parts of the packet are stored in different areas of main memory 22 by the stack 20 .
  • FIG. 2 a is a block diagram illustrating a packet transmission system 50 including main storage 22 and a hardware adapter 52 that processes packets and outputs them on a connection line 56 .
  • a descriptor 58 has been written into the main storage 22 by a device driver or other program running on the system 10 which governs the sending out of a packet (e.g., with some parameters given by the TCP/IP stack 20 or even by an application 16 ).
  • the descriptor 58 includes instructions as to what actions to take for an associated packet stored elsewhere in main storage 22 , and a pointer or address of where the body of the packet is stored in main storage 22 .
  • Header 60 is the header for the packet associated with the descriptor 58 .
  • the header includes the standard TCP and IP header information, as well as other header information such as Ethernet MAC address, if applicable.
  • the header was placed in the main buffer main storage by the TCP/IP stack 20 , while the Ethernet header, if present, was placed by an Ethernet device driver.
  • Body 62 is stored in the buffer in the same partition of main storage 22 as the header 60 and is the data for the packet associated with the descriptor 58 . Body 62 was placed in main storage by an application 16 running on the system or was copied there by the TCP/IP stack 20 .
  • a Tx processor 64 on the adapter 52 retrieves the descriptor 58 from an area of main storage 22 (a “descriptor area” which is the area where the descriptor is stored). The Tx processor 64 then instructs a Direct Memory Access (DMA) unit 66 to retrieve the packet header 60 and body 62 from the buffer of main storage 22 at an address indicated by the retrieved descriptor 58 . The DMA unit 66 provides the retrieved packet header and body to the data buffers 68 of the adapter 52 . Tx processor 64 retrieves the header and body from data buffers 68 using random access, e.g., one byte at a time, and determines a checksum.
  • DMA Direct Memory Access
  • the checksum is calculated by creating a TCP pseudo header that includes parts of the IP header within the header 60 (a source IP address, destination IP address, and protocol), and a TCP segment length (calculated by processor 64 or received as information in the descriptor 58 ). The checksum is calculated based on the TCP segment and pseudo header.
  • the Tx processor then writes the checksum value back to the data buffers 70 in the TCP checksum field of the header 60 .
  • the header and body are then output from the data buffers 70 on the network connection line 56 to a destination on the network.
  • FIG. 2 b is a block diagram illustrating a packet transmission system 100 including main storage 22 and a hardware adapter 104 that processes packets and outputs them on a connection line 106 .
  • a descriptor 108 has been written into a descriptor area of main storage 22 by a device driver or other program running on the system 10 .
  • the descriptor 108 includes instructions as to what actions to take for an associated packet stored elsewhere in main storage 22 , and a pointer or address of where the body of the packet is stored in main storage 22 .
  • the header 110 of the packet associated with the descriptor 108 is stored in same descriptor area and block of main storage 22 as the descriptor 108 .
  • the header 110 can directly follow the descriptor 108 in memory.
  • This storage scheme may have occurred to due particular circumstances and efficiencies in the system 10 .
  • the protocol stack 20 and device driver may coordinate to store the descriptor and header in the same block of main storage, for efficiency.
  • there may be advantages for keeping application data (the body) separate from the header e.g., in the case that the application wishes to eliminate the copy of data by the TCP/IP stack between application buffers and operating system kernel buffers (a.k.a. a “zero-copy”).
  • the body 112 of the packet is stored in the buffer of main storage 22 at some location and memory block different than descriptor 108 and header 110 .
  • a Tx processor 114 on the adapter 104 retrieves the descriptor 108 and header 110 from main storage 22 .
  • the Tx processor 114 then instructs a DMA unit 116 to retrieve the packet body 112 from main storage 22 at an address indicated by the descriptor 108 .
  • the DMA unit 116 provides the body 112 to the data buffers 118 of the adapter 104 .
  • the Tx processor 114 retrieves the body 112 from the data buffers 118 using random access, e.g., one byte at a time, and determines a checksum. As in the example of FIG. 2 a , the checksum is calculated over the TCP segment of the packet and a created pseudo header.
  • the Tx processor stores the checksum value in the header 110 and the header 110 is sent to a merge block 120 from Tx processor 114 .
  • the data buffers 118 are instructed to send the body 112 to merge block 120 after the header 100 , so that the body is merged with the header and the full packet is output on connection line 106 .
  • This system 100 requires less access and writing to the data buffers 118 than the system 50 of FIG. 2 a and thus can be more efficient (and merge unit is typically more efficient than writing to data buffers 118 ).
  • FIG. 2 c is a block diagram illustrating a packet transmission system 150 including main storage 22 and a hardware adapter 154 that processes data packets and outputs them on a connection line 156 .
  • the descriptor 158 , the associated packet header 160 , and the associated packet body 162 are stored in the descriptor area of main storage 102 , e.g., contiguously. This storage configuration is made possible if the body 162 is small enough in size so that it does not need to be stored and processed using larger data buffers 168 .
  • the descriptor 158 , header 160 , and body 162 are retrieved by the Tx processor 164 of the adapter 154 , which has all the information it needs to calculate a checksum as explained above, add the checksum to the appropriate field of the header 160 , and output the header 160 and body 162 as a packet on connection line 156 .
  • This example and system do not require use of a DMA unit 166 or data buffers 168 on the adapter 154 , and do not require address translation to read the packet information from the buffer of main storage 22 , and thus is the most efficient of the examples of FIGS. 2 a - 2 c.
  • FIG. 3 is a block diagram illustrating a packet transmission system 200 of the present invention.
  • Advantages of system 200 include its ability to handle any of the three cases illustrated in FIGS. 2 a - c , and it performs on-the-fly checksum accumulation and checksum adjustment, and thus faster, more efficient packet transmission. Furthermore, it requires no random access to the data buffers and thus no additional logic and latency for that function.
  • System 200 includes main storage 22 and a network hardware adapter 204 , which includes components that process packets to be sent out and output the packets on a connection line 206 of the network.
  • Main storage 22 stores the parts of the packet that is to be transmitted. The possible storage locations for parts of the packet are all illustrated in FIG. 3 , to indicate that all of these cases can be handled by system 200 .
  • a descriptor 208 is stored in main storage 22 , by a device driver or other program running on the system 10 which is sending out a packet, in a descriptor area.
  • the header 210 of the packet is stored in the same descriptor area and block of memory as the descriptor 208 , as described above with reference to FIG. 2 b .
  • the body 212 (if it is small enough) is stored in the same descriptor area and block of memory with the descriptor 208 and header 210 , as described above with reference to FIG.
  • header 210 and the body 212 are stored in a buffer area of main storage 22 different than the area storing descriptor 208 , as described above with reference to FIGS. 2 a and 2 b.
  • the processing system 200 on adapter 204 includes a Tx processor 216 that controls the packet transmission functions of the system 200 .
  • Tx processor 216 retrieves descriptor 208 and other packet information (if present) from main storage 22 , and sends appropriate instructions and data to the components of the system 200 to control their operation, including a DMA unit 218 , data buffers 220 , a merge unit 222 , and an XCS unit 224 .
  • packet information refers to a packet header 210 and/or body 212 .
  • DMA unit 218 retrieves the header 210 and body 212 of the packet, if stored in a different area of main storage than the descriptor 208 .
  • an accumulator 219 has been added to the DMA unit 218 to perform a blind checksum for received data on-the-fly (as it is being retrieved), and provides the blind checksum value to Tx processor 216 , which sends the blind checksum value to the XCS unit 224 .
  • the merge unit 222 merges any packet information provided by the Tx processor (such as header 210 in some cases) with any packet information received from the data buffers 220 .
  • the data buffers 220 are large enough to hold the maximum size of packet usable with the system 200 and computer system 10 .
  • Transmit Checksum (XCS) unit 224 of the present invention is provided after merge unit 222 and receives the packet information merged by that unit.
  • the XCS unit performs an adjustment and correction of the blind checksum value provided by the Tx processor 216 to create a standard TCP checksum value.
  • the XCS unit is given other information from the Tx processor 216 to facilitate the adjustment process.
  • the XCS unit can adjust the blind checksum as the packet header is received, and outputs the packet on line 206 and out to the network 14 on-the-fly after the adjustment of the blind checksum is performed based on the header of the packet.
  • embodiments of the system 200 of the present invention can perform multiple DMA actions by DMA unit 218 .
  • DMA unit 218 there can be “gather” descriptors in descriptor 208 , which are different DMA instructions, each pointing to different areas of memory. This can cause several DMA operations to happen sequentially by the DMA unit 218 . This can be appropriate, for example, in a case in which packet information for a packet, such as the body, is split across many different non-contiguous areas of main storage 22 ; each DMA action can retrieve packet information from a different area of main storage.
  • Tx processors 216 and DMA units 218 working in parallel to speed the processing of packets.
  • FIG. 4 is a flow diagram illustrating a method 250 of the present invention for providing a checksum for a packet to be transmitted over a network. This process is implemented preferably by the network adapter 24 in hardware.
  • a descriptor 208 is retrieved from the descriptor area of main storage 22 by the Tx processor 216 . Any packet information stored in the descriptor area which may be stored with the descriptor (in appropriate cases) is also retrieved, such as header 210 , or header 210 and body 212 , of the packet.
  • the process checks whether there is packet information in the main buffer of main storage 22 to be loaded. In some cases, the entire body 212 and header 210 was loaded to the Tx processor 216 with the descriptor 208 in step 254 , and thus no packet information need be loaded from the main buffer. In some other cases, the body 212 and/or the descriptor 210 are stored in the main buffer. In yet other cases, part of the body 212 is stored with the descriptor 208 , and part of the body 212 is stored in the main buffer.
  • step 258 the packet information and other information needed to determine the TCP checksum (explained in greater detail with respect to step 270 ) is provided to the XCS unit 224 from the Tx processor 216 .
  • the packet information can be sent via the merge unit 222 , without any actual merging occurring, and the other information can be directly provided to the XCS unit, or in other embodiments the other information can be sent via the merge unit 222 with the packet.
  • the XCS unit calculates a TCP checksum from the received information.
  • the checksum is calculated using a pseudo header based on the information in the IP header and from the descriptor, and the checksum calculated based on the TCP segment and pseudo header.
  • An example method for calculating the checksum is described below with reference to FIGS. 5 a and 5 b . It should be noted that in this case, the checksum is being created rather than adjusted/corrected, since no blind checksum was previously determined. The process then continues to step 272 , described below.
  • step 262 the DMA unit 218 is instructed by the Tx processor 216 to load the packet information from the buffer of main storage 22 at an address indicated by address or pointer information in the retrieved descriptor 208 , and a blind checksum is calculated.
  • the header 210 and the body 212 are retrieved as packet information from main storage 22 in this step, while in other cases, just the body 212 is retrieved.
  • the blind checksum of step 262 is calculated by an accumulator 219 which can be included in the DMA unit 218 . It is a “blind” checksum in the sense that the accumulator does not follow established rules to create a TCP checksum, i.e., with a pseudo header; it instead accumulates a sum simply based on the values of successive normally aligned halfwords (2-byte strings of bits) of packet information retrieved from the buffer of main storage 22 (storage units other than halfwords can be processed in other embodiments).
  • All the halfwords transferred from main storage 22 are included, from the start of the packet up to the end of the IP payload, i.e., including Ethernet header, the IP header, the TCP header, and the body of the packet that are included as the payload of the surrounding IP packet information. Not included are the Ethernet padding bytes (if any) or the Ethernet Cyclical Redundancy Check (CRC), a.k.a. a Frame Check Sequence (FCS) 4-bytes at the end. If the packet information starts or ends on an odd boundary in memory, as indicated by the addresses where it is stored, then the packet information is padded with a zero appropriately to allow the packet to properly align on an even boundary.
  • next step 264 the buffer packet information from main storage 22 is stored in the data buffers 220 (this actually can occur as each portion of the packet information is being retrieved by the DMA unit).
  • the accumulated blind checksum value is sent to the Tx processor 216 .
  • step 266 it is checked whether the header 210 was with the body 212 in the packet information retrieved from the buffer of main storage 22 in step 262 .
  • the header 210 was retrieved with the body 212 from the buffer area of main storage 22 and both header and body are stored in data buffers 220 ; if this is the case, the process continues to step 270 , described below, where both header and body are sent via the merge unit 222 to the XCS unit 224 .
  • the header 210 is not retrieved with the body 212 , since the header 210 was retrieved by the Tx processor 216 in step 254 with the descriptor 208 from the descriptor area of main storage 22 . If this is the case, then the process continues to step 268 , in which the header from the Tx processor 216 and the body from the data buffers 220 is merged at the merge unit 222 .
  • the Tx processor 216 sends the header 210 to the merge unit 222 , and then instructs that the body 212 in the data buffers 118 be sent to the merge block 222 to be placed after the header 210 so that the header is merged with the body to create the full packet.
  • the process then continues to step 270 .
  • the packet and other information is sent from or via the merge unit 222 to the XCS unit 224 .
  • the other information is directly sent from the Tx processor 216 to the XCS unit 224 .
  • the other information can be sent with the packet via the merge unit 222 , e.g., prepended to the packet as a “sticker” which is later removed by the XCS unit; such an embodiment requires no direct connections of Tx processor and XCS unit.
  • the other information includes the blind checksum value and an immediate data length (IMMLEN) value that indicates the number of bytes of the packet which has not been included in the blind checksum of step 262 (known from the descriptor 208 ).
  • IMMLEN immediate data length
  • the other information may also include an IP start offset indicating the offset in halfwords (or other storage unit) at which the IP header begins from the beginning of the packet, a TCP start offset indicating the offset at which the TCP segment begins from the beginning of the packet, and a TCP checksum offset indicating the offset in halfwords at which the TCP checksum field begins.
  • the XCS unit 224 does not parse this offset information from the packet, but instead receives it directly from the Tx processor 216 , where the Tx processor retrieved it from the descriptor 208 .
  • the XCS unit 224 can parse the packet to determine these offsets, e.g., start at the beginning of the packet at, e.g., Ethernet packet information, and continue field by field to the IP header start, the TCP header start, the TCP checksum field start, etc.
  • the XCS unit 224 can include a small buffer (e.g., 256 bytes) allowing random access to access the checksum field (which could end up at virtually any location in the buffer due to various Ethernet, IP, and TCP header lengths and previous packet sizes which may still be in the buffer).
  • the buffer is used to store the packet (or a portion thereof) until the checksum is fully determined.
  • step 272 the XCS unit 224 adjusts the blind checksum value to correct this checksum so that it corresponds to a TCP checksum.
  • the XCS unit determines whether to adjust the blind checksum value based on examined halfwords in the packet. The XCS unit performs this function on the fly, as each halfword is being received; thus, step 272 is preferably integrated with step 274 as the packet information is being received.
  • a method that the XCS unit 224 can use to adjust the blind checksum value, and achieve the TCP checksum, is described in greater detail below with respect to FIGS. 5 a and 5 b.
  • the XCS unit 224 places the determined TCP checksum in the TCP header of the packet, using the TCP checksum field offset received as other information in step 270 or 258 , and sends the packet out on the line 206 out to the network 14 .
  • the TCP checksum value is placed in the checksum field and the packet is begun to be transmitted, and all remaining halfwords of the packet received at the XCS unit 224 can be output on line 206 on the fly, as they are received; this is a significant advantage of the present invention.
  • the process is then complete at 276 .
  • each byte of the packet does not have to be ready from a “distance” and the checksum need not be calculated after the packet is received; rather, the checksum is accumulated as the packet passes, both in the accumulator 219 and in the XCS unit 224 , which is much more efficient.
  • FIGS. 5 a and 5 b are flow diagrams illustrating a method detailing a particular implementation of step 272 of method 250 of FIG. 4 , in which the XCS unit 224 adjusts the blind checksum value to achieve a TCP checksum (or calculates the TCP checksum directly without using a blind checksum, in some cases).
  • the method of FIGS. 5 a and 5 b is just one example of how the final checksum determination can be implemented.
  • a halfword pointer (HP) is moved to the next halfword (HW) in the received packet information.
  • the pointer starts at the first halfword of the packet (offset zero).
  • the XCS unit 224 receives the blind checksum value from the Tx processor 216 , and the packet information that is to be transmitted via the merge unit 222 . As each halfword is received by the XCS unit, it moves its halfword pointer to that received halfword, to achieve on-the-fly examination and adjustment of the blind checksum value.
  • this method assumes the XCS unit received other information from the Tx processor 216 , such as various offsets required in order to know the positions of various fields in the packet and to store it in the TCP header.
  • the XCS unit knows where the IP header starts due to having received an IP header offset, and knows where the TCP header starts by having received a TCP header offset.
  • the XCS unit can determine or parse these offsets by moving the pointer a known, standard number of bits or bytes through the packet information for each field and offset. Based on these offsets, the XCS can calculate the offsets of other fields such as the IP SA and DA offsets, needed for the checksum determination.
  • one of the other values received from the Tx processor 216 is the IMMLEN value, which is the immediate data length for the packet, i.e., the number of bytes in the packet that have not been included in the blind checksum, as known from the descriptor 108 .
  • IMMLEN the immediate data length for the packet, i.e., the number of bytes in the packet that have not been included in the blind checksum, as known from the descriptor 108 .
  • IMMLEN is the immediate data length for the packet, i.e., the number of bytes in the packet that have not been included in the blind checksum, as known from the descriptor 108 .
  • IMMLEN is the immediate data length for the packet, i.e., the number of bytes in the packet that have not been included in the blind checksum, as known from the descriptor 108 .
  • IMMLEN is not zero (i.e., positive)
  • some of the packet halfwords were not included in the blind checksum,
  • next step 286 the process checks whether the halfword pointer is at the IP source address (SA) or the IP destination address (DA) stored in the IP header of the packet. This information typically is specified in full words, so there are two halfwords provided for each address. If the pointer is at a halfword for one of these addresses, then the process checks in step 288 whether IMMLEN is equal to zero. If so, then as indicated in step 290 the checksum is not adjusted, and the process returns to step 284 to move to and examine the next halfword. If IMMLEN is not equal to zero, then this IP address information was not included in the blind checksum, and in step 292 the current halfword is added to the blind checksum. This is because the IP source and destination addresses are required for TCP checksum determination, i.e., these addresses are included in the pseudo header used in TCP checksum determination. The process then returns to step 284 .
  • SA IP source address
  • DA IP destination address
  • step 294 the process checks whether the halfword pointer is at a halfword describing the protocol field and time-to-live (TTL) field of the IP header of the packet. Each of these fields is a byte, and thus the halfword would include both fields. If the pointer is at this halfword, then in step 296 the process checks whether IMMLEN is equal to zero (i.e., whether this halfword is already included in the blind checksum). If so, in step 298 the TTL portion (byte) of the halfword is subtracted out, since the TTL field is not needed in the pseudo header to determine the TCP checksum; this leaves the protocol field, which is needed in the pseudo header.
  • TTL time-to-live
  • step 284 the process then returns to step 284 to move to and examine the next halfword. If IMMLEN is not equal to zero, then this IP address information was not included in the blind checksum, and in step 300 the protocol portion of the halfword (byte) is added to the blind checksum, since the protocol field is needed in the pseudo header. The process then returns to step 284 .
  • step 302 the process checks whether the halfword pointer is at a halfword describing the Version field (half byte), IP Header Length (HL) field (half byte), and Type of Service (TOS) field (1 byte) of the IP header of the packet. If the pointer is at this halfword, then in step 304 the process checks whether IMMLEN is equal to zero. If so, in step 306 this halfword is subtracted from the blind checksum, since these fields are not needed in the TCP pseudo header. In addition, the IP Header Length field is saved in a hardware latch (or other convenient storage), since this field is needed for step 314 (described below). The process then returns to step 284 .
  • IMMLEN is not equal to zero, then the current halfword was not included in the blind checksum, and in step 308 the IP Header Length field is subtracted from the blind checksum. This is in anticipation of step 316 (described below), in which the total length is added; since the required pseudo header length field is the TCP segment length (IP total length minus IP header length), the IP Header Length can be subtracted out now.
  • the process then returns to step 284 . Note that this is an advantage of the present invention: a normally unused adder cycle in which the XCS unit would do nothing, is instead efficiently utilized to make an adjustment to the blind checksum in anticipation of other adjustments, thus saving additional operations at the time of those later adjustments and avoiding the use of additional halfword adders.
  • step 310 the process checks whether the halfword pointer is at a halfword describing the IP Total Length field of the packet in the IP header of the packet. If the pointer is at this halfword, then in step 312 the process checks whether IMMLEN is equal to zero and this halfword is included in the blind checksum. If so, in step 314 the IP Header Length field saved in a latch in step 306 is subtracted from the blind checksum, since the pseudo header needs the TCP segment length (i.e., IP total length minus IP header length) to determine the TCP checksum. The process then returns to step 284 .
  • IMMLEN is not equal to zero, then the current halfword was not included in the blind checksum, and in step 316 the current halfword is added to the blind checksum. This creates the desired TCP segment length in the pseudo header since the IP Header Length is subtracted in step 308 . The process then returns to step 284 .
  • step 318 the process checks whether the halfword pointer is less than or equal to the IP header end, i.e. whether the pointer is at a halfword in the IP header that is not covered by the steps described above. If the pointer is at such a halfword location in the packet, then in step 320 the process checks whether IMMLEN is equal to zero and this halfword is included in the blind checksum. If so, in step 322 the current halfword is subtracted from the blind checksum value, since the pseudo header or TCP checksum does not need any other IP header halfwords or fields except those described in the steps above. The process then returns to step 284 . If IMMLEN is not equal to zero, then the current halfword was not included in the blind checksum, and as indicated in step 324 , the checksum is not adjusted. The process then returns to step 284 .
  • step 318 If the check of step 318 is negative, then the process continues to step 326 , as detailed in FIG. 5 b .
  • the remaining steps include situations where the halfword pointer is pointed to halfwords in the TCP header, the TCP payload, and after the TCP payload.
  • step 326 the process checks whether the halfword pointer is equal to the TCP checksum field. If so, in step 328 , the process checks whether the halfword pointer is equal to IMMLEN, i.e., whether the current halfword has an offset equal to the number of bytes not included in the blind checksum. If so, then it indicates that the halfword pointer is at the halfword at a boundary, and that the checksum field is at that boundary. In step 330 the process checks whether IMMLEM is on an even-numbered address boundary. If so, a halfword is subtracted out in step 332 , and the process returns to step 284 .
  • IMMLEN i.e., whether the current halfword has an offset equal to the number of bytes not included in the blind checksum. If so, then it indicates that the halfword pointer is at the halfword at a boundary, and that the checksum field is at that boundary.
  • step 330 the process checks whether IMMLEM is on an even-numbered address boundary. If so, a half
  • step 334 If on an odd boundary, then only the lower byte of the halfword is subtracted out in step 334 , since the upper byte is already included in the blind checksum. The process then returns to step 284 . If the pointer is not equal to IMMLEN at step 328 , then in step 336 the process checks whether the pointer is greater than IMMLEN. If so, a halfword is subtracted out in step 338 , and the process returns to step 284 . If not, the checksum is not adjusted as indicated in step 340 , and the process returns to step 284 .
  • step 326 the process checks whether the halfword pointer is equal to IMMLEN, i.e., whether the current halfword has an offset equal to the number of bytes not included in the blind checksum. If so, then it indicates that the halfword pointer is at the halfword at a boundary, such as the boundary between the IP header and the TCP header, or the boundary at the end of the packet; the location of the boundary depends on how much of the packet was included in the blind checksum.
  • step 328 the process checks whether IMMLEM is on an odd-numbered address boundary. If so, then in step 330 only the upper byte of the current halfword is added to the blind checksum value, since the lower byte belongs to the TCP header, for example, and was already included in the blind checksum value.
  • the blind checksum value has thus been fully adjusted to conform to a TCP checksum, and the process is then complete at 338 . If the pointer is at an even numbered boundary, then no additional bytes need be added, and the blind checksum value is not corrected as indicated in step 332 (e.g., a zero can be added). The adjustment/correction process of the blind checksum is then over as indicated at 338 , resulting in a TCP checksum value.
  • step 334 the process checks whether the halfword pointer is greater than IMMLEN, i.e., whether the current halfword is at a halfword already included in the blind checksum or is after the end of the TCP payload. If so, then remaining halfwords are already included in the blind checksum value, and the checksum is not adjusted as indicated in step 336 . The adjustment process of the blind checksum to a TCP checksum value is then over as indicated at 338 . If the halfword pointer is not greater than IMMLEN at step 334 , then it is less than IMMLEN and pointing to a halfword that was not included in the blind checksum.
  • step 340 the current halfword is added to the blind checksum, and the process then returns to step 284 for the next halfword.
  • step 340 can add halfwords to the checksum from the TCP header or body which were not included in the blind checksum (or if a blind checksum was never created, e.g., the body 212 was provided directly to Tx processor 216 ).
  • FIGS. 5 a and 5 b assumes that the header 210 is not stored so that it is split between the descriptor area of main storage 22 and the buffer area of main storage, i.e., that the header data remains contiguous. This is because this process assumes that the IMMLEN value, retrieved from the descriptor 108 , does not fall within the Ethernet or IP header, i.e., it is either zero or greater than the start offset of the IP header.

Abstract

Method and apparatus for providing a checksum in a network transmission. In one aspect of the invention, a checksum for a packet to be transmitted on a network is determined by retrieving packet information from a storage device, the packet information to be included in the packet to be transmitted. A blind checksum value is determined based on the retrieved packet information, and the blind checksum value is adjusted to a protocol checksum based on descriptor information describing the structure of the packet. The protocol checksum is inserted in the packet before the packet is transmitted.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application is related to the following copending U.S. patent applications:
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050059US1/3485P), entitled “Host Ethernet Adapter for Networking Offload in Server Environment”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050060US 1/3486P), entitled “Method and System for Accommodating Several Ethernet Ports and a Wrap Transmitted Flow Handled by a Simplified Frame-By-Frame Upper Structure”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050061US1/3487P), entitled “Method and Apparatus for Providing a Network Connection Table”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050062US1/3488P), entitled “Network Communications for Operating System Partitions”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050073US1/3502P), entitled “Configurable Ports for a Host Ethernet Adapter”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050074US1/3503P, entitled “System and Method for Parsing, Filtering, and Computing the Checksum in a Host Ethernet Adapter (HEA)”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050075US 1/3504P), entitled “System and Method for a Method for Reducing Latency in a Host Ethernet Adapter (HEA)”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050082US 1/3512P), entitled “Method and System for Performing a Packet Header Lookup”, filed on even date herewith and assigned to the assignee of the present invention.
  • U.S. patent application, Ser. No. ______ (Attorney Docket No. RPS920050089US1/3516P), entitled “System and Method for Computing a Blind Checksum in a Host Ethernet Adapter (HEA)”, filed on even date herewith and assigned to the assignee of the present invention.
  • FIELD OF THE INVENTION
  • The present invention relates to network transmissions for computer devices, and more particularly to error detection using checksums in network transmissions.
  • BACKGROUND OF THE INVENTION
  • Computer systems communicate over networks by establishing and using network connections. When providing secure network connections, one concern is that data may be lost during network transmission, and various techniques are used to ensure that data is not lost in transit. An additional concern is the risk that errors will be introduced in data from transmission over the network. One technique for detecting network transmission errors in data uses what is known as a checksum. The basic technique of a checksum is to take a string of data bytes (or other unit of storage) and add them together, then send this sum with the data stream and have the receiver check the sum using the same method used to create the sum. If the receiver's calculated sum matches the sum in the data stream, then no errors have been introduced during transmission.
  • For example, the Transmission Control Protocol (TCP) provides basic protection against errors in transmission by including a 16-bit Checksum field in the header of each data packet. In TCP, a standard algorithm is used to calculate the checksum which is slightly different than a conventional checksum algorithm. Instead of computing the checksum over only the actual data fields of the TCP segment, a 12-byte TCP pseudo header is created prior to checksum calculation. This header includes information taken from fields in both the TCP header and the IP datagram into which the TCP segment will be encapsulated. The TCP pseudo header includes a source Internet Protocol (IP) address of the originator (taken from the IP header), destination IP address of the intended recipient (taken from the IP header), a reserved field, a protocol field for specifying the protocol used, and a TCP length field specifying the length of the TCP segment including header and data (body) (which is calculated by the originator). The formed pseudo header is placed in a buffer, followed by the TCP segment, and the checksum is computed over this set of data (pseudo header plus TCP segment). The value of the checksum is placed into the Checksum field of the TCP header, and the pseudo header is discarded, since it is not an actual part of the packet and is not transmitted.
  • The packet is transmitted over the network, and the receiver performs the same calculation by forming the pseudo header performing the checksum (ignoring the Checksum value in the header field to replicate the original condition). If there is a mismatch between its calculation and the value in the Checksum field, this indicates that an error of some sort occurred, and the packet can then be discarded or the error noted. The checksum thus protects against errors in the TCP segment fields and against incorrect segment delivery (if there is a mismatch in the Source or Destination Address), incorrect protocol, and incorrect segment length.
  • TCP checksum generation is often performed in hardware to achieve faster performance. Since the TCP checksum field is in the packet header, which is transmitted before the packet data, true “on-the-fly” checksum generation is not provided. The packet data must be stored in transmission data buffers, and once the entire packet is received, the checksum can be generated and placed in the header, and then the packet can then start to be transmitted.
  • One problem with this packet transmission method is that it requires random access to the data buffers storing the packet, so that the checksum field can be accessed and written to with the determined checksum value. This random access capability to a large output buffer adds expense to the system and is slow and sequential, adding latency to the system. Furthermore, the determination of the checksum value can add processing time to the transmission process, since the checksum value is determined only after the packet is fully stored in the data buffer.
  • In addition, portions of the packets to be transmitted are often stored in different configurations. For example, the header of a packet might be stored in an area of memory easily retrieved with a descriptor, but the body of the packet may be stored elsewhere in memory. Or the header may be stored with the body. However, there are no existing methods to efficiently combine parts of a packet and handle the different packet storage configurations for checksum determination when transmitting.
  • Accordingly, what is needed is an apparatus and method for providing a network transmission mechanism that can efficiently process checksums for outgoing packets with minimal access to storage buffers, much-reduced latency, and efficient handling of packet storage configurations. The present invention addresses such a need.
  • SUMMARY OF THE INVENTION
  • The invention of the present application relates to providing a checksum in a network transmission. In one aspect of the invention, a method for determining a checksum for a packet to be transmitted on a network includes retrieving packet information from a storage device, the packet information to be included in the packet to be transmitted. A blind checksum value is determined based on the retrieved packet information, the blind checksum value is adjusted to a protocol checksum based on descriptor information describing the structure of the packet. The protocol checksum is inserted in the packet before the packet is transmitted.
  • In another aspect of the invention, an apparatus for determining a checksum for a packet to be transmitted on a network includes a memory access unit that retrieves packet information from a storage device, the packet information to be included in the packet to be transmitted. An accumulator determines a blind checksum value based on the retrieved packet information, and a transmission unit adjusts the blind checksum value to a protocol checksum based on descriptor information describing the structure of the packet. The transmission unit inserts the protocol checksum in the packet and outputs the packet for transmission on the network.
  • The present invention provides a method and apparatus that allows efficient checksum determination and transmission of packets having a checksum by determining a blind checksum, if necessary, and adjusting that blind checksum on-the-fly and without random accesses to data buffers. The invention allows low-latency checksum determination and packet transmission and flexibility in handling multiple packet information storage configurations.
  • BRIEF DESCRIPTION OF THE FIGURES
  • FIG. 1 is a block diagram of an example of a system suitable for use with the present invention;
  • FIGS. 2 a, 2 b, and 2 c are block diagrams illustrating different packet transmission systems that process packets and outputs them on a connection line to a network;
  • FIG. 3 is a block diagram illustrating a packet transmission system of the present invention which can handle the different situations illustrated in FIGS. 2 a-2 c;
  • FIG. 4 is a flow diagram illustrating a method of the present invention for providing a checksum for a packet to be transmitted over a network; and
  • FIGS. 5 a and 5 b are flow diagrams illustrating a method of the present invention for adjusting and determining a checksum value.
  • DETAILED DESCRIPTION
  • The present invention relates to network transmissions for computer devices, and more particularly to error detection using checksums in network transmissions. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
  • The present invention is mainly described in terms of systems provided in particular implementations. However, one of ordinary skill in the art will readily recognize that this method and system will operate effectively in other implementations. For example, the system architectures and network configurations usable with the present invention can take a number of different forms. The present invention will also be described in the context of particular methods having certain steps. However, the method and system operate effectively for other methods having different and/or additional steps not inconsistent with the present invention.
  • To more particularly describe the features of the present invention, please refer to FIGS. 1 through 5 b in conjunction with the discussion below. The present invention is described in the context of a TCP/IP protocol network system; however, other protocols (such as User Datagram Protocol (UDP), etc.) and configurations can be used in other embodiments.
  • FIG. 1 is a block diagram of a system 10 suitable for use with the present invention. System 10 is a computer system such as a server, mainframe, desktop client computer, workstation, or other computer or electronic device. System 10 can communicate with various other computer systems 12 over a network 14. System 10 can run one or more applications 16, which are processes running on the system. For example, an application 16 can provide data that is to be sent out over the network to one or more computer systems 12.
  • System 10 includes one or more TCP/IP stacks 20 to manage network communications to and from the system 10. The stack 20 is process code in an operating system or user software space running on the server which handles the incoming and outgoing data to and from the network connections 14. The TCP/IP stack can establish a new network connection to a server application 16, provide packets to an existing connection, etc. Each application 16 may have one or more connections. For example, the stack 20 (and/or other components) can provide data from application 16 as TCP/IP network packets to destination ports and addresses over the network 14. The stack 20 also receives network packets provided by other computer devices 12 on the network and provides the packets to the application 16 via network connections. The TCP/IP stack 20 can access main storage 22 of the system 10 to store packets intended to be sent out on the network 14. Storage 22 can be any suitable type of memory provided on a computer system, as is well known.
  • One or more device drivers 18 is running on the system 10 and can interface with the main memory 22 as well as the network adapter 24. The device driver 18 can, for example, write a packet descriptor into the main storage 22 with some parameters given by the TCP/IP stack 20 or even by an application 16. The packet descriptor (“descriptor”) includes characteristics for a packet to be transmitted and instructions as to what actions to take for the packet, which may be stored elsewhere in main storage 22, such as in buffers, and a pointer or address of where portions of the packet is stored in main storage 22, if applicable.
  • A network adapter 24 is used to provide the physical connection point between the system 10 and other computer systems 12 connected to the network 14. Adapter 24 can be, for example, a hardware network interface adapter. The adapter can take packets provided in main storage 22 and process them for transmission on the network, and send out the packets, as well as receive packets from the network 14. For example, in the present invention, the adapter 14 includes processing components so that the adapter can determine a TCP checksum that is added to each TCP/IP data packet before it is output on the network 14. This is detailed below with respect to FIGS. 2 a-c and FIG. 3.
  • A checksum value is added to the header of each TCP packet using a particular method so that a receiver of the packet can use the same checksum method to generate its own checksum value and compare with the checksum value in the packet to determine if the packet has any transmission errors. A “packet”, as referenced herein, is an entire TCP/IP packet, including an Ethernet header (including a Media Access Control (MAC) address), followed by an Internet Protocol (IP) header, followed by a TCP header, and followed by a body (data). The TCP segment is the TCP header and the body. The terms apply analogously to other protocols used in other embodiments, such as UDP.
  • A packet for transmission may be split such that different parts of the packet are stored in different areas of main memory 22 by the stack 20. Three examples that show how a packet intended for transmission may be distributed in main storage 22, and that show different systems for an adapter 20 for processing those packet distributions, are described below with reference to FIGS. 2 a, 2 b, and 2 c.
  • FIG. 2 a is a block diagram illustrating a packet transmission system 50 including main storage 22 and a hardware adapter 52 that processes packets and outputs them on a connection line 56. In the example of FIG. 2 a, a descriptor 58 has been written into the main storage 22 by a device driver or other program running on the system 10 which governs the sending out of a packet (e.g., with some parameters given by the TCP/IP stack 20 or even by an application 16). The descriptor 58 includes instructions as to what actions to take for an associated packet stored elsewhere in main storage 22, and a pointer or address of where the body of the packet is stored in main storage 22.
  • Header 60 is the header for the packet associated with the descriptor 58. The header includes the standard TCP and IP header information, as well as other header information such as Ethernet MAC address, if applicable. The header was placed in the main buffer main storage by the TCP/IP stack 20, while the Ethernet header, if present, was placed by an Ethernet device driver. Body 62 is stored in the buffer in the same partition of main storage 22 as the header 60 and is the data for the packet associated with the descriptor 58. Body 62 was placed in main storage by an application 16 running on the system or was copied there by the TCP/IP stack 20.
  • When transmitting the packet, a Tx processor 64 on the adapter 52 retrieves the descriptor 58 from an area of main storage 22 (a “descriptor area” which is the area where the descriptor is stored). The Tx processor 64 then instructs a Direct Memory Access (DMA) unit 66 to retrieve the packet header 60 and body 62 from the buffer of main storage 22 at an address indicated by the retrieved descriptor 58. The DMA unit 66 provides the retrieved packet header and body to the data buffers 68 of the adapter 52. Tx processor 64 retrieves the header and body from data buffers 68 using random access, e.g., one byte at a time, and determines a checksum. The checksum is calculated by creating a TCP pseudo header that includes parts of the IP header within the header 60 (a source IP address, destination IP address, and protocol), and a TCP segment length (calculated by processor 64 or received as information in the descriptor 58). The checksum is calculated based on the TCP segment and pseudo header. The Tx processor then writes the checksum value back to the data buffers 70 in the TCP checksum field of the header 60. The header and body are then output from the data buffers 70 on the network connection line 56 to a destination on the network.
  • FIG. 2 b is a block diagram illustrating a packet transmission system 100 including main storage 22 and a hardware adapter 104 that processes packets and outputs them on a connection line 106. In the example of FIG. 2 b, a descriptor 108 has been written into a descriptor area of main storage 22 by a device driver or other program running on the system 10. Similar to the example of FIG. 2 a, the descriptor 108 includes instructions as to what actions to take for an associated packet stored elsewhere in main storage 22, and a pointer or address of where the body of the packet is stored in main storage 22.
  • In this example, the header 110 of the packet associated with the descriptor 108 is stored in same descriptor area and block of main storage 22 as the descriptor 108. For example, the header 110 can directly follow the descriptor 108 in memory. This storage scheme may have occurred to due particular circumstances and efficiencies in the system 10. For example, the protocol stack 20 and device driver may coordinate to store the descriptor and header in the same block of main storage, for efficiency. Or, there may be advantages for keeping application data (the body) separate from the header, e.g., in the case that the application wishes to eliminate the copy of data by the TCP/IP stack between application buffers and operating system kernel buffers (a.k.a. a “zero-copy”). The body 112 of the packet is stored in the buffer of main storage 22 at some location and memory block different than descriptor 108 and header 110.
  • When transmitting the packet, a Tx processor 114 on the adapter 104 retrieves the descriptor 108 and header 110 from main storage 22. The Tx processor 114 then instructs a DMA unit 116 to retrieve the packet body 112 from main storage 22 at an address indicated by the descriptor 108. The DMA unit 116 provides the body 112 to the data buffers 118 of the adapter 104. The Tx processor 114 retrieves the body 112 from the data buffers 118 using random access, e.g., one byte at a time, and determines a checksum. As in the example of FIG. 2 a, the checksum is calculated over the TCP segment of the packet and a created pseudo header. The Tx processor stores the checksum value in the header 110 and the header 110 is sent to a merge block 120 from Tx processor 114. The data buffers 118 are instructed to send the body 112 to merge block 120 after the header 100, so that the body is merged with the header and the full packet is output on connection line 106. This system 100 requires less access and writing to the data buffers 118 than the system 50 of FIG. 2 a and thus can be more efficient (and merge unit is typically more efficient than writing to data buffers 118).
  • FIG. 2 c is a block diagram illustrating a packet transmission system 150 including main storage 22 and a hardware adapter 154 that processes data packets and outputs them on a connection line 156. In this system, the descriptor 158, the associated packet header 160, and the associated packet body 162 are stored in the descriptor area of main storage 102, e.g., contiguously. This storage configuration is made possible if the body 162 is small enough in size so that it does not need to be stored and processed using larger data buffers 168. When transmitted the packet, the descriptor 158, header 160, and body 162 are retrieved by the Tx processor 164 of the adapter 154, which has all the information it needs to calculate a checksum as explained above, add the checksum to the appropriate field of the header 160, and output the header 160 and body 162 as a packet on connection line 156. This example and system do not require use of a DMA unit 166 or data buffers 168 on the adapter 154, and do not require address translation to read the packet information from the buffer of main storage 22, and thus is the most efficient of the examples of FIGS. 2 a-2 c.
  • FIG. 3 is a block diagram illustrating a packet transmission system 200 of the present invention. Advantages of system 200 include its ability to handle any of the three cases illustrated in FIGS. 2 a-c, and it performs on-the-fly checksum accumulation and checksum adjustment, and thus faster, more efficient packet transmission. Furthermore, it requires no random access to the data buffers and thus no additional logic and latency for that function.
  • System 200 includes main storage 22 and a network hardware adapter 204, which includes components that process packets to be sent out and output the packets on a connection line 206 of the network.
  • Main storage 22 stores the parts of the packet that is to be transmitted. The possible storage locations for parts of the packet are all illustrated in FIG. 3, to indicate that all of these cases can be handled by system 200. Thus, a descriptor 208 is stored in main storage 22, by a device driver or other program running on the system 10 which is sending out a packet, in a descriptor area. In some cases, the header 210 of the packet is stored in the same descriptor area and block of memory as the descriptor 208, as described above with reference to FIG. 2 b. And in some cases, the body 212 (if it is small enough) is stored in the same descriptor area and block of memory with the descriptor 208 and header 210, as described above with reference to FIG. 2 c (also, the IP header portion of the header 210 could be stored with the descriptor 208 and the TCP header portion of header 210 stored with the body 212). In other cases, the header 210 and the body 212, or just the body 212, are stored in a buffer area of main storage 22 different than the area storing descriptor 208, as described above with reference to FIGS. 2 a and 2 b.
  • The processing system 200 on adapter 204 includes a Tx processor 216 that controls the packet transmission functions of the system 200. Tx processor 216 retrieves descriptor 208 and other packet information (if present) from main storage 22, and sends appropriate instructions and data to the components of the system 200 to control their operation, including a DMA unit 218, data buffers 220, a merge unit 222, and an XCS unit 224. The term “packet information,” as used herein, refers to a packet header 210 and/or body 212.
  • DMA unit 218 retrieves the header 210 and body 212 of the packet, if stored in a different area of main storage than the descriptor 208. In the present invention, an accumulator 219 has been added to the DMA unit 218 to perform a blind checksum for received data on-the-fly (as it is being retrieved), and provides the blind checksum value to Tx processor 216, which sends the blind checksum value to the XCS unit 224. The merge unit 222 merges any packet information provided by the Tx processor (such as header 210 in some cases) with any packet information received from the data buffers 220. The data buffers 220 are large enough to hold the maximum size of packet usable with the system 200 and computer system 10.
  • Transmit Checksum (XCS) unit 224 of the present invention is provided after merge unit 222 and receives the packet information merged by that unit. The XCS unit performs an adjustment and correction of the blind checksum value provided by the Tx processor 216 to create a standard TCP checksum value. The XCS unit is given other information from the Tx processor 216 to facilitate the adjustment process. The XCS unit can adjust the blind checksum as the packet header is received, and outputs the packet on line 206 and out to the network 14 on-the-fly after the adjustment of the blind checksum is performed based on the header of the packet.
  • It should be noted that embodiments of the system 200 of the present invention can perform multiple DMA actions by DMA unit 218. For example, there can be “gather” descriptors in descriptor 208, which are different DMA instructions, each pointing to different areas of memory. This can cause several DMA operations to happen sequentially by the DMA unit 218. This can be appropriate, for example, in a case in which packet information for a packet, such as the body, is split across many different non-contiguous areas of main storage 22; each DMA action can retrieve packet information from a different area of main storage.
  • In some embodiments, there can be multiple Tx processors 216 and DMA units 218 working in parallel to speed the processing of packets.
  • FIG. 4 is a flow diagram illustrating a method 250 of the present invention for providing a checksum for a packet to be transmitted over a network. This process is implemented preferably by the network adapter 24 in hardware.
  • The process begins at 252, and in step 254, a descriptor 208 is retrieved from the descriptor area of main storage 22 by the Tx processor 216. Any packet information stored in the descriptor area which may be stored with the descriptor (in appropriate cases) is also retrieved, such as header 210, or header 210 and body 212, of the packet. In step 256, the process checks whether there is packet information in the main buffer of main storage 22 to be loaded. In some cases, the entire body 212 and header 210 was loaded to the Tx processor 216 with the descriptor 208 in step 254, and thus no packet information need be loaded from the main buffer. In some other cases, the body 212 and/or the descriptor 210 are stored in the main buffer. In yet other cases, part of the body 212 is stored with the descriptor 208, and part of the body 212 is stored in the main buffer.
  • If no packet information need be loaded from the main buffer, then the process continues to step 258, in which the packet information and other information needed to determine the TCP checksum (explained in greater detail with respect to step 270) is provided to the XCS unit 224 from the Tx processor 216. The packet information can be sent via the merge unit 222, without any actual merging occurring, and the other information can be directly provided to the XCS unit, or in other embodiments the other information can be sent via the merge unit 222 with the packet. In next step 260, the XCS unit calculates a TCP checksum from the received information. The checksum is calculated using a pseudo header based on the information in the IP header and from the descriptor, and the checksum calculated based on the TCP segment and pseudo header. An example method for calculating the checksum is described below with reference to FIGS. 5 a and 5 b. It should be noted that in this case, the checksum is being created rather than adjusted/corrected, since no blind checksum was previously determined. The process then continues to step 272, described below.
  • If the packet body was not retrieved with descriptor 208 as checked in step 256, then the process continues to step 262, in which the DMA unit 218 is instructed by the Tx processor 216 to load the packet information from the buffer of main storage 22 at an address indicated by address or pointer information in the retrieved descriptor 208, and a blind checksum is calculated. In some cases, the header 210 and the body 212 are retrieved as packet information from main storage 22 in this step, while in other cases, just the body 212 is retrieved.
  • The blind checksum of step 262 is calculated by an accumulator 219 which can be included in the DMA unit 218. It is a “blind” checksum in the sense that the accumulator does not follow established rules to create a TCP checksum, i.e., with a pseudo header; it instead accumulates a sum simply based on the values of successive normally aligned halfwords (2-byte strings of bits) of packet information retrieved from the buffer of main storage 22 (storage units other than halfwords can be processed in other embodiments). All the halfwords transferred from main storage 22 are included, from the start of the packet up to the end of the IP payload, i.e., including Ethernet header, the IP header, the TCP header, and the body of the packet that are included as the payload of the surrounding IP packet information. Not included are the Ethernet padding bytes (if any) or the Ethernet Cyclical Redundancy Check (CRC), a.k.a. a Frame Check Sequence (FCS) 4-bytes at the end. If the packet information starts or ends on an odd boundary in memory, as indicated by the addresses where it is stored, then the packet information is padded with a zero appropriately to allow the packet to properly align on an even boundary.
  • In next step 264, the buffer packet information from main storage 22 is stored in the data buffers 220 (this actually can occur as each portion of the packet information is being retrieved by the DMA unit). In addition, once the packet information from main storage 22 is fully retrieved, the accumulated blind checksum value is sent to the Tx processor 216. In step 266, it is checked whether the header 210 was with the body 212 in the packet information retrieved from the buffer of main storage 22 in step 262. In one case, the header 210 was retrieved with the body 212 from the buffer area of main storage 22 and both header and body are stored in data buffers 220; if this is the case, the process continues to step 270, described below, where both header and body are sent via the merge unit 222 to the XCS unit 224.
  • In the other case, the header 210 is not retrieved with the body 212, since the header 210 was retrieved by the Tx processor 216 in step 254 with the descriptor 208 from the descriptor area of main storage 22. If this is the case, then the process continues to step 268, in which the header from the Tx processor 216 and the body from the data buffers 220 is merged at the merge unit 222. For example, the Tx processor 216 sends the header 210 to the merge unit 222, and then instructs that the body 212 in the data buffers 118 be sent to the merge block 222 to be placed after the header 210 so that the header is merged with the body to create the full packet. The process then continues to step 270.
  • In step 270, the packet and other information is sent from or via the merge unit 222 to the XCS unit 224. The other information is directly sent from the Tx processor 216 to the XCS unit 224. In other embodiments, the other information can be sent with the packet via the merge unit 222, e.g., prepended to the packet as a “sticker” which is later removed by the XCS unit; such an embodiment requires no direct connections of Tx processor and XCS unit. The other information includes the blind checksum value and an immediate data length (IMMLEN) value that indicates the number of bytes of the packet which has not been included in the blind checksum of step 262 (known from the descriptor 208).
  • Depending on the parsing abilities of the XCS unit in different embodiments, the other information may also include an IP start offset indicating the offset in halfwords (or other storage unit) at which the IP header begins from the beginning of the packet, a TCP start offset indicating the offset at which the TCP segment begins from the beginning of the packet, and a TCP checksum offset indicating the offset in halfwords at which the TCP checksum field begins. For example, in the described embodiment, the XCS unit 224 does not parse this offset information from the packet, but instead receives it directly from the Tx processor 216, where the Tx processor retrieved it from the descriptor 208. In a different embodiment, the XCS unit 224 can parse the packet to determine these offsets, e.g., start at the beginning of the packet at, e.g., Ethernet packet information, and continue field by field to the IP header start, the TCP header start, the TCP checksum field start, etc.
  • The XCS unit 224 can include a small buffer (e.g., 256 bytes) allowing random access to access the checksum field (which could end up at virtually any location in the buffer due to various Ethernet, IP, and TCP header lengths and previous packet sizes which may still be in the buffer). The buffer is used to store the packet (or a portion thereof) until the checksum is fully determined.
  • In next step 272, the XCS unit 224 adjusts the blind checksum value to correct this checksum so that it corresponds to a TCP checksum. The XCS unit determines whether to adjust the blind checksum value based on examined halfwords in the packet. The XCS unit performs this function on the fly, as each halfword is being received; thus, step 272 is preferably integrated with step 274 as the packet information is being received. A method that the XCS unit 224 can use to adjust the blind checksum value, and achieve the TCP checksum, is described in greater detail below with respect to FIGS. 5 a and 5 b.
  • In next step 274, the XCS unit 224 places the determined TCP checksum in the TCP header of the packet, using the TCP checksum field offset received as other information in step 270 or 258, and sends the packet out on the line 206 out to the network 14. Once the XCS unit has examined enough halfwords to have fully adjusted the checksum, then the TCP checksum value is placed in the checksum field and the packet is begun to be transmitted, and all remaining halfwords of the packet received at the XCS unit 224 can be output on line 206 on the fly, as they are received; this is a significant advantage of the present invention. The process is then complete at 276. It should be noted that there is no need to discard a created pseudo header, because a pseudo header is never separately created; rather, it is included in the determined checksum as part of the adjustment process. Another significant advantage of the invention is that the random access needed is limited to only the small size of the buffer in the XCS unit (e.g., 256 bytes), instead of for the large size of the data buffers (e.g., 9 kilobytes for a “jumbo” frame buffer). Random access capability is more expensive to set up for larger buffers. In addition, in the present invention, each byte of the packet does not have to be ready from a “distance” and the checksum need not be calculated after the packet is received; rather, the checksum is accumulated as the packet passes, both in the accumulator 219 and in the XCS unit 224, which is much more efficient.
  • FIGS. 5 a and 5 b are flow diagrams illustrating a method detailing a particular implementation of step 272 of method 250 of FIG. 4, in which the XCS unit 224 adjusts the blind checksum value to achieve a TCP checksum (or calculates the TCP checksum directly without using a blind checksum, in some cases). The method of FIGS. 5 a and 5 b is just one example of how the final checksum determination can be implemented.
  • The process begins at 282 in FIG. 5 a, and in step 284, a halfword pointer (HP) is moved to the next halfword (HW) in the received packet information. The first time step 284 is performed, the pointer starts at the first halfword of the packet (offset zero). As detailed above for FIG. 4, the XCS unit 224 receives the blind checksum value from the Tx processor 216, and the packet information that is to be transmitted via the merge unit 222. As each halfword is received by the XCS unit, it moves its halfword pointer to that received halfword, to achieve on-the-fly examination and adjustment of the blind checksum value. As explained above, this method assumes the XCS unit received other information from the Tx processor 216, such as various offsets required in order to know the positions of various fields in the packet and to store it in the TCP header. E.g., the XCS unit knows where the IP header starts due to having received an IP header offset, and knows where the TCP header starts by having received a TCP header offset. Alternatively, the XCS unit can determine or parse these offsets by moving the pointer a known, standard number of bits or bytes through the packet information for each field and offset. Based on these offsets, the XCS can calculate the offsets of other fields such as the IP SA and DA offsets, needed for the checksum determination.
  • As described above, one of the other values received from the Tx processor 216 is the IMMLEN value, which is the immediate data length for the packet, i.e., the number of bytes in the packet that have not been included in the blind checksum, as known from the descriptor 108. Thus, if IMMLEN equals zero, this indicates that all of the packet halfwords were included in the blind checksum, and that if any adjustment is required for the current halfword, it will be to subtract it from the blind checksum. Likewise, if IMMLEN is not zero (i.e., positive), then some of the packet halfwords were not included in the blind checksum, and subtraction and/or addition of halfwords may be needed for correction. In the described embodiment, it is assumed that IMMLEN is either zero or greater than the IP packet start; this restriction reduces hardware implementation complexity. Other embodiments can used methods to avoid this restriction.
  • In next step 286, the process checks whether the halfword pointer is at the IP source address (SA) or the IP destination address (DA) stored in the IP header of the packet. This information typically is specified in full words, so there are two halfwords provided for each address. If the pointer is at a halfword for one of these addresses, then the process checks in step 288 whether IMMLEN is equal to zero. If so, then as indicated in step 290 the checksum is not adjusted, and the process returns to step 284 to move to and examine the next halfword. If IMMLEN is not equal to zero, then this IP address information was not included in the blind checksum, and in step 292 the current halfword is added to the blind checksum. This is because the IP source and destination addresses are required for TCP checksum determination, i.e., these addresses are included in the pseudo header used in TCP checksum determination. The process then returns to step 284.
  • If the check of step 286 is negative, then in step 294 the process checks whether the halfword pointer is at a halfword describing the protocol field and time-to-live (TTL) field of the IP header of the packet. Each of these fields is a byte, and thus the halfword would include both fields. If the pointer is at this halfword, then in step 296 the process checks whether IMMLEN is equal to zero (i.e., whether this halfword is already included in the blind checksum). If so, in step 298 the TTL portion (byte) of the halfword is subtracted out, since the TTL field is not needed in the pseudo header to determine the TCP checksum; this leaves the protocol field, which is needed in the pseudo header. The process then returns to step 284 to move to and examine the next halfword. If IMMLEN is not equal to zero, then this IP address information was not included in the blind checksum, and in step 300 the protocol portion of the halfword (byte) is added to the blind checksum, since the protocol field is needed in the pseudo header. The process then returns to step 284.
  • If the check of step 294 is negative, then in step 302 the process checks whether the halfword pointer is at a halfword describing the Version field (half byte), IP Header Length (HL) field (half byte), and Type of Service (TOS) field (1 byte) of the IP header of the packet. If the pointer is at this halfword, then in step 304 the process checks whether IMMLEN is equal to zero. If so, in step 306 this halfword is subtracted from the blind checksum, since these fields are not needed in the TCP pseudo header. In addition, the IP Header Length field is saved in a hardware latch (or other convenient storage), since this field is needed for step 314 (described below). The process then returns to step 284. If IMMLEN is not equal to zero, then the current halfword was not included in the blind checksum, and in step 308 the IP Header Length field is subtracted from the blind checksum. This is in anticipation of step 316 (described below), in which the total length is added; since the required pseudo header length field is the TCP segment length (IP total length minus IP header length), the IP Header Length can be subtracted out now. The process then returns to step 284. Note that this is an advantage of the present invention: a normally unused adder cycle in which the XCS unit would do nothing, is instead efficiently utilized to make an adjustment to the blind checksum in anticipation of other adjustments, thus saving additional operations at the time of those later adjustments and avoiding the use of additional halfword adders.
  • If the check of step 302 is negative, then in step 310 the process checks whether the halfword pointer is at a halfword describing the IP Total Length field of the packet in the IP header of the packet. If the pointer is at this halfword, then in step 312 the process checks whether IMMLEN is equal to zero and this halfword is included in the blind checksum. If so, in step 314 the IP Header Length field saved in a latch in step 306 is subtracted from the blind checksum, since the pseudo header needs the TCP segment length (i.e., IP total length minus IP header length) to determine the TCP checksum. The process then returns to step 284. If IMMLEN is not equal to zero, then the current halfword was not included in the blind checksum, and in step 316 the current halfword is added to the blind checksum. This creates the desired TCP segment length in the pseudo header since the IP Header Length is subtracted in step 308. The process then returns to step 284.
  • If the check of step 310 is negative, then in step 318 the process checks whether the halfword pointer is less than or equal to the IP header end, i.e. whether the pointer is at a halfword in the IP header that is not covered by the steps described above. If the pointer is at such a halfword location in the packet, then in step 320 the process checks whether IMMLEN is equal to zero and this halfword is included in the blind checksum. If so, in step 322 the current halfword is subtracted from the blind checksum value, since the pseudo header or TCP checksum does not need any other IP header halfwords or fields except those described in the steps above. The process then returns to step 284. If IMMLEN is not equal to zero, then the current halfword was not included in the blind checksum, and as indicated in step 324, the checksum is not adjusted. The process then returns to step 284.
  • If the check of step 318 is negative, then the process continues to step 326, as detailed in FIG. 5 b. The remaining steps include situations where the halfword pointer is pointed to halfwords in the TCP header, the TCP payload, and after the TCP payload.
  • In step 326, the process checks whether the halfword pointer is equal to the TCP checksum field. If so, in step 328, the process checks whether the halfword pointer is equal to IMMLEN, i.e., whether the current halfword has an offset equal to the number of bytes not included in the blind checksum. If so, then it indicates that the halfword pointer is at the halfword at a boundary, and that the checksum field is at that boundary. In step 330 the process checks whether IMMLEM is on an even-numbered address boundary. If so, a halfword is subtracted out in step 332, and the process returns to step 284. If on an odd boundary, then only the lower byte of the halfword is subtracted out in step 334, since the upper byte is already included in the blind checksum. The process then returns to step 284. If the pointer is not equal to IMMLEN at step 328, then in step 336 the process checks whether the pointer is greater than IMMLEN. If so, a halfword is subtracted out in step 338, and the process returns to step 284. If not, the checksum is not adjusted as indicated in step 340, and the process returns to step 284.
  • In step 326, the process checks whether the halfword pointer is equal to IMMLEN, i.e., whether the current halfword has an offset equal to the number of bytes not included in the blind checksum. If so, then it indicates that the halfword pointer is at the halfword at a boundary, such as the boundary between the IP header and the TCP header, or the boundary at the end of the packet; the location of the boundary depends on how much of the packet was included in the blind checksum. In step 328 the process checks whether IMMLEM is on an odd-numbered address boundary. If so, then in step 330 only the upper byte of the current halfword is added to the blind checksum value, since the lower byte belongs to the TCP header, for example, and was already included in the blind checksum value. The blind checksum value has thus been fully adjusted to conform to a TCP checksum, and the process is then complete at 338. If the pointer is at an even numbered boundary, then no additional bytes need be added, and the blind checksum value is not corrected as indicated in step 332 (e.g., a zero can be added). The adjustment/correction process of the blind checksum is then over as indicated at 338, resulting in a TCP checksum value.
  • If the check of step 326 is negative, then the process continues to step 334, in which the process checks whether the halfword pointer is greater than IMMLEN, i.e., whether the current halfword is at a halfword already included in the blind checksum or is after the end of the TCP payload. If so, then remaining halfwords are already included in the blind checksum value, and the checksum is not adjusted as indicated in step 336. The adjustment process of the blind checksum to a TCP checksum value is then over as indicated at 338. If the halfword pointer is not greater than IMMLEN at step 334, then it is less than IMMLEN and pointing to a halfword that was not included in the blind checksum. Thus, in step 340, the current halfword is added to the blind checksum, and the process then returns to step 284 for the next halfword. For example, step 340 can add halfwords to the checksum from the TCP header or body which were not included in the blind checksum (or if a blind checksum was never created, e.g., the body 212 was provided directly to Tx processor 216).
  • It should be noted that the process of FIGS. 5 a and 5 b assumes that the header 210 is not stored so that it is split between the descriptor area of main storage 22 and the buffer area of main storage, i.e., that the header data remains contiguous. This is because this process assumes that the IMMLEN value, retrieved from the descriptor 108, does not fall within the Ethernet or IP header, i.e., it is either zero or greater than the start offset of the IP header.
  • Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims (28)

1. A method for determining a checksum for a packet to be transmitted on a network, the method comprising:
retrieving packet information from a storage device, the packet information to be included in the packet to be transmitted;
determining a blind checksum value based on the retrieved packet information; and
adjusting the blind checksum value to a protocol checksum based on descriptor information describing the structure of the packet, wherein the protocol checksum is inserted in the packet before the packet is transmitted.
2. The method of claim 1 wherein the blind checksum value is determined by summing all the retrieved packet information.
3. The method of claim 1 wherein adjusting the blind checksum value includes adding or subtracting at least one halfword value of the packet information to or from the blind checksum value.
4. The method of claim 3 wherein the packet to be transmitted is a TCP/IP packet, and wherein adjusting the blind checksum value includes adding a halfword value to the blind checksum value if the halfword value is an IP header field required to determine a TCP checksum value and the halfword value was not included in the blind checksum.
5. The method of claim 3 wherein the packet to be transmitted is a TCP/IP packet, and wherein adjusting the blind checksum value includes subtracting a halfword value from the blind checksum value if the halfword value is an IP header field not required to determine a TCP checksum value and the halfword value was included in the blind checksum.
6. The method of claim 1 wherein the retrieved packet information includes a header and a body of the packet.
7. The method of claim 1 wherein the retrieved packet information includes a body of the packet and no header of the packet, and further comprising retrieving the header of the packet with the descriptor information.
8. The method of claim 7 further comprising merging the header with the body of the packet after the blind checksum is determined for the body.
9. The method of claim 1 further comprising sending the packet information to a data buffer after the blind checksum has been determined, wherein the packet information is retrieved from the data buffer for the adjusting of the blind checksum.
10. The method of claim 1 further comprising retrieving the descriptor information from the storage device.
11. The method of claim 10 wherein the blind checksum value is determined when at a portion of the packet information is stored separately from the descriptor in memory, and further comprising:
determining the protocol checksum based on descriptor information describing the structure of the packet, if the packet information is stored with and retrieved with the descriptor information.
12. The method of claim 1 further comprising determining the descriptor information by parsing the packet information.
13. The method of claim 1 wherein the packet is provided according to the TCP/IP protocol.
14. The method of claim 3 wherein adjusting the blind checksum value includes subtracting out bytes of an IP header portion of the packet information and leaving in bytes of the IP header portion that are needed for a pseudo header to create a TCP checksum.
15. The method of claim 14 wherein adjusting the blind checksum value includes subtracting out one byte of a halfword and keeping the other byte of the halfword for fields in the IP header portion in which only one byte of the field is needed in the pseudo header.
16. The method of claim 3 wherein adjusting the blind checksum value includes subtracting out one byte of a halfword and keeping the other byte of the halfword if the halfword is positioned on a boundary between a portion of the packet information already included in the blind checksum value and a portion not included in the blind checksum value.
17. An apparatus for determining a checksum for a packet to be transmitted on a network, the apparatus comprising:
a memory access unit that retrieves packet information from a storage device, the packet information to be included in the packet to be transmitted;
an accumulator that determines a blind checksum value based on the retrieved packet information; and
a transmission unit that receives the packet information and the blind checksum value and adjusts the blind checksum value to a protocol checksum based on descriptor information describing the structure of the packet, wherein the transmission unit inserts the protocol checksum in the packet and outputs the packet for transmission on the network.
18. The apparatus of claim 17 wherein the accumulator determines the blind checksum value by summing retrieved packet information as it is loaded.
19. The apparatus of claim 17 further comprising a transmission processor, wherein the transmission processor retrieves the descriptor information from the storage device and provides the descriptor information to the transmission unit.
20. The apparatus of claim 19 wherein the transmission processor receives the blind checksum value from the accumulator and provides the blind checksum value to the transmission unit.
21. The apparatus of claim 17 further comprising a data buffer coupled to the memory access unit, wherein the data buffer receives the packet information from the memory access unit, and wherein the packet information is sent from the data buffer to the transmission unit.
22. The apparatus of claim 17 wherein the retrieved packet information includes a header and a body of the packet.
23. The apparatus of claim 17 wherein the retrieved packet information includes a body of the packet and no header of the packet, and wherein the memory access unit retrieves the header of the packet with the descriptor information.
24. The apparatus of claim 23 further comprising a merge unit that merges the header with the body of the packet after the accumulator determines the blind checksum for the body and wherein the transmission unit receives the merged packet information from the merge unit.
25. The apparatus of claim 17 wherein the transmission unit adjusts the blind checksum value includes adding or subtracting at least one halfword value of the packet information to or from the blind checksum value.
26. The apparatus of claim 25 wherein the packet to be transmitted is a TCP/IP packet, and wherein the transmission unit adjusts the blind checksum value by adding a halfword value to the blind checksum value if the halfword value is an IP header field required to determine a TCP checksum value and the halfword value was not included in the blind checksum.
27. The apparatus of claim 25 wherein the packet to be transmitted is a TCP/IP packet, and wherein the transmission unit adjusts the blind checksum value by subtracting a halfword value from the blind checksum value if the halfword value is an IP header field not required to determine a TCP checksum value and the halfword value was included in the blind checksum.
28. The apparatus of claim 19 wherein the transmission processor also retrieves the packet information with the descriptor information from storage device and provides the packet information to the transmission unit, wherein the transmission unit creates the protocol checksum based on the descriptor information.
US11/097,055 2005-04-01 2005-04-01 Method and apparatus for blind checksum and correction for network transmissions Abandoned US20060221953A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/097,055 US20060221953A1 (en) 2005-04-01 2005-04-01 Method and apparatus for blind checksum and correction for network transmissions
US12/200,985 US8225188B2 (en) 2005-04-01 2008-08-29 Apparatus for blind checksum and correction for network transmissions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/097,055 US20060221953A1 (en) 2005-04-01 2005-04-01 Method and apparatus for blind checksum and correction for network transmissions

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/200,985 Continuation US8225188B2 (en) 2005-04-01 2008-08-29 Apparatus for blind checksum and correction for network transmissions

Publications (1)

Publication Number Publication Date
US20060221953A1 true US20060221953A1 (en) 2006-10-05

Family

ID=37070368

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/097,055 Abandoned US20060221953A1 (en) 2005-04-01 2005-04-01 Method and apparatus for blind checksum and correction for network transmissions
US12/200,985 Expired - Fee Related US8225188B2 (en) 2005-04-01 2008-08-29 Apparatus for blind checksum and correction for network transmissions

Family Applications After (1)

Application Number Title Priority Date Filing Date
US12/200,985 Expired - Fee Related US8225188B2 (en) 2005-04-01 2008-08-29 Apparatus for blind checksum and correction for network transmissions

Country Status (1)

Country Link
US (2) US20060221953A1 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070223483A1 (en) * 2005-11-12 2007-09-27 Liquid Computing Corporation High performance memory based communications interface
US20070294426A1 (en) * 2006-06-19 2007-12-20 Liquid Computing Corporation Methods, systems and protocols for application to application communications
US20080148291A1 (en) * 2006-10-30 2008-06-19 Liquid Computing Corporation Kernel functions for inter-processor communications in high performance multi-processor systems
US20080151883A1 (en) * 2006-12-22 2008-06-26 Geoffrey Cockerell Serial digital communication protocol
US20080181245A1 (en) * 2007-01-31 2008-07-31 Claude Basso System and Method for Multicore Communication Processing
JP2010057033A (en) * 2008-08-29 2010-03-11 Nec Electronics Corp Communications apparatus and method therefor
US20110283068A1 (en) * 2010-05-14 2011-11-17 Realtek Semiconductor Corp. Memory access apparatus and method
CN102523205A (en) * 2011-12-05 2012-06-27 中兴通讯股份有限公司 Determination method and device for content checksum
JP2013102556A (en) * 2013-03-05 2013-05-23 Renesas Electronics Corp Communications apparatus and communication method
US20140068134A1 (en) * 2012-08-28 2014-03-06 Huawei Technologies Co., Ltd. Data transmission apparatus, system, and method
US8831658B2 (en) 2010-11-05 2014-09-09 Qualcomm Incorporated Controlling application access to a network
US8838086B2 (en) 2011-08-29 2014-09-16 Qualcomm Incorporated Systems and methods for management of background application events
US9178965B2 (en) 2011-03-18 2015-11-03 Qualcomm Incorporated Systems and methods for synchronization of application communications
US9264868B2 (en) * 2011-01-19 2016-02-16 Qualcomm Incorporated Management of network access requests
US9571952B2 (en) 2011-04-22 2017-02-14 Qualcomm Incorporatd Offloading of data to wireless local area network
US9603085B2 (en) 2010-02-16 2017-03-21 Qualcomm Incorporated Methods and apparatus providing intelligent radio selection for legacy and non-legacy applications
CN109417507A (en) * 2016-06-30 2019-03-01 华为技术有限公司 The message of section retards accesses
JP2019139638A (en) * 2018-02-14 2019-08-22 キヤノン株式会社 Communication device, communication method and program
US20210297157A1 (en) * 2020-03-20 2021-09-23 Arris Enterprises Llc Efficient remote phy dataplane management for a cable system

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8589333B2 (en) * 2008-08-19 2013-11-19 Northrop Grumman Systems Corporation System and method for information sharing across security boundaries
US8891532B1 (en) * 2011-05-17 2014-11-18 Hitachi Data Systems Engineering UK Limited System and method for conveying the reason for TCP reset in machine-readable form
US8683307B2 (en) * 2011-05-27 2014-03-25 International Business Machines Corporation Checksum calculation, prediction and validation
US10936405B2 (en) * 2017-11-13 2021-03-02 Weka.IO Ltd. Efficient networking for a distributed storage system

Citations (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4825406A (en) * 1981-10-05 1989-04-25 Digital Equipment Corporation Secondary storage facility employing serial communications between drive and controller
US5058110A (en) * 1989-05-03 1991-10-15 Ultra Network Technologies Protocol processor
US5359659A (en) * 1992-06-19 1994-10-25 Doren Rosenthal Method for securing software against corruption by computer viruses
US5430842A (en) * 1992-05-29 1995-07-04 Hewlett-Packard Company Insertion of network data checksums by a network adapter
US5442802A (en) * 1992-01-03 1995-08-15 International Business Machines Corporation Asynchronous co-processor data mover method and means
US5752078A (en) * 1995-07-10 1998-05-12 International Business Machines Corporation System for minimizing latency data reception and handling data packet error if detected while transferring data packet from adapter memory to host memory
US5983274A (en) * 1997-05-08 1999-11-09 Microsoft Corporation Creation and use of control information associated with packetized network data by protocol drivers and device drivers
US20010027496A1 (en) * 1997-10-14 2001-10-04 Alacritech, Inc. Passing a communication control block to a local device such that a message is processed on the device
US6400730B1 (en) * 1999-03-10 2002-06-04 Nishan Systems, Inc. Method and apparatus for transferring data between IP network devices and SCSI and fibre channel devices over an IP network
US6427169B1 (en) * 1999-07-30 2002-07-30 Intel Corporation Parsing a packet header
US20030026252A1 (en) * 2001-07-31 2003-02-06 Thunquest Gary L. Data packet structure for directly addressed multicast protocol
US20030088689A1 (en) * 2001-11-08 2003-05-08 Alexander Cedell A. Methods and systems for efficiently delivering data to a plurality of destinations in a computer network
US20030103499A1 (en) * 2001-11-21 2003-06-05 Tom Davis Configurable packet processor
US20030154399A1 (en) * 2002-02-08 2003-08-14 Nir Zuk Multi-method gateway-based network security systems and methods
US6650640B1 (en) * 1999-03-01 2003-11-18 Sun Microsystems, Inc. Method and apparatus for managing a network flow in a high performance network interface
US6658002B1 (en) * 1998-06-30 2003-12-02 Cisco Technology, Inc. Logical operation unit for packet processing
US6678746B1 (en) * 2000-08-01 2004-01-13 Hewlett-Packard Development Company, L.P. Processing network packets
US20040030766A1 (en) * 2002-08-12 2004-02-12 Michael Witkowski Method and apparatus for switch fabric configuration
US6724769B1 (en) * 1999-09-23 2004-04-20 Advanced Micro Devices, Inc. Apparatus and method for simultaneously accessing multiple network switch buffers for storage of data units of data frames
US6728929B1 (en) * 2001-02-16 2004-04-27 Spirent Communications Of Calabasas, Inc. System and method to insert a TCP checksum in a protocol neutral manner
US6735670B1 (en) * 2000-05-12 2004-05-11 3Com Corporation Forwarding table incorporating hash table and content addressable memory
US20040100952A1 (en) * 1997-10-14 2004-05-27 Boucher Laurence B. Method and apparatus for dynamic packet batching with a high performance network interface
US6751229B1 (en) * 1999-07-20 2004-06-15 Sony United Kingdom Limited Network terminator
US6754662B1 (en) * 2000-08-01 2004-06-22 Nortel Networks Limited Method and apparatus for fast and consistent packet classification via efficient hash-caching
US20040128398A1 (en) * 2001-02-15 2004-07-01 Banderacom Work queue to TCP/IP translation
US6788697B1 (en) * 1999-12-06 2004-09-07 Nortel Networks Limited Buffer management scheme employing dynamic thresholds
US6822968B1 (en) * 1999-12-29 2004-11-23 Advanced Micro Devices, Inc. Method and apparatus for accounting for delays caused by logic in a network interface by integrating logic into a media access controller
US20050022017A1 (en) * 2003-06-24 2005-01-27 Maufer Thomas A. Data structures and state tracking for network protocol processing
US20050076136A1 (en) * 2002-09-17 2005-04-07 Samsung Electronics Co., Ltd. Apparatus and method for streaming multimedia data
US20050089031A1 (en) * 2003-10-23 2005-04-28 Jon Krueger Determining a checksum from packet data
US20050108611A1 (en) * 2003-11-14 2005-05-19 Intel Corporation Early CRC delivery for partial frame
US6937574B1 (en) * 1999-03-16 2005-08-30 Nortel Networks Limited Virtual private networks and methods for their operation
US6954463B1 (en) * 2000-12-11 2005-10-11 Cisco Technology, Inc. Distributed packet processing architecture for network access servers
US6970419B1 (en) * 1998-08-07 2005-11-29 Nortel Networks Limited Method and apparatus for preserving frame ordering across aggregated links between source and destination nodes
US6976205B1 (en) * 2001-09-21 2005-12-13 Syrus Ziai Method and apparatus for calculating TCP and UDP checksums while preserving CPU resources
US6988235B2 (en) * 2000-03-02 2006-01-17 Agere Systems Inc. Checksum engine and a method of operation thereof
US20060031600A1 (en) * 2004-08-03 2006-02-09 Ellis Jackson L Method of processing a context for execution
US7023811B2 (en) * 2001-01-17 2006-04-04 Intel Corporation Switched fabric network and method of mapping nodes using batch requests
US7031304B1 (en) * 2002-09-11 2006-04-18 Redback Networks Inc. Method and apparatus for selective packet Mirroring
US7062570B2 (en) * 2000-08-04 2006-06-13 Avaya Technology, Corp. High performance server farm with tagging and pipelining
US7098685B1 (en) * 2003-07-14 2006-08-29 Lattice Semiconductor Corporation Scalable serializer-deserializer architecture and programmable interface
US7124198B2 (en) * 2001-10-30 2006-10-17 Microsoft Corporation Apparatus and method for scaling TCP off load buffer requirements by segment size
US7131140B1 (en) * 2000-12-29 2006-10-31 Cisco Technology, Inc. Method for protecting a firewall load balancer from a denial of service attack
US7134796B2 (en) * 2004-08-25 2006-11-14 Opnext, Inc. XFP adapter module
US7164678B2 (en) * 2001-06-25 2007-01-16 Intel Corporation Control of processing order for received network packets
US7218632B1 (en) * 2000-12-06 2007-05-15 Cisco Technology, Inc. Packet processing engine architecture
US7251704B2 (en) * 2002-08-23 2007-07-31 Intel Corporation Store and forward switch device, system and method
US7260120B2 (en) * 2002-11-07 2007-08-21 Electronics And Telecommunications Research Institute Ethernet switching apparatus and method using frame multiplexing and demultiplexing
US7269661B2 (en) * 2002-02-12 2007-09-11 Bradley Richard Ree Method using receive and transmit protocol aware logic modules for confirming checksum values stored in network packet
US7271706B2 (en) * 2002-10-09 2007-09-18 The University Of Mississippi Termite acoustic detection
US7274706B1 (en) * 2001-04-24 2007-09-25 Syrus Ziai Methods and systems for processing network data
US7283528B1 (en) * 2002-03-22 2007-10-16 Raymond Marcelino Manese Lim On the fly header checksum processing using dedicated logic
US7286557B2 (en) * 2001-11-16 2007-10-23 Intel Corporation Interface and related methods for rate pacing in an ethernet architecture
US7292591B2 (en) * 2004-03-30 2007-11-06 Extreme Networks, Inc. Packet processing system architecture and method
US7292586B2 (en) * 2001-03-30 2007-11-06 Nokia Inc. Micro-programmable protocol packet parser and encapsulator
US7295553B2 (en) * 2001-05-14 2007-11-13 Fujitsu Limited Packet buffer
US7298761B2 (en) * 2003-05-09 2007-11-20 Institute For Information Industry Link path searching and maintaining method for a bluetooth scatternet
US7308006B1 (en) * 2000-02-11 2007-12-11 Lucent Technologies Inc. Propagation and detection of faults in a multiplexed communication system

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1724198A (en) 1927-06-30 1929-08-13 Utica Products Inc Electric heater
US5172371A (en) 1990-08-09 1992-12-15 At&T Bell Laboratories Growable switch
US5793954A (en) 1995-12-20 1998-08-11 Nb Networks System and method for general purpose network analysis
US6041058A (en) 1997-09-11 2000-03-21 3Com Corporation Hardware filtering method and apparatus
US5991299A (en) 1997-09-11 1999-11-23 3Com Corporation High speed header translation processing
US6404752B1 (en) 1999-08-27 2002-06-11 International Business Machines Corporation Network switch using network processor and methods
US8019901B2 (en) 2000-09-29 2011-09-13 Alacritech, Inc. Intelligent network storage interface system
US7366194B2 (en) 2001-04-18 2008-04-29 Brocade Communications Systems, Inc. Fibre channel zoning by logical unit number in hardware
SG155038A1 (en) 2001-09-28 2009-09-30 Consentry Networks Inc A multi-threaded packet processing engine for stateful packet processing
EP1464144A4 (en) 2001-11-09 2010-09-22 Vitesse Semiconductor Corp A means and a method for switching data packets or frames
AU2002365837A1 (en) 2001-12-03 2003-06-17 Tagore-Brage, Jens P. Interface to operate groups of inputs/outputs
US6912612B2 (en) 2002-02-25 2005-06-28 Intel Corporation Shared bypass bus structure
US7304941B2 (en) 2002-04-11 2007-12-04 International Business Machines Corporation Switchover system and method in a data packet switching network
US7349399B1 (en) 2002-09-20 2008-03-25 Redback Networks, Inc. Method and apparatus for out-of-order processing of packets using linked lists
KR100460672B1 (en) 2002-12-10 2004-12-09 한국전자통신연구원 Line interface apparatus for 10 gigabit ethernet and control method thereof
US8296452B2 (en) 2003-03-06 2012-10-23 Cisco Technology, Inc. Apparatus and method for detecting tiny fragment attacks
US7283473B2 (en) 2003-04-10 2007-10-16 International Business Machines Corporation Apparatus, system and method for providing multiple logical channel adapters within a single physical channel adapter in a system area network
US20040218623A1 (en) 2003-05-01 2004-11-04 Dror Goldenberg Hardware calculation of encapsulated IP, TCP and UDP checksums by a switch fabric channel adapter
US8776050B2 (en) 2003-08-20 2014-07-08 Oracle International Corporation Distributed virtual machine monitor for managing multiple virtual resources across multiple physical nodes
JP4437650B2 (en) 2003-08-25 2010-03-24 株式会社日立製作所 Storage system
US20050114663A1 (en) 2003-11-21 2005-05-26 Finisar Corporation Secure network access devices with data encryption
JP2005223829A (en) 2004-02-09 2005-08-18 Nec Electronics Corp Fractional frequency divider circuit and data transmission apparatus using the same
US7502474B2 (en) 2004-05-06 2009-03-10 Advanced Micro Devices, Inc. Network interface with security association data prefetch for high speed offloaded security processing
US7436773B2 (en) 2004-12-07 2008-10-14 International Business Machines Corporation Packet flow control in switched full duplex ethernet networks
US8040903B2 (en) 2005-02-01 2011-10-18 Hewlett-Packard Development Company, L.P. Automated configuration of point-to-point load balancing between teamed network resources of peer devices
US7620754B2 (en) 2005-03-25 2009-11-17 Cisco Technology, Inc. Carrier card converter for 10 gigabit ethernet slots

Patent Citations (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4825406A (en) * 1981-10-05 1989-04-25 Digital Equipment Corporation Secondary storage facility employing serial communications between drive and controller
US5058110A (en) * 1989-05-03 1991-10-15 Ultra Network Technologies Protocol processor
US5442802A (en) * 1992-01-03 1995-08-15 International Business Machines Corporation Asynchronous co-processor data mover method and means
US5430842A (en) * 1992-05-29 1995-07-04 Hewlett-Packard Company Insertion of network data checksums by a network adapter
US5359659A (en) * 1992-06-19 1994-10-25 Doren Rosenthal Method for securing software against corruption by computer viruses
US5752078A (en) * 1995-07-10 1998-05-12 International Business Machines Corporation System for minimizing latency data reception and handling data packet error if detected while transferring data packet from adapter memory to host memory
US5983274A (en) * 1997-05-08 1999-11-09 Microsoft Corporation Creation and use of control information associated with packetized network data by protocol drivers and device drivers
US20010027496A1 (en) * 1997-10-14 2001-10-04 Alacritech, Inc. Passing a communication control block to a local device such that a message is processed on the device
US20040100952A1 (en) * 1997-10-14 2004-05-27 Boucher Laurence B. Method and apparatus for dynamic packet batching with a high performance network interface
US6658002B1 (en) * 1998-06-30 2003-12-02 Cisco Technology, Inc. Logical operation unit for packet processing
US6970419B1 (en) * 1998-08-07 2005-11-29 Nortel Networks Limited Method and apparatus for preserving frame ordering across aggregated links between source and destination nodes
US6650640B1 (en) * 1999-03-01 2003-11-18 Sun Microsystems, Inc. Method and apparatus for managing a network flow in a high performance network interface
US6400730B1 (en) * 1999-03-10 2002-06-04 Nishan Systems, Inc. Method and apparatus for transferring data between IP network devices and SCSI and fibre channel devices over an IP network
US6937574B1 (en) * 1999-03-16 2005-08-30 Nortel Networks Limited Virtual private networks and methods for their operation
US6751229B1 (en) * 1999-07-20 2004-06-15 Sony United Kingdom Limited Network terminator
US6427169B1 (en) * 1999-07-30 2002-07-30 Intel Corporation Parsing a packet header
US6724769B1 (en) * 1999-09-23 2004-04-20 Advanced Micro Devices, Inc. Apparatus and method for simultaneously accessing multiple network switch buffers for storage of data units of data frames
US6788697B1 (en) * 1999-12-06 2004-09-07 Nortel Networks Limited Buffer management scheme employing dynamic thresholds
US6822968B1 (en) * 1999-12-29 2004-11-23 Advanced Micro Devices, Inc. Method and apparatus for accounting for delays caused by logic in a network interface by integrating logic into a media access controller
US7308006B1 (en) * 2000-02-11 2007-12-11 Lucent Technologies Inc. Propagation and detection of faults in a multiplexed communication system
US6988235B2 (en) * 2000-03-02 2006-01-17 Agere Systems Inc. Checksum engine and a method of operation thereof
US6735670B1 (en) * 2000-05-12 2004-05-11 3Com Corporation Forwarding table incorporating hash table and content addressable memory
US6678746B1 (en) * 2000-08-01 2004-01-13 Hewlett-Packard Development Company, L.P. Processing network packets
US6754662B1 (en) * 2000-08-01 2004-06-22 Nortel Networks Limited Method and apparatus for fast and consistent packet classification via efficient hash-caching
US7062570B2 (en) * 2000-08-04 2006-06-13 Avaya Technology, Corp. High performance server farm with tagging and pipelining
US7218632B1 (en) * 2000-12-06 2007-05-15 Cisco Technology, Inc. Packet processing engine architecture
US6954463B1 (en) * 2000-12-11 2005-10-11 Cisco Technology, Inc. Distributed packet processing architecture for network access servers
US7131140B1 (en) * 2000-12-29 2006-10-31 Cisco Technology, Inc. Method for protecting a firewall load balancer from a denial of service attack
US7023811B2 (en) * 2001-01-17 2006-04-04 Intel Corporation Switched fabric network and method of mapping nodes using batch requests
US20040128398A1 (en) * 2001-02-15 2004-07-01 Banderacom Work queue to TCP/IP translation
US6728929B1 (en) * 2001-02-16 2004-04-27 Spirent Communications Of Calabasas, Inc. System and method to insert a TCP checksum in a protocol neutral manner
US7292586B2 (en) * 2001-03-30 2007-11-06 Nokia Inc. Micro-programmable protocol packet parser and encapsulator
US7274706B1 (en) * 2001-04-24 2007-09-25 Syrus Ziai Methods and systems for processing network data
US7295553B2 (en) * 2001-05-14 2007-11-13 Fujitsu Limited Packet buffer
US7164678B2 (en) * 2001-06-25 2007-01-16 Intel Corporation Control of processing order for received network packets
US20030026252A1 (en) * 2001-07-31 2003-02-06 Thunquest Gary L. Data packet structure for directly addressed multicast protocol
US6976205B1 (en) * 2001-09-21 2005-12-13 Syrus Ziai Method and apparatus for calculating TCP and UDP checksums while preserving CPU resources
US7124198B2 (en) * 2001-10-30 2006-10-17 Microsoft Corporation Apparatus and method for scaling TCP off load buffer requirements by segment size
US20030088689A1 (en) * 2001-11-08 2003-05-08 Alexander Cedell A. Methods and systems for efficiently delivering data to a plurality of destinations in a computer network
US7286557B2 (en) * 2001-11-16 2007-10-23 Intel Corporation Interface and related methods for rate pacing in an ethernet architecture
US20030103499A1 (en) * 2001-11-21 2003-06-05 Tom Davis Configurable packet processor
US20030154399A1 (en) * 2002-02-08 2003-08-14 Nir Zuk Multi-method gateway-based network security systems and methods
US7269661B2 (en) * 2002-02-12 2007-09-11 Bradley Richard Ree Method using receive and transmit protocol aware logic modules for confirming checksum values stored in network packet
US7283528B1 (en) * 2002-03-22 2007-10-16 Raymond Marcelino Manese Lim On the fly header checksum processing using dedicated logic
US20040030766A1 (en) * 2002-08-12 2004-02-12 Michael Witkowski Method and apparatus for switch fabric configuration
US7251704B2 (en) * 2002-08-23 2007-07-31 Intel Corporation Store and forward switch device, system and method
US7031304B1 (en) * 2002-09-11 2006-04-18 Redback Networks Inc. Method and apparatus for selective packet Mirroring
US20050076136A1 (en) * 2002-09-17 2005-04-07 Samsung Electronics Co., Ltd. Apparatus and method for streaming multimedia data
US7271706B2 (en) * 2002-10-09 2007-09-18 The University Of Mississippi Termite acoustic detection
US7260120B2 (en) * 2002-11-07 2007-08-21 Electronics And Telecommunications Research Institute Ethernet switching apparatus and method using frame multiplexing and demultiplexing
US7298761B2 (en) * 2003-05-09 2007-11-20 Institute For Information Industry Link path searching and maintaining method for a bluetooth scatternet
US20050022017A1 (en) * 2003-06-24 2005-01-27 Maufer Thomas A. Data structures and state tracking for network protocol processing
US7098685B1 (en) * 2003-07-14 2006-08-29 Lattice Semiconductor Corporation Scalable serializer-deserializer architecture and programmable interface
US20050089031A1 (en) * 2003-10-23 2005-04-28 Jon Krueger Determining a checksum from packet data
US20050108611A1 (en) * 2003-11-14 2005-05-19 Intel Corporation Early CRC delivery for partial frame
US7292591B2 (en) * 2004-03-30 2007-11-06 Extreme Networks, Inc. Packet processing system architecture and method
US20060031600A1 (en) * 2004-08-03 2006-02-09 Ellis Jackson L Method of processing a context for execution
US7134796B2 (en) * 2004-08-25 2006-11-14 Opnext, Inc. XFP adapter module

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8284802B2 (en) 2005-11-12 2012-10-09 Liquid Computing Corporation High performance memory based communications interface
US20070223483A1 (en) * 2005-11-12 2007-09-27 Liquid Computing Corporation High performance memory based communications interface
US7773630B2 (en) * 2005-11-12 2010-08-10 Liquid Computing Corportation High performance memory based communications interface
US20110087721A1 (en) * 2005-11-12 2011-04-14 Liquid Computing Corporation High performance memory based communications interface
USRE47756E1 (en) 2005-11-12 2019-12-03 Iii Holdings 1, Llc High performance memory based communications interface
US20070299970A1 (en) * 2006-06-19 2007-12-27 Liquid Computing Corporation Secure handle for intra- and inter-processor communications
US20070294426A1 (en) * 2006-06-19 2007-12-20 Liquid Computing Corporation Methods, systems and protocols for application to application communications
US8631106B2 (en) 2006-06-19 2014-01-14 Kaiyuan Huang Secure handle for intra- and inter-processor communications
US20070291778A1 (en) * 2006-06-19 2007-12-20 Liquid Computing Corporation Methods and systems for reliable data transmission using selective retransmission
US7664026B2 (en) 2006-06-19 2010-02-16 Liquid Computing Corporation Methods and systems for reliable data transmission using selective retransmission
US20070294435A1 (en) * 2006-06-19 2007-12-20 Liquid Computing Corporation Token based flow control for data communication
US7908372B2 (en) 2006-06-19 2011-03-15 Liquid Computing Corporation Token based flow control for data communication
US20080148291A1 (en) * 2006-10-30 2008-06-19 Liquid Computing Corporation Kernel functions for inter-processor communications in high performance multi-processor systems
US7873964B2 (en) 2006-10-30 2011-01-18 Liquid Computing Corporation Kernel functions for inter-processor communications in high performance multi-processor systems
US20080151883A1 (en) * 2006-12-22 2008-06-26 Geoffrey Cockerell Serial digital communication protocol
US8363541B2 (en) * 2006-12-22 2013-01-29 Pratt & Whitney Canada Corp. Serial digital communication protocol
US7715428B2 (en) 2007-01-31 2010-05-11 International Business Machines Corporation Multicore communication processing
US20080181245A1 (en) * 2007-01-31 2008-07-31 Claude Basso System and Method for Multicore Communication Processing
JP2010057033A (en) * 2008-08-29 2010-03-11 Nec Electronics Corp Communications apparatus and method therefor
US9603085B2 (en) 2010-02-16 2017-03-21 Qualcomm Incorporated Methods and apparatus providing intelligent radio selection for legacy and non-legacy applications
US20110283068A1 (en) * 2010-05-14 2011-11-17 Realtek Semiconductor Corp. Memory access apparatus and method
US8831658B2 (en) 2010-11-05 2014-09-09 Qualcomm Incorporated Controlling application access to a network
US9264868B2 (en) * 2011-01-19 2016-02-16 Qualcomm Incorporated Management of network access requests
US9178965B2 (en) 2011-03-18 2015-11-03 Qualcomm Incorporated Systems and methods for synchronization of application communications
US9571952B2 (en) 2011-04-22 2017-02-14 Qualcomm Incorporatd Offloading of data to wireless local area network
US9137737B2 (en) 2011-08-29 2015-09-15 Qualcomm Incorporated Systems and methods for monitoring of background application events
US8838086B2 (en) 2011-08-29 2014-09-16 Qualcomm Incorporated Systems and methods for management of background application events
CN102523205A (en) * 2011-12-05 2012-06-27 中兴通讯股份有限公司 Determination method and device for content checksum
US20140068134A1 (en) * 2012-08-28 2014-03-06 Huawei Technologies Co., Ltd. Data transmission apparatus, system, and method
JP2013102556A (en) * 2013-03-05 2013-05-23 Renesas Electronics Corp Communications apparatus and communication method
CN109417507A (en) * 2016-06-30 2019-03-01 华为技术有限公司 The message of section retards accesses
US10554548B2 (en) * 2016-06-30 2020-02-04 Futurewei Technologies, Inc. Partially deferred packet access
JP2019139638A (en) * 2018-02-14 2019-08-22 キヤノン株式会社 Communication device, communication method and program
US20210297157A1 (en) * 2020-03-20 2021-09-23 Arris Enterprises Llc Efficient remote phy dataplane management for a cable system

Also Published As

Publication number Publication date
US20090083611A1 (en) 2009-03-26
US8225188B2 (en) 2012-07-17

Similar Documents

Publication Publication Date Title
US8225188B2 (en) Apparatus for blind checksum and correction for network transmissions
US7580406B2 (en) Remote direct memory access segment generation by a network controller
US7849208B2 (en) System and method for TCP offload
US7185266B2 (en) Network interface device for error detection using partial CRCS of variable length message portions
EP1732285B1 (en) Apparatus and methods for a high performance hardware network protocol processing engine
US7814218B1 (en) Multi-protocol and multi-format stateful processing
US7596144B2 (en) System-on-a-chip (SoC) device with integrated support for ethernet, TCP, iSCSI, RDMA, and network application acceleration
USRE45070E1 (en) Receive processing with network protocol bypass
US7643505B1 (en) Method and system for real time compression and decompression
US8255600B2 (en) Method and system for interlocking data integrity for network adapters
US7535907B2 (en) TCP engine
US7080308B2 (en) Method and apparatus to perform error control
US20080126578A1 (en) Method, system, and program for managing data read operations
US20060034283A1 (en) Method and system for providing direct data placement support
US20060274787A1 (en) Adaptive cache design for MPT/MTT tables and TCP context
JPH0678024A (en) Network adaptor system
US8473632B2 (en) Packet receiving apparatus and processing method for the same
WO2006011963A1 (en) Processing receive protocol data units
US20200220952A1 (en) System and method for accelerating iscsi command processing
US20040006636A1 (en) Optimized digital media delivery engine
US7532644B1 (en) Method and system for associating multiple payload buffers with multidata message
US20060253768A1 (en) Techniques to speculatively determine network protocol unit integrity
WO2006046028A1 (en) Buffering packets according to their addresses

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BASSO, CLAUDE;CALVIGNAC, JEAN LOUIS;CHANG, CHIH-JEN;AND OTHERS;REEL/FRAME:016440/0586;SIGNING DATES FROM 20050606 TO 20050615

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION