romano layout - IEEE Xplore

ADVANCES IN QOS

CADENUS: Creation and Deployment of End-User Services in Premium IP Networks Giovanni Cortese and Roberto Fiutem, Sodalia S.p.A. Piergiorgio Cremonese, EPFL Lausanne — NETikos Pisa Salvatore D’Antonio, Marcello Esposito, and Simon Pietro Romano University of Napoli “Federico II” — CINI Consortium Ada Diaconescu, Teltec

ABSTRACT Current trends in the information and communications technology industry clearly indicate the existence of a business requirement for a market-enabling technology that allows network operators to interact with users in a seamless, transparent manner for the sale and delivery of a wide range of services with guaranteed quality of service. In this context the need arises for the dynamic creation, configuration and delivery of services with QoS guarantees via the automated management of service level agreements. The aim of the Cadenus project is to bring theoretical and practical contributions to this area by defining a framework for the provisioning of advanced communication services in premium IP networks. Such networks might be characterized by a high degree of complexity, in terms not only of scale, but also of number of operators and technological heterogeneity. Our contribution is twofold, comprising both the design of the proposed framework and its actual implementation. An innovative approach was taken to framework design, based on the concept of mediation. With respect to the framework implementation, an example illustrating the realization of a virtual private network scenario is presented.

INTRODUCTION This work is focused on the definition of an innovative framework for service creation and deployment. Its main purpose is the introduction of a novel approach to the implementation of viable solutions for automated service delivery. We concentrate our framework solution around the concept of mediation. In order to implement this concept into our framework, we introduce a number of functional blocks, or mediation components, to represent the main actors involved and define their automated

54

0163-6804/03/$17.00 © 2003 IEEE

interaction. The main actors we identified in the business model our framework addresses are the user, service provider (SP), and network provider (NP). It will be shown in the article that a component-based approach represents a good solution to the complex problem of defining a general architecture capable of performing all of the steps related to a service life cycle: from creation to negotiation, selling, configuration, invocation, activation, and monitoring. By clearly defining roles, responsibilities, and interfaces, it is possible to decompose such a complex cycle into a set of coherent subprocesses whose mutual interactions can easily be standardized. Based on this consideration, we herein make the assumption that the network infrastructure is managed starting from an abstract definition of a service as it is perceived at the network level, contained inside a standard document called a service level specification (SLS). As the next sections disclose, when an SLSdriven network infrastructure is available, our architecture is capable of translating a service representation from a user-centric perception (i.e., service level agreement, SLA) to a network-centric technical specification in a flexible way. The network-level technical specification is mandatory in order to allow correct configuration of the network’s engine, ranging from the logical entities it comprises down to the physical devices. We will also present some details on how an SLSdriven architecture can actually be implemented. We can therefore affirm that this work is not about the provisioning of quality of service (QoS) per se, but rather is focused on how QoS technologies can be controlled and managed via standard interfaces in order to create, customize, and support communication services for demanding applications. We believe this approach constitutes the novelty and major contribution of our proposal.

IEEE Communications Magazine • January 2003

The article is organized in seven sections, as follows. The reference framework in which our work is positioned is presented. We discuss the main issues related to the definition, negotiation, and activation of SLAs. We present service mediation aspects within the framework. We will delve into the details of our multilayer policy-based management framework, conceived for automatic configuration at both the network and device levels. We present some of the architectural choices we adopted in the actual implementation of the framework in the case of creation and delivery of a virtual private network (VPN) service. Finally, we provide some concluding remarks, along with some directions for future work.

DYNAMIC SERVICE CREATION THROUGH MEDIATION A high-level view of our service creation architecture for premium IP networks is presented in Fig. 1. The architecture includes key functional blocks at the interface between the user and the SP and within the SP and NP domains, respectively. We also refer to these functional blocks as mediation components, since they represent the main means of implementing the mediation concept in our framework. The combined role of these blocks is to manage user access to the service, to present the portfolio of available services, and to appropriately configure and manage the QoS-aware network elements available in the underlying network infrastructure. Their internal operations comprise activities such as authentication and aggregation, as well as a mediation procedure that includes the mapping of user-requested QoS to the appropriate service and network resources, taking into account the existing business processes. We have identified three major mediator components we believe are needed to supervise the dynamic service creation and configuration process: • Access mediator (AM) • Service mediator (SM) • Resource mediator (RM) The AM is the entity that allows users to input their requests to the system (i.e., mediates the users’ access to the system). The main responsibility of the AM is to present the user with a set of available services and corresponding service descriptions (e.g., type, cost) and allow the user to select, customize, and purchase these services via a harmonized interface. The source of the services is a so-called service directory database, from which the AM performs transparent processing of the available information. For example, in a video distribution service, the AM can select the cheapest offer if a movie is available from more than one SP, and notify the user as soon as a new movie matching the stored user’s profile becomes available. Thus, the main role of the AM consists of assisting and easing the service selection process. This functionality may be under the control of a trusted third party and appears to offer excellent novel opportunities for a value-added SP. The AM may form associations with one or more SMs to which requests are issued. Generally offline, the SM will take care of the creation


