Object-Oriented GSMP Extensions for QoS

Real Time CORBA support for GSMP

Multimedia-On-Demand

The General Switch Management Protocol (GSMP) is a protocol developed by Ipsilon Networks Inc. and available as an Internet RFC (RFC1987). It is a general-purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch, to add and delete leaves on a point-to-multipoint connection, to manage switch ports; request configuration information and to request statistics. This protocol has gained widespread acceptance as a vendor neutral standard for controlling ATM switches, and is supported by many ATM switch vendors. However, GSMP does not specify any means of supporting Quality of Service (QOS). QOS is a critical part of ATM networking and hence has become an important requirement in GSMP.

The Applied Research Laboratory at Washington University has implemented GSMP for controlling its Gigabit Network Switch and BayNetwork's LattisCell switch.

The Common Object Request Broker Architecture (CORBA) specifies a software architecture that supports object-oriented distributed systems. The Distributed Object Computing research group at Washington University (WU) is developing a high-performance, real-time ORB called TAO (The ACE ORB). TAO is a vertically integrated ORB end-system architecture that ranges from CORBA middleware down to the OS I/O subsystem, communication protocols, and network interfaces. The TAO technology is being transferred to ORB vendors to be built into commercial ORBs. The real-time support of TAO makes it an attractive platform for the development of multimedia applications.

The target of the first part of this project is to combine our experience with GSMP, networking, ATM switching and real time ORBs to develop a CORBA-based implementation of GSMP with support for QOS.

The target of the second part of this project is to build a CORBA-base multimedia application to exercise real time ORBs. For this effort we will again utilize the already developed TAO platform and modify an existing application of ours, Multimedia-On-Demand (MOD), to use CORBA in place of its current communications mechanisms. The following sections describe the specific tasks to be performed during the 12 months of the proposed projects.

 

Task 1: GSMP+

The typical GSMP model is shown in Figure 1.

A GSMP client creates GSMP requests and sends them to the switch, which executes the requested operation and sends the result back to the client. GSMP is a typical communications protocol in that a significant amount of the effort involved in the design, implementation and execution of it is in organizing messages, setting byte ordering and parsing and dispatching messages. By taking care of all of those types of issues, CORBA provides a better model for building distributed systems. The development team is thus relieved of the burden of correctly implementing the low-level mechanisms for handling messages. This should lead to higher quality and more robust systems. Figure 2c shows an implementation of GSMP+ (GSMP with QOS) in the CORBA model. This is the target system for Task 1.

The deliverables for this task will include:
1. Performance measurements of CORBA and conventional GSMP operations.
2. Specification of GSMP+;  
3. Conventional implementation of GSMP+;
4. Intermediate CORBA implementation of GSMP+;
5. Integrated CORBA implementation of GSMP+;
• Subtask 1: Performance Comparison: To begin this GSMP project, a performance evaluation will be done to compare a traditional GSMP message passing system with a CORBA based system. For this study we will isolate the message passing portions of each system from the processing and switch manipulation operations. We will also be able to generate estimates or actual times for updating Fore, Bay Networks and Washington University GigaBit switches. With this evaluation we will have a set of metrics with which to compare the use of the traditional GSMP message passing and CORBA based systems as well as judging the significance of the delay of these systems against the overall time required to perform switch operations.

An initial performance evaluation will be undertaken to justify the direction of the work to be performed. At the completion of the five subtasks listed, another evaluation will be done to validate the work.

