JP4612820B2 - Communication control apparatus and method - Google Patents

Description

  The present invention relates to a communication control apparatus and method.

  Even if it is not a personal computer or the like, opportunities and demands for directly connecting devices to a network are increasing. Examples include portable terminals, printers, cameras, copiers, displays, video equipment, audio devices, and the like. These devices may be equipped with a relatively low-priced and low-processing CPU, or may not be installed at all, such as TCP / UDP / IP that is used as standard in networks using such device resources. If an Internet standard protocol is to be realized, a TCP / UDP / IP protocol stack can be realized with a low processing capacity CPU even at a low bit rate (bandwidth), or a protocol processing such as TOE (TCP / IP offload engine) There is only a method of realizing a relatively broadband network communication by using an auxiliary device specialized for the above. However, while the amount of information handled by devices is large for all of photos, videos, and music, it is necessary to keep the cost of the devices low. It is not difficult to imagine that it will increase in the future.

  In the realization of the TOE (realization with TCP / IP protocol stack hardware), the simplest way to achieve this is to simply implement the method that has been implemented in software until now as hardware. is there. The TCP / UDP / IP protocol stack realized by software is realized by a sufficiently dead method, and this idea is one appropriate idea. However, when the method devised for software (for CPU) is made into hardware as it is, it is realized that it is realized with primitive devices such as gates, registers (flip-flops), and memories. If it is an appropriate way of realizing wear, it must be said that it is different. Hardware is not good at processing methods such as complicated pointer processing, dynamic generation and annihilation of variables, recursion processing, and generation of many processes. TCP / IP protocol stack implemented by software has complicated pointer processing and variables. And procedures such as dynamic creation and disappearance of memory areas exist.

  If the conventional procedure is realized in hardware as it is, the flow will be as follows. (1) A series of transmission data instructed to be transmitted from an application device is temporarily stored in a continuous shared memory area. (2) The uppermost protocol control block references, divides, and adds a header to a series of transmission data stored in the shared memory, and the control is transferred to the next protocol control block together with the access right of the shared memory. Each protocol control block sequentially references, divides, and adds a header to the shared memory. (3) The header and the payload are arranged adjacent to a continuous memory space. If the entire payload cannot be arranged in a continuous memory space, only the payload is arranged in another memory space. (4) The required number of consecutive headers and non-adjacent payloads and frames are stored in the memory as memory control information (generally called mbuf).

  That is, a header is generated after complex payload division and payload and header management information (mbuf) are generated, and this processing is sequentially executed in each protocol stack.

  Patent Document 1 below describes a device that processes TCP / IP in hardware and an operation method thereof.

JP 2001-268159 A

  However, if the above procedure is followed, if TCP segmentation or IP fragmentation by application transfer unit is required, all headers for each frame must be written to the memory. That is, with respect to the MTU that depends on the link layer, as the transfer unit of the application increases, the number of frames generated after the division increases, and the memory area that must be reserved for writing the header that must be added to the frame is increased. There is a problem of increasing.

  In general, a header and a payload are framed and output in a memory. However, if TCP segmentation or IP fragmentation is required depending on the transfer unit of the application, all headers for each frame must be written to the memory.

An object of the present invention is to suppress an increase in a memory area that must be secured for writing a header even when the number of frames to be transmitted increases due to an increase in the transfer unit of an application .

The communication control apparatus of the present invention collects header generation information necessary for header generation of a protocol of a plurality of layers , outputs a header generation instruction and header generation information for each frame, and the header from the protocol control unit When generation instruction and the header generation information is input, the header generates the header of the plurality of layers protocols in parallel to generate for each header, and the header generation means for outputting a generation completion notification header, from the header generating unit When the completion notification is input, and having a header / payload synthesis means for synthesizing the payload header and frames of said generated plurality layer protocol as frames.

