Integrated Services | Quality of Service (QoS)

QoS is the subject of ongoing active research and more or less active standardization.

ITU-T has done much work in relation to B-ISDN, in which it effectively relied on the output of the ATM Forum. To this end, ITU-T Recommendations I.356 and I.610, respectively, specify performance measurement methods and QoS objectives for end-to-end connections and define operations and management tools to monitor the QoS parameters. In addition, the B-ISDN signaling specifies mechanisms for negotiating traffic parameters and QoS performance objectives.

Because of its connection-oriented, virtual-circuit approach to packet networking, it is more or less straightforward to deal with the QoS in the PSTN: The characteristics of the virtual circuit are what need to be negotiated among the participants of a session (and between each participant and the network). Given the inherently connectionless and stateless nature of the IP networks, guaranteeing end-to-end QoS is a much more complex matter. Consequently, standardization of relevant protocols is more complex, too. Virtually all QoS work that is related to routing (or, more precisely, forwarding) is performed in the IETF, and so, we concentrate on the IETF developments (some of which are explicitly addressed by the documents issued by other standards bodies).

TheretHERE are two basic approaches to IP QoS:

1.  Guaranteeing certain QoS on a per-flow basis.

2.  Guaranteeing QoS on a per-packet basis (as designated by the packet’s class of service).

The former approach is taken by the Integrated Services (intserv) and Resource Reservation Setup Protocol (rsvp) working groups, the latter by the Differentiated Services working group. In addition, the Multiprotocol Label Switching (mpls) working group is dealing with what effectively amounts to establishing virtual circuits for IP traffic, which makes it particularly suitable to interworking with the PSTN B-ISDN networks (such as ATM and Frame Relay networks). In the rest of this section, we address the respective standardization developments in that order.

Integrated Services (intserv)

The IETF Integrated Services (intserv) working group (www.ietf.org/html.charters/intserv-charter.html ) has been chartered with the development of an abstract packet-forwarding model. The applications of the model to particular Layer 2 protocols (such as ATM) have been, and continue to be, developed in the Integrated Services over Specific Link Layers (issll) working group (www.ietf.org/html.charters/issll-charter.html), which has produced ATM-related RFCs and works on the following link layer protocols: PPP, IEEE 802.2 LAN, and ISO High-Level Data Link Control (HDLC).

The earlier informational RFC 1633 specified the reference model for the network elements, which sets basic functions and terminology (see Figure 1). In this model, an arriving packet passes the:

§  Classifier. Maps the packet into a specific class (the class of the packet determines its treatment).

§  Packet scheduler. Manages the forwarding of different packet streams using a set of queues and possibly other mechanisms, like timers.

§  Output (first-in, first-out) queue.

Figure 1: Implementation reference model for routers.

Source: RFC 1633.

In the upper part of the figure, the routing agent supports a specific routing protocol and maintains the routing database. The reservation setup agent supports a specific resource reservation protocol; after approval by admission control, the traffic control database (which is shared with the classifier and packet scheduler) is modified to reflect the desired QoS. The management agent can modify this database, too, on behalf of the network management requests, in order to arrange controlled link sharing and to set admission control policies.

Following the template defined in informational RFC 2216, two types of services—the controlled-load service and guaranteed service—and their respective network element behavior types are defined in RFC 2211 and RFC 2212, respectively, as follows:

Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded.

Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queuing delays.

To the application processes subscribing to the controlled-load service, the network appears to be unloaded. In other words, the packet loss, if any, will approximate that typical to the transmission medium. As for the delay, it is supposed to be nearly constant, dependent again on the transmission medium delay and the processing time delay in devices along the path. The application process specifies the controlled-load service by providing the Token Bucket Specification (Tspec, defined in RFC 2215). The application process specifies the guaranteed-load service by the same token bucket specification (Tspec) as well as the Reservation Specification (Rspec). Rspec is a pair of numbers that, respectively, specify the data rate (ranging from 1 to 40 TB/s) and the slack term (ranging from 0 to 2³² - 1 ms). The slack term is used by any network element to reduce its reservation level (the updated slack term is then passed to the next network element in the chain). RFC 2211 and 2212, respectively, specify the actions of network elements for each of the two types of services.

One resource reservation protocol has been developed, in close cooperation with the intserv working group, by the Resource Reservation Protocol (rsvp) working group (www.ietf.org/html.charters/rsvp-charter.html) in the transport area of the IETF. The protocol is also called RSVP, and is published in RFC 2205.

