10.4 Developing Goals for the Network Design

10.4 Developing Goals for the Network Design

In choosing candidate network technologies for the design, applying them to the design, and determining how to connect them, we need to have a set of clearly defined goals for the network design. Developing design goals is part of understanding what is expected from the network, and thus, from the design.

Design goals dictate the characteristics to be used to optimize a network design. All design goals for a network project should be listed at this point in the process so that the design is properly balanced to meet all of the goals.

Design goals should be closely coupled to the architectural goals discussed earlier in this book. In fact, design goals may be derived directly from architectural goals. You may be able to identify a single primary design goal for your network, one that will drive the design. For example, a common design goal is to minimize the costs for the network. Another goal may be to maximize performance of the network, in general or for a specific application, device, or group of users. Yet another design goal may be to maximize security for the network, across the entire network for particular locations (e.g., at interfaces to external networks). In doing the network analysis (requirements, flow, and possibly risk analyses) for your network, you might find that such design goals may already be clear.

Common design goals include optimizing the following:

• Network deployment and operations costs, including the costs for circuits and services

• Security, including maximizing security across the network, mapping security to a particular group's requirements, or providing multiple security models within the network

• One or more network performance characteristics

• Ease of use and manageability of the network

• Adaptability to new and changing user, application, and device needs

• Supportability of the network

As with the network architecture, keep in mind that there are trade-offs between design goals. For example, a primary design goal of minimizing costs may lead to choices that trade off performance, security, ease of use, or adaptability for cost. Alternatively, if optimizing security is a primary design goal, it may lead to choices that trade-off cost and performance for security. Such trade-offs are not a problem as long as you understand what they are, know how they relate to the network design goals, and have them well documented.

The initial conditions (scope, scale, and problem definition) for your network project can indicate what your design goals will be. If you are designing a brand-new network for an environment that currently does not have any networking, then you will be free from the requirements and constraints of existing networks. Your design may call for the building of a scalable infrastructure, a high-performance backbone, or specialized workgroups. If you are designing a network upgrade, adding to an existing network, or adapting a network to a new application, then you are faced with the existing networks, along with their infrastructures, technologies, and protocols, as well as users who are familiar with working on those networks. For these types of environments, you may be guided by making the network transition as easy as possible, minimizing disruption to the existing networks, and may trade off other goals to meet these.

The requirements and flow analyses can also indicate design goals for the network. For example, requirements for guaranteed or predictable performance are an indication of high-performance, relatively sophisticated solutions. Composite flows indicate traffic consolidation, where capacity sharing and cost management can be applied. In the flow analysis, the unitary, two-part, and multipart flowspecs provide flow information for service and capacity planning, which directly correlate to the goals listed earlier. Service planning implies maximizing one or more performance characteristics, as well as providing security and adaptability to users and management. Capacity planning, on the other hand, can be used to optimize the available capacity of the network, which, in turn, can be used to optimize network costs and ease of use.

Another consideration is that design goals may change in priority from one part of a network to another. You may have a user group that requires high performance in a particular area (e.g., a server farm or computing cluster), which will require a high-cost solution, and the rest of the network is optimized to reduce costs.

It is possible that, in trying to establish your goals, you will find that users want everything: a solution that is low cost, high performance, easy to use and maintain, and adaptable to the users' changing needs. At this point you can do the following:

1. Pull you hair out (if you have any left by now)

2. Arbitrarily choose one or more goals

3. Attempt to show the trade-offs between goals to the users (and management)

4. Let the users and management prioritize their goals for the system

You can develop an argument for or against a design goal by developing a list of trade-offs associated with the design goal and presenting them to users and management. One often-used argument is the trade-off between cost and performance. A graph showing the relative costs of technologies, listed for each area of the network, allows those who make funding decisions to pick the level(s) of performance and to understand the costs associated with each level.

Figure 10.2 is an example of a graph comparing costs and performance for candidate technologies. A graph like this can be used to show that, for extra funding, a different technology or set of technologies can be used that will bring better performance or function to users, applications, and devices.

Figure 10.2: Cost/performance graph.

The result of determining your design goals is a set of prioritized goals, based on a primary design goal and one or more secondary goals. The primary design goal will override other goals when considering trade-offs between goals and will tend to drive the design. When the primary goal is met, secondary goals are used to complete the design. There are times when a design goal will also be a constraint on the design. Constraints are boundaries that we will not be allowed to cross or that we will have to pay a penalty to cross. Examples of constraints are overall deployment or operations budgets, strict network performance requirements, physical factors such as network distances and latencies, or deployment time schedules.

For example, let's consider a design project in which we are going to build a local workgroup network. For this design, we have been budgeted $1 million to be used to purchase PCs and the network. Each PC (or laptop) costs about $1000, and we are required to have between 300 and 600 new PCs in the network, depending on how much we spend on the network. However, we cannot have fewer than 300 PCs in the network. These PCs will be working together in workgroups of 30 to 60, and their performance requirements are estimated as 80 Mb/s capacity and a less than 100-ms delay between any two PCs in a workgroup.

For this design project, we are constrained by costs, the minimum number of PCs in the network, and by performance, particularly delay within a workgroup. A graph of budget allocations for PCs and the network—including network interface cards (NICs), LAN/workgroup hardware and software, and cable infrastructure if necessary—would look like Figure 10.3.

Figure 10.3: Budget allocation for example.

Figure 10.3 shows the range of network and PC costs, which will total $2 million and provide between 300 and 600 PCs for the network. This graph also shows the available technologies within allowable network costs. If we have a primary design goal of minimizing the overall budget for this project, we could choose to minimize the number of PCs, which will give us more funds for the network (possibly providing better network performance) while reducing the overall budget. If the design goal is to maximize network performance, we could reduce the number of PCs (somewhere between 300 and 600) and use all of the remaining funds for the network, which will not reduce the overall budget but will maximize the funds available for the network. Another possible design goal for this environment could be to make this workgroup network available to as many users as possible. This would drive us to maximize the number of PCs in the network, reducing both funding for the network and probably network performance.

Thus, the choices we make for primary and secondary design goals will affect our evaluation of the network design. It is important that you understand your design goals as you begin the design process.