JP2003524934A - Automatic detection switch system and method for multimedia applications - Google Patents

Abstract

(57) [Summary] The present invention relates to a process and an apparatus for automatically providing an appropriate quality service to a multimedia streaming application in a data communication switch. The switch examines and interprets the multimedia setup messages that determine the characteristics of subsequent audio and visual streams and automatically sets up flow table entries that give these streams the appropriate priority.

Description

Detailed Description of the Invention

[0001]

TECHNICAL FIELD OF THE INVENTION

The present invention is generally directed to switching computer networks, particularly local area networks (LANs), such as those supported by communication protocols Ethernet® protocols and wide area networks (WANs), and asynchronous transfer mode (ATMs) protocols. It concerns the possible connections.

[0002]

[Prior Art and Problems to be Solved by the Invention]

(Description of Related Applications) This application is US Patent Application No. 09 / 285,617 "Application-Level Data Communicati
on Switching System and Quality of Service Adjustment for Multimedia Str
The basic application is "eaming Applications" and the priority is claimed.

The present application is directed to US patent application Ser. No. 09 / 058,448 filed April 10, 1998 “Syst
em and Process for Application-Level Flow Connection of Data Processing
Networks "and US patent application Ser. No. 09 / 060,575 filed April 15, 1998"
System and Process for Flexible Queuing of Data Packets in Network Switc
It is a partial continuation application of "hing".

This application is co-authored on the same day by Burley Spinney and Krishna Narayana Swami.
US patent application `` Application-Level Data Communi '' delegated to mmon entity
cation Switching System and Process for Automatic Detection of and Quali
ty of Service Adjustment for Bulk Data Transfers ".

The present application is US patent application Ser. No. 09 / 058,629 filed April 10, 1998 “High-speed data bus for network switching” and US patent application Ser. No. 09 / 058,597 filed April 10, 1998 “ It is also related to "System and Switching of Data Packets". (Background of the Invention) A problem of existing data communication switching is that it is impossible to distinguish different types of data flows. Therefore, switching or knotting may lead to congestion due to data traffic of low priority email or file transfer. The congestion caused by this switching needs to be in more real time, and
It may disrupt traffic for video and audio streaming, which has become more important due to developments such as Internet telephony and video conferencing.

One of the major problems in network connectivity is that the different network protocols used to communicate between different data process systems in a particular network make communication between such networks difficult. Is what you are doing. The other major problem is that many network protocols require considerable parameter configuration when adding computer systems or nodes, which is typically a mistake even if you are a network expert. Therefore, this is the case where the device address is manually input.
This problem is exacerbated when connecting across network boundaries.

[0007]

[Means for Solving the Problems]

The present invention is a method for flexible connection of a receiving physical path and a transmitting physical path for a flow of data packets, which method comprises: That is, (a) whether the data packet of the reception physical path is received, and (b) whether the data packet is part of a setup sequence associated with a class of multimedia stream data and is identified as a predetermined flow. And, if so, applying the quality of service sequence of the transmission of the packet identified as the class of the multimedia stream data, and (c) according to the quality of the applied service sequence, Send a data packet that is part of the particular flow.

[0008]

DETAILED DESCRIPTION OF THE INVENTION

  This specification is organized as follows.

1. BlazePath ™ / BlazeFire ™ architecture / chip set 1. 2. "Canonicalization" of the header and "canonicalization" of the packet. BlazeWire ™ high-speed MAC bus 4. Data flow in 5. Queue pointer management and operations 6. Reli Engine Operation / Flow Matching (FastPath ™) 7. Transmission scheduling 8. Download / Send to Interface Credit Loop 9. Ultra-high speed RAMBUS (registered trademark) operation 10. Background engine / initialization / monitoring 11. Scheduling of multimedia data flows 1. BlazePath (TM) / BlazeFire (TM) Architecture / Chipset The architecture of the present invention is called BlazePath (TM) and is an application layer flow switch or application header for packets that characterize membership in a particular flow. A connection made by virtually allocating (by a pointer to a high speed data buffer) an incoming data packet to one or more of a number of virtual queues according to a decision made based on In order to improve system throughput or bandwidth, the preferred embodiment, AppSwitch ™ Application Flow Switch, determines the flow's initial packet to match the hashed version of the header of the information, Identifies the packet after. By "canonicalizing" the header information of the incoming flow and splitting the long frame into smaller internal cells (but keeping them logically connected), the system uses independent cells of the frame. "become.

Referring to FIG. 1, in the preferred embodiment, the architecture is Blaz.
BlazeFire connected by eWire ™ MAC bus 60
(Trademark) chip set. Architecture is 100M
It is centered around a 287k gate Queue Manager (“QM”) ASIC 30 operating at Hz. This queue manager places a 16,000,000 queue of pointers (24 bit definition) at the location of the high speed data buffers 35 and 36 connected to the QM 30 where incoming packets are temporarily stored. Implement a queue-pointer scheme that allows placement. The queue is 410k
Gate Reli Engine ("RE") or Transfer Engine ("FE") AS running at 100 MHz, including Argonaut RISC (ARC) Central Processing Unit 387 and FIFO 305 for inspected packet headers.
Loaded based on the decisions made by IC 40. Inputs to and outputs from the system are 350k gate, 60MHz MOM (MTI (Media Independent Interface) Octal MAC) ASICs 10 and 20, daisy-chained on the BlazWire ™ MAC bus 60. Carried out using. The MOM chips 10 and 20 each have two quad physical link chips for local area Ethernet (71 and 72 and 70 and 73 respectively) or T1 and POTS ("normal conventional telephone service").
Can serve as an interface to a distributed access device (DAD) WAN processor 66 or a background engine (“BE”) 50 servicing the WAN line 69 of the.

FIG. 2 illustrates a MOM chip 10, such as M, used in a preferred embodiment of the present invention.
It is a block diagram of an OM chip. In general, the figure shows an MII interface 65 that provides eight dual Ethernet ports. The receive interface 11 and parser 12 receive the data packet, rewrite the frame header as a canonical header as described in Section 2 below, and divide the resulting packet into 128 byte cells. This cell is a round of 8 ports
Producer 13 and FIFO Arbiter 1 in Robin Arbitration
4 is placed in the FIFO 15. Data cells that do not carry a canonical header (packet cells following the first cell of the packet) have a burst header added by burst logic 17 for internal tagging of the data.
RX credit manager 19 adds transmit credits (discussed in section 8 below) to the header as appropriate to notify QM 30 that transmit FIFO 24 can receive more data to be transmitted. . The token arbiter 18 sends the data to the MAC bus TX cell 76, which
Determine when to send to QM 30 on C-bus 60.

Still referring to FIG. 2, incoming data cells on the MAC bus 60 are directed to the transmit consumer 26 by the circuit identifier of the canonical / burst header. The data packet header is sent by the sending consumer 26 and the interface 2
Rebuilt and sent by 7, TX Credit / Manager 28 is updated with credit information and returned to QM 30.

FIG. 3 is a block diagram of the QM 30 used in the preferred embodiment of the present invention. In essence, the QM 30 quickly performs the placement of data cells on the appropriate queues (virtually implemented by a linked list of pointers linked to the data buffer) and queues supported by the RE 40. A collection of gates and state machines designed to apply policies. QM 30 is divided into three clock regimes. The interface between the MAC bus 60 through the digital delay lock loop 302 that supplies the receive data FIFO 306 and the receive command FIFO 312 and the receive interface 304, and the digital delay lock loop 301 that discharges the transmit data FIFO 305 and the send interface 303 is
It is on the C bus clock. The received data cells are, as discussed below,
ERAM3 through direct dual RAMBUS access cell 308
Channeled 5 and 36. The DRAM interface 307 operating on the DRAM clock includes the MAC bus FIFOs 305 and 306 as well as the header out FIFO 309 (RE4 on the header data interface 74).
0 (not shown), including canonical header cells), header-in FIFO 310 (including canonical headers rewritten at the Reli engine data interface with appropriate routing information), and DRAM.
Coordinate operation of command FIFO 311. DRAM command FIF
O311 contains the RE determination implemented by the QM logic shown in the functional network under the SRAM clock domain. Reception engine 315, transmission engine 3
16, and the header prefetch engine 234 sends the data to the DRAM 35.
Directs the function of DRAM arbiter 314 to provide instructions to and from DRAM interface 307. Also, the reception engine 315
The transmit engine 316 coordinates with the free buffer manager 318 to allocate the buffers of DRAMs 35 and 36 for incoming data. Enqueue
Manager 319 and dequeue manager 312 coordinate with the header prefetch engine and receive queue state (receive queue pointer head and tail, as discussed in Section 5 below) 320, especially for pattern matching. , Decides when to send a cell containing canonical header data to the RE 40 and retrieve the corresponding packet from the received queue. header·
The prefetch engine 314 coordinates with the reli engine context 326, the instruction dispatch manager 327 that receives instructions from the RE via the interface 75, the reli engine instruction interface 329, and the reli engine instruction FIFO 328. The circuit poller 317 polls the transmission engine 316 for each circuit to transmit cells, and the SRAM interface 323.
Through an SRAM arbiter 322 that accesses a linked list of buffer pointers (“descriptors”) in SRAM 32 and keeps track of the constituent cells of a packet as it is received and transmitted on one or more queues. Appropriate fields
These operations, where the mappings are hard-wired, provide for a high degree of scheduling and routing flexibility, which is very fast.

FIG. 4 is a block diagram of the RE 40. The main function of the RE 40 examines the canonicalized packet header received at the interface 74 from the QM 30 and determines if the packet belongs to a known flow and accordingly issues an instruction on the interface 75 for proper scheduling. Quickly decide whether to provide (quality of service). CPU core 387 (implemented in an ARC processor) includes instruction cache 386 and data cache 385, and DRAM
Code and data DRAM via interface 384 (also receiving instructions from BE 50 via slow bus 62 and DMA 383 at initialization)
42. A string compare coprocessor 389 is used to assist in pattern recognition used to match packets and flows. Generally, the canonicalized packet header entering the RE 40 is data FI by MUSIn 394.
Pre-processed by hash preprocessor 399 in parallel with MUXing into FO394. The results of the parallel hashing are placed in the hash FIFO 393 and compared by the hash search engine 392 with the contents of the onboard L1 cache of the hash table 391 (for known hashes of header information associated with particular flow characteristics). . If no match is found in the L1 cache 391, the hash search engine 329 will consult the entire hash table of the search SRAM 45 accessed via the SRAM interface and arbiter 388. The tri-search coprocessor 390 is used to find appropriate flow parameters in situations where rapid pattern matching is not appropriate or has failed (discussed below). Depending on the determined flow parameters, CP
U387 issues an appropriate instruction to the instruction FIFO 395, and the data FIFO
QM across interface 75 from O394 to MUX Out 397
Any data provided in 30 is processed by the instruction push 396 multiplexed.

