Address Translation

A subject that is often confused with gateway discovery is the translation of a telephone number into an IP address. Among the services that need such translation are phone-to-PC calls made from a PSTN telephone to a PC (or to any telephony-capable IP appliance) on the IP network. A way to accommodate such a call from the PSTN is to assign the PC a telephone number. This not only allows a PSTN operator to leverage its existing PSTN infrastructure to offer IP telephony services, but also makes it easy for the telephone user to place a call to a PC. Of course, telephone numbers for this purpose should adhere to a special numbering plan that is distinct from the ones used in traditional telephony services. Depending on its geographical scope, this special numbering plan is under the administration of ITU-T or the national (or regional) telephone numbering authority.

Another service in question is Internet Call-Waiting, with which an end user can be notified of an incoming call while using the telephone line for a dial-up connection to the Internet. Upon receipt of the notification, the user then has the option to reject or accept the call. Either way, there are further details on the disposition of the call. What is relevant here is that the notification is delivered to the called party (identified by a telephone number) over the Internet. Ensuring instant notification of a call in waiting typically requires the knowledge of the IP address of the PC connecting to the Internet via the telephone line.

In general, any directory-like technology can support the type of translation in question. An example is a domain name system, which is best known for mapping a domain name (for example, www.lucent.com) to an IP address. Another example is LDAP, which is used to look up information (for example, John’s e-mail address) in a directory that is organized in a special tree structure. A caveat is that whatever existing directory technology is used must be adapted to satisfy the special requirements posed by IP telephony. One such requirement is that the directory used must allow for frequent updates of its entries. This arises where an IP endpoint is assigned an IP address dynamically, as is often the case in dial-up connections. In contrast to the relatively static telephone number given to the IP endpoint, the IP address changes at each connection. Another special requirement has to do with the real-time performance need of IP telephony. The additional step for directory lookup must not introduce significant delay in the IP telephony setup procedure.

An immediate benefit of using the general directory technology for telephone-number-to-IP-address translation is that other attributes associated with the endpoint can also be obtained with the operation. Consider as an example Mary, who wishes to receive calls at her PC over the IP network only from her daughter between 5:00 and 6:00 p.m. every day. Such information can be stored in the directory. If so, a call to Mary could trigger a directory query whose response includes the IP address of Mary’s PC as well as her preference for receiving calls. The additional information can then be used to process all calls to Mary. For instance, a call from a friend at 5:15 p.m. will result in no attempt at call setup inside the network. Instead, the call will be redirected to Mary’s voice mail. If you find this scenario familiar, you are right. It is similar to an IN-supported service where the user’s policy (or service logic) plays a part in the overall call processing and the policy is stored somewhere inside the network. This similarity again suggests that a networked repository for policies and dynamic information (for example, IP addresses) with simultaneous access from the PSTN and IP network is an effective device for supporting integrated services.

The subject of telephone number translation has been addressed in the IETF Telephone Number Mapping (enum) working group (www.ietf.org/html.charters/enum-charter.html ), which has been chartered to “define a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (for example, URLs) which can be used to contact a resource associated with that number.”

Gateway Location

What we have touched on so far are the core gateway functions—signaling and media conversion. Yet, to support an IP telephony call end to end, other things need to be taken care of. One such thing is gateway location.

Suppose a call originated in (or was passed on to) an IP network, and the call needs to be terminated in the PSTN. There are many gateways that could do the job, but only a few may be suitable for a particular call. For instance, the gateway definitely should be chosen so as to terminate the call at the point in the PSTN as close to the called party as possible. In this case, terminating at the gateway that is connected to the called party’s end office is clearly the optimal solution if other factors are not involved.

But other factors are typically involved, such as the load and capability of gateways in question, the IP network provider’s and the end user’s preferences, agreements with the PSTN service providers, and—to top it all—the costs to be incurred.

Thus, gateway location is an important activity that is bound to become more complex as more telephony gateways are built and deployed. A considerable amount of research on the subject has been done (Schulzrinne and Rosenberg, 1999) and more or less detailed proposals on that matter have been submitted to both ITU and the IETF [specifically, the IP Telephony (iptel) working group].