Further, the communication control method of the present invention collects header generation information necessary for header generation of a protocol of a plurality of layers , outputs a header generation instruction and header generation information for each frame, the header generation instruction, When the header generation information is input, in parallel headers of the plurality layer protocol generates for each header, and the header generation step of outputting the generated completion notification header and the header generation completion notice is input, And a header / payload synthesis step of synthesizing the generated multi-layer protocol header and frame-by-frame payload as a frame.

According to the present invention, headers of a plurality of layers of protocols are generated in parallel in units of frames and synthesized with a payload in units of frames, so that the number of transmission frames increases due to an increase in the transfer unit of the application. In addition, it is possible to suppress an increase in the memory area that must be secured for writing a header that must be added to the frame.

  FIG. 1 is a block diagram illustrating a configuration example of a communication control apparatus according to an embodiment of the present invention. The configuration will be described below with reference to FIG.

[Application device]
The application device (101) outputs the transmission request (106) and the transmission data length (107) to the frame number frame length calculation unit (102), and outputs the transmission data (110) to the payload division unit (103). Two types of application devices (101) are assumed. The first is a device with a constant bit rate (a constant amount of information per unit time). The second is a variable bit rate device (the amount of information per unit time is not constant, but the amount of information per unit time is specified). In addition, it is assumed that the device is shaped to temporarily buffer information from a variable bit rate device and periodically output a certain amount of information, but this is the same as the first type of device. Can be considered. In addition, a device that outputs RAW information at a quantization bit rate preliminarily defined by the sampling frequency can be assumed, but this can be regarded in the same manner as the first type of device. The communication control apparatus according to the present embodiment connected to all the application devices (101) has a transmission request (106), a transmission data length (107), transmission data (110), and an interface with the application device (101). I will receive it.

