US20010033580A1 - Multi-protocol packet translator - Google Patents

Multi-protocol packet translator Download PDF

Info

Publication number
US20010033580A1
US20010033580A1 US09730453 US73045300A US2001033580A1 US 20010033580 A1 US20010033580 A1 US 20010033580A1 US 09730453 US09730453 US 09730453 US 73045300 A US73045300 A US 73045300A US 2001033580 A1 US2001033580 A1 US 2001033580A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
memory
packet
pipeline
output
unit
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
Application number
US09730453
Inventor
Paul Dorsey
Kevin Frazier
Peter DeCarolis
Original Assignee
Dorsey Paul C.
Frazier Kevin M.
Decarolis Peter
Priority date (The priority date 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 date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/08Protocols for interworking or protocol conversion

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

    FIELD OF THE INVENTION
  • 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. [0001]
  • DISCUSSION OF THE RELATED ART
  • 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.”[0002]
  • 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. [0003]
  • 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. [0004]
  • 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. [0005]
  • 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. [0006]
  • FIG. 1 illustrates an example of a prior art connection between networks. The first network [0007] 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. According to the prior art, 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.
  • For design of the translator [0008] 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 [0009] 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).
  • SUMMARY OF THE INVENTION
  • 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. [0010]
  • 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. [0011]
  • 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. [0012]
  • 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.[0013]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates a prior art setting for translation of packets between two communication networks; [0014]
  • FIG. 2 illustrates one embodiment of a translator unit according to the present invention; [0015]
  • FIG. 3 illustrates translation from an original packet to a translated packet according to one embodiment of the present invention; [0016]
  • FIG. 4A illustrates one use of a translation unit according to the present invention; [0017]
  • FIG. 4B illustrates a second embodiment using a translator according to the present invention; [0018]
  • FIG. 4C illustrates a third embodiment using a translator unit according to the present invention to translate packets sent among three networks; [0019]
  • FIG. 5 illustrates the circuit for a multi-protocol translator according to one embodiment of the present invention; [0020]
  • FIG. 6 illustrates one embodiment of a pipeline unit for use in the multi-protocol translator of FIG. 5; [0021]
  • FIG. 7A illustrates a packet formatted according to the L[0022] 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; [0023]
  • FIG. 8 illustrates a method of translating a communication packet according to one embodiment of the present invention; [0024]
  • FIG. 9 illustrates another embodiment of a multi-protocol translator according to the present invention, including a double pipeline unit; [0025]
  • FIG. 10 illustrates another embodiment of a multi-protocol translator according to the present invention, including a quad pipeline; [0026]
  • FIG. 11A illustrates one step of translating the packet of FIG. 7A into the packet of FIG. 7B, using the circuit of FIG. 10; [0027]
  • FIG. 11B illustrates the partial results of the translation, after the step shown in FIG. 11A; [0028]
  • 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; [0029]
  • FIG. 12B illustrates the partial results of the translation, after the step illustrated in FIG. 12A is performed; [0030]
  • 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; [0031]
  • 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; [0032]
  • FIG. 14B illustrates the partial results after the step illustrated in FIG. 14A; [0033]
  • 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; [0034]
  • FIG. 15B illustrates the partial results in translating the packet after the step illustrated in FIG. 15A.[0035]
  • DETAILED DESCRIPTION OF THE INVENTION
  • 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. [0036]
  • 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 [0037] 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. [0038]
  • FIG. 2 illustrates a simplex translator [0039] 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 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. 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 at [0040] 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. In the alternative, 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. 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 [0041] 20 a, it is placed into an input memory 21 a. 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.
  • When a packet arrives, the controller [0042] 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. For many types of packets, 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 [0043] 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 packet [0044] 22 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) [0045] 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 [0046] 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.
  • FIG. 3 illustrates the translation process from one packet ([0047] 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. As shown, 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 [0048] 32 to the new 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 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.
  • The embodiment of FIG. 2 provides for unidirectional translation. That is, packets are only received (and not transmitted) on network interface [0049] 20 a, translated by the translator 28, and transmitted (and no packets received) from network interface 20 b. To apply 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).
  • 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 [0050] 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.
  • Another possibility is to use input memory [0051] 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. In this case, 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. Thus, packets sent from a first network [0052] 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 [0053] 46, as described above, to send packets both from the first network 41 to the second 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 [0054] 47 with additional networks. In this embodiment, 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. Of course, similar designs using any number of networks could be implemented.
  • Referring again to FIG. 2, the multi-protocol translator [0055] 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 [0056] 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 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. Thus, in FIG. 5, 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.
  • In the embodiment of FIG. 5, an address control unit [0057] 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 [0058] 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 [0059] 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 [0060] 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. Of course, mechanisms other than multiplexers could be used to perform the same function.
  • The output memory [0061] 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 [0062] 59 is also microcoded. Accordingly, 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. 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 the opcode memory 51 a).
  • At the beginning of the translation process, the controller [0063] 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 [0064] 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. In addition, 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 [0065] 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. For example, the time required to read from the input memory [0066] 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. 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 [0067] 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.
  • When data is to be written from one of the FIFO memories [0068] 54 and 55, the applicable opcode instruction is ignored in the first stage of the pipeline, and the appropriate command is issued in the second stage of the pipeline in the pipeline unit 52 (due to the shorter read latency). When the command reaches the last stage of the pipeline, the controller 50 causes the multiplexer 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 [0069] 52.
  • FIG. 6 illustrates a simple circuit design for the pipeline unit [0070] 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 [0071] 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: [0072]
    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). [0073]
  • 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 [0074] 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. Finally, at the end of the packet, is the data or payload 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 [0075] 70 of 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. Finally, 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). At a step [0076] 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 [0077] 89 illustrates the normal processing of a packet using one embodiment of a multi-protocol translator according to the present invention. At a step 82, the translator waits to receive a packet. Once a packet is received, processing begins at a step 83.
  • At step [0078] 83, the packet is loaded into the input memory 53 a of the translator.
  • At a step [0079] 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 a step 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 ([0080] 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. [0081]
  • The header translation is performed as illustrated at steps [0082] 86 a-86 d.
  • At step [0083] 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.
  • At step [0084] 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 the pipeline unit 52 to the output 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 the pipeline 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 the pipeline 52.
  • At a step [0085] 86 c, 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. In this particular embodiment, 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. 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.
  • Finally, at a step [0086] 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, 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. When 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).
  • When steps [0087] 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.
  • As might be appreciated from the disclosure provided above, the multiplexer [0088] 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.
  • 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. [0089]
  • 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 [0090] 90 b, which is controlled by an address 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 [0091] 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.
  • Like the input memory [0092] 90 b and the information memory 91 b, the output 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 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. Similarly, 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 [0093] 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 [0094] 93 a includes a multiplexer 96 a and a register 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) 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 [0095] 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, however, 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.
  • In this embodiment, the double pipeline unit [0096] 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. Thus, 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: [0097]
    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 [0098] 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).
  • 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. [0099]
  • 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 [0100] 105.
  • Like the earlier embodiments, this embodiment has an input memory [0101] 100 b for storing the original frame to be translated. The input memory 100 b is controlled by an address control unit 100 a. Similarly, 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. Unlike the earlier embodiments, however, 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 [0102] 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 [0103] 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 [0104] 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 [0105] 109 controls the timing and application of data being written to the output memory 105. Like the earlier embodiments, this embodiment has an opcode memory 106 b, controlled by an address 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 the opcode 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 [0106] 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 [0107] 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. [0108]
    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. [0109]
  • 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. [0110]
  • 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 [0111] 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 the output 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 the output memory 105. Accordingly, 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” (write immediate) 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.
  • In the second to the last stage of the pipeline [0112] 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 the output memory 105 until reaching the last stage of the pipeline 107. Instructions 111 a and 111 b, however, cause information to be read from information memory 101 b. Due to the latency of the memory 101 b, 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 [0113] 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. At this point, the last stage [0114] 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. As shown within the box illustrating information memory 101 b, 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. Thus, the illustrated connection transfers the Ether-type bytes to the output memory 105.
  • FIG. 12B illustrates the packet as stored in the output memory [0115] 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. At this point, the two most significant bytes for the ElanID field are stored in a four byte word in the information memory [0116] 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.
  • At the step illustrated in FIG. 13A, the other two pipelines hold two instructions that require reading of information from the input memory [0117] 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). By changing the address of the input 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 the input memory 100 b is longer than the read latency of the information memory 101 b. When instructions involving reading of the input memory 100 b reach the first stage 110 of the pipeline unit (at 131 a and 131 b), the control unit (not shown) 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. At this step, the remainder of the ElanID field is present at bytes 0 and 1 of the information memory [0118] 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. At the same time, 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. Thus, by storing the first two bytes of the ElanID field and the storage alignment units, 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 [0119] 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 [0120] 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.
  • 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 [0121] 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. [0122]
  • 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.[0123]

