An emulator for evaluating DQDB performance

Computer Networks and ISDN Systems 25 (1993) 1177-1204 North-Holland

1177

An emulator for evaluating DQDB performance Ma-Tit Yap and David Hutchison Computing Department, Lancaster University, Lancaster, LA 1 4 YR, UK

Abstract Yap, M.-T. and D. Hutchison, An emulator for evaluating DQDB performance, Computer Networks and ISDN Systems 25 (1993) 1177-1204. This paper presents the design and implementation of a DQDB network emulator, developed at Lancaster University. The emulator uses standard Unix processes and System V named pipes to create a model of a Distributed Queue Dual Bus subnetwork of a Metropolitan Area Network. Apart from gaining insights into the DQDB protocol implementation based on a finite state machine model, the goals of the work reported in this paper included the performance evaluation of DQDB networks and the provisioning of a suitable platform to investigate various isochronous service management issues. The paper provides results on the operations of the distributed queue state machines and on the performance evaluation of DQDB networks. Finally, future developments of the emulator are identified. Keywords: emulator; DQDB; MAN; performance evaluation; isochronous service.

1. Introduction Multiservice networks have been proposed as the future means of supporting distributed multimedia applications and systems. However, because of the variety of technologies and considerable ongoing development of these networks, there is a need for performance evaluation to be carried out via emulation as these technologies are not readily available at present. Various approaches are taken to emulate multiservice networks as platforms for research in distributed multimedia systems, including the following. The first approach uses independent analogue networks (circuits) for each continuous medium. One example is the IMAL project at Bellcore [24]. Typically there will be analogue audio and video switches in addition to the more common data switch. The data switch is usually an ethernet local area network. Each multimedia workstation consists of a traditional workstation such as a Sun, plus a video monitor, a camera, a microphone and Correspondence to." D. Hutchison, Computing Department, Lancaster University, Lancaster, LA1 4YR, UK. Email: dh (d,comp.lancs.ac.uk.

a speaker. These devices are connected to their respective networks and are under the control of the data network. This approach has the advantage of building on top of existing communication technologies to enable research into distributed multimedia applications without having to wait for the arrival of multiservice networks. The second approach is based on individual digital circuits for each continuous medium. This is the approach taken by the Cruiser/Patch Cords [4] and Touring Machine [1] projects at Bellcore. In this case the audio and video terminations at each workstation are digital in nature, but each continuous medium is still connected through a separate digital circuit. These digital circuits may be from one fibre-optic based ATM switch. The advantage of this approach is that the terminations at each workstation are digital and this brings us one step closer to the realisation of multiservice networks. The third approach is the direct realisation of multiservice networks. Each multimedia workstation has only one point of connection to the multiservice network. Continuous media are handled in the same hardware and software framework as other data. The digitised audio, video and data are all transported on the same network. The

0169-7552/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved

1178

M.-T. Yap, D. Hutchison / DQDB emulator

network has to ensure that it can guarantee that delay and jitter for the digitised audio and video are within the acceptable tolerance limits. These networks include the Broadband Integrated Services Digital Network (B-ISDN) based on Asynchronous Transfer Mode (ATM) technique [11, 16], the Distributed Queue Dual Bus (DQDB) subnetwork of a Metropolitan Area Network (MAN), and the Fibre Distributed Data Interface II (FDDI-II). This paper describes the design and implementation of a DQDB network emulator. A performance evaluation of DQDB networks is also presented. Most simulations use either the event scanning approach or the process interaction approach 1-14]. Some simulation techniques do not scan events in equidistant time units, but event handling jumps from event to event. Usually a list processing mechanism is used to schedule the arrival of events. In our DQDB emulator, we adopted a combination of event-by-event scanning and process interaction approach. However, the scheduling of the arrival of events is not based on list processing. Instead, a default slot generator node process actually generates the DQDB queue arbitrated and pre-arbitrated slots, complete with the three request priority levels, on both forward and reverse buses and passes them between processes which emulate the protocol. Both transmit and receive functions are implemented. A more detailed DQDB model can be built using this emulator approach. The advantages of the emulator over a simulation,

in particular, in performance evaluation of DQDB networks, include a complete insight of DQDB behaviour and the capability of carrying out more diverse experiments. In Section 2 we discuss the main characteristics, protocol data unit hierarchies and the slot access control mechanisms of DQDB networks. Section 3 presents the design and implementation of the DQDB network emulator software in outline, and finally the performance evaluation of DQDB networks under various operating conditions is reported in Section 4.

2. DQDB networks

2.1. Overview Distributed Queue Dual Bus (DQDB) is the standard for IEEE P802.6 Metropolitan Area Network (MAN). It evolved from the Queued Packet Synchronous Exchange (QPSX) proposal [3, 28, 29] submitted by Telecom Australia and has gone through many revisions [12, 19, 31]. Draft D15 [20] is the final draft. A metropolitan area network [23, 32] typically covers a geographical area of 50 km in diameter. The motivations behind the development of metropolitan area networks are manifold. These include high-speed transmission, longer distance, multiservice capabilities and interworking with ATM-based B-ISDN networks.

Ma-Tit Yap graduated with first class honours in computer engineering at the City University, London, in 1979. He has extensive industrial computing experience having worked for Plessey (UK) and AT&T Consumer Products, Singapore. Currently, he is on study leave from the Nanyang Technological University, Singapore, where he is a lecturer in the Computer Technology Division of the School of Applied Science. His research interests lie in computer networking, distributed computing and multimedia systems, on which he is working towards a M.Phil. degree at Lancaster University.

' David Hutchison is Professor in computing at the University of Lancaster and has been actively involved in research in local area network architecture and distributed systems applications for the past nine years, first at Strathclyde University, then (since 1984) at Lancaster. He is an investigator in the ESPRIT-funded "OSI 95" project and in the recently-started DELTA "JITOL" project. The main theme of his current research is architecture and protocols for distributed multimedia systems. He is seconded part time as technical consultant in Communications and Distributed Systems at the IT Division of the Department of Trade and Industry (DTI) within the UK SERC/DTI Joint Framework for Information Technology.

M.-T. Yap, D. Hutchison / DQDB emulator

1179

Bus B

Fig. 1. Open dual bus topology (left)and looped dual bus topology (right). Key: HOBA = head of bus A, HOBB = head of bus B, DSG = default slot generator, ETS = external timing source.

A new protocol like D Q D B is essential because all of the existing local area network (LAN) protocols do not meet these new requirements; for example, CSMA/CD (ethernet) and token ring networks lack the multiservice capabilities and the ability to interwork with ATM-based networks like B-ISDN. Basically there are three potential application areas of D Q D B networks. They could be used to implement a backbone network for lower speed LANs, as an access network to future ATM-based B-ISDN, and as a multiservice network supporting distributed multimedia applications. The technology of the Switched Multi-megabit Data Service (SMDS) 1-12, 17], a public packet-switched data service from Bellcore, is based on the IEEE 802.6 standard. Its interface and associated protocols are based on the connectionless part of the DQDB MAC standard. A D Q D B network is made up of two unidirectional, contra-flowing, high-speed buses. For a stable network, both buses must be running at equal speed. All nodes on a D Q D B subnetwork are attached to both buses with two attachments to each bus; an upstream read tap and an downstream OR-write connection. However, there is only one path of transmission between any two nodes because the buses are uni-directional. A D Q D B network uses a slotted transmission structure. A continuous train of short, fixed length slots is usually generated by the node located at the head of a bus, known as a default slot generator. The D Q D B slots propagate downstream and are eventually discarded by the node situated at the end of the bus. Figure 1 illustrates the two topologies of a D Q D B network; open dual bus and looped dual bus. A D Q D B network configured in either open or looped dual bus topology has the inherent capabil-

