NETWORK PLANNING AND DESIGN

Originally by Richard Van Slyke, Polytechnic University; Adapted.

In this article we deal with planning and design of data communication systems. We look first in Section I at the larger issues of how the organizational strategy, culture and policies affect planning and designing data communication systems. In Section II, we look at systematic methods for planning and design. Planning and designing of data communication networks is immensely complex. We narrow the scope considerably. First, we limit ourselves to planning and designing medium size networks. These are most frequently owned by organizations for their own use; that is, private networks. This excludes the very large networks, especially those public networks implemented by communication service vendors such as the telephone companies, and the large internet service providers. On the other end, we do not consider networks that are so small that they can be purchased out of the box, and for which, the planning, design, and implementation can all be carried out by a very few people, perhaps only one. We focus mainly on the network planning and design problems of user organizations with significant coordination issues; this usually means wide area networks. However, even those who work for common carriers and other communication service providers will find much of the material useful and certainly insight into the user (customer) perspective on these issues is valuable. With this reduction in scope, we are still left with much to consider. We give an overview of the most important aspects. Detailed treatments are cited in the reference section at the end of this article.

I. The Project Environment The Big Picture

Before, a data communications project even gets to the formal feasibility studies which are part of the development methodology that we propose in Section II, it is useful to make a top-down, qualitative evaluation of a proposed data communications system. Such an evaluation need not take much time or resources and may result in stopping unwise ventures early. This evaluation should start from a clear understanding of the structure, policies, and culture of the organization or organizations that will be using the system. The business role of the proposed application must also be clearly understood. For example, one should be sure that the project is not implemented just because some advanced or new technology seems interesting. On the other hand, one must be careful that focusing too narrowly on the business need does not unnecessarily limit or misdirect the technical approach. Since data communications projects take place in an environment of rapid technological advancement, it is important to closely examine technological risk. Finally, external factors such as government policy and regulation, the competitive situation, available technological services and products must be considered. We now consider these in order. Organizational Strategy and Culture Ideally, any data communications project should be planned in the context of a organizational information strategy and policy. Formal and informal policies regarding outsourcing, turn-key procurement, buying of services or in-house development are important. Sometimes policies affect the use of public versus private networks. The amount of human and technical resources in the data communication functions of the organization also strongly affects these choices. Developing a sensitive awareness of the organizational culture going into a project will help avoid later grief. For example it is very important to know where your organization is on the centralized/decentralized management continuum. Usually, but not always, management of an organization's network will be

centralized or decentralized according to whether the general management structure is centralized or decentralized. Unfortunately, electronic communication is so ubiquitous in modern business that it is hard to develop an overall strategic vision that is comprehensive and at the same detailed enough to be useful. But a modest effort can yield a strategy to guide the development. At this point you need to understand who are you connecting with the system, what the users are going to communicate, and what resources your organization hasfinancial, human, and timeto implement the project. Business role of applications in the organization When deciding on a data communication project, there can be two types of mistakes; attempting a project that is not justified, and not implementing a project that is necessary and/or valuable. You can often avoid these mistakes by asking yourself, what happens if the project fails, and then, what happens if the project succeeds? If the success of the project would not make a substantial positive difference in your organizations activities, then the project may need rethinking. Perhaps, a more aggressive approach is needed to make the project offer clear advantages. On the other hand if there are significant and unfortunate consequences of not doing the project, or if major opportunities will be lost, then, not only should the project go ahead, but a conservative path should be taken in its

development to make success more likely. In any case, it is important to recognize whether the application is seen as a requirement of doing business or as an opportunity for the organization. These initial evaluations do not substitute for, and should be followed by more formal return on investment, or cost-benefit analyses. But, it should not take numerical evaluations of several significant figures in financial models or assuming the successful application of extreme and risky technological approaches to make a project recognizably beneficial.
Technology push/ demand pull The impetus to implement technologically oriented projectswhich most data communications projects areis often characterized as pushed by technology, or pulled by demand. In the first case, the availability of new technology with major new capability leads to an evaluation of whether the technology can be used profitably within the organization. That is, a consideration of the technology precedes the determination of the business application. Demand-pull represents the situation where the planners start with a business need and look for the appropriate technology to satisfy it. A good example of both is e-commerce. Few traditional organizations that were early users of the technology felt a requirement to do business electronically. Rather, they saw the availability of the technology that might reduce costs, and expand markets. This is an example of technology push. Later, as electronic businesses became significant, electronic commerce became a competitive requirement. Technological risk; the bleeding edge The aggressiveness in which new technology is used in projects can strongly affect the chances of project success. If one is too aggressive in using new technologies before they are well proven; they may not be available when advertised, or they may not work as advertised. This can delay the project, prevent it from meeting its specifications, or, ultimately, make the project fail. On the other hand, too timid a use of technology can make the project obsolete the day it is cut over.

External Factors

