Analyzing Technical Goals and Constraints This chapter provides techniques for analyzing a customer's technical goals for

an enterprise network design. Analyzing your customer's technical goals can help you confidently recommend technologies that will perform to your customer's exp ectations. Typical technical goals include scalability, availability, performance, security , manageability, usability, adaptability, and affordability. Of course, there ar e tradeoffs associated with these goals. For example, meeting strict requirement s for performance can make it hard to meet a goal of affordability. The section, "Making Network Design Tradeoffs," later in this chapter discusses tradeoffs in more detail. One of the objectives of this chapter you discuss technical goals with your many terms for technical goals, and, the terms. This chapter can help you an the same things by the terms. is to give you terminology that will help customer. Network designers and users have unfortunately, many different meanings for use the same terms as your customer and me

This chapter concludes with a checklist to help you determine whether you have a ddressed all of your customer's technical goals and constraints. Scalability Scalability refers to how much growth a network design must support. For many en terprise network design customers, scalability is a primary goal. Large companie s are adding users, applications, additional sites, and external network connect ions at a rapid rate. The network design you propose to a customer should be abl e to adapt to increases in network usage and scope. Planning for Expansion Your customer should be able to help you understand how much the network will ex pand in the next year and in the next two years. (Ask your customer to analyze g oals for growth in the next five years also, but be aware that not many companie s have a clear five-year vision.) You can use the following list of questions to analyze your customer's short-term goals for expansion: How many more sites will be added in the next year? The next two years? How extensive will the networks be at each new site? How many more users will access the corporate internetwork in the next year? The next two years? How many more servers (or hosts) will be added to the internetwork in the ne xt year? The next two years? Expanding the Data Available to Users Chapter 1, "Analyzing Business Goals and Constraints," talked about a common bus iness goal of expanding the data available to employees who use enterprise netwo rks. Managers are empowering employees to make strategic decisions that require access to sales, marketing, engineering, and financial data. Traditionally this data was stored on departmental LANs. Today this data is often stored on central ized servers. For years, networking books and training classes taught the 80/20 rule for capac ity planning: 80 percent of traffic stays local in departmental LANs and 20 perc ent of traffic is destined for other departments or external networks. This rule is no longer universal and is rapidly moving to the other side of the scale. Ma ny companies have centralized servers residing on server farms located on buildi ng or campus backbone networks. In addition, corporations are increasingly imple menting intranets that enable employees to access centralized Web servers using

Internet Protocol (IP) technologies. At some companies, employees can access intranet Web servers to arrange business travel, search online phone directories, order equipment, and attend distance-l earning training classes. The Web servers are centrally located, which breaks th e classic 80/20 rule. In the 1990s, there has also been a trend of companies connecting internetworks with other companies to collaborate with partners, resellers, suppliers, and str ategic customers. The term extranet is gaining popularity to describe an interna l internetwork that is accessible by outside parties. If your customer has plans to implement an extranet, you should document this in your list of technical go als so you can design a topology and provision bandwidth appropriately. In the 1980s, mainframes running Systems Network Architecture (SNA) protocols st ored most of a company's financial and sales data. In the 1990s and beyond, the value of making this data available to more than just financial analysts has bee n recognized. The business goal of making data available to more departments oft en results in a technical goal of merging an SNA network with an enterprise IP n etwork. Chapter 7, "Selecting Bridging, Switching, and Routing Protocols," provi des more detail on how to migrate SNA data to an IP network. In summary, the business goal of making more data available to users results in the following technical goals for scaling and upgrading corporate enterprise net works: Connect separated departmental LANs into the corporate internetwork Solve LAN/WAN bottleneck problems caused by large increases in internetwork traffic Provide centralized servers that reside on server farms or an intranet Merge an independent SNA network with the enterprise IP network Add new sites to support field offices and telecommuters Add new sites to support communication with customers, suppliers, resellers, and other business partners Constraints on Scalability When analyzing a customer's scalability goals, it is important to keep in mind t hat there are impediments to scalability inherent in networking technologies. Se lecting technologies that can meet a customer's scalability goals is a complex p rocess with significant ramifications if not done correctly. For example, select ing a flat network topology with Layer 2 switches can cause problems as the numb er of users scales, especially if the users' applications or network protocols s end numerous broadcast frames. (Switches forward broadcast frames to all connect ed segments.) Subsequent chapters in this book consider scalability again. Chapter 4, "Charact erizing Network Traffic," discusses the fact that network traffic--for example, broadcast traffic--affects the scalability of a network. Part 2, "Logical Networ k Design," provides details on the scalability of routing and bridging protocols . Part 3, "Physical Network Design," provides information on the scalability of LAN and WAN technologies and internetworking devices. Remember that top-down net work design is an iterative process. Scalability goals and solutions are revisit ed during many phases of the network design process. Availability Availability refers to often a critical goal ed as a percent uptime l time in that period. the for per For amount of time a network is available to users and is network design customers. Availability can be express year, month, week, day, or hour, compared to the tota example, in a network that offers 24-hour, seven-days

