JP2007215013A - Protocol processor and protocol processing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To process a stationary packet and a non-stationary packet (fragment packet) at a high speed, using small circuit scale. <P>SOLUTION: This protocol processor has a control means for executing reassembly processing of fragmented packets and data checksum inspection processing of the reassembled packets, by using a checksum value stored in a checksum storage means and a checksum value stored in a packet header of the reassembled packets and this problem is solved by performing a checksum inspection by the control means, when it is decided that a received packet is a fragmented packet by a fragment inspection means and performing the checksum inspection by a checksum inspection means, when it is decided that the packet received is not the fragmented packet at the fragment inspection means. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a protocol processing apparatus and a protocol processing method.

  In data communication using a network, a technique using a protocol such as TCP / IP is used. In this communication by TCP / IP, data is divided into small units, and various information related to transmission / reception is added as a header, whereby transmission / reception is performed in a block of data called a packet.

  Further, in the network protocol, as represented by the OSI reference model, the processing unit is hierarchically performed, and according to this, the header information corresponding to each processing unit is hierarchically included in the packet data structure. It has been added.

  FIG. 1 is a diagram showing a data structure of a TCP / IP packet in Ethernet (registered trademark). In FIG. 1, an Ethernet (registered trademark) header 201, an IP header 202, and a TCP header 203 are sequentially added from the top of the data, followed by payload data 204 that is application data.

  FIG. 2 is a diagram illustrating a data structure of an IP packet. In FIG. 2, 301 indicates an IP header portion, and 302 indicates a data portion. The IP header section 301 includes a header size, a packet size, a service type, an identifier, an IP address between the transmission source and the transmission destination, a header checksum value indicated by 303, a flag indicated by 304, and a fragment offset indicated by 305. Stores values and so on. The header checksum 303 is 16-bit data for assuring that the IP header portion 301 and the data portion 302 are not broken. In the IP packet reception process, the apparatus calculates the checksum value of the IP header portion 301 of the received packet and compares the result with the header checksum 303 stored in the header.

  The flag 304 stores 3-bit data that controls fragment processing of the IP datagram. The fragment offset 305 stores 13-bit data that indicates where the fragmented data is located in the original IP datagram.

  FIG. 3 is a diagram illustrating a data structure of a TCP packet. In FIG. 3, 401 indicates a TCP header portion, and 402 indicates a data portion. The TCP header portion 401 stores a port number, a sequence number, various flags, a checksum value indicated by 403 including a header portion and a data portion, and the like.

  The checksum 403 is 16-bit data for ensuring that the TCP header portion 401 and the data portion 402 are not broken. In the TCP packet reception process, the apparatus calculates the checksum value between the TCP header portion 401 and the data portion 402 of the received packet, and compares the result with the checksum 403 stored in the header. .

  These TCP / IP protocol processes have been conventionally implemented by software. However, for example, in the calculation of the checksum value or the like, an addition process of about 1500 bytes is required for each packet process, and it takes time for the calculation in software, so it is difficult to increase the communication throughput.

  As means for solving this, Patent Document 1 proposes a circuit for generating a checksum value in a short time using hardware.

JP-A-9-134295

  As a means for executing IP packet processing at high speed, the method using hardware as proposed in Patent Document 1 described above can be realized relatively simply, particularly by only performing routine packet processing. Can be effective. However, if the hardware tries to process non-stationary packets, there is a problem that the hardware circuit scale increases.

  For example, in the TCP / IP protocol, for data having a size exceeding the maximum value (MTU) that an IP packet can be transferred through a data link, a function for performing packet division called fragmentation is determined as necessary. A device such as a router that relays a network has a function of dividing and transmitting a packet by fragment processing when the received IP packet is a packet having a size larger than the destination MTU.

  When this fragmented IP packet is received, the packet is reassembled after waiting for all the divided packets to arrive and passed to the upper protocol.

  When the waiting and reassembly of the fragmented packet is realized by hardware, complicated memory management must be performed and the circuit configuration becomes complicated. In addition, since a dedicated memory independent from the memory used by the higher-level protocol processed by software is required, the circuit scale increases.

  The present invention has been made in view of the above problems, and an object of the present invention is to process a stationary packet and a non-stationary packet (fragment packet) at high speed with a small circuit scale.

  Therefore, in order to solve the above problem, the present invention stores checksum calculation means for performing data checksum calculation of a received packet, a checksum value obtained by the checksum calculation means, and a packet header of the received packet. Checksum checking means for performing a data checksum check using a checksum value, a fragment checking means for determining whether or not the received packet is a fragmented packet, and a check obtained by the checksum calculation means Checksum storage means for temporarily storing the sum value, reassembly processing of the fragmented packet, checksum value stored in the checksum storage means, and packet header of the reassembled packet Data packet of the reassembled packet using the stored checksum value Control means for executing a checksum check process, and when the received packet is determined to be a fragmented packet by the fragment check means, the control means performs a checksum check, and the fragment check When the means determines that the received packet is not a fragmented packet, the checksum checking means performs a checksum check.

  With this configuration, non-stationary packet processing is performed by the control unit, and stationary packet processing is performed by, for example, hardware checksum calculation unit, fragment inspection unit, or the like. Therefore, stationary packets and non-stationary packets can be processed at high speed with a small circuit scale.

  In order to solve the above problem, the present invention may be a protocol processing method and a program.

  According to the present invention, stationary packets and non-stationary packets can be processed at high speed with a small circuit scale.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