Service provider Service mediator

SLA

Service mediator

ServiceServices provider Services Services Services Services Services

Access mediator SLS Resource mediator

Access network provider

Backbone network provider

Next network provider

Legend: SLA: service level agreement SLS: service level specification

■ Figure 1. The reference framework for premium IP networks. of new services and their presentation in the service directory. It is the task of the SM to map the SLA from the AM into the associated SLS(s) [1] to be instantiated in cooperation with the RM(s). The SLA can therefore be seen as the interface between the AM and the SM. The interface between the SM and the RM is the SLS, ensuring independence from both the high-level view of a service and the specific network architecture employed. In a few words, an RM can offer all that can fit inside an SLS (and no more than this). Coming to RM operation, SLS enforcement may be achieved by means of a policy-based approach, which ensures correct operation of the network in a flexible and dynamic fashion. Policy-based management enables network administrators to shift from individual device management toward controlling a network as a whole: it allows network elements from different vendors, equipped with different capabilities, to be consistently configured. By defining these three types of mediators in our architecture, two strategic goals are achieved. First, we meet the requirements of the emerging business models by addressing the various interaction types between users and providers, as well as between different providers (e.g., negotiations, service selection, profiling). Second, we clearly separate not only the service from the resource control and management, but also the service from the service creation machinery. The former is a well recognized requirement for next-generation networks, while the latter architectural feature opens standardization potential for service creation work. The three mediation components, together with the customer, are the entities taking part in the operational phase of the premium IP (PIP) services. Given the scenario described above, it must be noticed that our architecture also provides

55

It is our opinion that a clear understanding of what an SLA

support for advance resource reservations at the RM level (and at the SM level as well if the SM owns the content servers), which makes it possible for the clients to specify time as a parameter of the selected service. In the model presented herein, we will always look after time-dependent QoS management.

looks like is a must for the next generation networks. In our view, an SLA is a contract between the customer and the provider of a specified service.

1

This is a technical function within the marketing area.

56

SERVICE LEVEL AGREEMENTS AND THEIR MANAGEMENT A definition of the term service level agreement has been proposed by the differentiated services (Diffserv) working group of the Internet Engineering Task Force (IETF) [2]: “a service contract between a customer and a service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another DS domain (upstream domain).” Apart from this somewhat general statement, no specific work exists inside the IETF related to the definition of SLAs for particular classes of service. More precisely, most efforts have focused on the Diffserv framework, thus taking into account the definition of per hop behaviors (PHBs) rather than end-to-end service specifications. It is our opinion that a clear understanding of what an SLA looks like is a must for the nextgeneration networks. In our view, an SLA is a contract between the customer and the provider of a specified service. Such a contract is signed upon subscription to the service itself and is prepared from templates specifically conceived for the available services. SLA templates are used during customer negotiation to define the required level of service quality. As a general remark, an SLA should give the user the possibility to negotiate a certain type of service, among those offered by various providers. A generic user might ignore the details of the service he/she is willing to demand from the network (especially those concerning traffic characterization), because either such information is not available at all, or the user lacks the necessary technical skills required to understand their semantics. To ease the process of filling in the contract template, a number of different SLA models might prove useful: the contract would become easier to understand, being focused on the actual needs expressed by the user. Keeping in mind the reference framework we presented earlier, the scenario we envisage is one where users contact an AM in order to gain access to a number of value-added services, by means of negotiation of specific SLAs. The AM, in turn, needs to interact with one or more SMs, each providing a certain set of services, to retrieve information about the characteristics of the services themselves. Afterward, it organizes this information in order to allow the user to more easily select the service that most appropriately fits his/her needs. Once a specific service has been chosen, the involved SM(s) providing this service are notified and the negotiation process is initiated. During the service negotiation process, the SM is responsible for interacting with one or more RMs in order to negotiate the