FIG. 5 shows a general schematic diagram of the operation of the preferred embodiment of the present invention in terms of queue management. The data on the MOM receive port 15 'is directed into the QM main receive FIFO 330. Also, data is enqueued from WAN (T1 and POTS) port receive queues 69 'processed under protocol 66' and DAD management 66 'into DAD Ethernet transmit queue 348' and appears on MOM receive port 348. To do. The data cells of the receive FIFO 330 are located in the main system packet memory DRAMs 35 and 36, while
The canonical header is transferred to QM 30 in FIFO 394. Here, FastPath ™ processing is applied to per flow, per priority, and each port queue 332 (static priority as discussed below) and 33.
Appropriate queuing of packets per 3 (as discussed below, weighted Robin priority), MOM transmit port 24 '(or even T
1 and POTS port transmit queue 69 "for distribution to circuit queue 350.
It is possible to send to the DAD 66) distributed above. Fine tuning of scheduling can be achieved using quality of service scheduling process 336 for per-flow queuing with queue 335 scheduled as an "intermediate" queue. Management queue 337 also comprises a management operations process 338 running on the weighted round robin queue 333. Also, a monitor queue 334 is provided to the network that monitors the information transmitted on the MII 24 '. On the BE50 side, M
The data placed on the OM port transmission queue 339 is MII (100 Mbit).
On the Ethernet link 54) into the BE receive queue 341. The background engine main transfer process 342 sends information to the BE send low priority queue 346 or the management queue 3 served by the management operations process 344.
43, and develops data (serving commands) and sends BE high priority queue 345
Place it on top. Both BE transmit queues are drained into MOM port receive queue 347 and placed on QM receive queue 330 via link 64.

FIG. 6 is a generalized flow diagram for the process of the present invention. It should be appreciated that the process takes place simultaneously along various points of the figure for different cells.
Since the preferred embodiment of the invention often splits incoming long Ethernet frames into cells for later reassembly, it is important in this embodiment to characterize the cells with respect to the original packet. Is. The received cell is
It can be "start of packet"("SOP"),"middle of packet"("MOP"),"end of packet"("EOP"), or "start and end of packet" ( It is possible to include one packet as "SEP"). Packet reception and transmission in the preferred embodiment is performed per circuit,
Circuits are defined as local connections that maintain packet ordering, but cells of packets on one circuit can be interleaved with cells of packets on another circuit, such as on the MAC bus. , Cells received on the same circuit must be transmitted in the same order. Thus, in FIG. 6A, as time progresses from top to bottom, SOP 371 is received from circuit 2 in the order they appear on the MAC bus, then SEP 372 from circuit 1, SOP 373 from circuit 3, MOP 374 from circuit 2, EOP 376 from circuit 3, SOP 375 from circuit 1, EOP 37
7 is received from the circuit 3.

Referring to the generalized process shown in FIG. 6, at operation 351 the packet is received at the MII and at operation 352 the MO also adds a canonical header (and possibly a burst header).
It is divided into cells by M10 or 20 (see FIG. 1). The cells of the MOM transmit buffer are arbitrated on the MAC bus in operation 353 and stored in DRAM for later transmission in operation 354, which is also
Including the development of procedures for associating cells with the original packet, such as the linked list of virtual packets used in the preferred embodiment of the present invention. If the cell is a SOP, then a decision 355 is made to send the cell to the pattern matching procedure and the cell is hashed 356 against the known hash result associated with the previously identified flow.
, Then matched 357. If no match exists (possibly after some match steps), a new flow or exception is specified 358. In either case, the appropriate header is written to properly schedule and route the packet. In the preferred embodiment, scheduling is done by assigning packets to queues associated with a specified quality of service and a particular circuit. Cells on the queue are sent 360 at the appropriate time, and the process probably involves rewriting the header. If the cell sent was an EOP, the packet is dequeued from the circuit 361 and the data buffer is freed 3 if there is no other request to send the packet (owner 362 is no longer present).
63. This process can be further generalized and implemented in a variety of ways.

The flow of data according to the preferred embodiment of the present invention will be further presented below. This includes additional inventions.

2. Header "Canonicalization" and Frame "Cellularization" When a data packet is received on the physical layer, this inventive network
The switch takes the layer 2 and layer 3 headers of the incoming packet (drops any layer 1 packet preamble) and converts it to canonical form. The present invention further divides variable length packets into "cells" of a length that is most convenient for communication on a high speed internal bus. This allows data packets of different Layer 2 and Layer 3 header formats, such as Ethernet "frames" and ATM "cells", but different lengths, to be routed by the same switching process and equipment. . In the header
Canonicalization also aligns the headers along 4-byte boundaries, which is convenient for processing. The example here is for an Ethernet frame, but it is also applicable to ATM cells with appropriate modifications to the terminology and the interface ASIC.

Referring to FIG. 1, a frame of information is received by MOM1 chip 10 via one of the eight ports shown. Physical link layer 1 processing is
In the preferred embodiment, a dual "off-the-shelf" QuadPHY integrated circuit (L
uCent Technologies) and each circuit is 10 Base-T (10 Mbit / sec) or 100 Base-T.
Handles X (100 Mbit / sec) Ethernet transmit / receive electronics. One of the ports, for example the port from MOM2, can be connected by internal or external 10 Mbit Ethernet to a DAD integrated circuit containing an off-the-shelf WAN processor (such as those available from Motorola), which is a modem. Interface with the T1 and POTS lines via. Together, they form the QuadServer ™ WAN access module.

Referring to FIG. 1, a frame or packet of information in the form of a data stream forming a message is input to physical circuit 70 and then received by MOM1 chip 10 via one of its eight ports. To be done. FIG. 18 schematically shows the structure of a typical packet format. There is a preamble 620, followed by a data link layer 2 header 622 containing information for bridging packets, a network layer 3 header 623 containing information for routing messages, and the use of data There is an application header 624 that contains information about the application of interest. Following these headers is the data body 625, and possibly the trailer 626, which is usually unnecessary and unused.

The MOM1 chip, which in the preferred embodiment is pre-programmed in hardware to recognize various Ethernet protocols, drops preambles and trailers from received frames, layers 2 and 3 7A to generate the 28-byte canonical header of FIG. 7A. MOM1
Has a buffer capacity of 256 bytes per port, thus segmenting frame data into cells of 128 bytes each (other cell lengths may be used in other embodiments).

The received layer 3 (network) header information is stored with the canonical header immediately added. Since the canonical header is 28 bytes, the layer 3 header always starts at a multiple of 4 bytes from the beginning of the cell. The important fields in layer 3 are typically aligned on 4-byte boundaries. This makes processing these fields very efficient for 32-bit processor / memory architectures.

The layer 3 header is followed by other header information from higher layers, including the application layer. The canonical header is placed at the beginning of the first cell of each received frame or packet and is used by the RE 40 to route or bridge the packet. When a packet in the form of a stream of cells is sent to the MOM for transmission, the MOM reconstructs the appropriate header, preamble, and trailer according to the destination and protocol information in the transmitted canonical header and is designated. Start sending reconstructed packets on the line connected to the port.

FIG. 7A shows the structure and contents of the canonical header in a preferred embodiment. The first two bytes 430 hold the circuit identification of the circuit from which the data packet was received, and byte 432 or DL Info provides information about the data link (Layer 2) header from the original received header. FIG. 7B shows the specific allocation for these bits. Bit 7 indicates whether the received frame was tagged with a VLAN (Virtual Local Area Network) when it was received. If this bit is set on transmission, the outgoing packet is encapsulated in the VLAN header by the MOM chip that handles the transmission. However, it should be noted that packets received with a VLAN tag do not necessarily have to be sent out with a VLAN tag and vice versa.

Bits 6 and 5 of FIG. 7B show how CRC (Cyclic Redundancy Check) is processed. FIG. 7C need not be described again. A new CRC has to be generated when the outgoing frame is different from the received frame, but the CRC does not have to be changed if the original frame is simply transferred, so either keep the old CRC or use another CRC. Note that it needs to be generated. Bits 3 and 4
Is unused and remains 0. FIG. 7D shows the encoding for bits 2, 1, and 0 that identify the data link format.

The canonical header NL Info field 434 contains network layer information. FIG. 8A shows the meaning of 8 bits in NL Info. For reception, bit 7 true indicates that the destination address (DA) of the received information is the address of the bridge group associated with the circuit in which the packet was received. Bit 6 true indicates that DA is the system address for that port. Bit 5 true indicates that the DA is an address that is preconfigured as a "well-known address" by the present invention, such as an address associated with a network control protocol. This bit is ignored during transmission. On transmission, bits 7 and 6
If set, the SA field contains the appropriate source address.

Bits 4-0 identify the layer 3 protocol of the packet. FIG. 8B identifies these protocols pre-programmed within the present invention. These can be extended as new protocols are developed and need to be handled efficiently by this system.

The four bytes 138 of the time stamp contain the time at which the packet expires.
The QM 30 enters the time at which the packet expires when it receives the canonical header as part of the first cell of the packet. When sending a packet, the QM 30 will check if the current time is greater than the time stamp value in the canonical header. If so, the data link device
Do not send the packet, instead instructed to count it. This field, when initially generated by MOM, contains cell information as described in the "Data Flow In" section below.

The 2-byte receive circuit identification (Rx Ckt Id) identifies the circuit in which the packet is received. The QM copies from the Ckt Id field 430 the receive circuit identification initially provided by MOM1 before overwriting the Ckt Id field 430 with the circuit identification of the circuit where the data is retransmitted. Therefore, the receiving circuit identification is
For later use (for management by BE50 and RMON functions etc.)
Retained.

DA is the 48-bit Layer 2 (MAC) destination address of the received packet.

SA is the 48-bit Layer 2 (MAC) source address of the received packet.

The VLAN tag is a 2-byte field for supporting a packet received with an Ethernet 802.1Q tag. As mentioned above, the VLAN tag bit in the DL Info field is also set. The MOM chip that handles the transmission of this packet will tag the outgoing packet.