As it happens, the Internet has had a similar problem with interdomain routing, which has been solved. It should come as no surprise, then, that many ideas of a specialized routing protocol [called Border Gateway Protocol (BGP)] have been used to develop the gateway location technology.

In the tradition of IP routing, the process is dynamic and the knowledge is built using distributed computation performed by the gateways. Before the decision can be made regarding which gateway to choose, the database of eligible cooperating gateways has to exist. This database is built in the act of gateway discovery. Figure 1 shows a representative architecture that spans several administrative domains. Each domain, which contains several gateways and some number of endpoints (for example, PCs), has at least a logical entity, called a location server. The main job of the location server is to learn about the gateways in its own administrative domain as well as in other domains and to construct the database of the gateways. In the intradomain case, this is usually achieved in a registration process. Each gateway signs on with the location server when started up and updates its availability status whenever necessary. The information is propagated by means of an intradomain protocol, such as the Service Location Protocol.^[7]

Figure 1: Architecture for gateway discovery.

In comparison to the intradomain case, discovery of gateways in other domains is not as straightforward a process. Complicating the process is the need for a business agreement between the administrative domains for any exchange of gateway information or any use of the gateways by users in a different domain. A location server can only propagate to another location server the gateway information that is permitted by the agreement between the administrative domains to which they each belong. Similarly, synchronization of the database in one domain with that of another and selection of the route of a call are subject to the intradomain agreement and policy. As a result, there cannot be a single global database of gateways where a user can look up and select a gateway as desired. Instead, different databases may be available in different domains based on the respective business agreements and associated policies. The database contains the IP address of a gateway and a range of telephone numbers that the gateway can terminate. In addition, it contains the attributes of the gateway, such as signaling protocols (for example, SIP and H.323), usage cost, and the provider’s identification number, which we have mentioned before. A location server uses the attributes to decide which gateways are to be used for terminating a call to a particular number or to be further advertised to other location servers.

Interdomain gateway discovery is carried out through an interdomain protocol, such as the Telephony Routing Information Protocol (TRIP), which is under development in the IETF. As mentioned before, an inter-domain gateway discovery protocol resembles a routing protocol. It also shows significant differences, however. The most important are that the inter-domain gateway discovery protocol runs at the application level and runs between location servers, which may not be adjacent and, unlike routers, do not forward IP packets.

As far as access to the gateway database is concerned, it is an activity that is independent of gateway discovery. There are several possible approaches for such database access using different protocols. One protocol is Lightweight Directory Access Protocol (LDAP), which, as its name suggests, is for access to any directory organized in a special tree structure. When LDAP is used, the gateway database is organized based on the LDAP data model. Another protocol is Service Location Protocol, which has been designed for locating a networked service based on service attributes rather than the name (or location) of the network host providing the service. Logically, it can be used to find gateways given a set of user preferences. Yet another protocol is HTTP, the communications enabler of the World Wide Web. In this case, the gateway database has a Web front end, which allows a user to query it through Web-based forms. We should note that an inter-domain gateway discovery protocol is actually another possible candidate. Nothing prevents it from being used for retrieving information in the gateway database.

Media Gateway Control

An application-level protocol over the N1 interface can be used by the media gateway controller to run the media gateway (as far as call control, connection control, and resource allocation are concerned). Industry approaches vary in the way that resources are represented and calls and connections are modeled. Huitema et al. (1999) describe an early approach. Supplanting it is the approach that has been pursued jointly by ITU-T and the IETF media gateway control (MEGACO) named after the IETF working group [see www.ietf .org/ html.charters/megaco-charter.html]. While bearing resemblance to Huitema’s approach, MEGACO differs in a considerable way as well.

At the heart of the MEGACO approach is its connection model, which consists of two types of objects: a termination and a context. A termination is a source or sink of one or more flows on a media gateway. It has properties (for example, media characteristics, a set of events that can be detected, and a set of signals that can be acted on) describing the nature of the termination. Bearer circuit channels and RTP streams are examples of terminations. In particular, bearer circuits, like other physical resources, are terminations that are persistent as long as they are provisioned on a gateway. In contrast, RTP streams, which are created on demand, are ephemeral terminations. Terminations may come in a wide number of types. The MEGACO approach includes a mechanism to define them in separate packages.

