5.6 Architectural Models

5.6 Architectural Models

In developing the architecture for your network, you can use several architectural models as a starting point, as the foundation of your architecture, or to build on what you already have. Three types of architectural models are presented here: topological models, which are based on a geographical or topological arrangement and are often used as starting points in the development of the network architecture; flow-based models, which take particular advantage of traffic flows from the flow specification; and functional models, which focus on one or more functions or features planned for in the network. Your reference architecture will likely contain more than one architectural model.

5.6.1 Topological Models

There are two popular topological models: LAN/metropolitan-area network (MAN)/WAN and access/distribution/core models. The LAN/MAN/WAN architectural model is simple and intuitive, based on geographical and/or topological separation of networks. Figure 5.10 shows this model.

Figure 5.10: LAN/MAN/WAN architectural model.

The important feature of this model is that, by concentrating on LAN/MAN/WAN boundaries, a focus of this model is on the features and requirements of those boundaries and on compartmentalizing functions, services, performance, and features of the network along LAN/MAN/WAN boundaries. Both this model and the access/distribution/core model (Figure 5.11) also indicate the degree of hierarchy intended for the network. Both models can be collapsed to show fewer than three levels or expanded to show as many levels as necessary. For example, the LAN/MAN/WAN model is often used as a LAN/WAN model, or the LAN component is separated into campus, buildings, or even floors.

Figure 5.11: Access/distribution/core architectural model.

Interface control descriptions (ICDs) are useful in managing the development of this architectural model. ICDs define and describe LAN/MAN/WAN boundaries. This consists of the network devices, links, networks, and any other elements that are used to interconnect LANs, MANs, and WANs.

The access/distribution/core architectural model has some similarities and differences to the LAN/MAN/WAN model. It is similar to the LAN/MAN/WAN model in that it compartmentalizes some functions, services, performance, and features of the network, although not to the degree of the LAN/MAN/WAN model. The access/distribution/core model, however, focuses on function instead of location, as Figure 5.11 shows. An important characteristic of this model is that it can be used to reflect the behavior of the network at its access, distribution, and core areas.

The access area is closest to the users and their applications and is where most traffic flows are sourced and sinked. Thus, flows and requirements can be treated on an individual basis more easily than in the distribution and core areas.

The distribution area can also source and sink flows, but they are more likely to be to or from multiuser devices, such as servers or specialized devices. Few users are normally directly connected to the distribution area. As such, this area is often used to consolidate flows. As we will see, performance mechanisms that support both individual and combined flows can be used here.

The core of the network is used for bulk transport of traffic, and flows are not usually sourced or sinked at the core. Thus, any view of individual flows is lost at the core, unless it is specifically planned for (as with flows that have guaranteed requirements).

Both the LAN/MAN/WAN and access/distribution/core models are used as starting points in the network architecture, as they are intuitive and easy to apply. They can be restrictive, however, in that they place strict boundaries between areas. When applying these models, therefore, keep in mind that you may have to be creative in how you define each area so that it fits the requirements for that area.

5.6.2 Flow-Based Models

Flow-based architectural models are based on their counterparts, the flow models discussed in Chapter 4. If you used these models during the flow analysis process, it may be easy to then apply them here. Although each model has the features of its flow counterpart, it also has architectural features that were not discussed with the flow models. The flow-based models we present are as follows: peer-to-peer, client-server, hierarchical client-server, and distributed computing.

The peer-to-peer architectural model is based on the peer-to-peer flow model, in which the flow behaviors of the devices and applications are fairly consistent throughout the network. Important characteristics of this model are with the architectural features, flows, functions, and services. Since the users and applications in this model are consistent throughout the network, there are no obvious locations for architectural features. This pushed functions, features, and services toward the edge of the network, close to users and their devices, and makes flows end-to-end, between users and their devices. This resembles the core portion of the access/distribution/core model. Figure 5.12 shows this architectural model.

Figure 5.12: Peer-to-peer architectural model.

An example is with ad hoc networks, which lack a fixed infrastructure, forcing nodes to communicate in a peer-to-peer fashion.

The client-server architectural model also follows its flow model, but in this case there are obvious locations for architectural features, in particular where flows combine. Therefore, functions, features, and services are focused at server locations, the interfaces to client LANs, and client-server flows, as in Figure 5.13.

Figure 5.13: Client-server architectural model.

The characteristics of the client-sever model also apply to the hierarchical client-server architectural model. In addition to the functions, features, and services being focused at server locations and client-server flows, they are also focused at the server-server flows (Figure 5.14).

Figure 5.14: Hierarchical client-server architectural model.

In the distributed-computing architectural model (Figure 5.15), the data sources and sinks are obvious locations for architectural features.

Figure 5.15: Distributed-computing architectural model.

Flow-based models, like the topological models, are intuitive and easy to apply. Since they are associated with flows, they should map well to any flow maps you created as part of the requirements analysis process. These models are fairly general, and you may have to modify them to fit the specific requirements of your network.

5.6.3 Functional Models

Functional architectural models focus on supporting particular functions in the network. In this section we will present service-provider, intranet/extranet, single-tier/multitier performance, and end-to-end models.

The service-provider architectural model is based on service-provider functions, focusing on privacy and security, service delivery to customers (users), and billing. In this model, interactions between providers (the networks) and users are compartmentalized. Although this model represents a service-provider architecture, many enterprise networks are evolving to this model, applying it across organizations, departments, and buildings. Figure 5.16 illustrates this model.

Figure 5.16: Service-provider architectural model.

The intranet/extranet architectural model focuses on security and privacy, including the separation of users, devices, and applications based on secure access. Note that in this model, there can be several levels of hierarchy (security/privacy) (Figure 5.17).

Figure 5.17: Intranet/extranet architectural model.

