Evaluation of Broadband Networking Technologies: Phase I Report

Transcription

1 Evaluation of Broadband Networking Technologies: Phase I Report Sponsor: Sprint David W. Petr Victor S. Frost Lynn A. Neir Ann Demirtjis Cameron Braun Technical Report TISL Telecommunications and Information Sciences Laboratory Department of Electrical and Computer Engineering University of Kansas January 1993 Petr, Frost, Neir, Demirtjis, Braun Page 1

2 1. Executive Summary Awide variety of technologies are rapidly evolving to support the broadband communications needs of customers. These include Frame Relay (FR), Asynchronous Transfer Mode (ATM) and Switched Multimegabit Data Service based on the IEEE standard (802.6). Such technologies are being used for both customer access and network backbones. In Phase I of this Evaluation of Broadband Network Technologies project, research was conducted to assess the relative merits of different combinations of access/backbone technology combinations to support integrated customer traffic, i.e., voice, video, image and data (inter-lan). Specifically FR/ATM, ATM/ATM, 802.6/802.6 and 802.6/FR network configurations were evaluated based on network performance and customer-perceived quality of service (delay and throughput). All performance evaluations for Phase I were carried out using the Block Oriented Network Simulator (BONeS) [1]. Network configurations were designed to allow for fair comparisons of performance for the different traffic types with varying trunk loads and number of network hops. The BONeS models were developed with considerable flexibility so that they can be used in future performance evaluation studies. One significant product of this research is a set of direct comparisons of the different technology combinations in terms of delay for each type of traffic. In all cases, the FR/ATM and ATM/ATM combinations exhibited very similar performance. Numbers quoted here are 95% delays (i.e., 95% of the traffic has this delay or less) measured on an end-to-end (customer-perceived) basis for 3-hop connections at normalized trunk loads of Voice delays were nicely bounded for all technology combinations, ranging from 6 ms for 802.6/802.6 to 18 ms for 802.6/FR. Video delays were even smaller for all combinations, ranging from less than 2 ms for 802.6/802.6 to about 8 ms for 802.6/FR. However, there were significant differences in the data traffic delays, with FR/ATM and ATM/ATM at about 7 ms, 802.6/FR at about 20 ms, and 802.6/802.6 at many tens of ms (due to strict high priority of video and low priority of data and image traffic). Image delays behaved similarly to data delays, but were much larger due to the very large image blocks; image delays were about 150 ms for FR/ATM and ATM/ATM, 500 ms for 802.6/FR and about 800 ms for 802.6/ In connection with these delay results, it is also important to realize that the FR/ATM and ATM/ATM combinations carried nearly four times the total network traffic as the 802.6/802.6 and 802.6/FR combinations, due to faster trunk speeds. Based on these results we have concluded that both FR/ATM and ATM/ATM configurations are quite capable of supporting real-time services such as voice and video in addition to delay-tolerant services such as inter-lan and image transfers. Our results also indicated that technology is not particularly well-suited to integrated traffic, primarily due to its inflexible service priority structure. We have concluded that for broadband networks with integrated traffic, ATM is the preferred backbone technology, even if customer interfaces are Frame Relay. This project will now continue into Phase II. Further research into traffic source models, source traffic control (traffic descriptors and policers), queue service mechanisms or selective discarding mechanisms (or both), expansion of network models, and characterizations of cell and frame losses would increase our understanding of broadband networks and how to effectively deploy such technology. From this work Sprint Corporation not only obtained an evaluation of specific broadband technologies, but also received the developed evaluation tools, i.e., the simulation models. These models were designed to allow Sprint Corporation personnel to independently study the capabilities of a wide variety of broadband networking alternatives. Petr, Frost, Neir, Demirtjis, Braun Page 2

3 2. Phase ISummary 2.1 Introduction This report documents the activities and results of Phase I of the Evaluation of Broadband Networking Technologies project for Sprint. The two primary purposes of Phase I were to develop a base of general simulation models for studying broadband networks and to obtain head-to-head performance comparisons for several technology configurations with integrated traffic mixes. The technologies under consideration were Frame Relay, Asynchronous Transfer Mode (ATM), and IEEE Both Frame Relay and ATM are switch-based technologies that differ in their data unit sizes ("large" and variable for Frame Relay, "small" and fixed for ATM), intended transmission rates (45 Mb/s is seen as an upper bound for Frame Relay and a lower bound for ATM), and other protocol details. IEEE is also known as Distributed Queue Dual Bus (DQDB) and is the basis for a service called Switched Multimegabit Data Service (SMDS) offered by local exchange carriers. The definition includes provisions for integrated traffic (voice, data, etc), whereas SMDS is defined as a data-only service. In the context of the present study, the term "802.6" is more appropriate. This report assumes basic familiarity with these technologies. This study recognized that the technology used on network access links could very well be different from the technology used on the backbone network trunks. Four access/backbone combinations (listed in Table 1) were evaluated in Phase I. We will refer to these combinations as Frame Relay/ATM, ATM/ATM, pure 802.6, and 802.6/Frame Relay. TABLE 1. Phase I Technology Combinations Access Lines Backbone Trunks Frame Relay ATM ATM ATM Frame Relay All performance evaluations for Phase I were carried out using the Block Oriented Network Simulator (BONeS) [1]. The BONeS models developed for this project are all highly parameterized, allowing great flexibility in their use. All of the BONeS models, simulations, and results are contained in the BONeS database delivered as part of Phase I of this project. This permits Sprint analysts to examine the results of the Phase I simulations in more detail (including arranging the results in different presentation formats), re-running simulations with other parameter values, constructing new simulations from the lower-level modules, modifying the modules to alter their functionality, and constructing new modules to be used in conjunction with the ones provided. 2.2 Performance Evaluation Plan This section describes the basic structure of the Phase I performance evaluations for each of the four Phase I technology combinations: Frame Relay/ATM, ATM/ATM, Pure 802.6, and 802.6/Frame Relay. We emphasize here that the BONeS simulation models developed for Phase I are very general and can be used to construct many different high-level simulations besides the particular ones constructed for the Phase I studies. Petr, Frost, Neir, Demirtjis, Braun Page 3

