1.6 System Description

1.6 System Description

A system is a set of components that work together to support or provide connectivity, communications, and services to users of the system. Generically speaking, components of the system include users, applications, devices, and networks. Although users of the system can be considered outside of the system, they also have requirements that include them as part of the system. Throughout this book we will include users as part of the system. Figure 1.11 shows how these components are connected within the system.

Figure 1.11: Generic components of a system.

Figure 1.11 shows the generic components of a system. These components can be subdivided, if necessary, to focus on a particular part of the system. For example, users in a corporate network could be further described as network and computer support personnel, as well as developers and customers of that corporation's product. In a similar sense, applications may be specific to a particular user, customer or group, generic to a customer base, or generic across the entire network.

If we were to compare this view of a system with the open system interconnect (OSI) protocol model, it would look like Figure 1.12. Note that in this comparison, some of the OSI layers are modified. This is to show that there may be multiple protocol layers operating at one of the system levels. For example, the OSI physical, data link, and network layers may be present at the device level and may also be present multiple times at the network level (e.g., at switches and routers throughout the network).

Figure 1.12: Comparison of OSI layers to system levels.

Figure 1.13 shows that devices can be subdivided by class to show specialized functions, such as storage, compute, or application servers, or an individual device may be subdivided to show its operating system (OS), device drivers, peripheral hardware, or application programming interface (API).

Figure 1.13: Device component separated into constituents.

All of these components work together to provide connectivity and communications across the network, between users, applications, and devices. The connectivity and communications can be tailored to meet the specific needs of users and applications, such as real-time delivery of voice or streaming media, best-effort delivery of noninteractive data, or reliable delivery of mission-critical data.

The degree of granularity used to describe system components is a trade-off between the amount of detail and accuracy you want in the description and how much time and effort you are willing to put into it. If you are the network architect responsible for a corporate network, you may have the ability to invest time and resources into developing a detailed description of your system's components, whereas a consultant or vendor's design engineer may have little time and resources to spend on such a description. It is important to note, however, that even a small amount of time invested here will pay dividends later in the analysis process.

The traditional view of a system focused on the network providing connectivity between devices (Figure 1.14) and typically did not consider the users or applications.

Figure 1.14: Traditional view of system.

This traditional view of a system is not complete enough for today's networks. In particular, we need to include users and their applications in the system description. Experience shows that the degree of descriptiveness in the set (users, applications, devices, and networks) is usually sufficient to provide a complete and accurate description of most general-access systems, yet not so large as to be overwhelming to the network architect. (General-access is a term to describe common access of users to applications, computing, and storage resources across a network.) Within this set, users represent the end users, or customers, of the system. These end users are the final recipients of the network services supported by the system.

One reason for identifying components of the system is to understand how these components interface with each other across component boundaries. By defining what the components of the system are, we are also setting what is to be expected across each interface. For example, using the standard set (users, applications, devices, and networks), Figure 1.15 shows potential interfaces.

Figure 1.15: Generic system with interfaces added.

Although the description of the system given in Figure 1.15 is usually satisfactory for the start of most network architectures, there will be times when you will want to describe more components or have more defined interfaces. For example, the devicenetwork interface may be simple or complex, depending on what you are trying to accomplish. For a network that will be providing simple connectivity, the network-device interface may be a standard LAN interface (e.g., 100BaseT Ethernet) without any prioritization or virtual LAN (VLAN 802.1p/q) tagging. For a network that provides more than simple connectivity, such as quality of service, the device-network interface may be more closely coupled with the device or application. This may be accomplished by using drivers that bypass portions of the protocol stack and APIs that can interpret application performance requirements.

To illustrate, consider the difference in network-device interfaces between a network using ATM, a link-layer technology, in the backbone versus a network where devices directly connect to ATM, sometimes referred to as a native ATM network. Figure 1.16 shows a system description where ATM is used in the backbone and Ethernet is used to connect to the devices. In this description, ATM does not directly interface with the devices, applications, or users and is isolated from them by IP routers. This is one of the scenarios described in the classical model of IP over ATM, described in RFC 2225 (RFC is a request for comment, a standards document of the Internet Engineering Task Force [IETF]) and used in more detail in the design section of this book. In this system description, ATM is embedded within the network component of the set (users, applications, devices, and networks). Why is this important? By isolating ATM within the network component of the system, any capabilities specific to ATM that may be directly useful to devices, applications, or users of the system are lost.

Figure 1.16: Example of system with ATM in network.

Figure 1.17, on the other hand, shows a native ATM network in which ATM is integrated into devices and will interface directly with applications. In describing the system this way, we are explicitly including capabilities, such as quality of service, across the network-device interface. In this example the system may be better described as the set (users, applications, API, device driver, and network).

Figure 1.17: Example of system with native ATM.

You should consider more detailed system descriptions when there is a need to identify system components that are likely to affect the delivery of services to users. In Figure 1.17, the ATM-specific API translates application requirements to the ATM network. As part of the system description, this ATM-specific API is clearly recognized as being important to the delivery of services.

Although the system description is an attempt to identify components across the entire system, we need to recognize that most systems are not completely homogeneous and that components may change in various parts of the system. This usually occurs in parts of the system that perform specific functions, such as a device-specific network (e.g., a video distribution network) or a storage-area network (SAN). For example, although an SAN may be described as the set (users, applications, devices, and networks), users may be other devices in the system, and the only application may be for system storage and archival.