Copyright © 1997, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.

We're going to be launching an examination of the various ATM vendors' "infrastructure" perspectives in the next few issues. This is a review and measurement of the value of ATM (in general, and in specific vendor cases) in supporting generalized network-building in the WAN. In other words, we're going to look at what might make ATM an important technology at the core of the network.

One of the questions that will arise in this kind of evaluation is whether voice over IP would be a viable way of achieving an integrated network core. It isn't a viable topic for an ATM architecture comparison, but we thought it might be a useful one for management to review overall. This is a good moment to consider it, because Cisco and other vendors are now expanding their voice-over-IP capabilities.

If we want to carry voice on an IP network, we first have to establish just what role the IP network will play in the process, and that's a bit more complex than it seems. IP can "carry" voice, but how does it get it? In other words, what is its relationship to the voice telephone world?

There are three options for IP voice:

1. The IP network (the Internet, for example) can be used to connect two "voice agents" who agree on a voice coding and signaling procedure among themselves. Everything that arrives at one agent is transported over the IP network to the partner, and the only thing that has to be considered other than voice coding and quality is the issue of delivering call progress indications – ringing, busy, etc. If there is not a hard association between incoming and outgoing voice connections (if voice dial is supported), it will also be necessary to communicate the called number from the originator voice agent to the destination voice agent for dialing. In this case, there is no requirement for signaling integration between the IP network and the voice network, other than that each voice agent has to be able to signal his own partner voice devices.
2. The IP network can be used to connect a series of voice agents, greater than two in number. Each agent is assumed to have a community of voice users whose address (phone number, probably) in the voice domain is known. There is also assumed to be a directory (central or distributed) containing the universe of voice addresses that are part of the IP voice network, and the voice agent address associated with each. In this case, the voice agents must administer a consistent address space for their partners, but again no specific requirements for a signaling standard will exist except between voice device and associated agent.
3. The IP network can be used as a part of the public telephone network. In this case, the voice agent must have the ability to appear to the voice network as an intelligent part of that network – to be a switch or intelligent network component, and to signal in the standard SS7 language.

The common requirement for all of these options is the ability to transport voice in packet form. That task involves the coding of analog voice into digital chunks, and then the transport of those digital chunks as data packets.

Voice coding into digital form is a relatively easy process, and one that is already done for standard voice telephony. The ITU's G.711 standard provides for standard 64 kbps PCM encoding. Another standard, G.726, provides 32 kbps ADPCM, and still others (G.728, G.729, G.723) provide for compression based on linear predictive code (LPC). In theory, any of these would work, but LPC algorithms use less bandwidth.

The compression process is where we have to start talking about packet voice quality issues. As we build a packet, we'll have to assemble voice samples. The longer we take to do that, the longer the end-to-end voice delay will be. Generally, LPC algorithms require a greater compression handling and buffering delay, and generally the longer the packet the greater the time needed to assemble it.

Delay is an issue because it impacts conversation. When one-way delay is below about 50 milliseconds, the two parties are largely unaware of it. As delay rises to the 100 ms level, there is a slight "hitch" between the end of one party's talking and the receipt of positive feedback from the other. Most can notice it, but few are really bothered. As the delay approaches 200 ms, the call begins to work like a satellite path (the average delay there is about 240 ms). Fast-talking people will often "step on" each other's new sentences because they'll each hear a silent period and assume they can talk. Delay of 400 ms or so generates enough of these collisions that most users find it unacceptable unless some form of "radio discipline" (saying "over") is applied. Still, even delays in the seconds are tolerable if the people understand what's happening and condition their conversation practices to accommodate the delay.

Now we've got the data converted, and we can start squirting it into the network. The logical thing to do might seem to be to create a TCP session between the voice agents. That would allow error recovery should packets be lost. Logical, but wrong. The problem is that voice is real-time in nature, and its important to preserve not only the speech coding but also the relative timing of the speech elements. TCP flow control and error recovery would introduce delays into the speech at random places, and that would interfere with comprehension. Thus, all the voice-over-IP approaches will send over datagrams – UDP.

