on demand, SO the routing tables do not store path identifiers-just the address of each site. Users can connect to any site, as long as the address is programmed into the router and SVC capacity is available. Subscribers control call setup via their own routers or FRADs. The router programming, then, controls allocation of the aggregate bandwidth. SVCs share bandwidth, and they do SO either on a first-come, first-served basis or on a custom Packet-Switched Networks basis, where chosen SVCs are disconnected when a higher-priority application needs bandwidth. Frame Relay Performance Issues You need to consider a number of performance issues with Frame Relay: Likelihood of bottlenecks-This depends on whether the operator has oversubscribed the backbone. Ability to handle bursts-The operator may let you burst above your CIR for sufficient periods, or the bursts may be SO limited that you really don't get bandwidth-on-demand. Level of network delay-Operators commit to different maximum delays on different routes, SO if you are going to be handling delay-sensitive traffic, you especially need to address this issue. Network availability guarantees-You need to determine to what level you can get a service-level agreement (SLA) that guarantees network availabil- ity. This depends on the vendor, not on technology. As far as Frame Relay QoS goes, you can expect to be able to have classes of service (CoSs), where you specify your CIR and your maximum burst rate, as well as some minor traffic parameters, such as the discard eligibility bits and the congestion notification bits. Otherwise, Frame Relay has no provisions for controlling laten- cies and losses. VoFR is of interest among both carriers and users. The main driver behind VoFR is more efficient use of Frame Relay bandwidth. The average full-duplex voice con- versation consists of about half silence, so voice has a bursty quality. Data networks have been sharing bandwidth for many years. Voice is just another protocol, SO why not let it also share bandwidth and in this