[Frame number frame length calculation unit]
The frame number frame length calculation unit (102) divides transmission data into several frames based on the transmission data length (107) that is also input, triggered by the transmission request (106) input from the application device (101). To calculate whether to output.

  The flow of calculating the payload length and the number of headers will be described in detail using the flowchart of FIG. The frame number frame length calculation unit (102) receives the transmission request (106) from the application device (101), and also receives the length of data desired to be transmitted with the one transmission request as the transmission data length (107). (Steps 301 and 302). Then, the frame number frame calculation unit (hereinafter referred to as FFC) needs to calculate the number of frames (FLM_COUNT), the head frame payload length (HEAD_PAY_LEN), the intermediate frame payload length (MID_PAY_LEN), and the final frame payload length (FIN_PAY_LEN). These are first initialized (step 303). When TCP / UDP is assumed as to which frame unit is to be transmitted, an interface MTU or TCP MSS is assumed. First, the interface MTU is acquired (step 304). In addition, when handling a frame formed from TCP / UDP / IP, it is necessary to consider the length of each protocol header in order to calculate the payload length of the frame. Therefore, IPHL (IP Header Length) and UDPHL (UDP Header) Length) and TCPHL (TCP Header Length) are defined (step 305). In this step 305, the basic header length is shown, but when an optional header is assumed in each protocol, the header length including the optional header length is defined on this occasion. Next, it is identified whether the connection type is TCP, UDP or RAW. A method of preliminarily storing the connection type in the FFC (102) and a method of deriving based on the connection identifier are conceivable (step 306).

  In the case of UDP, it is confirmed whether the transmission data length is less than or equal to the interface layer MTU-IPHL-UDHL (step 311). If this is the case, since all the transmission data given in one frame can be stored, it is assumed that the number of frames is 1, the first frame payload length = the transmission data length (step 308). Otherwise, it is necessary to divide the transmission data into a plurality of frames. The operation of calculating the number of divisions and the length of each payload proceeds with the assumption of what happens when a frame is transmitted. First, the temporary transmitted data length (DONE_LEN) is set to 0 (step 312). Next, it is confirmed whether the untransmitted data length is equal to or shorter than the fragment payload length. It is determined whether this is the final fragment. The untransmitted data length is obtained by subtracting the provisional transmitted data length (DONE_LEN) from the transmitted data length, and this is compared with the MTU-IPHL length. (Step 313). In the flow of the prior check so far, it is impossible for the first comparison to make the untransmitted data length equal to or less than the fragment payload length. Next, the number of frames (FLM_COUNT) is incremented (step 314). If the transmitted data length is 0 (step 315), it is determined that it is the first frame, so the payload length of the first frame is MTU-IPHL-UDHL, and the temporary transmitted data length is MTU-IPHL-UDPHL. It is determined that there is (step 317). If it is not the first frame, it is an intermediate frame, so the intermediate frame length is MTU-IPHL, and the provisionally transmitted data length (DONE_LEN) is DONE_LEN + (MTU-IPHL). After these, it is determined again whether the untransmitted data length is equal to or shorter than the fragment payload length (step 313). If it is the final fragment, the final frame is obtained by subtracting DONE_LEN from the transmitted data length. It is determined (step 318). Thereafter, the number of frames corresponding to the final fragment frame is counted up (FLM_COUNT ++) (step 319), and the number of frames, the head frame payload length, the intermediate frame payload length, and the final frame payload length are determined and output (step 310).

  When the connection type is RAW, the number of frames is one and the frame payload length should be within the range of MTU-IPHL. If not, it is assumed that transmission data is cut off and transmitted. Yes. Alternatively, a method of sending a response as an error to the application device (101) can be considered (steps 308 and 309).

  When the connection type is TCP, the frame length is obtained because it is based on MSS (maximum segment size) (step 320). Next, the temporary transmitted data size (DONE_LEN) is initialized to zero (step 321), and it is checked whether the (temporary) untransmitted data length is equal to or less than the MSS (step 322). If it is less than the MSS, it can be determined that the given transmission data can be transmitted in the next one segment. If it is larger than the MSS, the number of frames is incremented (step 323), and if it is the head segment (this determination is made based on whether DONE_LEN is 0) (step 324), the head frame length is MSS, and DONE_LEN is It becomes MSS (step 326). It is checked again whether the provisional untransmitted data length is less than or equal to the MSS. If it is still larger than the MSS, the number of frames is counted up, this time the intermediate frame payload length is set to MSS, and the transmitted data length DONE_LEN = DONE_LEN + MSS is set (step 325). ). Check again whether the untransmitted data length is less than or equal to the MSS. If it is determined that it is the last segment, the final frame length is set to the value obtained by subtracting DONE_LEN from the transmitted data length (step 327). The number of transmission frames is counted (step 328).

  As described above, the number of frames, head frame payload length, intermediate frame payload length, and final frame payload length are determined and output (step 310). These four values are values relating to the number of frames and the frame length, and are output to the payload dividing unit (103), the protocol control unit (115), and the header / payload combining unit (120).

[Division of payload division part]
The payload dividing unit (103) divides the transmission data (110) given from the application device (101) based on the frame number given from the frame number calculation unit (102) and the input (109) related to the frame length. The frame payload is written and stored in the payload TX memory (104) (111). When the frame payload writing is completed, the payload dividing unit (103) notifies the protocol control unit (115) that the frame payload is ready for transmission (136).

[Checksum of payload division part]
The payload dividing unit (103) divides the transmission data (110) given from the application device (101) based on the frame number given from the frame number calculation unit (102) and the input (109) related to the frame length. However, when the frame payload is written and stored in the payload TX memory (104) (111), a checksum of the frame payload is obtained for each frame, and the checksum is calculated by the UDP header generation unit (117) and the TCP header generation unit (116). Tell the value (135).

