WO2002005499A1 - Device and method for packet formatting - Google Patents

Abstract

A device and method for reformatting data packets, independent of any particular protocol, while maintaining scalability in speed. The packet formatter inputs and writes data words from a data cell stream and a control data stream into a plurality of selectors. The selectors, controlled by a flow controller, selectively determine specific data bytes to read into a forward control for merging the data into reformatted data packets. Machine language instructions for generating the control data are prefetched by a microcode fetch unit and provided to the flow controller which generates the control data and provides it to the selectors to provide for continuous high speed processing and formatting of data packets with minimal processing of software.

Description

DEVICE AND METHOD FOR PACKET FORMATTING

FIELD OF THE INVENTION

The present invention relates to the field of high speed data packet processing for network systems, and in particular, to reformatting data packets for use with different communication protocols.

BACKGROUND OF THE INVENTION

The Internet provides a connection of different kinds of networks for communication, each network of which may be comprised of separate computers itself. However, each of these individual networks may communicate using different communication protocols relating to data packet formatting as well as other parameters. As a result, in order to transfer data packets over the Internet, these packets must undergo many transformations to make them compatible with the networks through which they are being transmitted. For example, data packets may undergo fragmentation in order to accommodate the different maximum size requirements of these networks. This fragmentation may include the insertion of headers into each fragmented portion, as well as providing recalculation to ensure the integrity of the data packets (e.g., checksum recalculations) .

To allow these various networks to communicate and "internetwork", a number of different interfaces need to be supported at mid-network routers and aggregators. For example, data traffic (e.g., a stream of data packets) coming in at one line interface of a network may need to be outputted on a different line interface depending upon the routing requirements of the data stream packets. The problem encountered is when the format required for each interface is different (e.g., Point-to-Point Protocol (PPP) versus Asynchronous Transfer Mode (ATM)). When this occurs, the packets passing through those networks must be converted from one protocol to another for further communication and transfer. In particular, data packets may have to be transferred through many different networks, each with a different communication protocol, before reaching their final destination. Further, these data packets may be encapsulated with different types of communication protocol information. For example, a Transmission Control Protocol (TCP) packet having a payload portion and header may be encapsulated into an Internet Protocol (IP) packet by adding a header, which may also be encapsulated into a PPP packet by adding a header.

It is known to use software to provide conversion and reformatting of data packets for different communication protocols. However, this solution is not fast enough to accommodate the demand today for ever increasing speeds of data transmission on the Internet. Presently known software processing routines are too slow to meet these demanding transmission requirements of the Internet. Further, as the speed of data transmission continues to increase, these software solutions are not scalable. Therefore, what is needed is a device for reformatting data packets for transfer through different networks having different communication protocols, with the device being not only scalable, but protocol independent. Furthermore, such a device would optimally be less dependent on, and speed limited by, its dependence on software. Ideally, such a device would provide for hardware conversion of data packets, and with a design that would be readily scalable and thus capable of conversion speeds faster than are presently achievable.

SUMMARY OF THE INVENTION

The present invention provides a device and method for reformatting data packets, independent of any particular protocol, while providing scalability and speed. The invention provides packet formatting configured to convert data packets from one communication protocol to another as required by the various networks through which the data packet is communicated. The packet formatter provides this conversion by inserting, deleting and replacing specific data bytes in the data packets. The ability to convert packets is obtained by creating within the packet formatter a repository of configurable microcode which can be invoked in a programmable sequence by a control data stream. Therefore, the packet formatter can format packets to and from any protocol set presently known or which may be developed in the future, and is not limited to a specific set of protocols. Additionally, the packet formatter provides for rearranging data bytes within data packets . Therefore, the invention provides high speed operation that is not only scalable for even higher speed operation, but that is highly adaptable because of its communication protocol independence .

Generally, the formatter of the present invention receives two data streams, one data cell stream and one control data stream. These data streams provide the information and data needed for the formatter to convert and reformat a data packet . The data cell stream is comprised of data packets which arrive as consecutive cells and the control data stream is comprised of control packets and/or data packets, which also arrive as consecutive cells. The communication protocol information and associated formatting information is provided at the inputs of the formatter by the control data stream. The identification of this information which is needed for converting the data packets (i.e., header communication protocols encapsulated in the data packet) is preferably provided by packet identification as described in co-pending U.S. patent application entitled "Device and Method For Packet Inspection" and having serial no. 09/494,235 and a filing date of January 30, 2000, which is incorporated herein by reference. However, any external control stream that provides the necessary information for reformatting can be used by the present invention.

Generally, the formatter inputs and writes data words from both the data cell stream and the control data stream into a set of selectors. The formatter then selectively determines which specific data bytes from the selectors are used to form a new data word for assembling with other data words into a reformatted data packet. The formatter has flexibility in processing a continuos stream of data having varied communication protocols. The formatter extracts appropriate protocol conversion information from the control data stream to determine the specific microcode needed to process and reformat the given data packet. This protocol conversion information is used by a microcode flow controller to reformat specific bytes of the data stream.

More specifically, in one aspect of the present invention, a device is provided for reformatting data cell packets using an external control stream comprising an input configured to receive the data cell packets and the external control stream in parallel, a plurality of selectors for selecting cell bytes of the data cell packets and cell bytes of the control data cell stream for reformatting using machine microcode (the starting address for the specific microcode instructions selected for processing is determined by information from the external control stream) , and an output for providing the reformatted data packets from the selectors . The plurality of selectors may be configured in parallel relation to each other. Further, the device may be configured wherein the selector inserts, deletes, replaces or rearranges data bytes for reformatting the data cell packets.

The device may be further configured wherein the selector comprises at least one storage area configured for writing and reading cell bytes. Further, the device may comprise a packet start indicator for determining the start of a new data packet . The external control stream may comprise control information for the data cell packets. In another aspect of the present invention, a packet formatter for reformatting data packets having a stream of data cells using a control stream of data cells, comprises an input for receiving the stream of data cells and the stream of control data cells, a plurality of memory units for storing data bytes of the data cells in parallel, a processor operatively connected to the memory units for selecting the data bytes of the data cells for reformatting using the stream of control data cells and merging the selected bytes into a reformatted data packet and an output for providing the reformatted data packets from the processor. The packet formatter may be configured wherein the processor further comprises a packet control for inserting, deleting, replacing and rearranging data bytes into data packets for reformatting. In yet another aspect of the present invention a method for reformatting data packets in a data stream using an external control stream is provided. The method comprises determining the format of the data packets using reformatting information from the external control stream, storing bytes of the data packets and external control cell stream in parallel, selecting data bytes for reformatting data packets using the reformatting information and reassembling the selected data bytes into the reformatted data packets . The method may further provide inserting data bytes for reformatting the data packets, deleting data bytes for reformatting the data packets, replacing data bytes for reformatting the data packets, or rearranging cells for reformatting the data packets.