The variability of arrival even with UDP can be a problem, however. IP networks have a variable transit delay, or "jitter", and this can cause intelligibility problems in itself. To take care of the jitter, the typical speech products use a timestamp process. Each packet is stamped with a time value that provides a measure of when it was generated relative to its predecessor and successor packets. If the destination end of an IP voice connection holds back enough data to compensate for the average period of delay jitter, it can then emit the voice packets at the relative times shown in the timestamps, and the result would be a voice stream that duplicated the timings of the source. The RTP (Real Time Protocol) of IP provides this feature, and so is used for most of these applications today. RTP is also called for in the H.323 packet video/audio conferencing standard, if IP networks are used as the transport mechanism.

Obviously, the goal in RTP has to be to control delay jitter. If something is lost – forget it. Discarding is better than delay in some ways, because the result of discarding will be only a "pop" of noise. Low delay jitter means a small hold-back at the destination, reducing the overall delay.

OK, that summarizes the voice transport side, so it's time to go on to the signaling issues. That's what separates the three optional architectures, and also what may separate the product options.

Signaling has three phases: caller to agent, agent to agent, agent to caller. The first and last of these necessarily involve a telephony-to-data and data-to-telephony exchange, and so it is there we have to concentrate. Agent-to-agent signaling will wait for another time; for now, suffice it to say that the H.323 standard will probably provide the framework.

Two aspects of signaling have to be considered: translation of the calling commands and call acceptance commands, and translation of the call progress signals. The assumption here is that a phone user would have to get the same kind of response from the process of calling over IP that would be associated with normal voice calling, or at least an unequivocal analog of those responses.

Dial signaling is handled today in two basic ways: message and stimulus. The message signaling is associated with "smart" phone protocols like ISDN's Q.931 and the SS7 protocol used for inter-switch signaling in the public network. The stimulus signaling is associated with pulse or touch-tone (DTMF) dialing from an instrument. Signaling is also characterized as being "common channel" signaling (CCS), meaning that all signaling for a group of lines is done on a single "common" signaling line (the "D" channel in ISDN) or "channel-associated" signaling (CAS), meaning in-band on the impacted channel. Most CCS is message-oriented, and most CAS is stimulus.

Call progress signals are exchanged in the same format that the call signaling was done. Stimulus call progress signals are audio tones, like "ringing" or "busy". The caller has to get fairly quick progress feedback during a call attempt, or the result is a "hang-up-and-redial" process. In most networks today, the originating switch (or voice agent, in our example) generates progress signals back to the caller based on interoffice (SS7) messages.

On the destination side, the agent has to recognize the call progress signals from the voice network and translate them into something that can then be returned to the originating voice agent for translation to the caller.

Two problems should be clear here. First, anybody who has a modem for fax or data knows that getting the thing to recognize analog call progress indicators like a busy signal is not a given. This complicates the second problem, which is that the delay across a combination of the phone network and the IP network to signal the called party may be considerable. If so, the caller may hang up, creating dissatisfaction, wasting network resources, and even generating potential billing inquiries.

What separates the options in our IP voice exploration, in signaling terms, is what level of signaling understanding we have. In the first option, signaling is essentially a pass-through function, so anything the parties agree on is fine. In the second one, we need an overall directory of addresses (phone numbers) reachable from each voice agent, but otherwise we don't need any special signaling beyond what each voice agent uses to talk to the local partners.

The third option requries SS7, and it is this option that also addresses a bogeyman issue: what happens if there are IP users who want to call directly from PCs?

Let's look at the options above if we assume a community of IP users. Option one doesn't work at all because the network has no directory to translate IP addresses and phone numbers. This means that if a voice agent supporting a local instrument were to be trying to communicate, the association between the two would have to be permanent; every time the IP guy called, it would be routed to the same voice trunk, like a tie line. The second option could permit calling between IP and agent-served destinations, but the numbering plan would have to be uniform; a given phone number would have to point either to an agent who could dial out to make the connection, or to an on-net IP phone destination.

Where things break down is if a special calling feature like 800 service, call forwarding, or voice mail is used. These features are distinctively part of the voice phone network. An internal IP user could consume them only by being made to look like a real voice user – by being proxied by his/her voice agent. But that might create some eccentric call routings. For example, dialing a phone number from an IP phone might result in a call out to the public network, where the number is forwarded to another IP phone! It's even more complicated if we assume IP-based call forwarding and messaging as well as telephone services of the same type, and try to plot the interactions between.

Desktop PC phone callers also create a problem with voice coding. When agents supported everybody, the only people who cared about voice coding were the agents themselves. If an IP desktop is going to receive a stream of voice packets, however, that desktop will have to use the same coding technique as the originating voice agent, and vice versa.

