Building Manageable Multimedia Network Services

Journal of Network and Systems Management, Vol. 8, No. 1, 2000

1064-7570/ 00/ 0300-0009$18.00/ 0 2000 Plenum Publishing Corporation

9

Building Manageable Multimedia Network Services

Rolf Stadler1,3 and Cristina Aurrecoechea2

The paper addresses the problem of designing and realizing manageable multimedianetwork services. We argue that open interface between the service delivery and theservice management systems can be defined using design patterns, i.e., generic objectmodels. As an example, we introduce a generic object model that makes instances ofa network service accessible to the management system. The model includes a set ofcooperating objects that can be customized for particular service and managementrequirements. By applying this model to the design of mcast, an ATM multicastservice, we enable the management system to monitor and control mcast sessions. Tovalidate our approach, we have implemented mcast and the management functions ontwo different platforms: (1) on a high-performance emulation platform, which allowsus to study the system’s dynamic behavior and scaling properties in various scenarios;(2) on a broadband testbed, on which network services can be fully implemented,including the transport between multimedia devices. We outline a specific techniquethat allows us to run the same code, without changes, on both platforms.

KEY WORDS: APIs for service management; multicast service; CORBA-basedcontrol and management; design patterns, prototyping.

1. INTRODUCTION

Until recently, telecommunication networks have been built upon a single tech-nology and delivered a small set of services. Because of the relative simplic-ity of the systems, the management task has focused primarily on the devicelevel. Currently, we are witnessing an explosive growth in distributed multi-media applications and services, such as video conferencing, video-on-demand(VOD) and collaborative distributed environments, together with an increasing

1 Center for Telecommunications Research and Department of Electrical Engineering Columbia Uni-versity, New York, 10027. E-mail: [email protected]

2 AT&T Labs West, San Jose, California 95134. E-mail: [email protected] To whom correspondence should be addressed at Department of Electrical Engineering, 500 W

120th Street, 1312 Seeley W. Mudd Bldg, Columbia University, New York, New York 10027-6699.

Stadler and Aurrecoechea10

variety of underlying network technologies. As a result, telecom networks andenvironments are becoming more and more complex.

This situation has created major challenges for managing telecom multi-media environments. One of these challenges relates to the variety of servicesand technologies. Management architectures have been developed to address thisproblem. The TMN framework [1], for instance, introduces an architecture thatdefines layers of increasing levels of abstractions (element management layer,network management layer, service management layer, and business manage-ment layer). The service management layer deals with the services provided bythe telecom system, including multimedia services.

A second challenge is to design the new services (and technologies) in sucha way that they can be managed on the appropriate level of abstraction. The factis that most management systems today are built as an afterthought to servicedelivery systems. This makes it difficult to add the hooks for monitoring andcontrolling service activities later. More importantly, the service delivery systemmight have been designed and/ or implemented differently, had the managementrequirements been taken into account during the analysis phase of the system’sdevelopment.

This paper addresses the problem of designing and realizing manageablemultimedia services. Our approach centers around defining a set of cooperatingobjects involved in the interaction between the service delivery and the servicemanagement system. The model we propose describes the interface between thetwo systems, and covers—in a generic way—the aspects of instantiation of aservice session, its access by a user, and its management by the operator. (Aservice session represents the information handled by all processes involved inproviding a service; a session has a start, a duration and an end.) Our modelsuggests a generic solution to a recurring problem in service design. The modelneeds to be customized for a particular service and refined according to man-agement requirements and available resources. In this sense, we are proposinga design pattern [2] for making telecom services manageable.

This work focuses on service management in the sense of supervising theservice delivery system. The management task includes monitoring and control-ling the service delivery system to ensure that it operates as intended, main-taining the service-level agreements while achieving management objectives.The task is performed on a slower time-scale than the functions executing inthe service delivery system. This activity relates to the OSI functional areas ofperformance and configuration management, and to the functions in the servicemanagement layer of the TMN architecture.

In the domain of service management we are considering, two activitiescan be identified: (a) managing the set of controllers (i.e., routers, connectionmanagers, etc.) which comprise the functionality of the service delivery system,and (b) managing the set of service instances (such as audio multicast connec-

Building Manageable Multimedia Network Services 11

tions or VOD sessions) which are dynamically created, modified and terminatedduring the operation of the service delivery system. While we have presentedsome results on activity (a) (see [3]), this paper focuses primarily on activity (b),namely, on the management of services instances (or sessions) and aggregationsof such instances [4].

