1. Introduction

Typically in fast Ethernet systems this computation is done by the driver software running on the CPU. However, with gigabit and 10Gbps interconnect speeds of moving data, computation of checksum using software drivers becomes a huge burden on the CPU - this is one of the most demanding tasks on the host, leaving less cycles for application processing. This results in the overall under-utilization of the network and hence degraded performance.

In an attempt to improve performance and to assist drivers in ensuring data integrity, checksum computation is increasingly being done in hardware. The checksum offload feature can be implemented as a combination of hardware and software functions - the hardware assists the driver in completing the checksum computation.

This functionality can be enabled in Asics and disabled in the existing drivers (TCP/IP protocol stack) easily.

Synopsys' DWC Ether MAC 10/100/1000 - universal IP in its current GA release, 3.20a implements the checksum-hardware-assist function by providing the IPv4 header checksum checking and payload checksum computation.

Now additional enhancements like TCP/UDP checksum handling have been implemented to further help the SoCs in computing checksum in hardware.

This article is intended to give a brief overview of the checksum feature for IPv4, TCP/UDP protocols and introduce its implementation in the GMAC Universal IP.

2. Technical Overview of the Checksum Functionality:

2.1 Checksum for IP protocol:

2.1.1 IPv4 datagram frame format: The following diagram shows the IPv4 frame format. The detailed descriptions for the header fields can be found in RFC 791.

IPv4 header format

The header checksum field is needed to ensure the integrity of the IP header. The sender of the IPv4 packet is required to compute the checksum value for the IP header fields and insert in the "header checksum' field. It is computed using the following algorithm.

2.1.2 IPv4 header Checksum computation algorithm:

The checksum is a 2-byte value. It is computed as the 16 bit one's complement of the one's Complement sum of all 16 bit words in the header. The value of the checksum field is regarded as zero for the purpose of computing the checksum. If the computed checksum value is all zeroes, its one's complement (all 1's) is inserted. If the received packet has all-zeros in its checksum field, it indicates that the checksum was not computed by the transmitter.

This checksum only determines the integrity of the IPv4 header.

IPv6 does not have the header checksum field.

2.2 Checksum for TCP protocol:

2.2.1 TCP Frame format: A TCP packet forms the payload for the IP frame. The TCP frame format is as shown below. The detailed description of each field is given in RFC 793.

TCP Header Format

Source Port			Destination Port
Sequence Number
Acknowledgement Number
Data Offset	Reserved	Flags	Window
Checksum			Urgent Pointer
Options + Padding

The TCP checksum computation algorithm is identical to the IPv4 header checksum algorithm. However in this case, the checksum is computed for the TCP header, payload data in that segment and the pseudo-header fields. The pseudo header consists of IPv4's source address, destination address, length (TCP data) and protocol fields. If the total number of bytes in the segment is odd, the last byte is padded for checksum computation.

2.3: Checksum for UDP protocol:

2.3.1 UDP frame format: The UDP packet, similar to TCP segment is contained in the IPv4 payload. The packet format is given in RFC 768 and is shown below.

UDP Header Format

Source Port	Destination Port
Length	Checksum

UDP Checksum computation procedure is identical to TCP. For UDP encapsulated in IPv4 protocol, the UDP checksum can be disabled by transmitting 0x0000 in the UDP checksum field.

3. Overview of Implementation in the GMAC-Universal Core:

GMAC Universal IP, on the receive side performs checksum checking for the IP4 header as well as the encapsulated TCP/UDP data segments for the in-coming frames. Data-corruption is determined and the error is reported to the host. In addition, it also computes checksum for the IPv4 "payload" and appends it to each received frame. On the transmit side, it computes the checksum value for each out-going frame and based on the protocol inserts in the header appropriately.

