February 1999

To: CTI Subscribers

Cc: 3Com, Argon, Ascend Communications, Alcatel Telecom, Cisco, IBM, IETF, Lucent, Newbridge Networks, Siemens Telecom Networks

Subject: Quality Of Service - For The (Permanent) Meantime

Part of the charm of the Internet is that it seems so egalitarian. That is, on the Internet, your packets are no more (or less) important than anyone else's packets. Then again, this egalitarian ethic can be frustrating. For example, it isn't hard to imagine the data packets for your time-sensitive financial transaction being bumped out of line at a crowded router port. And for what? For all you know, your transaction could be delayed because some survivalist out there decided to download a lengthy (and well-illustrated) paramilitary manifesto - as though the revolution couldn't wait a few more seconds!

Ideally, the Internet would provide enough bandwidth so that anyone could do anything at anytime. But we all know that the Internet traffic isn't getting any lighter. New users are jumping onto the Internet every day. And existing users are consuming more and more bandwidth by running increasingly bandwidth-hungry applications.

So, the problem is inadequate bandwidth. What's the solution? Well, the ultimate solution is to simply provide more and more bandwidth, however much is necessary. Yet, most people suspect that however much bandwidth becomes available, people will find a way to consume it. And then, we'll be right back to where we started.

It seems that until bandwidth becomes abundant (if ever), we'll have to institute some mechanism or mechanisms to prioritize Internet traffic. To some, this idea is anathema. For one thing, it would appear to break faith with the Internet's egalitarian spirit. For another, it might ultimately serve as a kind of crutch, a way to avoid provisioning adequate bandwidth. It could even, in a perverse way, support an artificial scarcity that would be profitable for some, but frustrating for the Internet community as a whole.

There is, however, another way to look at prioritization schemes or quality of service (QoS) mechanisms. These mechanisms, by encouraging people to pay for priority service, could generate revenues that could be reinvested (if only in part) in the Internet's infrastructure. In addition, QoS could stimulate a proliferation of enhanced services. While these services wouldn't be free, they would, presumably, offer sufficient value that people wouldn't mind paying for them.

QoS STANDARDS
The challenge of defining QoS mechanisms has occupied the major players in the networking industry as well as standards bodies. The Internet Engineering Task Force (IETF), for example, has endorsed at least two QoS standards: MPLS (Multi-protocol Label Switching) and DiffServ (Differentiated Services). Both standards address issues such as guaranteed bandwidth and minimal latency. They differ, however, as to where each is likely to be used.

MPLS will most likely be used to add QoS functionality with IP routing mapped to the core of carriers' networks (ATM). DiffServ, on the other hand, will probably end up on the enterprise level as well as the ISP level. In these implementations, DiffServ will likely be accompanied by a virtual circuit to a service provider's network or carrier network which is using MPLS-compatible hardware.

The standards also differ in that DiffServ relies on traffic conditioners sitting on the edge of the network to indicate each packet's requirements, which just require software/firmware upgrades. MPLS, on the other hand, requires a fairly substantial investment into a network of sophisticated label-switching routers capable of routing traffic to virtual circuits (VCs) or switched-virtual circuits (SVCs).

Although many IP proponents predict that IP will eventually obviate ATM, I have my doubts. Personally, I believe ATM will be with us for awhile. Thus, I expect we'll use both QoS standards.

What about interoperability between the two? Will they complement each other, or just complicate our lives? The former, I think. While the specifications don't need each other, they can work together. An MPLS network can obtain a packet's QoS information from the DS byte in an IP packet assigned via the DiffServ standard, and then route that packet accordingly. Thus, it is entirely possible we will see a combination of MPLS and DiffServ.

MPLS: MPLS defines a standard in which IP traffic (Layer 3) is directed through the Internet over predefined routes, providing predictable performance, and thus helping to guarantee QoS. MPLS specifies ways that Layer 3 traffic, such as IP, can be mapped to connection-oriented Layer 2 transports such as ATM and frame relay. (Note: TCP is Layer 4, whereas IP is Layer 3.)

When an IP packet first enters a MPLS-compliant network, the network may look at the IP header to determine QoS requirements. Essentially, MPLS adds a "label" containing specific routing information to each IP packet, and it allows routers to assign explicit paths according to the classes of traffic.

MPLS uses fields in the 32-bit (4-byte) label it adds to each IP packet. This label is intended to improve efficiency and control of the router network and allow routers to forward packets along predetermined paths according to specified QoS levels. The label associated with each packet is then used to inform the next hop on the MPLS network the packet's predetermined path(s) it may take.

Of course, as the packet travels across the network, it can be relabeled to travel a better path. After the packet leaves the MPLS-compliant network, the label is then stripped from the packet, which reassumes its original size. As far as the packet is concerned, the routers that carried it across the MPLS-compliant network appear as a single hop.

Today's IP networks require that a forwarding equivalence class (FEC) be evaluated and mapped to each packet at each and every hop, thus reducing efficiency and reducing speed. However, unlike native IP networks and their corresponding routers, MPLS-compliant networks assign each packet an FEC just once, thereby reducing the information routers must process.

When the MPLS-compatible router (also known as a label-switching router) sends a packet to the next hop, it sends the label along with it. Subsequent MPLS routers do not need to analyze the packet. Instead, they need only look at the MPLS label, which is indexed to a routing path table maintained by each of these routers. The logic residing in the table determines the next hop.

Companies with MPLS-enabled ATM switches include 3Com, Alcatel (IP@ATM), Ascend Communications (IP Navigator), Cisco, Newbridge Networks (Carrier Scale Internetworking), and Siemens Telecom Networks.

Beside QoS, MPLS will also address these issues:

1. Scalability of network layer routing and improved performance.
2. Greater flexibility in delivering routing services. For example, using labels to identify particular traffic which are to receive special services, such as QoS. Another example, using labels to provide forwarding (label-swapping based forwarding, also known as "label switching") along an explicit path different from the one assembled by traditional destination-based forwarding.
3. Make cell switches behave as "peers" with respect to routers.

DiffServ: The DiffServ specification, unlike the MPLS specification, is strictly Layer 3, which means that it makes no assumptions about the underlying transport. It is, in fact, strictly IP-based. However, because DiffServ runs over Layer 3, and since IP is Layer 3 as well, this QoS standard can run over Layer 2 networks without any modification.

Basically, DiffServ takes the IP packet's TOS (type of service) field, renames it the DS byte, and uses it to carry information about IP packet service requirements. Packets can then be classified according to priority. For instance, financial transactions can be given the highest priority, whereas e-mail packets can be given the lowest priority.

DiffServ evolved from Integrated Services (IntServ), the IETF standard which relies on RSVP (resource reservation protocol) to set up and tear down resource reservations along the path of data packets. Thankfully, DiffServ will effectively eliminate the need to use RSVP across wide area networks, which means DiffServ will avoid the scaling and implementation challenges presented by RSVP.

PROBLEMS IMPLEMENTING QoS
MPLS-DiffServ combinations may be complicated by varying implementations from vendor to vendor or from carrier to carrier. For instance, Cisco is offering support for three or four QoS levels, whereas Lucent and Argon promise thousands of levels, to provide more granular control over bandwidth allocation.

How might conflicting implementations arise? Once way is through the maneuvering caused by the enforcement of intellectual property rights. For example, IBM raised some eyebrows in the networking community with its announcement to the IETF that the company will charge licensing fees for pending patents pertaining to the MPLS specification. This action will undoubtedly raise equipment prices and possibly slow deployment of MPLS.

IBM's decision could result in developers choosing nonstandard implementations, thus defeating the purpose of the IETF standard. Although IBM has not fully disclosed which portions of the MPLS standard would carry a charge, IBM's Aggregate Route-based IP Switching (ARIS) technology is a necessary part of the MPLS standard. (The charges may affect small networking startups more than anyone else, since larger organizations often swap licensing agreements amongst themselves.)

Nonstandard implementations may also linger as vendors deploy products that combine standards-based and proprietary approaches. A case in point: Cisco, which recently announced that it has enhanced its IOS software to support integrated IP-ATM class-of-service (CoS) capabilities. (IP-ATM CoS helps to ensure traffic priority levels are consistent across IP and ATM networks.) This implementation includes a phased deployment of MPLS and Cisco's Tag Switching to steer traffic over IP/ATM networks.

Cisco's IP-ATM CoS feature supports existing WAN ATM networks and is currently available for Cisco's 7500 series routers. The problem with this solution, however, is clear: Cisco doesn't own the Internet. Thus, once you cross to another vendor's router, the system fails. The benefit of this product is that it is available now. As of this writing, Cisco does not yet offer MPLS products.

