Service Management in Multi-Party Active Networks - CiteSeerX

Download PDF
4 downloads 0 Views 76KB Size Report
Comment
Service Management in Multi-Party Active Networks. Marcus Brunner1. Computer Engineering and Networks Laboratory (TIK). Swiss Federal Institute of ...
Service Management in Multi-Party Active Networks Marcus Brunner1 Computer Engineering and Networks Laboratory (TIK) Swiss Federal Institute of Technology Zurich (ETH Zurich), Switzerland Rolf Stadler Center for Telecommunications Research (CTR) Columbia University, New York, USA

Abstract Active networking is an expanding field of research. It includes the ability to easily install and modify customized network services and to process packets within the network in a customized way. This paper addresses the question of how the benefits of active networking can be exploited in an environment, where a large number of customers must share a common network infrastructure. We introduce a management framework for active networks that allows customers to deploy and manage their own active services in a provider domain. The key concept in our framework is the Virtual Active Network (VAN). From the customers perspective, the VAN represents the environment in which the customer can install, run, and manage active services without interaction with the VAN provider. From the VAN provider’s perspective the VAN represents the object of resource partitioning and customer isolation. Active networking combined with the VAN concept allows for new business models in the telecom industry. Keywords Management of Active Networks, Service Management, Virtual Networks, CustomerControl, Network Architecture.

1 Introduction Recent research in the area of active networking has demonstrated the potential of this new technology [1][2]. From the service point of view, active networking allows customized packet processing inside the network on a per-packet, per-flow, or per-service basis. Customized packet processing can be applied, e.g., to application-aware routing, information caching, multi-party communications, and packet filtering [1]. From the management perspective, active networking technology enables rapid service deployment and flexible service management [2]. While suggesting attractive benefits, active networking also poses serious challenges that must be overcome to gain wide-spread acceptance. This paper focuses on one of these challenges, the problem of engineering a multi-user multi-services active network environment. We formulate the problem in the following way: 1. The author is now with C&C Research Laboratories, NEC Europe Ltd. Hardenbergplatz 2, D-10623 Berlin, Germany, e-mail: [email protected]

1

To appear in IEEE Communications Magazine: Special Issue on Active, Programmable, and Mobile Code Networks

How can a network provider, whose infrastructure is based on active networking technology, support a large number of customers, all of which independently install and run their own customized active services in the provider’s domain? Note that the term customer has different meanings here. See Section 6 for a discussion of different business models. To solve this problem, we need the capabilities to • enable each customer to create, run and manage his/her own customized active services, and • isolate the customers to avoid interference among each other. Current approaches to active networking address this problem by introducing a trust relationship between the customer which installs the software in the network and the owner of the network ([3], [4], and [5]). The software is trusted by the network owner in the sense that its execution is assumed to consume no more than a certain amount of resources, and that its functions inside the network do not interfere with other network services. The difficulties with this approach are that (1) only few parties implementing services might be able to build up such a trust relationship with network owners (which might lead to monopolies and thus prevent a wider market for active network services from being created) and (2) even trusted parties will (unintentionally) produce faulty service code with potentially serious consequences for network operation, ranging from overconsumption of network resources to breaking down the whole network. We take a different approach. We propose to isolate customers from each other through network virtualization. The concept we have developed to provide this capability is the Virtual Active Network (VAN). In the same way as an active network can be understood as a generalization of a traditional network, a VAN can be seen as a generalization of a traditional Virtual Private Network (VPN). Similar to a traditional VPN, a VAN can be used by a customer to run network services, using a provider's physical infrastructure. However, in contrast to a traditional VPN, a VAN gives a customer a much higher degree of flexibility and control, because a customer can install, run, and manage new customized services in the provider domain without interaction with the provider.