The many external factors affecting your project should NOT be neglected. These include government(s) regulation, activities of your competitors, and the current and projected availability of technology.

II. Planning
System Development Methodologies It is important to have a formal planning procedure for any non-trivial project. There are many project-planning methodologies; however, most are similar. Many organizations have there own, "blessed", versions but the mapping from the methodology we suggest here to other methodologies should be reasonably straightforward. It is sometimes argued that most projects involve modifications of existing systems, and, therefore, formal system planning is too time consuming and offers meager benefits. This argument is often false in the premise and/or the conclusion. The exponential growth of web based communications, particularly e-commerce, using the Internet, calls for new networks or radical redesign of existing networks not an evolutionary change from previous networks. But even if the proposed project is a seemingly straightforward enhancement to existing systems, a sequence of incremental changes without a well thought out strategy guiding the development results in Baroque networks that are opaque to the user and difficult to manage. All the methodologies consist of a number of stages to be performed in the project development process. Whatever the methodology, it is essential that at the end of each stage management make an explicit and written decision whether to abort the project, proceed to the next stage, or go back to previous stage and resolve specifically defined issues. One typical methodology is outlined in Table 1 and discussed below.

1. Initial Definition of Scope and Main Objectives 2. Feasibility Study 3. Requirements Analysis 4. Functional or Black Box Specification 5. Options Analysis 6. System Architecture 7. Detailed Design/RFP 8. Implementation 9. Training and Cutover 10. Evaluation 11. Upgrading/Replacement Table 1: Steps of a Development Methodology
1. Initial Definition of Scope and Main objectives: At the start of a project, you will be often be given an informal characterization of the task at handsometimes very informal. A crisp, unambiguous, written characterization is necessary at this point. This description should summarize the results of the kind of strategic, high level analysis described at the beginning of the previous section. Some of the issues to be addressed are: Who is communicating with whom? Is the project designed to support communications within the company, communications with vendors and customers (business-to-business), communications with customers (retail) or a combination of these? What is to be communicated? What business functions will the proposed network support? What, in

general terms, is the business rationale for the project? What is the time frame for the proposed project? Who is on the net; who is off; what classes of services are to be provided? 2. Feasibility study: The feasibility study for a project is very important because it is usually the last opportunity to make major changes in the project before substantial resources are expended. At this point quantitative cost/benefit analyses are required to make sure that the project has a high expectation of success. Part of the feasibility study is to make sure that the budget and time allowance is sufficient for the objectives specified in the Initial Definition Step. The feasibility study will be based on assumptions that must be made explicit, in writing. For if, during the project, one or more of these assumptions becomes invalid, an immediate assessment of the project should be made to see if adjustments are needed to maintain feasibility. Another appraisal needed at this point is of technological risk. Choosing exactly which generation of technology to use is fundamental. Unfortunately, appropriate technology is a moving target. For most projects, available technology will improve significantly in the period of implementation. One popular indicator of the exponential growth of computer technology is Moore's Law, which, in one of its manifestations, tells us that the performance of computer chips as measured by the number of transistors doubles every 18 months. In any case, a project, especially a slowly developing one, will find technology growing under its feet. 3. Requirements analysis: The objective here is to refine and make quantitatively explicit the objectives of Step 1. This starts with specifying the explicit services to be provided; e.g., voice, data, web services, e-commerce, various types of multi-media. To the extent possible, future services must be provided for as well. For each service, one must quantify current traffic, and project this traffic into the future. Particularly difficult is traffic modeling for new or projected services for which there is no current traffic to use as a baseline. The least likely traffic for such a network is what you projected. Either the network fails and you get less traffic, perhaps, none, or the network/application succeeds in which case you have to take very rapid steps to prevent being overwhelmed. Quality of service is also an important issue in modern requirements analysis. Differing services require differing performance guarantees. For example, video and voice require stringent delay guarantees, while data connections permit no data loss or corruption. Thus traffic volumes must not only be characterized by their sources and destinations but by their quality of service requirements as well. The dynamic nature of traffic also offers complications. Traffic rates have trends and cyclic variations that must be considered. The load on most data communication systems grows with time. In addition traffic levels fluctuate by the time of day, day of the week, and season of the year. Collecting traffic data and reducing it to a form that can be used in design is extremely time consuming and error prone. The information is often incomplete and almost always come from multiple and conflicting sources. Requirements must be systematically represented. Each requirement can be represented as a list of data senders, a list of data receivers (these two lists often consist of one entry each, but, for example, multicasting applications have longer ones). For each of these requirements the type of communication service: voice, data, various types of multi-media must be specified. For each service the traffic volume is required. Usually a dynamic specification of the volume is necessary reflecting the daily, weekly, monthly, yearly traffic patterns and long term trends. Quality of service requirements need to be specified as well. These include delay constraints (both in magnitude and variation), probability of packet loss constraints, and guaranteed capacity, availability,