We have applied our model for service management on a multicast VCservice for a multiclass broadband network. To validate our approach and togain experience, we have implemented the service and the management capa-bilities on two platforms, namely, (a) on a high-performance emulation platform,which makes possible to develop a software prototype and to study its dynamicbehavior and scaling properties in various scenarios [5], and (b) a broadbandtestbed running xbind [6], a CORBA-based [7] multimedia networking platform,on which services are fully implemented and the transport between multimediadevices is realized. In (b) we use CORBA technology for building not only theservice control system but also the service management system. CORBA pro-vides a flexible object oriented environment for implementing distributed soft-ware systems, and it facilitates the integration of control and management soft-ware under a single technology. Using a specific design technique, which isdescribed in the paper, we have built the software controllers in such a waythat they can run, without changes to the code, on both platforms.

The paper is organized as follows. Section 2 outlines the generic objectmodel we propose for making services manageable. Section 3 introduces anobject oriented design for a multicast service. A detailed description of the designof this service can be found in Aurrecoechea et al. [8]. In Section 4, the mul-ticast service is made manageable based on our model. A first implementationof the system on the two platforms mentioned above is described in Section 5.Finally, Section 6 summarizes some of the experience we gained with this workand, more important, outlines research topics in service management that arisewith the introduction of our model.

2. A GENERIC OBJECT MODEL FOR MANAGING SERVICEINSTANCES AND AGGREGATIONS

The service delivery system contains a set of interacting controllers thatperform the tasks of service creation and service delivery in a distributed fash-ion [3]. Specifically, the system consists of a large number of controllers, withmany instances of the same controller class spread throughout the system tosupport distributed operation and fault tolerance. A limited number of controllerclasses exist, each of which encapsulates a specific functionality, such as runninga network control algorithm (admission control, routing, etc.). Most controllersare realized in software. They can be designed as communicating active objects.They are multi-threaded, i.e., they have separate address spaces, and they com-


Fig. 1. Cooperating objects enabling service management.

municate by exchanging messages, which allows them to run on different timescales. Furthermore, they are designed as persistent objects, which are createdduring the initialization phase of the control system.

Our approach for making a service manageable introduces a new type ofcontroller in the service control system: a dynamic object that is created foreach new session. This object, which represents a service session (or serviceinstance), makes itself accessible to the management system by registering witha management object, the service aggregator.

Figure 1 shows the object classes involved in the service management activ-ity. For each type of service there is a service factory which handles the requestsfor new service sessions and coordinates the service creation/ instantiation pro-cess. For example, a service factory for unicast Virtual Channels (VCs) receivesa request for a new VC and contacts the necessary controllers (connection man-agers and routers) in order to set up the new VC. As a result the user whorequested the service will receive a handle to use the new VC. The service fac-tory object abstracts the specific scheme used for the service instantiation pro-cess.

The service instance represents the status and capabilities of an existingservice session. Figure 1 shows the service instance with two types of interface.One is accessed by the service user and represents the control capabilities (sta-tus, modify, terminate) a user has once the service session is created; the otheris accessed by the management system and represents the management capabili-ties. The service aggregator has two purposes. First, it provides a single point ofaccess for the service manager to monitor and control the existing service ses-sions of a particular service type. Second, it provides aggregated or abstractedviews of the service instances and allows the manager to manipulate sets ofservice instances. The service factory and the service aggregator are persistent


objects. They are created and initiated at service deployment time and generallystay alive as long as the service is provided. The service instance, on the otherhand, is a dynamic object. It is created when a service session is instantiated bythe service delivery system, and it is deleted when the session is terminated.

The model we are proposing is generic in the sense that it describes objectclasses, their relationships and their interactions for the purpose of making ser-vice sessions manageable. In fact the set of operations at the interfaces, bothoffered to the user and to the manager, are generic for any kind of service. Thespecific functionality of, say, a service factory, depends on the particular ser-vice. Similarly, the lifetime of service instances differ from service to service ina typical range from minutes to days. Service instances of different types canbe related via service composition. For example, a teleconference may be builtusing a set of unicast and multicast VCs.

An important aspect of our model is that the designer of a service has sev-eral degrees of freedom when developing service management functionality. Thechoices include the selection of the state information and functionality of the ser-vice instances, the amount of information kept in the service aggregators, and theconsistency requirements for the management data in the aggregators. All thesefactors influence the cost of managing the service in terms of design complexityduring the development phase and in terms of processing and computationalresources needed during the operational phase.

2.1. Related Work

The need for making services manageable has been widely recognized.Work on this topic is being pursued within the areas of distributed computing,internet networking and—of course—telecom systems. Within the field of dis-tributed computing, Schade et al. [9] propose an extension to CORBA IDL,which allows for specifying the management interface of service components ina distributed environment. The authors provide a library for implementing sucha management interface. An approach to make services manageable for an ISP(Internet Service Provider) is described by Bhoj et al. [10]. The authors addressthe problem of fault diagnosis in a multi-domain environment. Using the conceptof service contracts, they suggest an architecture that provides an ISP with man-agement (monitoring) interfaces to service components belonging to the domainof another ISP. In the telecom field, the activity most related to our work is theTINA initiative [11, 12]. TINA also applies an object-oriented methodology fordeveloping both the service delivery and the service management systems. Sofar, the TINA effort has concentrated on the service delivery system; aspects ofservice management as presented in this paper have not been addressed untilnow. The EURESCOM P610 project has recently been launched to develop anarchitecture for multimedia service management [13, 14]. Because it addresses