Claims (21)

    What is claimed is:
  1. 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. 2. The translator unit of
    claim 1
    , 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.
  3. 3. The translator unit of
    claim 1
    , wherein the microcoded control unit includes a pipeline unit.
  4. 4. The translator unit of
    claim 1
    , wherein the microcoded control unit includes two pipeline units.
  5. 5. The translator unit of
    claim 4
    , wherein:
    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. 6. The translator unit of
    claim 1
    , wherein the microcoded control unit includes four pipeline units.
  7. 7. The translator unit of
    claim 6
    , wherein:
    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. 8. The translator unit of
    claim 1
    , further comprising a direct memory access controller coupled to the input memory and the output memory.
  9. 9. The translator unit of
    claim 1
    , wherein the microcoded control unit includes an opcode memory programmed to perform multiple different protocol translations.
  10. 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. 11. The pipelined control unit of
    claim 10
    , further comprising a microcontroller coupled to the circuit.
  12. 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. 13. The method of
    claim 12
    , wherein the translating step includes a step of feeding the microcode instructions through a pipeline.
  14. 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. 15. The method of
    claim 14
    , wherein the loading step comprises a step of loading microcoded instructions.
  16. 16. The method of
    claim 14
    , wherein the connecting step comprises a step of feeding the instructions through a pipeline unit.
  17. 17. The method of
    claim 16
    , wherein:
    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. 18. The method of
    claim 17
    , 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.
  19. 19. The method of
    claim 14
    , 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.
  20. 20. The method of
    claim 14
    , wherein:
    the connecting step includes a step of connecting a plurality of data channels to the output memory.
  21. 21. The method of
    claim 20
    , 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.