A context is an association of a collection of terminations that defines the directions of flows, if any, between the terminations. Terminations can be added to or removed from a context. A context is created when the first termination is added and is destroyed when the last termination is removed. (Similarly, an ephemeral termination is created when it is added to a context and destroyed when it is removed from the context.) Terminations can also be moved from one context to another. In addition, their properties can be modified within a context. Terminations without any association belong to a special type of context called the null context. Such terminations usually represent physical resources. Adding these terminations to a normal context removes them from the null context; removing them from a normal context returns them to the null context. Figure 1 shows examples of contexts and terminations.

Figure 1: Examples of contexts and terminations.

Based on the connection model, the MEGACO approach defines a set of commands for the overall purpose of call and connection control. Among them are the commands for direct manipulation of terminations and contexts, including addition of a termination to a context, removal of a termination from a context, modifying the properties of a termination, and moving a termination from one context to another. Other commands are for auditing of the current state of a termination and the range of the termination properties supported on the media gateway, event notification, and management of the association between the media gateway and the controller. Most of these commands are initiated by the media gateway controller and are sent to the media gateway under its control. The exceptions are the ones for event notification and association management. For notifying the controller of certain events (for example, off-hook and end-of-tone) received by the media gate way, the command for event notification is naturally initiated by the media gateway. In contrast, the command for association management can be initiated by either the media gateway or the controller. When initiated by the media gateway, it is used to notify the controller of the change of the availability status of terminations on the media gateway or the availability status of the gateway itself. When initiated by the controller, it is used to instruct the media gateway to establish an association with a new controller or to take certain terminations out of service.

Another important aspect of the MEGACO approach is its operational model, which recognizes transactions and actions. A transaction consists of one or more actions; an action is composed of a series of commands and is applicable only to a specific context. Invocation of transactions is done by way of messages. To reduce the load of the communications exchange between the media gateway and the controller, a message can hold multiple transac- tions. The transactions in a message are treated independently and can be processed in any order or concurrently. In contrast, commands within a transaction must be processed sequentially. When a command fails, the processing of the rest of the commands stops, unless the failed command is optional. Commands must be responded to upon completion. When a transaction takes a long time to complete, a provisional response should be sent periodically to its originator indicating that the transaction is being processed. Responses are sent also by way of messages. As expected, a message can hold multiple transaction responses, each of which consists of a series of action responses. An action response comprises the responses to the commands pertaining to the action.

An assumption of the MEGACO operational model is that messages are exchanged reliably over the network. For this reason, implementations must ensure that the media gateway and the controller use a reliable transport mechanism [such as Transmission Control Protocol (TCP)] for the relevant exchange. When an unreliable transport [such as User Datagram Protocol (UDP)] is used, the mechanisms that eliminate message duplication and ensure in-sequence transmission of transactions must be used. In addition, it is important to have mechanisms that detect network congestion and respond to it by reducing the traffic. On the other hand, when a reliable transport is used, simple application-level timers may be all that is needed to guard against component failure and undesirable use of the network.

As you have probably noticed the MEGACO technology is somewhat closer to supporting the old-type telephones than true IP telephones, which can establish an end-to-end call without the network even being aware that the call is established. Doing so requires signaling protocols such as SIP and H.323.

Gateway Decomposition

The different types of gateways described iare specific instances of a generic gateway notion. It is useful to decompose the generic gateway into several functional components. Figure 1 depicts a common view of such a decomposed gateway. Three components are identified: (1) the media gateway (MG) function, (2) the signaling gateway (SG) function, and (3) the media gateway control (MGC) function. We describe these functions next.

Figure 1: Components of a decomposed PSTN-Internet gateway.

Physically, the media gateway function terminates PSTN circuits and connections to IP routers (in relation to which it is a host). It also performs all the necessary transformation to convert bit streams received from the sending network into bit streams particular to the receiving network. The transformation occurs at two levels: transmission and application.