network resources needed to support this service. Eventually, the RMs configure the underlying network elements to efficiently satisfy the negotiated requests. This configuration needs to be performed considering the QoS-related characteristics of the purchased service. The process described above foresees the generation of a number of documents (SLA, SLS, policies), each describing the same instance of the service at a different level of abstraction. Thus, it is required that these documents be created and interpreted by mediation components (AM, SM, RM) at the corresponding abstraction levels in the overall architecture.

THE SERVICE MEDIATOR COMPONENT The SM component is part of the operation support system (OSS) platform of an SP. It basically implements three processes: • Service design • Resource negotiation with RMs • Service fulfillment Such processes might in principle be executed independent of each other, although resource negotiation and service fulfillment are typically executed synchronously (the former triggering the latter).

SERVICE DESIGN The service design process is typically executed by a marketing function 1 within the provider’s organization when a new service offering needs to be added to the portfolio of the provider. For example, the provider may develop a new offer called UMTS VPN for business customers. During such a phase, the service designer configures the service provisioning OSS for such a new service. Service design includes definition of the overall service fulfillment workflow, specification of configuration policies for devices internal to the provider, and definition of rules for translating end-user QoS requirements into the corresponding technical connectivity parameters (i.e., SLA → SLS translation).

RESOURCE NEGOTIATION The resource negotiation process is used by the SM to acquire IP QoS connectivity resources, which are needed to fulfil the end-user services the SM is offering to its own customers. This process includes: • Finding partner RMs • Setting up trading relationships with the RMs • Acquiring information from the RMs • Managing negotiations with the RMs

SERVICE FULFILLMENT This process is executed each time the SM receives a new service request from an AM and needs to provide the necessary resources for supporting this service. Such resources might be either internal to the provider (e.g., middleboxes for security or video servers for multimedia services) or leased from an external provider. In the Cadenus model we assume that the SM owns the resources needed to build an end-user


service, while network resources are owned and managed by the RMs. The high-level functional architecture of the SM is shown in Fig. 2. Its main components are: A flexible service provisioning platform, negotiating and accepting requests coming from a business-to-business (B2B) interface, and overseeing their fulfillment, including the service configuration and activation phases. Platform flexibility is guaranteed by: • A service design environment, which allows the provider to define at service creation time (using configuration tools and metadata repositories) new service offerings, new SLA templates for the service, the provisioning workflow for the service, and activation policy rules • A runtime environment (including a workflow engine and repositories for service data and metadata), able to tailor its behavior to different types of services the provider sells to its subscribers B2B gateway(s), toward the AM and RM, implementing the public process agreed to by partners, and performing the necessary data and process mapping in order to match the internal workflow, as implemented by the service provisioning platform. The gateway toward the AM supports trading of end-user services, while the gateway toward RMs is an IP connectivity B2B gateway. Both gateways include: • A process design environment, to be used to design and deploy new business processes. It also includes a trading partner management environment, through which the technical agreements with trading partners can be stored and viewed. • A runtime environment that runs the messaging protocol engines, the transformations of business documents, and the workflow of public process instances. • A set of tools to facilitate trading of IP connectivity.

