Efficient Network Management for Collaborative

Efficient Network Management for Collaborative Services and Application Development Kevin H. Liu ∗

Vassilios Th. Tsaoussidis

Dept. of Network Operations and Management Telcordia Technologies Inc. (formerly Bellcore) [email protected] Abstract - Collaborative services and applications are becoming increasingly important and complex and have requirements for real-time multimedia support, high bandwidth availability, and low delays. The collaborative application view of QoS encompasses transport network, end systems as well as computational requirements. Therefore, how to coordinate and integrate collaboration management and network resource sharing efficiently and effectively is becoming more complex: a higher level functionality is required in parallel with a satisfying performance. The functionality should satisfy requirements of different levels of collaboration, and respect a hierarchy of priorities among users and tasks. The performance, depending on the application or the network, should be sufficient for real time information exchange, which is quite often a “heavy data exchange”. We have developed a management framework to satisfy complex functionality requirements that arise in collaborative applications and services development. The emphasis in designing such a framework, is given on several levels of design that affect the performance of collaboration environments, the connection management, the replication management, the data management, and the effective and interoperable usage of resources. Based on the proposed framework we present a Java-based application for mission planning.

1

Introduction

With the emergence of the Internet and Intranet, computer science and industry have entered into a new era, where enormous distributed information sources and greatly improved computer hardware, networks, and protocols signify a new wave of computing. Although the type of the collaboration over a network is application-specific, a common characteristic of collaborative applications is the heterogeneity of various types of communications links, devices, operating systems and application data, upon which users have different priorities. In real time applications, it is methodologically required to obtain certain levels of application quality of service (QoS) in addition to the network QoS. Network QoS issues on TCP/IP based Internet have received enormous attention and led to two distinct approaches, the Integrated Services architecture (intserv) and its accompanying signaling protocol, RSVP, and the Differentiated Services architecture (diffserv) [4]. Collaborative services and applications are associated with information retrieval and sharing and other computational tasks, e.g. data compression. This paper proposes a solution by addressing the entailed requirements of collaboration, in a unified management framework. The existing collaborative technologies are involved in supporting groupware activities such as planning, coordination and decisionmaking, and several toolkits for collaboration have been developed. Habanero is a framework for sharing Java objects with colleagues ∗

Dept. of Computer Science SUNY at Stony Brook [email protected] spread over the Internet. Networking facilities, and routing, arbitration, and synchronization mechanisms to accomplish the sharing of state data and key events between collaborators are provided in the system [2]. Tango is one of the few projects very tightly integrated with the Web so it is a Web - based collaboration system. The Tango system is targeted on collaborative applications for education and distance-learning, command-and-control, and health care [1]. These approaches are promising and they also have similarities. However, it is difficult to satisfy the complex functionality requirements of a collaboration environment and combine them along with a satisfying performance. In fact, the criteria to judge a system’s performance are associated with the type of the application that will use it. Still, there are certain requirements to be fulfilled: • Parameters of QoS can be satisfied only when the appropriate underlying mechanisms exist to control the resources. Although these control mechanisms are operating system and/or network dependent, they should be homogeneously operable by the application. In addition, issues of users and tasks priorities should be addressed together, and be reflected at the usage of resources. Therefore, a protocol for resource management in collaboration environments should be standardized. • How to handle the events generated in the environment and in the application and how to replicate different types of data over a heterogeneous network with different protocols and various signal types are critical issues for system performance and application QoS. For example, users may require different levels of information abstraction and various degrees of coupling. Distributed computation is worthwhile only when the time required for distributing data across the sites is smaller than the gained reduction in the local application processing time. • Collaboration among heterogeneous environments requires communication between different hosts, operating systems and networks. A platform independent language like Java can only partially solve the problem but issues such as time and resource usage when creating objects must be considered. The significant advantage of Java, besides portability and the rich set of class libraries with extensive networking support, is also the ease of implementation that offers to the application developer.

2

A Management Framework

In order to address these issues, we present a management framework to support collaborative activities. The purpose of collaboration management is to provide a safe sharing environment with multiple collaboration channels, where clients can register their interests and participate in the group activity. In such an environment there are normally two connection modes: push and pull, in accordance with the consumer and producer model. Figure 1 presents this framework; the design emphasis is on four levels

This research is conducted while the author was with CAIP Research Center, Rutgers University, New Brunswick, NJ.

