5.5 Reference Architecture

5.5 Reference Architecture

A reference architecture is a description of the complete network architecture and contains all of the component architectures (i.e., functions) being considered for that network. It is a compilation of the internal and external relationships developed during the network architecture process (Figure 5.8).

Figure 5.8: Process model for component architecture approach.

There can be more, less, or different component architectures than those described in this book, depending on how you choose to focus on for your network. For example, the component architecture labeled "Others" in Figure 5.8 could be an infrastructure architecture or a storage architecture. This flexibility allows you to choose those component architectures that best fit the requirements of that network.

In Figure 5.8, each component architecture defines the internal relationships for a particular function, whereas the reference architecture combines these components. As we will see, component architectures can be weighted to determine their relative priority levels.

Once the component architectures are developed for a network, their relationships with each other are then determined. These external relationships are defined by the interactions between pairs of component architectures, their trade-offs, dependencies, and constraints. Typically, all of the component architectures for a network are closely coupled to each other. This will be reflected in their external relationships.

Just as internal relationships are used to optimize each component architecture for the network, external relationships are used to optimize the sum of all component architectures. Thus, the reference architecture, developed by combining component architectures, incorporates the effects that functions have on each other.

Depending on the requirements, traffic flows, and goals for a particular network, the reference architecture is either balanced across all functions or weighted to favor one or more functions. In a network architecture that is balanced across all functions, constraints and dependencies between functions are minimized and trade-offs between functions are balanced so that no individual function is prioritized over the others.

When one or more functions are weighted in favor over others, the external relationships reflect this weighting. For example, in a network in which performance is the primary architectural goal, the external relationships between performance and the other functions would be weighted so that interactions (trade-offs in particular) favor performance.

This is a powerful capability that is missing in traditional approaches, not only because it provides the ability to decide which functions are prioritized higher than others, but also because this becomes an informed decision in which the effects on other functions and on the reference architecture are understood and documented as part of the network architecture.

Consider a network in which the set of requirements, flows, and goals indicate that low delay and jitter performance are high priority. Yet, in this same network, routing, network management, and security all affect delay and jitter performance. In traditional network architecture, the interactions between performance and the other functions are often not well understood, resulting in a network in which security, network management, and routing mechanisms increase delay and jitter, and the network does not meet its requirements or goals.

However, if each function is developed as its own composite architecture, delay and jitter can be optimized in the performance component architecture, and then this component architecture can be prioritized over the others so that when interactions are identified between performance and the other functions, performance is chosen.

5.5.1 External Relationships

To some degree, each function depends on and supports the other functions within a network, as well as the requirements from users, applications, and devices. This is reflected in the external relationships between their component architectures.

The addressing/routing component architecture supports traffic flows from each of the other functions. Based on the mechanisms used in the network management and security component architectures, their traffic flows may take separate paths from user traffic flows, a capability that must be incorporated into the addressing/routing component architecture.

In addition, routing can be configured so that traffic flows with differing performance requirements take separate paths through the network, coupling addressing/ routing with performance. This is evident in routing protocols that integrate performance mechanisms, such as multiprotocol label switching (MPLS).

Each component architecture depends on network management to support the access and transport of management data for that component. In practice, the monitoring and management of addressing/routing, performance, and security are often achieved through an integrated approach within the network management component architecture.

In this approach, network management supports flows of management data for each function equally. In some cases, however, multiple priority levels are assigned to the access and transport of management data for the various functions.

The performance component architecture provides network resources to support the other functions, as well as user, application, and device traffic flows. By understanding performance requirements at various levels of granularity (e.g., networkwide, per function, per user/application/device, or per flow), this component architecture describes how performance mechanisms are used to allocate resources at the proper level of granularity.

For example, the performance component architecture for a service-provider network may focus on traffic engineering to achieve a system-wide balance for bandwidth allocation. In addition, this network may include SLAs, access control, and traffic prioritization, scheduling, and conditioning to provide bandwidth and delay performance to select groups of users or applications.

The security component architecture supports the security and privacy requirements of each of the other functions. For addressing/routing, performance, and network management, network devices are where traffic flows are aggregated and controlled, and they often require a high degree of security, in terms of additional access controls and protocol (e.g., Simple Network Management Protocol) security.

5.5.2 Optimizing the Reference Architecture

Requirements, flows, and goals for a network are used to optimize the reference architecture, much the same way that each component architecture is optimized. However, for the reference architecture, interactions occur between pairs of component architectures. Numerous trade-offs, dependencies, and constraints occur between addressing/routing, network management, performance, and security. Some examples of common interactions between pairs of component architectures are presented in the following sections.

Interactions between Performance and Security

By their nature, security mechanisms are often intrusive, inspecting and controlling network traffic and access. Such actions require network resources and processing, increasing network delay. As security is increased, by adding more mechanisms to the network, performance is decreased. Whereas capacity can sometimes be increased to offset a decrease in performance, delay is difficult to mitigate.

When performance is high priority, particularly when there is a need to measure end-to-end performance between select users, applications, or devices, performance mechanisms may preclude the use of security in particular areas of the network. Some security mechanisms interrupt or terminate and regenerate traffic flows, seriously affecting the ability to provide end-to-end performance across a security interface. As a result, security can constrain performance mechanisms to within a security perimeter.

Interactions between Network Management and Security

Network management requires frequent access to network devices and thus is a potential security problem. Management access can be provided out-of-band via a separate management network, with its own security mechanisms. When management access is in-band, however, any additional security mechanisms for network management may affect performance for user traffic flows. When manageability is a high priority, a separate security component architecture for network management may be indicated.

Interactions between Network Management and Performance

In-band network management directly affects the performance of user traffic flows, as management traffic flows compete with user traffic flows for network resources. This is often a problem in centralized network management architectures, as all management traffic flows are aggregated to a common management device. As management traffic flows are aggregated, their network resource requirements can become quite large, particularly during periods of network problems. Thus, a trade-off of centralized management is either overengineering bandwidth, providing prioritization mechanisms for performance, or reducing performance expectations.

Interactions between Addressing/Routing and Performance

Performance can be closely coupled with routing through mechanisms such as MPLS, differentiated and integrated services, and signaling via the Resource Reservation Protocol. However, when routing protocol simplicity is a high priority, performance may be decoupled from routing. The result of this approach is a network architecture that shows how each function is optimally applied to the network, how the functions interact with each other, and how they can be balanced or prioritized in the reference architecture.

When the architectural process is completed, you will have a set of component architectures that will overlay on top of your requirements and flow maps, as shown in Figure 5.9. This set of overlays describes how each function is supported in the network, where mechanisms are to be applied, and how they interact with each other.

Figure 5.9: Component architectures form overlays onto requirements and flow maps.