Internet Services as a QoS framework in the Internet Architecture ... A short survey of IETF int-serv architecture framework ..... ISDN, LAN and MAN Standards.
Internet Services as a QoS framework in the Internet Architecture Janez Stergar, Bogomir Horvat Faculty of Electrical Engineering and Computer Science Institute of Electronics University of Maribor Smetanova 17, SI-2000 Maribor, Slovenia (janez.stergar, bogo.horvat)@uni-mb.si Abstract Over past several years there has been a considerable amount of research in the new field of Quality-ofServices (QoS) support for distributed multimedia systems. To date, most of the work has been within the context of individual architectural layers. Current research work is concentrated in overall endto-end support for multimedia communications and therefore in development of QoS architectures which incorporate QoS-configurable interfaces and QoS driven control and management mechanisms across all architectural layers [4, 7]. A short survey of IETF int-serv architecture framework for QoS in distributed multimedia systems will be presented and discussed. Also a short review of QoS support in the new generation IP protocol IPv6 will be presented.
1
Introduction
The increasing number of Internet hosts and routers and the demand for multimedia applications have led to new and revised protocols such as Internet Protocol version 6 (IPv6), Resource Reservation Protocol (RSVP), and Real Time Transfer Protocol (RTP). These form the foundation for new application-level protocols for the World Wide Web (WWW) such as the Hypertext Transfer Protocol (HTTP) and Real Time Streaming Protocol (RTSP). IP (IPv4 and Ipv6) alone provides best-effort service to the higher layers only. Many multimedia applications need more than this; the IETF thus defined new services to complement best-effort ones. These require reserving processing, memory, and bandwidth resources in end systems, routers, and networks. RSVP, a signaling protocol, exchanges resource reservation information among IP systems (routers and end systems). The transport protocols on top of IP−Transmission Control Protocol (TCP) and User Datagram Protocol−are not sufficient to run real time applications such as Internet
audio and video data transfer. They do not support synchronization within a single stream and between two or more streams. RTP and its associated Real-Time Control Protocol (RTCP), however, support real-time data transfer. IPv6, RSVP, and RTP also provides significant support for multimedia applications.
1.1
Quality of Services
Parameterization of services is defined in International Standard Organization (ISO) through the notion of QoS and is used in the OSI reference model [1, 2] to allow service users to communicate with network service regarding data transmission requirements. In ISO QoS specification the notion Quality of Services is defined as a concept for specifying the quality of the offered networking services. However the QoS specification is not limited only to the network layer. Meeting QoS guarantees in distributed multimedia systems is fundamentally an end-to-end issue, that is, from application to application (user-to-user) [6]. Hence we will discuss the characterization of QoS in a layered Multimedia Communication System (MCS). In such layered environment QoS can be characterized by a number of specific parameters where several important issues need to be considered with respect to QoS[3].
1.2
QoS architectures
Until recently, research providing QoS guarantees has primarily focused on network-oriented traffic models and service-scheduling disciplines. These guarantees are not, however, end-to-end in nature. Work on QoSdriven end-system architecture needs to be integrated with network configurable QoS services and protocols to meet application-to-application QoS requirements. In recognition of this, researches have recently proposed new communication architectures which are broader in scope and cover both network and end-system domains. This QoS architectures are:
Heidelberg QoS model (HeiProject of the IBM’s European Networking Center in Hei-delberg), XRM - Extended Integrated Reference Model (COMET group at Columbia University is developing the XRM), OMEGA (University of Pennsylvania), QoS-A Int-serv (IETF), OSI QoS framework, Tenet architecture (Tenet group at University of California, Berkeley) and TINA QoS framework, MASI end-to-end model (Laboratoiré MASI, Université Pierre et Marie Curie), End system QoS framework (Washington University).
In the next sections the IETF int-serv architecture framework for QoS implementation will be presented and discussed.
2
Int-serv architecture
The work by the Integrated Services (int-serv) Group of the internet Engineering Task Force (IETF) is a significant contribution to providing controlled QoS for multimedia applications over an integrated services network. The group has defined a comprehensive int-serv architecture and a QoS framework used to specify the functionality of internetwork systems elements (known as elements) which make multiple, dynamically selectable QoS available to applications. The behavior of elements, which constitute routers, subnetworks and end-point operating systems, is captured as a set of services, of which some or all are offered by each element. Each element is QoS-aware and supports interfaces required by the service definition [5, 6].
2.1
Integrated Services
The concatenation of service elements along an end-toend data path provides an overall statement of end-toend QoS. The following int-serv services are offered in addition to best effort:
controlled delay, which attempts to provide several levels of delay which the application can choose from, predictable delay, which provides a statistical delay bound similar to Tenets Group's statistical service and the COMET Group's guaranteed service and guaranteed delay, which provides an absolute guaranteed delay bound.
2.2
Int-serv architecture flows and components
Flows in int-serv architecture are characterized by two specifications:
a traffic specification, which is a specification of the traffic pattern which a traffic flow expects to exhibit, and a service request specification, which is a specification of the QoS a flow desires from a service element.
The int-serv architecture, which is restricted to the network but also applicable in the end-system, is comprised of four components: a packet scheduler, a classifier, an admission controller and a reservation setup protocol [5].
2.2.1
Packet scheduler
A packet scheduler forwards packets streams using a set of queues and timers. It has to be implemented at the point where packets are queued; this is the output driver level of a typical operating system and corresponds to the link layer protocol.
2.2.2
Classifier
A classifier maps each incoming packet into a set of QoS classes; all packets in the same class get the same treatment from the packet scheduler. Choice of a class may be based upon the contents of the existing packet header(s) and/or some additional classification number added to each packet.
2.2.3
Admission controller
An admission controller implements the admission control algorithm that the router or host uses to determine whether a new flow can be granted the requested QoS without impacting earlier guarantees. Admission control is invoked at each node to make local accept/reject decision, at the time a host requests a realtime service along some path through the Internet. In a few words, an admission controller determines whether a new flow can be admitted or denied.
2.2.4
Reservation setup protocol
The reservation setup protocol (e.g. RSVP), is necessary to create and maintain the flow-specific state in the endpoint hosts and routers along the path of the flow.
2.3
Quality of Services Manager
A part of the end-system int-serv architecture is the Quality of Service Manager (QM), which constitutes a user interface, service agents (SA) and dispatcher (Figure 1).
QM presents an abstract management layer designed to isolate applications from underlying details of the specific services provided by a QoS-driven Internet [6]. One motivating factor behind the introduction of a QM is that applications can negotiate desired QoS without needing to know the details of a specific network service described above. In this case, the QM provides a degree of transparency, whereby the applications express desired levels of QoS in application-oriented language rather than using communication QoS specifics. The QM is responsible for determining what QoS management capabilities are available on the application's communications path and chooses the path best suited to the application.
GLVSDWFKHU
573HWF 8'3
XVHULQWHUIDFH
DSSOLFDWLRQ
6$
6$
6$
,3
5693HWF
GDWDSDFNHWV
FRQWUROSDFNHWV
TXDOLW\PDQDJHPHQW LQWHUIDFH
Figure 1: int-serv QM.
3
Int-serv architecture implementation in next generation internet protocols
The IETF decision to develop a new IP version prompted proposals from several researchers. The IETF decided in 1994 to develop IPv6 based on the Simple Internet Plus proposal. Options and functions incorporated into IPv4 and not integrated in all IP implementations are now fully integrated in IPv6. New functions such as QoS and security support have been introduced to make the Internet even more attractive and to encourage the development of new applications. The new address format not only solves the address space problem but also supports automatic system configuration.
3.1
QoS support
QoS is supported by a priority value in the IP header and by flow labels identifying individual data streams (Figure 2).
Figure 2: Ethernet Packet Type 86DD. The priority field (Class field) allows a source to describe the required priority of its packets; priorities are always relative to a single source. Priority values are broken down into two independent areas. Values 0 to 7 are reserved for traffic types with integrated congestion control. Values 8 to 15 are used for traffic types without congestion control−for example, real-time data sent with a constant rate (Table 1) Value 8 should be used for packets where the sender can tolerate loss, since lower priority packets are discarded first in congestion situations. Flow labels identify packets that require special handling−for example, real-time data packets. The type of special handling can be communicated to the router explicitly with a signaling protocol such as RSVP or by information contained directly in the IPv6 packets, such as hop-by-hop options. This information may then be stored in an internal data structure called a flow state. Analyzing the TCP/UDP port numbers for identifying RSVP flows is imperative when integrating RSVP and IPv4, but IPv6 flow labels render this superfluous. This is particularly important when the IP payload and thus the port numbers are encrypted. Flow labels can also simplify packet processing. If a router receives a packet wit a unknown flow label, the router can initially perform the necessary processing steps and store the results (such as the outgoing network interface identifier or the next node's Medium Access Control (MAC) address) in the flow state. The calculated results can be reused for subsequent packets of the same flow. Not all IP packets will be assigned flow labels, however−the number of flows to be supported in routers would be to high. Future router or end-system architectures should not presume the existence of flow labels in all packets of a flow and must maintain performance even without them [4].
Table 1. Priorities for traffic types with congestion control. Priority Value
4
Traffic Type
0
Filter traffic (e-news)
1
Traffic not characterized in further detail
2
Data traffic without special treatment (e-mail)
3
Reserved
4
Data traffic with special treatment (ftp, NFS, http)
5
Reserved
6
Interactive traffic (telnet, X)
7
Control traffic (routing protocols, ICMP)
Discussion
With the exception of IETF int-serv architecture model (which uses RSVP maintained state) all in previous sections mentioned architectures advocate connectionoriented or 'hard-state' solutions to network level QoS provision; that is, hard state couples path establishment and resource reservation [4]. Work in the IETF on an integrated services architecture (using RSVP and IPv6 flows), as mentioned in Sect. 3, assumes that network-level QoS guarantees can be built using a 'soft-state' approach; that is, no explicit connection is established but flows traverse intermediate routers on paths that are temporarily established (i.e., network state is timed out and periodically refreshed). In this instance, path establishment and resource reservation are decoupled. It is argued that a soft-state approach provides better scalability, robustness, and eradicates the round-trip call setup time found in connection-oriented approaches.
References [1] W. Stallings. Networking Standards: A Guide to OSI, ISDN, LAN and MAN Standards. Addison-Wesley. 1993.
[2] ISO/IEC JTC1/SC21. Open Systems Interconnection, Data Management and Open Distributed Processing. Joint ISO/IEC & ITU-T Interim Meeting, Toronto. 1995.
[3] R. Steinmetz, K. Nahrstedt. Multimedia: Computing, Communications and Applications.Prantice Hall. 1995.
[4] IEEE Multimedia, Volume4, Number 3 [5] R. Braden, D. Clark, S. Shenker. Integrated Services in the Internet Architecture: an Overview. Request for Comments. RFC-1633.
[6] ACMPress, Multimedia Systems, Volume 6, Number 3, May, 1998
[7] J. Stergar. Quality of Services in Multimedia Communications, ERK 1998