4 2.2.1 Frame Relay/ATM and ATM/ATM The basic topology of the FR/ATM and ATM/ATM configurations for Phase I consists of four hubs (switches) interconnected by trunks, each serving two customer access lines (see Figure 1). Other topologies are possible using the developed BONeS models. Trunks operate at the STS-3 rate (nominal 155 Mb/s) and access lines at the DS3 rate (nominal 45 Mb/s), each adjusted to account for transmission overheads. Trunk topology and routing are carefully arranged to allow adequate trunk loading and provide simulation flexibility and efficiency. Inthe FR/ATM combination, the hubs convert between Frame Relay and ATM protocols. Hubs also perform routing and address translation functions. Each customer location multiplexes traffic from four distinctive types of sources: voice, video, data and image. Output queuing at customer locations and hubs is provided by a high-low (or T1/T2) queue [2], a dual queue module with a timer-based service mechanism (see Figure 2). Voice and video connections are put in the "high" priority queue and the data and image connections in the "low" priority queue. These are not strict priorities, however, since the there is a limit (timer) on how long the high priority queue is served until service switches to the low priority queue (with a similar timer controlling its service). Abase traffic mix of roughly 5% voice, 60% video, 20% data and 15% image provides a trunk load of approximately To obtain trunk loads of 0.85 and 0.95, more data and voice traffic is added. Access lines are relatively lightly loaded. Connections traverse 1, 2 or 3 trunks (hops) Pure The 802.6/802.6 configuration consists of an bus pair serving as a metropolitan area network (MAN), with eight customer locations connected to it via access lines (Figure 3). All buses operate at the DS3 (nominal 45 Mb/s) rate. A base traffic mix (with approximately the same ratios as in the FR/ATM and ATM/ATM configurations) again provides a load of approximately 0.75 on the MAN. Connections are established evenly among the MAN stations over Frame Relay The topology for the 802.6/FR combination is a combination of the two previous topologies (see Figure 4). It consists of four Frame Relay hubs interconnected by trunks, each providing access for a pair of customer premises locations. The access portion consists of two customers connected to an MAN via access lines. The MAN in turn is connected to its hub via a gateway station that converts between the protocol and Frame Relay. All access lines and trunks in this combination operate at the DS3 rate (nominal 45 Mb/s). The base traffic mix again has approximately the same traffic ratios and loads the Frame Relay trunks to approximately Trunk loads of 0.85 and 0.95 are obtained by adding voice and data traffic. Connections with different hop counts are provided as in the FR/ATM and ATM/ATM combinations Performance Criteria The performance criteria are delay and throughput. Delay is measured across the entire network (not on a link basis) from the time the first bit of the appropriate data unit enters the network until the last bit leaves the network. Two types of delay are measured. The first type is "network" delay, which is the delay of the data units from the input of the source access link to the output of the destination access link. The second type is "end-end" (or user) delay, which is the delay perceived by an end-user. This includes packetization delay (for voice and video) and all destination re-assembly delays for the larger data and image packets. Petr, Frost, Neir, Demirtjis, Braun Page 4

5 For all Phase I simulations, all queues were set large enough so that no overflow occurred. 2.3 BONeS Models This section describes the BONeS data structures, source models, and network models created for this project BONeS Data Structures Data structure planning is critical in BONeS projects. We defined a flexible data structure hierarchy for this project, anticipating future use of the developed models. Frame Relay, ATM and data structures were defined with fields corresponding to standards. To provide simulation flexibility and module re-use, a parent data structure (High Speed Generic) was defined, which included fields useful for simulation Sources Four traffic source models were developed to provide an integrated traffic environment for Phase I. Each source is capable of simulating several individual sources, each with its own network connection. Each source is also highly parameterized, allowing for customization without modifying the modules themselves. These traffic models are based on our previous experience and published studies [3-6]. The Voice source is a continuous bit rate source modeling active telephone connections. It produces fixed-length bursts at regular intervals. The Video source is a variable bit rate source modeling conference or high quality video connections. It produces fixed length bursts with exponentially distributed silence intervals. The Data source is a bursty source with a bimodal length distribution (data transfer and acknowledgements) modeling LAN-LAN data transfers. The Image source is also a bursty source, but it models very large image file transfers such as a hospital sending x-ray images or a shop-athome image database (reverse exponential length distribution). The silence periods of both data and image sources are exponentially distributed Frame Relay/ATM The high-level FR/ATM network is implemented in BONeS as interconnected Source (previously discussed), Router and Hub modules. The Routers serve primarily as the Frame Relay interfaces between the sources and the Frame Relay access lines, performing segmentation, address assignment and queuing functions. The Hubs segment frames from the access lines into ATM cells (and reassemble cells into frames) and perform address translation and routing functions on the cells. This system was thoroughly and systematically debugged and zero-load delays were verified ATM/ATM The ATM/ATM system is very similar to the FR/ATM system. The primary difference is that the Routers provide ATM cell segmentation (vs. frame segmentation), and segmentation is unnecessary in the Hubs. Zero-load delays were again verified following system debugging Pure The standard defines a high speed access protocol for use over a dual counter-flowing unidirectional bus network. It supports both isochronous and asynchronous traffic by implementing prearbitrated (PA) access and queue-arbitrated (QA) access, respectively. For efficient simulation, our Petr, Frost, Neir, Demirtjis, Braun Page 5