P-Type / len is a 2-byte field containing a protocol type / length field. In the preferred embodiment, this value is 1500 (10
If the value is greater than decimal, this field represents the protocol and its value is 150.
If 0 or less, this field represents the length. The protocol is NL Inf
It is included in the Protocol Kind subfield of the o field.
If the protocol is not so configured, then P in the NL Info field
The protocol Kind subfield will indicate Unknown (0), and the P-Type / len field will have that value. For example, if the packet is in Ethernet 802.3 format, this field will contain a length that can be used for validation using the length in the Layer 3 header.

The XX bytes may carry other information based on the packet format of the received packet. FIG. 8C shows the contents of the XX bytes for different DL format types.

3. BlazWire ™ High Speed MAC Bus A frame received and reassembled into one or more cells, where the first cell contains a canonical header and an upper layer header, is transmitted to and from the QM.
It is communicated on a high speed MAC bus called ire ™.

The BlazeWire ™ design here is a full-duplex clock bus with 10 signals and 1 clock signal in each direction between two large integrated circuit chips. This clocking protocol allows data transfers on the bus to be self-framing, asymmetric and non-aliasing. All signals are differential signals between two conductor runs where the underlying transmission line is properly terminated. In this preferred embodiment, the electrical characteristics of the differential driver and receiver are approximately as described in the Low Voltage Differential Standard (SVDS) ANSI / TIA / EIA-644. The differential signal voltage is approximately 250 millivolts (mv), and cable terminations and physical signal paths are designed for high speed operation across the bus. The bus is organized as a chain from one large chip (MOM or QM) to the other. Another daisy-chained token pass approach is implemented to control chip access to the bus, as described below. The electronic design of the bus compensates for the actual variations associated with different product runs of the chip, possibly resulting from different manufacturing, supply voltage variations, and temperature variations. In the preferred embodiment, the speed of the bus can be increased to the gigahertz range.

The 10 signals are composed of 8 data, one is parity and one is control. These data are arranged on both the rising and falling lines of the clock signal. Since the data is placed on the signal line at the clock transitions, the signal should be read at the receiving end or close to the center of the clock signal. This allows any overshoot and any other signal delays or anomalies to be resolved.
Since the data is loaded on the signal line at both clock signal transitions, it is critical to have a symmetrical clock with minimal skew between the clock edge and the data located on the bus. This circuit provides a feedback mechanism to monitor and find the center of both phases of the clock signal, and
It provides a symmetric clock for the signal being sent over the continuation of the bus through the chip.

FIG. 9 illustrates the basic signal flow between two subsystems shown as MOM 1 and MOM 2 with 20 signal lines in groups of 10 in each direction and one clock for each group. To do. FIG. 10 shows the differential characteristics of each of the 22 lines. Differential drivers and receivers well known in the art properly terminate transmission lines with impedances characteristic of them to maximize signal fidelity and minimize ringing. Other termination techniques may be used, such as a drive-side implementation, as may be advantageous in other embodiments.

FIG. 11 is a schematic of a circuit for outputting one of the ten data bits from one of the MOMs. This circuit is essentially duplicated for the other data bits. This circuit implementation maximizes clock symmetry and minimizes skew. A data 462 is placed on output 466 and B data 4
64 follows. The A data is latched into flop 468 and presented in a logical array. Consider that the previous B data remains in latch 472 and is input to logic array 460. The logic array is configured to load a signal into latch 474, which provides an A signal at the output of gate 466 when "exclusively ORed" with the signal remaining in latch 476. . Then, on a clock edge, a similar operation provides a B data signal at the output, which B data 464 is latched at 472 and "exclusive OR'ed with the previous signal in latch 474. Therefore, the “exclusive OR” of the data in the latch 476 is the “exclusive OR” 4
It will provide the B signal to the output of 66. FIG. 12 is a timing diagram that simplifies the above.

FIG. 12A shows a composite timing chart of the bus clock and the 10 data lines on the bus between MOM 1 and 2. FIG. 12A shows the transfer of eight consecutive bytes (plus parity and control) on each edge of the clock signal.

When the signal is received at the MOM or QM, FIG. 13 shows the circuit of the MOM used to provide a delayed clock with an edge at the center of some phase of the receive clock. Another similar circuit is used to provide a delayed clock with an edge at the center of another phase of the received clock. These centered clocks are used to latch the data during the receive MOM and serve as a reference to the symmetrical clock used to send the signal out of the MOM. The reception clock 80 becomes the data input to the latch 482 and the latch 484. Delayed clock DLYA (a delayed version of the input clock) latches clock signal 480 into latch 482, the output of latch 482 is SAMPLE CLK A, and delayed clock DLYB latches clock signal 480 into latch 484, which Output SAMPLE C
With LKB. DLYA and DLYB are delayed by the control logic by a programmable amount. Both of these SAMPLE CLKs are fed back to the control logic array 90 via circuitry designed to synchronize the signals.
In operation, the control logic can program when DLYA occurs. In this way, DLYA can latch the clock 480 signal when low and the control logic can determine when low by the SAMPLE CLK A signal. The control logic continues to set different delays until the clock 480 signal goes high. Similarly, the control logic continues to set different delays until the clock signal returns low. As before, the control logic is SAMPLE C
This condition is determined by monitoring the LKA signal. Referring to FIG. 13A,
When the control logic finds the first rising edge 480 ′ and the falling edge 480 ″ of the clock signal 480, the control logic “knows” the DLYA rising edge 486 and can set the center of the positive phase of the clock 480. This DLYA rising signal effectively becomes the rising 486 'used to latch the data on the next consecutive positive phase of clock 480. During centering of the DLYA signal, time 48 in FIG. 13A.
The actual data received at 6 is latched by the signal DLYB of FIG. 13 previously centered on the positive phase of clock 480. Pre-centering of DLYB was accomplished in the same manner as described above with the SAMPLE CLK B feedback signal and the DLYB delay signal. In this embodiment, one delay clock is latching data while another delay clock is centered for some later use.

The circuit of FIG. 13 is duplicated to accurately measure the center of the negative phase of the input clock signal to latch the data on the opposite phase. FIG. 13 shows the DLYC rising 489 exactly at the center of the negative phase of the receive clock. As described above, while the other clock (DLYD (not shown)) is latching data, DL
The YC clock is centered during some negative phase of clock 480 and the DLYC
DLYD is centered while the clock latches the data.

FIG. 14 shows each part of the delay circuit. The IN signal 494 is delayed by some gate 495 and input to the "and" gate 466. If the control 1 signal is a logic signal, it crosses 96 and is output via the “or” structure 498 and 3
The output signal is delayed by one gate delay, 495, 496, 498. This delay is considered as one delay unit. Control 1 signal is logic "0"
And the control 2 signal is a logic "1", the IN signal is applied to the gates 495, 495.
Move through'496 ', 498', 498. This path is longer than two gates and the IN signal is considered to have gone through two single unit delay circuits. Each signal delay unit adds two gate delays. If the control logic allows the IN signal to reach the three gates 500 and the control X signal is a logic signal, the IN signal will have four gates, namely three gates 500 and 504.
(The gate 502 is a common path duplicated in each delay circuit and disabled in the previous delay circuit). This circuit adds four gate delays to form two unit delays. A four unit delay (not shown) would replace three gates 500 with seven gates,
Therefore, adding 8 gate delays or 4 unit delay increments. In this preferred embodiment, there are 32 single unit delays, 16 2 unit delays and 16 4 unit delays. The configuration in this preferred embodiment allows for an arithmetic progression of delays up to a total of 128 unit delays that can be selected. In other embodiments, other delay circuit configurations may be selected and other known delay circuits may be used to advantage. This preferred embodiment provides a single delay of approximately 0.15 nanoseconds for the expected manufacturing process used to build the circuit, and for expected temperature and supply voltage operation. It is expected that one unit delay variation can range from 0.08 to 0.3 nanoseconds, depending on the parameters mentioned above.

FIG. 15 (Table 1) is a table showing the usage of control bits in this preferred embodiment. Bits are used for framing. In the timing diagram of FIG. 12A, e0
8 bytes are transferred at each clock transition marked ~ e7. Table 1 shows the values of the control bits for even transitions, e0, e2, e4, and e6.
These combinations represent the allowed functions shown in the rightmost column. If the control bit is zero on each even transition, the bus is idle. Any combination shown in row 510 indicates that the data on the data line is a valid frame. Specifically, in a valid frame of data, the value of the e6 time is always zero and the value of the e0 time is always 1, so that the system has zero to one control bits.
Find the time sequence of. For e0 a 1 is assumed, and if the combination shown in row 510 is present, the framing of this data indicates a valid set of 8 bytes.

The values in row 510 are selected so that aliasing does not occur in a valid frame of 8-byte data. There are always zeros followed by ones in the valid control bit sequence combinations, row 510 of FIG. 15, and no other zero / 1 pattern in the valid frame. In FIG. 16, the pattern of control bit values on the even clock transitions shows frame 512 as invalid, but this
This is because there is another zero / 1 pattern at 12 e2 and e4. However, the frame 514 is as effective as the frame 516. In practice, the value of the control bit is measured at each receive clock phase and the zero-to-one transitions separated by the clock phase are monitored. If such a transition occurs, a 1 is treated as being in the e0 time slot and the monitoring of the validity of the frame is based on its relative timing.

Data transfer from the MOM chip to the QM is in the preferred embodiment a token
Arbitrated by the ring. Referring again to the system configuration / schematic diagram of FIG. 1, a token ring arbitration path 61 is shown between MOM 1 and MOM 2. A token ring is a looped signal in which the chip has a token when there is a logical difference between the input token signal and the output token signal. In Figure 17, there is an inverter in the path because there is no valid inversion in the chip,
At initialization, one chip, in this case MOM 1, is guaranteed to get the token and control the bus. Once the chip gets the token, it is possible to send its own data over the bus, but if the chip does not get the token, it has to wait for the token, while other data simply passes through the chip. Will be handed over. When the chip gets the token, the token is released after all the data that needs to be sent by the chip has been sent. When MOM 1 gets the token, MOM 1 changes the state of the output signal 61 to cause the token to MOM.
Passed to 2. Then MOM 2 gets the token.

This token passing can be extended to multiple devices by connecting the single token output signal of one device and the single token input signal of the next device. The token output signal of the final device is inverted and then sent to the first device in the token passing chain.

Implementing token passing or changing the state of the information at the edge facilitates synchronization between different clock domains. Edge-based information passing automatically keeps the token valid on the previous device until the token is recognized and passed to the next device in the token passing chain.

4. Data Flow In The MOM 1 chip 10 can store or buffer up to 2 cells or up to 256 bytes of received data for each of 8 ports. The above
Header Canonicalization (Header Canonicalizat
section), the MOM chip read the Layer 2 and Layer 3 headers from the received frame or packet and generated the first 28-byte canonical header (detailed in this section). Afterwards, the layer 3 header of the network and the application layer header of the first cell are processed.

The MOM 10 (or 20) transmits cells to the QM 30 on the high speed MAC bus 60 when the MOM holds the token of the token ring arbitration path described above. Arbitration is sequential among the eight ports of MOM. Although the QM receives the cells and stores them in the dynamic RAMs 35 and 36, in the preferred embodiment, RAMBUS® with two fast access DRAM banks as described in Section 9 below. DRAM
Is. The information that describes the cells received and stored is called the "descriptor" and is the SRA.
It is located at M 32. The canonical header is modified to include a time stamp. The modified canonical header and the remaining header information in the first cell in the packet is forwarded to the header out FIFO for transfer to the RE 40.
It is arranged in 309.

Frame segmentation and arbitration schemes allow subsequent cells of a packet received on one circuit to be interleaved with cells of another packet received on another circuit. In order to provide information so that the QM can track the cell order of the packet, the MOM is added to subsequent cells of the same packet, corresponding to the first octobyte of the first canonical header of the first cell of the packet. Write the additional 8 byte (octbyte) "burst" header (up to 17 octbytes).

Additional information is transmitted on the control signaling line or bits of the high speed MAC bus to allow identification of cell boundaries and the type of information stored within the cell. FIG. 21 is a diagram showing the use of control bits to draw data in groups of octobytes. Control bits 700 on eight consecutive clock phases, framing on eight bytes, distinguish the data. The control bit values are shown in the table of FIG.
It is indicated by e0 to e7.

In FIG. 22, even control bits e0, e2, e4, and e6 are encoded as follows. E0 to indicate that an 8-bit valid group has been received
Is always 1 and e6 is always zero. In order to avoid aliasing of this encoding, the value indicating the valid group (for even control bits e0 to e6) is
Only 1000, 1100, and 1110. Bit e2 indicates the start of the cell and e4 indicates the start of the packet. FIG. 23 shows a possible sequence of even control bits where group 702 is not a valid group but groups 704, 708 and 710 are valid. A circled zero / one 708 indicates that the start of a valid group is only zero first, followed immediately by one, and the following two bits (e2 and e4) cannot have another zero / 1. Indicates that.

Still referring to FIG. 22, the odd control bits are encoded as follows. e1 indicates that there is a transmission credit (see discussion below), e3 (code bit 0) and e5 (code bit 1) form a 2-bit end code, and e7 (short word). Indicates that the octobyte contains less than eight significant bytes. Short words can be used at the beginning and end of cells.

FIG. 24 is a diagram showing some of the packet types that may occur. The first cell 720 can have up to 16 octbytes, or 128 bytes. The even control bits 722 for the first 32-bit word (octobyte) are 1110. As shown in FIG. 22, this code means that this octobyte is part of the valid first cell of the packet. A valid cell requires e0 to be equal to "1", e2 equal to "1" means this 8-byte transfer is the start of a cell, and e4 equals "1" means this. We know that e6 must be zero for a valid cell, meaning the start of a packet. For cell 720, the odd control bits are all zeros, with the exception that only bit e5 of the last 8-byte transfer is "1". FIG. 25 is a diagram showing encoding of control bits e1, e3, e5, and e7, that is, odd control bits. In the case of the cell 720, e5 is “1” and e3 is “
0 ", which is decoded" end of packet ". Therefore, cell 7
20 is one cell packet (SEP). Note that this cell need not be all 128 bytes long.

Cell 724 is a valid starting cell for the packet, where odd control bit 726 is
E3 is set to mean "end of cell" rather than "end of packet", so it is a SOP cell. The next cell 728 is the second cell (MOP) of the packet and all cells following the SOP contain an octobyte burst header 330 added to the beginning of each cell and have up to 17 octobytes. It will be. For this second cell, the last octbyte e3 is set to mean that this cell is the end of the cell, not the end of the packet. Cell 734 has e5 in the last 8-byte group, which is set to mean that this cell is the end of packet (EOP), and in this case also e7. Bit e7 means that the last group of eight was a "short word" (as represented in Figure 25) rather than being full, and when this occurs, the last byte 338 contains the last The number of valid bytes in the 8-byte group is stored. For example, if the last group had only three significant bytes, then the last byte (occurring at the same time as the e7 control bit) would contain 0011, or decimal 3.

For the transmission of cells from the MOM chip to the QM, at the beginning of the first cell, the first octobyte contains a part of the canonical header modified by the QM to include a time stamp. . The entire canonical header, along with other headers, is stored in DRAM, allowing such frame data to fit in the remaining 128 bytes.

FIG. 26 is a diagram showing the transmission of the first octobyte of the canonical header by QM. As can be seen, the first 4 bytes 740 written with MOM, Ckt ID, DL Info, and NL Info are transferred by QM. The second 4 bytes 742 containing the cell information are timed by the QM.
Overwritten with stamp 748. (The canonical header is sent to the RE and is only processed in the packet policy and is not concerned with cell information.) The first byte 744 of cell information byte 742 contains the number of transmission credits reported by the QM. Included (below "Transmission Credit Scheme (Transmi
session credit scheme) ”). The second byte contains the credit flag, bit 7 is the SYNCH flag (for initialization) and bit 6 is the "parent" flag (described in Section 8 below). The third byte is
Cell information having the meaning shown in FIG. 27 is provided. Each bit was selected from bit 7 a cell error, bit 6 a packet timeout, bit 5 a packet from the bad packet queue, bit 4 from a watch queue and bits 3 to 0 from the control described above. It means to indicate a bit. Bit 3 is the packet end bit, bit 2 is the packet start bit, bit 1 is the data cell bit, and bit 0 is the transmission credit bit. The last byte of cell information byte 742 represents the length of the cell in bytes.