At the transmission level, the MG function converts the bit streams between two different framing schemes. This usually involves multiplexing of bit streams of distinct communication sessions and the reverse operation—demultiplexing. In the PSTN, fixed-size digital channels (each typically carrying a voice conversation) are multiplexed based on the time division multiplexing (TDM) scheme at various hierarchical levels (for example, T1 and E3) and packed into frames for transmission over high-capacity facilities. In the IP networks, bits representing a voice conversation are packetized according to the Real-time Transport Protocol (RTP) profile for audio and video payloads (RFC 1890).

At the application level, the transformation takes place between different media-encoding schemes (see the section on codecs for more information) and is commonly known as transcoding. In IP telephony, two prevalent speech encoding schemes are G.711 and G.729. Operating at a bit rate of 64 kbps, G.711 is used ubiquitously in the digital backbone of the PSTN and sets what is known as the toll-quality voice standard. G.729 operates at a much lower bit rate of 8 kbps but still supports near-toll-quality voice service. For this reason, it is widely used in IP networks where bandwidth is constrained. Note that transcoding is computationally intensive and thus causes delays. In addition, transcoding results in degradation of voice fidelity, in particular when a speech coder uses compression.

Another important task of the MG function is to support the use of the QoS facilities of the IP network. Other tasks include echo cancellation (if required), event detection, signaling generation, usage recording, and support of specialized resources such as conference bridges, fax machines, modem pools, and interactive voice response units.

The SG function receives and sends PSTN signaling (such as SS No. 7 or ISDN access) messages. Depending on the arrangement, it may relay, translate, or terminate the PSTN signaling. It exchanges signaling information with the MGC function over IP, and with the PSTN using the SS No. 7.

The MGC function provides control of the media gateway function, including call and connection control and resource management. To this end, it terminates and originates all the relevant signaling. In addition, the MGC function keeps an inventory of the MG resources (for example, bearer circuits and RTP streams) and instructs the MG to reserve or release resources as required. (Naturally, some sort of local policy will govern the use of resources.) With its central role in call and connection control, the MG function logically also provides support for Internet offloading or advanced services and features (such as freephone or call-forwarding). It has the ability to detect data calls from the PSTN and to direct the data traffic straight to a network access server as well as to launch queries to SCPs for instructions for further call processing.

IP Telephony Gateway

If a call is to be made from a PC or specialized IP phone to a regular PSTN telephone or vice versa, both the PSTN and IP network are involved in making the call. The PSTN may also use an IP network for so-called trunk replacement, or IP trunking, where the long-distance portion of the PSTN voice traffic between two PSTN telephones is carried over an IP network.

When it comes to delivering real-time voice, the PSTN and an IP network are different in a number of ways, as summarized in Table 1. For establishing a call, for example, SS No. 7 has been traditionally used within the PSTN, while H.323 is the most prevalent protocol suite [with Session Initiation Protocol (SIP) as a viable alternative] in the Internet to date. In general, the connection of two dissimilar networks is achieved through some sort of a device—called a gateway—that compensates for the differences in the networks. There is no exception when it comes to interconnecting the PSTN and IP networks for supporting IP telephony. In this case, the interconnecting device is called an IP telephony gateway and will link users of IP telephony with a billion or so PSTN users.

Table 1: Key Differences between Telephony over the PSTN and the Internet

Distinguishing Aspect	PSTN	Internet
Bandwidth allocation for voice transport	A dedicated circuit (e.g., 64 kbps) set up for each two-party communications session.	Best-effort delivery of IP packets.
Numbering and addressing scheme	14-bit point code for network nodes and E.164 for endpoints.	4-byte IP address, domain name system (DNS), e-mail address, uniform resource locator (URL), etc.
Voice representation	Typically analog in the loop and G.711 (either A-or m-law) in the backbone.	G.711, G.723.1, G.729, etc.
Signaling protocols	Signalling System No. 7 Q.931, etc.,	H.323, SIP, etc.
Availability	99.999% (5 min downtime per year).	99% (88 h downtime per year).