6 modeling of voice traffic (isochronous, PA) was implemented by subtracting the appropriate amount of bandwidth at the slot generator level. We used two of the QA priority levels, with high priority given to video traffic and low priority given to data and image traffic. These are strict priority service mechanisms, as opposed to the timer-controlled priorities used for FR/ATM and ATM/ATM. The stations perform all segmentation and bus access functions according to the standard definitions. To offset a location-dependent unfairness of the basic bus access protocol, a bandwidth balancing mechanism has been proposed for the standard, but we did not model this procedure, nor did we allow slot re-use. In the pure configuration, there are eight independent access buses sharing a single main bus, all operating according to the standard. The main bus stations transfer data between the main bus and the access buses. Propagation delays between stations on the access bus, between the last access station and its main bus station, and between main bus stations are all explicitly modeled. Our modeling of the protocol was thoroughly verified and validated, Test results were found to be consistent with previous studies, and zero-load delays were verified /Frame Relay This configuration essentially combined the models with Hubs. A gateway station was built for converting between and Frame Relay, including appropriate segmentation and re-assembly. The gateway stations also injected voice traffic into the FR backbone network (since this traffic is not explicitly carried on the buses) and included high-low queues for access to the FR access line. The Hubs were essentially identical to the ATM/ATM hubs, except that they operate on frames instead of cells. 2.4 System Parameters Loading and Routing Tables The process of generating specific traffic mixes, link loads and routing tables for any network simulation is definitely non-trivial, so a "C" program (make. route) was developed primarily for the Phase Isimulations to partially automate this task. Inputs to make. route include configuration, connection, load, base flow, incremental flow, and overhead tables. The configuration table specifies the type of routing to be used, the capacities of all links, and the average rates of each type of source. The connections table gives the topology of the network, including access lines and trunks. The load table gives the maximum allowed loads on each link in the network. The base flow table gives the minimum number of video, telephone, data, and image sources that should be present for each access line, along with their destinations. The incremental flow table specifies how traffic should be added to the base flow to reach the specified link loads. The overhead table specifies protocol overhead factors for each type of link and each type of source. Outputs of make. route are traffic information, parameter values, routing and address translation tables, all used in constructing or running BONeS simulations Source Parameters All voice sources in Phase I were continuous bit rate, 8 bit per sample, 8000 sample per second (64 kb/s) sources collected into bursts that would completely fill a cell or slot (e.g., no ATM Adaptation Layer Petr, Frost, Neir, Demirtjis, Braun Page 6

7 overhead). The video source average bit rates ranged from 3.5 to 5.0 Mb/s (depending on configuration) with bits collected into bursts that would completely fill two cells or slots. The data sources each had an average rate of 512 kb/s, with a bimodal packet length distribution and maximum packet length of bits. The image sources produced approximately one image per second with average length of 400,000 bits and maximum length of 500,000 bits Network Parameters For the FR/ATM and ATM/ATM configurations, access lines (Frame Relay) were set to operate at adjusted DS3 rates, and trunks (ATM) were set to operate at adjusted STS-3 rates. Queue sizes in the high-low queues were set large enough to avoid any data loss due to queue overflow. Timer values in the high-low queue were set to reserve sufficient average trunk bandwidth for the high (voice and video) and the low (data and image) priority traffic at the highest simulated load (0.95). Segmentation and reassembly processing delays were set to 0.1 ms and switch processing delays to 15 µsec. Propagation delay was set to 5 µsec/km; trunk lengths were set to 20 km and access line lengths to 2 km to model a network in a metropolitan area. In all Phase I simulations, statistics were not gathered for the first 10% of each simulation in order to allow steady state to be reached. For the pure configuration, maximum queue sizes were again set large enough to avoid queue overflow, and the network size was again made consistent with a metropolitan area. The parameters for the 802.6/FR configuration were a combination of parameters for the access portion and Frame Relay parameters for the Hubs. 2.5 Results and Discussion Most Phase I results are for network and end-to-end delay performance, with graphs presented as cumulative distribution functions (CDFs). The term "95% delay" means that 95% of the data units would have this delay or less. Results presented here are representative rather than all-inclusive; complete results are included in the BONeS databases delivered along with this report Individual Technology Combinations Several subsections present and discuss delay performance results for the four individual technology combinations. Results presented illustrate the difference in network and end-to-end delay (e.g., the effects of voice packetization delay and end-to-end packet re-assembly), delay as a function of number of network hops (1,2 or 3 trunks), delay as a function of network load (0.75, 0.85 and 0.95 on the trunks), and delay comparisons for the different traffic types (voice, video, data and image). End-to-end delays for image traffic are generally much longer than for other traffic due primarily to the very large image burst sizes (average of over 50,000 bytes). The pure results compare delay as a function of bus position rather than number of hops. Also, only 0.75 load was simulated for pure since the video, data and image delays for this load were almost as large as the ATM/ATM delays for 0.95 load Technology Comparisons This section directly compares the different technology combinations. The first comparisons are in terms of end-to-end delay for each type of traffic source for 3-hop connections (except pure 802.6, where there are no "hops") and normalized trunk loads of The FR/ATM and ATM/ATM combinations exhibited very similar performance for all traffic types. Voice delay ranges from a constant 6 ms for pure (isochronous traffic feature) to about 18 ms (95%) for 802.6/FR. Video 95% delays range from less than 2 ms for pure (video had strict high priority) to about 8 ms for 802.6/FR. There are great Petr, Frost, Neir, Demirtjis, Braun Page 7

