The Design of a Generic QoS Architecture for Open ... - CiteSeerX

24 downloads 122245 Views 389KB Size Report
we do not constrain the application of QoS to distributed multimedia systems, but also extend the ..... issued by clients calling methods in local stub objects. ... Figure 6 illustrates an audio/video conference application built upon the streaming ...
The Design of a Generic QoS Architecture for Open Systems Frank Siqueira Distributed Systems Group, Trinity College Dublin This design document presents the results obtained by the author during his PhD studies.

Introduction The usual best-effort nature of services provided by currently available computing systems is unsuitable for a series of novel applications which require more predictable behaviour. These applications range from embedded control systems to desktop multimedia applications, and have very specific service requirements according to the activity performed or to the tolerance of the user. The requirements of this kind of application are described through the specification of a desired level of quality of service, or ‘QoS’ for short. Applications that require a certain level of quality of service must specify their requirements in a comprehensible and accurate manner using QoS parameters. The values of these parameters reflect the requirement imposed by the user, and can be stored in pre-defined value sets or obtained by the application through direct interaction with the user. The achievement of the specified level of quality of service will be made possible through the reservation of the resources made available by the lower-level system that are necessary to provide the service with the requested level of quality. These resources could be network bandwidth, processing time, physical memory, or access to multimedia hardware, for example. Some novel operating systems and network protocols are incorporating mechanisms that allow tasks to retain resources for their exclusive use. These mechanisms are the key element that allows the provision of QoS guarantees. Middleware components, usually referred as ‘QoS architectures’, are responsible for providing mechanisms for specification of quality of service and reservation of resources. QoS architectures deal with lower-level issues, such as the translation of QoS parameters comprehensible at the user- or application-level into parameters accepted by the multiple reservation protocols that control the access to resources provided by the system. These issues, without the services provided by a QoS architecture, would have to be dealt with by the application. Research on QoS architectures is still in its first stages, and the available proposals only cover very specific application fields running on top of particular lower-level platforms. A more generic approach still remains to be proposed. In this design document we propose a generic architecture for specification and achievement of quality of service that provides appropriate support for different application fields requiring QoS enforcement. No strong assumptions are made about the characteristics of the lower-level system, allowing the deployment of the architecture on top of heterogeneous systems with different resource reservation capabilities. Furthermore, the architecture supports systems subject to constant changes in the availability of resources because of hardware reconfiguration and mobility. This is achieved through the use of resource adaptation techniques.

Background In this section we analyse the main issues related to quality of service requirements and specification, and the achievement of these requirements through resource reservation. We also describe the mapping between requirements and resources, and the translation of QoS parameters specified at different levels of abstraction. We show how mechanisms for achievement of quality of service can be encapsulated by a QoS architecture, making resource reservation and QoS mapping and translation transparent from the user’s point of view.

Quality of Service Despite the evolution of computer hardware, resources such as network bandwidth, processing time and memory are becoming scarce because of the complexity of novel applications involving multimedia and cooperative work. We are experiencing the proliferation of applications with different sets of requirements, ranging from real-time embedded control systems to multimedia applications running on desktop computers connected to the Internet. With the migration of realtime systems from specialised architectures to more ‘open’ environments, guaranteed services and limited response times with very low (or even null) error rates are required for allowing consistent real-time behaviour. On the other hand, multimedia applications such as multi-party conferencing, audio and video broadcast, and distributed cooperative applications are becoming common despite the existing limitations of bandwidth and processing power to perform tasks such as media compression and decompression. This class of application can tolerate some error but imposes limited response times and a specific throughput. The main problem faced by these applications is to guarantee that the desired activity will be performed while respecting all the imposed constraints. A myriad of resources may have to be provided by the system to allow that, ranging from local resources such as memory and CPU to network bandwidth and other remotely located resources. ‘Quality of Service’, or QoS for short, is the keyword used to represent the set of requirements imposed by a user (human being or software component) related to the performance to be achieved in the provision of services by an application. With the proliferation of applications subject to QoS requirements, this is becoming an important area of research, in which much progress still has to be made. Definitions QoS is defined by the ISO OSI/ODP group as ‘a set of qualities related to the collective behaviour of one or more objects’ [ISO OSI/ODP 95]. Other authors try to clarify this definition. For example, Vogel et al [Vogel 95] state that QoS ‘represents the set of quantitative and qualitative characteristics of a distributed multimedia system necessary to achieve the required functionality of an application’. In this work we adopt a very similar definition, with the main difference residing in the fact that we do not constrain the application of QoS to distributed multimedia systems, but also extend the application of QoS to any system with constraints related to response time, performance, and output quality. ISO, along with the concept of quality of service, defines a complete terminology for dealing with QoS. Their main fault is to sometimes consider the application of QoS only for the specification of communication services at network level. We will adopt their terminology slightly modified to encompass diverse application fields.

According to ISO, a QoS characteristic is ‘a quantifiable aspect of QoS’ such as bandwidth or memory usage. A QoS measure is defined as ‘one or more observed values relating to a QoS characteristic’ such as the measured value of bandwidth or memory being used by an application at an instant in time. A QoS information is any ‘information related to QoS’. QoS information can be classified as a QoS requirement, when expressing ‘a requirement to manage one ore more QoS characteristics’, or as QoS data, if the information is a measured value, a warning, or any QoS information used by the system in an enquiry. QoS information is further classified as QoS parameters, when exchanged between entities, or QoS context, when retained in an entity. A QoS operating target is ‘QoS information that represents the target values of a set of QoS characteristics, derived from QoS requirements’, such as the necessary value of bandwidth to be provided to an application to allow it reach its requirements. ‘A group of user requirements that leads to the selection of a set of QoS requirements’ is called a QoS category. One example of QoS category is a user requirement such as ‘HDTV quality’ for a video session, leading to the selection of QoS requirements for bandwidth, error, and so on. QoS mechanisms are responsible for the establishment, maintenance, enquiry and management of QoS. QoS establishment creates the conditions to attain the desired set of QoS characteristics for an activity before it occurs; QoS maintenance keeps the set of QoS characteristics at the desired values while the activity is in progress; and QoS enquiry consists in ‘the use of QoS mechanisms to determine properties of the environment related to QoS’. QoS management is a set of activities performed by the system to support QoS monitoring, control and administration. QoS monitoring is the use of QoS measures to estimate the values of QoS characteristics, while QoS control and administration (usually referred as ‘QoS control’ for short) is responsible for providing conditions so that a desired set of QoS characteristics is attained. QoS management functions allow a specific QoS requirement to be met. QoS alerts are messages issued when limits or thresholds are crossed. Finally, a QoS policy is defined as ‘a set of rules that determine the QoS characteristics and QoS management functions’ to be used by the system in a particular case. The concepts defined by ISO are widely accepted, but are commonly used inappropriately. QoS characteristics, parameters, data and information are commonly used as synonyms, while the study of QoS mechanisms is mainly focused on QoS establishment, with maintenance, enquiry and management often being relegated despite their important role for achievement of quality of service. QoS Specification The desired quality of service has to be conveyed to the QoS mechanisms in the form of QoS parameters. Parameters can be expressed in very different formats, varying according to the application field, the corresponding abstraction level, or even personal taste. QoS mechanisms are likely to be flexible enough to accept different formats of QoS parameters and interpret them correctly. For example, a QoS parameter such as ‘frequency range’ for an audio application would be completely meaningless for an application based on data transfer. The same could be said about a parameter such as ‘window size’, useful for video but unintelligible for audio.