2 Management Framework for Active Networks In the following, we outline our management framework for active networks, which we have first proposed in [2]. Figure 1 shows the interaction between a customer domain and a provider domain for service provisioning, service delivery and service management. We propose that the provisioning of a specific (active) network service X is split into two different operations: • The provisioning of a generic service, which we call the VAN service, is performed via the cooperative VAN provisioning interface, in cooperation with the provider. VAN provisioning includes the negotiation of the VAN topology and allocating VAN resources. • The installation of the specific service X is performed via the generic service inter-

2

Customer Domain

Cooperative VAN Provisioning Interface

Customer NMS

Provider NMS VAN Provisioning

VAN Provisioning

Active Network Management Interface

Active Network Management Interface VAN & Node Mgt.

Provider Domain

Service Management

Service Management

Service

Service

Active Network

Generic Service Interface

VAN & Node Mgt.

Active Network

Figure 1: Customer-Provider Interaction in Multi-Party Active Networks face, without further interaction with the provider. The same interface is used to control and manage service X during its lifetime. In Figure 1, three interfaces are defined, the generic service interface, the cooperative VAN management interface, and the active network management interface. Using active networking nodes enables the definition of a generic service interface for network services, based on the concept of active packets. In addition, this service interface can be used for service management interactions, i.e., for operations related to the installation, supervision, upgrading and removal of a specific service. Therefore, service management operations can be performed by a customer in a flexible way without interaction with the provider’s management system. The management interface between network management systems of different domains, we call it the cooperative VAN provisioning interface, can be restricted to the task of VAN provisioning. Similar to the service interface, the management interface can be kept generic; it relates to a generic service abstraction (VAN) that allows for installing and running various network services. The active network management interface relates to the tasks of single-domain VAN configuration and network node management. Furthermore, the active network management interface becomes generic through the introduction of active packets replacing the standardized management protocols implementing the interaction between the network management system and the network to be managed. This allows each domain to implement its own management system. Additionally, the process of configuring the network elements on behalf of service provisioning and the process of monitoring of the network elements can profit from the active network technology in terms of information aggregation, customized filtering, and the delegation of network control [6].

3

3 The Virtual Active Network A Virtual Active Network (VAN) can be described as a graph of virtual active nodes interconnected by Virtual Links. Virtual active nodes are also called Execution Environments (EEs), following the terminology of the AN working group. A virtual active node has resources attached to it in form of processing and memory resources, provided by the underlying active networking platform. Similarly, a Virtual Link has bandwidth allocated to it. We envision that a single (physical) active node can run several virtual active nodes belonging to different VANs, and a single (physical) network link can support several Virtual Links for different VANs. Figure 2 shows an active network with five nodes in a provider domain. On this network, two VANs have been installed, one for customer 1 and one for customer 2. The figure also shows the Management VAN, interconnecting the Management EEs, which are used by the provider for VAN provisioning and supervision (see Section 4). Node E

Node A

Customer 2 EE

Customer 1 EE Customer 2 EE

Management EE

Management EE

Customer 1 EE

Customer 1 EE

Management EE Node C

Management EE

Customer 1 EE Customer 2 EE Management EE

Node B

Node D

Figure 2: An Active Network with nodes A-E, on which VANs for customers 1 and 2 and the provider’s Management EEs have been installed. What problem exactly does the VAN concept address and what are its benefits? 1. The VAN provides a generic service abstraction for an active network environment. From a provider’s point of view, the VAN is the entity according to which active network resources are partitioned and according to which the customers, using the provider’s infrastructure, must be isolated from one another. The VAN is the only object shared between provider and customer, and it is the object of negotiation between the two parties. Specifically, the provider is not concerned about which specific service(s) a customer is running on its VAN. The task of the provider is solely to configure a VAN and to monitor and police the use of resources on the 4

2.

3.

4.

5.

6.

