10.6 Guidelines and Constraints on Technology Evaluations

We will be using the information from our flow and requirements specifications to evaluate technologies based on the combined capacity requirements for best-effort services or on the RMA, capacity, and/or delay requirements for predictable or guaranteed services.

In the capacity and service plans of the flow specification, we combined the capacity requirements of all best-effort and predictable services for each flow, and we chose the highest performance RMA and delay characteristics for predictable flows. For guaranteed flows, the individual capacity, RMA, and delay requirements of each flow are used. These RMA and delay characteristics are compared to the ability of candidate technologies to support such services, and the combined capacity requirements are compared with the capacity of each candidate technology. Following are two guidelines for evaluating technologies based on capacity and service plans:

Guideline 1: If predictable and/or guaranteed requirements are listed in the flow specification (service plan), then either the technology or a combination of technology and supporting protocols or mechanisms must support these requirements. This guideline restricts the selection of candidate technologies to those that can support predictable and/or guaranteed requirements.

We can divide this guideline into two portions: support for predictable requirements and support for guaranteed requirements. First, we will examine support for predictable requirements. Recall that predictable requirements provide predictable or bounded performance. The objective of having a predictable service is to reduce the variabilities in RMA, capacity, and delay in network devices so that you can offer a more predictable service to users, applications, and devices. Although determinism in a service results in a better understood and more predictable service, it does not mean that the service is guaranteed to provide a particular level of performance.

What will distinguishing between best-effort and predictable services mean to an operational network that incorporates these design guidelines? Why not just treat all services, including predictable services, as best effort? This is basically saying that all traffic flows are to be treated in a similar fashion—that is, they are all the same, which they most definitely are not. From traffic flows that have no timing requirements (e.g., email), to real-time and mission-critical flows (e.g., telemetry, image processing, and online transaction processing), to interactive-burst flows (e.g., Web applications), each flow type has individual performance requirements that should be supported by the network. Therefore, we must recognize that there are indeed a variety of flows and requirements and service types to support them.

There are a couple of reasons to distinguish between services types. First, by separating those flows that have strict RMA, capacity, and/or delay requirements, we are taking the first steps toward offering multiple, various services to users, applications, and devices. As mechanisms for offering services evolve, becoming better understood and widely available, we will be prepared to take advantage of these services in the network design.

Second, flows that require predictable services need to be handled differently by the network. Given the nature of predictable requirements in flows, they are not as tolerant as best-effort flows to variances in network performance. Thus, we need to ensure that predictable flows receive more predictable performance from the network. This is the basis for our selection of candidate technologies for predictable flows.

For flows that have predictable requirements, we want to choose candidate technologies that can support these requirements. Predictable service is a bounded service, so we want technologies that can provide mechanisms that bound or control performance. Mechanisms to consider come from the performance architecture, for example:

Quality-of-service levels in ATM
Committed information rate levels in frame relay
Differentiated service or integrated service levels in IP
Nonstandard or proprietary methods

Such options provide more predictability than traditional best-effort services and can play a part in offering guaranteed services.

Support for guaranteed service is much more stringent than that for predictable services and includes feedback to ensure that the services are being delivered or to provide accountability when service is not being delivered. To offer a guaranteed service, a candidate technology must be capable of:

Determining the state of network resources and available levels of performance for the end-to-end path of the traffic flow
Allocating and controlling network resources along the end-to-end path of the traffic flow
Providing mechanisms to arbitrate and prioritize who gets or keeps service when it is contended for
Providing mechanisms to account and possibly bill for service

Note that a guaranteed service is meaningful only when it is applied end-to-end, between well-defined service points. This means that all network devices in the end-to-end path of the flow must provide support for the guaranteed service. As a result, a guaranteed service is the most difficult to provision and operate and will be the most expensive to offer within a network. It is therefore imperative that a guaranteed flow be justified through the requirements and flow analyses before it is considered in the network architecture and design.

For a service to be guaranteed to a flow, the state of each network device in the path of the flow, possibly including each of the end (user) devices, must be determined. There must be some mechanism to keep and provide state information for each of these elements, as well as a mechanism to get this information to make service decisions.

If a guaranteed service is to be offered to a flow, the appropriate network resources will then be configured in each of the network devices in the path of the flow, possibly including each of the end (user) devices. Resources that are configured in the network and user devices include:

Buffer allocations, including the establishment of multiple queues and prioritizing traffic flows across them
Input and/or output capacity, often linked to buffer allocations
CPU usage

In addition, the service needs to determine how to handle periods when there are more service requests than available resources (periods of contention). One method is to offer services on a first-come, first-served basis. Using this method, when the resources are fully utilized, no more service guarantees are given until resources become available. This method is not likely to be used on a large scale, as it promotes holding on to a service as long as possible, even if it is not needed. Another method is to use priorities to determine which flows get service during periods of contention. In this method, a flow may get "downgraded" from guaranteed service to predictable or best-effort service if a higher-priority flow needs the service.

At this time, for guaranteed service, we would consider ATM with its service levels, particularly constant bit rate and real-time variable bit rate for guaranteed capacity. We would also consider integrated services and Resource Reservation Protocol to support guaranteed service at IP. It is expected that vendor support (hardware and software) for guaranteed services will evolve to become more widely available and will be supported in more standard and proprietary technologies.

Guideline 2: When best-effort, predictable, and/or guaranteed capacities are listed in the flow specification, the selection of technology may also be based on capacity planning for each flow. Capacity planning uses the combined capacities from the flow specification to select candidate technologies, comparing the scalability of each technology to capacity and growth expectations for the network.

In the flow specification, we developed capacity estimates for each individual and composite flow. Each of these estimates was based on expected application and user behavior patterns.