[TX memory]
In the TX memory (104), a series of transmission data associated with one transmission request is stored as a frame payload column in the frame payload FIFO for each transmission request. As shown in FIG. 3, one FIFO is assigned to one TX request (340) in the TX memory (104), for example, here, it indicates that transmission data by one transmission request is composed of five frame payloads. ing. In this figure, frame payload 1 (first frame) to frame payload 5 (last frame) are stored in the FIFO. However, when transmission is performed in units of frames, five frames are not accumulated in this way. Each frame payload may be extracted and transmitted by the payload reading unit (105) immediately after being inserted into the FIFO.

[Payload readout section]
In response to one payload read instruction (114) from the header / payload combiner (120), the payload read unit (105) extracts one frame payload to be transmitted and outputs it to the header / payload combiner (120). (113).

[Protocol control section]
In response to an instruction from the frame number frame length calculation unit (102), the protocol control unit (115) specifies a necessary header for each frame and collects information necessary for the header, and each protocol header generation unit (116 to 119). Is notified of the header generation instruction and header generation information (122 to 125). FIG. 4 shows a flowchart of the protocol control unit (115). In step S1201, it is determined whether four values (108) of the number of frames, the payload length of the first frame, the payload length of the intermediate frame, and the payload length of the last frame have been received from the frame length calculation unit (102). If it is received (step S1201: Yes), in step S1202, it is determined whether the transmission frame is TCP or UDP, and information for generating a protocol header necessary for frame transmission is collected (step S1203). At this time, information to be collected is performed only for the header added to one frame. That is, at first, information is collected only for the header added to the first frame. In addition, various information to be collected may be set statically or may be dynamically searched. Examples of the dynamic table include a destination IP address, a source IP address, a destination port, an address table for determining a source port associated with a connection, an IP routing table, and the like. Next, it is determined whether a frame payload transmission preparation completion notification has been received from the payload division unit (103) (step S1204: Yes). If a frame payload transmission preparation completion notification is received, it is determined in step S1205 whether header information collection has been completed. When the collection of the header information is completed (step S1205: Yes), a header generation instruction and header generation information are output to the header generation unit that generates a header necessary for the transmission frame in step S1206. After outputting the header generation instruction, it is determined in step S1207 whether header generation instructions for the number of frames have been issued. If the header generation instruction for the number of frames has been issued (step S1207: Yes), the header transmission completion notification of the header instructed to be generated in step S1206 is received from the header / payload synthesis unit (120) in step S1208. When the header transmission completion notification is received, the protocol control is terminated assuming that all the frame headers for one datagram have been transmitted. If the header generation instruction for the number of frames has not been issued in step S1207 (S1207: No), the header of the header instructed to be generated in step S1206 in step S1209 is determined that frames to be transmitted must still be generated. Waiting for reception of the transmission completion notification from the header / payload combining unit (120), and reception of the header transmission completion notification starts the header creation of the next frame (step S1210). Then, the process returns to step S1203.

[TCP header generator]
The TCP header generation unit (116) starts header generation based on the header generation instruction and header generation information from the protocol control unit (115), and after the header generation is completed, a TCP header generation completion notification ( 126). When a TCP header generation instruction is received from the protocol control unit (115), TCP header information is acquired from the protocol control unit (115). TCP header information includes a source port number, a destination port number, a sequence number, an acknowledgment number, a header length, a flag bit, a window size, an emergency pointer and a pseudo IP header destination IP address, a source IP address, a segment length (TCP header) Length + payload length). A TCP header other than the pseudo header and checksum is created from the acquired header generation information. Next, the payload sum for each frame is received from the payload division unit (103), the TCP checksum other than the pseudo header and checksum is calculated, and the TCP checksum is calculated, and the checksum is set in the checksum field of the TCP header. Then, the generation of the TCP header is completed. When the generation of the TCP header is completed, a TCP header generation completion notification is sent to the header / payload synthesis unit (120), the TCP header generation is terminated, and the process waits until there is a next header generation instruction from the protocol control unit (115). The format of the header created by the TCP header generation unit (116) is shown in FIG. 6, and the pseudo header format is shown in FIG.

  When the TCP header generation unit (116) receives the output request (126) from the header / payload synthesis unit (120), it outputs (130) the generated TCP header to the header / payload synthesis unit (120).

