US20010033580A1 - Multi-protocol packet translator - Google Patents
Multi-protocol packet translator Download PDFInfo
- Publication number
- US20010033580A1 US20010033580A1 US09/730,453 US73045300A US2001033580A1 US 20010033580 A1 US20010033580 A1 US 20010033580A1 US 73045300 A US73045300 A US 73045300A US 2001033580 A1 US2001033580 A1 US 2001033580A1
- Authority
- US
- United States
- Prior art keywords
- memory
- packet
- pipeline
- output memory
- output
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
Definitions
- This invention relates to communication networks, and more particularly, to apparatus and methods for translating information packets from one network protocol to another network protocol.
- LAN local area network
- WAN wide area network
- Networks may be formed using a variety of different interconnection elements, such as unshielded twisted pair cables, shielded twisted pair cables, coaxial cable, fiber optic cable, or even wireless interconnect elements.
- the configuration of these cabling elements can follow one (or more) of many topologies, such as star, ring or bus.
- a communication within a network is referred to as a “packet” (“packet” and “data packet” are intended to include traditional data packets and any functional equivalent, whether referred to in the art as “cells,” “datagrams,” or the like).
- Packet and data packet are intended to include traditional data packets and any functional equivalent, whether referred to in the art as “cells,” “datagrams,” or the like).
- a packet intended for use with one protocol cannot necessarily be used in a network that follows a different protocol. Accordingly, some form of translation is required when sending packets between networks that follow different communication protocols.
- FIG. 1 illustrates an example of a prior art connection between networks.
- the first network 10 forwards communications within the network 10 according to one communication protocol.
- the second network 11 forwards communication packets around the network 11 using a different communication protocol. Accordingly, if a packet needs to be sent from the first network 10 to the second network 11 , a translation needs to be made.
- a translation unit 12 is included for translating packets from the communication protocol of the first network 10 to the communication protocol of the second network 11 , and vice versa.
- the prior art follows one of two approaches.
- a general purpose computer processor is used to do the translations.
- the processor generally stores the packet in memory, manipulates the packet within that memory to conform to the new protocol and then outputs the translated packet.
- the second approach is to design a custom hardware machine to perform the translation.
- a state machine is hard coded to perform each translation from one format to the other.
- a fast hard coded translator must be designed and implemented for each translation. While common parts of similar translations may be combined to decrease circuitry, this adds significantly to the complexity of hardware verification.
- the hard coded state machine is usually implemented on an application specific integrated circuit (ASIC) or using a programmable logic device (PLD, such as field programmable gate arrays or complex programmable logic devices).
- a translator unit for translating a packet from one communication protocol to a second communication protocol.
- the translator unit comprises an input memory, an information source, an output memory, and a connection circuit that selectively connects the input memory and the information source to the output memory, to selectively write information into the output memory according to the second communication protocol's format.
- the translator unit also includes a microcoded control unit coupled to the connection circuit.
- the microcoded control unit may include a pipeline unit coupled to the connection circuit.
- a pipeline control unit for reading data includes a first memory having a first read latency, a second memory having a second read latency, longer than the first read latency, a pipeline unit having a first stage and a second stage, and a circuit that initiates read cycles from the first memory based on a first instruction in the second stage of the pipeline and which initiates read cycles from the second memory based on a second instruction in the first stage of the pipeline.
- a method of translating a packet is disclosed.
- a first memory is loaded with a set of microcode instructions, each set being designed to perform a different network communication protocol translation.
- the method also includes the steps of receiving an original packet to be translated, selecting one of the sets of the microcode instructions based on the first protocol and the second protocol, and translating the original packet by executing the selected set of microcode instructions.
- a method of translating an original packet into a translated packet is disclosed.
- an instruction memory is loaded with a set of instructions.
- the original packet is placed into an input memory.
- An information source is provided and an output memory to store the translated packets is provided.
- the input memory and the information source are sequentially and selectively connected to the output memory, based on the instructions.
- FIG. 1 illustrates a prior art setting for translation of packets between two communication networks
- FIG. 2 illustrates one embodiment of a translator unit according to the present invention
- FIG. 3 illustrates translation from an original packet to a translated packet according to one embodiment of the present invention
- FIG. 4A illustrates one use of a translation unit according to the present invention
- FIG. 4B illustrates a second embodiment using a translator according to the present invention
- FIG. 4C illustrates a third embodiment using a translator unit according to the present invention to translate packets sent among three networks
- FIG. 5 illustrates the circuit for a multi-protocol translator according to one embodiment of the present invention
- FIG. 6 illustrates one embodiment of a pipeline unit for use in the multi-protocol translator of FIG. 5;
- FIG. 7A illustrates a packet formatted according to the L 2 VLAN tagged Ethernet dixie communication protocol
- FIG. 7B illustrates the packet of FIG. 7A, translated to the ATM Forum LANE 2.0 communication protocol
- FIG. 8 illustrates a method of translating a communication packet according to one embodiment of the present invention
- FIG. 9 illustrates another embodiment of a multi-protocol translator according to the present invention, including a double pipeline unit
- FIG. 10 illustrates another embodiment of a multi-protocol translator according to the present invention, including a quad pipeline
- FIG. 11A illustrates one step of translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 11B illustrates the partial results of the translation, after the step shown in FIG. 11A;
- FIG. 12A illustrates a subsequent step in translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 12B illustrates the partial results of the translation, after the step illustrated in FIG. 12A is performed
- FIG. 13A illustrates a next step in translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 14A illustrates a next step in translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 14B illustrates the partial results after the step illustrated in FIG. 14A
- FIG. 15A illustrates a next step in translating a packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 15B illustrates the partial results in translating the packet after the step illustrated in FIG. 15A.
- One or more embodiments of the present invention achieve a variety of advantages over these prior art systems.
- Certain embodiments of the present invention can achieve one or more of the following goals: the embodiment is fast, being equivalent or close to speed to a custom hardware based translation; real time processor intervention that would slow down translation is unnecessary; the translator can be adapted to perform new translations without extensive new development; the design is flexible and can be configured for multiple protocol translations; the translator is field upgradable (i.e., mistakes or new translations can be addressed with a field upgrade); the implementation is compact; and the translator is scalable—capable of performing trade-offs between speed and complexity.
- FIG. 2 illustrates a simplex translator 28 according to one embodiment of the present invention.
- a simplex translator packets are translated in only one direction.
- a packet would be received from a first network on the network interface 20 a , translated by the translator 28 , and output to a second network by network interface 20 b .
- the network interfaces 20 a , 20 b may be of the same form commonly used in the art to receive and send data packets to/from a network.
- the network interface may be part of known packet switches, routers, bridges or just a physical port with associated hardware.
- Data packets according to most protocols are in the general format illustrated at 22 a - 22 c .
- the packet typically includes a packet header 22 a .
- the packet header may include a number of fields. One field typically identifies (in some manner) the path over which the packet should traverse. For example, the header could contain a unique path identifier that specifies the entire path through a network.
- the header 22 a may include a destination address, that identifies the intended destination for the packet.
- Many communication protocols include both a destination address and a source address for the packet, as a part of header 22 a .
- the packet may also include a trailer 22 c .
- Both the header and the trailer typically include network, routing, format, error correction and detection, and other types of information, but not the actual data communicated.
- the data to be communicated or “payload” is a continuous block located between the header and trailer (or simply after the header, where there is no trailer), as illustrated at 22 b.
- the input memory 21 a can be any digital memory for storing received packets, including banks of registers, random access memory and other devices.
- the input memory 21 a may be a buffer memory, capable of storing multiple packets which arrive from network interface 20 a but have not yet been translated.
- the controller 24 determines what translation is required. This is done by determining what the current communication protocol format is for the packet and the communication protocol required to forward the packet. Where network interface 20 a is connected to only one type of network and network interface 20 b is connected to only one (different) type of network, this function is simple to implement; the translation is always from one specific protocol to another specific protocol. Where multiple protocols may be placed into input memory 21 a , and multiple protocols may be required for output, the controller may perform a table lookup or other procedure to determine what protocols are required. For example, the destination address and source address for a packet can be used to determine the source and destination protocols for the packet.
- the header 22 a will include information identifying the network protocol, and the destination will determine what the output communication protocol should be. In the event that a table lookup is performed, this may be done using an associated random access memory 25 . Techniques for identifying what particular translation is required are currently known. Where more than one protocol translation is required, the multi-protocol translator (MPT) performs the appropriate translation based on the information provided by the controller 24 . These functions of the controller are described in greater detail below.
- the controller 24 can be implemented in one of many ways. The controller will most likely be implemented using ASICs or programmable logic devices, for speed. A general processor could also be used to perform this function, as the amount of processing required to initiate packets is relatively small and delay incurred from use of a general purpose processor is minimal.
- the translation process is performed by two separate elements—the multi-protocol translator (MPT) 26 and the direct memory access (DMA) controller 27 .
- the MPT 26 translates the header and trailer information from the first protocol (e.g., packet 22 a - 22 c ) into the header and trailer information for the new packet ( 23 a - 23 c ).
- the translated packet is stored in output memory 21 b , and when complete is forwarded to the network interface 20 b for transmission across the second network.
- the MPT 26 could also forward the data portion 22 b of the incoming packet into the output memory 21 b . (This may be particularly useful where a trailer or other field needs to be formulated based on the contents of the entire packet, such as a check-sum field or other error detection or correction fields. By passing the data through the MPT, the applicable field can be accumulated as the output memory is written.) Because no change is required to the payload for most translations, however, in many cases this may be done using only a direct memory access (“DMA”) controller 27 . Thus, the DMA controller 27 can be forwarding data (payload) into the output memory while the MPT 26 is setting up the appropriate header and trailer information for the translated packet.
- DMA direct memory access
- FIG. 3 illustrates the translation process from one packet ( 31 - 33 ) to a packet using a different communication protocol ( 34 - 37 ).
- the first packet includes a header 31 , the remainder of the packet being data 33 .
- the MPT translates the header of the first packet 31 into the new translated header 34 .
- the MPT may also forward some of the payload 32 into the new translated packet, as shown at 35 .
- the DMA controller 27 would then handle the transfer of the remainder of the payload 38 .
- the DMA controller 27 may include also a mechanism to alter byte alignment when multiple bytes are read from an input memory and/or multiple bytes written to an output memory, as explained with reference to the storage alignment units of FIGS. 9 and 10.)
- the MPT might be configured to forward some of the data 32 to the new packet 35 , to accommodate the possibility of variable length headers.
- the length of the header varies.
- One approach to resolving this is to have the system controller look up the header length and have the MPT process only the header, while the DMA transfers only data.
- Another solution, as illustrated in FIG. 3, is to take the maximum header size (here, equivalent to fields 31 and 32 of FIG. 3, which, in this example, includes some data because, in FIG. 3, the actual header is smaller than the assumed maximum header size) and always run that portion of an incoming packet through the MPT. In this case, while some data is unnecessarily transferred through the MPT, there is no need to perform an additional table lookup to determine where the header/data boundary is for the applicable incoming packet.
- FIG. 2 provides for unidirectional translation. That is, packets are only received (and not transmitted) on network interface 20 a , translated by the translator 28 , and transmitted (and no packets received) from network interface 20 b .
- the translator 28 of FIG. 2 to the network of FIG. 1, two translator units 28 would be required. The first translator unit would handle packets traveling from the first network 10 to the second network 11 . The second translator would handle packets traveling in the opposite direction (as in FIG. 4A).
- FIG. 2 can be modified to handle bidirectional traffic. This can be achieved in at least two different ways. First, additional connections could be provided to permit translation both from memory 21 a to memory 21 b and vice versa. Thus, the DMA controller 27 would be capable of transferring data from the input memory 21 a to the output memory 21 b as before, and would also be able to directly transfer data from the memory 21 b to the memory 21 a when packets are being sent from network interface 20 b to network interface 20 a . Similarly, the MPT 26 would be capable of receiving information for translation from both memories 21 a and 21 b , and writing the translated header (or trailer) information to the other opposite memory.
- input memory 21 a only as an input buffer and output memory 21 b only as an output buffer, but to permit both network interface 20 a and 20 b to provide incoming packets to the input memory 21 a and allow output memory 21 b to provide outgoing packets to both network interface 20 a and 20 b .
- the embodiment of FIG. 2 could remain the same, but adding switches, multiplexers or the equivalent to permit multiple inputs and outputs for the input and output memories 21 a and 21 b.
- FIG. 4A illustrates use of two unidirectional processors for translation between two networks.
- packets sent from a first network 41 to a second network 42 are translated by a translator 44 .
- Packets sent from the second network 42 to the first network 41 are sent through a separate translator 45 . This permits parallel processing, at the expense of added hardware.
- FIG. 4B illustrates use of a single translator unit 46 , as described above, to send packets both from the first network 41 to the second network 42 and vice versa.
- the translator must perform two transactions—NW1 to NW2 and NW2 to NW1.
- FIG. 4C illustrates use of a single translator 47 with additional networks.
- the first network 41 , second network 42 and third network 43 each have a different communication protocol.
- the multi-protocol translator 47 can receive packets from all three networks, translate them to the appropriate protocol for the destination network, and forward the packet accordingly.
- similar designs using any number of networks could be implemented.
- the multi-protocol translator 26 should preferably be fast, flexible, programmable to handle multiple (and new) translations and upgradable without having to redesign the entire system.
- FIG. 5 illustrates one embodiment of a multi-protocol translator according to the present invention.
- the multi-protocol translator shown in the embodiment of FIG. 5 works as follows.
- the original frame (or frame to be translated) is held in memory 53 a .
- Substitute information to be inserted into the translated frame is held (or produced) in other mechanisms.
- these information sources are the two FIFO memories 54 and 55 .
- To produce a translated frame data is selectively passed from the input memory 53 a , information sources 54 and 55 , and from instruction operands, into the output memory 58 .
- the outgoing frame is then stored in the output memory 58 .
- the appropriate data is passed through a multiplexer 56 into the output memory.
- a microcoded, pipelined control unit 59 controls the reading of the memories 53 a , 54 and 55 and the passing of data to the output memory 58 through the multiplexer 56 .
- the translator has an input memory 53 a , in which the original frame (the frame to be translated) is stored.
- This input memory 53 a may receive the frame directly from a network interface as described above, or may be an additional buffer internal to the multi-protocol translator.
- an address control unit 53 b controls what memory location is read from the input memory for use in the translation.
- the address control unit 53 b may further control the input memory for writing the original frame into the memory, as could be readily designed by one of skill in the art based on the disclosure provided herein.
- the MPT also includes two first-in-first-out (“FIFO”) memories 54 and 55 . These memories contain new header information that may be required in one of the translations that the MPT can perform. Thus, the two FIFOs 54 , 55 provide alternative information that can be used to replace or supplement the header (or trailer) information in the original frame, during translation. Of course, other mechanisms and other forms of memory could be used in place of FIFOs 54 and 55 . More complicated information sources might include mechanisms to generate new fields based on previous fields, such as a check-sum or other error detection or correction field. The number of information sources may also vary, depending on what translation(s) the MPT can perform.
- a dump memory 57 may be included.
- the dump memory would serve to save information from the original frame (or the entire original frame) for system administration, diagnostic purposes, or for some other form of processing.
- a multiplexer 56 selectively provides the appropriate data from the input memory 53 a , FIFO 54 and 55 or from the controller, to the output memory 58 .
- mechanisms other than multiplexers could be used to perform the same function.
- the output memory 58 can be any suitable memory (including registers, random access memory, etc.) to hold the translated frame (or the portion of the frame being translated by the MPT) during processing.
- suitable memory including registers, random access memory, etc.
- multiple input or output buffers may be used, particularly where the buffer may be providing data to more than one network interface.
- the input and output memories may be formed within the same single larger memory unit or made up of multiple smaller memory units.
- the translator control unit is configured to issue read instructions in a pipelined fashion.
- the translator control unit 59 is also microcoded.
- the translator control unit includes an opcode memory 51 a that stores the various instructions required for all of the translations that the MPT is capable of performing. The stepping through of the instructions performed in the opcode memory is controlled by the address control unit 51 b . Instructions are fed from the opcode memory 51 a to a pipeline unit 52 .
- the pipeline is implemented as a three stage, two-register pipeline. One register pipeline of the two-register pipeline is used for opcodes. The other pipeline is used for operands (which are also stored in the opcode memory 51 a ).
- the controller 24 of FIG. 2 selects the appropriate microcoded instructions stored in the opcode memory 51 a for use in the applicable translation (i.e., depending on the original and the new protocol for the translation).
- the controller 24 sets the address control 51 b to the appropriate start place for the translation process.
- the controller 50 takes the opcode information from the pipeline 52 (received from the opcode memory 51 a ) and appropriately sends control signals to the information source components for the translated header, e.g., the input memory 53 a and the FIFOs 54 and 55 .
- the controller controls the multiplexer, which selects the data being fed to the output memory 58 for any given write cycle of the output memory 58 .
- the controller 50 also controls what original frame information is recorded in the dump memory 57 and controls writing output memory 58 by controlling the multiplexer 56 and the output memory 58 (including its associated address control).
- the controller 50 can be implemented using discrete components or as part of an ASIC or using programmable logic arrays.
- the controller 50 may also be implemented using a general purpose central processing unit, although this level of complexity may not be necessary for many implementations.
- the lag time necessary to retrieve information from the various sources that make up the translated header can vary.
- the time required to read from the input memory 53 a may be longer than the time required to read from one of the FIFOs 54 and 55 .
- Information coming directly from the translator control unit 59 could be written immediately.
- the example circuit of FIG. 5 has-three different read latencies: input memory (two clocks), FIFO (one clock), and data written from the controller (immediate).
- the pipeline 52 has three stages. For an opcode indicating data is to be transferred from the input memory to the output memory is encountered, the controller issues the appropriate read command to the input memory 53 a when the opcode is in the first register of the pipeline in the pipeline unit 52 . In subsequent stages of the pipeline, that opcode can be ignored, until the last stage, where the controller 50 configures multiplexer 56 to transfer the then-ready data from the input memory 53 a to the output memory 58 .
- FIG. 6 illustrates a simple circuit design for the pipeline unit 52 of FIG. 5.
- the pipeline is implemented using 8 bit register banks (or latches) 60 .
- the operand is fed through a first set of registers 62 while the opcode is fed through a second set of registers 61 . All of the registers 60 are clocked off of a common system clock CLK.
- Each of the stages of opcodes provides information to the controller 50 .
- the operand from the operand pipe 62 is directed to the output memory 58 , through the multiplexer 56 .
- the opcode memory may also effectively be used as an additional stage of the pipeline. For example, instructions to change the address of the input memory can be taken by the controller 50 and used to immediately begin the address change.
- a set of instructions that may be used to program a translation using the multi-protocol translator of FIG. 5 is illustrated in the following Table 1: TABLE 1 Single Pipe MPT Instructions Name Operand Description READ_ORIG no Move Byte from input memory to output memory READ_ORIG_DUMP no Move Byte from input memory to dump memory READ_FIFO1 no Move Byte from FIFO1 to output memory READ_FIFO2 no Move Byte from FIFO2 to output memory WRITE_IM yes Move operand to output memory JUMP_ORIG_DUMP yes Jump to new ORIG address (per operand value) and write to output memory JUMP_OPCODE yes Go to a “subroutine” address in a opcode memory space RETURN_OPCODE yes Return to opcode address + 1 which was stored when jump occurred RETURN_ORIG no Return to input memory address + 1 which was stored when jump occurred END no Tells controller that translation is finished
- FIG. 5 The operation of the multi-protocol translator illustrated in FIG. 5 can be understood in reference to the following example.
- the example shows conversion from L2 VLAN tagged Ethernet dixie (e.g., FIG. 7A) to ATM Forum LANE 2.0 communication protocol (as shown in FIG. 7B).
- FIG. 7A illustrates the format of a packet according to the L2 VLAN tagged Ethernet dixie communication protocol.
- a virtual destination address (VDA) and virtual source address (VSA) are the first two fields 71 of the packet 69 .
- a tag type 72 is included.
- a destination address (DA), source address (SA) and ether type fields 73 are included.
- the L2 VLAN tagged Ethernet dixie protocol is known to those of skill in the art.
- a packet of the L2 VLAN tagged Ethernet dixie protocol format illustrated in FIG. 7A is converted to the format of ATM Forum LANE 2.0, as illustrated in FIG. 7B.
- the first field 75 is a fixed communication protocol identifier and is the same for every packet formatted according to this protocol.
- An ether-type 76 is included (different from the ether type shown in FIG. 7A).
- An ElanID and LecID fields 77 are included. These fields are determined according to the protocol, and, in this example, loaded into the FIFO for the translation. Destination and source addresses and ether type fields 78 are included, which are identical in content to the corresponding fields 73 of FIG. 7A.
- a packet according to the ATM Forum LANE 2.0 protocol includes a payload 79 at the end. The payload 79 in the translated packet is identical to the payload 74 of the original packet.
- FIG. 8 illustrates a method of using a multi-protocol translator of FIG. 5 to translate the packet of FIG. 7A (L2 VLAN tagged Ethernet dixie) into the packet of FIG. 7B (ATM Forum LANE 2.0).
- the applicable operation codes in this case, including operands
- Block 89 illustrates the normal processing of a packet using one embodiment of a multi-protocol translator according to the present invention.
- the translator waits to receive a packet. Once a packet is received, processing begins at a step 83 .
- the packet is loaded into the input memory 53 a of the translator.
- the controller 24 (of FIG. 2) identifies what translation is required. This is done by examining the protocol of the incoming packet and determining (based on the destination of the packet) the protocol to which the packet should be translated.
- FIFO1 55 of FIG. 5 is also loaded with the ATM Forum LANE 2.0 ether type, ElanID and LecID fields (determined by the controller for the applicable packet using methods known in the art for this communication protocol).
- the payload of the packet ( 74 of FIG. 7A) is directly transferred into the output memory 58 of FIG. 5 (the DMA path is not shown in FIG. 5).
- the multi-protocol translator unit translates the header information of the original packet into the appropriate header for the translated packet.
- the header translation is performed as illustrated at steps 86 a - 86 d.
- step 86 a the initial fields of the original packet are dumped (fields 71 , 72 of FIG. 7A). This may be accomplished either by stepping through these fields of the packet header and writing the information only to the dump memory 57 of FIG. 5. In the alternative, where the 3 information need not be saved, the controller can simply cause the address control 53 b of the input memory 53 a to jump over these fields.
- the LLC-OUI header is written to the output memory.
- the LLC-OUI field is written directly from the opcode memory. That is, a series of microcode instructions write the operand directly from the pipeline unit 52 to the output memory 58 of FIG. 5 (through multiplexer 56 ).
- the entire field is contained as operands in the opcode memory and transferred by directly writing the operands to the output memory.
- the Ether type, ElanID and LecID fields ( 76 , 77 of FIG. 7B) are written from FIFO1 55 of FIG. 5 to the output memory 58 .
- the lag time of the FIFO1 55 read before the output memory can be written is two clock cycles. Accordingly, when an instruction from the opcode memory 51 a is passed to the pipeline 52 , calling for writing data from FIFO1 55 to the output memory 58 , nothing happens at the first stage. At the second stage, however, the read command is issued to FIFO1 55 .
- the opcode When the opcode reaches the last stage of the pipeline unit 52 , the data is ready to be read from FIFO1 to the output memory. Accordingly, when that instruction is in the last stage of the pipeline, the instruction causes the controller 50 to configure the multiplexer 56 to pass data from FIFO1 55 to the output memory 58 and sets up output memory 58 for the appropriate write. In the meantime, a new read is issued from the second stage of the pipeline unit 52 , to setup the next data to be written from FIFO1 55 to output memory 58 .
- the DA, SA and Ether type fields of the original packet are transferred directly to the output memory 58 (corresponding to field 78 of FIG. 7B).
- the input memory 53 a is assumed to have a latency period (in clock cycles) longer than the FIFO (two clock cycles rather than one). Accordingly, when the opcode is placed in the pipeline unit 52 , a read command is issued at the first stage of the pipeline 52 .
- the opcode corresponding to transfer of data from input memory 53 a to output memory 58 reaches the last stage of the pipeline 52 , the data is ready to be passed from the input memory 53 a to the output memory 58 (the clock cycles corresponding to the latency of input memory having passed, while the opcode is passing through the pipeline 52 ). Accordingly, when the command reaches the last stage of pipeline 52 , it causes the controller 50 to configure the multiplexer 56 to pass data from the input memory 53 a to the output memory 58 (as well as enabling writing of the output memory 58 ).
- steps 85 and 88 are complete, the complete translated packet is in the output memory 58 of FIG. 5. Accordingly, at a step 87 , the packet can be transferred from the output memory to the network interface for propagation to its applicable destination address. When this is done, processing may continue at step 82 .
- the multiplexer 56 of FIG. 5 should be configured so that the data path into the output memory 58 is open before the setup time of the output memory logic, but after the hold time of the multiplexer logic. If the sum of the setup and hold time of the multiplexer plus the hold time of the input path plus the setup of the output logic exceeds one clock cycle, the multiplexer configuration may be performed at an earlier stage (e.g., the second stage) of the pipeline 52 . This would make the multiplexer control logic based on the previous stage rather than decoded from the current last stage.
- a one byte channel is used to move information from the applicable source (pipeline operand, FIFO memory or input memory) to the output memory.
- the throughput of the translator can be increased by providing for a wider data channel.
- FIG. 9 illustrates a multi-protocol translator unit that includes a sixteen bit (two byte) data channel, according to the present invention.
- the incoming, original packets are stored in input memory 90 b , which is controlled by an address control 90 a , as in FIG. 5.
- the input memory can read two bytes of information from the data packet.
- the translator includes an information memory 91 b , controlled by an address control 91 a .
- Memory 91 b stores information to be written into the translated header, and functions similar to the FIFO memory illustrated in FIG. 5. A difference, however, is that two bytes of information can be read from the information memory 91 b.
- the output memory 97 can receive two bytes of information.
- a and B can be simultaneously written to the output memory.
- a byte of data from the input memory can be provided to the A channel or the B channel of the output memory 97 .
- Multiplexer 92 a selects the applicable byte from the input memory 90 b or the information memory 91 b for provision along the A channel to be written in the output memory 97 .
- multiplexer 92 b selects a byte from the information memory or input memory to be provided to the B channel of the output memory 97 , through multiplexer 95 b .
- Multiplexers 95 a and 95 b select the data lines for connection to the applicable channel of the output memory 97 , permitting data to be written from the translator control unit 98 c , the input memory or information memory data selected by the applicable multiplexer 92 a or 92 b , or the data stored in storage alignment units 93 a and 93 b.
- the storage alignment unit 93 a serves to hold data to be written to the output memory 97 in later clock cycles. Thus, if information needs to be delayed before being written to the output memory, that information can be held for one or more clock cycles in the storage alignment unit 93 a . This permits data to be held and realigned when written to the output memory 97 . For example, if a byte becomes available in the data passed from multiplexer 92 a before the corresponding data to be written in channel B of the output memory 97 is available, the A channel information can be held and delayed in storage alignment unit 93 a . When the corresponding byte for channel B of the output memory 97 is available, the delayed information held in storage alignment unit 93 a can be written to the A channel of the output memory 97 , through multiplexer 95 a.
- the storage alignment unit 93 a includes a multiplexer 96 a and a register 96 b .
- the register is written on every clock cycle. Accordingly, if the data needs to be delayed for more than one clock cycle, the data held in 96 b needs to be refreshed (or maintained) through multiplexer 96 a .
- An example of a translation using the delay units 93 a and 93 b is provided below in connection with an embodiment that has four data channels that may be written to the output memory at one time.
- the control unit 98 c has a similar configuration to the control unit 59 of FIG. 5.
- An opcode memory 99 b stores the opcodes and operands for controlling the entire translator unit.
- An address control 99 a controls the opcodes being read from the opcode memory 99 b .
- the opcode memory 99 b includes two opcode/operand channels, each sixteen bits wide.
- the first opcode/operand pair is fed to a first pipeline 98 a ′, like the pipeline unit 52 of FIG. 5.
- the second opcode/operand pair is fed to a second pipeline 98 a ′′, also like the pipeline unit 52 of FIG. 5.
- the two sections 98 a ′, 98 a ′′ of the double pipeline unit 98 a permit separate control for components used in writing the A channel and B channel of output memory 97 .
- the double pipeline unit 98 a includes two three-stage pipelines. In this particular embodiment, three stages were selected to correspond to different latencies from the various components that provide data to the output memory 97 .
- the input memory 90 b might have one read latency, the information memory 91 b a different (e.g., shorter) read latency, and the information being written directly from an operand held in the last stage of either side of the double pipeline unit 98 a having no latency.
- a set of instructions that may be used for the translator unit of FIG. 9 are listed in the following table: TABLE 2 Name Operand Description R_ORIG_U_A no read upper Byte lane of input memory and advance address controller R_ORIG_L _A no read lower Byte lane of input memory and advance address controller R_0MG_U_NA no read upper Byte lane of input memory and do not advance address controller R_ORIG_U_NA no read lower Byte lane of input memory and do not advance address controller PRELOAD_ORIG_U yes preload input memory address controller with address in operand and read from upper Byte lane PRELOAD_ORIG_L yes preload input memory address controller with address in operand and read from lower Byte lane R_INFO_U_A no read upper Byte lane of INFO memory and advance address controller R_INFO_L_A no read lower Byte lane of INFO memory and advance address controller R_INFO_U_NA no read upper Byte lane of INFO memory and
- Each of the opcode/operand pairs listed in Table 2 can be fed to either side of the double pipeline unit 98 a . That is, an entire opcode/operand output from the opcode memory 99 b would include two instructions of the form listed in Table 2—one for each side. In selecting binary opcodes for these instructions, additional bits are dedicated to signal an individual function. One bit signals writing of the output memory 58 . The other bit controlling reads and writes from an alignment storage unit 93 a or 93 b . Thus, each of the above instructions has four forms (encoded with the two extra bits)—any combination of commands for writing the output memory (0 or 1) and writing the applicable storage alignment unit (0 or 1).
- FIG. 10 illustrates an embodiment of a translator unit where four channels A, B, C and D can be written simultaneously to an output memory 105 .
- this embodiment has an input memory 100 b for storing the original frame to be translated.
- the input memory 100 b is controlled by an address control unit 100 a .
- information to be inserted into the translated header of the translated packet is stored in an information memory 101 b , which is controlled by an address control unit 101 a .
- four bytes of data can be read from each of the input memory 100 b and information memory 101 b in one clock cycle.
- a set of four multiplexers 102 permit any of the output bytes of the input memory 100 b and information memory 101 b to be fed along a data channel that feeds any of the four input channels A, B, C and D of the output memory 105 .
- a series of four alignment storage units 103 permit a byte being fed along one of the data channels to the output memory to be stored, for alignment with subsequently read data on the other data channels.
- These alignment storage units are of the same configuration as described above with respect to the alignment storage units 93 a and 93 b of FIG. 9.
- a set of four multiplexers 104 provide the final selection as to what data is actually written to the applicable data channel A, B, C, D of the output memory 105 for a particular clock cycle.
- a control unit 109 controls the timing and application of data being written to the output memory 105 .
- this embodiment has an opcode memory 106 b , controlled by an address control unit 106 a .
- this opcode memory provides a set of four opcodes, each with an applicable operand. Thus, sixty-four bits are provided as an output of the opcode memory 106 b.
- the quad pipe includes four pipelines of the type illustrated and described above with reference to pipeline unit 52 of FIG. 5. Each opcode/operand pair can perform one or more functions with respect to the components in one of the channels providing data to the output memory 105 . Thus, because four different pipelines are functioning simultaneously, components in all four of the data channels can be controlled simultaneously and separately. Because there are three different memory latency cycles (one for the input memory, one for the information memory and the immediate write of an operand to the output memory through one of the multiplexers 104 ), this pipeline also has three stages.
- a controller 108 takes the information from each of the stages of the pipeline, and each of the four pipeline units, and uses that information to provide the appropriate control signals for the remainder of the translator unit.
- Table 3 sets forth a set of instructions that may be used to control the translator unit of FIG. 10. TABLE 3 Opcodes Name Operand Description R_ORIG_B3_A no read Byte lane 3 of input memory and advance address controller R_ORIG_B2_A no read Byte lane 2 of input memory and advance address controller R_ORIG_B1_A no read Byte lane 1 of input memory and advance address controller R_ORIG_B0_A no read Byte lane 0 of input memory and advance address controller R_ORIG_B3_NA no read Byte lane 3 of input memory and do not advance address controller R_ORIG_B2_NA no read Byte lane 2 of input memory and do not advance address controller R_ORIG_B1_NA no read Byte lane 1 of input memory and do not advance address controller R_ORIG_B0_NA no read Byte lane 0 of input memory and do not advance address controller PRELOAD_ORIG_B3 yes preload input memory address controller with
- each of these opcodes applies to each of the data channels A, B, C, D of the output memory.
- the opcodes of Table 3 apply to just one of the channels, and each read from the opcode memory would produce four of such opcodes.
- two extra bits for each opcode encode whether one or both of the output memory or applicable storage alignment unit is written.
- Operation of the circuit of FIG. 10 can be understood through the following example.
- This example converts the L2 VLAN tagged Ethernet dixie packet illustrated and discussed with reference to FIG. 7A into the ATM Forum LANE 2.0 protocol, as illustrated and discussed with reference to FIG. 7B.
- FIG. 11 A illustrates the first write to output memory when using the translator unit of FIG. 10 to translate the packet of FIG. 7A into the packet of FIG. 7B.
- the pipeline 107 has already received three sets of instructions (over three clock cycles).
- an instruction in each of the four parallel pipelines causes data to be written immediately to the output memory 105 .
- the four operands of the applicable instructions are written to the output memory during the next clock cycle.
- FIGS. 11 A- 15 A the most significant byte is presumed to be at the bottom of the output memory 105 .
- the opcode/operand pairs causes the sequence AA-AA-03-00 (4 bytes of data) to be written simultaneously to the output memory 105 .
- the opcode “write_im” causes the control unit (not shown) to configure the multiplexers 104 to connect the applicable operands to the input of the output memory 105 , as shown.
- the read information commands at 111 a and 111 b cause a read cycle to begin at the information memory 101 b , when the read information operation code is in the second to last stage 111 of pipeline unit 107 —so that the data is ready to be written to the output memory 105 when the data reaches the last stage of the pipeline.
- FIG. 11B illustrates the state of the output memory after the operation performed in FIG. 11A. As illustrated, four bytes of the header 118 have been written. The remainder of the translated packet 119 has not yet been written to the output memory.
- FIG. 12A illustrates the next step in translating the packet.
- the last stage 112 of the pipeline unit 107 has two write immediate commands 120 a and 120 b . These two commands write the last two bytes of the fixed header of the translated packet (shown in FIG. 7B).
- the instructions to read information from the information memory 120 c and 120 d have also reached the last stage of the pipeline. Because the read was initiated during the preceding clock cycle (shown in FIG. 11A), the information is now ready to be transferred from the information memory 101 b to the output memory 105 . Accordingly, the control unit (not shown) configures the appropriate multiplexers 104 to pass the information directly into the output memory 105 .
- the two bytes of the Ether-type are stored in bytes “0” and “1” of the four byte word stored in the information memory 101 b .
- the illustrated connection transfers the Ether-type bytes to the output memory 105 .
- FIG. 12B illustrates the packet as stored in the output memory 105 after the step illustrated in FIG. 12A takes place. As shown, the leading header and Ether-type have now been written to the output memory 105 , as shown at 125 . The remainder of the translated packet 126 has not yet been written to the output memory 105 .
- FIG. 13A illustrates the next step in the translation.
- the two most significant bytes for the ElanID field are stored in a four byte word in the information memory 101 b , as shown. These two bytes cannot be written directly to the output memory, however, because the output memory requires a four byte word to be written. Accordingly, the two bytes of the ElanID need to be stored in the storage alignment units 103 , for later writing to the output memory 105 . This is done as illustrated in FIG. 13A. During this clock cycle, no information is written to the output memory. Accordingly, the output memory continues to hold the same partially translated packet of FIG. 12B.
- the other two pipelines hold two instructions that require reading of information from the input memory 100 b 13 jump orig B0 at 131 a (which causes the input memory 100 b to jump to an operand address—to cause the address controller (not shown) of the input memory 100 b to skip over the portions of the original packet header that are not used in the translated packet, i.e., fields 71 , 72 of FIG. 7A).
- the address controller (not shown) of the input memory 100 b to skip over the portions of the original packet header that are not used in the translated packet, i.e., fields 71 , 72 of FIG. 7A).
- the read latency of the input memory 100 b is longer than the read latency of the information memory 101 b .
- the control unit causes the input memory's address control unit 100 a to apply the applicable address and initiates a read of the input memory 100 b.
- FIG. 14A illustrate the next clock cycle in this translation.
- the remainder of the ElanID field is present at bytes 0 and 1 of the information memory 101 b . Accordingly, these bytes may be written from the information memory 101 b to the output memory, as is accomplished with instructions 140 c and 140 d .
- These instructions cause the top two multiplexers of the multiplexers 104 to pass the data from bytes 0 and byte 1 of the information memory 101 b to the output memory 105 .
- instructions causing data to be written from the bottom two storage elements of the storage elements 103 to be simultaneously written to the output memory 105 i.e., the instructions 140 a and 140 b ) reach the last stage of the pipeline.
- the last two bytes of the ElanID can be appropriately aligned with the first two bytes for simultaneous writing to the output memory 105 .
- FIG. 14B illustrates the portion of the packets stored in the output memory 105 , after the step illustrated in FIG. 14A. As is shown, the beginning of the packet through the ElanID field is included 145 . The remainder of the packet 146 remains to be placed into the output memory. (Note, however, that if DMA control is used to transfer the payload to the output memory, a portion of the payload may also be in the output memory at this point and, perhaps, earlier.)
- FIG. 15A illustrates the next clock cycle. During this clock cycle, the first two bytes of the destination address are written to the output memory from the input memory, per the instructions at 150 c and 150 d . As discussed above, the read from this memory was initiated back when these instructions appeared in the first stage of the pipeline 110 . At the same time, two instructions 150 a and 150 b cause the two bytes of the LecID to be written to the output memory from the information memory.
- FIG. 15B illustrates the contents of the output memory 105 after the step illustrated in FIG. 15A. Most of the header has been written, including a portion of the destination address (transferred directly from the equivalent field of the original packet). The remainder of the packet 156 is yet to be written to the output memory.
- the instructions to transfer the remainder of the header of the original packet header to the translated packet in the output memory are shown (the DA, SA and Ether-type fields that remain to be written are all transferred directly from the equivalent fields held in the input memory 100 b ).
- the information is transferred using the storage alignment units, in the manner described above.
Abstract
A multi-protocol packet translator is disclosed. The translator may have microcoded control to translate a packet from one protocol to another. The microcoded instructions may be fed through a pipeline to control reading of information from information sources (including the original packet) and selectively connecting those sources to an output memory.
Description
- This invention relates to communication networks, and more particularly, to apparatus and methods for translating information packets from one network protocol to another network protocol.
- Computer communication networks have proliferated in order to enable the sharing of computer resources over a computer network. A network for permitting communication may be referred to as a local area network or “LAN.” LAN refers to an interconnection data network that is usually confined to a moderately sized geographical area, such as a single office building or a campus area. Larger networks are often referred to as wide area networks or “WANs.”
- Networks may be formed using a variety of different interconnection elements, such as unshielded twisted pair cables, shielded twisted pair cables, coaxial cable, fiber optic cable, or even wireless interconnect elements. The configuration of these cabling elements can follow one (or more) of many topologies, such as star, ring or bus.
- In addition, a number of different protocols for accessing the networking medium have evolved. Examples of various network protocols include FDDI, Ethernet (and multiple Ethernet communication protocols), ATM, token ring (and multiple token ring communication protocols) and ISDN. One particularly attractive communication network is described in U.S. Pat. No. 5,485,455, issued Jan. 16, 1996.
- The total number of installed communication networks has grown explosively. The number of communication protocols also continues to expand. Consequently, there are a great number of installed networks, many using different protocols. As the number of networks and network protocols has expanded, so has the desire to expand the scope of network coverage. The result is a desire to send packets from networks using one communication protocol to networks using other communication protocols.
- A communication within a network is referred to as a “packet” (“packet” and “data packet” are intended to include traditional data packets and any functional equivalent, whether referred to in the art as “cells,” “datagrams,” or the like). A packet intended for use with one protocol cannot necessarily be used in a network that follows a different protocol. Accordingly, some form of translation is required when sending packets between networks that follow different communication protocols.
- FIG. 1 illustrates an example of a prior art connection between networks. The
first network 10 forwards communications within thenetwork 10 according to one communication protocol. Thesecond network 11 forwards communication packets around thenetwork 11 using a different communication protocol. Accordingly, if a packet needs to be sent from thefirst network 10 to thesecond network 11, a translation needs to be made. According to the prior art, atranslation unit 12 is included for translating packets from the communication protocol of thefirst network 10 to the communication protocol of thesecond network 11, and vice versa. - For design of the
translator 12, the prior art follows one of two approaches. In the first approach, a general purpose computer processor is used to do the translations. The processor generally stores the packet in memory, manipulates the packet within that memory to conform to the new protocol and then outputs the translated packet. - The second approach is to design a custom hardware machine to perform the translation. For this solution, a state machine is hard coded to perform each translation from one format to the other. In the event that the
translator 12 must translate from multiple formats to multiple formats, a fast hard coded translator must be designed and implemented for each translation. While common parts of similar translations may be combined to decrease circuitry, this adds significantly to the complexity of hardware verification. The hard coded state machine is usually implemented on an application specific integrated circuit (ASIC) or using a programmable logic device (PLD, such as field programmable gate arrays or complex programmable logic devices). - According to one embodiment of the present invention a translator unit is disclosed for translating a packet from one communication protocol to a second communication protocol. In this embodiment, the translator unit comprises an input memory, an information source, an output memory, and a connection circuit that selectively connects the input memory and the information source to the output memory, to selectively write information into the output memory according to the second communication protocol's format. The translator unit also includes a microcoded control unit coupled to the connection circuit. In this embodiment, the microcoded control unit may include a pipeline unit coupled to the connection circuit.
- According to another embodiment of the present invention, a pipeline control unit for reading data is disclosed. The control unit includes a first memory having a first read latency, a second memory having a second read latency, longer than the first read latency, a pipeline unit having a first stage and a second stage, and a circuit that initiates read cycles from the first memory based on a first instruction in the second stage of the pipeline and which initiates read cycles from the second memory based on a second instruction in the first stage of the pipeline.
- According to another embodiment of the present invention, a method of translating a packet is disclosed. According to this embodiment, a first memory is loaded with a set of microcode instructions, each set being designed to perform a different network communication protocol translation. The method also includes the steps of receiving an original packet to be translated, selecting one of the sets of the microcode instructions based on the first protocol and the second protocol, and translating the original packet by executing the selected set of microcode instructions.
- According to another embodiment of the present invention, a method of translating an original packet into a translated packet is disclosed. According to this method, an instruction memory is loaded with a set of instructions. The original packet is placed into an input memory. An information source is provided and an output memory to store the translated packets is provided. The input memory and the information source are sequentially and selectively connected to the output memory, based on the instructions.
- FIG. 1 illustrates a prior art setting for translation of packets between two communication networks;
- FIG. 2 illustrates one embodiment of a translator unit according to the present invention;
- FIG. 3 illustrates translation from an original packet to a translated packet according to one embodiment of the present invention;
- FIG. 4A illustrates one use of a translation unit according to the present invention;
- FIG. 4B illustrates a second embodiment using a translator according to the present invention;
- FIG. 4C illustrates a third embodiment using a translator unit according to the present invention to translate packets sent among three networks;
- FIG. 5 illustrates the circuit for a multi-protocol translator according to one embodiment of the present invention;
- FIG. 6 illustrates one embodiment of a pipeline unit for use in the multi-protocol translator of FIG. 5;
- FIG. 7A illustrates a packet formatted according to the L2 VLAN tagged Ethernet dixie communication protocol;
- FIG. 7B illustrates the packet of FIG. 7A, translated to the ATM Forum LANE 2.0 communication protocol;
- FIG. 8 illustrates a method of translating a communication packet according to one embodiment of the present invention;
- FIG. 9 illustrates another embodiment of a multi-protocol translator according to the present invention, including a double pipeline unit;
- FIG. 10 illustrates another embodiment of a multi-protocol translator according to the present invention, including a quad pipeline;
- FIG. 11A illustrates one step of translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 11B illustrates the partial results of the translation, after the step shown in FIG. 11A;
- FIG. 12A illustrates a subsequent step in translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 12B illustrates the partial results of the translation, after the step illustrated in FIG. 12A is performed;
- FIG. 13A illustrates a next step in translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 14A illustrates a next step in translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 14B illustrates the partial results after the step illustrated in FIG. 14A;
- FIG. 15A illustrates a next step in translating a packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10;
- FIG. 15B illustrates the partial results in translating the packet after the step illustrated in FIG. 15A.
- While use of general purpose processors to perform translations is flexible, the system cannot be optimized for performing packet translation. Accordingly, a processor based system may not be able to meet the performance requirements for fast networks or when there is a lot of traffic through the translator.
- The alternative, hard coded state machines, can be quite expensive. In addition, they are inflexible. If any change is required, a new design must be made. This is a significant problem because communication protocols change frequently and new protocols are promulgated with some frequency. Moreover, the designs typically are difficult to modify to apply in new environments or where additional translations need to be performed by the
translator 12 of FIG. 1. - One or more embodiments of the present invention achieve a variety of advantages over these prior art systems. Certain embodiments of the present invention can achieve one or more of the following goals: the embodiment is fast, being equivalent or close to speed to a custom hardware based translation; real time processor intervention that would slow down translation is unnecessary; the translator can be adapted to perform new translations without extensive new development; the design is flexible and can be configured for multiple protocol translations; the translator is field upgradable (i.e., mistakes or new translations can be addressed with a field upgrade); the implementation is compact; and the translator is scalable—capable of performing trade-offs between speed and complexity.
- FIG. 2 illustrates a
simplex translator 28 according to one embodiment of the present invention. In a simplex translator, packets are translated in only one direction. Thus, a packet would be received from a first network on thenetwork interface 20 a, translated by thetranslator 28, and output to a second network bynetwork interface 20 b. The network interfaces 20 a, 20 b may be of the same form commonly used in the art to receive and send data packets to/from a network. For example, the network interface may be part of known packet switches, routers, bridges or just a physical port with associated hardware. - Data packets according to most protocols are in the general format illustrated at22 a-22 c. The packet typically includes a
packet header 22 a. The packet header may include a number of fields. One field typically identifies (in some manner) the path over which the packet should traverse. For example, the header could contain a unique path identifier that specifies the entire path through a network. In the alternative, theheader 22 a may include a destination address, that identifies the intended destination for the packet. Many communication protocols include both a destination address and a source address for the packet, as a part ofheader 22 a. The packet may also include atrailer 22 c. Both the header and the trailer typically include network, routing, format, error correction and detection, and other types of information, but not the actual data communicated. Typically, the data to be communicated or “payload” is a continuous block located between the header and trailer (or simply after the header, where there is no trailer), as illustrated at 22 b. - When a packet is received from
network interface 20 a, it is placed into aninput memory 21 a. Theinput memory 21 a can be any digital memory for storing received packets, including banks of registers, random access memory and other devices. Theinput memory 21 a may be a buffer memory, capable of storing multiple packets which arrive fromnetwork interface 20 a but have not yet been translated. - When a packet arrives, the
controller 24 determines what translation is required. This is done by determining what the current communication protocol format is for the packet and the communication protocol required to forward the packet. Wherenetwork interface 20 a is connected to only one type of network andnetwork interface 20 b is connected to only one (different) type of network, this function is simple to implement; the translation is always from one specific protocol to another specific protocol. Where multiple protocols may be placed intoinput memory 21 a, and multiple protocols may be required for output, the controller may perform a table lookup or other procedure to determine what protocols are required. For example, the destination address and source address for a packet can be used to determine the source and destination protocols for the packet. For many types of packets, theheader 22 a will include information identifying the network protocol, and the destination will determine what the output communication protocol should be. In the event that a table lookup is performed, this may be done using an associatedrandom access memory 25. Techniques for identifying what particular translation is required are currently known. Where more than one protocol translation is required, the multi-protocol translator (MPT) performs the appropriate translation based on the information provided by thecontroller 24. These functions of the controller are described in greater detail below. - The
controller 24 can be implemented in one of many ways. The controller will most likely be implemented using ASICs or programmable logic devices, for speed. A general processor could also be used to perform this function, as the amount of processing required to initiate packets is relatively small and delay incurred from use of a general purpose processor is minimal. - When an incoming packet22 a-22 c has been received and stored in the
input memory 21 a, and after the controller has determined what translation to perform, the controller can begin the translation process. - In the embodiment of FIG. 2, the translation process is performed by two separate elements—the multi-protocol translator (MPT)26 and the direct memory access (DMA)
controller 27. TheMPT 26 translates the header and trailer information from the first protocol (e.g., packet 22 a-22 c) into the header and trailer information for the new packet (23 a-23 c). The translated packet is stored inoutput memory 21 b, and when complete is forwarded to thenetwork interface 20 b for transmission across the second network. - The
MPT 26 could also forward thedata portion 22 b of the incoming packet into theoutput memory 21 b. (This may be particularly useful where a trailer or other field needs to be formulated based on the contents of the entire packet, such as a check-sum field or other error detection or correction fields. By passing the data through the MPT, the applicable field can be accumulated as the output memory is written.) Because no change is required to the payload for most translations, however, in many cases this may be done using only a direct memory access (“DMA”)controller 27. Thus, theDMA controller 27 can be forwarding data (payload) into the output memory while theMPT 26 is setting up the appropriate header and trailer information for the translated packet. - FIG. 3 illustrates the translation process from one packet (31-33) to a packet using a different communication protocol (34-37). The first packet includes a
header 31, the remainder of thepacket being data 33. As shown, the MPT translates the header of thefirst packet 31 into the new translatedheader 34. The MPT may also forward some of thepayload 32 into the new translated packet, as shown at 35. TheDMA controller 27 would then handle the transfer of the remainder of thepayload 38. (TheDMA controller 27 may include also a mechanism to alter byte alignment when multiple bytes are read from an input memory and/or multiple bytes written to an output memory, as explained with reference to the storage alignment units of FIGS. 9 and 10.) - The MPT might be configured to forward some of the
data 32 to thenew packet 35, to accommodate the possibility of variable length headers. For some communication protocols, the length of the header varies. One approach to resolving this is to have the system controller look up the header length and have the MPT process only the header, while the DMA transfers only data. Another solution, as illustrated in FIG. 3, is to take the maximum header size (here, equivalent tofields - The embodiment of FIG. 2 provides for unidirectional translation. That is, packets are only received (and not transmitted) on
network interface 20 a, translated by thetranslator 28, and transmitted (and no packets received) fromnetwork interface 20 b. To apply thetranslator 28 of FIG. 2 to the network of FIG. 1, twotranslator units 28 would be required. The first translator unit would handle packets traveling from thefirst network 10 to thesecond network 11. The second translator would handle packets traveling in the opposite direction (as in FIG. 4A). - The embodiment of FIG. 2 can be modified to handle bidirectional traffic. This can be achieved in at least two different ways. First, additional connections could be provided to permit translation both from
memory 21 a tomemory 21 b and vice versa. Thus, theDMA controller 27 would be capable of transferring data from theinput memory 21 a to theoutput memory 21 b as before, and would also be able to directly transfer data from thememory 21 b to thememory 21 a when packets are being sent fromnetwork interface 20 b to networkinterface 20 a. Similarly, theMPT 26 would be capable of receiving information for translation from bothmemories - Another possibility is to use
input memory 21 a only as an input buffer andoutput memory 21 b only as an output buffer, but to permit bothnetwork interface input memory 21 a and allowoutput memory 21 b to provide outgoing packets to bothnetwork interface output memories - FIG. 4A illustrates use of two unidirectional processors for translation between two networks. Thus, packets sent from a
first network 41 to asecond network 42 are translated by atranslator 44. Packets sent from thesecond network 42 to thefirst network 41 are sent through aseparate translator 45. This permits parallel processing, at the expense of added hardware. - FIG. 4B illustrates use of a
single translator unit 46, as described above, to send packets both from thefirst network 41 to thesecond network 42 and vice versa. In this case, the translator must perform two transactions—NW1 to NW2 and NW2 to NW1. - FIG. 4C illustrates use of a
single translator 47 with additional networks. In this embodiment, thefirst network 41,second network 42 andthird network 43 each have a different communication protocol. Themulti-protocol translator 47 can receive packets from all three networks, translate them to the appropriate protocol for the destination network, and forward the packet accordingly. Of course, similar designs using any number of networks could be implemented. - Referring again to FIG. 2, the
multi-protocol translator 26 should preferably be fast, flexible, programmable to handle multiple (and new) translations and upgradable without having to redesign the entire system. - FIG. 5 illustrates one embodiment of a multi-protocol translator according to the present invention. In general, the multi-protocol translator shown in the embodiment of FIG. 5 works as follows. The original frame (or frame to be translated) is held in
memory 53 a. Substitute information to be inserted into the translated frame is held (or produced) in other mechanisms. In FIG. 5, these information sources are the twoFIFO memories input memory 53 a,information sources output memory 58. The outgoing frame is then stored in theoutput memory 58. The appropriate data is passed through amultiplexer 56 into the output memory. A microcoded, pipelinedcontrol unit 59 controls the reading of thememories output memory 58 through themultiplexer 56. Thus, in FIG. 5, the translator has aninput memory 53 a, in which the original frame (the frame to be translated) is stored. Thisinput memory 53 a may receive the frame directly from a network interface as described above, or may be an additional buffer internal to the multi-protocol translator. - In the embodiment of FIG. 5, an
address control unit 53 b controls what memory location is read from the input memory for use in the translation. Theaddress control unit 53 b may further control the input memory for writing the original frame into the memory, as could be readily designed by one of skill in the art based on the disclosure provided herein. - The MPT also includes two first-in-first-out (“FIFO”)
memories FIFOs FIFOs - A
dump memory 57 may be included. The dump memory would serve to save information from the original frame (or the entire original frame) for system administration, diagnostic purposes, or for some other form of processing. - A
multiplexer 56 selectively provides the appropriate data from theinput memory 53 a,FIFO output memory 58. Of course, mechanisms other than multiplexers could be used to perform the same function. - The
output memory 58 can be any suitable memory (including registers, random access memory, etc.) to hold the translated frame (or the portion of the frame being translated by the MPT) during processing. Of course, multiple input or output buffers may be used, particularly where the buffer may be providing data to more than one network interface. Similarly, the input and output memories may be formed within the same single larger memory unit or made up of multiple smaller memory units. - To reduce the delay from memory read latency, the translator control unit is configured to issue read instructions in a pipelined fashion. In order to maintain flexibility and permit new translations to be performed on existing structures, the
translator control unit 59 is also microcoded. Accordingly, the translator control unit includes anopcode memory 51 a that stores the various instructions required for all of the translations that the MPT is capable of performing. The stepping through of the instructions performed in the opcode memory is controlled by theaddress control unit 51 b. Instructions are fed from theopcode memory 51 a to apipeline unit 52. In the embodiment of FIG. 5, the pipeline is implemented as a three stage, two-register pipeline. One register pipeline of the two-register pipeline is used for opcodes. The other pipeline is used for operands (which are also stored in theopcode memory 51 a). - At the beginning of the translation process, the
controller 24 of FIG. 2 selects the appropriate microcoded instructions stored in theopcode memory 51 a for use in the applicable translation (i.e., depending on the original and the new protocol for the translation). Thecontroller 24 sets theaddress control 51 b to the appropriate start place for the translation process. - The
controller 50 takes the opcode information from the pipeline 52 (received from theopcode memory 51 a) and appropriately sends control signals to the information source components for the translated header, e.g., theinput memory 53 a and the FIFOs 54 and 55. In addition, the controller controls the multiplexer, which selects the data being fed to theoutput memory 58 for any given write cycle of theoutput memory 58. Thecontroller 50 also controls what original frame information is recorded in thedump memory 57 and controls writingoutput memory 58 by controlling themultiplexer 56 and the output memory 58 (including its associated address control). - The
controller 50 can be implemented using discrete components or as part of an ASIC or using programmable logic arrays. Thecontroller 50 may also be implemented using a general purpose central processing unit, although this level of complexity may not be necessary for many implementations. - The lag time necessary to retrieve information from the various sources that make up the translated header can vary. For example, the time required to read from the
input memory 53 a may be longer than the time required to read from one of the FIFOs 54 and 55. Information coming directly from thetranslator control unit 59 could be written immediately. Thus, the example circuit of FIG. 5 has-three different read latencies: input memory (two clocks), FIFO (one clock), and data written from the controller (immediate). - To reduce delays from memory latency, the
pipeline 52 has three stages. For an opcode indicating data is to be transferred from the input memory to the output memory is encountered, the controller issues the appropriate read command to theinput memory 53 a when the opcode is in the first register of the pipeline in thepipeline unit 52. In subsequent stages of the pipeline, that opcode can be ignored, until the last stage, where thecontroller 50 configuresmultiplexer 56 to transfer the then-ready data from theinput memory 53 a to theoutput memory 58. - When data is to be written from one of the
FIFO memories controller 50 causes themultiplexer 56 to transfer the then-ready data from the FIFO to the output memory. - Finally, for information to be written directly to the output memory from the operand, the applicable opcode is ignored in the first two stages of the pipe, and the applicable write is made in the last stage of the pipe in the
pipeline unit 52. - FIG. 6 illustrates a simple circuit design for the
pipeline unit 52 of FIG. 5. The pipeline is implemented using 8 bit register banks (or latches) 60. The operand is fed through a first set ofregisters 62 while the opcode is fed through a second set ofregisters 61. All of theregisters 60 are clocked off of a common system clock CLK. Each of the stages of opcodes provides information to thecontroller 50. The operand from theoperand pipe 62 is directed to theoutput memory 58, through themultiplexer 56. - The opcode memory may also effectively be used as an additional stage of the pipeline. For example, instructions to change the address of the input memory can be taken by the
controller 50 and used to immediately begin the address change. - A set of instructions that may be used to program a translation using the multi-protocol translator of FIG. 5 is illustrated in the following Table 1:
TABLE 1 Single Pipe MPT Instructions Name Operand Description READ_ORIG no Move Byte from input memory to output memory READ_ORIG_DUMP no Move Byte from input memory to dump memory READ_FIFO1 no Move Byte from FIFO1 to output memory READ_FIFO2 no Move Byte from FIFO2 to output memory WRITE_IM yes Move operand to output memory JUMP_ORIG_DUMP yes Jump to new ORIG address (per operand value) and write to output memory JUMP_OPCODE yes Go to a “subroutine” address in a opcode memory space RETURN_OPCODE yes Return to opcode address + 1 which was stored when jump occurred RETURN_ORIG no Return to input memory address + 1 which was stored when jump occurred END no Tells controller that translation is finished - The operation of the multi-protocol translator illustrated in FIG. 5 can be understood in reference to the following example. The example shows conversion from L2 VLAN tagged Ethernet dixie (e.g., FIG. 7A) to ATM Forum LANE 2.0 communication protocol (as shown in FIG. 7B).
- FIG. 7A illustrates the format of a packet according to the L2 VLAN tagged Ethernet dixie communication protocol. A virtual destination address (VDA) and virtual source address (VSA) are the first two
fields 71 of thepacket 69. Atag type 72 is included. A destination address (DA), source address (SA) and ether type fields 73 are included. Finally, at the end of the packet, is the data orpayload 74. The L2 VLAN tagged Ethernet dixie protocol is known to those of skill in the art. - In this example, a packet of the L2 VLAN tagged Ethernet dixie protocol format illustrated in FIG. 7A is converted to the format of ATM Forum LANE 2.0, as illustrated in FIG. 7B. In the ATM Forum LANE 2.0
packet 70 of FIG. 7B, thefirst field 75 is a fixed communication protocol identifier and is the same for every packet formatted according to this protocol. An ether-type 76 is included (different from the ether type shown in FIG. 7A). An ElanID and LecID fields 77 are included. These fields are determined according to the protocol, and, in this example, loaded into the FIFO for the translation. Destination and source addresses and ether type fields 78 are included, which are identical in content to the correspondingfields 73 of FIG. 7A. Finally, a packet according to the ATM Forum LANE 2.0 protocol includes apayload 79 at the end. Thepayload 79 in the translated packet is identical to thepayload 74 of the original packet. - FIG. 8 illustrates a method of using a multi-protocol translator of FIG. 5 to translate the packet of FIG. 7A (L2 VLAN tagged Ethernet dixie) into the packet of FIG. 7B (ATM Forum LANE 2.0). At a
step 80, the applicable operation codes (in this case, including operands) for the translation are loaded into the opcode memory 51A of FIG. 5. This is typically done at initialization, not during translation. -
Block 89 illustrates the normal processing of a packet using one embodiment of a multi-protocol translator according to the present invention. At astep 82, the translator waits to receive a packet. Once a packet is received, processing begins at astep 83. - At
step 83, the packet is loaded into theinput memory 53 a of the translator. - At a
step 84, the controller 24 (of FIG. 2) identifies what translation is required. This is done by examining the protocol of the incoming packet and determining (based on the destination of the packet) the protocol to which the packet should be translated. At astep 84,FIFO1 55 of FIG. 5 is also loaded with the ATM Forum LANE 2.0 ether type, ElanID and LecID fields (determined by the controller for the applicable packet using methods known in the art for this communication protocol). - In this embodiment, after the applicable translation has been identified, the payload of the packet (74 of FIG. 7A) is directly transferred into the
output memory 58 of FIG. 5 (the DMA path is not shown in FIG. 5). - In this embodiment, while the payload is being transferred from the input to the output memory, the multi-protocol translator unit translates the header information of the original packet into the appropriate header for the translated packet.
- The header translation is performed as illustrated at steps86 a-86 d.
- At
step 86 a, the initial fields of the original packet are dumped (fields dump memory 57 of FIG. 5. In the alternative, where the 3 information need not be saved, the controller can simply cause theaddress control 53 b of theinput memory 53 a to jump over these fields. - At
step 86 b, the LLC-OUI header is written to the output memory. In this particular embodiment, the LLC-OUI field is written directly from the opcode memory. That is, a series of microcode instructions write the operand directly from thepipeline unit 52 to theoutput memory 58 of FIG. 5 (through multiplexer 56). Thus, for the LLC-OUI field (75 of FIG. 7B), the entire field is contained as operands in the opcode memory and transferred by directly writing the operands to the output memory. Thus, when the opcode is provided to thepipeline unit 52, nothing happens immediately. (However, since it is pipelined, previous and subsequent opcodes may be active, depending on the opcode and the stage the opcode is in.) Instead, the operand passes through the three stages of the pipeline, with the operand being written when the instruction is in the last stage of thepipeline 52. - At a
step 86 c, the Ether type, ElanID and LecID fields (76, 77 of FIG. 7B) are written fromFIFO1 55 of FIG. 5 to theoutput memory 58. In this particular embodiment, the lag time of theFIFO1 55 read before the output memory can be written is two clock cycles. Accordingly, when an instruction from theopcode memory 51 a is passed to thepipeline 52, calling for writing data fromFIFO1 55 to theoutput memory 58, nothing happens at the first stage. At the second stage, however, the read command is issued to FIFO1 55. When the opcode reaches the last stage of thepipeline unit 52, the data is ready to be read from FIFO1 to the output memory. Accordingly, when that instruction is in the last stage of the pipeline, the instruction causes thecontroller 50 to configure themultiplexer 56 to pass data fromFIFO1 55 to theoutput memory 58 and sets upoutput memory 58 for the appropriate write. In the meantime, a new read is issued from the second stage of thepipeline unit 52, to setup the next data to be written fromFIFO1 55 tooutput memory 58. - Finally, at a
step 86 d, the DA, SA and Ether type fields of the original packet (field 73 of FIG. 7A) are transferred directly to the output memory 58 (corresponding to field 78 of FIG. 7B). In this example, theinput memory 53 a is assumed to have a latency period (in clock cycles) longer than the FIFO (two clock cycles rather than one). Accordingly, when the opcode is placed in thepipeline unit 52, a read command is issued at the first stage of thepipeline 52. When the opcode corresponding to transfer of data frominput memory 53 a tooutput memory 58 reaches the last stage of thepipeline 52, the data is ready to be passed from theinput memory 53 a to the output memory 58 (the clock cycles corresponding to the latency of input memory having passed, while the opcode is passing through the pipeline 52). Accordingly, when the command reaches the last stage ofpipeline 52, it causes thecontroller 50 to configure themultiplexer 56 to pass data from theinput memory 53 a to the output memory 58 (as well as enabling writing of the output memory 58). - When steps85 and 88 are complete, the complete translated packet is in the
output memory 58 of FIG. 5. Accordingly, at astep 87, the packet can be transferred from the output memory to the network interface for propagation to its applicable destination address. When this is done, processing may continue atstep 82. - As might be appreciated from the disclosure provided above, the
multiplexer 56 of FIG. 5 should be configured so that the data path into theoutput memory 58 is open before the setup time of the output memory logic, but after the hold time of the multiplexer logic. If the sum of the setup and hold time of the multiplexer plus the hold time of the input path plus the setup of the output logic exceeds one clock cycle, the multiplexer configuration may be performed at an earlier stage (e.g., the second stage) of thepipeline 52. This would make the multiplexer control logic based on the previous stage rather than decoded from the current last stage. - In the embodiment of FIG. 5, a one byte channel is used to move information from the applicable source (pipeline operand, FIFO memory or input memory) to the output memory. The throughput of the translator can be increased by providing for a wider data channel.
- FIG. 9 illustrates a multi-protocol translator unit that includes a sixteen bit (two byte) data channel, according to the present invention. In the embodiment of FIG. 9, the incoming, original packets are stored in
input memory 90 b, which is controlled by anaddress control 90 a, as in FIG. 5. The difference, however, is that the input memory can read two bytes of information from the data packet. - The translator includes an
information memory 91 b, controlled by anaddress control 91 a.Memory 91 b stores information to be written into the translated header, and functions similar to the FIFO memory illustrated in FIG. 5. A difference, however, is that two bytes of information can be read from theinformation memory 91 b. - Like the
input memory 90 b and theinformation memory 91 b, theoutput memory 97 can receive two bytes of information. Thus, two single byte channels of information, A and B, can be simultaneously written to the output memory. A byte of data from the input memory can be provided to the A channel or the B channel of theoutput memory 97.Multiplexer 92 a selects the applicable byte from theinput memory 90 b or theinformation memory 91 b for provision along the A channel to be written in theoutput memory 97. Similarly,multiplexer 92 b selects a byte from the information memory or input memory to be provided to the B channel of theoutput memory 97, throughmultiplexer 95 b.Multiplexers output memory 97, permitting data to be written from thetranslator control unit 98 c, the input memory or information memory data selected by theapplicable multiplexer storage alignment units - The
storage alignment unit 93 a serves to hold data to be written to theoutput memory 97 in later clock cycles. Thus, if information needs to be delayed before being written to the output memory, that information can be held for one or more clock cycles in thestorage alignment unit 93 a. This permits data to be held and realigned when written to theoutput memory 97. For example, if a byte becomes available in the data passed frommultiplexer 92 a before the corresponding data to be written in channel B of theoutput memory 97 is available, the A channel information can be held and delayed instorage alignment unit 93 a. When the corresponding byte for channel B of theoutput memory 97 is available, the delayed information held instorage alignment unit 93 a can be written to the A channel of theoutput memory 97, throughmultiplexer 95 a. - The
storage alignment unit 93 a includes amultiplexer 96 a and aregister 96 b. In this particular embodiment, the register is written on every clock cycle. Accordingly, if the data needs to be delayed for more than one clock cycle, the data held in 96 b needs to be refreshed (or maintained) throughmultiplexer 96 a. An example of a translation using thedelay units - The
control unit 98 c has a similar configuration to thecontrol unit 59 of FIG. 5. Anopcode memory 99 b stores the opcodes and operands for controlling the entire translator unit. Anaddress control 99 a controls the opcodes being read from theopcode memory 99 b. Theopcode memory 99 b, however, includes two opcode/operand channels, each sixteen bits wide. The first opcode/operand pair is fed to afirst pipeline 98 a′, like thepipeline unit 52 of FIG. 5. The second opcode/operand pair is fed to asecond pipeline 98 a″, also like thepipeline unit 52 of FIG. 5. The twosections 98 a′, 98 a″ of thedouble pipeline unit 98 a permit separate control for components used in writing the A channel and B channel ofoutput memory 97. - In this embodiment, the
double pipeline unit 98 a includes two three-stage pipelines. In this particular embodiment, three stages were selected to correspond to different latencies from the various components that provide data to theoutput memory 97. Thus, theinput memory 90 b might have one read latency, theinformation memory 91 b a different (e.g., shorter) read latency, and the information being written directly from an operand held in the last stage of either side of thedouble pipeline unit 98 a having no latency. - A set of instructions that may be used for the translator unit of FIG. 9 are listed in the following table:
TABLE 2 Name Operand Description R_ORIG_U_A no read upper Byte lane of input memory and advance address controller R_ORIG_L _A no read lower Byte lane of input memory and advance address controller R_0MG_U_NA no read upper Byte lane of input memory and do not advance address controller R_ORIG_U_NA no read lower Byte lane of input memory and do not advance address controller PRELOAD_ORIG_U yes preload input memory address controller with address in operand and read from upper Byte lane PRELOAD_ORIG_L yes preload input memory address controller with address in operand and read from lower Byte lane R_INFO_U_A no read upper Byte lane of INFO memory and advance address controller R_INFO_L_A no read lower Byte lane of INFO memory and advance address controller R_INFO_U_NA no read upper Byte lane of INFO memory and do not advance address controller R_INFO_U_NA no read lower Byte lane of INFO memory and do not advance address controller PRELOAD_INFO_U yes preload INFO memory address controller with address in operand and read from upper Byte lane PRELOAD_INFO_L yes preload INFO memory address controller with address in operand and read from lower Byte lane R_BYTE_STORE no read byte stored in Delay Unit WRITE_IM yes write operand into output memory JUMP_OPCODE yes change the current address of the opcode address controller to the operand. Store off current address to opcode jump register RETURN_OPCODE no change the current address of the opcode to the opcode jump register + 1; STALL no do not write output memory END no end of algorithm - Each of the opcode/operand pairs listed in Table 2 can be fed to either side of the
double pipeline unit 98 a. That is, an entire opcode/operand output from theopcode memory 99 b would include two instructions of the form listed in Table 2—one for each side. In selecting binary opcodes for these instructions, additional bits are dedicated to signal an individual function. One bit signals writing of theoutput memory 58. The other bit controlling reads and writes from analignment storage unit - By increasing the number of bytes that can be written to the output memory per clock cycle from one to two (as was done in altering the embodiment of FIG. 5 to FIG. 9), the throughput of the translator unit can be increased. The number of channels can of course be increased beyond two.
- FIG. 10 illustrates an embodiment of a translator unit where four channels A, B, C and D can be written simultaneously to an
output memory 105. - Like the earlier embodiments, this embodiment has an
input memory 100 b for storing the original frame to be translated. Theinput memory 100 b is controlled by anaddress control unit 100 a. Similarly, information to be inserted into the translated header of the translated packet is stored in aninformation memory 101 b, which is controlled by anaddress control unit 101 a. Unlike the earlier embodiments, however, four bytes of data can be read from each of theinput memory 100 b andinformation memory 101 b in one clock cycle. - A set of four
multiplexers 102 permit any of the output bytes of theinput memory 100 b andinformation memory 101 b to be fed along a data channel that feeds any of the four input channels A, B, C and D of theoutput memory 105. - A series of four
alignment storage units 103 permit a byte being fed along one of the data channels to the output memory to be stored, for alignment with subsequently read data on the other data channels. These alignment storage units are of the same configuration as described above with respect to thealignment storage units - A set of four
multiplexers 104 provide the final selection as to what data is actually written to the applicable data channel A, B, C, D of theoutput memory 105 for a particular clock cycle. - A
control unit 109 controls the timing and application of data being written to theoutput memory 105. Like the earlier embodiments, this embodiment has anopcode memory 106 b, controlled by anaddress control unit 106 a. Unlike the earlier embodiments, however, this opcode memory provides a set of four opcodes, each with an applicable operand. Thus, sixty-four bits are provided as an output of theopcode memory 106 b. - These four opcode/operand pairs are provided to a quad pipe. The quad pipe includes four pipelines of the type illustrated and described above with reference to
pipeline unit 52 of FIG. 5. Each opcode/operand pair can perform one or more functions with respect to the components in one of the channels providing data to theoutput memory 105. Thus, because four different pipelines are functioning simultaneously, components in all four of the data channels can be controlled simultaneously and separately. Because there are three different memory latency cycles (one for the input memory, one for the information memory and the immediate write of an operand to the output memory through one of the multiplexers 104), this pipeline also has three stages. - A
controller 108 takes the information from each of the stages of the pipeline, and each of the four pipeline units, and uses that information to provide the appropriate control signals for the remainder of the translator unit. - Table 3 sets forth a set of instructions that may be used to control the translator unit of FIG. 10.
TABLE 3 Opcodes Name Operand Description R_ORIG_B3_A no read Byte lane 3 of input memory and advance address controller R_ORIG_B2_A no read Byte lane 2 of input memory and advance address controller R_ORIG_B1_A no read Byte lane 1 of input memory and advance address controller R_ORIG_B0_A no read Byte lane 0 of input memory and advance address controller R_ORIG_B3_NA no read Byte lane 3 of input memory and do not advance address controller R_ORIG_B2_NA no read Byte lane 2 of input memory and do not advance address controller R_ORIG_B1_NA no read Byte lane 1 of input memory and do not advance address controller R_ORIG_B0_NA no read Byte lane 0 of input memory and do not advance address controller PRELOAD_ORIG_B3 yes preload input memory address controller with address in operand and read from Byte lane 3 PRELOAD_ORIG_B2 yes preload input memory address controller with address in operand and read from Byte lane 2 PRELOAD_ORIG_B1 yes preload input memory address controller with address in operand and read from Byte lane 1 PRELOAD_ORIG_B0 yes preload input memory address controller with address in operand and read from Byte lane 0 R_INFO_B3_A no read Byte lane 3 of info memory and advance address controller R_INFO_B2_A no read Byte lane 2 of info memory and advance address controller R_INFO_B1_A no read Byte lane 1 of info memory and advance address controller R_INFO_B0_A no read Byte lane 0 of info memory and advance address controller R_INFO_B3_NA no read Byte lane 3 of info memory and do not advance address controller R_INFO_B2_NA no read Byte lane 2 of info memory and do not advance address controller R_INFO_B1_NA no read Byte lane 1 of info memory and do not advance address controller R_INFO_B0_NA no read Byte lane 0 of info memory and do not advance address controller PRELOAD_INFO_B3 yes preload info memory address controller with address in operand and read from Byte lane 3 PRELOAD_INFO_B2 yes preload info memory address controller with address in operand and read from Byte lane 2 PRELOAD_INFO_B1 yes preload info memory address controller with address in operand and read from Byte lane 1 PRELOAD_INFO_B0 yes preload info memory address controller with address in operand and read from Byte lane 0 R_BYTE_STORE no read byte stored in Alignment Storage WRITE_IM yes write operand into output memory JUMP_OPCODE yes change the current address of the opcode address controller to the operand. Store off current address to opcode jump register RETURN_OPCODE no change the current address of the opcode to the opcode jump register + 1; STALL no do not write output memory END no end of algorithm - As above, each of these opcodes applies to each of the data channels A, B, C, D of the output memory. Thus, the opcodes of Table 3 apply to just one of the channels, and each read from the opcode memory would produce four of such opcodes. In addition, like above, two extra bits for each opcode encode whether one or both of the output memory or applicable storage alignment unit is written.
- Operation of the circuit of FIG. 10 can be understood through the following example. This example converts the L2 VLAN tagged Ethernet dixie packet illustrated and discussed with reference to FIG. 7A into the ATM Forum LANE 2.0 protocol, as illustrated and discussed with reference to FIG. 7B.
- FIG. 11 A illustrates the first write to output memory when using the translator unit of FIG. 10 to translate the packet of FIG. 7A into the packet of FIG. 7B. As shown in FIG. 11A, the
pipeline 107 has already received three sets of instructions (over three clock cycles). In the last stage of the pipeline at this step, an instruction in each of the four parallel pipelines causes data to be written immediately to theoutput memory 105. Thus, the four operands of the applicable instructions are written to the output memory during the next clock cycle. In FIGS. 11A-15A, the most significant byte is presumed to be at the bottom of theoutput memory 105. Accordingly, the opcode/operand pairs causes the sequence AA-AA-03-00 (4 bytes of data) to be written simultaneously to theoutput memory 105. The opcode “write_im” (write immediate) causes the control unit (not shown) to configure themultiplexers 104 to connect the applicable operands to the input of theoutput memory 105, as shown. - In the second to the last stage of the
pipeline 111, two more write immediate codes are present as instructions. As described above, no action is taken when these instructions are at this stage of the pipeline, because the write immediate cannot immediately write data to theoutput memory 105 until reaching the last stage of thepipeline 107.Instructions information memory 101 b. Due to the latency of thememory 101 b, the read information commands at 111 a and 111 b cause a read cycle to begin at theinformation memory 101 b, when the read information operation code is in the second tolast stage 111 ofpipeline unit 107—so that the data is ready to be written to theoutput memory 105 when the data reaches the last stage of the pipeline. - FIG. 11B illustrates the state of the output memory after the operation performed in FIG. 11A. As illustrated, four bytes of the
header 118 have been written. The remainder of the translatedpacket 119 has not yet been written to the output memory. - FIG. 12A illustrates the next step in translating the packet. At this point, the
last stage 112 of thepipeline unit 107 has two writeimmediate commands information memory information memory 101 b to theoutput memory 105. Accordingly, the control unit (not shown) configures theappropriate multiplexers 104 to pass the information directly into theoutput memory 105. As shown within the box illustratinginformation memory 101 b, the two bytes of the Ether-type are stored in bytes “0” and “1” of the four byte word stored in theinformation memory 101 b. Thus, the illustrated connection transfers the Ether-type bytes to theoutput memory 105. - FIG. 12B illustrates the packet as stored in the
output memory 105 after the step illustrated in FIG. 12A takes place. As shown, the leading header and Ether-type have now been written to theoutput memory 105, as shown at 125. The remainder of the translatedpacket 126 has not yet been written to theoutput memory 105. - FIG. 13A illustrates the next step in the translation. At this point, the two most significant bytes for the ElanID field are stored in a four byte word in the
information memory 101 b, as shown. These two bytes cannot be written directly to the output memory, however, because the output memory requires a four byte word to be written. Accordingly, the two bytes of the ElanID need to be stored in thestorage alignment units 103, for later writing to theoutput memory 105. This is done as illustrated in FIG. 13A. During this clock cycle, no information is written to the output memory. Accordingly, the output memory continues to hold the same partially translated packet of FIG. 12B. - At the step illustrated in FIG. 13A, the other two pipelines hold two instructions that require reading of information from the
input memory 100 b 13 jump orig B0 at 131 a (which causes theinput memory 100 b to jump to an operand address—to cause the address controller (not shown) of theinput memory 100 b to skip over the portions of the original packet header that are not used in the translated packet, i.e., fields 71, 72 of FIG. 7A). By changing the address of theinput memory 100 b, the next portion of the header to be read can be moved to an address that skips (deletes) fields 71, 72 of FIG. 7A (deletes the VDA, VSA and TAG type fields). In this particular embodiment, the read latency of theinput memory 100 b is longer than the read latency of theinformation memory 101 b. When instructions involving reading of theinput memory 100 b reach thefirst stage 110 of the pipeline unit (at 131 a and 131 b), the control unit (not shown) causes the input memory'saddress control unit 100 a to apply the applicable address and initiates a read of theinput memory 100 b. - FIG. 14A illustrate the next clock cycle in this translation. At this step, the remainder of the ElanID field is present at
bytes information memory 101 b. Accordingly, these bytes may be written from theinformation memory 101 b to the output memory, as is accomplished withinstructions multiplexers 104 to pass the data frombytes 0 andbyte 1 of theinformation memory 101 b to theoutput memory 105. At the same time, instructions causing data to be written from the bottom two storage elements of thestorage elements 103 to be simultaneously written to the output memory 105 (i.e., theinstructions output memory 105. - FIG. 14B illustrates the portion of the packets stored in the
output memory 105, after the step illustrated in FIG. 14A. As is shown, the beginning of the packet through the ElanID field is included 145. The remainder of thepacket 146 remains to be placed into the output memory. (Note, however, that if DMA control is used to transfer the payload to the output memory, a portion of the payload may also be in the output memory at this point and, perhaps, earlier.) FIG. 15A illustrates the next clock cycle. During this clock cycle, the first two bytes of the destination address are written to the output memory from the input memory, per the instructions at 150 c and 150 d. As discussed above, the read from this memory was initiated back when these instructions appeared in the first stage of thepipeline 110. At the same time, twoinstructions - FIG. 15B illustrates the contents of the
output memory 105 after the step illustrated in FIG. 15A. Most of the header has been written, including a portion of the destination address (transferred directly from the equivalent field of the original packet). The remainder of thepacket 156 is yet to be written to the output memory. - Returning to FIG. 15A, the instructions to transfer the remainder of the header of the original packet header to the translated packet in the output memory are shown (the DA, SA and Ether-type fields that remain to be written are all transferred directly from the equivalent fields held in the
input memory 100 b). As can be seen from the instructions in the pipeline, the information is transferred using the storage alignment units, in the manner described above. - Pipelines with three stages and having a width of 1, 2 and 4 pipelines have been described. Pipelines of varying numbers of stages and varying widths can be constructed. Moreover, the example opcodes are illustrative only. Any number of other byte manipulations could be implemented. Finally, because the translator circuit structure may be built from common components, circuit design lends itself to automated procedures, including automated circuit design and optimization.
- Having thus described at least one illustrative embodiment of the invention, various modifications and improvements will readily occur to those skilled in the art and are intended to be within the scope of the invention. Accordingly, the foregoing description is by way of example only and is not intended as limiting. The invention is limited only as defined in the following claims and the equivalents thereto.
Claims (21)
1. A translator unit for translating a packet formatted according to a first protocol into a packet according to a second protocol, the translator unit comprising:
an input memory;
at least one information source;
an output memory;
a connection circuit, coupled to the input memory, the information source and the output memory, to selectively connect the input memory and the information source to the output memory; and
a microcoded control unit coupled to the connection circuit.
2. The translator unit of , wherein the information source is selected from the group consisting of a register, a FIFO memory, a random access memory and an opcode memory storing data as operands of microcoded instructions.
claim 1
3. The translator unit of , wherein the microcoded control unit includes a pipeline unit.
claim 1
4. The translator unit of , wherein the microcoded control unit includes two pipeline units.
claim 1
5. The translator unit of , wherein:
claim 4
the output memory includes at least two inputs to simultaneously write at least two bytes of data into the output memory; and
the connection circuit includes means for aligning the two bytes of data to be simultaneously written into the output memory.
6. The translator unit of , wherein the microcoded control unit includes four pipeline units.
claim 1
7. The translator unit of , wherein:
claim 6
the output memory includes at least four inputs to simultaneously write at least four bytes of data into the output memory; and
the connection circuit includes means for aligning the four bytes of data to be simultaneously written into the output memory.
8. The translator unit of , further comprising a direct memory access controller coupled to the input memory and the output memory.
claim 1
9. The translator unit of , wherein the microcoded control unit includes an opcode memory programmed to perform multiple different protocol translations.
claim 1
10. A pipelined control unit for reading data, comprising:
a first memory having a first read latency;
a second memory having a second read latency, longer than the first read latency;
a pipeline unit having a first stage and a second stage;
a circuit, coupled to the pipeline unit, the first memory and the second memory, to initiate read cycles from the first memory based on a first instruction in the second stage of the pipeline, and to initiate read cycles from the second memory based on a second instruction in the first stage of the pipeline.
11. The pipelined control unit of , further comprising a microcontroller coupled to the circuit.
claim 10
12. A method of translating an original packet from a first protocol to a second protocol, comprising steps of:
loading a first memory with a plurality of sets of microcode instructions, each set being designed to perform a different network communication protocol translation;
receiving the original packet;
selecting a one of the sets of microcode instructions, based on the identity of the first protocol and the identity of the second protocol; and
translating the original packet into a translated packet by executing the selected set of microcode instructions.
13. The method of , wherein the translating step includes a step of feeding the microcode instructions through a pipeline.
claim 12
14. A method of translating an original packet into a translated packet, comprising steps of:
loading an instruction memory with a set of instructions;
loading the original packet into an input memory, the input memory having a first read latency;
providing an information source;
providing an output memory to store the translated packet;
sequentially, selectively connecting the input memory and the information source to the output memory, based on the instructions.
15. The method of , wherein the loading step comprises a step of loading microcoded instructions.
claim 14
16. The method of , wherein the connecting step comprises a step of feeding the instructions through a pipeline unit.
claim 14
17. The method of , wherein:
claim 16
the pipeline unit has a plurality of stages;
the set of instructions includes a first instruction to read information from the input memory and write the information to the output memory, and a second instruction to read information from the information source and write the information to the output memory; and
the connecting step comprises steps of
initiating reads from the input memory when the first instruction is at a one of the pipeline stages selected based on a read latency for the input memory; and
initiating reads from the information source when the second instruction is at a one of the pipeline stages selected based on the second read latency.
18. The method of , wherein the connecting step comprises a step of connecting the input memory to the output memory when the first instruction reaches a one of the pipeline stages after the pipeline stage where the first instruction initiated reading of the input memory.
claim 17
19. The method of , further comprising a step of transferring a payload portion of the original packet from the input memory to the output memory using a direct memory access controller.
claim 14
20. The method of , wherein:
claim 14
the connecting step includes a step of connecting a plurality of data channels to the output memory.
21. The method of , further comprising a step of storing data in an alignment storage unit to align data on the data channels to be simultaneously written to the output memory.
claim 20
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/730,453 US20010033580A1 (en) | 1997-11-19 | 2000-12-05 | Multi-protocol packet translator |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/974,632 US6198751B1 (en) | 1997-11-19 | 1997-11-19 | Multi-protocol packet translator |
US09/730,453 US20010033580A1 (en) | 1997-11-19 | 2000-12-05 | Multi-protocol packet translator |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/974,632 Division US6198751B1 (en) | 1997-11-19 | 1997-11-19 | Multi-protocol packet translator |
Publications (1)
Publication Number | Publication Date |
---|---|
US20010033580A1 true US20010033580A1 (en) | 2001-10-25 |
Family
ID=25522278
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/974,632 Expired - Lifetime US6198751B1 (en) | 1997-11-19 | 1997-11-19 | Multi-protocol packet translator |
US09/730,453 Abandoned US20010033580A1 (en) | 1997-11-19 | 2000-12-05 | Multi-protocol packet translator |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/974,632 Expired - Lifetime US6198751B1 (en) | 1997-11-19 | 1997-11-19 | Multi-protocol packet translator |
Country Status (6)
Country | Link |
---|---|
US (2) | US6198751B1 (en) |
EP (1) | EP1033020B1 (en) |
AU (1) | AU729211B2 (en) |
CA (1) | CA2310741C (en) |
DE (1) | DE69810511T2 (en) |
WO (1) | WO1999026376A2 (en) |
Cited By (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002063831A1 (en) * | 2000-12-30 | 2002-08-15 | Redback Networks Inc. | Method and appatatus for processing of multiple protocols within data transmission signals |
US20030016699A1 (en) * | 2001-03-31 | 2003-01-23 | Mcclary Michael | Alignment of TDM-based signals for packet transmission using framed and unframed operations |
US20030023760A1 (en) * | 2001-03-31 | 2003-01-30 | Mcclary Michael | Method and apparatus for sync hunting signals |
US20030069997A1 (en) * | 2001-08-31 | 2003-04-10 | Philip Bravin | Multi modal communications system |
US20030140157A1 (en) * | 2002-01-22 | 2003-07-24 | Beverly Harlan T. | Removing data from contiguous data flows |
US20040073714A1 (en) * | 2001-03-31 | 2004-04-15 | Mcclary Michael | Method and apparatus for deframing signals |
US20050047407A1 (en) * | 2003-08-27 | 2005-03-03 | Cosine Communications, Inc. | Heterogeneous media packet bridging |
US20050068948A1 (en) * | 2003-09-15 | 2005-03-31 | Sanjay Bhardwaj | Generating an encapsulating header based on encapsulated information provided at protocol-dependent locations |
US20050078704A1 (en) * | 2003-10-14 | 2005-04-14 | International Business Machines Corporation | Method and apparatus for translating data packets from one network protocol to another |
US6950446B2 (en) | 2001-03-31 | 2005-09-27 | Redback Networks Inc. | Method and apparatus for simultaneously sync hunting signals |
US7050395B1 (en) | 2001-11-30 | 2006-05-23 | Redback Networks Inc. | Method and apparatus for disabling an interface between network element data processing units |
US7075951B1 (en) | 2001-11-29 | 2006-07-11 | Redback Networks Inc. | Method and apparatus for the operation of a storage unit in a network element |
US7151780B1 (en) * | 2002-03-06 | 2006-12-19 | Cisco Technology, Inc. | Arrangement for automated teller machine communications based on bisync to IP conversion |
US20070064704A1 (en) * | 2002-06-04 | 2007-03-22 | Fortinet, Inc. | Methods and systems for a distributed provider edge |
US20070109968A1 (en) * | 2002-06-04 | 2007-05-17 | Fortinet, Inc. | Hierarchical metering in a virtual router-based network switch |
US7308004B1 (en) | 2002-03-06 | 2007-12-11 | Redback Networks, Inc. | Method and apparatus of multiplexing and demultiplexing communication signals |
US20080008211A1 (en) * | 2006-07-07 | 2008-01-10 | Itai Ephraim Zilbershtein | Inter-network translation |
US7324539B1 (en) | 2001-11-28 | 2008-01-29 | Redback Networks Inc. | Method and apparatus for processing channelized and unchannelized data within a signal |
US20080186052A1 (en) * | 2007-02-01 | 2008-08-07 | International Business Machines Corporation | Methods, systems, and computer program products for using direct memory access to initialize a programmable logic device |
US20080259934A1 (en) * | 2000-09-13 | 2008-10-23 | Fortinet, Inc. | Distributed virtual system to support managed, network-based services |
US20080317040A1 (en) * | 2004-11-18 | 2008-12-25 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US20090046728A1 (en) * | 2000-09-13 | 2009-02-19 | Fortinet, Inc. | System and method for delivering security services |
US20090073977A1 (en) * | 2002-06-04 | 2009-03-19 | Fortinet, Inc. | Routing traffic through a virtual router-based network switch |
US20090225754A1 (en) * | 2004-09-24 | 2009-09-10 | Fortinet, Inc. | Scalable ip-services enabled multicast forwarding with efficient resource utilization |
US20090238181A1 (en) * | 2002-06-04 | 2009-09-24 | Fortinet, Inc. | Network packet steering via configurable association of processing resources and network interfaces |
US20100011245A1 (en) * | 2002-08-29 | 2010-01-14 | Fortinet, Inc. | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
US20100094980A1 (en) * | 2000-09-13 | 2010-04-15 | Fortinet, Inc. | Managing and provisioning virtual routers |
US7720053B2 (en) | 2002-06-04 | 2010-05-18 | Fortinet, Inc. | Service processing switch |
US20100189016A1 (en) * | 2001-06-28 | 2010-07-29 | Fortinet, Inc. | Identifying nodes in a ring network |
US20100265879A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Multi-satellite architecture |
US20100265877A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Access node/gateway to access node/gateway layer-2 connectivity (end-to-end) |
US20100265941A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Layer-2 extension services |
US20100265950A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Acceleration through a network tunnel |
US20100265876A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US20100265957A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Core-based satellite network architecture |
US20100265878A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Mobility across satellite beams using l2 connectivity |
US7912936B2 (en) | 2000-09-13 | 2011-03-22 | Nara Rajagopalan | Managing interworking communications protocols |
US20110200044A1 (en) * | 2002-11-18 | 2011-08-18 | Fortinet, Inc. | Hardware-accelerated packet multicasting in a virtual routing system |
US8069233B2 (en) | 2000-09-13 | 2011-11-29 | Fortinet, Inc. | Switch management system and method |
US20130148583A1 (en) * | 2010-01-13 | 2013-06-13 | Sony Corporation | Method and system for transferring data between wireless devices |
WO2015171922A1 (en) * | 2014-05-09 | 2015-11-12 | Google Inc. | System and method for adapting to network protocol updates |
US9276663B2 (en) | 2009-04-17 | 2016-03-01 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US9391964B2 (en) | 2000-09-13 | 2016-07-12 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
US11711299B2 (en) * | 2020-01-10 | 2023-07-25 | Cisco Technology, Inc. | Traffic mirroring in hybrid network environments |
US11962397B2 (en) | 2022-07-08 | 2024-04-16 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
Families Citing this family (41)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6791947B2 (en) | 1996-12-16 | 2004-09-14 | Juniper Networks | In-line packet processing |
US6198751B1 (en) * | 1997-11-19 | 2001-03-06 | Cabletron Systems, Inc. | Multi-protocol packet translator |
US6438137B1 (en) * | 1997-12-22 | 2002-08-20 | Nms Communications Corporation | Packet-based trunking |
US6980543B1 (en) * | 1998-06-19 | 2005-12-27 | Juniper Networks, Inc. | Interconnect network for operation within a communication node |
AU771091B2 (en) | 1998-06-19 | 2004-03-11 | Juniper Networks, Inc. | Device for performing IP forwarding and ATM switching |
US6603768B1 (en) | 1998-06-27 | 2003-08-05 | Intel Corporation | Multi-protocol conversion assistance method and system for a network accelerator |
US6604136B1 (en) | 1998-06-27 | 2003-08-05 | Intel Corporation | Application programming interfaces and methods enabling a host to interface with a network processor |
US6735773B1 (en) | 1998-06-27 | 2004-05-11 | Intel Corporation | Method and apparatus for issuing commands to a network processor configured to provide a plurality of APIs |
US6657959B1 (en) | 1998-06-27 | 2003-12-02 | Intel Corporation | Systems and methods for implementing ABR with guaranteed MCR |
US6724767B1 (en) * | 1998-06-27 | 2004-04-20 | Intel Corporation | Two-dimensional queuing/de-queuing methods and systems for implementing the same |
JP3149926B2 (en) * | 1998-09-28 | 2001-03-26 | 日本電気株式会社 | Address translation method and apparatus |
US6785730B1 (en) * | 1999-02-16 | 2004-08-31 | Rebecca S. Taylor | Generic communications protocol translator |
JP2000354080A (en) * | 1999-04-09 | 2000-12-19 | Komatsu Ltd | Method for controlling communication between electronic devices, construction machine using the same, and electronic circuit for construction machine |
US6879588B1 (en) * | 1999-05-21 | 2005-04-12 | Broadcom Corporation | Address resolution snoop support for CPU |
US7039800B1 (en) * | 1999-05-24 | 2006-05-02 | Rockwell Collins, Inc. | Translator terminal for two or more wireless networks |
US6957346B1 (en) * | 1999-06-15 | 2005-10-18 | Ssh Communications Security Ltd. | Method and arrangement for providing security through network address translations using tunneling and compensations |
JP4292693B2 (en) * | 2000-07-07 | 2009-07-08 | 株式会社日立製作所 | Computer resource dividing apparatus and resource dividing method |
DE50013403D1 (en) * | 2000-08-09 | 2006-10-12 | Tektronix Berlin Gmbh & Co Kg | Apparatus for analyzing digital data |
US7301933B1 (en) * | 2000-12-22 | 2007-11-27 | Cisco Technology, Inc. | Delivery of a service program to a digital signal processor within a multiservice processing system |
US7113520B1 (en) * | 2001-04-11 | 2006-09-26 | Adl Llc | Local protocol server |
US6894979B1 (en) * | 2001-04-24 | 2005-05-17 | Crossroads Systems, Inc. | Network analyzer/sniffer with multiple protocol capabilities |
JP4217386B2 (en) * | 2001-05-15 | 2009-01-28 | 株式会社リコー | FIFO device |
US20030188056A1 (en) * | 2002-03-27 | 2003-10-02 | Suresh Chemudupati | Method and apparatus for packet reformatting |
US7529243B2 (en) | 2002-07-16 | 2009-05-05 | Enterasys Networks, Inc. | Apparatus and method for a virtual hierarchical local area network |
US7441039B2 (en) * | 2003-12-04 | 2008-10-21 | Exar Corporation | Method and apparatus for adapting mac and network processor core to packet format changes and for mapping RPR architecture over spatial reuse architecture |
US7441106B2 (en) * | 2004-07-02 | 2008-10-21 | Seagate Technology Llc | Distributed processing in a multiple processing unit environment |
US9544216B2 (en) * | 2005-02-04 | 2017-01-10 | Hewlett Packard Enterprise Development Lp | Mesh mirroring with path tags |
US8356431B2 (en) * | 2007-04-13 | 2013-01-22 | Hart Communication Foundation | Scheduling communication frames in a wireless network |
US8230108B2 (en) * | 2007-04-13 | 2012-07-24 | Hart Communication Foundation | Routing packets on a network using directed graphs |
US8325627B2 (en) * | 2007-04-13 | 2012-12-04 | Hart Communication Foundation | Adaptive scheduling in a wireless network |
US8676219B2 (en) * | 2007-04-13 | 2014-03-18 | Hart Communication Foundation | Combined wired and wireless communications with field devices in a process control environment |
US8570922B2 (en) * | 2007-04-13 | 2013-10-29 | Hart Communication Foundation | Efficient addressing in wireless hart protocol |
US8213085B2 (en) * | 2008-01-18 | 2012-07-03 | Visera Technologies Company Limited | Image sensor device with high photosensitivity |
US7703202B2 (en) * | 2008-01-18 | 2010-04-27 | Inventec Corporation | Method for manufacturing a transmission line equalizer |
WO2009102354A1 (en) * | 2008-02-13 | 2009-08-20 | Hewlett-Packard Development Company, L.P. | Managing electronic devices using an electronic device as a root of trust |
WO2009102352A1 (en) * | 2008-02-13 | 2009-08-20 | Hewlett-Packard Development Company, L.P. | Providing manageability to an electronic device that supports location limited manageability functionality |
US8441947B2 (en) * | 2008-06-23 | 2013-05-14 | Hart Communication Foundation | Simultaneous data packet processing |
WO2011149558A2 (en) | 2010-05-28 | 2011-12-01 | Abelow Daniel H | Reality alternate |
US8831021B2 (en) | 2011-09-25 | 2014-09-09 | Qualcomm Incorporated | System and method for dynamically configurable multi-window divergent protocol bridge |
EP3237979B1 (en) * | 2014-12-24 | 2021-09-01 | ABB Schweiz AG | An inter-operable remote terminal unit |
CN113722013B (en) * | 2021-09-10 | 2023-07-28 | 中国西安卫星测控中心 | Data exchange method suitable for Beidou No. three satellite measurement, operation and control system |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4025771A (en) * | 1974-03-25 | 1977-05-24 | Hughes Aircraft Company | Pipe line high speed signal processor |
US5253360A (en) * | 1988-12-16 | 1993-10-12 | Kabushiki Kaisha Toshiba | Facsimile device having continuous operating capabilities immediately after recovery from trouble and related method |
US5651002A (en) * | 1995-07-12 | 1997-07-22 | 3Com Corporation | Internetworking device with enhanced packet header translation and memory |
US5787255A (en) * | 1996-04-12 | 1998-07-28 | Cisco Systems, Inc. | Internetworking device with enhanced protocol translation circuit |
US5809552A (en) * | 1992-01-29 | 1998-09-15 | Fujitsu Limited | Data processing system, memory access device and method including selecting the number of pipeline stages based on pipeline conditions |
US5832236A (en) * | 1996-05-20 | 1998-11-03 | Compaq Computer Corporation | High speed frame translation for computer networks |
US6172990B1 (en) * | 1997-06-19 | 2001-01-09 | Xaqti Corporation | Media access control micro-RISC stream processor and method for implementing the same |
US6198751B1 (en) * | 1997-11-19 | 2001-03-06 | Cabletron Systems, Inc. | Multi-protocol packet translator |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5067104A (en) | 1987-05-01 | 1991-11-19 | At&T Bell Laboratories | Programmable protocol engine having context free and context dependent processes |
FR2635243B1 (en) * | 1988-08-05 | 1994-01-14 | Lmt Radio Professionnelle | PACKET SWITCHER FOR ASYNCHRONOUS DATA TRANSFER IN A DIGITAL TRANSMISSION NETWORK |
US5655140A (en) | 1994-07-22 | 1997-08-05 | Network Peripherals | Apparatus for translating frames of data transferred between heterogeneous local area networks |
US5812792A (en) * | 1994-07-22 | 1998-09-22 | Network Peripherals, Inc. | Use of video DRAM for memory storage in a local area network port of a switching hub |
US5717910A (en) * | 1996-03-29 | 1998-02-10 | Integrated Device Technology, Inc. | Operand compare/release apparatus and method for microinstrution sequences in a pipeline processor |
-
1997
- 1997-11-19 US US08/974,632 patent/US6198751B1/en not_active Expired - Lifetime
-
1998
- 1998-11-13 AU AU14060/99A patent/AU729211B2/en not_active Ceased
- 1998-11-13 EP EP98957918A patent/EP1033020B1/en not_active Expired - Lifetime
- 1998-11-13 WO PCT/US1998/024237 patent/WO1999026376A2/en active IP Right Grant
- 1998-11-13 DE DE69810511T patent/DE69810511T2/en not_active Expired - Lifetime
- 1998-11-13 CA CA002310741A patent/CA2310741C/en not_active Expired - Fee Related
-
2000
- 2000-12-05 US US09/730,453 patent/US20010033580A1/en not_active Abandoned
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4025771A (en) * | 1974-03-25 | 1977-05-24 | Hughes Aircraft Company | Pipe line high speed signal processor |
US5253360A (en) * | 1988-12-16 | 1993-10-12 | Kabushiki Kaisha Toshiba | Facsimile device having continuous operating capabilities immediately after recovery from trouble and related method |
US5809552A (en) * | 1992-01-29 | 1998-09-15 | Fujitsu Limited | Data processing system, memory access device and method including selecting the number of pipeline stages based on pipeline conditions |
US5651002A (en) * | 1995-07-12 | 1997-07-22 | 3Com Corporation | Internetworking device with enhanced packet header translation and memory |
US5787255A (en) * | 1996-04-12 | 1998-07-28 | Cisco Systems, Inc. | Internetworking device with enhanced protocol translation circuit |
US5832236A (en) * | 1996-05-20 | 1998-11-03 | Compaq Computer Corporation | High speed frame translation for computer networks |
US6172990B1 (en) * | 1997-06-19 | 2001-01-09 | Xaqti Corporation | Media access control micro-RISC stream processor and method for implementing the same |
US6198751B1 (en) * | 1997-11-19 | 2001-03-06 | Cabletron Systems, Inc. | Multi-protocol packet translator |
Cited By (123)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7818452B2 (en) | 2000-09-13 | 2010-10-19 | Fortinet, Inc. | Distributed virtual system to support managed, network-based services |
US8320279B2 (en) | 2000-09-13 | 2012-11-27 | Fortinet, Inc. | Managing and provisioning virtual routers |
US20080259934A1 (en) * | 2000-09-13 | 2008-10-23 | Fortinet, Inc. | Distributed virtual system to support managed, network-based services |
US7885207B2 (en) | 2000-09-13 | 2011-02-08 | Fortinet, Inc. | Managing and provisioning virtual routers |
US20110032942A1 (en) * | 2000-09-13 | 2011-02-10 | Fortinet, Inc. | Fast path complex flow processing |
US8069233B2 (en) | 2000-09-13 | 2011-11-29 | Fortinet, Inc. | Switch management system and method |
US20090046728A1 (en) * | 2000-09-13 | 2009-02-19 | Fortinet, Inc. | System and method for delivering security services |
US9853948B2 (en) | 2000-09-13 | 2017-12-26 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
US9667604B2 (en) | 2000-09-13 | 2017-05-30 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
US9391964B2 (en) | 2000-09-13 | 2016-07-12 | Fortinet, Inc. | Tunnel interface for securing traffic over a network |
US20100094980A1 (en) * | 2000-09-13 | 2010-04-15 | Fortinet, Inc. | Managing and provisioning virtual routers |
US20110176552A1 (en) * | 2000-09-13 | 2011-07-21 | Fortinet, Inc. | Managing interworking communications protocols |
US7912936B2 (en) | 2000-09-13 | 2011-03-22 | Nara Rajagopalan | Managing interworking communications protocols |
US6765916B1 (en) | 2000-12-30 | 2004-07-20 | Redback Networks Inc. | Method and apparatus for processing of multiple protocols within data transmission signals |
WO2002063831A1 (en) * | 2000-12-30 | 2002-08-15 | Redback Networks Inc. | Method and appatatus for processing of multiple protocols within data transmission signals |
US20030023760A1 (en) * | 2001-03-31 | 2003-01-30 | Mcclary Michael | Method and apparatus for sync hunting signals |
US6959008B2 (en) | 2001-03-31 | 2005-10-25 | Redback Networks Inc. | Alignment of TDM-based signals for packet transmission using framed and unframed operations |
US6950446B2 (en) | 2001-03-31 | 2005-09-27 | Redback Networks Inc. | Method and apparatus for simultaneously sync hunting signals |
US6941381B2 (en) | 2001-03-31 | 2005-09-06 | Redback Networks Inc. | Method and apparatus for sync hunting signals |
US20040073714A1 (en) * | 2001-03-31 | 2004-04-15 | Mcclary Michael | Method and apparatus for deframing signals |
US20030016699A1 (en) * | 2001-03-31 | 2003-01-23 | Mcclary Michael | Alignment of TDM-based signals for packet transmission using framed and unframed operations |
US7593432B2 (en) | 2001-03-31 | 2009-09-22 | Redback Networks Inc. | Method and apparatus for deframing signals |
US20100189016A1 (en) * | 2001-06-28 | 2010-07-29 | Fortinet, Inc. | Identifying nodes in a ring network |
US7890663B2 (en) | 2001-06-28 | 2011-02-15 | Fortinet, Inc. | Identifying nodes in a ring network |
US8208409B2 (en) | 2001-06-28 | 2012-06-26 | Fortinet, Inc. | Identifying nodes in a ring network |
US20030069997A1 (en) * | 2001-08-31 | 2003-04-10 | Philip Bravin | Multi modal communications system |
US7333507B2 (en) * | 2001-08-31 | 2008-02-19 | Philip Bravin | Multi modal communications system |
US7324539B1 (en) | 2001-11-28 | 2008-01-29 | Redback Networks Inc. | Method and apparatus for processing channelized and unchannelized data within a signal |
US7075951B1 (en) | 2001-11-29 | 2006-07-11 | Redback Networks Inc. | Method and apparatus for the operation of a storage unit in a network element |
US7050395B1 (en) | 2001-11-30 | 2006-05-23 | Redback Networks Inc. | Method and apparatus for disabling an interface between network element data processing units |
US20030140157A1 (en) * | 2002-01-22 | 2003-07-24 | Beverly Harlan T. | Removing data from contiguous data flows |
US7308004B1 (en) | 2002-03-06 | 2007-12-11 | Redback Networks, Inc. | Method and apparatus of multiplexing and demultiplexing communication signals |
US7151780B1 (en) * | 2002-03-06 | 2006-12-19 | Cisco Technology, Inc. | Arrangement for automated teller machine communications based on bisync to IP conversion |
US8306040B2 (en) | 2002-06-04 | 2012-11-06 | Fortinet, Inc. | Network packet steering via configurable association of processing resources and network interfaces |
US8848718B2 (en) | 2002-06-04 | 2014-09-30 | Google Inc. | Hierarchical metering in a virtual router-based network switch |
US7720053B2 (en) | 2002-06-04 | 2010-05-18 | Fortinet, Inc. | Service processing switch |
US8064462B2 (en) | 2002-06-04 | 2011-11-22 | Fortinet, Inc. | Service processing switch |
US20070109968A1 (en) * | 2002-06-04 | 2007-05-17 | Fortinet, Inc. | Hierarchical metering in a virtual router-based network switch |
US20070064704A1 (en) * | 2002-06-04 | 2007-03-22 | Fortinet, Inc. | Methods and systems for a distributed provider edge |
US20090238181A1 (en) * | 2002-06-04 | 2009-09-24 | Fortinet, Inc. | Network packet steering via configurable association of processing resources and network interfaces |
US8111690B2 (en) | 2002-06-04 | 2012-02-07 | Google Inc. | Routing traffic through a virtual router-based network switch |
US8085776B2 (en) | 2002-06-04 | 2011-12-27 | Fortinet, Inc. | Methods and systems for a distributed provider edge |
US20090073977A1 (en) * | 2002-06-04 | 2009-03-19 | Fortinet, Inc. | Routing traffic through a virtual router-based network switch |
US8819486B2 (en) | 2002-08-29 | 2014-08-26 | Google Inc. | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
US8412982B2 (en) | 2002-08-29 | 2013-04-02 | Google Inc. | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
US20100011245A1 (en) * | 2002-08-29 | 2010-01-14 | Fortinet, Inc. | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
US7761743B2 (en) | 2002-08-29 | 2010-07-20 | Fortinet, Inc. | Fault tolerant routing in a non-hot-standby configuration of a network routing system |
US20110200044A1 (en) * | 2002-11-18 | 2011-08-18 | Fortinet, Inc. | Hardware-accelerated packet multicasting in a virtual routing system |
US8644311B2 (en) | 2002-11-18 | 2014-02-04 | Fortinet, Inc. | Hardware-accelerated packet multicasting in a virtual routing system |
US7957407B2 (en) * | 2003-08-27 | 2011-06-07 | Fortinet, Inc. | Heterogeneous media packet bridging |
US8503463B2 (en) | 2003-08-27 | 2013-08-06 | Fortinet, Inc. | Heterogeneous media packet bridging |
US9185050B2 (en) | 2003-08-27 | 2015-11-10 | Fortinet, Inc. | Heterogeneous media packet bridging |
US20110235649A1 (en) * | 2003-08-27 | 2011-09-29 | Fortinet, Inc. | Heterogeneous media packet bridging |
US9509638B2 (en) | 2003-08-27 | 2016-11-29 | Fortinet, Inc. | Heterogeneous media packet bridging |
US7720095B2 (en) * | 2003-08-27 | 2010-05-18 | Fortinet, Inc. | Heterogeneous media packet bridging |
US9331961B2 (en) | 2003-08-27 | 2016-05-03 | Fortinet, Inc. | Heterogeneous media packet bridging |
US20100220741A1 (en) * | 2003-08-27 | 2010-09-02 | Fortinet, Inc. | Heterogeneous media packet bridging |
US9853917B2 (en) | 2003-08-27 | 2017-12-26 | Fortinet, Inc. | Heterogeneous media packet bridging |
US20050047407A1 (en) * | 2003-08-27 | 2005-03-03 | Cosine Communications, Inc. | Heterogeneous media packet bridging |
US7873045B2 (en) * | 2003-09-15 | 2011-01-18 | Exar Corporation | Generating an encapsulating header based on encapsulated information provided at protocol-dependent locations |
US20050068948A1 (en) * | 2003-09-15 | 2005-03-31 | Sanjay Bhardwaj | Generating an encapsulating header based on encapsulated information provided at protocol-dependent locations |
US20050078704A1 (en) * | 2003-10-14 | 2005-04-14 | International Business Machines Corporation | Method and apparatus for translating data packets from one network protocol to another |
US7881244B2 (en) | 2004-09-24 | 2011-02-01 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
US8213347B2 (en) | 2004-09-24 | 2012-07-03 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
US20100142527A1 (en) * | 2004-09-24 | 2010-06-10 | Fortinet, Inc. | Scalable IP-Services Enabled Multicast Forwarding with Efficient Resource Utilization |
US8369258B2 (en) | 2004-09-24 | 2013-02-05 | Fortinet, Inc. | Scalable IP-services enabled multicast forwarding with efficient resource utilization |
US20110122872A1 (en) * | 2004-09-24 | 2011-05-26 | Fortinet, Inc. | Scalable ip-services enabled multicast forwarding with efficient resource utilization |
US20090225754A1 (en) * | 2004-09-24 | 2009-09-10 | Fortinet, Inc. | Scalable ip-services enabled multicast forwarding with efficient resource utilization |
US20110235548A1 (en) * | 2004-11-18 | 2011-09-29 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US7961615B2 (en) | 2004-11-18 | 2011-06-14 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US20080320553A1 (en) * | 2004-11-18 | 2008-12-25 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US8107376B2 (en) | 2004-11-18 | 2012-01-31 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US7843813B2 (en) | 2004-11-18 | 2010-11-30 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US7869361B2 (en) | 2004-11-18 | 2011-01-11 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US7876683B2 (en) | 2004-11-18 | 2011-01-25 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US20080317231A1 (en) * | 2004-11-18 | 2008-12-25 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US20080317040A1 (en) * | 2004-11-18 | 2008-12-25 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US20090007228A1 (en) * | 2004-11-18 | 2009-01-01 | Fortinet, Inc. | Managing hierarchically organized subscriber profiles |
US20080008211A1 (en) * | 2006-07-07 | 2008-01-10 | Itai Ephraim Zilbershtein | Inter-network translation |
US20080186052A1 (en) * | 2007-02-01 | 2008-08-07 | International Business Machines Corporation | Methods, systems, and computer program products for using direct memory access to initialize a programmable logic device |
US20120278510A1 (en) * | 2007-02-01 | 2012-11-01 | International Business Machines Corporation | Using direct memory access to initialize a programmable logic device |
US8407658B2 (en) | 2007-02-01 | 2013-03-26 | International Business Machines Corporation | Methods, systems, and computer program products for using direct memory access to initialize a programmable logic device |
US8589834B2 (en) * | 2007-02-01 | 2013-11-19 | International Business Machines Corporation | Using direct memory access to initialize a programmable logic device |
US8495545B2 (en) | 2007-02-01 | 2013-07-23 | International Business Machines Corporation | Using direct memory access to initialize a programmable logic device |
US8427999B2 (en) | 2009-04-17 | 2013-04-23 | Viasat, Inc. | Multi-satellite architecture |
US20100265878A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Mobility across satellite beams using l2 connectivity |
US8457035B2 (en) | 2009-04-17 | 2013-06-04 | Viasat, Inc. | Mobility across satellite beams using L2 connectivity |
US20100265941A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Layer-2 extension services |
US8379613B2 (en) * | 2009-04-17 | 2013-02-19 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US8804730B2 (en) | 2009-04-17 | 2014-08-12 | Viasat, Inc. | Layer-2 extension services |
US8345650B2 (en) | 2009-04-17 | 2013-01-01 | Viasat, Inc. | Access node/gateway to access node/gateway layer-2 connectivity (end-to-end) |
US8279748B2 (en) | 2009-04-17 | 2012-10-02 | Viasat, Inc. | Core-based satellite network architecture |
US11424821B2 (en) | 2009-04-17 | 2022-08-23 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US8948149B2 (en) | 2009-04-17 | 2015-02-03 | Viasat, Inc. | Access node/gateway to access node/gateway layer-2 connectivity (end-to-end) |
US8274981B2 (en) | 2009-04-17 | 2012-09-25 | Viasat, Inc. | Acceleration through a network tunnel |
US11018758B2 (en) | 2009-04-17 | 2021-05-25 | Viasat, Inc. | Mobility across satellite beams using L2 connectivity |
US9264127B2 (en) | 2009-04-17 | 2016-02-16 | Viasat, Inc. | Mobility across satellite beams using L2 connectivity |
US9276663B2 (en) | 2009-04-17 | 2016-03-01 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US20100265879A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Multi-satellite architecture |
US20100265877A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Access node/gateway to access node/gateway layer-2 connectivity (end-to-end) |
US9419702B2 (en) | 2009-04-17 | 2016-08-16 | Viasat, Inc. | Layer-2 extension services |
US9432896B2 (en) | 2009-04-17 | 2016-08-30 | Viasat, Inc. | Mobility across satellite beams using L2 connectivity |
US10965365B2 (en) | 2009-04-17 | 2021-03-30 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US10680704B2 (en) | 2009-04-17 | 2020-06-09 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US10404355B2 (en) | 2009-04-17 | 2019-09-03 | Viasat, Inc. | Mobility across satellite beams using L2 connectivity |
US20100265957A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Core-based satellite network architecture |
US10218432B2 (en) | 2009-04-17 | 2019-02-26 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US9774385B2 (en) | 2009-04-17 | 2017-09-26 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US9800322B2 (en) | 2009-04-17 | 2017-10-24 | Viasat, Inc. | Mobility across satellite beams using L2 connectivity |
US20100265876A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
US20100265950A1 (en) * | 2009-04-17 | 2010-10-21 | Viasat, Inc. | Acceleration through a network tunnel |
US9887766B2 (en) | 2009-04-17 | 2018-02-06 | Viasat, Inc. | Layer-2 extension services |
US20130148583A1 (en) * | 2010-01-13 | 2013-06-13 | Sony Corporation | Method and system for transferring data between wireless devices |
US8855057B2 (en) * | 2010-01-13 | 2014-10-07 | Sony Corporation | Method and system for transferring data between wireless devices |
KR20180088531A (en) * | 2014-05-09 | 2018-08-03 | 구글 엘엘씨 | System and method for adapting to network protocol updates |
JP2017517951A (en) * | 2014-05-09 | 2017-06-29 | グーグル インコーポレイテッド | System and method for adapting to network protocol updates |
CN106256112A (en) * | 2014-05-09 | 2016-12-21 | 谷歌公司 | For adapting to the system and method that procotol updates |
KR102146947B1 (en) | 2014-05-09 | 2020-08-21 | 구글 엘엘씨 | System and method for adapting to network protocol updates |
US9503552B2 (en) | 2014-05-09 | 2016-11-22 | Google Inc. | System and method for adapting to network protocol updates |
WO2015171922A1 (en) * | 2014-05-09 | 2015-11-12 | Google Inc. | System and method for adapting to network protocol updates |
CN113765892A (en) * | 2014-05-09 | 2021-12-07 | 谷歌有限责任公司 | System, method, and computer readable medium for adapting to network protocol updates |
US11711299B2 (en) * | 2020-01-10 | 2023-07-25 | Cisco Technology, Inc. | Traffic mirroring in hybrid network environments |
US11962397B2 (en) | 2022-07-08 | 2024-04-16 | Viasat, Inc. | Layer-2 connectivity from switch to access node/gateway |
Also Published As
Publication number | Publication date |
---|---|
CA2310741A1 (en) | 1999-05-29 |
US6198751B1 (en) | 2001-03-06 |
DE69810511D1 (en) | 2003-02-06 |
CA2310741C (en) | 2004-04-13 |
WO1999026376A2 (en) | 1999-05-27 |
EP1033020A2 (en) | 2000-09-06 |
EP1033020B1 (en) | 2003-01-02 |
DE69810511T2 (en) | 2003-10-02 |
WO1999026376A3 (en) | 1999-11-25 |
AU729211B2 (en) | 2001-01-25 |
AU1406099A (en) | 1999-06-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6198751B1 (en) | Multi-protocol packet translator | |
US7392331B2 (en) | System and method for transmitting data packets in a computer system having a memory hub architecture | |
US5568477A (en) | Multipurpose packet switching node for a data communication network | |
US6731631B1 (en) | System, method and article of manufacture for updating a switching table in a switch fabric chipset system | |
US6804731B1 (en) | System, method and article of manufacture for storing an incoming datagram in switch matrix in a switch fabric chipset system | |
EP0606368B1 (en) | Packet processing method and apparatus | |
US7616562B1 (en) | Systems and methods for handling packet fragmentation | |
US7283528B1 (en) | On the fly header checksum processing using dedicated logic | |
US6963535B2 (en) | MAC bus interface | |
US6052383A (en) | LAN to ATM backbone switch module | |
US7782857B2 (en) | Logical separation and accessing of descriptor memories | |
US20070180310A1 (en) | Multi-core architecture with hardware messaging | |
JPH0795231A (en) | Inter-lan connecting device | |
US7474672B2 (en) | Frame alteration logic for network processors | |
US7596148B2 (en) | Receiving data from virtual channels | |
US6724759B1 (en) | System, method and article of manufacture for transferring a packet from a port controller to a switch fabric in a switch fabric chipset system | |
US5592488A (en) | Method and apparatus for pipelined multiplexing employing analog delays for a multiport interface | |
US7212530B1 (en) | Optimized buffer loading for packet header processing | |
US7239630B1 (en) | Dedicated processing resources for packet header generation | |
KR100264875B1 (en) | High speed cyclical redundancy check system using a programmable architecture | |
US6208645B1 (en) | Time multiplexing of cyclic redundancy functions in point-to-point ringlet-based computer systems | |
JP2003521156A (en) | Apparatus and method for sharing memory using a single ring data bus connection configuration | |
US7158520B1 (en) | Mailbox registers for synchronizing header processing execution | |
US20030046458A1 (en) | Data transfer equipment and aligner included in data transfer equipment | |
JP4588560B2 (en) | Table device and address search device using the same |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |