1.4 Overview of Analysis, Architecture, and Design Processes

1.4 Overview of Analysis, Architecture, and Design Processes

What are network analysis, architecture, and design? Network analysis is about studying network components (from network devices such as switches and routers, to requirements and performance levels) and their inputs and outputs to understand network behavior under various situations (Figure 1.2). Network analysis defines, determines, and describes relationships between network components for many conditions. In analyzing a network, we will examine the state of the existing network, including whatever problems it is having. We will also examine network goals and requirements, traffic flows, and user and application behavior. Analysis results include descriptions of requirements and traffic flows, as well as mappings of users, applications, and devices within the network environment (everything that is external to the network, for example, users, applications, devices, buildings, business environment).

Figure 1.2: Inputs and outputs to network analysis process.

Network analysis helps us understand what problems we are trying to solve, and in the process, we compile information that will be used in developing an architecture and design.

Network architecture uses this information to develop a high-level, end-to-end structure for the network. A network architecture develops the major network functions (e.g., addressing/routing, network management, performance, security) as architectural components that will be brought together to form the network; goals for the architecture; and sets of interactions, trade-offs, dependencies, and constraints (these will be described in detail later) that will be used to optimize the architecture. There usually is not a single "right" architecture or design for a network; instead there are several that will work, some better than others. Architecture and design focus on finding the best network (optimized across several parameters) for your customer. Network architecture also provides a set of guidelines that can be used to formulate the technical design of a network.

Results of the network architecture process include a reference network architecture (or just reference architecture), which is a description of the complete network, considering all of its architectural components. It is a compilation of the relationships developed during the network architecture process. Results also include descriptions of the interactions, trade-offs, dependencies, and constraints used to arrive at that architecture.

Figure 1.3: Inputs and outputs to network architecture process.

Network design provides physical detail to the reference architecture. During network design, you evaluate and choose technologies for each area of the network and develop strategies to connect these technologies across the network. You will learn how to set design goals, such as minimizing network costs or maximizing performance, as well as how to achieve these goals, through mapping network performance and function to your design goals and evaluating your design against its goals to recognize when the design varies significantly from these goals. Network design is also about applying the trade-offs, dependencies, and constraints developed as part of the network architecture. Trade-offs, such as cost versus performance or simplicity versus function, occur throughout the design process, and a large part of network design concerns recognizing such trade-offs (as well as interactions, dependencies, and constraints) and optimizing the design between them. As part of the design process, you will also learn how to develop evaluation criteria for your designs.

As we will see throughout the remainder of this book, network analysis, architecture, and design combine several things—requirements, traffic flows, architectural and design goals, interactions, trade-offs, dependencies, constraints, and evaluation criteria—to optimize a network's architecture and design across several parameters. These parameters are chosen and analyzed during the analysis process and prioritized and evaluated during the architecture and design processes. Upon completion of these processes, you should have a thorough understanding of the network and plenty of documentation to take you forward to implementation, testing, and integration.

Example 1.1

A network's architecture and design are analogous to the architecture and design of a home. Both the network and home architecture describe the major functional components of each (for the network, network management, addressing and routing, security and privacy, and performance; for the home, plumbing, electrical, HVAC [heating, vacuum, air conditioning], framing) and the relationships between them (for the network, interactions, dependencies, trade-offs, and constraints; for the home, where each component is placed relative to one another). The network and home designs are also similar in that they both provide physical detail to the architecture. For the network, this means where major network devices are located and, for the home, where ducts, outlets, faucets, drains, and so forth are located.

1.4.1 Hierarchy and Interconnectivity

All of these processes center around two important characteristics of networks: their levels of hierarchy and interconnectivity. Hierarchy is the degree of concentration of networks or traffic flows at interconnection points within the network, as well as the number of tiers of interconnection points within the network. In general, as networks grow in size and numbers of users, applications, and devices increase, hierarchies provide separation and structure within the network. Hierarchies are important because they help us in determining the sizes of networks, including routing and addressing configurations, and the scaling of network technologies, performance, and service levels. A key concept of this book is understanding these hierarchies, learning how and where they will occur, and learning how to take advantage of them.

