Integrated Services Architecture (Int-Serv)

An Overview of Int-Serv

IntServ was defined in IETF RFC 1633, which proposed the resource reservation protocol (RSVP) as a working protocol for signaling in the IntServ architecture. This protocol assumes that resources are reserved for every flow requiring QoS at every router hop in the path between receiver and transmitter using end-to-end signaling.

The IntServ model for IP QoS architecture defines three classes of service based on applications’delay requirements (from highest performance to lowest):

·         Guaranteed-service class - with bandwidth, bounded delay, and no-loss guarantees;

·         Controlled-load service class - approximating best-effort service in a lightly loaded network, which provides for a form of statistical delay service agreement (nominal delay) that will not be violated more often than in an unloaded network;

·         Best-effort service class - similar to that which the Internet currently offers, which is further partitioned into three categories:

·         interactive burst (e.g., Web),

·         interactive bulk (e.g., FTP) and

·         asynchronous (e.g., e-mail)

The main point is that the guaranteed service and controlled load classes are based on quantitative service requirements, and both require signaling and admission control in network nodes. These services can be provided either per-flow or per-flow-aggregate, depending on flow concentration at different points in the network. Although the IntServ architecture need not be tied to any particular signaling protocol, Resource Reservation Protocol (RSVP) described below, is often regarded as the signaling protocol in IntServ. Best-effort service, on the other hand, does not require signaling.

RSVP

Using a method similar to the switched virtual circuit (SVC) of asynchronous transfer mode (ATM) networks, IntServ uses RSVP between senders and receivers for per-flow signaling (Fig.5). RSVP messages traverse the network to request and reserve resources. Routers along the path, including core routers, must maintain soft states for RSVP flows. (A soft state is a temporary state governed by the periodic expiration of resource reservations, so that no explicit path tear down request is required. Soft states are refreshed by periodic RSVP messages.)

RSVP is a set-up protocol providing a receiver-based, guaranteed, end-to-end QoS pipe. A reserved pipe is created in the following manner: First, PATH messages flow from the sender downstream to discover the data path. An RESV message, originating from a receiver and traveling in the reverse direction of the PATH messages, attempts to set local Integrated Services standard (IntServ) reservation for the flow. Each node along the path may either admit or reject the reservation subject to capacity or policy admission controls.

Figure 5 - Classical operation of RSVP.

Advantages of IntServ

The major advantage of IntServ is that it provides service classes, which closely match the different application types described earlier and their requirements. For example, the guaranteed service class is particularly well suited to the support of critical, intolerant applications. On the other hand, critical, tolerant applications and some adaptive applications can generally be efficiently supported by controlled load services. Other adaptive and elastic applications are accommodated in the best-effort service class.

A major characteristic of IntServ is that it leaves the existing best-effort service class mostly unchanged (except for a further subdivision of the class), so it does not involve any change to existing applications. This is an important property since IntServ is then capable of providing this class of service as efficiently as the current Internet. IntServ also leaves the forwarding mechanism in the network unchanged. This allows for an incremental deployment of the architecture, while allowing end systems that have not been upgraded to support IntServ to be able to receive data from any IntServ class (with, of course, a possible loss of guarantee).

IntServ provides a very interesting set of service classes that, although maybe not ideal, represent an excellent approximation of the kind of services required in a global telecommunication platform since it does not discriminate against any applications.

Disadvantages of IntServ

Although IntServ is a straightforward QoS model, end-to-end service guarantees cannot be supported unless all nodes along the route support IntServ. This is obviously so because any best-effort node along any route can treat packets in such a way that the end-to-end service agreements are violated. In the case of end-end implementation of IntServ QoS model, it is recognized by the industry that the support of per-flow guarantees in the core of the Internet will pose severe scalability problems. Therefore, scalability is a key architectural concern for IntServ, since it requires end-to-end signaling and must maintain a per-flow soft state at every router along the path. Other concerns are, how to authorize and prioritize reservation requests, and what happens when signaling is not deployed end-to-end. Because of these issues, it is generally accepted that IntServ is a better candidate for enterprise networks (i.e., for access networks), where user flows can be managed at the desktop user level, than for large service provider backbones. A hybrid model (RSVP-DS) that uses RSVP at the edges and DiffServ in the backbone has been proposed and seems to be winning consensus as a backbone service architecture concept.

Finally, although the subclassing of best-effort service, although already a significant improvement on the flat best-effort service currently provided in the Internet, finer-grained subclassing of the best-effort service class may be desirable in a commercial network.