8 differences in the data traffic 95% delays, with FR/ATM and ATM/ATM at about 7 ms, 802.6/FR at about 20 ms, and pure at many tens of ms (due to strict high priority of video and low priority of data and image traffic). Image delays behave similarly to data delays, but are much larger due to the very large image blocks; 95% image delays are about 150 ms for FR/ATM and ATM/ATM, 500 ms for 802.6/FR and about 800 ms for pure In connection with the above delay results, it is also important to realize that the FR/ATM and ATM/ATM combinations carried nearly four times the total network traffic as the pure and 802.6/FR combinations, due to faster trunk speeds. The combination of larger network capacity and good overall performance for all traffic types definitely favors the FR/ATM and ATM/ATM combinations. We also compared the maximum queue fills reached in each of the simulations to get an idea of required buffer sizes for very low queue overflow probabilities (the queues were set very large in Phase I to avoid queue overflow altogether). Even at trunk loads of 0.95, queue sizes of about cells or frames would probably have been sufficient to avoid queue overflow in the Phase I simulations. For reference, approximately 50,000 video cells were generated in the FR/ATM and ATM/ATM simulations between each pair of endpoints. 2.6 Conclusions and Possible Phase II Work Conclusions We list here several important conclusions from the Phase I work which are discussed in more detail in the main report. First, technology is not particularly well-suited to integrated traffic, even though its definition contains mechanisms supposedly designed to support such traffic. In particular, the strict priority mechanism for the queue-arbitrated traffic (and to a lesser extent the isochronous traffic mechanism) has insufficient flexibility to provide good delay performance to all traffic classes. For the above reason and since performance depends on bus position, networks should be lightly loaded. Another conclusion is that higher link speeds are better than lower link speeds. This is totally unsurprising, but nonetheless significant since ATM is expected to be viable at trunk speeds of 155 Mb/s and up, which is probably not true of Frame Relay or Combined with the smaller store-andforward delays for ATM backbones compared to pure (unsegmented) Frame Relay backbones, we conclude that ATM is the preferred backbone technology, even if customer interfaces are Frame Relay. In fact, if access link loads are kept light, the choice of access mechanism is relatively unimportant. Both FR/ATM and ATM/ATM configurations are quite capable (from a delay standpoint) of supporting real-time services such as voice and video. The excellent balance of delays between real-time and non-real-time traffic is largely due to the flexibility of the high-low queue mechanism used in our simulations Future Work Possibilities: Phase II There are many possible areas of concentration for Phase II of this project. These include further work on traffic source models, investigations of source traffic control (traffic descriptors and policers), additional work on queue service mechanisms or selective discarding mechanisms (or both), expansion of network models, and characterizations of cell and frame losses. The plan of work for Phase II will be defined through discussions with Sprint personnel. We also discuss in the main report the possibility of studying a dynamic high-low queue and present some preliminary results showing its promise. Petr, Frost, Neir, Demirtjis, Braun Page 8

