Packet switching
Michael Debenham looks at the technology from the point of view of the user's requirements. The flexibility, capability and cost-effectiveness of
packet switched networks, coupled with their high degree of compatibility, can make them an irresistible choice.
The corporate user of switched data networks sees a number of benefits and costs associated with the technologies available to meet his requirements. The paper looks at the features of a packet-switched network that affect the operation and management of the system and the performance delivered to the end user. The importance of performance studies at the network design stage is discussed, and a methodology for integrating network and host performance evaluation is outlined. Keywords: computer networks, packet switching, network performance, network management
Metron Technology Ltd, 50 North Street, Taunton, Somerset TAI 1 LX, UK
a user viewpoint
The prospective user of a private packet-switched communications network is faced with a number of issues to resolve, including shortterm planning and the continuing task of operating the network satisfactorily. The planning process includes the resolution of fundamental questions such as: 'Do I really need a packetswitched network, or should I use switching multiplexers, a network of data switches or even my digital PABXs?' It also encompasses the problem of interworking terminals (possibly of several types) with a variety of mainframes or minicomputers, the associated protocol differences, the possibility of interworking with other networks and, very importantly, the sizing and design of the network itself. Operational issues centre on network management, which is normally taken to cover such matters as control, administration, statistics, diagnostic services and event reporting. However, there are other operational factors of importance to the corporate network user, particularly performance, availability and cost. There are also longer-term issues to be considered, such as the ability of the network to evolve and grow to meet the user's changing needs, and compatibility with other systems and networks that are or will become available, such as the ISDN. All these points apply with similar force to each networking technology, but the emergence of packet switching as the de facto standard for data
communications at levels 2 and 3 of OSI is concentrating interest on the ability of the technology to meet the needs of the user in these respects. This paper will examine the issues as seen by a corporate communications user contemplating the use of packet-switching techniques to provide all or some of his organization's data-communication requirements.
PLANNING -- WHY USE PACKET SWITCHING?
The primary benefit of packet switching is the increased line utilization that is potentially available by virtue of the multiplexing that is inherent in the concept of packets sharing a datalink. Whenever the traffic load is more than trivial, this is likely to provide an operational cost advantage over circuit-switched technology with its associated line idle time on every connection. However, this advantage is shared by statistical multiplexers, which can achieve similar savings on high-speed link utilization. It is interesting to note that most commercial statistical multiplexers use HDLC frames to control their high-speed links as does X.25; consequently there is usually little or no hardware difference between a small- or mediumsized statistical multiplexer and the equivalent PAD for X.25 working. It is often only the controlling firmware that determines the functionality of the product. The user's choice is likely to be
0140-3664/87/020088-04 $03.00 © 1987 Butterworth & Co (Publishers) Ltd 88
computer communications
determined in practice by a combination of cost factors and the corresponding features and facilities available from the competing technologies. Here, the flexible and powerful range of facilities that are brought by the alterable profile specified in the CCITT X.3 Recommendation 1 together with the inherent routing flexibility and consequent resilience of packet techniques have proved decisive for many users. The international standardization of the X.25 interface is an assurance of a high degree of compatibility among suppliers, and this is not yet true in the statistical multiplexer market. The growing number of computer manufacturers who provide an on-board X.25 capability for communications bears witness to the recognition of packet switching as a powerful standard.
T E R M I N A L A N D HOST INTERWORKING A completely new networked system is seldom installed without regard for existing systems and without the intention to interwork or to share terminals with other systems. Most probably, there will coexist both hosts and terminals from different suppliers with an interworking compatibility problem. The use of X.25 as a lingua franca will enable connections to be set up, and suitable choices of PAD profiles will handle differences of line speed, flow control method and formateffector handling. The additional parameters specified in the 1984 version of X.3 enhance this capability in respect of echo masking, parity handling and page wait features. However, the X.25 standard is limited to providing the networking capability at level 3 of the OSI model and will not resolve the differences between, for example, the screenhandling procedures of different manufacturers where these features are built into the intelligence of the terminal. The user must now rely on the additional (nonX.25) features included by many manufacturers within the PAD and associated equipment. The modular construction of much commercial packet-
vol 10 no 2 april 1987
switching equipment enables a range of special features to be provided either optionally or as standard. Two approaches are possible to the multihost, multiterminal problem. The conversion between standards (or that part of the conversion that cannot be handled by PAD parameter adjustment) can be carried out either in the PAD-related equipment or in the terminal itself. Where terminals are already installed, only the first option is likely to be practical, but where new terminals are to be obtained for communication with multiple host types, the multifunction terminal approach is greatly to be preferred. Here the manufacturer-dependent features are included as alternative control programs within the terminal, selectable by user action at the keyboard, while the PAD to which it is connected need contain only the standard X.3 and X.25 features. Other facilities that may be provided by PAD manufacturers include user-friendly means of conversing with the PAD, both to adjust the profile and to set up a call. No one who has used a packet network from a simple terminal and set up a call using a 12-digit address will doubt the advantages of mnemonic addresses and parameter setting using meaningful messages. Such features are usually also available on the more sophisticated data switches and switching multiplexers, and are in practice essential for X.25 users.
HANDLING PROTOCOL DIFFERENCES An extension to the multihost problem is the case of manufacturerdependent communication protocols at the networking level, such as 3270 or CO3. If it is necessary to connect equipment using such protocols over a packet-switched network, there are two approaches: protocol conversions between the host or terminal and the network, and adaptation of the network interface to handle the particular protocol. In the case of polling protocols that expect to see a cluster controller, it is
desirable to avoid passing the polling information across the network as this would cause a heavy packet overhead and kill the network performance. It is usual for packetswitching equipment suppliers to offer special network interfaces on a plug-in basis that cause the network to appear to the host as a cluster controller high-speed interface, and to the terminal as the low-speed interface. In both cases the host/ controller polling is simulated, with only live data being transmitted in packets across the network. The alternative approach of separate protocol converters may be necessary if no suitable network interface is available but should be avoided, if possible, on grounds of cost, efficiency and performance, all of which suffer from the extra step in the communications path.
C O M M U N I C A T I N G WITH OTHER NETWORKS The internetworking requirement of many communication-systems users may be considered under several headings: interfacing with existing systems, including in particular PABXs and LANs; interworking with other packet-switched networks, such as British Telecom's Packet Switch Stream; and intep~vorking with the ISDN. The nature of the problem is determined by the nature of the other network, and, in general, networks based on packet switching in the broadest sense (such as LANs, which are effectively distributed packet switches) are more effectively connected to an X.25 network than those based on circuit switching (such as PABXs). Even so, none of the three standard LAN technologies is directly compatible with X.25, and in each case a gateway is needed. Such gateways are available from the LAN manufacturers and from some X.25 manufacturers. The existence of the gateway should not be evident to the user; a well-designed gateway conforming to the 'maximum integration' concept will effectively extend the facilities of the packet network to the terminal or host attached to the LAN.
89
The most usual example of interfacing to a PABX is the utilization of the PABX wiring to connect terminals to a PAD or packet switch using data-over-voice techniques. Strictly speaking, this does not involve the PABX at all but may be the most convenient method of effecting a local connection that is transparent to the user. A more costeffective method may be for the terminal to use a dedicated PABX line for connection to a PAD, thereby offering a connection over the network to a distant host, but this offers the worst of both worlds, in that a two-stage call set-up is required, as well, possibly, as line drivers. In general, this is to be avoided unless essential, to eliminate the cable-laying problems that can arise in some buildings. Interworking with other X.25 networks, including public networks, offers no technical problems, provided that a watch is kept on the range of optional facilities provided by each network. The CCITT X.25 Recommendation of 19842 lists 28 optional user facilities, ranging from closed user groups to packet retransmission on failure. The user's primary concern will be to ensure consistency of availability and use of those facilities across the connected networks. Looking only a short time ahead, the advent of the ISDN will bring digital telephony and data together on one line to the user. At this stage, the public packet-switched networks in countries having an ISDN will be accessed via the ISDN rather than directly or by PSTN dial-up, as at present. Private ISDNs based on digital PABXs will offer similar facilities to the corporate user. In both cases, digital circuit-switched paths will be available for data rates between 8 and 64 kbit/s as a high-speed alternative to packet-switched access at speeds up to 8 kbit/s. The corporate user of a private packet-switched network will be able to interface his network to the ISDN at the PABX, which now becomes an ISPBX (Integrated Services Private Branch Exchange). At the end-to-end level there will be few interworking problems with X.25 networks when the call has been set up, but initially a two-stage call set-up
90
procedure may be required (the 'minimum integration scenario'). Further developments will lead to a single-stage procedure for call set-up, although this will be available only to packet-mode terminals at speeds up to 8 kbit/s (the 'maximum integration scenario'). A fuller description of ISDN/packet network intenNorking is given by Gleen 3.
NETWORK DESIGN The ready availability of packet switches, PADs and gateways from a number of manufacturers, each offering a good range of features and facilities both within and additional to the X.25 Recommendation 2, greatly simplifies the design process. However, a vitally important preliminary is the gathering of volumetric data relating to the expected use of the network, followed by sizing calculations to establish numbers of high-speed links, link capacities, switch capacities and the most suitable topology to handle expected traffic flows. Closely related to these activities is the estimation of performance in terms of network throughput, response times, blocking probabilities and call failure. Collectively this process is part of the science of performance engineering, which has been outlined in papers by Griffiths 4 and Harvey s. The performance experienced by users of packet-switched networks in recent years has not always been of the high standard originally expected. There are several reasons for this, including poor choice of PAD profiles, rule-of-thumb design techniques and lack of proper appraisal of the traffic load to be placed on the network. In each case, the proper application of performance-engineering techniques at the design stage would have avoided operational problems. The full procedures for analysing the performance of a network are specialized and at present beyond the scope of most users, but it is possible to analyse requirements so as to produce a meaningful performance specification for the equipment supplier to meet.
Quality of Service (QOS) is defined for packet networks by the CClTIunder the following headings: • call processing and transfer delays--seen by the user as extended response times, • failure due to c o n g e s t i o n - seen by the user as inability to establish or sustain a connection, • failure due to malfunction, • loss of service, • transmission performance - - seen by the user as error-free operation. For public networks, quantified objectives are set out for the first two of these factors by the CCII-I- in Recommendations X.135 and X.1366 respectively, and the remaining three are for further study. Private network operators should first establish a view of the level of performance they require under each heading, and use this to gauge the performance obtained in practice. If analytical or simulation modelling tools are available to analyse the network design, this data will be essential as a means of validating the model. A validated model can then be used to examine the effect of changing traffic loads and network configurations, leading to greater confidence in the design eventually selected and a better service to the end users. These concepts are examined further later in this paper.
NETWORK M A N A G E M E N T The management requirements seen by the operator of a networked information system include: facilities for the immediate control and administration of the network; a means of forecasting traffic loading; ensuring adequate capacity for growth; and providing for security, resilience and flexibility. Control of a network is facilitated by the ready availability of information on network performance, throughput, availability, failures, response times and delays. In the general networking case, such information is commonly provided by bolt-on network-management systems, which may vary from tailor-
computer communications
made monitors supplied by the network-equipment manufacturer to general-purpose monitor and control systems from a specialist supplier. The effectiveness of the former depends on the ability of the network to provide and transmit the information, while the latter type is commonly very powerful and effective but correspondingly expensive. It is a feature of packet-switched networks that they are inherently capable of providing a range of performance statistics and other management information and delivering it to any point on the network on demand. This obviously simplifies both the collection of information and the delivery of control signals. It also assists the provision of the wide range of data needed for network administration, including usage statistics, charging information, network configuration data and performance data. A significant user benefit is the ability to perform all network control and administration functions from any point on the network with no cost penalties. Any network user can be given the capability to set up a call to a management port and, subject to security and access control at that point, carry out management functions. It follows that it is seldom necessary for the operator of a packet network to make any significant investment in equipment for control and administration. The total network management concept also includes a number of 'offline' functions, covering design and performance issues, which were discussed briefly above. Historically these matters do not appear to have received much attention, although several papers have been published on the performance analysis of packet networks 7' 8, and organizations such as the Computer Measurement Group are taking an increasing interest in the effect of networks on overall system performance. The science of performance management has been well developed for mainframe computers and has been described by Garth 9. The extension of these techniques to attached network systems will provide the information system performance
vol 10 no 2 april 1987
analyst with the tools required to ensure adequate service levels to the networked user. Packet networks are the subject of much study in this context, and commercially available data network performance planning tools are likely to concentrate on this technology.
PERFORMANCE PLANNING It is useful to review the methodology of performance planning, which is essentially the same for both computer systems and attached networks. Effective performance planning depends on accurately representing both the system (host or network) and workload (batch quantities and transaction rates or traffic load). Analytical modelling or simulation techniques are then used to determine the expected performance of the system with the imposed workload, and the results are compared with the measured performance of the real system. At this stage, the modelling of both workload and system can be validated. Working with this validated model, the performance analyst can adjust the workload to represent expected changes in traffic volumes or new applications, and test the effect on performance of different network configurations. This enables the planning and design processes to be carried out with confidence, and network costs can be optimized to ensure that the user is given the service levels he requires without either performance degradation, caused by under provision, or excessive costs, caused by over provision. The use of this technique for performance evaluation depends on the availability of a means of modelling networks and traffic levels. The only practical method is computer modelling as used for mainframe capacity planning, and a cost-effective approach is to use one modelling tool for the total system of host plus network. There are, however, differences between the mathematical modelling algorithms used for the host and network, and care is needed to ensure accurate
representation of each part of the total system.
CONCLUSIONS Operators of private packet networks enjoy the advantages of flexibility, wide availability of equipment to a recognized universal standard, costeffective network management and compatibility with evolving networks including the ISDN. They also face the challenges of network planning and performance management to ensure adequate user service levels. These challenges can be most effectively met by the use of computer modelling techniques in conjunction with capacity planning of the attached host computer.
REFERENCES I 2 3
4
5
6 7
C C l f f Red Book, Recommendation X.3 Vlllth Plenary Assembly (I 984) CClI-I" Red Book, Recommendation X.25 Vlllth Plenary Assembly (I 984) Gleen, K E 'ISDN-- interworking with other networks' Brit. Telecom. Eng. Vol 4 (October 1985) pp 151-155 Griffilhs, P H 'The role of performance engineering in system design' BriL Telecom. Technol. J. Vol 4 No 3 (July 1986) pp 135-141 Harvey, C 'Performance engineering as an integral part of system design' Brit. Telecom. Technol. J. Vol 4 No 3 (July 1986) pp 142-I 47 CClTI" Red Book, Recommendations X.135/X.136 VIIIth Plenary Assembly (1984) Mills, K L 'Performance measurement problems in a packet-switched network' CMG Trans. No 52 (Spring 1986) pp 50-59 Burrington, P R H 'Service standards for packet-switched networks -- an introduction' Brit. Telecom. Eng. Vol 3 (October 1984) pp 197-200 Garth, M J A 'Benefits of capacity planning' Data Processing Vol 27 No I0 (December 1985) pp 9-I 2
91