JP4875126B2 - Gigabit Ethernet adapter supporting ISCSI and IPSEC protocols - Google Patents

Description

  The present invention relates to a method and apparatus for processing data with a communication protocol used for telecommunications, in particular data transmission and reception.

Computer networks require the definition of various communication protocols for sending and receiving data. Typically, a computer network comprises a system of devices such as computers, printers, and other computer peripherals that are communicatively connected together. Data is transferred between each of these devices by data packets communicated over the network using a communication protocol standard. A number of different protocol standards are currently in use. Examples of popular protocols are Internet Protocol (IP), Internetwork Packet Exchange (IPX), Sequenced Packet Exchange (SPX), Transmission Control Protocol (TCP), and Point-to-Point Protocol (PPP). Each network device includes a combination of hardware and software that translates protocols and processes data.

  An example is a computer attached to a local area network (LAN) system, where the network device uses hardware to handle link layer protocols and software to manage network, transfer, communication protocols and information data processing. A network device typically configures one link layer protocol in hardware and limits the attached computer to only that particular LAN protocol. Higher-order protocols, such as network, transfer and communication protocols, are configured as software programs with data handlers to process the data once they are sent to the system memory through the network device hardware. The advantage of this configuration is that it allows a general purpose device such as a computer to be used in a number of different network setups to support the optional network applications required. However, as a result of this configuration, the system has a high processor overhead and a large amount of system to coordinate different software protocols and data handlers that communicate to the computer operating system (OS) and the computer, and network hardware. Requires computer and complicated configuration setup on the computer user side.

  This high overhead required in processing time is shown in Schrier, US Pat. No. 5,485,460, filed Jan. 16, 1996, which includes multiple software protocol stacks running the same protocol on the device. Shows how it works. This type of configuration is used in disk operating system (DOS) based machine operation Microsoft Windows. During normal operation, once the hardware confirms the transfer or link layer protocol, the resulting data packet is transferred to a software layer that determines the packet frame format and resolves any particular frame header. The packet is then sent to a different protocol stack where it is evaluated for a particular protocol. However, a packet can be forwarded to several protocol stacks before it is accepted or rejected. The time delay generated by the software protocol stack prevents audio and video transmissions from being processed in real time, and the data must be buffered before being played. Obviously, the amount of processing overhead required to process the protocol is very high, extremely cumbersome, and intended for applications with powerful central processing units (CPUs) and large amounts of memory.

  Computer products that do not fit the traditional network device model are on the market. Some examples of these products include pagers, cellular phones, game machines, smart phones, and televisions. Most of these products have a small footprint, 8-bit controller, limited memory, or require a very limited form factor. Consumer products like these are simple, inexpensive and require low power consumption. The protocol configuration described above requires a great deal of hardware and processor power to meet these requirements. This complexity of configuration makes it difficult to integrate into consumer products in a cost effective manner. These products can access network services such as the Internet if network access can be simplified to be easily manufactured with low cost, low power, small form factor devices.

  Communication networks use protocols for data transmission and reception. A communications network includes a collection of network devices, also called nodes, such as computers, printers, storage devices, and other computer peripherals that are typically connected to communicate with each other. Data is transferred between each of these network devices using data packets transmitted over the communication network using a protocol. A number of different protocols are currently in use. Examples of popular protocols are Internet Protocol (IP), Internetwork Packet Exchange (IPX) Protocol, Sequenced Packet Exchange (SPX) Protocol, Transmission Control Protocol (TCP), Point-to-Point Protocol (PPP) and in development Other similar new protocols are included. The network device includes a combination of hardware and software that processes protocols and data packets.

  In 1978, the International Organization for Standardization (ISO), the standard-setting body, created a network reference model known as the Open Systems Interconnection (OSI) model. This OSI model includes seven conceptual layers. That is, 1) a physical (PHY) layer that defines physical components that connect a network device to the network, and 2) data that controls the movement of data in a discrete form known as a frame containing data packets. A link layer, 3) a network layer that constructs data packets according to a specific protocol, 4) a transfer layer that ensures reliable transfer of data packets, and 5) a session that allows two-way communication between network devices. 6) a presentation layer that controls how data is represented and confirms that the data is in the correct form, and 7) an application layer that performs file sharing, message processing, printing, and the like. Sometimes the session and presentation layers are omitted from this model. For an explanation of how modern communications networks and the Internet relate to the seven-layer model of ISO, see for example the text “Internetworking with TCP / IP”, Douglas E. Corner (Volume 1, 4th Edition, ISBN 020 1633469) and the text “TCP / IP Illustrated”, W. Richard Stevens (Vol. 1, ISBN 0130183806), Chapter 1.

  An example of a network device is a computer attached to a local area network (LAN), where the network device uses the host computer's hardware to manage the physical and data link layers, and the network, transfer, session, presentation, Use software running on the host computer to manage the application layer. The network, transport, session, and presentation layers are implemented using protocol processing software, also called a protocol stack. The application layer is executed using application software that processes the data once it has been transferred through the network device hardware and protocol processing software. The advantage of this software-based protocol processing structure is that it allows a general purpose computer to be used in many different types of communication networks and supports any required application. However, as a result of this software-based protocol processing structure, the overhead of the protocol processing software that runs on the central processing unit (CPU) of the host computer to process the network, transfer, session, and presentation layers is very high. Software-based protocol processing structures also require a large amount of memory at the host computer because the data must be copied and moved when the software processes the data. The high overhead required by protocol processing software is described in US Pat. No. 5,485,460 by Schrier filed Jan. 16, 1996, which teaches how to operate a number of software protocol stacks. This type of software-based protocol processing structure is used, for example, in Microsoft Windows running computers.

  During normal operation of the network device, the network software hardware then extracts data packets that are sent to the host computer's protocol processing software. The protocol processing software runs on a host computer, which is not optimized for the tasks performed by the protocol processing software. The combination of protocol processing software and a general purpose host computer is not optimized for protocol processing, thereby limiting performance. Limiting performance in protocol processing, such as time delays generated by the execution of protocol processing software, is detrimental, for example, preventing audio and video transmissions from being processed in real time, or the full speed and capacity of a communications network Interferes with the use. It is clear that the amount of host computer CPU overhead required to process the protocol is very high and extremely cumbersome and requires the host computer to use a CPU and a large amount of memory.

  New consumer and industrial products that do not fit the traditional network equipment model have entered the market and at the same time the network speed continues to increase. Examples of these consumer products are Internet enabled cell phones, Internet enabled TVs, and Internet equipment. Examples of industrial products are network interface cards (NICs), internet routers, internet switches, internet storage servers. Software-based protocol processing configurations are not efficient to meet the demands of these new consumer and industrial products. Software-based protocol processing configurations are complex and difficult to include in consumer products at an efficient price. Software-based protocol processing configurations require processing power and are difficult to integrate into high speed industrial products. If the processing of the protocol can be simplified and optimized so that it can be easily manufactured in an inexpensive, low power, high performance integrated small form factor device, these consumer and industrial products will Data can be read and written on any communication network such as the Internet.

  Contrary to software-based, hardware-based protocol processing configuration Internet tuners are J. Minami, R. Koyama, M. Johnson, M. Shinohara, T. Poff, D. Burkes Multiple network protocol encoder / decoder and data processor, U.S. Pat. No. 6,034,963 (March 7, 2000) (hereinafter referred to as the '963 specification). This Internet tuner provides basic techniques for processing protocols.

  It would be advantageous to provide a Gigabit Ethernet adapter that provides a hardware solution for high communication network speeds. It is also effective to provide a Gigabit Ethernet (registered trademark) adapter that is compatible with many communication protocols.

  The present invention is implemented with a Gigabit Ethernet adapter. The system according to the present invention provides a compact hardware solution that handles high network communication speeds. Furthermore, the present invention is compatible with a number of communication protocols due to its modular structure and design. The preferred embodiment of the present invention provides an integrated network adapter that decodes and encodes network protocols and processes data. The network adapter is a wired data path for processing streaming data, a wired data path for receiving and transmitting packets, and encoding and decoding packets, and a plurality of parallel, A wired protocol state machine, wherein each protocol state machine is optimized for a particular network protocol, the protocol state machine performs processing in parallel, and further allocates shared resources based on traffic. Means for scheduling.

1 is a schematic block diagram of a NIC card structure according to the present invention. 1 is a schematic block diagram of an interface of a device attached to a network according to the present invention. FIG. 1 is a level block diagram of a system according to the present invention. 1 is a high level block diagram of a Gigabit Ethernet adapter in accordance with the present invention. FIG. FIG. 2 is a block diagram showing an outline of I / O used in a MAC interface module according to the present invention. 1 is a schematic block diagram of an Ethernet interface according to the present invention. FIG. 1 is a schematic block diagram of an address filter and packet type parser / module according to the present invention. FIG. FIG. 4 is a timing diagram illustrating the operation of an address filter and packet type parser / module according to the present invention. 2 is a schematic block diagram of a data aligner module according to the present invention. FIG. 1 is a schematic block diagram of an ARP module according to the present invention. 1 is a schematic block diagram of an ARP cache according to the present invention. FIG. 4 shows a transmission queue entry format according to the present invention. The figure which shows the search table entry format according to this invention. FIG. 4 shows an ARP cache entry format according to the present invention. FIG. 5 is a flow diagram illustrating an ARP search process according to the present invention. 1 is a schematic block diagram of an IP module according to the present invention. FIG. 3 is a block diagram of an IP generator according to the present invention. FIG. 3 is a block diagram illustrating a data flow by an injector according to the present invention. 1 is a top level block diagram of a TCP module according to the present invention. FIG. FIG. 4 is a diagram showing a TCP reception data flow according to the present invention. FIG. 5 is a flow diagram of control block search resolution of a VSOCK / Rcv state handler according to the present invention. FIG. 3 is a basic data flow diagram according to the present invention. FIG. 4 is a flow diagram of socket reception data according to the present invention. FIG. 6 shows a socket transmission flow according to the present invention. FIG. 4 is a data flow diagram according to the present invention. FIG. 3 is a block diagram of a module according to the present invention. The figure which shows the algorithm according to this invention. FIG. 28 is a block diagram of the entire algorithm shown in FIG. 27. FIG. 4 is a diagram showing logic means according to the present invention. FIG. 4 is an optional format diagram according to the present invention. FIG. 6 is a format diagram of another option according to the present invention. FIG. 6 is a format diagram of another option according to the present invention. FIG. 4 is a format diagram of yet another option according to the present invention. FIG. 4 is a format diagram of yet another option according to the present invention. 1 is a schematic block diagram of an IP router according to the present invention. FIG. 4 is a format diagram of an IP route entry according to the present invention. FIG. 6 is an illustration of signaling used to request and receive a route according to the present invention. FIG. 3 is a schematic block diagram of an exception handler according to the present invention. FIG. 4 shows an M1 memory map according to the present invention. FIG. 4 shows a sample memory map according to the present invention. FIG. 3 is a block diagram of a data flow according to the present invention. FIG. 4 is a block diagram of an mtxarb subunit according to the present invention. FIG. 3 is a block diagram of a data flow according to the present invention. FIG. 3 is a block diagram of an mcbarb subunit according to the present invention. FIG. 4 shows a default memory map of a network stack according to the present invention. The figure which shows the default setting according to this invention. FIG. 5 shows a matched IB and SB queue that together form a channel in accordance with the present invention. FIG. 5 is a flow diagram of instruction block queue processing in accordance with the present invention. FIG. 6 is a block diagram showing the data flow of an ar state block passing between a network stack, an on-chip processor, and a host according to the present invention. FIG. 3 is a block diagram of an iSCSI transmit data path according to the present invention. FIG. 4 is a diagram showing an iSCSI transmission flowchart according to the present invention. FIG. 4 is an illustration of the use of a 4-byte buffer according to the present invention. FIG. 3 is a block diagram of an iSCSI receive data path according to the present invention. Explanatory drawing which shows the transfer divided | segmented into two requests according to this invention. FIG. 6 illustrates a DMA transfer to a host that is divided into separate requests according to the present invention. FIG. 6 shows an SA block flow according to the present invention. The figure which shows the format of the TX AH transfer SA block by this invention. The figure which shows the format of TX ESP-1 transfer SA block by this invention. The figure which shows the format of TX ESP-2 transfer SA block by this invention. The figure which shows the format of the TX AH tunnel SA block by this invention. The figure which shows the format of the TX AH tunnel SA block by this invention. The figure which shows the format of TX ESP-2 tunnel SA block by this invention. The figure which shows the format of the RX AH SA block by this invention. The figure which shows the format of the RX ESP-1 SA block by this invention. The figure which shows the format of the RX ESP-2 SA block by this invention. 2 is a block diagram illustrating the overall flow for IPSEC logic in accordance with the present invention. FIG. FIG. 3 is a schematic block diagram of a data flow according to the present invention. FIG. 4 is a block diagram of a data path flow for a received IPSEC packet according to the present invention. FIG. 4 is a flow diagram illustrating an IPSEC anti-relay algorithm according to the present invention.

  The present invention is implemented with a Gigabit Ethernet adapter. The system according to the present invention provides a compact hardware solution for handling high network communication speeds. Furthermore, the present invention is compatible with a number of communication protocols through a modular structure and design.

[Preface]
[General description]
The present invention includes an architecture (hereinafter referred to as IT10G) used in a high speed hardware network stack. The description here defines the data path and flow, registers, application theory and timing. In combination with other system blocks, IT10G provides a core for line speed TCP / IP processing.

[Definition]
The following terms used herein have corresponding meanings:
10 Gbps 10 Gigabit (10,000,000,000 bits per second)
ACK Acknowledgment AH Authentication header AHS Additional header segment ARP Address resolution protocol BHS Basic header segment CB Control block CPU Central processing unit CRC Cyclic redundancy check DAV Available data DDR Double data rate DIX Digital Intel Xerox DMA Direct memory access DOS Service denial DRAM Dynamic RAM
EEPROM PROM that is electrically erasable
Fiber Channel FIFO over ESP Encapsulated Security Payload FCIP IP First In First Out FIM Fixed Interval Marker FIN Finish Gb Gigabit (10,000,000,000 bits per second)
HDMA Host DMA
HO Half-open HR Host retransmission HSU Header storage IB Command block ICMP Internet control message protocol ID Identification IGMP Internet group management protocol IP Internet protocol IPsec IP security IPX Internet packet exchange IQ Command block queue iSCSI Internet Internet small computer system interface ISN Initial sequence Number LAN Local network LDMA Local DMA
LIP Local IP address LL Linked list LP Local port LSB Lower digit byte LUT Search table MAC Media access controller MCB CB memory MDL Memory descriptor list MIB Management information base MII Media independent interface MPLS Multiprotocol label switching MRX Receive memory MSB Upper Digit Bit MSS Maximum Segment Size MTU Maximum Transmission Unit MTX TX (Transmission) Memory NAT Network Address Translation NIC Network Interface Card NS Network Stack OR Logical Function PDU Protocol Data Unit PIP Peer IP Address PP Peer Port PROM Programmable ROM
PSH Push PV Valid pointer QoS Quality of service RAM Random access memory RARP Reverse address resolution protocol Rcv Receive RDMA Remote DMA
ROM read only memory RST reset RT round trip RTO retransmission timeout RTT round trip time RX receiving SA security association SB state block SEQ sequence SM state message SNMP simple network management protocol SPI security parameter index Stagen state generator SYN synchronous TCP transfer control protocol TOE Transfer offload engine TOS Service type TTL Time to live TW Wait time TX Transmission UDP User datagram protocol URG Emergency VLAN Virtual LAN
VSOCK Virtual socket WS Window scaling XMTCTL Transmission control XOR Exclusive OR

[Application Overview]
[Overview]
As bandwidth continues to increase, the ability to handle TCP / IP communications will exceed system processor overhead. When a large number of sources reach an Ethernet rate of gigabits per second (Gbps), their TCP / IP protocol processing consumes nearly 100% of the host computer's CPU bandwidth, and the rate increases further to 10 Gbps. , The entire TCP / IP protocol process must be offloaded to a dedicated subsystem. The IT 10G described here configures TCP and IP as a series of state machines with associated protocols including, for example, ARP, RARP, and IP host routing. The IT10G core constitutes an accelerator or engine, also known as a transfer offload engine (TOE). Although hooks are provided so that connected on-chip processors can be processed to be used to extend the characteristics of the network stack, the IT10G core does not use a processor or software.

[Sample application]
An example use of the IT10G core is an intelligent network interface card (NIC). In a typical application, the NIC is plugged into a computer server and natively processes TCP / UDP / IP packets.

  FIG. 1 is a block diagram schematically showing the NIC of the present invention. In FIG. 1, the IT10G core 10 is coupled to a processor 11, system peripherals 12, and a system bus interface 13 to a single chip NIC controller. A single chip NIC controller is integrated with the Ethernet PHY 14 and combined with an optional external memory of the network stack to form a configuration EEPROM 15, a low chip count NIC. The processor memory 16 (both ROM and RAM) may be internal or external to the integrated chip.

  Another use of the IT10G core 10 is to serve as an interface to devices attached to a network such as storage devices, printers, cameras, and the like. In such a case, a custom application socket (or interface) 17 can be provided in the IT 10G to handle the layer 6 and 7 protocol and to facilitate the movement of data special to that application. Examples include custom data paths for protocols such as streaming media, bulk data movement, iSCSI and FCIP.

  FIG. 2 is a schematic block diagram of an interface to a device attached to a network according to the present invention. IT10G is designed to support 10 Gbps line rate processing, and the same architecture and logic units can also be used at lower speeds. In these cases, only Ethernet (registered trademark) MAC21 and PHY14 are different. Advantages of using this low line speed architecture include, for example, low power consumption.

[Challenge]
The challenge for high bandwidth is in the processing of TCP / IP packets at wireline speeds. This is shown in the table below.

Note: This assumes an average packet size of 500 bytes.
2 This assumes 500 instruction overhead per packet and 1 instruction per byte.

  The numbers in the above table are very conservative and do not take into account, for example, the dual nature of networking. If dual operation is taken into account, the processing power requirement is easily doubled. In any case, starting at the gigabit level, it is clear that the processing overhead of TCP / IP is a major drain on host computer processing power and another solution is needed.

Bandwidth limit
IT10G solves the host computer processing power limitation by implementing various architectures. The implementation includes the following characteristics:
On-the-fly (streaming) processing of input and output data,
-Ultra wide data path (64 bits in the current structure),
・ Parallel operation of protocol state machines,
Intelligent scheduling of shared resources,
• Minimized memory copy.

[System Overview]
[Overview]
This section describes the upper level of the preferred embodiment. This provides a block level description of the system and the theory of operation for different data paths and transfer types.

  Embodiments of the present invention include an IT10G network stack that combines processor cores and system components to provide a complete networked subsystem in different applications. A block level diagram of the system is shown in FIG.

[Clock request]
The presently preferred embodiment of the present invention is a chip designed to operate in different clock domains. The following table lists all clock domains for both 1 Gbps and 10 Gbps operation.

[Protocol processor]
[Overview]
This section gives an overview of the internal protocol processor.

[Process Core]
The chip described here uses an internal (or on-chip) processor for programmability and flexibility. This processor is also complete with all the peripherals necessary to complete the operating system. Under normal operating conditions, the on-chip processor controls network slack.

[Memory Architecture]
On-chip processors have the ability to address memory up to 4 Gbytes. All the peripheral devices, the RAM, the ROM, and the network slack are located in this address space.

[Network slack architecture]
[Overview]
This section outlines the IT10G architecture. Subsequent sections here will go into details about the individual modules. IT10G takes network slack hardware protocol processing capabilities and adds enhancements to enable scaling up to 10 Gbps rates. The main addition to the previous version is to extend the data path, state machine parallelism, and intelligent scheduling of shared resources. In addition, other protocols that were not previously supported add support for protocols such as RARP, ICMP, IGMP. FIG. 4 is a high level block diagram of IT10G.

[Theory of operation]
Before transferring any data using IT10G, the socket connection must be initialized. This can be done by using a command block or by directly programming up the TCP socket register. Characteristics that must be programmed for each socket include the destination IP address, the destination port number, and the type of connection (eg, TCP or UDP, server or client). Optional parameters include settings such as QoS level, source port, TTL, and TOS settings. Once these parameters are entered, the socket can be activated. In the case of a UDP socket, data can begin to be sent or received immediately. For TCP clients, a socket connection must be set up first, and for TCP servers, a SYN packet must be received from the client and then a socket connection must be set up. All such operations can be performed entirely by IT10G hardware.

[Send packet]
When a TCP packet needs to be sent, the application running on the host computer first writes data to the socket (fixed socket or virtual socket—virtual sockets are supported by the IT10G architecture). If the current transmit buffer is empty, a partially working checksum is maintained when data is being written to memory. The partial checksum is used as a start seed for the checksum calculation, eliminating the need for a TCP layer in the IT10G network stack to read through the data again before sending the data. Data can be written to the socket buffer in 32-bit or 64-bit chunks. Up to 4 valid_byte signals are used to indicate valid bytes. When writing to the socket buffer, the data must be packed with only the last word with possible invalid bytes. This stage also applies to UDP packets where there is an option not to calculate the data checksum.

  Once all the data has been written, a SEND command can be generated by an application running on the host computer. At this point, the TCP / UDP engine calculates the packet length, checksums, and creates a TCP / IP header. This TCP / IP header is previously pending in the socket data section. The packet's buffer pointer, along with the socket QoS level, is then placed in the transmission queue.

  The transmission scheduler observes all sockets with pending packets and selects the packet with the highest QoS level. This transmission scheduler observes all types of packets that require transmission. These packets can include, for example, TCP, UDP, ICMP, ARP, RARP, and raw packets. A minimum bandwidth algorithm is used to ensure that the socket is not fully coupled. When a socket packet is selected for transmission, the socket buffer pointer is transferred to the MAC TX interface. The MAC TX interface operates to read data from the socket buffer and send the data to the MAC. The buffer is used to store packets that are output when retransmission is required due to Ethernet collisions or other reasons. Once packet data is transmitted from the original socket buffer, the data buffer is released. When a valid transmission state is received from the MAC, the data buffer is flushed and the next packet can then be transmitted. If a transmission state that is not valid is received from the MAC, the last packet stored in the data buffer is retransmitted.

[Receive packet]
When a packet is received from the MAC, the Ethernet header is analyzed to determine whether the packet is destined for this network stack. The MAC address filter can be programmed to receive unicast addresses, unicast addresses that fall within a programmed mask, broadcast addresses, or multicast addresses. In addition, the encapsulation protocol is also determined. If the 16-bit TYPE field of the Ethernet header indicates an ARP (0x0806) or RARP (0x0835) packet, the ARP / RARP module is further enabled to process the packet. If the TYPE field is decoded to IPv4 (0x0800), the IP module is enabled to further process the packet. A complete list of example supported TYPE fields is shown in the table below. If the TYPE field is decoded to any other value, the packet is optionally routed to a buffer and the host computer is notified that an unknown Ethernet packet has been received. In this last case, the application reads the packet and determines an appropriate course of operation. With this data path configuration, any protocol not directly supported by hardware such as IPX can be indirectly supported by IT10G.

  Note: IPv6 packets are managed as exceptions in the Ethernet layer.

[ARP / RARP packet]
If the received packet is an ARP or RARP packet, the ARP / RARP module is enabled. This examines the packet's OP field to determine if this is a request or a reply. If so, an external entity is polling for information. If the polled address is for IT10G, reply_req is sent to the ARP / RARP reply module. If the received packet is an ARP or RARP reply, the result, ie MAC and IP address, is sent to the ARP / RARP request module.

  In another embodiment, ARP and / or RARP functions are processed in the host computer using IT10G dedicated and optimized hardware to transmit ARP / RARP packets to the host via the exception path. The

[IP packet]
If the received packet is an IP packet, the IP module can be used. The IP module checks the version field in the IP header to determine if the first received packet is an IPv4 packet.

  The IP module parses the embedded protocol of the received packet. Based on the protocol to be decoded, the received packet is sent to the appropriate module. Protocols directly supported by the hardware of this embodiment of the invention include, for example, TCP and UDP. Other protocols such as RDMA can be supported by other optimized processing modules. All unknown protocols are handled using exception handlers.

[TCP packet]
If a TCP packet is received by IT10G, the socket information is parsed and the corresponding socket is available. The socket status information is retrieved and the socket status is updated accordingly based on the type of packet received. The packet's data payload (if applicable) is stored in a socket data buffer. If an ACK packet needs to be generated, the TCP status module generates an ACK packet and schedules to send the ACK packet. If a TCP packet that does not correlate with an open socket is received, the TCP status module generates an RST packet and the RST packet is scheduled to be transmitted.

[UDP packet]
If a UDP packet is received, the socket information is parsed and the data stored in the socket receives the data buffer. If there is no open socket, the UDP packet is silently discarded.

  In another embodiment, UDP packets can be processed by the host computer using an exception handler.

[Network stack register]
The IT10G hardware network stack is configured to appear as a peripheral to the on-chip processor. The base address of the network stack is programmed via the NS_Base_Add register of the on-chip processor. This architecture allows the on-chip processor to place the network stack at various locations in its memory or I / O space.

[Ethernet (registered trademark) MAC interface]
[Overview]
The following description describes the Ethernet MAC interface module. The function of the Ethernet MAC interface module is to abstract the Ethernet MAC from the IT10G core. This allows, for example, IT10G network stack cores to be coupled to different speed MACs and / or MACs from various sources without changing the IT10G core architecture. This section describes the communication interface requirements for the IT10G core.

[Module I / O]
FIG. 5 is a block diagram schematically showing I / O used in the MAC interface module.

[Ethernet (registered trademark) interface]
[Overview]
This section describes the Ethernet interface module. The Ethernet interface module communicates with the low end Ethernet MAC interface, and blocks such as the high end ARP and IP modules. The Ethernet interface module processes data on both the receive and transmit paths. On the transmitting side, the Ethernet interface module operates to schedule packets for transmission, set up a DMA channel for transmission, and communicate via Ethernet MAC interface transmission signals. On the receiving side, the Ethernet interface module analyzes the Ethernet header, determines whether the packet should be received based on the address filter settings, and next based on the TYPE field of the packet header. Enables the encapsulated protocol, operates to align the data to start on a 64-bit boundary relative to the upper layer protocol. FIG. 6 is a schematic block diagram of the Ethernet (registered trademark) interface 40.

[Description of sub module block]
[Send Scheduler]
The transmission scheduler block 60 operates to take transmission requests from the ARP, IP, TCP, and raw transmission modules and to determine the next packet to be transmitted. The transmission scheduler determines the transmission order by comparing the QoS level of each transmission request. Along with the QoS level, each transmission request includes a pointer to the starting memory block of the packet along with the packet length. The transmission scheduler has the ability to be programmed to weight the transmission priority of certain packet types more heavily than others. For example, QoS level 5 from a TCP module can be made more valuable than level 5 requests from an IP module. The transmission scheduler allows multiple modules to operate in parallel and in a shared manner based on transmission data traffic. The following description is the algorithm currently used for packet scheduling decisions.

  Check if the packet channel has reached the starved state. This is a programmable level per channel type, ie TCP, IP, ARP, raw buffer, which indicates how many times the channel has been passed before the scheduler disables the QoS level and the packet is sent out. . If two or more packets reach the starvation state at the same time, the channel with the higher weight is given priority. Other packets are then scheduled for subsequent transmission. If the packets have the same priority weight, they are sent out alternately according to the following order: TCP / UDP, then ARP, then IP, then raw Ethernet.

  If the channel has no deficient packets, the channel with the highest combined QoS level and channel weight is transmitted.

  If only one channel has a packet to be sent, it is sent immediately.

  Once the packet channel is selected for transmission, the channel memory pointer, packet length, and type are transferred to the DMA engine. When the transfer is complete, the DMA engine then returns a signal to the transmission scheduler. At this point, the scheduler sends packet parameters to the DMA engine.

[DMA engine]
The DMA engine 61 receives packet parameters from the transmission scheduler. Packet parameters include packet type, packet length, and starting memory pointer. The DMA engine uses the packet length to determine how many data bytes are transferred from memory. The packet type indicates to the DMA engine which memory buffer to retrieve data from, and the start memory pointer indicates where to start reading the data. The DMA engine needs to understand how large each memory block used in the channel packet is because the output packet spans many memory blocks. The DMA engine receives 64 bits of data at a time from the memory controller and provides 64 bits of data to the transmitter interface at a time.

[Transmitter interface]
The transmitter interface 62 takes the output from the DMA engine and generates macout_lock, macout_rdy, macout_eof, and macout_val_byte signals of the Ethernet MAC interface. The 64-bit macout_data bus connects directly from the DMA engine to the Ethernet MAC interface.

[Receiver interface]
The receiver interface 63 operates to interface with an Ethernet MAC interface. The receiver interface takes the data and provides it to the address filter and packet type parser block along with the status count information.

[Address filter and packet type parser]
The address filter and packet type parser 64 parses the Ethernet header and performs the following two main functions:
Determine whether the packet is for a private network stack.
Analyze the encapsulated packet type to determine where to send the remaining packets.

[Address filtering]
The network stack can be programmed with the following filter options:
・ Reception of programmed unicast address,
・ Reception of broadcast packets,
・ Accepting multicast packets,
・ Accepting addresses within the range specified by the netmask,
Promiscuous mode (accepts all packets)

  All of these parameters can be set by the host computer via a register.

[Supported packet types]
The following packet types are known by IT10G hardware and are uniquely supported.
IPv4 packet with type = 0x8000,
An ARP packet with type = 0x0806,
RARP packet with type = 0x8035

  The packet type parser also handles the case where an 802.3 length parameter is included in the TYPE field. This case is detected when the value is 1500 (decimal) or less. When this condition is detected, the type parser should send the encapsulated packet with both the 802_frame signal assertion to both the ARP and IP receiving modules and decode the packet with the realization that the module is not really intended. Each subsequent module approves that it is.

  Note: IPv6 packets are treated as exception packets by the Ethernet layer.

  FIG. 7 is a schematic block diagram of the address filter and packet type parser module, and FIG. 8 is a timing diagram showing the operation of the address filter and packet type parser module. At the I / O timing, the signal indicating the packet type is in the asserted state until the assertion of the machine_lock signal corresponding to the packet is canceled. The All_packet signal also only triggers if the destination MAC address is acceptable.

  The address filter and packet type parser module parses a packet that it does not understand, and if an unsupported type characteristic becomes available, the packet is forwarded to an exception handler for storage and further processing. Is done.

[Data aligner]
Data aligner 65 operates to align the data bytes of subsequent packet processing layers. A data aligner is required because the Ethernet header is not an even multiple of 64 bits. Depending on whether a VLAN tag is present, the data aligner directs the 64-bit data so that the data is MSB aligned with respect to the upper processing layer. In this way, the payload section of an Ethernet frame is always aligned on an even 64-bit boundary. The data aligner also operates to generate a ready signal to the next layer. The ready signal activates 2 or 3 ready cycles after macin_rdy is asserted. FIG. 9 is a schematic block diagram of the configuration data alignment module.

[Ethernet (registered trademark) packet format]
IT10G receives both 802.3 (SNAP) and DIX format packets from the network, but only transmits DIX format packets. In addition, when 802.3 packets are received, they are first converted to DIX format and then processed by an Ethernet filter. Therefore, all Ethernet exception packets are stored in DIX format.

[ARP protocol and ARP cache module]
[Overview]
The following is a detailed description of the ARP protocol and ARP cache module. In one embodiment of the IT10G architecture, the ARP protocol module also supports the RARP protocol, but does not include the ARP cache itself. Since each module that can send a packet queries the ARP cache earlier than this, this common resource is separated from this ARP module. The ARP protocol and ARP cache module send updates to the ARP cache based on the received packet type.

ARP property list:
-It is possible to respond to an ARP request by generating an ARP reply.
An ARP request can be generated in response to the ARP cache.
-ARP replies can be given for multiple IP addresses (multihomed host / ARP proxy).
A target (unicast) ARP request can be generated.
• Filter illegal addresses.
Transfer the aligned ARP data to the processor.
・ Free ARP can be done.
The CPU may bypass the automatic ARP reply generation and dump the ARP data to the exception handler.
• The CPU may generate a custom ARP answer (when in bypass mode).
Depending on network conditions, it has variable priority of ARP packets.

RARP property list:
-Request an IP address.
Request a specific IP address.
• The RARP request is handed off to the exception handler.
• Manage irregular RARP responses.
Send the aligned RARP data to the processor.
The CPU can generate custom RARP requests and answers.

ARP cache characteristics:
・ Dynamic ARP table size,
-Automatically updated ARP entry information,
-An interrupt when the sender's hardware address changes,
・ Ability to collect ARP data crowded,
・ Duplicate IP address detection and interrupt generation,
ARP request capability via the ARP module,
-Support for static ARP entries,
An option that allows static ARP entries to be replaced by dynamic ARP data;
・ ARP proxy support,
A configurable expiration time for the ARP entry.
(The CPU may be either a host computer CPU or an on-chip processor in this context.)

[ARP module block diagram]
FIG. 10 is a schematic block diagram of one configuration of the ARP module.

[ARP cache module block diagram]
FIG. 11 is a schematic block diagram of one configuration of the ARP cache block.

[ARP module theory of operation]
Packet parsing
The ARP module 100 processes only ARP and RARP packets. The module waits for a ready signal received from the Ethernet receiving module. When the signal is received, the frame type of the incoming Ethernet frame is checked. If the frame type is not ARP / RARP, the packet is ignored. Otherwise, the module starts parsing.

  Data is read from the Ethernet interface in 64-bit words. An ARP packet takes 3.5 words. The first word of an ARP type packet contains mostly static information. The first 48 bits of the first word of an ARP type packet include the hardware type, protocol type, hardware address length, and protocol address length. These received values are compared with the values expected in an ARP request for IPv4 over Ethernet. If the received values do not match, the data is sent to the exception handler for further processing. Otherwise, the ARP module continues analysis. The last 16 bits of the first word of an ARP type packet contain an operation code. The ARP module stores the operation code and checks whether it is valid, i.e., 1, 2 or 4. If the opcode is not valid, the data is sent to the exception handler for further processing. Otherwise, the ARP module continues analysis.

  The second word of the ARP type packet contains the source Ethernet address and half the source IP address. The ARP module stores the first 48 bits in the source Ethernet address register. The ARP module then checks whether this field is a valid source Ethernet address. The address must not be the same as the address of the IT10G network stack. If the source address is not valid, the packet is discarded. The last 16 bits of the packet are then stored in the upper half of the source IP address register.

  The third word of the ARP type packet contains the second half of the source IP address and the target Ethernet address. The ARP module stores the first 16 bits in the lower half of the source IP address register and checks whether the stored value is a valid source IP address. The address must not be the same as the IT10G hardware address or broadcast address. The source address should be in the same subnet. If the source address is not valid, the ARP module discards the packet. If the packet is an ARP / RARP reply, compare the target hardware address with the Ethernet address. If the addresses do not match, the ARP module discards the packet. Otherwise, the ARP module continues analysis.

  Only the first 32 bits of the last word of an ARP type packet contain data (target IP address). The ARP module stores the target IP address in a register. If the packet is an ARP packet (as opposed to an ARP request or RARP packet), compare the target IP address with the IP address. If the addresses do not match, discard this packet. Otherwise, if this packet is an ARP request, an ARP reply is generated. If this is a RARP reply, transfer the assigned IP address to the RARP handler.

  Once all address data is confirmed, the source address is transferred to the ARP cache.

[Transmission packet]
The ARP module sends packets from three sources: the ARP cache 110 (ARP request), the parser / FIFO buffer (for ARP answers) internally, and the system controller (for custom ARP / RARP) or the host computer. Can receive requests. Because of this condition, priority-queue type is needed to schedule transmission of ARP / RARP packets.

  Transmission requests are queued on a first-come-first-served basis, except when two or more entries wish to transmit. In that case, the next request in the queue will follow that priority. RARP requests usually have the highest priority, followed by ARP requests. ARP answers usually have the lowest priority. Resources can be shared according to data traffic through the use of priorities.

  There is one state in which the ARP answer has the highest priority. This occurs when the ARP reply FIFO buffer is full. When the FIFO buffer is full, incoming ARP requests will begin to be discarded, so the ARP reply should have the highest priority at that time to avoid having the ARP request retransmitted.

  When the transmission queue is full, no further requests are made until one or more transmission requests are achieved F (dequeued). When the ARP module detects a full queue, it requests an increase in priority from the sending arbiter. This request signal can be a single bit because there are only two states in the queue: full or not full.

  When the sending arbiter allows sending the ARP module, ARP / RARP packets are generated dynamically according to the type of packet being sent. The packet type is determined by the instruction code, which is stored in each queue entry. FIG. 12 shows the transmission queue entry format.

[Bypass mode]
The ARP module has an option to bypass the automatic processing of incoming packet data. When the bypass flag is set, incoming ARP / RARP data is transferred to the exception handler buffer. The CPU then accesses the buffer and processes the data. When in bypass mode, the CPU generates its own ARP reply and transfers the data to the transmission scheduler. The fields that can be customized in the output ARP / RARP packet are a source IP address, a source Ethernet (registered trademark) address, a target IP address, and an instruction code. All other fields match the standard values used in IPv4 ARP / RARP by Ethernet and the source Ethernet address is set to the address of the Ethernet interface. (The CPU may be a host computer or an on-chip processor in this context.)
Note: If these other ARP / RARP field changes are required, the CPU must generate the raw Ethernet frame itself.

[Theory of ARP cache operation]
[Add ARP entry to ARP cache]
An ARP is generated when receiving a targeted ARP request and answer (dynamic) or when requested by the CPU (static). (The CPU may be a host computer or on-chip processor in this context.) A dynamic entry is an ARP entry that is generated when an ARP request or answer is received for one of the interface IP addresses. A dynamic entry typically exists for a limited time of 5 to 15 minutes as specified by an application program running on the user or host computer. Static entries are ARP entries that are created by the user and do not normally terminate.

  New ARP data comes from two sources: the CPU and ARP packet parser via the ARP registers. Because it is necessary to process incoming ARP data as quickly as possible, dynamic ARP entries have priority when both sources request to add ARP entries at the same time.

  Once the ARP data source is selected, it is necessary to determine where in the IT10G hardware memory the ARP entry is stored. To do this, a lookup table (LUT) is used to map a given IP address into a memory location. The search table contains 256 entries. Each entry is 16 bits wide and includes a memory pointer and pointer valid (PV) bits. The PV bit is used to determine whether the pointer points to a valid address, i.e. the starting address of a memory block allocated by the ARP cache. FIG. 13 shows a search table entry format.

  An 8-bit index is used to determine where in the LUT the pointer needs to be retrieved. This index is taken from the last octet of the 32-bit IP address. The reason for using the last octet is that in a local area network (LAN), this is the portion of the IP address that varies most between hosts.

  Once the slot used by the LUT is determined, it is checked whether or not a valid pointer (PV = "1") is included in the slot. If there is a valid pointer, it means that there is a block of memory assigned to this index, and the target IP address can be found in that block. At this point, the directed memory block is searched and the target IP address is searched. If the LUT does not contain a valid pointer for this slot, the memory must be allocated from internal memory, malloc1. Once the memory is allocated, the address of the first word of the allocated memory is stored in the pointer field of the LUT entry.

  After allocating memory and storing the pointer in the LUT, it is necessary to store the necessary ARP data. This ARP data contains the IP address needed to determine if this is an accurate entry during cache search. A set of control fields is also used. The retry counter is used to keep track of multiple ARP request attempts made at a given IP address. The type field indicates the type of cache entry (000 = dynamic entry; 001 = static entry; 010 = proxy entry; 011 = ARP check entry). The resolution flag indicates that this IP address is properly resolved to an Ethernet (registered trademark) address. A valid flag indicates that this ARP entry contains valid data. Note: While the first ARP request is made, the entry is valid and not resolved. The src field indicates the source of the ARP entry (00 = dynamic addition, 01 = system interface, 10 = IP router, 11 = both system interface and IP router). The interface field allows the use of multiple Ethernet interfaces, but defaults to a single interface (0). The control field that follows is a link address that points to the following ARP entry. The high-order bit (MSB) of the link address is actually the flag link_valid. The link_valid bit indicates that another ARP entry follows. The last two fields are an Ethernet address where the IP address is resolved and a time stamp. The time stamp indicates when the ARP address was generated and is used to determine whether the entry has expired. FIG. 14 shows an example of the ARP cache entry format.

  In a LAN with more than 256 hosts or multiple subnets, collisions between different IP addresses occur in the LUT. In other words, two or more IP addresses can be mapped to the same LUT index. This is for two or more hosts having a predetermined value in the last octet of the IP address. To deal with collisions, the ARP cache uses chains, which are described next.

  A search is performed on the LUT and when an entry is found to already exist in that slot, an ARP entry directed from memory is searched. Check the IP address of the ARP entry and compare it with the target IP address. If the IP addresses match, the entry can simply be updated. However, if the addresses do not match, observe the Link_Valid flag and the last 16 bits of the ARP entry. The last 16 bits contain the link address pointing to another ARP entry that maps to the same LUT index. If the Link_Valid bit is asserted, search for an ARP entry pointing to the link address field. Again, the IP address in the entry is compared with the target IP address. If there is a match, the entry is updated, and if not, the search process continues (with subsequent links in the chain) until a match is found or the Link_Valid bit is not asserted.

  When the end of the chain is reached and no match is found, a new ARP entry is created. Creation of a new ARP entry requires allocation of memory by the malloc1 memory controller. Each block of memory is 128 bytes in size. Thus, each block can accommodate 8 ARP entries. If the end of the block is reached, a new memory block must be requested from malloc1.

  As previously mentioned, the user (or application running on the host computer) has the option of creating a static or permanent ARP entry. The user has the option of allowing dynamic ARP data to replace static entries. In other words, when ARP data is received for an IP address for which a static ARP entry has already been generated, the static entry can be replaced with the received data. The advantage of this arrangement is that static entries become stale, allowing dynamic data to be overwritten on static data, resulting in a newer ARP table. This update capability is disabled if the user is confident that the IP to Ethernet address mapping is constant, eg, storing the router interface IP and Ethernet addresses. Is done. The user can also choose to keep a static entry to minimize the number of ARP broadcasts on the LAN. Note: ARP proxy entries can never be overwritten by dynamic ARP data.

Search cache entries
Searching for an ARP cache entry follows a process similar to the process of creating an ARP entry. The search begins by using the LUT to determine whether memory is assigned to a given index. If memory is allocated, the memory is searched until an entry is found (causes a cache hit) or encounters an entry with the link_valid flag set to zero (cache loss).

  If a cache loss occurs, an ARP request is generated. This includes creating a new ARP entry in the cache and a new LUT entry if necessary. In the new ARP entry, the target IP address is stored, the resolution bit is set to zero, and the valid bit is set to one. The request counter is similarly set to zero. The entry is then time stamped and the ARP request is sent to the ARP module. If no answer is received after 1 second, the request counter is incremented and another request is sent. After sending three requests and not receiving a reply, the attempt to resolve the target IP is abandoned. Note: The retry interval and the number of request retries are user configurable.

  When a cache loss occurs, the request module is notified of the loss. This allows the CPU or IP router to decide to wait for an ARP reply for the current target IP address, or to start a new search for another IP address and place the current IP address at the back of the queue. It is done. This minimizes the impact of cache loss on multiple connection settings. FIG. 15 is a flowchart showing the ARP search process.

  If a matching entry is found (cache hit), the resolved Ethernet address is returned to the module requesting the ARP search. Otherwise, if the target IP address is not found in the cache and all ARP request attempts time out, the request module is notified that the target IP address has not been resolved.

  Note: When an ARP search request from an IP router fails, the router must wait at least 20 seconds before starting to search further for that address.

[Cache initialization]
When the ARP cache is initialized, some components are reset. The lookup table (LUT) is cleared by setting all PV bits to zero. All currently used memory is deallocated and released back to the malloc1 memory controller. The ARP expiration timer is also set to zero.

  During the initialization period, no ARP request is generated. Also, attempts to generate an ARP entry from the CPU (static entry) or from received ARP data (dynamic entry) are ignored or discarded.

[Expiration of ARP entry]
Dynamic ARP entries can only exist in the ARP cache for a limited amount of time. This prevents any IP-to-Ethernet address mapping from being invalidated. Old address mapping occurs if the LAN uses DHCP to assign an IP address or if the Ethernet interface of the device is changed during the communication session.

  A 16-bit counter is used to maintain time tracking. A counter operating at a clock frequency of 1 Hz is used to track the number of seconds that have elapsed. Each ARP entry contains a 16-bit timestamp taken from this counter. This time stamp is taken when the IP address is properly resolved.

  The expiration of an ARP entry occurs when the ARP cache is idle, i.e. no search or request is currently being processed. At this time, the 8-bit counter is used to search and search the LUT. Each slot in the LUT is checked to see if it contains a valid pointer. If the pointer is valid, the memory block to which it points is retrieved. Each entry in the block is then checked to see if the difference between its timestamp and the current time is greater than or equal to the maximum lifetime of the ARP entry. If other memory blocks are unchained from the first memory block, the entries contained in these blocks are also checked. Once all entries associated with a given LUT index have been checked, the next LUT slot is checked.

  If it is found that the entry has expired, the valid bit in the entry is set to zero. If no other entry exists in the same memory block, the block is deallocated and returned to malloc1. If the deallocated block is the only block associated with a given LUT slot, the PV bit for that slot is also set to zero.

[Execute ARP proxy]
The ARP cache supports proxy ARP entries. The ARP proxy is used when this device acts as a router for LAN traffic or when there is a device on the LAN that cannot respond to ARP queries.

  When the ARP proxy is enabled, the ARP module passes requests for IP addresses that do not belong to the host to the ARP cache. The ARP cache then searches to find the target IP address. If a match is found, the type field of the ARP entry is examined to determine if it is a proxy entry. If it is a proxy entry, the ARP cache returns the corresponding Ethernet address to the ARP module. The ARP module then generates an ARP reply using the Ethernet address found in the proxy entry as the source Ethernet address. Note: ARP proxy search is only performed for incoming ARP requests.

[Duplicate IP address detection (ARP check)]
When the system (host computer and IT10G hardware) first connects to the network, the user or application running on the host computer uses one of the IP addresses assigned to that interface by any other device on the network. A free ARP request should be made to test whether If two devices on the same LAN use the same IP address, this creates a problem for the two host routing packets. A free ARP request is a request for a host-specific IP address. If no answer to the query is received, it can be assumed that there are no other hosts on the LAN using IP addresses.

  The ARP check is started in a manner similar to that of performing an ARP search. The only difference is that the cache is discarded once the ARP request is completed. If no answer is received, the entry is removed. If a reply is received, an interrupt is generated to notify the host computer that the IP address is being used by another device on the LAN, and the entry is removed from the cache.

[Cache access priority]
Different tasks have different priorities for access to the ARP cache memory. The search for proxy entries has the highest priority because it requires a quick response to the ARP request. The second priority is to add dynamic entries to the cache, and incoming ARP packets must be received at a very high rate and processed as quickly as possible to avoid retransmission. The ARP search from the IP router has the next highest priority, followed by the search by the host computer. Manual generation of ARP entries has the second lowest priority, expired cache entries have the lowest priority, and occur whenever the cache does not handle ARP searches or generate new entries.

[IP module]
[Overview]
The UT 10G inherently supports IPv4 packets that automatically parse on all types of received packets.

[Block diagram of IP module]
FIG. 16 is a schematic block diagram of one configuration of the IP module block.

[Description of IP submodule]
[IP parser]
The IP parser module 161 operates to analyze the received IP packet and determine where to send the packet. Each received IP packet can be sent to a TCP / UDP module or an exception handler.

[Analysis of IP header field]
Only IPv4 is received and parsed by the IP module, so this field must be 0x4 processed. If an IPv6 packet is detected, it is managed and processed as an exception by the exception handler. Any packet with a version smaller than 0x4 is considered malformed (illegal) and the packet is dropped.

[IP header length]
The IP header length field is used to determine whether any IP options are present. This field must be 5 or greater. If it is smaller, the packet is considered malformed and dropped.

[IP TOS]
This field is not parsed or maintained in the received packet.

[Packet Len]
This field determines the total number of bytes in the received packet and is used to indicate where the end of the data section exists in the next level protocol. After this count expires, all data bytes received before the ip_packet signal releases the assertion are assumed to be embedded bytes and are silently discarded.

[Packet ID, flag, fragmentation offset]
These fields are used for packet defragmentation. Fragmented IP packets can be processed by dedicated hardware or treated as exceptions and processed by exception handlers.

[TTL]
This field is not parsed or maintained in the received packet.

[PROT]
This field is used to determine the next encapsulated protocol. The following protocols are fully supported (or partially supported in other embodiments) in hardware.

  If any other protocol is received and the unsupport_prot property is enabled, the packet can be sent to the host computer. A protocol filter can be selectively enabled to receive certain protocols. Otherwise, the packet is silently discarded.

[Checksum]
This field is not parsed or maintained. This is simply used to ensure that the checksum is correct. If the checksum is found to be inappropriate, the bad_checksum signal going to all next layers is asserted. This is the state of the claim until it is answered.

[Source IP address]
This field is parsed and sent to the TCP / UDP layer.

[Destination IP address]
This field is parsed and checked against a valid IP address to which the local stack should respond. This takes more than one clock cycle, in which case the analysis must continue. If it is found that the packet has been misdirected, the bad_ip_add signal is asserted. This is the state of the claim until it is answered.

[IP ID generation algorithm]
The on-chip processor can set the IP ID seed value by writing any 16-bit value to the IP_ID_Start register. The ID generator takes this value and performs a 16-bit mapping to generate an IP ID for use by different requesters. On-chip processors, TCP modules, and ICMP echo reply generators can all request an IPID. A block diagram of one structure of the ID generator is shown in FIG.

  The IP ID seed register is incremented each time a new IP ID is requested. The bit mapper block re-arranges the IP ID_Reg value so that the IP ID_Out bus is not a simple increment value.

[IP injector module]
The IP injector module is used to inject packets from the on-chip processor to the IP and TCP modules. The IP injector control registers are located in the IP module register space and these registers are programmed by the on-chip processor. A block diagram showing the data flow of the IP injector is shown in FIG.

  As can be seen, the IP injector can insert data under the IP module. To use IP injection, the on-chip processor programs the IP injector module with the start address of the memory where the packet resides, the length of the packet, and the source MAC address. The injector module generates an interrupt when it completes sending a packet from the memory of the on-chip processor to the stack.

[TCP / UDP module]
[Overview]
This section describes the TCP module, which manages TCP and UDP transport protocols. The TCP module is divided into four main sections: socket send interface, TCP send interface, TCP receive interface, and socket receive interface.

[Feature list]
The following is a list of IT10G TCP characteristics.
64K socket support Inappropriate support for TCP Slow start Fast retransmission / Recovery Selectable Nagle algorithm Window scaling Selective ACK (SACK) Protection against wrapped sequence numbers
(PAWS)
Timestamp support Keepalive timer [Window scaling]
IT10G supports window scaling. Window scaling is an extension that expands the TCP window specification to 32 bits. This is specified in RFC 1323 section 2 (see http://www.rfc-editor.org/rfc/rfc1323.txt). Window scale behavior is based on three variables. One is the SL_Win_En bit of TCP_Control1 (this enables the window scale), the second is the sliding window scale of TCP_Control3 (which sets the scaling factor), and the last is the value to be scaled WCLAMP parameters that determine

  Without the SL_Win_En bit, the hardware does not attempt to negotiate window scaling via the TCP window scale option during the TCP-3 direction handshake.

[TCP dump mode]
The TCP dump mode is an IT10G hardware mode that enables support for widely used diagnostic programs such as TCP dumps and other packet monitoring programs. When TCP dump mode is enabled, all received packets are sent as exceptions to the host, and all outgoing TCP / UDP packets coming from the hardware stack are looped back as exception packets.

  The driver makes a copy of these packets to the network monitor, injects the received packet again, and sends the transmitted packet as a raw Ethernet frame.

[Host ACK mode]
The host ACK mode is an IT10G hardware mode in which only the TCP ACK is transmitted when the host computer receives data from the TCP segment. The host ACK mode waits for the MTX buffer DMA containing the data segment to complete before sending the ACK. The host ACK mode ensures additional data integrity if data is corrupted when passing between the host computer and the integrated network adapter or vice versa.

[Time stamp]
IT10G provides time stamp support. The time stamp is an enhancement to TCP defined in RFC 1323 (see http: //www/rfc-editor.org/rfc/rfc1323txt). The time stamp allows TCP to compute RTT (round trip time) measurements well and is used to support PAWS (protection against wrapped sequences).

[PAWS]
PAWS (protection against wrapped sequences) is specified in RFC 1323 (see http: //www/rfc-editor.org/rfc/rfc1323txt). PAWS is a protection against old duplicate segments that break TCP connections. This is an important feature for high speed links.

[TCP host retransmission mode]
The TCP host retransmission mode allows data to be retransmitted directly from the host's memory buffer rather than from a buffer located at the integrated network adapter. This allows the amount of memory required by the integrated network adapter to be reduced.

[Initial sequence number generation]
The initial sequence number generation needs to be protected. RFC 1948 points out the weaknesses of RFC 793's original initial sequence number specification and recommends several alternative methods. The integrated network adapter uses an optimized method that operates according to RFV 1948, but is efficient to configure in hardware.

[Double stack mode]
The dual stack mode allows the hardware TCP / IP stack integrated in the network adapter to work together with the host computer's TCP / IP stack.

  The dual stack mode allows the integrated network adapter to support the coexistence of software stacks operating in parallel using the same IP address.

  The dual stack mode requires two basic hardware functions of the integrated network adapter. The first hardware function is the SYN status message mode. In the SYN status message mode, any received SYN generates a status message to the host computer, and the SYN / ACK responds until the host computer returns the appropriate instruction block to the integrated network adapter hardware. Not generated by hardware. If the SYN status message mode is not enabled on the integrated network adapter, SYN / ACK is automatically generated by the integrated network adapter and no status message is generated.

  A second hardware function required by the dual stack mode is suppression of RST messages from the integrated network adapter hardware when a TCP packet that does not match the integrated network adapter control block database is received. In this case, instead of automatically generating an RST, the integrated network adapter hardware hosts the packet as an exception packet to allow the host computer's software TCP / IP stack to handle this packet as an exception packet. Must be sent to the computer.

[IP ID division]
IP (Internet Protocol) ID (Internet Identification) partitioning is part of the dual stack support package. IP ID partitioning allows host computers and integrated network adapters to share IP addresses without IP ID overlap. When IP ID split is switched off, the integrated network adapter uses the full 16-bit ID range (0-255). When IP ID split is switched on, IP ID bit [15] is set to 1, allowing the TCP / IP stack of the host computer software to use half of the IP ID range (ie, an integrated network adapter Uses 128-255, and the host computer software TCP / IP stack uses 0-127 in the IP ID).

[Custom filtering]
There are several locations in the hardware that have custom filters that can be used to limit, approve, or perform special operations on certain types of packets. Ethernet filtering can take the following attributes:
Receiving a programmed unicast address,
・ Receiving broadcast packets,
・ Receiving multicast packets,
・ Receiving addresses within the range specified by the netmask,
Enable promiscuous mode (accept all packets).

[VLAN support]
VLAN support consists of several optimized hardware elements. One hardware element removes the VLAN header from the input packet, the second optimized hardware element generates an output packet tagged with a VLAN, and the third optimized hardware element is the input SYN. A VLAN parameter is generated from the frame, and the fourth optimized hardware element passes the VLAN tag information of the exception packet and the UDP packet.

[Jumbo frame support]
The jumbo frame is larger than a normal 1500 byte Ethernet (registered trademark) frame. A jumbo frame that is smaller than the network bandwidth used for header information allows for increased data processing capacity in the network. The integrated network adapter uses hardware that is optimized to support jumbo frames up to 9 kbytes.

[SNMP support]
SNMP is a form of high-level protocol that allows network and hardware adapter performance statistics to be monitored remotely.

[MIB support]
The integrated network adapter includes hardware support optimized for a number of statistical counters. These statistical counters are defined by a standard management information base (MIB). Each of these SNMP MIB counters tracks events that occur in the network and integrated network adapters (received, transmitted, dropped packets).

[Memory check]
Memory error checking and correction (ECC) is similar to partial checking. However, even if the parity check can detect only a single bit error, the ECC can detect and correct a single bit memory error and detect a double bit error.

  Single bit errors are most common and are characterized by a single bit of data that is inaccurate when reading a complete byte or word. A multi-bit error is the result of two or more bits in error within the same byte or word.

  The ECC memory uses additional bits to store the encrypted ECC code along with the data. When data is written to memory, the ECC code is also stored. When the data is read back, the stored ECC code is compared with the ECC code generated when the data was written. If the ECC codes do not match, it can be determined which bits in the data are in error. The error bit is "inverted" and the memory controller releases the corrected data. Errors are corrected “on-the-fly” and the corrected data is not returned to memory. If the same corrupted data is read again, the correction process is repeated.

  The integrated network adapter allows the ECC to be programmed and selected in a flexible way to protect both packet data and control information within the adapter.

[Heritage mode]
Legacy mode allows all network traffic to be sent to the host computer regardless of traffic type. These modes allow the integrated network adapter to operate as if a hardware TCP / IP stack is not present on the adapter, and the mode is often referred to as a dump NIC (network interface card).

[IP fragmentation]
Reassembly of IP fragmented packets is not handled by the integrated network adapter. The IP fragmentation packet is passed as an exception packet, reassembled in the driver, and then “reinjected” to the integrated network adapter via the IP injection mode.

[IP injection]
The IP injection mode allows IP packets (eg, reassembled IP fragments or IPsec packets) to be injected into the hardware TCP / IP stack of the integrated network adapter.

  The injection control register is used to inject IP packets into the TCP / IP stack in the integrated network adapter. The injection control register feature allows the host computer to control injection and to inject IP packets into the hardware TCP / IP stack in the integrated network adapter. The injection control register thus allows injection of SYN, IPSec, or other packets into the integrated network adapter. The injection control register is also part of the TCP dump mode function.

[NAT, IP masquerade, port forwarding]
NAT, IP masquerading, and port forwarding are supported by the integrated network adapter via a port range register that forwards all specified type UDP or TCP packets that fall into the programmable range of the port to the exception path. The port register allows a range of ports to be used in network control operations such as NAT, IP masquerading, and port forwarding.

[Multiple IP addresses]
The integrated network adapter hardware supports up to 16 ranges of IP addresses that can respond as its own IP address. These address ranges are accessible as an IP address base with a mask. This allows the IP address to be extended to the IP address range. This allows the integrated network adapter to perform multihoming or the ability to respond to multiple IP addresses.

[IP debug mode]
When the test and control bits are available on the integrated network adapter, all IP packets are sent as exceptions to the host computer. This mode is designed for diagnostic purposes.

[Time standby state]
Time standby is the final state of a passive mode TCP connection, and the time standby state and its operation are described in RFC 793, see http://www.rfc-editor.org/rfc/rfc793.txt I want.

Virtual socket
The integrated network adapter hardware supports a variable number of sockets or connections, and the current configuration supports up to 645535 sockets.

  The integrated network adapter provides optimized hardware support (integrated with the TOE) to transfer the connection between the adapter and the host computer.

  When the integrated network adapter hardware accepts a connection equal to its maximum capacity, the next SYN is passed to the host as an exception packet, and the host can handle this connection. For the host to open this connection, use a portion of the dual stack mode that allows TCP packets that do not match the hardware database to be forwarded to the host as exception packets instead of replying to the RST. Note that you need to configure the hardware.

[Survival time]
TTL or lifetime is an IP address parameter that limits the lifetime of IP packets in the network to the number of hops (a hop is a jump across layer 3 devices such as routers). The integrated network adapter hardware sets this value to be limited to the lifetime of the transmitted packet for the output frame. For more information, see RFC 791 section lifetime at http://www.faqs.org/rfcs/rfc791.html.

[Keep Alive]
Keepalives are described in section 4.2.3.6 of RFC1122. Refer to http://www.faqs.org/rfcs/rfc1122.html. Keepalive allows idle TCP connections to stay connected and not time out by periodically sending keepalive packets across the link.

[ToS]
TOS or type of service is an IP address parameter that can be used by the router to prioritize IP packets. TOS parameters need to be adjustable at the system and socket layers. On transmission, the integrated network adapter hardware sets the TOS via several registers. See http://www.faqs.org/rfcs/rfc791.html for more information on service types in the RFC791 section.

[QoS]
The integrated network adapter hardware supports four transmission queues to allow QoS of transmitted data. Each socket can be assigned a QoS value. This value can also be used to map to a VLAN priority level.

  The transmission operation is summarized as follows. The TCP transmit data flow begins with a socket query module, which goes through the transmit data valid bit table and looks for entries with their transmit data valid bit set. When such an entry is found, the socket query module places the entry in one of four queues according to the socket's user priority level. Sockets with priority level 7 or 6 are placed in queue list 3, levels 5 and 4 are placed in queue list 2, levels 3 and 2 are placed in queue list 1, levels 1 and 0 are queued Placed in matrix list 0.

  These QoS characteristics using priority queues allow the parallel use of multiple hardware modules according to the transmitted traffic.

[Failover]
Failover between network adapters is supported by the NO_SYN mode. The NO_SYN mode allows a socket to be created without attempting to initiate a connection. This allows the integrated network adapter hardware socket and all its associated data structures to be created without a connection. The NO_SYN mode enables support for failover from a software TCP / IP stack to another card or connection transition from the integrated network adapter.

[Top-level block diagram]
FIG. 19 shows a top-level block diagram of one configuration of the TCP module. A socket control block (CB) 191 contains information, status, and parameter settings specific to each socket connection and forms the most important or key part of the virtual socket (VSOCK) architecture. The locking mechanism is installed so that one module operates on the CB while the other module does not.

[TCP reception sub-module]
FIG. 20 shows a TCP reception 200 data flow.

[Overview]
For normal IP traffic, the packet is received via a 64-bit TCP Rx data path. The packet header proceeds to the TCP parser module, and the packet data is routed to the received data memory controller 201. For IP fragmented traffic, data is received via the memory block and header information is received via the normal path. This makes the memory block from IP fragmentation look similar to the data block written by the received data memory controller. CPU data also uses memory blocks to inject received data through the received data memory controller. This architecture provides maximum flexibility in handling normal and fragmented traffic, which allows performance to be optimized for normal traffic while supporting fragmented traffic.

  The receive TCP parser 202 operates to analyze the header information and pass the parameters to the VSOCK 203 and the receive state handler 204. If the receiving TCP parser does not know what to do with the data, it is forwarded to the exception handler 205. In addition, the receiving TCP parser can be programmed to send all data to the exception handler.

  The VSOCK module takes local and remote IP and port addresses and returns a pointer to the control block.

  The NAT & IP masquerade module 206 determines whether the received packet is a NAT or IP masquerade packet. If yes, the packet is passed to the host system in raw (complete packet) format.

  The receive state handler keeps track of the state of each connection and therefore updates its control block.

[Receive TCP parser]
The reception TCP parser registers the packet header information with other modules in the TCP reception part of the IT10G network stack and transmits it. The receive TCP parser module also includes registers that are required to inject data from the CPU (on-chip processor or host computer) into the receive stream. The CPU must set up the memory block and then program the information into the receive TCP parser register. The receive TCP parser generates a partial checksum of the TCP header, appends this partial checksum to the partial checksum from the received data memory controller, and the resulting complete checksum of the TCP header. Compare with checksum. For fragmented packets, the receiving TCP parser checks the checksum of the TCP header against the checksum sent by IP fragmentation in the last fragment.

  Note: The IP module must set the IP fragmentation bit and insert the first memory block pointer, last memory block pointer, index, and partial checksum into the appropriate packet fragment data stream. TCP reception also requires IP protocol information to calculate pseudo headers.

[Received data memory controller]
The received data memory controller transfers data from the 64-bit bus between the IP and TCP modules to the RxDRAM data memory block. There are two transfer modes. The normal mode is used to store TCP data in the memory block. Raw mode is used to store the entire packet in a memory block. Raw mode is used for NAT / IP masquerading. In exception handling, the normal mode is used with a register to transfer CB data to the CPU.

[VSOCK]
The VSOCK module passes the local and remote IP and port address from the packet and returns a socket open or TIME_WAIT (TW) control block (CB) pointer to the receive state handler. VSOCK performs a hash calculation with the IP and port address and generates a hash value that serves as an index to the Open / TW CB Search Table (LUT) 207. The LUT entry at that position holds a pointer to the release 208 or TW209 control block.

  The pointer from the Open / TW CB LUT points to the first control block in the linked list of zero or more CBs, each with a different IP and port address, but the same hash number (resulting from a hash collision) Produce. VSOCK goes through this chain and compares the packet IP and port address with the entries in the chained CB until a match is found or the end of the chain is reached. If a match is found, a pointer to the CB is passed to the receive state handler. If the end of the chain is reached, VSOCK notifies the TCP parser of an error.

  The chain of CBs connected to the Open / TW CB LUT entry includes Open CB and TIME_WAIT CB. The open CB is the first in the chain. There is a maximum number of open CBs as determined by the incoming TCPMaxOpenCBperChain. The TW CB is chained after the open CB. There is also a maximum number of TW CBs per chain. The open CB is generated when the three-way handshake is completed, and the HO CB is moved to the open CB by the reception state handler. The TW CB is generated from the open CB by the reception status handler when the last ACK is sent in the FIN sequence. If there is no more room in either case, the error is returned to the receive state handler.

  The CB cache of the open CB is composed of open CBs instead of presetting the number of links from the LUT entry. The CB bit is set when in the cache. The cache is searched in parallel for hash / LUT operations. FIG. 21 shows a control block search solution flow of the VSOCK / reception status handler.

[Rcv state handler]
If SYN is received, the 12-bit hash is made in addition to the VSOCK call (to open the 17-bit hash and search for the TIME_WAIT control block), and the destination port is checked against the allowed port list. Is done. If the port is enabled and VSOCK does not find a matching Open / TW CB, the hash result is used as an index into the HO CB table. If VSOCK discovers open or TIME_WAIT CB, a Dup CB error can be sent to the host computer and SYN is dropped. If an entry with a different IP and port address already exists in the HO CB table, the new packet information is overwritten on the old information. This allows resources to be held in a SYN flood denial of service (DOS) attack. Overwriting eliminates the need for aging of the HO CB table. An already SYN / ACKed connection can be implicitly dropped. The pointer to CB is transferred to the reception status handler. Only connections opened by the remote side (the local side receives SYN, not SYN / ACK) enter the HO CB table. Connections opened by the local side are tracked by the open CB.

  If an ACK is received, a 12-bit hash is performed and VSOCK is called. A three-way handshake for the connection if there is a hit in the HO CB via a 12-bit hash, but VSOCK does not find an open or TW CB, and if the sequence and ACK number are valid Is complete and the CB is transferred to the open CB table by the reception state handler. If VSOCK finds an open or TW CB but does not match the 12-bit hash, the ACK is checked for a valid sequence and ACK number, and a duplicate ACK by the receive state handler.

  Once the VSOCK module finds the correct socket CB, other appropriate information is read and updated by the receive state handler. TCP data is stored in a large (2 kbytes) or small (128 bytes) memory buffer. A single segment can span the memory buffer. If there is no buffer of one size, the other size is used. When data is received at a given socket, its Data_Avail bit of the socket hash LUT is also set.

  If the receive state handler determines that an RST packet is required, the receive state handler forwards the appropriate parameters to the RST generator 210. If SYN / ACK or ACK is required, the receive state handler sends a CB handle to the receive / send FIFO buffer 211.

[RST generator]
The RST generator takes a MAC address, four socket parameters, a sequence number received in a packet that requires an RST response, and constructs an RST packet. The RST generator first requests a block from the MTX memory to create a packet. Since RST packets are always 40 bytes long, these packets fit in any size MTX block. The RST generator always requests the smallest available block, usually a 128 byte block. The RST packet has their IP ID fixed at 0x0000 and their DF bits set in the IP header (not the fragment bits).

  After the RST generator constructs the RST packet, the RST generator stores the start address of the MTX block containing the RST packet in the RST transmission queue. This queue is formed in the M1 memory. A block of M1 memory is requested and used until it is full. The last entry of each M1 block points to the address of the next M1 block to be used. Therefore, the RST queue can grow dynamically. Since the MTX block address is only 26 bits, the RST generator accesses 32 bits of M1 memory at a time. The length of this queue can grow to a size where M1 memory is available. If there is no more memory available for the queue, the RST generator implicitly discards the RST packet request from the RCV state handler. This has a network effect similar to dropping RST packets in transmission. This has no serious impact on performance since there are no connections.

  The output of the RST transmission queue is given to the TCP transmission packet scheduler. When the transmission scheduler indicates to the RST generator that an RST packet has been transmitted, the MTX block used for the RST packet is released. When all entries of the M1 memory block are sent and the link access to the next M1 block is read, the M1 memory block is released. The basic data flow is shown in FIG.

[Receive / Transmit FIFO buffer]
The receive / send FIFO buffer is used to queue SYV / ACK and ACK that the receive state handler has determined that needs to be sent in response to the received packet. The reception status handler passes the following information to the reception / transmission FIFO buffer.
-CB address (16 bits) including socket information
CB type (2 bits; 00 = half open, 01 = open, 10 = Time_Wait),
• Message type to be transmitted (1 bit, 0 = SYN / ACK, 1 = ACK).

  The receive / transmit FIFO buffer entries are 4 bytes long and are stored in various memory buffers. Currently, this buffer is allocated 4K bytes, which provides a 1K entry deep receive and transmit FIFO buffer. The output of the reception / transmission FIFO buffer is supplied to the SYN / ACK generator.

[SYN / ACK generator]
The SYN / ACK generator 212 takes the information output from the receive / transmit FIFO buffer and searches for other appropriate information from the specified CB of half-open, open or Time_Wait, and the desired packet of SYN / ACK or ACK Create The SYN / ACK generator first requests a block from the MTX memory to create a packet. Since SYN / ACK and ACK packets are always 40 bytes long, these packets always fit any size MTX block. The SYN / ACK generator always requests the smallest available block, usually a 128 byte block.

  After the SYN / ACK generator creates a SYN / ACK or ACK packet, the SYN / ACK generator places the starting MTX block address in a 16 deep queue, which then feeds the TCP transmit packet scheduler. To do. If the receive / transmit FIFO buffer passes a programmable high watermark, the transmit packet scheduler is notified of the status and increases the transmit priority of these packets.

[NAT and IP Masquerade]
The NAT and IP masquerade block 206 operates in parallel with the VSOCK module. The NAT and IP masquerade block decodes the incoming packet and sees if it is a pre-specified NAT or IP masquerade port range. If yes, a signaling mechanism is used to indicate to VSOCK that this is a NAT packet. When this occurs, the entire packet is stored as it is in the receive memory buffer. The packet is then forwarded to the host system at several points. The host system driver then performs the routing function and operates to replace the header parameters and send them to the appropriate network interface.

[Exception handler]
The exception handler sends a packet to a host computer that is not processed by the IT10G core.

[Support circuit]
[Rset occurrence]
The rst signal is generated simultaneously from the top level rset signal.

[Tcp_in_rd generation]
tcp_in_rd is used to freeze input data from the IP. This is claimed when a DRAM write request is not immediately approved. It also occurs when the DRAM runs out of small or large memory blocks.

[Word counter]
The word counter, word_cnt [12: 0], is zero at reset and software reset. This is incremented when tcp_in_rd is active and ip_in_eof is not active. Zero in the first word of ip_in_data [63: 0] and 1 in the second word. This will be zero for the first word after ip_in_eof and will remain zero between valid ip_in_data words.

[Memory block control circuit]
[Pending memory block]
The memory block control circuit keeps small and large memory blocks always available. This ensures that there is little delay when data has to be written to the memory block. The memory block control circuit also makes a block request in parallel with the data writing. These pending memory blocks are initialized from reset.

[Initialization and memory block size selection]
TCP or UDP segment parameters are initialized. The size of the memory block to be used is determined by the TCP length information from the IP and the TCP header length information from the parser. If the data size (TCP length-TCP header length) fits into a small memory block, the reserved small memory block is used and another small memory block is requested to replenish the hold. Otherwise, the pending large memory block is used and another large memory block is requested to replenish the pending. If a small memory block is not available, a larger memory block is used. However, if a large memory block is required but not available, a small memory block is not used.

[Write aligned TCP data to memory block]
If there are an odd number of optional halfwords (32 bits wide each) in the TCP header, the data in the TCP packet is aligned and the data starts on a 64-bit boundary. If the TCP packet data is aligned, the TCP packet data can be placed directly into the memory block when the data is sent from the IP block. The address of the second block for the segment is sent to the TCP state machine. Similar to the data left in the TCP segment, the count is maintained in the space left in the block. If the memory block is already full, the record must also be maintained. When the end of a TCP segment is reached, if the previous block is full, that block must be linked to the current block. Also, the link in the current block header is cleared and the data length and the checksum in which the data is operating are written into the block header. The data length is a function of the number of bytes in the last 64-bit word, as determined by the bits in ip_in_bytes_val. If the block runs out before the end of the TCP segment, the data length and the working checksum are written to the block header and a flag is set indicating that the block is finished. The remaining data in the TCP segment is used to determine whether large or small reserved memory blocks are used. If the block size is exhausted, the same rules as described above are used. The address of the last memory block must be sent to the TCP state machine.

[Write unaligned TCP data to memory block]
If the TCP segment data is not aligned (ip_in_data [63: 0] contains data to be written to two different memory blocks) to store the first lo32-bit halfword from the IP block First, there must be an extra cycle so that the data can be written in the memory block as a high 32 bit half word. During the next bus cycle from the IP block, the high 32-bit halfword is written as a low 32-bit halfword in the same cycle as the stored halfword. Count and checksum calculations must also be adjusted to handle this condition. Otherwise, the unsorted data is processed in the same manner as the sorted data and has the same end case as already described.

[Write UDP data to memory block]
Since UDP data is always aligned, UDP data is processed in the same way as TCP aligned data. The same end case applies.

[Checksum calculation]
The checksum is calculated as described in REC1071. In the checksum calculation block, the checksum is calculated only for the data. The parser calculates the header checksum, and the TCP state machine combines the two checksums to determine how to handle packets with checksum errors.

[Analysis of fixed header fields]
[Word counter]
The word counter, word_cnt [12: 0], is zero at reset and software reset. The counter increments when tcp_in_rd is active and ip_in_eof is not active. The counter is zero during the first word of ip_in_data [63: 0] and 1 during the second word. The counter is zero for the first word after ip_in_eof and remains zero between valid ip_in_data words.

[Latch of remote_jp_add [31: 0] and local_ip_indx [3: 0]]
These latches are zero at reset and software reset. remote_jp_add is latched from src_ip_add [31: 0] when src_ip_add_valid, ip_in_dav, tcpportp_packet is asserted. Local_jp_indx is latched from dest_ip_index [3: 0] when dest_ip_add_valid, ip_in_dav, and tcpportp_packet are asserted. Both are valid until reloaded with the next packet.

Note: The field is cleared or initialized (in parentheses) with the first word from reset and IP.
Note: Latches are also qualified by tcp_packet, udp_packet & ip_in_dav.

[Checksum, error check, optional header field analysis]
[Checksum]
The RFC1071 checksum is an IP source address, an IP destination address (not an index), an 8-bit type field preceded by 8-bit zero (= hexadecimal of 0006), a header length field along with a pseudo header including the TCP length. Calculated in the header as specified in.

[Header length check]
Once the rx_tcp_hdr_len field is parsed (word count> 0001), the rx_tcp_hdr_len field is checked. The rx_tcp_hdr_len field cannot be less than 5 or greater than MAX_HDR_LEN set to 10. If so, an error rx_tcp_hdr_len signal is asserted and is in that state until the start of the next packet.

[TCP length check]
The IP payload length from the IP is checked. The IP payload length cannot be smaller than 20 bytes (used when rx_tcp_header_len is not yet valid) and cannot be smaller than rx_tcp_header_len. If so, an error rx_tcp_hdr_len signal is asserted and is in that state until the start of the next packet.

[Optional header field analysis]
The field is cleared on reset and the first word from the IP block. Only the time stamp (10 bytes + padding), MSS (4 bytes), and window scale (3 bytes + padding) are searched. Since an option of only 20 bytes can exist, the header length is only 10 32-bit half words (word count = 0004).

  Options are parsed in a straightforward way. Options start at the second half word count = 2 and are aligned to 32 bits. The first byte of the option identifies the option type.

  If a timestamp option is detected, rx_tcp_timestamp, rx_tcp_tx_echo and rx_tcp_timestamp_val are loaded.

  If the MSS option is detected, rx_tcp_remote_mss and rx_tcp_remote_mss_val are loaded.

  If the window scale option is detected, rx_tcp_remote_win_scl and rx_tcp_rem_win_scl_val are loaded.

  These are valid until the start of the next packet.

[Socket Receive Submodule]
The socket receive submodule handles the interface between the IT 10G and the received data system (host computer). FIG. 23 shows a socket reception data flow.

  The socket receive submodule process starts at the receive logic unit 230 and sets 1 bit in the socket receive DAV bitmap table 231. The socket receive DAV bitmap table has one bit associated with each 64K socket (hence the table is 8K bytes). By knowing the position of CB, the appropriate bit is set.

  The Socket_DAV inquiry module 232 is a block that continuously scans the socket reception DAV bitmap table. When the Socket_DAV query module finds one set bit, it generates a corresponding CB address and checks the CB structure to see if the CB structure contains a valid link_list block. A valid link_list block consists of a 64-bit memory address and a 16-bit length. If the CB has a valid link_list block, the CB address and valid link_list information are passed to the DMA Prep module 233 via a two-stage pipeline register pair. The Socket_DAV module also clears the corresponding bit in CB at that time. If the CB does not contain a valid link_list block, a status message is generated for the socket to notify the host that data is available on the socket but no valid transfer block information exists on the socket. The In this case, the corresponding bit in the bitmap table has not yet been cleared. The CB can also be updated in this case until it knows that it has already sent a status message to the host asking the link_list block. This step is necessary because it does not send multiple status messages for the same CB. If there is a valid link_list block, the next step is to send CB and transfer information to the DMA prep module. The DMA prep module operates to read data from the socket data buffer and transfer the data to one of the two ping-pong transfer FIFO buffers 234 of the DMA engine. When this data transfer ends, the DMA prep module sends a request to the transmit DMA engine 235 that there is data to be transferred. The link_list information is also transferred to the transmit DMA engine.

  When the transmit DMA engine gets a request from the DMA prep module, the transmit DMA engine informs the main DMA engine 236 that it wants to perform a DMA transfer to the host. When the bus is granted, the DMA engine reads data from the ping-pong buffer and sends them to the host computer. When the DMA transfer ends, the CB for the socket is updated and a status message is generated indicating that data is being sent to the host computer.

  The status message generator 237 is a module that operates to generate a status message and write the status message to a status message block in memory (1 Kbyte). The request to generate a status message comes from the sending DMA engine, the socket DAV inquiry module, or the CPU.

[Socket transmission submodule]
The socket transmission submodule handles the interface between IT19G and the system for data transmission. FIG. 24 shows a socket transmission flow.

  The socket transmission flow starts with receipt of a command block list from the host. The command block list is received via DMA transfer and is located in the command list 241. Blocks are extracted from there and analyzed by the command parser module 242. Commands understood by the parser are executed and those not understood are transferred to the on-chip processor.

  If the command transfers data, link_list information along with the CB address is extracted from the command block and placed in the transfer queue 243.

  The receive DMA engine 244 removes this transfer queue entry and executes data transfer from the host computer memory. The data is placed in a pair of ping-pong FIFO buffers 245. The CB address associated with the data just received is transferred to the socket Xmt data control module 246.

  The socket Xmt data control module collects data from the ping-pong FIFO buffer and provides the data to the transmit socket data memory 248. The socket Xmt data control module retrieves the block address from the allocxx memory allocation unit 247. The socket Xmt data control module also queries the socket CB for the socket priority level. When all data has been transferred to the data buffer, the socket Xmt data control module provides a CB address to one of the four priority queues. The socket Xmt data control module also updates socket CB with new data transmission count information.

  When data is transferred from the DMA receive FIFO buffer to the socket data memory, a running checksum is then performed. The checksum is calculated on a block-by-block basis. This helps to reduce transmission latency when the data does not need to be read again later.

[CB LUT]
[Overview]
TCP receive logic uses the LUT to discover open socket connections. The LUT is 128K deep with 18 bits.

[CB LUT and DRAM interface]
This section describes the interface between the miscmem module and the NS DDR arbitration module. This explains the data flow, lists the interface signals, and details the required timing.

[data flow]
The CB LUT provides only a single read / write access to the data DRAM. In the configuration of the present invention, the DRAM is external, but the memory is provided with an on-chip instead. DRAM access is in DWORD. Since each LUT entry is only 18 bits, only the lower 18 bits of DWORD are sent to the CB LUT memory interface.

[TCP transmission submodule]
[Overview]
The TCP transmission submodule operates to determine the next socket to be serviced for data transmission and thus update the socket CB block. The data flow is shown in FIG.

  The TCP transmission data flow starts with a socket query module. The socket query module scans the XMT_DAV bit table looking for entries with valid bit sets of their transmitted data. When the socket query module finds a valid bit set of the set transmit data, the socket query module places the entry in one of four queues according to the socket's Use_Priority level. Sockets with priority level 7 or 6 are located in queue list 3, levels 5 and 4 are located in queue list 2, levels 3 and 2 are located in queue list 1, and levels 1 and 0 are waits Located in matrix list 0.

  These lists are all supplied to the packet scheduler 251. The packet scheduler operates to remove packets from the priority queue in a non-destructive manner. The packet scheduler also arbitrates between outgoing data packets and SYN_ACK and RST packets generated from half-open support modules.

  The packet scheduler transfers this information to the socket send handler 252 when the packet scheduler determines the next packet to be sent. The socket transmission handler module reads the socket CB information, generates a packet header, updates the CB, and transmits the packet transmission information to the transmission queue 253. All packet headers are then generated in separate memory buffers that are pre-pended to the data buffer. This also applies when the data to be transmitted starts in the middle of the data buffer. In this case, the point from the packet header data buffer points to the first byte of data to be transmitted. The locking mechanism is used so that this module does not change the same socket CB that another module can operate at the same time.

  The transmit queue operates to form a queue of packets as it is transmitted to the master transmit arbitrator.

[Packet Scheduler]
The packet scheduler operates to determine the next packet to be sent. A block diagram of this module in one configuration is shown in FIG.

  The packet scheduling process begins with the comparison device 260 taking the queue number in the current state and checking to see if there is anything to be sent in that queue. The queue number can represent either a queue list or a TCP RCV packet. If there is a packet of that type waiting, the entry is retrieved and scheduled as the next packet to be transmitted. If there are no packets in that queue, the status counter is incremented and the status of the next queue is checked. This continues until the queue number matches a queue list (or TCP received packet) with packets ready for transmission, or the last bit of the status entry is set. If the last bit is set, the status counter resets to zero (0).

  The queue arbitration sequence is programmable. The application can set the queue arbitration sequence by first setting the Queue_State register to 0x00 and then writing the queue number and the last bit to the Queue_Entry register. There are two built-in arbitration sequences that can be set by asserting a flat or steep bit in the Queue_State register.

[Flat sequence]
The flat sequence is the default sequence state that the scheduler uses after any reset. The flat sequence is also set to 01 by writing the seq_prog field to the T sequence register. The sequence is shown below.
3-2-3-2-3X-1-3-2-3-X-2-3-1-3-X-2-3-2-3-DX <Repetition>
Here, 3, 2, 1 and 0 are queue lists, respectively, and X is a packet from the TCP receiving logic device. In this scheme, each list has the following bandwidth allocation:

[Steep sequence]
An alternative to a programmed flat sequence is a steep sequence. The steep sequence further weights the high priority queue and is useful when multiple high priority applications are run simultaneously. The steep sequence is set to 10 by writing the seq_prog field in the T sequence register. The steep sequence is as follows.
3-3-2-3-3-2-X-3-3-1-3-3-3-3-X-3-2-2-3-3-1-3-3-X-2-3- 3-2-3-3-0-X
The percentage bandwidth of this sequence is shown below.

  The use of a packet scheduler allows sharing of hardware modules and resources according to received data traffic.

[Hash algorithm]
The hash algorithm used combines the local and peer ports of the socket with the local and peer IP addresses to form a single 17-bit hash value. The hash algorithm is designed to be simple, thereby producing a single clock cycle result, as well as sufficient spread spectrum to minimize hash LUT collisions. The hash equation is shown below.
LP = local port,
PP = peer port,
LI = local IP address,
PIP = peer IP address Hash [16: 0] = {({LP [7: 0], LP [15: 8] ^ PP}, 1′b0) ^ {1′b0, ((LIP [15: 8] ^ LIP [7: 0]) ^ (PIP [15: 8] ^ PIP [7: 0]))};
The following are the steps performed on the hash.
• Local port bytes are swapped.
The new byte swapped local port is XORed with the peer port to form a 16 bit port product.
The MSB of the local IP address is XORed with the local IP address and LSB.
The MSB of the peer IP address is XORed with the LSB of the peer IP address.
• Two IP address products are XORed to form an IP word product.
The port product is shifted left by 1 bit and padded with 0s to form a 17-bit value.
IP word products are accompanied by leading zeros to form a 17-bit product.
The new 17-bit port product and IP word product are XORed to form the final hash value.

  This hash algorithm is shown in FIG.

  The following is an example of a hash algorithm.

LP = 1024,
PP = 0080,
LI = 45. C3. E0.19,
PIP = 23. D2.3F. A1
Port product = 0 × 2410 ^ 0 × 0080 = 0 × 2490
IP product = (0 * 45C3 ^ 0 * E019) ^ (0 * 23D2 ^ 0 * 3FA1) = 0 * A5DA ^ 0 * 1C73 = 0 * B9A9
Final hash = {0 × 2490,0} ^ {0,0 × 79A9} = 0 × 04920 ^ 0 × 0B9A9 = 0 × 0F089
In a half-open control block LUT, a 12-bit hash is used. This 12-bit hash value is obtained from the above equation as follows.
Hash 12 [11: 0] = hash 17 [16: 5] ^ hash 17 [11: 0]
Here, the hash 17 is an expression defined earlier.

[ISN algorithm]
[Theory of operation]
The ISN algorithm used in IT10G is similar to the algorithm described in RFC 1948, with a 4 microsecond-based timer, a random boot value configurable by the host system, and four socket parameters (port and IP address). is doing. The function has the following form.
ISN = timer + F (boot_value, src_jp, dest_ip, src_port, dest_port)
Here, the timer is a 32-bit up counter based on 4 microseconds. The F () function is based on the function FC () and is defined as follows.
FC (hv32, data32) = [(prev32 << B) ^ (prev32 >> 7)] ^ data32
Initially, the value of hv32 is set to a random boot_value from the system (host computer). Then, for each requested ISN, hv32 is calculated as follows:
hv32 = FC (prev32, src_ip)
hv32 = FC (prev32, dest_ip) v
hv32 = FC (prev32, {src_port, dest_port})
A block diagram of the entire algorithm is shown in FIG.

  The current architecture takes 4 clock cycles to calculate the ISN. In the first cycle, the source IP address (src_ip) is fed through to generate hv32. In the second clock cycle, the destination IP address is fed through, and in the third clock cycle, the port information is fed through. The fourth clock cycle is used to add an incrementing timer value to the final function value. Note also that registers A and B are not clocked in the fourth clock cycle.

[Test mode]
The ISN test mode is provided as one method for setting the ISN to a predetermined number for diagnostic purposes. This test mode is used as follows.
Write 0x00 to 0x1A06 (TCP TX read index register),
Write ISN bits [7: 0] to 0x1A07,
Write 0x01 to 0x1A06,
Write ISN bits [15: 8] to 0x1A07,
Write 0x02 to 0x1A06,
Write ISN bits [23:16] to 0x1A07,
Write 0x03 to 0x1A06,
Write ISN bits [31:24] to 0x1A07,
Write 0x04 to 0x1A06,
Write an arbitrary value to 0x1A07 (enable test mode).

  The write in step # 10 described above enables the ISN test mode. The currently specified ISN is used the next time an ISN is requested. In order to clear the test mode, 0x05 is written to 0x1A06 and an arbitrary value is written to 0x1A07.

[Socket control block structure]
[Overview]
A socket control block or CB contains operational information for each socket and resides in the CB memory space. The CB contains all status information, memory pointers, configuration settings, and timer settings for the socket. These parameters can be updated by various TCP submodules. The locking mechanism ensures that only one submodule can change socket CB at a time. IT10G uses different CB structures for sockets that are half open, set, and closed.

[Key TCP / UDP CB structure of configured socket]
The following table lists all the fields in the main TCP / UDP CB structure of the configured socket memory. There is also an accompanying TCP CB structure defined below.

[Key CB field specification of the set socket]
[Remote IP address (address 0x00, 32 bits)]
This 32-bit field represents the remote IP address for connection. For client sockets, this field is set by the application. For server sockets, this field is filled with the IP address received in the SYN packet or the IP address of the received UDP packet.

[Remote port (address 0x01 [31:16], 16 bits)]
This field represents the remote port number for the connection. For client sockets, this field is always specified by the application. For server sockets, this field is always filled with the port number received in the SYN or UDP packet.

[Local port (address 0x01 [15: 0], 16 bits)]
This field represents the local port number for connection. For client sockets, this field is specified by the application or automatically generated by the network stack. For server sockets, this field is always specified by the application.

[IP index (address 0x02 [31:28], 4 bits)]
This field represents an index of the network stack IP address table of the IP address of the host interface for the socket and is filled with the network stack hardware.

[ConnState (address 0x02 [27:24], 4 bits)]
This field indicates the current state of the connection and is decoded as follows:

[AX (address 0x02 [23], 1 bit)]
This bit indicates that the received ACK status message mode is enabled. In this mode, a status message is generated when an ACK is received that acknowledges all outstanding data. This mode is used with the Nagle algorithm.

[SA (address 0x02 [22], 1 bit)]
This bit indicates that a selective ACK option (SACK) should be used with this socket (0 = do not use SACK, 1 = use SACK).

[TS (address 0x02 [21], 1 bit)]
This bit indicates that the timestamp option should be used by this socket (0 = do not use the timestamp option, 1 = use the timestamp option).

[WS (address 0x02 [20], 1 bit)]
This flag indicates that the sliding window option is properly negotiated for the TCP socket (0 = WS option should not be used, 1 = WS option will be enabled). This bit is not used for UDP sockets.

[ZW (address 0x02 [19], 1 bit)]
This bit indicates that the socket's peer window is 0x0000 and the socket is in a zero window probe state.

[AR (address 0x02 [18], 1 bit)]
This bit is set when an ACK packet is sent on a particular socket. This is cleared when an ACK packet is sent.

[CF (address 0x02 [17], 1 bit)]
This bit indicates that the current CB is in the receive / transmit FIFO buffer queue and therefore cannot be decremented. Once the ACK for the socket is transmitted, the TCP transmission block moves from Open CB to Time_Wait CB.

[CV (address 0x02 [16], 1 bit)]
This bit indicates that the CB contains valid information. This bit is always cleared before any CB decrements.

[RD (address 0x02 [15], 1 bit)]
This bit indicates that the CB retransmission time has expired but cannot be queued for retransmission because the priority queue is full. When the CB polar finds this bit claimed in the CB, it ignores the retransmission time field and processes the CB for retransmission. This bit is cleared when the CB enters the priority transmission queue.

[CBVer (address 0x02 [14:12], 3 bits)]
These bits indicate the CB version and are mainly used by the on-chip processor, thereby distinguishing the CB type of future hardware versions. This field is currently defined as 0x1.

[CB interface (address 0x02 [11: 8], 4 bits)]
These bits are used to identify the specific physical interface of the socket and are used in multiport architectures. In a single port architecture, this field should be left at 0x0.

[SY (address 0x02 [7], 1 bit)]
These bits indicate that the socket has received a SYN packet while in the TW state. If this bit is set and then a RST is received on the socket and kill_tw_mode is set to 0x00, the CB is immediately ignored.

[ST (address 0x02 [6], 1 bit)]
This bit indicates that the left and right SACK fields of TX are valid. When the TCP receiving logic unit notices a hole in the received data, the TCP receiving logic unit positions the start and end addresses of the hole in the left and right SACK fields of the TX, and the next transmitted packet contains a SACK option. Set this bit to indicate that it should. This bit is cleared when a packet containing these parameters is sent.

[SR (address 0x02 [5], 1 bit)]
This bit indicates that the left and right SACK fields of RX are valid. When the TCP receiving logic unit receives the SACK option, the TCP receiving logic unit positions the first pair of SACK values in the left and right SACK fields of the RX and indicates that this section needs to be retransmitted. Set this bit to indicate to the machine. This bit is cleared when the section is retransmitted.

[KA (address 0x02 [4], 1 bit)]
For TCP sockets, this bit indicates that a keepalive timer should be used for this socket (0 = do not use keepalive timer, 1 = use keepalive timer). For UDP sockets, this bit indicates whether the checksum should be checked (1 = enable checksum, 0 = ignore checksum).

[DF (address 0x02 [3], 1 bit)]
This bit represents the state of the DF bit of the IP header for the socket. When this bit is set, the packet is not fragmented by any hops. This bit is used for path MTU discovery.

[VL (address 0x02 [2], 1 bit)]
This bit indicates whether it is included in the Ethernet (registered trademark) frame output by the VLAN tag. If this bit is asserted, the 4 bytes of VLAN tag information are created by cb_tx_vian_priority and cb_tx_vid, and the VLAN tag identification (fixed value) is included in the subsequent Ethernet address field.

[RE (address 0 × 02 [1], 1 bit, TCP CB)]
This flag is used to indicate a timeout condition and that a retransmission is required. Cleared when data is retransmitted. This bit is specified only for TCP CB.

[UP (address 0x02 [1], 1 bit, UDP CB)]
This flag is used to indicate whether the UDP port is dynamically assigned or pre-specified. If dynamically allocated, it will be deallocated when the CB is replicated. Otherwise, if specified in advance, no port action is taken when the CB is replicated. This bit is specified only for UDP CB.

[AD (address 0x02 [0], 1 bit)]
This bit indicates that an ACK is queued for a delayed ACK transmission on the socket. This bit is set in the TCP RX logic unit and is cleared when the ACK is queued by the CB poller for transmission.

[TX ACK number (address 0x03, 32 bits)]
This is an operation ACK number for TCP connection. This represents the predicted SEQ number of the received TCP PSH packet. When a TCP data packet is received, the SYN number is checked against this number. If there is a match or the received SEQ number plus the length of the packet covers this number, the data is accepted. This number is automatically updated by the network stack and is not used for UDP connections.

[SEQ number (address 0x4, 32 bits)]
This is the operation SEQ number of the TCP connection. This represents the SEQ number used in the TCP packet and is automatically updated by the network stack. This field is not used for UDP connections.

[Keep-alive time 0x05 [31:24], 8 bits]
This field represents the future time when the keep-alive trigger is asserted. This time is reset every time a packet is sent on the socket or every time a pure ACK packet is received. The time is expressed here in minutes.

[LWin scale (address 0x05 [23:20], 4 bits)]
This field represents the local sliding window scale factor used for the connection. Valid values are from 0x00 to 0x0E.

[RWin scale (address 0x05 [19:16], 4 bits)]
This field represents the sliding window scale factor when requested by the remote end in the TCP SYN packet. Valid values are from 0x00 to 0x0E.

[Remote MSS (Address 0x05 [15: 0], 16 bits)]
This field represents the MSS received in the SYN packet for TCP connection. This indicates the maximum packet size that can be received by the remote end. If no MSS option is received, this field defaults to 536 (0x0218). This field is not used for UDP connections.

[PA (address 0x06 [31], 1 bit)]
This bit is used to indicate that the CB port has been automatically assigned. If this bit is set, when it is time to replicate the CB, this bit is checked whether the port needs to be deallocated.

[Priority (address 0x06 [30:28], 3 bits)]
This field represents the priority level of the user used for the VLAN tag. This field also represents the service level of the socket in the transmission schedule. The higher the number, the higher the priority (7 is the highest and 0 is the lowest). The default value for this field is 0x0 and can be set by software.

[VID (address 0x06 [27:16], 12 bits)]
This field represents the VLAG identification used in the VLAG tag frame. The default value for this field is 0x000 and can be set by software. For connections initiated from the peer, this field is set by the VID received in the opening SYN packet.

[Remote MAC address (Address 0x06 [15: 0] -0x07, 48 bits in total)]
This field represents the destination MAC address of the packet being transmitted on this socket. When a socket is first set up, the ARP cache is queried with this address. After this is resolved, the address is stored here and further ARP cache queries are avoided. If the CB is created as a server socket, this address is taken from the destination MAC address contained in the SYN socket. Address bits [47:32] are stored in CB address 0 × 6.

[Local IP address (address 0x08, 32 bits)]
This field represents the local IP address for the socket connection. For client sockets, this field is specified by the application. For server sockets, this field is filled when the CB is transitioned from half-open to open.

[RX ACK number (address 0x09, 32 bits)]
This field represents the most recent ACK number received from the peer for this socket. This is used to determine if any retries are needed on the socket. Note that this is a different number than the sequence number used in the transmitted packet.

[Congestion window (cwnd) (address 0x0A [31: 0], 32 bits)]
This field tracks the cwnd parameter. The cwnd parameter is used in the congestion avoidance and slow start algorithm and is initialized to 1MSS.

[HA (Host ACK) (Address 0x0B [31], 1 bit)]
This bit indicates that Host_ACK mode is active on this socket. In this mode, the data ACK is triggered by the host and is not automatically transmitted when data is received.

[SS (RX DAV state to be transmitted) (address 0x0B [30], 1 bit)]
This bit indicates that an RX DAV status message for CB has been sent to the on-chip processor. The bit clears when data is DMAed to the host.

[Socket type (address 0x0B [29:27], 3 bits)]
This field indicates the type of socket represented by the control block according to the following table.

  All other decryptions not shown are reserved for future use. In UDP raw mode, the application is given a remote IP address and UDP header information along with UDP data. In the normal mode of UDP, only the data part is given to the application.

[MI (address 0x0B [26], 1 bit)]
This bit is used to indicate that data is not currently present in the socket receive memory block.

[RX end memory block pointer (address 0x0B [25: 0], 26 bits)]
This field represents the address of the last MRX buffer in which received data has been written. This is used to link the next memory block used for the socket.

[RX start memory block pointer (address 0x0C [25: 0], 26 bits)]
This field represents the address of the next MRX buffer sent to the host.

[HD (address 0x0C [26], 1 bit)]
This bit indicates that there is data left to be DMAed to the host and no RX DMA status message has been sent yet. The TCP RX logical unit sets this bit when scheduling an RX DMA operation and is cleared by the TCP RX logical unit when requesting an RX DMA done status message. This bit is used to facilitate the FIN vs. status message timing issue.

[ISPEC mode (address 0x0C [30:27], 4 bits)]
These bits indicate the IPSEC mode enabled for packets sent on this socket connection. Decoding is shown in the table below.

  If no bit is set, there is no IPSEC used on the socket.

[AB (ACK Req Pending) (Address 0x0C [31], 1 bit)]
This bit indicates that an ACK request from the TCP receiving logic device to the TCP sending logic device is pending. It is set when a TCP data packet is received and cleared when a data ACK is sent. If another data packet is received while this bit is still set, another ACK is not requested and the number of received ACKs is updated.

[HR (host retransmission socket) (address 0x0D [30], 1 bit)]
This bit indicates that this socket is an iSCSI application.

[AS (address 0x0D [30], 1 bit)]
This bit indicates that this socket is an on-chip processor socket application.

[DA (address 0x0D [29], 1 bit)]
This bit indicates that retransmission was performed due to a duplicate ACK. This is set when a retransmitted packet is transmitted. Cleared when acquiring an ACK that advances the received ACK pointer. Set cwnd = ssthresh (part of high speed recovery algorithm) when ACK for new data is obtained after duplicate ACK retransmission. This bit is used with the DS bit in word 0x14. The retransmission of the lost segment is done only once and requires two bits.

[R0 (address 0x0D [28], 1 bit)]
This bit indicates that the retransmission time field is valid (0 = invalid, 1 = valid).

[RV (address 0x0D [27], 1 bit)]
This bit indicates that the retransmission time field is valid (0 = invalid, 1 = valid).

[TP (address 0x0D [26], 1 bit)]
This bit indicates that a timed packet is currently in progress. Used only if the RTO option is not enabled.

[Next TX memory block pointer (address 0x0D [25: 0], 26 bits)]
This field represents the address of the next MTX buffer to be transmitted.

[MSS_S (2 bits, word 0 × 0E [31:30])]
These bits are used to specify the MSS size used in the SYN packet. The valid settings are shown below.

[Series window size (address 0x0E [29: 0], 30 bits)]
This field represents the operating window size as tracked by the TCP RX hardware. This window maintains the actual window size and is transferred to the actual window only when it is larger than the MSS.

[RX DMA count (address 0x0F [31:16], address 0x12 [31:24] 24 bits)]
This field represents the number of bytes sent to the host via RX DMA for the last RX DMA status message transition. The MSB of the count is stored at address 0x12.

[Host buffer offset pointer (address 0x0F [15: 0], 16 bits)]
This field represents the offset into the current host memory buffer where RX DMA is used.

[Window clamp (address 0x10 [31: 0], 32 bits)]
This field represents the largest advertised window enabled on the socket connection.

[RX link list address (address 0x11 [31: 0], 32 bits)]
This is the on-chip processor memory address of the RX link list used for RX DMA operations.

[RX transmission limit (address 0x12 [15: 0], 16 bits)]
This is the transfer limit for RX DMA transfers. An RX DMA status message is generated when this limit is reached. For CBs that require a status message after each DMA transfer, this limit should be set to 0x0001.

[RX link list entry (address 0x12 [23:16], 8 bits)]
This is the number of entries in the RX DMA link list.

[K (keep-alive triggered) (address 0x13 [31], 1 bit)]
This bit is used to indicate that the current CB is in a keep alive state. This bit is set when the keep alive timer expires on the CB, when the CB is deallocated because the keep alive discovers that the other side has disappeared (has disappeared), or a keep alive probe (ACK packet) Cleared by TCP-RX when a response to is received.

[DupAck (address 0x13 [30:28], 3 bits)]
This field tracks how many duplicate ACKs have been received. This parameter is used for fast retransmission algorithms.

[Retry / Probe (Address 0x13 [27:24], 4 bits)]
This field tracks the number of retries sent for a particular packet. This is also used to keep track of the number of window probes transmitted. The latter number is required so that an appropriate window probe transmission interval can be used.

[Available TX data (address 0x13 [23: 0], 24 bits)]
This field represents the total amount of data available to be sent on the socket.

[Socket channel number (address 0x14 [31:24], 8 bits)]
This is the socket channel number. When a status message is sent back to the host, this channel specifies the queue to be used.

[SX (address 0x14 [23], 1 bit)]
This bit indicates that SACK retransmission is required. This is set and cleared by the retransmission module when a SACK retransmission is sent.

[FX (address 0x14 [23], 1 bit)]
This bit indicates that a FIN packet is being sent out on this socket. This is set by the TCP TX logic unit.

[DA (address 0x14 [19], 1 bit)]
This bit indicates that the socket is in a duplicate ACK state. This bit is set when the duplicate ACK threshold is reached. Cleared when peer ACK is new data.

[UM (address 0x14 [18], 1 bit)]
This bit indicates that the advertised window of the peer has exceeded twice the MSS. If this bit is set, the data is stored in MTX at the maximum MSS size. If the bit is not set, the data is stored with a maximum of one quarter of the MSS.

[UC (address 0x14 [17], 1 bit)]
This bit indicates that the control block type of the next CB link field is UDP CB.

[TW (address 0x14 [16], 1 bit)]
This bit indicates that the control block type of the next CB link field is TW CB.

[Next CB link (address 0x14 [15: 0], 16 bits)]
This field represents the CB memory address of the next linked CB. This CB has the same hash value as this socket. The VSOCK submodule fills this field when it concatenates CB to the same hash value.

[RX window size (address 0x15 [31:16], 16 bits)]
This field represents the advertised window at the remote end that is not adjusted by the sliding window scale factor.

[IP TTL (address 0x15 [15: 8], 8 bits)]
This field represents the TTL used in the socket IP header.

[IP TOS (address 0x15 [7: 0], 8 bits)]
This field represents the TOS field setting used in the IP header for socket connection. This is an optional parameter that can be set by the application. If no TOS parameter is specified, this field defaults to 0x00.

[RX timestamp / time-determined sequence number (address 0x16, 32 bits)]
When timing one segment at a time, this field is used to store the sequence number of the timed packet. When an ACK covering this sequence number is received, the RTT can be obtained for that packet. The time stamp when this packet was transmitted is stored in the local time stamp of the last transmission field. When the timestamp option is enabled, this field is used to store the timestamp received in the TCP packet.

[Smooth average derivation (address 0x17, 32 bits)]
This field represents the smoothed average derivation of the round trip time measurement as calculated using the Fan Jacobson algorithm specified in RFC793.

[Slow start threshold (ssthresh) (address 0 × 18, 32 bits)]
This field tracks the ssthresh parameter. The ssthresh parameter is used for the congestion avoidance algorithm and is initialized to 0x0000FFFF.

[Smooth RTT (address 0x19, 32 bits)]
This field represents a smoothed round trip time value as calculated using the Fan Jacobson algorithm specified in RFC793.

[Retransmission time stamp (address 0x1B, 16 bits)]
This field is used to represent future times when retransmissions are required on the socket.

[TX left SACK (address 0x1C, 32 bits)]
This field represents the sequence number (lowest sequence number) of the first byte of the first island of the out-of-sequence data received after the in-sequence data.

[TX right SACK (address 0x1D, 32 bits)]
This field represents the number obtained by adding 1 to the sequence number (highest sequence number) of the last byte of the first island of the out-of-sequence data received after the in-sequence data.

[RX left SACK (address 0x1E, 32 bits)]
This field represents the sequence number of the first byte of the first island of out-of-sequence data reported by the SACK option of the received packet.

[RX right SACK (address 0x1F, 32 bits)]
This field represents the number of the sequence number of the last byte of the first island of out-of-sequence data reported by the SACK option of the received packet plus one.

[Set socket attached CB structure]
The following table lists all the fields of the attached CB structure of the configured socket memory.

[Socket attached CB field definition]
[RX left SACK memory address (address 0x0 [23: 0], 24 bits)]
This field represents the first address of the first MRX memory block in the linked list of blocks in the SACK island.

[RX right SACK memory address (address 0 × 1 [23: 0], 24 bits)]
This field represents the first address of the last MRX memory block in the linked list of blocks in the SACK island.

[SACK block count (address 0x0-0x1 [31:24], 16 bits)]
This field represents the number of memory blocks used by the socket.

[RX RX written (address 0x2-0x3, 64 bits)]
This field represents the total number of bytes written to the socket's MRS memory. The least significant digit word is stored at address 0x2, and the most significant digit word is stored at address 0x3.

[TX byte transmitted (address 0x4-0x5, 64 bits)]
This field represents the total number of bytes sent on the socket. The least significant digit word is stored at address 0x4 and the most significant digit word is stored at address 0x5.

[IS (address 0 × 6 [31], 1 bit)]
This bit indicates that CB is used as an iCSI socket.

[MD (address 0x6 [30], 1 bit)]
This bit indicates that CB is using MDL for the received buffer list.

[DS (address 0x6 [29], 1 bit)]
This bit indicates that a duplicate ACK has been received at the socket. This is set by the logic unit that handles duplicate ACKs. If a duplicate ACK is received and this bit is already set, the lost segment is not retransmitted. This is used with the DA bit of the word 0x0D in the main open CB structure. The state table for these two bits is shown below.

[Non-updated iSCSI seed (IN) (address 0x6 [28], 1 bit)]
This bit is set by the davscan module when an iSCSI memory block is processed and cleared when the seed for that block is saved. A bit is asserted to indicate to the host that the local copy of the CRC seed has not been updated by the hardware. When the host wants to reset the CRC seed, this bit needs to be probed first. If the bit is asserted, it is necessary to set the Seed_Clrd_by_Host bit on the socket. The hardware clears this bit when updating the local copy of the CRC seed with a new value written by the host.

[(CH) iSCSI seed cleared by host (address 0x6 [27], 1 bit)]
This bit is set by the host when writing a new value into the CB iSCSI seed of CB AND, and the IN bit is set. When the davscan module observes that this bit is set, it clears this bit in the iSCSI seed and CB.

[MDL transfer length (address 0x6 [15: 0], 16 bits)]
This field is used to indicate how long an MDL DMA transfer should be. Usually the same length as reported in the RX_DAV status message that generated the RX_MDL IB.

[IPSEC hash (address 0x7 [31: 0], 31 bits)]
This field represents the hash value of all SA entries used in the socket connection.

[Last unapproved sequence number (address 0x8, 32 bits)]
This field represents the last unapproved sequence number from the peer. This relative is used in the timestamp to store the calculation.

[ISCSI FIM interval (address 0x9 [31:16], 16 bits)]
This field represents the FIM interval for iSCSI connection. This is stored as a number of bytes.

[ISCSI FIM offset (address 0x9 [15: 0], 16 bits)]
This field represents the number of bytes until the next FIM insertion.

[ISCSI CRC seed (address 0xA, 32 bits)]
This field represents the CRC seed of the received iSCSI data.

[IPSEC overhead (address 0xB [7: 0], 8 bits)]
This field represents the overhead related to the double word count (4 bytes) occupied by one packet by the IPSEC header (and excessive IP header). This information is used when determining the amount of data that can be placed in the packet.

[ISCSI FIM Enable [FE] (Address 0xB [8], 1 bit)]
This bit indicates whether FIM support is required in the CB (0 = FM disabled, 1 = FIM enabled).

[MRX buffer (address 0 × B [31:16], 16 bits)]
This field represents the number of MRX buffers currently used by the socket. When this number reaches the MRX buffer limit (general setting), no more data packets are accepted on the socket.

[DAV buffer length (address 0xC [15: 0], 16 bits)]
This field indicates the buffer length used for DAV status messages.

[RX transmission FIN status message [SM] (address 0 × C [16], 1 bit)]
This bit indicates that an RX FIN receive status message should be sent on the CB.

[RX transmission DAV status message [SV] (address 0 × C [17], 1 bit)]
This bit indicates that an RX DAV status message should be sent to the CB.

[RX DMA status message pending [DP] (address 0xC [18], 1 bit)]
This bit indicates that a status message made by RX DMA is pending in CB.

[Last DMA [LD] (Address 0xC [19], 1 bit)]
This bit indicates that the last DMA of the host buffer segment is being transmitted. Upon completion of this DMA, an RX DMA status message is generated.

[FIN status message pending [FP] (address 0xC [20], 1 bit)]
This bit indicates that the FIN status message is pending. This is set when data remains in the MRX memory but no DMA is currently in progress. This is cleared when the DMA starts and the SV bit is set.

[Reset Pending [RP] (Address 0xC [21], 1 bit)]
This bit indicates that the reset status message is pending and should be sent after the RX DMA status message. This is set when data remains in the MRX memory but no DMA is currently in progress. This is cleared when the DMA starts and the SV bit is set.

[Transmission reset message [RM] (address 0 × C [22], 1 bit)]
This bit is only used between the tcprxsta and davscan modules when an RST packet is received.

[Open to TW [OT] (Address 0xC [23], 1 bit)]
This bit indicates that the socket has transitioned to the wait time state and has opened to the wait time transfer process. This bit is set by davscan, rxcbupd. read by v.

[Zero window time stamp (address 0xC [31:24], 16 bits)]
This field indicates a future time stamp for sending the next zero window probe.

[TX tunnel AH handle (address 0xD [15: 0], 16 bits)]
This field represents the TX tunnel AH SA (security related) handle associated with the socket.

[TX tunnel ESP handle (address 0xD [31:16], 16 bits)]
This field represents the TX tunnel AH ESP SA (security related) associated with the socket.

[TX transfer AH handle (address 0xE [15: 0], 16 bits)]
This field represents the TX transfer AH SA (security related) handle associated with the socket.

[TX transfer ESP handle (address 0 × E [31:16], 16 bits)]
This field represents the TX transfer ESP SA (security related) associated with the socket.

[ISCSI bytes 0-1-2 (address 0xF [23: 0], 8 bits each)]
These bytes represent unaligned bytes of the iSCSI CRC calculation.

[SBVal (address 0 × F [25:24], 2 bits)]
This field is used to indicate a valid iSCSI byte [2: 0].

[Max RX window (address 0x10 [15: 0], 16 bits)]
This field represents the largest window advertised by the peer. This is used to determine the parameters used in the MTX data packing limit.

[Local MSS (Address 0x10 [31:16], 16 bits)]
This field represents the local MSS value used in the SYN or SYN / ACK packet. This is used to adjust the window size.

[Last CWND update (address 0x11 [31:16], 16 bits)]
This field represents the last timestamp that cwnd was updated, and this information is used to increase cwnd when it is greater than ssthresh.

[DMA ID (address 0x12 [3: 0], 4 bits)]
This field represents the DMA ID for the CB. This field is incremented each time TCP TX DMA is requested. When the xmtcbwr module finishes packing the DMA transfer, the DMA_Pending bit is cleared (by xmtcbwr) if the MDA ID matches that in CB.

[DMA pending (address 0x12 [4], 1 bit)]
This field indicates that TX DMA is pending on this socket. This bit is set by sockregs when requesting TX DMA, and when the TX DMA ID exactly matches CB's TX_DMA, xmtcbwr. Cleared by v.

[Combined CB structure]
In the CB memory, the socket CB is stored as one continuous memory block. The format is shown in the following table.

[Main CB structure of half-open socket]
The following table defines the main CB structure of half-open socket memory.

[Definition of the main CB field of a half-open socket]
[Remote IP address (32 bits, word 0x0 [31: 0])]
This is the IP address of the remote end of the connection. Bits [31:16] of the IP address are stored in word 0x0 and bits [15: 0] are stored in word 0x1.

[Remote port (16 bits, word 0x0 [47:32])]
This is the port address at the remote end of the connection.

[Local port (16 bits, word 0x0 [63:48])]
This is the port address at the local end of the connection.

[Local IP index (4 bits, word 0 × 1 [15:12])]
This is an index of the local IP address used for this connection. This value is resolved by the IP module into a complete IP address and corresponding MAC address.

[Connection status (4 bits, word 0 × 1 [11: 8])]
This is the current state of the connection and is decoded as follows:

[RxACK (1 bit, word 0 × 1 [7])]
This bit indicates that RX ACK status message mode is enabled. In this mode, a status message is generated when an ACK is received that acknowledges all outstanding data.

[SACK (1 bit, word 0 × 1 [6])]
This bit indicates that the remote end has sent a SACK option in its SYN packet.

[RxTS (1 bit, word 0 × 1 [5])]
This bit indicates that the remote end has sent a time stamp option and the received time stamp field is valid in an attachment control block that is half open.

[WinSc (1 bit, word 0 × 1 [4])]
This bit indicates that the remote end has sent a window scale option.

[RxMSS (1 bit, word 0 × 1 [3])]
This bit indicates that the remote end has sent an MSS option and the remote MSS field is valid.

[ACKRq (1 bit, word 0 × 1 [2])]
This bit indicates that an ACK is requested for this socket. This means that similar bits are duplicated in the configuration control block but are not used here.

[CBinFF (1 bit, word 0 × 1 [1])]
This bit indicates that this CB cannot be cleared yet because it is in the Rx to TX FF queue.

[CBVal (1 bit, word 0 × 1 [0])]
This bit indicates that a half-open CB is valid.

[CB version (4 bits, word 0x1 [31:28])]
These bits indicate the CB version. This field is currently defined as 0x1.

[TX interface (4 bits, word 0x1 [27:24])]
These bits indicate the interface from which the outgoing SYN is coming.

[IPSEC (1 bit, word 0 × 1 [23])]
This bit indicates that HO CB is used in an IPSEC protected packet. In this case, the received SYN that does not match this HO CB is discarded.

[MSS size (2 bits, word 0 × 1 [22:21])]
These bits are used to specify the MSS size used in the SYN / ACK packet. The valid settings are shown below.

[KA (1 bit, word 0 × 1 [20])]
This bit indicates that the keepalive timer should be used on this socket.

[DF (1 bit, word 0 × 1 [19])]
This bit is used to identify bits that should not be fragmented in the IP header.

[VLANV (1 bit, word 0 × 1 [18])]
This bit indicates that the VLAN field is valid.

[Retransmission (1 bit, word 0x1 [17])]
This bit indicates that a retransmission is required on this socket.

[RxURG (1 bit, word 0 × 1 [16])]
This bit indicates that the URG bit is set in the received packet.

[ACK (32 bits, word 0 × 1 [63:32])]
This is the number of ACKs used in the transmitted packet.

[SEQ (32 bits, word 0 × 2 [31: 0])]
This is the operation sequence number used in the transmitted packet.

[SA overhead (8 bits, word 0x2 [47:40])]
This field is used to store the IPSEC overhead of the CB (in double word number).

[Local WinScale (4 bits, word 0 × 2 [39:36])]
This field represents the local sliding window scale factor used for the connection. Valid values are 0x00 to 0x0E.

[Remote WinScale (4 bits, word 0x2 [35:32])]
This field represents the sliding window scale factor as requested by the remote end of the TCP SYN packet. Valid values are 0x00 to 0x0E.

[Remote MSS (16 bits, word 0x2 [63:48])]
This field represents the MSS received in the SYN packet for the TCP connection. This indicates the maximum packet size that the remote end can accept. If no MSS option is received, this field defaults to 536 (0x0218). This field is not used for UDP connections.

[VLAN priority (3 bits, word 0 × 3 [14:12])]
This field represents the user priority level used for the VLAN tag. It also represents the service level for the socket in the transmission schedule. The higher the number, the higher the priority (7 is the highest and 0 is the lowest). The default value for this field is 0x0 and can be set by software.

[VLAN VID (12 bits, word 0x3 [11: 0])]
This field represents the VLAN identification used in the VLAN tag frame. The default value of this field is 0x000 and can be set by software. For connections initiated from the peer, this field is set by the VID received in the opening SYN packet.

[Remote MAC address (48 bits, word 0x3 [63:16])]
These fields represent the destination MAC address for the packet being sent on this socket. When the socket is first set up, the ARP cache is queried for this address. After being resolved, the address is stored here, thereby preventing further ARP cache queries. If the CB is generated as a server socket, this address is taken from the destination MAC address contained in the SYN packet.

[Received timestamp (32 bits, word 0x4 [31: 0])]
This is a time stamp included in the received packet.

[Local time stamp (32 bits, word 0x4 [63:32])]
This is the timestamp of the last packet sent for this socket.

[TTL (8 bits, word 0 × 5 [15: 8])]
This is the TTL used for the connection. When SYN / ACK is generated, this parameter is provided by the IP router and stored in this location. When the socket transitions to the configured state, this information is passed to the open control block.

[TOS (8 bits, word 0 × 5 [7: 0])]
This is the TTL used for the connection. When SYN / ACK is being generated, this parameter is provided by the IP router and stored at this location. When the socket transitions to the configured state, this information is passed to the open control block.

[SYN / ACK retry count (4 bits, word 0 × 5 [19:16])]
This field tracks the number of SYN / ACK retries sent for a particular socket. If the number of retries reaches the programmed maximum value, the socket is replicated.

[IPSEC mode (4 bits, word 0x5 [31:28])]
This field is used to indicate an active IPSEC mode for the socket. Decoding of this field is shown below.

[Local IP address (32 bits, word 0x5 [63:32])]
This field is used to store the destination IP address received in the SYN packet. This represents the local IP address for socket connection.

[TX tunnel AH SA handle (16 bits, word 0x6 [15: 0])]
This field is used to store the TX tunnel AH SA handle (if applicable) for the CB.

[TX tunnel ESP SA handle (16 bits, word 0x6 [31:16])]
This field is used to store the TX tunnel ESP SA handle for the CB (if applicable).

[SA hash (31 bits, word 0 × 6 [63:32])]
This field is used to store the SA hash for the CB.

[TX transfer AH SA handle (16 bits, word 0x7 [15: 0])]
This field is used to store the TX forwarding AH SA handle (if applicable) for the CB.

[TX transfer ESP SA handle (16 bits, word 0x7 [31:16])]
This field is used to store the TX transfer ESP SA handle for the CB (if applicable).

[Local MSS (16 bits, word 0x7 [47:32])]
This field is used to store the local MSS value used in the connection. This is required to adjust the window size to avoid the serial window syndrome.

[Standby time CB structure]
The following table defines the CB structure of the memory of the socket in the Time_Wait state.

[Standby time CB field definition]
[Remote IP address (address 0x00, 32 bits)]
This 32-bit field represents the remote IP address for connection. For client sockets, this field is set by the application. For server sockets, this field is filled with the IP address received in the SYN packet or the IP address of the received UDP packet.

[Remote port (address 0x01 [31:16], 16 bits)]
This field represents the remote port number for the connection. For client sockets, this field is always specified by the application. For server sockets, this field is filled with the port number received in the SYN or UDP packet.

[Local port (address 0x01 [15: 0], 16 bits)]
This field represents the local port number for connection. For client sockets, this field is specified by the application or automatically generated by the network stack. For server sockets, this field is always specified by the application.

[IP index (address 0x02 [31:28], 4 bits)]
This field represents the network stack IP address table index of the IP address at the socket host interface and is filled by the network stack hardware.

[ConnState (address 0x02 [27:24], 4 bits)]
This field indicates the current connection state and is decoded as follows.

[RX (address 0x02 [23], 1 bit)]
This bit indicates that RX ACK status message mode is enabled. This mode has no meaning for TW CB.

[SA (address 0x02 [22], 1 bit)]
This bit indicates that a selective ACK option (SACK) should be used on this socket (0 = do not use SACK, 1 = use SACK).

[TS (address 0x02 [21], 1 bit)]
This bit indicates that a timestamp option should be used on this socket (0 = do not use timestamp option, 1 = use timestamp option).

[WS (address 0x02 [20], 1 bit)]
This flag indicates that the sliding window option is negotiating properly for the TCP socket (0 = do not use WS option, 1 = enable WS option). This bit is not used for UDP sockets.

[MS (address 0x02 [19], 1 bit)]
This bit indicates that the CB's remote MSS field is valid. The MSS is located in word 5 [15: 0].

[AR (address 0x02 [18], 1 bit)]
This bit is set when an ACK packet is sent on a particular socket. This is cleared when an ACK packet is being sent.

[CF (address 0x02 [17], 1 bit)]
This bit indicates that the current CB is in the receive and transmit FIFO buffer queue so that it cannot be yet replicated. Once the socket ACK is sent, the TCP send block moves from the open CB to the Time_Wait CB.

[CVI (address 0x02 [16], 1 bit)]
This bit indicates that the CB contains valid information. This bit is always cleared before any CB is replicated.

[CBVer (address 0x02 [15:12], 4 bits)]
These bits indicate the CB version and are used by the on-chip processor to discriminate future versions of the CB in hardware. This field is currently defined as 0x1.

[CB interface (address 0x02 [11: 8], 4 bits)]
This bit is used to identify a specific physical interface to the socket and is used in a multiport architecture. In a single port architecture, this fee should be left at 0x0.

[KA (address 0x02 [4], 1 bit)]
This bit indicates that a keep-alive timer should be used with this socket (0 = do not use keep-alive timer, 1 = use keep-alive timer).

[DF (address 0x02 [3], 1 bit)]
This bit represents the state of the DF bit of the IP header for the socket. When set, the packet is not fragmented by any hops. This bit is used for path MTU discovery.

[VL (address 0x02 [2], 1 bit)]
This bit indicates whether it is included in the Ethernet (registered trademark) frame output by the VLAN tag. If it is claimed, 4 bytes of VLAN tag information created by cb_tx_vlan_priority and cb_tx_vid and the VLAN tag identification (fixed value) are included, followed by the Ethernet address field.

[RE (address 0x02 [1], 1 bit)]
This flag is used to indicate a timeout condition and that a retransmission is required. It is cleared when data is retransmitted.

[UR (address 0x02 [0], 1 bit)]
This bit indicates that urgent data has been received. This is claimed until the application reads (or indicates that it has read) this received emergency data pointer.

[ACK number (address 0x03, 32 bits)]
This is an operation ACK number for TCP connection. This represents the predicted number of SEQs in the received TCP PSH packet. When a TCP data packet is received, the SYN number is checked against this number. If this matches, or if the received SEQ number + packet length covers this number, the data is received. This number is automatically updated by the network stack and is not used for UDP connections.

[Number of SEQ (address 0x4, 32 bits)]
This is the number of operation SEQ for TCP connection. This represents the number of SEQ used in the TCP packet and is automatically updated by the network stack. This field is not used for UDP sockets.

[IPSEC mode (address 0x5 [30:27], 4 bits)]
This field is used to indicate the IPSEC mode active on the socket. Decoding of this field is shown below.

[Socket type (address 0x05 [26:24], 3 bits)]
This field indicates the type of socket represented by the control block according to the following table.

[LWinScale (address 0x05 [23:20], 4 bits)]
This field represents the local sliding window scale factor used for the connection.

[RWinScale (address 0x05 [19:16], 4 bits)]
This field represents the sliding window scale factor as requested by the remote end of the TCP SYN packet.

[Local window (address 0x05 [15: 0], 16 bits)]
This field represents 16 bits of the window advertised in the TCP local sliding window field.

[Priority (address 0x06 [30:28], 3 bits)]
This field represents the user priority level used for the VLAN tag. It also represents the service level for a socket that is being scheduled for transmission. The higher the number, the higher the priority (7 is the highest and 0 is the lowest). The default value for this field is 0x0 and can be set by software.

[VID (address 0x06 [27:16], 12 bits)]
This field represents the VLAN identification used in the VLAN tag frame. The default value of this field is 0x000 and can be set by software. For connections initiated from the peer, this field is set by the VLAN identification received in the opening SYN packet.

[Remote MAC address (Address 0x06 [15: 0] -0x07, 48 bits in total)]
This field represents the destination MAC address of the packet being transmitted on this socket. When the socket is first set up, the ARP cache is queried for this address. After resolution, the address is stored here to avoid further ARP cache queries. If the CB is generated as a server socket, this address is taken from the destination MAC address contained in the SYN packet. Address bits [47:32] are stored in CB address 0 × 6.

[Local IP address (address 0x8, 32 bits)]
This field represents the local IP address of the socket connection.

[Remote time stamp (address 0x09, 32 bits)]
This is a time stamp included in the received packet.

[TW generation time stamp (address 0xA, 32 bits)]
This is a time stamp when the CB enters the time waiting state.

[Tunnel AH handle (address 0xB [31:24], address 0xC [31:24], 16 bits)]
This is the tunnel AH SA handle for CB. This is also effective when the CB tunnel AH (TA) bit is set.

[Forward link (address 0xB [23: 0], 24 bits)]
This is the link of the next CB in the search chain.

[Tunnel ESP handle (address 0xD [31:24], address 0xE [31:24], 16 bits)]
This is the tunnel ESP SA handle for CB. This is also valid when the CB tunnel ESP (TE) bit is set.

[Forward age link (address 0xD [23: 0], 24 bits)]
A link to the next CB by the age of the search chain.

[Reverse age link (address 0xE [23: 0], 24 bits)]
A link to the previous CB by the age of the search chain.

[Transfer AH handle (address 0xF [15: 0], 16 bits)]
This is the forwarding AH SA handle for CB. This is also effective when the CB transfer AH (NA) bit is set.

[Transfer ESP handle (address 0xF [31:16], 16 bits)]
This is the forwarding ESP SA handle for CB. This is also effective when the CB transfer ESP (NE) bit is set.

[TCP congestion control support]
[Overview]
IT 10G performs slow start, congestion prevention, fast retransmission, fast recovery algorithm, window scaling, and reordering of packets whose hardware is out of order. In addition, IT 10G supports a round trip time TCP option that allows more than one segment to be timed at a time. These features are required in high speed networks.

[Measurement of round trip time]
IT 10G can measure round trip time (RTT) in two ways. In traditional methods, time measurements are taken from the TCP PSH packet until the packet ACK is received. The sequence number of the timed packet is stored in the sequence number of the timed packet field in the CB, and the time stamp of the packet is stored in the time stamp of the last transmission field of the CB. When an ACK for a timed packet is received, the delta between the current timestamp and the stored timestamp is the round trip time RTT. When an ACK is received, the RTO [1] bit in socket CB is cleared to indicate that the next packet is timed.

  When the RT option is negotiated in the opening TCP handshake, RT measurements can be taken from each received ACK.

  Regardless of the method used to make the round trip time measurement. The logic flow that takes that value and determines the retransmission timeout (RTO) value is the same. This logic is shown in FIG.

  The scaled and smoothed RTT, mean deviation, RTO are all stored in the socket CB.

[Slow start algorithm]
Slow start is a TCP congestion control mechanism first described in RFC 1122, and also http://www.rfc-editor.org/rfc/rfc1122.txt and http; // www.rfc-editor.org of RFC2001. It is described in /rfc/rfc2001.txt.

  Slow start slowly raises multiple data segments being transmitted at once. Initially the slow start must have only two data segments transmitted (corresponding to the current segment cwnd of twice the maximum segment size or 2 * MSS) before predicting an acknowledgment (ACK). Upon receiving each successful ACK, the transmitter can increase cwnd by 1 MSS until cwnd equals the receiver's advertising window (thus allowing transmission of more than 1 segment).

  Slow start always starts with a new data connection, and is sometimes triggered in the middle of the connection when data traffic jams occur. Slow start is used to get things done again.

  The network stack supports a slow start algorithm for each TCP connection. This algorithm uses a congestion window parameter (cwnd), which is initialized to 1 MSS when the socket is first set up.

  The slow start algorithm indicates when the socket is first set up, indicating that only one packet can be sent and no more data can be sent until an ACK for the packet is received. When an ACK is received, cwnd is incremented by 1 MSS, which allows up to 2 packets to be transmitted. Each time an ACK is received, cwnd is incremented by 1 MSS.

  This continues until cwnd exceeds the advertised window size from the peer. The network stack always sends the advertised window with the minimum cwnd.

  If the network stack receives an ICMP source extinction message, it resets cwnd to 1MSS. However, the same slow start threshold variable (ssthresh) is maintained.

[Congestion prevention algorithm]
The network stack keeps sending the minimum advertised advertised window from the peer. The congestion prevention algorithm also uses a slow start threshold variable (ssthresh), which is initialized to 0xFFFF.

  When congestion is detected due to timeout, ssthresh is set to half of the current transmission window (minimum cwnd and peer advertising window). If this value is less than twice the MSS, this value is used instead. Cwnd is set to 1 MSS.

  When new data is acknowledged, cwnd is incremented by 1 MSS until it is greater than ssthresh (hence the name). Thereafter, cwnd is increased by 1 / cwnd. This is the congestion prevention phase.

[High-speed retransmission and high-speed recovery algorithm]
Fast retransmission is first described in RFC 112 as an experimental protocol, formalized in RFC 2001, http; // www.rfc-editor.org/rfc/rfc1122.txt, and http; // www.rfc-editor.org You can refer to /rfc/rfc2001.txt.

  Fast retransmission generates an ACK immediately when an out-of-order segment is received to allow the sender to quickly fill the hole instead of waiting for a standard timeout.

  Fast retransmission is invoked when the receiver receives three duplicate ACKs. When fast retransmission is invoked, the sender tries to fill the hole. Duplicate ACKs are considered duplicates when segment ACKs and window advertisement values match each other.

  It is strongly indicated that packets are dropped when the network stack receives duplicate ACKs. When n duplicate packets are received, the dropped segment is immediately retransmitted even if the retransmission timer has not yet expired. This is a fast retransmission algorithm. The number n of duplicate ACKs that must be received before retransmission is set via the TCP_Dup_ACK register (0x36) and defaults to 3.

  When a specified number of duplicate ACKs are received, ssthresh is again set to half the current window size as in the case of the congestion prevention algorithm, but at this time cwnd is set to ssthresh + (3 * MSS) The This ensures that after receiving a duplicate ACK, it will return to the congestion prevention algorithm rather than a slow start. Each time another duplicate ACK is received, cwnd is incremented by 1 MSS. This is a high speed recovery algorithm.

  When an ACK for new data is received, cwnd is set to ssthresh.

[Operation retransmission theory]
Logical retransmission support exists in three locations: the location where data is transmitted, the location where received ACKs are processed, and the location in the CB poller.

[Data transmission]
When sending data, the sending logic unit observes the retransmission valid bit of the associated CB. If the bit is not set, it implies that a valid retransmission time is not stored, and the currently stored RTO (in CB) is appended to the current timestamp. The resulting time is the retransmission time for the packet. This time is stored in the CB, and the retransmission valid bit of the CB is set.

  If the retransmission valid bit is already set in the CB, it means that there is currently outstanding data in the socket and the retransmission time does not need to be updated here.

  If the data buffer being sent is due to a timeout and therefore a retransmission, the retransmission time of the CB is always updated and the RTO stored in the CB is also adjusted (duplicated). .

[ACK processing]
When the TCP RX module receives an ACK, it sends a notification to the TX module with an ACK timestamp (if included). The TX module uses this information to update the RTO. If the ACK responds to the retransmitted packet, this update is not performed. An indication of whether the packet has been retransmitted is maintained in a data buffer header in the MTX memory.

  After it is calculated, if a new RTO is needed, it is stored in the CB. If any conspicuous data is detected in the socket, the new retransmission time is also calculated by appending a new RTO to the current timestamp, which is also stored in the CB.

[CB polara]
The CB polar circulates all CBs looking for an active block. When the CB polar finds an active block, the CB polar checks the retransmission valid bit. If the retransmission valid bit is set, the CB poller compares the retransmission times. If the CB poller finds that the retransmit time has expired, the CB poller retransmits the CB bit (ie, how the data transmitter knows that the packet is a retransmitted packet). And place CB in one of the priority queues.

[MSS selection]
[Overview]
This section gives an overview of how MSS options are obtained.

[Initial setup]
Before enabling TCP transactions, the host should set up the following parameters and settings:

The default non-local MSS used in registers 0x1A4A-0x1A4B,
Default local MSS used in registers 0x1A4C-0x1A4D.

[Selection algorithm]
When selecting the MSS value to be used for any of the two connections, the TCP engine queries the IP router. If the destination route passes through the gateway, a non-local MSS is used.

[TCP option]
[Overview]
The following description is an overview of the supported TCP options and their formats. The four supported options are:
・ MSS,
Window scaling,
·Time stamp,
-SACK.

[MSS option]
This option is always sent. The actual MSS value used is determined according to the algorithm already described. The format of the MSS option is shown in FIG.

[Window scaling option]
This option is always sent in a SYN packet as long as the Sl_Win_En bit is set in the TCP_Control register. This option is sent in a SYN / ACK packet only if it is included in a SYN packet that generates a SYN / ACK response. The format of this option is shown in FIG. Note that this option is always preceded by a NOP byte so that it is aligned on a 4-byte boundary.

[Timestamp option]
This option is always sent in a SYN packet if the timestamp option is enabled, and if the option is included in a SYN packet that generates a SYN / ACK response, regardless of whether the timestamp option is enabled. Only in SYN / ACK packets. An optional format is shown in FIG. Note that this option is always preceded by two NOP bytes so that it is aligned on a 4-byte boundary.

[Selective ACK (SACK) option]
Selective Acknowledgment (SACK) allows TCP to acknowledge data containing holes (lost data packets) and allows retransmission of lost data rather than all data after dropping. This feature is described in RFC2018.

  This option is always sent in SYN and SYN / ACK packets as long as the SACK_En bit is set in the TCP_Control register. SACK uses two different TCP option types. One option type is used in the SYN packet, and the other option type is used in the data packet. An optional format is shown in FIGS.

[MTX buffer header format]
[Overview]
This section describes the header format used at the start of each MTX data buffer. The header contains information about the data contained in the buffer such as the checksum, sequence number, next link, etc. The header format is different between TCP and UDP.

[TCP keep-alive timer]
[Overview]
This section describes the keep-alive timer used for TCP connections. This section contains the theory of operation for how this feature is implemented in the IT 10G network stack.

[Keep-alive parameters]
The following parameters are used in the network stack keep-alive characteristics.

[Theory of operation]
By default, the keep-alive timer is disabled on the socket. When the socket is created, the host has the option of setting the Keep_Alive bit in the Socket_Configuration register. If this bit is set and a socket parameter is given, the keepalive property is enabled on that socket.

  Once the socket is set up, the keep_alive timestamp is maintained in the CB (word 0x05). This timestamp represents the future time when the socket is considered idle. This time stamp is updated each time a packet is sent on the socket or when the packet arrives at the socket. The updated timestamp is the sum of the currently running counter and the keep_alive time (as entered by the host via the Keep_Alive_Timer register (0x1A3A)).

  The CB polar module checks the keep alive time stamp once each CB with keep alive characteristics is available. If the CB polar module finds a socket with a time stamp that matches the current free running minute counter, the CB polar module schedules a keep alive probe to be sent on that socket. The CB polar module does this by queuing the CB into the data transmission queue and setting the K bit (the CB word 0x0B keep-alive retry bit). The CB polar module also sets the CB keepalive retry field (word 0x13) to 0x1. If the transmission queue is full, the CB polar module increments the CB's keep_alive timestamp to trigger the CB poller again during the next minute check.

  When the data packet generator encounters a CB with the K bit set, the data packet generator will send a 1-byte PSH packet with a sequence number set to a value one lower than the sequence number normally set. Send it out. The data generator also updates the CB's keep alive timestamp with the current free running count plus the keep alive retry interval. If this is still active (active), it causes the peer to return an ACK with the correct predicted sequence number.

  If the peer is active and sends a response, the TCP-RX module clears the K bit in the CB, resets the retry count to 0x0, and updates the keep alive timestamp.

  If the peer does not send a response within the keepalive retry interval, the CB poller again encounters the socket from which it was doing the previous minute keepalive timestamp check. When observing that the K bit is already set, the keep alive retry counter is incremented by 1 and the CB is rescheduled for data packet transmission.

  If the CB poller finds that the maximum number of retries has been reached, the CB poller sends a notification to the host computer and replicates the socket.

  During the keep-alive probe delivery course, the network stack receives an RST packet, which most likely means that the peer has been rebooted (reset or restarted) without properly closing the socket. In this case, the socket is replicated.

  Another possibility is that the network stack receives an ICMP error message in response to a keep-alive probe, eg, a network keep-alive probe that is not reachable. This condition occurs when the intermediate router goes down. In this case, the ICMP message is sent to the on-chip processor. After receiving a plurality of these ICMP messages, the on-chip processor can read the socket CB and observe that it is in a keep-alive retry state. The on-chip processor can then initiate a CB depletion process.

[TCP ACK mode]
[Overview]
The following description details the TCP ACK mode that is valid in the IT10G network stack. There are two bits that determine the mode in which the stack is operating among the four modes. These are the Dly_ACK bit in the TCP_Control1 register and the Host_ACK bit in the Socket_configuration register. The operation matrix is shown in the table below.

[Normal ACK mode]
In this mode, data is ACKed as soon as they are received into the NRX DRAM. The TCP receive logic unit schedules the ACK by positioning it in the RX-to-TX packet FIFO buffer. The AR bit of socket CB is not used in this mode. This is the default mode of the TCP module and can be used by releasing the assertion of the Dly_ACK bit in the TCP_Control1 register. This is a general TCP setting to apply to all sockets.

[Delayed ACK mode]
In this mode, data is not immediately ACKed. Instead, when data arrives at the socket, the TCP receive logic sets the AR bit in socket CB. The CB polar module then periodically tests all active CBs to observe CBs with the AR bit set. When the CB poller finds a set bit, the CB poller schedules an ACK for that socket. The polling interval looking for the AR bit can be set via the Del_ACK_Wait register and is specified for a 2 ms timer step. The default interval is 250 ms. This mode is enabled by asserting the Dly_ACK bit in the TCP_Control1 register. It is also a general TCP setting to apply to all sockets.

[Host-normal ACK mode]
In this mode, data is not ACKed when received into the MRX DRAM. Instead, the ACK is sent only after the data is sent to the host computer, and the host computer acknowledges receipt of the data by generating a data ACK command. When the IT 10G hardware receives an ACK command, it writes CB, the socket handle, to the Host_ACK_CB register. This action schedules the ACK packet via the RX-TX packet FIFO buffer. The AR bit of socket CB is not used in this mode. This mode can be enabled according to socket base by asserting the Host_ACK bit in the Socket_Configuration register.

[Host delayed ACK mode]
In this mode, data is not immediately ACKed. Instead, after the data is received, it is transmitted to the host computer, which acknowledges receipt of the data by generating an ACK command for the data. When the IT 10G hardware receives an ACK command, it writes CB, the socket handle, to the Host_ACK_CB register. This action causes the AR bit in the socket CB to be set. When the CB poller module checks all AR bits in the next ACK polling cycle, the CB poller schedules an ACK to be sent out for that socket. The CB polling cycle specified via the Del_ACK_Wait register specifies only the AR bit polling interval and takes into account the delay caused by first sending data to the host computer and waiting for the host computer to respond to that data. Note that not. Therefore, if this mode is used, it is suggested that the ACK polling interval is set to some value lower than the default 250 ms. The optimum interval depends on the turnaround time of the host computer that generates the ACK command.

[Host resend mode]
[Overview]
The IT 10G network stack is designed to retransmit TCP data from its local data buffer or from host memory. This description details the operation when the network stack is operating in the latter mode. The advantage of retransmitting from host memory is that the amount of local transmit buffer memory can be kept to a minimum. This is because the MX data buffer block is released as soon as the data is transmitted over the wire. The disadvantage is that it takes more host memory, host CPU cycles, and latency to support host memory retransmission.

[Enable host resend mode]
Host retransmission mode can be enabled according to socket base by asserting the Host_Retrans bit in the Socket_Configuration2 register. This mode can be used with any ACK mode of operation.

[Host retransmission mode operation theory]
When operating in host retransmit mode, the host CPU operates to keep track of the sequence number. In each data section DMAed from the host memory, the first 128 bits form the header for the data block.

  The host must write to this header as the first 128 bits of each data transfer. Header bits [127: 64] should be DMAed with the first 64-bit word, followed by header bits [63: 0], followed by the first data byte.

  When the IT10G hardware generates a data packet, it takes the sequence number of the alternate data buffer header from socket CB. The IT10G hardware then forms the packet as usual and sends the data packet over the wire. After the transfer of the packet, the MTX data buffer is immediately freed.

  When an ACK for data is received from the peer, the host computer is notified via the status message about the CB that received the data and the received SCK number. With this information, the host computer can determine when the data from the host computer memory is cleared to free.

  The retransmission timer is still used in socket CB under normal conditions. When the retransmission timer expires, a status message is sent to the host computer along with the corresponding socket handle. The host computer then schedules a DMA transfer of the oldest data present in memory that has not yet been acknowledged.

[Pier Zero Window Case]
[Overview]
Sometimes the peer side of a TCP connection runs out of receive buffer space. In this case, the peer advertises a window size of 0x0000. The peer window is always written to socket CB by the TCP receive section. When the receiving logic unit detects a window size of 0x0000, it sets the ZW bit in the CB flag word (word 0x02 bit [19]). The next time data is sent on this socket, the TCP send logic will find the ZW bit that is set and send a 1-byte data packet with an incorrect sequence number instead of sending the data. The sequence number is one less than the correct sequence number. This data packet looks like a keep-alive probe packet. In response to this incorrect data packet, the peer must send an ACK packet with the updated window size. After sending a 1-byte data packet, the CBzero_window probe count is incremented by 1 (word 0x13 bits [27:24]), and when the next zero_window probe is to be sent, CB zero_win_timestamp (bits of word 0x0C) [31:26]) is written.

[Zero_Window Timestamp]
This field is used to determine when the next zero_window probe should be sent. Each time a zero_window probe is sent, the probe count is incremented and the timestamp is updated. The transmitting logic unit shifts the zero_window_interval count by the number of probes transmitted and adds this time to the current free-running second timer to determine the next zero_window timestamp. The resulting time stamp represents a future time when the next probe is transmitted. Therefore, with a default value of 3 seconds, the probe is delivered at intervals of 0, 3, 6, 12, 24, 48, 60 seconds. Once the interval reaches 60 seconds, it is capped.

  In the CB polar module, the logic unit polls all active CB ZW bits every X seconds, where X is the zero_window_interval count. When the CB poller finds a CB with the ZW bit set, the CB poller reads the zero_window timestamp and compares its timestamp with a second timer that runs freely. If they match, the zero window probe is queued for transmission. Unlike keep alive probes, there is no limit to the number of zero window probes transmitted.

[Open window]
When the peer's window eventually opens, the peer either sends an arbitrary ACK (window announcement) or the peer indicates that the open window of the ACK responds to a zero window probe. The TCP receiving logic then updates the CB peer window. The next time the CB appears with the zero_window probe, the CB poller observes that the window is open. The CB polar then clears the ZW bit and schedules regular data transfer. The number of zero_window retries is also reset to 0x0.

[Naggle operation]
[Overview]
This section describes IT10G hardware support for the Nagle algorithm. This algorithm states that when a TCP connection has unacknowledged data during transition, a small segment cannot be sent until the data is acknowledged.

[Nagle transmission IB]
A separate send command block is given using the Nagle algorithm. These instruction blocks (IBs) are similar to regular non-naggle IBs except that they do not have the claimed IB code msb. The 32-bit address nagle transmission IB is 0 × 81, and the 64-bit address code is 0 × 82. Nagle transmission IBs operate in the same way as normal transmission IBs, except that when they are parsed by HW, the RxACK bit of socket CB is asserted. Normal transmission IB processing clears this bit if this is set.

[RxACK bit]
This is a bit present in the socket CB and can be set via the application by asserting bit [3] in the Socket_Config1 register. When set, this bit generates an RX_ACK status message that all outstanding data has been acknowledged when an ACK is received. This state is satisfied when the received ACK number matches the SEQ number used by the socket. The status message code is 0x16 for the received ACK.

  The RxACK status bit is cleared when a regular send IB is processed by the IT10G hardware, or when an RxACK status message is sent, or by an application that manually clears the socket CB bit. The last case is done for diagnostic purposes only.

[MTX data storage]
[Overview]
This section describes the algorithm that the TOE uses to determine the size at which data can be stored in the MTX buffer. This affects the size of the TCP packet transmitted when one MTX buffer corresponds to one TCP packet.

[MSS vs. 1/4 MSS (or maximum half peer window)]
If the peer's advertised window exceeds twice the MSS, the socket MSS size (as stored in CB location 0x05) is the socket on how many bytes can be stored in the MTX buffer. Used as a decision factor. If the peer advertised window does not reach twice the MSS level, then the maximum number of bytes stored in the MTX buffer is (depending on the configuration) one quarter of the MSS or the maximum advertised window of the peer. It is half. The bit that maintains this comparison is bit [18] of the CB word 0x14.

[Packet overhead]
A fixed byte overhead is deducted from the MSS or a quarter of the MSS or half of the peer's maximum window value (depending on the configuration). This overhead includes packet header bytes and IPSEC overhead.

[CB size limit vs. buffer size]
After deciding whether to use the MSS, or a quarter of the MSS or half of the peer's maximum window value (depending on the configuration), and deducting the packet overhead, the logical unit is the type of buffer available Observe. This limits storage size if only a 128 byte buffer is available. Also, after the above calculation, if the data size is still larger than the large MTX buffer size, the packet size can be limited again by the MTX buffer size.

[IP router]
[IP router characteristics]
Provide default route capability.
Provide routes for multiple host IP addresses.
Provide host specific and network specific routes.
• Dynamically update routes after ICMP redirect.
• Process IP broadcast addresses (limited, subnet redirected, network guided broadcasts).
Process the IP loopback address.
Process IP multicast addresses.

[Module block diagram]
FIG. 35 is a schematic block diagram of an IP router.

[Theory of IP router operation]
[Request route]
When a local host wants to send an IP packet, it must decide where to send the packet: another host on the local network, the external network, or the local host itself. This is an IP router task that guides an output IP packet to an appropriate host.

  When the module requests a route, the sending module sends the destination IP address of the packet to the IP router. The IP router compares the target IP address with the list of destinations stored in the IP route list. If a match is found, the IP router will attempt to resolve the appropriate Ethernet address. The IP router performs this resolution by requesting an ARP search for the destination IP address in the ARP cache. If the destination Ethernet address is resolved, the Ethernet address is returned to the sending module and used as the destination of the Ethernet frame that outputs this Ethernet address. .

  Route information is provided by three separate components: a default route register 351, a custom route list 352, and a non-routable address cache 353. These components are all queued simultaneously when a route request is given.

[Default route]
The destination of the packet can be described as local or external. The local destination is attached to the same local network as the sending host. The external destination belongs to a network other than the sending host's local network.

  When the outgoing packet destination IP address is found to belong to a host attached to the local network, the IP router tries to set the resolved destination IP address to its corresponding Ethernet address. Use ARP. If it is determined that the destination IP address belongs to the external network, the IP router must determine the gateway host to be used to relay outgoing packets to the external network. Once a gateway host is selected, outgoing IP packets use the gateway host's Ethernet address as their destination Ethernet address.

  If a route cannot be found for the packet destination IP address, the packet must use the gateway host specified by the default route. The default route is only used when no other route can be found for a given destination IP address.

  To minimize the number of accesses to the ARP cache, the IP router caches the default gateway Ethernet address when a default route is set. The default gateway Ethernet address is cached for a maximum amount of time equal to the amount of time that a dynamic entry in the ARP cache is allowed to be cached.

[Broadcast and multicast destinations]
When the destination IP address is a broadcast or multicast IP address, an ARP search is required. Instead, the destination Ethernet address is generated according to the type of IP address. A packet having the destination IP address set for the IP broadcast address (255.255.255.255) is transmitted to the Ethernet (registered trademark) broadcast address (FF: FF: FF: FF: FF: FF). Packets with the destination IP address set to the multicast IP address (244.xxx) have their destination Ethernet address calculated from the multicast IP address.

Static route
In addition to the default route, the IP router allows the generation of a static route to map the destination IP address to a special Ethernet interface or gateway host. The IP route entry includes a destination IP address, a netmask, and a gateway IP address. The netmask is used to match the destination IP address range with the destination IP address stored in the IP route entry. Netmasks also allow discrimination between special host routes and network routes. The gateway IP address is used when resolving the destination Ethernet (registered trademark) address via ARP.

  Since it is possible to have multiple routes in the IP route list, IP route entries are stored in dynamically allocated memory (called m1 memory in this structure). Each IP route entry uses 128 bits. The last 32 bits of each entry do not store any data and are used as padding to align the IP route engine along a 64-bit boundary. The format of each IP route entry is shown in FIG.

  The IP route list is configured as a classified link list. Since IP routes are added to the IP route list, they are ordered according to their netmask, with the highest specific IP route appearing in front of the list and the IP route with the lowest specific netmask listed. Placed at the end of. The route pointer field of the IP route entry contains the m1 memory address, where the next IP route entry can be found in the m1 memory. The first (most significant) bit of the route pointer field is used as a flag to determine whether the m1 memory address is valid and there is a route following the current one. If the pointer valid bit in the route pointer field is not asserted, there are no more IP routes in the IP route list and the end of the IP route list is reached.

  If it is not determined that the destination IP address is a broadcast or multicast IP address, the IP route list is searched for a matching IP route entry. If no match is found in the IP route list, the default route is used to provide gateway information.

  IP routers also allow the use of multiple physical and loopback interfaces. Using the interface ID field of the IP route entry, the IP router can direct outgoing packets to a specific Ethernet interface of IT10G. The interface ID field is also used to route ARP requests to the appropriate Ethernet interface.

[Loopback address]
If the destination IP address belongs to IT10G or is a loopback IP address (127.xxx), it is assumed that an output packet is fed back to IT10G. The IP router for the loopback destination is stored in the IP route list. An IP address that is not assigned to the IT 10G can also be configured as a loopback address. In order to allow this local redirection, the interface ID field of the IP route entry must be set to 0x8. Otherwise, the interface ID field of the IP route entry must be set to one of the Ethernet interfaces (0x0, 0x1, 0x2, etc.).

Generate route
The new IP route comes from the system interface (eg host computer). The IP routes generated by the system interface are static routes, meaning that they remain in the table until they are removed by the system interface. The system interface adds and removes routes via the IP router module register interface.

  An ICMP redirect message is sent when an IP packet is being sent to an incorrect gateway host. ICMP redirect messages usually contain the correct gateway host information to be used for incorrectly derived IP packets. When an ICMP redirect message is received, the message is processed by the system interface. The system interface is engaged in updating the route list via the IP router's register interface, updating existing IP routes, or creating new IP routes.

Routing to local network hosts
In order to direct packets directly to other hosts in the local Ethernet network, an IP route with an IT10G subnet mask must be created. Instead of identifying another host as the gateway for this route, the gateway IP address must be set to 0.0.0.0 to indicate that this route has a direct connection across the local network.

[Route Request Signaling]
Each sending module has its own interface to the IP router to request a route. The signaling used for requesting and receiving routes is shown in FIG.

  When a module requests an IP route, the requesting module asserts a route request signal (eg, TCP_Route_Req) and provides a destination IP address (TCP_Trgt_IP in FIG. 21) to the IP router. Once the IP router finds a route for the supplied IP address, the IP router asserts a routed signal and outputs the destination Ethernet address. The route_valid signal is used to indicate to the sending module when an IP route is properly discovered. If the route_valid signal is asserted when the rootdan signal is asserted, a valid route has been found. If the route_valid signal is not asserted, this means that routing was not successful. Does this routing failure have a default route set? This is due to several causes such as the gateway supplied by the matching IP route entry is down and not responding to the ARP request. In the event of a route failure, the sending module waits and later tries to resolve the route again or engages in aborting the current connection attempt.

  When an IP route requires an ARP search to resolve an Ethernet address for a host or gateway IP address, there may be a delay if that IP address is not found in the ARP cache. When there is a cache loss, ie when the target IP address has no entry in the ARP cache, the ARP cache notifies the IP router of the loss. The IP router then sends a signal to the sending module that requested the IP route that an ARP cache loss has occurred. At this point, the sending module attempts to request another route by selecting a delay in setting up the current connection or trying to set up the next connection in the connection queue. Even if the transmission module has a route request to the IP router, the ARP search continues. If the target of the ARP search is active and responds to an ARP request from IT10G, the resolved Ethernet address of the target IP address is added to the ARP cache for possible later use. . Note: An IP router can have many outstanding ARP requests.

Show individual routes
After generating the static route, the user can read back the entries stored in the route table in two ways. If the user knows the target IP address for a given route, the Show_Route command code can be used to display the netmask and gateway for that route.

  The Show_Index command can be used to display all entries in the route table. Using the Route_Index register, the system interface may access routes in order of specificity. More special (host) routes are displayed first, followed by less specific (network) routes. For example, an IP route entry having route_index0 × 001 is the most special route in the IP route list. Note: The default is stored at index zero (0x0000). The Route_Found register is asserted when a route is properly found, and the route data is Route_Trgt and Route_Mask. Stored in the Route_Gw register.

[Caching of unresolvable destinations]
When the IP router cannot resolve the Ethernet address for the destination host / gateway, the router caches the destination IP address for 20 seconds. During that time, if the router receives a request for one of these cached unresolvable destinations, the IP router immediately responds to the module requesting the route with the route failure. This unresolvable destination caching aims to reduce the number of accesses to the shared m1 memory, where ARP cache entries are stored. Unresolvable destination caching also works to avoid redundant ARP requests. Note: The amount of time that unresolved addresses are cached is user configurable via the Unres_Cash_Time register.

[System exception handler]
[Overview]
The following description details the system exception handler. This module is called whenever there is data that the IT10G hardware cannot process directly. This may be an unknown Ethernet type packet, an IGMP packet, a TCP or IP option, or the like. For each of these exceptions, the main parser enables the system exception handler when detecting an exception case. The system exception handler module stores data, notifies the system interface (typically an application running on the host computer) that there is exception data to be processed, and operates to send the data to the system interface.

[Exception handler block diagram]
FIG. 38 is a schematic block diagram of one configuration of the exception handler.

[Theory of exception handler operation]
The exception memory is part of the on-chip processor memory. Each source module that can generate an exception packet has its own exception buffer start address and exception buffer length register. This module provides an exception packet to the FIFO buffer and queues it for storage in on-chip processor memory. The exception_fifo_full signal is fed back to each call module to indicate that the exception FIFO buffer is full. This module can service only one exception packet at a time. If a subsequent exception packet is received, this is held until the previous packet is stored in memory.

  Since exception packets are stored in on-chip processor memory, host computer access is not granted through this module.

[Memory allocator 1]
[Overview]
This section describes the memory allocator (malloc1) used to service the IP module, ARP cache, route table, and on-chip processor. This allocator operates by first dividing the M1 memory into discrete blocks, allocating them on request, and putting freed blocks back on the stack.

[Theory of operation]
Malloc1 needs to have two parameters entered before starting its operation. These are the overall size of the M1 memory block and the size of each memory block. Only one memory size is supported by this allocator.

  After entering these parameters, the system asserts the M1_Enable bit in the M1_Control register. When this happens, the allocator starts embedding the block address starting from the top of the M1 memory block. That is, if the M1 memory block is 4K bytes in total and the block size is 512 bytes, the M1 memory map will appear as shown in FIG.

  Four addresses are maintained for each M1 address location with respect to the M1 block address. In addition to maintaining the starting block address in memory, Malloc1 also includes a 16 entry cache. At initialization, the first 16 addresses are maintained in the cache. When blocks are requested, they are fetched from the cache. When the cache number reaches zero, four addresses (one memory read) are read from memory. Similarly, whenever the cache is full of addresses. The four addresses are written back to memory. This is done only after the allocator first reads the address from the M1 memory.

[TX / RX / CB / SA memory allocator]
[Overview]
This section describes memory allocators used in socket send (malloctx), socket receive (malloccrx), control block (mallocb), and SA (mallsa) memory. These allocators operate to allocate memory blocks upon request, return freed blocks to the stack, and arbitrate to use memory.

[Theory of operation]
Malloc needs to have some parameters entered before the start of its operation. These are bitmaps representing the starting and ending address pointer locations in the MP memory space and each available block in each memory space. Two sizes of blocks are available in socket data memory: 128 bytes and 2k bytes. The CB memory has a fixed 128 byte block. All allocators also use an 8-entry cache for each memory size block address.

  After entering these parameters, the system asserts the enable bit in the control register. The allocator can then allocate memory blocks and initiate deallocation.

[Default memory map]
FIG. 40 shows a sample memory map assuming 256 Mbytes of integrated network stack data memory, ie MRX and MTX share a common physical memory bank. The current configuration uses external DDR DRAM for both MRX and MTX, but in other configurations it is possible to place these memories on-chip or to use different types of memory (eg SRAM).

[Network stack data DDR block diagram]
Network stack data DDR DRAM is shared between the transmit and receive data buffers and the on-chip processor. The flow of the data block diagram is shown in FIG.

  Data DDR DRAM arbitrator 411 operates to arbitrate access to DDR DRAM shared between different resources. The overall DDR DRAM 412 is also memory that is mapped into the memory space of the on-chip processor.

[MTX DRAM interface and data flow]
[Overview]
The following description is an overview of the interface between the malloctx module and the data DDR arbitration module. Describes the data flow, lists interface signals, and details the required timing.

[data flow]
Three different access types are supported in MTX DRAM. These are burst write, burst read, single access. Malloctx 413 arbitrates requests from different sources for each of these cycle types, but all three cycles are requested simultaneously from the data DDR arbitrator. A block diagram of the mtxarb subunit is shown in FIG.

  Data to be written to the MTX memory is first written to the FIFO buffer and then burst written to the DDR DRAM.

[RX DRAM interface and data flow]
[Overview]
This section describes the interface between mallocrx 414 and the receive socket data DRAM controller. This describes the data flow, lists interface signals, and shows the required timing details.

[data flow]
In the receiving DRAM, the highest priority is given to the data written in the memory. This is because the network stack must keep up with data being received from the network interface. Writing to the DRAM is first done to the FIFO buffer. When all the data is written to the FIFO buffer, the controller burst writes it to the DRAM. In jumbo frames, the TCP receiving logic unit divides burst write requests into 2K sized chunks.

  For data that is burst read from DRAM, the DRAM controller reads the memory and writes the requested data to a pair of ping-pong FIFO buffers that feed the PCI controller. These FIFO buffers are needed to move the data rate from the DRAM clock to the PCI clock domain.

[Network stack DDR block diagram]
The network stack DDR is shared among CB, miscellaneous memory, and SA memory. The flow of the data block diagram is shown in FIG.

  The NS DDR arbitrator operates to arbitrate access to DDR shared between different resources.

[MCB DRAM interface and data flow]
[Overview]
This section describes the interface between the mallocb module and the NS DDR arbitration module. This shows the data flow, lists interface signals, and details the required timing.

[data flow]
Two different access types are supported for MCB DRAM. These are burst read, single access. Mallocb arbitrates requests from different sources for each of these cycle types, but both cycles may be requested from the NS DDR arbitrator at the same time. A block diagram of the mcbarb subunit is shown in FIG.

[Network stack memory map]
FIG. 45 shows a default memory map of the network stack. The address shown is a byte address.

[Miscellaneous memory]
[Overview]
The following description is a detail of a 512 Kbyte miscellaneous memory bank. This memory is used for the purposes listed below.
-Half-open control block (main),
TCP port authentication table,
・ UDP source port usage table,
TCP source port usage table,
-Wait time control block allocation table,
・ Set control block allocation table,
TX memory block allocation table (both 128 and 2K bit blocks),
RX memory block allocation table (both 128 and 2K bit blocks),
FIFO buffer for packets from TCP RX to TX,
A valid bitmap of socket data,
Server port information,
SA entry allocation table.

[Memory organization and performance]
The miscellaneous memory is shared with the CB memory. Most resources access 256-bit words of data to minimize access.

[Definition of stored data]
[Half-open control block]
These are control blocks for half-open TCP connections. Each control block is 64 bytes in size, and there are 4K control blocks in total. Therefore, the number of bytes required for a half-open control block is 4K × 64 = 256K bytes.

[TCP port authentication table]
This table keeps track of the TCP ports that are authenticated to accept connections. Maintain one bit for each of the 64K possible ports. Therefore, this table uses 64K / 8 = 8K bytes. In an alternative configuration, a TCP port authentication table and a UDP and TCP source port usage table can be maintained on the host computer.

[UDP source port usage table]
This table keeps track of the available UDPP ports for the source ports used for locally initialized connections. Maintain one bit for each of the 64K possible ports. Therefore, this table uses 64K / 8 = 8K bytes. This table should not include local UDP service ports and ports that can be used.

[TCP source port usage table]
This table keeps track of the number of ports available for source ports used for locally initialized connections. Maintain one bit for each of the 64K possible ports. Therefore, this table uses 64K / 8 = 8K bytes.

[Wait time control block allocation table]
This is a waiting time control block allocation table. Maintain one bit of each of the 32K wait time control blocks. Therefore, this allocation table uses 32K / 8 = 4K bytes. This module uses a 16-bit data bus in total.

[Set control block allocation table]
This is a set control block allocation table. Maintain one bit of each of the 64K control blocks. Therefore, this allocation table uses 64K / 8 = 8K bytes.

[TX socket data buffer block allocation table]
This table is made up of a 2 Kbyte block allocation table and a 128 Kbyte block allocation table, which are used in the dynamically allocated transmit data buffer memory. The number of blocks of each type is configurable, but the size of both of the combined allocation tables is fixed at 72K bytes. This allows for a maximum of 475K 128 byte blocks. At this level, the number of 2K byte blocks is 98K.

[RX socket data buffer block allocation table]
This table is made up of a 2 Kbyte block allocation table and a 128 Kbyte block allocation table, which are used in the dynamically allocated receive data buffer memory. The number of blocks of each type is configurable, but the size of both of the combined allocation tables is fixed at 72K bytes. This allows for a maximum of 475K 128 byte blocks. At this level, the number of 2K byte blocks is 98K.

[TCP RX FIFO buffer]
This FIFO buffer is used to keep track of packet transmission requests from the TCP receiving logic to the TCP sending logic. Each TCP RX FIFO buffer entry is made up of several control flags and control block addresses with a total of 4 bytes (4 flags, 26-bit address, 2 unused bits). This TCP RX FIFO buffer is 1024 words deep and therefore requires 1024 × 4 = 4K bytes.

[Available bitmap of socket data]
This bitmap represents a 64K socket with data ready to be sent to the host system. One bit is maintained in each socket. This bitmap therefore uses 64K / 8 = 4K bytes.

[SA entry allocation table]
This is an SA entry allocation table. One bit is maintained for each 64K SA entry. Therefore, this allocation table uses 64K / 8 = 4K bytes.

[Server port information]
This database is used to store parameter information for TCP ports opened in LISTEN state. Because these server ports do not have a CB associated with them until they are opened, port specific parameters are maintained in this area. Each port entry consists of 2 bytes and there are 64K possible ports. Therefore, this database requires 64K × 2 = 128K bytes.

[Miscellaneous memory map]
The memory map used for miscellaneous memory is configurable. The default settings are shown in FIG. The block is not scaled.

[Miscellaneous memory operation theory]
[Module initialization]
It is rarely necessary for the CPU to initialize before starting the miscellaneous memory arbitrator. If the default memory map is used, the CPU can enable the arbitrator by asserting the MM_Enable bit in the Misc_Mem_Control register.

  If a non-default memory map is used, all base address registers must be initialized before the arbitrator can be used. It is the responsibility of the host computer software to ensure that the programmed base address does not generate any overlapping memory areas. No hardware is provided to check this.

[CPU access]
The CPU can access any location in the miscellaneous memory. This is done by first programming at the address to the MM_CPU_Add register (0x1870-0x1872) and reading bytes or writing to the MM_CPU_Data register (0x1874). The address register automatically increments each time the data register is accessed.

[MIB support]
[Overview]
This section describes the MIB support built into the IT10G network stack. This includes register definitions, theory of operation, and an overview of what MIBs are used for.

[Preface of SNMP and MIB]
SNMP is a management protocol that allows an SNMP management station to obtain statistics and other information about networked devices and allows the devices to be configured. Software that runs on the device is called an agent. The agent runs on top of the UDP socket and processes requests from the SNMP management station. The agent can also send a trap to the SNMP management station when an event occurs on the device. The SNMP RFC documents a standard set of information objects called Management Information Base (MIB) when grouped together. Vendors can also define the specific MIBs they support in addition to the applicable standard MIBs specified in the RFC.

  Standard MIBs specify the information that most devices of a specified type must provide. Some information can be completely processed by the SNMP agent software, the rest requires some level of support from the operating system, drivers and devices. SNMP support is provided by all three main transferables, hardware, embedded software, and drivers.

  In most cases, hardware support is limited to the collection of statistical information on certain counters associated with the networking layer comprising hardware. Interrupts can also be triggered by certain events. Embedded software development also supports counters for layers implemented in software, such as ICMP and exception handling. In addition, embedded software can query a database generated by hardware to report on things such as ARP table entries, TCP / UDP socket status, and other non-counter statistics. Driver support is focused on interfacing an embedded platform to an API that can return related objects back to the SNMP agent, allowing some level of configuration of the SNMP agent.

[MMU and timer module]
[Overview]
The following description provides an overview of MMUs used in general purpose timers and systems.

[CPU timer]
Four general purpose 32-bit timers are provided that are cascaded or independent of the previous timer. All timers can be operated in single shot or loop mode. In addition, a clock prescaler is provided that can divide the main core clock before being used by each timer. This allows minimal code changes for different core clock frequencies.

[Timer test mode]
Each individual timer can be put into test mode by asserting the Timer_Test bit in the corresponding timer control register. When this mode is activated, the 32-bit counter is incremented at different rates according to the three lsb of the 8-bit clock divider setting.

[On-chip processor MMU]
On-chip processors use the MMU to divide the processor's 4 Gbyte memory space into different regions. Each area can be individually specified by a base address and an address mask. The areas may also overlap, but in this case the data read back from the shared memory area is unpredictable.

[On-chip processor DRAM interface and data flow]
[Overview]
This section describes the interface between the on-chip processor and the network stack (NS) data DDR arbitration module. This shows the data flow, lists the interface signals, and details the required timing.

[data flow]
Three different access types are supported by the on-chip processor DRAM. These are burst write, burst read, single access. Furthermore, a lock can be applied so that successive single accesses are made by the on-chip processor without giving up the DRAM. The on-chip processor memory arbitrator arbitrates requests from different sources in each of these cycle types, but all three cycles are requested simultaneously from the NS DDR arbitrator. When it needs to be enabled via register bits, it is assumed that only the on-chip processor itself uses the lock feature.

[Operation theory of instruction / state block]
[Overview]
The following description outlines the theory of operation of the instruction block (IB) and state block (SB) passing between the host, on-chip processor, and network stack. It also covers the concept of MDL.

  Individual IBs and SBs are linked to a queue. There are IB queues and SB queues. Each queue has a host computer component and an on-chip processor component. Each IB queue also has an associated SB queue. Matching IB and SB queues together form a channel. This is illustrated in FIG.

Note: All state and instruction queue lengths must be multiples of 16 bytes and are DWORD aligned.

  The preferred embodiment supports four channels. In each queue (both IB and SB) there is a queue descriptor. These descriptors detail the location of the queue and the read and write pointers along with the length of the queue. Each queue is treated as a circular FIFO buffer. The parameters that define each queue are divided into registers in the host register interface for the parameters that make up host memory usage, and general network stack register space registers that define on-chip processor memory usage. The format of the queue descriptor is shown in the following table. The address offset listed here is relative to the start of the queue descriptor register.

  The processing flow of the instruction block queue is shown in FIG. This also shows the association with the IB parser module.

[SB passing]
A block diagram showing the data flow of the state block passing between the network stack, the on-chip processor, and the host computer is shown in FIG.

  The SB timer threshold is the primary interrupt aggregation mechanism in the integrated network adapter hardware. Interrupt aggregation reduces the number of interrupts between the integrated network adapter and the host computer, and the reduction or collection of interrupts increases data processing capabilities.

  The HW can send a general SB to the on-chip processor and send a socket specific SB directly to the host computer. Host computer status messages include socket set, RX DMA, CB_Create, Socket_RST status messages.

[SB from HW to host]
When a socket specific event occurs, the owner of the CB is determined by examining the HS bit in the socket CB structure. If the socket belongs to the host computer, the CB channel number is also read from the CB. The channel number is transmitted to the HW status message generator (statgen module) 491 together with the event notification.

  The statgen module forms the appropriate SB and places the SB in one of the four DMA FIFO buffers 492. These FIFO buffers are physically located in the on-chip processor memory and are identified by the on-chip processor SB FIFO buffer address and the on-chip processor SB FIFO buffer length.

[SB from HW to on-chip processor]
When a non-socket specific event, ie an exception Ethernet packet, occurs, the statgen module generates an appropriate SB and sends it to one status message queue defined in the on-chip processor memory. An interrupt can be generated to the on-chip processor at this time if statgen_int becomes available. There is only one status message queue defined from hardware to the on-chip processor, and all SBs go to this one queue.

  The SB queue actually exists in the on-chip processor memory. As entries are written to this memory area, they are automatically pulled into the on-chip processor's register FIFO buffer to be read via the STAT_READ_DATA register (network stack general register 0x005C-0x005F). The on-chip processor can also poll to see how much data is available at 0x005A by reading the STAT_FIFO_FILLED register. This register returns the number of double words available in the queue.

[SB from on-chip processor to host computer]
When the on-chip processor needs to send an SB to one of the host's SB queues, it sends it via a statgen hardware module. In this case, the on-chip processor generates an SB in its memory and programs the start address of this SB, the channel number of the SB, and the length of the CB sent to the statgen module. The HW then forwards the SB (or SBs) to the appropriate SB queue to the host. In this way, the SBs from the on-chip processor and HW are mixed in the same SB queue supplying the SB DMA engine 493.

  The on-chip processor can be notified that the SB has been transferred to the appropriate SB queue via an interrupt or by polling status bits. Before writing any parameters of this function, the on-chip processor should ensure that the statgen module has completed the transfer of any previous SB request, i.e. the on-chip processor has the SB bit set to statgen. It should be confirmed that it is not claimed in the command register.

[MDL processing]
The MDL (Memory Descriptor List) is first DMAed from the host computer memory to the DDR DRAM on-chip processor memory. The on-chip processor returns an MDL handle to the host based on the MDL DDR address.

  The Send MDL 32 / 64IB including the MDL handle, the offset to the MDL, and the transfer length is analyzed by the IB parser and performs the following operations.

  Read the first entry in the MDL and understand if the specified offset is within this entry. This determination is made by comparing the offset with the length of the first MDL entry.

  If it does not fall within the first MDL entry, the next MDL entry is read. When it finally finds the correct MDL entry, it queues a TX DMA transfer using the address in the MDL. The transfer spans a number of MDL entries from the point where the offset begins.

  When the on-chip processor acquires IB, the on-chip processor programs the offset into socket CB. When the CB gets this information, it can DMA the data. Alternatively, if the host computer knows the offset unexpectedly early, the offset can be programmed into the CB unexpectedly early.

  The transfer threshold specifying the number of bytes that must be DMAed before the RX DMA status message is generated is still applicable in MDL mode.

[Instruction block and status message]
[Overview]
The following description details the instruction block and status message format. The host uses the IB to transfer commands to the IT10G hardware, and the IT10G hardware uses status blocks to transfer information to the on-chip processor and the host computer.

[Instruction block structure]
The only IB that the hardware directly analyzes is the various forms of Send_Command.

[HW analyzed instruction]
These instructions are used to send data and request the IT10G hardware to close or post the receive parameters for a given socket. There are four forms of the SEND instruction to handle TCP, UDP, 32-bit and 64-bit host computer memory addressing.

[ISCSI support]
One embodiment of IT10G uses a host computer to assemble the iSCSI PDU header, while another embodiment uses IT10G hardware and an on-chip processor to assemble and process the iSCSI PDU. Both embodiments are described below.

[ISCSI support]
[Overview]
This section describes IT10G iSCSI hardware support using a host computer to assemble the iSCSI PDU header. IT10G hardware offloads the calculation of iSCSI CRC for transmission and reception, and hardware performs iSCSI framing using a fixed interval marker (FIM) for transmission. Framing is not currently supported for reception.

[Theory of operation]
The iSCSI protocol is specified in the IETF iSCSI Internet Draft, which is a normative document for defining hardware functions. The iSCSI protocol encapsulates SCSI commands in protocol data units (PDUs) transmitted in a TCP / IP byte stream (a SCSI command is a command descriptor block or CDB). SCSI commands are documented in several standards. The hardware receives the iSCSI header segment and the iSCSI data segment from the host iSCSI driver and prepares to send an iSCSI PDU. The hardware receives the iSCSI PDU, calculates the iSCSI CRC, and sends the result to the host iSCSI driver.

  The hardware is primarily related to the external format of the iSCSI PDU, which includes an iSCSI header segment and an iSCSI data segment. An iSCSI PDU consists of a required basic header segment (BHS) followed by zero or more additional header segments (AHS) followed by zero or more data segments. The iSCSI CRC is optional and is included in the iSCSI PDU as a header digest and a data digest. The described arrangement allows the iSCSI header and data to be separated and copied to the host computer memory without requiring an additional memory copy on the host computer.

[ISCSI transmission]
[Overview]
A block diagram of the iSCSI transmit data path is shown in FIG.

[ISCSI control module]
The iSCSI control module 501 receives control signals from the TX DMA engine module 502, the CB access module 503, and the Statgen module 504.

  The iSCSI control module provides control signals to the CB access module 503, the iSCSI CRC calculation module 505, and the FIM insertion module 506. The iSCSI control module calculates an iSCSI PDU length that includes an arbitrary iSCSI CRC word and an optional marker, and provides the iSCSI PDU length that includes the iSCSI CRC word and an optional marker to the XMTCTL MUX module.

  The host iSCSI driver assembles a complete iSCSI PDU header in host memory. The host iSCSI driver then generates a TCP send 32 iSCSI IB or a YCP send 64 iSCSISCIB, depending on whether a 32-bit address or a 64-bit address is required. The host iSCSI then sends a TCP send iSCSI IB, which is received by the on-chip processor. The effect of the host iSCSI driver sending the TCP send iSCSI IB to the on-chip processor is to instruct the iSCSI control module to begin DMA transfer of the iSCSI PDUs to the linked list of buffers in the host computer memory. .

  ISCSI PDUs containing BHS, optional AHS, optional data segments are transferred using TCP send 32 iSCSI IB or TCP send 64 iSCSI IB.

  If the iSCSI PDU is not completely contained in a single DMA transfer, it is difficult to design an iSCSI CRC calculation module that must insert the iSCSI at the end of the iSCSI PDU header segment or at the end of the iSCSI PDU data segment. is there.

  When the iSCSI PDU is as small as 48 bytes (BHS), the overhead of using a single IB for each iSCSI PDU coalesces the iSCSI PDU for a single DMA transfer and then separates the iSCSI PDU for further processing. Is no bigger than overhead.

  The first transport block must be one complete iSCSI PDU header or multiple headers, ie BHS followed by 0, 1, or more AHS, all headers in the first transport block included.

  It is necessary that the first transport block is one complete iSCSI PDU header or multiple headers so that the CRC calculation module can insert the iSCSI header CRC at the end of the iSCSI PDU header.

  The iSCSI control module should check that the TCP send 32 iSCSI IB or the TCP send 64 iSCSI IB contains at least one transport block. This is a necessary condition for correct operation. If this condition is not met, it is an error and the module is not eligible.

  The iSCSI control module initiates the DMA transfer of the iSCSI PDU by requesting the DMA engine module to allow the DMA transfer. When an iSCSI control module request to perform a DMA transfer is accepted, the iSCSI control module is locked access to the DMA engine. The DMA engine is locked until all transfer blocks in the iSCSI IB are serviced. All transfer blocks of the iSCSI IB are serviced when all iSCSI header and iSCSI data information is transferred from host memory to hardware by DMA. The DMA engine signals the iSCSI control module when all iSCSI header and iSCSI data information is transferred from host memory to hardware by DMA.

  The iSCSI control module facilitates execution of FIM and CRC operations and is locked access to the DMA engine to allow for iSCSI login phase.

  Two bits, iSCSI IB, iSCSI CRC select bit 1 and iSCSI CRC select bit 0, are used for iSCSI control if the iSCSI CRC calculation module should calculate iSCSI CRCs other than the iSCSI header and / or iSCSI data. Set by the host iSCSI driver to send signals to the module. These two iSCSI CRC selection bits may take any combination of 1 and 0.

  The iSCSI IB corresponds to a linked list (LL) of buffers in host memory and includes a set of address and length pairs known as transfer blocks. A linked list of buffers in the host memory stores iSCSI header and iSCSI data information. The transport block included in the TCP send iSCSI IB provides iSCSI control module information about where to find the iSCSI header and iSCSI data via a linked list of buffers. The first transfer block of each iSCSI IB points to the iSCSI header of the host memory, and the remaining transfer blocks in the iSCSI IB point to the iSCSI data of the host memory.

The iSCSI control module takes the iSCSI PDU length that includes the CRC word but excludes the marker, and calculates the length of the iSCSI PDU that includes the optional CRC word and the optional marker. The XMTCTL MUX module requires the length of the iSCSI PDU including CRC words and markers to provide the XMTCTL module with the length of the data input to the XMTCTL module.

  The XMTCTL MUX module requires a PDU length that includes any CRC word and any marker before storing the iSCSI PDU in the MTX buffer.

  The iSCSI control module is included in the TCP send 32 iSCSI IB or TCP send 64 iSCSI IB and calculates the length of the iSCSI PDU by using the iSCSI PDU length that includes any CRC word but excludes any marker.

The following information is used to calculate the PDU length containing an arbitrary CRC word and an optional marker.
-FIM interval, marker interval in bytes,
The current FIM count, the number of bytes since the last marker was inserted and stored in socket CB,
A PDU length that is included in a TCP transmission 32 iSCSI IB or a TCP transmission 64 iSCSI IB and includes a CRC word but excludes a marker.

Using two counters, a PDU length counter and a marker counter, the calculation of the PDU length containing any CRC word and any marker is equal to:
1. Initialize the marker counter to zero.
2. Initialize the PDU length counter to the current FIM count.
3. Check the PDU length counter for PDU lengths that include any CRC word but exclude any markers.
4). If the PDU length counter is greater than the PDU length containing any CRC word but excluding any markers, the loop is exited.
5. Add the FIM interval to the PDU length counter and increment the marker counter by one.
6). Go to step 3.
7). A PDU length including an arbitrary CRC word and an arbitrary marker is calculated by adding the length of the marker calculated from the marker count.

[Another FIM algorithm]
1. Initialize total_marker_length to zero.
2. The length_counter is initialized to the next marker (FIM_interval-current_FIM_count).
3. If length_counter> PDU_length, go to step 7.
4). The total_marker_len is incremented by the marker_size.
5. length_counter = length_counter + FIM_interval.
6). Go to step 3.
7). xmitctl obtains total_marker_len + PDU size.

  Note that the last marker must be located if it must be ensured that the marker accurately follows the PDU and correctly handles the case where the current FIM count = 0.