The third option can't solve the latter problem but it can solve the former. If the IP network can "talk SS7", it can appear to the voice network as another exchange or another carrier. The IP network would presumably be known by its own "area code" or exchange prefix, and calls to it would be routed to the SS7-aware voice agent, who would appear to the public phone network as either a Class 5 (if the agent looked like an exchange) or a Class 4 (if it looked like another carrier) switch.

But we haven't gotten to the tough issues yet: business and regulation. The value of voice over IP is economic, if it exists. Since anything that can be used to compress voice for IP can also be used without IP, the value of compression itself can't be considered an IP benefit. What IP would do that standard TDM telephony would not is take advantage of the silent periods in a conversation to fill in other traffic. ATM or frame relay can also do this, we should point out. Thus, it is not clear that there is a real technical benefit for IP voice.

The benefit must therefore be either to leverage an existing network justified for another matter, or to play tariff arbitrage games. The former justification has been used from time to time with success by businesses on their internal networks. The latter is often based on the no-usage pricing scheme of the Internet. Both create business issues.

Leveraging internal data networks to handle voice calls sounds neat, but there are some regulatory barriers to this in some areas of the world where national administrations have a local exchange monopoly. For example, it would probably be illegal in most countries for a corporation to establish an Internet-based phone service in competition with the local administration. It would be illegal in some for a business to take calls from outside their company off the public network and complete them across a national border. Beware, in other words, of local regulations.

The arbitrage game is also risky. The Internet wasn't intended to carry the total load of voice telephony. To make it capable of doing so would require capital investment and additional bandwidth, both of which can't happen if the callers aren't paying for the voice connections they're making. Thus, the current business model of the ISPs suggests that "Internet voice" will have to be viewed as undesirable, which means it may not continue to be supported.

So where does that lead us? We can do voice over IP, and probably can do it at acceptable quality levels if the IP network is conditioned for the traffic. The problem is that it isn't at all clear whether there is an economic incentive for that to happen. Would it be cheaper for corporate users to build IP voice or just get a voice VPN? In the US, it's probably the latter unless we factor in the arbitrage issues. Internationally, IP is probably a better deal, but we have again the question of how the infrastructure could be augmented to handle voice when the value of voice is based on the assumption that the caller isn't paying extra for the voice traffic. We also have the issue of the legality of the whole thing.

Summary time. Voice over IP is technically feasible, and may be financially viable where integration of low-level speech with a data network is possible. Where public data network resources are used, or public phone connections are supported, legal and business issues will have to be considered carefully before you invest.

So far, IP voice products are concentrated in our first two classes of capability. Whether the third, and most feature-rich class, develops will probably depend on whether the legal and business issues we've noted here are resolved.

Continuing on our theme of integration of networking, we are now going to establish the parameters on which we will be judging vendor WAN ATM architectures in the future. We've looked at the LAN architectures for ATM integration in the past, but WAN ATM is quite different – as you might expect.

Getting answers to all these questions by research would be a daunting task, and frankly nobody's proposing to pay us to undertake anything that complex. What we intend to do to insure that the process of information-gathering is practical, fair to vendors, and still provides the reader with useful information.

We reserve the right to nominate vendors on our own, of course, and we also reserve the right to decline to cover a vendor if they don't really represent (in our view) a viable ATM WAN player. We're looking for vendors with a complete product line, from access mux to core switch, and a portfolio of features and management offerings to match.

Once we have a list of vendor candidates, we will be sending each a copy of this article, so they have the 21 points of evaluation in context. We will then ask each vendor to respond on behalf of their product line in each of the areas. We'll ask them for the following on each point:

1. Their view on the importance of this point to the successful building of ATM WANs. This view might include a "we think this is a dumb issue, and you're dumb for suggesting it is important". No holds barred here, vendors!
2. Their overall product line capabilities in the area, with enough specific details to be clear and useful.
3. A reference to product literature (which they must supply) or web material that validates their claim to have something. If the product or feature is a future, we will ask when it will be available.
4. A statement of direction in the area – one that will indicate future commitments or capabilities.
5. A list of any capabilities the vendor feels are important but that were not included in our list.