-a-week service, if the network is up 165 hours in the 168-hour week, availabili ty is 98.21 percent. Network design customers don't use the word availability in everyday English and have a tendency to think it means more than it does. In general, availability m eans how much time the network is operational. Availability is linked to redunda ncy, but redundancy is not a network goal. Redundancy is a solution to the goal of availability. Redundancy means adding duplicate links or devices to a network to avoid downtime. Availability is also linked to reliability, but has a more specific meaning (per cent uptime) than reliability. Reliability refers to a variety of issues, includ ing accuracy, error rates, stability, and the amount of time between failures. S ome network users use the term recoverability to specify how easily and in what timeframe a network can recover from problems. Recoverability is an ingredient o f availability. Availability is also associated with resiliency, which is a word that is becomin g more popular in networking magazines. Resiliency means how much stress a netwo rk can handle and how quickly the network can rebound from problems. A network t hat has good resiliency usually has good availability. Sometimes network engineers classify capacity as part of availability. The think ing is that even if a network is available at Layer 1 (the physical layer), it i s not available from a user's point of view if there is not enough capacity to s end the user's traffic. For example, Asynchronous Transfer Mode (ATM) has a connection admission control (CAC) function that regulates the number of cells allowed into an ATM network. If the capacity and quality of service requested for a connection are not availa ble, cells for the connection are not allowed to enter the network. This problem could be considered an availability issue. However, this book classifies capaci ty with performance goals. Availability is considered simply a goal for percent uptime. One other aspect of availability is disaster recovery. Most large institutions h ave a plan for recovering from natural disasters, such as floods, fires, hurrica nes, and earthquakes. Also, some large enterprises (especially service providers ) must plan how to recover from satellite outages. Satellite outages can be caus ed by meteorite storms, collisions with space debris, solar flares, or system fa ilures. Unfortunately, some institutions have also found the need to specify a r ecovery plan for man-made disasters, such as bombs or hostage situations. A disa ster recovery plan includes a process for keeping data backed up in a place that is unlikely to be hit by disaster, as well as a process for switching to backup technologies if the main technologies are affected by a disaster. The details o f disaster-recovery planning are outside the scope of this book. Specifying Availability Requirements You should encourage your customers to specify availability requirements with pr ecision. Consider the difference between an uptime of 99.70 percent and an uptim e of 99.95 percent. An uptime of 99.70 percent means the network is down 30 minu tes per week, which is not acceptable to many customers. An uptime of 99.95 perc ent means the network is down five minutes per week, which probably is acceptabl e. Availability requirements should be specified with at least two digits follow ing the decimal point. It is also important to specify a timeframe with percent uptime requirements. Go back to the example of 99.70 percent uptime, which equated to 30 minutes of dow ntime per week. A downtime of 30 minutes in the middle of a working day is proba bly not acceptable. But a downtime of 30 minutes every Saturday evening for regu

larly scheduled maintenance might be fine. Not only should your customers specify a timeframe with percent uptime requireme nts, but they should also specify a time unit. Availability requirements should be specified as uptime per year, month, week, day, or hour. Consider an uptime o f 99.70 percent again. This uptime means 30 minutes of downtime during a week. T he downtime could be all at once, which would be a problem, or it could be sprea d out over the week. An uptime of 99.70 percent could mean that approximately ev ery hour the network is down for 10.70 seconds. Will users notice a downtime of 10.70 seconds? Perhaps. For many applications, however, a downtime of 10.70 seco nds every hour is tolerable. Try doing the math yourself for a network goal of 99.80 percent uptime. How much downtime is permitted in hours per week? How much downtime is permitted in minu tes per day and seconds per hour? Which values are acceptable? The Cost of Downtime In general, a customer's goal for availability is to keep mission-critical appli cations running smoothly, with little or no downtime. A method to help both you and your customer understand availability requirements is to specify a cost of d owntime. For each critical application, document how much money the company lose s per hour of downtime. (For some applications, such as order processing, specif ying money lost per minute might have more impact.) If network operations will b e outsourced to a third-party network management firm, explaining the cost of do wntime can help the firm understand the criticality of applications to a busines s's mission. Specifying the cost of downtime can also help clarify whether in-service upgrade s must be supported. In-service upgrades refer to mechanisms for upgrading netwo rk equipment and services without disrupting operations. Most internetworking ve ndors sell high-end internetworking devices that include hot-swappable component s for in-service upgrading. Mean Time Between Failure and Mean Time to Repair In addition to expressing availability as a percent uptime, you can define avail ability as a mean time between failure (MTBF) and mean time to repair (MTTR). Yo u can use MTBF and MTTR to calculate availability goals when the customer wants to specify explicit periods of uptime and downtime, rather than a simple percent uptime value. MTBF is a term that comes from the computer industry and is best suited to speci fying how long a computer or computer component will last before it fails. When specifying availability requirements in the networking field, MTBF is sometimes designated with the more cumbersome phrase mean time between service outage (MTB SO), to account for the fact that a network is a service, not a component. Simil arly, MTTR can be replaced with the phrase mean time to service repair (MTTSR). This book uses the simpler and better-known terms MTBF and MTTR. A typical MTBF goal for a network that is highly relied upon is 4,000 hours. In other words, the network should not fail more often than once every 4,000 hours or 166.67 days. A typical MTTR goal is one hour In other words, the network fail ure should be fixed within one hour. In this case, the mean availability goal is 4,000 / 4,001 = 99.98 percent A goal of 99.98 percent is typical for mission-critical operations.