In the above calculation,
The FIM interval comes from CB.
Current_FIM_count comes from CB.
total_marker_length is a time variable for the FIM insertion module.
length_counter is a time variable of the FIM insertion module.
marker_size is the overall size of the FIM marker in bytes.

  FIG. 51 shows an iSCSI transmission flowchart.

[ISCSI CRC calculation module]
The DMA TX module provides iSCSI PDUs to an iSCSI CRC calculation module that consists of an iSCSI header segment and an iSCSI data segment.

  The output from the iSCSI CRC calculation module, which is a PDU containing any inserted CRC word, is provided to the FIM insertion module.

  The iSCSI CRC calculation module calculates an iSCSI CRC value for both the iSCSI PDU header and the iSCSI PDU data.

  The CRC calculation module inserts the iSCSI CRC at the end of the iSCSI PDU header, the end of the iSCSI PDU data, or both, or both. The calculation of the iSCSI CRC is controlled and indicated by the iSCSI CRC selection bit 1 and the iSCSI selection bit 0 of the TCP transmission iSCSI IB.

  The input to the CRC calculation module is a BHS followed by 0, 1 or more AHS in the first transport block, and a BHS followed by 0 or 1 data segments in the second transport block.

  The DMA engine must send a signal to the iSCSI calculation module at the boundary of the transfer block. The iSCSI calculation module must know where the first transfer block starts and ends and where the last transfer block ends. The iSCSI header CRC is always inserted with an iSCSI PDU at the end of the first transport block if the header CRC becomes available. The iSCSI data CRC is always inserted with an iSCSI PDU at the end of the last transport block if the data CRC becomes available.

  It is critical that the first transport block of the IB is a complete iSCSI header (BHS plus 0, 1 or more AHS).