In still another aspect of the present invention, a data packet processor is provided and comprises a packet identifier for supplying a pair of data streams with one of said data streams being a stream of data cells and the other of said data streams being a stream of control cells, and a packet formatter connected to the packet identifier for receiving the pair of data streams in parallel . The packet formatter has at least one selector for reformatting the data cells into one of a plurality of predetermined data protocols . The data packet processor may further .comprise a microcode flow control coupled to the selector and to the data streams with the microcode flow control processing appropriate conversion microcode for supplying the appropriate read and write signals to instruct the selector for processing a particular data cell.

The data packet processor may further comprise an extractor for extracting data cell formatting information from each control stream cell as it arrives from the packet identifier and a memory means connected between the extractor and the microcode flow control with the memory means containing the conversion microcode for access by the microcode flow controller. The selector may include a plurality of selectors connected in parallel for parallel processing of the data stream cells and the control stream cells and the data packet processor may further comprise a forward control for receiving the reformatted cells. The memory means may include machine code comprising the conversion microcode and wherein the microcode flow control includes a processor for processing the machine code.

In another aspect of the present invention a data packet processor for reformatting a parallel stream of cells (one of said streams comprising a stream of data cells and the other stream comprising a stream of control cells) comprises a plurality of selectors for parallel processing of both of the streams to thereby reformat the streams . The data packet processor may further comprise a cell processor connected to the selectors for providing a plurality of reformatting instructions to the selectors . The data packet processor may . still further comprise an input and memory means connected to the cell processor for extracting the incoming cell format and supplying the cell processor with machine code for generating the reformatting instructions.

The selectors may further receive each of the control and data cells, and wherein the processor supplies each of the selectors with a reformatting instruction identifying which portion of the data or control cell is to be forwarded into a reformatted cell.

The data packet processor may further comprise a packet identifier connected to the input with the packet identifier providing the parallel streams of cells to the input . The data packet processor may also include a plurality of pairs of dual port memories with each pair of the memories being connected to an input to one of the selectors and holding the data and control cells for processing by the selectors, and further comprise a write control connected to the data packet processor input to receive both of the data stream and the control stream, with each of the write controls being connected to each of the .memories.

In a further aspect of the present invention, a data packet processor for reformatting a plurality of parallel streams of cells is provided wherein the data packet processor comprises a plurality of selectors for parallel processing of the streams to thereby reformat the streams into at least one reformatted stream. The data packet processor may further comprise a memory means connected to said plurality of selectors with the memory means containing conversion information for reformatting the plurality of parallel streams of cells into the at least one reformatted stream having a predetermined data protocol .

While the principal advantages and features of the present invention have been explained above, a fuller understanding of the invention may be attained by referring to the description of the preferred embodiment which follows.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic block diagram of a packet formatter constructed according to the principles of one embodiment of the present invention;

Fig. 2 is a schematic block diagram of an extractor of the packet formatter in Fig. 1;

Fig. 3 is a schematic block diagram of a microcode fetch unit of the packet formatter in Fig. 1;

Fig. 4 is a schematic block diagram of a microcode flow controller of the packet formatter in Fig. 1;

Fig. 5 is a schematic block diagram of a memory unit in a selector of the packet formatter in Fig. 1; Fig. 6 is a schematic block diagram of a write controller of the packet formatter in Fig. 1;

Fig. 7 is a schematic block diagram of a read controller in a selector of the packet formatter in Fig. 1;

Fig. 8 is a schematic block diagram of a forward controller of the packet formatter in Fig. 1;

Fig. 9 is a schematic block diagram of a packet/cell flow controller of the packer formatter in Fig. 1;

Fig. 10 is a block diagram showing packet formatting requirements of an incoming and outgoing data packet; and

Fig. 11 is a block diagram showing the process of the packet formatter in Fig. 1 when processing and reformatting the data packet of Fig 10; and

Fig. 12 is a block diagram showing the packet reformatting process of the packet formatter in Fig.l.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A packet formatter according to a preferred embodiment of the present invention is shown in Fig. 1 and is indicated generally by reference character 100. As shown therein, two data streams arrive at the input to the packet formatter 100.

A data cell stream 102, which is comprised of data packets that are provided as consecutive cells, and a control data stream • 104, which may be comprised of control and/or data packets that are also provided as consecutive cells. For every data packet, there is a corresponding control packet, although each control packet may correspond to more than one data packet . Additionally, multiple control cells may correspond to one data packet. Preferably, the data stream comprises sixty-four byte cells, with each cell including eight words or windows of eight bytes each, which are preferably provided consecutively. As is described in co-pending application entitled "Device and Method For Packet Identification" mentioned above, information needed to process and reformat the data packets is included in the control data stream. However, it should be appreciated by one skilled in the art that the control data stream may be provided by other external sources that include information needed for processing and formatting information. Additionally, it should be noted that machine microcode provided within the packet formatter is processed to reformat the data packets.

Referring again to Fig. 1, the data formatter 100 essentially comprises an extractor unit 106, a microcode (MC) fetch unit 108, a data stream write controller 110, a control stream write controller 112, eight selectors 114 (each of which include a data memory unit 116, a control memory unit 118, and a read controller 120) , a packet/cell flow controller 122 and a microcode (MC) flow controller 124.

In order to process data packets, the write controllers 110 and 112 of the packet formatter 100 write data to each of the selectors 114. However, before the data is written to the selectors 114, the extractor unit 106 extracts data packet information from the control data stream 104 for use by the MC fetch unit 108 and MC flow controller 124 to ensure that the proper microcode is provided by the microcode flow controller 120 to process the associated data packets in the data streams.