An octobyte long burst header used to track cells without canonical headers is shown in FIG. This field is the first of the canonical header except that DL Info and NL Info (used by the RE intended for SOP only) have been replaced by cell sequence number 752 and unused space. This is the same as the field of 1 octbyte. The Ckt Id 750 should have a cell (more specifically, its surrogate buffer descriptor) having the same Ckt Id and a sequential sequence number (unless the cell has been discarded). Used to match the preceding cell. Q
M links the cell once (as described below) with the preceding cell,
When the credit is entered and the action on the other cell information is performed, the burst header is no longer needed and is dropped. (A cell may be discarded when the parity information detects an error. In such a case, signaling to the MOM chip causes the cell to be dropped at this point, and eventually the packet to be dropped.) Transmission At step QM creates a new burst header for the cell, where the CKT ID indicates where the packet will be sent.

5. QM Buffer and Queue Structure and Operation The data cells received by the QM on the MAC bus are described in Section 9 below.
In accordance with the high-speed access operation described in, a RAMBUS (registered trademark) DRAM addressable 128-byte data buffer is rewritten to include a time stamp but with a regular header, and an octobyte in a burst header is dropped. And are stored individually. Address 00000 does not include cell information,
Corresponds to a null pointer.

All cells received on the MAC bus and stored in the data buffer are organized into a single virtual receive queue using the descriptor / pointer scheme, with the exception of a few dedicated queues. It This scheme enables a receive queue for data up to 1 gigabyte.

In this descriptor / pointer scheme, the data buffer “descriptor” in the QM SRAM contains two 4-byte words that act as a proxy for the actual data stored in that buffer and pass the logical packet Linked to form. Therefore, the descriptor assigned to the data buffer along with the data is stored in the first word field indicating the address of the buffer in the DRAM in which the associated cell is stored and in the SRAM associated with the next cell in the same packet. A second word field containing a pointer to another descriptor 802. As shown in FIG. 29, a complete multi-cell packet has a second word of SOP buffer descriptor 801 pointing to MOP buffer descriptor 802 and a second word of descriptor 802 pointing to EOP buffer descriptor 803.
With the second word of descriptor 803 associated with the last cell of the packet,
Including a pointer to the descriptor 801 associated with the first cell of the packet,
It is described by the descriptor "link-list". The incomplete packet has a null pointer in the second word of descriptor 805, as shown in FIG. 29B.

In the present invention, the queue is associated with the first cell of the first packet of the queue and the field pointing to the first word of the descriptor associated with the first cell of the next packet of the queue. Formed by the queue head pointer pointing to the first word of the assigned descriptor, and thus iteratively linked to the last packet of the queue. This queue has a queue tail pointer to it, as shown in FIG. 30, with the receive queue head pointer pointing to the designator 812 associated with the first cell of the first packet of the queue, and the tail 811 points to the designator 815 associated with the first cell of the last packet of the receive queue (the descriptor maps to a 128-byte buffer in DRAM 35 or 36, respectively). As shown, the queued parameters do not necessarily have to be complete, but in this packet-oriented embodiment, the data cells received from the MAC bus are not at the end of the queue, but at the Rcv of the burst header. It is "appended" to that packet identified by Ckt.

In a receive operation, the QM Descriptor SRAM is organized into a buffer descriptor table and a receive context (or circuit) table. This buffer table or list has a descriptor containing two 4-byte words,
The word 0 contains the buffer address of the data buffer of the RAMBUS® DRAM (hence this buffer table entry is an implicit buffer),
Word 1 contains a pointer to another descriptor in the buffer table. When initializing,
This buffer table is the "free buffer table", in which the head pointer points to the designator of the first free buffer by the QM hardware and its second word is the next free buffer descriptor. , And is iteratively linked to the final free buffer designator that contains the null terminator of the second word.

When a data cell is presented to the QM from the MAC bus, the QM extracts its circuit ID from its regular header or burst header and provides a receive context (circuit) table that provides information about the activity of that circuit. Check for items. When a SOP is detected, an entry (8 bytes circuit) in the receive context table is created and a pointer (current buffer) is entered to point to the next free buffer identifier. This cell data is the associated RAMBUS® D
Written to RAM buffer. The free buffer list pointer is moved to the next free buffer designator after the "current buffer" has been allocated.

If the received cell is not a SEP, the second word of the buffer designator is the next free
Points to the buffer designator, preallocates the associated buffer, and writes a "0" in the second word of the next buffer entry.

If the received cell is a SEP or EOP, the second word of this buffer designator is set to point to the first buffer designator of that packet, and a linked list defining the resulting packet. Is unlinked from the receive context table.

Thus, cells received with the same circuit id, which may be interleaved on the MAC bus, are effectively reassembled into packets by the linked list,
Some of them may be incomplete even when the leading cell is being sent in a disconnect operation. In the latter case, as shown in FIG. 30B, the reception context table 820
Current buffer points to the next buffer descriptor 833 corresponding to the buffer into which the data cell is to be loaded, which is linked to descriptors 832, 822, and 821 of the other cells of the packet. There is. One of this descriptor, descriptor 832, is linked as the current buffer 821 of the circuit entry in the send context table. Since the circuit entry in the send context table provides the routing information, the data subsequently placed in the buffer associated with descriptor 833 is "knowing where to go." This link management system allows "cutting" or sending part of a packet while still receiving the other part of the packet.

6. Relay engine processing / flow matching (FastPath ™)
The SOP's linked descriptor receive queue awaits processing by the RE 40. SO
The P-cell itself is loaded into a "circular" FIFO 394 of 16 128-byte registers processed by the relay engine as memory space becomes available. This is done by the pointer system following the processing of the SOP cell, adding cells until its register is full (when the second pointer "catches up" with the receive pointer in FIG. 19) and then pointing with the head pointer. Another cell is added only when the processed cell is complete and dropped (and when the receive pointer "lags" the send pointer).

The operation of RE is centered on a 4-stage pipeline. Pipeline is a term of the art for many years, especially in high speed hardware design, and will not be described further herein except as a concomitant reference. The task of the RE is to make the best transfer of frame flows and to determine how to provide the transfer information to the QM accordingly, in order to route and schedule the retransmissions of stored packets. The four stages are briefly described here, followed by a more detailed description of the hash and signature functions used to perform pattern matching to identify flows.

The first stage stores the complete header information (entire SOP cells) in a “circular” data FIFO, in parallel with the header being processed by the hash engine, and the packet is routed to the routing information. And compute a hash value and a signature value to implement a pattern matching function to check if the schedule management information is part of an existing flow already developed for it.

The second stage receives the Hash value used to address the Hash Table L1 391. If a valid entry is found in this table,
The signature from the L1 Table is compared to the calculated signature of the Hashed data. If there is a match, a Hash Table Flow Tag (not shown) is presented with an indication that a valid hit was found in the next stage of the pipelined FE / RE hardware. The Flow Tag is a 24-bit index into a table in memory where information about that flow is stored. This information includes one or more circuits that forward the packet along with other flow-related information, as described elsewhere herein.

A valid Flow Tag pointer (which links the content pointed to) is the preferred result of the pattern matching function described in this preferred embodiment.

If no match is found in L1, then a search is performed on the external L2Table45. The signatures are compared as described above and the Flow Tag of the L2 table is presented to the next stage. The L2 entry is written to the L1 table to facilitate the next search.

If there is no hit in either L1 or L2, the calculated hash and signature are submitted to the next stage with an indication that no hit was found.