[UDP header generator]
The UDP header generation unit (117) starts header generation based on the header generation instruction and header generation information from the protocol control unit (115). After the header generation is completed, a UDP header generation completion notification ( 127). When a UDP header generation instruction is received from the protocol control unit (115), UDP header information is acquired from the protocol control unit (115). The UDP header information includes a transmission source port number, a destination port number, and a UDP data length. A UDP header other than the pseudo header and the checksum is created from the acquired header generation information. Next, it is determined whether the payload sum is received from the payload dividing unit (103). If it is received, the UDP checksum is calculated from the sum of the UDP header and the payload sum other than the pseudo header and the checksum, and the checksum is calculated. Is set in the checksum field of the UDP header, and the generation of the UDP header is completed. When the generation of the UDP header is completed, a UDP header generation completion notification is sent to the header / payload synthesis unit (120), and the UDP header generation ends.

  However, since the checksum of the UDP header is supported as an option, if the UDP checksum is not set, the UDP header information (source port number, destination port number, When the UDP data length) is acquired, the UDP checksum field is set to 0, and a UDP header generation completion notification is output to the header / payload combining unit (120).

  The format of the header created by the UDP header generator is shown in FIG. 8, and the pseudo header format is shown in FIG.

  When the UDP header generation unit (117) receives the output request (127) from the header / payload synthesis unit (120), it outputs (131) the generated UDP header to the header / payload synthesis unit (120).

[IP header generator]
The IP header generation unit (118) starts header generation based on the header generation instruction and header generation information from the protocol control unit (115), and after completion of header generation, the header / payload synthesis unit (120) notifies the header generation of IP header generation (120). 128). When an IP header generation instruction is received from the protocol control unit (115), IP header information is acquired from the protocol control unit (115). The IP header information includes version, header length, TOS, total length, identifier, flag, fragment offset, TTL, protocol, source IP address, and destination IP address. The header checksum of the IP header is calculated from these pieces of information to complete the IP header, and an IP header generation completion notification is sent to the header / payload synthesis unit (120). The format of the header created by the IP header generation unit is shown in FIG.

  When the IP header generation unit (118) receives the output request (128) from the header / payload synthesis unit (120), the IP header generation unit (118) outputs (132) the IP header to the header / payload synthesis unit (120) in the order of generation. .

[MAC header generator]
The MAC header generation unit (119) starts header generation based on the header generation instruction and header generation information from the protocol control unit (115). After the header generation is completed, the MAC header generation completion notification (120) is sent to the header / payload synthesis unit (120). 129). When receiving a MAC header generation instruction from the protocol control unit (115), the MAC header generation unit (119) acquires MAC header information. The MAC header generation information includes a header generation number, a source MAC address, a destination MAC address, and a type length. The MAC header is completed from these pieces of information, and a MAC header generation completion notification is sent to the header / payload synthesis unit (120). The format of the MAC header created by the MAC header generation unit is shown in FIG.

  When the MAC header generation unit (119) receives the output request (129) from the header / payload synthesis unit (120), it outputs (133) the generated MAC header to the header / payload synthesis unit (120).

[Header / payload synthesis unit]
The header / payload combining unit (120) calculates the type and number of headers to be generated from the frame number from the frame number from the frame length calculation unit (102). Next, the header completion notification from each protocol header generator recognizes that the header required for the transmission frame is complete. In the case of TCP / IP, the MAC header generator (119), the IP header generator ( 118), an output request is made in the order of the TCP header generation unit (116) and the payload reading unit (105), the header and payload are read out, combined as a frame, and output to the frame transmission unit (121). In the case of UDP / IP, an output request is made in the order of the MAC header generation unit (119), the IP header generation unit (118), the UDP header generation unit (117), and the payload reading unit (105) in the order of the first frame. Makes an output request in the order of the MAC header generation unit (119), the IP header generation unit (118), and the payload reading unit (105), reads the header and payload, synthesizes them as frames, and outputs them to the frame transmission unit (121). When transmitting a frame having no payload, only the header is read out, combined as a frame, and output to the frame transmission unit (121). The header / payload combining unit (120) outputs a header transmission completion (137) to the protocol control unit (115) when the header is output to the frame transmission unit (121).