that affect the performance characteristics of collaboration environments and provide the high-level functionality: • Replication management: this design is based on the network traffic engineering, e.g., categorization of the generated events and the categorization of the system behavior for each category of events in order to avoid unnecessary network traffic. Events generated in the environment may be co-related. • Connection management level: the connection manager deals with the connection setup and teardown as well as with the users joining the session late. The session manager configures/reconfigures environments for collaboration including replacement of network equipment and adding or deleting network links. Connection Management Session

Replication Management Filter

Connect

Replicator

Data Manager

Resource Manager Network Resources

Database

Fig. 1. Collaboration configuration management • Data management level: for efficient and effective collaboration, information from distributed heterogeneous data sources has to be retrieved, integrated, processed, analyzed, and visualized before presenting to the user. The information abstraction increases the flexibility of coupling between users. As a result, collaborators, usually from different backgrounds with different responsibilities, are able to have not only different views of the same set of data but also different levels of detail for information gathered by the same query. • Resource management level. Collaboration management is closely associated with the resource management scheme that monitors and controls resources over different platforms and operating systems in a unified manner. In addition it utilizes a highlevel protocol to control resources with respect to the specific requirements of collaboration. It respects priorities of users and tasks during collaboration by reflecting the different properties of collaborators to the usage of the resources. A collaboration session supports multiple channels that may rely on different network protocols and, within one channel, clients are able to request various signal types (e.g. different bit rates), protocols (e.g. connection-oriented or connectionless protocol), and security-levels (e.g. employ a private encryption technique). 2.1 Components and Interaction Figure 1 shows four main components in the collaboration network management, connection, replication, resource, and data management. Once a session is initiated in the connection management, a collaboration channel is established. There are two types of collaboration between clients: synchronous and asynchronous. The former occurs when all components are cooperating at the same time possibly from different locations,

whereas the latter takes place when components participate at different times over the course of collaboration. In the collaboration channel, events generated in a session are passed through an event filter before being inserted into a queue. The collaboration-unrelated events are suppressed and only userproduced collaboration-oriented events are forwarded into the channel concurrency controller. Resource-oriented events, such as an incapable CPU, will be forwarded to the resource manager; dataoriented events, such as searching an employee address from a relational database, are passed to the data manager. Through replication manager, the decision is made on providing the most efficient way for collaboration. The collaboration-related events are converted into a unified external data format for multicasting according to subscription information. 2.2 Data Management Multiple levels of information sharing between collaborators are achieved by providing different levels of information abstraction. For example, a project manager and a technical staff require different levels of information details although they share the same interest in the project. The former is keen on decision-support information such as the budget and the project progress according to proposal deliverables, whereas the later is more interested in technical details in his area and the interfaces to other modules. Degree of information sharing is the degree of association between collaborators. A collaborator may not be interested in every task discussed in a session and thus he/she would like to subscribe to a specific topic. Figure 2 shows 3 levels of information abstraction. Level A indicates the raw data in a specific format; Level B involves summarized and integrated data; Level C visualizes the data in a more condensed format. It is unnecessary and costly to reengineer all the existing data into a new storage so providing an API on top of the databases is desirable. The API makes use of the existing gateway protocols, such as JDBC and ODBC, and provides interface to other managers in the system.

Abstract

Level A: Visualized data

Group 1 Group 2.1

Levels of

Level B: Integrated data

Information Sharing

Details

Level C: Information Access—format 1

Data 1

2.2

Degrees of Information Sharing Level C: Information Access—format 2

Data 2

Fig. 2. Collaboration data management 2.3 Connection and Replication Management Connection management consists of a session manager and a connection manager. The session manager prepares for the collaboration by registering the sites’ software and hardware information and collecting the link topology and application specific information. The connection manager receives requests