(Embodiment 1)
FIG. 4 is a block diagram illustrating the overall configuration of the apparatus according to the first embodiment. In the first embodiment, description will be made using Ethernet (registered trademark) which is a standard of wired LAN represented by IEEE 802.3 as a physical layer and a data link layer of a network. Further, description will be made using the TCP / IP protocol as a network layer and a transport layer.

  In FIG. 4, reference numeral 101 denotes a MAC (Media Access Control), and an Ethernet (registered trademark) frame on the network is first received by the MAC 101. The MAC 101 executes a protocol process provided in the physical layer and the data link layer according to the information of the MAC header, and performs a process of transferring packet data to an upper layer after removing the MAC header. A TCP (UDP) / IP deframer 102 receives a TCP / IP packet from which the MAC header has been removed by the MAC 101 from the MAC 101, and extracts the IP header and TCP header data.

  The extracted IP header and TCP header have the structures described with reference to FIGS. The TCP (UDP) / IP deframer 102 sends the extracted header data to the header information analysis unit 106 described later. Further, the TCP (UDP) / IP deframer 102 sends the extracted packet data to the checksum calculation unit 103 described later.

  When the checksum calculation unit 103 receives data from the TCP (UDP) / IP deframer 102, it calculates a checksum value of the TCP packet.

  The checksum calculation unit 103 first generates a pseudo header composed of a transmission destination IP address, a transmission source IP address, a packet length, and a protocol number as the calculation of the checksum value of the TCP packet. Next, after adding 0 to the checksum area in the TCP header, the checksum calculation unit 103 adds the pseudo header, the TCP header, and the data part by 1's complement in units of 16 bits. Then, the checksum calculation unit 103 sends data to the reception packet buffer 104. The reception packet buffer 104 is an area for storing received packet data for one packet, and performs processing to discard data when the reception packet is not a normal packet.

  When the data stored in the reception packet buffer 104 is normal packet data, the data is written into the data buffer 105 b in the reception buffer 105.

  The reception buffer 105 is composed of a RAM (Random Access Memory), and is a memory area managed by a CPU 110 described later. Therefore, the memory address where the packet data is written is designated in advance by the CPU 110. The reception buffer 105 includes a packet descriptor 105a and a data buffer 105b.

  The data buffer 105b is an aggregate of fragmented memory areas and has a queue structure. The packet descriptor 105a is an area for storing information for managing the fragmented memory area constituting the data area as a chained queue structure, and a more detailed data structure will be described later.

  The IP header and TCP header data extracted by the TCP (UDP) / IP deframer 102 are analyzed by the header information analysis unit 106 to the contents of the various headers, and then transferred to the TCP protocol control, which is a higher level protocol processed by the CPU 110. Passed. The contents of the header to be analyzed include a packet length, a transmission destination and a transmission source IP address, an identifier, a flag, a fragment offset, a protocol number, various options, etc. in the IP header. The contents of the header to be analyzed include a transmission destination and transmission source port number, a sequence number, an acknowledgment number, a code bit, a window size, a checksum value, various option information, and the like in the TCP header.

  The header information analysis unit 106 also calculates the checksum value of the IP header, checks whether the calculation result matches the checksum value written in the IP header, and the CPU 101 also checks the check result. To the received packet buffer 104. The reception packet buffer 104 performs processing for discarding the reception packet when the mismatch of the header checksum value is detected.

  As the calculation of the checksum value of the IP header, the header information analysis unit 106 puts 0 in the checksum area in the IP header, and then adds up the IP header part by 1's complement in 16-bit units.

  The checksum information 106a is one of TCP header information analyzed by the header information analysis unit 106, and is a checksum value of packet data calculated and embedded at the transmission destination. The flag information 106b is one piece of IP header information analyzed by the header information analysis unit 106, and is information (fragment control information) for controlling fragment processing of an IP packet. The flag information 106b includes identification information for instructing whether or not the IP packet may be fragmented. Further, the flag information 106b includes information for identifying whether or not the IP packet is a fragmented packet, and in the case of a fragmented packet, the flag information 106b identifies whether it is the last fragment packet or an intermediate fragment packet.

  The fragment inspection unit 107 reads the flag information 106b analyzed by the header information analysis unit 106, and determines whether the IP packet is a fragmented packet. In addition, in the case where the IP packet is a fragmented packet, the fragment checking unit 107 checks whether it is the last fragment packet or an intermediate fragment packet. The fragment inspection unit 107 transmits the inspection result to the CPU 110 and the selector 111.

  When the packet is a fragment packet, the selector 111 sends the checksum value of the packet calculated by the checksum calculation unit 103 to the checksum value temporary storage unit 108, and when the packet is not a fragment packet, the checksum check unit Send to 109.

  The checksum value temporary storage unit 108 is a memory that temporarily stores the checksum value of each packet until all the fragment packets having the same identifier arrive. When the arrival of all the packets is completed, the stored checksum value is read by the CPU 110 and used for the packet reassembly process and the checksum check process by the CPU 110.

  Also, the checksum checking unit 109 compares the calculation checksum value sent from the checksum calculation unit 103 with the checksum value sent from the checksum information 106a of the header information analysis unit 106. Then, the checksum inspection unit 109 transmits the inspection result (comparison result) to the CPU 110 and the reception packet buffer 104.

  When receiving a test result indicating that the checksum values do not match, the received packet buffer 104 performs processing to discard the held received packet.

  The CPU 110 receives various information of the IP header and TCP header analyzed by the header information analysis unit 106, the inspection result of the fragment inspection unit 107, and the inspection result of the checksum inspection unit 109, and performs various controls based on these information. Do. In addition, the CPU 110 receives information such as a checksum value stored in the checksum value temporary storage unit 108, and performs various controls based on this information and the like. The control includes, for example, control of the packet descriptor 105a in the reception buffer 105, control of reading and writing data to the data area 105b, and the like. The control includes memory address designation control when the reception packet buffer 104 writes packet data, fragmented packet reassembly processing control, TCP protocol processing control that is a higher level protocol, and the like. However, details of the control processing procedure of the CPU 110 will be described with reference to a flowchart described later.

  FIG. 5 is a diagram for explaining a detailed data structure of the reception buffer 105. FIG. 5 shows a data structure in the case where a single packet data is stored in the reception buffer 105.

  In FIG. 5, 501 and 502 are packet descriptors indicated by 105a, and 503 and 504 are data buffers indicated by 105b. The data buffer 105b is divided into units of a certain size, and the reception buffer 105 has a queue structure that manages the association of the plurality of divided areas with the data described in the packet descriptor 105a. ing.

  501 includes data such as p_next1 (501a), p_data1 (501b), len1 (501c), pktlen1 (501d), p_buf1 (501e), size1 (501f), and other information 1 (501g). . Similarly, 502 includes data such as p_next2 (502a), p_data2 (502b), len2 (502c), pktlen2 (502d), p_buf2 (502e), size2 (502f), and other information 2 (502g). It is.

  Reference numeral 503 includes header1 (503a), data1 (503b), and 504 includes data2 (504a). These 503 and 504 are each one of divided areas for storing packet data.

  Reference numeral 503 denotes a data buffer in which the first block of packet data is stored, and includes TCP header and IP header data indicated by 503a and payload data indicated by 503b. Reference numeral 504 denotes a data buffer in which subsequent blocks of packet data are stored, and includes subsequent payload data shown in 504a.

  FIG. 5 shows an example in which one packet is divided and stored in a plurality of data buffers (503, 504). Usually, one packet is often stored in one data buffer. . However, when a fragmented packet is received, since each divided packet arrives at a different time, it is stored and managed in a block divided for each arrival.

  Next, the packet descriptor 501 stores data buffer 503, various information related to the packet data 503a and 503b, information for managing the queue structure of the packet descriptor, and the like.

  p_next1 (501a) is pointer information indicating the start address of the next packet descriptor when the packet descriptor of the next block exists. In the example of FIG. 5, the start address of the area 502 is stored. If there is no next packet descriptor, that is, a packet descriptor for the last block, NULL is stored.

  In the data buffer, p_data (501b) stores an address which is a pointer indicating the head of the packet data 503a and 503b actually stored in the data buffer 503 that is the target of the packet descriptor. In len1 (501c), the combined data length of the packet data 503a and 503b is stored. pktlen1 (501d) stores the data length of the entire packet, that is, the total size of 503a, 503b, and 504a. This total size is stored only in the packet descriptor of the first block when one packet is composed of a plurality of blocks.

  Next, p_buf1 (501e) stores an address which is a pointer indicating the head of the data buffer 503 to be the target of the packet descriptor in the data buffer. The size of the data buffer 503 is stored in size1 (501f).

  Other information 1 (501g) includes information for managing other packet data, for example, when the data buffer is managed with a plurality of division sizes, its block type, pointer information to a packet having the next identifier, etc. Is stored.

  The packet descriptor 502 stores various information related to the data buffer 504 and packet data 504a, information for managing the queue structure of the packet descriptor, and the like.

  The configuration of information stored in 502 is the same as the configuration described in 501, but the information on the data length of the entire packet indicated in pktlen2 (502d) is that 502 is not the packet descriptor of the first block of the packet. NULL is stored.

  FIG. 6 is a flowchart illustrating control of software executed by the CPU 110 according to the first embodiment. The CPU 110 always repeats and executes the process shown in FIG.

  In step S601, the CPU 110 performs a process of waiting for a packet to be received. In step S602, CPU 110 determines whether a packet has been received. If CPU 110 determines that a packet has been received, the process proceeds to step S603. If CPU 110 determines that a packet has not been received, CPU 110 repeats the process of step S602.

  In step S <b> 603, the CPU 110 acquires the checksum check result (calculation checksum value) of the IP header of the packet calculated by the header information analysis unit 106. In step S604, the CPU 110 compares the operation checksum value acquired in step S603 with the checksum value in the IP header of the packet to determine whether the received packet is a normal packet.

  That is, if the calculated checksum value acquired in step S603 matches the checksum value in the IP header of the packet, the CPU 110 determines that the packet is a normal packet and proceeds to step S605. On the other hand, if the calculated checksum value acquired in step S603 does not match the checksum value in the IP header of the packet, the CPU 110 determines that the packet is not a normal packet and stores the packet stored in the received packet buffer 104. Discard the data. Then, the CPU 110 ends the process shown in FIG.

  In step S605, the CPU 110 secures a data buffer for the received packet in the data buffer 105b of the reception buffer 105. The CPU 110 performs processing for assigning the data buffer for writing from the reception packet buffer 104 and processing for generating a packet descriptor 105a for managing the data buffer. These data buffers and packet descriptors are managed in the queue structure as described with reference to FIG.

  In step S606, the CPU 110 acquires packet header information including a checksum value embedded in the TCP header from the header information analysis unit 106. This checksum value is used in a checksum check process, which will be described later, or an upper protocol process such as TCP control.

  Subsequently, in step S607, the CPU 110 acquires from the fragment inspection unit 107 information on the inspection result, that is, whether the received IP packet is a fragmented packet (IP fragment packet).

  Subsequently, in step S608, CPU 110 determines whether or not the received IP packet is an IP fragment packet based on the inspection result acquired in step S607. If the CPU 110 determines that the received IP packet is an IP fragment packet, the process proceeds to step S614. If the CPU 110 determines that the received IP packet is not an IP fragment packet, the process proceeds to step S609.

  In step S <b> 609, the CPU 110 acquires the checksum check result of the TCP packet from the checksum checker 109. Here, the check result of the TCP packet checksum matches the checksum value of the TCP packet calculated by the checksum calculation unit 103 and the checksum value read from the TCP header by the header information analysis unit 106. It is information on whether or not to do.

  In step S610, the CPU 110 determines whether the packet is a normal packet based on the check result of the checksum of the TCP packet acquired in step S609. If the CPU 110 determines that the packet is a normal packet, the process proceeds to step S611. If the CPU 110 determines that the packet is not a normal packet, the process proceeds to step S613. The CPU 110 determines that the packet is a normal packet if the checksum value of the TCP packet calculated by the checksum calculation unit 103 matches the checksum value read from the TCP header by the header information analysis unit 106. judge. On the other hand, if the checksum value of the TCP packet calculated by the checksum calculation unit 103 does not match the checksum value read from the TCP header by the header information analysis unit 106, the CPU 110 is not a normal packet. Is determined.

  As the packet data stored in the reception packet buffer 104 is discarded, in step S613, the CPU 110 releases the data buffer and packet descriptor in the reception buffer 105 reserved for the reception packet in step S605.

  In step S611, the CPU 110 executes control processing for the reception buffer 105. This control process is a process of writing a numerical value to each item in the packet descriptor corresponding to the packet data written in the memory block in the reception buffer 105. The numerical value is the size of the received packet, the address in the memory block, the information such as the data length of the entire packet obtained by referring to the header information, and the pointer address to the descriptor of the next packet. .

  Subsequently, in step S612, the CPU 110 executes control processing for TCP, which is a higher level protocol. A detailed description of TCP control processing is omitted, but includes connection management, flow control, congestion control, and the like.

  On the other hand, in step S614, the CPU 110 determines whether all the fragment packets have arrived. The CPU 110 determines whether all the fragment packets have arrived based on the flag 304 of the IP packet having the same identifier and the fragment offset 305.

  If the CPU 110 determines that all fragment packets have arrived, the process proceeds to step S615. If the CPU 110 determines that all fragment packets have not arrived, the process proceeds to step S619.

  In step S619, the CPU 110 writes the size of the received packet and the address in the memory block as control processing of the reception buffer 105, as in step S611. Further, when receiving the first block, the CPU 110 writes the data length of the entire packet, writes the pointer address to the descriptor of the next packet, and the like.

  By executing the control process of the reception buffer 105 each time a fragment packet arrives, the fragment packet stored in each data buffer 105b can be handled as continuous data, and the packet reassembly process can be executed. it can.

  In step S615, the CPU 110 performs a process of adding the operation checksum values of all packets stored in the checksum value temporary storage unit 108. The checksum value (data checksum) of the reassembled packet can be obtained by this addition processing.

  Subsequently, in step S616, the CPU 110 compares the checksum value of the reassembled packet obtained in step S615 with the checksum value in the TCP header, and determines whether or not they match. If the CPU 110 determines that the checksum value of the reassembled packet obtained in step S615 matches the checksum value in the TCP header, the process proceeds to step S611. On the other hand, if CPU 110 determines that the checksum value of the reassembled packet obtained in step S615 does not match the checksum value in the TCP header, the process proceeds to step S618.

  In step S618, as in step S613, the CPU 110 releases the data buffer and packet descriptor in the reception buffer 105 reserved for the reception packet in step S605.

