For example, Pacific Bell’s switched multimegabit data service (SMDS) has a stated availability, in terms of mean time between service outages or greater than or equal to 3500 hours, with a mean time to restore of less than or equal to 3.5 hours. On the other hand, the Bellcore specification for SMDS calls for an availability of 99.9%. From our earlier discussion we can see that both of these specifications describe similar availability characteristics, with the MTBCFMTTR specification being more specific. Some of the estimation techniques we used require knowledge of which technologies and services exist or are planned for the system. Since at this point in the process we really do not know which technologies and services we will be using for our network (as those are determined in the architecture and design processes), these techniques may be used on the technologies and services that are in the current network, or on a set of candidate technologies and services for our planned network. Later in the architecture and design processes, when we have chosen technologies and services for our network, we can apply the information gathered here for each of those technologies An example of a general threshold for RMA is for uptime. Users normally expect the system to be operational as close to 100% of the time as possible. Uptime can get close to 100%, within a tenth, hundredth, or sometimes a thousandth of a percent, but with tradeoffs of system complexity and cost. Earlier in this chapter Developing Delay Requirements 125 99 99.99 High Performance Testbed LowPerformance % Uptime FIGURE 3.13 Thresholds between Testbed, Low, and HighPerformance Uptime we described a general threshold for uptime, based on experience and observation, of 99.99%. In general, requirements for uptime that are greater than or equal to 99.99% are considered to be high performance, those that are less than 99.99% are low performance. In addition, a general threshold of approximately 99.5% can be used to distinguish a lowperformance requirement from that of prototypes and testbeds. These thresholds are shown in Figure 3.13. Note that any environmentspecific thresholds that are developed for your network would supersede these general thresholds. Error or loss rate is used as a measurement of uptime. For example, for an uptime requirement of 99.99%, packet or cell loss can be used to measure this performance. For many applications, experience has shown that a 2% packet loss is sufficient to lose application sessions. This can be considered downtime and in fact is a more practical measurement and verification of uptime than attempts at mathematical representations. If you are using a 2% loss threshold and measuring packet loss in the network, it is counted as downtime when the packet loss is greater than 2%. For 99.99% measured weekly, the network can have 2% or greater packet loss for 1 minute per week (see Section 3.5.3).