issues similar to those discussed in this paper, results from this project will poten-tially influence our research.

3. mcast—A MULTIMEDIA SERVICE

mcast is an ATM multicast service based on an object oriented design. Itprovides the capability of transporting multimedia information from a source toone—or more than one—destination. An mcast session belongs to one specificservice class, i.e., video, data or voice. (A service class defines the performancecharacteristics and the performance requirements of a cell flow.) A destinationcan request to join or leave an mcast session. The termination of a session isrequested explicitly by the source.

The mcast design includes three classes of controller objects: the mcastdirectory service (MDS), the mcast router (MR) and the mcast connection man-ager (MCM). The first two classes are global controllers, i.e., they maintainglobal knowledge about the service. In contrast, the MCM keeps local knowl-edge (from a host or switch).

The main purpose of MDS is to allow prospective destinations to get infor-mation about the currently existing mcast service sessions. MDS also keepspartial information about the current graph that represents each mcast sessionfor routing purposes. MR computes the route to a prospective destination uponrequest. It first selects an intermediary node in the tree to act as source in theroute.

Figure 2 shows the cardinality relationship among mcast controllers. TheNodeServer encapsulates the switch capabilities to establish and terminate localunicast connections. It realizes the interface between the service delivery systemand the network resources. There is one MCM instance for each node (host orswitch). The operations offered by MCM are associated with two interfaces: oneoffered to the service user and the other offered to a peer MCM. The operationsat the service user interface are: initiate, join, renegotiate, leave and

Fig. 2. Cardinality relationship among mcast controllers.


Fig. 3. Invocation relationship between mcast object classes.

terminate. They all refer to one specific mcast session. An MCM receivinga join request coordinates the reservation of resources by interacting with thepeer MCMs along the route to the new destination. Upon a leave or a termi-

nate request, the interaction among MCMs is hop-by-hop. This interaction canhappen in either direction—from destination to source or vice versa—dependingon which controller initiates the process: the source, a destination or a third-party.

To further clarify our design, Fig. 3 shows the mcast object classes and theway they invoke each other.

All interactions among controllers are asynchronous and are based on areliable data-gram service with FIFO property.

The mcast service design addresses the issue of consistency of multicasttrees under concurrent operations. A discussion of this aspect can be found inAurrecoechea et al. [8].

The mcast service capabilities are similar to those defined by the ATMForum [15] or the IETF [16]. For instance, mcast allows for root, leaf and third-party initiated join and leave requests; contrary to the IETF scheme, an mcastsession stays alive until it is explicitly terminated.

mcast, as described earlier, is a connectivity service that provides a connec-tivity graph between network endpoints. As such, it does not address (1) the com-munication between the multimedia devices which actually produce/ consumethe information, and the network endpoints; (2) the transport aspect of the mul-timedia flows. In order to directly support networked multimedia applications,mcast needs to be extended to an Application Level Service (ALS), in whichend-devices and the transport of flows are considered.

In principle, an ALS must provide the following functionality:

• Coordinate the transport and the control of flows• Coordinate the end-users/ applications on the service and session level• Map the QoS from user/ application level to connectivity service level

A possible design for an ALS includes three classes of controller objects:


Fig. 4. Invocation relationship between object classes.

1. A local ALS-manager (ALS-M), which represents the ALS in the userdomain. Each ALS-manager has access to different devices, one or moretransport services, and one or more connectivity services.

2. A global directory service (ALS-DS). This component serves as a repos-itory of existing service instances. It allows users to find informationabout existing sessions.

3. A QoS-Mapper (ALS-QM). The QoS as specified by end-users/ applica-tions is translated to the level of devices, transport and connectivity.

Figure 4 outlines the design of an ALS, which is an extension of the mcastservice to the end-users. (A more complex design could include alerting func-tionality, the use of more than one connectivity service, an 1-m cardinality rela-tionship between ALS sessions and mcast sessions.) The controller ALS-M playsthe role of the mcast user (shown in Fig. 3). Figure 4 shows the interaction amongthe components of the ALS service and the interaction between ALS servicecomponents (ALS-M) and controllers of the lower level services—mcast, TP(transport service) and VD (virtual devices).

4. MAKING mcast MANAGEABLE

Using the model introduced in Section 2, we present a design for managingservice instances and aggregations of mcast sessions. The management systemmonitors the set of existing mcast sessions and is able to control the systemby creating new mcast instances, modifying the state of existing instances andterminating instances.

In order to make a service manageable, (1) the service delivery system has