We will review the responses in each of the areas, and include our comments. We will allow each vendor to rebut or comment on our position, but only after publication; no previewing of the pieces will be permitted. We will decide what, if any, of the vendor post-mortem comments we'll include in future issues, however. Each vendor who participates will receive a full set of issues containing the published responses. We will advise you of all vendors who do not elect to participate, and we reserve the right to either provide our own views on these vendors' product lines, or seek other sources for detailed information – like customers.

We hope that this will create a kind of "populist review" that reflects more the needs of the real network buyers than the convenience of putting together a matrix or simple statement of capability.

We reiterate that this series of reports will not be published on the Internet. We may make them available in the form of an electronic book at a later time, but we make no commitments in that area for the moment.

Let's see if we can make this something both interesting and useful.

The last issue talked about various real-time approaches in IP. We're going to continue that issue this month, by popular demand, and expand it a bit to include a discussion of some of the strategies in use or under consideration in actually providing service quality.

We've noted many times that there's a difference between making a reservation and getting a table. The question of how networks act to assure QoS is a complicated one, and we're going to take a step upward to look at some of the bigger pictures for a minute.

All QoS starts with somebody wanting it. There are two basic ways that a particular information flow can become blessed with special handling:

1. The originator or destination of the flow can request it. This is what RSVP allows. The problem is that most applications don't know from QoS, and don't make the request. If they do, there's no assurance that the organization would really want the request honored.
2. A network agent can decide, based on some policy set, that the flow should be prioritized. This relieves the users from actually having to deploy QoS-requesting applications. It also eliminates the problem of whether the application or user is really allowed to have what they want.

Whatever happens in the request or identification area, the next step is to do something about the request. That "something" can take a number of forms:

Let's take these issues one at a time, starting with the "How do I know this guy gets QoS?" question.

Given the fact that most of the applications we'll run for the next five years are already being run in some form today, it may be very difficult to make application changes to request QoS. Even if we made them, as our comments above suggest, there'd still be a question of whether we really wanted to give everyone what they asked for. Thus, we believe that QoS is really a policy management function.

With policy management QoS, the edges of the network contain policy agents that monitor incoming traffic looking for somebody special. The way this is done could vary considerably. Some organizations (Ipsilon comes to mind) would look for bit patterns in the IP datagrams. Others have kicked around ideas of linking into the name/address resolution process (DNS) to activate special handling when a given requestor makes a request for a given set of destination resources. Either way, somebody at the edge does a policy lookup and decides to bless this flow, so to speak.

The next issue, and the big one, is how we can communicate that blessing to the nodes that will really handle the traffic. That's where the implementation of this thing gets critical – where what will work separates from what will be neat or interesting, but never useful.

The conditioning of a pipe through the network on a per-flow basis is a problem in the sense that the core nodes of the network will require knowledge of each individual QoS-managed flow. In other words, this concept probably doesn't scale worth do-do. There's also a question of whether letting individual flows select a highly precise form of QoS is useful, given the fact that connectionless networks really aren't designed to handle QoS anyway.

This is where the precedence concept comes in. If we have a finite set of QoS values, why not just tag the data with the correct precedence setting and let the nodes that handle it conveniently lump it into a few (seven, in the case of IPv4) categories? With only a few QoS categories, the nodes don't have an unreasonable task to execute.

The problem with precedence is that one user might well find seven QoS levels enough, but networks are likely to have more than one user. Can we define seven meaningful service levels into which we can lump all possible applications from all possible users? Maybe not. Certainly it would be really hard to get too many people to say that this kind of granularity of QoS is a good thing.

Well, how about approach number three? If we view an IP network as a series of overlapping QoS planes, each with a virtual circuit that leads the traffic onto that plane from each edge node, then the decision that the edge node makes on steering datagrams is based not on destination address (we can get to all destinations on all subnets), but on QoS. How many different QoS destinations can we support? As many as we have discrete identifications on which steering the datagram can be made. Have 900 VCs available on a frame relay interface? Then 900 QoS levels are supportable.

The way this would work is that a policy management process would yield the QoS steering information for a given flow as it entered the network. That steering information would then put the datagram onto one of the QoS subnetworks. There, normal routing would steer it to the destination, which would receive it on the channel that QoS level used there.

Neat, huh? Unfortunately there are problems here, too. The biggest one is that we need to have individual full routing within each subnet, but each subnet covers the same address range. Does that mean we have a router set for each QoS network? If so, this is going to get expensive real fast. If not, we'd need to be able to partition the process somehow.

