Weight Watchers With per-megabyte pricing, the efficient coding of voice traffic is imperative. As noted, a 16-Kbps codec will generate calls that cost about a penny per minute--an excellent value compared to typical switched, long-distance rates. Yet a 64-Kbps codec used in a voice-over-IP application can drive costs up to 10 cents a minute, obliterating any relative cost savings.

Carrier technical policies also can affect the design of the network. In the Qwest network, for example, virtual circuits are typically limited by a 2:1 oversubscription policy; that is, the sum of all virtual circuits can't exceed twice the port rate. Therefore, if your port speed is 64 Kbps with one 32-Kbps PVC, all active SVCs must be less than or equal to 96 Kbps (in other words, 128 Kbps minus the 32 kilobits that the PVC uses). This consideration keeps you from configuring every SVC at full port speed.

SVC standards make interoperability possible, but they aren't exhaustively specified. The Frame Relay Forum User-to-Network SVC Implementation Agreement (FRF.4) has been in place for more than five years, but there are notable items still missing in it. For example, devices can't request a specific end-to-end latency or service priority. Unlike with PVCs, there are no standard link management protocols that apply to SVCs--neither T1.617 Annex D nor Q.933 Annex A report on the status of SVCs. Although SVC STATUS ENQUIRY and SVC STATUS messages are defined, they aren't issued regularly to the network as is the practice with common frame relay link management procedures.

With standards this old, it's not difficult to find equipment that supports SVCs. However, the quality of implementations still varies, mostly because of the lack of real field experience with the equipment--and the noted holes in the standards. For example, until recently some equipment would not release a call unless it received a DISCONNECT message from the network--even if the remote side had been shut down. Thus, an SVC would be blocked due to a remote-side physical line failure, until the local equipment was initialized. This problem was later addressed by monitoring traffic received on the SVC and timing out with inactivity.

SETUP and Framed The major difference with SVCs is the dynamic assignment of parameters typically statically defined with PVCs. Signaling is based on a simplified version of the Q.931 protocol, as specified in the FRF.4 Implementation Agreement (see "Frame Relay SVC Signaling in a Voice Over Frame Relay Environment," at left). When a call is initiated, the requesting device sends a SETUP message to the network. If the message is understood and can be fulfilled, a CALL PROCEEDING message is sent to the originator, detailing the parameters that the network can deliver--as well as the DLCI (Data Link Connection Identifier) to be used for the call.

On the remote end, the carrier switch sends the SETUP message to the party being called, who may respond with its own CALL PROCEEDING message (our Motorola 6560 did not generate these optional messages). If the receiver accepts the call, it sends a CONNECT message to the network, which delivers it to the remote side if its requirements can be met by the network.

The originator's initial SETUP message specifies the minimum acceptable bandwidth needed for the call, including committed burst and excess burst size. You'll need a detailed understanding of how your carrier calculates these values before you can configure your equipment, or calls may not set up properly. For example: Recall that committed burst size is the maximum number of bits the network agrees to transfer, measured over an interval T. Most would expect a CIR setting of 32 Kbps to translate to a committed burst size of 32 kilobits, but they could well be wrong if the carrier doesn't define T as one second. In the MCI WorldCom case, T is assigned the value 1.5 if the port speed runs at sub-T1 speeds. Therefore, a 32-Kbps CIR uses a committed burst value of 48,000 bps (32 Kbps = 48 Kbps/1.5), and connections won't get established if you configure the SVC for 32,000 bps.

Customer equipment maps network-specific addresses (phone numbers or IP addresses, for example) into these E.164 addresses, and when necessary using subaddresses passed in the Q.931 call setup to route a call (for example, to a specific voice station port on a remote frame relay access device). This call detail then gets logged by the network equipment, either locally or to a network-based logging device.

The Most Complex Task Finally, analyzing usage data is the most complex aspect of implementing SVCs. While Qwest and MCI WorldCom bill SVCs on total traffic in megabytes, other carriers are considering time-based billing--a more natural match for both voice and video applications. This billing alternative not only affects how equipment should be configured (for example, time-based billing places more importance on shutting down calls quickly than in selecting the most-efficient codec), but it also affects how it needs to be reported.

To verify call detail from the carrier equipment, logs must be collected and summarized. Matching detail against carrier-supplied data--as is commonly done in switched call accounting--is difficult, and in the short term may well be impossible. Note that neither MCI WorldCom nor Qwest is offering electronic call detail at this time. Moreover, building a reporting system for frame relay SVC data is a do-it-yourself process, since common reporting platforms and frame relay management systems do not automatically handle this information.

Send your comments on this article to David Willis at dwillis@nwc.com.