ity to reconfigure when node or link failures occur. Simultaneous occurrences of multiple node or link failures will result in isolated islands of D Q D B subnetworks. Due to the asymmetric nature of slot generation, four types of node are defined. In an open dual bus topology, the two nodes at the extreme ends are the Head Of Bus A and Head Of Bus B (HOBA, HOBB). The other nodes are known as ETS nodes since they derive timing information from an External Timing Source (ETS). In a looped dual bus topology, the network is wrapped around. The slot generating functions for both buses are combined into one node known as the Default Slot Generator (DSG). Timing is generated from the received data stream, even at the head of the bus. One node, not necessarily HOB, may receive timing from an external source; this timing is passed around the network. 2.2. Protocol data unit hierarchies

Two classes of service are provided in a D Q D B network; the asynchronous service and the isochronous service. The protocol data units supporting these two services are depicted in Figs. 2 and 3, respectively. For the asynchronous service, MAC service data units (M_SDU) are encapsulated to form initial MAC protocol data units (IMPDU); a header and a trailer are added to each I M P D U , as shown in Fig. 2. A segmentation process transforms each I M P D U into one or more fixed length (44-octet) segmentation units. Depending on the length of an I M P D U , either one (SSM or single segment message), two (a BOM, beginning of message followed by an EOM, end of message), or more (multiple

I-

-I

MA-UNITDATA. request (source_address, destination_address, data, priority, service_class) #v0100= 16 bit 1000= 48 bit 1100= 60 bit, individual, public 1101= 60 bit, individual, private 1110= 60 bit, group, public ~,.J 111,, 60 bit, group, private

Reserved

Set to 1

[Value X 4]

I C~) I (~) [i

<~> I(~)1

Set to

~:...~:.~%<~.....

. ~:

~,

-'.>-"-~>-

.: -

IMPDU ~ ' Into

0

U

IMPDU

i

i

i

(0-9188)

i++++.+++++++: ii ++++<+++++.++++++. "piUinit++++++++.++++,Unit S~mentetior, U.it

IIIII

(44)

~1 SU |1 o ^ r ^ rl ,4..)

SU | PpO

I~

+o) r

EOM Segmentation Unit (44)