The third stage receives said information and determines if the header lookup was successful. If successful, the header data is updated according to the applicable protocol rules and the packet is forwarded according to the flow information. But,
If the header is found to be a TCP (Layer 4 Transfer Control Protocol) SYN packet or the corresponding start of a connection packet of another protocol, or if the frame is not part of a known connection flow, the packet is It is not transferred according to the flow information. In those cases, the RE acts to route the flow frame by decrypting the complete pre-hashed header. In this process, it creates useful flow information and uses the hash and signature values obtained by the hardware in stage 1 to generate the L2 Hash T
Insert a tag pointing to it in the table.

In the fourth stage of this pipeline, according to the information provided by the Flow Tag or the routing information provided by decoding the full pre-hashed header of the RE, the header is put into a designated queue. Returned to QM to be queued for transmission. To consolidate the information for forwarding subsequent packets of that flow, the RE inspects the application layer data in addition to the Layer2 and Layer3 headers.

In more detail, referring to FIG. 4, when a packet is received, the QM 30 provides a useful header that may be 128 bytes long (as determined from the NL field). Provide the FE / RE by loading the data into the RE's dual port circular buffer. Referring to FIG. 4, the header data is transmitted from the QM 100 to the MUXIn 102 and placed in the FIFO stack DF of the RE 40. The RE uses the network link byte to index into the already stored ordered data array of 128-bit items. Here each bit is 1 of the complete header data byte received.
Correspond to one. The bytes corresponding to the bits with a 1 are extracted and processed by the hash and signature functions. The byte string consists of an odd number of 4
The end is padded with zeros to provide a string of bytes. In this preferred embodiment, up to 64 bytes of the 128 header bytes can be processed by the hash / signature operation, but less or more may be advantageous in favor of other preferred embodiments.

The hash function and signature function are the same, except that different multipliers are used. However, in another preferred embodiment, it is also possible to use other combinations of different multipliers and different divisors for the sake of advantage.

Referring to FIG. 4, the Hash Preprocessor 399 inputs a selected byte from 128 bytes of header data. This select byte forms the nth 32 bit word (a multiple of 4 as described above). This 32 bits
The bits in the sequence of words are treated as polynomials in the Galois field, GF [2], a Galois field of 2 (the Galois field is known in the art). In the preferred embodiment, this polynomial is multiplied by a random 32-bit polynomial and divided by a carefully selected 32nd order polynomial, resulting in a 32-bit remainder. The divisors used above are irreducible and primitive (primitive).
e) Selected to be both (irreducible and basic are terms known in the art). The subset of remainder bits is used as the actual index into the hash table. Bits 5 to 0 are addresses assigned to the on-chip L1 cache 391. Bits 16 to 1 are used to address the 64K location in the off-chip L2RAM 45.

The divisor used in this preferred embodiment is _x ³² _{+ x} ⁷ _{+ x} ⁵ _{+ x} ³ _{+ x} ² _{+ x + 1} , but other divisors may be used as long as they are irreducible and basic.

Hash T to identify the Flow Tag and / or the destination of the incoming frame
The organization of the contents of the "able" is as follows.

Hash Table 1 contains 64 words, each of which is 64 bits, and exists on-chip to optimize the return of values at common occurrences where only a few flows are active. Larger tables can be used. Looking at FIGS. 20A and 20B, in each word, bits 31-24 form a state that indicates a valid entry if bit 31 is true. Bits 0 to 23 form a 24-bit Flow Tag in which information regarding a specific flow is stored. This tag is a pointer that points to information about one or more circuits to which the packet is transferred. Acquiring a Flow Tag is the main task of RE. The Hash Table also includes a 32-bit signature in bits 63-32, which is used to ensure that no collisions have occurred and the result is valid. To further ensure the validity of the Flow Tag lookup, a pre-hashed header to allow unambiguous identification.
The data is stored.

If there is no match in the L1Hash table, the system uses the hashed result bits 16-0 to index into the 64K Hash Table L2. Each position is 64 bits wide. Bit 30 is a Hash Bucket pointer, and when this bit is zero, the bits in the L2 table are organized functionally in the same way as the L1 table. If there is one valid entry in this Hash Address, the system gets the flow tag with L2 bits 0-23 as the index into the flow table. See FIG. 20B. If there is no valid entry in this Hash Address, the valid bit L2 bit 31 is set to zero. If there is more than one entry in this hash address, status word bit 30 is set to 1 and the system
The L2 bits 55 to 36 are used as pointers to Hash Buckets.

The Hash Bucket holds up to eight 64-bit word alias addresses. If the collision bit 29 is 1, then the aliasing state persists for both hash and signature operations, and no useful information is available, so the hash mechanism does not perform further decomposition. At this point, the two competing flows are returned to the processor to do a trie search for routing information. Hash
The 8 words in the Bucket are searched consecutively, and to facilitate this search,
Addresses are contiguous, starting with the lowest index into the table. If more than eight entries are destined for the Hash Bucket, the system reverts and searches the overflow for a try routine. Trie search uses coprocessor 390 and is organized as a large trie database for routing and bridging.

The occurrence of signatures and / or hash collisions can be monitored and, if excessive, each multiplier can be changed. Such changes result in more effective randomization for a given set of addresses encountered in the network.

The results of the hashing and signature routines may not be available in some situations. Connect when a TCP SYN or equivalent "start connection" packet arrives, or if a packet is found that does not belong to the connection flow, or if the packet is part of a high security or other special mode. An example is when is started. When such a situation is found, the system can return to the try search.

Processing of subsequent packets in the flow is generally accelerated by optimizing software pattern matching as described above.

The RE returns information including instructions that specify in which queue a cell should be placed for transfer with addressing. QM receives the information and places the cell,
This cell is stored in the linked list forming the content of the packet which is being received or has been received on the sending list.

7. Transmission Scheduling RE programs the QM, which can manage up to 16,000,000 transmission queues (24 bits) with controlled priorities for various circuits.
It is virtually evolved by the linked pointer of the descriptor SRAM.

The core of the transmit stage is the Transmit Context Table, which is organized by circuits and has four 4 bytes per circuit, as shown in FIG.
There is a word. Word 0 is the credit sync bit, 7 for send credit
It includes bit 812 (no transmission is done if there is no credit to the circuit), a start bit 814 of the packet bit, and 23 bits that specify the next buffer to send (next buffer ID). Word 1 816 contains eight flag bits 818. FIG. 35A shows the meaning of these flag bits. Bit 7 indicates that the packet is a single buffer, bit 6 indicates that the packet is bad due to a CRC error, and the MOM should abort the packet, and bit 5 indicates that the packet is monitored. Dequeued from the queue, indicating that the packet can be offloaded to some other port or background engine for traffic analysis, bit 4 is "multi-owned" and more than one , Bits 3-0 indicate a buffer length of up to 128 bytes in a group of 16 bytes. The remaining 24 bits of word 1 contain the address of the first queue (each circuit can have 1, 2, 4, 8 or 16 associated queues). Word 2 820 of the send context table is
It contains 1 bit 822 indicating that a monitor queue is attached, 4 bits indicating the queue service policy, and 3 bits indicating the reference count.
FIG. 35B shows the meaning of these four queue service policy bits. Possible indications are: 1 is a queue, 2, 4, 8 or 16 is a static queue; or 2, 4, or 8 is a weighted round robin queue; or 2, 4,
Half of 8 and 16 are static queues, half are weighted round robin queues, and so on. As described below, static queues have the highest priority, followed by weighted round robin queues. Word 3 contains the standby scheduler control word, which contains the "next cctID", "parent cctID" (used only for standby scheduler circuitry), status bits (active or idle), and standby scheduler interval. including.

The Queue Table shown in FIG. 36 is a Transmit Context.
Works in conjunction with Table and contains four 4-byte words per queue. Word 0 contains a 2-byte standby circuit ID (discussed below), and a 2-byte queue summary bit (only for every 16 queue numbers). Word 1
Contains a 2-byte indicating the queue size and a 2-byte overflow counter ID. Word 2 contains a 5-bit field that indicates the number of standby queues and 24 bits of the head of queue pointer. Word 3 contains a 24-bit tail of cue pointer.

In the preferred embodiment, a queue is formed by linking the SOP cell starting with the head of queue pointer to the first SOP (and the tail pointer to the last SOP), and the new cell of the packet is Remember that it will be added to the cell. Therefore, referring to FIG. 37, the linked descriptor 8
As indicated by 63, the queue 16 of the Queue Table 850 has four SOs.
P, and there are two SOPs in queue 17, as represented by the linked descriptor 864. Incomplete packets, such as those represented by linked descriptor 862, can still be sent (by allowing "cut-through"), but the last descriptor indicates that its associated buffer is empty. And the transmission stops on the circuit, thereby maintaining the rule of keeping the packet order on the circuit.

Queue policies allow prioritization and scheduling of data packet transmissions. Therefore, under a fixed static priority, all packets in a particular queue are sent before packets in another queue. The weighted round robin queue scheme sends a certain number of packets in one queue, then a certain number of packets in the next queue, and so on. This allows classes of traffic (queues) to have a relative priority without "povertying" the lower priority classes. A "half and half" scheme is provided in which static queues have priority when they are serviced.

The Schedule Table for the circuit in use is continuously scanned. As shown in FIG. 37, this table is stored in the Primary Schedule.
Table A865, Primary Schedule Table B
866, and a Primary Schedule Table with a Secondary Schedule Table 870. Primar
The yScheduleTable is located on-chip and consists of two previously mentioned subtables, each with 64 entries. Primary Sc
The slots in the Hedible Table A are all Schedule T
It is visited once every time the "time" ticks. Primary Table
The A entry contains a 6-bit index into the entry of the Primary Schedule Table B. As shown in FIG. 37, every Table B entry has two or more Table A entries pointing to it. The Primary Table B entry contains the size of the secondary table, and if this size is not equal to "0", the offset into the secondary table 857, and
It also contains the base address of the secondary table 868. If the size is equal to "0", the remaining fields are "Use Parent Circuit" bits 871.
, Parent Circuit ID 872, and Circuit ID
873.

A cell send event is fired when a schedule table entry with a Circuit ID is found. Sched the appropriate Circuit ID
By inputting into the ule Table, a cell transmission ordering pattern is generated which effectively allocates bandwidth to the circuit depending on the circuit's individual ratio of transmit events.

The hierarchical nature of the Schedule Table allows a wide range of rates to be programmed. This is done by "chaining" up to three levels of subtables. Size of the Primary Table B entry
If the field is non-zero, this entry is a Seco located off-chip.
Contains a pointer to the ndary Table. Secondary Table
The 870 can have up to 255 entries, each of which points to a Tertiary Table, or Circui.
t ID can be included. When table chaining is encountered, offset field 867 is used to track which entry in the low level table should be accessed. Each visit to this field increments the offset modulo the table size.

The Stand-by Scheduler (SBS) is a secondary scheduling mechanism. As its name implies, a Stand-by Schedule
r schedules traffic for postponed bandwidth from the schedule table. Can carry standby traffic 2
There are two cases. That is, (1) the transmission event did not transmit data to the circuit (insufficient credit or insufficient data), and (2) the Circuit ID programmed in the schedule table was zero, and Is a case where a certain amount of bandwidth is pre-allocated to standby traffic.