US09730453 1997-11-19 2000-12-05 Multi-protocol packet translator Abandoned US20010033580A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US08974632 US6198751B1 (en) 1997-11-19 1997-11-19 Multi-protocol packet translator
US09730453 US20010033580A1 (en) 1997-11-19 2000-12-05 Multi-protocol packet translator

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09730453 US20010033580A1 (en) 1997-11-19 2000-12-05 Multi-protocol packet translator

Publications (1)

Publication Number Publication Date
US20010033580A1 true true US20010033580A1 (en) 2001-10-25

Family

ID=25522278

Family Applications (2)

Application Number Title Priority Date Filing Date
US08974632 Expired - Lifetime US6198751B1 (en) 1997-11-19 1997-11-19 Multi-protocol packet translator
US09730453 Abandoned US20010033580A1 (en) 1997-11-19 2000-12-05 Multi-protocol packet translator

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US08974632 Expired - Lifetime US6198751B1 (en) 1997-11-19 1997-11-19 Multi-protocol packet translator

Country Status (5)

Country Link
US (2) US6198751B1 (en)
EP (1) EP1033020B1 (en)
CA (1) CA2310741C (en)
DE (2) DE69810511T2 (en)
WO (1) WO1999026376A3 (en)

Cited By (43)

* Cited by examiner, † Cited by third party
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
US20080317231A1 (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
US20100265876A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Layer-2 connectivity from switch to access node/gateway
US20100265878A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Mobility across satellite beams using l2 connectivity
US20100265941A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Layer-2 extension services
US20100265877A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Access node/gateway to access node/gateway layer-2 connectivity (end-to-end)
US20100265957A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Core-based satellite network architecture
US20100265950A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Acceleration through a network tunnel
US20100265879A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Multi-satellite architecture
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

Families Citing this family (39)

* Cited by examiner, † Cited by third party
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
CN1166247C (en) 1998-06-19 2004-09-08 杜松网络公司 Communi cation internet and method for transmitting signal therein
US6980543B1 (en) * 1998-06-19 2005-12-27 Juniper Networks, Inc. Interconnect network for operation within a communication node
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
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
US6724767B1 (en) 1998-06-27 2004-04-20 Intel Corporation Two-dimensional queuing/de-queuing methods and systems for implementing the same
US6657959B1 (en) 1998-06-27 2003-12-02 Intel Corporation Systems and methods for implementing ABR with guaranteed MCR
US6879588B1 (en) * 1999-05-21 2005-04-12 Broadcom Corporation Address resolution snoop support for CPU
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
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 partitioning apparatus and resource partitioning method
EP1179916B1 (en) * 2000-08-09 2006-08-30 Tektronix Berlin GmbH & Co. KG Apparatus for analysing 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 equipment
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
US8325627B2 (en) * 2007-04-13 2012-12-04 Hart Communication Foundation Adaptive scheduling in a wireless network
US8356431B2 (en) * 2007-04-13 2013-01-22 Hart Communication Foundation Scheduling communication frames in a wireless network
US8570922B2 (en) * 2007-04-13 2013-10-29 Hart Communication Foundation Efficient addressing in wireless hart protocol
US8230108B2 (en) * 2007-04-13 2012-07-24 Hart Communication Foundation Routing packets on a network using directed graphs
US8660108B2 (en) * 2007-04-13 2014-02-25 Hart Communication Foundation Synchronizing timeslots in a wireless communication protocol
US7703202B2 (en) * 2008-01-18 2010-04-27 Inventec Corporation Method for manufacturing a transmission line equalizer
US8213085B2 (en) * 2008-01-18 2012-07-03 Visera Technologies Company Limited Image sensor device with high photosensitivity
US20100325625A1 (en) * 2008-02-13 2010-12-23 Osvaldo Diaz Managing electronic devices with different types of device location limited device management clients
US8479262B2 (en) * 2008-02-13 2013-07-02 Hewlett-Packard Development Company, L.P. Managing electronic devices using an electronic device as a root of trust
US8441947B2 (en) * 2008-06-23 2013-05-14 Hart Communication Foundation Simultaneous data packet processing
US9183560B2 (en) 2010-05-28 2015-11-10 Daniel H. Abelow Reality alternate
US8831021B2 (en) 2011-09-25 2014-09-09 Qualcomm Incorporated System and method for dynamically configurable multi-window divergent protocol bridge

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6172990B2 (en) *
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)