[FIM insertion module]
The FIM insertion module inserts a fixed interval marker (FIM) into the iSCSI PDU, which is equivalent to inserting a fixed interval marker into the iSCSI transmission stream.

  When the FIM insertion module is active, the FIM insertion module inserts only the marker. The FIM insertion module is only active when FIM is set in the CB corresponding to the current iSCSI socket (iSCSI socket CB).

  The FIM insertion module must be able to keep track of the count of the 4-byte word number of each iSCSI stream that contains any CRC bytes that can be inserted by the iSCSI CRC calculation module for each iSCSI socket. The FIM insertion module keeps track of the 4-byte word count by storing two FIM values in the iSCSI socket CB, namely the FIM interval and the current FIM count. Each of these fields, the FIM interval and the current FIM count are measured in 4 byte words.

  The FIM interval and current FIM count can be stored in a 16-bit field.

  If the FIM interval or current FIM count overflows, there should be a qualified failure mechanism.

If a marker is used to enable an iSCSI connection setup that includes the iSCSI login phase, then marker insertion will only begin at the first marker interval after the end of the iSCSI login phase. However, in order to allow the marker inclusion and exclusion mechanism to operate without knowing the length of the iSCSI login phase, the first marker is in the iSCSI PDU stream as if the marker-free interval included the marker. Placed. Thus, all markers appear in the iSCSI PDU stream at the byte position given by:
[(MI + 8) * n-8]
Here, MI = FIM (marker) interval, and n = integer.

  As an example, if the marker interval is 512 bytes and the iSCSI login phase ends with byte 1003 (the first iSCSI positioned byte is 0), the first marker is after byte 1031 of the stream. Inserted.

  The iSCSI PDU stream is defined in the iSCSI Internet draft, but the term used in the Internet draft is a TCP stream. FIM uses payload byte stream counting that includes every byte located by the iSCSI of the TCP stream except the marker itself. This excludes any bytes that TCP counts but does not start with iSCSI.

  The host iSCSI driver initializes the FIM interval and initial FIM count of the iSCSI socket CB by generating an iSCSI FIM interval command block. The on-chip processor receives the iSCSI FIM interval command block. The on-chip processor writes the FIM interval to the socket specific TX_FIM_Interval register and the FIM interval field of the iSCSI socket CB. The on-chip processor writes the initial FIM count to the socket specific TX_FIM_COUNT register and the current FIM count of the iSCSI socket CB.

  The host iSCSI driver controls the FIM state of the iSCSI socket CB by generating an iSCSI set FIM state command block. The on-chip processor receives the iSCSI set FIM status command block. The on-chip processor then writes the FIM state to the FIMON bit in the iSCSI socket CB.

  After initialization of the FIM interval, initial FIM count, and FIM state, the FIM insertion module is in an initialization state waiting for iSCSI IB.

  An attempt to change the FIM state, FIM count, or FIM interval for the current iSCSI socket while FIM is active is an error.

  When the FIM insertion module is waiting for the iSCSI IB and an iSCSI IB is received, the FIM insertion module reads the FIMON bit in socket CB and the current FIM count. If the FIMON bit in iSCSI socket CB is set, the FIM insertion module is active. If the FIM insertion module is active, the FIM insertion module sets the FIM interval counter to the current FIM count from iSCSI socket CB. If the FIM insertion module is not active, the FIM insertion module returns to waiting for iSCSI IB.

  The FIM insertion module is now in a state of counting each 4-byte word of data received from the CRC calculation module. After each 4-byte word in the iSCSI PDU is received by the FIM insertion module that includes any CRC bytes inserted by the iSCSI CRC calculation module, the FIM insertion module decrements the FIM interval counter by one. The FIM insertion module then returns to counting each 4-byte word.

  When the FIM insertion module completes scanning data from the iSCSI socket while counting each 4-byte word, the FIM insertion module saves the current FIM interval counter value to the current FIM count of the current iSCSI socket CB. To do. The FIM insertion module completes scanning of data from the iSCSI socket when all transport blocks in the iSCSI IB have been serviced. At this point, the FIM insertion module is ready for iSCSI IB.

  While in the state of counting each 4-byte word, the FIM interval insertion module inserts a marker in the iSCSI PDU when the FIM interval counter reaches zero. After inserting a marker in the iSCSI PDU, the FIM insertion module resets the FIM interval counter to the FIM interval, reads from socket CB, and then returns to counting 4 byte words.