Two main abstraction levels can be identified in systems subject to QoS specification: the application level and the system level. Parameters specified at different levels are related, but differ strongly in meaning. An application parameter is generally related to an idea present only at this level, for example the number of frames of video shown per second in a video broadcast application. At system level this corresponds to network bandwidth to transfer data, processing time to compress and decompress the information, memory, access to specialised hardware, etc. The application fields and the system components in which QoS mechanisms can be utilised vary enormously. Any attempt to define a common set of parameters for QoS specification to be employed by the user to specify its QoS requirements would constrain his expressiveness in a very damaging manner. Therefore, a balance must be achieved between the needs of different application fields regarding the manner QoS requirements are expressed and the generalisation necessary for the architecture to be deployed over heterogeneous platforms. We believe that our architecture reaches this balance through the adoption of a sophisticated mechanism for translation of QoS parameters that will be described further in this document. QoS Mapping and Translation QoS parameters have to be translated between different levels of abstraction to be meaningful for the mechanisms present at that level. Translation implies that a mapping exists between parameters at different levels. Mappings are not usually one-to-one between parameters, but may be one-to-many, many-to-one or many-to-many parameters. Although the mapping may be complex, the process of translation consists in simple arithmetic operations over a limited set of variables. In addition, mappings and translation mechanisms have to be bi-directional to be able to transfer QoS data from the bottom layers to the top ones, reporting QoS measures to the application using QoS parameters comprehensible at this level of abstraction. For the particular case in which several different application fields and lower-level components must be supported, the translation process has to deal with different sets of parameters appropriate for the environment in which it is inserted. Since the creation of direct (one-step) translators for N application fields deployed on top of M low-level components would need the definition of N * M translators, this solution seems to be unacceptable. To allow the support of diverse application fields and system components, a way to extend the mapping and the translation mechanisms must be provided. The addition of support for a new application field or low-level component should be as easy as possible. In other words, the addition of support for a new kind of application should not imply writing one translator for every component supported, and vice-versa.

Resource Reservation In order to achieve the desired system performance, QoS mechanisms have to guarantee the availability of the shared resources needed to perform the services requested by users. The concept of resource reservation provides the predictable system behaviour necessary for applications with quality of service (QoS) constraints. Aiming to provide more guaranteed availability of resources for applications, networks and operating systems are incorporating mechanisms for resource reservation. Reservation mechanisms have to keep track of the use of the limited set of resources provided by the system, and receive requests from new users interested in using these resources. New requests are subject to admission tests based on the usage of the resources and the guarantee levels that satisfy the user. Reservations are then accepted, if there are resources available, or rejected if not. The

problem of allocating limited resources becomes even more complex if we consider that current computational systems are basically heterogeneous, subject to mobility and constant reconfiguration, but still have to provide a dependable and accurate service in a limited response time. The concept of resource reservation, as well as quality of service, originated from work on communication networks and was subsequently extended to other components of computational systems. In the area of computer networks, we can mention the development of ATM [ATM standards] as a significant advance towards the provision of QoS-constrained communication services. Aiming to provide similar behaviour, but working at the logical network level, the IETF is proposing a new suite of protocols for the Internet [IETF standards]. The suite of protocols is based on IP version 6 (IPv6) in conjunction with a reservation protocol (RSVP) and a new transport protocol named RTP. At the operating system level, some work has been developed to extend operating systems to provide more predictable behaviour suitable for applications with QoS constraints. Microkernelbased operating systems, such as Chorus and Mach, have been extended to provide timeconstrained services. Other conventional commercial versions of UNIX are being adapted to provide a behaviour suitable for applications with QoS constraints, generally following the RTPOSIX standard [POSIX.2 standards]. Each of the existing reservation protocols has its own interface and its own set of parameters or reservation messages for the specification of the resources to be reserved for use by the application. The handling of differences between multiple reservation protocols by QoS mechanisms then becomes a complex task that has to be considered by systems targeted at heterogeneous platforms aiming to provide QoS constrained services. Resource Adaptation One of the new trends in the research in the area of resource reservation protocols is resource adaptation [Gecsel 97]. Some authors consider resource reservation as a strong guaranteed m ethod to deliver a specified quality of service to an application during its entire lifetime. Another school of thought proposes the development of adaptive applications to deal with the changes in resource availability during the provision of service. A third idea based on resource adaptation, which mixes both approaches mentioned previously, has been considered as a viable and necessary alternative to either. Several drawbacks appear in efforts to provide a guaranteed resource reservation services for the following reasons: •

the physical structure of the whole computer system may change due to hardware reconfiguration and computer mobility, and changes in the distribution of resources may become necessary;



monitoring services may detect that the QoS requested by an application is not being achieved with the resources that were allocated for it, and then decide to allocate new resources;



the system may reclaim resources that are not being utilised or that are necessary for more important activities.