A POLICY-BASED MANAGEMENT FRAMEWORK In the architecture we designed, there is one RM responsible for managing each network domain (i.e., autonomous system, AS) belonging to a network provider. This management process comprises a number of intermediate steps, each needed in order to lower the level of abstraction, thus filling the gap between the human-oriented concept of a “service” (represented by an SLA and associated SLSs) and the device-specific configuration commands needed to activate the service. This subsection is specifically concerned with the definition of the processes that take place immediately after a new SLS is created as a consequence of the negotiation of a new service instance at the SM level. Figure 3 depicts the Cadenus policy framework. The RM has been designed to be independent of the underlying physical network, or means of providing QoS (e.g., Diffserv, MPLS, over-provisioning). Thus, we can affirm that the RM is both network-independent (NI in the fig-


EndUserSvc B2B gateway

End-user services negotiation/ fulfillment

Service design

Access mediator IP trader subsystem

Process design

IP Svc B2B gateway

Service mediator

Resource mediator(s)

■ Figure 2. The functional architecture of the service mediator. ure) and device-independent (DI). The underlying network controller (NC) component provides all the needed technology-dependent functionality. Its main role is to translate abstract NI service requirements from the RM level, into specific network-dependent requirements or policies (network-dependent policies, NDPs). The NC is a network-dependent (ND) but DI component. It uses the NDPs to configure and manage the underlying network devices in order to provide the contracted services for the enduser. The NDPs are translated into device-specific commands thanks to the intervention of the device controller component (which then has to be both ND and device-dependent, DD). As shown in the figure, starting from an SLS instance (produced by an SM not shown in the picture), we cross all of the policy framework components in order to arrive at the network devices and appropriately configure them. To give a flavor of the overall operation of the framework, we briefly identify the following steps: 1) An RM receives an SLS as input and stores it in an SLS repository (SLSR). As a recent trend suggests, the SLSR might store information in the form of policies, as specified, for example, in the various proposals stemming from the Common Information Model under standardization inside both the IETF and Distributed Management Task Force (DMTF) research communities. 2) When the time to enforce the service arrives (e.g., service activation time is due), the appropriate subset of the information contained inside the SLSR is passed to the network controller, which translates it in a form that is compliant with the specific network architecture adopted (MPLS, Diffserv, etc.). The translation process results in a new set of rules, NDPs, that are stored

57

SLS

NI

SLSR

RM

NDPR

NC (PDP)

RM

DI

ND COPS DI

PIB

PEP COPS API

Device controller ND

TC API Traffic control

DD

Router

SLS: service level specificaton RM: resource mediator SLSR: SLS repository NC: network controller

COPS

PIB

PEP

Next-hop AS

COPS

COPS API Device controller

COPS API Device controller TC API

TC API Traffic control

PIB

PEP

Traffic control

Router

PDP: policy decision point PEP: policy enforcement point PIB: policy information base NDPR: Network dep. policy repository

Router

Autonomous system

■ Figure 3. An overview of the policy framework components. inside an ad hoc defined policy information base (PIB). The NC acts as a policy decision point (PDP), which exploits a protocol like Common Open Policy Service (COPS) to send, based on the provisioning paradigm, NDPs to the underlying policy enforcement points (PEPs). 3) Upon receiving a new set of policies, the PEP is in charge of interacting with a device controller (DC), thus triggering the last level of policy translation. The output of this phase is a set of commands needed to appropriately configure the traffic control modules (e.g., allocation and configuration of queues, conditioners, markers, filters, etc.) on the underlying network elements. During the negotiation of an SLS that spans over multiple domains, a certain number of RMs — those belonging to the crossed domains — must be involved in the negotiation phase. Each RM in the chain is in charge of ensuring the part of the service pertaining to its own domain. Thus, we adopted a cascade model in which a multidomain SLS can be recursively split into two parts: a singledomain SLS plus a remaining part that has to be enforced somewhere else (i.e., over one or more downstream domains). In this light, an end-to-end service configuration can be achieved composing one or more edge-to-edge services, each described by means of a singledomain SLS instance [3].

58

FROM THEORY TO PRACTICE: VPN DESIGN AND IMPLEMENTATION In this section we show how we implemented the Cadenus architecture and how it can be exploited via the definition of an appropriate business process for the creation and delivery of innovative services. In order to explain the operational aspects of our framework, we have chosen a VPN service.

SERVICE CREATION PHASE There are four main steps involved in the service creation process: • Define and put in a standard format a description of the business process associated with the service trading. • Define a standard graphical user interface (GUI) needed to allow users to customize the service parameters. • Define a standard template for the SLA to be used during the negotiation process of this service. • Define the rules to be enforced in the translation from the SLA to the corresponding SLS(s) at negotiation time. In a Web-based scenario, once the aforementioned tasks have been completed, the only remaining operation is the publication of the business process specification, together with the newly defined components (service GUI and SLA template) into the service directory.