The marker includes a next iSCSI PDU start pointer equal to the number of bytes to skip in the iSCSI stream up to the next iSCSI PDU header. The FIM insertion module must calculate the next iSCSI PDU start pointer for each marker. To calculate the next iSCSI PDU start pointer, the FIM insertion module must count the number of bytes in the current PDU and measure from the start of the current iSCSI PDU to the marker insertion point that is the current iSCSI PDU byte count. . To count the number of bytes in the current iSCSI PDU, the FIM insertion module uses an iSCSI PDU byte counter. In addition to the current iSCSI PDU byte count, the FIM insertion module must know the start position of the next iSCSI PDU header with respect to the start of the current PDU header. The difference between the start of the next iSCSI PDU header and the start of the current iSCSI PDU header is equal to the current iSCSI PDU length. The FIM insertion module calculates the next iSCSI PDU start pointer as follows.
Next iSCSI PDU start pointer = current iSCSI PDU length-current iSCSI PDU byte count The next iSCSI PDU start pointer is 32 bits long.

  The iSCSI Internet Draft specifies the maximum value MaxRecvPDUDataSize negotiated for the PDU data segment size from 512 bytes to ((224 **)-1) bytes (16777216-1 bytes or about 16 Mbytes).

  The current iSCSI PDU length (measured in bytes) should be at least 25 bits.

  There are several ways to give the FIM insertion module an iSCSI PDU length that includes any CRC word but excludes any marker. One way to provide the PDU length to the FIM module is for the iSCSI host driver to calculate the PDU length.

  The iSCSI host driver calculates the current iSCSI PDU length excluding the iSCSI PDU header CRC or iSCSI PDU data CRC as the sum of 48 bytes (BHS length) + total AHS length + data segment length.

  The total AHS length and data segment length must be calculated in software when they are already included in the BHS.

  The host iSCSI driver then calculates the current iSCSI PDU length that includes any CRC word but excludes the marker. The current iSCSI PDU length that includes any CRC word but excludes the marker is equal to the iSCSI PDU length that excludes the iSCSI PDU header CRC or iSCSI PDU data CRC, +4 bytes if the iSCSI PDU header CRC is enabled, Equal to +4 bytes if iSCSI data CRC becomes available.

  The host iSCSI driver inserts the current iSCSI PDU length that includes any CRC word but excludes the marker into the TCP send 32 iSCSI IB or TCP send 64 iSCSI IB. See the description of TCP send 32 iSCSI IB and TCP send 64 iSCSI IB.

