Routing arbiter for data network switching

The present application is a non-provisional application of provisional application serial No. 60/086,902, filed May 27, 1998.

An apparatus commonly known to persons skilled in the art of data communications as a data network switch, is used to interface between a plurality of network segments. The apparatus works in a way that allows a plurality of simultaneous independent data transactions on different network segments, one transaction on each segment, while concurrently enabling a plurality of data transmissions between segments whenever such transmissions are requested. A central routing controller receives routing requests from the plurality of segments and attempts to connect the requesting segment to the requested destination segment when the request is routable. A request is considered routable when both the requesting source segment and the requested destination segment are idle, which means neither is engaged in data communications with any other segment at the time of the route change. In the prior art, the requesting segments send their routing requests to a queue, which lines-up the requests and attempts to establish the requested route if both the requesting source and the requested destination are idle. In case a routing request of the first request in line is not readily available this request and all other subsequent requests in the queue must wait until the requested route becomes available. This case is called a Head of Line Blocked route case and is the most undesirable case as it delays all subsequent routing requests in the queue. The present invention describes a routing arbiter which optimizes the process of routing of available routes and minimizes Head of Line routing blockage.

The routing arbiter described herein maintains a list of all pending route requests and receives information of all idle sources and destinations. Whenever a request for routing exists when both the destination and the source are simultaneously idle, the arbiter grants permission to execute that request, where the criteria for such grant is not the order of the requests within the queue but rather a set of programmable priority parameters. The uniqueness of this invention is in the way it processes the pending requests. It does not do it on an individual basis, handling one request at a time, but instead processes all the pending requests simultaneously.

This invention describes a device intended to solve “Head of Line Blocking” problems associated with routing queues in computer data network switches. Such queues typically store all pending routing requests, and processes them in the order of their arrival. If the request at the head of the queue can not be processed and the requested routing cannot be granted because of a busy requested source or destination at the time of process, all other pending request cannot be processed until the head of the queue is cleared. All pending requests are processed simultaneously, thus there is no “Head of Line” in the queue. Instead the decision and the selection of the request to be granted at the time of processing is based on a programmable priority scheme. Further, all pending requests are compared simultaneously with all idle sources and destinations. A request is considered routable if both the requesting source and requested destination in that particular request match with an idle source and an idle destination. If more than one request is routable at the time of the processing, the routable request with the highest priority is granted. This priority scheme equates to a virtual prioritized queue. Several virtual queues can exist side by side. Priorities can be applied within each virtual queue and also between the queues. If desirable, more than one request may be granted in any single processing period. The process of examination of all the pending routing requests repeats itself in a cyclic fashion, once per each clock cycle.

FIG. 1 is a block diagram of an arbiter according to the present invention.

FIG. 2 is a typical routing request data format.

FIG. 3 is a conceptual block diagram of the arbiter's register stack.

FIG. 4 is a logic circuit used in each arbiter slice to find a match between a pending request and available idle resources.

FIG. 5 is a conceptual block diagram of the priority determination, and the bandwidth allocation mechanism which controls the routing chances for the various virtual queues.

FIG. 6 depicts the method by which the age of pending routing requests is determined for the purpose of retirement.

FIG. 7 is a typical output bus data format.

The circuit description is best understood in conjunction with FIGS. 1 through 7. The arbiter ( 9 ) receives Routing Request Commands (RRC) via down a route request bus ( 1 ), which is W bits wide, in the format shown in FIG. 2 . The number of bits in each group and the total number of bits in the bus varies, depending on the number of ports in the network switch serviced by the Arbiter and other design parameters. In general the route request word is composed of six groups of bits: The first group is n bits wherein each bit used to indicates one requesting (source) port. Only one of the n bits in the group can be set within a single RRC. The second group is m bits wherein each bit indicates one of m requested (destinations) ports. Any number of bits out of the m bit in the group may be set within a single RRC. The third group of q1 bits is used to identify a particular message for which that RRC is issued. The fourth group of q2 bits includes a time stamp indicating the time of issuance of that routing request. The fifth group of q3 bit is used to assign a single or several priority levels and other processing information to that route request. The last group of q4 its constitutes a tag that indicates the validity of that route request.

The Routing Request Commands are stored in the order of arrival, in the register stack ( 2 ) which serves as a processing pool memory. FIG. 3 shows a detailed block diagram of the register stack ( 2 ). This register stack ( 2 ) is constructed such that received routing requests ( 15 ) get stored in the stack in an orderly fashion from the bottom up. The first request to arrive is placed in the bottom slice of the stack ( 2 ). When a second request arrives, it is placed in a slice just above the previous one. This method of storage arranges the received routing requests in the order of their arrival with the least recent ones at the bottom and the most recent ones on top. When a request is deemed routable, the multiplexer ( 6 ) selects the data from the associated register, and that data is provided as the “granted” routing instruction ( 7 ). Consequently the register from which the granted routing instruction was read, is purged and data stored in all the stack slices above the purged slice are shifted down one location to fill up the void in the stack ( 2 ).