Fig. 5. Management of mcast service sessions.

to maintain the service instances; and (2) the service management system has tobe able to access the instances.

To accomplish (1), we need to identify the controller(s) offering the serviceinterface to the user. In our service management model, this interface is providedby the service factory object (creation) and the service instance object (all otheroperations). In mcast, this interface is provided by the mcast connection manager(MCM). As described in Section 2, MCM provides the following operations tothe user: initiate, join, renegotiate, leave, and terminate. Figure 5shows an example in which the MCMs, acting as service factories, generate theservice instance objects.

To accomplish (2), upon creation, these objects make themselves accessibleto the management system by registering with the mcast service aggregator.

To refine the design, the following questions need to be answered: What isthe state about an mcast session that is to be kept in a service instance object?What is the mechanism by which service instances are updated? What is the levelof aggregation within the service aggregator? What is the interface between theservice aggregator and the service manager?


For our implementation we have defined the following information as thestate of a service instance object:

• resource requirements: the service class, i.e., video, data, audio;• connectivity graph: the size—number of endpoints—and network

resources involved;• traffic statistics: this characterizes the dynamics of mcast sessions in terms

of destinations joining and leaving.

Next, the interfaces a–c shown in Fig. 5 need to be defined. Each of them willaffect the interfaces of two controllers.

4.1. Monitoring mcast Service Instances

There are two possible ways of monitoring: either the management systempolls the system being managed for its state, or the system being managed sendsnotifications about its state to the management system.

At the interface a, both polling (from service manager to service aggregator)and sending notifications (from the service aggregator to the service manager) aresupported, for a single service instance and for a set of instances. The operationsdefined are:

• for a session: newSession,modifiedSession,terminatedSession

as notifications and getState as a polling operation (this allows the ser-vice manager to obtain the current state of a session);

• for a set of sessions: getState, as polling operations. In the currentimplementation a set is specified by enumeration.

Monitoring in b and c is accomplished via notification messages. In b thesemessages, which travel from the service instances to the service aggregator, are:newSession,modifiedSession and terminatedSession. In c the only mes-sage defined is modifiedSession.

4.2. Controlling mcast Service Instances

Our management system is able to perform the following operations: cre-ate a service instance, modify one service instance or a set of service instances,and terminate one service instance or a set of service instances.

For example, the management system connects a video broadcast to thenetwork. This procedure includes the service manager requesting a new sessionvia the mcast service aggregator, which, in turn, contacts an MCM acting as theservice factory. As a result, the availability of the video broadcast is advertisedthrough the mcast directory service. Note that these management operations domake use of the service delivery system for its execution, as shown in Fig. 6.


Fig. 6. Controlling mcast instances.

The create operation issued by the manager identifies a source and a list ofdestinations: the SA will execute the initiate operation and as many join

operations as necessary on the corresponding MCMs. The terminate operationspecifies a set of instances: the SA will pass the request to the MCMs at sources.

The modify operation applies to the state of a service instance or a set ofinstances. Givn this definition for the state of a service instance (resource require-ments, connectivity graph, and traffic statistics), modify can apply to either therequirements or the graph. If the modification request applies to the service class,the request is translated by the delivery system into a renegotiate operation.If it applies to the graph, then it is translated into a join or leave operation.

4.3. mcast and ALS Management

Applying the model for managing service instances (Section 2) to bothmcast and an ALS service (Section 3) can lead to two co-existing managementsystems. This is shown in Fig. 7. Having several co-existing management sys-tems may be necessary in some cases, for example, in a telecom environment inwhich mcast and ALS are offered by different providers. It may also be usefulin a single-provider environment, if mcast is accessed by a variety of ALS.

The design outlined in Fig. 7 raises the question of how to refine it suchthat the consistency requirements between mcast and ALS service instances (andconsequently between mcast-SA and ALS-SA) are taken into account. Our cur-rent work does not address this issue. Our design is based on the assumptionof a single-provider environment and includes an ALS that is a straightforwardextension of mcast. In our case, there is a one-to-one relationship between mcastand ALS service instances. We therefore model an ALS service instance as acontainer object that includes a single mcast service instance. As a result, wehave implemented only the ALS management system, leaving out the mcast SAand SM controllers.

The design for ALS management, as outlined earlier, is consistent with the


Fig. 7. Applying the Service Management model to mcast and ALS.

approach to service management as expressed in TINA’s Service ComponentModel, which is part of the TINA Service Architecture [17]. By “consistent”we mean that there is a direct mapping between functional components of bothmodels. Our model is simpler in the sense that it does not address issues ofpeer-to-peer management, subscription and accounting, and certain aspects oflife-cycle management, such as service deployment and withdrawal. On the otherhand, our model is more generic, since it can be applied to connectivity services,as demonstrated by the example of mcast. (TINA has developed its own man-agement model for that purpose, as part of the Network Resource Architecture[18].) Most important, however, our model is based on asynchronous interactionamong components, which enables management and service control operationsto be performed on different time-scales, and which facilitates the concurrencyof operations within the control and management systems.