On the other hand, adaptation is very limited for services with strong requirements, and does not solve the problems faced by this category of application when using the best-effort systems currently available. Resource reservation combined with adaptation entails a more relaxed approach for providing QoS to applications. According to this new approach, resources can be seen by applications as guaranteed during some time, but their availability can vary over long periods. Applications are responsible for estimating their initial resource requirements and for negotiating their reservation with resource providers. During run time the application has to be able to adapt its behaviour based on feedback received from the system. QoS mechanisms have to be aware of the possibility of resource adaptation, making it transparent to the application whenever possible. When the agreed QoS is not reachable with the resources available, the application has to be informed that the agreed QoS has to be renegotiated. Applications have to be ready to handle this kind of situation without severe disruptions in the service being provided to the user. More specifically, applications holding resources that are subject to changes in their availability because of resource adaptation have to be able to degrade gracefully when it occurs.

QoS Architectures QoS architectures are responsible for integrating QoS mechanisms in computational systems, and organising the resources provided by the system in a consistent manner with the intent of fulfilling the end-to-end requirements imposed by the user. To allow the utilisation of the features provided by networks and operating systems with reservation capabilities at user level, several QoS architectures have been defined in the literature. However, most of the QoS architectures proposed so far target only a specific configuration of processing and communication hardware. This tight dependency on a specific environment constrains their application in ‘real’ computer systems, where heterogeneity is always present. ATM-based systems combined with real-time operating systems are the most popular platforms for the development of QoS architectures, because of their suitability for the implementation of QoS mechanisms based on the reservation of system resources. Some architectures are also targeted at very specific application fields, with video conferencing being the one where the technology is more mature because of several research projects that explored this topic. If not well conducted, the attempt to fulfil the particular needs of highly diverse application fields and system components can easily constrain the usefulness of a QoS architecture. To avoid this problem, the adoption of a very flexible and extensible QoS architecture for provision of QoS mechanisms is envisaged by us as a main issue in this area of research. We consider that allowing easy extension of a general-purpose QoS architecture we would be able to fulfil the requirements of different application areas. The main requirements considered by us in the design of a new QoS architecture were: •

adequacy to open environments, in which different protocols and hardware coexist;



allow high expressiveness for users to specify QoS requirements;



ease of use, with interfaces independent of application field or lower-level system;



transparency of QoS and reservation mechanisms from the user's point of view; and



allow dynamic changes in the distribution of resources to be performed by the system without loss of service consistency at application level.

The fulfilment of these requirements represents an important challenge in the research and development of QoS architectures.

Proposal - The QoS Architecture This section describes the QoS architecture proposed in this document. The following identify the main architectural components and define their role in the provision of services subject to QoS requirements. The interfaces of the components of the architecture, the parameters handled internally by the architecture at different levels of abstraction, and the algorithms used by the architectural components are also described.

Description of the Proposed QoS Architecture The QoS architecture is composed of a QoS agent running on top of the several resource reservation protocols available in the target system. QoS applications use the services provided by the QoS agent to obtain the desired level of QoS. Figure 1 shows the main building blocks of the QoS architecture. The resources themselves are not represented in the figure because the manner in which they are structured varies significantly, and this would be impossible to represent.

QoS Application

QoS Agent

Resource Reservation System

Figure 1 - The QoS Architecture The major component of the architecture, the QoS Agent, is responsible for implementing the QoS mechanisms necessary for the provision of services with the quality requested by the user. This incorporates two main tasks: the translation of parameters between different levels of abstraction, and the interaction with the underlying reservation mechanisms provided by the resource reservation protocols present in the system. Because of the intrinsically open nature of the target environment, several component-specific reservation protocols may be available. The application interface of the QoS Agent is responsible for receiving lists of QoS parameters specified according to the notion of quality understood by the user. The QoS Agent interprets this information and employs the available reservation protocols to obtain the resources necessary for the provision of the service with the level of quality specified by the user. The QoS Agent is composed internally by a translation unit and multiple component-specific agents running over a reservation protocol stack responsible for administering the use of the corresponding component. Figure 2 shows the internal structure of the QoS Agent.

QoS Agent QoS Translation Unit Component Agent 1

Component Agent 2

Component Agent 3



Reservation Protocol Stack 1

Reservation Protocol Stack 2

Reservation Protocol Stack 3



Figure 2 - Internal Structure of the QoS Agent The translation unit contains QoS Filters and a QoS Translator. QoS Filters can be subdivided in application- and component-specific filters, one for each application field and system component, respectively. Application-specific filters get QoS parameters understood at userlevel, interpret them, and update the values of a pre-defined set of generic application-level QoS parameters. The set of application-level QoS parameters is translated into a set of generic system-level QoS parameters by the QoS translator. Finally, the generic system parameters are used by component-specific filters to define the value of component-level QoS parameters understood by the underlying reservation mechanisms. The component-specific agents get the values of QoS parameters determined by the translation unit and perform the reservation of the resources provided by the corres ponding component, using the associated reservation protocol. There are no severe assumptions related to the behaviour or the services provided by the underlying reservation protocols. Any particular characteristic regarding the way to perform resource reservations is masked by the corresponding component-specific agent, and any lack of functionality can be complemented or masked by an optional management layer placed between the corresponding agent and the reservation protocol itself. All the details about the internal components of the QoS Agent are represented in Figure 3. A common feature generally neglected by available reservation protocols and QoS architectures is the provision of support for dynamic reconfiguration of resources. Dynamic reconfiguration results in adjustments in the level of QoS provided by the system to the application. The QoS agent reports dynamic changes in QoS to the user as user-level QoS parameters. Consequently, the translation unit has to be able to provide an inverse path of translation, with a set of specialised component-level QoS parameters being translated into specialised user-level QoS parameters. When the underlying reservation mechanism does not provide dynamic reconfiguration of resources, it can be wrapped with an optional management layer that fulfils this requirement. The management layer is responsible for monitoring, controlling and administering the resources made available by the corresponding component, and for emitting QoS alerts when limits are reached and when a reconfiguration of the distribution of resources is necessary. The componentspecific agent catches eventual QoS alerts and makes the changes that occurred in the distribution of resources reflect in the upper layers, resulting in changes in the values of userlevel QoS parameters.

QoS Agent Sets of Specialised User-Level QoS Parameters App. Filter A

App. Filter B

App. Filter C



Generic Application-Level QoS Parameters QoS Translator Generic System-Level QoS Parameters Comp. Filter 1 Comp. Filter 2 Comp. Filter 3



Sets of Specialised Component-Level QoS Parameters Comp. Agent 1 Comp. Agent 2 Comp. Agent 3



Management Management Management Management Reservation Reservation Reservation Protocol 1 Protocol 2 Protocol 3

… …

Figure 3 - Detailed Structure of the QoS Agent The structure of the QoS Architecture is highly portable, reusable and extensible, because the particular needs of application fields, system components and reservation mechanisms are encapsulated by application and component filters, and component-specific reservation agents respectively. Changes at application or system level imply the replacement of filters and component-specific agents, or the plugging of new ones into the QoS Agent. Filters are simple and easy to implement because they deal with parameters described at the same level of abstraction, i.e., application filters translate user parameters specified at application level into generic application parameters, while system filters translate generic system parameters into specific ones. The translation between parameters related to different layers is executed by the QoS Translator provided by the architecture. This is possible only because of the definition of sets of generic parameters at application and system level. Despite the definition of these standard sets of parameters, the expressiveness of the user is not affected because of the adoption of application-specific filters that handle QoS parameters understood at user level.

Standard Interfaces The QoS Agent provides a very simple interface to the QoS Application. The messages exchanged between the QoS Agent and the application, and the internal messages between components of the QoS Agent, are represented in Figure 4. To request a service with a specific level of QoS to be provided by the environment, the application issues a QoSRequest message. This message carries an identifier that describes the nature of the service and a list of variables identifying the QoS parameters and setting their respective values. The identifier provided by the QoS Application will be used to select the application-specific QoS filter applied to translate the QoS parameters contained in the QoSRequest message.

QoS Application Application Object X

Application Object Y

QoSReport QoSRequest

QoS Agent TranslateQoSDownwards

Application Filter A

TranslateQoSDownwards

Application Filter B

TranslateQoSUpwards TranslateQoSUpwards TranslateQoSDownwards

QoS Translator TranslateQoSUpwards TranslateQoSDownwards TranslateQoSDownwards

Component Filter 1

Component Filter 2

TranslateQoSUpwards QoSRequest

TranslateQoSUpwards QoSRequest

Component Agent 1

Component Agent 2

Protocol-Specific Interface

Protocol-Specific Interface

Opt. Management Management Layer Layer

Opt. Management Management Layer Layer

Reservation Protocol 1

Reservation Protocol 2

Figure 4 - Interface of the QoS Agent and of its Internal Components The same format of message is accepted by the component-specific agents. The main difference is that at this time the identifier specified in the QoSRequest message matches the corresponding component at system level, and the parameters are those comprehensible at this level, obtained after the translation process performed by the translation unit. The translation elements - application- and component-specific QoS filters and the translator itself - accept two kinds of messages. The first one, TranslateQoSDownwards, carries QoS parameters meaningful for the upper layer that are to be translated into parameters useful in the lower layer. The other message, TranslateQoSUpwards, performs the reverse process of translation, from the lower to the upper layer. The application is notified about changes in the QoS provided by the system through QoSReport messages. This message is sent when one or more component-specific QoS agents receive a QoS alert from the reservation protocol, using its protocol-specific interface. This message is propagated upwards, translated into user-level QoS parameters by the translation unit, and delivered as a QoSReport message to the application. The application is then responsible for adapting the service to the new QoS provided by the system, allowing a graceful degradation of the service provided to the user.

QoS Parameters As described before, the QoS Architecture deals with four distinct classes of QoS parameters according to the associated abstraction level. Two of them are generic sets and are standardised by the architecture: the generic application-level QoS parameters and the generic system-level QoS parameters. The other two classes of parameters are defined according to the filters used to interpret them and translate them from/into generic parameters.

Scoped Names Parameters are described as pairs . To allow the easy identification of the corresponding abstraction level and consequently identify the translation process to which the parameter has to be submitted, we have adopted a scoped namespace. Parameters are scoped with the name of the corresponding abstraction level in which they are meaningful. The generic sets of QoS parameters are scoped with App:: and Sys:: for application- and systemlevel parameters respectively. System-level parameters are further subdivided into two sets: a set of QoS parameters scoped with Net:: related to the network, and another scoped with OpSys:: for parameters related to the QoS to be provided by the operating system. This is necessary to identify when the responsibility for the fulfilment of a requirement is shared by the network and the local system, is related to only one of them, or is applied equally to both. For example, a time bound at application time is usually shared, resulting in the addition of two bounds at network and operating system level. A bandwidth requirement is applicable only to the network, while a requirement of service guarantee is valid for both. A similar strategy is adopted for user- and component-specific parameters. For example, parameters for an MPEG rendering application could be scoped with Mpeg::, subsequently translated into generic application parameters scoped with App::, then into system parameters scoped with Sys::, and finally into component-specific parameters scoped with Rsvp:: (for resource reservation protocol) and Posix:: (for posix-compliant operating systems). The user in general specifies parameters at his own abstraction level. In cases where he wants to specify the QoS to be provided by the system at a lower level, parameters can be specified using the scoped names of the corresponding abstraction level. These parameters will be ignored by the first translation steps and then caught by the corresponding translation element. When a parameter is described without a scope, the architecture assumes that it corresponds to the current abstraction level. In addition to scopes, parameter names can also be suffixed with radicals such as Avg for average, and Min and Max for limit values. Generic Application-Level QoS Parameters The following table describes the generic application-level QoS parameters defined by the QoS Architecture and recognised by the translation unit of the QoS Agent. Parameter Name

Suffixes

Description

DataUnitSize

Avg, Min, Max

Size of data units processed by the application (in bytes)

DataUnitRate

Avg, Min, Max

Rate of data units processed by the application (in units/s)

EndToEndDelay Avg, Min, Max

Time between production and consumption of data (in s)

ErrorRatio

Avg, Max

Acceptable error (in %)

Guarantee



Levels of service guarantee (best-effort, deterministic, etc.)

Cost

Avg, Max

Financial cost (currency per unit or per second)

SecurityLevel



Security mechanism for data transfer (none, encrypted, etc.)

Table 1 - Generic Application-Level QoS Parameters

Generic System-Level QoS Parameters System-level parameters are subdivided into two groups: network and operating system parameters. Some of them are originated from the division of tasks between the network and the local system to provide a service, and others are only applicable to one of them. Table 2 lists and describes these parameters. Parameter Name Net::Bandwidth

Suffixes

Description

Avg, Min, Max Bandwidth provided by the network (in bytes/s)

Net::Delay and OpSys::Delay Avg, Min, Max

Transmission and processing delays (in s)

Net::ErrorRatio

Avg, Max

Acceptable transmission error (in %)