Specifically, the extractor unit 116, as shown in Fig. 2, preferably includes a first in - first out (FIFO) controller 126, a start of packet monitor 128, a pipeline 130, a prefetch control register 132 and a start of packet active control 134. The control data stream 104 is received by the FIFO controller 126 of the extractor 106. The words of the control data stream 104, which as illustrated in this disclosure are eight bytes each, are written into the extractor 106 one word at every clock cycle. The start of packet monitor 128 determines whether the control data stream 104, and in particular, whether a word or window of that stream includes a start of packet (SOP) indication or flag indicating that the particular data word being transmitted is the start of a data packet. The prefetch control register 132 preferably acts as a latch to process the control information for that data packet when an SOP signal is detected. It should be noted that before a data word reaches the last four locations in the FIFO controller

126, it is processed by the prefetch control register 132 for the SOP indication and packet-formatting information is extracted out of it. The packet-formatting information of the control data packet is processed by the MC fetch unit 108 for use in determining and forwarding microcode instructions to process the data packets . The prefetch operation ensures that the time needed to load a microcode instruction into the MC flow controller 124 before the data at the extractor 104 inputs is to be processed, is met. Also, delay in processing time is reduced, if not eliminated.

The information extracted is sent to the MC fetch unit 108 and the packet/cell flow controller 122, as signals. As shown in Fig. 2, these signals preferably include the SOP to indicate the start of a new packet, a micro-code instruction pointer (MCIP) which identifies the instructions in a microcode (MC) table 136 to process and reformat the data packet, a new packet length signal for use in calculating when the end of the data packet will occur, and a block control bit signal for use by the write controllers 110 and 122, and the selectors 114 to determine where to read and write in the selector memory. These signals are specifically provided from the prefetch routine to ensure that the MCIP is extracted from the control data stream 104 with enough time for the MCIP to be used as a lookup index in the MC table 136, with the corresponding microcode instruction loaded into the MC flow controller 124 for processing of the data packets. This prefetch feature provides the advantage of speed in processing because the MC flow controller 124 is not waiting for instructions (i.e., control signals) to process and reformat a particular data packet .

A control word is forwarded to the pipeline 130 once the prefetched information is communicated to the MC fetch unit 108. It should be noted that if one SOP indicator immediately follows another SOP indicator in the extractor 106 before the first SOP indicator reaches the control stream write controller 112, it is stalled or held back to ensure that the SOP signal and other fields in the MC fetch unit 108 are not overwritten. Therefore, once the data word containing the SOP indicator exits the pipeline 130, the extractor 106 is ready to extract another SOP indicator for processing. For example, if the MC flow controller 124 is not ready to process the incoming data packet, it will de-assert the read control data signal (read Ctrl data) , such that even if the extractor 106 has outputted a control data ready signal to the MC flow controller 124, indicating that control data is ready to process, the logical AND function as shown in Fig. 2 prevents the processing of the new data packet. The MC flow controller 124 will not assert the read control data signal until it is ready to process the new data packet .

It should be noted that the SOP signal is sent to the start of packet monitor 128 to indicate that another start of packet signal cannot be asserted. This also prevents overwriting of previously generated instructions . Once the data word containing the SOP signal has processed through the pipeline 130, which is preferably four data words wide (giving sufficient time to process the control information) , the SOP signal is used to de-assert the start of packet active controller 134, which again activates the start of packet monitor 128 to monitor for SOP indications. Therefore, once the SOP data word has reached the last window in the pipeline 130, the microcode required to process the data streams is already encoded in the MC flow controller 124.

The prefetch control register 132 and the start of packet active controller 134 provide the control signals to the MC fetch unit 108. The MC fetch unit 108, as shown in Fig. 3, preferably comprises an address controller 138 (e.g., a multiplexer) and logic to provide the control signals. The asserted SOP signal selects the address controller 138 input to send the MCIP signal received from the prefetch control register 132 to the MC table 136 only when the packet/cell flow controller 122 asserts its get next instruction pointer (GNIP) , indicating that the MC flow controller 124 is ready to process the new data packet. As is shown, the MC instruction pointer passes through a microcode address register 140, which processes and provides the specific start address for retrieval from the MC table 136, which is sent to the MC flow controller 124. It should be noted that the specific start address points to specific machine microcode in the MC table 136 which provides for reformatting the data packet. The MC table 136 includes machine microcode instructions for processing and reformatting between many different communication protocols, including for example, communication protocols necessary for Internet communication. The machine microcode in the MC table 136 may include any instructions necessary to reformat data packets as is required, and is not limited to any specific reformatting instructions, but may accommodate new protocols that may be developed.

The address controller 138, during normal operation, will be incremented by one with the current address +1 signal that is generated with each pass through the MC address register 140 by the adder. However, the MC flow controller 124 may not be ready for the next instruction or may need to jump to a non- consecutive microcode instruction address. The MC flow controller 124 can send a stall signal to the address controller 138, which causes the address controller 138 to output the current address signal, thereby maintaining the current microcode address instruction for the clock cycle. This signal also causes the MC active signal to be de-asserted so that any microcode sent to the MC flow controller 124 will be disregarded as not valid.

The MC flow controller 124 can also assert a jump signal to the address controller 138 which will cause the jump address signal from the MC flow controller 124 to pass through the MC address register 138 and select a non-consecutive microcode instruction address in the MC table 136 (i.e., the current MCIP is updated) . Therefore, only when the MC active signal sent with the microcode (as shown in Figs. 1 and 3) are asserted, does the MC flow controller 124 process the microcode instruction.

The MC flow controller 124 of the present invention, as shown in Fig. 4, preferably comprises a microcode (MC) cache table 142, a stall controller 144 and a microcode (MC) decoder 146 which provides microcode instructions. Provided below as Exhibit A is the preferred microcode instruction set for the packet formatter 100.