5. PROTOTYPING AND IMPLEMENTING A MANAGEABLE mcastSERVICE

We have implemented the mcast service and the management capabilitiesdescribed in Sections 3 and 4 on two platforms, namely, (a) on a high-perfor-mance emulation platform, which allows us to develop a software prototype andto study its dynamic behavior and scaling properties in various scenarios [5], and(b) on a broadband testbed running xbind [6], a CORBA-based multimedia net-working platform, on which services are fully implemented and the transportbetween multimedia devices is realized. The mcast service control and manage-ment functions described in the previous sections have been implemented exactlyonce. This software can run on both platforms, the emulator and the broadbandtestbed, using a middleware layer, which we have developed for this purpose.This middleware layer, which we call TeleSoft supports services as a collection


of interacting software controllers, hiding the platform specific realization of aset of controller functions.

In this section we outline the methodology we used to develop and imple-ment mcast and its management. We start with describing the two experimentalplatforms we used and continue with a description of the TeleSoft approach,which allows us to build telecom software in a platform independent way.

5.1. The Platforms: Emulation Platform and Broadband Testbed

Figure 8 shows the building blocks of the emulator platform. The emulatedsystem and emulation support modules consist of a set of objects that communi-cate by exchanging messages, using functions provided by the simulation kernel.The emulated system module represents the prototype system under evaluation.In our case, this module contains the controllers of the mcast service deliveryand management systems. Generally, each controller is implemented as a C++object, and has a structure to be discussed in Section 5.2.

The simulation kernel controls the execution of these objects and ensuresthat messages are processed in the correct order. It is realized as a parallel dis-crete event simulation (PDES) system, using a window-based synchronizationprotocol. In order to support real-time visualization and interactive control ofthe emulated system, the kernel controls the progression of the simulation time,constraining it by the progression of the processor time. The module for real-time visualization and interactive control contains a graphical interface whichprovides 3-D visual abstractions of the system state.

Both the emulated system and the simulation kernel (coded in C++) run onan SP2 parallel processor located at the Cornell Theory Center (CTC) in Ithaca,New York. The real-time visualization and interactive control module resideson an SGI Indigo2 workstation at Columbia University. It is written using OpenInventor, a 3D graphics tool kit based on Open GL. The emulation support mod-ule is distributed on the two machines. These machines communicate throughNYNET, an ATM network that connects several research laboratories in NewYork State.

As for the broadband testbed, we use CORBA technology [7] and C++for building the mcast service delivery system as well as the management sys-

Fig. 8. Building blocks of the interactive emulation platform.


Fig. 9. Hardware and software layers in the broadband testbed.

tem. CORBA offers a flexible object oriented environment for the design ofdistributed software. The CORBA implementation we use is based on OrbixV2.0 [19].

The broadband testbed is a local ATM network that connects a set of work-stations and multimedia devices, such as cameras and microphones. The testbedruns xbind [6], a CORBA-based open platform for service creation and imple-mentation. xbind defines and implements a collection of CORBA objects calledthe Binding Interface Base (BIB). The BIB provides access to abstractions ofnetworking resources and multimedia devices. For example, the VirtualDeviceinterface abstracts the operations that apply to a multimedia stream device; theVirtualSwitch controls the manner in which VPI/ VCI pairs are allocated anddeallocated for ATM switches and ATM adapter cards. Support for QoS is real-ized via a set of abstractions that characterize the multiplexing capacity of net-working and multimedia resources. The control of the ATM switches is accom-plished via the General Switch Management Protocol (GSMP) [20].

Figure 9 gives an overview of the current testbed architecture. At the lowestlayer, the ATM LAN connects a set of hosts including multimedia devices (cam-eras, speakers, microphones, and displays). The BIB is at the lowest softwarelayer. mcast controllers, located in the layer above, make calls to the BIB inter-faces to access the networking resources and multimedia devices. The highestlayer contains the management entities.


5.2. Moving Code from the Emulation Platform to the BroadbandTestbed

How can telecom software be written in a way that it can be moved, withoutchanges, from the emulator platform to the broadband testbed? Over the last twoyears, we have devoted a substantial amount of time to finding a practical andeffective answer to this question. We experimented with different approaches,which we applied during the development of a VPN control and managementsystem [21]. Finally, during the development of mcast, we believe we found thebest solution yet. As mentioned before, we call this method and the supportingsoftware TeleSoft [22, 23].

1) A service control system, such as mcast can be modeled as a set ofinteracting controllers. As explained in Section 1, we argue that this isa useful way—for the purpose of software engineering—to structure atelecom system.