9 3. Performance Evaluation Plan This section describes the details of how the network models are constructed (i.e., topology, trunk loading and performance evaluation) for each of the four technology combinations: Frame Relay/ATM, ATM/ATM, Pure 802.6, and 802.6/Frame Relay. Particular network configuration choices were made for the Phase I evaluations, but the BONeS models developed as part of this effort are general enough to be configured in many other ways with virtually no modification. All performance evaluations were accomplished via BONeS simulations. 3.1 Frame Relay/ATM and ATM/ATM Configurations Figure 1 shows the basic network topology of the configurations involving the Frame Relay and ATM access combinations. This topology will work with either Frame Relay or ATM functioning on the access links and either Frame Relay or ATM functioning on the backbone trunks. The combinations of interest are Frame Relay/ATM and ATM/ATM, with the access links at DS3 rates (45 Mb/s) and trunks at STS3 rates (155 Mb/s). The actual rates used are shown in the tables in section 5.2. The actual rates are based upon overheads associated with carrying ATM on SONET trunks and Frame Relay or ATM on DS3 trunks. For example, for ATM over SONET 4 of 90 columns are taken up by overhead, so the actual data rate is: (86/90)155 Mb/s = Mb/s. Two crossing trunks (joining hubs 1-3 and 2-4) were included in the original proposal, but have been removed from the topology for the following reason. If we assume the access lines are DS3 lines and the backbone trunks are STS-3 then we can have a load of 1.0 on all backbone trunks with this new topology. However, if we were to include the crossing trunks then we couldn t have a load of 1.0 on all backbone trunks because the access lines would saturate before the backbone trunks. In addition, the new topology allows us to easily define 0, 1, 2, or 3 hop traffic (where a hop is defined as the number of trunks encountered along the path), assuming all traffic flows in a clockwise direction. Zero hop traffic occurs when a connection is established between users connected to the same hub (switch). Output queuing at customer locations and hubs is provided by a high-low (or T1/T2) queue [2], a dual queue module with a timer-based service mechanism (see Figure 2). Voice and video connections are put in the "high" priority queue and the data and image connections in the "low" priority queue. These are not strict priorities, however, since the there is a limit (timer T1) on how long the high priority queue is served until service switches to the low priority queue (with a similar timer controlling its service). For all Phase I configurations we have homogeneous sources (all sources have approximately the same traffic mix). The base mix consists of 3 video sources operating at an average rate of 5 Mb/s each, 9 image sources with an average rate of 384 kb/s each, 9 data sources with an average rate of 512 kb/s each, and 18 telephone sources with a constant rate of 64 kb/s each. The video sources are 2 hop connections. The image sources are 1, 2, and 3 hops (3 of each type). The data sources are 1, 2, and 3 hops (3 of each type). The telephone sources are 1, 2, and 3 hops (6 of each type). This base mix provides a load of approximately 0.75 on the trunks. We are interested in the performance of the system at loads of on the trunks. To raise the load, additional data and voice sources are added to each customer premises (CP) location (CP Mux). This works as follows. Six telephone sources are added to each CP Mux (1, 2, and 3 hop; two of each type), then 3 data sources are added (1, 2, and 3 hop; two of each type). This process is repeated until no more telephone or data sources can be added without exceeding the desired load. A computer program has been developed to automate the procedure (see section 5.6). Petr, Frost, Neir, Demirtjis, Braun Page 9

10 CP mux CP mux hub 2 trunk line traffic flow CP mux CP mux CP mux hub 1 hub 3 CP mux hub 4 access line CP mux CP mux Figure 1. Frame Relay/ATM and ATM/ATM Topology Queue 1 (High) T1 Demux T2 Shared Server Queue 2 (Low) Figure 2. High-Low (or T1/T2) Queuing Mechanism To increase the loads on the access lines, zero hop traffic can be added. Zero hop traffic is traffic that flows between access lines connected to the same hub. The result is that the loads on both the access and trunk links can be made as high we need, so that we can stress the network. The Phase I evaluations, however, donot include any zero hop traffic. Petr, Frost, Neir, Demirtjis, Braun Page 10

11 3.2 Pure Configuration Figure 3 shows the topology used to provide access lines interconnected by an MAN. The access lines and the MAN trunks are both DS3 rate (45 Mb/s). The actual link rate is given in section 5.4. MAN MAN to access line interface Gateway slot generator data data data data data data data data access line voice voice voice voice voice voice voice voice video video video video video video video video image image image image image image image image Figure 3. Pure Topology Because the access lines and the MAN trunks are the same rate it is no problem to generate a high load on the MAN trunk (which is what we are interested in doing here), but if we were to use the base load given in the previous section, the MAN would become heavily overloaded. So the number of sources in the base mix is cut by a third to give: 1 video source per access line, 6 telephone sources per access line, 3 data sources per access line, and 3 image sources per access line. The average rate of the video source is reduced to 3.5 Mb/s to make the load on the trunks the same as the FR/ATM scenario. This new mix with the reduced video rate gives a load of about 0.75 on each MAN trunk. The routing is symmetric so the loads and traffic mix on each MAN trunk are equivalent. Higher loads can be reached by adding telephone and data sources in the same manner as described in the previous section /Frame Relay Configuration Figure 4 shows the topology for the over Frame Relay model. The access lines are DS3 rate (45 Mb/s), the MAN and Frame Relay trunks are also DS3 rate (45 Mb/s). The actual data rates are given in the tables in section 5.5. Petr, Frost, Neir, Demirtjis, Braun Page 11