Figure 1 illustrates the integration of the PSTN and the Internet (or any IP network) through gateways in support of IP telephony. It distinguishes four types of IP telephony gateways based on the PSTN interfaces and certain specific functions that they support.

Figure 1: PSTN-Internet integration through gateways.

1. 
   
   Trunking gateway. Connects a central office (CO) switch to an IP router. Such a gateway typically has an SS No. 7 signaling interface and manages a large number of 64-kbps digital circuits and Real-Time Transport Protocol (RTP) streams. It is used in the trunk replacement application where the long-distance portion of a call between two telephones is made over the IP network instead of the PSTN. (In IP telephony parlance, such calls are known as phone-to-phone calls.)
2. 
   
   Access gateway. Connects telephones or PBXs to an IP router through an access interface [such as ISDN primary rate interface (PRI)]. It supports calls between two telephones with the IP network as an intermediary transport or between a telephone and a PC. (Again, in IP telephony parlance, calls between a telephone and a PC are also known as PC-to-phone calls or phone-to-PC calls.)
3. 
   
   Network access server. Connects a central office switch to an IP router. (Though previously discussed, it is included for completeness, because this type of gateway can be controlled in exactly the same manner as others.) Such a gateway may have an ISDN interface similar to that of the access gateway.
4. 
   
   Residential gateway. Connects analog phones to an IP router. Such a gateway typically supports a small number (two to four) of analog lines and is located on the customer premises. It brings the Internet interconnection point directly to the curb and maximizes the use of the IP network for calls between two telephones as well as between a telephone and a PC.

Active Networks | QoS

Some implementations of active networks (AN) exist (for example, see www.cccc.com), but no standards projects are currently associated with them. The area of the application of AN is larger than ensuring QoS, but AN is viewed with much interest in the research and development communities as a possible means of ensuring and supporting QoS.

As Calvert et al. (1998) observe, AN means different things to different people. In a sense, this is true, although everyone seems to agree that, in a nutshell, AN is about programmability of network elements (for example, routers) and—to an extent—bypassing, if not totally eliminating, standardized protocols, replacing them with dynamic, created-on-the-fly protocols. Marcus et al. (1998) lament that “existing protocols do not operate well for emerging applications or take advantage of novel network technologies,” citing “IP’s inability to capitalize on sub-networks which offer quality of service . . . guarantees.” While one could argue with this particular example, there is a point in the complaint. It is indisputable, however, as the authors further note, that “Forming a consensus within large groups is a slow process, and is likely to remain slow; therefore, protocol standards will continue to evolve at a slow pace.” The question, of course, is whether this pace is sufficient for the market development, and only the future will bring the answer. The idea behind AN is quite similar to (if not influenced by) the idea that resulted in the creation of Java. The language [Hypertext Markup Language (HTML)] and the protocol [Hypertext Transfer Protocol (HTTP)] that made possible the Internet killer application—the World Wide Web—do not support rapid interaction of the user with the page. Such interaction has been made possible by the invention of the principle by which a program (applet) written in Java is sent to the user’s personal computer (PC) or Internet appliance and then interpreted locally (by a Java interpreter). The user actually sees no difference (unless a silly message on a screen proudly announces that a Java program is being executed). The user simply clicks on an object, and HTTP carries the Java code to the user’s machine. Now, AN proposes pretty much the same mechanism, except that the active code is to be carried not in the application protocol message but in a network layer packet, and this code is to be executed not (or, in general, not only) at the host, but by the network elements themselves. Although many questions can be asked (most cannot yet be answered) regarding the security issues involved with this approach and its exact applications, it is relatively straightforward to see how in principle the QoS-related state of a router can be changed with unprecedented efficiency, and how the network-wide services could potentially be implemented. A specific and somewhat less futuristic application of AN to network management is described in Raz and Shavitt (1999).

The overall architecture for AN is being developed in the Defense Advanced Research Projects Agency (DARPA), the same organization that sponsored the development of what has now become the Internet. Several universities (notably Berkeley University, Columbia University, Georgia Tech, MIT, the University of Arizona, the University of Kansas, the University of Pennsylvania, and Washington University—by no means an exhaustive list), as well as the research facilities of major corporations, have AN projects.