[XMTCTL Mux module]
The XMTCTL mux module receives TCP data from the DMA Tx FIFO buffer and receives iSCSI data from the FIM insertion module.

  The XMTCTL mux module provides data from the DMA TX FIFO buffer or FIM insertion module to the XMTCTL module.

  Function: The XMTCTL mux module operates to multiplex the data input to the XMTCTL module.

  The XMTCTL mux module provides the data length to the XMTCTL module.

  The length of iSCSI data must include any CRC bytes inserted by the CRC calculation module.

  The length of iSCSI data must also include any markers inserted by the FIM insertion module.

  The XMTCTL module uses the size of the input data to separate the data into the appropriate dimensions of the TCP packet, based on MSS or the like. The XMTCTL module generates an appropriately sized packet stored in the MTX memory buffer. Each MTX buffer corresponds to a separate TCP packet.

  The XMTCTL mux module provides data to the XMTCTL module in a 128 bit wide format. Data is sent to the XMTCTL module using the dav / grant handshake.

[ISCSI reception]
[Overview]
The receive DMA engine includes an iSCSI receive data path. The receive DMA data path computes the iSCSI CRC and passes the last iSCSI CRC to the host iSCSI driver via the RX DMA state with the iSCSI CRC message.

[Theory of iSCSI reception operation]
The hardware offloads the iSCSI CRC calculation. The host iSCSI driver controls the receive data path to ensure correct operation of the iSCSI CRC mechanism.

  iSCSI CRC information is transferred between the hardware and the host iSCSI driver in two places. The last iSCSI CRC is part of the RX DMA state with the iSCSI CRC message sent from the hardware to the host iSCSI driver. The iSCSI CRC seed is a part of both the TCP receiving iSCSI 32IB and the TCP receiving iSCSI 64IB transmitted from the host iSCSI driver to the hardware.

  The host iSCSI driver must post a correctly sized buffer in the TCP receive iSCSI 32IB and TCP receive iSCSI 64IB to keep the iSCSI CRC calculation mechanism working properly.

  During the iSCSI recording phase, the host iSCSI driver handles the iSCSI socket in the same way as a normal TCP socket. When the iSCSI recording phase is complete, the iSCSI connection enters the full feature phase.

  When an iSCSI connection enters the full feature phase, the connection is ready to transfer iSCSI PDUs that may contain iSCSI CRC information in the iSCSI header and / or iSCSI data.

  The RX DMA engine sends the last iSCSI CRC calculated via the RX DMA state with the iSCSI CRC message from the scatter set list specified by the TCP receive iSCSI 32IB and TCP receive iSCSI64IB.

  Once the iSCSI recording phase is complete, the host iSCSI CRC driver posts the correct size receive buffer in the iSCSI PDU header. The host iSCSI driver then parses the iSCSI PDU header. The host iSCSI driver then posts the correct size receive buffer for the iSCSI PDU data segment if the data segment exists. Each host iSCSI driver continues to post the correct size buffer for the next iSCSI PDU data segment. The DMA engine calculates the iSCSI CRC for each iSCSI PDU header segment and iSCSI PDU data segment.

  For an iSCSI PDU header, the host iSCSI driver posts the iSCSI basic header segment (BHS) size (48 bytes) and the size of the sum of the iSCSI PDU CRC (4 bytes) if the header CRC is negotiated during the iSCSI login phase. . The BHS is then transferred by the DMA containing the subsequent iSCSI PDU header if present.

  When the BHS DMA transfer is complete, the RX DMA state with the iSCSI CRC message contains the remainder of the final iSCSI CRC calculated by the hardware. The host iSCSI driver receives an RX DMA state with an iSCSI CRC message that includes the remainder of the final iSCSI CRC calculated by hardware. The host iSCSI driver then checks the last iSCSI CRC in the RX DMA state to ensure that its value matches the expected remainder of this iSCSI polynomial. If the header CRC is not negotiated during the iSCSI recording phase, the host iSCSI driver ignores the remainder of the last iSCSI CRC returned in the RX DMA state with the iSCSI CRC message.

  The BHS is followed by an additional header segment (AHS). Byte 4 of the BHS contains TotalAHSLength, ie the total length of AHS. For iSCSI PDU headers that contain AHS and therefore have a length greater than 48 bytes, the host iSCSI driver generates an additional TCP receive iSCSI 32IB or TCP receive iSCSI 64IB for the AHS.

  If iSCSI CRC is enabled, the host iSCSI driver seeds the calculated iSCSI CRC value using the iSCSI CRC seed field in the TCP receive iSCSI 32IB or TCP receive iSCSI 64IB. The use of the iSCSI CRC seed field allows the rest of the iSCSI PDU header CRC to be checked correctly.

  If continuation of the iSCSI CRC calculation is not required, the iSCSI CRC seed in the TCP receive iSCSI 32IB or TCP receive iSCSI 64IB must be set to zero.

  When requesting an iSCSI CRC for a data section of an iSCSI PDU, the host iSCSI driver must specify an extra 4-byte data buffer to store the iSCSI CRC. This 4-byte data buffer is inserted as a final transfer block, and an extra 4 bytes are efficiently added to the end of the link list in TCP reception iSCSI 32IB or TCP reception iSCSI 64IB. The 4-byte data buffer allows the iSCSI CRC of the iSCSI PDU data segment to be transferred outside the iSCSI PDU data stream. The use of a 4-byte buffer is illustrated in FIG.