12 hub 2 Frame Relay Trunk Frame Relay Access Line hub 1 hub 3 SMDS MAN and Access Links hub 4 Gateway 1 2 slot generator SMDS access line data voice data voice SMDS MAN video video image image Figure over Frame Relay Topology Again because the access lines and trunks are the same rate, the trunks would be overloaded by the traffic mix given in the FR/ATM scenario. So the number of sources in the base mix is again cut by a third relative to the FR/ATM and ATM/ATM configurations: 1 video source per access line (2 hop), 6 telephone sources per access line (1, 2, and 3 hop; two of each type), 3 data sources per access line (1, 2, Petr, Frost, Neir, Demirtjis, Braun Page 12

13 and 3 hop; one of each type), and 3 image source per access line (1, 2, and 3 hop; one of each type). The average rate of the video source is adjusted to 4.0 Mb/s to make the load on the trunks the same as the FR/ATM scenario (0.75). Higher loads are obtained by adding telephone and data sources as described in section 5.6. The MAN and access links can be loaded down with the addition of zero hop traffic, that is, traffic which flows from one access line to another access connected to the same MAN. Again, however, no zero hop traffic is included in the Phase I evaluations. 3.4 Performance Criteria The Phase I performance criteria are delay and throughput. Losses are not reported for the Phase I performance evaluations, since all queues are set large enough so that no overflow occurred. To negate any transients, all statistics are gathered after 10% of the simulation time has elapsed. Delay is measured across the entire network (not on a link basis) from the time the first bit of the appropriate data unit enters the network until the last bit leaves the network. Two types of delay are measured. The first type is "network" delay, which is the delay of the data units that exist on the access links. For example, in the ATM/ATM simulations this is cell delay, measured from when the first bit leaves the cell segmenter until the last bit arrives at the re-assembler. The second type is "end-end" (or user) delay, which is the delay perceived by an end-user. For telephone sources, this includes the time to accumulate a voice frame or cell (48 bytes at 64 kb/s). For the longer data and image "packets", it was measured from when the first bit arrives at the segmenter until the last bit leaves the re-assembler. In each configuration, we monitor the performance of only part of the traffic, with the remainder acting as interference traffic. We monitor the video, telephone, data, and image ports of a particular destination (it doesn t matter which destination since the sources are homogeneous and the routing is symmetric). At an arbitrary destination we obtain the statistics for: video (2 hop only), data (1, 2, and 3 hop), and telephone (1, 2, and 3 hop). An exception is made for the image traffic. Since only a few images are generated by each source in our simulations (approximately 1.5 sec of simulated time), we aggregate the events occurring at all eight image sources, yielding 1, 2, and 3 hop image statistics for the entire network. For the pure simulations, no telephone statistics are gathered because telephone traffic is carried isochronously. This is modeled by having the slot generators periodically drop slots corresponding to the bandwidth taken by telephone traffic on the link. Petr, Frost, Neir, Demirtjis, Braun Page 13

14 4. Bones Models This section describes the BONeS data structures, source models, and network models created for this project. 4.1 BONeS Data Structures Figure 5 shows the BONeS data structure hierarchy created for this project. The parent data structure is HS Generic. The HS Generic data structure contains fields common to ATM, Frame Relay, and (SMDS). These data structures have been designed anticipating future use of these BONeS models for evaluating a wide variety of high-speed networking technologies. Table 2 shows a list of the fields of the HS Generic data structure. Any data structure that is a child of HS Generic will inherit the fields shown in Table 2. DMPDU IMPDU Segment Slot HS Generic ATM Cell Frame Relay Frame Figure 5. BONeS Data Structure Hierarchy TABLE 2. HS Generic Data Structure Field Name Type Description VC Integer Virtual Circuit Number Data Root-Object Encapsulated Information Length Integer Length of cell/frame/packet including overhead Service Priority Integer 0=voice, 1=video, 2=data, 3=image Sequence Number Integer Used in reconstructing information stream Order Number Integer Used to check for missing info during assembly Time Generated Integer Time DS was created Hop Count Integer Used to record number of hops a DS encounters (Formerly Future Expansion 1) Future Expansion 2 Root-Object Not currently used Because of the way in which the data structure hierarchy has been set up, general segmenter and assembler modules were constructed that operate on HS Generic type data structures, and these modules can be used by any data structure that is a child of HS Generic. Soany module that only operates on the Petr, Frost, Neir, Demirtjis, Braun Page 14

15 common fields can be made into a general module that can be used by ATM, Frame Relay, or802.6 (children of HS Generic). In addition, if new children are added to HS Generic these general modules will also work on them. In addition to the segmenter and assembler modules, the High-Low Queue and the Switching Fabric modules were created to operate on HS Generic data structures. Currently there are three children under HS Generic: ATM, Frame Relay, and (SMDS). These data structures are used as placeholders (i.e., they contain no new fields). Under the placeholder data structures are the actual definitions of the protocol s data structures. For example, Table 3 shows the additional fields added to make the ATM cell data structure. As the table shows, only the VCI field is used in Phase I. The others were added to make the data structure complete, and they might be used in subsequent work. Remember that all fields created in the HS Generic DS will be inherited by the Cell DS. The VC and FutureExpansion fields in the HS Generic DS are the only fields inherited in the Cell DS that are not used. The Data field contains the payload information. The Length field is always set to 384 bits (48 bytes) for ATM. The ServicePriority field is set depending on what kind of information the cell is carrying (voice, video, data, or image). The Sequence and Order number fields are used in reconstructing cell streams. The Time Generated field is used for measuring cell delay. The fields Length, Service Priority, Sequence Number, Order Number, and Time Generated do not actually appear in the standard definition of an ATM cell; they are included here for simulation purposes only. TABLE 3. Additional Fields Added to Create Cell DS Field Name Type Description GFC Integer Generic Flow Control - Not Used VPI Integer Virtual Path Identifier - Not Used VCI Integer Virtual Channel Identifier PT Integer Payload type - Not Used RES Integer Reserved for future expansion - Not Used CLP Integer Cell Loss Priority bit - Not Used HEC Integer Header Error Control - Not Used 4.2 Sources A description of the BONeS source models is given next. These sources are based on our previous experience and published traffic studies [3-7] Voice Source Model Figure 6 shows the BONeS model of the voice source. The model used here can simulate up to N telephone sources. N is a parameter of this module. Each telephone source is given a unique virtual circuit number, so that the individual voice streams can be identified when they leave the source. Figure 7shows how the output voice packet stream would appear if N = 3. If each voice source was 64 kb/s and the size of the packets (Voice Block Size) was 48 bytes (384 bits) then the interarrival time between packets would be 6 ms. The Uniform Pulse Train in Figure 7 generates pulses periodically so that the proper interarrival time is obtained. Each time a pulse is output by the Uniform Pulse Train a new voice packet is created. The voice packets are HS Generic data structures. After creating the data structure the length of the voice Petr, Frost, Neir, Demirtjis, Braun Page 15

