Distributed –Queue, Dual Bus DQDB

These notes are divided into hyperlinked sections

Distributed –Queue, Dual Bus
Bus Transmission Scheme
Slot Structure
The DQDB Protocol
Reservation Requests
The Counting Mechanism for DQDB
Example of operation of DQDB Protocol


This lecture is designed to give an insight into the methods used by stations in a LAN to gain access to the shared medium. The differences in methods used will prove useful when the design of any MAC is considered.

MAC methods are required to allow a set of nodes or stations that share a common medium to gain access to the shared medium in some sort of controlled manner. You should alredy be familiar with the methods of MAC used by Ethernet and Token Ring LANs.

Distributed–Queue, Dual Bus

This MAC protocol has been standardised by IEEE 802.6 committee as a part of its MAN standard. This protocol is intended to be used on a dual-bus configuration.

Fig 4.1 Basic Operational layout of DQDB protocol

To help understand the operation of the DQDB protocol, let us define the following terms.

Bus Transmission Scheme

Both bus A and B contain a steady stream of fixed length slots of length 53 octets or bytes. Each node is able to read data from and write to each of these slots. The slots on bus A and B are generated by head(A) and head(B) respectively. Both streams of slots are absorbed by the bus terminators, shown above as grey boxes.

The network is controlled by a 125 msec clock. Both head(A) and head(B) generate and transmit multiple slots to their respective buses every 125 mseconds. The actual number of slots generated during this clock cycle is determined by the physical data rate of the bus.

Slot Structure

Each slot is 53 bytes long, the first byte being the Access Control Field, the other 52 bytes being for data. There are two types of slots, queue arbitrated (QA) and pre-arbitrated (PA) slots. QA slots are formed to carry packet-switched data types and PA slots are to carry circuit-switched data types.

By the nature of circuit switching, it is necessary to issue a dedicated stream of slots for each node wishing to perform circuit-switched data transfers, otherwise the utilisation of the switched circuit will fall to an unacceptable level. The operation of the PA arbitration scheme has not yet been standardised. This discussion will concentrate on QA slots.

Fig 4.2 Diagram of DQDB protocol slot structure

One bit within the access control field is toggled to indicate whether the packet is free or busy. Another bit in the access control field is toggled to represent a reservation request has been issued.

The DQDB Protocol

The distributed queue access protocol provides access to the QA slots on the DQDB medium. The operation of this protocol relies on there being two buses running in opposite directions. This symmetry allows the discussion of bus(A) to equally apply to bus(B).

The distributed queue access protocol is a distributed reservation scheme and takes into account the bus symmetry.

Let us look at the example of two nodes in the network. Node N wishes to transmit to node P so N must decide on which bus P is downstream of N. Let us assume that this is bus(A). This means that P is downstream(A) of N, as shown below.

Fig 4.3 Diagram to illustrate the relative positions of nodes N and P

For N to transmit to P, it must use an available slot originating from Head(A) i.e. upstream(A). However, if the nodes upstream(A) monopolise the medium and there are no free slots, N will be unable to transmit. To get round this, N must reserve a slot(s) from its upstream(A) peers. To communicate with its upstream(A) peers, N must use bus(B) to communicate this reservation as N’s upstream(A) peers are also downstream(B) and will be able to receive a reservation request from N on bus(B).

The operation of the DQDB protocol dictates that any node wishing to transmit must postpone its own need to the needs of its downstream peers. At any time, a node that has downstream peers with reservation requests must not transmit. This allows unused slots to continue downstream for the use of these downstream peers. Thus the protocol is based around a mechanism that allows each node to keep track of all reservation requests from its downstream peers.

There are four positions of significance with respect to bus(A). Refer now back to figure 4.1.

