QOS ARCHITECTURES: A DETAILED REVIEW
USMAN AHMAD
Department of Electrical and Computer Engineering Center For Advanced Studies In Engineering, Islamabad, Pakistan.
Scholar Teacher Research Alliance For Problem Solving (STRAPS), Bahawalpur, Pakistan.
E-mail: [email protected]
ABSTRACT
The ever increasing demand of internet usage has given rise to many issues like internet application management, bandwidth utilization, protocols mechanism management and, etc. But the Quality of Service (QoS) has become the hottest issue among these issues. Over the past several years, a considerable amount of research work has been done in the field of QoS support for distributed multimedia applications. Most of the work related to QoS support is done at the level of individual architectural layers and a less progress has been made to address the overall end-to-end support for multimedia traffic. A number of research groups proposed the development of QoS architectures across all layers. This paper presents a state of the art survey of QoS architectures. The approach followed is to present the QoS terminology and understanding the QoS regarding distributed multimedia systems. A number of QoS architectures that have been appeared in literature after 1990 from the computer communications and telecommunications are fully evaluated. A qualitative comparison of several QoS architectures is made in the end.
Keywords— Internet, Quality of Service, End-to-End support, Multimedia Traffic, QoS Architectures.
1. INTRODUCTION
In the last few years, the demand of multimedia traffic has increased to a great extent. General multimedia applications include video conferencing, distance learning, multiplayer gaming and etc. Such type of applications requires a large amount of data to be shared among a number of users that are dispersed over the whole globe. The increased amount of data in these applications gives birth to a source of reliable delivery mechanism that is called as Quality of Service (QoS) in internet terminology. Microsoft says that “the goal of QoS is to provide preferential delivery service for the applications that need it by ensuring sufficient bandwidth, controlling latency and jitter, and reducing data loss” [1]. Cisco says that QoS “refers to the capability of a network to provide better service
to selected network traffic over various
technologies, including Frame Relay,
Asynchronous Transfer Mode (ATM), Ethernet and 802.1 networks, SONET, and IP-routed networks that may use any or all of these underlying technologies” [2]. Dictionary.com says that QoS is “the performance properties of a network service, possibly including throughput, transit delay, and priority. Some protocols allow packets or streams to include QoS requirements” [3]. The definitions shown above describes that QoS has been examined from a technical aspect.
"Quality of service'' (QoS) is often heavy provision that is used to point to both the efficiency of a network corresponding to application requirements and the group of technologies that empowers a network to make performance guarantees. Quality of Service (QoS) is by far the most significant enforcement consideration. If the network QoS is not in function, IP voice or video conferencing calls will
be uncertain, incompatible, and much
unsatisfactory. So a QoS mechanism has a vital role in a distributed multimedia system [4-5].
applications occurs when architecture addresses QoS from an ISPs point of consideration.
Figure1. End-to-End QoS Scenario
The present situation of QoS provision in architectures can be described as [6]:
a. Incompleteness: The interfaces are not QoS configurable, and a small set of services is supplied for control and management of multimedia streams. b. Deficiency of a general architecture: It
is the need of current state of internet usage for multimedia applications that a general architecture must be put forward to guarantee QoS at each level of the system.
c. Deficiency of mechanisms: A major
work is required related to QoS mechanisms so that level of service might be projected.
Many research groups adopted a systems architectural approach to QoS provision for the discussion of above mentioned restrictions. The
section QoS architectures discusses those
frameworks [58-81]. In section 2 a number of QoS architectures are qualitatively evaluated that appeared in the literature. Finally a complete comparison is presented at the end of the paper. Features of all the architectures are discussed in section 4 and then conclusions are made in section 5.
2. QoS ARCHITECTURES
Although QoS is referred to end-to-end services or end-to-end applications, many researchers proposed different communication architectures that discuss the QoS as an element related to access points. This section evaluates a number of QoS architectures that have been appeared in literature.
2.1 XRM
A research group at Colombia University known as The COMET group worked on an Extended Integrated Reference Model (XRM) [14] as a modeling framework for control and management of multimedia telecommunication networks. The COMET group claims that the bases of
operability of multimedia computing and
networking devices are interchangeable i.e both classes of devices can be modeled as producers, consumers and processors of media. The overall goal that a set of devices places to attain in the network or end-system is the only distinction The XRM can be segmented into five different planes [60] as demonstrated in Figure 2.
The functions involving these planes can be described as,
• The function that settles in N-plane
(network management) and incorporates the OSI functional areas and system management is termed as Management Function.
• The function which remains in M-plane
(resource control), and C-plane
(connection management and control) is Traffic Control Function. The M-plane establishes call admission, admission
control, flow control, memory
management, process scheduling,
routing, call routing and cell scheduling in the end systems.
• The function positioned in U-plane (user
transport) designs the media protocols and entities for the transport of user information in both the network and the
end-systems, is called Information
Transport Function.
• The function residing in D-plane (data abstraction and management) is Telebase
that collectively expresses the
information, data abstractions existing in the network and end-systems. The Telebase performs data sharing among all planes of XRM.
The XRM is developed on theoretical work of guaranteeing QoS requirements in ATM networks and end-systems occupied with multimedia devices. Overall ideas for identifying the dimensions of network [73] and end-systems devices [64] have been matured. XRM identifies the capability scope of an ATM multiplexer with QoS guarantee as a schedulable region, at the network layer.
2.2 OMEGA
University of Pennsylvania has been working on an end-point architecture named as the OMEGA architecture [61]. OMEGA appeared as the result of an interdisciplinary research effort that is examining the relationship between application QoS requirements (which make stringent resource
demands) and the ability of local (the operating
system) and global resource management
(combining communication and remotely
managed resources) to satisfy these demands. The
OMEGA architecture assumes a network
subsystem which provides bounds on delay, errors and can meet bandwidth demands, and an operating system which is capable of providing run time QoS guarantees as illustrated in Figure 3. Resource reservation and management of end-to-end resources is the essence of OMEGA architecture. Communication is preceded by a call setup phase where application requirements, expressed in terms of QoS parameters, are negotiated, and guarantees are made at serveral logical levels, such as between applications and the network subsystem, applications and the operating system, network subsystem and operating system. This establishes customized connections and results in the allocation of
resources appropriate to meet application
requirements and operating system/ network capabilities. The University of Pennsylvania has also developed a QoS brokerage model [79] which incorporates QoS translation, and QoS negotiation and renegotiation to facilitate this resource management process (see [80] for full details on similar work on QoS negotiation protocol at University of Montreal).
Figure 3. OMEGA
2.3 Tenet Architecture
California (Berkley). This model includes a Real-Time Channel Administration Protocol (RCAP) [37] in addition to Real-Time Internet Protocol (RTIP), Continuous Media Transport Protocol (CMTP) [23]. The preceding supplies general communication formation resource reservation and signaling functions for the rest of the protocol family. RCAP compasses the network and transport layers for general resource reservation and flow arrangement CMTP is clearly formed for continuous media encouragement. It is a trivial protocol which operates on top of RTIP and accommodates sequenced and repeated transmission of continuous media patterns with QoS direction over throughput, delays and error bounds. The Tenet Group creates discrimination between deterministic and statistical assurances for hard real-time and continuous media flows [36], respectively. In the deterministic case, guarantees specify a hard limit on the execution of all cells within a spell. Statistical guarantees assures that no more than x% of packets would undergo a delay greater than defined or no more that x% of cells might be misplaced in a spell.
Figure 4. Tenet Architecture
2.4 Heidelberg QoS Model
A comprehensive QoS model that effectively provides the guarantee in the end systems, and network has been developed at IBM’s European Networking Centre in Heidelberg under the HeiProject [62]. As illustrated in Figure 5. , this
communications architecture includes a
continuous media transport system (HeiTS/TP) [28], which provides QoS mapping and media scaling [76]. Underlying the transport is an inter networking layer based on ST-II [32], which supports both guaranteed and statistical levels of service. The network also supports QoS-based routing and QoS filtering using a QoS finder algorithm. The key to provide end-to-end
guarantees is HeiRAT i.e resource administration
technique [62]. HeiRAT comprises a
comprehensive QoS management scheme which includes QoS negotiation, QoS calculation, admission control, QoS enforcement and resource scheduling. The HeiRAT operating system scheduling policy is a rate-monotonic scheme whereby the priority of a system thread performing protocol processing is proportional to the message rate requested.
Figure 5. Heidelberg QoS Model
The Heidelberg QoS model has been designed to support QoS adaptivity via flow filtering and
media scaling techniques and to handle
heterogeneous QoS demands from individual receivers in a multicast group. The fundamentals, to meet heterogeneous QoS demands, are flow filtering and resource sharing in the network and media scaling and codec translation at the end systems. Media scaling matches the source with the receivers’ QoS capability by manipulating flows at the network edges. In contrast, filtering accommodates the receiver’s QoS capability by manipulating flows at the core of the network as flows traverse bridges, switches and routers.
2.5 QoS-A
differentiates the origination, circulation and ultimate utilization of a single media stream as an unified action influenced by a single account of QoS. Flows are always simplex but can be either unicast or multicast. The perception of the flow theory solicits effective QoS management and firm consolidation between device management, end-system thread scheduling, communications protocols and networks.
If we technically talk about QoS-A, it involves multiple layers as illustrated in Figure 6.
• The topmost layer comprises of a shared
applications platform substantially
enhanced with services to cater
multimedia communications and QoS
condition in an object-based
circumstances [10].
• The platform level below the topmost
layer is an orchestration layer which
brings jitter improvement and
multimedia synchronization checks
across multiple associated application flows [30].
• Sustaining this is a transport layer which involves a variety of QoS configurable services and techniques [20].
• Under this, an inter networking layer and
lower layers form the core for end-to-end QoS guarantee.
Figure 6. QoS-A
The realization of QoS management is earned by the three vertical planes in QOS-A. The first plane is the protocol plane, which is prompted by the convention of separation and consists of distinct user and control sub-planes. Separate protocol profiles are used for the control and media components of flows because of the
different QoS requirements of control and data. A number of layer specific QoS managers are contained in the QoS maintenance plane. The responsibility of QoS managers includes excellent grained supervision and protection of their
corresponding protocol bodies. At the
orchestration layer [30], the QoS manager is concerned in the stringency of synchronization between several associated flows. In comparison the transport QoS manager is involved in intra-flow QoS such as bandwidth, loss, jitter and delay. QoS managers sustain the level of QoS in the operated flow by sharp grained resource regulating policies. The ultimate QoS-A plane applies to flow management, which is liable for flow formation, QoS mapping and QoS scaling.
2.6 Open System Interconnection QoS Framework
The OSI QoS Framework is one of the earliest
additions to the domain of QoS-driven
architecture [58] that focuses mainly on QoS support for OSI services. QoS terms and ideas are extensively characterized in OSI Framework, and it arranges a model which specifies entities of concern to QoS in open system standards. The QoS affiliated with objects, and their fundamental interactions is explained through the description of a set of QoS attributes. The prime OSI QoS framework concepts comprehend:
• QoS requirements, which are recognized
through QoS management and
conservation existences
• QoS characteristics, which are a
characterization of the principal norms of QoS that have to be administered.
• QoS categories, which evoke a
standpoint influencing a group of QoS requirements explicit to a precise circumstances such as time-critical communications.
• QoS management functions, which can
be integrated in diverse modes and exercised to several QoS peculiarities in order to cater QoS requirements.
urgency operations to govern the performance of the layer. The policy may contain details of safety, time dependent services and resource control. Preference and presentation of the applicable protocol existences to cater for the QoS goals is concluded by the QoS control function. A system management channel is used to permit system resources to be remotely administered The OSI interface is reinforced by the system's management controller that arranges a usual interface to check, supervise and handle end-systems. The system policy control function cooperates with each layer-specific policy control function to arrange an overall selection of QoS roles and services.
Figure 7. OSI QoS Framework
2.7 IntServ Architecture
A considerable addition to bring monitored QoS for multimedia functions over an integrated system is the work of the Integrated Services Group [48] in Internet Engineering Task Force (IETF). The group has argued an encompassing IntServ architecture [48] and a QoS framework [70] used to particularize the workability of internetwork system entities (known as elements) which cause multiple, dynamically selectable
QoS attainable to applications. Routers,
subnetworks and end-operating systems can be referred as elements and their behavior can be captured as a set of services. Each element supports the interface required by the service [48]. The following IntServ services are provided in addition to best effort:
(i) controlled delay, which tries to give different stages of delay which the application can select from;
(ii) predicated delay, which supplies a statistical delay bound analogous to Tenet Group’s statistical service [35] and the COMET Group’s guaranteed service [47]; and
(iii) guaranteed delay, which gives an absolute guaranteed delay limit.
In the IntServ architecture, flows are described by two requirements a traffic requirement that is a requirement of the traffic order which a flow awaits to show and a service request requirement that is a requirement of the QoS a flow desires from a service entity. The IntServ architecture that is constrained to the network but can be valid to end-systems is consisted of four parts [48]:
• a packet scheduler, which sends packets
streams utilizing a collection of
sequences and timers;
• a classifier, which portrays every
arriving packet into a series of QoS categorizes;
• an admission controller, which executes the admission control algorithm to decide whether a latest flow can be permitted or rejected; and
• a reservation setup protocol (e.g., RSVP
[34]), which is essential to produce and retain flow-specific stage in the routers along the path of the flow.
Figure 8. IntServ Architecture QM
2.8 End-System QoS Framework
The end-system QoS framework is designed to assure QoS in end-systems for networked multimedia applications. This framework is developed by Gopal and Purulkar [63] at Washington University. This architecture consists of four components as shown in Figure 9.
• QoS Specification
• QoS Mapping
• QoS Enforcement
• Protocol Implementation
QoS specification is above all the components and arranges ease to applications in the specification of flow requirements using a small number of criterions QoS mapping works assuming QoS specification and it extracts the resource requirement for each end-to end application spell. The system resources pondered in [63] incorporate the CPU, Memory and
Network. QoS enforcement is the third
component and is primarily involved in real time processing assurances for data transfer. A real time upcall (RTU) provision [72] has been advanced for organizing protocols. A rate monotonic policy [82] with deferred preemption is used to organize the RTUs. It gives the two advantages:
1. Reduced context switching overhead
2. Increased end-system scheduling
efficiency
The last component is the protocol
implementation model. Protocol code is
integrated as RTUs with features that are acquired from high level specifications by QoS mapping operations.
Figure 9. End-system QoS Framework
2.9 TINA QoS Architecture
An architecture that stipulates the QoS
characteristics of distributed networks within the frame of reference of the computer science
framework is the Telecommunications
Information Networking Architecture QoS
architecture (TINA) [76]. Engineering and calculative perspectives of distributed networks applications have been discussed in this architecture. Service Attributes define the
requests for QoS parameters. [85].TINA
architecture is illustrated in Figure 10. Distributed Processing Environment (DPE) handles the requests that are requested by elementary multimedia applications. Allocation of needed resources and maintenance of transparency of QoS provisions is governed by the resource
managers. The load of applications in
Figure 10. TINA architecture
2.10 MASI End-to-End Framework
A research team at Laboratoire MASI, Université Pierre et Marie Curie, worked on a project called the CESAME project, and matured an end-to-end framework that supplies QoS for multimedia applications. That model is nominated as MASI End-to-End model. The elementary goal of this architecture is end-to-end QoS. This model
functions over ATM based networks to
particularize and enforce the needed QoS demands ATM networks, host operating system and host communication subsystem are spanned by the end-to-end resource management in MASI architecture. The principal aims of this framework are:
i. effective mapping of Open Distributed Processing (ODP) QoS needs to define resource faculties
ii. sustaining the multimedia
synchronization of multiple Open
Distributed Processing flows [9] iii. Supplying the appropriate protocol for
these services [85]
Figure 11. MASI End-to-End architecture
2.11 UMTS QoS Architecture
A Universal Mobile Telecommunication System (UMTS) [86] has been developed under the 3rd Generation Partnership Project (3GPP) to support QoS within the services of wireless or mobile networks. The facility for the setup of QoS resources from one end to another is provided by bearer services in UMTS framework. UMTS framework provides different type of services for QoS management:
• End-to-End Service
• External Bearer Service
• UMTS Bearer Service
• TE/MT Local Bearer Service
• CN Bearer Service
• Radio Access Bearer Service
• Backbone Bearer Service
• Iu Bearer Service
• Radio Bearer Service
• Physical Bearer Service
• UTRA FDD/TDD Service [87]
Figure 12. UMTS QoS architecture
There are four different QoS traffic classes in UMTS framework [87]:
i. conversational class: used for voice
applications (VoIP, Video-telephone) to serve real time traffic
ii. interactive class: used for web browsing
iii. streaming class: used for streaming videos (Video downloading, News stream, Web radio) to serve real time traffic
iv. background class: used for email
applications and telemetry (Emails, Files, SMS) to serve best effort traffic
The transmission aspect is kept in mind while using UMTS to support end-to-end QoS.
2.12 DiffServ Architecture
IntServ does not provide the feature of scalability so to provide end-to-end scalable QoS Internet
Engineering Task Force defined another
architecture after IntServ that is called a DiffServ architecture. IntServ works on the model of signaled QoS in which the network is acquainted about the QoS requirements of the hosts by themselves, but the DiffServ architecture follows the model of provisioned-QoS in which network parameters are set up to provide service to different classes of traffic according to variable QoS needs. DiffServ categorizes the traffic into multiple classes termed as Class of Service (CoS) and the QoS elements are applied to those classes. In the IP header, an 8-bit Type of Service (ToS) field is added to aid packet categorization. The use of ToS has been implemented as a part of DiffServ architecture [83]. The ToS byte is segmented into 6-bit Differentiated Service Code Point (DSCP) field and a 2-bit spare field. DiffServ architecture is illustrated in Figure 13.
Figure 13. DiffServ architecture
A service type is formed by three parts:
i. Setting DSCP bits in the header
ii. Use of these bits to decide packet
advancing
iii. Adjusting the marked packets at network
boundaries.
Substantiality of the DiffServ is mapping the DSCP contained in IP header to a particular treatment or Per-hop-Behavior (PHB), at each node along its path. Multiple per-hop-behaviors are defined. As we can see that Assured Forwarding (AF) [84] provides the user the guarantee of the lowest throughput even in the phases of bottleneck.
There is no end-to-end signaling mechanism in DiffServ, and it works on the basis of a Service Level Agreement (SLA) between the provider and customer. Packets from the user are marked to specify the SLA and are managed properly. There are multiple components of a DiffServ network:
a. Packet classifiers b. Traffic profile
c. Traffic conditioner
DiffServ architecture can be summarized
according to its features as follows:
1. Single service level can map multiple flows
2. QoS guarantees are given to applications
3. No need to maintain the state information of each flow along the path.
3. OTHER QoS ARCHITECTURES
The Object Management Group (OMG)
developed a Common Object Request Broker Architecture (CORBA) [88] that uses an Object Request Broker (ORB) for QoS assurance.
Institute of Science and Technology of University of Manchester has developed the Quality of Service and Pricing Differentiation for IP Services project (QoSIP) that provides QoS for real-time applications and monitors the service innovation process and price [89].
A research group named as Distributed Systems Group (DSG) of Trinity College Dublin worked on Broadband Access Service Solution (BASS) that assures end-to-end QoS in IP using bandwidth reservation and admission control [90].
Ecklund et. al. presented, a
“Dynamically-Configured, Strategic QoS Management
Hierarchy for Distributed Multimedia Systems” [91].
In Switzerland, Martel GmbH worked on Creation and Deployment of End User Services in Premium IP Networks project (CADENUS) that separates network services from ISP services [92].
European Commission supported a project named as Traffic Engineering for Quality of Service in Internet (TEQUILA) and tried to achieve the end-to-end QoS guarantees [93].
Laboratoire d'Analyse et d'Architecture des Systemes du Centre National de la Recherche Scientifique (LAAS-CNRS) developed the Global
Communication Architecture and Protocols
(GCAP) to assure QoS for Multimedia Multipeer and Multi-network applications [94].
Cruvinel et. Al. discussed “Distributed Dynamic Quality of Service (DDQoS) architecture [95].
4. DISCUSSION
QoS specifications are considered while
evaluating the QoS architectures surveyed in Section II. A brief discussion is being presented here about each of the QoS architectures. The design base of XRM is the flow specification consisting of one QoS parameter that determines the bandwidth and class of traffic. In comparison, OMEGA, Tenet and QoS-A architectures are based on the concept of a flow specification of several parameters. According to XRM the management of complexity in the network and the end-systems can be easy if a small set of well known services is taken to serve the internet traffic. But OMEGA, Tenet and QoS-A
architectures believes that limitation of
parameters has no effect on network management. If we specifically talk about Heidelberg QoS model, it provides statistical services in addition to common multimedia QoS services. OSI architecture like all other architectures except IntServ believes in hard-state solutions i.e establishment of connection for QoS assurance. But IntServ argues about the soft-state solutions i.e there is no need to establish a connection for the guarantee of QoS and it follows the rule of
temporary establishment on which data
immediately flows and traverses. IntServ also provides predicted services. Different services are provided by each of the architecture. End-System architecture provides QoS for some classes and believes that all the applications come under those three categories that are discussed in Section II. TINA QoS architecture works on the basis of different service attributes and assures QoS using these attributes. MASI architecture assumes end-to-end QoS as its primary objective. UMTS architecture provides QoS using a type of
bearer services for different classes of
applications. Diffserv architecture manages the QoS according to the application needs and follows the model of provisioned-QoS. It also provides scalability feature and that’s the main reason it outweighs IntServ.
In this paper a number of QoS architectures have been evaluated on the basis of QoS elements and the key that is put forward is to design a QoS architecture that can guarantee the QoS in end-systems. A qualitative comparison is made after reviewing the QoS architectures that appeared in the literature of computer networks and communications. The area of QoS research is now mature in multimedia networking but still there is a need of a comprehensive QoS framework that can assure the QoS in end-to-end applications. A state of the art survey is presented in this paper that will surely contribute a good amount in this field.
REFERENCES
[1] Microsoft Windows Server TechCenter,
"What is QoS?," Microsoft Corporation, 2003.
Available:http://www.microsoft.com/techne t/prodtechnol/windowsserver2003/library/T
echRef/1c1f53a6-da9e-496f-be84-b91e2763dbeb.mspx.
[2] Cisco Systems Inc, Internetworking
Technologies Handbook. Indianapolis:
Cisco Press, 2003.
[3] Dictionary.com, "Quality of Service," Lexico Publishing Group, LLC, 1998. Available:
http://dictionary.reference.com/search?q=qu ality%20of%20 service.
[4] I. Bom et al., “Integrated dynamic QoS
control for multimedia applications” Int.
Symposium SYBEN 98 Broandband
Europen networks, Zurich, May 1998.
[5] A. Campbell and G. Carlson, “A QoS
adaptive transport system: design,
implementation and experience”, ACM Multimedia `96, pp. 117-127, Boston, 1996. [6] Hutchison, D., Coulson G., Campbell, A.,
and G. Blair , “Quality of Service Management in Distributed Systems”, M. Sloman ed., Network and Distributed Systems Management, Addison Wesley, Chapter 11, 1994.
[7] APM Ltd , “ANSAware 3.0 Implementation
Manual”, APM Ltd, Poseidon House, Castle Park, Cambridge CB3 0RD, UK, 1991.
[8] Open Software Foundation, ”Distributed
Computing Environment”, 11 Cambridge Center, Cambridge, MA 02142, USA, 1992.
[9] ODP, “Draft recommendations X.903:
basic reference model of open distributed processing”, ISO/IEC JTC1/SC21/WG7, International Standards Organization, 1992. [10] Coulson G., Blair G. S., Davies N. and
Williams N.” Extensions to ANSA for
Multimedia Computing”, Computer
Networks and ISDN Systems, 25(11), 305– 23, 1992.
[11] Nicolaou, C., “An Architecture for
Real-Time Multimedia Communication
Systems”, IEEE Journal on Selected Areas in Communications, Vol. 8, No. 3, April 1990.
[12] Hazard, L., Horn, F., and J. B. Stefani, “Towards the Integration of Real-Time and QoS Handling in ANSA”, CNET Report CNET.RC.ARCADE.01, June 1993.
[13] Guangxing, “An Model of Real-Time QoS
for ANSA” , Technical Report
APM.1151.00.04, APM Ltd, Cambridge, UK, March 1994.
[14] Lazar, A. A., Bhonsle S., Lim, K.S., “A
Binding Architecture for Multimedia
Networks”, Proceedings of COST-237 Conference on Multimedia Transport and Teleservices, Vienna, Austria, 1994.
[15] Bulterman D. C. and van Liere R.,
“Multimedia Synchronisation and UNIX”, Proc. Second International Workshop on Network and Operating System Support for Digital Audio and Video, Heidelberg, Springer Verlag, 1991.
[16] Leslie, I.M., McAuely, D., and S.J.
Mullender, “Pegasus - Operating Systems
Support for Distributed Multimedia
Systems,” Operating Systems Review, Vol. 27, No. 1, 1993.
[17] Govindan, R., and D.P. Anderson,
“Scheduling and IPC Mechanisms for
Continuous Media”, Thirteenth ACM
Symposium on Operating Systems
Principles, Asilomar Conference Center, Pacific Grove, California, USA, SIGOPS, Vol 25, pp 68-80, 1991.
[18] Jeffay, K., “The Real-Time
Producer/Consumer Paradigm: A Paradigm for Construction of Efficient, Predictable
Real-Time Systems,” Proc. 1993
ACM/SIGAPP Symposium on Applied Computing, Indianapolis, IN, February 1993.
[19] Tokuda H. and T. Kitayama, ”Dynamic QoS
Network and Operating System Support for
Digital Audio and Video, Lancaster
University, Lancaster LA1 4YR, UK, 1993. [20] Coulson, G., Campbell, A and P. Robin,
“Design of a QoS Controlled ATM Based Communication System in Chorus”, IEEE
Journal of Selected Areas in
Communications (JSAC), Special Issue on
ATM LANs: Implementation and
Experiences with Emerging Technology, May 1995
[21] Jeffay, K and D. Bennett, “A Rate-Based Execution Abstraction For Multimedia
Computing,” Proc. Fifth International
Workshop on Network and Operating Systems Support for Digital Audio and Video,”, Durham, NH, April 1995.
[22] Danthine, A., Baguette Y., Leduc G., and L.
Leonard, “The OSI 95 Connection-Mode Transport Service - Enhanced QoS”,Proc. 4th IFIP Conference on High Performance Networking, University of Liege, Liege, Belgium, December 1992.
[23] Wolfinger, B. and M. Moran, “A
Continuous Media Data Transport Service and Protocol for Real-time Communication
in High Speed Networks”, Second
International Workshop on Network and Operating System Support for Digital Audio
and Video, IBM ENC, Heidelberg,
Germany, 1991.
[24] Feldmeier, D.,“A Framework of
Architectural Concepts for High Speed
Communication Systems”, Computer
Communication Research Group, Bellcore, Morristown, May 1993.
[25] W. Doeringer, D. Dykeman, M.
Kaiserswerth, B. Meister, H. Rudin, R. Williamson, “A Survey of Light-weight
Transport Protocols for High-speed
Networks”, IEEE Transactions on
Communications, November 1990.
[26] Chesson, G., “XTP/PE Overview”, Proc.
13th Conference on Local Computer
Networks, Pladisson Plaza Hotel,
Minneapolis, Minnesota, 1988.
[27] Clark, D.D., Lambert, M.L., and L. Zhang, “NETBLT: A High Throughput Transport
Protocol”, Computer Communications
Review, Vol. 17, No. 5, 1987.
[28] Hehmann, D.B., Herrtwich R.G., Schulz W.,
Schuett, T., and R. Steinmetz,
“Implementing HeiTS: Architecture and Implementation Strategy of the Heidelberg High Speed Transport System”, Second
International Workshop on Network and Operating System Support for Digital Audio
and Video, IBM ENC, Heidelberg,
Germany, 1991.
[29] Schulzrinne, H. and S. Casner, “RTP: A
Transport Protocol for Real-Time
Applications”, Work in Progress, Internet Draft, <draft-ietf-avt-rtp-05.ps>, 1995. [30] Campbell A., Coulson G., Garcia F. and
Hutchison D., “A Continuous Media Transport and Orchestration Service”, Proc.
ACM SIGCOMM ‘92, Baltimore,
Maryland, USA, 99–110, 1992.
[31] Keshav and Saran, “Semantics and
Implementation of a Native-Mode ATM Protocol Stack”, Bell Labs Technical Memorandum,
http://www.cs.att.com/csrc/keshav/papers.ht ml, 1994.
[32] Topolcic, C., “Experimental Internet Stream
Protocol, Version 2 (ST-II)”, Internet Request for Comments No. 1190 RFC1190, October 1990.
[33] Clark, D.D., Shenker S., and L. Zhang, “Supporting Real-Time Applications in an
Integrated Services Packet Network:
Architecture and Mechanism”, Proc. ACM SIGCOMM’92, pp. 14-26, Baltimore, USA, August, 1992.
[34] Zhang, L., et. al., “RSVP Functional
Specification”, Working Draft, draft-ietf-rsvp-spec-10.ps, 1996.
[35] Ferrari, D. and Verma D. C., “A Scheme for
Real-Time Channel Establishment in Wide-Area Networks”, IEEE JSAC, 8(3), 368–77, 1990.
[36] Ferrari, D., Ramaekers J. , and G. Ventre, “Client-Network Interactions in Quality of Service Communication Environments”, Proc. 4th IFIP Conference on High Performance Networking, University of Liege, Liege, Belgium, December 1992. [37] Benerjea, A. and B. Mah, “The Real-Time
Channel Administration Protocol”, Second International Workshop on Network and Operating System Support for Digital Audio and Video”, Heidelberg, November 1991.
[38] H. Zhang, S. Keshav, “Comparison of
Rate-Based Service Disciplines”, ACM
SIGCOMM, 1991.
[39] ATM Forum, ATM User-Network Interface
Specifications, Version 4.0, ATM Forum, 1996.
Scheduling Architecture for an Integrated Service Packet Network”, Working Draft
available via anonymous ftp from
parcftp.xerox.com:
/transient/service-model.ps.Z.
[41] Zitterbart, M., Stiller, B., and A Tantawy,“A Model for Flexible High-Performance Communication Subsystems”, IEEE JSAC, May 1992.
[42] Parekh, A. and R. G. Gallagher, “A
Generalised Processor Sharing Approach to
Flow Control in Integrated Service
Networks - The Multiple Node Case”, Proc. IEEE INFOCOM’93, pp.521-530, San Francisco, USA, April 1993.
[43] Golestani, S.J., “A Stop and Go Queueing Framework for Congestion Management”, Proc. ACM SIGCOMM’90, San Francisco, June 1990.
[44] Keshav, S., “On the Efficient
Implementation of Fair Queueing”,
Internetworking: Research and Experiences, Vol. 2, pp 157- 173, 1991.
[45] Guerin, R., Ahmadi, H., and M.
Naghshineh, ”Equivalent Capacity and its Application to Bandwidth Allocation in High Speed Networks” , IEEE Journal on Selected Areas in Communications, Vol. 9, No. 7, Sept. 1991.
[46] Cruz, R., “A Calculus for Network Delay: Part I: Network Elements in Isolation”, IEEE Transactions on Info. Theory, Vol. 37. No. 1, Jan. 1991.
[47] Hyman, J., Lazar, A., and G. Pacifici, “Real-Time Scheduling with Quality of Service Constraints”, IEEE Journal on Selected Areas in Communications, Vol. 9. No. 7, April 1990.
[48] Braden R., Clark, D., and S. Shenker,
“Integrated Services in the Internet
Architecture: an Overview”, Request for Comments, RFC-1633, 1994.
[49] Floyd, S., “Link-Sharing and Resource
Management Models for Packet Networks”, Draft available via anonymous ftp from ftp.ee.lbl.gov: link.ps.Z, September 1993. [50] Jain, R., “Congestion Control and Traffic
Management in ATM Networks: Recent Advances and a Survey”, Computer Networks and ISDN Systems (to appear), 1996.
[51] Dabbous, W. and C. Diot, “High
Performance Protocol Architectures”,
Technical Report, INRIA, Sophia Antipolis, France, 1995
[52] Turner, J. “ATM-Soft: A Mini-Proposal for
ATM Network Control Using Soft State”, Technical Note, Washington University, 1995.
[53] Little, T.D.C, and A. Ghafoor,
“Synchronisation Properties and Storage Models for Multimedia Objects”, IEEE
Journal on Selected Areas on
Communications, Vol. 8, No. 3, pp. 229-238, April 1990.
[54] Escobar, J., Deutsch, D. and C. Partridge, “Flow Synchronisation Protocol”, IEEE GLOBECOM’92, Orlando, Fl., December 1992.
[55] C. Liu, J. Layland, “Scheduling Algorithms for Multiprogramming in Hard Real Time Environment”, JACM, 1973.
[56] Stankovic et al., “Implications of Classical
Scheduling Results for Real-Time
Systems”, IEEE Computer, Special Issue on Scheduling and Real-Time Systems, June 1995.
[57] Kurose, J.F., “Open Issues and Challenges in Providing Quality of Service Guarantees in High Speed Networks”, ACM Computer Communications Review, Vol 23, No 1, pop 6-15, January 1993.
[58] ISO, “Quality of Service Framework”,
ISO/IEC JTC1/SC21/WG1 N9680,
International Standards Organization, UK, 1995.
[59] Campbell, A., Coulson, G., García, F.,
Hutchison, D., and H. Leopold, “Integrated
Quality of Service for
MultimediaCommunications”, Proc. IEEE INFOCOM’93, pp. 732-739, San Francisco, USA, April 1993.
[60] Lazar, A.A., “A Real-time Control,
Management, and Information Transport Architecture for Broadband Networks”, Proc. International Zurich Seminar on Digital Communications, pp. 281-295, 1992.
[61] Nahrstedt K. and J. Smith, “Design,
Implementation and Experiences of the
OMEGA End-Point Architecture”,
Technical Report (MS-CIS-95-22),
University of Pennsylvania, May 1995, (submitted to JSAC).
[63] Gopalakrishna, G., and G. Parulkar, “Efficient Quality of Service in Multimedia Computer Operating Systems”, Department
of computer science, Washington
University, Report WUCS-TM-94-04,
August 1994.
[64] Lazar, A. A., “Challenges in Multimedia Networking”, Proc. International Hi-Tech Forum, Osaka, Japan, February 1994.
[65] Campbell, A., Coulson, G. and D.
Hutchison, “A Quality of Service
Architecture”, ACM Computer
Communications Review, April 1994.
[66] OMG, (1993), “The Common Object
Request Broker: Architecture &
Specification”, Rev 1.3., December 1993.
[67] TINA-C, “The QoS Framework”, Internal
Technical Report,1995.
[68] Besse, L., Dairaine L., Fedaoui, L., Tawbi, W., and K. Thai, “Towards an Architecture for Distributed Multimedia Application Support”, Proc. International Conference on
Multimedia Computing and Systems,
Boston, May 1994.
[69] Sluman, C., “Quality of Service in
Distributed Systems”, BSI/IST21/-/1/5:33, British Standards Institution, UK, October 1991.
[70] Shenker, S., and J. Wroclawski, “Network Element Specification Template”, Internet Draft, June 1995.
[71] Slides from IETF meeting 31, Integrated
Service Working Group,
ftp://mercury.lcs.mit.edu/pub/intserv, 1995.
[72] Gopalakrishna, G., and G. Parulkar, “A
Real-time Upcall Facility for Protocol Processing with QoS Guarantees”, (Poster) 15th ACM Symposium on Operating Systems Principles, December. 1995. [73] Hyman, J., Lazar, A., and G. Pacifici, “Joint
Scheduling and Admission Control for ATS-based Switching Node”, Proc. ACM SIGCOMM ‘92, Baltimore, Maryland, USA, August 1992.
[74] Lazar, A. A., Ngoh, L.H. and A. Sahai, “Multimedia Networking Abstraction with Quality of Services Guarantees”, Proc. SPIE Conference on Multimedia Computing and Networking, San Jose, February 1995. [75] Ferrari, D., “The Tenet Experience and the
Design of Protocols for Integrated Services
Internetworks”, Multimedia Systems
Journal, 1996.
[76] Delgrossi, L., Halstrinck, C., Hehmann,
D.B., Herrtwich R.G., Krone, J., Sandvoss,
C., and C. Vogt, “Media Scaling for
Audiovisual Communication with the
Heidelberg Transport System”, Proc. ACM Multimedia ‘93, Anaheim, August 1993.
[77] Campbell, A., Coulson G. and D.
Hutchison, “Supporting Adaptive Flows in a
Quality of Service Architecture”,
Multimedia Systems Journal, 1996.
[78] Anderson, D.P., Herrtwich R.G., and C.
Schaefer. “SRP: A Resource Reservation
Protocol for Guaranteed Performance
Communication in the Internet”, Internal Report , University of California at Berkeley, 1991.
[79] Nahrstedt K. and J. Smith, “The QoS
Broker”, IEEE Multimedia, Spring 1995. [80] Vogel, A., G. v. Bochmann, R. Dssouli, J.
Gecsei, A. Hafid and B. Kerherve, “On QoS Negotiation in Distributed Multimedia Application”, Proc. Protocol for High Speed Networks, April 1994.
[81] Yeadon, N., Garcia, F., Campbell, A and D.
Hutchison, “QoS Adaptation and Flow Filtering in ATM Networks”, Second
International Workshop on Advanced
Teleservices and High Speed
Communication Architectures, Heidelberg, 1994.
[82] Stankovic et al., “Implications of Classical Scheduling Results for Real-Time
Systems”, IEEE Computer, Special Issue on Scheduling and Real Time Systems, June 1995.
[83] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “ An Architecture for Differentiated Services.” IETF draft, draft-ietf-diffserv-arch-01.txt, Aug. 1998.
[84] D. Clark and J. Wroclawski, “An Approach
to Service Allocation in the Internet.” Internet draft: draft-clark-diff-svcalloc- 00.txt, July 1997.
[85] T. Campbell, C. Aurrecoechea, and L.
Hauw, "A review of QoS Architectures," presented at Proceedings of the 4th International Workshop on Quality of Service, Paris, France, 1996.
[86] Nortel Networks, "Benefits of Quality of Service (QoS) in 3G Wireless Internet,"
1997. [Online]. Available:
http://www.3gweekly.net/html/whitepapers/ nt_qos.zip. [Accessed: Nov. 27, 2002]. [87] White Paper, "3G/UMTS Towards Mobile
Broadband and Personal Internet," UMTS
Forum, 2005. [Online]. Available:
http://www.umts-forum.org/servlet/dycon/ztumts/umts/Live/e n/umts/MultiMedia_PDFs_Papers_Towards -Mobile-Broadband-Oct05.pdf. [Accessed: Nov. 12, 2005].
[88] W. L. Bethea, "Adding Parametric
Polymorphism to the Common Object Request Broker Architecture (CORBA)," presented at Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA 2000, Minneapolis, Minnesota, United States, 2000.
[89] P. Arabas, M. Kamola, K. Malinowski, and
M. Malowidzki, "Pricing for IP Networks and Services," Information Knowledge System Management, vol. 3, pp. 153-171, 2002.
[90] T. Savage, R. Meier, and V. Cahill, "Near and far: Exploring the Use of Broadband Technology to Overcome Segregation
between Distance and Face-to-Face
Students," presented at Proceedings of the
2nd International Conference on
Technology in Teaching and Learning in Higher Education, Greece, 2001.
[91] D. J. Ecklund, V. Goebel, T. Plagemann, and E. F. Ecklund, "A Dynamically-Configured, Strategic QoS Management
Hierarchy for Distributed Multimedia
Systems," presented at Proceedings of the
2001 International Workshop on
Multimedia Middleware, Ottawa, Ontario, Canada, 2001.
[92] S. D. Antonio, M. Esposito, S. P. Romano, and G. Ventre, "Assessing the Scalability of
Component-Based Frameworks: The
CADENUS Case Study," SIGMETRICS Perform. Eval. Rev., vol. 32, pp. 34-43, 2004.
[93] TEQUILA Project, "Traffic Engineering for Quality of Service in the Internet, at Large Scale," IST TEQUILA, 2004. [Online].
Available: http://www.ist-tequila.org/.
[Accessed: Nov. 5, 2005].
[94] M. Diaz, R. Canonico, L. Costa, S. Fdida, D. Hutchison, L. Mathy, A. Meissner, S. Owezarski, R. Vida, and L. C. Wolf, "GCAP: A New Multimedia Multicast
Architecture for QoS," presented at
Proceedings of the 6th international
Conference on Protocols for Multimedia Systems, PROMS 2001, Enschede, The Netherlands, 2001.
[95] Laercio Cruvinel, Teresa Vazão,
COMPARISON
A detailed and qualitative comparison is presented in this section. The QoS architectures are evaluated on the basis of different generalized elements in Table 1[85].
Table 1. Comparison of QoS Architectures
QoS Model
[Ref] QoS Provision QoS Control
QoS Management
QoS Mechanism
QoS Mapping
Admission Control
E-to-Ea
Coordination
Flow Scheduling
Flow Shaping
Flow Control
QoS Filtering
Flow
Synchronization Alerts
QoS Maintenance
XRM [14] e/n e/n (e) n (e) n NA n NA NA n NA
OMEGA
[61] e (n) e (n) e (n) e (n) e e NA NA e e r
Tenet [75] e/n n n n n (e) n NA e d e r s
Heidelberg
[62] (e) (n) e/n e/n e (n) (e) (n) n NA e d e r s
QoS-A [59] e/n e (n) e/n e (n) e (e) (e) n E e (a) d e/n r s
OSI [58] (e) (n) e/n e/n NA NA NA NA NA e/n e/n
IntServ [48] e/n NA e NA NA NA NA NA e/n e/n r
End-System
[63] e e NA e e NA NA NA NA e r
TINA [76] (e) (n) n NA NA NA NA (n) (n) NA
MASI [77] e (n) e (n) e e NA NA NA e e e
UMTS [86] e/n (e) e/n e NA e NA NA e e/n r (a)
DiffServ
[83] e/n e/n e (e) n (e) n (e) (n) NA NA e/n e/n r (a)
a. The expression “E2E coordination” points to the coordination of end-system and network resources for flows. This could be granted by a resource reservation protocol (e.g., RSVP [34]), connection setup protocol (e.g., RCAP [37]) or signaling protocol (e.g., UNI 4.0 [39]).
The terms used are as follows:
e/n “addressed in detail in the end- system/network”
NA “not addressed”
(e) (n) “mentioned only in the end- system/network”
r “QoS renegotiation addressed in detail”
s “QoS scaling addressed in detail”
d “QoS degradation addressed in detail”