Referring now specifically to the MC flow controller 124, as shown in Fig. 4, if the MC active signal is asserted, the MC cache table 144 passes the microcode to the stall controller 144. In the event that the MC active signal is not asserted, indicating that the information being sent is not valid, the MC flow controller 124 will disregard the microcode. If the MC active signal is asserted, but the stall control 144 issues a stall signal (e.g., the microcode indicates that a data word should be written into a selector 114, but the data word is currently not available for writing) indicating that the MC flow controller 124 is not ready to process another microcode instruction, the MC cache table 142 holds the microcode instruction. The stall controller 144 will continue to assert the corresponding read control (ctrl) data and read data signals (from the microcode) in an attempt to continue processing the data bytes in the selectors 114. Once, the data is available for reading, the stall signal is de-asserted, the data bytes will be processed, and the packet formatting process resumes . Note that the MC cache table 142 is preferably four words wide, which is needed to accommodate a stall operation (e.g., when extra processing time is needed by the MC fetch unit 108 because it is attached to a static read-only-memory (SRAM) and cannot stop processing signals immediately upon receiving the stall signal) . Also, if an end of packet (EOP) signal is received by the microcode flow controller 124, no stall will occur (e.g., the packet formatter needs to complete processing the end of a data packet that includes "padding" by writing a pattern into the memories 116 and 118) .

If the stall controller 144 receives valid microcode (i.e., MC active signal asserted) it will send the read Ctrl data and read data signals to the extractor 106 and data stream 102, respectively, indicating that the data words of the control stream 104 can be forwarded to the control stream write controller 112 and the data words of the data stream 102 can be forwarded to the data stream write controller 110. The microcode instruction is also processed in the MC decoder 146 for providing control signals to the selectors 114.

The microcode decoder 146 provides the control signals to the data stream write controller 110 and the control stream write controller 112 to initiate the write command to the selectors 114. This is provided by the CWriteMC and DWriteMC signals. Each of the write controllers 110 and 112 write their respective data word to all of the selectors 114 in parallel, with the data word stored in the data memory unit 114 and the control word stored in the control memory unit 116. The memory units are preferably dual port random access memories (DPRAMS) which allow for simultaneous read and write operation. To further provide added versatility and speed, as well as ensuring that data is not overwritten, each memory unit includes two blocks 148, each preferably eight bytes wide (the size of one word), as shown in Fig. 5. Each block is further preferably provided with a buffer area 150 and a loop area 152. The provision of multiple blocks provides pipelined operations between data packets (e.g., a new data packet to be written into the memory is received before data from a previous data packet is completely read out of the memory, and thereby avoids bytes from the new data packet being read into and corrupting the previous packet being reformatted) . Thus, data words can be written and read in parallel from different areas of the memory. To provide for rearrangement of bytes, words can be maintained in the buffer area 150 for a determined number of clock cycles provided by the MC flow controller 124. Additionally a fixed buffer area may be provided for inserting or replacing data from another source.

It should be noted that buffer area 150 is provided to store bytes which will be repeated, for example, when used again in a new data packet, while the loop area 152 provides for small scale permutations within a portion of a data packet. The selection of the buffer area 150 is particularly useful, for example, in the case of fragmentation, wherein control data may have to be maintained for several data packets. It should also be noted that data word alignment in the present invention is provided by processing one word in each clock cycle. Additionally, the control signals are clocked each cycle. Further, delays are provided in the various component parts of the packet formatter 100 to ensure proper data processing and integrity of that process.

Returning to Fig. 4, the MC flow controller 124 also sends out a block signal to control which memory block in each selector 114 the data word is written. As shown in Fig. 6, the write controllers 110 and 112 are provided with a buffer area pointer control 160 and a loop area pointer control 162 which output the address to which the current data word should be written in the memory units of the selectors 114. When an SOP signal is received by the write controllers 110 and 112, the buffer area pointer 160 and loop area pointer 162 are reset. The microcode determines to which area data is written.

The block signal is also provided through the write controllers 110 and 112 to select the block 148 in the memory unit. The write signals WriteMC provide the specific address location in the buffer area 150 or the loop area 152 of the memory unit to write the data. Additionally, a write enable signal (WEN) is provided for indicating that the data word should be written into the address of the memory units of the selectors 114 as determined by the pointers 160 and 162.

The MC flow controller 124 also sends out read control signals ReadMC 0 through ReadMC 7, and corresponding block signals to the read controllers 120 of the selectors, which signals provide for selecting the following: the data memory unit 116 or control memory unit 118, the block 148, the address of the word to be read and the address of the byte to be selected. This addressing is determined by the specific microcode provided by the MC fetch 108 from the MC table 136 to the MC flow controller 124. It should be noted that the read control signals are reset by the microcode flow controller 124 upon receiving an SOP signal.

Referring now to Fig. 7, the read controller 120 is preferably provided with a read decoder 154 which processes the signals received from the MC flow control 124. The read decoder 154 provides a selector D_C output to select between either the data packet or control packet. A byte selector is also provided from the read decoder 154 to select the address of the word and byte in the selector 114 memory unit from where data is to be read. Additionally, the decrement signal (deer) is processed through the read decoder 154 to a decrement unit 156 which provides a decrement signal (essentially a time to live (TTL) indication) to prevent the formatted packets from cycling through networks endlessly, for example, if routers to which the data packet is transmitted are busy. The count of the decrement indication (i.e., TTL) is also decreased by other routers to ensure that if at some predetermined period of time, the data packet has not reached its destination address, it will be disregarded.

Once the data byte is selected by the read controller, the selected byte is written into an FIFO in the forward control unit 158, as shown in Fig. 8. It should be noted that data words are not always written at each clock cycle. Further, more than one data word may be written at each clock cycle. Therefore, an asynchronous enqueue controller 166 is needed to provide the full eight byte data words, one full word at a time, though the FIFO, and to the synchronous dequeue controller 168 for merging as a reformatted assembled data packet. Therefore, the eight selected bytes are forwarded in parallel through the FIFO to the synchronous dequeue controller 168. Depending upon the outgoing communication protocol, either a header checksum or CRC (i.e., outgoing protocol is ATM) must be included in the data packet . The old checksum control 160, new checksum control 162 and checksum insertion control 164 provide for incremental header checksum calculations to be included with the reformatted data packet if necessary. This may be accomplished by using, for example, the incremental checksum procedure defined in RFC Standard 1624, entitled "Computation of the Internet Checksum via Incremental Update" (May 1994) .

