2.7 Network Requirements

2.7 Network Requirements

Figure 2.12 shows the relationship of the device component with the rest of the system.

Figure 2.12: Types of network requirements.

For the network component, requirements for a network architecture/design must consider the requirements, services, and characteristics of any existing networks that will be incorporated into, or interface with, the new network.

2.7.1 Existing Networks and Migration

Most network architectures/designs today need to incorporate existing networks. Few networks today are built entirely from scratch. This includes system upgrades, such as adding a new application to the system, migrating to a new or different technology or protocol, or upgrading the network infrastructure, and the expansion or reduction of a system's size or scope. Sometimes the network architecture and design must accommodate any dependencies and constraints imposed by the existing network. Examples include:

• Scaling dependencies. The existing network can affect how the planned network will scale. For example, how will the addition of the new network to the existing network change the size and scope of the system? Will the change be dramatic, as in growing from a LAN to a WAN, or will the change be within the LAN/MAN/WAN boundaries of the existing network?

• Location dependencies. Depending on how the new networks interface with or incorporate the existing network or how the network modifications are done, the locations and/or concentrations of other components of the system are likely to change. This will show up when we develop flows later in the analysis process.

• Performance constraints. The overall performance of the system will be affected by our architecture and design for the expected network (or network modification), how it interacts with the existing network, and its performance levels. Since the performance of the existing network will affect overall system performance, its performance characteristics should be integrated into the performance requirements of the planned network. Since the existing network is already in place, it is usually possible to measure the performance of this network. Thus, while the performance of the expected network is based on a best estimate, the performance of the existing network (and potential performance impacts) can be better understood.

• Network, system, and support service dependencies. These include network addressing strategies, security, choices, and configurations of routing protocols and naming strategies, whereas support services include system-wide security, accounting, and monitoring and management. Current and planned requirements for each of these should be considered.

• Interoperability dependencies. Interoperability dependencies between existing and planned networks occur at boundaries between the networks, usually where different technologies or media are used. In addition, by taking an end-to-end perspective on the design, the boundaries between existing and planned networks are points where service information and performance guarantees need to be translated, or they will be lost. Requirements should include the technologies and media of the existing network and any performance and/or functional requirements from the existing network.

• Network obsolescence. Even though there may be parts of the existing network that will be integrated into the planned network, these parts, including network devices, protocols, and software, may become obsolete during the life cycle of your new network. When possible, you should note that parts of the network that will be integrated into the planned network, yet are near the end of their usefulness, will need to be transitioned out of the planned network.

In addition, requirements for the users, applications, and devices of the existing network must be considered as part of the system being built and their requirements analysis done along with the analysis for new parts of the system.

2.7.2 Network Management and Security

Throughout the architecture and design processes we will discuss network management and security, so it will be useful to briefly outline their requirements here, as a start toward considering them in the architecture and design. It is likely that our analysis of network management and security later in the architecture and design processes will generate new requirements or modify some that we develop here. At this point in the analysis process, we want to think in general terms about how we may accomplish network management and security in the new network.

As we will see in the architecture and design processes, there are four categories of network management tasks:

• Monitoring for event notification

• Monitoring for metrics and planning

• Configuring the network

• Troubleshooting

Monitoring is obtaining values for network management parameters from network devices (e.g., routers, hubs, switches) of the system, processing the data, displaying some or all of the data to network operators, and archiving the data. Monitoring for event notification involves taking a frequent snapshot of the network in order to understand the current state of the network and to help in isolating and solving network problems. If the data are collected for a long-term analysis of network performance, the monitoring is for metrics and capacity, RMA, and/or delay engineering. Network configuration and troubleshooting are more specialized tasks that are modifications of event notification, metrics, and planning.

In monitoring, we want to develop a set of characteristics that we will use for event monitoring and metrics and planning. These characteristics may be specific to each type of network device, which will be better understood later in the architecture and design processes. We will also consider the facilities for accessing these characteristics, which will include network management protocols, end-to-end monitoring tools, and direct access methods.

Some architectural issues with network management include determining the paths that the management data will take, as well as the hierarchy in management data flows. Management data can be in the path of the users' network traffic (in-band) or may take a different path (out-of-band). For the pros and cons of in-band versus out-of-band management, see Chapter 7. Management data flows can be hierarchical, indicating separate components of and locations for the management system, or flat, indicating that the management system is in a single device.

As with the other components of this chapter, the performance characteristics of network management also need to be considered. At this point, we can start to list some potential network management requirements:

• Monitoring methods

• Instrumentation methods (these include the network management protocols [SNMPv3, CMIP, RMON], parameter lists [MIBs], monitoring tools, and access methods)

• Sets of characteristics for monitoring

• In-band versus out-of-band monitoring

• Centralized versus distributed monitoring

• Performance requirements

In preparation for developing security requirements for our network, we first need to determine security requirements. We will perform a risk analysis for our existing network and planned network to gather information about current security and requirements for new security features. The risk analysis is often structured as a list of questions about the existing network, problems experienced, and network security strengths and weaknesses. It also often contains a risk assessment matrix, which contains potential security problems, system components that need to be protected, and perceived likelihood and severity of attacks.

Figure 2.13 shows an example of a security risk assessment for a specific organization. In this example, a risk analysis was performed as part of the requirements analysis, and the risk matrix shown was completed with the appropriate values.

Effect/ Probability	User Devices	Servers	Network	Software	Services	Data
Unauthorized Access	B/A	B/B	C/B	A/B	B/C	A/B
Unauthorized Disclosure	B/C	B/B	C/C	A/B	B/C	A/B
Denial of Service	B/B	B/B	B/B	B/B	B/B	D/D
Theft	A/D	B/D	B/D	A/B	C/C	A/B
Corruption	A/C	B/C	C/C	A/B	D/D	A/B
Viruses	B/B	B/B	B/B	B/B	B/C	D/D
Physical Damage	A/D	B/C	C/C	D/D	D/D	D/D
Effect:			Probability:
A: Destructive		C: Disruptive		A: Certain	C: Likely
B: Disabling		D: No Impact		B: Unlikely	D: Impossible

Figure 2.13: Security risk assessment.

Security requirements and the results of the risk analysis will be used to develop a security plan and define security policies for the network.