An Application-oriented Cross-Domain Resource Management ...

An Application-oriented Cross-Domain Resource Management Schema using CORBA V. Tsaoussidis, H. Badr, G. Sazaklis

Department of Computer Science SUNY at Stony Brook [vassilis, badr, sazaklis]@cs.sunysb.edu 

Abstract { This work outlines a framework for application - oriented management of network resources, suggesting exchange of appropriate Application Management Information between management nodes in dierent domains, in order to better assist the application's task. When the application requirements cannot be satis ed within the local environment, Management Information is passed to the closest available resource of the same type. In our proposed approach, resources are represented as resource virtual machines which exhibit similar characteristics, change their state, and perform operations with respect to the availability of the resource, the user or task priority, and/or the user requirements. Attempting to balance the functionality overhead and the real-time constraints of decision making as to the appropriate resource to satisfy a request, resource virtual machines encapsulate the decision concerning the ability of the resource to satisfy speci c requests. The suggested model is based on distributed computing principles and proposes a hierarchical structure of specialized entities (inspectors) to assist information exchange among a variety of nodes or subnetworks. Finally, `Resource Inspectors' of the same type (controlling the same type of resource) constitute a logical communication backbone. We present the model's architecture, as well as the prototype implementation using the Common Object Request Broker Architecture. Keywords Application Management, Cross-domain Management, Quality of Service.

dynamic characteristics of resources provides sucient information for application management. Most management frameworks today have functionality to process such management information. However, quite often, application requirements exceed the availability of resources in the local environment; we suggest a model to eectively handle this situation. The request can be locally satis ed when its priority is high; else it can be satis ed by another logical network. This approach requires realtime management and dynamic decision-making capability. The real issue in such high-level functionality systems is to balance exibility and performance: complexity cannot transgress the boundaries of real-time management, while simplicity cannot fall short of the real goal by not having sucient functionality to assist the application's task. With the advent of dynamic management and the widespread use of distributed computing as a natural way of implementing network applications, static (monitor / control initiated by the network administrator) or local (management nodes do not exchange management information if they belong to dierent logical domains) management oers incomplete service to applications and hence, it is not an acceptable solution today. In addition, the resources states, their availability at any given time, as well as their capabilities are related to the Quality of Service requirements of a user or application. The question that needs to be addressed is the control of network resources in a manner that is appropriate for the application, distributes the system/resources load, and satis es Quality of Service requirements. An extended LAN is suitable to demonstrate the applicability of such systems, since quite often users can use resources at dierent domains. Certainly, such an approach should take into account the priority of the task, the properties of the user, and even the current load on the local environment. According to our approach, an application minimizes the eect of resources in an insuf cient state when its task is completed by other available resources of the same type. In parallel, the resources that

1 Introduction It is becoming clear that application management in networked environments is associated with eective management of network resources with respect to their static characteristics as well as the dynamic changes of their state. Management information consisting of static and  Proceedings

of the IEEE IWS '99

1

are found in an insucient state can be dynamically managed. In this paper we present an initial prototype of the proposed architecture using the Common Object Request Broker Architecture (CORBA)[9] and Services that enable interactions between the system's entities; we focus on the architecture and communication aspects rather than the appropriate algorithms associated with decision making. The ORB used for the prototype was The ACE ORB (TAO)[15].

2 Related work There is a signi cant amount of ongoing work trying to address these issues of application - oriented and dynamic management of network resources. Some recent studies present results of dynamic management using CORBA (e.g [13]). Others provide management rules for speci c protocols of the network or other layers (e.g. [1], [3]), present the general infrastructure for multimedia networking middlewares [8], or the architecture for SNMPbased frameworks [6]. These results are very signi cant and can be combined with the protocol presented here. The framework presented approaches higher-level functionality aspects and utilizes underlying protocols and mechanisms for dynamic management. There are several approaches to decision-making, taking into account the dynamic changes of the network, for the appropriate resource to achieve load balancing. These approaches' focus is mainly on CPU load balancing, utilizing speci c algorithms and checking the dynamic states at the time of the request, thereby resulting in signi cant delays; quite often such systems do not re ect the real state of the resource at the time of the decision. Some more general resource management systems, appropriate for multimedia networks, are often too complex to be applicable. Here, the resource management needs are not associated with the QoS requirements of the user. From the user's perspective, the central problem is not just limited to selecting an appropriate resource amongst all existing network resources, but, furthermore, crucially extends to ensuring that the selected resource is located in the user's own working environment where possible, or is otherwise geographically closest to that environment. A recent work at NEC C&C Research outlines the QoS requirements from the user's perspective [11] and suggests a framework to satisfy the user's requirements [12]. This work is moving towards the direction of application - oriented Resource Management, and its focus is on the mechanism and framework which enable QoS bene ts to be achieved from dierent layers of the network archi-

tecture appropriately managing the network resources. Along the same lines, but focusing on a quality assurance language or adaptation techniques of the application with respect to the resource (bandwidth) state, are [5] and [2] respectively. An application - oriented framework for resource management, and appropriate management interfaces to re ect QoS parameters, are presented in [17, 18, 19]. An interesting project, with a focus on the network management and control of resources from the Application Programmer's Interface perspective, is DIRM [4]: Dynamic Integrated Resource Management, at BBN. The results of this research are expected to assist applications to integrate resource reservations as well as multicast capabilities. CORBA interfaces are used to overcome the heterogeneity of system-speci c control mechanisms. A recent work is currently still in progress at Carnegie Mellon University(Darwin project). This project aims at designing and implementing a set of resource management mechanisms that support the deployment of customizable, value-added services in the network by using Service Brokers. Once a broker has identi ed the resources needed to satisfy a request, it uses a signaling protocol to allocate the resources [16]. This work is very interesting; however, a signi cant dierence is that its focus is on the functonality of the 'service brokers' while we additionally focus on the uniform operational interfaces, the widespread use of resources in accordance with a best eort service, and load balancing beyond the borders of a LAN. Our proposed management schema has several advantages:  Enables exchange of management information between dierent domains.  Supports QoS parameters.  Satis es user requests with minimal eort.  Has a distributed structure with high fault tolerance.  Is hierarchically organized and therefore resources from dierent nodes or subnetworks can be used.  Can be used compatibly with existing management systems and protocols.

3 Cross-Domain Resource Management Architecture It is quite often the case that certain requests ought to be satis ed by local resources. More precisely, when a resource cannot satisfy a request, it is traditionally the

user's choice to select the next appropriate resource (a printer or video camera row in a LAN is a suitable example to demonstrate this case). In such cases, a resource which is unable to satisfy the request should itself pass the request to another resource of the same type. Our framework's design is based on a simple idea: Resource Virtual Machines (RVM) represent the resource state and encapsulate the decision as to the availability of a resource, enabling real-time selection of the appropriate resource. The nal state of the virtual machine adjusts the current state of the resource in accordance with the default or user-de ned constraints and the management session chosen by the user. For example, a resource that is used by some process will be represented as available with respect to new incoming user requests, in the case where the user or default constraints are not violated. The action taken by the virtual machine can be, depending on the session and state: to pass the request to the next available resource of the same type; to satisfy the request; or to return an error. The mechanisms to monitor/control the resource, as well as the algorithms that are used to determine the availability of a resource, are hidden; the resource virtual machine encapsulates the result of this processing. Each management node is administered by Node Inspectors distributed in such a manner as to eectively handle geographical and logical constraints. For instance, a user might not have the same access privileges at all nodes of the network, and certain resources might normally be forbidden him except under well-de ned conditions of pressing need. Node Inspectors possess the functionality to satisfy user requests within their inspection area, according to the priority of the request and the contingent access priviliges granted an individual user.

3.1 The Resource Virtual Machines

Resources are managed by the Cross-Domain Resource Management Protocol(CDRM): Resource Inspectors, advised by constraints (default or user-de ned), update the virtual machine state accordingly. This state can be:  Available, when the resource is ready to accept a request.  Busy, when the resource has violated predescribed constraints.  Not Available, when the resource is out of service. The fact that network activity is summarized by three states does not really eliminate user exibility: busy simply means that the user constraint cannot be met. Thus, it might be the case that the resource is considered "available" and is in an available state although it already has other jobs or tasks to be performed.

APPLICATION session: only if QoS satisfied session: best effort session: static

Mgmt Node

Node Inspector

constraints

Node Inspector

RVM

RVM

Busy

Res. Inspector check constraint

Busy

RVM

Res. Inspector

RVM

RVM

Busy

Accept

Res. Inspector

Res. Inspector

Accept

Res. Inspector

Figure 1: Inter-Domain Resource Management Architecture The operation of the Resource Inspector is to perform the required action, or to pass the request to the next (or previous) Resource Inspector of the same type. Therefore, we can imagine the Resource Inspectors as a communication backbone at each management node. When the local resources are not capable of ful lling the request, a Node Inspector passes the request to another management node. The hierarchical approach assists the wide usage of resources; each Node Inspector manages its local management node; when there are not sucient resources, or there are not resources in the appropriate state to ful ll the requirements, Management Information is passed to the next Node Inspector. The routing algorithm which is used for the communication between nodes is simple: each knows the previous and the next. This ensures that if a Node Inspector is down, the round can be completed from the other direction. The same approach is followed for the Resource Inspectors: in case the request returns to the Node Inspector that has initiated the request, the inspector passes the request to the next (or previous) node.

3.2 CDRM Protocol outline

We have implemented a high-level protocol to enable communication between Resource Inspectors and User Applications. The application uses the protocol to request the level of service needed, while the Resource In-

spector replies back with a return code or other relevant information. While the resource state is a major factor that determines the nal outcome of a request, the user application is not normally interested in the state, but only in whether the request was granted or not. Because of the distributed nature of our system, the nal reply may be generated by some resource located in a dierent subnetwork, and subsequently propagate back. Depending on the nature of the request, the user may or may not desire to know the originating location of the reply. For example, if we print a le, it is essential to know which printer in the printer pool was used. On the other hand, when we store an incoming video stream in some distributed video archive, it is of little importance where in the archive it is being stored, so long as our QoS requirements (bandwidth, compression ratio, etc.) are satis ed. The messages in the current formulation of the protocol are of two kinds: (i) Service Requests and (ii) Return Codes. We assume three general situations that satisfy dierent kinds of user requirements. We examine each of these in turn:

Static Session Here the user constrains the system to

having the request satis ed by a particular resource administrator. This is the simplest session in which the request, depending on the state of the resource, may be granted immediately, be placed in the queue, or rejected (see the table below for the resource state diagram). The Service Request is a message originating from the user application (which takes the role of a client in this context), intended for a resource administrator (operating as a server) and requesting some type of service. It includes a service RequestId (to distinguish it from other requests), all the parameters necessary for the completion of the request, as well as a SessionId. The message format is quite simple: StaticReq := f RequestId SessionId Parameters g The Return Code for a Static Session is also simple: it informs the user application whether the request was completed successfully, appended to a waiting list, or rejected. Its format is: StaticReturn := f RequestId \ACK" [ACCEPTED, QUEUED, REJECTED] g

QoS Session When using this session, the user desires a certain level of service from the system but with no particular constraints as to the location or the

identity of the resource that will eventually serve the request. Each resource is accompanied by an entry in the Application Management Information Base (A-MIB), describing its capabilities and the level of service it provides ([17] details this mechanism). The SNMP protocol already implements a rudimentary version of a similar mechanism. Since the level of service for each resource is maintained locally and we wish to avoid a centralized architecture, the only way the system can grant a QoS request is by performing a search for a resource that oers appropriate service. Depending on the topology of the distributed resource management system and the knowledge that each resource administrator has about its neighbors, the search algorithm as well as the system as a whole will exhibit dierent performance characteristics (that is, message and time complexity). The Service Request format is similar to that of the Static session case; the only dierence being that the user who originated the request has to be known (and a return address be provided). We append the user identity to the information that already exists in the Service Request message de ned for the Static session. In our system we have chosen to use the pair fhost, portg to uniquely identify the user (at most one user may be attached to a given port at any time). Thus, the format is as follows: QoS-Req := fStaticReq [host] [port] g If the client submits the request without its identity, the Node Inspector can easily supply it, before it forwards the packet to the next resource on the list. The user information stays with the packet as it travels in the system, so that when it returns to the local resource administrator, the return address will be recognized and the return code delivered. The Return Code is similar to the Static Session case, with the addition of the host, port ID. Best Eort This session is the most demanding on the system. The user wishes to have the best possible results from the system. Again, since our system architecture is distributed, we have to perform a certain type of search. The basic operation is to locate the resource that maximizes a \bene t" function. Without global knowledge of the capabilities of dierent resources, and in the presence of a heterogeneous environment, resources have to be queried separately and asked about the service which could be provided for the request. It is noteworthy that the bene t function the user provides may dier from request to request, and

therefore tabulation is not appropriate. For example, for a printing job the bene t function might be a weighted sum of dierent factors, where speed is most important for a draft copy, but print quality (resolution, color etc.) increases in importance for the nal copies. The format for the Service Request message is based on the corresponding message for the QoS session, but is tagged with the current best value of the bene t function and the signature of the resource that can provide it. Each new resource that receives the message reviews the target function, and if its value is higher (i.e. it provides better service) it replaces the existing tag (including the resource signature) with its own. When the message returns to the original resource (this can be detected by the user id present), the best resource for this particular request has been detected and the job is carried out there. The format of the Service Request for this session is: BestEortReq := f QoS-Req Bene tFunction Max.Value WinnerResource g

The replies are of the same format as for the Qos session: they need the user id to use as a destination address. Session Static QoS Best Eort

Accept Run Constraints ok Run else Passby

Busy Queue

NA Reject

Passby Passby

interface Export { OfferId export (); };

Passby Passby

interface Import { void query(); }

Bene t value larger: tag with signature;

2nd round: if it is ours

Run

by the Object Management Group(OMG) [9, 10] is selected as the appropriate broker that can support our framework with sucient functionality. CORBA Object Request Brokers (ORBs) allow clients to invoke operations on target object implementations without concern for where the object resides, what language the object is written in, what OS/hardware platform it runs on, or what communication protocols and networks are used to interconnect distributed objects. For our prototype we have used the TAO ORB [14, 15] and the functionality of the Event, the Naming and the Trading services [9, 10, 15]. Naming, Trading and Event Services are combined to satisfy the model's functionality requirements. The Naming Service is used as a "glue" between the application, the Node Inspector and the Resource Inspector, so they can access each other by "name" instead of by object reference. At the heart of the system lies the Trading Service; it provides a matchmaking service for objects. Resource Inspectors, as Service Providers use the Trading Service to advertise their services. The Node Inspectors consult the Trading Service to obtain information about suitable services oered by Resource Inspectors, based on the type of service and speci c characteristics of each service, the resource capabilities, and user requirements; it then suggests the appropriate resource back to the user. This interaction is based on the standard interfaces of an intermediate entity the trader.The Resource Inspectors export their service oers, while Node Inspectors import the suitable ones.

4 Implementation: Interactions & Interfaces We implemented a preliminary version of the proposed interfaces using the TAO ORB[15]. Object-oriented techniques oer a variety of principles, methods, and tools that help to alleviate much of the complexity associated with developing distributed applications. The Common Object Request Broker Architecture(CORBA) de ned

Resource Inspectors are the Service Providers; they use the PropertySetDef interface of Property Service to describe oered services. For example, property Cost describes the cost of usage. Each Resource Inspector registers its service oer with the local trader, so each logical local network has one trader which knows all the resource services on it. This service oer de nes four properties, for example: Interface_Ref (reference to ResourceInspector); Interface_Type ("IDL:ResourceManager / ResourceInspector:1.0"); Resource_Name ("Postscript Printer"); Resource_Attr ("Speeding:1000f/s");

Resource Inspectors are aware of the speci c Service Type and also use the PropertySetDef interface to de ne the information that describes the services.

APPLICATION request response

NI

network domain

Resolve Consume

Naming Service

Import

Event Service

Trading Service Export

Bind

Supply

RI

RI RI

RI

RVM

printer

scanner camera

cdrom

NI: Node Inspector RI: Resource Inspector RVM: Resource Virtual Machine

Figure 2: CORBA Services in CDRM Architecture The Resource Inspector has an one-to-one relation with the resource, but the functionality corresponds to the kind of the resource. Therefore, for dierent kind of resources we de ne dierent operations; this is to be expected since control operations are resource speci c. For example, for printers, we de ne the print() operation; for backup services such as tapes, we de ne the backup() operation; and so on. Resource Inspectors use the Interface De nition Language (IDL) and Interface Repository Service to de ne their attributes and operations. We de ne the abstract interfaces of Resources, Resource Inspectors and Node Inspectors; using the TAO IDL compiler we generate object classes in C++. The attributes and operations de ned by the IDL language are maintained by the CORBA Interface Repository Service. interface ResourceInspector { struct Resource { string strRIHostName; short sResourceID; string strResourceName; short sResourceStatus; // 1 available; 2 busy; 3 unavailable; short sTime; }; ... }

The Node Inspector

uses the trading mechanism to discover the existing service oers. While the Resource Inspectors export their services, the Node Inspector is the service importer. Resource Inspector represents various resources that register in the Node Inspector's trader. The Import interface enables an importer to nd ServiceOers registered with this trader (and possibly other traders) that match the importer's particular requirements. by sending query requests to the trader to get the service object. Through Interface Repository Service the Node Inspector can get the attributes and operations of the services oered. The following script de nes the common Node Inspector object interface: interface NodeInspector { short requestNodeResourceInf (); short requestService (); ResourcesInf requestNodeInf (); ResourcesInf requestOneResourceInf (); long updateResourceInf (); long updateOneResourceInf (); void destroy (); oneway void shutdown (); };

When the application issues a request for service, the request goes to the local Node Inspector. The Node Inspector consults the local trader to locate the Resource Inspector with the desired resource service. The request will then be passed to this Resource Inspector who performs the required action. If the search fails, the Node Inspector will contact the other traders of the node either using the links between the traders, or through a straightforward operation by contacting other traders directly, in order to nd the next available Resource Inspector of the same type. If there is no such resource in the local node, the Node Inspector will contact the other Node Inspectors to nd all available Resource Inspectors. Therefore, we can imagine the Resource and Node Inspectors together as a communication backbone at each logical network. This hierarchical approach assists in the geographically widespread usage of resources. The application calls the operation requestService() to send a request to the Node Inspector. We use the Object Management Group (OMG) Constraint Language to express the query; therefore, the Node Inspector can search the service oers as shown below: lookup_->query ("RI", "exist Name",

"", policies.policy_seq (), desired_props, 8, offer_seq_out, offer_iterator_out, limits_applied_out, TAO_TRY_ENV);

4.1 Trader-based Cross-Domain Interactions

Depending on the size and/or distribution of the nodes, we can have several traders in the system. Such a solution might be appropriate for extended LANs; however, we have not yet evaluated dierent strategies in the context of various topologies. Although Service Users could individually query ServiceOers from many individual traders, it is more convenient to interact with a single trader that accesses other traders on their behalf. In a trader federation , traders act recursively as clients to other traders. In our architecture, the Node Inspector undertakes the role of gathering information from traders, depending on the user requirements. A trader federation is a set of traders with links between them. A link from T raderA to T raderB means that query operations performed at T raderA can propagate to T raderB , but not vice versa. A link is a trading service provided by another trader; that is, a link can be realized as a ServiceOer which describes a trader. The LinkManagement interface provides operations to add links to other traders and remove such links. The trader inherits the LinkManagement interface to manage its links to other traders.

4.2 Event-based State Reporting

We use the Event Service to implement a reporting mechanism initiated from the Resource Inspector and targeting the appropriate Node Inspector, in order to keep track of events that aect the decision as to the appropriate resource. Assume, for example, that resources using the event service send their "state info", summarized as busy, not available, or accept. An event should be generated each time a resource state changes. The Event Service provides a exible model for asynchronous communication among objects. The Resource Inspector will be able to monitor extraordinary events that are related to the object, and push these events to the Event Channel. Meanwhile, these events will be pushed to the Node Inspector by the Event Channel. The

CORBA Event Service is a real-time service which is responsible for accepting and delivering events [7, 15]. The event-based mechanism is presented in detail in [7]. Node Inspectors, Resource Inspectors and Resource Virtual Machines are processes running on dierent hosts connected to a network. The state of each resource is stored in a text le. The Resource Virtual Machine generates messages which correspond to this and publishes it through the Event Service. The Resource Virtual Machine registers itself with the Event Service as the publisher of a particular event. Henceforth, it can send events with this ID. Methods used for interacting with the Event Channel are: 1. void 2. void

push_consumer(EventSet&) subscribe_event(EventSet&)

In the Event Channel implementation, we have used the Push technology. Push follows the publisher - subscriber paradigm. This means, there are events being generated and there are processes which are interested in these events. The advantage of using push technology is twofold: First, if the resources are idle and no state change is taking place, the Event channel is very quiet and this causes no network utilization. This is because, no polling is involved and no periodic queries are made. Second, as soon as the state of the resource changes, a message is received by the Node Inspector. This, of course, depends upon the load on the Network and the real time guarantee oered by the ORB. Each of them can monitor a particular kind of resource. This is made possible by event ltering, which means, if a Node Inspector is not interested in listening to the events of a particular resource, it will not subscribe it and hence any event generated by that resource will not be delivered by the Event Service to this Node Inspector.

5 Conclusion and Future Work We have presented a cross - domain management schema to satisfy network applications with respect to the user priority, and the availability of resources. The architecture of the system presented allows cross-domain decisions facilitating the application's task, enabling quality of service requirements to be met, and resulting in load balancing for a variety of resource types beyond the boundaries of a logical network. The proposed schema can be used compatibly with new technologies which enable dynamic management as well as with existing protocols. CORBA to SNMP gateways

are presented in [13], and similar gateways to other resource management protocols are on the way (e.g. RSVP). When a resource is found in an inappropriate state, a gateway can be used from the inspector as a part of its action plan to manage the resource dynamically. This operation can be a process in the background while the user request is satis ed by another resource of the same type.

6 References [1] F. Baker, J. Krawczyk, A. Sastry, "RSVP Management Information Base" Internet-Draft, April 1998 ftp://ftp.ietf.org/internet-drafts/ draft-ietf-rsvp-mib-v2-00.txt

[2] S. Chatterjee, J. Sydir, B. Sabata, "Modeling Application for Adaptive QoS-based Resource Management", Procceding of the 2nd IEEE High Assurance Systems Engineering Workshop, August 1997 [3] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick, "A Framework for QoS-based Routing in the Internet", Internet-Draft, April 1998. ftp://ftp.ietf.org/internet-drafts/ draft-ietf-qosr-framework-04.txt

[4] DIRM: Distributed Integrated Resource Management, Technical Overview:

http://www.dist-systems.bbn.com/projects/DIRM

[5] P. Florissi,Y. Yemini, "Management of Application Quality of Service", Proceedings of the IFIP/IEEE International Workshop on Distributed Systems: Operations and Management,October 1994.

Broker: Architecture and Speci cation, Revision 2.0, MA, July 1996 http://www.omg.org/. [10] Object Management Group, "CORBA Services: Common Object Services Speci cation, Trading Object Service Speci cation v1.0", March 1997 [11] M. Ott, "What is wrong with QoS Research?", CCRL, NEC Internal Report,. 98-N-002, 1998 [12] M. Ott, G. Michelitsch, D. Reininger, G. Welling, "An Architecture for Adaptive QoS and its Application to Multimedia Systems Design, Computer Communications special issue on Guiding QoS into Distributed Systems, 1997 [13] S. Mazumdar, "Inter-Domain Management between CORBA and SNMP", Seventh IFIP/IEEE International Workshop on Distributed Systems: Operations and Management, Italy, October 1996. [14] D. Schmidt, "The Adaptive Communication Environment" June 1994 http://www.cs.wustl.edu/ schmidt/ACE-papers.html. [15] D. Schmidt, "TAO: a High-performance ORB Endsystem Architecture for Real-time CORBA" http://www.cs.wustl.edu/ schmidt/ACE-papers.html. [16] Peter Steenkiste, Allan Fisher, and Hui Zhang, "A Case for Customizable Resource Management in Networks", CMU technical report CMU-CS-98-167, October 1998.

[17] V. Tsaoussidis, A. Deka, "Resource Control of Dis[6] D. Harrington, R. Presun, B. Wijnen, RFC 2271 tributed Applications in Heterogeneous Environments", "An Architecture for describing SNMP Management Frame- Proceedings of the IEEE SECON '98, Florida, USA, April works", January 1998 1998 [7] S. Kaniyar, V. Tsaoussidis, H. Badr, "Real-Time [18] V. Tsaoussidis, K. Liu, "Application-oriented ManApplication Management based on CORBA Event Seragement in Distributed Environments", Proceedings of vice", Proceedings of the 17th IASTED Conference on the third IEEE Symposium on Computers and CommuApplied Informatics, AI'99, Innsbruck, Austria, Februnications (ISCC '98), Athens, Greece, June 1998. ary 1999. [19] V. Tsaoussidis, A. Deka, C. Comaniciu, C. Ku[8] S. McCanne, et al., "Towards a Common Infraslikowski, "Application-oriented System for Quality of Sertructure for Multimedia- Networking Middleware", Provice (ASQoS)", Proceedings of the IEEE International ceedings of 7th Intl. Workshop on Network and OperatConference on Networks '98 (SICON '98), Singapore, ing Systems for Digital Audio and Video (NOSSDAV'97), July 1998 May 1997. [9] Object Management Group, "The Object Request