[Frame sending section]
The frame transmission (transmission) unit (121) has a function of transmitting the frame output from the header / payload synthesis unit (120) to the outside of the communication control device. In accordance with IEEE 802.3, it performs preamble addition, frame padding, CRC generation, and the like.

<TCP segment transmission example>
FIG. 5 shows an example in which a transmission datagram is divided into three segments at the time of TCP / IP frame transmission. In response to the transmission instruction and transmission data length (1301) from the application device (101), the frame number frame length calculation unit (102) determines the number of frames (three), the payload length of the first frame (PL0 length), The payload length (PL1 length) of the frame and the payload length (PL2 length) of the final frame are output (1302) to the protocol control unit (115) and the header / payload synthesis unit (120). The protocol control unit (115) determines that the protocol type is TCP, and collects TCP, IP, and MAC header information. Further, the payload division unit (103) writes the payload to the TX memory (104), and when the writing for one frame (one TCP segment) is completed, the frame control unit (115) is ready for frame payload transmission (1303). Is output. Upon receipt of frame payload transmission preparation completion (1303), the protocol control unit (115) determines whether header information collection for generating the header of TCP, IP, or MAC of the first frame obtained by segmenting the datagram has been completed. If completed, the header generation instruction and header information (1304) are sent to the TCP header generation unit (116), the header generation instruction and header information (1305) are sent to the IP header generation unit (118), and the MAC header generation unit (119). ) Simultaneously outputs a header generation instruction and header information (1306). The TCP header generation unit (116) that has received the header generation instruction generates a TCP header from the header information from the protocol control unit (115) and the payload sum (1307) from the payload division unit (103), and the header / payload synthesis unit The TCP header generation completion (1308) is output to (120). The IP header generation unit that has received the header generation instruction generates an IP header from the header information from the protocol control unit (115), and outputs an IP header generation completion (1309) to the header / payload synthesis unit (120). The MAC header generation unit (119) that has received the header generation instruction generates a MAC header from the header information from the protocol control unit (115), and the MAC header generation completion (1310) is sent to the header / payload synthesis unit (120). Output minutes. The header / payload combining unit (120) requires a TCP header, an IP header, and a MAC header in the first frame of the frame segmented from the number of frames (1302) received from the frame number frame length calculation unit (102). If all of TCP header generation completion (1308), IP header generation completion (1309), and MAC header generation completion (1310) are received, it is determined that the frame can be transmitted. The header / payload combining unit (120) outputs the first frame to the MAC header, IP header, TCP header, and payload and the read frame sending unit (121). When the MAC, IP, and TCP headers are output to the frame transmission unit (121), the header transmission completion (1311) is output to the protocol control unit (115).

  Upon receiving the header transmission completion (1311), the protocol control unit (115) collects header information of the next frame, that is, the intermediate frame of the frame segmented into three here. The header necessary for the intermediate frame collects information on the TCP, IP, and MAC headers in the same manner as the top. Upon receipt of the next frame payload transmission preparation completion (1312) from the payload division unit (103), it is determined whether or not the header information collection for generating the TCP, IP, and MAC headers of the intermediate frame has been completed. If so, the header generation instruction and header information (1313) are simultaneously output to the TCP header generation unit (116), and the header generation instruction and header information (1314) are simultaneously output to the IP header generation unit (118). The TCP header generation unit (116) that has received the header generation instruction generates a TCP header from the header information from the protocol control unit (115) and the payload sum (1315) from the payload division unit (103), and the header / payload synthesis unit The TCP header generation completion (1316) is output to (120). The IP header generation unit (118) that has received the header generation instruction generates an IP header from the header information from the protocol control unit (115), and outputs an IP header generation completion (1317) to the header / payload synthesis unit (120). .

  The header / payload combining unit (120) requires a TCP header, an IP header, and a MAC header in the intermediate frame of the frame segmented from the frame number (1302) received from the frame number frame length calculation unit (102). When the TCP header generation completion (1316) and the IP header generation completion (1317) are received, it is determined that the frame can be transmitted. Since the MAC header generation completion is output for the number of frames at the time of the first frame, the header / payload combining unit (120) determines that the MAC header generation of the intermediate frame is completed at this time. The header / payload combining unit (120) that has determined that the frame can be transmitted outputs the intermediate frame to the MAC header, the IP header, the TCP header, and the payload and the frame sending unit (121) to be read out. When the MAC, IP, and TCP headers are output to the frame transmission unit, the header transmission completion (1320) is output to the protocol control unit (115).

  Upon receiving the header transmission completion (1320), the protocol control unit (115) collects header information of the next frame, that is, the final frame of the frame segmented into three here. As for the header required for the final frame, information on TCP, IP, and MAC headers is collected in the same manner as the head and middle. Since the next frame payload transmission preparation completion (1318) from the payload division unit (103) has already been received, the TCP header generation unit is completed as soon as the header information collection for generating the TCP, IP, and MAC headers is completed. The header generation instruction and header information (1321) are simultaneously output to (116), and the header generation instruction and header information (1322) are simultaneously output to the IP header generation unit (118). The TCP header generation unit (116) that has received the header generation instruction generates a TCP header from the header information from the protocol control unit (115) and the payload sum (1319) from the payload division unit (103), and the header / payload synthesis unit The TCP header generation completion (1323) is output to (120). The IP header generation unit (118) that has received the header generation instruction generates an IP header from the header information from the protocol control unit (115), and outputs an IP header generation completion (1324) to the header / payload synthesis unit (120). .

  The header / payload combining unit (120) requires a TCP header, an IP header, and a MAC header in the last frame of the frame segmented into three from the number of frames (1302) received from the frame number frame length calculation unit (102). When the TCP header generation completion (1323) and the IP header generation completion (1324) are received, it is determined that the frame can be transmitted. Since the MAC header generation completion is output for the number of frames at the time of the first frame, the header / payload combining unit (120) determines that the MAC header generation of the intermediate frame is completed at this time. The header / payload combining unit (120), which has determined that the frame can be transmitted, outputs the final frame to the MAC header, IP header, TCP header, and payload and the frame sending unit (121) that reads out the frame. When the MAC, IP, and TCP headers are output to the frame transmission unit, the header transmission completion (1325) is output to the protocol control unit (115).

  As described above, according to the present embodiment, there is provided a communication control apparatus that receives transmission data of an arbitrary length from the application device (101) and outputs a frame with an appropriate frame size to a supported data link layer. . The protocol control unit (101) collects header generation information necessary for frame generation, and outputs a header generation instruction and header generation information for each frame. When a header generation instruction and header generation information are input from the protocol control unit (115), the header generation means (116 to 119) generates a header for each header and outputs a header generation completion notification. When a header generation completion notification is input from the header generation unit (116 to 119), the header / payload synthesis unit (120) synthesizes the generated header and the frame-unit payload as a frame. The protocol control unit (115) can output a desired header generation instruction to the header generation units (116 to 119).

  The TX memory (104) is a memory for storing a payload in units of frames. The protocol control unit (115) outputs the next frame after outputting the header synthesized by the header / payload synthesis unit (120) as the previous frame and after the next payload is written in the TX memory (104). The header generation instruction is output to the header generation unit (116 to 119).

  According to this embodiment, even if the number of frames generated after division increases as the transfer unit of an application increases for an MTU that depends on the link layer, a header is generated and transmitted in units of frames. It is not necessary to secure a memory area for writing a header that must be added.

  The above-described embodiments are merely examples of implementation in carrying out the present invention, and the technical scope of the present invention should not be construed in a limited manner. That is, the present invention can be implemented in various forms without departing from the technical idea or the main features thereof.