SBS uses a version of the Calendar Queue algorithm, essentially a slotted time ring implemented as an array of linked lists. Each element of the array corresponds to a different time slot. Each time
The slot is populated with a list of circuits that are scheduled to transmit cells at this time. The slot index advances over time. When a popular slot is found, the cell for the first circuit in the list in that slot can be transmitted. When a cell is transmitted for a particular circuit, the qualifying time for the next cell on that circuit is calculated and mapped to another time slot.

Referring to FIG. 38, Stand by Scheduler Calendar
The ar Table 878 is an on-chip table composed of 64 entries. Each entry contains a head index and a tail index that describe a linked list of circuits that are installed in a particular slot. The link is stored in the Next CCtId field of word 3 in the Transmit Context Table 860. Slot index 87
Step 7 progresses with the period corresponding to the QM core clock. When an SBS opportunity occurs, the next circuit to transmit is found by scanning forward from the time represented by the current value of the slot index. The next circuit to send is the one at the top of the list for the next most popular slot. After the next circuit is found, it is delisted from the list and rescheduled.

Rescheduling is performed by calculating the next slot in which to send the circuit. The calculation of the next slot is based on the Transmit Context T
Based on the Word 3 SBS interval field in the available. This field is a 6-bit number that represents the number of calendar table slots during consecutive transmission events for the circuit. The next slot for the circuit is the sum of the current slot and this interval modulo the table size. SB
The net effect of S is an approximation of the weighted Weighted Fair Queueing algorithm. The weight of a given circuit is the inverse of its SBS interval.

Another aspect of the Stand-by Scheduler is that it can perform dynamic bandwidth allocation based only on circuits that are “active”, that is, have data to send. Many circuits can be enabled for standby bandwidth. However, only a few circuits are likely to be active at any given time. In order to use the standby bandwidth more effectively, the SBS keeps only the active circuits in the scheduler. The SBS receives messages from the process that manages the Queue Table when the circuit becomes active or becomes idle. The transition from active to idle occurs when the packet is dequeued and all queues for the circuit are empty. The transition from idle to active occurs when a packet is queued to a circuit that has an empty queue.

Any circuit can be scheduled using both the schedule table and SBS at the same time. This is the ATM available bit rate ("ABR").
) Useful for traffic.

The "send" in the preferred embodiment unlinks the packet string (which may be incomplete) from its queue ("unwait") and it (shown in Figure 37). Start by linking to the current buffer of the Transmit Context Table 860. Then the Transmit Context
The Table's circuit entry is polled and the buffer content of the current buffer (if not empty) is sent to the corresponding "circuit" 63 '. The cell data is stored in the RAMBU according to the "ping-pong" method described below.
Read from SDRAM.

When the packet is completely transmitted, its buffer is returned in the free buffer list. Completion of packet transmission is indicated by the transmit context tab.
When the next buffer of le is sent towards the descriptor 880 associated with the first buffer of the packet, with reference to pointer 883 of FIG. 39A, it is indicated by the second word of descriptor 882 of the last buffer of the packet. The free buffer manager (not shown) then determines the "owner" of the SOP's descriptor 880.
Others (for multicasting etc.) by examining the field
Check if there is an "owner", and if there is no owner (if the value is 1, decrement otherwise) as shown in FIG. 39B, the free buffer manager returns the second of descriptor 890. The free counter 890 is incremented by the buffer count 891 in the word. The free buffer manager moves the free buffer list head pointer from the head 895 of the free buffer list to the descriptor pointed to by the descriptor 880, that is, the descriptor 881 of the buffer of the second cell, and the descriptor field of the descriptor 880. Enter a pointer to the beginning of the free buffer list 896 before it. Thus FIG. 39B
As can be seen, all three buffers are linked at the beginning of the free buffer list.

8. Transmit Credit Loop The preferred embodiment provides a hierarchical flow and congestion control scheme by using a multiple credit loop. 8 to accept cells for transmission
A system of credits is established that indicates the MOM chip's capabilities for each of the output channels. The MOM for a particular channel sends a packet on a cell-by-cell basis, and when each cell is transmitted, that MOM indicates that another cell may be sent to its MOM chip via the aforementioned credit bits. As shown in FIG. 31, the MOM when transmitting a cell increments the credit count 760 and when the QM transfers the cell 762 to the MOM, the QM decrements the credit count 764. As mentioned above, the credit has a circuit ID such that the appropriate MOM channel credit is retained. In this preferred embodiment, four transmission cells can be stored. The MOM has a FIFO in which packets are reassembled from the cell.

When a cell is transmitted from the MOM chip, the credit sent back to the QM is
This is the credit for the maximum length cell. It can be 17 octbytes in cell mode or 16 octbytes in packet mode (because MOM removes the burst header when in packet mode). However, the QM may send less than the maximum cell size. FIG. 32 is duplicated for each output channel associated with the MOM chip and the credit is MO
A schematic representation of the mechanism processed in the M-chip is shown. Head pointer 770, tail
There is a pointer 772, a virtual tail pointer 774, and a start 776 of the packet pointer. In the preferred embodiment, 512 bytes
There are locations, or all four 128 byte locations. In FIG. 32, there are 64 slots, and each slot 778 symbolically holds one octobyte (64 octobytes equal 512 bytes of storage in this embodiment).

At initialization, the FIFO is empty and the virtual tail is incremented and moves through the FIFO location. The virtual tail pointer stops when the virtual tail reaches or attempts to reach the head pointer. Each increment of the virtual tail pointer causes a single credit to be sent via the send and receive credit managers in the MOM chip. These credits are accumulated in the QM for this circuit. M
When the OM receives a cell to this circuit, the tail pointer (which points to the actual information representing the actual cell length) is incremented. The virtual tail pointer is corrected when the QM transmits less than the entire cell. The head pointer is incremented when the MOM actually transmits a cell. When the MOM sends a cell, the head pointer moves from the virtual tail pointer and the real tail pointer,
Empty the room inside. A virtual tail pointer, which sends less than the maximum cells and may have been corrected by QM, is transmitted by the transmit FIFO without cycling through the head pointer.
Credits are sent and established during QM when the maximum cell length in O can be incremented.

The start of the other remaining pointer, the packet pointer 776, has one important function. Its function is to keep the starting location of the start of the packet so that if there is a collision on the Ethernet cable the colliding packet can be retransmitted according to the published specification.

With reference to FIG. 2, the virtual tail pointer is controlled by the transmission credit manager, the real tail pointer is controlled by the transmission FIFO “producer”, and the “consumer” controls the header and start of the packet pointer. To do. All pointers are accessible to all transmission credit managers for comparison and credit issuance.

FIG. 33 shows how a MOM FIFO, 2 port, 64 octobyte memory is controlled. The arbiter 780 uses the three most significant addresses of the FIFO from the "producer" side to keep track of the cells loaded from the QM.
The bottom 6 bits of all 9 bits needed to control the bits and address the 512 locations are tail pointers 782 (indicating one of eight).
Controlled by. Virtual tail pointer 784 does not point to real data. The counter mechanism allows the credit manager to determine the number of credits to send to the QM. Another arbiter 786 and head pointer (indicate one of eight) controls the unloading and emptying of the FIFO as the packet is physically transmitted by the MOM chip. The head pointer 788 controls the lower 6 bits of the FIFO from the unload side of the FIFO. The consumer increments the head pointer when the data is sent. The head, tail, and start of the head pointer are available to the transmission credit circuit.

Referring to FIG. 26, the first octobyte portion 742 of the initial canonical header, and referring to FIG. 27, the burst header contains two credit flags, a “sync” flag and a “parent” flag. Including the flag. The sync flag is used at power up to properly establish the aforementioned credit cycle operation. On power up, the MOM sends a sync flag to the QM every 10 ms. When the QM is powered up, it looks for the sync flag and when it finds the QM, it sends a sync confirmation to the MOM. The MOM then sends any of the credits mentioned above along with a guarantee that the QM is ready to accept the credit.

The parent flag is necessary because there are multiple physical communication paths multiplexed in the channel of the MOM chip. When there is only one communication circuit connected to the MOM channel and the MOM is connected to the Ethernet, the credit system works as described above, but with multiple separate paths to the MOM channel A method is designed to maintain credit for each of the paths connected to the channel. An important aspect of this credit system is that it ensures that no one of the multiple communication paths connected to one MOM channel can be blocked or locked out by other paths in the multiple communication paths. It is necessary. In this embodiment, FIG. 34 shows two FIFO channels in the MOM chip. FIFO 800 operates in a single communication path. In this case, MOM FIFO 800 is a leaf that illustrates its operation by a single communication circuit. FIFO 802 is associated with a FIFO channel, which is
It is connected to another chip, for example the DAD chip 804 of the presently preferred embodiment, provided that the DAD is further connected to eight other communication circuits 804. In this case, the FIFO 802 is called "parent", and the eight communication circuits connected to the DAD are leaves. In this circuit, the QM maintains credits for the individual leaves connected to the parent FIFO in the MOM. In this way, the QM will know when the transmit FIFO is full and cannot accept any more cells. The QM will then forward the cell to the other leafs by simply polling for the credits in the parent and leaf, resulting in the cell being transmitted. In this way, one leaf cannot block the services of another leaf.

Referring to FIG. 38, the Schedule Table 866 in the QM includes:
There is an indication 871 of whether there is a parent associated with a particular circuit. The MOM, which acts as a parent, sends a credit for the parent FIFO and each leaf associated with the parent.

The Parent Credit Table 875 is a 64-entry on-chip table in QM. Each entry contains a credit count for what is treated as a "parent circuit". When a circuit is coupled to a parent circuit, it is connected to its Transmit Context T
Able Credit Field and Parent Credit Table
It only sends a cell to the MAC bus if it has credit available both in its parent credit field within.

When a cell is transmitted to a circuit with a parent, the Transmit Co
The text Table credits and associated credits are decremented. Parent credit update cells from the parent channel are sent back to the QM, which increments the parent credit.

The schedule table is used to bind a circuit to a given parent circuit. The Use Parent Circuit ID field 872 is used for this purpose. If the schedule table entry has the P bit set, this means that the circuit has a parent and Parent Credential
Parent Circu for Indexing Table 875
It means that it ID 872 should be used.

9. Ultrafast Access on RAMBUS® RAMBUS® DRAMs 35 and 36 are off-the-shelf items. In the present invention, they are used in a unique manner to maximize read and write bandwidth for this date communication application.

The present invention provides an interface 308 to RAMBUS®, which is a dual bank organization for increasing the effective bandwidth of RMBUS® memory.
Ion) is used. The Dual FIFO stack is used with the controller to alternately address the separate DRAM banks in the RAMBUS®. Although FIFO adds latency and increases the hardware overhead of the electronics that control the RAMBUS®, an attempt is made to guarantee the sequence of data written or read from the alternate bank. In this scheme, one bank will be precharged while the other bank will be accessed, then the other bank will be precharged and the first bank will be accessed during that time.