When comparing capacity estimates from the flow specification to capacities expected from candidate technologies, we want to determine a capacity boundary that will indicate that a technology's capacity is insufficient for a flow. In capacity planning, we want to design toward that capacity boundary and make sure that the technology has capacity to spare. If the flow contains only best-effort capacities, then a guideline is for the combined (summary) capacity of that flow to be approximately 60% of the capacity boundary for that flow. If the flow contains predictable capacities, then the guideline is for the predictable capacity of that flow to be approximately 80%, or the combined best-effort capacity to be 60%, of the capacity boundary of the flow, whichever is greater.

These guidelines are based on experience and should be used as a first attempt to evaluate technologies based on capacity. As you use them, you should be able to modify them to better approximate your network design. For example, if you can estimate the degree of burstiness in the data flow from an application, you can use it to modify the boundary capacity. Some bursty networks are designed to the boundary capacity divided by burstiness. Thus, if the burstiness (peak data rate/average data rate) of a predictable application is 5, then the design is based on 80% 5, or 16% of the boundary capacity. Doing this enables the network to accommodate a much higher capacity during times of burstiness from applications. To be able to use these guidelines, you need to know the characteristics of each flow in the flow specification.

Table 10.1 contains some estimates for maximum throughput for various technologies. These estimates are from experience, and you should note that these numbers will vary depending on how the network is constructed, the level of maturity of the technology, and the configuration of end (user) devices.

Table 10.1: Throughput Estimates for Selected Technologies
Technology	Maximum Capacity	Maximum Throughput
Ethernet	10 Mb/s	3–9 Mb/s
	100 Mb/s	80–95 Mb/s
	1 Gb/s	700–980 Mb/s
Token Ring	4 Mb/s	4 Mb/s
	16 Mb/s	16 Mb/s
	100 Mb/s	80–100 Mb/s
ATM
T3	45 Mb/s	34 Mb/s
OC-3c	155 Mb/s	120–135 Mb/s
OC-48	2.5 Gb/s	2.1–2.35 Gb/s
HiPPI	800 Mb/s	350–750 Mb/s
	1.6 Gb/s	0.5–1.4 Gb/s
	6.4 Gb/s	1.8–6 Gb/s
Frame relay	45 Mb/s	45 Mb/s
ADSL	Up to 1.5 Mb/s, depending on service level	Up to 1.5 Mb/s, depending on service level

When growth expectations are available, we can use them with the flow specification to estimate scalability for the network design. We may base growth estimates on the numbers of users, applications, and devices in the network.

Technology guidelines are driven in part by what is available from service providers that may be used for the network. For example, if a local service provider can offer only frame relay, you may be constrained to that technology for your network. You may have multiple service providers for your network, with different available technologies (e.g., frame relay, 802.11, cable modem, xDSL). When service providers are coupled to available technologies, you may need to include service providers in your evaluation of these technologies.

Part of the guidelines for technology evaluation should be a requirement to adhere to open technology standards. Open standards are important—they allow the network design to be flexible in adopting the same technology from multiple vendors, helping your customer to be vendor independent. Experience shows that dependence on vendors is usually a problem for customers, locking them into vendor-specific technologies and devices that may not be optimal for the customer.

10.6.1 Constraints on Candidate Technologies

There are three potentially major constraints on the selection of candidate technologies: the costs of each candidate technology, preexisting networks, and implications on facilities.

After developing a list of candidates, we can prioritize the list, much the same way we prioritized the flows in the flow specification. If we already have a cost-prioritized list of flows, we can apply that cost information to the area that the flow is in, as well as to the candidates for that area. For example, let us consider the list in Table 10.2 of cost-prioritized flows (where costs are nonrecurring network hardware and installation for technologies and may include first-year costs for services).

Table 10.2: Prioritized Flows and Candidate Technologies
Composite Flow	Cost (Budget)	Candidate Technologies
BB1 (LAN)	$800K	Gigabit Ethernet HiPPI
F2 (WAN)	$250K	ATM T3 Frame relay T3
F3 (LAN)	$200K	Fast Ethernet 100 Mb/s Token Ring ATM OC-3c
F4 (LAN)	$125K	Fast Ethernet 100 Mb/s Token Ring

For each area (in this case, each LAN/WAN and flow ID [F1, F2, etc.]), we would compare the equipment and installation costs for each technology to the budget allocated for that area. This would either eliminate some candidates or result in a cost-prioritized list of candidates.

When there are existing networks, we will need to consider their characteristics, both the constraints they impose on the design and the features they offer to it. From the flow considerations, the individual and composite flows can be affected when they connect to an existing network. If we have a requirement in the flow specification for a capacity of 150 Mb/s but the flow path traverses an existing Fast Ethernet network, either the requirements and/or flow analyses were not done properly, the existing network technology needs to be upgraded, or the flow cannot be supported by the design. During this evaluation and selection process, analyzing flows that connect to existing networks should identify when an existing network needs to be upgraded or replaced.

Existing networks may support the new design. For example, it may be possible to use existing LAN cabling for faster LAN technologies. Likewise, some WAN technologies, such as ATM, frame relay, or SMDS, may already provide connectivity with existing hardware and may require only a reconfiguration or software upgrade to support a higher-capacity individual or composite flow.

Technology choices have implications on facilities, including requirements to have more available space and sufficient HVAC support. Increases in available space may include space for individual users and their devices, as well as space for devices that are shared, such as servers and specialized equipment.

The purpose of evaluating technologies based on the criteria presented in this section is to help us select a list of candidate technologies to apply to the design. Although a process has been presented here, you will likely want to modify it by adding or eliminating sections. You may also find that one or more of the sections (broadcast and NBMA methods, technology functions and features, performance upgrade paths, or flow considerations) are not appropriate for your network design.