2) For all controllers that make up a telecom system, a common, genericstructure can be defined. This means in object-oriented terms: we candefine an abstract controller class, such that all controllers in a systemcan be modeled as subclasses of this abstract class.

3) We can find an object-oriented design technique, such that each con-troller can be built out of two parts—an application dependent part anda platform dependent part. This allows us to build the application depen-dent part of a controller, the concrete controller, in such a way that itcan be run on both platforms. This aspect is shown in Fig. 10.

Fig. 10. Software controllers are built in a platform independent way. A middleware layer, TeleSoft,maps controller functions onto different platform.


These three basic ideas are further elaborated in the following subsections.Note that, in the example of mcast, the design given in this paper is restricted tothe control plane. All mcast controllers described in Section 3 relate to signalingcomponents and do not perform functions in the data path. Therefore, the mcastimplementation on the emulator platform allows us to validate and experimentwith control plane functionality. The flow of user data, therefore, is not mod-eled on a packet per packet basis on the emulator platform. On the broadbandtestbed, however, the mcast service manages real connections, since the deviceabstractions, such as the NodeServer in Fig. 2 are connected to physical devices.

5.2.1. Generic Controller Model and APIWe have identified certain characteristics to be part of a generic controller,

out of which telecom control and management systems can be constructed. Thesecharacteristics include the ability of a controller to execute operations, to sendand receive messages while communicating with other controllers in a asyn-chronous way, to perform an operation at a specific time, to provide state infor-mation at defined time intervals, and to set control parameters that determineits functional behavior. Figure 11 shows the interface of our realization of thegeneric controller concept. It is defined by the public and protected part of theabstract C++ class TS Controller: the upper part of the interface declares vir-tual methods that must be defined by the application, the lower part providesfunctional support for the application. (We use the term application here withthe same meaning as telecom service.)

Fig. 11. Controller API: the controller is implemented as C++ class, concrete application controllersinherit the interface by deriving from it.


Fig. 12. Interface of class TS SysObject serving as abstraction for the platform (incomplete).

In order to implement an application controller, the user defines a C++class derived from the TS Controller class, which overloads the virtual methods,implementing the application-specific semantics.

5.2.2. Running Controllers on Different PlatformsWhile the API discussed in the last section provides an interface upwards or

towards the application, another class named TS SysObject provides an inter-face downwards, or towards the platform. Both of these interfaces serve the samepurpose—hiding implementation specific details. While the controller API pro-vides the functionality of the generic controller, the TS SysObject interfaceabstracts the specific platform, such as the emulator or the broadband testbed.

In order to support a specific platform, the interface of the TS SysObject

abstract base class must be implemented in a derived class. Figure 12 displaysthe interface of the class TS SysObject. The upper part includes the virtualmethods that define the basic functionality of TeleSoft. These methods need tobe implemented for each specific platform, i.e., for each specific platform a classderived from TS SysObject needs to be defined. The lower part of the interfaceis implemented in the base class, since it is platform independent. For instance,the method dispatchRequest() forwards an arriving request to the applica-tion controller for processingTo combine the TS Controller interface witha specific TS SysObject implementation, a design pattern known as the bridgepattern [2] is used (Fig. 13). The bridge pattern generally allows to de-couplean abstraction from its implementation, so that the two can vary independently.In our case, the class TS Controller is the abstraction (for application con-trollers), while TS SysObject is the implementation of that abstraction on aspecific platform. The actual implementation of both classes is provided by sub-classes. At run-time, each application controller, derived from TS Controller,is combined with an instance of the implementor, derived from TS SysObject.


Fig. 13. Bridge Pattern: the basic functionality available to the controller is implemented in a classderived from the abstract implementor (bridge) class TS SysObject.

Depending on which platform the application is running on, a different imple-mentor is chosen.

The concrete implementation of the TS SysObject class, TS SysObject-Impl, for the CORBA platform, is achieved as follows. TS SysObjectImpl

derives not only from that base class, but also from the CORBA objectOrbixObjectBOAImpl via multiple inheritance. TS SysObjectImpl thuscombines the capabilities of the CORBA object (which supports sending andreceiving CORBA requests) with the interface of the class TS SysObject (Fig.14) At run-time, each application controller is linked to one instance of classTS SysObjectImpl. The latter receives CORBA requests through the CORBAmethod TS SysobjectImpl::processRequest() and forwards them to thecontroller for processing. Requests generated by the application controller aresent to the destination controller by invoking the processRequest() CORBAmethod of the TS SysObjectImpl instance that is associated with the des-tination controller. Sending and receiving requests on the CORBA platformis realized using CORBA one way calls. The concrete implementation of theTS SysObject class for the emulation platform is achieved in a similar wayas that described for the CORBA platform. The main difference is that, insteadof the class CORBAObject-BOAImpl (Fig. 14), the basic class for simulationobject is used.