Referring to FIG. 40, a RAMBUS 900 is shown in block form,
Among these are a phase-locked loop, a PLL, and two dynamic RAs.
M banks, DRAMs 1 and 2 are shown (36 and 37 respectively). RA
The multiplexed data / address bus entering or exiting MBUS® is an essentially 8-bit wide serial port with an attached clock.

The organization of the data buffers in DARAMs 35 and 36 is such that all (128 byte) even data buffers are on one bank and all odd data buffers are on the other bank. ing. The arbiter 902 determines the order in which various requests for data are loaded into the FIFO stacks 904 and 906. The buffer addresses in the request are even or odd, requests with even buffers are loaded into FIFO 904, and those with odd buffers are loaded into FIFO 906.

On condition that the FIRO is empty, the request is loaded into an even or odd FIRO and the interleaver 908 sends the request to the controller 910.
Since there are many requests, FIRO requests back up. Once the request backs up to both FIROs, the interleaver 908 will
Receive requests alternately from RO and others ("ping-pong operation"). Since these buffer addresses alternate between even and odd, the controller accesses the two different banks of RAMBUS in an alternating or interleaved manner. By this operation, the first bank is accessed when the second bank is precharged, and in the next access, the second bank is accessed when the first bank is precharged. This alternating access substantially provides the fastest access for writing or reading the RAMBUS and maximizes the RAMBUS memory throughput as long as there are requests on both FIRO stacks. On the other hand, purely FIR
Requests residing on the O base will have fractions in back-to-back even or back-to-back odd requests. So the timeout minutes are precharged.

Latency for a particular request occurs in the usual way. This method guarantees maximum utilization of RAMBUS in high traffic conditions. 10. Background Engine / Initialization An important part of the present invention is the use of BE to interface with the monitor and other MOM ports when making important decisions. This gives the BlazeWatch and Learn & Lock safety system access to configuration and control functions.

In FIG. 1, boot FLASH ROM 51 is provided to allow access to BE 50 for system initialization and startup. Boot ROM instructions run when there is a power up or a complete system reset. The boots are tested and verified to be maneuverable and reliable in the BE DRAM 53 section. This section is ISB code and B
This is where the lazeNet Runtime Journal (BeRT) exists. The first 1F (hex) or 32 (decimal) address of the ROM 51 holds the original interference vector. Address 20-7F holds ROM information, 80-FF holds console support interface routine, 1
00-4FF holds the MOM attribute table, 500-1FFF
B holds the boot image, and 1FFFC-1FFFF holds the boot image checksum of cyclic redundancy check (CRC). In this embodiment, the remaining BE DRAM 53 will be tested in parallel with the BeRT initialization process.

Boots may also be in BARK (background engine kernel), for example
Test the interrupt structure and operation to get the interrupt from the timer. Next, the boots initialize the I2C bus 62 and I2C
Assign addresses to chips attached to the bus. The boot then determines the ID of the bus chip. The boot looks up the ID of the found chip and the initializer is found in the boot directory downloaded for execution.

The main system image is present in the non-volatile storage 52 of the CompactFlash (registered trademark) card containing, for example, 10 megabytes of system software. Basic information is RE40 and MOM10 on I2C bus.
And 20. The full image is transferred on the DMA channel.

The above description is a preferred embodiment of the present invention at the time of filing. It is possible to replace them with uniform members and functions. Various mixed applications of hardware and software are possible. The present invention is very flexible and can be scaled. 11. Scheduling multimedia data streams Multimedia applications use reliable and unreliable data network communications. Control signals must be reliably received in the order sent. Control signals require a reliable form of communication. Audio and video data are usually carried in an uncertain transport protocol such as UDP. The real-time protocol standard consists of two protocols, a real-time control protocol (RTCP) running over TCP and a real-time protocol (RTP) running over UDP. These protocols provide thin shims over TCP and UDP transport layers to support multimedia communications. For example, the RTP header consists of a time stamp and a sequence number. The receiving station removes overlapping packets from the sequence packets and synchronizes the sound, video and data to achieve continuous playback. When there are multiple receivers, the sender uses IP multicast instead of duplicating the packet to each receiver. The receiver combines the IP multicast groups exchanged on the control channel and receives the packet. The H.323 standard generally uses the RTP protocol for delivery.

Multimedia applications require high quality services such as guaranteed bandwidth and weighted priority for timely packet transport. Having sufficient bandwidth for multimedia applications is essential for application integrity, but difficult to achieve in high volume data networks. In addition, the multimedia data must be content with all other data packets from non-real-time applications that cause the switch to easily interwork. These problems are eliminated by using multimedia application switches that keep the application evolving.

FIG. 41 shows a forward engine (FE) code and data DRAM 45 (FIG. 1).
Flow information data structure 1100, 1102 located in
Shows a part of the application policy record 1110. Each flow has two flow information data structures 1100 and 1102. The first flow information data structure 1100 is the flow direction from sender to receiver. The second flow information data structure 1102 is the flow direction from the receiver to the sender.

The flow information data structures 1100 and 1102 have a plurality of fields. The pre-hash data field 1115 holds information extracted from the data packet before the hashing process is performed. The extracted information is what is used in the flow identification process. Flow handler field 11
20 is a pointer to a software routine that completes the additional processes needed for a given type of flow. The flow queue instruction field 1125 includes an instruction for arranging a flow in a predetermined queue, and the number of predetermined queues is stored in the flow queue number field 1130. The flow byte and packet counter field 1135 holds the byte and packet count for the flow. Reverse flow data field 1
137 is two flow information data structures 1100 and 11
Link 02 together. The reverse flow data field of the sender / receiver flow information data structure 1100 has a pointer to the receiver / sender flow information data structure 1102 or vice versa. The application data field 1140 holds a pointer to the application policy record 110. In this example, the application data fields 1140 of both flow information data structures point to the same policy record, but they can point to different policy records. The flow maintenance data field 1145 contains software overhead to keep the data structure consistent within the switch.

The application policy record 1110 holds handling data and parameters of each type of flow passing through the switch. The application policy record shown in FIG. 41 includes 10 fields, multimedia application ID 1150, control policy ID 1155, and sender IP.
Address 1160, receiver IP address 1165, voice-sender port number field 1170, voice-receiver port number field 117
5, video-sender port number field 1180, video-receiver port number field 1185, video policy ID 1190 and video policy ID 1195.

The application switch monitors the new control connection set up between the sender and receiver. An example of a set-up criterion that can be used is the ITU H.245 protocol for multimedia data. When the control connection opens, the switch creates a new flow record for each direction 1100, 1102 of the flow. The flow records are linked together in the reverse flow data field 1137. The switch eavesdrops the exchange between the source and destination that provide the connection. Sources and destinations and exchanges are stored in the application data field 1140 of the flow records 1100, 1102. When the sender indicates the audio and video address (UDP port number) in the control channel, the application switch stores this information in the flow records 1100, 1102, locks up the policy for this application, and Prepare a subsequent part of the transaction by creating a new lookup record for the connection setup handler to switch the video.

If there are multiple receivers, the application switch gets the IP multicast group of audio / video data from the control connection and sets up one flow record used when packets from the application arrive. . Instead of the number of flow queues in the record, we have one queue list for each receiver. It then directs the queue manager to queue the packets into their respective queues. In conjunction with the queue manager's multicast transmission capabilities, it eliminates the need to prepare a separate copy of each receiver's packet.

FIG. 42 is a flowchart of the control connection process of the application switch. The receiving process of the application switch sends the packet received from the queue manager to a different handler and sends it out by instructing the queue manager to place the packet in a particular outgoing queue. There are three different handlers used to handle multimedia application packets. They are a connection setup handler, a multimedia control handler, and a policy handler for multimedia data.

When the receiving process of the application switch receives packets that have no entries in the hash table (block 1200), the switch sends these packets to the connection setup handler (block 1205). When the multimedia application is invoked, the first packet is between the sender and receiver. Connection setup handler is TCP
This packet is identified by matching the destination port number field in the header with the known port number specified in the IETF (block 121.
0). When the packet is identified as the start of a new multimedia flow, the connection setup handler creates two new flow records (block 1220). One is for the flow between the sender and the receiver, and one is for the flow between the receiver and the sender. A multimedia control connection handler is specified for these two new flows to program the relay engine hash table with the flow tag for the created flow record (block 1
220). All subsequent packets received from the sender and receiver are sent to the multimedia control connection handler (block 1225).
This handler listens in the packet and stores the information from them in the application data field of the flow record. Among the information exchanged between the sender and receiver is information about the number of ports for sending voice and video data. Once this information has been exchanged, the multimedia control connection handler saves the information locally and consults with the policy database to save the information for voice and video data (blocks 1230, 123).
5). Subsequently, a new entry is created in the transport lookup table used by the connection setup handler that indicates the policy used when the voice and video connections are initialized (block 1).
240).

FIG. 43 is a flowchart of the video and voice connection data flow.
When the first packet of a voice and video connection arrives at the switch, the receiving process sends it to the connection setup handler (block 1300).
). Since the connection setup handler has been primed by the multimedia q control connection handler, the policies that apply to these new flows are discovered (block 1305). Then a new record is created, a policy based on the policy for that application is specified, and the hash table is programmed with the flow tag for the flow record. Then, when the voice and video connection packets arrive, the receiving process sends them directly to the policy handler that sends them out (block 1315). All flows remain active until the flow record is discarded and an end-of-flow indication is received when the entry is removed (blocks 1320, 1).
325).

The above embodiments are for the purpose of explaining the present invention, and various modifications and improvements can be made within the scope of the present invention.

[Brief description of drawings]

FIG. 1 is a block diagram of a preferred embodiment of the present invention.

FIG. 2 is a media interface ASIC (MOM) of the preferred embodiment of the present invention.
Block diagram of.

FIG. 3 is a block diagram of the queue manager ASIC (QM) of the preferred embodiment of the present invention.

FIG. 4 is a block diagram of a relay engine ASIC (RE) of the preferred embodiment of the present invention.

FIG. 5 is a schematic diagram of the data flow of the preferred embodiment of the present invention.

FIG. 6 is a general household flow diagram used in the preferred embodiment of the present invention.

FIG. 7A shows the data structure of a standard header used in the preferred embodiment of the present invention. FIG. 7B shows the data structure of a portion of the standard header used in the preferred embodiment of the present invention. FIG. 7C shows possible entries for the data structure and another portion of the standard header used in the preferred embodiment of the present invention. Figure 7
D shows the data structure and possible entries of another part of the standard header used in the preferred embodiment of the present invention.

FIG. 8A shows the data structure of another portion of the standard header used in the preferred embodiment of the present invention. FIG. 8B shows possible entries for the data structure and another portion of the standard header used in the preferred embodiment of the present invention. FIG. 8C shows the data structure and possible entries of another part of the standard header used in the preferred embodiment of the present invention.

FIG. 9 is a block diagram of a high speed bus used in the preferred embodiment of the present invention.

FIG. 10 shows characteristics of the bus line of FIG.

FIG. 11 is a schematic of the transmit circuit used in the bus shown in FIG.

FIG. 12 is a timing diagram of the transmission circuit of FIG. Figure 1
2A is the composite timing of the transmit circuit of FIG.

FIG. 13 is a schematic of the clock delay used to propagate the bus shown in FIG. FIG. 13A is a timing diagram of the signals of the circuit shown in FIG.