(Embodiment 2)
In the first embodiment, when a fragmented packet is detected, the reassembly process is always executed by the CPU 110. However, in the network protocol using TCP / IP, the arrival order of fragmented packets is not guaranteed. However, if the transmitted packets do not pass through a complicated network path, they will arrive in order from the first packet. There are many.

  When sequentially receiving fragmented packets from the beginning, the received data can be written continuously into the memory, so this memory processing does not require complicated memory management and only a simple address increment is required. . Therefore, the circuit scale does not increase.

  Therefore, in the second embodiment, even when a fragmented packet is received, control is performed to automatically write to the reception buffer memory by hardware while the packet arrives in order from the first block. An example in which the CPU 100 performs the reassembly process when it is detected that the arrival order has been changed will be described.

  FIG. 7 is a block diagram illustrating the overall configuration of the apparatus according to the second embodiment. Also in the second embodiment, description will be made using Ethernet (registered trademark), which is a standard of wired LAN represented by IEEE 802.3, as a physical layer and a data link layer of a network. Further, description will be made using the TCP / IP protocol as a network layer and a transport layer.

  In FIG. 7, a MAC (Media Access Control) 101 and a TCP (UDP) / IP deframer 102 perform the same control as in the first embodiment. The header data extracted by the TCP (UDP) / IP deframer 102 is sent to the header information analysis unit 106, and the packet data is sent to the checksum calculation unit 103. The header information analysis unit 106 and the checksum calculation unit 103 also perform the same control as in the first embodiment.

  The reception packet buffer 104 and the reception buffer 105 are also memories for storing packet data as in the first embodiment, and the reception buffer 105 is managed as a queue structure as described with reference to FIG.

  The IP header and TCP header data extracted by the TCP (UDP) / IP deframer 102 are analyzed by the header information analysis unit 106 to the contents of the various headers, and then transferred to the TCP protocol control, which is a higher level protocol processed by the CPU 110. Passed. A processing procedure and the like of the CPU 110 in the second embodiment will be described in detail with reference to a flowchart described later.

  The fragment inspection unit 707 reads the flag information 106b analyzed by the header information analysis unit 106, and determines whether or not the IP packet is a fragmented packet. In addition, when the IP packet is a fragmented packet, the fragment inspection unit 707 inspects whether it is the last fragment packet or an intermediate fragment packet. In addition, the fragment inspection unit 707 determines whether the IP packet is a fragmented packet, whether the fragment packet has arrived in a sequential order from the beginning, and if the IP packet has arrived in a continuous order, determines whether it is the last fragment packet. Check for no. The fragment inspection unit 707 transmits these inspection results to the CPU 110 or the selector 711.

  When it is determined that the IP packet is a fragment packet that has arrived discontinuously, the selector 711 sends the checksum value of the packet calculated by the checksum calculation unit 103 to the checksum value temporary storage unit 708. When the selector 711 determines that the IP packet is not a fragment packet, the selector 711 sends the checksum value of the packet calculated by the checksum calculation unit 103 to the checksum check unit 709 via the selector 713.

  If the selector 711 determines that the fragment packet has arrived in a sequential order from the beginning, the selector 711 sends the checksum value of the packet calculated by the checksum calculation unit 103 to the checksum addition unit 712.

  The checksum value temporary storage unit 708 is a memory that temporarily stores the checksum value of each packet until all fragment packets having the same identifier arrive. When the arrival of all the packets is completed, the stored checksum value is read by the CPU 110 and used for the packet reassembly process and the checksum check process by the CPU 110.

  When receiving successive fragment packets, the checksum adding unit 712 reads the checksum value of the fragment packet having the same identifier among the checksum values stored in the checksum value temporary storage unit 708. Then, the checksum adding unit 712 performs the control of adding the checksum value and then writing the checksum value temporarily storage unit 708 again. In other words, while receiving successive fragment packets, the sum of checksum values of packets having the same identifier that have arrived so far is stored in the checksum value temporary storage unit 708.

  Further, when the fragment inspection unit 707 detects that the packet is the last of the packets that have arrived as continuous fragment packets, the selector 711 informs the selector 713 of the detection result. Upon receiving the detection result, the selector 713 sends the checksum value stored in the checksum value temporary storage unit 708 to the checksum check unit 709. When the selector 713 receives a detection result other than the detection result (or a control signal other than the detection result), the selector 713 sends the checksum value calculated by the checksum calculation unit 103 to the checksum checking unit 709.

  By such processing, the checksum value sent out from the checksum value temporary storage unit 708 finally becomes the checksum value of the entire packet, and the checksum check is performed on this checksum value.

  When the fragment checking unit 707 determines that the packet is not fragmented, the checksum value calculated by the checksum calculating unit 103 is sent to the checksum checking unit 709 as described above.

  The checksum checker 709 compares the checksum value sent from the checksum calculator 103 with the checksum value sent from the checksum information 106a of the header information analyzer 106, and compares the check result with the CPU 110 and the received packet. Tell the buffer 104.

  The reception packet buffer 104 performs processing for discarding the reception packet when the checksum value mismatch is detected.

  The CPU 110 receives various information of the IP header and TCP header analyzed by the header information analysis unit 106, the inspection result of the fragment inspection unit 707, and the inspection result of the checksum inspection unit 709, and performs various controls based on these information. Do. Further, the CPU 110 receives information such as a checksum value stored in the checksum value temporary storage unit 708, and performs various controls based on this information and the like. The control includes, for example, control of the packet descriptor 105a in the reception buffer 105, control of reading and writing data to the data area 105b, and the like. The control includes memory address designation control when the reception packet buffer 104 writes packet data, fragmented packet reassembly processing control, TCP protocol processing control that is a higher level protocol, and the like. However, details of the control processing procedure of the CPU 110 will be described with reference to a flowchart described later.

  FIG. 8 is a diagram showing the structure of data written to the memory block in the data buffer 105b when successive fragment packets are received. In FIG. 8, reference numeral 801 denotes a header data portion in which IP header information is stored. Reference numeral 802 denotes a fragmented initial data portion, which includes a header of a higher protocol such as a TCP header and a part of the payload. A portion obtained by combining the data 801 and the data 802 is received as the first fragment packet.

  Reference numeral 803 denotes a second data portion, and 804 denotes a third data portion. Each time the data 803 and the data 804 are received, the data is added after the previous data and stored in the memory in the data buffer 105b. Written to the block.

  FIG. 9 is a flowchart illustrating control of software executed by the CPU 110 according to the second embodiment. The CPU 110 always repeats and executes the process shown in FIG.

  The processing from step S901 to step S907 is the same as the processing from step S601 to step S607 shown in FIG. 6 of the first embodiment.

  In step S908, the CPU 110 determines whether the received IP packet is an IP fragment packet based on the inspection result acquired in step S907. If the CPU 110 determines that the received IP packet is an IP fragment packet, the process proceeds to step S920. If the CPU 110 determines that the received IP packet is not an IP fragment packet, the process proceeds to step S909.

  The processing from step S909 to step S913 is the same as the processing from step S609 to step S613 shown in FIG. 6 of the first embodiment.

  In step S920, the CPU 110 determines whether or not the packet data is being subjected to hardware reassembly control, that is, whether or not it is a continuously arriving fragment packet. If the CPU 110 determines that the packet data is subjected to hardware reassembly control, the process proceeds to step S921. If the CPU 110 determines that the packet data is not subjected to hardware reassembly control, the process proceeds to step S914.

  In step S921, the CPU 110 determines whether or not the reassembly has been completed, that is, the packet written in the memory block as shown in FIG. 8 as the packet data completed by receiving the last data of the same identifier packet. It is determined whether or not. If the CPU 110 determines that the reassembly is complete, the process proceeds to step S909. If the CPU 110 determines that the reassembly is not complete, the process proceeds to step S922. The CPU 110 determines whether the reassembly has been completed based on the inspection result output from the fragment inspection unit 707 or the like.

  In step S922, the CPU 110 executes update processing of the packet size and the address in the memory block as control processing of the reception buffer 105.

  The processing from step S914 to step S919 is the same as the processing from step S614 to step S619 shown in FIG. 6 of the first embodiment.