1 Node 0 (i.e. head(A)) is responsible for generating the QA slots on bus(A). Because head(A) is the source of slots for bus(A), bus(A) will contain no slots addressed to node 0. Thus all QA slots originating from head(A) will be free slots. If this node wishes to transmit, it inserts the data on the next QA slot that it generates (having satisfied all outstanding slot requests received from bus(B). Because it has no upstream(A) peers, node 0 has no need to issue reservation requests. Head(A) must ensure that outstanding reservation requests in addition to its own needs are satisfied in a fair (round-robin or first-come-first-served) manner. It does this by placing reservation requests in a stack, and every time that it issues a free QA slot it discards the oldest request for a slot. When head(A) has its own data to send, it generates an internal request that is placed on the base of a FIFO stack. Any subsequent requests will be added to the stack after head(A)’s request for a slot. After the required number of slots have been issued, head(A)’s request arrives at the top of the stack and head(A) issues a busy QA with its own data addressed to the destination.

2 At the opposite end of bus(A) is node (N-1) or head(B). This node has no downstream(A) nodes and therefore does not transmit on bus(A). Being the source of slots for bus(B) it does not need to issue any reservation requests on bus(B). Its only data transfer activity on bus(A) is to monitor the slot stream for any QA slots addressed to itself which it then copies.

3 The closest node upstream(A) of head(B) is node (N-2). If this node wishes to transmit a segment of data it must first issue a request on bus(B) for an available slot on bus(A). This is achieved by setting a request bit in a passing slot on bus(B). Node (N-2) makes reservations on bus(B) but never receives any reservation requests on bus(B) because the only node upstream(B) is head(B) and as discussed in the previous paragraph, head(B) does not need to issue reservation requests on bus(B). Node (N-2) receives slots addressed to itself from bus(A). If node (N-2) wishes to transmit to node (N-1) it issues a reservation request on bus(B) and then may transmit its data segment onto the first free slot that passes on bus(A). There is one bit in each slot that indicates whether the slot is available or busy.

Reservation Requests

The reservation requests are kept track of by head(A). This is the difference between incoming QA slots on bus(B) with the reserve bit set and outgoing free QA slots.

4 Any other node lying in between head(A) and node (N-2), here labelled as node x. This node receives data addressed to it from bus(A). In a similar fashion to node (N-2), whenever node x wishes to transmit it must issue a reservation request on bus(B) for a free slot. In addition to this, similar to head(A) it must also keep track of all reservation requests that arrive on bus(B) so that its own requests are handled in a fair manner. To enforce the round-robin approach, node x must keep track of all reservation requests that precede and follow its own request for a free slot on bus(A). Thus when node x has data to send (at some time T) and has issued its own reservation request, it may transmit its own data when the number of free slots that have passed on bus(A) since time T is equal to the number of requests for slots received from upstream(B) before time T.

The behaviour of the nodes as discussed above may be summarised as in the tables below

Behaviour of head(A)
At the moment that head(A) is ready to issue the next QA slot:
Status of Head(A)
No preceding requests outstanding
One or more preceding requests outstanding
Head(A) has no data to send Issue a free QA slot (busy bit set to zero. Issue a free QA slot and reduce the count of preceding requests by 1.
Head(A) has a segment of QA data to send Issue a QA slot containing the data it wishes to transmit; busy bit set to 1, destination address and data inserted; following requests, if any now become preceding requests. Issue a free QA slot and reduce the count of preceding requests by 1.

At the moment that head(A) receives the next QA slot on bus(B):
Status of Head(A)
Incoming slot contains a request
Incoming slot does not contain a request
Head(A) has no data to send Add 1 to count of preceding requests No action
Head(A) has a segment of QA data to send Add 1 to count of following requests No action

Behaviour of node x
At the moment that node x observes a free QA slot on bus(A):
Status of node x
No preceding requests outstanding
One or more preceding requests outstanding
node x has no data to send Let free slot pass. Let free slot pass and reduce by one the count of preceding requests.
node x has a segment of QA data to send and has previously issued a reservation request on bus(B) Set the busy bit to 1 on the passing slot and insert data; following requests, if any, now become preceding requests. Let free slot pass and reduce by one the count of preceding requests.

At the moment node x observes a QA slot on bus(B)
Status of node x
Incoming slot contains a request
Incoming slot does not contain a request
Node x does not have an outstanding request Add 1 to count of preceding requests No action
Node x has a segment of QA data to send and has already issued a request for that segment Add 1 to count of following requests No action
Node x has a segment of QA data to send and has not yet issued a request for that segment Add 1 to count of preceding requests  

The counting mechanism for DQDB

The DQDB protocol is implemented by a distributed collection of FIFO stacks. At each node a queue is formed for each bus and for each reservation request that is observed passing, the node increments the stack by one. When the node itself wishes to transmit it adds an item to the queue for itself. When this item arrives at the top of the stack, the node may then transmit in the next passing free QA slot. Each node may only have one request for itself in the queue at any one time, bearing in mind that the symmetry of the scheme allows for two stacks per node.

The nodes therefore have a pair of counters for each bus. These are known as request count, RQ and countdown count, CD. During the times that a node has no data to send it keeps track of reservation requests received from bus(B) by noting for each passing QA slot whether its request bit is set. Each time that a request bit is observed to have been set the request count, RQ, is incremented by one. Simultaneously the node also monitors the slot flow on bus(A). Every time a free slot passes the node it decrements the requisite RQ stack by one down to a minimum of zero.

Thus at any given time, the RQ status (an integer, sRQ) represents the un-met need for free QA slots by the node’s downstream(A) peers. This means that the node must allow sRQ free QA slots to pass on bus(A) before it is able to use a QA slot to transmit. When this node does wish to transmit on bus(A) it issues a request on bus(B) as soon as possible. Ideally this should be the first slot passing on bus(B) that does not have its request bit already set by an upstream(B) peer. Whilst waiting for a slot that has not had its request bit set, the node must also monitor the passing requests from bus(B) and increment the RQ stack. When the first slot arrives on bus(B) that has not had its request bit set by upstream(B) peers, the node can change that slot’s request bit to one and allow it to pass. Simultaneously, the current value of count on the RQ stack, sRQ is transferred to the countdown count stack, CD and RQ is set to zero. Now CD has an integer value sCD. The node then continues to monitor both the requests received on bus(B) and increments sRQ for each reservation request received and also monitors the free slots on bus(A), decrementing the CD stack count, sCD by one each time a free slot passes until sCD is equal to zero. At this time the node may transmit on bus(A) using the next free passing QA slot. This effectively maintains a single FIFO stack into which a node may issue its own request.

The above method of queue formation ensures that a slot is never wasted if there has been a request for a slot to transmit issued. The CD count in the queued nodes represents the number of reservation requests that have been queued ahead. At any time, one of the requests must have queued first so at least one node is guaranteed to have a CD count of zero and that node will be able to use the next passing free slot.

Example of operation of DQDB Protocol

In the discussion below, we shall consider a section of a network where none of the nodes is either head(A) or (B). The discussion is also limited to transmission on bus(A) but due to the symmetry of the system, the argument can be applied to bus(B).

For the slots, the first bit represents the busy bit and the second represents the reserve bit.

Initially the network is free and there are no outstanding requests for slots. All nodes have a RQ value of zero

Fig 4.4 (a)

Node E issues a request for a slot by flipping the request bit on a slot passing along bus(B). All downstream(B) nodes increment their RQ stack by one. Simultaneously, node E transfers its RQ count to its CD stack. Because RQ was zero, CD is zero too, so node E may use the next free QA slot that arrives on bus(A).

Fig 4.4 (b)

Node B now issues a request on bus(B). Node B then transfers its sRQ value to its CD stack and sets sRQ to zero. This node will have to wait while one free slot passes on bus(A) before it can transmit. Node A sees the set request bit as it passes and sets its sRQ to 2.

Fig 4.4 (c)

Node C issues a reservation request on bus(B). C sets sCD to the value held by sRQ previously and sets sRQ back to zero. Nodes B and A respectively increment their RQ values as the slot passes. Note that B’s CD value remains 1.

Fig 4.4 (d)

A free slot passes down bus(A). Nodes A and D decrement their RQ stacks. Nodes B and C decrement their CD stacks. Node E now has sCD value of zero and so can use the next free slot by changing the busy bit from 0 to 1 and inserting a QA segment.

Fig 4.4 (e)

Another free slot passes down bus(A). Node A decrements its RQ count. Both nodes B and C have sCD value of zero and so are eligible to use the next free slot. Because node B is upstream(A) of node C, it is node B that utilises the next free slot. B changes the slot’s status to busy and inserts a QA segment.

Fig 4.4 (f)

Node C uses the next passing free slot to transmit. Nodes A and B decrement their RQ stack. The system now returns to its original state where all nodes have sRQ value of zero.

Note that the three requests were serviced in the same order as that in which they were issued. It can be seen that this type of MAC technique acts as a FIFO stack.


This protocol is extremely effective under all load conditions. During light network load conditions, sCD will be small or zero and there will be an abundance of free slots and so delay will be negligible, akin to CSMA/ CD protocols.

Under heavy network loads, nearly every free QA slot will be used by one of the waiting nodes and network efficiency approaches 100% akin to token bus and token ring protocols. These characteristics of quick access under heavy load and predictable queuing under heavy load makes this protocol suitable for MAN implementation, in situations of high data rate where the traffic will be a mix of bursty traffic as caused during interactive use and more sustained stream-like traffic such as arises during file transfers.

MM Clements 2000