8.6 Architectural Considerations

8.6 Architectural Considerations

In developing our performance architecture, we need to evaluate potential performance mechanisms and determine where they may apply within the network, as well as the sets of internal and external relationships for this component architecture.

8.6.1 Evaluation of Performance Mechanisms

At this point, we should have requirements, goals, type of environment, and architectural model(s) and are ready to evaluate potential performance mechanisms. When evaluating performance mechanisms, start simple (e.g., DiffServ QoS) and work toward more complex solutions only when necessary.

Where a performance mechanism will apply in a given network will depend primarily on where performance requirements are located throughout the network, based on the results of the requirements and flow analyses. In addition to the requirements and flow analyses, we can use any architectural goals that have been developed, as well as the architectural models presented in Chapter 5.

Recall that the access/distribution/core architectural model separates a network based on function, where the core network supports the bulk transport of traffic flows, distribution networks support flows to and from servers and aggregate traffic flows from access networks, and access networks are where most traffic flows are sourced and sinked. This functional separation of a network can be applied when evaluating performance mechanisms.

For example, performance mechanisms that operate on individual traffic flows, such as admission control and signaling for resources, IntServ, and ATM QoS, should be considered where traffic flows are more likely to be individual (e.g., before they are aggregated), such as at access networks. Performance mechanisms that operate on aggregates of traffic flows, such as DiffServ, CBQ, WFQ RED/WRED, and MPLS, should be considered where traffic flows are more likely to be aggregated, such as at distribution and/or core networks or at interfaces to external networks.

An example of where performance mechanisms may generally be applied is presented in Figure 8.12. Note that these are to be used as general guidelines. Depending on the network, any performance mechanism may be applied at any area of a network.

Figure 8.12: General applications of performance mechanisms.

Along with determining the regions of the network where each performance mechanism will apply, we also need to consider which devices will implement each mechanism. Examples include DiffServ edge devices, where traffic flows are classified and marked with DSCPs, and policy decision points (PDPs), which are servers where policies are configured and maintained. Policies are implemented at policy enforcement points (PEPs), which include network devices that are configured for performance (e.g., through QoS).

8.6.2 Internal Relationships

Interactions within the performance architecture include trade-offs between end-to-end and per-hop prioritization, scheduling, and conditioning of traffic flows, admission control, and whether flows are treated individually or aggregated into groups. These interactions are closely coupled to the use of DiffServ and IntServ within the network.

When policies, SLAs, and DiffServ are chosen, part of this component architecture describes the placement of databases for SLA and policy information, including PDPs, PEPs, and DiffServ edge devices.

8.6.3 External Relationships

External relationships are trade-offs, dependencies, and constraints between the performance architecture and each of the other component architectures (addressing/ routing, network management, security, and any other component architectures you may develop).

There are common external relationships between performance and each of the other component architectures, some of which are presented in the following subsections.

Interactions between Performance and Addressing/Routing

Performance can be closely coupled with routing through mechanisms such as MPLS, DiffServ and IntServ, and RSVP. However, when routing protocol simplicity is a high priority, performance may be decoupled from forwarding.

Interactions between Performance and Network Management

Performance depends on network management to configure, monitor, manage, verify, and bill for performance levels throughout the network. Network management helps to couple QoS, SLAs, and policies by providing common communications paths and protocols for performance information. In addition, network management can tie performance management to the customer's operations support system (OSS).

SLAs need to be coupled with network management for performance monitoring and trouble reporting/ticketing. This provides the feedback loop necessary between performance and network management, users, and management/staff.

Interactions between Performance and Security

As we will see in Chapter 9, security mechanisms are often intrusive, intercepting, inspecting, and controlling network access and traffic. Such actions require network resources and processing, increasing network delay. As security is increased by adding more mechanisms (and mechanisms that are more intrusive) to the network, performance is decreased. Whereas capacity can sometimes be increased to offset a decrease in performance caused by security, increased delay is difficult to mitigate.

When performance is high priority, particularly when there is a need to provision end-to-end performance between select users, applications, or devices, performance mechanisms may preclude the use of intrusive security mechanisms in those areas of the network.

When security mechanisms interrupt or terminate and regenerate traffic flows, they seriously affect the ability to provide end-to-end performance across the security interface. As a result, security constrains performance to operate within a security perimeter (Figure 8.13). These security perimeters, or security zones or cells, can be configured in different ways. This will be discussed further in Chapter 9.

Figure 8.13: Performance is constrained by security.