VAN level. The provider has to ensure that the quality, as agreed upon between customer and provider, can be guaranteed. But the provider is relieved from managing services, which could get very complex these days. In traditional network environments, the customer has a simple service abstraction and sees the service essentially as a black box with access points. In contrast, the VAN is a very flexible service abstraction compared to today’s virtual path or flow based abstractions. The flexible selection of the VAN topology allows a customer to configure the service abstraction with different degrees of detail. The service abstraction can be very detailed for instance a VAN that spans over the whole physical active network of a provider, which allows a customer to detailed control the service. Or the VAN can also be very small and simple, e.g. only providing a Virtual Link through the network, comparable to the ATM Virtual Path abstraction without control of any virtual nodes. The level of detail is freely selectable and depends on the requirements of a customer’s service, or on the management policy a customer selects. Some customers prefer a lot of control and management capabilities in the provider domain, others want to keep their service management lean and simple. The whole range of requirements concerning the service abstraction are possible with the VAN approach. The VAN provisioning allows a customer for a fine-grained resource allocation, which enables a customer to optimize the overall resource consumption of a service. Since the VAN is a collection of computation, communication, and memory resources located on active nodes and links, a customer can fine-tune the usage of each resource on each node separately. For instance, some services need a lot of computation but little memory, and others need a lot of computing resource before packets are sent over an unreliable physical link. In addition, the service manager can trade one resource for another to minimize the cost and to maximize the service quality. From a customer’s perspective, the VAN concept allows for installation and management of active network services, without interaction with the provider. (As mentioned above, all interactions between customer and provider relate strictly to the VAN.) The customer can run a large variety of active network services on the VAN. These services are only restricted by the specific EEs the VAN supports. Furthermore, a customer can install service-specific customized service management functionality together with the service. Note that the high degree of customer control over services running in a provider’s domain, which a VAN provides, is virtually impossible to realize with today’s “traditional” networking technology. Exploiting a general benefit of active networking, the VAN concept enables rapid deployment of new network services. Deploying and upgrading network services is difficult and time consuming in today’s networks due to the closed, integrated architecture of network nodes. With the concept of a VAN the installation of any customer-specific service becomes feasible, and, as explained before, it can be accomplished by the customer alone, without interaction with the VAN provider, which heavily speeds up the service deployment. This is extremely useful in today’s market place, where the time to market is essential for profitable business. Customers can run a large variety of different network services on a single VAN in

5

parallel, which allows customers to perform dynamic re-allocation of VAN resources to the various services, according to their own control objectives and traffic characteristics -- again, without interaction with the VAN provider. The VAN concept can be compared to that of a Virtual Path (VP)-based Virtual Private Network (VPN). Similar to a VAN, a VP-based VPN provides customers with a service abstraction, on which they can run their own services, such as IP-based data or real-time services. Since a VP is a simple abstraction, a customer’s ability to control traffic inside the provider’s domain is very limited. A VAN, on the other hand, is a much more complex abstraction than a VP and, consequently, gives customers extensive control capabilities inside the provider’s domain. In a similar way as dynamic bandwidth provisioning can be performed in a VP-based VPN, we envision that VAN resources can be re-negotiated during the lifetime of a particular VAN via the cooperative VAN provisioning interface shown in Figure 1.

4 Active Network Node Architecture Figure 3 gives an operating system point of view of an active network node. A node operating system layer configures and provides access to the node’s resources, such as links, processing and memory resources. This layer runs the EEs, separates them from each other, and polices the use of the resources consumed by each EE. Service Service 1 Mgt 1

.....

Service Service M Mgt M SPI

Execution Environment

Customer 1

.....

VAN Management Node Configuration Management EE

Provider

Customer N

LVMI Node Operating System Node Operating System Memory

CPU

SPI: Service Programming Interface

I/O

Hardware

LVMI: Local VAN Management Interface

Figure 3: Architecture of an Active Network Node in a Telecom Environment Figure 3 specifically shows the case where a provider offers VANs to several customers (Customer 1,..., Customer N). The figure shows one such node containing EEs of different customers/VANs. Each customer runs its services in a separate EE. The service components and service management components access the EE over the Service Programming Interface (SPI). The SPI includes functionality for running active packets, to configure the EE to service-specific needs in the functional and the run-time behavior.