(Embodiment 3)
In the above-described embodiment, the case where there is no overlapping area in all fragment packets has been described as an example. In such a case, the checksum operation processed by the CPU 110 simply adds the checksum value of each fragment packet stored in the checksum value temporary storage unit 108, and the checksum value of the entire reassembled packet. I was able to ask.

  However, in a network spanning multiple segments, fragment packets with the same identifier may arrive at the device via different routes, or the same payload data may be generated as different size fragment packets by retransmission. To do. As a result, a fragment packet having an overlapping area arrives at the apparatus, and there may be a case where the checksum value of the entire packet cannot be obtained by simply adding the checksum value for each fragment packet.

  In the third embodiment, an example will be described in which processing is performed so that the CPU 110 does not have to recalculate all checksum values even when a fragment packet having an overlapping area is received. By performing such processing, a checksum check can be performed at high speed.

  FIG. 10 is a diagram illustrating a configuration example of fragment packets in which duplication occurs due to retransmission processing. In FIG. 10, 1001a represents the IP header portion in the original packet data at the time of transmission, and 1001b represents the payload portion.

  Reference numerals 1002a, 1002b, 1003a, 1003b, 1004a, and 1004b are configuration examples of packets that are fragmented into three pieces after transmission, and indicate an IP header and a payload, respectively.

  Further, reference numerals 1005a, 1005b, 1006a, 1006b, 1007a, 1007b, 1008a, and 1008b are configuration examples of packets retransmitted in response to a TCP retransmission request from the receiving side, and indicate an IP header and a payload, respectively. By passing through a different network route from the packet transmitted first, the packet is fragmented into four parts.

  FIG. 11 is a diagram (part 1) illustrating a configuration example of a received packet when a duplicate fragment packet is generated. In FIG. 11, when the packet is received in the order of “packet indicated by 1101” and “packet indicated by 1102” in the order of the fragment packet, the overlapping area of the payload becomes the range indicated by 1103, and the overlapping area is smaller than half the size of the received packet 1102. small.

  FIG. 12 is a diagram (part 2) of a configuration example of a received packet when a duplicate fragment packet is generated. In FIG. 12, when the fragment packets are received in the order of “packet indicated by 1201”, “packet indicated by 1202”, and “packet indicated by 1203”, the overlapping area of the payload becomes a range indicated by 1204. This overlapping area is larger than half the size of the received packet 1203.

  FIG. 13 is a flowchart illustrating control of software executed by the CPU 110 according to the third embodiment. The CPU 110 always repeats and executes the process shown in FIG.

  The processing from step S1301 to step S1307 is the same as the processing from step S601 to step S607 shown in FIG. 6 of the first embodiment.

  In step S1308, the CPU 110 determines whether the received IP packet is an IP fragment packet based on the inspection result acquired in step S1307. If the CPU 110 determines that the received IP packet is an IP fragment packet, the process proceeds to step S1320. If the CPU 110 determines that the received IP packet is not an IP fragment packet, the process proceeds to step S1309.

  The processing from step S1309 to step S1313 is the same as the processing from step S609 to step S613 shown in FIG. 6 of the first embodiment.

  In step S1320, CPU 110 determines whether or not there is an overlap area between the received fragment packet data and the already received fragment packet data with the same identifier. If the CPU 110 determines that there is an overlapping area, the process proceeds to step S1321, and if it is determined that there is no overlapping area, the process proceeds to step S1314.

  In step S1321, the CPU 110 executes a correction process for the checksum value stored in the checksum value temporary storage unit 108, and the process proceeds to step S1314. Details of the processing in step S1321 are shown in FIG.

  The processing from step S1314 to step S1319 is the same as the processing from step S614 to step S619 shown in FIG. 6 of the first embodiment.

  FIG. 14 is a flowchart showing a checksum value correction process. In step S1401, the CPU 110 performs processing for calculating the size of the overlapping area of fragment packets. The calculation of the size is performed using the packet information of the received fragment packet and the packet information of the fragment packet having the same identifier as the received fragment packet described in the packet descriptor 105a in the reception buffer 105.

  Subsequently, in step S1402, the CPU 110 determines whether or not the calculated size is ½ or less of the size of the received fragment packet. If the CPU 110 determines that the calculated size is ½ or less of the size of the received fragment packet, the CPU 110 proceeds to step S1403. If the CPU 110 determines that the calculated size is not ½ or less of the size of the received fragment packet, The process proceeds to S1407.

  In step S1403, CPU 110 calculates the checksum value of the data in the overlapping area of the received fragment packet. In step S <b> 1404, the CPU 110 reads the checksum value of the received fragment packet stored in the checksum value temporary storage unit 108.

  Subsequently, in step S1405, the CPU 110 obtains a value obtained by subtracting the checksum value calculated in step S1403 from the checksum value read in step S1404. By this process, the checksum value of the data in the non-overlapping area can be obtained. Subsequently, in step S1406, CPU 110 writes the value (checksum value) obtained in step S1405 back to checksum value temporary storage unit 108 again.

  On the other hand, in step S1407, CPU 110 calculates a checksum value of data in a non-overlapping area in the received fragment packet. Subsequently, in step S1408, CPU 110 replaces the received flag surface and packet checksum value stored in checksum value temporary storage unit 108 with the checksum value calculated in step S1407.

  As described above, even when an overlapping area of fragment packets occurs, the calculation process of only the overlapping area and the calculation process of only the non-overlapping area are switched and the checksum value calculated by the checksum calculation unit 103 is changed. Use. Therefore, the checksum check can be performed at high speed without recalculating the checksum value of the entire packet area by software. That is, the calculation amount of the CPU 110 can be reduced.

  Regular packets and non-steady packets (fragment packets) can be processed at high speed with a small circuit scale.

  The preferred embodiments of the present invention have been described in detail above, but the present invention is not limited to such specific embodiments, and various modifications can be made within the scope of the gist of the present invention described in the claims.・ Change is possible.