There are two things on which the AN community agrees: (1) Networks must be service independent and (2) end-to-end service programs must be network independent. Do these sound like early IN principles? Exactly! After all, the more things change, the more they stay the same.

Label or Tag Switching | QoS

We now move to label switching or, as called by some implementations, tag switching, which is standardized by the IETF. The technology was initially developed for the purpose of interworking between the IP-based and ATM and frame relay networks, and it was later developed to apply to any network layer protocol (hence the multi- designation). The ATM (B-ISDN) switches follow the PSTN model in establishing and maintaining virtual circuits and virtual paths. The B-ISDN access protocol specifies the QoS, which is then guaranteed by the network.

To get an idea of MPLS, try to answer the following question: If the ATM and IP networks are to interwork, what should the router on the border of the ATM and IP networks do? The most straightforward answer is try to maintain the virtual circuits and virtual paths. To do so, the first router in a chain would need to “understand” the “ATM language” and act (that is, route the packet) based on the connection identifier established by the ATM switch. The next router on the path to the destination does not necessarily have to “understand” the same “ATM language,” but then it needs to understand whatever means the first router uses to identify a connection. The same applies for the rest of the routers on the path to the destination.

This is precisely how the MPLS routers work. They make forwarding decisions based on a fixed-length string called a label to decide how to forward the packet. The labels are meaningful only to the pair of routers sharing a link, and only in one direction—from a sender to the receiver. The receiver, however, chooses the label and negotiates its semantics with the sender by means of the Label Distribution Protocol (LDP). The label can indicate not only where to forward the packet (that is, which port to use), but also the QoS characteristics of the packet that specify its priority and suggest an appropriate treatment.

This approach is very different from the traditional (that is, non-MPLS routing) approach, where a router makes forwarding decisions based on the IP header. In the traditional approach, the routing table must be searched, which takes more time and processing power than a lookup in a label table, which the label-based forwarding requires. Furthermore, the routers that are not capable of analyzing the network layer packet can still perform the label lookup and replacement (a much simpler operation). Another advantage of MPLS is that using the labels (that is, in a sense, maintaining the history of the path) allows the forwarding decisions to be made based on the identity of the router at which the packet enters the network—packets entering the network via different routers are likely to be assigned different labels. Finally, when a packet is to be forced to follow a particular explicit route (rather than be left to the mercy of routing algorithms), the MPLS label can be used to represent the route. RSVP can be extended to complement MPLS by associating labeled paths with the flows. With that, resource reservations associated with an explicit route can be made to guarantee QoS.

We should mention one more important MPLS application: MPLS provides an excellent mechanism for tunneling by stacking the labels and thus supporting nested routing decision making. One important potential application of combining RSVP and MPLS is that the resulting tunnels can be routed away from the points of network failure or congestion. We highly recommend the work of Armitage (2000) as a comprehensive review of the subject.

Another means for ensuring QoS is network-wide enforcement policies, which are rules for control of the network resources and services. In describing these, we follow Kozik et al. (1998). Quality of service is only one aspect of policy-based networks; others are security, authorization, and accounting. These aspects are often inseparable—the accounting function, for example, may determine whether the present level of use has been paid for (by keeping track of the use of the resource). If use has not been paid for, policies can restrict access to the resource or affect QoS by downgrading the level of use.

The architecture of policy-based networks—sometimes also called directory-enabled networks. The architecture actually repeats the IN conceptual pattern in both the way that the policies are stored and the way that they are accessed by network elements (for example, routers, access servers, or telephony gateways). The policies are stored centrally in a policy database by a policy management system. When a network element detects an event that requires policy access (such as a request to provide bandwidth in order to establish an IP telephony call), the network element queries a policy server, which in turn consults the policy database and then either denies the request or carries it through by instructing all concerned entities to perform the actions that would enforce the policy.

Figure 1: The architecture of policy-based networks.

The IETF is addressing the subject of policy-based networks in the Policy Framework (policy) working group.

Fair Queuing and Weighted Fair Queuing | QoS

