For each component architecture, understanding why that function is needed for that particular network is important; this is especially important for the performance architecture. The process of developing goals for this (or any other) component architecture begins during the requirements analysis process and is further refined during the architecture process. Therefore, the requirements and flow specifications and maps provide important input to this process.
Although performance is always desirable, we need to ensure that the performance mechanisms incorporated into the architecture are necessary and sufficient to achieve the performance goals for that network. Therefore, toward developing this architecture, we should answer the following questions:
Are performance mechanisms necessary for this network?
What are we trying to solve, add, or differentiate by adding performance mechanisms to this network?
Are performance mechanisms sufficient for this network?
In determining whether performance mechanisms are necessary for a network, we should already have the information needed to make a decision from the requirements and flow analyses. Part of the purpose of determining the necessity of performance mechanisms is to avoid implementing such mechanisms just because they are interesting or new. For example, it may be tempting to implement quality-of-service (QoS) mechanisms in a network, even when there are no clear goals or problems to solve.
When performance mechanisms are indicated, start simple and work toward a more complex architecture when warranted. Simplicity may be achieved in this architecture by implementing performance mechanisms only in selected areas of the network (e.g., at the access or distribution [server] networks), by using only one or a few mechanisms, or by selecting only those mechanisms that are easy to implement, operate, and maintain.
There should be information in the requirements and flow analyses that can help you determine the need for performance mechanisms in a network. Some requirements include:
Clearly different sets of network performance requirements, per user, group, application, device, and/or flow
Requirements to bill and account for network service
When you plan to implement performance mechanisms in a network, you should also determine whether your customer is willing to pay the costs for such mechanisms. For example, does your customer have a network staff that is capable of configuring, operating, and maintaining QoS, SLAs, and policies? If not, is the customer willing to pay the cost to acquire such staff or outsource performance (and some portion of network management)? Performance is not a capability that is implemented once and then forgotten; it requires continual support. If your customer is not willing to provide that support, it is better not to implement such mechanisms.
Experience has shown that when performance mechanisms are implemented and not supported, maintained, or kept current, performance in the network can actually degrade to a point at which it would be better not to have any performance mechanisms. Therefore, determining the requirements for performance and the willingness of your customer to support performance is critical to developing this architecture.
Having established a need for performance in the network, you should also determine what problems your customer is trying to solve. This may be clearly stated in the problem definition or developed as part of the requirements analysis, or you may need to probe further to answer this question. Some common problems that are addressed by the performance architecture include:
Improving the overall performance of a network
Improving the performance to select users, applications, and/or devices
Changing the network from a cost center to profitability
Merging multiple traffic types over a common network infrastructure
Differentiating (and possibly charging) customers for multiple levels of service
Improving the overall performance of a network is consistent with the network having single-tier performance (determined during the requirements analysis). When all users, applications, and/or devices in a network require a similar level of performance, your goal may be to improve performance for everyone.
When sets of users, applications, and/or devices require greater performance than others on the same network, performance mechanisms are required to deliver multiple performance levels. Such networks have multitier performance.
When you are attempting to charge customers for service and possibly to generate revenue for network service, performance mechanisms are needed to provide the contractual framework between subscribers and provider, as well as to deliver multiple performance (and charging) levels.
Performance mechanisms are also needed when a customer wants to merge multiple traffic flow types. This is common when multiple networks are being consolidated. For example, when building a new data network, your customer may want to (eventually) migrate voice and video services onto that network, eliminating the existing separate voice and video networks. Performance mechanisms are needed to be able to identify these multiple traffic flow types and provision the required network resources to support each flow.
Finally, having established the need for performance in the network, and determining what problems will be solved by implementing performance mechanisms, you should then determine whether these performance mechanisms are sufficient for that network. Will they completely solve the customer's problems, or are they only a partial solution? If they are a partial solution, are there other mechanisms that are available or will be available within your project timeframe? You may plan to implement basic performance mechanisms early in the project and upgrade or add to those mechanisms at various stages in the project.