Along with hierarchy, there must be some consideration for the degree of interconnectivity (or redundancy) in the network design. As hierarchy provides structure in the network, interconnectivity balances this structure by interconnecting the network at different levels in the design to provide greater performance through parts of the network. Interconnectivity is important in that it provides a mechanism to achieve performance within a hierarchical structure. The dynamic between hierarchy and interconnectivity is perhaps one of the most fundamental trade-offs in network architecture and design, and it shows up several times in the analysis, architecture, and design processes.

Hierarchy and interconnectivity may be a bit confusing at this point, but they will become clearer as we progress through the book. Hierarchy is fundamental to networking (as it is throughout nature): It provides a separation of the network into segments. These segments may be separate, smaller networks, or subnets, or broadcast domains. This is necessary when the amount of traffic on the network grows beyond the capacity of the network or when interactions between devices on the network result in congestion (e.g., broadcast storms).

Figure 1.4 illustrates levels of hierarchy and interconnectivity in a network. This is a typical tree structure for a network, with circles representing networks or routers and lines representing the communications links between networks and/or routers. In this figure there are four levels of hierarchy, from core (or backbone) networks to access networks closest to users. Note that the end points of this tree (commonly refereed to as leaves; they represent the end networks, devices, or users) all occur at the same level of hierarchy. This does not have to be the case; indeed, in most networks there are leaves at most levels of hierarchy.

Figure 1.4: Hierarchy and interconnectivity in a network.

An example of adding hierarchy to a network is changing from a flat (bridged or layer 2 switched) structure to a routed structure. This may be done to reduce the size of the broadcast domain or the number of devices that are reached by a broadcast message. Adding routing to the network breaks a broadcast domain into a number of smaller broadcast domains, and traffic flows are concentrated at routers. Figure 1.5 shows this scenario.

Figure 1.5: Hierarchy added to a network.

A content delivery network (CDN) is an example of adding interconnectivity to a network. A CDN bypasses the core of a network, where congestion is most likely to occur, and directly connects devices or networks lower in the hierarchy (Figure 1.6). This provides better, more predictable performance but can also affect the network hierarchy by modifying its routing behavior.

Figure 1.6: Interconnectivity added to a network.

1.4.2 Importance of Network Analysis

The importance of network analysis is emphasized in this book because experience has shown that networking personnel find it extremely valuable—once they are convinced of its importance. Analysis takes work, and when you know that there will be a payoff, you will be more likely to do that work.

In this book you will learn how to gather and analyze network requirements and traffic flows. Network requirements are requests for capabilities in the network, usually in terms of performance and function, which are necessary for the success of that network. Network requirements can be gathered and/or derived from customers, applications, and devices. Such requirements are fundamental to a network's architecture and design—they form the basis for customer expectations and satisfaction. Requirements, in conjunction with measurements on the existing network (if there is one), are used to derive traffic flows (sets of network traffic that have some common attributes, such as source/destination address, information type, routing, or other end-to-end information). Analysis of these flows imparts location and directional information onto requirements. This is where performance requirements and architecture start to converge and is often the point in these processes where one can begin to see where "hot spots"—focal points for network performance—will appear in the network. As we will see, evaluating security risks is also part of the analysis process.

Results of the analysis process, the requirements and flow specifications, are then used as input for both network architecture and design. In developing the network architecture, a number of component architectures, targeting particular functions of the network, will be evaluated. Desired component architectures will then be combined into the reference architecture, which will provide a high-level view of your network. This high-level view is then physically detailed during the network design process.

Network analysis is important in that it helps us understand the complexity and nuances of each network and the systems they support. Analysis also provides data upon which various decisions are made, and these data can and should be documented as part of an audit trail for the architecture and design processes. Such data help ensure that the resulting architecture and design are defensible.

Understanding Network and System Complexity