[Operation theory of RX DMA]
The host driver knows that there is RX data available when receiving the RX DAV status message from the hardware. The notification of the RX DAV status message is the same as a normal TCP connection. The CB handle in the RX DAV status message points to the CB associated with iSCSI. The host driver then allocates a buffer to store RX data, and the total linked list buffer size must be equal to the amount of data that the host driver expects to receive plus the CRC if predicted (see FIG. 52). . Also, since the iSCSI PDU is expected to be in that format, the total buffer size must always be aligned on dword boundaries. The host driver must also initialize the CRC seed to 32'hffffffff.

  When an RX DMA operation is performed, the hardware first extracts the iSCSI CRC seed from the socket CB attachment. The hardware also extracts host retransmission (HR) bits from the main CB structure. The HR bit indicates to other hardware whether this is an iSCSI socket or not. The hardware then calculates a new CRC while transferring data.

  The data stream may or may not include the expected iSCSI CRC value for the PDU header or data segment. If the data stream does not contain an iSCSI CRC digest, the iSCSI CRC calculated by the hardware is stored back to the CB attachment as a working iSCSI CRC. The RX-DMA status message may or may not be generated. If an RX DMA status message is generated, the status message contains this working iSCSI CRC. If the data stream contains an iSCSI CRC digest at its end, the iSCSI CRC hardware computes an iSCSI CRC over the PDU segment that contains the iSCSI CRC digest (which is the expected iSCSI CRC value). If the PDU segment is not corrupted and the iSCSI CRC digest is correct, the final iSCSI CRC value calculated by the hardware is always equal to the remainder of the fixed iSCSI CRC.

  Once all posted buffer lists are filled, the Statgen module generates an RX DMA state with an iSCSI CRC message that includes the remainder of the last iSCSI CRC.

  The on-chip processor operates to process TCP receive iSCSI 32IB or TCP receive iSCSI 64IB. During IB processing, the on-chip processor writes an iSCSI CRC seed that may be 32'hffffffff to indicate the start of a new CRC calculation, or an iSCSI CRC seed from a previous RX DMA status message to the socket CB attachment. Include. In this way, writing the iSCSI CRC seed sets the correct value for the iSCSI CRC.

  For other non-iSCSI mechanisms that use standard receive 32 and receive 64 lbs and follow the RX DMA engine, the CRC mechanism is ignored and the CRC seed is meaningless and can be skipped.

  Before an RX DMA operation is performed, the peer sends one or more TCP packets that contain a data payload that is ultimately transferred to the host memory by the DMA. Depending on how the peer's network stack operates, this payload can be divided into non-dword aligned boundaries even though iSCSI requires all PDUs to align themselves at dword boundaries. The DMA operation does not directly match the size of the payload of each TCP packet. If the payload is non-dword aligned, the DMA operation is non-dword aligned and it is required to calculate the CRC through this non-dword aligned data stream. The problem is that the iSCSI CRC hardware predicts that all data will be dword aligned.

  As the iSCSI CRC hardware encounters this area, it continues to calculate the iSCSI CRC through the unaligned data stream. When it reaches the end, it stores 1-3 bytes of non-double word aligned to the CB's attachment. It also stores the number of valid bytes. For example, if the data stream is 15 bytes long, the hardware stores the last 3 bytes and the effective number of bytes is 3. If the data stream is 32 bytes long, the number of valid bytes is 0 because this data stream is dword aligned. The information stored in the CB attachment is retrieved and inserted before the next DMA transfer.