With reference now to Fig. 9, the packet/cell flow controller 122 of the present invention is shown in its preferred embodiment. The packet/cell flow controller provides the GNIP signal based on the SOP signal and the length of the data packet, as provided from the new packet length signal of the prefetch control register 132 in the extractor 106. The packet/cell flow controller 122 calculates the length of a new data packet (using the new packet length signal from the extractor 106) and the length of the packet header and compares that total length to the maximum data cell size minus the cell header, each time a cell is processed. When the remaining packet length is less than the maximum cell size minus the cell header, the near end of packet (NearEOP) signal is generated and sent to the MC flow controller 124 (this signal is pre- calculated and the NearEOP signal is generated based on the remaining packet length before the last cell is processed, which provides a Near EOP signal which can be used by the microcode decoder 146 for a conditional near end of packet jump) . This provides the MC flow controller 124 with an additional indication in the event that the microcode instructions are to be processed at a later time, for example, when a jump instruction is needed.

When an SOP signal is sent to the packet/cell flow controller 122 and the remaining cell size is less than the maximum cell size minus the cell header (i.e., the next cell is a new packet) or when the remaining cell size is less than the maximum cell size minus the cell header, and the WordCounter is equal to zero (decreases from 7 to zero if the cell size is 8 words) , the packet/cell flow controller 122 generates the end of packet (EOP) signal indicating that the cell is the last data cell in a given packet . The WordCounter provides for processing of the data stream in eight byte word cells. To provide time for the next pointer instruction to be processed so that operation of the packet formatter 100 is continuous, the GNIP signal is generated when the WordCounter is equal to four (i.e., there are 4 remaining words in the cell to process) and the EOP signal is asserted, indicating that the last cell in the data packet is going to be processed. This again accommodates for the possible delay of the MC fetch 108 due to the SRAM to which it is connected.

In operation, the packet formatter 100 takes a data stream 102 and a control stream 104, which represents, for example, an incoming data packet that needs to be reformatted to the outgoing data packet because different protocols are required, and replaces or adds cell headers as needed, as well as inserts new data bytes as required. An example of the operation of the packet formatter is illustrated in Figs. 10- 12. Fig. 10 illustrates an example of the packet formatting changes required in the packet formatter 100 given the incoming packet and outgoing packet as shown. In this example, the incoming packet needs to be reformatted to the outgoing packet . The reformatting that must occur is as follows : the first word must be replaced with the new cell header and new PIE header (which may be proprietary protocol information or other reformatting and/or conversion information from an external source) ; then the PPP header must be attached followed by a new IP header; finally a new cell header must be placed in every eighth word of a cell . Note that the new bytes to be inserted come from the control data stream 102. Fig. 11 shows the clock cycle and the results of each of the signals in the packet formatter 100 when processing the packets of Fig. 10. An asserted signal is represented by a "1" and a de-asserted signal is represented by a "0". In this example, the read and write operations for the control data are completed in the first three cycles, and the remaining cycles read and write data bytes .

With respects to Fig. 12 and to the specific operation of the packet formatter 100, an eight byte word from each of the data stream 102 and control stream 104 are inputted into the data stream write controller 110 and the control stream write controller 112, respectively, when instructed by the microcode flow controller 124. These write controllers then write in parallel, a data word of each of their respective data cells to their respective memory units in each of the selectors 114.

The read controllers 120, controlled by the MC flow controller 124 (which obtains its microcode instructions from information in the control stream 104, which was extracted from the control data stream 102 by the extractor 106 and processed in the MC fetch unit 108) then read specific bytes, as instructed by the MC flow controller 124, into the FIFO of the forward controller 158. This process continues until the required data bytes are merged and the data packet reassembled for communication with the new protocol . Provided below as Exhibit B is an example of the C-code preferably used for generating the machine microcode for the MC table 136. Exhibit C is another example of a preferably used C-code for generating the machine microcode for the MC table 136. These examples show the adaptability of the present invention to reformat data packets to different protocols as necessary. The C-code is compiled by a C-compiler for assembly into the MC table 136. Note that some of the terminology used in the Exhibits differs from terminology used in this specification, but such differences would be readily apparent to one of skill in the art and are not considered to materially interfere with a complete understanding of the present invention as disclosed herein. The processing and formatting of the packet formatter 100 occurs at high speed due to the parallel structure of the packet formatter 100, and in particular, the parallel arrangement of the selectors 114 and the manner in which data is read and written to the selectors. However, it should be understood by one skilled in the art that the packet formatter 100 may be configured in alternate ways. For example, the packet formatter 100 may be configured to read in only specific bytes and write out one word at a time, which reduces the hardware complexity and memory requirements, but limits the flexibility of the packet formatter 100. Therefore, depending upon the specific application, the read and write functions may be modified. Additionally, the packet formatter 100 may process and merge more than two data cell streams. These modifications would merely require minor programming changes, including modifications of the microcode, and would not require any significant hardware changes.

Although the packet formatter 100 of the present invention has been described in detail only in the context of reformatting data packets for use in routing processes, the packet formatter may also be readily configured to accept different external control streams for processing in other non- networking applications and anywhere it is required to reformat data from one protocol to another.

Further, it should be understood that the present invention is not limited to the specific number of component parts as illustrated. For example, the eight selectors 114 for processing the eight byte words, with eight words per data cell, was selected because of the Internet application as illustrated. More selectors may be used as required or desired and the cell or word size that is processed also modified (e.g., bits). Additionally, changes to the size of the blocks in the memory units of the selectors 114 is also contemplated. This flexibility provides for the scaleability in speed of the invention.

Additionally, the various block representations as described herein represent hardware implementation of the invention, such as in chip architecture. Several of the chips or functions could be incorporated into a custom chip. Although not preferable, one or more of the functions performed in hardware could be implemented in software.

There are various changes and modifications which may be made to the particular embodiments of the invention described herein, as recognized by those skilled in the art. However, such changes and modifications of the invention may be constructed without departing from the scope of the invention. Thus, the rights in this invention should be limited only by the scope of the claims appended hereto, and their equivalents.

Packet Formatter

O D Microcode Instructions O

O

3

Microcode for Packet Formatter

Control I Bits I Remark

JMP OPERATION 2^,b00-oJMP;check for extended code

2'bOl-JMP

13:0 2'blO-JMP not EPO

2'bll-JMP EPO

JMPAdrr/ 12 If JMP or JMPNEOP asserted, Jump Address, Ext. Microcode otherwise used for extended Microcode