Note that controller design—although very important—is not the onlyaspect to be considered for writing telecom software in a platform independentway. Other aspects include object naming and data marshalling, for which wehave adopted solutions. Further, there are issues, such as system initialization,which are very difficult to solve in a platform independent way, and which we


Fig. 14. Building a controller in the CORBA environment: An application-specific part(TS ControllerImpl) is linked with an instance of class TS SysObjectImpl.

have solved using platform specific schemes. See [22, 23] for a discussion ofall these aspects.

5.3. Prototyping mcast and Service Management

We designed and implemented mcast and its management functions in threephases. After producing the first design, we implemented the system on the emu-lation platform. During this phase, the user interface of the management stationwas also developed. (See Fig. 15.) The second phase included running the sys-tem on the broadband testbed, as a CORBA emulation, without interaction withthe physical devices. In the final phase, we connected the system running on theCORBA platform to the multimedia device abstractions provided by xbind andthe ATM switches in our lab. In this phase, the system is fully operational andapplications on the testbed can, e.g., set up connections using the mcast CORBAinterfaces.

From a system engineering point of view, our specific approach to proto-typing a telecom service paid off: While it took us several weeks to completethe first version of the prototype on the testbed (going through all three phasesdescribed earlier) subsequent enhancements or modifications to the system couldbe realized in only a few hours, once they had been tested on the emulation plat-form. Further, most parts of the management station, including the user interface,have been used for a system running on either platform.

Figure 15 shows the 3D operator interface used in both platforms for themanagement of the mcast service. The network topology is shown at the lowestlayer. Different colors on these bars represent different service classes, such asvideo, audio, and data. The balls above represent mcast sessions for which thenodes below act as sources. For the six sessions starting at the node nearest theviewer (bottom left), the multicast trees are shown.


Fig. 15. The operator interface displaying the current link load and the current sessions of the mcastservice. The window in the lower left corner allows the operator to perform service managementoperations on selected mcast sessions.

6. DISCUSSION AND FUTURE WORK

Our implementation proves that the model introduced in Section 2 is appli-cable to the mcast service and indeed makes service sessions manageable. Apply-ing our model to similar services like a point-point VC service or another flavorof a multicast service seems straightforward. Using our model, we are currentlydesigning and implementing a “Virtual Workshop” teleconferencing system andits management on top of the mcast service.

Our current research is not so much directed towards applying our model toadditional services in order to prove its generic applicability as to use the modelas a guide to investigate design approaches to efficient and scalable manage-ment systems. Efficiency relates to using minimal resources to achieve a set offunctional requirements. By scalable, we mean the ability of the system to (a)support high rates of service requests, caused e.g., by a high load of the servicecontrol system combined with a short average life-span of service sessions, and(b) to offer interfaces between service aggregators and service managers that aresuited for a large number of concurrent sessions.


As outlined in Section 2, a designer has several degrees of freedom inorder to introduce management functionality to a particular service. Consider,for example, the service instance of mcast. The state of such an object can sim-ply consist of an identifier of a service session, but, additionally, it can includethe end points of the multicast session, or the topology of the multicast tree,or the Virtual Channel Link identifiers of the edges of that tree, etc. Likewise,the functionality of the service instance must include a command to terminate asession, but it can also include one or more of the following commands: querysession status, modify session properties, and terminate a specific sink.

Consequently, there is a wide range of possible designs for building man-agement systems for a particular service, from light-weight, low-cost systemswith minimal functionality to heavy, high-cost systems with rich functionality.More precisely, we believe that a trade-off analysis must be made, balancingvarious factors in order to achieve the best combination between low cost, goodscalability and rich functionality of the management system for a specific serviceand a particular environment. There are strong reasons to engineer configurablesystems which can be customized at the time of service deployment. Moreover,it may be necessary to allow for dynamic reconfiguration of a system during run-time, in response to changing needs and the availability of resources allocatedto management tasks.

In the current mcast prototype system, the service aggregator creates aglobal view by simply making all states of the service sessions available at itsinterface, and it allows the service manager to execute control operations ona single session or a set of sessions. Based on our experience with the emu-lation platform, such a design is scalable up to a few dozen service sessions.For large numbers of sessions (103 or more), other approaches to the designof this interface are needed. Specifically, such an interface must include oper-ations involving aggregated information on sessions in the sense of condensedor abstracted data. This type of functionality is beyond that of the scoping andfiltering mechanisms supported by OSI-based management systems or the inter-face languages of today’s database systems (which are typically based on set andrelational calculus).

ACKNOWLEDGMENTS

This research was supported by the Department of the Air Force, RomeLaboratory, under contract F30602-95-R-0143.

REFERENCES

1. ITU-T Recommendation M.3010 (1992), Principles for a Telecommunications Management Net-work. ITU, 1992.


