Note: Descriptions are shown in the official language in which they were submitted.
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
1
METHOD AND SYSTEM FOR PROVIDING MULTIMEDIA
SERVICE IN AN ATM COMMUNICATIONS NETWORK
' Technical Field
This invention relates to asynchronous transfer
mode (ATM) network service and, more particularly, to the
creation, deployment and management of multimedia service
in an ATM network.
Background of the Invention
Most communications networks operate either in
a connection-oriented mode in which communication is
maintained through pre-established channels having long
lifetimes, or in a connectionless mode where data packets
are routed hop-by-hop through the network. In both types
of networks, service to customer premise equipment (CPE)
has been provided by a small number of computationally
powerful processors in the network, called service
controllers (SC) or service control points (SCP).
Connectionless mode includes ATM which has been adopted
as a standard for packet-based communications.
Summary of the Invention
We have recognized that distributed
computational capability, e.g. of customer premise
equipment (CPE) can be used to advantage in service
provisioning in an ATM network. An open and programmable
software platform or kernel is included in the network
for building, deploying and managing multimedia services.
The kernel is open in that it supports functional
application programming interfaces for developing useful
services, and it is programmable in that these APIs allow
service specification and creation in a high-level
programming language.
The kernel forms a distributed operating system
for managing and controlling multimedia networking
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
2
resources to provide services with quality of service
(QOS) guarantees. The system includes an organized
collection of interfaces designated as binding interface
base (BIB), and an overlying set of processing
capabilities.
Brief Description of the Drawing
Fig. 1 is schematic depiction of a broadband
kernel in accordance with a preferred embodiment of the
invention.
Fig. 2 is a diagram of interface hierarchy of
the binding interface base (BIB) of the broadband kernel.
Fig. 3 is a schematic depiction of the four
types of primary interfaces provided by broadband kernel
services.
Fig. 4 is a schematic depiction of interaction
between broadband kernel services in setting up a high-
level teleconferencing service.
Detailed Description of Preferred Embodiments
The broadband kernel operates on two primary
principles, namely separation between control and
transport, and information abstraction. In the former,
the broadband kernel uses the Internet protocol (IP) as
the primary messaging system for control messages, while
retaining support of native ATM protocols for high
performance. In the latter, the broadband kernel relies
on the use of the CORBA (Common Object Request Broker
Architecture) distributed object-oriented standard for
support in defining and implementing open distributed
object interfaces.
The broadband kernel architecture recognizes
two layers of abstractions in a multimedia network. The
first layer hides away details of the network hardware
via a set of interfaces called QOS abstractions. These
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
3
interfaces allow resource capacity in the network to be
precisely characterized and managed in real-time.
Various resource allocation and control algorithms
operate on these abstractions to realize a set of low-
s level services called broadband kernel services that
provide the fundamental communication facility of the
network.
The second layer of abstractions exists above
the broadband kernel services to hide away the complexity
of these algorithms. These abstractions provide a clean
interface for building higher-level network services,
e.g. virtual chains, virtual paths and virtual networks
that are typically used by a service provider.
Collectively, these interfaces form the service interface
base (SIB) .
All interfaces in the architecture are
specified in CORBA interface definition language (IDL)
which is an open-platform neutral format. The
architecture is open, defining interfaces that allow open
third party access to key functionality at two levels in
the network. In the first level, third party software
developers can extend the broadband kernel services in
the architecture by building additional algorithms on top
of the BIB. At the second level, the SIB provides third
party software developers a set of platform-independent
APIs for building user-level services.
Major components of the broadband kernel
include (A) the BIB, (B) the broadband kernel service
modules, and (C) the network service modules.
A. Binding. Interface Base (BIB?
' This is a collection of IDL interfaces that
model multimedia logical or physical networking resources
in a network. Shared resources have a finite capacity
which may be allocated out for use. The interfaces in
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
4
the BIP can be divided into two main categories, namely:
a. interfaces of resources which represent
hardware that processes, generates or switches multimedia
streams, including interfaces to virtual devices, central
processor units (CPU), transport protocols (TP), switches
and links; and
b. interfaces to software entities or modules that
represent the processing, transporting and name space
capacities of the hardware of category (a), including
interfaces to virtual name space and virtual capacity
region.
yirtual Device Interface models producers and
consumers of multimedia streams. The interface specifies
generic operations on streams including methods for
adding, deleting, pausing, resuming and changing the
attribute streams. The Virtual Device Interface is
typically used to model multimedia devices that generate
or process multimedia streams including cameras,
speakers, microphones and displays. Two subclasses of
the Virtual Device interface exist, representing source
and sink devices. A third interface derives from both
classes and is used to specify devices that act as both
source and sink, e.g.,software filters.
Virtual CPU Interface models the scheduler and
a multitasking CPU for processing media streams. The
interface allows scheduling policies and parameters to be
set so that quality of service (QOS) constraints of the
media are met.
Virtual TP Interface models control interface
to a transport stack. The interface allows control over
transport parameters such as window size, rate, delay and
protocol parameters to be monitored and set externally.
Virtual Switch interface models an abstract
ATM switch. Methods allow setup, tear-down, and
renegotiation of virtual circuits and virtual paths for
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
point-to-point or multicast connections. Additional
functionality includes methods for simple switch and port
management and adjacency protocol operation.
Virtual Link Interface models the multiplexing
5 functionality of a switch port. Methods in the interface
allow tuning of scheduling policies as well as scheduler
specific parameters for guaranteeing cell-level QOS in
the network.
Virtual Name Space Interface models the
capacity of a finite naming resource like virtual channel
and virtual path identifiers (VCI/VPI). These resources
are usually associated with the VCI/VPI translation table
of an ATM switch.
Virtual Capacity Rection Interface models the
processing or transport capacity of a resource.
Specifically, when associated with a Virtual Link, the
interface models the switching capacity of the link. Or,
when associated with a virtual CPU, the interface models
the processing capacity of the media processor. Methods
in the interface allow the size of the capacity as well
as its dimensions to be changed.
B. Broadband Kernel Services
These are defined as basic enabling services
that allow the construction of higher-level network
services. Included are:
connection management service for connection
setup, resource control and renegotiation;
transport control (TC) or management service
' for real-time QOS monitoring and control of transport
streams;
' route management service for determining the
best physical route between source and destination
endpoints during the connection setup process;
QOS mapping service for translating between
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
6
user- or application-level QOS parameters and network
level QOS;
device management service for managing the
capabilities and verifying the compatibility of media
formats supported by communicating multimedia devices.
Connection Management Service. The connection
manager is responsible for the setup, tear-down and
renegotiation of resources for a connection request. 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 transport. A connection manager
I5 can reside on any host computer.
In this design, both "stateful" and "stateless"
variants of the connection manager are possible.
Addition, removal or renegotiation of a connection by
different connection managers are possible also.
Transport Controller fTC). The TC implements
QOS monitoring on the slow-time scale. There is one TC
per end system. At regular intervals, it palls every
connection it is responsible of monitoring and gathers
network management statistics. Upon a continuous QOS
violation, it notifies the appropriate service manager of
the event. The service manager can then decide to
initiate QOS renegotiation or to ignore the notification
based on the control rules it has. TC also monitors each
connection to see whether it is active or not. If it has
been inactive for more than a pre-specified interval, it
stores it, assuming that the application has "crashed".
Route Management Service. 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
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
7
delay. Various weight parameters have been experimented
with on a prototype implementation, such as hop count,
bandwidth, and utilization. If there is no route between
two hosts 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 in the sense that it only recomputes a new set of
routes on request. There can be multiple instances of
route managers running simultaneously.
OOS Mapping Service. The QOS mapper maps the
application level QOS into network level QOS. In terms
of COMET classes, all the video services are mapped into
class 1, audio into class 11 and reliable data into class
111. In the context of user-to-application and
application-to-transport QOS mapping, the QOS parameters
specified by the user (quality, type of audio, size and
compression algorithm for the video) are mapped to the
transport QOS parameters (delay, loss, etc.), measured
per frame. The network QOS parameters are the same as
those for transport, but they are measured on a per cell
basis.
Device Manager. The device manager tracks the
capabilities of all multimedia devices on a particular
host. Each of these devices in turn may support a number
of media formats, rates or options. When a device
initializes during the boot-up 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 unregister itself from the
device manager. The device manager of its own accord
polls the devices on a regular basis to ascertain their
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
8
continued availability.
C. Network Services
Network services are higher-level services
built on top of the interface of broadband kernel
services. Here, network services specifically include
switched virtual circuits, virtual paths, and multicast.
Switched Virtual Circuit service provides the
facility of setting up point-to-point virtual circuits
with on-demand bandwidth renegotiation, management, and
transport binding, monitoring and control capabilities.
Virtual Path service allows the reservation and
setup of whole virtual paths with programmable rerouting
and virtual circuit allocation parameters.
Multicast service extends the switched virtual
circuit service to deal with point-to-multipoint
connections and multicast group management.
The above-described modules or services
interact during the service creation process. For
example, for teleconference service, binding algorithms
used for connection set up, distributed systems
implementing synchronization protocols, resource
allocation protocols such as routing, etc., interact
cooperatively for realizing the service. The structure
of this interaction depends on the higher-level service
to be constructed. However, sufficient similarities
exist between high level services, especially network
services so that a generalized model of service creation
can be applied.
The service generation process is executed by a
service provisioning entity. Multiple such entities
execute in parallel and in a distributed fashion. The
service creation process includes five steps:
1. Creation of a service skeleton for an
CA 02290484 1999-11-19
WO 98/53578 PCT/US97109363
9
application (e. g., virtual circuit, virtual path, virtual
network or multicast). For example, the skeleton for a
virtual circuit consists of a graph from a source node to
a destination node.
2. Mapping of the skeleton into the appropriate
name and resource space, thereby creating a network
application.
3. Association (or binding) to the application of
a media transport protocol, thereby creating a transport
application.
4. Binding of the transport application to
resources, creating a network service.
5. Binding of the service management system to the
network service, thereby creating a managed service.
The 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 broadband kernel services to create the
service.
Services are created within the context of
servers which are specialized software processes or
modules that provide the necessary support (memory and
processing power) for a service to be created. Within a
server, a service can be viewed as being composed of an
algorithmic component and a data component. The
algorithmic component expresses the execution logic of
the service instance, and the data portion is an
abstraction of its state. In order for services to
interact with each other, several types of service
interfaces are also defined. These interfaces reflect
the roles that a service might play in the process of its
execution. Typically these include creation, operation,
CA 02290484 1999-11-19
WO 98/53578 PCT/L1S97/09363
management and programming.
The service creation interface is like a
constructor of a class. It is the primary entry point of
execution or instantiation of a service and is called by
5 the server once the service template has been completely
downloaded. The service operation interface defines the
operational functionality of the service and is usually
the primary interface through which services interact.
The programming interface allows manipulation of the
10 service logic to be performed while a service is in
execution. The service management interface allows for
monitoring of service states and manipulation of service
parameters.
Fig. 1 depicts the conceptual model of the
broadband kernel. The broadband network is defined as
the physical network 11 (also known as the R model) that
consists of switching and communication equipment and
multimedia end-devices. Superimposed on this physical
infrastructure, the multimedia network 12 is also known
as the G model and primarily serves to provide the
middleware support for the higher services, in the
services and applications network, to realize end-to-end
QOS guarantees. The multimedia network 12 achieves this
by first extracting, from the broadband network 11, QOS
abstractions that define the resource management and
control space of elements in the physical network. Then,
the multimedia network 12 realizes a fundamental set of
system-wide services through the execution and operation
of various resource control and management algorithms on
these QOS abstractions. These services are the broadband
kernel services and include many of the rudimentary
communication services like connection management,
resource reservation and the like. The services and
applications network 13 is also known as the B model and
realizes user-level services by building upon service
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
abstractions of the broadband kernel services.
This 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 abstractions which
are similar in structure, but differ in usage.
The role of the G-model is to create services,
including network services such as virtual networks, as
well as the low-level support functions for realizing
such a service. High level network services are realized
within the resource management and control space of the
R-model.
Fig. 1 illustrates some examples of services
provided by the G-model. These services are realized as
objects, i.e. algorithms and data structures, and
represent the "broadband kernel service" of multimedia
networks. They can be used as building blocks by an
application in the B-model to create multimedia services.
As illustrated in Fig. 1, the G-model is
divided into five conceptual planes 121-125. The states
of the broadband kernel are stored in plane 123, the D-
plane. The algorithms acting upon them reside in planes
125, 124, 122 and 121, the N-, M-, C- and U-planes,
respectively.
While resource control (M-plane) services such
as routing, admission control and the like, and
management (N-plane) services are important for the
deployment of broadband networks, the following is more
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
12
specifically concerned with the realization of the C-
plane, i.e. with connection management, and the U-plane,
i.e. with information transport.
The connection manager is the coordinator that
enables the creation of connection services. The
following functionalities are required by any connection
manager to perform its task: route selection, resource
reservation, states saving, and renegotiation. Multiple
connection schemes may run simultaneously in the network.
The route selection approach used depends on
the routing strategy. Routing is a control algorithm
running on the M-plane. The path of a connection is
provided by route objects in the BIB, whose routes are
updated by the router objects. There are two extreme
route selection approaches: source routing and hop-by-
hop routing. In source routing, the route object
completely specifies a route at once. In hop-by-hop
routing, the route object provides sufficient information
to progress to the next hop only. In-between these two
approaches, any combination is possible. Domain routing
falls under this hybrid category, where a number of
routers are needed to completely specify a route.
Resource reservation performed by a connection
manager can be divided into two groups: reserving system
resources such as buffer, bandwidth, CPU cycles and the
like, and reserving and setting of identifiers in the
network fabric for cell transport. The reservation of
system resources should be based on abstractions that are
independent of the details of the system hardware and
that provide QOS guarantees. For manipulation of
switching identifiers, the primitive should be as close
as possible to the hardware abstractions so that maximum
flexibility is maintained. For reserving and setting
resources, the state of the hardware can be made
accessible, to allow its modification through a set of
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
13
generic ATM switch interfaces. The requests received by
the connection manager can be specified in terms of
application level terminology. In order to reserve or
change resource usage, the connection manager specifies
these requirements in the appropriate terminology. For
example, QOS abstractions for the network resources can
be defined in terms of calls of a predefined class of
service, where each of such classes is defined with
specific cell loss, cell delay and the like. The
multimedia network service abstractions are specified in
terms of frame rate, frame loss and the like. Here, a
QOS mapper translates QOS specifications between the
various abstractions.
In the interest of system robustness, once a
connection has been set up its state is kept, e.g. the
bandwidth reserved and the route. Then, e.g. if the
connection manager "crashes", the manager can be
restarted, and requested to find out all the routes it
had established. Each switch keeps sufficient
information so that a connection manager can discover the
entire route of a connection by tracing forward and/or
backward starting from any hop in the connection. As
this causes heavy interactions among objects during
setup, renegotiation and deletion, in order to improve
the signalling performance, connection managers can cache
the connections state information. In this case,
connection managers must assume that the cached
information can become invalid. This might arise, for
example, if a connection is released by another
connection manager.
Renegotiating means asking for more or less
system resources for a connection than the one currently
committed. Renegotiation may be performed either when
the application using the connection explicitly requests
it or when it is triggered by the QOS monitoring system
CA 02290484 1999-11-19
WO 98/53578 PCT/LJS97/09363
14
due to sustained QOS violations. Renegotiation can be
performed also during the connection setup phase. In
order to efficiently perform renegotiations, resource
interfaces must allow immediate changes in resource
reservation, i.e., without releasing the resource first.
The information transport, or U-plane, focuses
on QOS-aware transport protocols. These contain
mechanism for the processing of media streams, i.e., in
flow and on a fast-time scale. For guaranteeing end-to-
end QOS, QOS-based transport APIs (for provisioning, QOS
control and media transfer) are used.
The U-plane offers media stream services such
as motion JPEG, MPEG video and CD quality audio for real-
time multimedia applications. For non-real time
I5 applications, services such as reliable (i.e. error free)
and best effort are offered. At the G-B interface, the
QOS is specified in the application level terminology and
per session. The QOS parameters are expressed in terms
of frames or packets, i.e., for real-time services, the
frame loss rate, frame gap loss, frame delay, frame peak
rate and the maximum frame size, and for non real-time
services, the average throughput, average packet delay,
maximum packet rate and maximum packet size. Only losses
and delays represent QOS parameters. These are monitored
by the receivers. The other parameters are traffic
descriptors used for regulating the media flows at the
senders.
To support applications with QOS requirements,
QOS-aware transport protocols are used. In particular,
the transport protocols provide mechanisms to support
flow and rate control for real-time and non-real-time
media streams, as well as mechanisms to handle error
control. The transport protocols should also have the
capability to perform in-flow QOS monitoring such as
measuring, frame delay, frame rate, frame loss and the
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
like. When fast-time-scale QOS violations are detected,
the protocol should have the capability to adapt, e.g.,
by changing the size of the transport protocol data unit
or by reducing its peak rate. Furthermore, the transport
5 protocol should have the capability to the notify network
management system or the application if the network does
not provided the guaranteed QOS or if a connection is
lost.
A QOS-based transport API is used for
10 provisioning, control and media transfer. Provisioning
takes into account multicast as well as unicast
connections. Control APIs are for renegotiation and
monitoring. These should permit the network monitoring
service to retrieve the in-flow QOS measurements and
15 allow kernel services to set new parameters for flow
control, monitoring or violation detection. Preferably,
the media transfer APIs provide the transport protocol
with the type of information it carries.
QOS monitoring is used for ensuring that the
QOS associated with a service is as guaranteed at
admission time, for collecting data for management, and
for detecting QOS violations and initiating
renegotiations. Monitoring is performed on a fast-time
scale or in flow, for flow control mechanisms to adapt to
rapid network fluctuations, and on a slow-time scale for
renegotiations and management purposes. In-flow
monitoring is performed in the transport protocol, since
it is tightly coupled with the media stream. This is a
U-plane functionality. Slow-time scale monitoring, which
is an M-plane service, can be performed by polling the
transport protocol of each active connection for their
current measurements or by waiting for transport
protocols to forward their measurements. The monitored
data is stored and/or processed, and is accessible for
management. If QOS violations are detected, e.g., if
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
16
sustained violations occur, the monitoring service should
have the ability to trigger renegotiation.
To satisfy the above requirements in a
prototype system, several components were designed and
implemented: qStack, a transport protocol for real-time
communications that performs in-flow QOS monitoring on a
fast-time scale; TP, a transport class with a QOS-based
API that supports multiple transport protocol suites;
and TC, a transport controller responsible for the slow-
time scale operations such as long-term QOS monitoring,
QOS violation detection and QOS renegotiation.
The U- and C-plane modules and kernel services
lie at the heart of an extended machine, namely a
broadband operating system, that extends in the network
rather than residing on a single host. In the process of
service creation, multiple such services are composed for
creating higher level services.
Fig. 2 depicts the interface hierarchy of the
BIB. At the root of the interface tree is the base class
interface, BindingInterface, which derives directly from
CORBA::Object. The BindingInterface class defines
generic methods for event registration and notification,
and ownership specification and verification that all
classes derive from.
Fig. 3 depicts the 4 types of primary
interfaces that services must provide. These include the
service creation interface, the service operation
interface, the service programming interface and the
service management interface.
As an example, Fig. 4 depicts the interaction
between broadband kernel services in setting up a high-
level teleconferencing service. Upon receiving a session
setup request from a user, the teleconferencing service
object (TM) creates an instance of the service skeleton.
It then queries the device manager (DM) of each host
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
17
involved in the conference to see if any devices capable
of supporting the requested type of media stream exist.
If successful, a connection setup request is made to the
connection manager (CM) who in turn queries the QOS
mapping service (QOSM) for a translation between the
transport level QOS specified by the BIB components and
the network level QOS understood by the Virtual Switch
and Virtual Link interfaces. The CM gets its route from
the Route object that contains the latest set of routes
computed by the route manager (RM). Once a route has
been obtained, the CM proceeds to each host (Virtual
Switches/Virtual Links) along the route and reserves the
required resources. The connection setup process ends
with the CM returning back to the TM a pair of VPI/VCIs
representing the entry and address points to the
connection that it has established. At this point, the
TM proceeds to inform the two transport interfaces (TPs)
at both endpoints to open the associated network
interface device using the VPI/VCI pair and transport
protocol of choice, and gets in return a unique
connection identifier that it then passes to the Virtual
Devices (VDs). The 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 devices so that different simultaneous
transport protocol stacks can be used by the same device
without any chance required. Once this is completed,a
session has been established and a multimedia stream
generated at the source device can be carried over the
network to the destination device. During the lifetime
of the connection, the transport controller (TC) monitors
the QOS obtained in the end system for any violation of
QOS. In the situation where sustained QOS violations
occur, the TC may initiate a renegotiation request to the
TM who would in turn request the TP of the transmitting
CA 02290484 1999-11-19
WO 98/53578 PCT/US97/09363
18
device to reduce its rate. The TP in turn can interact
with the device to effect the rate control.
Alternatively, if a feedback channel to the
transmitting device is available, as may be required by
some protocols, the TP of the receiving device can
directly notify the TP of the transmitting device of the
violations. Still another alternative is when the user
requests for a change in the grade of service. In this
case, the TM issues a renegotiation request to the CM who
then attempts to renegotiate for new resources via the RM
and QOSM on the respective hosts. The other interfaces
(management and programmability) of the TM exist so that
other B::N-plane applications can monitor and control
service creation policies of the TM.