Write Control I Write Control for Buffered Data to DP RAM 1

2'b00:NOP

15:14 2'b01:Write to buffer area

2'b 10: Write to loop area

2'bl l:Reserved (Write to Buffer and Loop Area)

Write Control II Write Control for CPU Data

2'b00:NOP

17:16 2'b01 :Write to buffer area

2^,blO:Write to loop area

2'bl l:Reserved (Write to Buffer and Loop Area)

18 Forward Control Forward merged data

DP Selector Selects Dual Port to read from

19 l'bO:Packet Dat DP

S1 l*bl:CPU Data DP

23:20 Read Address I 0:3 Read Address for DP RAM

26:24 Byte Selector 0:2 Selects which Byte is chosen from Output

. . .So 82:27 Selector II - Vffl 56 Read Information for each individual Selector Parity 89:83 Parity Parity across the microcode

/* $Id: atm-linecard.c,v 1.12 1999/11/03 23:48:43 steve Exp $ Celox */

/*.

This Software and Related Documentation are Proprietary to Celox Communications, Inc.

Copyright 1999 Celox Communications, Inc., St. Louis, MO

Unpublished -

All Rights Reserved Under the Copyright Laws of the United States.

Restricted Rights Legend: Use, Duplication, or Disclosure by the Government is Subject to Restrictions as Set Forth in Paragraph (c) (1) (ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013. Celox Communications, Inc.

tinclude "cxdef . " #include "pm.h" #include "mc routines. "

/*

* Forward an incoming ATM packet from the linecard to the switch

* fabric. Strip the eight byte LLC/SNAP header from the payload data. *

* This microcode expects the following format in the data cells: *

* _{+ +}

* cell 0 I ATM header word 1 |

* + +

* I ATM header word 2 |

* + +

* I LLC/SNAP header |

* + +

* I Payload |

*

* _{+ +}

* cell n I ATM header word 1 |

* _{+ +}

* I ATM header word 2 |

* + +

* I Payload | *

* And it expects the following format in the CPU packet:

*

* 0 + +

* I pdlen, FlowID, CSIX HDR |

* 1 1 1 PIE Header |

* The outgoing cells will look like this:

* cell 0 1 FlowID | PIE Header |

* + + + +

* I Payload | *

* * cell n I FlowID | Payload |

* + + +

* I ... I

*

*/ int atm_ingress_format (pm_pfu_inst_ptr ptr, FILE * h, int offset)