16 Voice Source [ 4-Nov :32:32 ] Uniform Pulse Train Create HS Generic Insert Length Insert VC Insert Time Generated Insert Service Priority Insert Order Number Output Voice Voice Block Size (bits) Circular Counter TNow R- 0 P Voice Block Size (bytes) P Sampling Frequency P Sampling Size (bits) P N (Number of Phones) VC = 0? T F One Packet Time R T Counter Figure 6. BONeS Voice Source Model packet is inserted, then the VC number is inserted using a circular counter (0 to N-1 as shown in Figure 7). Next a time stamp is given to the voice packet. The time stamp is used to measure end-to-end delay of the voice packets. The time stamp indicates the time the last bit of the packet left the voice source. Next the service priority field is filled in with zero. Zero indicates the packet carries voice data. Last of all the order number field is filled in. The order number field is used at the destination to check that no voice packets have been lost Pulses generated to create voice packets. Figure 7. Voice Model time The two parameters Sampling Frequency and Sampling Size would typically be set to 8000 Hz and 8 bits, respectively, to represent a 64 kb/s voice source. Other combinations such 8000 Hz and 4 bits could be used if Adaptive Differential Pulse Coded Modulation (ADPCM) was used to reduce the voice source rate to 32 kb/s Video Source Model Figure 8 shows the BONeS model of the video source. The model generates fixed length (Video Packet Length (bits)) video packets with exponentially distributed interarrival times [3]. The model is capable of simulating an arbitrary number of video sources, all with the same average rate. The parameter Video VC controls the number of video sources. Each video source will have an average rate given by the parameter Average Video Bit Rate (bps). Starting at the left side of Figure 8 we see a Poisson Pulse Train generating pulses to create HS Generic data structures. The pulses are generated at a rate of Video Pulse Rate = Video VC Average Video Bit Rate Video Packet Length Next the video packet length is inserted into the data structure. The VC is chosen from a uniform Petr, Frost, Neir, Demirtjis, Braun Page 16

17 Video Source [ 5-Nov :07:37 ] Poisson Pulse Train Create HS Generic Video Packet Length Insert Length IU[0,N-1] - Param Insert VC 1 Insert Service Priority VC Order Number Vecter Mem Insert Order Number FIFO w/reject Select Length DS F Int to Real Output Link Rate R/ Abs Delay Insert Time Generated TNow R- Output Video P Video Packet Length (bits) P Average Video Bit Rate (bps) P Video VC Simple Counter Write Error (NUMERIC) Figure 8. BONeS Video Source Model distribution that ranges from zero to Video VC 1. Next a service priority of one is inserted. A service priority of one indicates that the data structure is a video packet. Next is a FIFO queue to space out the packets which might otherwise overlap due to the statistical number generation. The last thing done in this module is the time stamp. The time stamp indicates the time the last bit of the packet exited the video source Image Source Model This source could be used to model large image transfers such as a hospital sending x-ray images or a shop-at-home image database. Figure 9 shows the top-level model. The segmenter at the output of the image source is used to break down the images in case the receiving network is not able to handle large image bursts. Image Source [ 5-Nov :07:37 ] Image Bit Generator P Images per Hour P Number of Image Stations segmenter Image Out P Maximum Segment Size (bits) P Output Line Capacity (bps) P Max Image Size (bits) P Mean Image Length (bits) P Segmenter Processing Delay Figure 9. BONeS Image Source Model At this level (Figure 9) there are seven parameters: Petr, Frost, Neir, Demirtjis, Braun Page 17

18 Images Per Hour : Average number of image transfers per hour. Number of Image Stations : Number of connections from this source. Mean Image Length (bits) : Average length of image burst. Output Line Capacity (bps) : Capacity of link leaving Image Source. Maximum Segment Size (bits) : Maximum size of image packet leaving segmenter. Max Image Size (bits) : Maximum size of image packet entering segmenter. Segmenter Processing Delay (sec) : Overhead associated with segmenting. The parameter Number of Image Stations controls the number of VCs the module will simulate. Each VC will transmit images at a rate of Images per Hour, each with a length of Mean Image Length (bits). Note that all VCs share a common link, and the VC number field in the HS Generic data structure can be used to tell which VC the image packet is from and can be used for routing. Figure 10 shows the inside of the image bits generator. This source samples a reverse truncated exponential distribution to obtain the image packet length. The image packets are separated by exponentially distributed silence times. Image Bit Generator [ 5-Nov :08:10 ] Init Uniform Rangen - Param Abs Delay Reverse Truncated Exponential- Sprint Abs Delay Expon Rangen - Param Abs Delay R/ Output Line Cap. Create HS Generic Insert Length Insert VC Insert Service Priority Insert Time Generated Insert Order Number Output Data Round IU[0,N-1] - Param P Max Image VC Number P Mean Length (bits) P Minlength (bits) P Maxlength (bits) P Mean Silence Time (s) P Output Line Capacity (bps) Iconst TNow VC R- Order Number Vecter Mem Figure 10. Image Source - Low Level Starting at the left side of Figure 10 we see a Uniform Rangen Param module feeding an Abs Delay module. These two modules cause the image source to start producing packets at a random time so all image sources do not start transmitting at the same time. After this random start time a packet length is sampled from the the reverse truncated exponential distribution. The packet is delayed by the time required to clock the packet onto an Ethernet LAN. There are two branches after the delay. One branch introduces the silence time before creating another burst. The other branch creates the image packet and fills in the fields in the data structures and sends the data structure out. Petr, Frost, Neir, Demirtjis, Braun Page 18