It is a block diagram of the communication control apparatus by embodiment of this invention. It is a flowchart which shows the flow of payload length and the number of headers calculation. It is a figure which shows TX memory. It is a flowchart of a protocol control part. FIG. 3 is a diagram illustrating a sequence 1. It is a figure which shows a TCP header format. It is a figure which shows a TCP pseudo header format. It is a figure which shows a UDP header format. It is a figure which shows a UDP pseudo header format. It is a figure which shows IP header format. It is a figure which shows a MAC header format.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Application device 102 Frame number Frame length calculation part 103 Payload division part 104 TX memory 105 Payload reading part 115 Protocol control part 116 TCP header generation part 117 UDP header generation part 118 IP header generation part 119 MAC header generation part 120 Header / payload synthesis Part 121 Frame sending part

Claims (11)

Protocol control means for collecting header generation information necessary for header generation of multiple layer protocols and outputting a header generation instruction and header generation information for each frame;
When the header generation instruction and the header generation information from the protocol control unit is input, a header generating means in parallel headers of the plurality layer protocol generates for each header, and outputs the generated completion notification header,
Wherein when the header generation completion notice from the header generating means is input, communication and having a header / payload synthesis means for synthesizing the payload header and frame of the generated multiple layers of protocols as a frame Control device. The header generation means includes
TCP header generation means for generating a TCP header for each header;
UDP header generation means for generating a UDP header for each header;
IP header generation means for generating an IP header for each header;
MAC header generation means for generating a MAC header for each header,
The communication according to claim 1, wherein the protocol control means can output a header generation instruction to the TCP header generation means, the UDP header generation means, the IP header generation means, and the MAC header generation means. Control device.   The protocol control means outputs a header generation instruction for the next frame to the header generation means after outputting the header synthesized as the previous frame by the header / payload synthesis means. Or the communication control apparatus of 2. Furthermore, it has a memory for storing the payload of the frame unit,
The communication control apparatus according to claim 1, wherein the protocol control unit outputs a header generation instruction corresponding to the payload to the header generation unit after the payload is written in the memory. Furthermore, it has a memory for storing the payload of the frame unit,
The protocol control means outputs a header generation instruction for the next frame after outputting the header synthesized by the header / payload synthesis means as the previous frame and after the next payload is written in the memory. The communication control apparatus according to claim 1, wherein the communication control apparatus outputs the data to a generation unit.   The communication control apparatus according to claim 1, further comprising a frame transmission unit configured to transmit the frame synthesized by the header / payload synthesis unit.   The communication control device according to claim 1, further comprising payload dividing means for dividing transmission data into payloads in frame units.   8. The communication control apparatus according to claim 7, further comprising a memory for storing a payload in frame units divided by the payload dividing means.   9. The communication control apparatus according to claim 8, further comprising payload reading means for reading a payload in frame units from the memory and outputting the payload to the header / payload combining means. Furthermore, it has a frame number frame length calculation means for calculating the number of frames and the frame length based on the transmission data length,
The communication control apparatus according to claim 7, wherein the payload dividing unit divides the payload based on the calculated number of frames and frame length. A communication control method performed by a communication control device,
A protocol control step for collecting header generation information necessary for header generation of a protocol of a plurality of layers, and outputting a header generation instruction and header generation information for each frame;
When the header generation instruction and the header generation information is input, a header generating step in parallel headers of the plurality layer protocol generates for each header, and outputs the generated completion notification header,
Wherein the header generation completion notice is input, a communication control method characterized in that it comprises a header / payload synthesis step of synthesizing a payload header and frame of the generated multiple layers of protocols as a frame.

Images