* Cited by examiner, † Cited by third party
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 switch for data transfer in asynchronous mode 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

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6172990B2 (en) *
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 (111)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100094980A1 (en) * 2000-09-13 2010-04-15 Fortinet, Inc. Managing and provisioning virtual routers
US9853948B2 (en) 2000-09-13 2017-12-26 Fortinet, Inc. Tunnel interface for securing traffic over a network
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
US9667604B2 (en) 2000-09-13 2017-05-30 Fortinet, Inc. Tunnel interface for securing traffic over a network
US8069233B2 (en) 2000-09-13 2011-11-29 Fortinet, Inc. Switch management system and method
US20110176552A1 (en) * 2000-09-13 2011-07-21 Fortinet, Inc. Managing interworking communications protocols
US20110032942A1 (en) * 2000-09-13 2011-02-10 Fortinet, Inc. Fast path complex flow processing
US7818452B2 (en) 2000-09-13 2010-10-19 Fortinet, Inc. Distributed virtual system to support managed, network-based services
US9391964B2 (en) 2000-09-13 2016-07-12 Fortinet, Inc. Tunnel interface for securing traffic over a network
US7912936B2 (en) 2000-09-13 2011-03-22 Nara Rajagopalan Managing interworking communications protocols
US20090046728A1 (en) * 2000-09-13 2009-02-19 Fortinet, Inc. System and method for delivering security services
US8320279B2 (en) 2000-09-13 2012-11-27 Fortinet, Inc. Managing and provisioning virtual routers
WO2002063831A1 (en) * 2000-12-30 2002-08-15 Redback Networks Inc. Method and appatatus for processing of multiple protocols within data transmission signals
US6765916B1 (en) 2000-12-30 2004-07-20 Redback Networks Inc. Method and apparatus for processing of multiple protocols within data transmission 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
US7593432B2 (en) 2001-03-31 2009-09-22 Redback Networks Inc. Method and apparatus for deframing signals
US20040073714A1 (en) * 2001-03-31 2004-04-15 Mcclary Michael Method and apparatus for deframing signals
US20030023760A1 (en) * 2001-03-31 2003-01-30 Mcclary Michael Method and apparatus for sync hunting signals
US20030016699A1 (en) * 2001-03-31 2003-01-23 Mcclary Michael 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
US8208409B2 (en) 2001-06-28 2012-06-26 Fortinet, Inc. Identifying nodes in a ring network
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
US7333507B2 (en) * 2001-08-31 2008-02-19 Philip Bravin Multi modal communications system
US20030069997A1 (en) * 2001-08-31 2003-04-10 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
US7151780B1 (en) * 2002-03-06 2006-12-19 Cisco Technology, Inc. Arrangement for automated teller machine communications based on bisync to IP conversion
US7308004B1 (en) 2002-03-06 2007-12-11 Redback Networks, Inc. Method and apparatus of multiplexing and demultiplexing communication signals
US20070064704A1 (en) * 2002-06-04 2007-03-22 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
US7720053B2 (en) 2002-06-04 2010-05-18 Fortinet, Inc. Service processing switch
US8848718B2 (en) 2002-06-04 2014-09-30 Google Inc. Hierarchical metering in a virtual router-based network switch
US8064462B2 (en) 2002-06-04 2011-11-22 Fortinet, Inc. Service processing switch
US8085776B2 (en) 2002-06-04 2011-12-27 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
US20090238181A1 (en) * 2002-06-04 2009-09-24 Fortinet, Inc. Network packet steering via configurable association of processing resources and network interfaces
US8306040B2 (en) 2002-06-04 2012-11-06 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
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
US8819486B2 (en) 2002-08-29 2014-08-26 Google 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
US9331961B2 (en) 2003-08-27 2016-05-03 Fortinet, Inc. Heterogeneous media packet bridging
US20050047407A1 (en) * 2003-08-27 2005-03-03 Cosine Communications, Inc. Heterogeneous media packet bridging
US9853917B2 (en) 2003-08-27 2017-12-26 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
US20100220741A1 (en) * 2003-08-27 2010-09-02 Fortinet, Inc. Heterogeneous media packet bridging
US8503463B2 (en) 2003-08-27 2013-08-06 Fortinet, Inc. Heterogeneous media packet bridging
US7720095B2 (en) * 2003-08-27 2010-05-18 Fortinet, Inc. Heterogeneous media packet bridging
US9185050B2 (en) 2003-08-27 2015-11-10 Fortinet, 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
US7873045B2 (en) * 2003-09-15 2011-01-18 Exar Corporation 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
US20090225754A1 (en) * 2004-09-24 2009-09-10 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
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
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
US20080317040A1 (en) * 2004-11-18 2008-12-25 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US7876683B2 (en) 2004-11-18 2011-01-25 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20080320553A1 (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
US20110235548A1 (en) * 2004-11-18 2011-09-29 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US7869361B2 (en) 2004-11-18 2011-01-11 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US7961615B2 (en) 2004-11-18 2011-06-14 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US7843813B2 (en) 2004-11-18 2010-11-30 Fortinet, Inc. Managing hierarchically organized subscriber profiles
US20080317231A1 (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
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
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
US20120278510A1 (en) * 2007-02-01 2012-11-01 International Business Machines Corporation 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
US8345650B2 (en) 2009-04-17 2013-01-01 Viasat, Inc. Access node/gateway to access node/gateway layer-2 connectivity (end-to-end)
US8457035B2 (en) 2009-04-17 2013-06-04 Viasat, Inc. Mobility across satellite beams using L2 connectivity
US8279748B2 (en) 2009-04-17 2012-10-02 Viasat, Inc. Core-based satellite network architecture
US8427999B2 (en) 2009-04-17 2013-04-23 Viasat, Inc. Multi-satellite architecture
US8274981B2 (en) 2009-04-17 2012-09-25 Viasat, Inc. Acceleration through a network tunnel
US8804730B2 (en) 2009-04-17 2014-08-12 Viasat, Inc. Layer-2 extension services
US20100265876A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Layer-2 connectivity from switch to access node/gateway
US20100265879A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Multi-satellite architecture
US8379613B2 (en) * 2009-04-17 2013-02-19 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)
US20100265941A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Layer-2 extension services
US9800322B2 (en) 2009-04-17 2017-10-24 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
US20100265957A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Core-based satellite network 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
US9774385B2 (en) 2009-04-17 2017-09-26 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
US20100265878A1 (en) * 2009-04-17 2010-10-21 Viasat, Inc. Mobility across satellite beams using l2 connectivity
US9887766B2 (en) 2009-04-17 2018-02-06 Viasat, Inc. Layer-2 extension services
US8855057B2 (en) * 2010-01-13 2014-10-07 Sony Corporation Method and system for transferring data between wireless devices
US20130148583A1 (en) * 2010-01-13 2013-06-13 Sony Corporation Method and system for transferring data between wireless devices
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
JP2017517951A (en) * 2014-05-09 2017-06-29 グーグル インコーポレイテッド System and method for adapting to the network protocol update

Also Published As

Publication number Publication date Type
DE69810511D1 (en) 2003-02-06 grant
US6198751B1 (en) 2001-03-06 grant
CA2310741C (en) 2004-04-13 grant
EP1033020B1 (en) 2003-01-02 grant
EP1033020A2 (en) 2000-09-06 application
WO1999026376A2 (en) 1999-05-27 application
CA2310741A1 (en) 1999-05-29 application
DE69810511T2 (en) 2003-10-02 grant
WO1999026376A3 (en) 1999-11-25 application

Similar Documents

Publication Publication Date Title
US6546464B2 (en) Method and apparatus for increasing data rates in a data network while maintaining system coherency
US5838684A (en) Low latency, high clock frequency plesioasynchronous packet-based crossbar switching chip system and method
US7401126B2 (en) Transaction switch and network interface adapter incorporating same
US5872919A (en) Computer communication network having a packet processor with an execution unit which is variably configured from a programmable state machine and logic
US6631484B1 (en) System for packet communication where received packet is stored either in a FIFO or in buffer storage based on size of received packet
US5898688A (en) ATM switch with integrated system bus
US6697362B1 (en) Distributed switch memory architecture
US20030067934A1 (en) Multiprotocol decapsulation/encapsulation control structure and packet protocol conversion method
US8270401B1 (en) Packet routing and switching device
US20040190538A1 (en) Speculative transmit for system area network latency reduction
US5943481A (en) Computer communication network having a packet processor with subsystems that are variably configured for flexible protocol handling
US6212597B1 (en) Apparatus for and method of architecturally enhancing the performance of a multi-port internally cached (AMPIC) DRAM array and like
US5793953A (en) Method and apparatus for allowing packet data to be separated over multiple bus targets
US20100106917A1 (en) Method and system for improving serial port memory communication latency and reliability
US6226292B1 (en) Frame replication in a network switch for multi-port frame forwarding
US4991172A (en) Design of a high speed packet switching node
US5274631A (en) Computer network switching system
US6615282B1 (en) Adaptive messaging
US6105079A (en) Apparatus and method in a network interface device for selectively supplying long bit information related to a data frame to a buffer memory and a read controller for initiation of data transfers
US20050044304A1 (en) Method and system for capturing and bypassing memory transactions in a hub-based memory system
US20050232303A1 (en) Efficient packet processing pipeline device and method
US5949799A (en) Minimum-latency data mover with auto-segmentation and reassembly
US6147996A (en) Pipelined multiple issue packet switch
US20030193927A1 (en) Random access memory architecture and serial interface with continuous packet handling capability
US20040151170A1 (en) Management of received data within host device using linked lists