This is an optional feature and the GMAC-Universal core can be easily configured to include this module through coreConsultant. The checksum functionality can be enabled or disabled during run-time by programming a register bit appropriately. This initiates the checksum checking and IPv4 payload-checksum appending on the receive side. On the transmit side, the user can select checksum computation function for any one or more of the protocols i.e., IPv4 or TCP/UDP via top level ports or setting register bits. The application has the flexibility to control this during run-time on a per-frame basis.

3.1 Checksum support in receive data path:

3.1.1 IP Checksum:

The receiver parses the incoming data and first ascertains the Ethernet MAC frame's data integrity by checking the CRC/FCS in the received frame. For the good Ethernet frames that pass CRC, the "length/type" field in the MAC frame is checked to see if it has the value "0x0800" , which indicates that the encapsulated payload is an IPv4 datagram or "0x86DD" to see if it is IPv6 datagram. Next the version field in the IP header is checked to verify that it matches with the value in the "type" field. I.e., version field for IPv4 needs to be set to "0x4" and in case of IPv6, it should be set to 0x6.

After determining that the frame is a valid IPv4 frame, the checksum is computed over the header fields including the checksum field according to the algorithm outlined above. A value of 0xffff indicates that the received checksum is correct. Any mismatch will be indicated as an error and the packet is optionally dropped inside the core. In addition, inconsistency between the "type" field in the encapsulating Ethernet frame and the version field is regarded as an error and reported.

An IPv6 header does not contain a header-checksum field.

To further assist software, the GMAC -Universal IP computes the checksum over the IP datagram's payload (which can be TCP/UDP datagram). This is done using the same checksum computation algorithm as outlined above. The non-aligned last byte is padded if necessary and the 2-byte value thus computed is appended to the MAC frame after the FCS field and presented to the application.

3.1.2 TCP/UDP Checksum:

The received frame could be a TCP or a UDP segment, encapsulated in IPv4 or IPv6, as indicated by the "type" field in the MAC frame. Further, TCP vs. UDP is indicated by the "protocol" field in the IP frame. The checksum-calculator module will decode this and based on the protocol, the frame is parsed suitably to compute the checksum. As in case of IPv4 header, a checksum value of "0xffff" indicates that the frame is not corrupted. Here, the checksum is calculated for the TCP/UDP header as well as the data payload and the pseudo header.

The IPv4 header checksum error is reported to the host through a register bit. Any TCP/UDP segment checksum error is reported through a common status bit as well. The errors also include the mismatch between the values as indicated in the length field in the IP header vs. the actual number of bytes received. In case of the IPv6 datagram, any extension field other than hop-by-hop or routing header or destination header is considered as non-supported field. In this case the payload checksum appending is automatically disabled.

3.2 Checksum support in transmit data path

IPv4:

In the transmit path, the core can be instructed to compute and insert the checksum value in an outbound frame, on a per-frame basis. Further the checksum insertion can be enabled for IP only or TCP/UDP and also to include pseudo-header. This can be programmed as a part of the frame's transmit descriptor when the core is in GMAC-AHB configuration i.e., AMBA2.0 host interface. The same controllability is provided as primary pins in the GMAC-MTL (exposed FIFO interface) configuration.

When instructed to insert the IPv4 checksum, it is computed using the algorithm used above and is inserted in the IPv4 header. The application is responsible for allocating space for the checksum field in the MAC frame.

TCP/UDP:

The process is identical to the IPv4 checksum insertion. The protocol is identified by decoding the 'protocol" fielding the IP datagram. On its basis, the computed checksum is inserted into the appropriate field in the header. The checksum is computed over the entire TCP/UDP segment.

The transmit engine also determines the frame length received from the application and compares it with the value in the length field in the IPv4 header. Any mismatch is indicated as an error to the application. Similarly, the IP datagram's payload length is also computed and compared with the value in the TCP/UDP header and mismatch is reported. The frames are transmitted to the PHY.

Since the TCP/UDP checksum is calculated for the entire out-going data segment, it requires the store-and-forward mode of operation. The FIFO size on the transmit side should take this into account.

4. Availability

5. Summary