A Quality of Service Decision for ATM-LAN/MAN Interconnection N. Davies, P. Francis-Cobley Department of Computer Science, University of Bristol Introduction With ATM networks now coming of age, there is a need to understand how the promise of broadband data transport will work in practical environments Rolling out ATM will be expensive. To ensure the long term economic viability and development of ATM will require new ways of exploiting the (expensive) infrastructure, one suggested route is to use ATM to carry video based services into the home. Here there are competing approaches to the final few metres. Some see ATM directly into ATM Set Top Boxes (STBs), while others see a different carrier within the home, a local area network that is used to interconnect other consumer equipment (e.g. video recorders, computers, televisions). The two technologies adopt diametric opposite approaches to QoS issues. ATM acts in a declarative manner this is the QoS I would like/require. LAN protocols describe the QoS in an operational manner this is the portion of the system bandwidth I want every 125µs. These two approaches mean that there is a definite need for a gateway between the two QoS models. Such a gateway is also likely to have to perform operations on the data flow between the two transmission technologies. In this paper we describe a model of a system containing such a gateway, we outline the issues that need to be addressed in a performance study of the overall system. We are using this model to understand the QoS trade-offs with such a system, formalising the system s performance through using Generalised Stochastic Petri Nets (GSPNs). Rationale for WAN/LAN interface models The initial delivery of services into the home will minimise risks by adopting a dedicated infrastructure with CBR-type services. In the longer term there will be a need to utilise statistical sharing of the network infrastructure to drive down the costs. One major source of the statistical sharing will be the use of VBR delivery services for video and other continuous media. We are building a performance model to investigate the potential issues for this overall service model, highlighting the architectural issues and the potential performance/cost trade-offs. Our initial thinking was based around the following analogy: 69/1
ATM Cells Time Slot Conveyor Belt Interface LAN/MAN Wheel (e.g. FDDI, IEEE 1394) 1 Figure 1. Conveyor Belt - Wheel Analogy Somewhere there is an ATM cell production facility that inserts the cells carrying video data into the network. The network acts as a conveyor moving the relative positions of the cells. There is an interface unit that assembles this cell stream and reconstitutes the cells into the appropriate packet data units (PDUs). These are then delivered across the local area network technology. We felt that a rotating wheel was a good analogy for several LAN technologies, ones in which there are definite cycles of isochronous traffic. The cyclic service, with its guaranteed quanta of isochronous bandwidth, will ensure timely delivery of the PDU, however if the PDU arrives slightly out of phase with the LAN delivery cycle then additional delay is incurred. Our aim is to quantify the jitter within the components of such a system, investigate how they can be controlled. The driving aim is to identify how the individual components can collaborate to reduce the jitter as seen by the end-terminal. We hope that this will allow for the generation of a cost model of the most cost-effective place to have buffering within the system. System Architecture Performance The outline architecture, which incorporates a LAN/WAN interface, is illustrated in Figure 2. In this we have identified the key performance components and boundaries for our investigations. 69/2
Continuous Media Stream (CMS) (Video Source) Blocking Segmentation CMS / WAN interface WAN Insertion ATM Network End User Equipment LAN Transfer LAN Insertion De-blocking Reassembly WAN / LAN interface Figure 2. Outline System Architecture We have chosen to create boundaries where we believe a single processor (or similar) would be tasked with the activities of that block. This allows us to enhance the model with contention for resources such as memory bandwidth and CPU cycles at a later date. We do not assume that we have complete control over the sources of contention for example, we are treating the transfer function abstraction of the ATM network as a given input. We hope to pick up on other work that is being performed in this area. In investigating this model there are several approaches to modelling each of these components: The following summarises the properties of each component that we intending to investigate: Continuous media stream source We are taking a stochastic model of the generation of the PDUs, which are subsequently blocked. There does not appear to be any generally available characterisation of such sources. Our initial stochastic models are: Minor variation from CBR-like arrival, normally distributed variation from the mean. Bulk arrival pattern at a fixed divisor of the underlying frame rate making the assumption that the encoder is performing its operation over a fixed number of video frames. Continuous media stream/wan interface Where the media stream is CBR-like there are potential issues of phasing. We consider the insertion model to be an interesting area of study. Are cells 69/3
inserted in phase with some globally standardised clock (e.g. 8khz) or is the insertion criteria based on a fixed cell inter-arrival rate (i.e. the first cell of a sequence is delivered immediately)? Is the network performance sensitive to such phased insertion, if so to what extent? With VBR traffic generation by the media source, what policing is required and how does this interact with the overall system performance? ATM network There is a substantial body of work being done in this area. It is of interest to us the extent to which this work can be used as input to overall system models, such as ours. We intend to use the generated probability density functions (pdfs) from such work as an approximation to the delay that a cell would experience while transiting an ATM WAN. LAN/WAN interface Our original interest in this model was centred at this point. However, as we developed our model we began to realise that this interface is likely to be simple in its conception while complex in its realisation. It is likely that this will be the point at which any shortcomings in the WAN and the STB will have to be overcome. In mediating the flow of traffic between WAN and LAN the interface will have to ensure that respective QoS on WAN and LAN, both requested and delivered, are sufficient to keep the STB services operating at a level acceptable to the end user. The processing required to perform these monitoring functions are likely to be performed by the same processor which is performing the reassembly, deblocking and delivery into the LAN. This raises the issue of contention for CPU and memory bandwidth within this interface unit. Although our initial model does not capture this potential contention, we intend to extend it to allow us to quantify the amount of residual CPU and memory resource after performing these WAN/LAN interface functions. The LAN protocols tend to provide two distinct types of service. There is a set of issues here relating to how to make the best use of the isochronous and asynchronous services they provide. General ling Issues We hope to be able to physically create and instrument such a system and to allow for comparisons between predicted and observed traffic. To allow this to happen, the models we are developing allow us to capture the pdf of the PDU inter-block transit times. 69/4
We have chosen to use Petri Nets as our modelling medium, as they allow us to construct simple and flexible models. This is particularly important where we wish to enhance our models by the introduction of additional contention (e.g. memory bandwidth). The following is a brief overview of Petri nets. A Petri Net (PN) is a directed, bipartite graph with two classes of nodes, places and transitions. Directed arcs connect places to transitions or transitions to places. Rectangles (or bars) represent transitions; circles represent places. An arc from place p to transition t is called an input place of t; an output place is similarly defined. A PN is marked by placing tokens (represented by black dots) in the places. The state (or marking) of a PN is defined by the number of tokens in each place. If every input place for a transition t has at least one token, t is said to be enabled. An enabled transition can then be fired by removing a token from each of its input places and adding a token to each of its output places In modelling, the places represent conditions and the transitions represent events. The firing of a transition simulates the occurrence of that event. Events are actions that take place in the system and are controlled by the state of the system. Conditions are captured in logical description of the state of the system; they may either be true or false. Input arcs represent the conditions necessary for an event to occur, input and output arcs together describe the effect an event has on the system Petri nets can be extended by associating a firing rate with each transition. Stochastic Petri nets represent one such extension in which the firing rates have negative exponential distribution. Generalised stochastic Petri nets (GSPNs) are an extension of a stochastic Petri nets by allowing the transitions to have either an exponential firing rate or an immediate firing rate (fire in zero time). GSPNs are such that timed enabled transitions fire one at a time, according to the probabilistic structure of the model. For further details on PNs refer to [1,2,3]. 69/5
Specific ling Issues The mapping of the system architecture to Petri net representation is illustrated below for the WAN/LAN interface block. WAN Transport 8 AAL5 re-assembly buffer Re-assembly time 2 MPEG transport block buffer LAN Insertion LAN transport CPU idle Figure 3. Petri net illustration In this model it can be seen that we can capture the requirement that eight ATM cells (representing a single AAL5 frame) have to be received before the MPEG transport blocks can be generated. Once there are eight cells present and the CPU is available, the re-assembly time transition can fire. This takes a finite period of time during which the CPU is unavailable for other uses. At the end of this period the CPU is now available for other uses and an additional two tokens have been placed in the MPEG transport block buffer. The individual MPEG transport blocks are then processed, subject to the availability of the CPU and the LAN insertion model. We have hidden the details of the LAN insertion model, as there are several ways of approaching this issue. One approach might be to transport a single MPEG transport block at the start of each isochronous cycle, when the MPEG transport block buffer is non-empty. To extract the statistics that we require, we need to gather the latencies for each of the tokens in key places within the Petri net. Average flow rates can be easily calculated, whereas the jitter characteristics require capturing key delays between points in the Petri net model as a relative frequency histogram. Conclusions Our initial Petri net models revealed several interesting issues. In taking the block approach we have been able to defined boundaries between the components to structure our current investigation. In addition to global picture of an overall system, we get an insight into the design issues associated with the component blocks. Although we have chosen here to illustrate CPU contention within the WAN/LAN 69/6
interface block our current thoughts point to memory bandwidth as being a more pressing issue. In this paper, we have outlined our approach to modelling a QoS system for ATM/LAN interconnection. Simulation results will be presented subsequently. References 1. Peterson, J.L, Petri Net Theory and the ling of Systems, Prentice Hall, Englewoods Cliffs, NJ, USA, 1981. 2. Molloy, M., Performance Analysis Using Stochastic Petri Nets, IEEE Transactions on Computers,, vol. C31, N0. 9, September, 1982, pp. 913-917. 3. Marsan, A.J., et al, A Class of Generalised Stochastic Petri Nets for the Performance Evaluation of Multiprocessor Systems, ACM Transactions on Computing,, vol. 2, No. 2, May 1984, pp 93-122. 69/7