[ISCSI instruction block]
The TCP send iSCSI command block (IB) is used to send iSCSI PDUs using an iSCSI socket. The length of the TCP transmission iSCSI 32IB is variable because this IB can contain one or more transfer blocks used in DMA transfer. A transfer block consists of a pair of address (header or data) and transfer length.

  The iSCSI CRC selection bit 1 and the iSCSI CRC selection bit 0 determine the calculation of the iSCSI CRC by the iSCSI control module. If the iSCSI CRC selection bit 0 = 1, the iSCSI control module calculates the iSCSI CRC over the iSCSI header. If the iSCSI CRC select bit = 1, the iSCSI control module calculates the iSCSI CRC over the iSCSI data. The iSCSI CRC calculation can be performed by the iSCSI CRC calculation engine over both iSCSI header and iSCSI data, iSCSI data only, iSCSI header only, or otherwise.

  The total DMA length of iSCSI is the length of the entire data that needs to be DMAed by the iSCSI transmission block. This does not include the CRC length that needs to be calculated.

  The address and transfer length pair of the first transfer block of the TCP transmission iSCSI 32IB points to the iSCSI header in the host memory. The second and optional further transfer blocks of the TCP send iSCSI 32IB point to the iSCSI data in the host memory.

  An iSCSI PDU containing a BHS, an optional AHS, and an optional data segment is transferred using a TCP send 32 iSCSI IB or a TCP send 64 iSCSI IB.

  The first transport block of a TCP send iSCSI 32 IB must be a complete BHS followed by one or more iSCSI PDU headers, 0, 1, or more AHS, and all singular or multiple headers are TCP send iSCSI 32 IB Must be included in the first transfer block.

  To say the same in different ways to emphasize, the host iSCSI driver must include any iSCSI data segment with an iSCSI header segment in the TCP send iSCSI 32IB. The iSCSI data segment must be present in the TCP send iSCSI 32IB in a separate transport block from the iSCSI header segment.

  The host memory address of each transfer block of the TCP transmission iSCSI 32IB is 32 bits. If a 64-bit address is required, TCP send iSCSI 64IB should be used.

  The format of a TCP send iSCSI 32IB having three transport blocks clearly illustrated is described below.

  CRC select bit 0 and CRC select bit 1 are stored in separate words in the IB rather than the unused portion of the first transfer block in order to make the processing of each transfer block similar.

  The TCP receive iSCSI 32IB is used to post a buffer to be used to receive on an iSCSI socket.

  The length of the TCP receive iSCSI 32IB is variable because this IB consists of an optional number of transfer blocks used for DMA transfer. The transfer block of the TCP reception iSCSI 32IB is composed of a pair of address and transfer length.

  The iSCSI CRC seed is used to seed the iSCSI CRC engine before DMA and iSCSI CRC calculations begin. The iSCSI CRC seed must be set to 32'hffffffff if iSCSI CRC is requested. If the iSCSI CRC is not requested, the seed value set is inappropriate.

  Description: If no iSCSI CRC calculation is required, there is no need to set the iSCSI CRC seed to zero.

  The address length of each transfer block in the TCP reception iSCSI 32IB is 32 bits. For 64-bit addressing, TCP receive iSCSI 64IB must be used.

[Another iSCSI configuration]
The above description details the operation of IT10G using a host computer to assemble the iSCSI PDU header. Another embodiment allows IT10G hardware and on-chip processors to assemble and process iSCSI PDUs. This alternative embodiment will now be described.

  This section describes iSCSI hardware support through the use of on-chip processors. From the high level, the hardware offloads the CRC and fixed interval marker (FIM) of the transmitted packet. In the received data path, the ability to DMA the PDU header to the on-chip processor or host computer and DMA the data section of the PDU to the host is supported along with a CRC check. This allows the iSCSI header and data to be separated and copied to the host computer memory without requiring an additional memory copy at the host computer.

[Header storage device (HSU)]
For transmitted iSCSI PDUs, the on-chip processor operates to build the packet header in its memory. The on-chip processor receives an iSCSI command block (IB) from the host computer to indicate the type of iSCSI PDU generated. If there is SCSI data associated with the PDU, a linked list of buffers is also provided via the IB.

  Once the on-chip processor generates a PDU header, it uses the HSU module to transfer the header from the on-chip processor memory to the MTX memory (transmit data buffer). The HSU also calculates the header CRC if necessary.

  If there is no SCSI data associated with the PDU, it begins to transfer data from on-chip processor memory to MTX memory as soon as the HSU module is available. If necessary, the CRC is also calculated and the FIM is inserted.

  If there is SCSI transferred in the PDU, two modes of DMA are given, one shot and link list. If link list mode is used, the HSU retrieves the first link list (LL) entry and requests a host DMA transfer. When the DMA engine indicates to the HSU that the first transfer has been completed, the HSU starts transferring the header from the ARM memory to the MTX memory. The data just DMAed is attached to the end of the header. Also during this time, the next LL entry is retrieved and the DMA is requested. Once the HSU is granted host DMA transfer, it locks access to the DMA engine (at least on the TX side) until all entries in the LL are serviced. This makes it easy for FIM and CRC logic units to run in the data path.

[CRC calculation module]
This module operates to calculate CRC values for both the PDU header and the data section. The CRC is then attached to the corresponding field. The data providing this module can come from on-chip processor memory via HSU (for header data) or from DMA TX FIFO (for SCSI data). The output from the CRC calculator is provided to the FIM module.

[FIM insertion module]
This module operates to insert the FIM into the PDU. This receives the initial offset, interval count, and PDU length from the HSU unit. When inserting a FIM, some repacking of data will be required. Another function of this module is to determine the total length of transmitted PDUs. This length is the programmed length of PDU + any CRC byte + any FIM. This length is then sent to the XMTCTL module, which operates to break the PDU into appropriately sized TCP packets.

[XMTCTL Mux module]
This module operates to multiplex data input to the XMTCTL module. Data is directly from the DMA TX FIFO buffer or FIM insertion module. With either path, the multiplexing logic unit indicates the total length of the packet and provides data in a 128 bit wide format. Data is sent to the XMTCTL module using a dav / grant handshake.

[ISCSI reception support]
[Overview]
A block diagram of the iSCSI receive data path is shown in FIG.

[TCPRX module]
This module 531 operates to analyze the received TCP packet. When an iSCSI packet arrives, it is stored first in the MRX memory with a 128 byte or 2K byte buffer, so it is treated first like any other TCP data. The socket CB bit (WORD 0xD, bit [30]) indicates whether this socket is owned by the host or on-chip processor. If the socket is owned by the on-chip processor, the data is not automatically DMAed to the host. Instead, status messages are generated and sent to the on-chip processor via the normal network stack status message queue.

[On-chip processor access to MRX memory]
When the on-chip processor is informed that the socket is receiving iSCSI data, the data in the MRX can be read via the CPU address and the data register of the mallocrx register set. It is expected that the on-chip processor is primarily reading the MRX memory 532 to determine the PDU type received from the header therein. If the on-chip processor decides to move the header to its memory, it uses the LDMA module. If it is decided to DMA and PDU data to the host, the HDMA module 533 is used.

[RXISCSI module]
The RXISCSI module is used when the on-chip processor wants to move data from the MRX memory to its own local memory. The CRC of the data is selectively checked during this transfer. When the operation is complete, an interrupt or status message is generated.

  If the data spans multiple MRX buffers, the transfer must be divided into two requests. An example of this is shown in FIG.

  In this case, the first transfer is programmed with Add1 as the MRX source address and Length1 as the transfer length. The LAST_BLK bit is also not set for the first transfer. When the operation is complete, a partial CRC result is also returned in the status message. The on-chip processor then programs the local DMA (LDAM) with Add2 and Length2, and sets the LAST__BLK bit to end the header transfer. If the operation is continuous, the CRC seed need not be programmed. Otherwise, the CRC partial result returned in the status message should not be programmed as a CRC seed for the second transfer. If only CRC bytes remain in the second buffer, a zero length transfer should be used with the CRC check enabled.

[HDMA started with on-chip processor]
When the on-chip processor wishes to send the received SCSI data to the host, it programs a host DMA (HDMA) engine with a transfer length in both MRX and host memory with a start address. Instead, the on-chip processor can identify the location in its memory where the linked list of buffers is located.

  The linked list can contain up to 255 entries. During a DMA transfer, the HDMA module can optionally be programmed to check the CRC value. If this option is enabled, the DMA transfer length must not include CRC bytes. Also, an optional CRC start seed can be programmed when a CRC check is requested.

  If the SCSI data is split across multiple MRX buffers, the DMA transfer to the host must be split into separate requests. This state is shown in FIG.

  In this case, the HDMA must first be programmed with Add1 as the starting MRX memory address and Length1 as the transfer length. The Last_Host_Blk bit must also not be set for the first transfer. A status message is generated when the DMA operation is complete. If a CRC check is also requested, the status message also returns a partial checksum value. The on-chip processor then programs the HDMA engine with Add2 and Length2, and sets the LAST_Host_Blk bit to end the data transfer. If these two transfers are consecutive, the CRC seed value need not be programmed. Otherwise, the partial CRC result returned in the status message is programmed as part of the second DMA transfer request. If only CRC bytes remain in the second buffer, a transfer of length = 0 and CRC_En = 1 must be used.

[Release MRX buffer of on-chip processor]
In sockets owned by the on-chip processor, the on-chip processor operates to release MRX buffers that are no longer used to the MRX buffer deallocator. This is done by writing the base address for the block to be released to the MRX_128_Block_Add or MRX_2K_Block_Add register and then issuing a release command to the corresponding MRX_Block_Command register.

[IPSec support architecture]
[Overview]
The following description details the support performed in hardware for IPSEC. This configuration assumes separate modules to handle the computer characteristics of protocol encryption, decryption, and authentication functions, all of which are well known and understood. The configuration also assumes that any well-known and well-understood and used key exchange protocol such as IKE is processed as an application on the host computer. Of course, the key exchange function can also be integrated.

  This description divides IPSEC support into transmit and receive sections. This is done because the two modules operate independently of each other in addition to sharing a common security association (SA) block.

IPSec characteristics:
・ Anti-replay support for each SA,
Zero, DES, 3DES algorithm, and AES 128-bit algorithm in cipher block chaining (CBC) mode,
・ Zero, SHA-1, MD-5 authentication algorithm,
A variable length encryption key up to 192 bits,
-Variable length authentication key up to 160 bits,
・ Jumbo frame support,
Automatic processing of SA expiration based on time and total data transferred,
-IPsec policy enforcement,
IPsec exception handling including exception packet generation and status notification.

IPsec protocol and mode:
・ Transfer AH,
・ Transfer ESP,
・ Transfer ESP + AH,
・ Tunnel AH,
・ Tunnel ESP,
・ Tunnel ESP + AH,
・ Transfer AH + Tunnel AH,
・ Transfer AH + Tunnel ESP,
・ Transfer AH + Tunnel ESP + AH,
・ Transfer ESP + Tunnel AH,
・ Transfer ESP + Tunnel ESP,
・ Transfer ESP + Tunnel ESP + AH,
・ Transfer ESP + AH + Tunnel AH,
・ Transfer ESP + AH + Tunnel ESP,
Transfer ESP + AH + tunnel ESP + AH.

[Security-related block format (SA)]
A dedicated memory structure is used to store information on each IPSEC connection. Separate blocks exist for both AH and ESP protocols, and RX and TX SA (RX SA cover data is received and TX SA cover data is transmitted). Therefore, socket connections that use both AH and ESP for both sending and receiving data require multiple SA blocks. AH requires one SA block and ESP requires two blocks (ESP-1 and ESP-2). The total number of socket connections to be secured depends on the total amount of memory given to the SA block.

  The Tx data path can support tunnel and transfer mode with a single transfer. In the worst case scenario, six SA blocks can be concatenated together if both AH and ESP are used in both tunnel and transfer modes. For transmitted data, socket CB contains a pointer to tunnel / forward TX AH or tunnel / forward TX ESP-1 SA. If both protocols are used in the transmitted data, the CB contains a link to the TX AH SA, which contains a link to the TX ESP-1 SA.

  The Rx data path does not support AH and ESP decoding in a single transfer. The Rx data path does not support tunnel and transfer mode with a single transfer. Encrypted packets are repeatedly decrypted. In the received data, RX_SA_LUT contains a pointer to RX AH or TX ESP-1 SA.

  FIG. 56 shows the SA block flow.

[Create client socket]
When an application needs to create an IPSEC protected client socket, the following sequence must be performed:
• Write all applicable SA parameters to the IPSEC SA specific register. This requires the generation of a large number of write commands. The SA handle is inserted into the RX SA LUT.
• IPSEC returns a new SA handle.
• Write this SA handle to the socket specific register.
Write all applicable socket parameters, including the setting of the IPSEC bit of the socket structure 2 register, to the CP socket specific register.
Generate a commit_socket command.

  The link to TX SA is stored in open CB. The socket is now ready for use.

[SA generation of server socket]
When an application needs to create an IPSEC protected server socket, the following sequence must be performed:
• Write all applicable SA parameters to the IPSEC SA specific register. This requires the generation of a large number of write commands. The SA handle is inserted into the RX SA LUT.
• IPSEC returns a new SA handle.
• Write this SA handle to the socket specific register.
Write all applicable socket parameters, including the setting of the IPSEC bit of the socket structure 2 register, to the CP socket specific register.
Generate a commit_socket command.

  In addition to generating the server port information table entry, the commit socket command also generates a HO CB. The HO CB has an IPSEC bit set in it. This bit prevents the HO CB from being reused by another incoming SYN that happens to decode to the same HASH. The TX SA handle is stored in the HO CB. The socket is now ready for use.

  Note: In this case, as mentioned above, the HO CB is not overwritten when a SYN with the same HASH is received. The HO CB is replicated when the socket is transitioned to the configured state and an open CB is created. However, if the socket fails to reach the configured state, the host operates to manually replicate the HO CB. This is done by entering the HO CB handle into the HO_CB handle register and then generating a Deprecate_HOCB command. A host in this state must replicate the associated SA block.

[SA link]
The SA block has a link valid bit and a link field, which points to another SA. The CPU can use this field to link multiple SAs if necessary. The CPU must execute the following sequence to connect the SA blocks.
-The SA_Link register is configured by the connected SA blocks.
• Set the Link_Val bit in the CFG1 register.
-The SA_Handle register is configured by the connected SA blocks.
Generate an “update SA” command.

[SA replication / deallocation]
Tx or Rx SA blocks are not automatically replicated when CBs are replicated. The CPU generates a “SA Disable” command to keep track of unused SA blocks and to replicate / deallocate those SA blocks.

  When the SA expires, an interrupt is generated if the HW is not masked. Expired SA blocks are not deallocated from memory. This event also generates a status message containing the SA handle of the expired SA. The CPU can use this handle to update this SA, or the CPU can generate a “SA Invalidate” command to replicate / deallocate that SA block.

[TX AH transfer SA block format]
FIG. 57 shows the TX AH transfer SA block format.

[TX ESP-1 transfer SA block format]
FIG. 58 shows the TX ESP-1 transfer SA block format.

[TX ESP-2 transfer SA block format]
FIG. 59 shows the TX ESP-2 transfer SA block format.

[TX AH tunnel SA block format]
FIG. 60 shows a TX AH tunnel SA block format.

[TX ESP-1 Tunnel SA Block Format]
FIG. 61 shows the TX ESP-1 tunnel SA block format.

[TX ESP-2 tunnel SA block format]
FIG. 62 shows the TX ESP-2 tunnel SA block format.

[RX AH SA block format]
FIG. 63 shows the RX AH SA block format.

[RX ESP-1 SA block format]
FIG. 64 shows the RX ESP-1 SA block format.