RSVP is used by the application process at the receiving end of flows (that is, streams of data with the same QoS requirements, which are defined by the destination address related to a particular session) as well as by the network elements along the path among the hosts whose processes are involved in the session. (The protocol has been specifically designed for and used by the multicast sessions, which explains its major features—especially the reservation mechanism described in the following text.) Although choice of a transport layer is not essential to key function of the protocol, the transport layer ports specifically considered in the document are those of UDP and TCP.

The reservations are requested for simplex flows. That means that the protocol treats the receiver and sender as two independent entities (in a manner similar to the single-endedness principle of the IN). Only the receiver makes reservations. If there are two application processes talking to each other, two different and independent reservations will be made: one by the receiver in one process, and one by the receiver in the other.

Figure 2 demonstrates the place of RSVP in the integrated services architecture—in particular, to the interface between a host and a router. The host model is equivalent to that of the router, which underlines the principle that the QoS is defined at the edges by hosts with routers carrying out the requests. The data path (that is, the interface between the packet scheduler of the sender and classifier of the receiver) is clearly separated from that between the two RSVP processes, which explains why the “implementation of RSVP will typically execute in the background, not in the data forwarding path.” (For this reason, following telephony terminology, the Internet community often refers to RSVP messages as the out-of-band signaling, although the difference between in-band and out-of-band is much more subtle here than in the case of the PSTN.) We should clarify, however, that RSVP is not an admission-control or packet-scheduled application, and its role is to reserve rather than provide the resources.

Figure 2: RSVP in hosts and routers.

Source: RFC 2205.

An RSVP reservation request uses a flow descriptor, which consists of flowspec (which may, in turn, include the service class, Tspec, and Rspec) and filterspec. The flowspec describes the QoS and is used by the packet scheduler; the filterspec defines the set of packets (that is, the flow) for the given QoS and is used by the packet classifier. Two-reservation options with respect to the treatment of different senders in the same session are supported: (1) establishing a distinct reservation for each sender and (2) making a single reservation shared among all senders. Other two-reservation options with respect to the selection of senders and, thus, the existence and number of filter specs provide (1) the explicit list of senders (with one filter spec for each sender) and (2) the so-called wildcard that explicitly selects all senders (and so eliminates the need for the filterspec).

Following is a description of how RSVP works. The sender transmits the Path message specifying the QoS request. As this message traverses network elements, it is stored in the path state in each of them. The receiver sends back along the same path Resv messages specifying the QoS for the reservation requests. The messages affect a soft (i.e., temporary) state: As the Path messages are periodically retransmitted, so the Resv messages are repeated to maintain this soft state for the duration of the session. These two messages are defined as fundamental by the RSVP standard (RFC 2205), which was designed to identify (via Path messages) all endpoints of a multicast flow. (The Resv messages from separate receivers can be combined into a single request at those points in the network where a flow’s paths merge.) With these two messages, RSVP not only uses existing routing protocols to determine the path of the flow between source(s) and destination(s), but it also reacts to changes in the network topology. Retransmission of Path/Resv over a new path can be used to change a path of a reserved flow, while the absence of retransmissions can be detected by the routers so as to deallocate the QoS resources associated with a delinquent path.

Integrated Services Digital Network (ISDN)

The need for data communications services grew throughout the 1970s. These services were provided (mostly to the companies rather than individuals) by the X.25-based packet switched data networks (PSDNs). By the early 1980s it was clear to the industry that there was a market and technological feasibility for integrating data communications and voice in a single digital pipe and opening such pipes for businesses (as the means of PBX access) and households. The envisioned applications included video telephony, online directories, synchronization of a customer’s call with bringing the customer’s data to the computer screen of the answering agent, telemetrics (that is, monitoring devices—such as plant controls or smoke alarms—and automatic reporting of associated events via telephone calls), and a number of purely voice services. In addition, since the access was supposed to be digital, the voice channels could be used for data connections that would provide a much higher rate than had ever been possible with the analog line and modems.

The ISDN telephone (often called the ISDN terminal) is effectively a computer that runs a specialized application. The ISDN telephone always has a display; in some cases it even looks like a computer terminal, with a screen and keyboard in addition to the receiver and speaker. Several such terminals could be connected to the network terminator (NT) device, which can be placed in the home or office and which has a direct connection to the ISDN switch. Non-ISDN terminals (telephones) can also be connected to the ISDN via a terminal adapter. As far as the enterprise goes, a digital PBX connects to the NT1, and all other enterprise devices (including ISDN and non-ISDN terminals and enterprise data network gateways) terminate in the PBX.