Net::Guarantee and OpSys::Guarantee



Levels of service guarantee provided (best-effort, unloaded, deterministic, etc.)

Net::Cost and OpSys::Cost

Avg, Max

Financial cost (currency per connection or time)

Net::SecurityLevel



Security mechanism (none, encrypted, etc.)

Table 2 - Generic System-Level QoS Parameters

Translation Rules There is a clear mapping between the two generic sets of QoS parameters defined previously. Table 3 describes the relationship between them. At Application Level

At System Level

App::DataUnitSize * App::DataUnitRate

Net::Bandwidth

App::EndToEndDelay

Net::Delay + OpSys::Delay

App::ErrorRatio

Net::ErrorRatio

App::Guarantee

Net::Guarantee = OpSys::Guarantee

App::Cost

Net::Cost + OpSys::Cost

App::SecurityLevel

Net::SecurityLevel

Table 3 - Relationship between Generic Parameters The division of cost and delay between network and local system is calculated by the QoS translator based on data kept in a Resource Information Base (RIB). This database stores information describing the state of the network and the local system in terms of load, cost, and any other data useful to obtain a balance in the usage of resources from the network and the operating system.

Use of the QoS Architecture on CORBA The proposed QoS Architecture can be incorporated into a CORBA-based environment and used in conjunction with a series of mechanisms provided by CORBA, resulting in a complete framework for the deployment of applications with QoS constraints. The main target of the framework defined in this section is the area of distributed multimedia applications. However, the QoS Architecture was designed to target all kinds of applications in open systems, and can be

used to handle QoS constraints in any other field of application running over a diversity of distributed platforms.

The Common Object Request Broker Architecture The Common Object Request Broker Architecture (CORBA) is a framework of standards and concepts for open systems proposed by the Object Management Group (OMG). In this architecture, methods of remote objects can be invoked transparently in a distributed and heterogeneous environment through an ORB (Object Request Broker). The CORBA specification [OMG 96] establishes the role of each ORB component in the environment and defines its interfaces. CORBA interfaces are specified as a layer masking differences between distinct lower-level systems. The components of the CORBA architecture conforming to the specifications defined by OMG are shown in Figure 5.

Client

IDL Stubs

Object Implementation

Dynamic Invocation Interface

ORB Interface

IDL Skeletons

Dynamic Skeletons

Object Adapter

ORB Core Figure 5 - The CORBA Architecture In the CORBA architecture, each object implementation has its interface (operations and parameters) specified in IDL (Interface Definition Language). Remote method invocations are issued by clients calling methods in local stub objects. These stubs are generated by the IDL compiler and have the same interface as the corresponding remote objects. Alternatively, the client can build the request using the Dynamic Invocation Interface (DII). The ORB Core transmits the request and transfers the control to the object implementation (i.e., the server) using an IDL skeleton and the corresponding object adapter. The object implementation is unaware of the kind of CORBA interface used by the client to issue the request. Dynamic skeletons allow servers to receive invocations on any object, even if this object was not defined at compile time. The dynamic skeleton interface (DSI) is usually adopted to build gateways. When the client and the object implementation are located in ORBs that use different protocols for remote communication, a communication protocol called IIOP (Internet Inter-ORB Protocol) is used to allow interoperability. The ORB offers some general-purpose services to CORBA objects through a well-defined interface. Object implementations can also use services provided by their corresponding object adapters. OMG specifies the interfaces of a general-purpose Basic Object Adapter (BOA) which covers the requisites of a wide range of object systems.

In addition to the CORBA specification, OMG have defined CORBAservices, a set of services useful in distributed systems, and CORBAfacilities, a set of services oriented towards end-user applications. CORBA together with its services and facilities compose OMG’s Object Management Architecture (OMA) [OMG 92]. Initially, the following major services were proposed by OMG in the CORBA Services Specification [OMG 95]: Naming, Life Cycle, Event, Transaction, Security, Time, Licensing, Properties, Relationship, Query, Persistency, Concurrence Control, and Externalisation Service. CORBAfacilities include Financial, Internationalisation, System Management, and Distributed Document Component Facility, among others. OMG is constantly incorporating new services and facilities to the architecture. Stream-Based Communication Mechanism. Despite its adequacy for transmission of besteffort data using the client-server invocation mechanism, CORBA does not have support for realtime data delivery. To fulfil this gap in the architecture, OMG is defining streaming mechanisms to be introduced at application level in the CORBA architecture [OMG 96b]. Figure 6 illustrates an audio/video conference application built upon the streaming mechanism defined by OMG.

Stream Control

Partner 1 Input Device 1

Partner 2

Output Device 2

Output Device 1

Input Device 2

O Stream Endpoint

R

Stream Endpoint

B

Figure 6 - The Stream-based Communication Mechanism The streaming mechanism defines a group of abstractions to deal with stream data in multimedia systems. The abstractions are called multimedia devices, stream endpoints, and stream control. Multimedia devices are software components that abstract multimedia hardware. A stream endpoint transfers stream data through the network, getting data from and delivering data to multimedia devices. Stream endpoints are composed by one or more unidirectional flows that carry media data. The data delivery is subject to QoS constraints described during the creation of the stream, i.e. during the binding of two or more multimedia devices. The stream control is a normal CORBA object accessible remotely through the client-server invocation scheme. It can be a remote object or can be located in the same address space as one of the multimedia devices. Modification of the QoS parameters associated with a stream (such as maximum delay and bandwidth), the control of the data flow (i.e., starting and stopping flows of data), and the addition and removal of new parties from a multi-party stream connection can be performed through the stream control object. A binding operation establishes a stream between two multimedia devices, defining the QoS parameters associated to the stream. Two binding semantics are allowed. The simple local

binding uses the multimedia device and returns a stream control object. Besides, in the third party binding mechanism, a stream control object can bind two remote multimedia devices and keep the control over the data flow. The Notification Service. The notification service [OMG 97] is an extension to the CORBA event service that aims to provide a more flexible and efficient way to allow the notification of events occurring in the system, including the definition of delivery constraints for certain events. This novel mechanism, together with the event service, can be employed to implement, at application-level, mechanisms to impose inter-stream synchronisation constraints.