6

A special EE called the Management EE runs the provider’s VAN management and node configuration system. The Management EE uses the local VAN management interface, to create EEs for customers and is able to monitor, modify and terminate them. The VAN provisioning and configuration system is controlled by the provider’s management system via the exchange of active packets. The provider’s management system, as shown in Figure 1, maintains a global view of the provider’s domain for the purpose of VAN provisioning. 4.1 VAN Provisioning Figure 4 depicts the same active network node architecture shown in Figure 3 in order to better visualize the mechanisms needed to setup a VAN, and to show how an EE is embedded into the node. Physical InPorts

Virtual InPort ...

Execution Environment N

Virtual OutPort

Physical OutPorts

...

Execution Environment 1 Demultiplex Incoming Packets

Virtual Memory Access control

Multiplexing Outgoing Virtual Packets Processor ... Schedule Execution CPU

... Storage

Active Network Node

Figure 4: Active Network Node Architecture During the VAN provisioning phase, the provider’s network management system creates EEs on a set of active network nodes, according to a customer’s topology requirements. The node operating system is configured to allocate the node resources specified. The EE consists of Virtual Ports, Virtual Memory, and a Virtual Processor to abstract from the real hardware. Active packets arriving at the physical InPort are demultiplexed and forwarded to the different EEs, where they get visible at the Virtual InPort of the EE. Active packets sent by the EEs at the Virtual OutPorts are multiplexed to a physical OutPort, constrained by the Virtual Link resource reserved during the VAN provisioning. Furthermore, Virtual Memory access is controlled, and the execution of the Virtual Processors need to be scheduled. 4.2 Node Operating System Requirements This section describes the functionality needed in the node OS in order to realize the VAN concept on an active networking platform. Conceptually, the functional requirements can be summarized in the following five points. • Resource Partitioning: Resources, such as CPU-cycles, memory, and transmission 7

•

•

•

•

bandwidth of the outgoing physical links have to be partitioned among different EEs, i.e., customers. Resource Policing and Isolation: An EE must be prevented from consuming more resources than granted by the VAN provider if other EEs need the resource. In addition, its allocated memory has to be protected from unauthorized read and write. Demultiplexing and Multiplexing: Active packets on an incoming physical link must be demultiplexed, identified and forwarded to their corresponding EEs. Furthermore, active packets leaving the EEs need to be multiplexed onto the outgoing physical links. Note that the multiplexing and demultiplexing has only local significance, which allows to choose any multiplexing identifier small. Cut-through Links: The node operating system needs to support cut-through links, allowing packets to directly pass through the node on a fast path, without being processed. This is needed because a VAN is not obliged to span the physical active network completely. Actually, this functionality can be easily supported by underlying hardware. Local VAN Management Interface: The node operating system has to provide a local VAN management interface. The interface needs the functionality to install and remove new EEs, new Virtual Ports, and Cut-through Links. Furthermore, it needs the function to reserve or modify the resources associated with EEs, Virtual OutPorts, and Cut-through Links. Additional, it should include access to usage information of the VAN elements for monitoring purposes.

5 Service Management Service management includes installation, update, running, monitoring, and removing an active service [6]. Without further interaction with the provider’s management system, the customer configures its EEs (virtual nodes of the VAN) for the specific services it wants to run and for the service management functionality it needs. Figure 5 shows a VAN spanned over two customer networks and two provider networks. The service management system is controlled from a Service Management Station (Figure 5), which serves as the human-computer interface for the service management system. The station initiates service management actions and displays monitoring information. An active network service, as defined in our framework, consists of stationary service components installed on the EEs of a VAN. Active packets travel through a VAN, accessing stationary service components and the Service Programming Interface, when they execute on EEs. Active packets are the basic communication entity in terms of what information they transport, and they are the basic computation entity in terms of what functions they execute on the EEs. Active packets are used for two different tasks. First, they are the objects which implement an end-to-end networking service on behalf of a distributed application. Second, active packets are executing service control and management tasks on behalf of the service management system. In Figure 6, they are labeled active service management packets. Active service management packets prepare the EE to be used by an active service. 8