The single-tier/multitier performance architectural model focuses on identifying networks or parts of a network as having a single tier of performance, multiple tiers of performance, or components of both. This model is based on results from the requirements and flow analyses, in which single-tier and multitier performance requirements are determined. Recall that for multitier performance, there are applications, devices, and users that can be the drivers for the network architecture and design, in terms of performance, whereas single-tier performance focuses on supporting (usually a majority of) applications, devices, and users that have a consistent set of performance requirements. These have two very different sets of requirements on the architecture.

Finally, the end-to-end architectural model focuses on all components in the end-to-end path of a traffic flow. This model is most closely aligned to the flow-based perspective of networking (Figure 5.18).

Figure 5.18: End-to-end architectural model.

Functional models are the most difficult to apply to a network because you must understand where each function will be located. For example, to apply the end-to-end model, you first have to define where end-to-end is for each set of users, applications, and devices that will be a part of end-to-end. An advantage to using functional models is that they are likely to be the most closely related to the requirements you developed during the requirements analysis process.

5.6.4 Using the Architectural Models

Typically, a few of the models from the previous three sections are combined to provide a comprehensive architectural view of the network. This is usually achieved by starting with one of the topological models and then adding flow-based and functional models as required. This is shown in Figure 5.19.

Figure 5.19: Functional and flow-based models complement the topological models.

The result of combining models and developing the relationships between architectural components is the reference architecture (Figure 5.20).

Figure 5.20: The reference architecture combines component architectures and models.

In developing a reference architecture for a network, we will use as input information from the requirements specification, the requirements map, and the flow specification, along with the architectural models and component architectures. At this point in the process we have not developed any of the component architectures, so we will focus on the architectural models. As each component architecture is developed, it is integrated into the reference architecture.

As mentioned in the previous section, we would normally start with one of the topological models—LAN/MAN/WAN or access/distribution/core—and add to that with one or more of the functional and/or flow-based models. The topological models are a good starting point, as they can be used to describe the entire network in a general fashion. Although the functional and flow-based models can also be used to describe an entire network, they tend to be focused on a particular area of the network and as such are used to add to a more general description.

Nine models have been presented in this chapter (two topological, four flowbased, and three functional models) to provide you with as many options as possible to develop your reference architecture. In practice, one or two models are typically sufficient for many networks. You may choose to apply a model to describe the entire network, with additional models for specific areas (e.g., a clientserver model for access to a server farm or a distributed-computing model for computing centers).

Consider, for example, the access/distribution/core model. The areas of this model focus on different functions in the network, such as traffic flow sources and sinks in the access network, server and/or specialized device flows in the distribution network, and bulk transport of traffic (no sources or sinks) in the core network. We would combine this model with the requirements specification and requirements map to determine which areas of the network are likely to be access, distribution, and core networks. Determining the core network is often relatively easy, but determining the distribution and access network can be more challenging. In some cases there may not be a distribution network, only access and core networks.

From a flow perspective, the core network will not source or sink any flows, the distribution network will source and sink server and specialized device flows, and the access network will source and sink generic computing device flows, as shown in Figure 5.21.

Figure 5.21: Access/distribution/core model from a flow perspective.

Given this perspective, we can identify potential distribution networks as locations of servers and specialized devices. We can then apply flow-based models to distribution and access networks that have client-server and hierarchical client-server flows (identified in the flow specification). As shown in Figure 5.22, these models overlap with the distribution and access networks. Usually the client-server and hierarchical client-server models apply across the distribution and access areas but may at times also apply across the core. However, even when these models apply across the core, they may not affect the architecture of the core network.

Figure 5.22: Where client-server and hierarchical client-server models may overlap with the access/distribution/core model.

As a general rule of thumb, Figure 5.23 shows where the functional and flowbased models may overlap with the access/distribution/core model. This figure does not imply the concurrent use of these models within one network architecture but rather where each model may overlap with the core/distribution/access model.

Figure 5.23: Access/distribution/core model with functional and flow-based models added.

The results of the requirements and flow analyses are used as input to the network architecture, which then lead to the development of the network design. Network architecture and design are attempts to solve nonlinear problems, and figuring out where to begin can be difficult. You cannot start at the top without some understanding of the capabilities of the individual components, and you cannot easily pick components until you understand the top-down requirements. Optimally we try to converge on an understanding of all of the pieces and then start at the top and work our way down to the individual components.

Example 5.1: Applying Architectural Models

Consider the flow map from the storage example from Chapter 4, shown in Figure 5.24.

Figure 5.24: Flow map from storage example in Chapter 4.

From this flow map, we can determine where flows are sourced and sinked and where servers are located. This information can be used with the access/distribution/core architectural model, with the results shown in Figure 5.25.

Figure 5.25: Access, distribution, and core areas defined for Example 5.1.

For this flow map, the access areas are where user devices (including the digital video camera) are located, as these devices are the primary sources of data for storage. Distribution areas are where servers are located in each campus, as these are sinks (as well as sources) of data from multiple devices. The core area is shown between buildings, as this is where bulk data transport is needed, and there are no obvious data sources or sinks. Although as shown the core area is not located at any building on the campuses, any network devices that would connect to the core area would be located at the junction between core and distribution areas at each campus.

In this example, we could also apply a distributed-computing architectural model between servers and their clients. The distributed-computing model is chosen here over the client-server model (which seems more intuitive) because the flows are primarily in the direction from the user devices to the storage servers. When this model is applied, we get Figure 5.26.

Figure 5.26: Distributed-computing areas defined for Example 5.1.

There are three areas where the distributed-computing model can apply in this example, one area at each campus. Note that in each area the flows within the area are from user devices to servers. At the north campus, there are also server-to-server flows, so we could have modified either the distributed-computing or the hierarchical client-server model to apply there.