• Subtask 2: Specification of GSMP+: In collaboration with Sprint and the University of Kansas (KU), we will generate a specification of GSMP+. The primary focus of this new specification will be to add ATM Forum UNI 3.1 Quality of Service parameters to the GSMP protocol. If time permits, extensions to include new features of UNI 4.0 will also be investigated.
• Subtask 3: Conventional Implementation of GSMP+: As a first step in implementing GSMP+ we will undertake a conventional, i.e. non-CORBA, implementation of GSMP+ with a Fore switch, as shown in Figure 2a. An implementation of GSMP with a Fore switch exists or has been begun at KU. This implementation will be extended to produce this first version of GSMP+. This subtask will be done in collaboration with KU.
• Subtask 4: CORBA Interface to GSMP+: The second stage in the implementation of GSMP+, shown in Figure 2b, provides a CORBA interface through which the client performs GSMP operations. For this subtask, the GSMP+ server in the Fore switch control software will remain unchanged. On the client side, a CORBA-base GSMP+ object implementation will be developed that generates GSMP+ protocol messages which will be sent to the switch.
• Subtask 5: Integrated CORBA Implementation of GSMP+: The third stage in the implementation of GSMP+, Figure 2c, provides an integrated CORBA implementation. For this subtask the GSMP+ client is unchanged from the one in Subtask 4. The major work to be done in this subtask is to integrate the ORB into the switch control software on the Fore switch. This will again be done in collaboration with KU,
• Subtask 6: Performance Evaluation: To conclude this task we will evaluate the performance of the three implementations. This evaluation will attempt to isolate the affects on performance of the use and level of integration of CORBA in the switch control software.

  

Task 2: Multimedia-On-Demand with Real Time CORBA  

We are currently building a scaleable Multimedia-On-Demand (MOD) server that will support Quality-of-Service (QOS) guarantees, high concurrency and web based access. Control functions such as random search, fast-forward, rewind, pause slow-play and content-based searches are all supported or planned.

The current system is being constructed using eight Pentium PCs running the NetBSD operating system, which has been enhanced to support periodic multimedia streams. Each PC is also equipped with an ATM network interface with a locally written driver, which supports native ATM communications. A prototype of this server has been constructed and is in operation. This prototype utilizes the MultiMedia eXplorer (MMX) for ATM multimedia stream transmission and reception.

In this project, we propose to modify the existing prototype system so that it operates on a Solaris workstation and utilizes a Real Time ORB for communication of its control operations. MMX as well as MBone multimedia streams will be supported. Specific subtask action items for this task are the following:

• Subtask 1: Port of current MoD to Solaris: The first step in porting the MoD system is to modify the server so that it runs on Solaris. The current NetBSD implementation relies on enhancements to the OS for support of periodic multimedia streams and features of the locally developed ATM driver that support native ATM communications. Under Solaris we will utilize threads and enhancements to the real time scheduler that we are undertaking. The mechanism for communicating over ATM will have to be modified to work with an existing ATM network interface and driver.
• Subtask 2: Use of CORBA for MoD Control operations: Use of CORBA for control operations will require modifications to both the client and the server. The client will still provide web-based access, but instead of issuing http requests it will issue CORBA requests. The server will be modified to fit one of two possible models, the first option being a proxy model where the server operates on http requests which have been generated by a CORBA proxy agent. In this case, the server would be unchanged but have a proxy agent in front of it to handle the CORBA requests. The second option is an integrated model where the CORBA objects are integrated directly into the server. This second option has one less level of communication and so should be more efficient but requires more extensive modifications to the MoD server.
• Subtask 3: Addition of MBone video to MoD: The use of the MMX as a multimedia device provides very high quality audio and video but it does limit the MoD system to a specialized device. For this reason, we plan to add MBone video as an option to the MoD system. The added generality that Mbone service will provide will make the MoD system one that can be run in environments that do not already have MMXs. An MMX costs approximately $9000 and so building an environment with multiple MMXs can be a costly venture.
• Subtask 4: Design of a Multimedia Composition Application: So far the use of CORBA has been limited to the communication of control operations. To really test the capabilities of a RT ORB, we plan to design a multimedia composition application. This application would operate on objects of multimedia data and give the user the capability to compose these objects into a multimedia stream. For example, a typical motion picture contains a large number of sequences, which are separated by cuts from one scene to another or from one view to another. Each of these sequences could be stored as a separate video clip and composed into a stream by playing them sequentially. To implement the video-on-demand behavior in the ORB an implementation of the draft OMG multimedia streaming service will be used. In this subtask we plan to design such an application and pursue as much implementation as is possible.