Service Management Station

EEs

Virtual Active Network (VAN)

Physical Active Network Physical Active Network

Physical Active Network Customer

Customer Provider 2

Physical Active Network Provider 1

Figure 5: A Virtual Active Network over three Domains

We take a hybrid approach to active networking. The active packet may carry program code, or the code can be pre-installed and bound to the active packet on arrival at the EE. Furthermore, active service management packets are used to install code and stationary service components on EEs and to configure the EEs to meet the run-time requirements of an active service. Figure 6 shows active packets arriving at a Virtual InPort of the EE, accessing stationary service components while executing, and leaving the EE on a Virtual OutPort. configure & monitor

Stationary Service Components

install & supervise

Stationary Service Management Components

access leave arrive Active Packet Virtual InPorts

Active Service Management Packet configure & monitor access

Virtual configure & OutPorts monitor configure & monitor

execute

Execution Environment Virtual Processor

Virtual Memory

Figure 6: Active Packets and Stationary Service Components The Service Programming Interface includes functions which are used by active packets to implement a service. Such functions are accessing memory, leaving the EE over Virtual OutPorts, and supporting active packet’s run-time, such as creation, termination, and synchronization of active packets. Additionally, the interface contains functions mainly used by active service management packets for configuration and monitoring purposes. The configuration interface include functions to set and configure packet classifiers at the Virtual InPorts, packet schedulers at the Virtual OutPorts, CPU scheduler at the Virtual Processor, and memory management at the Virtual Memory. Service management functionality need to be installed together with the service code, because it is not known in advance what control and management requirements a service has. Furthermore, the monitoring of active services is very well supported by

9

active networking technology with the property to install programmable filters which pass or drop events, to install programs taking specific automated actions at the occurrence of events (management by delegation). Additionally, the collection of management information from a VAN takes advantage of easily aggregating information within the VAN. The service management system can install programs, which aggregate and filter management information within the VAN in a customized way. The aggregation reduces management data traffic, but still provides important management information. The programs installed can also take appropriate actions within the network on the occurrence of specific service behaviors, which is extracted from the management information gathered in the network [6].

6 Business Models The deployment of the VAN concept requires a discussion of possible business models for all involved parties. They can take the following roles: • A VAN provider is an organization owning an active networking infrastructure, which supports the VAN concept. • An Active Service Provider is an organization, which runs one or more services on a VAN, purchased from one or more VAN providers. Note, that the Active Service Provider may buy an implementation of an active service from another party, or it may design and implement new services and new service management functionality. • End-users utilize an active service and can range from large companies to households. They do not manage the services used. End-users can use active services by sending active packets including code which access service components installed and managed by an Active Service Provider. Besides these roles, a number of business interactions can be performed. Typically, a business interaction takes place between a customer, which buys a good, and a provider, which sells the good. A business entity may take more than one of the roles. A number of examples are discussed in the following subsections. In Section 2, we assumed that the same party is negotiating the VAN topology and the resources associated with the VAN over the cooperative VAN provisioning interface (Figure 1). In many of the following described scenarios, it makes sense that different parties perform topology negotiation and resource reservation. Which means one party decides on a topology of the VAN and negotiates the topology. Another party decides on the resources needed in a VAN and negotiates the resources. 6.1 Outsourcing Service Management A customer outsources different services to different Active Service Providers. In such a scenario, a customer acts as an end-user and a VAN provider at the same time. He only needs an active networking infrastructure on which a VAN is provisioned for each Active Service Provider.

10