PROBLEMS ONCE QoS IS IMPLEMENTED
What are some of the possible drawbacks of providing QoS functionality on the Internet? Well, first of all, the way the Internet works today, every one is treated the same at the ISP level, at least for dial-up connections. Obviously, there are QoS provisions on frame relay Internet connections, T1 connections, and the like. But the home user can be assured that his or her 28.8 or 56K dial-up connection to the Internet at $19.95 or $21.95 per month grants equal bandwidth to all the other customers using the same ISP.

Of course, there are other variables. Even within each ISP, different ISP locations have different "hooks" and bandwidth capacities into the Internet backbone. Thus, gauging access to bandwidth can be a tricky business. But, all things being equal (same modem speed, same local ISP modem bank, etc.), I can at least guarantee that the users of any given ISP will pretty much all have equal treatment when it comes to divvying up the ISP's bandwidth.

My point is this: If we start charging customers more money for guaranteed bandwidth (particularly the home user), will these "premium class" customers allocate to themselves most of the ISP's available Internet bandwidth, thus leaving little bandwidth for the "regular-class" $19.95-per-month Internet home user?

Will this mean that "regular class" customers will have to wait longer for Web pages to load? This is something that surely will cause a stir in the passionate Internet community. Will we see conflict between the "haves" and the "have-nots" with respect to Internet bandwidth? Personally, I doubt it. I see a couple of market trends that should prevent a rebellion by the home user. These include the following:

• The deployment of enhanced applications that will actually encourage home users to become premium-class customers. These applications include Internet call waiting, Internet telephony (VoIP), and unified messaging. Ultimately, the burden is on service providers to attract customers to enhanced services, and to convince customers to pay extra for them.
  
  
• The generation of revenue by enhanced services, and the application of this revenue to infrastructure improvements. MPLS and DiffServ equipment rollouts will only happen if the networking vendors, ISPs, and service providers feel they can make money. Lower prices in the computer/networking industry, for such things as memory, processors, and DSPs, have reduced profit margins, causing companies to look for enhanced services to provide more wealth. QoS over the Internet will open the doors to many enhanced service applications, which is why there has been so much press coverage on these two standards. Some of the profits attained via enhanced services will no doubt be used to offset the increased bandwidth utilization and to improve the overall network infrastructure.
  
  
• Continued increases in the Internet's bandwidth capacity. While premium-class customers may claim a huge "guaranteed" chunk of the Internet's bandwidth, I still believe there will be plenty left for anyone. Of course, purveyors of doom and gloom will disagree. But these sorts have been predicting the collapse of the Internet for some time now, and they have yet to be proven right! So, while demand for bandwidth may always outpace bandwidth capacity, don't look for the Internet to collapse because of capacity limitations.

OPPORTUNITIES OCCASIONED BY QoS
Several products are already redefining the edge of the network, that increasingly nebulous area where the service provider ends and the customer premises begins. These products typically include QoS capabilities. (One such product is discussed in this column's What's Hot section.)

There are, for example, QoS-enabling edge-of-the-network devices poised to crack the multi-billion dollar PBX equipment business. I've seen a few products that bring all the functionality of a PBX to a customer premises simply by installing a network transport, such as ATM or IP, and a "black box," which is called a voice/data switch. In fact, some voice/data switches have completely converged voice onto the network transport (using voice-over-IP or ATM), thus completely alleviating the need for any trunk lines (analog, T1, ISDN) drawn to the customer's premises. Instead, the voice traffic is routed across the network transport (using Internet telephony technology) to a centrally managed system at the CO operated by a service provider.

The only interface the black box (voice/data switch) requires is an Ethernet port and extension interfaces, to which the desktop phones are attached. Some voice/data switches go even further and use Internet telephony to the desktop, thus eliminating the need for the phone company to draw phone lines to an office building. This is exciting stuff. This is the future of CTI.

CONCLUSION
An Internet that can support QoS is an Internet that can support video conferencing, multicast conferencing, and enhanced services. Moreover, with an Internet capable of QoS, Internet service providers (ISPs) will be able to roll out Internet telephony services, which means that ISPs will be able to compete with competitive local exchange carriers (CLECs) and incumbent local exchange carriers (ILECs) for customers' billable phone minutes. In addition, many ISPs and second-generation CLECs will have an added advantage over ILECs; that is, they will have the benefit of having built IP and/or ATM networks, which can more easily handle enhanced services such as Internet call waiting, Centrex-style services, or virtual private networks (VPNs).

