1. Field of the Invention
The present invention relates to computer networks, and more particularly, to processing network data packets using hardware components.
2. Background of the Invention
Computer networking is commonplace in today's world. Network computing allows users to share information regardless of where they are located. Network computing has also increased the use of mass storage devices that can store data. Such storage devices often have to interface with networks to exchange commands and/or read and write data. Storage controllers are used to facilitate interaction between storage systems and computing systems.
Traditionally, storage controllers (e.g., disk array controllers, tape library controllers) have supported the SCSI-3 protocol and have been attached to computers by a Small Computer System Interface (SCSI) parallel bus or Fibre Channel.
Internet SCSI (iSCSI) standard as defined by the Internet Engineering Task Force (IETF) maps the standard SCSI protocol on top of the TCP/IP protocol.
Networks are generally defined as having layers of protocol. The iSCSI and TCP/IP protocol suite consist of 4 protocol layers; the application layer (of which iSCSI is one application), the transport layer (TCP), the network layer (IP) and the link layer (i.e. Ethernet). A complete description of the TCP/IP protocol suite is provided in “TCP/IP” Illustrated, Vol. 1 by W. Richard Stevens and Volume 2 by Gary R. Wright and W. Richard Stevens published by Addison Wesley Professional Computing Series.
TCP Overview
TCP is a network protocol that provides connection-oriented, reliable, byte stream service. This means that two nodes must establish a logical connection before sending data and that TCP maintain state information regarding the data transfer. Reliable means that data is guaranteed to be delivered in the same order that it was sent. A byte stream service means that TCP views data to be sent as a continuous data stream that is sent in any way it sees fit and delivers it to the remote node as a byte stream. There is no concept of a data frame boundary in a TCP data stream. Applications, such as iSCSI, must provide their own mechanisms for framing data, if it is needed.
Sequence Numbering in TCP Data Transfer
Each byte of data sent using a TCP connection is tagged with a sequence number. Each TCP segment header contains the sequence number of the first byte of data in the segment. This sequence number is incremented for each byte of data sent so that when the next segment is to be sent, the sequence number is again for the first byte of data for that segment. The sequence numbering is used to determine when data is lost during delivery and needs to be retransmitted.
A data packet receiver keeps track of the sequence numbers and knows the next sequence number when a new segment arrives. If the sequence number in the segment is not the expected one, the receiver knows that the segment has arrived out of order. This could be because the network reordered the segments or a segment was lost. Typically, TCP handles both of these cases.
TCP initially assumes that data is arriving out of order for a short number of segments or time. If the out of order segment does not arrive after three segments, the segment is considered lost and is retransmitted.
TCP Data Segments
All TCP data segments are protected by a checksum. The checksum algorithm includes 16 bit ones complement addition of the entire TCP segment. On transmission, the “ones” complement of the calculation is stored in the segment. On reception, the checksum calculation includes the transmitted complemented checksum so that the result of the receiver's checksum is all 1's.
FIG. 1A shows a sample TCP packet. The packet includes a TCP checksum with a TCP header and data. It also includes a pseudo header in the calculation. The pseudo header is built by the packet receiver specifically for the checksum calculation. The purpose of including the pseudo header is to verify that a TCP segment has arrived at the correct IP destination and was passed to the correct layer. The pseudo header is derived from information in the IP header. This includes the source and destination IP addresses and the protocol field. The pseudo header also includes the length of the TCP segment itself. The TCP header does not have a length field in it. TCP length is calculated from the total IP length minus the length of the IP header.
Delayed ACK Packets
Typically, when a TCP segment is received on a node, an acknowledgement (“ACK”) packet is returned to acknowledge reception of the packet. To help reduce the number of segments on a network, TCP may delay the delivery of an ACK packet. The ACK packet is held for a set time period to see if another ACK packet is to be sent or if the ACK can be coupled to a data segment that is being sent back. The delay in sending ACK packets occurs when data is being received in order, and skipped, if a segment is out of order.
Internet Protocol (“IP”) Overview
The IP protocol provides a datagram service whose function is to enable routing of data through various network subnets. Each of these subnets could be a different physical link such as Ethernet, ATM, etc. IP is also responsible for fragmentation of the transmit data to match a local link's MTU. IP can fragment data at the source node or at any intervening router between the source and destination node. The destination IP reassembles fragments into the original datagram sent.
Most conventional solutions for controlling communications between storage controllers and networks are via software often based on Open Systems Interconnection (OSI) model. The iSCSI protocol with the TCP/IP protocol stack running in software on a computer requires a large amount of computing power, especially at current 1 giga bits per second (1 Gbps) and future 10 Gbps network rates.
Mixed software and hardware solutions have been also been proposed. One such solution is provided in U.S. Pat. No. 6,226,680 (Boucher et al.). In Boucher et. al., a network interface card uses a “fast path microprocessor or the host stack”. This decision is based on a summary of packet headers. A host software stack processes some packets and others are processed by a “fast path microprocessor”.
The system and process illustrated in Boucher et. al. still requires processing by a software stack and hence is not suitable to the present high bandwidth requirements.
Therefore, what is needed is a process and system that can process network packets in storage controllers efficiently and quickly to meet the present and future high bandwidth requirements.
USPTO Backgrounds
USPTO Backgrounds