and reliability (e.g., diverse routing). Again, while we describe the process of collecting requirements as being independent of the design; in fact, the process is iterative. For example, the use of local area networks facilitates some kinds of multicasting. When these technologies are included in the design, unforeseen requirements often materialize. Fortunately, modern network management systems and standards offer support for requirements analysis. For example, the Management Information Base (MIB) of the Simple Network

Management Protocol (SNMP) offers much useful baseline information for the objects in existing networks--hosts, bridges, router, and hubs, as well as transmission facilities. RMON, a remote monitoring standard allows network wide collection of network-monitoring data, particularly from Ethernet LAN segments. RMON (RFCs 2021 and 1757) makes it possible to collect automatic histories of traffic statistics such as utilization and congestion.
Finally, some global requirements must be addressed. These include privacy/security issues, and

network management functions.

4. Functional or black box specification: The goal here is an input/output characterization of the system from the user's perspective. How does the system look from the outside? What do users see? What can they do? A careful consideration of human factors is essential here. The output of this stage is, in a sense, a contract with the user community defining what the communication system will do for them. For the credibility of the project it is essential to have objective (and preferably quantitative) targets for service: performance, reliability, response, ..., so that service to the users can be monitored. To the extent possible the system should include automatic monitoring of these service objectives measures. 5. Options analysis: At this point, with a good grasp of the objectives and requirements of the project, one can turn to the identification and evaluation of available implementation options. One way to do this is to use the information so far gathered and prepare a Request for Information (RFI) to send to vendors to gain a general notion of the equipment, facilities, and services they can provide which are relevant to the objectives and requirements. In any case, you need to systematically collect data on the devices, transmission facilities, software, and services that may be useful. In each case you need to know the features, the costs, the financing options (lease, buy, etc.), the availability, the reliability of the vendor, and the customer support. 6. System Architecture: The main task is to select from the options identified in the Options Analysis the networking approaches to be taken to support the Requirements identified in Step 3, and the functionality defined in Step 4. What roles do LANs, MANs, and WANs play? Is wireless technology called for? What kind of distributed computing applications are involved and how should they be supported by communications networking? If there are multiple networks, how do they interconnect? In addition, the acquisition strategy should also be identified: what elements to build, what to buy, and what to out-source. Standards play a very important role in designing communication systems. They often determine if you have the safety of alternative vendors. So you must decide which standards to require in your design. In today's environment of rapid technological change and uncertain requirements a primary objective is to maintain flexibility: lease, don't buy; use accepted standards; don't get locked into one vendors products or services. Pick technologies and architectures that scale; that is, that can be gracefully modified to support increasing demands without requiring radical redesign.

7. Detailed design/RFP: At this stage we prepare the documents against which purchases, implementation, contracts, and other financial commitments will be made. We must specify in almost stupefying detail how the communications system is to be implemented. Consultants and vendors may help, but the owner is ultimately responsible. The users of the system must be identified. The locations of the equipment must be specified. The applications that will be supported must be detailed. The capacity and performance of the systems must be quantified. Security and reliability requirements must be set forth. The costs of equipment, transmission, and services (including support, and maintenance) must be spelled out. Deployment and cutover, together with payment schedules must be set down. The cutover plan must make provisions for a fall back if the new system does not perform as well as expected so that essential operations are maintained. If possible, the new and old system should operate in parallel until the new system is proved in operation. Acceptance testing should be implemented as a formal procedure to determine that the development is complete. Arrangements for user training must be made. For systems involving technical risk or other uncertainties, a pilot project might be called for. Support for privacy and security must be specified. Network management tools to support the operation of the network must be specified in detail. 8. Implementation: This is the actual implementation of the network. The primary activity of the planner/designer is to establish a systematic review procedure to audit adherence to the detailed design document. In case of serious divergences it may be necessary to cycle back to earlier steps in the development process and make adjustments. The planner/designer usually plays an important role in the acceptance testing as well, which ends this step. 9. Training and Cutover: Hopefully, a detailed schedule has been prepared for user training to be completed before the cutover. If a pilot is part of the development plan, it is often useful to test the training plans as well. A critical decision here is when to allow the fallback facilities to be eliminated. 10. Evaluation: After the systems has been in operation for some time, it is important to have a scheduled and formal evaluation of the system in light of operational experience. Some of the factors that should be considered are: Did the system achieve its operational objectives? Do the users find the system responsive and dependable? What was/is the financial performance? Did the project come in within budget? Are the operational expenses within budget? Were the financial benefits of the project realized? How does the actual load on the system compare to the projected loads? 11. Upgrading/Modifications/Replacement. In virtually all cases, the Evaluation Step will identify many surprises, frequently unpleasant. These will often need to be addressed by modifications to the system. Moreover, it is never too early to start planning for the upgrading or replacement of the system. A major error is to look at network planning and design as an event rather than a process. Modifications, upgrades, and replacement will take place continuously. There will not be a point where victory can be pronounced and the project declared complete.