19 4.2.4 Data Source Model Research studies [4,5,6] have shown that the packet size distribution of inter-lan traffic is essentially bimodal. The small packet size peak corresponds to acknowledgment packets, control packets and interactive traffic. Although these packets constitute a relatively large percentage of total packets, they account for only a small fraction of total bits due to their small size. Another peak is at the maximum packet size which is protocol related. Maximum size packets constitute only a small fraction of total packets but they account for a large percentage of total bits. The distribution for the silence time (i. e., the time between packets) is not very clear although an exponential silence distribution model may be appropriate. Another character of inter-lan traffic is that it is extremely bursty over an extremely wide range of time scales. Based on the above observations, we use a truncated two-exponential pattern to model a LAN data source with the following packet size density function: Pmin p(x) = C r_min e (x x_min) r_min + 1 Pmin r_max e (x_max x) r_max x_min < x < x_max where C is a normalization constant and x_min and x_max correspond to the small and large peaks, respectively. Figure 12 implements the data source described above in BONeS. The two left-most modules, Uniform Rangen Param and Abs Delay, provide an initial silence period delay so that all the bits generators don t start sending at the same time. After this delay a random switch selects between the truncated exponential and the reverse truncated exponential distributions. The truncated exponential models the small bits bursts and the other models the large bits bursts. The sample from this distribution plus the Ethernet overhead is put into the length field of bits data structure, then an output clocking delay is performed. After this delay a silence delay is performed. Then the random switch is re-enabled and the process starts over again. Data Source [ 6-Nov :03:48 ] Truncated Exponential- Sprint Init Uniform Rangen - Param Abs Delay Random Switch - Param Reverse Truncated Exponential- Sprint Abs Delay Expon. Silence Time Abs Delay Output Link Rate R/ LAN Clock Rate R/ P Max VC Number P Small Packet Exp. Mean (bits) P Large Packet Exp. Mean (bits) P Minlength (bits) P Maxlength (bits) P Probability of Small Packets P Ouput Link Capacity (bps) P LAN Clock Rate Create HS Generic Round Ethernet Packet Overhead I+ Insert Length IU[0,N-1] - Param Insert VC Iconst Insert Service Priority Insert Time Generated TNow VC R- Order Number Vecter Mem Insert Order Number Output Data Figure 11. BONeS Data Source Model Petr, Frost, Neir, Demirtjis, Braun Page 19

20 The parameters for this module are: Max VC Number - Number of VCs the source is simulating. Small Packet Exp. Mean (bits) - mean size of truncated exp. Large Packet Exp. Mean (bits) - mean size of reverse truncated exp. Minlength (bits) - minimum burst size (lower truncation). Maxlength (bits) - maximum burst size (upper truncation). Probability of Small Packets - probability of selecting truncated exp. distribution. LAN Clock Rate - bit rate of an individual LAN (e.g., Ethernet). Output Link Capacity (bps) - may be larger than the LAN Clock Rate if multiple LAN sources are being simulated. This model, like the others, is capable of simulating a number of simultaneous connections as given by the parameter Max VC Number. Each VC transmits on average 512 kb/s. 4.3 Frame Relay/ATM Next a description of the of the top level Frame Relay over ATM network is given. The High-Low Queue module, used extensively in our Phase I simulations, is also described. Finally, the results of a validation test are presented Top Level Model The top level of the ATM network with Frame Relay access (FR/ATM network) is constructed from six different BONeS modules (see Figure 12): eight identical sets of four traffic sources (video, voice, data, and image), eight identical Frame Relay routers, and four identical ATM hubs. The Frame Relay router provides several services to the sources to which it is connected and functions as a Frame Relay interface between those sources and the Frame Relay access lines. The packets that enter the router from the sources are HS Generic data structures (DS) which must be segmented to the correct lengths for Frame Relay frames, converted to a DS containing actual Frame Relay data fields (C/R, BECN, FECN, etc.), and queued by the router before being multiplexed on to the access line. In order to transport the source packets through the network as ATM cells, the hubs must segment the frames into 48 byte payloads and convert the Frame Relay DS into a DS containing ATM data fields (GFC, VPI, VCI, etc.). Each cell is then given a unique VCI and is routed to the destination by using the VC and port map tables that were generated with the make.route program (this program is discussed later in section 5.6) Two-Class Queue Model The High-Low Priority (H-L) Queue is a dual queue module with a timer-based service mechanism [2]. This mechanism allows for guaranteed allocation of bandwidth to two different traffic classes. The three main parts of the H-L Queue module (Figure 13) are the priority selector, the two queues, and the service modules. The priority separation is based on the Service Priority field in the HS Generic data structure. High Priority has a service Priority of 0 or 1 ( Voice and Video) and Low Priority has a Service Priority of 2 or 3(Data and Image). Once the separation is complete the packets are sent to the FIFO queues (High Priority Queue and Low Priority Queue). Petr, Frost, Neir, Demirtjis, Braun Page 20