Definition of the Distributed Multimedia Framework We have defined a framework for the provision of multimedia services over CORBA-compliant middleware. The framework relies on the streaming mechanism as the basis for media transfer between distributed objects over the network. For synchronisation of media we adopt the notification service, an extension to the CORBA event service that allows the specification of constraints on the latency of events propagated between objects. For provision of quality of service we incorporate the QoS architecture described previously, encapsulated in a ‘QoS Agent’ object. As a basis for the middleware software, we utilise operating systems and protocols with resource reservation capabilities, which provide limited response time to the services requested by the application. Figure 7 shows a distributed multimedia application for audio and video conference built upon the distributed multimedia framework described above. In addition to the similar application presented previously, this one provides to the user a service with media synchronisation and QoS.

Partner 1 Input Device 1

Stream Control

Output Device 2

Partner 2 Output Device 1

Input Device 2

O QoS Agent

Reservation Protocols

Stream Endpoint

R

Stream Endpoint

B

synchronisation events

Notification Service

synchronisation events

QoS Agent

Reservation Protocols

Figure 7 - The Distributed Multimedia Framework The QoS Architecture on CORBA transfers all the obligations related to QoS specification, translation and provision through resource reservation from the media devices and stream endpoints to the QoS agent. This makes the devices more portable and simplifies significantly the job of the programmer.

Role of the QoS Architecture in the Distributed Multimedia Framework The QoS Agent is contacted by multimedia devices and stream endpoints in order to specify the QoS constraints imposed on an activity performed by the application. For example, suppose that an application that provides audio and video conferencing is implemented using this framework as shown in Figure 7. The input and output devices will establish the quality of audio and video that they expect to have, according to interaction with the user or through parameters defined previously in a profile. The stream endpoint created linking the partners has knowledge about the quality of the communication service that has to be provided in order to achieve the QoS specified by the application. All this information is transferred to the QoS Agent, which performs the reservations of resources available in the system necessary to provide the service with the desired quality. In order to perform the corresponding reservation, the QoS Agent uses the system and the network reservation protocols. In addition, the QoS Agent monitors the quality of service provided by the system and the network, and initiates resource adaptation when necessary.

IDL Interfaces The IDL code below corresponds to the interfaces defined by the QoS Architecture. QoS parameters are specified using the QoS structure defined by the streams mechanism [Iona 97]. In addition, some exceptions defined in the same document are used to report failures related to QoS. // IDL for QoS Architecture on CORBA // Definitions of QoS structure and exceptions; taken from // "Control and Management of A/V Streams" (OMG Telecom/97-05-07) #include "PropertyService.idl" struct QoS { string QoSType; PropertyService::Properties QoSParams; }; exception notSupported {}; exception QoSRequestFailed { string reason; };

Besides, each element of the QoS Architecture has its interface described in IDL. The messages defined in Figure 4 for each component of the architecture are mapped as CORBA operations, and carry the necessary QoS information as parameters. In addition, each call can raise exceptions according to the failures that can occur during their processing. // Interface supported by the QoS Application interface QoSApplication { oneway QoSReport ( in QoS user_qos ) raises ( notSupported ); }; // Interface supported by the QoS Agent interface QoSAgent { void QoSRequest ( in QoS user_qos ) raises ( notSupported, QoSRequestFailed ); }; // Interface supported by the Component-Specific QoS Agents

interface ComponentAgent { void QoSRequest ( in QoS component_qos ) raises ( notSupported, QoSRequestFailed ); }; // Interface supported by the QoS Translation Elements, i.e., ... // QoS Translator and QoS Application- and Component-Specific Filters interface QoSTranslationElement { QoS lower_qos TranslateQoSDownwards ( in QoS upper_qos ) raises ( notSupported ); QoS upper_qos TranslateQoSUpwards ( in QoS lower_qos ) raises ( notSupported ); }; interface QoSTranslator: QoSTranslationElement {}; interface QoSApplicationFilter: QoSTranslationElement {}; interface QoSComponentFilter: QoSTranslationElement {};

Implementation In the near future we intend to build a functional prototype of the architecture in order to analyse its behaviour while supporting applications with QoS requirements. Our target platform consists initially of a network of PCs running Windows NT. Iona’s Orbix will be adopted as the CORBA middleware, added of our own implementation of the A/V streams mechanism running on top of the RSVP network protocol. Support for new platforms and network protocols might be added later.

Related Work The following sections present other QoS Architectures and frameworks for distributed multimedia applications present in the literature. At the end of the section, they are compared to the results of this research project in terms of their global functionality and their application in distributed systems.

QoS-A (MPG, Lancaster) The Distributed Multimedia Research Group at Lancaster University have developed a Quality of Service Architecture (QoS-A) [Campbell 94], which offers a framework for specifying and implementing the required performance properties of multimedia applications over highperformance ATM-based networks. QoS-A provides ‘system-wide’ quality of service, including end-systems, communications systems and networks, through the use of QoS mechanisms that span across all architectural layers. The architecture incorporates the following notions to an environment composed of machines interconnected by an ATM network: •

flow: single media streams that represent the production, transmission and consumption of media data;



service contract: agreement between users and service providers regarding the QoS level to be achieved; and



flow management: monitoring and maintenance of the contracted QoS levels.

QoS-A makes possible the provision of data flows with an associated level of quality of service through the tight integration between devices, end-system and network. A structure of layers and planes integrated with ATM provides a QoS-configurable communication mechanism, while thread scheduling algorithms based on QoS constraints provide the desired behaviour at system level. In addition, devices are built in a way to take advantage of both scheduling and communication with QoS capabilities. Three planes compose the architecture: •

the Protocol Plane is responsible for data transfer. It subdivided in a user plane, for transmission of media data, and a control plane, responsible for control data, because of the essentially different requirements of these distinct categories of data.



the QoS Maintenance Plane is responsible for monitoring and maintenance of the QoS levels specified by the user in service contracts accepted by the architecture. Based on the information monitored from the system, this layer configures the available resources aiming to provide the QoS levels agreed with the user.



the Flow Management Plane executes flow establishment procedures (including admission control and resource reservation), QoS renegotiation, QoS mapping and translation, and QoS adaptation.

The first two planes are subdivided in layers as follows: •

the distributed systems platform provides services for multimedia communication and QoS specification.



the orchestration layer is responsible for media synchronisation and jitter correction.



the transport layer provides a basic QoS-configurable communication service.



the lower layers - network, data link and physical layer - compose the basis for the communication service.

QoS-A is implemented over an enhanced Chorus micro-kernel and enhanced protocols for multimedia built on a local ATM network.