The customer can choose the topology of the VAN himself, which allows him to choose at which end-points a specific service is accessible. But he has to partition the network resources according to the requirements defined by the Active Service Provider to run that service. For instance, assume a cable TV provider decides to offer other services on his network, but has no knowledge how to accomplish that. With an active networking infrastructure, he can contract with an Internet Service Provider1 and a telephone company. He provisions for each of these companies a VAN. The topology of the VAN is such that each end-user subscribing to one of these services is connected to the VAN. In this scenario, the cable TV provider neither has to manage the IP network nor the voice network. For example, if the Internet service provider updates his network to an IPv6 network, the cable TV provider does not deal with this service update. 6.2 Virtual Private Networks End-users with distributed premises networks, which could be traditional networks or active networks, may need a Virtual Private Network in order to connect their premises securely. In this scenario, a customer acts in the role of an end-user and an Active Service Provider simultaneously. A VAN provider offers this customer a VAN which fulfills the customer’s requirements (topology and resources). At this point, the end-user owns one large virtual network, spanning over its premises and one or more provider’s networks, which the end-user can manage as a single entity. E.g., he can install the same service as installed in his premises and use traditional service management applications and protocols. In case the end-user runs an active network, he can install, upgrade, monitor, and remove whatever active services he likes. 6.3 Virtual Enterprises The virtual enterprise scenario is a special case of the VPN scenario mentioned previously. A virtual enterprise consists of different parts of different companies/organizations, building a virtual enterprise in order to produce (mostly electronic) goods. It will be very convenient for such a virtual enterprise to operate its own network and running its own services on that network. The VAN concept provides this functionality. Each company acts as a VAN provider towards the virtual enterprise. Additionally, a infrastructure provider offers a VAN to interconnect those VANs used by the virtual enterprise. 6.4 Multi-Service Networks Providers can combine the roles of a VAN provider and an Active Service Provider at the same time. Such a provider uses the VAN abstraction to offer different services to different customers (end-users). The provider benefits from the possibility to upgrade services very fast and to offer new services very fast. The isolation between VANs is mainly needed in order to protect services from each other. This functionality is very 1. Note that a Internet Service Provider is a special case of an Active Service Provider, where the service to be managed is based on the Internet Protocol.

11

convenient in the case where new services are deployed in a short time to market without being thoroughly tested. 6.5 Tripartite Scenario A tripartite scenario, where each role is taken by a different party is the most likely case how active networking could work. By connecting VANs located in different VAN provider domains into a single VAN, an Active Service Provider can rapidly setup a networking infrastructure with Active Service Provider’s services running on top of the VAN. In this case, the Active Service Provider can reach many end-users in a very short time with new networking services. The Active Service Provider’s service subscription system controls the topology of the VAN in order to connect end-users to VANs running the subscribed service. The resource reservation is also performed by the Active Service Provider, but it is heavily influenced by Quality of Service requirements given by the end-user to the Active Service Provider. It is in the duty of the Active Service Provider to map QoS parameters of the active service to VAN resources, which are negotiated with the VAN provider afterwards. 6.6 Content Providers Content providers are a special kind of service providers, which have another motivation to act in the role of an Active Service Provider. Content providers are very sensitive to what a customer really gets at the end-system, because otherwise they will be blamed for not providing good quality content. Therefore, a content provider wants to control the entire path from where the content is produced to where the content is consumed by an end-user. Furthermore, the content provider typically knows best, how its content is transported over a network. In such a scenario, it is beneficial for the content provider to contract with a VAN provider to setup a VAN connecting the content consumers with a certain quality and installing its specific networking service to transport the content in a content-aware fashion. As an example we take the scenario where e-business over the World Wide Web takes place. The seller of goods is interested that each customer can access its Web-server fast enough, because a potential buyer could otherwise change the seller and buy the good somewhere else. Such a scenario can be improved by allowing the seller to purchase a VAN with enough capacity, paying for it to make buyers happy.