{ int i, count; uint8 csix_cell, mark, last_cell = 0; uint8 atm_slice; /* 0 to 7 */ uint8 csix_slice; /* 0 to 7 */ uint8 cur__sel; /* 0 to 7 */

#define MAX_CELLS_TO__TRY 100 count = 0 ; f rintf(h, "#define ATM_INGRESS_START_ADDR %d\n", offset);

/*

* Instruction 0: Write CPU and CELL data

*/ set_cmd_info (&ptr [count] , CELL_LOOP, CPU_LOOP, NOENQUEUE); count++;

/*

* Instruction 1: Write CPU and CELL data

*/ set_cmd_info (&ptr [count] , CELL_LOOP, CPU_LOOP, NOENQUEUE); count++;

/*

* Instruction 2: Write CPU and CELL data plus read FLOWID and

* PIE Header from CPU data.

*/ set_cmd_info (&ptr[count] , CELL_LOOP, CPU_NOREAD, ENQUEUE);

/* Source Flow ID */ set_read_info (&ptr[count] , 0, CPU_DATA, 0, 6) ; set_read_info (&ptr[count] , 1, CPU_DATA, 0, 7);

/* PIE Header */ for (i = 2 ; i < 8 ; i++) set_read_info (&ptr [count] , i, CPU_DATA, 1, i) ; count++; csix_slice = 1; /* FlowID and PIE header already written */ atm_slice = 3; /* Skip 2 slice (16 byte) ATM header + LLC/SNAP */ cur_sel = 0; for (csix_cell = 0 ; csix_cell < MAX_CELLS_TO_TRY ; csix_cell++) { if (atm_slice == 4 && cur_sel == 0)

{ if ( csix_cell ==. 1 ) mark = count + 1 ; else

{ pdebug(D_ASSERT, dtag, "@ loop at CSIX cell %d, instr %d\n", csix_cell, count) ; set_conditional_jurαp (&ptr [count + 1], mark + offset + 1) ; /* Damn off by one problems... */ ptr[count - 1] . rite_ctrll = 0; last__cell = 1; } } else if (last_cell) break; while (csix_slice < 8) {

/*

* Handle special case where we've reached the end of the

* ATM cell and need to handle the header of the next cell.

*/ if (atm_slice == 7 && cur_sel)

{

/*

* There's less than a full slice left in the previous

* ATM cell

*/ if (csix_cell < 2 | | csix__cell % 4)

{ set_cmd_info (&ptr[count] , CELL LOOP, CPU_NOREAD,

NOENQUEUE) ; count++; } set_cmd_info (&ptr [count] , CELL_LOOP, CPU_NOREAD, NOENQUEUE); count++; set_cmd_info (&ptr [count] , CELL_LOOP, CPU_NOREAD, ENQUEUE);

/* Skip the flow ID in the first dice of CSIX cell */ if (csix_slice == 0)

{ set_read_info(&ptr [count] , 0, CPU_DATA, 0, 6) ; set_read_info (&ptr [count] , 1, CPU_DATA, 0, 7); i = 2; } else i = 0;

/* pick selector data */ for (; i < 8 ; i++)

{ set_read_info(&ptr [count] , i, CELL_DATA, atm_slice, cur_sel) ; if (++cur_sel == 8) { atm slice = 2; cur_sel = 0 ; } } csix_slice++; count++;

} else if (atm_slice == 8)

{

/* * We used up the entire ATM cell evenly

*/ if (csix_cell < 2 11 ( (csix_cell % 8) == 0)) { set cmd info (&ptr[count] , CELL_LOOP, CPU NOREAD,

NOENQUEUE) ; count++;

} set_cmd_info (&ptr [count] , CELL_LOOP, CPU_NOREAD, NOENQUEUE); count++; atm_slice = 2; cur sel = 0;

} else

{ set_cmd_info (&ptr [count] , CELL_LOOP, CPU_NOREAD, ENQUEUE);

/* Skip the flow ID in the first dice of CSIX cell */ if (csix_slice == 0)

{ set_read_info (&ptr [count] , 0, CPU_DATA, 0, 6) ; set_read_info (&ptr [count] , 1, CPU_DATA, 0, 7); i = 2; } else i = 0;

/* pick selector data */ for (; i < 8 ; i++)

{ set_read_info (&ptr [count] , i, CELL_DATA, atm_slice, cur_sel) ; if (++cur_sel == 8) { atm_slice++; cur_sel = 0; } } csix_slice++; count++;

}

/* We're starting a new CSIX cell. */ csix_slice = 0;

/* Source Flow ID */ set_read_info (&ptr[count] , 0, CPU DATA, 0, 6); set_read_info (&ptr[count] , 1, CPU DATA, 0, 7 ) ;

if (csix_cell >= MAX_CELLS_TO_TRY) { pdebug(D_ASSERT, dtag, "@ Holy shit batman! This code don't loop\n"); exit (1) ;

} return count;

/* $Id: pos-egress.c,v 1.1 1999/10/20 19:31:59 steve Exp $ Celox */

/*

This Software and Related Documentation are Proprietary to Celox Communications, Inc.

Copyright 1999 Celox Communications, Inc., St. Louis, MO

Unpublished -

All Rights Reserved Under the Copyright Laws of the United States.

Restricted Rights Legend: Use, Duplication, or Disclosure by the Government is Subject to Restrictions as Set Forth in Paragraph (c) (1) (ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013. Celox Communications, Inc. *

#include "cxdef . h" tinclude "pm.h" #include "mc_routines .h"

#define POS_PPP_HEADER_SIZE 4

/*

* Forward an outgoing CSIX packet from the switch fabric to the POS

* interface. (IE: an ATM Egress Linecard configuration) *

* This microcode expects the following format in the data cells:

* cell 0 I FlowID | PIE Header |

* I Payload | *

*

* cell n I FlowID | Payload |

* + + + +

* I . . . I

*

* And it expects the following format in the CPU packet: *

* + +

* I pdlen, flowid, csix hdr |

* _{+ +}

* I PPP header |

* _{+ +}

*

* The outgoing cells will look like the following: *

* cell 0 + + +

* I PPP header | |

* + + +

* I Payload |

* cell n + +

* I Payload | *

*/ int pos_egress_format (pm_pfu_inst_ptr ptr, FILE * h, int offset) int i, count ; uintl6 pos_cell; uintlβ mark; uintδ last_cell = 0; uint8 pos_slice; /* 0 to 7 */ uint8 csix_slice; /* 0 to 7 */ uint8 cur_sel; /* 0 to 7 */ count = 0 ; fprintf(h, "#define POS_EGRESS_START_ADDR %d\n", offset);

/*

* Write CPU and CELL data

* (The first CPU word is mostly useless in EGRESS mode, and

* the first cell data is FlowID + PIE Header) */ set_cmd_info (&ptr [count] , CELL_LOOP, CPU LOOP, NOENQUEUE); count++;

/*

* Write CPU and CELL data

* (First valid CSIX data slice + PPP header in CPU data) */ set_cmd_info (&ptr [count] , CELL_LOOP, CPU_LOOP, NOENQUEUE); count++;

/*

* Write CPU and CELL data plus read ATM header slice 2

*/ set_cmd_info (&ptr [count] , CELL_NOREAD, CPU_LOOP, ENQUEUE); for (i = 0 ; i < POS_PPP_HEADER_SIZE ; i++) set_read_info (&ptr [count] , i, CPU_DATA, 1, i) ; for ( ; i < 8 ; i++) set_read_info (&ptr [count] , i, CELL_DATA, 1, i - POS_PPP_HEADER_SIZE) ; count++;

/*

* Okay, at present we have the entire CPU buffer read into

* the selectors and we have written the POS PPP header and

* the first partial cell slice into the outgoing packet. */ csix_slice = 1; pos_slice = 1; cur_sel = POS_PPP_HEADER_SIZE; pdebug(D_ASSERT, dtag, "@ Generating code for POS Egress with a " "%d byte PPP header\n", POS_PPP_HEADER_SI E) ;

/*

* We now go into a loop, reading 62 bytes from each incoming CSIX

* cell and writing 64 bytes into each outgoing POS cell. When we

* recognise we're back in the starting state, then set a jump

* pointer, finish the current cell, then exit. */ for (pos_cell = 0 ; pos__cell < 15 ; pos_cell++) {

/* Loop detection code */ if (csix slice == 0 && cur sel == 2) { if (pos_cell < 3 ) { pdebug(D_ASSERT, dtag, "@ Setting mark at POS cell %d\n", pos_cell) ; mark = count; } else { pdebug(D_ASSERT, dtag, "@ found loop at cell %d, instr

%d\n" , pos_cell, count) ; set_conditional_jump (&ptr [count + 1], mark + offset); last_cell = 1; } } else if (last_cell) break; while (pos_slice < 8) {

/*

* Handle special case where we've reached the end of the

* CSIX cell and need to handle the header of the next cell. */ if (csix_slice == 7 && cur_sel)

{

/*

* There's less than a full slice left in the previous

* CSIX cell V set_cmd_info (&ptr [count] , CELL_LOOP, CPU_NOREAD, NOENQUEUE); for (i = 0; i < 8 ; i++)

{ set_read_info (&ptr [count] , i, CELL_DATA, csix_slice, cur_sel) ; if (++cur_sel == 8)

{ csix_slice = 0; cur_sel = 2; } } pos_slice++; count++;

} else if (csix_slice == 8)

{

/*

* We used up the entire CSIX cell evenly

*/ set_cmd_info (&ptr [count] , CELL_LOOP, CPU_NOREAD, NOENQUEUE); count++; csix_slice = 0; cur_sel = 2;

} else

{ set_cmd_info (&ptr [count] , CELL_LOOP, CPU_NOREAD, ENQUEUE); for (i = 0; i < 8 ; i++)

{ set_read_info (Sptr [count] , i, CELL_DATA, csix_slice, cur_sel) ; if (++cur_sel == 8) { csix_slice++; cur_sel = 0; } } pos_slice++; count++; } }

/* We're starting a new POS cell. */ pos_slice = 0; } if (pos_cell >= 50) pdebug(D_ASSERT, dtag, "@ Holy shit batman! This code don't loop\n"); return count;

Claims

What is claimed is :

1. A device for reformatting a stream of data cell packets using an external control data cell stream, the device comprising: an input configured to receive the data cell packets and the external control data cell stream in parallel; a plurality of selectors connected to the input for selecting cell bytes of the data cell packets and cell bytes of the control data cell stream received from the input for reformatting using the external control data cell stream; and an output connected to said selectors for providing said reformatted data packets from the selectors.

2. The device according to claim 1 wherein the plurality of selectors are configured in parallel relation to each other.

3. The device according to claim 2 wherein each selector is configured to insert data bytes for reformatting the data cell packets.

4. The device according to claim 2 wherein each selector is configured to delete data bytes for reformatting the data cell packets.

5. The device according to claim 2 wherein each selector is configured to replace data bytes for reformatting the data cell packets .

6. The device according to claim 2 wherein each selector is configured to rearrange data bytes for reformatting the data cell packets.

7. The device according to claim 2 wherein each selector further comprises at least one dual port memory having at least one storage area.

8. The device according to claim 7 wherein the storage area is configured for reading and writing cell bytes .

9. The device according to claim 2 wherein the input further comprises a packet start detector connected to the input for determining when a new data cell packet is received by the input .

10. The device according to claim 2 further comprising a processor and an associated memory means, said processor being connected to said selectors for generating a plurality of conversion instructions to said selectors from instructions provided by said memory means .

11. A packet formatter for reformatting data packets comprising a stream of data cells using a stream of control data cells, the packet formatter comprising: an input for receiving the stream of data cells and the stream of control data cells; a plurality of selectors connected to the input for storing data bytes of the data cells in parallel; a processor operatively connected to the selectors for providing instructions to the selectors for selecting the data bytes of the data cells for reformatting using reformatting information from the stream of control data cells; and an output connected to the selectors for providing the reformatted data packets from the selectors .

12. The packet formatter according to claim 11 wherein the selector further comprises a plurality of dual port memories .

13. The packet formatter according to claim 12 wherein the selector inserts data bytes from at least one of the cell streams for reformatting.

14. The packet formatter according to claim 13 wherein the selector deletes data bytes from at least one of the cell streams for reformatting.

15. The packet formatter according to claim 14 wherein the selector replaces data bytes from at least one of the cell streams for reformatting.

16. The packet formatter according to claim 15 wherein the selector rearranges data bytes in at least one of the cell streams for reformatting.

17. A method for reformatting data packets in a data cell stream using an external control cell stream, the method comprising the steps of: determining the format of the data packets using reformatting information from the external control cell stream; storing in parallel bytes of the data packets and external control cell stream; selecting the stored data bytes for reformatting the data packets using the reformatting information,- and reassembling the selected data bytes into the reformatted data packets.

18. The method according to claim 17 wherein the step of selecting data bytes further comprises inserting data bytes for reformatting the data packets .

19. The method according to claim 17 wherein the step of selecting data bytes further comprises deleting data bytes for reformatting the data packets .

20. The method according to claim 17 wherein the step of selecting data bytes further comprises replacing data bytes for reformatting the data packets.

21. The method according to claim 17 wherein the step of selecting data bytes further comprises rearranging cells for reformatting the data packets.

22. A data packet processor comprising a packet identifier for supplying a pair of data streams, one of said data streams being a stream of data cells and the other of said data streams being a stream of control cells, and a packet formatter connected to said packet identifier for receiving said pair of data streams in parallel, said packet formatter having at least one selector for reformatting said data cells into one of a plurality of predetermined data protocols.

23. The data packet processor of claim 22 further comprising a microcode flow control coupled to said selector and to said data streams, said microcode flow control processing appropriate conversion microcode for supplying the appropriate read and write signals to instruct the selector for processing a particular data cell.

24. The data packet processor of claim 23 further comprising an extractor for extracting data cell formatting information from each control stream cell as it arrives from the packet identifier and a memory means connected between the extractor and the microcode flow control, the memory means containing the conversion microcode for access by said microcode flow controller.

25. The data packet processor of claim 24 wherein said selector comprises a plurality of selectors connected in parallel for parallel processing of the data stream cells and the control stream cells.

26. The data packet processor of claim 25 further comprising a forward control for receiving the reformatted cells.

27. The data packet processor of claim 26 wherein said memory means includes machine code comprising said conversion microcode, and wherein said microcode flow control includes a processor for processing said machine code.

28. A data packet processor for reformatting a parallel stream of cells, one of said streams comprising a stream of data cells and the other stream comprising a stream of control cells, said data packet processor comprising a plurality of selectors for parallel processing both of said streams to thereby reformat said streams .

29. The data packet processor of claim 28 further comprising a cell processor connected to said selectors for providing a plurality of reformatting instructions to said selectors .

30. The data packet processor of claim 29 further comprising an input and memory means connected to the cell processor for extracting the incoming cell format and supplying the cell processor with machine code for generating the reformatting instructions .

31. The data packet processor of claim 30 wherein each of said selectors receives each of said control and data cells, and wherein said cell processor supplies each of said selectors with a reformatting instruction identifying which portion of said data or control cell is to be forwarded into a reformatted cell.

32. The data packet processor of claim 31 further comprising a packet identifier connected to the input, said packet identifier providing said parallel streams of cells to said input .

33. The data packet processor of claim 31 further comprising a plurality of pairs of dual port memories, each pair of said memories being connected to an input to one of said selectors and holding said data and control cells for processing by said selectors, and further comprising a write control connected to the data packet processor input to receive both of the data stream and the control stream, each of said write controls being connected to one of said memories.

34. A data packet processor for reformatting a plurality of parallel streams of cells, said data packet processor comprising a plurality of selectors for parallel processing said streams to thereby reformat said streams into at least one reformatted stream.

35. The data packet processor of claim 34 further comprising a memory means connected to said plurality of selectors, the memory means containing conversion information for reformatting the plurality of parallel streams of cells into the at least one reformatted stream having a predetermined data protocol .