A New Network Design Paradigm

The entry of the Internet, Intranets, Extranets and VPNs into the networking fields has altered the way networks must be modeled, designed and optimized. Many new design requirements have arisen due to recent technological advances and available application mixes.

The first major requirement is to take into account the nature of multimedia traffic being handled at each site. This will require the conversion of all traffic types into bits per second to allow full integration into either TCP/IP or ATM technology.

The second major requirement is to model desired (or required) traffic intensities (and not the actually observed ones) to handle business scenarios. The very fast changing traffic mixes and levels of traffic flows necessitate this second major requirement. Static traffic models are no longer valid since they are hard to measure and they are always fluctuating rapidly.

The third major requirement is to have a network design tool that is inexpensive, intuitive, iterative and interactive. In particular, such a tool must allow one to gather pertinent design data for all sites almost effortlessly. Since most networking specialists already know that a majority of network design effort is actually spent on collecting site related design data and not on network design effort itself, they can no longer depend on the traditional databases employed by telephone companies and long distance carriers. These traditional databases need constant updates due to the addition/overlays of NPAs (area codes). Instead, the new network design tool should employ the newly copyrighted database structured around 5-digit postal zip codes. Such a database should provide V&H coordinates (or Vertical and Horizontal), LATA numbers, site location names instantly when a list of zip codes is available. The new design tool should also allow rapid modeling of network topologies with major nodes and links at any desired hierarchy with a sole purpose to obtain an optimum topology iteratively. If necessary, only an optimum topology should be subjected to computer simulation based on detailed protocols. Detailed computer simulation generally requires the use of an expensive design tool.

The fourth major requirement is to use an optimum network topology as a basis of each request-for-proposal (RFP) or  a statement-of-work (SOW) that is sent to all the desired hardware vendors, local exchange carriers (LECs) and long-distance-carriers (LDCs) for meaningful responses. If RFPs or SOWs are not based on an optimized network topology, the enterprise is doomed to lose money during the entire lifecycle of a network system.

We will now quote some pertinent excerpts from the recent book "Network Design Using EcoNets" published by ITCP, Boston in 1997. We will focus on Chapter 2 in particular that provides a special language to describe the need for meaningful network design and analysis tools.

2.1 INTRODUCTORY REMARKS

Any network system can be modeled at any level of detail. Even the largest network system can be modeled as a single node that handles a certain mix of user transactions per second. As the model gets complicated, one has to define the performance of each network system in terms of a larger number of transactions and different mixes. User transactions become mixed with other transactions required to maintain a given level of network system integrity while providing an acceptable level of services to the subscribers.

The task of modeling is simply that of representing the entire system in terms of a network of nodes belonging to certain levels of an hierarchy.…. It will suffice to say here that a successive decomposition (each resulting in a different model) is continued until no more useful understanding results.

2.2 CONCEPTS OF SYSTEM ANALYSIS AND DESIGN

Figure 2.1 illustrates the relationship between modeling, analysis and design. It shows that it is very hard to separate the efforts generally associated with either modeling, analysis or design. Such efforts are completely intertwined. In general, an analysis effort should provide a prediction of system performance assuming correct distribution of transaction arrivals and their holding times. A system design effort on the other hand should yield a network system architecture and topology that will provide the desired performance. But in all cases, many passes will be needed to arrive at the correct system architecture and topology. The iterative process as illustrated in Figure 2.2 is probably the least understood by the telecommunications professionals. They still assume that the network design effort is a one-time effort executed on a large mainframe at the beginning of a network planning cycle. Many of them expect the use of detailed tariff-related data bases for each resulting topology during the above mentioned iterative process. Such an approach will always slow down the design process even on a mainframe. Since the topology of a network is mainly affected by architectural/technological choices and never by small perturbations in tariffs (consult Chapters 7 through 14 for justification), one should only employ simple models of tariffs in order to make the design process of Figure 2.2 a truly interactive one. See Chapter 6 for a discussion of a software package that achieves this goal while providing a user-friendly interface. Since this package runs on a desktop workstation, it also encourages a continuous use for studying the affects of new tariffs and technologies during the entire life cycle of each network system.

Figure 2.3 illustrates a life cycle of a properly designed network system. Ten tasks are executed in series. Modeling of existing environs, user requirement modeling (existing traffic intensities and performance ), user requirements growth modeling, analysis and design of all the alternative system cutover models, return-on-investment (ROI) modeling, choosing of the most cost-effective system, system implementation, system performance measurements after the cutover and documenting the results. Experience shows (1) that the task of network design takes the least time and (2) the most important event is the ongoing collection of the analysis and design tools required to system engineer the present and the previous network systems. The data base of all the tools represent the art and science of networking if these tasks are performed with diligence and patience for several complex network systems.

There are three basic methods of analyzing system performance: 1. Physical simulation, which requires the availability of the final system under investigation. Tests are performed under typical traffic loads to obtain all aspects of the performance. This is by far the most expensive and time consuming approach.

2. Computer simulation which requires a software modeling of all operations and running the program until one achieves a statistical equilibrium. The development of the simulation software may take a sizeable amount of time. Furthermore, the use of a mainframe for predicting the performance of every interesting configuration may cost a great deal of money.

3. Analytic simulation, which employs well-proven analytical techniques for modeling and predicting the performance of a network system or its elements. This method is by far the most elegant, the quickest and the cheapest.

 The author’s experience shows that even the most complex system can be broken into smaller and smaller components until analytical techniques can be employed and then the results are combined to predict the performance of the entire system. It must be emphasized that all methods yield approximate results since no one can simulate all possible environs. Large discrete systems are afflicted with too many design and traffic variables. The number of possibilities generally exceeds the number of electrons in the universe. In most cases, approximate analytical tools will generally yield more meaningful results than other methods considering cost and time constraints.

2.3 CONCEPTS OF SYSTEM PERFORMANCE

It is a sad fact of life that very little concern to performance is being given to most of the network systems that are being implemented or for which standards are being developed. The simple answer lies in the complexity and high costs related to the time consuming tasks of predicting the performance of any large network system. These observations apply both to public and private network systems. Performance of a network system generally deals with costs, throughputs, quality-of-service (QOS) and grade-of-service (GOS).

System costs should be reduced to monthly costs of transmission, hardware and network management/ operations. Experience shows that the monthly costs for hardware and network management/operation don't vary from vendor to vendor, and that it is a small portion of the total monthly costs. Therefore one can simplify the entire task by simply considering the monthly costs for transmission since these are directly dependent upon network topology - a bye-product of network design.

System throughput should be simply modeled as number of transactions (messages or packets) handled per second by the system. One must know the paths of typical transactions before one can compute the system throughput for each given topology.

System QOS should deal with bit error rates (BER) or error-free periods, reliability (or probability of mission success) and subjective quality of digitized voice/video received.

System GOS should deal with average delays experienced by packets. Again one must know the paths of typical transactions before one can compute the system GOS for each given topology.

Most of the published literature bundles GOS and QOS into a single category of QOS. That is fine as long as all aspects of performance are considered.
 

----------------------------------------------------------

---------------------------------------------------------------