When voice and data services are offered across a single data network, manageability, serviceability, administration, and powerful reporting can be performed much more easily and much less expensively. Also, since the voice and data services are centrally managed, billing can be performed via a single invoice. VPNs will be one of the biggest benefactors of DiffServ, since service providers can provide tiered pricing based on customers' bandwidth requirements.

So, with all of these wonderful possibilities, why would anyone object to implementing QoS on the Internet? My guess is that some people feel that implementing QoS would be contrary to the Internet's character, which, to date, has been remarkably egalitarian, thanks, in no small degree, to the absence of any privileged class of users. Once we start defining different classes of users, however, we risk letting ourselves become so absorbed in divvying up Internet bandwidth that we fail to recognize the possibility of simply expanding the Internet's overall bandwidth capacity. Or so the fear runs.

The challenge, as I see it, is to pursue dual goals for the Internet. We need to allocate existing bandwidth as intelligently as possible while, at the same time, increasing the overall quantity of bandwidth. But allowing ourselves to be drawn into Byzantine allocation schemes could distract us from the overriding need to simply provision more bandwidth for everyone. Bandwidth, after all, isn't a limited resource, like oil. It's something we create. But how much of it will we create in the absence of the usual incentives?

By "the usual incentives," I mean money, of course. Where will it come from? Is it too much to expect that those who place the greatest burden on the Internet should be the ones to contribute the most to the maintenance and growth of the Internet? In a sense, that is what QoS (and MPLS and DiffServ) is about - deploying mechanisms whereby revenue is extracted from the biggest consumers of Internet bandwidth. Rejecting QoS out of a commitment to egalitarianism, or whatever else we might think to call it, might deny us a workable option for the continued growth of the Internet, both in terms of capacity and in terms of the sophistication of the applications supported by the Internet.

AltiGen Introduces IP Telephony Option
At CTI™ EXPO in San Jose, AltiGen announced Integrated Voice/IP Gateway for its AltiServ all-in-one CTI server (PC-PBX), as part of its AltiWare IP package. The gateway supports standards for both multimedia communications (H.323) as well as voice compression (G.711 available/G.723.1 pending). AltiGen's Integrated IP telephony option saves money, provides flexibility, and reduces complexity for small to mid-sized businesses and branch offices.

Dialogic Enhances Board Management
Dialogic has released an SNMP-compatible software for remote CTI board management of Dialogic hardware. This allows for centralized management capabilities, and it provides a single point of configuration and inventory for Dialogic hardware.

Sample HP OpenView scripts provide customized and integrated views of Dialogic devices. Using BoardWatch, system owners can reduce the total cost of ownership of their CTI systems by lowering their technical support costs. Technical support departments can directly view the board model, driver, and firmware versions, along with other important configuration and performance information about the machines and boards they are supporting, without assistance from the remote user.

Supported boards include Dialogic's ProLine/2V, DIALOG/4, D/21D, D/41D, D/21H, D/41H, D/41ESC, D/41ESCplus,VFX/40ESC, D/160SC-LS, D/80SC, D/160SC, D/240SC, D/300SC, and D/480SC. SNMP management of CTI hardware is a great feature that has been long overdue.

VINA Technologies Rolls Out QoS-Enabling Edge Device
Although VINA doesn't rely on MPLS or DiffServ (discussed in this column), it does allow for QoS, via native ATM, which has inherent QoS. The VINA solution, called Multi-service Xchange, enables service providers to extend their infrastructures to deliver ATM-based voice and data services to the customer premises.

At the customer premises, VINA's Business OfficeXchange (BOX) hardware and software solution allows small business and branch offices to integrate all of their communications requirements in a single device. BOX comes with voice switching (PBX functionality), data and Internet capabilities, key system functionality, and VPN features. Since BOX has voice switching (up to 144 voice ports) and key system functionality built-in, it acts as a miniature local voice switch, minimizing the number of Class 5 switches required for local deployment.

Incidentally, when VINA came to visit TMC, the company brought along with a customer of theirs, a second-generation CLEC. The customer told us they were able to move into cities at a tenth of the traditional cost. The reason? The customer didn't have to deploy $10 million AT&T 5ESS switches in each city they operated, since VINA's product requires nothing more than a T1 connection at the customer premises and an ATM network in the second-generation CLEC's infrastructure. Who says voice and data convergence is a pipe dream? Viable business applications exist today!