and is able to initiate or terminate a connection across a network. If one intends to join a session, he needs the session identification number and possibly a password if it is not a public session. Offline users can contact the session manager for archiving data or session replay. Replication management deals with replicating data to collaborators during collaboration and also with placing data over collaborative sites before a session. There are at least two ways to distribute data to collaborators during collaboration. One is to retrieve local data, attach them to the event locally, and transmit the event. Another way, which is applicable when the appropriate data does not exist in the local node, is to send data separately from the event and associate data and event at destination node. This mechanism is useful in case that event and data are transferred over different communication techniques (e.g., the event is transported over an Object Request Broker, while the data uses a simple socket connection). Therefore, data and event may even be replicated separately and concurrently. The decision on data placement before establishing a session, is based on level of sharing, access pattern behavior and knowledge level of access pattern. The level of replication should depend on the ratio of read-only queries to the updated queries. Replication management not only enables collaboration but also has influence on its performance. During a course of collaboration, not every type of event requires transmission, nor is the mechanism of replication the same in heterogeneous and homogeneous environments. For example, external data representation (e.g. XDR or CDR) can be omitted, thus gaining performance when the environment is homogeneous. This implies the existence of several mechanisms to transport data and also requires an intelligent entity to decide in which case to apply each mechanism. An event classification scheme is to structure events into streams based on their semantic meaning carried. Events can be grouped into collaboration-unrelated and collaboration-related events, where collaboration-related events are further classified into resource, collaboration, and data-oriented ones. Resource-oriented events can be network element (NE) or communication related events. An example of NE-oriented event is an incapable CPU and an instance of communication-oriented event is network congestion. The resource-oriented events may be correlated; for example, a link cut may be associated with the port alarm in the NE. Data-oriented events differ from the collaboration-oriented events since in the data-oriented event users are sharing the result (e.g. a query result) but not the event (e.g. the query) itself. Directly forwarding dataoriented events to collaborators will not only waste network bandwidth but also raise concurrency to data sources. Data-oriented events can be local if users have the copy of the database, or nonlocal if users require a data transfer. Collaboration events can be categorized into low-level and semantic events. Semantic events can be application-specific. The objective of event classification is to minimize collaboration communication cost. An event filter is an implementation of this event classification schema and it applies before the event replication.

3

Interoperable Resource Control in Collaboration

Quality of Service (QoS) parameters can be supported, only when a variety of underlying mechanisms exist in order to flexibly control the resources or utilize communication protocols. Users might prefer faster communications rather than reliable ones, or they might demand the guaranteed delivery of the crucial

commands. Some applications require reservation of CPU and bandwidth, and could be possibly enhanced by a priority-based usage of other resources. The controlling methodology described hereby emphasizes on management of networked resources in order to enable collaborative services that, typically, run over distributed, heterogeneous environments. This methodology implies that application developers need to implement different mechanisms in order to control the resources. However, it provides guarantees that these mechanisms can be presented as universal service objects to the application developers and can support functionality to control resources with respect to priorities of users and tasks. In the networked environment, resources are shared among users or applications. Consequently, quite often, users might compete for the same resource; applications may require resource reservation to ensure QoS; a significant task might need more resources to be temporarily allocated than others do. A QoS enabling system should interact with a variety of mechanisms that flexibly control resources in order to support different levels of service quality.

Resource Manager Demon Priority Table

Priority Coordinator & Scheduler

System Dependent Control Program

Kernel Resources

Fig. 3. Interoperable resource control Since a common controlling mechanism that applies to all systems is not feasible, the only way to provide a generic management solution in a collaboration environment is to allow flexibility to the implementation of the system-specific controlling mechanisms that arbitrate the resources. This way, we can enable a distributed application running above different platforms, to utilize different mechanisms to control the resources. Similarly, we can rely on different network protocols and programs in order to manage the network resources in a unified manner as shown in Figure 3. The resource arbitrators provide common interfaces to the application. Applications can benefit from these units by operating them dynamically or even discovering them dynamically in order to control the resources in accordance with current requirements and conditions. We propose the Common Object Request Broker Architecture (CORBA) [3] as a proper solution for their implementation since it simplifies distributed computing by overcoming issues of heterogeneity, location transparency, and dynamic discovery of objects. 3.1 Functionality and Operational Interface The Resource Arbitrators are autonomous units, which provide a uniform framework that can cater to the service requirements of various applications during a collaborative work. They have the following features: provide CORBA interfaces, understand priorities, standardize the operational interface, and enable controlling mechanisms. The resource control mechanisms are