The Extended Reference Model and xbind (Comet, Univ. of Columbia) The Extended Reference Model (XRM) [Lazar 96] has been designed and implemented by the Comet group at University of Columbia. XRM models the communication architecture of networking and multimedia computing platforms using three components: the broadband network, the multimedia network, and the services and applications network. The broadband network is defined as the physical network. Upon this physical infrastructure, resides the multimedia network whose primary function is to provide support for services with end-to-end QoS guarantees. The user has contact only with the service abstractions provided by the services and application network level. The services visible at the multimedia network level are provided by xbind, a programming platform for creating, deploying and managing multimedia services. Functionally, it consists in a kernel that provides end-to-end QoS over broadband networks, including software components for implementing mechanisms for distributed network resource allocation, broadband signalling, real-time switch control, multimedia transport and device management.

An associated binding architecture presents the service provider with a set of open binding interfaces with multimedia and QoS capabilities. Additionally, the Binding Interface Base (BIB) allows an easy integration of control (connection establishment and resource allocation), network management and service management. The CORBA architecture was adopted as the lower level for implementing the ‘binding architecture, providing interoperation between multiple platforms’. The xbind kernel has been ported and tested on several operating systems and LAN switches.

QUANTA (Old Dominion University) The Quality of service Architecture for Native TCP/IP over ATM networks (QUANTA) [Dharanikota 96] consists in an architecture for provision of QoS control over communication services based on Internet protocols running over ATM. Basically, it allows that applications that need a network service with predictable performance define a region of operation in terms of user-level QoS parameters. Applications are characterised according to classes of service, such as the classes defined for ATM. Each class has a translator that converts parameters described for that class into generic network QoS parameters, such as throughput, delay, loss, etc. These generic parameters are then translated into end-system protocol-depend control parameters by a protocol-dependent translator. These parameters are used to configure the lower-level network service. QUANTA supports TCP/IP and UDP/IP over AAL5/ATM, and AAL5/ATM directly. The testbed consisted of Sun workstations with ATM cards connected to two Fore Systems ASX-100 switches, which allow a maximum bandwidth of 100 Mbps.

The OMEGA Architecture and the QoS Broker (Univ. of Pennsylvania) The OMEGA Architecture [Nahrstedt 95] is an endpoint architecture for provision of real-time guarantees in network multimedia systems. In order to provide guaranteed service, the research effort focus on local and global resource management in distributed systems. The QoS Broker [Nahrstedt 95b] is the main component of the OMEGA Architecture. It is basically a middleware component responsible for the negotiation of QoS levels to be delivered to the application by the underlying system. The requirements specified by the application are translated by the QoS Broker and result in the negotiation of resource allocations with the operating system and the network. Resource reservation is based on QoS parameters associated to the specific media device, and handled internally by the QoS Broker. A translator is employed to obtain lower-level QoS requirements from the application-level parameters specified by the user, adopting a fixed set of translation relations for each media type. The translation is bi-directional, allowing dynamic changes in resource reservations to be reported to the user as application-level QoS parameters. The obtained parameters result in the reservation of network and operation system resources, both local and remote. Consequently, the local QoS Broker aiming to perform reservations of remote resources, called the ‘buyer’, is responsible for interacting with other QoS Brokers located remotely, known as ‘sellers’ of resources. A ‘buyer/seller protocol’ is provided to be utilised in this situation. The QoS Broker employs orchestration services and relies on information stored in resource databases to achieve a balance among the resources taken from multimedia devices, operating systems and the network. The underlying operating system is assumed to have real-time capabilities, allowing that its temporal behaviour be predicted by the QoS Broker and used to

perform the orchestration of resources. In addition to the QoS Broker, the OMEGA Architecture embraces communication model composed by two protocols at distinct abstraction levels. In the application subsystem, a RealTime Application Protocol (RTAP) is responsible for tasks such as call management, device management, synchronisation, and media delivery; and in the transport subsystem, a Real-Time Network Protocol (RTNP) implements functions for connection management, error correction, rate control, and network access. These protocols provide guaranteed communication services over specified communication channels obtained by applications and configured by them through the QoS Broker. The OMEGA architecture and the QoS Broker were validated through two practical experiments [Nahrstedt 97]. In the first application, a robot interconnected to a dedicated ATM network was operated and monitored remotely by workstations running the AIX operating system with realtime extensions. In the second example, a video-on-demand application with lip synchronisation was implemented on a platform composed by SGI Indy machines running the IRIX operating system, interconnected by a 10Mbps Ethernet LAN.

Arcade Project (CNET - France Telecom Research Center) The Arcade project is being developed by CNET (France Telecom Research Center) and the Department of Informatics at the Ecole Nationale Superieure des Telecomunication (National Superior School of Telecommunication). Arcade is conceptually a platform for the support of distributed multimedia applications. The first results obtained by researcher working on this project are in the area of system-level QoS. A scheduling framework that automatically derives scheduling information from temporal QoS constraints was presented in [Demeure 96]. This framework allows the description of high-level temporal QoS constraints in the form of arithmetic equations using a language called QL (QoS Language). These equations are translated automatically into scheduling information used by a user-level scheduler. This scheduler works together with the operating system scheduler, doing their best effort to allow that applications meet their deadlines. In this framework, both schedulers follow the Earliest Deadline First (EDF) policy. Temporal QoS equations are translated into deadlines and used as parameters for the scheduling of system threads. An application is implemented as a multithreaded process with one or more objects, and each invocation of a method of an object creates or activates a thread. A library of lightweight user-level threads is used to implement the framework, allowing that switches between threads of the same application occur without interaction with the system kernel. Arcade is based on the Chorus kernel extended to support the EDF policy.

Comparison with our Approach QoS-A, XRM/xbind and QUANTA are basically network-oriented (and mostly ATM-oriented), i.e. they do not cover system-level QoS constraints. The matter of translation and mapping is very simplified because QoS is handled at network level only. On the other hand, translation and mapping have a special role in our architecture, which covers a wider range of QoS information specified at a higher level of abstraction. In addition, the tight integration of the architecture with the communication system that occurs in QoS-A and XRM/xbind, constrains the flexibility and limits the extensibility of the architecture. QUANTA adopts a translation mechanism similar to the one proposed by us, but there are many differences that can be observed. First, the introduction of two sets of generic QoS parameters