It is a figure which shows the data structure of the TCP / IP packet in Ethernet (trademark). It is a figure which shows the data structure of an IP packet. It is a figure which shows the data structure of a TCP packet. 1 is a block diagram illustrating an overall configuration of an apparatus according to a first embodiment. 4 is a diagram for explaining a detailed data structure of a reception buffer 105. FIG. 3 is a flowchart illustrating control of software executed by a CPU 110 according to the first embodiment. It is a block diagram showing the whole structure of the apparatus which concerns on Embodiment 2. FIG. It is a figure which shows the structure of the data written in the memory block in the data buffer 105b when a continuous fragment packet is received. 6 is a flowchart illustrating control of software executed by a CPU 110 according to the second embodiment. It is a figure which shows the structural example of the fragment packet in which duplication has generate | occur | produced by the resending process. FIG. 11 is a diagram (part 1) illustrating a configuration example of a received packet when a duplicate fragment packet is generated. FIG. 10 is a diagram (part 2) illustrating a configuration example of a received packet when a duplicate fragment packet is generated. 10 is a flowchart illustrating control of software executed by a CPU 110 according to the third embodiment. It is a flowchart which shows the correction process of a checksum value.

Explanation of symbols

110 CPU
103 Checksum operation unit 105 Reception buffer 107 Fragment checking unit 109 Checksum checking unit