7 Conclusions One of the key problems in the field of active networking is the prospect of users loading and executing untrusted code in the network. In this work, we took the approach of network virtualization, which solves this problem by isolating different customers. For that reason, we introduced a management architecture for active networks, which allows to separate service provisioning of a generic service called Virtual Active Network (VAN) from managing a specific service. With this framework, a customer manages a customized active service in the provider domain without interaction with the 12

provider. This functionality allows a customer to rapidly deploy new network services, which definitely helps if the customer sells the service to end-users. The framework further allows a customer to configure service abstractions with different degrees of detail and controllability. The functionality is to our knowledge not possible in today’s network architectures. Additionally, we described how an active network node is designed and what functionality it needs in order to support the VAN concept. Furthermore, we showed how active service are installed, monitored, and updated in a scalable, programmable, and customized way. We implemented a functional prototype, which includes an active network (ANET), a VAN provisioning and supervision system, a service management system which runs in a VAN spanning over different domains, and different networking services [6]. The potential that active networking opens up by deploying the VAN concept is exemplified by business scenarios, which can hardly be accomplished by using today’s networking technology.

8 References [1] D. Tennenhouse, J. Smith, W. Sincoskie, D. Weatherall, G. Minden, “A Survey of Active Network Research”, IEEE Communications Magazine, Vol. 35(1), 1997. [2] M. Brunner, R. Stadler, “The Impact of Active Networking Technology on Service Management in a Telecom Environment”, Sixth IFIP/IEEE International Symposium on Integrated Network Management (IM ‘99), Boston, USA, 1999. [3] D. Weatherall, J. Guttag, D. Tennenhouse, “ANTS: A Toolkit for Building and Dynamically Deploying Network Protocols”, IEEE Conference on Open Architecture and Network Programming (OPENARCH’98), San Francisco, USA, 1998. [4] S. Alexander, W. Arbaugh, M. Hicks, P. Kakkar, A. Keromytis, J. Moore, C. Gunter, S. Nettles, J. Smith, “The Switchware Active Network Architecture”, IEEE Network, Vol. 12(3), 1998. [5] D. Decasper, G. Parulkar, S. Choi, J. DeHart, T. Wolf, B. Plattner, “A Scalable, High Performance Active Network Node”, IEEE Network, Vol. 13(1), 1999. [6] M. Brunner, “Service Management in a Telecom Environment based on Active Network Technology”, Ph. D. thesis No. 13433, Swiss Federal Institute of Technology Zurich (ETH Zurich), Switzerland, 2000.

9 Biography Marcus Brunner ([email protected]) is a research staff member of the C&C Research Laboratories of NEC Europe Ltd. in Berlin. He received his Ph. D. from the ETH Zurich in 2000, while working in the Computer Engineering and Networks Laboratory of the Electrical Engineering Department. Before, he got a diploma (M.S.) in Computer Science from the Swiss Federal Institute of Technology (ETH Zurich) in 1994. Rolf Stadler is a research scientist and adjunct professor at the Department of Electrical Engineering at Columbia University in New York. On leave from Columbia Uni13

versity, he currently is a Visiting Professor at ETH Zurich. Dr. Stadler received a master’s degree in mathematics and a Ph.D. in computer science from the University of Zurich, Switzerland, in 1984 and 1990, respectively. During 1991 he was a postdoctoral researcher at the IBM Zurich Research Laboratory. From 1992 to 1994 he was a Visiting Scholar at the Center for Telecommunications Research, Columbia University. Dr. Stadler’s current research is focused on active technology with respect to telecom networks and networked multimedia systems. Recently, he has been a guest editor of the IEEE JSAC issue on Service Enabling Platforms for Networked Multimedia Systems (Sept. 1999) and General Chair and Program Co-Chair of the Tenth IFIP/ IEEE International Workshop on Distributed Systems: Operations & Management (DSOM ’99), Zurich, Oct.1999.

14