Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1997-09-25
2001-09-11
Nguyen, Chau (Department: 2633)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S473000
Reexamination Certificate
active
06289023
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to checksums that verify the integrity of data packets as the data packets flow though network protocol stacks. More specifically, the present invention uses hardware to generate a checksum that flows through the stack alongside the data packet, thereby allowing any particular layer of the protocol stack to access the checksum without incurring the time penalty associated with calculating the checksum after the packet arrives at the layer.
DESCRIPTION OF THE RELATED ART
In the art of computer networking, protocol stacks are commonly used to transmit data between network nodes that are coupled by network media. Network nodes include devices such as computer workstations, servers, network printers, network scanners, and the like. To harmonize the development and implementation of protocol stacks, the International Standards Organization (ISO) promulgated an Open System Interconnection (OSI) Reference Model that prescribes seven layers of network protocols.
FIG. 1
is a block diagram
10
of the OSI reference model. The model includes a hardware layer
12
, a data link layer
14
, a network layer
16
, a transport layer
18
, a session layer
20
, a presentation layer
22
, and an application layer
24
. Each layer is responsible for performing a particular task. Hardware layer
12
is responsible for handling both the mechanical and electrical details of the physical transmission of a bit stream. Data link layer
14
is responsible for handling the packets, including any error detection and recovery that occurred in the physical layer. Network layer
16
is responsible for providing connections and routing packets in the communication network, including handling the address of outgoing packets, decoding the address of incoming packets, and maintaining routing information for proper response to changing loads. Transport layer
18
is responsible for low-level access to the network and the transfer of messages between the users, including partitioning messages into packets, maintaining packet order, flow control, and physical address generation. Session layer
20
is responsible for implementing the process-to-process protocols. Presentation layer
22
is responsible for resolving the differences in formats among the various sites in the network, including character conversions, and half duplex/full duplex (echoing). Finally, application layer
24
is responsible for interacting directly with the users. Layer
24
may include applications such as electronic mail, distributed data bases, web browsers, and the like.
Before the ISO promulgated the OSI reference model, the Defense Advanced Research Projects Agency (DARPA) promulgated the ARPNET reference model. The ARPNET reference model includes four layers, a network hardware layer, a network interface layer, a host-to-host layer, and a process/application layer.
As their names imply, the OSI reference model and the ARPNET reference model provide guidelines that designers of protocols may or may not chose to follow. However, most networking protocols define layers that at least loosely correspond to a reference model.
In the field of computing, there are many popular protocols used to transmit data between network nodes. For example, TCP/IP, AppleTalk®, NetBEUI, and IPX are all popular protocols that are used to transmit data between servers, workstations, printers, and other devices that are coupled to computer networks.
It is common for many of the protocols to operate concurrently within a single network node, even if the network node has a single network interface. For example, a typical computer workstation may use TCP/IP to communicate over the Internet, and IPX to communicate with a network server. Likewise, a printer may be configured to receive print jobs using either the AppleTalk® protocol or the NetBEUI protocol. Typically, a software routine existing at data link layer
14
or network layer
16
routes data packets between the network adapter and the proper protocol stack.
Various protocols also define methods to verify the integrity of data transmitted by the protocol. For example, consider a TCP/IP packet as it arrives at an Ethernet network adaptor. The entire Ethernet packet is protected by a cyclic redundancy check (CRC) code that is calculated and stuffed into the Ethernet packet by the sending network adapter, and is used by the receiving network adapter to verify the integrity of the Ethernet packet. If the integrity of the packet cannot be verified, the packet is discarded.
Encapsulated within the Ethernet packet is the IP portion of the TCP/IP protocol. The IP portion has a 16 bit checksum code that protects the IP header. If the integrity of the IP header cannot be verified, the packet is discarded. The TCP portion of the TCP/IP protocol is encapsulated within the IP portion, and has a 16 bit checksum code that protects the TCP header and the contents of the TCP portion of the packet. If the integrity of the TCP header or the contents of the TCP portion cannot be verified, the packet is discarded and the sender will retransmit the packet after not receiving an acknowledge packet from the intended recipient.
The integrity of the Ethernet packet is verified by the networking hardware at hardware layer
12
, and therefore is performed quite quickly. However, the higher layers of the protocol stack are typically implemented by software. Calculating a checksum using a software routine is considerably slower. In the prior art, a checksum required by a higher layer of the protocol stack could not be generated at the hardware layer because the hardware layer did not have knowledge of the higher layers of the stack.
One prior art solution that speeds up the generation of a checksum at a higher layer of a protocol stack is to use a hardware checksumming facility that is controlled by the higher layer of the protocol stack. For example, when a TCP module seeks to verify the integrity of a TCP header and its respective data, the TCP module writes to a register of the hardware checksumming facility to begin the checksumming process, and polls the facility to determine when the checksum is complete. While such a solution is faster than a checksum generated solely by a software routine, there is still a significant delay while the checksum is generated.
Another method of calculating checksums using hardware was disclosed by Snyder et al. in U.S. Pat. No. 5,522,039, which is entitled “Calculation of Network Data Check Sums by Dedicated Hardware With Software Corrections.” This patent discloses generating a “gross checksum” for the entire packet as the packet is transferred via a direct memory access (DMA) operation between adapter memory and system memory. Higher layers of the protocol stack then calculate the checksum required by calculating a checksum for the portions of the packet that are not needed, and then subtracting this checksum from the gross checksum to form a “net checksum”, which is the checksum required by that layer of the protocol stack. Since the checksum for the portion is calculated over a relatively small number of bytes, the scheme disclosed by Snyder et al. incurs a smaller time penalty than other prior art methods.
SUMMARY OF THE INVENTION
The present invention provides a protocol stack layer with the ability to verify a data packet using a fly-by checksum that was generated at a lower layer of the protocol stack. In one embodiment, a network adapter includes one or more protocol stacks and a LAN controller that includes a fly-by checksum generation unit. In this embodiment, a checksum algorithm is registered with the fly-by checksum generation unit for each protocol layer that is to receive a fly-by checksum. The fly-by checksum generation is provided with the type of checksum algorithm to be executed, as well as beginning and ending byte positions that define the portion of the incoming packet to be checksummed. As an incoming packet is transferred from network media to network adapter memory via a DMA operation, the fly-by checksum generation un
Dowling Brian M.
Warling Christian J.
Wendt James G.
Boakye Alexander
Hewlett--Packard Company
Nguyen Chau
Plettner David A.
LandOfFree
Hardware checksum assist for network protocol stacks does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Hardware checksum assist for network protocol stacks, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Hardware checksum assist for network protocol stacks will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2520616