These arrangements are depicted on the left side of Figure 1. The right side of the figure shows the partial structure of the PSTN, which does not seem different at this level from the pre-ISDN PSTN structure. This similarity is no surprise, since the PSTN had already gone digital prior to the introduction of the ISDN. In addition, bringing the ISDN to either the residential or enterprise market did not require much rewiring because the original twisted pair of copper wires could be used in about 70 percent of subscriber lines (Werbach, 1997). What has changed is that codecs moved at the ultimate point of the end-to-end architecture—to the ISDN terminals—and the local offices did need to change somewhat to support the ISDN access signaling standardized by ITU-T. Again, common channel signaling predated the ISDN, and its SS No. 7 version could easily perform all the functions needed for the intra-ISDN network signaling.

Figure 1: The ISDN architecture.

As for the digital pipe between the network and the user, it consists of channels of different capacities. Some of these channels are defined for carrying voice or data; others (actually, there is only one in this category) are used for out-of-band signaling. (There is no in-band signaling even between the user and the network with the ISDN.) The following channels have been standardized for user access:

• A. 4-kHz analog telephone channel.

• B. 64-kbps digital channel (for voice or data).

• C. 8- or 16-kbps digital channel (for data, to be used in combination with channel A).

• D. 16- or 64-kbps digital channel (for out-of-band signaling).

• H. 384-, 1536-, or 1920-kbps digital channel (which could be used for anything, except that it is not part of any standard combination of channels).

The major regional agreements support two combinations:

• Basic rate interface. Includes two B channels and one D channel of 16 kbps. (This combination is usually expressed as 2B+D.)

• Primary rate interface. Includes 23 B channels and 1 D channel of 64 kbps. (This combination is accordingly expressed as 23B+D, and it actually represents the primary rate in the United States and Japan. In Europe, it is 30B+D.)

The ISDN has been deployed throughout mostly for enterprise use. The residential market has never really picked up, although there has been a turnaround because of the demand for fast Internet access (it is possible to use the 2B+D combination as a single 144-kbps digital pipe) and because ISDN connections are becoming less expensive.

Even before the ISDN standardization was finished, the ISDN was renamed narrowband ISDN (N-ISDN), and work began on broadband ISDN (B-ISDN). B-ISDN will offer an end-to-end data rate of 155 Mbps, and it is based on the asynchronous transfer mode (ATM) technology. B-ISDN is to support services like video on demand—predicted to be a killer application; however, full deployment of B-ISDN means complete rewiring of houses and considerable change in the PSTN infrastructure.

Although the ISDN has recently enjoyed considerable growth owing to Internet access demand, its introduction has been slow. The United States until recently trailed Europe and Japan as far as deployment of the ISDN is concerned, particularly for consumers. This lag can in part be explained by the ever complex system of telephone tariffs, which seemed to benefit the development of the business use in the United States. Another explanation often brought up by industry analysts is leapfrogging: by the time Europe and Japan developed the infrastructure for total residential telephone service provision, the ISDN technology was available, while in the United States almost every household already had at least one telephone line long before the ISDN concept (not to mention ISDN equipment) existed

Carrier System : Integrated Services Digital Network (ISDN)

Integrated services digital network (ISDN) is a structured all digital telephone network system that was designed to replace (upgrade) existing analog telephone networks. The ISDN network supports for advanced telecommunications services and defined universal standard interfaces that are used in wireless and wired communications systems. There are two key user interfaces defined for ISDN networks: basic rate interface (BRI) and primary rate interface (PRI).

The basic rate interface (BRI) is the smallest transmission system (or interface) available through ISDN. BRI provides for two 64 kbps bearer channels (B channels) and a 16 kbps signaling (data) channel (D channel). This configuration is also is also referred to as 2B+D.

The primary rate interface (PRI) is a standard high-speed data communications interface that is used in the ISDN system. This interface provides a standard data rates for T1 1.544 Mbps and E1 2.048 Mbps. The interface can be divided into combinations of 384 kbps (H) channels, 64 kbps (B) channels and includes at least one 64 kbps (D) control channel.

Integrated Services Digital Network (ISDN)