We adopted the latest standard proposals coming from the electronic business research community, with respect to both the modeling methodology and the actual design for implementation. More precisely, the business process specification we came to is fully compliant with the electronic business XML (ebXML) framework [4], whereas the distributed online service directory has been implemented via Universal Description, Discovery and Integration (UDDI). The ebXML framework aims at creating a single global electronic marketplace where enterprises of any size and in any geographic location can meet and conduct business with each other through the exchange of standard XML-based messages. The specification of a business process is the main required activity while creating a new service. Coming to the service GUI and SLA template, they have been implemented as customizable Web components, whose goal is to ease the negotiation process. While designing a template for an SLA for VPNs, we kept in mind the fact that users are looking for simple solutions to complex problems: that is to say, when buying an enhanced VPN service, users would just like to express their needs at a high level of abstraction, with no need to bother with all the underlying technicalities. Thus, we exploited the capabilities of the mediation framework in order to fill the semantic gap between the user and the provider perspectives on the same service. We provide the user with a friendly graphical interface enabling him to design his/her own private network by simply drawing a graph representing the sites he wishes to interconnect, together with the related tunnels (represented by the edges in the graph). Furthermore, for each tunnel, we envisaged the possibility of selecting the tunnel’s specific features: • Type: uni- or bidirectional • Required bandwidth • Desired quality • Time schedule • Authentication procedure • Encryption algorithm This graphical representation of the VPN is stored in an XML format and passed to the AM. The AM uses this XML representation for building an SLA template that contains information related to the service instance that has to be negotiated. An SLA template lays the grounds for the new service negotiation process involving all mediator components as described in the previous sections. A GUI example for defining VPN services is shown in Fig. 4: it is implemented as a friendly Web-based interface that can easily be exploited by users who are totally unaware of the technical details of the service. As the next section will disclose, the GUI is obtained while negotiating the service as the outcome of a series of interactions among the various components of the architecture.

SERVICE NEGOTIATION PHASE When negotiation starts, the user is required to indicate the service he/she is willing to receive, specifying a QoS level for this service (Fig. 4). As stated in the previous section, the negotiation


process has been implemented adopting the ebXML approach. We will summarize in the following the formal sequence of steps needed at this stage: • The user subscribes to (or is authenticated by) the AM. • The user asks for negotiation of a new service instance. • The AM allows the user to choose one of the available services (in this case VPNs will be the user’s choice). • The AM contacts the centralized service directory in order to retrieve the service GUI associated with the selected service (Fig. 4). • The service GUI is sent to the end user. It has to be noticed that the AM does not make any semantic interpretation of the service under negotiation, but simply acts as a broker between the end user and the SM. This has the advantage of relieving the AM from the responsibility of being aware of any specific service definition: the only entity involved in the definition process is, as one would expect, the SM. After receiving the service GUI, the user fills the required fields and submits his/her request to the AM. This event triggers the following actions on the AM’s side: The AM contacts all the SMs that registered as sellers of the specified service. The list of such SMs may either have been obtained with the previous access to the repository (when the service GUI has been fetched), or may be retrieved through a further access. A document containing the service parameters specified by the user is sent to the SMs in the list in order to let them become aware of the service the AM (on behalf of the end user) is willing to request. Starting from the received document, each SM creates one or more associated SLSs, which are delivered to the RM. The RM uses SLSs to make an evaluation of the impact the service is going to have on the network and derives a cost to be paid for service enforcement. This operation is performed by means of an admission control process, which implies the participation of all the network management entities (as explained earlier). The computed cost is returned to the SM. The SM is now capable of formulating an offer, which is sent back to the AM: the offer comprises a contribution coming from the cost information provided by the RM and an additional fee related to the SM’s own value-added service (e.g., content provisioning, brokerage activity with respect to network configuration, management of service options). Should the service be unavailable, the quotation might contain an infinite cost value. Once all of the quotations coming from the involved SMs have arrived, the AM sorts these quotations according to the user’s preferences, which may be derived from the user’s profile. The sorted list of available offers is presented to the user: each single offer is built on the basis of the standard SLA template defined during the service creation phase. The user selects the offer he/she deems most suitable; this operation, which has a legal value, is in all respects equivalent to the signature of a formal contract (SLA).

The ebXML framework aims at creating a single global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of standard XML based messages.

59

REFERENCES [1] D. Goderis et al., “Service Level Specification Semantics and Parameters,” draft-tequila-sls-02.txt, work in progress. [2] S. Blake et al., “An Architecture for Differentiated Services,” IETF RFC 2475, 1998. [3] S. D’Antonio et al., “An Approach to Multi-Domain Service Management in SLS-based Networks,” Tech. rep. TR-COMICS-12-2002; ftp://ftp.grid.unina.it/pub/pubs/ cadenus/TR-COMICS-12-2002.pdf [4] ebXML Technical Architecture Project Team, “ebXML Technical Architecture Specification v1.0.4,” ebXML_TA_v1.0.4.doc, 2001.