/P.ie=,l I Number I [+] / [`] I

Type

DMPDU

,~lLengthl

Identifier

+

[,o]

IC"~Ul I ~'~"1 I ¢+)1

COlvl=O0 EOM=01 BOM=IO SSM=I 1

I [2011

OA Segment

A,

[21

0o

P'~ I~ ITraller 1(2)

'-"+r 0

IPrlorit~ I Cheek |~i / ISe~ue"~e |l! /

[21

00

I

[+

[el

00t00m0

t+S Default CL VCI for MAC Service

pu~L~=i~PS~l~,~-et !+ ype

QA Slot

0~

to 1 Slot

QA Isegment I

I Header

I

GA Segment Payload

I m

I

""

I+

¢'>

I'+

I

I~1 I I I<,I I

~ s~,nt m)

Numbers in ( ) brackets are octets Numbers in [ ] brackets are bits

Fig. 2. DQDB protocol data unit hierarchy.

CRD |~

+ 1 m l t,o] F

~+ S,~r~nt,t~o. u., (44>

$:::;$~~~..~-.:::'..-:'<~::::::::::::'.::~::.:~ ~,<~!

Ivo, Type

P+,o..,l~

,

[.......! [!i

M.-T. Yap, D. Hutchison / DQDB emulator

48 64 kbl~ channels

Ive, I Pay ,dlSeg"

1181

I

•• • ••

-I

C~.ck 1~ Sequence

112011 12l I [21 PA Segment

00

[8]

[~ PA Segment Header (4)

,, r[',71,,i,,, i [,,

PA Slot

....

00

set I=PA

ACF

to 1 Slot (1)

PA Segment Payload

I

(48)

PA Segment (52)

Numbers in ( ) brackets are octets Numbers in [ ] brackets are bits

Fig. 3. A pre-arbitrated slot.

COMs, continuation of message sandwiched between a BOM and an EOM) segmentation units are created. A derived MAC protocol data unit (DMPDU) is derived from each segmentation unit by adding a header and a trailer. The type of a segmentation unit is identified by the segment type field in the header. DMPDUs are further encapsulated to form the QA segment payload of QA segments. An Access Control Field (ACF) is then added to each QA segment to complete the formation of a QA slot, which is fixed at 53 octets. Note that the MAC address is found in the first segment; therefore if the segment type is either BOM or SSM, the node can look immediately in the destination address field for its own address, and if a match is not found, can discard the segment. Figure 3 depicts the formation of a pre-arbitrated (PA) slot, for supporting isochronous service. The ACF and the PA segment header are pre-set by the slot generator node. Both the busy and slot type subfields are set to one. The 20-bit virtual channel identification subfield in the PA segment header holds the key to the pre-arbitrated slot access control mechanism. Within a PA segment payload, each octet represents a 64 kbps channel. The current standard allows multi-user (node) access to a PA slot. Multiple octets within a PA slot, or even multiple PA

slots, may be combined to provide higher rate channels. However, care must be taken not to destabilise the asynchronous service, since the total bandwidth is shared between both the asynchronous and isochronous services. When a large portion of the total bandwidth is allocated to the isochronous service, the remaining bandwidth represents the inter-service time of the asynchronous service; if this inter-service time is larger than the average inter-arrival time of asynchronous data packets, the queueing system becomes unstable. 2.3. Distributed queue state machine

The finite state machine model used in the queue arbitrated slot access control protocol, in support of the asynchronous service, is known as the distributed queue state machine (DQSM). There are six distributed queue state machines for each DQDB node; one for each combination of bus and request priority level. The state transition diagram and the corresponding event/action table of a generic DQSM are shown in Figs. 4 and 5. In the event/action table, bus x signifies the forward bus operated by the DQSM while bus y denotes the opposite bus, or the reverse bus, while I and J refer to the request priority levels (0, 1 or 2).

M.-T. Yap, D. Hutchison / DQDB emulator

1182

11 a

11d

22a

( 11c

22c 21 Fig. 4. D Q S M s t a t e t r a n s i t i o n d i a g r a m .

Transition

Events

11a

REQ..J on Bus y & J>=I

Increment RQ_I by 1 (up to maximum)

12

Request to queue QA segment for Bus x at priori~level I

Self_Req_I for Bus x C D I <- RQ_I RQ_I <- 0 REQ_I for Bus y

1lb

Self_Req_J for Bus x & J>l

Increment RQ_I by 1 (up to maximum)

1lc

Empty, QA slot on Bus x

Decrement RQ_I by l (down to 0)

11d

Increment RQ_I by 1 (up to maximum)

22a

BWB_reset_x signal received from BWBM for Bus x Req..J on Bus y & J>I

22b

Req_J on Bus y & J=I

Increment RQ_I by l (up to maximum)

21

Empty, QA slot on Bus x & CD_I--O

Mark the QA slot as busy Send BWB_up signal to BWBM for Bus x Start transmitting the QA

22c

Self_Req_J for Bus x & J>l

Increment C D I by 1 (up to maximum)

22d

Empty, QA slot on Bus x & CD_I>0

Decrement CD_I by l (down to 0)

22e

BWB_reset_x signal received from BWBM for Bus x

Increment CD_I by 1 (up to maximum)

Number

Actions

Increment CD_I by l (up to maximum)

segment

Fig. 5. D Q S M e v e n t / a c t i o n table.

A distributed queue state machine observes the forward bus for empty QA slots and the opposite bus for downstream requests in addition to handling the distributed queue. The operation of a DQSM depends on the current state it is in. Two possible states are defined; the idle and countdown states. A DQSM is in the idle state when it does not have data packets to send. In other words, it does not occupy a place in the distributed queue. When a distributed queue state machine has a data packet

to send, the data packet will occupy a place in the distributed queue and a state transition will occur from idle to countdown state. Each DQSM handles five types of event; a downstream request (req-J), local or self request of a higher priority (self_req-J), the passing of an empty QA slot, the receipt of a bandwidth balancing reset signal (BWB_reset_x) generated by a bandwidth balancing machine (BWBM), and a request to queue a QA segment. The bandwidth balancing events are maintained by a bandwidth balancing machine. There is one BWBM associated with each bus. A BWBM counts the number of QA slots to which the node has gained access and receives a reset when the count reaches BWBMOD (bandwidth balancing modulus). The counter is cleared, and the corresponding request counter is incremented by one. This effectively lets one empty QA slot pass downstream for every B W B M O D number of QA slots to which the node has gained access. Each DQSM maintains a current state record, which contains the current state of a state machine, the number of downstream requests, and other related counters so that it knows when to access a passing slot and when to let an empty QA slot pass downstream. These counters include the request counter, countdown counter, bandwidth balancing counter and request queue machine counter. The request counter contains the number of outstanding downstream requests. Associated with each bus is a request queue machine (RQM). Each RQM contains a counter, which maintains a count of the number of outstanding requests waiting to be sent on the opposite bus. The standard has introduced two numbers to prevent the distributed queue from growing without bound. These are the maximum number of outstanding requests (MAXRQ) and the maximum number of countdown (MAXCD), to be imposed on request counters and countdown counters respectively. When a state machine is in idle state, it updates the request counter accordingly; it increments the request counter for every downstream request, and for every bypassing empty QA slot the request counter is decremented until it reaches zero. The request counter simply reflects the number of outstanding downstream requests that corresponds to the number of empty QA slots it must allow to pass downstream. A state transition from idle to countdown occurs when a state machine has a data

M.-T. Yap, D. Hutchison / DQDB emulator

1183

isochronous slot

I

I I -~

Bus ~

VCI-Offset Pair Table

Fig. 6. Pre-arbitrated slot access control mechanism.

packet to send. During this transition, the state machine transfers the number in the request counter to the countdown counter and initialises the request counter to zero. The number in the countdown counter represents the position of this data packet in the distributed queue. In the countdown state, the state machine performs the countdown operation. The countdown counter is decremented for each passing empty QA slot. When the count reaches zero, it means that this data packet has reached the beginning of the queue, and the server (bus) is ready to service it. Access is thus gained. 2.4. Isochronous service

Two functions, the pre-arbitrated function and the isochronous convergence function (ICF), provide support to the isochronous service. For each isochronous service user (ISU) within a node, a connection end point (CEP) is established during the connection establishment phase. A buffer is inserted between an ISU and the pre-arbitrated slot access function to cater for any fluctuations in the actual data rate. An isochronous convergence function operates a 125 Its clock. Upon the expiry of the timer, ICF will pull out a byte from an ISU and insert it into the ICF transmit buffer, assuming that particular ISU channel rate is 64 kbps. The buffer acts as a smoothing device to minimize the effect of fluctuations in the channel output rate of an ISU. Figure 6 shows the pre-arbitrated slot access control (PASAC) mechanism. Two tables, a connection end point table and a VCI-offset pair table, are used to control the access to PA slots. When an isochronous channel is being set up, the slot gener-

ator pre-allocates some bytes at fixed offsets within a PA slot. The number of bytes allocated depends on the channel capacity; x bytes for x times 64 kbps. The node adds an entry to the connection end point table while multiple entries are added to the VCI-offset pair table. Each entry in the VCIoffset pair table identifies a 64 kbps component channel. For every passing PA slot, PASAC examines the virtual channel identifier subfield looking for a match with the entries in the VCI-offset pair table. Once a match is found, it uses the connection end point identification (CEPID) field to locate the corresponding buffer. It then OR-writes a byte from the appropriate ICF transmit buffer at the proper offset position within the current PA slot. It should be noted that the DQDB base standard was not intended to cover the isochronous service in a complete way. As long as the isochronous service has still to be defined by the standardisation committee, its description does not form part of the DQDB standard. In fact, the committee has decided to go to PA segments dedicated to a single connection, based on the concept of a frame group [21-1, in order to provide compatibility with ATM switches which may be used to interconnect DQDB subnetworks. Identification is by VCI only and not by position relative to the start of the frame.

3. Emulator design and implementation The design of the network emulator was started by looking at ways to represent a DQDB network. The conceptual design of the emulator can be

M.-T. Yap, D. Hutchison / DQDB emulator

1184

read_tapO

isuO

arrival()

Queues

From other ' ' ' ~ ' ' ~ ' ~ nodes ..................-~

(

) I I I I I I

( ..-,-. +

, ~ o m

)

othernodes

?

Q Local Queues

arrival()

isuO

read_tapO

Fig. 7. DQDB nodal model.

divided into two areas; the nodal model and the network model.

3.1. DQDB nodal model Figure 7 depicts the DQDB nodal model we implemented. Unlike many simulation studies that consider only a receive function based on one bus and one request priority level of DQDB, the trans-

mit and receive functions for both buses and the three request levels associated with each bus are implemented in our DQDB nodal model. This allows interactions between the buses and all three request priority levels of each bus to be studied. The DQDB nodal software is written in C. A separate compilation approach is used to develop the software, dbxtool was used extensively to debug the program. The basic DQDB nodal software is

M.-T. Yap, D. Hutchison / DQDB emulator

divided into eight modules and two header files. These eight modules are n o t . e , dqdb.e, initdqdb.e, eefg.e, qasae.e, pasac,e, 1 q. c and p e r f . c . The no t module forks out the required number of child processes to represent the nodes within a D Q D B network. The dqdb module contains the D Q D B node driver for each D Q D B node and a housekeep() function that acts as the basic timing reference. Each call to housekeep() advances the emulator by one slot time. The i n i t d q d b module performs various initialisation functions. The e e f g module is responsible for configuration control and implements the read taps and write connections. Distributed queue state machines ( d q s m ( ) ) and bandwidth balancing machines are contained in the q a s a e module, while p a s a c module contains the pre-arbitrated slot access control mechanism and the isochronous convergence function. Six local queues with Poisson distributed inter-arrival time are provided by the 1 q module. Finally, the p e r f module accumulates and computes various statistics required for the performance evaluation of D Q D B networks. All six local queues and the six distributed queues are represented as static arrays. A separate queue for the isochronous convergence transmit buffer also forms part of the model. The current state records are implemented as a two-dimensional static array of structures (c s r [ 2 ] [ 3 ]). The first index corresponds to the bus number (A or B) and the second index corresponds to the three levels of request priority. A traffic arrival process is associated with each local queue and the isochronous convergence transmit buffer queue. The traffic arrivals are coded as stochastic processes of which the inter-arrival time between packets is Poisson distributed. The operation of the asynchronous service is aided by the current state records while both the connection end point table and the VCI-offset pair table are used to operate the isochronous service. When the emulator is executed, the r t ~ i n ( ) function forks out the required number of child processes to represent the nodes within the D Q D B network. Each child process in turn executes a D Q D B node driver routine to emulate the D Q D B protocol. Upon activation, a node initialises various internal channels between the queue arbitrated slot access control, pre-arbitrated slot access control, configuration control, local and distributed queues, and the external channels bus_in

1185

and bus_out for both buses A and B. It also initialises the slot tables to be used by the slot generator to perform the slot marking function, the connection end point table, and the virtual channel identification/octet offset pair table. These two tables are used by both the isochronous convergence function (ICF) and the pre-arbitrated slot access control (PASAC). Asynchronous service: Four functions are involved in the provision of MAC service to LLC. These are MAC convergence transmit and receive functions, queue arbitrated transmit and receive functions. In our model, data packets are transferred from local queues to the respective distributed queues. There are two instances of queue arbitrated slot access control, one for each bus. At the heart of queue arbitrated slot access control are the six instances of the distributed queue state machine, one for each combination of bus (A or B) and request priority level (0, 1, or 2). Common inputs to these state machines include the current slot on the bus (cur_slot[ ]), the request bits coming from the opposite bus, opp(b), and the distributed queues. One data packet at a time is transferred conditionally from a local queue to a distributed queue. Whenever a data packet is being transferred to the distributed queue, it also calls upon the request queue machine rqm( ) to send a request bit to all upstream nodes on the opposite bus. Local or self requests are also being generated and captured in the self request counter self_cntr, a member of the respective current state record. Once a distributed queue state machine has gained access to a slot, it OR-writes the slot segment header and segment payload of the current slot, and sets the busy bit in the access control field to one. Note that the request queue machine rqm( ) could OR-write a request bit on a slot header regardless of whether it is a PA or QA slot as long as the relevant request bit is not already set. lsochronous service: The framing structure to realise the isochronous service is based on the assumption that within 125 ~ts 44 slots (SL_PER_FR) will pass by a D Q D B node. Four functions are involved in the provision of isochronous service; the isochronous convergence transmit and receive functions, and pre-arbitrated transmit and receive functions. An isochronous convergence transmit function, icf_transmit(), is placed in between an isochronous service user and the pre-arbitrated slot access control transmit function pa_transmit(). In order

1186

M.-T. Yap, D. Hutchison / DQDB emulator

to simulate the fact that ISU_DATA.request is generated isochronously, a 125 ~ts timer (an integer counter) is included in the CEP table. For each passing slot, the timer of an active CEP is incremented by one. Once it reaches the value of SL_PER_FR, a timeout is raised and the function isu_data_request( ) is called to service that particular connection end point. There is one isochronous convergence function for each isochronous service user. The connection establishment, maintenance, and termination of a virtual channel are not defined in the standard. Two connect functions, connect_ceps() and connect_vcipairs(), were written to set up three connection end points (CEPs) with their appropriate virtual channel identification, octet offset fields set up in the corresponding VCI octet offset-pair tables. These two functions are used to set up three connection end points for the testing of the prearbitrated slot access control functions. Higher rate channels may be set up by utilising a capacity field in the CEP table. This field is set accordingly during connection establishment phase to indicate the required channel capacity in units of 64 kbps. An integer x number of octets from an ISU to the associated isochronous convergence transmit buffer is moved by isu_data_request() where x equals the channel capacity in units of 64 kbps. 3.2. D Q D B network model

System V named pipes (FIFOs) are used to implement the dual bus. Each named pipe implements a segment of a bus. Every Unix process emulating the DQDB protocol is connected to two adjacent processes by four named pipes. These named pipes are loaded with a variable number of DQDB slots during an initialisation phase to emulate changing network distances. The timing approach is based on the passing of slots as the basic timing source. Timing is derived from the passing data stream. Note that these named pipes are configured for blocking read and non-blocking write operations in order to ensure proper process synchronisation.

4. DQDB performance evaluation 4.1. The experiments

The basic DQDB network emulator described above is now in working order. To facilitate the

debugging and verification of the emulator, each nodal process writes the results of a run to six data files; one for each bus and request priority level combination. Information that may be written to the data files includes configuration control and slot generation data, the distributed queue state machine data indicating which node gains access to an empty passing slot, the operation of the isochronous convergence function and the pre-arbitrated slot access control status. This data is captured on a slot by slot basis. As to which data to capture during a run, it is specified through the use of a network configuration file which is read and interpreted at the beginning of each run. Also specified in a network configuration file is the number of nodes for a particular network. The emulator software will fork out the correct number of child processes and inter-connect them with FIFOs. The Unix kernel of the development Sun workstation is configured for up to a maximum of one hundred pipes to be forked out. This allows experiments with up to fifty nodes per network model to be carried out. Various simulation experiments have been carried out in order to evaluate the performance of the asynchronous service of the DQDB protocol. The results of these experiments are reported here. A model of the DQDB network used in the performance evaluation is depicted in Fig. 8. Multiple simulation runs are executed by varying the input parameters. These input parameters include the stochastic asynchronous traffic arrival process at each node, the setting of the bandwidth balancing machine (BWBMOD), the local queue buffer size, the inter-node distance in slot time units, the bus rate in Mbps, the simulation time in ~ts and the number of nodes in the network. Unless otherwise stated, the following assumptions are used in all the experiments; the bus rate is 150 Mbps, the internode distance is 4 slot times, and the local queue buffer size is 50 slots. This results in 44 slots per frame and each slot time is equal to 2.83 ~ts. Packets are of slot length. The inter-arrival time between packets of the traffic arrival process is Poisson distributed. Based on the traffic arrival at each node, the performance of the DQDB network is evaluated under three different conditions; underload, overload and asymptotic conditions. In underload conditions, the total traffic arrivals from all nodes do not exceed the bus bandwidth. Three cases are

M.-T. Yap, D. Hutchison / DQDB emulator Input Parameters Traffic Arrival

BWBM LQBufferSize ~ NetworkDistance BusRate SimulationTime

1187

Output Parameters

~ ~

Access Delay (DQ)

~

WaitingTime(DQ+LQ) BandwidthSharing(Mbps) Packet Loss (%)

No. of Nodes Fig. 8. D Q D B network model for performance evaluation.

considered; 85%, 90% and 95% of the bus bandwidth. In overload conditions, the total traffic arrivals from all the nodes exceed the bus bandwidth. Three cases are evaluated here; 105%, 110% and 120% of the bus bandwidth. Asymptotic conditions occur when one or more nodes attempt to obtain all the bus bandwidth. Two different situations are considered; when one node is attempting to obtain all the bus bandwidth in an otherwise underload conditions, and when every node is attempting to obtain all the bus bandwidth. The performance evaluation is conducted on a per node basis since fairness is a critical issue in DQDB networks. These individual performance results are further combined to give a network-wide view. Four statistics are derived as the evaluation criteria; the access delay, the waiting time, bandwidth sharing (Mbps) on a per node basis and the packet loss experienced by each node expressed as a percentage. The access delay and the waiting time are expressed in microseconds. Access delay is the average time delay experienced by packets arriving at the distributed queue of a node. It is computed as the difference between the slot time a packet gains access to the bus and the slot time the packet joins the distributed queue. Waiting time is the average time delay experienced by packets arriving at a local queue of a node. It is computed as the difference between the slot time a packet gains access to the bus and the slot time the packet joins a local queue. This is the amount of time a packet has spent in the local queue and the distributed queue. Various constant time components such as the packet transmission time are excluded from our model. Bandwidth sharing is computed as the ratio of the number of packets (slots) transmitted over the total number of slots counted during the simulation run. It is expressed in Mbps. Packet loss is expressed as the ratio of the number

of packets dropped from the local queue over the total number of slots transmitted. Since it is expressed as a ratio over the total number of packets successfully transmitted, the value of packet loss may exceed 1 indicating that the number of packets dropped from the local queue is greater than the number of packets successfully transmitted. The formulae used are summarised below. tACC = tGain - -

tJoint-DQ

t w = tGain - - tjoint_LQ

BWS = number of packets transmitted/ total number of slots counted PL = number of packets dropped from LQ/ total number of packets transmitted The simulation experiments were executed on a Sparc 1 workstation simulated for one second which is equivalent to 353773 slot counts. Because of our emulation approach and the fact that the disk space is almost 95% full most of the time, each run for 20 nodes, each with two buses, takes up to six hours to complete, resulting in a total of 14,150,920 slots being circulated around. Note that node one is the default slot generator (DSG) and the looped bus configuration is used. However, the results are independent of whether the topology is open or looped. The simulation experiments carried out on bus A are summarised in Fig. 9. In the next sections of this paper we present the results of the various experiments. Note that under the asymptotic conditions, we assume node 10 attempts to obtain the full bus bandwidth of 150 Mbps. The performance of the DQDB protocol has been investigated extensively in recent years. For comparative studies, see [2, 5-10, 13, 22, 25-27, 30, 34-39].

M.-T. Yap, D. Hutchison / DQDB emulator

1188

Traffic Arrival

BWBM

(%) 80 90 95 80 90 95 105 110 120 105 110 120 120 120 120 120 95 95 ~ 150Mbps 150Mbps 95% Nl0150Mbps 120%N10150Mbps 95 95 95

0 0 0 8 8 8 0 0 0 8 8 8 1 4 12 16 8 8 ~ 0 8 8 8 8 8 8

LQ Buffer Size

Inter-Node

50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 10 30 100 50 50 50 50 50 50 50

4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 I 8 10

Distance

Fig. 9. Summary of experiments.

4.2. Underload conditions 4.2.1. Bandwidth balancing machine disabled We evaluated the performance of the DQDB protocol under underload conditions when the bandwidth balancing machine is disabled. The access delay, waiting time and bandwidth sharing are depicted in Fig. 10. We ran three experiments with total traffic arrival set to 80°/0, 90% and 95% of the bus bandwidth, respectively. The bandwidth balancing machine is disabled by setting the bandwidth balancing modulus (BWBMOD) to 0. It can be seen that as long as the bus bandwidth is not saturated, the waiting time is mainly contributed by the access delay component. Even though the waiting time experienced by nodes further downstream from the default slot generator increases with the node index, the maximum waiting time at node 20 is less than 15 ~ts. The bandwidth sharing is also fair. 4.2.2. Bandwidth balancing machine enabled We ran three experiments similar to the previous section to investigate the effect of the bandwidth balancing machine under underload conditions.

The bandwidth balancing machine is enabled by setting the bandwidth balancing modulus to 8. The performance graphs are shown in Fig. 11. By comparing Fig. 11 with Fig. 10, we conclude that the bandwidth balancing machine has little or no effect in underload conditions. Bandwidth sharing is slightly fairer but nodes further downstream encounter increased waiting time. Compared to BWBM disabled, the curves for BWBMOD set to eight show that delays are slightly higher because not every free passing slot can be used. 4.2.3. Effects of network distance In this set of experiments, we turned our attention to the effect of increasing network distance on the performance and fairness of DQDB under underload conditions. The total traffic arrival is set to 95% of the bus bandwidth of 150 Mbps. The bandwidth balancing machine is disabled. The inter-node distance is varied for 1, 4, 8 and 10 slot time in four separate runs. This corresponds to a network of 15.64 km to 156.4 km, i.e. 20 to 200 slot times given that one slot time is equivalent to 782 m. The performance graphs are shown in Fig. 12. By comparing Fig. 12 with Fig. 10, we conclude that increasing network distance has negligible effect on the performance and fairness of DQDB protocol under underload conditions. The effect of a larger network (or higher speed, which is equivalent) is that there is a tendency towards throughput unfairness among nodes. The degree of unfairness strongly depends on the sequence in which nodes start transmitting. 4.3. Overload conditions 4.3.1. Bandwidth balancing machine disabled The performance of DQDB under overload conditions was next studied. We ran three experiments with traffic arrivals set to 105%, 110% and 120% of the bus bandwidth of 150 Mbps. The bandwidth balancing machine is disabled. The access delay, waiting time, bandwidth sharing and packet loss are depicted in Fig. 13. In contrast to Fig. 10, it can be seen that under heavy load conditions, the DQDB protocol is unfair and unstable. Nodes further downstream from the default slot generator suffer higher waiting time and share less bandwidth than their upstream counterparts. The waiting time is mainly contributed by the LQ delay component. The unfairness results for 120% loading can be

M.-T. Yap, D. Hutchison / DQDB emulator

1189

20

80q* •41, 9o~ •U" 95~

15

bwb=O

1o

(a) o ~=

o

2

4

6

8

tO

12

14

16

18

20

12

14

16

18

20

Node Index

80%

bwb=0

-@9o~ Q 95~ io

0

2

4

6

8

I0 Node Index

7.0

6.8

6.6

6.4

6.2

•ira 80%

bwl~0

•4F 90'~ 41' 95~ 6.0

5.8

5.6

,

i

i

i

2

4

,6

8

,

I 10

,

I 12

,

I 14

,

I 16

.

I 18

( ) .C 20

Node Index Fig. 10. U n d e r l o a d c o n d i t i o n s w i t h B W B M

d i s a b l e d : (a) access d e l a y , (b) w a i t i n g t i m e , (c) b a n d w i d t h s h a r i n g .

M.-T. Yap, D. Hutchison / DQDB emulator

1190

20

O 8O% "0'9O% 41" 95%

15

bwb=:8

lO

0

2

4

6

8

10

12

14

16

18

2O

Node Index 2O '0

80% 9O% 95%

Q

bwb=8

15

10

-

(b)

0

0

2

4

6

8

I0

12

14

16

18

20

12

14

16

18

20

Node Index 7.0

6.8

6.6

6.4

6.2

5.8

5.6 0

2

4

6

8

l0 No& Index

F i g . 11. U n d e r l o a d

conditions with BWBM

e n a b l e d : (a) a c c e s s d e l a y , (b) w a i t i n g t i m e , (c) b a n d w i d t h

sharing.

M.-T. Yap, D. Hutchison / DQDB emulator

1191

20

•4D 1 "@4 "mS

15

95% offered leod bwb::O

"41" 10

10

(a) 0 0

i

I

I

I

2

4

6

8

a

I

I

,

I

,

I

,

I0

12

14

16

18

20

Node Index 20

95% olt'ered load bwb~0

"0"4

g8

(b) I

,

2

I

4

,

I

6

=

I

8

=

I

a

I

I

I

10

12

14

16

18

I

20

Node Index 6.86 6.84 6.82 6,80 6.78 6.76

0

95% offered load bwb:~

6.72

(c)

6.70 0

2

4

6

8

10

12

14

16

18

20

Node Index

Fig. 12. Effect o f n e t w o r k d i s t a n c e in u n d e r l o a d c o n d i t i o n s : (a) a c c e s s d e l a y , (b) w a i t i n g t i m e , (c) b a n d w i d t h s h a r i n g .

M.-T. Yap, D. Hutchison / DQDB emulator

1192

-ID IDYt,

8oi-

t

^

~vl~0

-e..~

!

~

~

1

/

/ v~

"

40

2O

0 0

2

4

6

S

10

12

14

16

18

20

Nede gadex

1°4

~o0 0

2

4

6

8

I0

12

14

16

I1~

20

Node Index g

8

?

6

/

4" . ~

0

2

~T~:,

I I

V

i

4 4

6

8

10

12

14

16

18

20

Nod= Index

Fig. 13. Overload conditions with BWBM disabled: (a) access delay, (b) waiting time, (c) bandwidth sharing, (d) packet loss.

M.-T. Yap, D. Hutchison / DQDB emulator

1193

1.0

0.8

bwb,,~

~,~ 110% 120%

0.6

0.4

0.2

0.0

. . ~• ~

-- _~- = 2

4

_~- --

_~"

6

8

= -'- ~ 10 Node

12

14

16

18

20

Index

Fig. 13. (continued)

arbitrarily different for other starting sequences. But as observed, the protocol is unfair and unstable. In the next section, the same set of experiments is repeated with the bandwidth balancing machine in operation.

4.3.2. Bandwidth balancing machine enabled The bandwidth balancing machine mechanism was introduced into the DQDB standards as a means to improve the fairness of DQDB under heavy load conditions. We ran these three experiments to confirm that fairness of the DQDB protocol has been improved as a result of incorporating the bandwidth balancing machine. The performance results are shown in Fig. 14. From the bandwidth sharing graph of Fig. 14, it can be seen that indeed fairness has been achieved. It is achieved at the expense of longer waiting time at upstream nodes, see Fig. 13, thus making all nodes experience waiting time of the same magnitude. Note that the waiting time for 110/120% loading is bounded by the finite buffer capacity. The value is approximately 51 times the access delay of 54 ~ts. The results are in agreement with those in [35]. 4.3.3. Effects of bandwidth balancing machine setting In this set of experiments, we attempted to evaluate the performance of DQDB under overload conditions with various settings of the bandwidth balancing modulus (BWBMOD). The traflic arrival at

each node is set to 120% of the bus bandwidth. The BWBMOD is varied, using 1, 4, 8, 12 and 16. The performance graphs are shown in Fig. 15. From the bandwidth sharing graph, it can be seen that with BWBMOD set to 1, bandwidth sharing is fair but the wastage is relatively higher. On the other hand, the experiment shows that a setting of 16 causes bandwidth sharing to fluctuate. There seems to be an effect of initial over-regulating. We turned next to investigate the convergence speed of the BWB protocol. The bandwidth sharing experienced at nodes 2, 10 and 20, as a function of time for BWBMOD set to 1, 8 and 16 is depicted in Fig. 16. The convergence speed and the corresponding bandwidth sharing achieved are summarised below.

BWBMOD

Node

BW (Mbps)

Time (in slots)

1 1 1 8 8 8 16 16 16

2 10 20 2 10 20 2 10 20

7.320 7.317 7.309 7.483 7.402 7.425 7.526 7.478 7.442

3319 840 156904 171580 131246 274345 100442 242849 333483

We observe that under overload conditions, as the number of nodes, or the network distance

M.-T. Yap, D. Hutchison / DQDB emulator

1194 6O

.

,°f

40t

.

.

.

-

"~' 105%

I-

-

,

- ' ~

-..,,o..

"~'

.."~

I

30

20

lO

0

2

4

6

8

I0

12

14

16

18

20

Node Index 3000

2000

1

105% •4' It0% 41' ~20% •I D

bwb=$

I000

(b) 2

4

6

8

I0

12

14

16

18

I

i

I

l

|2

14

16

18

20

Node

" D 105% •dk JlO%

bwb=ll

120%

(c) 4

I

0

I

2

I

|

4

I

|

6

l

|

8

l

I

I0

~

,

20

Node Index

Fig. 14. O v e r l o a d c o n d i t i o n s w i t h B W B M enabled: (a) access delay, (b) w a i t i n g time, (c) b a n d w i d t h s h a r i n g , (d) p a c k e t loss.

M.-T. Yap, D. Hutchison /' DQDB emulator

1195

0.16

0.14

0.12

0.10

•G . -0'

0.08

11~ 120%

bwb~ll

0.06

(d) •

0.04 0

2

4

6

8 Node

10

12

I

14

•

I

•

16

I

•

18

20

Index

Fig. 14. (continued)

56

55

54

4.4 41"8

53

=B'

12 16

(a)

n

52 0

2

4

6

8

10

12

14

16

18

20

Node Index

Fig. 15. Effectsof BWBM setting in overload conditions: (a) accessdelay, (b) waiting time, (c) bandwidth sharing, (d) packet loss.

increases, the convergence speed of the BWB protocol also increases rapidly. However, different settings of the B W B M O D do not affect the steady state bandwidth sharing in a significant way. The convergence speed of the BWB protocol increases with larger values of B W B M O D in general, but slower convergence is experienced at downstream nodes. The selection of B W B M O D has more effect on the convergence speed of the protocol, and less effect on the bandwidth sharing. The amount of bandwidth wastage certainly de-

creases with an increase in the B W B M O D setting, but this decrease is only marginal. Given sufficient time, all the nodes will eventually converge to a fair share of bandwidth. The bandwidth balancing mechanism is rate-based. For an active node, the more slots it acquires, the more empty slots it will pass downstream. Lower rate users will not be penalised because they will let go fewer empty slots. In a D Q D B network, traffic loadings may change from time to time, and indeed additional traffic may be turned on abruptly during bulk file

M.-T. Yap, D. Hutchison / DQDB emulator

1196

2900

2800

2700

2600

"0"4 41'S

2500

•'0" 12 4 " 16

2400

(b) m

2300 • 0

2

4

6

8

I0

12

16

.

18

20

Node Index 7.7

"0'4 -m. 8 12 41. 16

7.6

7.5

7.4

7.3

--.(c)I

7.2 b 0

2

4

6

8

10

12

18

14

Node Index 0,17

0.16

0.15

0.14

i

0.13

0.12

o.I1

0.I0 0

6

8

10

12

Node Index F i g . 15. ( c o n t i n u e d )

14

16

2O

M.-T. Yap, D. Hutchison / DQDB emulator 20-

20

18,

•

'~

1197

18

Node 2 Node 10 N o d e 20

Node2 Node 10 N o d e 20

s

16.

16

14,

14

A

12,

12 ,n

== 'E

== 10

10 w

8 c

iii

|

,=6

4

2

(a)

(b) 0 I

01 . . . . . .

;o2

......

;03 Time

......

;'0' ......

;'0~ . . . . . .

(in slots)

101

.......

J

10 2

.......

~

........

10 3

Time

i

10 4

........

i

.......

10 5

10 6

(in slots)

Fig. 16. Convergencespeed of the BWB protocol: (a) BWB_MODset to 1, (b) BWB_MODset to 8, (c) BWB_MODset to 16.

transfer. The convergence speed of the BWB protocol is the deciding factor in how well the protocol can cope with fluctuating traffic loadings in a fair manner. We conclude that for large values of BWBMOD, system dynamics are slow [34, 36]. The better choices are 8 or 12 with fairer bandwidth sharing, and maximum bandwidth utilisation, while the setting of 8 gives lower waiting time and is easier to implement in hardware. 4.3.4. Effects of local queue buffer size We have run four experiments to study the effect of the local queue buffer size on the performance of D Q D B under overload conditions. These experiments are not performed under underload conditions because in such conditions, local queue buffers are not filled to maximum and typically neither overflow nor packet loss will occur. In these experiments, the local queue buffer size is varied using 10,

30, 50 and 100 slots. The traffic arrival at each node is set to 120% of the bus bandwidth. B W B M O D is set to 8. The results are shown in Fig. 17. From the waiting time graph of Fig. 17, it can be seen that the size of the local queue buffer must be carefully selected to match the acceptable MAC delay with higher layer protocols in mind. Also from the bandwidth sharing graph, it can be seen that the local queue buffer size has negligible effect on the fairness of D Q D B protocol under overload conditions. 4.4. Asymptotic conditions 4.4.1. All nodes attempt to obtain all bus bandwidth In this part of the work we intended to find out whether D Q D B can cope with a situation when every node in the network makes excessive demand on the bandwidth. The performance of D Q D B under asymptotic conditions is evaluated. Each traffic

M.-T. Yap, D. Hutchison / DQDB emulator

1198

arrival process generates packets at the rate of 150 Mbps, Poisson distributed. The bus bandwidth is assumed to be 150 Mbps. We ran two experiments, the performance results of which are depicted in Fig. 18. The continuous curves are obtained for bandwidth balancing machine (BWBM) enabled with the bandwidth balancing modulus set to 8, while the discrete curves are obtained with the BWBM disabled. From the graphs it can be seen that when the BWBM is disabled, the access delay fluctuates and the waiting time among the nodes swings from 1 ms to 7 ms with a local queue buffer size of 50 slots. Bandwidth sharing is also unfair. But when the BWBM is enabled, the bandwidth sharing is fair and the waiting time is predictable. We conclude that D Q D B together with the bandwidth balancing mechanism can cope well under asymptotic conditions. Again, the unfairness pattern for B W B M O D set to 0 depends on the initial loading sequence of the network.

20

Node

2

Node

20

Node

10

16

14

12 .,=

g, m

10

8

c

6

4

4.4.2. One node attempts to obtain

all bus bandwidth In this set of experiments we studied the situation when the network is underloaded (95% of the bus bandwidth with BWB disabled) or overloaded (120% of the bus bandwidth with BWB set to 8) and one of the nodes (node 10, the tenth node further downstream from the default slot generator) attempts to obtain all the bus bandwidth.

2

(c) ......

10 1 "

J

.......

10 2

J

........

10 3

i

........

i

"10 4

........

10 5

10 6

Time (in slots)

Fig. 16. (continued)

50o0 •ID 4,30 4oo0

lo

"II' 50

3ooo 2ooo

IOOO

0 0

2

4

6

8

10

12

14

16

18

Node Index Fig. 17. Effect of LQ buffer size in overload conditions: (a) waiting time, (b) bandwidth sharing.

20

M.-T. Yap, D. Hutchison / DQDB emulator

1199

7.52

(b) 7.50

7A8

7A6 7.44 " ~ I0 =•' 30 41' 50

7A2

•4)" I00

7.40

7.38 0

2

4

6

8

10

12

14

16

IS

20

Node Index F i g . 17. ( c o n t i n u e d )

140

120

I00

Q

bwb-S

•

bwl~0

•

•

•

SO

60

40

20

0

u

n

n

n

n

2

4

6

8

10

n

n

a

12

14

i

I

16

n

I

18

n

20

Node Index

Fig. 18. Performanceresults under asymptoticconditions:(a) access delay,(b) waitingtime, (c) bandwidthsharing,(d) packet loss.

The performance results are given in Fig. 19. Node 10 does not seize all the bandwidth desired, and all the other nodes are not depleted of bandwidth sharing completely. In underload conditions, all the other nodes suffer a slight drop in bandwidth sharing, while the bandwidth hungry node gets a proportionally larger share of the bandwidth (18.68 Mbps) with increased waiting time (1126 Ixs). In overload conditions, node 10 does not obtain any additional bandwidth over any other nodes. The amount of bandwidth that the single heavy user obtains strongly depends on when it starts transmitting. Its throughput is certainly larger

when it starts first. Thus the fairness of the protocol strongly depends on the initial loading conditions. Even when the bandwidth balancing machine is enabled, the bandwidth balancing time is not effective to equalize an initial high throughput share of a heavy user in a stochastic environment. Again, note that the waiting time is bounded by finite buffer capacity. 4.5. Overall network performance The results from the above experiments for underload (80%, 90%, 95%) and overload (105%,

M.-T. Yap, D+ Hutchison

1200

+°F 6000 r

~

j.

DQDB emulator

•

bwb=8

.+o

•

|

"

4ooo ~,-

•

•

!

t

•

2000

(b) 0 0

2

4

6

8

I0

12

14

16

I

.-. I

I

14

16

18

20

Node Index 30

•m. bwb=8 • bwb=0 @

20

•

I0

•

•

@

.

I

I

I

I

I

2

4

6

8

I0

12

f.

~o,

I

•

18

20

Node Index 30

•m. bwb..8 • bwb=O

• •

20

J I0

•

(d) I

I

I

I

I

I

I

I

2

4

6

8

I0

12

14

16

Node Index Fig. 18. ( c o n t i n u e d )

I

I

18

I

20

M.-T. Yap, D. Hutchison / DQDB emulator

1201

50

301

I

40

20

10

(a) 0 0

2

4

6

8

10

12

"14

16

18

20

16

18

20

Node Index 300O a

A

~

A

2000

95qt .41. 12oq,

1000

0

50 IS

16

14

12

10

8

6 0

2

4

6

8

10

12

14

Node l~dex

Fig. 19. Performance results with one node attempts to obtain all bus bandwidth: (a) access delay, (b) waiting time, (c) bandwidth sharing.

M.-T. Yap, D. Hutch!son / DQDB emulator

1202

4000

Q

3000

0 A

2000

1000

0-"

I

~L

80

!

m

90

100

110

120

Total Offenxl Load (%) 160

0 "41"8

150

0

140

130

120

(b) 110

!

80

I 90

!

I

100

!

I

|

110

120

TotalOfferedL~d (%) Fig. 20. Overall network performance: (a) waiting time, (b) bandwidth utilisation.

110%, 120%) conditions are summarised in Fig. 20. Two cases are obtained here; one with BWBM disabled and the other with BWBM set to 8. From the bandwidth utilisation graph, it can be seen that as total offered load increases, the total carried load approaches the limit of the bus bandwidth (150 Mbps). With BWBM set to 8, the bandwidth utilisation is slightly lower than the bus bandwidth. The exact formula on bandwidth utilization for BWBM is given in [15, 35]. [15] is the paper describing the origin of BWBM. 5. Further work

The bulk of the work reported here has been concerned with the development of the basic net-

work emulator software and the performance evaluation of D Q D B networks. At the time of writing, work is under way to investigate the isochronous service aspect of D Q D B networks. Two of the issues in isochronous management which are not defined in the D Q D B standard are circuit allocation techniques and circuit establishment and termination procedures. In D Q D B networks, asynchronous service is provided on a delay basis while isochronous service is provided on a blocking basis. Isochronous service is chosen to provide fixed rate services like audio and video because of its circuit switching characteristics. Isochronous service is connectionoriented. In order to establish an isochronous connection between two or more users, control packets

M.-T. Yap, D. Hutchison / DQDB emulator

would have to be exchanged between the users involved and the head end nodes (default slot generator in a looped bus configuration, or the head of bus nodes in an open bus configuration) via the asynchronous service. At the end of a connection, control packets would again need to be exchanged among the parties in order to terminate or tear down the connection. During a circuit establishment/termination phase, an isochronous circuit has to ble allocated/ freed. Since slots are divided into asynchronous and isochronous slots, we will be investigating the merits of various bandwidth partitioning schemes between asynchronous and isochronous slots. These schemes include fixed boundary, moveable boundary and no boundary schemes. Many issues which have not been sufficiently studied are related to performance evaluation and congestion control of an entire network based on multiple DQDB subnetworks interconnected by bridges and routers. The basic emulator could be extended to support such research by using a network of workstations and replacing System V named pipes with socket inter-process communication mechanisms. Another issue that may be tackled is the effect of node processing, delay and phase difference on the order of access and therefore on the apportionment of capacity under overload. This could be used to obtain different overload cycles for a given architecture.

6. Conclusion In this paper, high speed multiservice networks are evaluated as the possible future solution to support distributed multimedia applications and systems. Three multiservice network emulation approaches are described, and the functionalities of the DQDB protocol are explained. A software model of a DQDB subnetwork of a metropolitan area network based on standard Unix processes and System V named pipes has been created. This model forms the basis of a DQDB network emulator. We have designed and implemented the DQDB network emulator and carried out various performance evaluation experiments on it. In doing this, we have gained considerable insight into the DQDB protocol implementation. The performance of

1203

DQDB has been evaluated under underload, overload and asymptotic conditions. The results show that the bandwidth balancing machine has no effect in underload conditions. DQDB is unfair in overload conditions, but this unfairness is corrected by operating the bandwidth balancing machine. The optimum setting of the BWBMOD is 8. Under asymptotic conditions, the amount of bandwidth that a single heavy user obtains strongly depends on when it starts transmitting. The fairness of the protocol strongly depends on the initial loading conditions. System dynamics are slow for larger values of BWBMOD. There is a tendency to throughput unfairness among nodes of a larger network or of higher speed. This degree of unfairness strongly depends on the sequence in which nodes start transmitting.

Acknowledgements The work described in this paper is supported by Nanyang Technological University of Singapore under the Academic Staff Development Scheme. The authors gratefully acknowledge the assistance of the reviewers' comments in revising and improving the original version of this paper.

References [1] P. Bates and M. Segal, Touring machine: a video telecommunications software tested, in: Proc. International Workshop on Network and Operatin# System Support for Digital Audio and Video, Berkeley, CA, November 1990. [2] C.C. Bisdikian, Waiting time analysis in a single buffer DQDB (802.6) network, IEEE J. Selected Areas Comm. 8(8) (1990) 1565-1573. [3] Z.L. Budrikis, J.L. Hullett, R.M. Newman, D. Economou, F.M. Fozdar and R.D. Jeffery, QPSX: a queued packet and synchronous circuit exchange, in: P.J. Kuehn, ed., New Communication Services. A Challenge to Computer Technology, Proc. 8th International Conference on Computer Communication, Munich, Germany, 15-19 September 1986 (North-Holland, Amsterdam, 1986) 288-293. [4] R. Clayton, The Patch Cord User's Guide, Draft TM, Bellcore, 1989. [5] M. Conti, E. Gregori and L. Lenzini, DQDB under heavy load: performance evaluation and unfairness analysis, Proc. IEEE INFOCOM'90, San Francisco, CA, June 1990, pp. 313-320. I-6] M. Conti, E. Gregori and L. Lenzini, An extensive analysis of DQDB performance and fairness in asymptotic conditions, Proc. EFOC/LAN'90, Munich, Germany, June 1990, pp. 259-265.

1204

M.-T. Yap, D. Hutchison / DQDB emulator

[7] M. Conti, E. Gregori and L. Lenzini, A methodological approach to an extensive analysis of DQDB performance and fairness, IEEE J. Selected Areas Comm. 9(1) (1991) 76-87. [8] M. Conti, E. Gregori and L. Lenzini, DCP: a distributed control polling MAC protocol: specifications and comparison with DQDB, IEEE J. Select. Areas Comm. 9(2) (1991) 241-247. [9] P. Davids and P. Martini, Performance analysis of DQDB, Proc. IEEE 1990 Phoenix Conference, Phoenix, AZ, June 1990, pp. 27-29. [10] P. Davids, T. Welzel and T. Anwar, Performance analysis of the DQDB metropolitan area network, SICON, 1989, 222-227. [11] M. dePrycker, Asynchronous Transfer Mode: Solution for Broadband ISDN (Ellis Horwood, Chichester, UK, 1991). [12] F.R. Dix, M. Kelly and R.W. Klessig, Access to a public switched multi-megabit data service offering, Comput. Comm. Rev. 20(3) (1990) 46-61. [13] J. Filipiak, Access protection for fairness in a distributed queue dual bus metropolitan area network, Proc. IEEE International Conference on Computer Communications, Boston, MA, June 1989, pp. 11-14. [14] G.S. Fishman, Principles of Discrete Event Simulation (Wiley, New York, NY, 1978). [15] E.L. Hahne, A. Choudhury and N.F. Maxemchuk, Improving the fairness of DQDB networks, Proc. IEEE INFOCOM'90, San Francisco, CA, June 1990, pp. 175-184. [16] R. Handel and M.N. Huber, Integrated Broadband Networks: An Introduction to A TM-based Networks (AddisonWesley, Reading, MA, 1991). [17] T. Hills, RBOCs begin the big push on SMDS, Comm. Int. (May 1991) 3-8. [18] IEEE 802.6 Distributed Queue Dual Bus (DQDB) - Metropolitan Area Network (MAN) - Draft Standard, Version DO, 14 July 1988. [19] Proposed IEEE 802.6 Standard: Distributed Queue Dual Bus (DQDB) Subnetwork of a Metropolitan Area Network (MAN), Version D14, 13 July 1990. [20] IEEE 802.6 Distributed Queue Dual Bus (DQDB) - Metropolitan Area Network (MAN) -Draft Standard, Version D15, 1 October 1990. [21] IEEE 802.6 Working Document 91/79: Isochronous Services on a Distributed Queue Dual Bus (DQDB) Subnetwork of a Metropolitan Area Network (MAN), 1991. [22] K.M. Khalil and M.E. Koblentz, A fair distributed queue dual bus method, Proc. IEEE 14th Conference on Local Computer Networks, Minneapolis, MN, 10-12 October 1989, pp, 180-188. [23] R.W. Klessig, Overview of metropolitan area networks, IEEE Comm. Mag. 24(1) (1986) 9-15. [24] LF. Ludwig and D.F. Dunn, Laboratory for emulation and study of integrated and coordinated media communication, SIGCOMM'87 Workshop (ACM Press, New York, NY, 1987) 283-291.

[25] P. Martini, Fairness issue of the DQDB protocol, Proc. IEEE 14th Conference on Local Computer Networks, Minneapolis, MN, October 1989, pp. 160-170. [26] P. Martini, The DQDB protocol - what about fairness, Proc. IEEE GLOBECOM'89, Dallas, TX, 27-30 November 1989, pp. 298-302. [27] A. Myles, DQDB simulation and MAC protocol analysis, Electron. Letters 25(9) (1989) 616-618. [28] R.M. Newman and J.L. Hullett, Distributed queueing: a fast and efficient packet access protocol for QPSX, in: P.J. Kuehn, ed., New Communication Services. A Challenge # to Computer Technology, Proc. 8th International Conference on Computer Communication, Munich, Germany, 15-19 September 1986 (North-Holland, Amsterdam, 1986) 294-299. [29] R.M. Newman, Z.L. Budrikis and J.L. Hullet, The QPSX MAN, IEEE Comm. Mag. 26(4) (1988) 20-28. [30] H. Santoso and S. Fdida, Protocol evolution and performance analysis of the IEEE 802.6 DQDB MAN, Proc. EFOC/LAN'90, Munich, Germany, June 1990, pp. 226-230. [31] K. Sauer and W. Schodl, Performance aspects of the DQDB protocol, Proc. International Teletraffic Congress (ITC), Adelaide, Australia, September 1989; Comput. Networks ISDN Systems 20 (1990) 253-260. [32] D.T.W. Sze, A metropolitan area network, IEEE J. Selected Areas Comm. 3(6) (1985) 815-824. [33] P. Tran-Gia and Th. Stock, Approximate performance analysis of the DQDB access protocol, Comput. Network ISDN Systems 20 (1990) 231-240. [34] H.R. van As, Performance evaluations of the bandwidth balancing in the DQDB MAC protocol, 8th Annual EFOC/LAN Conference, Munich, Germany, 27-29 June 1990, pp. 231-239. [35] H.R. van As, Major performance characteristics of the DQDB MAC protocol, SBT/IEEE International Telecommunications Symposium (ITS'90), Rio de Janeiro, 3-6 September 1990, pp. 113-119. [36] H.R. van As, J.W. Wong and P. Zafiropulo, Fairness, priority and predictability of the DQDB MAC protocol under heavy load, 1990 International Seminar on Digital Communications, Zurich, Switzerland, 5-8 March 1990, pp. 410-417. [37] Y. Yaw, Y.-K. Yea, W.-D. Ju and P.A. Ng, Analysis on access fairness and a technique to extend distance for 802.6, Proc. 14th IEEE Conference on Local Computer Networks, Minneapolis, MA, 10-12 October 1990, pp. 171-176. [38] M. Zukerman and P.G. Potter, The effect of eliminating the standby state on DQDB performance under overload, Int. J. Digital and Analog Cabled Systems 2(3) (1989) 179-186. [39] M. Zukerman and P.G. Potter, The DQDB protocol and its performance under overload traffic conditions, Comput. Networks ISDN Systems 20 (1990) 261-270.