In general, networks and the systems that they support are becoming increasingly complex. Part of this complexity lies in the sophistication of the capabilities provided by that network. Consider, for example, how services can be incorporated into a current state-of-the-art network. Infrastructure capacity planning, which often includes traffic overengineering, may now be expanded to include support for delay-constrained applications and may contain a variety of capacity and delay control mechanisms, such as traffic shaping, quality of service at multiple levels in the network, service-level agreements to couple services to customers, and policies to govern and implement service throughout the network. (Note that quality of service refers to determining, setting, and acting on priority levels for traffic flows. A service-level agreement is an informal or formal contract between a provider and user that defines the terms of the provider's responsibility to the user and the type and extent of accountability if those responsibilities are not met. Finally, policies are high-level statements about how network resources are to be allocated among users.) Analysis of these mechanisms— how they work and interoperate—will be covered in detail later in this book.

Network and system complexity is nonlinear. Network optimization must consider competing and often conflicting needs. In addition, multiple groups with differing ideas and desires (e.g., users, corporate management, network staff) influence the network design. The network is either designed by committee or through a systematic approach that the groups can agree on.

Networks have evolved to incorporate more sophisticated capabilities. Early (first-generation) networks focused on supporting basic connectivity between devices and on how to scale networks to support growing numbers of users (e.g., segmenting networks using bridges or routers). Second-generation networks focused on interoperability to expand the scope and scale of networks to allow connections between multiple disparate networks. We are currently at the stage in network evolution where service delivery is important to the success of users and their applications. This is the generation of network services, which can be considered the third generation of networking. Figure 1.7 illustrates the various generations of networking and their interactions.

Figure 1.7: Generations of networking.

We are beginning to see steps toward next-generation capabilities, such as rudimentary decision making within the network. It may be expected that components of the network will evolve to become self-configurable and manageable, especially for those networks that must be configured or administered by end users (e.g., telecommuters, users of mobility/portability services). Indeed, this will become necessary as the complexity and performance of networks increase and as services offered by networks become more sophisticated.

Along with networks, users, applications, and devices are also evolving more sophisticated capabilities. An example of this is the dynamic between hierarchy and interconnectivity as can be seen in the current Internet. As application and device traffic flows evolve to incorporate information regarding quality, performance, and cost (e.g., real-time streaming media), it is expected that these characteristics can be used to ensure paths through the Internet that will support high performance or high-quality delivery of such traffic. Hierarchy in the Internet often forces traffic flows through nonoptimal paths, hindering high-performance, high-quality delivery. Figure 1.8 shows a hierarchy of multiple levels of networks from core (or backbone) network providers to access network providers. Traffic flows between end users may travel across several levels of this hierarchy.

Figure 1.8: Hierarchy and traffic flow.

To counteract the impact of hierarchy, interconnectivity can be introduced into the Internet at strategic points, providing shortcuts that bypass parts of the Internet. The result is that, for some select flows, paths are optimized for high-performance, high-quality delivery (Figure 1.9). The dynamic between hierarchy and interconnectivity exists in all networks to some degree, and part of the analysis process is determining where and how to apply it. In Figure 1.9, connections are added between networks at the same level of hierarchy, in essence providing a "shortcut" or "bypass" around part of the Internet, resulting in better performance characteristics.

Figure 1.9: Interconnectivity added to optimize traffic flow.

Analysis helps us understand how technologies influence networks, users, applications, and devices (and vice versa). This is important in understanding how users of the network will adapt to the network, which affects the overall life cycle of the network. Consider, for example, the evolution of routing protocols, shown in Figure 1.10. Although the Routing Information Protocol (RIP), an Interior Gateway Protocol (IGP) deployed as part of early TCP/IP releases, was simple and easy to use, its limitations were stressed as networks expanded to accommodate larger groups of users (workgroups), even groups of networks (autonomous system [AS]). Routing technology adapted by adding hierarchy to routing, in terms of new IGPs such as Open Shortest Path First (OSPF), as well as in development of Exterior Gateway Protocols (EGPs) such as Border Gateway Protocol (BGP), which can accommodate hierarchy in groups of networks (AS hierarchy). This process continues today as high-level policies are being introduced to control routing at a level above IGPs or EGPs, and BGP4 introduces hierarchy through grouping BGP4 routers into confederations. We will discuss routing protocols in detail in the addressing and routing architecture (see Chapter 6).

Figure 1.10: Routing evolution.

Similarly, users, applications, and devices also influence their environment. As new, upgraded, or different users, applications, and devices are added to a network, the requirements on that network may change. The analysis process should examine how the impact of high-end compute and applications servers, data storage, analysis and archival systems, and specialized environment-specific devices such as video cameras or medical equipment changes the network.

Finally, the analysis process helps us understand the forces and changes at work within the system (network and its users, applications, and devices). Networks are highly dynamic, changing the rest of the system and being changed by the system. Some of the factors leading to change in the system include usage behavior and patterns; what, how, where, and when each user impacts the system; the emergence of new capabilities, for example, optical switching, faster central processing units (CPUs) and cheaper memory; and changes in scope and scale of the environment, including consolidation and outsourcing.

Architecture and Design Defensibility

An important (and often overlooked) part of network analysis is that, when documented properly, analysis should provide information about decision making in the network architecture and design processes. During the analysis process, we are gathering data that can be used to determine which architectural and design decisions need to be made, details regarding each decision (including reasons for each decision), dependencies between decisions, and any background material used to arrive at these decisions.

Data from network analysis, along with any decisions made during the process, can be documented to form an audit trail, that is, the set of documents, data, and decisions, for the architecture and design. Audit trails are useful in describing and defending a particular network architecture or design. An audit trail helps address questions such as "Why did you choose that technology?" "Why doesn't this new network perform as expected?" or "Why did this network cost so much?" Having documented your analysis of the existing network, the problems to be addressed, requirements for the new network, and all decisions made regarding that network, you will be able to answer questions at any time about your new network.

Decisions made regarding the network architecture and design need to be defensible from several perspectives: budgetary, to ensure that network costs are within budget or to provide good reason why a budget has been exceeded; schedule, to ensure that time frames for development, installation, testing, and operations are being met; and resources, such as personnel or equipment, to ensure that the customer has everything necessary to build and operate this network.

An audit trail is also useful as a historical document about the network. Over time, after the network is made operational, new network personnel can review this document to understand the logic behind the way that network was designed. Ideally, this document should be periodically reviewed, with new information added regarding changes to the network. Thus, an audit trail becomes a history for that network.

Experience shows that the set of documents, data, and decisions in an audit trail can be vital in making day-to-day tactical design decisions throughout the project. The investment in time at this phase of the project can save large amounts of time and resources later in the project.

The Web is a great tool to use in building an audit trail. Since an audit trail contains information about the old network, the new network, and decisions made about the new network, having this information easily accessible by those who use the network makes a lot of sense. Putting such information on internal Web pages allows easy access by everyone, and changes or additions to the audit trail can be seen immediately. Although there may be some information that your customer might not want everyone to view, such as the results of a risk analysis, most information usually can be accessible to everyone. For information that is restricted (need-to-know), hidden and password-protected Web pages can be used. Of course, when putting sensitive information at a common location, such as a Web site, sufficient security from outside attacks (hackers) should be provided.

An audit trail can be developed using standard word processing and spreadsheet software tools, and software tools specialized for this purpose are available. Requirements, problem definitions, goals, decisions, and all background data are entered into the audit trail, and all information is time-stamped. Examples of audit trail information are presented later in this book.

1.4.3 Model for Network Analysis, Architecture, and Design

Networking traditionally has had little or no basis in analysis or architectural development, with designers often either relying on technologies that they are most familiar with or those that are new or popular or being influenced by vendors and/or consultants. There are serious problems with this traditional approach, particularly that decisions may be made without the due diligence of analysis or architectural development and that such decisions made during the early phases of the project are uninformed.

As a result, there may not be an audit trail for the architecture and design; therefore, the architecture and design are not defensible. In addition, such an architecture/design may lack consistency in its technological approach. Lacking data from analysis and architecture, we may not have a basis for making technology comparisons and trade-offs. Therefore, network analysis, architecture, and design are fundamental to the development of a network.

Network analysis, architecture, and design are similar to other development processes in that they address the following areas:

• Defining the problems to be addressed

• Establishing and managing customer expectations

• Monitoring the existing network, system, and its environment

• Analyzing data

• Developing a set of options to solve problems

• Evaluating and optimizing options based on various trade-offs

• Selecting one or more options

• Planning the implementation

In defining the problems to be addressed, this should be a quick evaluation of the environment and project, in essence performing a sanity check on the task at hand, as well as determining the size and scope of the problems, determining that you are working on the right problems, and checking the levels of difficulty anticipated in the technologies, potential architectures and designs, administration, management, and politics in that environment. As you size up the problems faced in this project, you should begin to estimate the level of resources needed (e.g., budget, schedule, personnel). You should also develop your own view of the problems affecting that environment. You may find that, from your analysis of the situation, your definition of the problems may differ from the customer's definition. Depending on how far apart your definitions are, you may need to adjust your customer's expectations about the project.

Example 1.2

Once, in performing an analysis on a customer's metropolitan-area network (MAN), I realized that the problem was not what the customer thought—that the technology chosen at that time, switched multimegabit data service (SMDS), and the routing protocol (OSPF) were not working properly together. Rather the problem was that the network personnel had forgotten to connect any of their LANs to the MAN. Of course, when they ran tests from one LAN to another, no data were being passed. It was an easy problem to fix, but a lot of work was spent changing the customer's view on the problem and expectations of what needed to be done. The customer originally wanted to change vendors for the routing equipment and replace the SMDS service. Eventually, the customer was convinced that the equipment and service were fine and that the problem was internal to the organization.

Although SMDS is not widely available anymore, its behavior as a nonbroadcast multipleaccess (NBMA) technology is similar to other currently available technologies such as ATM and frame relay.

An early part of every project is determining what your customer's expectations are about the project and adjusting these expectations accordingly. The idea here is not to give customers false expectations or to let them have unrealistic expectations; this will only lead to difficulties later in the project. Instead, the goal is to provide an accurate and realistic view of the technical problems in the network and what it will take to solve them. Customers' expectations will likely focus on budget, schedule, and personnel but may also include their opinions about technologies and methodologies. And, at times, politics become imbedded within the project and must be dealt with. The key here is to separate technical from nontechnical issues and focus on technical and resource issues.

Part of determining customers' expectations is understanding what customers want to do with their network. This may involve understanding the customer's business model and operations. In addition, the customer may expect to have significant input into the development of the network. As you set the customer's expectations, you may need to establish the lines of communication between the network architecture/design group, management, users, and network staff.

Having established what the customer's expectations are, you may need to adjust and manage these expectations. This can be done by identifying trade-offs and options for resources, technologies, architectures, and designs and then presenting and discussing trade-offs and options with your customer. Bringing customers into the process and working with them to make critical decisions about the network will help them become comfortable with the process.

If an existing network is part of this project, monitoring this network, as well as other parts of the system and its environment, can provide valuable information about the current behavior of users, applications, and devices and their requirements for the new network. Monitoring can also validate your and your customer's definitions of the problems with the existing network. When it is possible to monitor the network, you will need to determine what data you want to collect (based on what you want to accomplish with the data), any strategic places in the network where you want to collect this data, and the frequency and duration of data collection.

At this point in the process you should have several sets of information with which you can begin your network analysis. You may have historical data from network management; data captured during monitoring; requirements gathered from users, staff, and management; the customer's definition of the problem; and your definition. All of these data are used in the network analysis, of which there are three parts: requirements or needs analysis, flow analysis, and a risk (security) analysis. Information in these analyses can be placed on the customer's internal Web page, as mentioned earlier, although some information (e.g., the results of the risk analysis) may need to be kept private.

Results of the network analysis are used in the architecture and design processes, where sets of options are developed, including potential architectures, designs, topologies, technologies, hardware, software, protocols, and services.

These sets of options are then evaluated to determine the optimal solutions for the problems. Criteria will need to be developed throughout the analysis, architecture, and design processes in order to evaluate these options. Along with these criteria, you will use the results of the network analysis, including requirements, trade-offs, and dependencies between options.

Having selected one or more options, you will able to complete the network architecture and design and prepare for implementation. At this point you may consider developing a project plan to determine schedule, budget, and resources, as well as major and minor milestones, checkpoints, and reviews.