with a translator from one generic set into the other reduces the work done by QoS filters. Filters are simple to implement and can be added by the application programmer. On the other hand, QUANTA translators, equivalent to our filters, incur in more complex translation procedures. In addition, they are not accessible to the user, and the addition of new classes of applications or network protocols implies that changes have to be made to the architecture software. Researchers at Lancaster say that a single QoS manager such as the QoS Broker in the OMEGA architecture, ‘requires a huge amount of mapping and management knowledge to support largescale distributed applications, and that service management through a single entity is too centralised and severely inflexible’ [Waddington 97]. We don't incur this problem, because perapplication QoS Agents encapsulate only the support necessary for specification of QoS capabilities for the corresponding application field and interaction with the reservation protocols supported by the end-system. Flexibility and extensibility are guaranteed by the use of filters and component-specific QoS agents, instead of a monolithic structure such as adopted by the QoS Broker. Issues regarding resource reservation are handled by the corresponding protocol associated to the component that avails the resources, with the component-specific agent being responsible only for the interface with these protocols. Scalability is an intrinsic characteristic that incurs from the lightweight and distributed nature of the architecture. Arcade is an example of purely system-level QoS architecture based on a specific platform. We could simulate the same behaviour implementing and application-level QoS filter that interprets the QoS language used by Arcade and translates the temporal constraints expressed with this language into generic application-level QoS parameters used by our architecture, and with a component filter and agent that interact with the Chorus kernel. In addition, we have the possibility of establishing network QoS constraints. Finally, it is important to make clear that the QoS architecture described in this document is targeted at a wide range of network protocols and system platforms, a matter that is not considered by the other architectures for multimedia with QoS capabilities present in the literature so far.

Conclusion In this paper we have introduced a QoS architecture that deals with QoS constraints present in distributed applications such as multimedia tools and suites for cooperative work. The proposed QoS architecture makes the lower-level aspects of resource reservation transparent from the user's point of view, although allowing the necessary control through notification when resource adaptation occurs, handling it internally or notifying the user in the form of user-level parameters when changes in the QoS agreed previously are necessary. The design of the architecture allows its easy extension to support new classes of applications and heterogeneous operating systems and communication mechanisms in addition to the ones already supported. This extension occurs through the addition of QoS translation filters and component-specific QoS agents written by the application programmer. The QoS architecture was designed to allow its use in heterogeneous platforms, enabling its extension or integration into frameworks for the development of distributed computing applications with QoS requirements. In this document we have presented an example of use of the QoS architecture in a complete framework for the development of multimedia applications based on CORBA and networks and operating systems with resource reservation capabilities. This framework relies on the QoS agent to interact with the system and the network towards the provision of QoS-constrained services.

References [ATM standards]

ITU-T Recommendations for ATM and ATM Forum.

[Aurrecochea 95]

Cristina Aurrecoechea, Andrew Campbell and Linda Hauw “A Survey of Quality of Service Architectures”, Distributed Multimedia Research Group (MPG), University of Lancaster, Internal report number MPG-95-18.

[Campbell 94]

Andrew Campbell, Geoff Coulson and David Hutchison “A Quality of Service Architecture”, ACM Computer Communications Review, Volume 24, Number 2, 1994, pp. 6-27. MPG Internal report number MPG-94-08.

[Demeure 96]

Isabelle Demeure, Jocelyne Farhat, and F. Gasperoni “A Scheduling Framework for the Automatic Support of Temporal QoS Constraints”, Proceedings of the Fourth International Workshop on Quality of Service, Paris, March 1996.

[Dharanikota 96]

Sudheer Dharanikota, Kurt Maly “QUANTA: Quality of Service Architecture for Native TCP/IP over ATM networks”, HPDC'96 Proceedings; also Old Dominion University Department of Computer Science Technical report #TR-96-01, February 1996.

[Gecsel 97]

Jan Gecsel "Adaptation in Distributed Multimedia Systems", IEEE Multimedia, Vol. 4, No. 2, April-June 1997.

[IETF standards]

IETF RFC 1883 (IPv6), RFC 1889 (RTP), and Draft of RSVP specification.

[Iona 97]

Iona Technologies, Lucent Technologies and Siemens-Nixdorf "Control and Management of Audio/Video Streams - OMG RFP Submission", OMG Document telecom/97-05-07.

[ISO OSI/ODP 95]

ISO/IEC JTC1/SC21 (OSI/ODP) "Information Technology - Quality of Service - Framework", DIS 13236 ICS 35.020, July 1995.

[Lazar 96]

Aurel A. Lazar, Koon-Seng Lim and Franco Marcocini "Realizing a Foundation for Programmability of ATM Networks with the Binding Architecture", IEEE Journal of Selected Areas in Communication, no. 7, pp. 1214-1227, September 1996.

[Nahrstedt 95]

Klara Nahrstedt, Jonathan M. Smith, "Design, Implementation and Experiences of the OMEGA Architecture", Report MS-CIS-95-22, University of Pennsylvania, May 1995.

[Nahrstedt 95b]

Klara Nahrstedt, Jonathan M. Smith "The QoS Broker", IEEE Multimedia, Spring 1995, Vol.2, No.1, pp. 53-67.

[Nahrstedt 97]

Klara Nahrstedt "Experiences with QoS Brokerage and Enforcement", Proceedings of the Second International Conference on Multimedia Information Systems (ICMIS97), Chicago, IL, April, 1997.

[OMG 96]

Object Management Group "The Common Object Request Broker: Architecture and Specification", Revision 2.0, OMG Document ptc/96-0304.

[OMG 97]

Object Management Group "Notification Service - Request for Proposal", OMG Document telecom/97-01-03.

[POSIX.2 standards]

ISO/IEC 9945-1 / IEEE 1003.1 / OSF POSIX.1 and ISO/IEC 9945-2 / IEEE 1003.2 / OSF POSIX.2 standards.

[Vogel 95]

Andreas Vogel, Brigitte Kerherve, Gregor von Bachmannn, and Jan Gecsei “Distributed Multimedia and QoS: A Survey", IEEE Multimedia, Vol. 2 No. 2, Summer 1995.

[Waddington 97]

Daniel Waddington, Christopher Edwards and David Hutchison "Resource Management for Distributed Multimedia Applications", Proceedings of the Second European Conference on Multimedia Applications, Services and Techniques, Milan, Italy, May 1997; MPG Internal report number MPG97-10.