2. E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: Elements of reusable object-oriented software, Addison-Wesley, 1995.

3. M. C. Chan, G. Pacifici, and R. Stadler, Managing multimedia network services, Journal ofNetwork and Systems Management, Vol. 5, No. 3, pp. xx–xx, 1997.

4. C. Aurrecoechea, A. A. Lazar, and R. Stadler, Towards building manageable multimedia networkservices, IFIP/ IEEE International Conference on Management of Multimedia Networks andServices ’97 (MMNS’97), Montreal, Canada, July 1997.

5. M. C. Chan, G. Pacifici, and R. Stadler, Prototyping network architectures on a supercomputer,Fifth International Symposium on High Performance Distributed Computing (HPDC-5), Syra-cuse, New York, August 1996.

6. A. A. Lazar, K. S. Lim, and F. Marconcini, Realizing a foundation for programmability of ATMnetworks with the binding architecture, IEEE Journal of Selected Areas in Communications,September 1996.

7. Object Management Group (OMG), CORBA 2.0/ IIOP Specification. Technical Documentptc/ 96-08–04, http:/ / www.omg.org/ corba/ corbiiop.htm, August 1996.

8. C. Aurrecoechea, M. Borla, and R. Stadler, mcast: Design of the service and its management,CTR Technical Report No. 484-97-18, Columbia University, December 1997.

9. A. Schade, P. Trommler, and M. Kaiserswerth, Object Instrumentation for Distributed Applica-tions Management, Distributed Platforms, Chapman and Hall, London, 1996.

10. P. Bhoj, S. Singhal, and S. Chutani, Management of new federated services, IFIP/ IEEE Inter-national Symposium on Integrated Network Management (IM’97), San Diego, California, May1997.

11. G. Nilsson, F. Dupuy, and M. Chapman. An overview of the telecommunications informationnetworking architecture, TINA 95, Melbourne, Australia, February 1995.

12. H. Mulder and J. Pavon, TINA: Evolving the TMN, Journal of Network and Systems Manage-ment (Special Issue on TINA), Vol. 5, No. 4, pp. 381–383, December 1997.

13. EURESCOM P610 participants, Providing framework, architecture and methodology for multi-media services management, IFIP/ IEEE International Workshop on Distributed Systems: Oper-ations and Management (DSOM ’97), Australia, October 1997.

14. L. Mathan, The TMN Program in Eurescom, Journal of Network and Systems Management,Vol. 7, No. 2, pp. 247–256, June 1999.

15. ATM Forum, UNI V4: User to Network Interface specification. ATM Forum, 1995.16. L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala, RSVP: A new resource reservation

protocol, IEEE Network, September 1993.17. TINA Service Architecture Version: 5.0, June 18, 1997. http:/ / www.tinac.com/ 97/ sa50-main.ps.18. TINA Network Resource Architecture—version: 3.0, February 10, 1997. http:/ / www.tinac.com/

97/ nra v3.0 public.ps19. Iona Technologies, The Orbix architecture, http:/ / www.iona.ie/ Orbix/ arch/ index.html, Novem-

ber 1996.20. T. Worster (Editor), General switch management protocol, Internet Draft, http:/ / www.ietf.org/

internet-drafts/ draft-ietf-gsmp-02.txt, October 1999.21. M. C. Chan, A. A. Lazar, and R. Stadler, Customer management and control of broadband

VPN services, IFIP/ IEEE International Symposium on Integrated Network Management (IM’97), San Diego, California, May 1997.

22. R. Puttkammer, A real-time simulator for prototyping telecommunications applications, M.S.Thesis, Columbia University, New York, 1997.

23. R. Puttkammer and R. Stadler, Simulation Kernel 2.0—Users Manual, Center for Telecommu-nications Research, Columbia University, March 1997.


Rolf Stadler is a visiting professor at the Swiss Federal Institute of Technology (ETH) inZurich. He is on leave from Columbia University where he holds positions as a research scientistand an associate adjunct professor. He received the M.S. degree in mathematics and the Ph.D. incomputer science from the University of Zurich, Switzerland, in 1984 and 1990, respectively. He isleading research efforts at Columbia University and ETH Zurich in the area of active technologiesfor network and service management and software architectures for networked multimedia systems.

Cristina Aurrecoechea is a Principal Technical Staff Member at AT&T Labs West, currentlyworking on the Geoplex project. In 1984, she received the M.Sc. in IEOR-Power Systems from theUniversity of the Basque Country, Spain, and in 1986 she graduated in Business Administration andFinances from the University de Deusto in Spain. She worked for Telefonica Espana from 1987 to1991 on management of data networks, and joined the COMET group at the Center for Telecommu-nications Research at Columbia University in 1992. She graduated from Columbia University witha Ph.D. degree in Electrical Engineering in 1999.

Documents

Building Manageable Multimedia Network Services