Claims (11)

Checksum calculation means for calculating the data checksum of the received packet;
Checksum checking means for performing a data checksum check using the checksum value obtained by the checksum calculation means and the checksum value stored in the packet header of the received packet;
Fragment checking means for determining whether the received packet is a fragmented packet;
Checksum storage means for temporarily storing the checksum value obtained by the checksum calculation means;
Fragmented packet reassembly process, checksum value stored in the checksum storage means, and reassembly using the checksum value stored in the packet header of the reassembled packet A control means for executing a data checksum check process of the received packet;
Have
When the received packet is determined to be fragmented by the fragment checking means, the control means performs a checksum check, and the fragment checking means determines that the received packet is not a fragmented packet. If so, the checksum checking means performs a checksum check.   2. The protocol processing apparatus according to claim 1, wherein at least the checksum calculation means and the checksum checking means are configured by dedicated circuits. A reception buffer means having a data buffer for storing the reception packet, and a management buffer for storing connection information related to the connection of the plurality of data buffers;
When the fragmented packet is received, the control means uses the concatenation information to control the concatenation of the data buffers in which packets having the same identifier are stored, and recycles the fragmented packet. 3. The protocol processing apparatus according to claim 1, wherein an assembly process is performed. While receiving the fragmented packets in the sequential order from the beginning, each time a packet is received, a checksum addition means is further provided that performs a data checksum calculation of the packet and accumulates the checksum value. Have
When the fragmented packets are received in the sequential order from the head to the tail, the checksum checking means stores the checksum value obtained by the checksum adding means and the packet header of the fragmented packet. Data checksum check using the checksum value that is
When the first fragmented packet received is not at the beginning, or when the fragmented packets are not in a continuous order, the control means performs reassembly processing of the fragmented packets. The protocol processing device according to any one of claims 1 to 3.   The control means performs a data checksum calculation using the data of the overlapping area or the data of the non-overlapping area when there is an overlapping area in each packet among the fragmented packets, and the checksum value 5. The protocol processing apparatus according to claim 1, wherein the checksum value obtained by the checksum calculation means is corrected using the checksum value.   6. The protocol processing apparatus according to claim 5, wherein the control means performs data checksum calculation using data in the overlapping area when the overlapping area is smaller than ½ of the packet length. .   6. The protocol according to claim 5, wherein the control means performs data checksum calculation using data in a non-overlapping area when the overlapping area is larger than half of the packet length. Processing equipment.   The control means performs data checksum calculation using the data of the overlapping area from the checksum value obtained by the checksum operation means stored in the checksum storage means, and obtains the obtained checksum 7. The protocol processing apparatus according to claim 6, wherein a checksum value of a non-overlapping area is obtained by subtracting the value and writing back to the checksum storage means.   The control means calculates the checksum value obtained by the checksum calculation means stored in the checksum storage means by performing data checksum calculation using data in the non-overlapping area. 8. The protocol processing apparatus according to claim 7, wherein a checksum value of a non-overlapping area is obtained by rewriting to a checksum value. A protocol processing method in a protocol processing device,
A checksum calculation step for calculating the data checksum of the received packet;
A checksum check step for performing a data checksum check using the checksum value obtained in the checksum calculation step and the checksum value stored in the packet header of the received packet;
Fragment inspection step for determining whether the received packet is a fragmented packet;
A storage step of temporarily storing the checksum value obtained in the checksum calculation step in a checksum storage means;
Fragmented packet reassembly process, checksum value stored in the checksum storage means, and reassembly using the checksum value stored in the packet header of the reassembled packet A control step for performing a data checksum check process of the received packet;
Have
If it is determined in the fragment checking step that the received packet is a fragmented packet, a checksum check is performed in the control step, and the received packet is determined not to be a fragmented packet in the fragment checking step. If so, a checksum check is performed in the checksum check step.   A program for causing a computer to execute the protocol processing method according to claim 10.

Images