[RX ESP-2 SA block format]
FIG. 65 shows the RX ESP-2 SA block format.

[Definition of security-related block fields]
[SA type]
These bits are used to identify the type of SA block that the block represents and are provided for diagnostic support. Decoding is shown in the table below.

  All other decryptions not shown in the table above are reserved for future use.

[SA version]
These bits specify the SA version number and are provided for diagnostic purposes. The current version of all SA block types is 0x1.

[XV, RV (valid transmission / reception SA)]
These bits indicate that the SA block is valid and can be used.

[XA, RA (Enable Send / Receive Authentication)]
These bits indicate that authentication is enabled for this protocol and should be used in packets on this socket. Corresponding authentication algorithms and key fields are also valid. In TX / RX AH SA, this bit should always be set. In TX / RX ESP SA, this is optional.

[XA_ALG, RA_ALG (transmission / reception authentication algorithm)]
These bits indicate the algorithm used for authentication. The possible choices are listed in the table below.

  All decryptions not shown are reserved for future use.

[XE, RE (Transmit / Receive Encryption Enable)]
These bits indicate that encryption should be used for this socket packet and that the encryption key and encryption algorithm fields are valid. This bit is specified only for TX / RX ESP SA.

[XE_ALG, RE_ALG (transmission / reception algorithm)]
These bits indicate the algorithm used for encryption. The possible choices are listed in the table below.

  All other decryptions not shown are reserved for future use.

[RAR (Reception Anti-Replay Enable)]
This bit indicates that the anti-replay algorithm should be used in the received packet.

[XTV, RTV (transmission / reception time stamp valid)]
These bits indicate that the time stamp field is valid for SA, and when the time stamp expires, the SA block should be considered stale.

[XBV, RBV (transmission / reception byte count valid)]
These bits indicate that the byte count limited field is valid in SA and that when the byte count reaches this value, the SA block should be considered stale.

[XSV, RSV (valid for transmission / reception sequence only)]
These bits indicate that the SA block should be considered stale when the sequence number field wraps 0xFFFFFFFF.

  Note: If all xTV, xBV, or xSV bits are not set, the SA block is considered persistent and never expires.

[RDC (Reception destination IP check enable)]
This bit indicates that the destination IP address of any packet must match the destination IP address field of this SA.

[RSC (Receive SPI Check Enable)]
This bit indicates that the SPI field of the IPSEC header must match the destination IP address field of this SA.

[RTR (Received / Disabled Received Timestamp Watermark Limited)]
If this bit is not set, a timestamp watermark check can be performed. When this generates a status message, this bit is set so that no further watermark status message is sent.

[LV (link valid)]
This bit indicates that the SA block is linked to this SA. When this bit is valid, the link field contains the SA handle of the next SA block.

[SPI number]
This is the SPI associated with the protocol. In TX SA, this SPI is included in the protocol header. In RX SA, this SPI is compared against the corresponding field of the received data packet.

[Sequence number]
This is the sequence number associated with the protocol. Since AH and ESP SA expire to different secretaries, the sequence numbers are different between the two protocols. In TX SA, this sequence number is reset to 0x00000000 when the SA is generated and incremented by 1 for each packet transmitted using the SA block. For received packets, this field represents the last sequence number received on the socket and is used to check with packet replay.

[Authentication key]
This parameter is the key used for protocol authentication. If the key is smaller than 160 bits, it should be assumed lsb correct.

[Encryption key]
This parameter is a key used for encryption of IPSEC packets and is specified only for TX / RX ESP SA. For algorithms that use bits smaller than 192 bits, the key should be lsb correct.

[Time stamp]
This is a future time stamp when the SA block is considered old. It is initialized when the SA is generated. When a packet is sent or received, the current free running millisecond timestamp is compared to this time. If the time matches or exceeds this timestamp, the SA block is considered stale.

[Byte count]
This parameter is set when the SA is initialized. Determine the maximum number of bytes that can be sent using the SA block. The HW uses this as an initial number for the decrement counter. The HW decrements this byte count when a packet is sent or received on this SA. When the byte count reaches zero, the SA is considered stale. If this limit is used, the xBV bit should be set.

[Link]
This field points to the next SA block associated with the socket.

[IPsec module]
IPsec is divided into the following four main modules.
・ IPSECX,
・ IPSECR,
・ IPSECREGS,
IPSEC memory.

  IPSECX includes the transmission data path logic of IPSEC. Data and control packets are first transferred to the internal IPSECX memory. The encryption engine reads these packets, encrypts them, and writes these packets back to IPSECX memory. These packets are then forwarded to an Ethernet transmitter for transmission.

  IPSECR contains the IPSEC receive data path logic. Any incoming packet is parsed against an IPSEC type packet. If the packet is an IPSEC packet, it is transferred to the internal IPSECR memory. The decryption engine decrypts these packets and writes them back to the IPSECR memory. This packet is read and injected back into the network stack. At this time, since this packet is decrypted, the parser does not identify it as an IPSEC packet, but identifies it as a normal TCP / IP packet.

  IPSECREGS contains programmable registers for the CPU. By programming these registers, the CPU generates and updates or deletes the SA. This module performs indirect memory accesses to the internal memory for diagnostic purposes.

IPSEC uses two SRAMs as shown in the following figure. Both memories can hold 9KB size packets. The IPSEC memory size is shown below.
IPSECX memory: 592 x 32 bits x 4 dual ports (9472 bytes),
IPSECR memory: 1168 × 32 bits × 2 dual port (9344 bytes).

  FIG. 66 is a block diagram showing the overall flow of the IPSEC logic device.

[IPSEC transmission data path (IPSECX)]
[Overview]
The following description is the details of the transmission IPSEC data path. The IPSEC encryption / authentication engine operates on packets that occur before it is invoked. A block diagram outlining the data flow is shown in FIG.

[Data flow of packets transmitted by IPSEC]
[TXDATCB / TCPACK]
The transmission data for the IPSEC protected socket is first stored in the MTX DRAM 671 in the same way as a normal socket. The TXDATCB / TCPACK module 672 operates to form Ethernet, IP, TCP, and arbitrary IPSEC headers for packets. This module reads the information from the appropriate SA block to determine which header and the required header format. Each socket has a CB structure associated with it. The CB contains old information for each socket. Within the CB structure there is a pointer to the SA block used. For sockets that require multiple SA blocks, the CB contains pointers to all AH and ESP1 SA blocks.

  The TXDATCB / TCPACK module writes the packet header to a buffer in the MTX DRAM. When the packet is found to require IPSEC processing, the TXDATCB / TCPACK module notifies the IPSECXIF module 673 that there is a packet ready for processing. At the beginning of the header generation process, if the TXDATCB / TCPACK module notices that the IPSECXIF block is full, it returns the packet to the transmit queue for later processing.

[TCPACK]
In addition to data packets, TCP utility packets (ACK, SYN, FIN) can also be encrypted. These packets come from the TCPACK module. Although not shown in the previous data path of FIG. 67, this module also accessed the CB and SA memory.

  Note: RST packets generated because the local socket is not available are not IPSEC protected. The only protected RST is a packet that responds to an illegal SYN / ACK that is used for termination termination or received in response to SYN. Both of these RST packets are formed by the TCPACK module rather than the normal RST packet queue.

[IPSECXIF]
This module operates to transfer packets (via TCPDATCB) from MTX DRAM or TCPACK to IPSECX internal memory. This internal memory is organized as 576 × 128 bits. When it gets a packet from TXDATCB or TCPACK, this module starts transferring data to the IPSEC memory. It also obtains information applicable to the SA from the SA register in order to send it to the encryption engine. The read pointer is fed back from IPSECTX to prevent this module from overwriting the current packet in IPSECX memory.

[Encryption / Authentication Engine]
This module 674 operates to add encryption and authentication to the packet. It takes the parameters provided by the IPSECXIF module and processes the packets stored in the IPSECX memory 675. If both authentication and encryption are required in a packet, this module is assumed to be before both properties before forwarding the packet to the IPSECTX module. The encrypted data should be written to the same memory location as the source packet. When processing is complete, it informs the IPSECTX module that the completed packet is ready for transmission. The encryption engine operates entirely in the drum_clk domain.

  This module consists of two identical encryption engines in parallel. In this case, they are serviced in an alternating order. Also, when the encrypt_rdy indicator is sent to IPSECTX, the packets given must be in the same order as they were given to the encryption engine.

[IPSSECTX]
This module 676 operates to retrieve the processed packet from the encryption engine and schedule it for transmission. When a preparation completion instruction is received from the encryption engine, the start address and packet length information are registered. Thereafter, the transmission request is transmitted to the Ethernet (registered trademark) transmission arbitrator. The Ethernet (registered trademark) transmission arbitrator reads packet information directly from the IPSECX memory and transmits it to the MAC transmission buffer. When the entire packet is read, this strobes opticx_done. When receiving this indication, the IPSECTX module updates its opticx_rd_add. This bus is returned to IPSECXIF to indicate that more memory has been freed.

[IPSECX Memory Arbitrator (IPSECX MEMARB)]
This module 677 operates to arbitrate access to the IPSECX memory bank. This module operates in the drum_clk domain.

[IPSECX Memory Interface (IPSECX MEMIF)]
This module 678 provides an interface to the dual port RAM. This module couples between the SRAM and other logic devices that access the RAM. This module needs to be changed when the RAM model is changed. This module works entirely in the drum_clk domain.

[IPSEC Receive Data Path (IPSECR)]
[Overview]
The block diagram of FIG. 68 shows the data path flow of the received IPSEC packet. This forms the basis for the following explanation.

[Data flow of IPSEC received packet]
[IPIN]
The received data of the IPSEC protected socket is first analyzed by the IPIN module 687. In the outermost IP header, there is a protocol field indicating the protocol type of the next header. If it detects that the protocol is 0x50 (ESP) or 0x51 (AH), it completes the packet containing the outermost IP header for the IPSECRIF module.

  If the received packet is fragmented, it is treated like any other fragmented IP packet and sent to the exception processor. When the packet is complete, it is reinjected into the bottom of the IP stack via the IPINARB module 682.

[IPSECRIF]
When IPIN indicates to this module 683 that an IPSEC packet has been received, it begins to store the packet in the IPSECR memory 684. The packet starts to be stored from the header, and immediately after that the outermost IP header is stored. The IPSECRIF module also analyzes the SPI, source IP address, and AH / ESP settings to perform LUT discovery to find the correct RX SA block. When obtaining the LUT value, it reads the SA block and checks if its parameters match the parameters of the received packet. If they match, you will have the appropriate SA. If not, the packet is dropped and the event is recorded.

  When the correct SA block is found, the received SA parameters are read and stored. If the anti-replay feature is enabled for this SA, the sequence number is checked to see if it is valid. If this is good, the SA parameter is transferred to the decryption module 685 along with the starting memory address in the packet's IPSECR memory. If the sequence number is not valid, the packet is dropped and the event is recorded. However, the sequence number and sequence bitmap are not updated at this time. The purpose of the anti-replay check in this respect is to prevent a bad packet from being unnecessarily decoded and authenticated. Anti-replay updates are processed in the IPSECRX module 686 after the packet is authenticated.

[Encryption / Authentication]
This module 685 operates to decrypt and authenticate IPSEC packets. When the packet is available, the IPSECRIF module indicates this to the decryption engine by asserting the ipsecrif_rdy signal. The IPSECRIF module also provides the starting address of the packet. If the packet fails authentication, it is discarded and the event is recorded. If authentication passes, the packet is decrypted if necessary. The decrypted packet is written back to the same IPSECR memory location as the original packet. The decryption engine then indicates to the IPSECRX module that the packet is ready to be received by asserting decrypt_rdy. If a packet requires both authentication and decryption, it is assumed that both functions are completed before performing the process of turning the packet off to the IPSECRX module.

  This module consists of two identical decoding engines in parallel. In this case, they are serviced in an alternating order. Also, when the decrypt_rdy indicator is sent to IPSECRX, the given packets must be in the same order as they were given to the decryption engine.

  Note: The decryption / authentication engine operates off the DRAM clock.

[IPSECRX]
This module 686 operates to take the decrypted / authenticated packet and reinject it into the stack. For tunnel mode packets, the processed packets can be injected back directly via IPINARB. For transfer mode packets, an IP header is generated and prepended to the start of the packet. By doing this, it is possible to reuse the IPIN internal TCP checksum and interface logic for all packets.

  This module also operates to update the received SA block of the packet. The new sequence number and bitmap for the SA is transferred from the decryption engine to the module along with the SA handle. This module updates the received timestamp and byte count. If this finds that any parameters have reached their limits, the SA is invalidated and a status message is sent to the exception processor.

[IPSECR Memory Arbitrator (IPSECRMRMARB)]
This module 687 operates to arbitrate access to the IPSECR memory bank. This module operates in the drum_clk domain.

[IPSECR Memory Interface (IPSSECR MEMIF)]
This module provides an interface to the dual port RAM. This module couples between the SRAM and other logic devices that access the RAM. This module needs to be changed when the RAM model is changed. This module works entirely in the drum_clk domain.

[IPSEC LUT]
This LUT is organized as 128K by 17 bits. Each word consists of a 16-bit SA handle and a 1-bit valid indicator. Physically the LUT is contained within the MTX DRAM bank.

[IPARB]
This module arbitrates traffic coming from the Ethernet input parser and IPSECRX.

[IPSEC Anti-Replay Algorithm]
This is an algorithm used for anti-replay check inspection. This algorithm uses a 32-bit window to check the last 32 sequence numbers. In the bitmap, msb represents the oldest sequence number, and lsb represents the current sequence number. This algorithm is used for both AH and ESP protocols.

LAST_SEQ: Last received sequence number. This is stored in the SA block.
SEQ: Sequence number of the received packet.
BITMAP: A 32-bit bitmap representing the last 32 sequential sequence numbers.

  FIG. 69 is a flowchart showing the IPSEC anti-replay algorithm.

[IPSEC register (IPSECREGS)]
[Overview]
This module provides an interface to the CPU and includes programmable registers. This module also generates, updates, or invalidates the SA when the CPU issues an appropriate command. This provides indirect access to the following memory for diagnostic purposes:
・ IPSECX,
・ IPSECR,
・ RX SA LUT,
-SA block.

[IPSEC SA status message]
For both receive and transmit SA blocks, a status message is generated to the on-chip processor whenever the block becomes invalid. Blocks can become invalid when the sequence number reaches 0xFFFF or when the time stamp or byte count reaches their limit.

[SA block and data flow for DRAM interface]
[Overview]
The following description is an overview of the interface for accessing the SA block via the NS DDR arbitration module. This shows the data flow, lists the interface signals, and details the required timing.

[data flow]
Three different access types are supported in the SA block. These are burst write, burst read, single read. The ipsecsarb module arbitrates requests from different sources to access SA memory.

[SA LUT]
[Overview]
The IPSEC receiving logic uses the LUT to find the appropriate SA block. The LUT is 16 bits × 32K deep. Each LUT block contains an SA block handle. If the SA handle has the value 0, this is considered invalid.

[SA LUT to DRAM interface]
The following description is an overview of the interface between the SA LUT and the data DDR arbitration module. It shows the data flow, lists interface signals, and details the required timing.

[data flow]
The SA LUT only has a single read and write access to the DRAM. The access is always in WORD. Since each LUT block is only 16 bits, only the lower 16 bits of the WORD are transferred to the SA LUT memory interface. Reading and writing are not done in the same LUT access cycle.

  Although the present invention has been described herein with reference to preferred embodiments, those skilled in the art will readily recognize that the applications described herein can be substituted for other applications without departing from the scope of the invention. Will. Accordingly, the invention should be limited only by the claims.

Claims (79)

An integrated network adapter that decodes and encodes network protocols and processes data,
Wired data paths for processing streaming data,
A wired data path to send and receive packets and to encode and decode packets;
Multiple parallel, wired protocol state machines; and
Wired transfer offload engine (TOE),
A processor integrated with the TOE;
Optimized hardware support for network address translation (NAT), IP masquerading, and port forwarding with port range registers that forward all UDP or TCP packets entering the programmable port range to the exception path A module to provide,
A means of scheduling shared resources based on traffic,
With
The plurality of protocol state machines are optimized for a particular network protocol;
The protocol state machine performs processing in parallel;
The port range register allows a range of ports to be used in network control operations and port forwarding;
Integrated network adapter characterized by that. An integrated network adapter composed of a single integrated circuit,
Wired transfer offload engine (TOE),
A processor integrated with the TOE;
A physical layer module (PHY);
A media access layer module (MAC);
An IPsec processing engine integrated with the TOE;
An upper level protocol (ULP) for offload processing integrated with the TOE;
Optimized hardware support for network address translation (NAT), IP masquerading, and port forwarding with port range registers that forward all UDP or TCP packets entering the programmable port range to the exception path A module to provide,
With
The port range register allows a range of ports to be used in network control operations and port forwarding;
Network adapter. The ULP implements the iSCSI protocol;
The network adapter according to claim 2. The ULP offloads the calculation of the iSCSI CRC for transmission and reception;
The network adapter according to claim 3. The ULP performs iSCSI framing using a fixed interval marker (FIM) for transmission;
The network adapter according to claim 3. The TOE obtains an iSCSI header segment and an iSCSI data segment from the host iSCSI driver and prepares an iSCSI PDU for transmission.
The network adapter according to claim 3. A host iSCSI driver present in the host computer;
The host iSCSI driver communicates with the TOE;
The network adapter according to claim 3. The TOE receives an iSCSI protocol data unit (PDU), calculates an iSCSI CRC, and sends the iSCSI CRC to the host iSCSI driver.
The network adapter according to claim 7. The host iSCSI driver seeds the calculated iSCSI CRC value using the iSCSI CRC seed field of the iSCSI instruction block (IB);
The network adapter according to claim 8. The host iSCSI driver assembles a complete iSCSI protocol data unit (PDU) header in host memory, generates an iSCSI command block (IB), and sends the iSCSI IB to the TOE.
The network adapter according to claim 7. The iSCSI IB corresponds to a linked list of buffers in the host computer memory and includes a set of address and length pairs known as transfer blocks.
The network adapter according to claim 10. The host iSCSI driver stores the CRC bytes by adjusting the buffer size of the final transfer block when receiving iSCSI data, and accurately separates the iSCSI header from the data segment.
The network adapter according to claim 11. An iSCSI protocol data unit including a corresponding basic header segment (BHS), an optional additional header segment (AHS), and an optional data segment is sent to the host iSCSI driver and the TOE using an iSCSI command block (IB). Transmitted between
The network adapter according to claim 7. The host iSCSI driver posts the correct size receive buffer for the iSCSI PDU header and, if a data segment is present, posts the correct size receive buffer for the iSCSI PDU data segment. Divide the iSCSI protocol data unit (PDU) header and data segment into
The network adapter according to claim 7. The host iSCSI driver posts a precisely sized buffer of any additional header segment (AHS) received using the instruction block;
The network adapter according to claim 14.   8. The network adapter according to claim 7, wherein the TOE and the host iSCSI driver interface at an iSCSI PDU level. The TOE performs direct memory access (DMA) on the protocol data unit (PDU) header to the processor or the host computer and direct memory access (DMA) on the PDU data section to the host computer, thereby storing the memory of the host computer. Separate the iSCSI protocol data unit (PDU) header and data segment without requiring an additional memory copy;
The network adapter according to claim 7. The TOE performs IPsec anti-replay support for each security association (SA).
The network adapter according to claim 2. The TOE performs IPSec zero, DES, 3DES algorithm, and AES 128-bit algorithm in cipher block chaining (CBC) mode;
The network adapter according to claim 2. The TOE performs IPSec Zero, SHA-1, and MD-5 authentication algorithms;
The network adapter according to claim 2. The TOE executes an IPSec variable length encryption key;
The network adapter according to claim 2. The TOE executes an IPSec variable length authentication key;
The network adapter according to claim 2. The TOE performs IPSec jump frame support;
The network adapter according to claim 2. The TOE performs an IPSec automatic processing of the expiration of the security association (SA) based on the time and all data transferred;
The network adapter according to claim 2. The TOE performs IPSec policy enforcement;
The network adapter according to claim 2. The TOE executes IPSec exception handling including exception packet generation and status notification.
The network adapter according to claim 2. An integrated network adapter,
A wired data path to send and receive packets and to encode and decode packets;
At least one wired protocol state machine;
At least one communication channel between the network adapter and a host computer;
A scheduler that schedules shared resources based on traffic;
Wired transfer offload engine (TOE),
A processor integrated with the TOE;
Optimized hardware support for network address translation (NAT), IP masquerading, and port forwarding with port range registers that forward all UDP or TCP packets entering the programmable port range to the exception path A module to provide,
With
The port range register allows a range of ports to be used in network control operations and port forwarding;
Integrated network adapter. The at least one communication channel transfers data and control information using a command block (IB) and a status message (SM);
The network adapter according to claim 27. Further comprising at least one threshold timer for controlling communication via the at least one communication channel;
Data is transmitted at selected threshold intervals,
The network adapter according to claim 27. The threshold timer includes an interrupt aggregation mechanism for reducing the number of interrupts between the network adapter and the host computer and increasing data processing capacity.
30. The network adapter according to claim 29. A module for setting at least one data threshold for controlling communication via the at least one communication channel;
Data is transmitted when the data level reaches a selected threshold,
The network adapter according to claim 27.   28. The network adapter of claim 27, further comprising an interrupt aggregation mechanism that optimizes data processing capabilities of the processor and the TOE. A module providing hardware support optimized for TCP selection acknowledgment (SACK);
TCP responds with a lost data packet and retransmits only the lost data packet.
The network adapter according to claim 27. Further comprising a module providing hardware support optimized for TCP fast resend credit;
The network adapter according to claim 27. The TCP fast retransmission generates an ACK immediately to allow the transmitter to quickly fill the hole instead of waiting for a standard imout when an out-of-order segment is received,
The network adapter according to claim 34. When the receiver receives three duplicate ACKs, the TCP fast retransmission is invoked,
When the TCP fast retransmission is invoked, the transmitter tries to fill the hole,
If the ACK and the segment window ad value match each other, the duplicate ACK is determined to be duplicate.
The network adapter according to claim 34.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for TCP window scaling. The window scaling operation is based on three variables comprising at least one bit that enables window scaling, at least one bit for setting a scaling factor, and a parameter for determining a scaling value.
The network adapter according to claim 27.   28. The network adapter of claim 27, further comprising a module that provides optimized hardware support for iSCSI header and data CRC generation and checking.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for generating iSCSI fixed interval markers (FIM).   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for a TCP dump mode that supports a diagnostic program and a packet monitoring program. When TCP dump mode is enabled, all received packets are sent as exceptions to the host and all outgoing TCP / UDP packets coming from the hardware stack are looped back as exception packets.
42. The network adapter according to claim 41.   43. The network adapter of claim 42, further comprising a driver that copies the exception packet for network monitoring and transmits the TX packet as a raw Ethernet frame to reinject the RX packet. A module providing hardware support optimized for host ACK mode;
Only when the host receives data from a TCP segment to ensure data integrity if the data may be corrupted when the data passes between the host computer and the network adapter TCP ACK is sent,
The network adapter according to claim 27. The host ACK mode waits for a direct memory access (DMA) of the MTX buffer containing the data segment to complete before sending an ACK.
45. A network adapter according to claim 44.   A module that provides optimized hardware support for TCP timestamps to allow TCP to calculate round trip time measurements (RTTM) well and support protection against wrap sequences (PAWS) 28. The network adapter according to claim 27, further comprising:   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for TCP PAWS to prevent destruction of TCP connections due to old overlapping segments.   28. The network of claim 27, further comprising a module that provides hardware support optimized for TCP host retransmission mode to cause data to be retransmitted directly from a buffer in host memory rather than from a buffer in the network adapter. adapter.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for a random initial sequence number. A module with hardware support optimized for dual stack mode,
A hardware TCP / IP stack embedded in the network adapter operating in cooperation with and in conjunction with the host software TCP / IP stack;
Further comprising
The network adapter supports coexistence of the software TCP / IP stack operating in parallel using the same IP address as the network adapter;
The network adapter according to claim 27. A module that supports a synchronous (SYN) status message mode;
Any SYN received receives a status message back to the host;
SYN / ACK is not generated by the network adapter until the host returns an appropriate command block to the network adapter,
If the SYN status message mode is not enabled on the network adapter, a SYN / ACK is automatically generated by the network adapter and no SYN receive status message is generated.
The network adapter according to claim 50. A module for supporting suppression of reset (RST) messages from the network adapter when a TCP packet that does not match the network adapter control block database is received;
The network adapter sends a packet to the host as an exception packet instead of automatically generating an RST, so that the TCP / IP stack of the host can process the packet as an exception packet.
The network adapter according to claim 50.   28. The module of claim 27, further comprising a module that provides hardware support optimized for IP ID partitioning to allow the host and the network adapter to share IP addresses without overlapping IP IDs. Network adapter.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for filtering data packets to limit, accept, or perform special operations on certain types of packets. The filtering includes any characteristics of acceptance of programmed unicast addresses, acceptance of broadcast packets, acceptance of multicast packets, acceptance of addresses within a range specified by a netmask, and promiscuous mode for accepting all packets. Can take,
The network adapter according to claim 54. A VLAN module that provides hardware support optimized for a virtual local area network (VLAN);
The network adapter according to claim 27. The VLAN module includes an element for removing a VLAN header from an input packet, an element for generating an output packet with a VLAN tag, an element for generating a VLAN parameter from an input SYN frame, and VLAN tag information of an exception packet and a UDP packet With one of the elements to pass through,
57. The network adapter according to claim 56.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for jumbo frames.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for Simple Network Management Protocol (SNMP).   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for a management information base (MIB). A module that provides hardware support optimized for network adapter operation in legacy mode;
All network traffic is sent to the host regardless of traffic type,
The network adapter operates as if a hardware TCP / IP stack is not present in the adapter.
The network adapter according to claim 27. Further comprising a module that provides optimized hardware support that allows IP partitioning to be handled either in hardware or software;
IP fragmented packets that are transmitted as exception packets and reconstructed by the software driver are reinjected back into the network adapter by the IP injection mode;
The network adapter according to claim 27.   28. The network adapter of claim 27, further comprising an IP injection module that provides hardware support optimized for IP injection that allows IP packets to be injected into the TCP / IP stack of the network adapter. The IP injection module comprises one or more injection control registers for injecting IP packets into the TCP / IP stack of the network adapter;
The one or more injection control registers allow the host to inject IP packets into the TCP / IP stack of the network adapter;
64. A network adapter according to claim 63.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for a plurality of IP addresses. The module further provides hardware support optimized for debug mode,
All IP packets are sent as exceptions to the host when test and control bits are enabled in the network adapter;
The network adapter according to claim 27.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for TCP time wait states.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for a variable number of connections. If the network adapter accepts a connection equal to the maximum capacity of the network adapter, the next synchronization (SYN) is passed to the host as an exception packet so that the host can handle the connection;
The network adapter according to claim 27.   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for User Datagram Protocol (UDP).   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for TTL (Time to Live) to limit the lifetime of an IP packet to a selected number of hops.   A module that provides hardware support optimized for TCP keep-alive to allow idle TCP connections to be maintained and not timed out by periodically sending keep-alive packets on the link The network adapter according to claim 27, further comprising:   28. The network adapter of claim 27, further comprising a module that provides hardware support optimized for a TCP type (TOS) of service used by the router to prioritize IP packets. An integrated network adapter,
A wired data path to send and receive packets and to encode and decode packets;
At least one wired protocol state machine;
At least one communication channel between the network adapter and a host computer;
A scheduler that schedules shared resources based on traffic;
A module for hardware support optimized for TCP slow start;
With
The slow start is
Before predicting an acknowledgment (ACK), first allow only two data segments to flow corresponding to the current window (cwnd) twice the maximum segment size (MSS),
To stream one more segment, by incrementing cwnd by one MSS each time a successful ACK is received until the cwnd is equal to the receiver's advertising window,
Gradually increase the number of data segments flowing at once,
Integrated network adapter. The slow start is always started with a new data connection,
The slow start is activated in the middle of the connection when data traffic congestion occurs,
75. The network adapter according to claim 74. An integrated network adapter,
A wired data path to send and receive packets and to encode and decode packets;
At least one wired protocol state machine;
At least one communication channel between the network adapter and a host computer;
A scheduler that schedules shared resources based on traffic;
Wired transfer offload engine (TOE),
A processor integrated with the TOE;
An ECC module that provides hardware support optimized for flexible and programmable memory error checking and correction (ECC);
With
The ECC module stores the encrypted ECC code in the packet along with the data using at least one additional bit;
The ECC code is also stored when the data is written to memory,
When the data is read, the stored ECC code is compared with the ECC code generated when the data is written;
If the ECC codes do not match, a determination is made as to which bits in the data are in error;
The bit in error is inverted, and the memory controller releases the corrected data,
The error is corrected on the fly, the corrected data is not returned to the memory,
If the same damaged data is read again, the operation of the ECC module is repeated.
Integrated network adapter. An integrated network adapter,
A wired data path to send and receive packets and to encode and decode packets;
At least one wired protocol state machine;
At least one communication channel between the network adapter and a host computer;
A scheduler that schedules shared resources based on traffic;
Wired transfer offload engine (TOE),
A processor integrated with the TOE;
A module that provides hardware support optimized for TCP quality of service (QoS);
With
The TCP send data flow starts with a socket query module, which passes through a send data valid bit table looking for an entry with a send data valid bit set,
When the socket inquiry module finds the entry, it places the entry in one of a plurality of queues according to a socket user priority level.
Integrated network adapter. An integrated network adapter,
A wired data path to send and receive packets and to encode and decode packets;
At least one wired protocol state machine;
At least one communication channel between the network adapter and a host computer;
A scheduler that schedules shared resources based on traffic;
Wired transfer offload engine (TOE),
A processor integrated with the TOE;
A failover module that provides hardware support optimized for failover, and
With
The failover module has a NO_SYN mode that allows a socket to be created without attempting to initiate a connection;
A socket in the network adapter and all data structures associated with the socket are generated without creating a connection;
The NO_SYN mode supports failover from another card or from a connection transition from a software TCP / IP stack to the network adapter;
Integrated network adapter. An integrated network adapter,
A wired data path for receiving packets; and
Multiple parallel, wired protocol state machines; and
A scheduler that schedules shared resources based on traffic;
Wired transfer offload engine (TOE),
A processor integrated with the TOE;
Optimized hardware support for network address translation (NAT), IP masquerading, and port forwarding with port range registers that forward all UDP or TCP packets entering the programmable port range to the exception path A module to provide,
With
The protocol state machine performs processing in parallel;
The port range register allows a range of ports to be used in network control operations and port forwarding;
Integrated network adapter.

Images