Look at it this way. My QoS-segregated packet flows into a node from one of the discrete QoS subnetworks. There, I've got to somehow route it without losing which QoS subnet it came from, because I need to get it back to that subnet on exit.

Ascend does this with a "collection tree" of virtual circuits that eliminate the need to route on an intermediate basis. The source node looks at both QoS and the destination address, and puts the datagram on the correct virtual circuit based on both. This means I need one VC for every destination node at each originating node, for each level of QoS I want. That sounds like a lot, but it's not as bad as the per-flow approaches.

The approach is particularly good if we assume that the "network" we're providing QoS over is a WAN, and that the LANs that connect to it are so overbuilt that they won't interfere with QoS at all. The WAN network will thus set it, and the number of destinations in the WAN network is the number of LANs or sites, not the number of desks.

A more generalized approach would be to have the nodes in the network each sit on all the QoS subnetworks. When a datagram arrived, the nodes would remember which subnet it came from, pick a destination trunk, and then put the datagram on the QoS subnet that's associated with that trunk. In effect, we're using QoS subnetwork as a tag to further qualify the destination.

Nobody is exactly doing this today. While the approach is theoretically valid, there is a real potential for eating up processor cycles in making it work. Thus, it's not clear how or who will do this.

Somebody will, eventually. The truth is that the nodal approach we're talking about here is the logical way to do QoS routing in connectionless networks. The resources needed for a given set of QoS options are assigned on a node/trunk basis using whatever metrics are convenient to the equipment and services. Sure this sounds like a cop-out on a tough issue, but anything that is going to assure QoS has to reserve or assign resources to do it; all we're saying is that this approach needs whatever everything else would have needed, so let's set that aside.

Anyway, once that is done, we have effective QoS tiers in the network. Now, the nodes of the network can handle the traffic based on a combination of QoS and destination address. The double metric means that some low-QoS applications might take (dare we say it) the low road, while the good stuff took the high. This could be supported because QoS "tag" would be part of the address lookup.

The advantage of this approach over the virtual circuit collection tree is that a given node doesn't need to have a VC for each destination/QoS combination terminating there. It needs a QoS delineation on every exit trunk, which is a lot less complicated, and requires a lot less handling.

Router purists will recognize this as another of the examples of partitioning routers. A similar problem exists if we use public IP networks to support corporate VPNs with overlapping address ranges. We can't route them together because we'd mix the traffic, so we add a "VPN tag" to the destination address and the result is unique even if the organizations have adopted the private IP address 10.0.0.0 and thus would intermingle sites if their routing was done on the basis of one common table.

We should note here that the MLPS initiative (formerly tag switching) will address, or could address, some of these points. With MLPS, a router would know destinations by a tag to it. If the selection of a tag is made based not only on destination address but also on VPN ID and/or QoS level, the desired partitioning would be available.

The problem here, to recapitulate, is the potential processing power needed to handle all of this. We've made light of the questions of how policy management data is used, and how the actual allocation of resources is done. That's a valid approach when our objective is to analyze options on the basis of what differentiates them; these issues are common to all options. But in a performance and standardization sense, the questions of policy management and resource allocation loom large.

Most policies will be based on source/destination pairings, meaning that the policy effectors will have to know just what combinations of partners need priority. That may require a central database, and the lookup delay on that database could be a significant factor in performance. As we've noted, most companies are looking at combining existing directory functions to create a mass database that can deliver to edge devices not only resolved addresses but also completed policies. The recent Newbridge/Bridgewater alliance on policy management could be addressing this theme.

Most resource allocation is based on a combination of reservations and shaping/policing of traffic. Those are always the ugly issues of QoS, because everybody likes the idea of positive quality but nobody wants to pay a price if their traffic gets unruly and runs outside the envelope the network agreed to carry.

In the final analysis, users want to behave like bandwidth was limitless, and in the final analysis, we may be forced to make that as true as we can possibly make it.

Future issues will deal with the specific vendor responses to our ATM WAN questions. This will probably be spread over six months or more ... be patient.

We're also going to continue our coverage of policy management. As you may already know, we're bullish on this issue as a key driver in 21^st-century networking, but it still needs to mature. We'll cover it as it does.

Access the index of CIMI Corporation's recent newsletters.