FIG. 14 is a circuit detail of the circuit shown in FIG.

FIG. 15 shows the possible values and the meaning of the control bits used in the bus shown in FIG.

16 shows the order of the control bits shown in FIG.

FIG. 17 is a block diagram showing a token ring arbitration used between the interface chips shown in FIG. 1.

FIG. 18 shows the sequence of cell transmissions used in the preferred embodiment of the present invention.

FIG. 19 shows the pointer register configuration used in the preferred embodiment of the present invention.

FIG. 20A shows the data structure of a hash table entry used in the preferred embodiment of the present invention. FIG. 20B shows the data structure of another hash table entry used in the preferred embodiment of the present invention.

FIG. 21 is a timing diagram for the control signals used in the bus shown in FIG.

22 shows the possible values and the meaning of the control bits used in the bus shown in FIG.

23 shows an example of the order of control bits that may be found in the bus shown in FIG.

FIG. 24 schematically shows a cell transmission for the cells that may be transmitted to the bus shown in FIG.

FIG. 25 shows the possible values and the meaning of the codes used in the bus shown in FIG.

FIG. 26 shows the data structure of the standard header field used in the preferred embodiment at different times.

27 shows details of one data structure of the sub-field shown in FIG. 26. FIG.

FIG. 28 shows the data structure of a temporary “burst” header used in the preferred embodiment of the present invention.

FIG. 29 shows a series of details depicted in the data packet used in the preferred embodiment. FIG. 29B shows a series of details used in the preferred embodiment to delineate incomplete packets.

FIG. 30 shows a series of details used in the preferred embodiment to create a virtual cue.

FIG. 30B shows the association of buffer descriptors for receiving and transmitting the context table used in the preferred embodiment to track the data cells forming a packet.

FIG. 31 is a description of the credit managed transmission system used in the preferred embodiment of the present invention.

32 is a description of the ring pointer system used in the preferred embodiment of the present invention to determine whether credits should be issued to the system described in FIG.

FIG. 33 is a more detailed description of the system described in FIG.

FIG. 34 is a description of the hierarchical queuing system used in the preferred embodiment of the present invention.

FIG. 35 shows the data structure of a Transmit Context Table entry used in the preferred embodiment of the present invention. FIG. 35A shows the data structure of the field of the data structure shown in FIG. 35, and FIG. 35B shows the possible service policies symbolized in the Q SVC policy field of the data structure shown in FIG. Show.

FIG. 36 shows the data structure of the queue table used in the preferred embodiment.

FIG. 37 is a description of possible links and queues during the transmission phase of the preferred embodiment.

FIG. 38 illustrates the operation of the spare scheduler used in the preferred embodiment of the present invention.

39A illustrates a linked descriptor set illustrating a complete packet of memory in the preferred embodiment, and FIG. 39B is represented by the linked descriptors shown in FIG. 39A. FIG. 39A illustrates the separation of the descriptor set shown in FIG. 39A to free the buffer.

FIG. 40 is a block diagram of a DRAM control system used in the preferred embodiment of the present invention.

FIG. 41 is a flow information data configuration 1100, 1102 located in the previous engine code and data DRAM 45 (FIG. 1) according to the principles of the present invention.
Diagram of.

FIG. 42 is a flow chart of a control connection process of an applied switch according to the principles of the present invention.

FIG. 43 is a flowchart of a video or voice connection data flow according to the principles of the present invention.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE), OA (BF, BJ , CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, K E, LS, MW, SD, SL, SZ, TZ, UG, ZW ), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, C N, CR, CU, CZ, DE, DK, DM, DZ, EE , ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, K P, KR, KZ, LC, LK, LR, LS, LT, LU , LV, MA, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE (72) Inventor Naraya Swami, Krishna             Massachusetts, United States             01581-1770 Westborough Computer             Tadrive 2400, top layer             Networks, Inc. Within F term (reference) 5K030 GA01 GA08 HA08 HB13 HB18                       HB21 HC01 JA05 LC01 LC05

Claims (32)

[Claims] 1. A method for flexible connection of a receive physical path and a transmit physical path for a flow of data packets, the method comprising: (a) receiving a data packet of the receive physical path. And (b) determining whether the data packet is part of a setup sequence associated with a class of multimedia stream data and is identified as a predetermined flow, and if so, the multimedia stream. Applying the quality of service sequence of the transmission of packets identified as the class of data, and (c) transmitting the data packets that are part of the particular flow according to the quality of the applied service sequence. . 2. The step of determining whether the data packet is part of the setup sequence comprises comparing the contents of a field of the data packet with a particular pattern of information indicative of such a setup sequence. The method of claim 1 including the step of: 3. The step (c) of determining whether the data packet is the predetermined flow comprises the contents of a specific field of the data packet and a part of a start-up sequence for the predetermined flow. The method of claim 1, further comprising: comparing the contents of corresponding fields in the data packet previously determined to be 4. The method of claim 3, wherein the step of comparing the contents of the fields is accomplished by comparing the results of subdividing the fields. 5. The pattern of the information is ITU H.264. The method of claim 2, which corresponds to unique information in a setup data packet under the H.245 protocol. 6. The method according to claim 1, further comprising the step (a1) of dividing the received data packet into canonical cells immediately after receiving the data packet. 7. The method according to claim 6, wherein a data packet transmitting step (d) is performed, in which the data in each canonical cell extracted from the received packet is continuously transmitted. 8. The method of claim 6, further comprising storing each successive one of the cells of the received data packet in a memory location. 9. The method of claim 8, wherein the logical linking and arraying is accomplished by linking a cue pointer to each memory location where the cell is stored. 10. The method according to claim 9, wherein the quality of the service sequence is determined by an entry sequence of the queue pointer into a pointer table. 11. A method for flexible connection of an inbound physical path and an outbound physical path for a flow of data packets that are continuously converted into perceptual data by a human perceptible. , A method consisting of: (A) receive the data packet of the received physical path, (b) divide the received data packet into canonical cells, (c) for each successive one of the cells, (i) save the cell And logically link it to the previous cell, if it exists. (Ii) If the cell is the first cell of the data packet, comparing the contents of the fields of the cell with a specific pattern of information indicating such a setup sequence, the cell is a multimedia stream. Determining whether it is part of a setup sequence associated with a class of data and, if so, applying the quality of service sequence of the transmission of packets identified as the class of the multimedia stream data, iii) if the cell is the first cell of the data packet,
The data packet is identified by comparing the contents of the particular field of the cell with the internal use of the corresponding field in the data packet previously determined to be part of the startup sequence for the particular flow. Of the data packets that are part of the flow based on the link of the cell and the quality of the service sequence. 12. The specific information pattern is ITU H.264. 12. The method of claim 11, corresponding to unique information in a setup packet under the H.245 protocol. 13. The method of claim 11, wherein the quality of the service sequence is determined by a sequence of pointer entries in a pointer table. 14. The method of claim 11, wherein the step of comparing the contents within the field is accomplished by comparing the results of subdividing the field. 15. The method of claim 11, wherein each stored and linked cell is arranged for transmission. 16. The method of claim 11, wherein step (c) (i) further comprises arranging the stored and linked cells for transmission. 17. The logical linking and arraying is accomplished by linking a cue pointer to a corresponding memory location where the cell is stored.
The method described in. 18. The method according to claim 17, wherein the quality of the service sequence is determined by the sequence of entries in the pointer table to the queue pointer. 19. A device for flexible connection of a receiving physical path and a transmitting physical path for a flow of data packets, which device comprises: Means for receiving the data packet of the reception physical path. Setup sequence means for determining whether the data packet is part of a setup sequence associated with a class of multimedia stream data. Quality of service means for applying the quality of service sequence to the data packet if it is part of a setup sequence. Flow determining means for determining whether or not the data packet is specified as a predetermined flow. And transmitting means for transmitting the data packet of the specific flow according to the quality of the service sequence. 20. The setup sequence means further comprises first comparison means for comparing the contents of the field of the data packet with a specific information pattern indicating a specific setup sequence. The device according to. 21. The flow determining means further includes the contents of a specific field of the data packet and a data packet of a data packet previously determined to be part of a startup sequence for the specific flow. 20. Apparatus according to claim 19, comprising second comparing means for comparing with the content of the corresponding field. 22. The apparatus of claim 21, wherein the second comparing means further comprises means for comparing the subdivision results of the fields. 23. The information pattern is ITU H.264. 21. The apparatus of claim 20, corresponding to singular data in a setup data packet under the H.245 protocol. 24. The apparatus of claim 19, wherein the receiving means further comprises means for dividing the received data packet into canonical cells immediately after receiving the data packet. 25. The apparatus according to claim 24, wherein the transmitting means continuously transmits the data in each of the canonical cells extracted from the received data packet. 26. Storage means for storing each successive one of said cells of said received packet in a memory location, and logically linking said stored cells for transmission, 25. The apparatus of claim 24, further comprising arranging means for arranging. 27. The apparatus of claim 26, wherein the arranging means further comprises means for linking a cue pointer to a corresponding memory location where the cells are stored. 28. The quality of service means further comprises an entry sequence in a pointer table to the queue pointer.
The device according to. 29. An apparatus for flexible connection of a receiving physical path and a transmitting physical path for a flow of data packets, the apparatus comprising: An interface connected to the reception physical path and the transmission physical path. A multimedia data stream detector connected to the interface for determining whether the data packet is associated with a particular multimedia stream data class. A flow detector connected to the interface for determining whether the data packet is part of a particular flow. A queue manager that allocates the transmission of the data packet to one of a plurality of queues corresponding to the flow detector and the multimedia data stream detector, the allocated queue providing a particular quality of service. . 30. A network switch for flexible connection of a receiving physical path and a transmitting physical path for the flow of data packets, which comprises: A network interface connected to the reception physical path and the transmission physical path to receive a data packet. A sending engine connected to the network interface for determining whether the data packet represents a particular class of multimedia stream data, and whether the data packet is part of a particular flow. Sending engine for making decisions. And a queue manager connected to the sending engine for managing the time of transmission of the data packet according to the determination of the sending engine. 31. A network switch for flexible connection of a receiving physical path and a transmitting physical path for the flow of data packets, which comprises: A network interface for receiving and sending data packets. A memory for storing the data packet. A database with stored data about multimedia data streams. A microprocessor connected to the memory for determining whether the data packet represents a multimedia data stream using stored data in the database, the microprocessor further comprising: , The microprocessor determines the quality of service in response to the determination of the multimedia data stream ribbon flow. Further, a queue manager that sends the data packet according to the quality of service. 32. A method for flexible connection of a receive physical path and a transmit physical path for a flow of data packets, the method comprising: (A) receiving a data packet from a sender to a receiver on the receiving physical path; (b) setting up the data packet by identifying at least one multimedia data flow port number in the data packet. Identifying a multimedia data flow by determining whether it is part of a sequence, and (c) said for audio and video port numbers used to transmit data packets in said multimedia data flow. Intercepting exchanges to establish a connection between sender and receiver, and (d) depending on the audio and video port number, the quality of service to be applied to subsequent data packets in the multimedia data flow. (E) according to the quality of service , Sending subsequent data packets of the multimedia data flow.