ADDITIONAL READING [1] IST CADENUS (IST-1999-11017), “Creation and Deployment of End-User Services in Premium IP Networks,” http://www.cadenus.org/

BIOGRAPHIES GIOVANNI CORTESE ([email protected]) is an independent consultant specializing in software development strategies and software architectures. He has worked in the telecommunications and computer industry for 15 years as project manager, and has published on both telecom subjects and software methodologies. He has an M.S. in computer science from the University of Torino.

■ Figure 4. A sample service GUI for VPNs.

CONCLUSIONS AND FUTURE WORK This article presents the Cadenus approach to the design and development of a global architecture for the effective deployment of valueadded Internet services on premium IP networks. This is an ambitious goal, requiring comprehensive understanding of all the procedures involved, from user-to-network interaction to appropriate configuration of network devices, passing through a formal description of services. Based on these considerations, we pointed out the need for a thorough definition of the concept of an SLA and associated SLS. We then presented a model based on a modular decomposition of tasks involved in the deployment process, exploiting the concept of mediation. Finally, to give an idea of how these concepts apply in a real-world operational scenario, we focused on the issues related to the creation and deployment of a virtual private network service. We believe that our proposal brings in some novel contributions. However, it is clear that an important issue is related to the behavior of the proposed framework in large-scale scenarios such as the current Internet. Scalability, for example, is one of the most important aspects that should be emphasized; a sharp analysis of the potential bottlenecks of the mediation architecture is needed, with respect to both the individual components we identified and their orchestrated operation. Moreover, keeping in mind that our architecture pretends to be capable of managing a heterogeneous interconnected network, a clear idea of how to deal with the interdomain scenario must be developed and devised. This will unavoidably impose a systemic analysis of the trade-off between the granularity of a service and the overhead associated with its provisioning (in terms of processing time and signaling messages).

60

P IERGIORGIO C REMONESE is project manager in the Netikos S.p.A. Web Factory. He has been involved in several European Projects focused on networking, working mainly on the application layer. His main research interests are on QoS networking, network-management-policies-based. Netikos in this project is involved as consultant for EPFL. SALVATORE D’ANTONIO received an M.S. degree in computer engineering from the University of Naples “Federico II.” He is currently a researcher at C.I.N.I., the Italian University Consortium for Computer Science. His current research interests include network monitoring and control, QoS provisioning over IP networks and e-business platforms. He is currently involved in a number of international research projects in the area of interdomain QoS monitoring and delivery. ADA DIACONESCU received a B.Eng. degree in computer engineering from the Polytechnic University of Timisoara, Romania, in 2000. The same year she joined Teltec Ireland, at Dublin City University, as a postgraduate research student. Work carried out under this research group was related to QoS-aware end-user services over IP networks. In March 2002, she joined the Performance Engineering Laboratory at Dublin City University, where she is currently pursuing a Ph.D. in electronic engineering. Her current research interests include performance and reliability of component-based systems, dynamic architectures, and autonomous systems. MARCELLO ESPOSITO received a degree in telecommunications engineering from the University of Napoli “Federico II” in 2000. He is currently working as a researcher at C.I.N.I., the Italian University Consortium for Computer Science, and teaches computer architectures at the University of Napoli. His research interests include QoS provisioning, interdomain network management, and monitoring. ROBERTO FIUTEM received a Laurea degree in electronic engineering from the Politecnico of Milano, Italy, in 1988. Since 1989 he has been a researcher at the Istituto per la Ricerca Scientifica e Tecnologica (IRST), Trento, Italy, working in artificial intelligence and software engineering research projects. In 1998 he joined Sodalia, a telecom software industry in Trento, where he is working mainly in EU funded R&D projects on IP QoS and SLA management. SIMON PIETRO ROMANO ([email protected]) received a degree in computer engineering from the University of Napoli “Federico II” in 1998. He is currently a research assistant at the Computer Science Department of the University of Napoli. His research interests primarily fall in the field of networking, with special regard to QoS provisioning in heterogeneous environments and new-generation Web-based applications (electronic marketplaces, distance learning, etc.). He is currently involved in a number of European research projects, whose main scope is the design and implementation of effective solutions for the provisioning of services with quality assurance over premium IP networks.