however operating-system-specific since they utilize library routines of the system. Every Arbitrator has a standard operational interface. The system, in order to utilize the management services provided by the Arbitrators, has to invoke their standard operations. The operations are: • monitor(): This operation is invoked when a client requests the Arbitrator to monitor the extraordinary events that are related to the resource. • get(): This is invoked when a user (client) wishes to retrieve the current state of an object. • set(): This operation allows a client to set constraints regarding an object’s state. Constraints represent the state that should trigger an alarm or activate a control mechanism. We use the constraints as the values to be compared to the resource’s current state value. • control(): This operation is invoked when the client or the Arbitrator (dynamically) wishes to start the controlling operation (mechanism). Therefore, an application can explicitly call a control mechanism, set constraints that upon violation will start the control operation, or monitor the state of the resource and the related events. In our experimental implementation of the framework we have tested the Resource Arbitrators as CORBA objects (we used JavaIDL), having interfaces as shown below: interface resource_arbitrator { oneway void monitor(in string tag, in string portName); void set(inout string tag, out int code, in string portName, in ThresholdInfo thresholdVar); float get(inout string tag, out int code, in string portName); opStatus control(inout string tag, in string portName, in OpInfo opID); };

3.2 Priorities The Arbitrators have a priority mechanism that takes into account user priorities and task priorities. Users are classified with regard to their access rights, and tasks are categorized based on their priority and resource availability requirements; the resource arbitrators should exhibit behavioral characteristics in accordance with these user and task requirements. In case of a shared resource like the bandwidth, the Arbitrator can reserve bandwidth for different users according to their rights, and allocate resources according the application specific characteristics and the significance of the current task (e.g. using RSVP). In case of a constrained and shared resource, the Arbitrator has to control the usage of the resource by other users and applications. A token manager can be used to arbitrate resource contention based on user priorities. A typical scenario of such a case is when two requests of different users are in a queue and the token manager hands a token to the higher-prioritized user so that he gets to use the resource first. A priority table can advise the Arbitrator where users’ priorities are filed. Based on the decision-making algorithm, it reorders the request queue with regard to task and user’s priority. The users have the option of setting scheduling priorities for their tasks. For example, if a control program that manages CPU load finds a performance bottleneck due to over-commitment of CPU resources, the arbitrator can request a controlling action. A simple controlling action is to ask the user to favor his critical processes over others by reordering the scheduling priorities of the processes.

4

Concluding Remarks

We have presented a management framework for collaborative services and applications in a distributed environment emphasizing the connection management, replication management, data management, and resource control mechanisms. Connection management includes a session manager and a configuration manager; replication management includes an event filter and replication; data manager is capable of preparing data in specific formats or of visualizing and condensing representations. Resource management mechanism, i.e. resource arbitrator, consists of an operational interface and the system dependent control programs, and is capable of making user- and/or task-priority-influenced decision. Based on the above framework, we have designed a military mission planning application and developed a software prototype using the Java programming language. The application is able to simulate troop movement and provide troop position and troop status update. It also provides distributed database access and query result visualization. The application’s users are military officers, commanders and soldiers located at remote locations. The application scenario is presented in Figure 4. An operation officer is planning a military assault on Hill 718 and the objective is to push the enemy troops out of the map. During the session, double clicking on the troop icon triggers an information access. The troop status information is retrieved and integrated and then condensed and visualized according to a standard code-color scheme. OBJECTIVE WAYNE - Hill 718

UNIT STATUS

MINEFIELD

MSR MANHATTAN

2ND PLT A COM MISSION LT. W. KELLY 95% EFFECTIVE LOGISTICS 35 TROOPS 5 M60’S 7 MORTORS 4 BRADLEY’S 5 M109

TF DRILL TF CROWBAR

TF HAMMER

MSR RICHMOND

MSR BROOKLYN

ASSEMBLY AREA

Fig. 4. Application scenario Event replication is separated from data replication as the data streams consist of multimedia files and consume considerable bandwidth. The network functional managers are interfaced using CORBA. A collaboration-oriented event can be, UpdateInfoVector (troop ID, logotude, latitude, timestamp, awareness string), and an example of awareness string is “User Kevin is moving the Infantry Union 200 Troop ID s22244”.

References [1] Tango Project, http://trurl.npac.syr.edu/tango/papers/tangowpthe.html [2] Habanero Project, http://www.ncsa.uiuc.edu/SDG/Software/Habanero [3] Object Management Group, The Common Object Request Broker: Architecture and Specification, http://www.omg.org/corba [4] Differentiated Service, IETF Internet draft, http://search.ietf.org/internet-drafts/draft-naser-voice-diffserv-eval00.txt