These abstractions are used by the services and applications network for ..... A device management service whose main role is to check for the existence and.
Service Creation, Renegotiation and Adaptive Transport for Multimedia Networking Mun Choon Chan, Jean-François Huard, Aurel A. Lazar and Koon-Seng Lim Department of Electrical Engineering and Center for Telecommunications Research Columbia University, New York, NY 10027-6699 CU/CTR TR 460-96-26
Abstract In this paper, we describe a prototype implementation of the Binding Architecture [1], an open architecture that achieves seamless binding between networking and multimedia devices for the purpose of creating distributed multimedia services. As a proof of concept, a multi-party teleconferencing service was built. The service creation framework has the following characteristics: binding of different classes of transport protocols with adaptive capabilities to the application, dynamic renegotiation of application QOS using the signalling network and, support for multiple resource reservation algorithms in parallel.
1. Introduction The Binding Architecture [1] for multimedia networks is an open architecture that achieves seamless binding between networking and multimedia devices for the purpose of creating distributed multimedia services. The architecture consists of an organized collection of interfaces which we termed the Binding Interface Base [2] (BIB), and a set of algorithms that run on top of these. BIB interfaces provide open and uniform access to abstractions that model the ‘local’ states of multimedia networking resources. Algorithms, on the other hand, provide useful services which are constructed by binding together multimedia and networking resources. Note that since all forms of resource reservation can be thought of as a consistent manipulation of some distributed states in a system, the Binding Architecture can therefore be viewed as a control system for manipulating distributed states. In this paper, we describe a prototype implementation of this architecture, in the form of a toolkit that allows complex multimedia services to be readily assembled by binding together a number of objects. As a proof of concept, a multi-party teleconferencing service was built using this toolkit. The paper is organized as follow. In section 2, we briefly described the overall architectural model. In section 3, we focus on the design and realization of the G-model, and in section 4, details of the implementation are presented.
Page 1 of 19
2. Modeling the Multimedia Network In this section we will start our presentation by briefly reviewing our architectural networking model called the XRM. This will be followed by a description of the Binding Model and its embedding into the XRM. We will close this section by discussing the problem of modeling resources using QOS abstractions.
2.1 RGB Decomposition of the XRM The XRM models the communications architecture of networking and multimedia computing platforms. It consists of 3 components called, the Broadband Network, the Multimedia Network and the Services and Applications Network (see Figure 1). The broadband network is defined as the physical network that consists of switching and communication equipment and multimedia enddevices. Upon this physical infrastructure, resides the multimedia network whose primary function is to provide the middleware support needed to realize services with end-to-end QOS guarantees over the physical media-unaware network. This is achieved by building upon a set of QOS abstractions derived from the broadband network . The set of QOS abstractions jointly define the resource management and control space. The process of service creation calls for resource reservation and distributed state manipulation algorithms. From this perspective, the multimedia network provides a programming model that allows service behavior to be specified and executed. Service abstractions represent the states of a service created using algorithms native to the multimedia network. These abstractions are used by the services and applications network for managing and creating new services through dynamic composition and binding.
B
Services and Applications Network Service Abstractions
The Multimedia Network G
Binding Algorithms Binding Interface Base
Programming Model
QOS Abstractions
R
The Broadband Network FIGURE 1. Overview of the RGB Decomposition of the XRM
The 3 component networks of the model above can be refined further. As shown in Figure 2, each of the original RGB component networks is decomposed into five planes. The decomposition results in 3 submodels collectively known as the RGB decomposition. The RGB decomposition represents detailed viewpoints of the broadband network, the multimedia network and the services and applications network, respectively. The interface between R-, and G-models is a set of QOS abstractions typically structured as graphs that quantitatively represent various resources in the physical network. The G-model uses these graphs for creating service abstractions that are provided to the B-model for building more complex services. Thus, the interface between the R- and G-models and the interface between the G- and B-models provide abstrac-
Page 2 of 19
tions that are similar in structure but differ in usage. For more details on the RGB decomposition please refer to [12].
G
R N-plane
B N-plane Auditing Monitoring Services Controlling Services Billing
N-plane
Monitoring Individual States Controlling Individual States
QOS Abstractions
Resource Control M-plane (buffer and memory management, flow control) (link and OS scheduling)
D-plane Global Distributed Memory Network Objects and Media Processor Objects (MIB)
C-plane Signalling (supports, e.g., distributed scheduling)
U-plane
Synchronization M-plane Resource Control (Routing, Admission Control)
D-plane
Binding Interface Base Directories Naming
Stream Control C-plane Connection Management Binding
Service Abstractions
Monitoring Planes Controlling Planes
M-plane Control of Services
MM Mail CSCW Information Gateways VOD PVM
C-plane Service Creation Tools Navigation Tools
U-plane
U-plane
AAL Protocols
Application Protocols
Media Stream Protocols
Broadband Network
Multimedia Network
D-plane
Services and Applications Network
FIGURE 2. The RGB Decomposition of the XRM
2.2 The Binding Model The Binding Model defines a conceptual framework for the creation, deployment and management of multimedia services on ATM-based broadband networks with end-to-end QOS guarantees. Binding refers to the activity of creating a requested multimedia service with QOS guarantees. It entails the association of a set of network and end system resources with a media transport protocol and the service management system. The Binding Model gives the XRM:G its operational capability through a model of service creation. In this context, service creation is defined as a process of object composition whereby objects are manipulated by algorithms residing in various XRM:G-planes. The Binding Model describes how to marshall and compose resources into network services starting with services offered at the R||G interface. There are a number of services provided at the R||G interface including the physical connection graph and the multimedia networking capacity graph (Figure 3). These will be described further in the next section. Overall, the Binding Model consists of two building blocks: a set of (enveloped) states that can be accessed through the BIB and a set of binding algorithms operating on these interfaces. The two building blocks structure of the Binding Model is justified through a separation principle. This principle gives a clear focus towards what should be and what needs to be standardized within the
Page 3 of 19
XRM:G. Our proposal is to standardize the access to the BIB and leave the algorithms and the service creation proprietary. The BIB is a repository of interfaces modeling the access to resources such as switches, links, multimedia devices, etc. Within the XRM, the BIB is located in the Telebase (G:D-plane). The physical connection graph and the multimedia capacity graphs are both logically represented in the BIB. At the G||B interface, the XRM:G model also offers a number of network services. Among others, we mention, virtual circuits, virtual paths [28], virtual networks [29] and multicast [30]. The reader is recommended to consult these references for details.
2.3 QOS Abstractions for End-to-End QOS The Binding Model captures the topology of the network with the physical connection graph. This graph carries connectivity information regarding all network resources, as well as the capacity of each resource. For example, the links are specified in Mb/s whereas processors are specified in MIPS. Unfortunately, this characterization of the network does not have an operational significance when determining end-to-end QOS of multimedia flows. For the purpose of QOS characterization, resources are divided into two categories: media transporters and media processors. The former are network resources such as switches and links, and the latter are end-point resources such as CPUs, storage media, cameras, microphones, and speakers. In [16], the schedulable region concept was established for providing QOS in the network. In the end system, a similar concept, namely the multimedia capacity region concept was formulated in [14]. When interconnected, the schedulable regions and multimedia capacity regions form a networking capacity graph (see Figure 3). The networking capacity graph is a QOS abstraction of the network. It is created by associating a networking capacity region to each link and end-point of the physical connection graph. Guaranteeing QOS at the call level is the job of the admission controller. A call can be admitted into the network only if the requested end-to-end QOS can be provided without violating the QOS agreement made with existing calls. The admission controller must ensure that a data flow can be established through all networking capacity regions on the route between the source and destination. For example, in Figure 3, the flow goes through the multimedia capacity region at the source (SRC), then the schedulable regions between nodes A and B, and B and C, and finally through the multimedia capacity region at the destination (DEST). The flow will be accepted only if, for each networking capacity region, the new operating point is inside the networking capacity region.
3. Realization of the G-Model The G-model of the XRM realizes the functionality of the multimedia network. To recapitulate, the role of the G-Model is one of mapping the services provided by the R-Model (QOS abstractions) into network services provided to the B-Model at the G||B interface. A multimedia service is created in the process of this mapping. There are two views to the service creation process. The service (or local) view describes the sequence of steps perform in the creation of a particular ser-
Page 4 of 19
Schedulable Region DEST C
B
A
SRC
Multimedia Capacity Region FIGURE 3. The Networking Capacity Graph
vice. The network view of service creation describes how binding algorithms that participate in the process of service creation interact and co-exist in the G-Model. The process of service creation consists of generating, starting from a set of objects (states) residing in the BIB, another set of objects (states). The generation process is executed by a Service Provisioning Entity. Multiple such entities execute in parallel and in a distributed fashion. The role of the Binding Model is to define the overall organization of distributed operations for service creation. These operations or services can be used to create other services. All operations reside in the N-, M-, C- and U-planes. Figure 4 shows the distributed nature of BIB interactions, and suggests possible distributed interactions among different binding algorithms during the service creation process. Binding algorithms arise in connection set up for broadband networks, distributed systems implementing synchronization protocols, resource allocation protocols such as routing, multimedia computing platforms, etc. New applications can be supported without changing the underlying binding model. In addition, several proprietary binding algorithms can operate at the same time.
Page 5 of 19
BIBI = BIB Interface
G::M- or C- Plane Algorithms
G:: D- Plane BIBI BIBI
BIBI BIBI R || G QOS Abstractions
G || B Service Abstractions
FIGURE 4. Network View of the Service Creation Process
In the rest of this section, the service view is first presented, followed by the network view. In the latter, we will only describe the C- and U-plane aspects of the network view.
3.1 The Service View of the Service Creation Process The service (or local) view towards the service creation process highlights the steps that lead to the creation of the service. The process of service creation consists of five steps:
1. create a service skeleton for an application such as a virtual circuit, virtual path, virtual network or multicast. The structure of the skeleton for a virtual circuit, for example, consists of a graph from a source node to destination; 2. map the skeleton into the appropriate name and resource space and thereby create a network application; 3. associate (bind) to the application a media transport (stream) protocol and thereby create a transport application; 4. bind the transport application to resources and thereby create a network service; 5. bind the service management system to the network service and thereby create a managed service. Figure 5 illustrates the individual service view of the service creation process. First a skeleton is created using name and resource mapping services. The resulting network application is bound to a transport protocol, resources and service management. When a service is required, the application process issues a service request to the responsible service provisioning entity that in response will invoke the corresponding binding algorithm(s) for establishing a service instance. This simple view of the service creation process is surprisingly complete. For example, familiar algorithms such as routing belong to step 2, connection management and admission control to
Page 6 of 19
Stream Protocol Binding
Resource Reservation and Binding
Service Skeleton
Name and Resource Mapping Binding
Service Management Binding
FIGURE 5. Service View of the Service Creation Process.
step 3, and transport protocol selection to step 4 of the above process. In Section 3.2 and Section 3.3 we describe each of these algorithms in greater detail. Based on the service creation process described above, we define the following object framework for service creation [12]. Services are offered by servers which support the creation and maintenance of their state. When a request for a service is made to a server, a service instance is instantiated or created. Each service instance is composed of an algorithmic part and a data part. The algorithmic part expresses the logic of the service instance while the data portion is an abstraction of its state. Individual service instances can be customized by modifying the logic of its algorithmic part. Similarly control can be effected on an executing service instance by the modification of its states. Servers also have an algorithmic component which specifies how service instances are created, deployed and managed and a data part which models the state of the server and its policies. Typical servers expose 4 interfaces. These are the Service Factory interface, the Service Programming interface, the Service Control interface and the Service Management interface. The service factory interface is used to request the creation of a service instance. The service programming interface allows customization or modifications to be made to the algorithmic component of the server or service instance. The service control interface is the operational interface to the service instance and allows the monitoring and manipulation of service instance states during execution. Finally the service management interface allows for monitoring and control of the server and the setting of management policies as Figure 6 below illustrates.
Page 7 of 19
Logical Name Mapping Resource Reservation Transport Selection
Service Control
Server States
Service Skeleton
Scripts
Script Scripts
Service Programming
Service Factory
service instance Service Management
FIGURE 6. Interfaces for Multimedia Distribution Services
It is possible for some services to have no state (e.g., a simple database lookup service). Such services do not create instances and have only factory and logic interfaces.
3.2 Connection Management and Renegotiation The Connection Manager is the coordinator that enables the creation of connection services and resides on the C-plane. On a lower level, the functionalities performed by the connection manager can be broadly divided into two groups: reserving identifiers and setting these identifiers in the network fabric for cell transports, and reserving of system resources (buffer, bandwidth, CPU cycles, etc.). We have defined a set of interfaces (or APIs) for ATM switches that provide a generic abstraction that allows these functions to be performed [3]. With this set of switch APIs, we are able to implement a very large class of connection management algorithms. This class of algorithms is described by the four sub-tasks it performs: route selection, resource reservation, states saving, and renegotiation. In addition, we have the following objectives in mind. First, control logic and policy should be, as far as possible, parameterized and thus can be changed during run-time. Second, multiple connection schemes should be allowed to run simultaneously in the network. There are two extremes to route selection: source routing, and hop-by-hop routing. In source routing, the route object is consulted just once and the route is completely specified. In hop-byhop routing, the route object provides just sufficient information such that progress can be made only to the next hop. In between these two approaches, any combination is possible. Domain routing falls under this category, where a number of routers cooperate to specify the route. For example, the PNNI approach to routing can be explained in terms of a high-level router that specifies a set of intermediate hops and the sub-domain routers cooperate to specify the rest. The connection manager should be able to handle any route selection style.
Page 8 of 19
A straight forward resource reservation approach is to reserve sufficient resource such that QOS constraints can be satisfied. Besides this approach, a number of other approaches have been proposed. In [24], resources along multiple routes are reserved simultaneously during the reservation process. In [28], excess resources are reserved along a single route so that the resulting queue delay can be much smaller than the required delay constraints. If one of these approaches is taken, the connection manager has to release excess resource reserved so as to achieve a good utilization of system resource. When a connection has been successfully setup, the state of this connection must be kept. Our approach is to keep the connection states only in the switches. Each switch keeps sufficient information so that from any switch that a connection passed through, the entire route can be discovered by tracing forward and/or backward. The connection manager(s) is (are) allowed to cache this information, but the assumption must be that these information can be made invalid, for example if the connection has been released by another connection manager. During the life time of a connection, renegotiation may be performed. Renegotiation can be performed either when the application explicitly request change or triggered automatically when QOS violation is detected. A number of approaches are possible (e.g. [25], [26],[27]). In [25] and [26], a layered approach is taken. In [26], the QOS management system is decomposed into three logical layers. If at any level a QOS requirement cannot be met, a renegotiation may occur to try to meet a lower level of QOS. This renegotiation may be determined by the maximum and minimum requirements and/or by some default degradation paths. During the lifetime of a connection, the strategy for QOS adaption is to recover from QOS violation as much as possible in a way transparent to the higher layers. If this fails, the layer indicates a QOS failure to the next higher layer. When the highest layer fails to negotiate satisfactory QOS, the application either fails or request intervention from the human user in the form of a revised QOS requirements. In [25], in addition to layering, renegotiation functionalities is also divided into two planes. The QOS maintenance plane performs medium time scale adjustment of resource allocation in response to minor QOS variation. On a slow time scale, the flow management plane performs coarse grain adjustment. Our approach to renegotiation differs from the above mentioned approach in that we do not use a layered approach. Instead, there is only one resource abstraction (e.g., the scheduleable region, multimedia capacity region) per device or host. For an end-to-end connection, these abstraction may be different from hop to hop (the resource abstraction on a switch is different from the abstraction on a workstation). A QOS mapper is used to translate among the different abstractions. In addition to application requests and QOS violations, renegotiation can also be triggered by a change in the size of the (estimated) capacity region. Change in the size of a resource capacity can affect many connections simultaneously. Currently, we are looking into distributed algorithms that can handle such negotiations without the applications’ intervention.
3.3 Object-Oriented Information Transport Our work on the U-plane, or the information transport plane, focuses on the mechanisms needed in the transport protocol for guaranteeing end-to-end QOS. By this we mean mechanisms such as QOS mapping between application QOS and network QOS; QOS monitoring and adaptation of the media stream; and finally a QOS-based transport API for provisioning, renegotiation and media transfer.
Page 9 of 19
To satisfy the above requirements, three transport components were designed: qStack, a transport protocol for real-time communications that performs QOS monitoring and adaptation on a fast time scale; TP, a transport class with a QOS-based transport API that supports multiple transport protocol suites; and finally TC, a transport controller responsible for the slow time scale operations such as long-term QOS monitoring (for management), QOS violation detection and QOS renegotiation. The transport architecture is illustrated in Figure 7. Before describing each of these components, we first describe the transport services offered to applications.
3.3.1 Transport Services
Sender
E Adaptation
Rate adaptation Flow control
Receiver
TC App
App
TP
TP
Net
D Monitoring Delay/Loss/Rate
Net
Network
feedback
FIGURE 7. Feedback Paths for the Information Transport: via Signalling (TC) and InFlow.
The information transport offers multimedia services with QOS specified per-session in application level terminology (e.g., motion JPEG, MPEG video and CD quality audio) and non real-time services such as reliable data transfer. The QOS parameters are expressed in terms of application level terminology. For real-time services they are the frame loss rate, frame gap loss, frame delay, frame peak rate and the maximum frame size. For non real-time services, they are the average throughput, average delay, maximum packet rate and the maximum packet size. Only losses and delays represent QOS. These parameters are monitored by the receivers. Other parameters represent traffic descriptors and are used for regulating the media flow at the senders. The reader is referred to [13] for more details.
Page 10 of 19
3.3.2 qStack: A Transport Protocol with QOS Support qStack is a light, real-time transport protocol that performs in-flow QOS monitoring and adaptation at the frame level (end-to-end). For QOS adaptation, each connection requires a feedback channel. Furthermore, a handshaking mechanism to synchronize the clocks, negotiate the mutt size and the initial sequence number is provided. The clock synchronization mechanism is similar to ntp [31] and is required for the end-to-end frame delay measurements. For monitoring, a sequence number and a time stamp are added to each (application) frame (not TPDU). For each QOS parameter, the minimum, maximum and average values are monitored. On the fast time scale, the averages are estimated over a measurement era of N frames. For slow time scale monitoring (see Section 3.3.4) these measurements are accumulated and can be polled at any time. Overlapping windows are used to perform accurate QOS violation detection. At the end of each window, if the QOS measurements show that the QOS is violated, a notification is sent to the sender via the feedback channel or to TC via signalling depending upon the kind of violation. For example, feedback is used for adjusting the frame rate whereas the signalling system is used for notifying the network that too many losses occurred. The adaptation mechanisms in qStack are limited. It can regulate the frame rate and peak rate at which the sender transmits the frames. If QOS violation is sustained more than a pre-determined time, the application (or the transport controller; see below) is notified by an upstream call. qStack was originally developed for real-time applications using the AAL5/ATM protocol suite. It can also be used with UDP/IP.
3.3.3 Transport Protocol Object The purpose of a transport protocol class (or object) is to shield the application developer from the complexity of QOS control and management. Furthermore, we believe that the application programmer should not be constrained by the choice the transport protocol. With this goal in mind, we designed a C++ transport class (TP) that supports multiple transport protocol suites. It has a well-defined CORBA-IDL interface based on a QOS-based transport API [13]. It was designed to be used as a base class for multimedia applications implemented in C++ (e.g., devices in the xbind framework). TP’s API is simple; it has calls for QOS provisioning, QOS control (renegotiation and violation notification), media transfer and supports both unicast and multicast connections. TP is a “wrapper” class that permits us to support many protocol suites transparently, i.e., without the application having to be rewritten every time we wish to use a different transport protocol. TP uses the signalling for adaptation on the slow time scale. It polls at regular intervals the transport protocol for QOS violations. When a QOS violation is detected (i.e., last for more than some pre-determined time period,) TP notifies the transport controller via signalling. When sustained QOS violations occur, the application can be notified via an upstream call.
3.3.4 Transport Controller The transport controller (TC) is a transport service (server) responsible of the slow time scale transport operation of a set of TP. In particular it is responsible of initiating QOS renegotiation when QOS violations occur. At regular interval it polls all of its TP’s active connections for longterm monitoring (for management purpose). If a transport protocol is not specified by the service
Page 11 of 19
manager (e.g., a conference manager), TC is then responsible of selecting an appropriate transport protocol based on the QOS requirements and availability of resources. To summarize the three information transport components: the protocol stacks are responsible for the in-flow (fast time scale) QOS monitoring at the application level (end-to-end) and some flow control (rate control) adaptation; the transport protocol object (TP) has a well-defined QOSbased API and maps the various transport calls to the appropriate one in the various supported transport protocol suites; finally, the transport controller deals with the slow time scale transport operations such as QOS renegotiation and QOS monitoring for network management. There are two feedback paths (see Figure 7): one for the fast time scale adaptation (flow control and rate regulation) between the sender and a receiver in the protocol stack and one for the slow time scale adaptation (QOS renegotiation) via signalling or TC. The main characteristic of our transport architecture is that it is not layered in the OSI sense [27]. The various mechanisms directly communicate for providing QOS. For a review of other models that provide QOS, see [17], [18], [19], [20] and the references therein.
4. Prototype Implementation: xbind 2.0 In this section, we describe a prototype implementation of the G-model, xbind 2.0 [3]. xbind 2.0 is a second generation middleware toolkit that allows complex multimedia services to be readily assembled by binding together a number of simple objects. It is implemented in CORBA and uses Iona Technologies Orbix 2.0 [11] as the distributed computing platform. We begin by describing the high level system architecture following descriptions of the major system services. Finally, we present the implementation of a client application, a multi-party teleconferencing service, built on top of this toolkit that supports dynamic bandwidth renegotiation, per-connection selectable transport and real-time QOS monitoring and control functionality.
4.1 System Architecture Figure 8 gives the high level system architecture of xbind 2.0. The system comprises of 5 functional layers. At the lowest layer is the physical hardware that make up the system. Above this lie the Binding Interface Base, a collection of CORBA interfaces that offers an abstract view of resources in the Binding Architecture. These include naming resources like ATM Virtual Circuit Identifiers (VCIs) or physical resources like multimedia devices. Calls are made to these interfaces to bind the underlying resources to create low level services, i.e., broadband kernel services. Upon these, network services are built. Examples of the former include routing and device management, and of the latter, virtual circuits, virtual paths and virtual networks. These services are used to build the multimedia services layer. The multimedia services layer consists of very high level services for multimedia content search, retrieval, distribution and interaction. These include conference management services, multimedia agent-based services, Java [8], [9] and the World Wide Web (WWW) enabled services. At the highest layer of the architecture lie the user level applications which may be WWW browsers or conventional interactive applications.
4.2 System Services Figure 9 shows the detailed view of the broadband kernel services plane. In order to support a complex service such as the xbind teleconferencing service, a number of sub-services are needed. These include:
Page 12 of 19
B::D
lic at io ns
Java-xbind
CameraDevice
Display
R||G
Camera Adapter
Link
Switch
er vi ce lS as e eB
In g in
VirtualLink
Link
Adapter
Host
Hardware
VirtualLink
VirtualSwitch
nd
VirtualLink 0 VirtualLink
Bi
G::D
VirtualSwitch
te r
DisplaylDevice VirtualSwitch
Host
fa c
Router
Br oa db
DeviceMgr TransportMgr
Software
QOSMapper
an d
G||B
ConnectionMgr
K er ne
M
TeleConfMgr
s
ul tim ed
ia
Se
B::C
rv ic e
s
Ap p
WWW server
FIGURE 8. High Level System Architecture
1. A device management service whose main role is to check for the existence and compatibility of multimedia end devices involved in a conference, 2. A transport management service for real-time QOS monitoring and control during the lifetime of a conference, 3. A connection management service for connection setup, resource control and renegotiation, 4. A route management service for determining the best physical route between source and destination endpoints during the connection setup process, and 5. A QOS mapping service for translating between user or application level QOS parameters and network level QOS. The teleconference session manager upon receiving a request (point 1) from a user through its factory interface creates an instance of the service skeleton. It then queries the device manager (point 2) of each host involved in the conference to see if any devices capable of supporting the requested type of media stream exist. After this, the teleconference manager initializes the transport managers at each of the hosts who in turn initialize the transport stack component of the corresponding devices. A connection setup request (point 3) is then made to the connection manager who in turns queries the QOS mapping service (point 3.2) for a translation between the transport level QOS specified by the BIB components. The connection manager also makes a request to the route manager (point 3.1) for a physical route that the connection must traverse. Once this has been obtained, the connection manager will proceed to each host (virtual switches/links) along the route to reserve the corresponding resources required for the connection (point 3.3). The connection setup process completes with the connection manager returning
Page 13 of 19
back to the teleconference manager a pair of VPI/VCIs representing the entry and egress points to the connection that it has established. At this point, the teleconference manager proceeds to inform the two transport managers (point 4) at both endpoints to open the associated network interface device using the VPI/VCI pair and gets in return a unique connection identifier which it finally passes to the device (point 5). This connection identifier serves to abstract away any details about the transport protocol (such as the actual VPI/VCI pair or transport stack in use) from the device so that different simultaneous transport stacks can be used by the same device without any change required. Once this is completed, a session is said to have been established and a multimedia stream generated at the source device can be carried over the network to the destination device using the specified transport protocol. During the lifetime of the connection, the transport manager at the receiving device periodically monitors the device for any violation of QOS parameters. In the situation where this happens continuously, the transport manager may initiate a renegotiation request to the teleconference manager (point B) who would in turn request the transport manager (point C) of the transmitting device to reduce its rate. This manager would in turn interact with the device (point A) to effect the rate control. Alternatively, if the receiving device has a reverse feedback channel (as maybe required by some protocols) to the transmitting device, then the receiving device can notify the transmitting device of the violations directly. Still another alternative is when the user requests for a change in the grade of service. In this case, the teleconference manager would need to issue a renegotiation request (point D) to the connection manager who would then attempt to renegotiate for new resources via the route manager, QOS mapper and the respective hosts. The other interfaces (management and programmability) of the teleconference manager exist so that a service manager can monitor and control service creation policies of the server on-the-fly.
1.
Route Manager TeleConference Manager
QOS Mapper
3.
3.1
D.
B.
3.2
4. Connection Manager
C. E.
3.3
5.
F.
Transport Manager
2. A. 0.
Device Manager
4.1
Service Manager
VirtualSwitches/Links
VirtualDevices
FIGURE 9. Teleconferencing Service Architecture
Page 14 of 19
In the remainder of this section, we will describe each of these services in greater detail beginning with the connection manager.
4.2.1 Connection Manager The connection manager is responsible for connection-related operations (add, remove a connection, renegotiation of resources, etc.). Todate only unicast connections have been considered for implementation. In order for the connection manager to perform its task, it needs the services of a route manger which provide a list of possible routes between the source and destination node, a QOS mapper that translates resource requirements between transport level and network level and vice versa, and a node server which exports all the necessary interfaces for setting up switch routing tables and reserve resources. The scope of the connection manager is end-to-end in the sense that it communicates with the host machines on both ends of a connection during setup. The successful completion of a connection setup returns a transport connection data structure that contains a file descriptor that can be used by the application. A connection manager can reside on any host computer. We have implemented both “stateful” and “stateless” connection managers. We allow add, remove or renegotiation of a connection to be performed by different connection managers.
4.2.2 Route Manager The route manager implements minimum weight routing with delay constraints. The route manager keeps a data structure that contains the network topology and for each link, its weight and delay. Various weight parameters have been experimented with on a prototype implementation [29] (hop count, bandwidth, and utilization, etc.). If there is no route between two host where the sum of link delays is less than the delay constraint, the two hosts are considered unreachable from each other, even though link bandwidth may be available. The route manager implemented is passive. It only recomputes a new set of routes on request. There can be multiple copies of route manager running simultaneously.
4.2.3 Node Server The node server is a container object that groups the implementation of the VirtualSwitch interface, VirtualLink interface and, VirtualCPUs interfaces into a single object. The implementation of the VirtualSwitch interface is a software component that provides the abstraction that allows xbind to run directly on physical switches. Three types of switches are used here: Fore ASX100, Fore ASX200 and Nec Model 5. A variant of the VirtualSwitch interface is the adapter interface that provides access to an ATM adapter card. In our environment, all machines are equipped with the FORE SBA-200 adaptor card. An adapter object can be thought of as a switch object that does not perform any routing table management functions. The functions performed by these two objects are similar. The node server keeps the state of connection passing through the switch. Other objects (like the connection manager) may cache this information for efficiency reason. For reasons of robustness, we are looking into implementing a version of the node server where the connection state are made persistent by saving them into a file. When a node server boots up, it reads the connection state contained in this file. Thus, in the event that the node server crashes, it can be restarted with no (or minimum) loss of state information.
Page 15 of 19
4.2.4 QOS Mapper The QOS mapper is responsible for mapping the application level QOS into (COMET classes) network level QOS. In terms of COMET classes, all the video services are mapped into class I, audio into class II and reliable data into class III. For details on the class mapping, please see [13]. For parameter mapping, the current mapper does only simple rescaling of parameters based on the ratio of the maximum frame size to cell. Furthermore, the mapper currently only supports network-transport mapping. Ongoing work is currently underway for realizing application-transport and user-to-application QOS mapping.
4.2.5 Transport Controller (TC) The transport controller (TC) implements QOS monitoring on the slow time scale. There is one TC per end system (workstation). Every five seconds, it polls every connection it is responsible of monitoring (using tp_query) and gathers network management statistics. Upon a continuous QOS violation, it notifies the appropriate service manager (the conference manager in the application example of Section 4.3). The service manager can then decide to initiate QOS renegotiation or to ignore the notification based on some control rule it may have. TC also monitors each connection to see whether it is active or not. If it has been inactive for more than 2 minutes, it stores it, assuming that the application (device) has crashed.
4.2.6 Transport Protocol Base Class (TP) This object is responsible for monitoring all the established connections of a device. For each connection, it maintains all QOS monitoring information described in Section 3.3.2. The object is aware of many transport protocols. The protocols currently supported are qStack (our real-time protocol over AAL5/ATM or UDP/IP) and a native-mode ATM protocol stack [32]. TP hides from the application all the complexity of the QOS provisioning and control. The only common identifier with the application is the connection identifier and the Send and Recv calls. For provisioning, TP is invoked from TC. When a call is established, an end-point identifier, a protocol stack and a service type are required. TP returns the connection identifier to be used in subsequent transport calls (Send, Recv, Release, set QOS, queryQOS).
4.2.7 Device Manager The device manager is responsible for tracking the capabilities of all multimedia devices on a particular host. Currently 4 categories of multimedia devices are supported. These are audio input devices such as microphones, audio output devices such as speakers, video input devices such as cameras and video output devices such as displays. Each of these devices in turn may support a number of media formats, rates or options. A camera device for example, may support a particular kind of video encoding format at a particular window size from a particular video source. When a device initializes during the bootup process, it registers with the device manager and passes to it a sequence of data structures describing all the formats, rates and options it supports. Thus at any time, the device manager is aware of all the details of each device available on its host. When a device terminates due to an error or is killed, it also attempts to deregister itself from the device manager. The device manager on its own accord polls the devices on a regular basis to ascertain that it is still available.
Page 16 of 19
4.3 The Client Application Figure 10 below shows a screen dump of the user interface of the xbind teleconferencing service. Essentially, the interface is realized as a single Java applet with communications to the back-end CORBA-based teleconference manager achieved using Iona Technologies’ OrbixWeb [10] toolkit. The toolkit includes a compiler that automatically generates a Java proxy class from an IDL interface and a set of Java libraries that implement the Internet Inter-ORB Protocol (IIOP) feature of CORBA 2.0 for applet-to-ORB communication. The role of the applet is thus merely to collect user input and to make the appropriate CORBA invocations to the teleconference manager when the user confirms his selection. As there is currently no simple way of allowing communication in the reverse direction (i.e., for the back-end server to call the front-end applet), the relationship between the applet and CORBA server is currently restricted to only client and server, respectively.
FIGURE 10. Figure 2. xbind Tele Conferencing Service Applet
5. Future Work We see a lot of new possibilities for interesting future work. These possibilities include expanding existing services on the C- and U-plane, e.g., supporting more protocol stacks and reservation protocols (e.g., RSVP). We are also looking at adding new services and extending the functionalities of the existing teleconferencing application. In addition, we would also like to have a more complete implementation of the G-model by integrating additional related work within the COMET group into the prototype. These include scalable multi-cast and, QOS estimation and adapation within the ATM switch control software.
6. References [1]
Lazar, A.A., Bhonsle, S. and Lim, K.S., “A Binding Architecture for Multimedia Networks”, Journal of Parallel and Distributed Computing, Vol. 30, No. 2, Nov. 1995, pp. 204-216.
[2]
Lazar, A.A., Lim, K.S. and Marconcini, F., “Realizing a Foundation for Programmability of ATM Networks with the Binding Architecture”, IEEE Journal of Selected Areas in Communi-
Page 17 of 19
cations, Special Issue on Distributed Multimedia Systems, Vol. 14, No. 7, September 1996. [3]
Project xbind, http://www.ctr.columbia.edu/comet/xbind/xbind.html
[4]
Lazar, A.A., Lim, K.S. and Marconcini, F., “Binding Model: Motivation and Description.” CTR Technical Report #411-95-17, Center for Telecommunications Research, Columbia University, New York, June 1995. Available under URL: http://www.ctr.columbia.edu/comet/xbind/ xbind.html.
[5]
OMG, The Common Object Request Broker: Architecture and Specification, Rev. 1.2, Dec. 1993.
[6]
TINA-C, Service Architecture Version 2.0, Document No. TB_MDC.012_2.0_94, Mar. 1995.
[7]
Barr, W. J., Boyd, T. and Inoue, Y., “The TINA Initiative,” IEEE Communications Mag., Mar. 1993.
[8]
Sun Microsystems, The Java Language Environment, White Paper, Mountain View, CA, Oct. 1995.
[9]
Sun Microsystems Inc., The Java Language Specification. Version 1.0 Beta, Mountain View, CA, October 1995.
[10] Iona Technologies Ltd., Orbix for Java, White Paper, Cambridge MA., Feb. 1996. [11] Iona Technologies Ltd., Programmers Guide, Orbix 2.0, http://www.iona.ie, July 1995. [12] Lazar, A.A. and Lim, K.-S., “Programmability and Service Creation for Multimedia Networks.” In Proceedings of the Fifth International Symposium on High Performance Distributed Computing, Syracuse, NY, Aug. 1996. [13] Huard, J.-F., Inoue, I., Lazar, A.A., and Yamanaka, H., “Meeting QOS Guarantees by Endto-End QOS Monitoring and Adaptation.” In Proceedings of the Fifth International Symposium on High Performance Distributed Computing, Syracuse, NY, Aug. 1996. [14] Lazar A.A., Ngoh, L.H., and Sahai, A., “Multimedia networking abstractions with quality of service guarantees.” In Proceedings of the SPIE Conference on Multimedia Computing and networking, San Jose, CA, Feb. 1995. [15] Lazar, A.A. and Pacifici, G., “Control of Resources in Broadband networks with Quality of Service Guarantees.”, IEEE Communications Mag., Vol, 29, No. 10, Oct. 1991. [16] Hyman, J.M., Lazar, A.A. and Pacifici, G., “Real-Time Scheduling with Quality of Service Constraints.” IEEE Journal of Selected Areas in Communications Vol 9, No. 7, Sept. 1991. [17] Aurrecoechea, C., Campbell, A. and Hauw, L. “A Review of QoS Architectures.” In 4th International Workshop on Quality of Service, Mar. 1996. [18] Banerjea, A. Ferrari, D. Mah, B.A., Moran, M., Verma, D.C., and Zhang, H., “The Tenet Real-time Protocol SuiteL Design Implementation and Experiences.” IEEE/ACM Trans. Networking, Vol. 4, No. 1, Feb., 1996. [19] Campbell, A.T., “Towards End-to-End Programmability for QoS Controlled Mobility in ATM Networks and their Wireless Extensions.” In 3rd International Workshop on Mobile Multimedia Communications, Finland, Sept. 1996. [20] Campbell A., Eleftheriadis A., and Aurrecoechea, C., “End-to-End QoS Management of Adaptive Flows.”, In IEEE Symposium of Multimedia Communications and Video Coding,
Page 18 of 19
Oct. 1995. [21] Crutcher L.A. and Waters A.G., “Connection management for an ATM network.” IEEE Network, vol. 6, pp. 42-55, Nov. 1992. [22] Campbell, A., Coulson, G. and Hutchison, D., “A Quality of Service Architecture.” ACM SIGCOMM Computer Communication Review, 1994, 6-27 [23] Seneviratne, A., Fry, M., Withana, V., Saparamdu, V., Richards, A. and Horlait, E., “Quality of Service Management for Distributed Multimedia Applications.” In Proceedings of the 1994 IEEE 13th Annual International Phoenix Conference on Computers and Communication, 1994, pp. 434-439 [24] Tawbi, W., Fedaoui, L., and Horlait, E., “Management of Multimedia Applications QOS on ATM Networks.” International Conference on Computer Networks: Architectures and Applications, Elseriver Science, North-Holland, pp.15-26. [25] Parris, C., Zhang, H., and Ferrari, D., “Dynamic Management of Guaranteed-Performance Multimedia Connections.” Multimedia Systems, No. 1, 1994, pp. 267-283. [26] Chan, M.C., Pacifici G., and Stadler, R., “Prototyping network architectures on a supercomputer.” In Proceedings of the Fifth International Symposium on High Performance Distributed Computing (HPDC-5), Syracuse, NY, Aug.1996. [27] Schwartz, M. Telecommunication Networks: Protocols, Modeling and Analysis. AddisonWesley, Reading, Mass. 1987. [28] Aneroussis, N.G. and Lazar, A.A., “Managing Virtual Paths on XUNET III: Architecture, Experimental Platform and Performance.”. In Proceedings of Fourth International Symposium on Integrated Network Management, Santa Barbara, CA, May 1-5, 1995, pp. 370-384. [29] Chan, M.C., Hadama, H. and Stadler. R., “An Architecture for Broadband Virtual Networks under Customer Control”, IEEE Network Operations and Management Symposium (NOMS’96), April 1996, Kyoto, Japan. [30] Aurrecoechea, C. Campbell, A., Hadama, H. and Hauw, L., “A Model for Multicast in the Binding Architecture”, CTR Technical Report #413-95-19, Center for Telecommunications Research, Columbia University, New York, May 1995. [31] Mills, D.L., “Network Time Protocol (version 3): Specification, Implementation and Analysis.” IETF RFC 1305, Mar. 1992. [32] Ahuja, R., Keshav, and S., Saran, H. “Design, Implementation and Performance of a Native Mode ATM Transport Layer.” In Proc. of IEEE Infocom, San Francisco, CA, Mar. 1996. Extended version to appear in IEEE/ACM Trans. on Networking.
Page 19 of 19