FIG. 4 shows the structure of the register stack ( 2 ). The stack has n slices, wherein each slice has a register ( 11 ) and a multiplexer ( 10 ). The register ( 11 ) and the multiplexer ( 10 ) are each W=(m+n+q1+q2+q3+q4) bits wide. This combination of register and multiplexer enables each slice to execute three modes of operation:

1. Receive and load data directly from the input bus ( 15 ).

2. Receive and load data from an adjacent slice to perform a SHIFT operation.

3. Hold the data stored in the register ( 11 ) unchanged.

The multiplexer ( 10 ) of each slice has its own control input ( 13 ), thus the modes of operation described above may be localized whereas part of the register stack ( 2 ) may be in the HOLD mode, another part in the SHIFT mode while another part may be in the LOAD mode.

Each slice in the register stack ( 2 ) has an associated matching comparator in the comparator stack ( 3 ). Each comparator receives the requesting source and the requested destination data (bit groups n and m) from the associated register in the register stack ( 2 ). It also receives information on all the idle sources and destinations ( 4 ). The details of a typical comparator are shown in FIG. 4 . In the comparator, two sets of AND gates ( 30 ) are used to find matches between requests and idle resources. In the first set, idle sources ( 33 ) are matched with requesting sources ( 34 ). A bit indicating an idle source is in the logic “1” state when that source is idle. Of all the bits indicating the requesting sources ( 33 ), only one bit may be at the logic “1” state in any single RRC. Therefore only one of the gates in this group of gates will have an output logic state of “1”. In the second group of gates the idle destinations bits ( 35 ) are matched with requested destinations ( 36 ). In this group multiple matches can exist in any single RRC. The outputs of the AND gates ( 30 ) of each group are summed up by the OR gates ( 31 ), the output of which is applied to an AND gate ( 32 ). The output state of either OR gate ( 31 ) is logic “1” whenever any match exists in the AND gates ( 30 ) in front of them. The output of the AND gate ( 32 ) will be a logic “1” match ( 37 ) only if both the outputs of the OR gates ( 31 ) are logic “1”. The result of this process is a MATCH output ( 37 ) only when a match is found between a requesting source and an idle source simultaneously with a match between a requested destination and an idle destination. The outputs of all the matching comparators in the comparator stack ( 3 ) are fed to the priority encoding stack ( 5 ), along with the q3 bits of the associated register in the register stack ( 2 ), which indicate the assigned priority of the matching request. The priority encoding stack.( 5 ) also receives a bandwidth allocation instruction ( 8 ) to control the allocation of routing resources between the various virtual queues and assigned priority levels. The priority encoding stack like all of the arbiter is constructed in a slice form, one slice for each register (slice) in the register stack ( 2 ). FIG. 5 shows the details of the priority encoding stack ( 5 ). It depicts a typical case of four virtual queues ( 21 ) and 256 priority encoding slices but the actual number of queues and slices may vary. In the priority encoding stack ( 5 ), matching data ( 24 ) comes in from the associated comparator slices in the comparator stack ( 3 ). Each encoder slice in the priority encoding stack ( 5 ) determines the priority and the disposition of matches determined in the comparator stack ( 3 ) slice it is associated with. Each slice ( 22 ) in the priority encoding stack ( 5 ) makes the decision with regards to the routing request stored in the register stack ( 2 ) associated with it. The priority encoding stack ( 5 ) slice output ( 25 ) directly controls the multiplexer ( 11 ) in the corresponding register stack ( 2 ) slice via the control lines ( 13 ), as well as the selection and readout of the granted routing instructions and the purging of the corresponding register. The multiplexer ( 6 ) is also controlled by the priority encoding stack. It selects and delivers the routing instruction determined by the arbiter to the output buses ( 7 ). An output bus includes s bit to identify the source of the requested route, t bit to identify the selected rote destination, and z bits to specify special modes, instructions, or services derived from the q1 bits in the associated routing request, as shown in FIG. 7 .

Since routing requests in the queue are processed based on routability combined with assigned priorities, certain requests may end up staying in the register stack ( 2 ) for an excessive length of time may have to be deleted as “over-due” or “unroutable”. In the way the register stack ( 2 ) is constructed, the most recent entry is always on top, and the least recent entry at the bottom of the stack. Therefore the bottom slice in the register stack ( 2 ) is equipped with a request age comparator as shown in FIG. 6 . The real time counter ( 40 ) indicates the time at the instance of the observation. The subtractor ( 41 ) subtracts the time of issuance of the request stored in the register at the bottom of the stack ( 2 ), provided by the q2 bits in the register. The output of the subtractor ( 41 ) represents the duration of time the request had been waiting for processing known as the request age. The second subtractor ( 42 ) subtracts the request age generated by the first subtractor ( 41 ) from the programmable “retirement” age stored in the register ( 43 ). If the output of the subtractor ( 42 ) is a negative number ( 44 ), it indicates that the request stored in the register at the bottom of the stack ( 2 ) is over the age of retirement and is to be deleted. This causes the purging of the bottom slice register, and a subsequent shift down of all other slices in the stack.