Using the new queuing schemes, each flow now has its own queue. With the fair queuing policy, the packets are transmitted round-robin in order to guarantee each flow an equal share of the capacity (possibly penalizing flows that have large packets at times of network congestion). Weighted fair queuing—an algorithm that is widely used in today’s advanced QoS-capable routers—assigns each different type of flow its (by no means necessarily identical) share of bandwidth. Figure 1 illustrates the concept: In Figure 1a, with the first-come, first-served queue, airplanes, cars, and elephants move in the same order in which they have arrived (a scheme that would cause plane crashes and annoy the drivers of the cars following elephants!). In Figure 1b, with fair queuing, the queues are formed per each flow (defined here as a formation of planes or cars or a caravan of elephants), but they are preempted so that bigger things have to wait until an equivalent number of smaller things passes (still, a maddening experience for elephants!). In Figure 1c, with weighted fair queuing, the planes are given the right of way, so they move through the queue almost without slowing down and always keeping formation; the planes are followed by cars, and the cars by the caravan of elephants. This property of keeping the packet “formation” eliminates delay variance (called jitter).

Figure 1: Queuing and scheduling in routers. (a) First-come, first-served queuing. (b) Fair queuing. (c) Weighted fair queuing.

In 1992, A. Parekh and R. Gallager of MIT demonstrated that a flow that experiences a service rate slightly higher than the flow’s data rate has a bounded delay. In other words, by requesting that a flow not exceed a certain rate, the network can guarantee that the delay experienced by the flow does not exceed a certain value. (A good example of a similar result is green streets in cities, where stoplights are adjusted so that a car traveling at a certain speed—for example, 25 mph—is guaranteed a green light at about 9 out of 10 intersections.)

The scientists then augmented the weighted fair queuing with the specification of guaranteed delay for each flow. This work resulted in a new architecture for what its creators called integrated services packet networks [compare with the expansion of the integrated services digital network (ISDN)] in Clark et al. (1992). Two types of services—guaranteed (which supports real-time traffic with determined latency and jitter bounds) and controlled-load (which deals with relaxed traffic)—were defined. At that point, the groundwork was laid for the standardization work in the Internet Engineering Task Force (IETF). The protocol that defines integrated services, called the Resource Reservation Setup Protocol (RSVP)—which is not a routing protocol. In a nutshell, RSVP, which was designed with multicasting (that is, sending a message to multiple receivers) in mind, makes bandwidth reservations—from destination to source—in the routers along the spanning tree covering multicast group members. The routers store the necessary state information, which is then maintained by sending specific RSVP messages in both directions.

The integrated services approach has been comprehensive, but apparently far too ambitious to implement widely. One recurring sentiment is that the overhead associated with reservations is far too large; the other is that it is overkill as far as the short-lived flows (of which most of the present Internet traffic consists) are concerned. (The counterargument to the latter is, of course, that the model was not created with the short-lived flows in mind; but then, something needs to be done about the short flows, too.) The third concern (Weiss, 1998) regarding the integrated services approach is that it would make charging those who request a higher QoS difficult. In any event, while the applicability of the RSVP to wide area networks and the Internet is questioned, it is being implemented for smaller enterprise networks. In essence, the integrated services approach has been a top-down one—guaranteeing absolute QoS in the network on a per-flow basis.

A bottom-up alternative technology, where QoS building blocks (which routers can recognize and act on) are defined, is called differentiated services (Kumar et al., 1998; Weiss, 1998). This technology has been actively addressed by the IETF and has resulted in a standard. The concept behind the technology is definition of various classes of services. The service provider establishes with each customer a service level agreement (SLA). Among other things, an SLA specifies how much traffic a user may send within any given class of service. A particular class of service of a packet is encoded in its IP header. The traffic is then policed at the border of the service provider’s network. Once the traffic enters the network, specialized routers provide it with differentiated treatment, but—unlike the case with the integrated services approach—the treatment is based not on a per-flow basis, but solely on the indicated class of service. The overall network is set up so as to meet all SLAs.

Quality of Service (QoS) | Converged Networks

The Glossary of the Telecommunications Terms of the U.S. Federal Standard 10377 (available at www.its.bldrdoc.gov/fs-1037/fs-1037c.htm) defines quality of service (QoS) as:

1. The performance specification of a communications channel or system. . . . 2. A subjective rating of telephone communications quality in which listeners judge transmissions by qualifiers, such as excellent, good, fair, poor, or unsatisfactory.

This definition best expresses both the objective (that is, something based on a computable metrics) and subjective (that is, perception-based) aspects of the QoS concept. Three objectives that drive the need to integrate the Internet and the PSTN relate to QoS: (1) carrying voice across both the IP networks and the PSTN, (2) combining the PSTN transport and IP access to services, and (3) accessing the IP networks over the PSTN lines. The first item is associated with the most perceivable QoS requirements. Nevertheless, the IP network access aspect (and connected to it, issues of supporting VPNs) is equally important, as we will demonstrate.

To begin with, different applications (or, rather, their users) have different perceptions of what the QoS is. Using an application called telemedicine, a doctor may expect a copy of a brain tomogram taken in a remote laboratory. The transmission can be delayed for a few minutes; however, the doctor cannot afford to have any detail of the tomogram compromised (a missing detail could wrongly suggest a tumor or leave it undetected)—the chief QoS requirement here is that no data arrive in error. On the other hand, in an IP telephony application, an occasional error in the signal would cause no problem; however, a long delay (or a variable delay, called jitter) is likely to be unacceptable.

The model of routing for the PSTN is based on the concept of circuits, which are created end to end for the duration of the session. Circuits are mapped into fixed switched physical connections. Thus, any message between two end users in a session always traverses the same physical path for the duration of a session. [For conferencing, such circuits can be bridged (that is, joined) by switches or other devices that have switching fabric; thus, any multicast message will follow the same, predetermined set of physical circuits.] With this routing model, it is possible to determine whether a session that requires certain characteristics (such as bandwidth or loss tolerances) can be established. Once the session is established, it is relatively straightforward to guarantee that the requested characteristics will remain constant for the duration of the session.

One important factor in PSTN routing is the time that it takes to set up a circuit; the call setup time has traditionally been an essential QoS metric in the PSTN. Incidentally, this model, which naturally grew out of telephony, was applied by the ITU-T to the definition of virtual circuit for data communications standards. First, this concept was defined in X.25 and, subsequently, frame relay and asynchronous transfer mode (ATM) networks. ISDN access guarantees certain bandwidth (depending on a particular national standard) to the subscriber. Broadband ISDN (B-ISDN) access, in addition, specifies parameters that are needed by the ATM network. At this very moment, the mechanisms are being developed to back up B-ISDN by Intelligent Network, which could ensure policy-based networkwide QoS enforcement. Overall, in today’s PSTN, the main QoS metric is, as mentioned before, the call blocking rate.

The Internet routing model, on the other hand, has traditionally avoided stressing any built-in mechanism for creation and maintenance of virtual circuits. In the Internet, QoS issues (which also define their respective metrics) include bandwidth availability, latency (that is, end-to-end delay) control, jitter (that is, delay variation) control, and packet loss. Historically, the IP networks have been supporting what is called the best effort (but no guarantees) of packet transmission. In this system, no differentiation among different types of traffic is made, and neither the sequence of packet arrivals nor the arrival itself is guaranteed.

Whatever the end-to-end QoS requirements may be, at the network layer the packets travel (similarly to those of us who take airplanes) from hub to hub (that is, from router to router). Each router queues newly arriving packets for retransmission over the link to the most suitable (according to the routing table) router or destination host. Until very recently, most routers used a first-come, first-served queuing discipline, which is fair to all packets and, for this very reason, cannot make some packets more equal than others.

Overall, for applications such as voice or video over IP, a new network layer model was clearly needed, and such models have been researched and implemented since the 1990s. Two new approaches proposed mechanisms that are now called fair queuing and weighted fair queuing . With fair queuing and weighted fair queuing, routers are no longer required to treat packets equally. The incoming traffic is separated into well-defined flows. (A TCP connection is an example of a flow, although it may be difficult to detect by a router—all TCP connections between the same pair of hosts is a more realistic example; a voice session is another one.)