Active and Programmable Networks: IFIP TC6 7th International Working Conference, IWAN 2005, Sophia Antipolis, France, November 21-23, 2005, Revised ... Networks and Telecommunications)

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris ...

Author: David Hutchison | Spyros Denazis | Laurent Lefevre | Gary J. Minden

266 downloads 817 Views 7MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Massachusetts Institute of Technology, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

4388

David Hutchison Spyros Denazis Laurent Lefevre Gary J. Minden (Eds.)

Active and Programmable Networks IFIP TC6 7th International Working Conference, IWAN 2005 Sophia Antipolis, France, November 21-23, 2005 Revised Papers

13

Volume Editors David Hutchison University of Lancaster, Faculty of Science and Technology Computing Department, InfoLab21 Lancaster, LA1 4WA, UK E-mail: [email protected] Spyros Denazis University of Patras Department of Electrical and Computer Engineering Patras, Greece E-mail: [email protected] Laurent Lefevre INRIA RESO / LIP - University of Lyon Ecole Normale Supérieure de Lyon 46 Allée d’Italie, 69364 Lyon Cedex 07, France E-mail: [email protected] Gary J. Minden The University of Kansas Information & Telecommunication Technology Center 2335 Irving Hill Road, Lawrence, KS 66045-7612, USA E-mail: [email protected]

Library of Congress Control Number: Applied for CR Subject Classification (1998): C.2, D.2, H.3.4-5, K.6, D.4.4, H.4.3 LNCS Sublibrary: SL 5 – Computer Communication Networks and Telecommunications ISSN ISBN-10 ISBN-13

0302-9743 3-642-00971-9 Springer Berlin Heidelberg New York 978-3-642-00971-6 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2009 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12642465 06/3180 543210

Preface

This volume contains the proceedings of the 7th International Working Conference on Active and Programmable Networks (IWAN 2005) that was held during November 21–23, 2005, in Sophia Antipolis, Cote d’ Azur, France, jointly organized by Hitachi Europe and INRIA. IWAN 2005 took place against a backdrop of questions about the viability and necessity of a conference that deals with an area perceived by many as having run its full course. The Organizing Committee, during the preparations of the conference, took these concerns seriously and reflected them in the theme of this year’s event, entitled “Re-incarnating Active Networking Research,” and expanding the scope of past calls for papers into topics that have emerged from active and programmable networks. The result was a success because we received 72 submissions, a number that exceeded our expectations and in fact is one of the highest in the history of the conference. The distinguished Technical Program Committee set high standards for the final program; each one of the submitted papers received three peer reviews with detailed comments and suggestions for the authors. In total, 13 papers were accepted for the main program sessions with 9 papers accepted unconditionally and the remaining 4 papers being conditionally accepted with shepherding by selected Program Committee members. The Program Committee also noted that from the papers that were not selected a considerable number were also of high quality, therefore a small committee was formed to suggest which of these could be accepted as short papers, resulting in the final selection of an additional set of 13 short papers also included in these proceedings. The full-length papers were organized, according to their content, into four sessions, “Programmable Networks and Heterogeneity,” “Network Architectural Frameworks,” “Node Architectures,” and “Services,” with the short papers providing the material for two further sessions. We have kept the same paper order and structure in this volume. With the aim of addressing the issues implied by the IWAN theme, we invited two distinguished keynote speakers who have been at the forefront of active and programmable networks research since the beginning: Ken Calvert of Kentucky University and Gísli Hjálmtýsson of Reykjavik University. In his talk “Reflections on the Development of Active and Programmable Networks,” Ken Calvert discussed the past and present of the field. Gísli Hjálmtýsson, speaking about “Architecture Challenges in Future Network Nodes,” addressed future directions. Finally, the program concluded with a panel “The Guises of Active Networking––Strategy or Destiny?” chaired by Lidia Yamamoto, where invited panellists evaluated the shortcomings and the impact of active networks on the computer networking field. We thank the Technical Program Committee for their thorough work in reviewing, selecting and shepherding the papers. Special thanks go to Robin Braun of the University of Technology, Sydney and Jean-Patrick Gelas of INRIA, for their outstanding work as Publicity Chairs, Mikhail Smirnov for selecting and organizing a Tutorial Day with truly state-of-the-art tutorials, and last but not least the secretarial support of

VI

Preface

Beatrice Dessus and colleagues of the Hitachi Sophia Antipolis Lab, and Danièle Herzog of INRIA and Jean-Christophe Mignot from the LIP Laboratory, the hidden heroes of every conference. Above all, we would like to thank all the authors who honored IWAN 2005 by submitting their work and the 55 participants of the conference; they are the ones who really made the conference a success.

November 2005

Spyros Denazis Laurent Lefevre Gary Minden David Hutchison

Introduction

Active and programmable networking has, over the past several years, laid the foundations of providing an easy, but robust, introduction of new network services to devices such as routers and switches by adding dynamic programmability to network equipment. Network programmability and service deployment architectures are necessary to bring the right services to the customer at the right time and in the right location. However, research focused exclusively on the field has been declining during the last couple of years and is currently carried out in the context of other emerging or more “fashionable” research areas instead. Under these circumstances, the 7th International Working Conference on Active Networks (IWAN 2005), through its call for papers and consequently its program, was called upon to explore whether active networking (AN) research can be re-incarnated within these new research fields. Such motivation was inspired by the fact that methods and technologies that have been explored in active and programmable networking research have helped to realize the trend toward various research initiatives including ad-hoc networks, autonomic networks and communications, overlays, sensor networks and content-aware distribution. Furthermore, the issues that AN technology has tried to address find themselves at the center of any future research agenda that touches upon service and network operations at large, and in this respect AN will always be relevant. It is also our belief that many of the problems identified by the AN and programmable networks research agenda are far from being solved in a satisfactory, scalable and secure way and in this respect research in the new fields are likely to be haunted by the lack of appropriate solutions in the absence of embracing a programmable networking – if not an AN – approach. Having reached such a stage, we included in our program two keynotes that covered the past, present and future of AN. These talks were chosen with two contrasting observations in mind. First, the lack of wide acceptance of AN derives at least partly from the inability to identify truly compelling example applications (not necessarily killer applications), and this is an aspect that should not be neglected by future researchers. But second, AN and programmable networks have been quite successful in helping define simple and expressive reference models and elegant solutions to persisting problems like security, QoS, and multicasting, but perhaps the lack of their adoption could be attributed to the fact that they have generally not been presented with a strong business model in mind. A message conveyed by this year’s IWAN – which may be the last of its kind – is to bear in mind the likely utility of the technology developed by this community which goes beyond hype and buzzwords like active and programmable networks. And we should keep the essence of it in new research areas such as those already mentioned, including ad-hoc networks, autonomic networking and content-aware distribution. November 2005

Organization

Organizing Committee General Chair General Co-chair Program Comittee Chairs

Publication Chair Publicity Chair

Tutorial Chair Local Arrangements committee Local Technical Support

David Hutchison, Lancaster University, UK Akira Maeda, Hitachi, Japan Spyros Denazis, Hitachi Europe, France / Universtiy of Patras, Greece Laurent Lefevre, INRIA, France Gary J. Minden, The University of Kansas, USA Alessandro Bassi, Hitachi, France Jean-Patrick Gelas, INRIA, France Robin Braun, University of Technology of Sydney, Australia Mikhail Smirnov, Fraunhofer FOKUS, Germany Beatrice Dessus, Hitachi Europe, France Daniele Herzog, INRIA, France Jean Christophe Mignot, LIP, Ecole Normale Superieure de Lyon, France

Program Committee Bobby Bhattacharjee Christian Bonnet Elisa Boschi Matthias Bossardt Raouf Boutaba Marcus Brunner Ken Calvert Ken Chen Hermann DeMeer Simon Dobson Takashi Egawa Alex Galis Erol Gelenbe Peter Graham Jim Griffioen Robert Haas Toru Hasegawa Gisli Hjalmtysson Doan Hoang

University of Maryland, USA Eurecom, France Hitachi Europe, France ETH, Switzerland University of Waterloo, Canada NEC, Germany University of Kentucky, USA University Paris 13, France University of Passau, Germany University College of Dublin, Ireland NEC Corporation, Japan University College of London, UK Imperial College, UK University of Manitoba, Canada University of Kentucky, USA IBM, Switzerland KDDI R&D laboratoies, Japan Reykjavik University, Iceland University of Technology, Sydney, Australia

X

Organization

Javed Kahn Andreas Kind Guy Leduc Dave Lewis John Lockwood Laurent Mathy Douglas Maughan Eckhart Moeller Sandy Murphy Scott Nettles Naomichi Nonaka Cong-Duc Pham Guy Pujolle Danny Raz Paul Roe Lukas Ruf Joan Serrat Nadia Shalaby Yuval Shavitt Vijay Sivaraman James Sterbenz Toshiaki Suzuki Yongdong Tan Dirk Trossen Christian Tschudin John Vicente Tilman Wolf Miki Yamamoto Krzysztof Zielinski Martina Zitterbart

Kent State University, USA IBM, Switzerland University Liege, Belgium Trinity College Dublin, Ireland Washington University, USA Lancaster University, UK U.S. Department of Homeland Security, USA Fraunhofer Fokus, Germany Trusted Information Systems Labs, USA University of Texas – Austin, USA Hitachi Ltd., Japan University of Pau, France LIP6, France Technion, Israel Queensland University of Technology, Australia ETH, Switzerland UPC, Spain Princeton University, USA Tel Aviv University, Israel CSIRO (ICT Centre), Sydney, Australia University of Kansas (USA) / Lancaster University (UK) Hitachi Ltd, Japan Southwest Jiaotong University, China Nokia, USA University of Basel, Switzerland INTEL, USA University of Massachusettes, USA Kansai University, Japan University of Mining and Metallurgy Krakow, Poland University of Karlsruhe, Germany

Table of Contents

Programmable Networks and Heterogeneity Validating Inter-domain SLAs with a Programmable Traffic Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elisa Boschi, Matthias Bossardt, and Thomas D¨ ubendorfer Cross-Layer Peer-to-Peer Traffic Identification and Optimization Based on Active Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I. Dedinski, H. De Meer, L. Han, L. Mathy, D.P. Pezaros, J.S. Sventek, and X.Y. Zhan Towards Effective Portability of Packet Handling Applications across Heterogeneous Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mario Baldi and Fulvio Risso

1

13

28

Architectural Frameworks Architecture for an Active Network Infrastructure Grid – The iSEGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T.K.S. LakshmiPriya and Ranjani Parthasarathi

38

Network Services on Service Extensible Routers . . . . . . . . . . . . . . . . . . . . . . Lukas Ruf, K´ aroly Farkas, Hanspeter Hug, and Bernhard Plattner

53

A Network-Based Response Framework and Implementation . . . . . . . . . . . Marcus Tylutki and Karl Levitt

65

Towards Resilient Networks Using Programmable Networking Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Linlin Xie, Paul Smith, Mark Banfield, Helmut Leopold, James P.G. Sterbenz, and David Hutchison

83

Node Architectures Towards the Design of an Industrial Autonomic Network Node . . . . . . . . Martine Chaudier, Jean-Patrick Gelas, and Laurent Lefèvre A Web Service- and ForCES-Based Programmable Router Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evangelos Haleplidis, Robert Haas, Spyros Denazis, and Odysseas Koufopavlou

96

108

XII

Table of Contents

An Extension to Packet Filtering of Programmable Networks . . . . . . . . . . Marcus Sch¨ oller, Thomas Gamer, Roland Bless, and Martina Zitterbart

121

Services SAND: A Scalable, Distributed and Dynamic Active Networks Directory Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . M. Sifalakis, A. Mauthe, and D. Hutchison

132

A Programmable Structured Peer-to-Peer Overlay . . . . . . . . . . . . . . . . . . . . Marius Portmann, Sébastien Ardon, and Patrick Sénac

145

Interpreted Active Packets for Ephemeral State Processing Routers . . . . Sylvain Martin and Guy Leduc

156

Short Papers A Secure Code Deployment Scheme for Active Networks . . . . . . . . . . . . . . Le¨ıla Kloul and Amdjed Mokhtari

168

Securing AODV Routing Protocol in Mobile Ad-Hoc Networks . . . . . . . . Phung Huu Phu, Myeongjae Yi, and Myung-Kyun Kim

182

Extensible Network Configuration and Communication Framework . . . . . Todd Sproull and John Lockwood

188

A Model for Scalable and Autonomic Network Management . . . . . . . . . . . Amir Eyal and Robin Braun

194

Intelligibility Evaluation of a VoIP Multi-flow Block Interleaver . . . . . . . . ´ Juan J. Ramos-Mu˜ noz, Angel M. G´ omez, and Juan M. Lopez-Soler

200

A Web-Services Based Architecture for Dynamic-Service Deployment . . . Christos Chrysoulas, Evangelos Haleplidis, Robert Haas, Spyros Denazis, and Odysseas Koufopavlou

206

The Active Embedded Ubiquitous Web Service Framework . . . . . . . . . . . . Dugki Min, Junggyum Lee, and Eunmi Choi

212

Framework of an Application-Aware Adaptation Scheme for Disconnected Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Umar Kalim, Hassan Jameel, Ali Sajjad, Sang Man Han, Sungyoung Lee, and Young-Koo Lee Kinetic Multipoint Relaying: Improvements Using Mobility Predictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jérˆ ome H¨ arri, Fethi Filali, and Christian Bonnet

218

224

Table of Contents

The Three-Level Approaches for Differentiated Service in Clustering Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Myung-Sub Lee and Chang-Hyeon Park On the Manipulation of JPEG2000, In-Flight, Using Active Components on Next Generation Satellites . . . . . . . . . . . . . . . . . . . . . . . . . . L. Sacks, H.K. Sellappan, S. Zachariadis, S. Bhatti, P. Kirstein, W. Fritsche, G. Gessler, and K. Mayer TAON: A Topology-Oriented Active Overlay Network Protocol . . . . . . . . Xinli Huang, Fanyuan Ma, and Wenju Zhang

XIII

230

236

247

A Biologically Inspired Service Architecture in Ubiquitous Computing Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frank Chiang and Robin Braun

253

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

259

Validating Inter-domain SLAs with a Programmable Traffic Control System Elisa Boschi1 , Matthias Bossardt2 , and Thomas Dübendorfer2 1

Hitachi Europe Sophia Antipolis Lab, France [email protected] 2 Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology, ETH Zürich, Switzerland {bossardt,duebendorfer}@tik.ee.ethz.ch

Abstract. For network users and service providers it is important to validate the compliance of network services to the guarantees given in Service Level Agreements (SLAs). This is particularly challenging in inter-domain environments. In this paper, we propose a novel solution for inter-domain SLA validation, based on programmable traffic processing devices that are attached to routers and located in several autonomous systems. Using our service management infrastructure, the measurement logic is deployed on the traffic processing devices in a flexible and secure way. We safely delegate partial network management capability from network operators to network users, which are enabled to configure service logic on the traffic processing devices. At the same time, the management infrastructure guarantees against negative influence of the network user’s configuration on network stability or other user’s traffic. Via the flexible configuration of service logic, our system gives network users powerful means to observe quality of service parameters agreed upon in SLAs. We present a detailed scenario of the SLA validation service and its deployment across several administrative domains. Keywords: Inter-domain measurement, programmable networks, SLA validation, network service, management delegation.

1 Introduction The need for verifiable quality differentiation of network services is one major trigger for the deployment of measurements in IP networks. Services like VoIP, multimedia streaming, video telephony or e-gaming require a minimum guaranteed level of network performance. Internet Service Providers (ISPs) negotiate a contract with their customers called Service Level Agreement (SLA) in which they specify in measurable terms the service to be furnished. One of the main problems faced by ISPs is how to deploy SLAs that cross ISP boundaries (inter-domain SLAs) to achieve end-to-end SLA enforcement. The problem stems from the fact that although ISPs can control and monitor their own network, which allows them to validate their intra-domain SLAs, they have only minimal information about the characteristics and performance of other networks. Also customers that stipulate SLAs with one single ISPs have concerns that the agreed D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 1–12, 2009. © IFIP International Federation for Information Processing 2009

2

E. Boschi, M. Bossardt, and T. Dübendorfer

Quality of Service has been met, and are therefore interested in end-to-end, interdomain measurements. Classical measurement architectures determine end-to-end, or edge-to-edge performance, comparing ingress and egress reports from two measurement devices located at the end points of a flow. These architectures though, are not sufficient to determine performance of specific path portions, or to determine which segments failed to provide the expected Quality of Service (QoS) in case the end-to-end guarantees are not met. If for instance the delay is higher than agreed in the SLA, it is not possible to determine in which administrative domain the higher delay occurred (or in other words: which ISP is responsible for not meeting the requirements). Another problem with such architectures is that they require to configure two edge devices and retrieve information from them. This configuration is difficult in case the devices are not located in the same administrative domain, since ISPs have major security related concerns in delegating any management function to third parties. These concerns are based on the risk that third party configurations may negatively affect network stability or other user’s network traffic. In this paper, we present a novel solution for inter-domain SLA validation that allows deploying measurement logic on distributed devices in a flexible and secure way. The system is flexible in that it allows the deployment of almost arbitrary service logic with just a few restrictions that we specify later in this paper. These restrictions, together with the concept of traffic ownership [9,5] are used in our system to address the ISPs’ security concerns. The goal of our architecture is to configure on demand several measurement devices along a flow path in a multi domain environment, and to process the raw measurement data, in order to determine the QoS experienced by the flow on several nodes of its path. With these kind of measures, an end user, or a monitoring application, could determine not only the end-to-end QoS, but also the QoS provided on different path segments even if belonging to different administrative domains. This paper is organized as follows. Section 2 discusses the state of the art in interdomain measurements. Section 3 discusses our distributed architecture for end-to-end SLA validation, describing the underlying traffic control system and how it can be used for effective, flexible and secure inter-domain measurements. A detailed scenario is presented in Section 4. Finally, we draw our conclusions in Section 5.

2 State of the Art 2.1 Inter-domain QoS Models The authors of [17] distinguish three different models being pursued in the attempt to provide inter-domain QoS: bilateral, cooperative and third-party. In the bilateral approach two providers interconnect at one or more points and agree on a set of metrics, measurement methods, service classes, settlements and issue resolution processes in a customized way. Generally the solutions agreed have a very low reusability for other peering agreements. Moreover these contracts involve just two parties, two neighboring ISPs, limiting the feasibility of end-to-end SLA validation (and QoS provision) to very “simple” cases.

Validating Inter-domain SLAs with a Programmable Traffic Control System

3

Cooperative approaches extend bilateral ones by defining a set of rules that a group of cooperating ISPs has to follow to provide inter-domain QoS within that group. These rules include the definition of common metrics, common SLA monitoring and reporting methodologies, common tools. This approach requires standard measurement and reporting techniques, metrics, data formats. While the IETF [13] is partly working towards this goal, e.g. [16,14] a full standardized inter-domain QoS provision process is unlikely to come in the near future. A more flexible approach is provided by the third-party model. There a third party composes an end-to-end service offer out of the single provider offerings and is responsible for the site-to-site measurement, and the metric definitions. Our approach falls into this category. 2.2 Inter-domain Measurement The National Internet Measurement Infrastructure (NIMI) [20] is a software system for building network measurement infrastructures consisting of measurement servers (called NIMI probes) and measurement configuration and control software running on separate hosts. Each probe reports to, and is configured by, a Configuration Point of Contact (CPOC), typically one per administrative domain. The probes are accessed through access control checks, and communications between all NIMI components are encrypted via public key credentials. NIMI does not require a particular set of measurement tools, new tools can be included in the infrastructure by writing a wrapper for them and propagating both tool and wrapper to all NIMI probes. The IP Measurement Protocol (IPMP) [15] is a protocol based on packet probes suited to measure packet delay at router level. This active measurement protocol operates as an echo protocol, allowing hosts in a domain to gather information from router units along the end-to-end path. However, only a limited set of measurements can be taken: packet loss, one-way packet length, round-trip time, and one-way delay. In [3] inter-domain measurements are configured sending XML-based documents called Specification of Monitoring Service (SMS) to a controller, located on each administrative domain crossed by the flow to be monitored. The configuration is sent to the controller in the source domain, and then with a cascade model, each domain configures its intra-domain measurement and forwards the request pertaining to the rest of the path to the controller of the subsequent autonomous system. The Diameter protocol [11] is used for secure inter-domain communication. All the above systems miss a flexible system to automatically deploy the requested services (i.e. a measurement technique for a particular metric) to the appropriate measurement devices in the network. Also, they do not provide adequate guarantees for network data privacy and against intended or unintended misuse of the system once the user has been authorized to configure the system. This considerably lowers the acceptance of a system especially if multiple network operators are involved.

3 Traffic Control System To validate the conformance of a service to the guarantees given in an SLA involving several domains, it is necessary to set up an inter-domain QoS measurement. In this

4


section we describe the traffic control system that we use to configure, deploy, and perform the measurement. The measurement results are exported to a collector, and used as input for the QoS metrics computation done in a component called evaluator. Collector and evaluator are not part of the traffic control system and therefore are not further described in this section. 3.1

Network Model

The network model of the traffic control system distinguishes four different roles: Internet number authority, Traffic control service provider (TCSP), Internet service provider (ISP), and Network user. The TCSP manages traffic control (TC) services. It sets up contracts with many ISPs that subsequently attach Traffic Processing Devices (TPDs), to some or all of their routers and enable their network management system to program and configure these devices (see Figure 1). The introduction of a TCSP helps to scale the management of our service. A network user needs only a single service registration with the TCSP instead of a separate one with each ISP. A network user must first register with the TCSP before using the traffic control system. The TCSP checks the identity of the network user performing similar actions as a digital certification authority (CA), e.g. offline verification of an official identity card or online verification of a digital certificate issued by a trusted CA. To verify the claimed ownership of IP addresses the user wants to control traffic for, the TCSP checks with Internet number authorities if the IP addresses are indeed owned by the network user. Ownership of (ranges of) IP addresses is maintained in databases of organizations such as ARIN, RIPE NCC, etc. Upon successful user identification, access to the traffic control system is granted. The binding of a network user to the set of IP addresses owned and the subsequent verification when using the TC service is implemented with digital certificates signed by the TCSP. After successfully registering to the basic TC service, a network user can initiate the deployment of a specific service (e.g. QoS traffic monitoring), which is implemented on top of the TC service. 3.2

Node Architecture

The node architecture is based on a legacy Internet router with basic filtering and redirection mechanisms. The router is extended with a programmable Traffic Processing Device (TPD), as shown in Figure 1. Network user traffic can be redirected permanently based on source or destination IP address in the transported IP packet to the traffic processing device, processed according to the service requested by the network user, and further sent along its path. Services are composed of components that are arranged as directed graphs [18,6], each of which performs some well defined packet processing. When the TPD processes a network packet, it first executes traffic control, such as e.g. monitoring, on behalf of the owner of the source IP address (first processing stage) and subsequently on behalf of the owner of the IP destination address (second processing stage). The functionality of service components is restricted as specified in Section 3.3. For instance, service components


5

Fig. 1. Node architecture

that match traffic by header fields, payload (or payload hashes), or timing characteristics can be installed, configured, and activated instantly. 3.3

Security Considerations

For the proposed distributed traffic control service to be accepted by ISPs, it is vital, that traffic processing devices keep the network manageable by the network operators and that it cannot be misused for an attack itself. This is addressed by the core concept of the traffic control system, which is traffic ownership. We restrict the traffic control for each network address owner to his/her own traffic, i.e. packets to/from owned IP addresses. This allows our service to assure that traffic owned by other parties is not affected. Hence, collateral damage caused by misconfigurations or malicious behavior of users having access to such devices can be prevented. In addition, ISPs do not loose control over their network. As any misuse of such a novel service must be prevented from the very beginning for gaining acceptance by network operators, we restrict it even further. We do not allow the adaptive device to modify the source and the destination IP address of a packet. Such rerouting could wreak havoc easily (causing routing loops, interference with other routing mechanisms, transparent source spoofing, or “forwarding” of attack traffic). Also the TTL (time to live) field of IP packets is a field we cannot allow to be modified as it aims to set an upper bound of network resources a packet is able to use. Furthermore, we need to prevent that the service can cause amplifying network-like effects. The traffic control must not allow the packet rate to increase. In addition, the amount of the network traffic leaving the traffic processing device must be equal or less1 compared to the amount of traffic entering it. I.e. packet size may only stay the same or become smaller. New service components for the traffic processing devices must be checked for security compliance before deployment. The security concerns of ISPs with respect to the danger of delegating partial control of the network from the network operator to the customers are adequately addressed as countermeasures against effects of misconfigurations and misuse were taken into consideration when designing the traffic control system. 1

For e.g. logging, statistics or trigger event services, we will allow a reasonable amount of additional traffic.

6


3.4 Deployment Process The deployment process is subdivided into TCSP, ISP, TCU and Device layer. A Traffic Control Unit (TCU) is defined as the combination of a router interface and all the TPDs that traffic from the interface can be redirected to. The TPDs can be physically separate, even located at different sites, or integrated into future routers. The complete deployment process is carried out at the management stations of TCSP and ISP. For each service a layer offers, a service descriptor specifies the following: – The mapping of the service to sub-services offered by the layer below. – The set of mandatory and optional parameters, their default values and their mapping to parameters for sub-services. – Restrictions that direct the placement of service logic. For each layer a database contains context information about the infrastructure relevant to that layer. These logical databases may be merged into two physical databases located at the TCSP and ISP management stations. Information at the TCSP layer includes the identities of contracted ISPs and properties of their networks, e.g. whether they transport transit traffic or provide a stub network, or BGP information. At the ISP layer relevant information includes the location of the TCUs, e.g. whether it is located at the border of a network or in the core network. At the TCU layer details about the pairing of TPDs and routers are kept as context information. Finally, at the Device layer information about the make and version of TPDs and routers and their configuration interfaces must be kept. Additionally, context information can contain dynamic state information about managed objects and deployed services. Deployment logic on each layer maps the service request from the layer above to services provided by the layer below based on information provided by the service descriptors. Taking into account restrictions specified in the service descriptor and context information from the databases, sub-services are placed on the managed objects of the corresponding lower layer (ISPs, TCUs, TPDs and routers, respectively). The deployment process ends with the configuration of the devices that were selected to run part of the service logic.

4 Delay Variation Measurement Scenario This section describes how the traffic control architecture can be used to perform endto-end QoS measurements for SLA validation. We describe here the deployment of the delay variation measurement service. Other QoS measurements (e.g. one way delay, one way loss, round trip time) could be similarly performed. 4.1 Scenario Description Let’s suppose that a corporate Internet user, e.g. a video streaming company (from now on identified simply as “user”), wants to verify that the performance parameters agreed in an SLA stipulated with ISP1 have been met. The SLA specifies guarantees on the jitter of a video the user sends from point A in the network of ISP1 to point Z in


7

the administrative domain of ISPn (cf. Figure 2). The user employs our traffic control system to measure the jitter of the video flow, and verify the SLA conformance of the service he’s providing. IP delay variation, or jitter, is defined as the difference of one-way delay values for selected packets [8]. This metric can be calculated by performing passive measurement of one-way delay [1] for subsequent packets (e.g. of a flow) and then calculating the differences. Jitter is particularly robust with respect to differences and skews of the clocks of the measurement points. This allows performing jitter measurements even if the TPDs are not synchronized. As described in [8], indications of reciprocal skew of the clocks can be derived from the measurement and corrections are possible. The measurement requires the collection of data at two measurement points at least (in our case the TPDs) situated at the end points of the flow. If more measurement points are involved in the measurement, detailed information on jitter values on the different path segments (or autonomous systems) can be obtained. The data returned by the TPDs need to be collected and post-processed to calculate the jitter. These actions are performed at a collector where data collected at the TPDs are exported to, and an evaluator, where the delay variation is computed. In an inter-domain environment it is crucial to have standard formats and protocols to export measurement results. The IP Flow Information eXport (IPFIX) [7] protocol is about to become a standard for exporting flow information from routers and probes, while standardized methods for packet selection and the export of per packet information will be provided by the IETF group on packet sampling (PSAMP) [21]. 4.2 Measurement Service Deployment at the TCSP Layer The network user requests the TCSP to deploy the jitter monitoring service in the network, selecting the service from among those that the TCSP has made available (see Figure 2). The service, with the parameters it requires are described in the service description (see Figure 3a), while the user provides the necessary parameter values in the service request shown in Figure 2. In the service request, the user identifies itself as the owner of the source address of the flow and specifies parameters necessary to the measurement service. Parameters listed are the source and destination addresses of the flow, the addresses of the uplink interface of source A to ISP1 and the downlink interface from ISPn to the flow destination Z, and the address of the data collector the measurement results have to be sent to. A set of fields that allow to further specify the flow to be measured are optional. In this example, we provide also source and destination ports. The user can specify start and end time of the measurement. These parameters are defined as optional in the TCSP layer service description (see Figure 3a). That is, if no value is provided default values are used: the service is started immediately, as specified with the default element and/or ended when the given flow ends using a flow termination criterium that is hard coded into the service component. The TCSP maps the request to the sub-service component jitterOnEgressRouters and selects appropriate ISPs according to the restriction as defined in the restrictionDefinition. In our case, this restriction limits the ISPs to those on the BGP path between A and

8


Fig. 2. Service request and deployment

Z 2 . The restriction yields true if the ASnumber taken from the context database is one that can be found on the BGP path. The TCSP obtains the BGP path using the function getBGPPath specified in the service description for the TCSP layer (see Figure 3a). Required and optional parameters needed by the jitterOnEgressRouters sub-service complete the description. The parameters can be defined as fixed values, taken from the network user’s service request or calculated using a function (e.g. getNextAS). 4.3 Measurement Service Deployment at the ISP Layer ISPs in turn select appropriate TCUs and TPDs to deploy and configure the jitter service components according to the service descriptor in Figure 3b. The restrictions are to deploy the service ”only on egress routers on the path from previous autonomous system prevAS to next autonomous system nextAS (refID 1) and at the uplink (refID 2) and downlink interfaces (refID 3)”. The sub-services, or service components, to be deployed on all selected TPDs are specified in the service descriptor: pktSelection, timestamp, IDGeneration, jitterRecordGeneration, ipfixExport. The deployed components are shown in Figure 4. Packets belonging to the flow to be measured are first selected and then timestamped. Timestamping should be done as early as possible in order to get the best possible accuracy for the arrival time and to reduce further variable delay effects like variations in packet processing time. The selection function could either select all subsequent packets in a 2

In case of BGP route changes the service must be deployed again using the same descriptors.


(a)

(b)

Fig. 3. Jitter measurement service description at the TCSP layer (a) and at the ISP layer (b)

9

10


Fig. 4. Jitter measurement service components

given time interval, or be a sampling function. In our scenario, the pktSelection function selects all packets matching the parameters specified in the request: source and destination address, and source and destination port. It is necessary to recognize the same packets captured at different measurement points to correlate packet arrival events. To recognize a packet parts of its header and eventually payload need to be captured. To reduce the amount of measurement data a unique packet ID can be calculated from the header and part of the content e.g. by using a CRC or hash function [12,10,23]. This identifier must be unique during a relatively long period of the flow measurement in order to avoid duplicate packet identification. At least, timestamp and packet ID need to be exported. Packet size should be reported as well since it influences the measurement: the delay measurement starts with the first bit of the packet sent from the source and ends with the last bit received at destination. These data are exported with IPFIX using the solution proposed in [4], that optimizes the export of per-packet information and is therefore particularly suited in case of jitter measurements. 4.4

Scalability Considerations

The scaling factors that our distributed traffic control service depends on are 1) the number of service subscribers (i.e. network users), 2) the total number of ISPs deploying our service, 3) the number of service components installed per network user, and 4) the bandwidth of network links. These scaling factors influence several parameters: Service logic and state per TPD. Following the estimation made in [5] on the number of users and number of services run on a TPD per user, the memory needed is a rather modest requirement. Signalling effort. Even if we assume that each AS corresponds to one ISP and that all ISPs offer our distributed traffic control service, signalling overhead due to the secure distribution of the small service deployment messages by the TCSP to a few thousand ISPs is not a bottleneck. Traffic processing capacity. A hardware based solution for our traffic processing devices is favorable. Research prototypes of FPGA based devices exist that can


11

concurrently filter 8 mill. flows [22] on a 2.5 Gbps (OC-48) link. According to [2], faster FPGAs allow achieving advanced packet filtering at 10 Gbps (OC-192). A more detailed scalability analysis can be found in [5].

5 Conclusions In this paper, we have shown how guarantees given in an SLA spanning multiple autonomous systems can be validated by setting up inter-domain QoS measurements. We described a scenario where an end-to-end jitter measurement service is deployed and automatically configured with our management system using a service description language. The jitter measurement service is executed on a programmable traffic control system, able to safely delegate partial control over traffic processing devices to network users. Our system allows network users to deploy almost arbitrary measurement logic on distributed traffic processing devices attached to routers located in different autonomous systems. The service deployment has just a few restrictions, that guarantee against negative influence on network stability or other user’s traffic. The measurement service is highly modular, i.e. composed of functional components. This modularity has the advantages of reusability of some components in other services, and it simplifies restriction compliance tests. Thus, we provide a network user with the means to locate his measurement logic on the end-to-end path to be monitored, and ISPs with guarantees against collateral damage due to users’ intended or unintended misbehavior. Jitter measurement is by no means the only service that can be provided by our TCS: one way delay, one way loss, RTT, flow volume are other metrics that can be measured (just to cite a few). Inter-domain measurement is not even the only application for our system. Mitigation of DDoS attacks, as well as other emerging applications based on the presented TCS have already been investigated in [9,5] and showed promising results. Leveraging acceptance by ISPs is vital. We think that our traffic control system offers many incentives for ISPs and at the same time a high level of security against misuse, which was a major concern with other approaches in the field of active and programmable networks and is still one of the major concerns in inter-domain data exchange or control delegation. Currently, we are implementing the measurement service components for Click router– [18] and Field Programmable Gate Array (FPGA)–based [19] traffic processing devices.

References 1. Almes, G., Kalidindi, S., Zekauskas, M.: RFC 2679, A One-way Delay Metric for IPPM (September 1999), ftp://ftp.rfc-editor.org/in-notes/rfc2679.txt 2. Attig, M., Lockwood, J.W.: A Framework for Rule Processing in Reconfigurable Network Systems. In: Proceedings of IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM), Napa, USA (April 2005) 3. Boschi, E., Denazis, S., Zseby, T.: A Measuremnet Infrastructure for Inter-domain SLA Validation. Elsevier Journal of Computer Communications: Special Issue on End-to-end QoS Provision Advances (to appear)

12


4. Boschi, E., Mark, L.: Use of IPFIX for Export of Per-Packet Information, Internet-draft, work in progress (2005) 5. Bossardt, M., Dübendorfer, T., Plattner, B.: Enhanced Internet Security by a Distributed Traffic Control Service Based on Traffic Ownership. Elsevier Journal of Network and Computer Applications: Special Issue on DDoS and Intrusion Detection (to appear, 2005) 6. Bossardt, M., Hoog Antink, R., Moser, A., Plattner, B.: Chameleon: Realizing Automatic Service Composition for Extensible Active Routers. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982. Springer, Heidelberg (2004) 7. Claise, B., Bryant, S., Sadasivan, G., Leinen, S., Dietz, T.: IPFIX Protocol Specification, Interrnet-draft, work in progress (2005) 8. Demichelis, C., Chimento, P.: RFC 3393, IP Packet Delay Variation (November 2002), ftp://ftp.rfc-editor.org/in-notes/rfc3393.txt 9. Dübendorfer, T., Bossardt, M., Plattner, B.: Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation. In: IEEE Proceedings of IPDPS, International Workshop on Security in Systems and Networks SSN (2005) 10. Duffield, N., Grossglauser, M.: Trajectory Sampling for Direct Traffic Observation. In: ACM SIGCOMM 2000 (2000) 11. Calhoun, P., et al.: RFC 3588, Diameter Base Protocol (September 2003), ftp://ftp.rfc-editor.org/in-notes/rfc3588.txt 12. Graham, I.D., Donnelly, S.F., Martin, S., Martens, J., Cleary, J.G.: Nonintrusive and accurate measurement of unidirectional delay and delay variation on the internet. In: INET 1998 Proceedings (1998) 13. Internet Engineering Task Force, http://www.ietf.org/ 14. IP Performance Metrics (IPPM), http://www.ietf.org/html.charters/ippm-charter.html 15. IPMP homepage, http://watt.nlanr.net/AMP/IPMP/ 16. IP Flow Information Export (IPFIX), http://www.ietf.org/html.charters/ipfix-charter.html 17. Jacobs, P., Davie, B.: Technical Challenges in the Delivery of Interprovider QoS. IEEE Communications Magazine, 112–118 (June 2005) 18. Kohler, E., Morris, R., Chen, B., Jannotti, J., Kaashoek, M.F.: The Click Modular Router. ACM Transactions on Computer Systems 18(3), 263–297 (2000) 19. Lockwood, J., Naufel, N., Turner, J., Taylor, D.: Reprogrammable network packet processing on the field programmable port extender (FPX). In: Proceedings of the ACM International Symposium on Field Programmable Gate Arrays (FPGA 2001) (February 2001) 20. NIMI National Internet Measurement Infrastructure, http://www.ncne.nlanr.net/nimi/ 21. Packet SAMPling (PSAMP), http://www.ietf.org/html.charters/psamp-charter.html 22. Schuehler, D.V., Lockwood, J.W.: A Modular System for FPGA-based TCP Flow Processing in High-Speed Networks. In: Becker, J., Platzner, M., Vernalde, S. (eds.) FPL 2004. LNCS, vol. 3203, pp. 301–310. Springer, Heidelberg (2004) 23. Zseby, T., Zander, S., Carle, G.: Evaluation of Building Blocks for Passive One-way-delay Measurements. In: Proceedings of Passive and Active Measurement Workshop (PAM) (2001)

Cross-Layer Peer-to-Peer Traffic Identification and Optimization Based on Active Networking* I. Dedinski1, H. De Meer1, L. Han2, L. Mathy3, D.P. Pezaros3, J.S. Sventek2, and X.Y. Zhan2 1

Department of Mathematics and Computer Science, University of Passau, Passau, Germany, 94032 {dedinski,demeer}@fmi.uni-passau.de 2 Department of Computing Science, University of Glasgow, Scotland, UK, G12 8QQ {lxhan,joe,xyzhan}@dcs.gla.ac.uk 3 Computing Department, Lancaster University, Lancaster, UK, LA1 4WA {laurent,dp}@comp.lancs.ac.uk

Abstract. P2P applications appear to emerge as ultimate killer applications due to their ability to construct highly dynamic overlay topologies with rapidlyvarying and unpredictable traffic dynamics, which can constitute a serious challenge even for significantly over-provisioned IP networks. As a result, ISPs are facing new, severe network management problems that are not guaranteed to be addressed by statically deployed network engineering mechanisms. As a first step to a more complete solution to these problems, this paper proposes a P2P measurement, identification and optimisation architecture, designed to cope with the dynamicity and unpredictability of existing, well-known and future, unknown P2P systems. The purpose of this architecture is to provide to the ISPs an effective and scalable approach to control and optimise the traffic produced by P2P applications in their networks. This can be achieved through a combination of different application and network-level programmable techniques, leading to a cross-layer identification and optimisation process. These techniques can be applied using Active Networking platforms, which are able to quickly and easily deploy architectural components on demand. This flexibility of the optimisation architecture is essential to address the rapid development of new P2P protocols and the variation of known protocols.

1 Introduction and Motivation P2P overlays do not adopt any notions of centralised management nor do they employ the traditional static client/server paradigm. Most of the peers in a P2P network are symmetric and can allow their resources to be shared amongst other peers to deliver a common service [Ora01]. Consequently, within a file sharing P2P overlay every peer *

This work has been supported by the grant EPSRC GR/S69009/01 and EuroNGI NoE.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 13–27, 2009. © IFIP International Federation for Information Processing 2009

14

I. Dedinski et al.

can simultaneously act as a server and a client, fetching and providing data objects that range from a few megabytes to approximately one gigabyte in size [GDS03]. By exploiting a user-configurable, arbitrary amount of peers’ end-systems resources, a P2P overlay can perturb the Internet in new ways by constituting random nodes and portions of the network highly loaded for an unpredictable amount of time. Internet Service Providers (ISP)s can hence experience rapidly varying traffic patterns at nonstatically-provisioned portions of their networks, which can adversely impact the network performance experienced by all traffic flows. For example, a recent study that analysed traffic collected from a 1 Gb/s link connecting an ISP backbone to several ADSL areas revealed that at least 49% of the overall traffic is due to P2P applications, as this has been reported by well-known transport port numbers [AG03]. In addition, it has also been recently reported that the proportion of P2P traffic on Tier 1 networks is steady if not increasing the last two years [KBB04]. This, coupled with the dynamicity of P2P traffic, can impact not only the peering relationships among ISPs, but also the volume-based charging imposed by upstream providers. Traditional tools for network management support quite static forms of network and traffic engineering usually based upon offline post-analysis of monitored data and estimated approximation of path, traffic and demand matrices [GR02]. However, the rapidly varying traffic patterns expected by P2P flows are not addressed by such tools, since P2P requests are not guaranteed to be addressed to a few popular servers, as is the case for the client-server environment [SW02]. Rather, the main dynamic of P2P systems is the advertisement of new data objects, which can appear at arbitrary peers [GDS03], and hence operators are in need of more dynamic (real time) mechanisms to provide fine control over the network-wide P2P traffic flow. A longer-term perspective of P2P dynamics is the constant evolution of P2P protocols and the creation of new P2P applications, which are rapidly spreading over the Internet. The P2P phenomenon is still relatively recent and does not conform to any standards or rules regarding program interfaces, connection behaviour, etc. The mutation of the P2P protocols as well as the appearance of new protocols makes tracking of P2P traffic steadily more complicated and static planning of network resources less successful. The P2P community is averse to ISP control of any kind and invents protocols that attempt to prohibit and avoid traffic identification, shaping and blocking. An ISP, therefore, needs to track actual P2P development and to adapt on new techniques and protocols quickly. The store-compute-and-forward model of operation facilitated by network node programmability is particularly suitable for such dynamic, non-standardised and highly unpredictable systems. The additional intelligence and control that is integrated with the network’s main forwarding operation can be exploited to provide for dynamic identification of P2P traffic, and consequently for network performance optimisation in the onset of P2P activity. Such traffic control enforcement can also employ application-aware programmable mechanisms that do not simply shape and block P2P traffic, but favour well-behaved P2P systems and optimise the overall resource utilisation of the network. A comparative study of different programmable network architectures can be found in [CMK99] This paper focuses on the investigation and deployment of a synergistic networklayer and application-aware programmable framework aimed at measuring, managing, and optimising the performance in networks that support P2P applications. Section 2

Cross-Layer Peer-to-Peer Traffic Identification and Optimization

15

discusses existing P2P identification and optimisation approaches and raises its limitations. Section 3 describes the architectural properties of an always-on programmable system that exploits network and application-level knowledge to synergistically detect and the onset of P2P activity and employ traffic optimisation algorithms over both the overlay and the physical network topologies. Preliminary analysis has initially focused on the network-level identification of P2P flows based on their internal traffic behaviour, and comparison between the performance characteristics of P2P and non-P2P flows are presented in section 4. In addition, wavelet analysis results that demonstrate the existence of discriminating information within P2P traffic behaviour are presented. Section 5 concludes the paper and outlines future work directions.

2 P2P Traffic Identification and Optimization Challenges Currently, there are three, widely-used approaches for passive P2P traffic identification: application signatures, transport layer ports and network/transport layer P2P pattern recognition based on heuristics. The application signatures based approach [SSW04] searches for protocol specific patterns inside the packet payloads. The simplicity of this method is obvious, but it also introduces some important problems. First, it cannot be adapted automatically to unknown, recently-introduced P2P protocols. Enhancements to existing protocols, as well as the appearance of new protocols, occur frequently. Second, application-level pattern search in each transport packets creates a higher load compared to other network and transport-layer-based approaches. Finally, some P2P protocols avoid payload inspection by using encryption algorithms. The transport layer port identification [SW02] solves the last two problems. It is easy to use, does not produce too much load at the measurement nodes and does not rely on inspecting application payloads. This method suffers from inability to adapt to modified or recently-introduced protocols. Furthermore, many P2P applications have begun using variable or non-P2P port numbers (HTTP, FTP, etc.) to deliberately avoid port-based identification and allow P2P communication through firewalls. As a result, port-based P2P identification highly underestimates the actual P2P traffic volume [KBB03]. Heuristic based network/transport layer approaches [KBB03, KBF04] use simple network/transport layer patterns, e.g. the simultaneous usage of UDP and TCP ports and the packet size distribution of a P2P flow between two peers. This method gives good performance for existing P2P protocols and can even be used to discover unknown protocols. The problem here, however, is that it is straightforward to construct a new P2P protocol, effectively avoiding the proposed heuristics. Recently, it has been suggested that the observation of host behaviour and the identification of social, functional and application-level patterns therein can lead to accurate traffic classification that obviates the aforementioned concerns [KPF05]. Active P2P traffic identification approaches (active probing) have been used to traverse and gather topological information about different types of P2P networks [Gnu, Tuts04, KaZ]. These approaches use some probing peers called crawlers to connect to a desired P2P network. The crawlers then issue search requests and collect the IP addresses of the answering peers. By collecting these addresses, one can

16

I. Dedinski et al.

reconstruct the overlay topology of the P2P network. One obvious advantage of constructing such a topology is that subsequent P2P traffic measurement and identification needs to concentrate only on flows coming from or directed to IP addresses collected by the crawler. This improves the identification performance considerably and is an example of how application-aware, active probing can support passive P2P identification approaches. On the other hand, active probing has its limitations. In the eDonkey network, for example, it is only possible to discover the eDonkey superpeers in an efficient way. Identifying eDonkey clients can be done efficiently by using passive P2P identification approaches, which track flows coming from and directed to eDonkey superpeers. Therefore, a combination of application-aware active probing and network-level passive identification techniques is a promising strategy. As it has already been mentioned, network-layer controlling techniques do not consider preserving or even improving the functionality and performance of the P2P network. This goal can be achieved by using application-layer optimisation approaches [ADD04, Fry99, DeMeer03, GDS03, LHK04, LBB02, THH04], which all rely on P2P traffic redirection, shaping or proxy caching. These approaches work fine for a big number of P2P protocols, which are still widely open (not encrypted and can be reverse-engineered), so the redirection and shaping are possible. Application-aware programmable mechanisms can transparently provide for micro-services such as application-level routing, and application-specific resource discovery and differentiation. An ISP-controlled overlay mesh can be established in this way to manage the associated (P2P) traffic flows, through an understanding of application-specific data transfers without knowing the details of the underlying physical network. However, application-level approaches are strongly dependent on application-specific semantics. A programmable networking infrastructure that enables the deployment of specific application-aware optimiser and identification components for new, recently reverse-engineered P2P protocols is required, On the other hand, network-layer controlling techniques (shaping and blocking) do not depend on application protocol internals. The combined use of both network-level and application-level optimisation techniques to enforce control mechanisms to optimise the overall network operation opens new promising grounds for research and, at the same time, yields many integration issues. A straightforward example of such synergy is to force P2P clients to use a certain application layer optimisation service provided by the ISP by blocking and shaping non-conforming P2P traffic at the network layer [MTT03].

3 Architectural and Experimental Design This paper describes an always-on Monitoring Measurement and Control (MMC) architecture for P2P identification and network optimization deployed on programmable nodes at strategic points in the network. The choice of these points depends on numerous factors such as programmable node performance, and network topology and load. Instead of statically specifying strategic points, MMC relies on the dynamic instantiation of ALAN proxylets [Fry99] to allow the on-demand installation and removal of components at different programmable network nodes. Such approach also


17

allows the fast deployment of application-specific modules for P2P protocols that have been newly reverse-engineered. The ALAN infrastructure operates synergistically with the LARA++ active router framework, essentially offering an additional application-specific programmable layer. LARA++ is a software implementation of a programmable router that augments the functionality of a conventional router/host by exposing a programmable interface, allowing active programs -referred to as active components- to provide network level services on any packet-based network [SFS01]. Figure 1 shows the coarse structure of the proposed architecture. It is divided in three processing planes spread across the network and application layers. These planes try to synergistically address the identification and optimisation challenges presented in section 2. Additionally, a communication module is used to exchange locally collected data among programmable nodes. Its purpose is to enable global identification and optimization of P2P traffic. The communication module can for example be implemented in a centralistic way (programmable nodes exchange information through a central database server). Other possible communication approaches like the construction of a decentralized programmable node overlay structure. This paper does not rely on any particular design of the communication module.

Fig. 1. Architecture – Two Layer Programmability

Measurement and Identification Planes The measurement plane takes as input the traffic, passing through its network node. It captures and aggregates relevant microflow patterns used for traffic clustering. A microflow can be easily identified at the network layer by a 5-tuple including the source and destination IP addresses, transport protocol and transport layer source and destination port numbers, if not encrypted [CBP95, Cla94]. In contrast to common passive flow measurement systems that only record aggregate flow indicators [Bro97, NFL], the flow-based classification and measurement employed by this architecture needs to keep per-packet state in order to compute performance properties such as packet inter-arrival time and packet size distributions. Such state needs to be captured continuously but at the same time reduced at a minimum by periodically substituting perpacket information with aggregate statistics. Packet timestamps and lengths kept for each active flow are being periodically aggregated by the pattern detection measurement modules to distribution summary statistics. The raw indicators are subsequently

18

I. Dedinski et al.

removed from the flow table. Further state reduction through sampling is considered with systematic count-based sampling schemes being appropriate candidates due to the simplicity of the sampling algorithm, but also due to its ability to capture the traffic’s burstiness and produce accurate approximation of the parent population for both single and multi-point performance metrics [CPB93, Zse05].

(a)

(b)

Fig. 2. (a) Identification-Measurement Plane and (b) Optimization Plane

Figure 2(a) presents a more detailed view on the components of the identification and measurement planes. Plug-in measurement modules that are implemented as ALAN proxylets act as microflow pattern detectors and periodically compute properties of the identified microflows in order to classify them into similarity classes, according to some per-packet and/or inter-packet characteristics. Estimates of the packet size distribution, for example, can be used to distinguish bulk from interactive and signalling TCP flows. Although this can prove more challenging than exploiting simple heuristics, interactive flows’ dependence on user-behaviour can be revealed from the periodicity of their time series as well as from their distribution’s heavy tails. The main dynamic behaviour of the measurement process lies in the ability of new instances of measurement-based pattern detector ALAN proxylets to be loaded ondemand to compute additional metrics. This also influences the operation of the traffic monitor and shaper which can be dynamically configured to record and deliver additional per-packet information passed to the corresponding microflow pattern detector. The microflow patterns collected at the measurement layer are stored in a flow database. The microflow classifier component, which is located at the identification plane, searches for correlations between microflows passing through this access point node. The microflows are clustered into similarity classes according to the patterns collected at the measurement plane. Supervised and unsupervised adaptive techniques for flow classification can be applied to discover similarity classes. A comparative study of classification (clustering) methods is presented in [Zai97]. Unsupervised techniques have the advantage of detecting new unknown traffic classes. The addresses of all source and the destination hosts producing traffic in the same similarity class are collected in the database. With this information, a topology can be constructed, containing all hosts that produce traffic belonging to that similarity class. The micro and


19

macroflow information (patterns, similarity classes) is stored with some history, which allows the correlation of flows that are not necessarily passing through the instrumented node at the same time. The macroflow classifier uses the topology information to distinguish between P2P like traffic and non-P2P traffic. For example in P2P systems the participating nodes are mostly acting both as client and server. A P2P topology collected by the macroflow aggregator would thus contain incoming and outgoing flows for the most of the nodes. On the other hand, a topology collected for the HTTP protocol would have a two level hierarchical structure, with each node uniquely identifiable as a server or a client. And a DNS topology would have a multi level hierarchical structure. The knowledge about the topology is a powerful traffic identification criterion, which can help to identify even unknown traffic. The macroflow aggregator exports its macroflow knowledge to the other programmable nodes by using the communication module. Respectively, the macroflow classifier uses macroflow information coming from the communication module to construct a local view of a certain traffic topology and to decide whether it is P2P like. Finally active crawler ALAN proxylets are dynamically loaded at the application layer to traverse and discover the overlay networks of reverse-engineered P2P protocols. The results of the crawlers are stored into the flow database and are compared with the results of the identification components at the network layer in order to improve and verify the performance of the latter. Optimization Plane Based on the information collected and produced by the measurement and the identification planes, optimization and manipulation actions regarding identified P2P protocols can be taken at the optimisation plane (Figure 2(b)). The blocking and shaping component for unknown P2P traffic initiates network level actions, without semantic knowledge about a P2P protocol. Such actions can be priority-based routing, complete blocking or bandwidth limits for certain traffic flows (similarity classes). These actions may have regional or global character. The P2P optimizer components do not block or shape P2P traffic, but instead redirect it, thus avoiding network congestions and at the same time improving the P2P network performance. Different applicationlevel optimization techniques are applicable for different P2P protocols, so the application optimizer component has to be adjusted to a predefined set of supported applications. Some of the application level techniques need to install blocking or shaping strategy components for the network layer to prohibit P2P traffic to run around the optimizing entities (P2P caches, proxies). Experimental Design A critical aspect of the methodology described above is to determine the network-level characteristics of P2P application traffic of relevance to different microflow pattern detectors. An isolated network tracing environment has been constructed to capture traces of synthetic traffic from a number of P2P applications. An eDonkey-specific setup using this environment is shown in Figure 3 below.

20

I. Dedinski et al.

Fig. 3. Experimental Packet Capture Environment

Isolated experimental configurations have been setup in three participating sites (universities of Glasgow, Passau, and Lancaster), and initial tests using the eDonkey protocol have been conducted. No other network traffic was active on the sub-nets behind the isolation routers, although the traced traffic was subject to variable delays due to congestion in the campus intra-networks and the Internet. The analysis discussed below was with respect to a single content-providing peer interacting with a single downloading peer at a remote site. After a short search for the content at the superpeer, the downloading peer initiated the download of a 600 MB file from the providing peer. Full packet traces were recorded at the edges of each isolated configuration by GPS-synchronised GigEMON passive monitoring systems, which are engineered to perform lossless, full-packet capture of traffic in both directions to disk storage [End]. Pattern Detection Methodology The initial approach to detecting network-level packet patterns is to look for specific temporal behaviours associated with the packets in a P2P micro-flow. For timedependent processes that are stationary, the traditional approach is to perform a Fourier analysis of the signal, thus converting the large number of experimental data points to a small, bounded number of coefficients for the Fourier basis functions in the Fourier expansion of the signal. Due to the time varying nature of the Internet, one does not expect the temporal behaviour of a micro-flow to be stationary. Wavelet analysis techniques [Chu92] have been developed to address temporal behaviour that is non-stationary. Wavelet techniques exhibit good time resolution in the high frequency domain (implying good localization in time) as well as good frequency resolution in the low frequency domain [AV98]. For a non-stationary signal, wavelet analysis can determine sharp transitions simultaneously in both frequency and time domains. This property of wavelet analysis makes it possible to detect hidden but highly regular traffic patterns in packet traces. The result of wavelet analysis is a small, bounded number of coefficients for scaling and wavelet basis functions.


21

Initially, the collected eDonkey traces have been subjected to wavelet analysis to understand whether such analysis provides the ability to distinguish eDonkey traffic from non-eDonkey traffic. To that end, analysis results for an FTP session transferring the same file in the experimental environment are provided for comparison with the eDonkey analysis results in the following discussion.

4 Preliminary Analysis and Results Before discussing the results of wavelet analysis, it is informative to first look at various statistical characterizations of the measured traces. The initial focus has been with respect to packet inter-arrival time and packet size distributions. Each flow consists of control packets used by the applications to locate and initiate data transfers and data packets that correspond to the actual download of the requested content. The packet patterns for these two, different sub-flows are expected to exhibit significantly different characteristics, since the control/signalling traffic is an RPC-style interaction at the application level, while the data traffic is more characteristic of an asynchronous, reliable flow from the server to the client. Therefore, signalling and data traffic are considered separately below. Inter-Arrival Time Distributions Figures 4 and 5 below show the probability/frequency distribution functions for the inter-arrival time distributions for the data and signalling sub-flows, respectively. Two observations are immediately obvious from these figures: •

•

The data streams exhibit resonances at the same values of packet inter-arrival time; even though the resonance at 10-4 seconds for the p2p data sub-flow is more pronounced than for the ftp flow, it is not sufficiently significant to confidently discriminate between eDonkey and FTP based upon this evidence alone. The signalling sub-streams, on the other hand, exhibit significant differences in their inter-arrival time spectra, especially for large inter-arrival times. If these differences persist over different congestion regimes of the intervening networks (to be established experimentally in future work), then it is feasible that high-confidence discrimination can be achieved with appropriate pattern matching filters.

(a)

(b)

Fig. 4. Probability distribution as a function of packet inter-arrival time (in seconds) for (a) eDonkey data and (b) ftp data flows

22

I. Dedinski et al.

(a)

(b)

Fig. 5. Frequency distribution as a function of packet inter-arrival time (in seconds) for (a) eDonkey control and (b) ftp control flows

Packet Size Distributions Figures 6 and 7 below show the frequency distribution functions for the packet size distributions for the data and signalling sub-flows, respectively. Two observations are immediately obvious from these figures: •

•

The data streams exhibit strong resonances at essentially the same values of packet size; note that the p2p data sub-flow exhibits a small number of packets interspersed between the two strong resonances; it is not clear whether the presence of these intermediate packet size values is sufficiently significant to confidently discriminate between eDonkey and FTP based upon this evidence alone. The signalling sub-streams, on the other hand, exhibit differences in their packet size spectra, especially for large packet sizes. If these differences persist over different congestion regimes of the intervening networks (to be established experimentally in future work), then it is feasible that highconfidence discrimination can be achieved with appropriate pattern matching filters.

(a)

(b)

Fig. 6. Frequency distribution as a function of packet size (in bytes) for (a) eDonkey data and (b) ftp data flows


(a)

23

(b)

Fig. 7. Frequency distribution as a function of packet size (in bytes) for (a) eDonkey control and (b) ftp control flows

Note that analysis by others has yielded similar insights [Nla]. The results for the signalling sub-stream, if they hold across congestion regimes, augurs well for developing pattern matching filters for detection of control sub-flows when the packets are encrypted, as most encryption schemes are packet-size preserving, modulo padding introduced to make the packet size a multiple of 4 or 8 bytes. Wavelet Analysis Despite the fact that the distributions for the p2p and ftp data flows shown in figures 4 and 6 do not show significant differences, scatter plots of these traces with respect to both attributes do show significantly more variation in the p2p trace than in the ftp trace (not shown due to space reasons). This indicates that there is scope for discriminating between such traces. The first attempt at such discrimination has been through the use of wavelet analysis. Only aspects of wavelet analysis that are critical to this application are discussed below; interested readers are urged to consult [DAU92] for more details. In terms of wavelet theory, a signal Y0(t) (e.g. bursty traffic) can be represented as: J

Y 0 (t ) = Y J (t ) + ∑ detail j {Y (t )} j =1

J

= ∑ a (k )ϕ J ,k (t ) + ∑∑ d Yj (k )ψ j ,k (t ) J Y

j =1 k

k

where k and j denote time and frequency indices, respectively. The ing (approximation) coefficients, and the

aYJ (k ) are scal-

d Yj (k ) are wavelet (detail) coefficients. A

scaling function with low-pass filter properties

ϕ J ,k

is used to capture an approxima-

tion signal (low-frequency signal), and a wavelet function ψ

j, k

with band-pass filter

properties is used to extract the detailed information (high-frequency signal).

24

I. Dedinski et al.

Wavelet signal analysis consists of three primary phases: •

The analysis phase decomposes the data into a hierarchy of component signals by iteration. Starting with a signal S, the first step of the transform decomposes S into two sets of coefficients, namely approximation coefficients

aY1 (k ) and de-

j

• •

tail coefficients d Y (k ) . The input S is convolved with the low-pass filter to yield the approximation coefficients. The detail coefficients are obtained by convolving S with the band-pass filter. This procedure is followed by down-sampling by a factor of 2, and this process is then applied to the down-sampled signal. At each iteration of this phase, the input is a signal of length N, and the output is a collection of two or more derived signals which are all of length N/2. We obtain the approximation signal at the highest level j and the collection of detail coefficients at each level until the end of decomposition. The signal processing phase compresses, de-noises and detects the underlying signal by modifying some wavelet coefficient values and then reconstructs the signal using these altered wavelet coefficients. The synthesis phase is the inverse of the iteration phase.

The wavelet coefficients are key to matching the spike pattern of a signal. By focusing on the Probability Density Function (PDF) of wavelet coefficients, one can determine the algorithm for selecting a suitable threshold and dropping nonsignificant coefficients when reconstructing the signal. Tools to perform this analysis on micro-flow, inter-arrival time distributions obtained from the the experimental environment described in section 4 above have been developed and validated. These tools have been applied to the data sub-flow distributions shows in figure 4 above. Exploration of the information resulting from these analyses is in its beginning stages; the initial focus has been to concentrate on measures of the significance of wavelet coefficients at each decomposition level, denoted by the index j. Table 1 below shows the significance for each decomposition level in the analysis of the p2p and ftp data sub-flow traces. Table 1. Level-specific coefficient significance from wavelet decomposition

p2p ftp

j=1 -5.3490 -9.6785

j=2 -4.5921 -5.3787

j=3 -4.0269 4.5109

j=4 -5.0712 -4.5486

j=5 6.7115 4.8186

j=6 -1.1379 -6.0644

A particularly useful way to visualize the relationships between decompositions for different applications is to plot these values on a radar diagram. Such a diagram is shown in Figure 8 below. From this diagram, it is immediately apparent that the p2p trace is significantly different from the ftp trace at levels 1, 3 and 6. While Figure 4 did not provide sufficient information to discriminate between the two data flows, it is apparent that sufficient discriminating information is contained in the traces.


25

Fig. 8. Wavelet coefficient significance per level for eDonkey and ftp data sub-flows

Real-Time Considerations A micro-flow detector must detect patterns in real-time to feed the optimization layer in the architecture described in section 4. It is important to estimate the ability of a detector based upon wavelet analysis to function in real-time. In order to perform a wavelet analysis to level N, a sufficient number of packets must be accumulated in the inter-arrival time histogram for a micro-flow such that 2N bins have nonzero frequency counts. For example, if analysis to level 3 is sufficient to discriminate the flows of interest, then 8 non-zero bins are required. In addition to considerations regarding minimum number of observations, one must also assure that the time duration of the observed portion of the flow is sufficient to mask any startup transients and to yield a distribution that is representative of the entire flow. As with any predictive technique, the expected accuracy of predictions will improve if more data is available over which to perform the analysis. Given that most p2p sessions are operational for a long period of time, there is a tradeoff to consider between rapidity of prediction versus accuracy of prediction. Reduction of false positives, consistent with rapid enough prediction, is the long-term goal.

5 Conclusions and Future Work This paper has introduced an architecture for exploiting active/programmable networking techniques to manage p2p applications. Crucial to the success of an infrastructure based upon this architecture is the ability to detect onset of p2p activity by passively observing network-level micro-flows. Application-level probing mechanisms can support the network-layer identification process, which can in turn be the basis for application-layer optimisation techniques that improve P2P performance.

26

I. Dedinski et al.

The project has constructed an experimental infrastructure that enables the full packet capture of synthetic micro-flow traffic. The traces resulting from this synthetic traffic enables the assessment of a number of p2p pattern detectors for driving such management activities. The first analysis technique that has been assessed has been based upon the use of wavelets. Preliminary results indicate that these techniques may prove useful for constructing real-time p2p pattern detectors. Future work will focus on extensive measurement and analysis of further invariant factors that can be measured in real-time to identify P2P activity in short timescales. Traces of a number of p2p and non-p2p applications will be captured and analysed to gain confidence in the efficacy of wavelet analysis.

References [ADD04]Andersen, F.U., De Meer, H., Dedinski, I., Kappler, C., Mäder, A., Oberender, J., Tutschku, K.: Enabling Mobile P2P Networking. In: Kotsis, G., Spaniol, O. (eds.) Euro-NGI 2004. LNCS, vol. 3427, pp. 219–234. Springer, Heidelberg (2005) [AG03] Azzouna, N.B., Guillemin, F.: Analysis of ADSL traffic on an IP Backbone link. In: Proceedings of IEEE Globecom 2003, San Francisco, USA, December 1-5 (2003) [AH01] Akansu, A.N., Haddad, R.A.: Multiresolution signal decomposition –Transforms, Subbands, and Wavelets. Academic Press, London (2001) [AV98] Abry, P., Veitch, D.: Wavelet Analysis of Long Range Dependent Traffic. IEEE Transactions on Information Theory 44(1), 2–15 (1998) [Bro97] Brownlee, N.: Traffic Flow Measurement: Experiences with NeTraMet, IETF, Network Working Group, RFC2123 (March 1997) [CBP95] Claffy, K.C., Braun, H.-W., Polyzos, G.C.: A Parameterizable Methodology for Internet Traffic Flow Profiling. IEEE Journal On Sketched Areas In Communications 13(8), 1481–1494 (1995) [Chu92] Chui, C.K.: An introduction to the wavelets. Academic Press, London (1992) [Cla94] Claffy, K.C.: Internet Traffic Characterization. PhD thesis, University of California, San Diego, CA (1994) [CPB93] Claffy, K., Polyzos, G., Braun, H.-W.: Application of Sampling Methodologies to Network Traffic Characterisation. In: ACM SIGCOMM 1993, San Francisco, California, USA, September 13-14 (1993) [Dau92] Daubechies, I. (ed.): Ten Lectures on Wavelets. S.I.A.M (1992) [EH96] Erlebacher, G., Hussaini, M.Y., Jameson, L.M. (eds.): Wavelets: Theory and Applications. Oxford University Press, Oxford (1996) [END] http://www.endace.com [Fry99] Fry, M., Ghosh, A.: Application Level Active Networking. Computer Networks 31(7), 655–667 (1999) [GDS03] Gummadi, K.P., Dunn, R.J., Saroiu, S., Gribble, D., Levy, H.M., Zahorjan, J.: Measurement, modeling, and analysis of a peer-to-peer file-sharing workload. In: Proceedings of the nineteenth ACM symposium on Operating systems principles, Boston, October 19-22 (2003) [Gnu] Gnutella, http://www.gnutella.com/ [GR02] Grossglauser, M., Rexford, J.: Passive Traffic Measurement for IP Operations. In: Park, K., Willinger, W. (eds.) The Internet as a Large-Scale Complex System. Oxford University Press, Oxford (2002)


27

[Kaz] KaZaa, http://www.kazaa.com/ [KBB03] Karagiannis, T., Broido, A., Brownlee, N., Claffy, K., Faloutsos, M.: File-sharing in the Internet: A characterization of P2P traffic in the backbone. Technical report (November 2003) [KBB04] Karagiannis, T., Broido, A., Brownlee, N., Claffy, K.C., Faloutsos, M.: Is P2P dying or just hiding? In: IEEE Global Internet and Next Generation Networks (Globecom 2004), Dallas, Texas, USA, 29 November - 3 December, 2004, [KBF04] Karagiannis, T., Broido, A., Faloutsos, M., Claffy, K.: Transport layer identification of P2P traffic. In: Proceedings of the 4th ACM SIGCOMM conference on Internet measurement 2004 (2004) [KPF05] Karagiannis, T., Papagiannaki, D., Faloutsos, M.: BLINC: Multilevel Traffic Classification in the Dark. In: ACM SIGCOMM 2005, Philadelphia, PA, USA (August 2005) [LBB02] Leibowitz, N., Bergman, A., Ben-Shaul, R., Shavit, A.: Are File Swapping Networks Cacheable? Characterizing P2P Traffic. In: 7th International Workshop on Web Content Caching and Distribution (WCW 2003), Boulder, CO (2002) [LHK04] Le Fessant, F., Handurukande, S., Kermarrec, A.-M., Massoulie, L.: Clustering in peer-to-peer file sharing workloads. In: Voelker, G.M., Shenker, S. (eds.) IPTPS 2004. LNCS, vol. 3279, pp. 217–226. Springer, Heidelberg (2005) [Mal01] Mallat, S.: A Wavelet Tour of Signal Processing. Academic Press, San Diego (2001) [MTT03] de Meer, H., Tutschku, K., Tran-Gia, P.: Dynamic Operation in Peer-to-Peer Overlay Networks. Praxis der Informationsverarbeitung und Kommunikation -Special Issue on Peer-to-Peer Systems (PIK Journal) (June 2003) [NFL] Cisco IOS Netflow, on-line resource, http://www.cisco.com/warp/public/ 732/Tech/nmp/netflow/index.shtml [Nla] http://www.nlanr.net/NA/Learn/packetsizes.html [Ora01] Oram, A. (ed.): Peer-to-Peer: Harnessing the Benefits of a Disruptive Technology. O’ Reilly (2001) [SFS01] Schmid, S., Finney, J., Scott, A.C., Shepherd, W.D.: Component-based Active Network Architecture. In: IEEE Symposium on Computers and Communications (July 2001) [SSW04] Sen, S., Spatscheck, O., Wang, D.: Accurate, scalable in-network identification of p2p traffic using application signatures. In: Proceedings of the 13th international conference on World Wide Web (2004) [SW02] Sen, S., Wong, J.: Analyzing peer-to-peer traffic across large networks. In: Second Annual ACM Internet Measurement Workshop (2002) [THH04] Tagami, B., Hasegawa, T., Hasegawa, T.: Analysis and Application of Passive Peer Influence on Peer-to-Peer Inter-Domain Traffic. In: Proceedings of the Fourth International Conference on Peer-to-Peer Computing. IEEE, Los Alamitos (2004) [Tuts04] Tutschku, K.: A measurement-based traffic profile of the eDonkey filesharing service. In: Barakat, C., Pratt, I. (eds.) PAM 2004. LNCS, vol. 3015, pp. 12–21. Springer, Heidelberg (2004) [Zai97] Zait, M., Messatfa, H.: Comparative study of clustering methods. Future Gener. Comput. Syst. 13(2-3), 149–159 (1997) [zse05] Zseby, T.: Sampling Techniques for Non-Intrusive QoS Measurements: Challenges and Strategies. In: Computer Communications Special Issue on Monitoring and Measurement (to appear, 2005) [CMK99] Campbell, A.T., de Meer, H., Kounavis, M.E., Miki, K., Vicente, J.B., Villela, D.: A Survey of Programmable Networks. ACM SIGCOMM Comput. Commun. 29(2) (April 1999)

Towards Effective Portability of Packet Handling Applications across Heterogeneous Hardware Platforms* Mario Baldi and Fulvio Risso Politecnico di Torino, Dipartimento di Automatica e Informatica, Torino, Italy {mario.baldi,fulvio.risso}@polito.it

Abstract. This paper presents the Network Virtual Machine (NetVM), a virtual network processor optimized for implementation and execution of packet handling applications. As a Java Virtual Machine virtualizes a CPU, the NetVM virtualizes a network processor. The NetVM is expected to provide a unified layer for networking tasks (e.g., packet filtering, packet counting, string matching) performed by various network applications (firewalls, network monitors, intrusion detectors) so that they can be executed on any network device, ranging from high-end routers to small appliances. Moreover, the NetVM will provide efficient mapping of the elementary functionalities used to realize the above mentioned networking tasks onto specific hardware functional units (e.g., ASICs, FPGAs, and network processing elements) included in special purpose hardware systems possibly deployed to implement network devices.

1 Introduction An increasing number of network applications performing some sort of packet processing are being deployed on current IP networks. Well known examples are firewalls, intrusion detection systems (IDS), network monitors, whose execution is must take place in a specific location within the network (e.g., backbone, network edge, on end systems) or, in some cases, be distributed across different devices. In general, such network applications must be deployed on very different (hardware and software) platforms, ranging from routers, to network appliances, personal computers, smartphones. In some cases, the whole range of potential target platforms is not even precisely and finally known at development time. A development and execution platform for packet handling applications with features comparable to the ones of Java and CLR has been thus far not available. This paper reports on work aiming at designing, implementing, and assessing such a platform based on a Network Virtual Machine (NetVM), a new architecture for a (virtual) network processor in which execution of packet handling related functions is *

This work has been carried out within the framework of the QUASAR project, funded by the Italian Ministry of Education, University and Research (MIUR) as part of the PRIN 2004 Funding Program. Its presentation has been supported by the European Union under the E-Next Project FP6-506869.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 28–37, 2009. © IFIP International Federation for Information Processing 2009

Towards Effective Portability of Packet Handling Applications

29

optimized. Specifically, when the NetVM is deployed on network processors or hardware architectures, packet handling related functions can be mapped directly on underlying special purpose hardware (such as ASICs, CAMs, etc) thanks to their virtualization in what are called NetVM coprocessors. This virtual device is programmed with an assembly language, or NetVM bytecode, that supports a set of interactions among the various blocks (e.g. memory, execution units, etc.) inside the NetVM. The project reported by this work addresses also the interaction between NetVM and external environment, e.g. how to download code to the NetVM, how to get the results of code execution, etc.

Fig. 1. NetVM framework

Virtual machines are the basis for the “write once, run anywhere” paradigm, thus enabling the realization and deployment of portable applications. Even though from certain points of view the NetVM has a more limited scope than Java and CLR virtual machines (i.e., the NetVM targets a smaller range of applications), its goals are somewhat more ambitious. In fact, the latter aim at application portability across platforms that, while different from both hardware and software (i.e., operating system) point of view, are similar in being designed to support generic applications. Instead, the NetVM must combine portability and performance; this translates in the capability of effectively deploying available hardware resources (such as processing power, memory, functional units) notwithstanding the significantly different architecture and components of the various hardware platforms targeted. The efficiency and portability of the NetVM has a significant by-product: it makes it a potential candidate for becoming a universal application development platform for network processing units (NPUs). Network processors combine high packet processing rates and programmability. However, programming NPUs is a complex task requiring detailed knowledge of their architecture. Moreover, due to the significant architectural differences, applications must be re-written for each NPU model. Deploying a virtual machine could help dealing with the diversity of network processors by offering a common platform for writing and executing portable applications. On

30

M. Baldi and F. Risso

the one hand, the NetVM hides the architectural details of the underlying NPU from the programmer. On the other hand, being designed specifically for network packet processing, the NetVM has un-matched potential for effective execution on a hardware platform specifically designed for the same purpose. NetVM programming is further simplified by the definition of a high-level programming language that operates according to packet descriptions realized with NetPDL (Network Packet Description Language) [3] and is compiled into native NetVM bytecode, as shown in the top part of Fig. 1. Once NetVM support be provided by commonly deployed network gear, distributed applications could be based on downloading NetVM code on various network nodes and possibly collecting the results deriving by its execution. This paper is structured as follows. Alternatives for the implementation of the NetVM are presented in Section 2. Section 3 outlines the proposed NetVM architecture discussing its main components; performance issues are tackled in Section 4. Section 5 draws some conclusions and briefs current and future work.

2 NetVM Implementation The NetVM aims at providing programmers with an architectural reference, so that they can concentrate on what to do on packets, rather than how to do that. This has been dealt with once for all during the NetVM implementation. This section focuses on how to implement the NetVM on both end-systems and network nodes. Several choices are available, ranging from software emulation — NetVM bytecode is interpreted and for each instruction a piece of native code is executed to perform the corresponding function — optionally with specific hardware support (selected instructions can be mapped to specific hardware available on that platform), to recompilation techniques — e.g. an ahead-of-time (AOT) or just-in-time (JIT) compiler can translate NetVM bytecode into assembler specific for the given platform (es. x86, IXP2400, etc), therefore making use of the processor registers instead of operating on a stack. A further option is to implement the NetVM architecture in hardware, i.e., the proposed architecture can be used as the basis for the design of a hardware device for network processing (e.g. VHDL can be used to create a new chip that implements the NetVM). Taking this option a step further, the NetVM code implementing a set of functionalities (e.g., a NetVM program that tracks the amount of IPv6 traffic) could be compiled in the hardware description of a (possibly integrated) hardware system that implements such functionality (e.g., an ASIC or an FPGA configuration). In other words, the NetVM could provide support to fast prototyping, specification, and implementation of network oriented hardware systems. Since the NetVM design has been modeled after the modern network processor architecture, perhaps the most appropriate implementation option for the NetVM is an AOT/JIT compiler that maps NetVM assembler into a network processor’s native code. This approach also solves one of the problems of network processors, which is their complexity from the programmability point of view.


31

3 NetVM Architecture and Components The main architectural choices of the NetVM were driven by the goal of achieving flexibility, simplicity, and efficiency and built upon the experiences maturated in the field of Network Processing Unit (NPU) architectures since they are specifically targeted to network packet processing. The resulting NetVM architecture is modular and built around the concept of Processing Element (NetPE), which virtualizes (or, it could be said, is inspired to) the actual micro-engine of a NPU. Processing Elements deal with only few tasks, but they have to perform them very fast: they have to process data at wire speed and in real time, they have to process variable size data (e.g. IP payload) or/and fragmented data (e.g. an IP payload fragmented over several ATM cells). In addition, they should execute specific tasks, such as binary searches in complex tree structures and CRC (Cyclic Redundancy Code) calculation with stringent time constraints. Multithreading is an expected feature of a NPU, hence an objective of our architectural design: in fact packets are often independent from each other and suitable to be processed independently. For example, one of the first Network Processors — the Intel IXP1200 — is composed of six processing elements called Packet Engines. The larger the number of Processing Elements, the higher is the achievable degree of parallelism, since independent packets could be distributed to these units.

Exchange Buffer 2

NetPE2 (e.g. session statistics)

Output Port

Input Port

Exchange Buffer 1

Output Port

NetPE1 (e.g. filtering)

Network Data

Network Packet

Input Port

NetVM

General Purpose CPU

Shared Memory

CRC coprocessor

Crypto coprocessor

Classification coprocessor

Fig. 2. NetVM configuration example

A NetPE is a virtual CPU (with an instruction set and local memory) that executes an assembly program that performs a specific function and maintains private state. A NetVM application is executed by several NetPEs (for example, Fig. 2 shows an application deploying two NetPEs), each of which may implement a simple functionality; complex structures can be built by connecting different NetPEs together. Moreover NetPEs use specialized functional units (coprocessors, shown in Fig. 2) and various types of memories to exchange data. This modular view derives from the observation that many packet-handling applications can be decomposed in simple functional blocks that can be connected in complex structures. These structures can exploit parallelism or sequentiality to achieve higher throughput. 3.1 Processing Element (NetPE) Architecture The general architecture of a NetPE includes six registers (Program Counter, Code Segment Length, Data Segment Length, Packet Buffer Length, Connection Table

32


Length, Stack Pointer) in support to the processor operation, a stack used for instruction operands, a connection table whose purpose is outlined in Section 3.2, and a memory encompassing 4 independent segments (Section 3.3). Like most existing virtual processors, the NetVM has a stack-based design where each NetPE has its own stack. A stack-based virtual processor does not encompass general-purpose registers as instructions that need to store or process a value make use of the stack. This grants portability, a plain and compact instruction set and a simple virtual machine. The consequence of this choice is that. The execution model is event-based. This means that the execution of a NetPE is activated by external events, each one triggering a particular portion of code. Typical events are the arrival of a packet from an input, the request of a packet from an output or the expiration of a timer. 3.2 Internal and External Connections Connections are used to connect a NetPE with other NetPEs, with the physical network interfaces, and eventually with user applications. A NetPE can have a number of input and output exchange ports (or ports for the sake of brevity), each coupled to an exchange buffer. Each connection connects an output port of a NetPE to an input port of another one and is used to move data, usually packets, between the two. Although the meaning of a connection is different, the connection model of the NetVM is similar to the one of Click1. Particularly, two types of connections are defined: • •

Push connection: the upstream NetPE passes data to the NetPE at the other end of the connection. This is the way packets usually move from one processing function to the next one in network devices. Pull connection: the downstream NetPE initiates data transfer by requesting the NetPE at the other end of the connection to output a packet. Two options are provided for the downstream NetPE in case no packet is available: (i) it enters a wait state, (ii) an empty exchange buffer is obtained. For example, a NetPE that extracts packets from a buffer and sends them on an output interface uses a pull connection.

Also ports can be either push or pull. The NetVM runtime environment checks the validity of a NetPE interconnection configuration at creation time since there may be some illegal configuration, such as a connection between a push port and a pull port. The number and type of ports of a NetPE is defined by the NetVM application and is maintained in the Connection Table within the NetPE, which is a read-only memory portion. The NetVM runtime environment fills out the connection table during configuration instantiation. Programs can use it to obtain, for every connection, the ID inside NetVM environment, the type (push / pull), and the direction (incoming or outgoing). The NetVM communicates with external entities through of NetVM sockets. For example, if a NetVM is deployed inside the operating system of a desktop PC, external entities could be network devices, file streams or user applications that rely on the NetVM for low-level operations like filtering or network monitoring. 1

In Click [5] a connection is a direct call to a C++ method, while in NetVM it is a communication channel between two independent entities.


33

Applications that are intended to receive packets from a NetVM deploy a socket connected, through a push connection, to the push output port of a NetPE. The transfer of packets is initiated by the virtual machine (i.e., by the connected NetPE) and the application receives them through a libpcap-style [2] callback function. Alternatively, an application that is supposed to request data from a NetVM deploys a socket connected to the pull output port of a NetPE. Pull connections are appropriate to applications that retrieve tables, counters, flows, and other similar data. An advantage of the socket/exchange port model is that transferred data is generic since exchange buffers are simple data containers; it follows that the application does not have any implicit information about the data that it receives, i.e., about data type, which must be provided in some other way. 3.3 Memory Architecture A NetPE has four types of memory: one shared among all NetPEs (shared memory), one for private data (data memory), one (local to the NetPE) that contains the program that is being executed (code memory) and one that contains the data (usually a network packet) that is being processed (exchange buffer). Shared memory can be used to store data that is needed concurrently by more than one NetPE (e.g., routing tables or state information). A NetPE is not compelled to use the shared memory: if it needs only local storage, only the Data Memory segment is used. This architecture allows to better isolate different kinds of memory and to increase efficiency through better parallelization of memory accesses. Memory addresses are 32-bit wide, although we do not expect to have such amount of memory (4GB) in network devices. Since the NetVM may be potentially mapped on embedded systems and network processors, the use of high-level memory management systems like garbage collectors is not feasible. Therefore, the bytecode has a direct view of the memory. Furthermore, the memory is statically allocated during the initialization phase: the program itself, by means of appropriate opcodes, specifies the amount of memory it needs for being able to work properly. Obviously, these instructions can fail if not enough physical memory is present. The flexibility lost with this approach is balanced by higher efficiency: the program can access the memory without intermediation thanks to ad-hoc load and store instructions. Specific instructions for buffer copies (a recurrent operation in network processing; some platform have even ad-hoc hardware units) are provided as well, either inside the same memory or between different ones. Moreover, knowing the position and the amount of memory before program execution allows very fast accesses when an AOT/JIT compiler is used because memory offsets can be pre-computed. 3.4 Exchange Buffers Packets are stored in specific buffers, called exchange buffers, which are shared by two NetPE that are on the same processing path in order to minimize racing conditions (and avoid bottlenecks) when exchanging data. For instance, the NetPE1 in Fig. 2 will copy output data (e.g. the filtered packet) in the exchange buffer, which is then made accessible to NetPE2 for further elaboration (e.g. computing session statistics). Although, in principle, data can be moved from a NetPE to another through the

34


shared memory, this could lead to very poor performance because this memory could become the bottleneck. Vice versa, exchange buffers provide a very efficient exchange mechanism between NetPEs that are on the same processing path. In order to increase packet-handling efficiency, network-specific instructions (e.g. string search) and coprocessors may have direct access to exchange buffers. Instructions for data transfer (to, from and between exchange buffers) are provided as well. Furthermore, instead of moving packet data around, NetPEs can operate on the data contained in the exchange buffer, which are then “moved” from a NetPE to another. This is very efficient because exchanged buffers are not really moved; the NetVM guarantees exclusive access to them, so that only the NetPE that is currently involved in the processing can access to that data. The typical size of exchange buffer is usually limited to some kilobytes; for larger data the shared memory can be used. This stems from the fact that this memory is often used to transport packets, although it can contain also generic data (e.g. fields, statistics or some generic state). In some cases, exchange buffers can contain also sub-portions of packets, as some network processors break packets into separate cells for internal transmission. Usually, a NetPE has a single exchange buffer (i.e. it processes one packet at a time), although the NetPE specification does not prevent to have multiple exchange buffers. Exchange buffers are readable and writeable, although some particular virtual machine implementations could provide read only access for performance purposes or hardware limitations. Under these platforms an AOT/JIT compiler will refuse to build the NetPEs that perform write operations on packet memory. 3.5 Coprocessors The NetVM instruction set is complemented by additional functionalities specifically targeted to network processing. Such functionalities are provided by coprocessors that, as shown in Fig. 2, are shared among the NetPEs. Making coprocessor functionalities explicitly available to the NetVM programmer is beneficial when the NetVM is executed on both general-purpose processors and network processors or special purpose hardware systems. On general purpose systems coprocessors are realized by native code possibly implementing optimized algorithms. Code and data structures can be shared among different modules, thus granting efficient resource usage. For example, in a NetVM configuration with several NetPEs using the CRC32 functionality, the same coprocessor code can be used by all the NetPEs. If the implementation of the CRC32 coprocessor is improved, every NetPE benefits from it without any change in the NetVM implementation or in the application code. Also, more complex functionalities, such as string search or classification, can share data structures and tables among different modules for even better efficiency and resource usage. An example is the AhoCorasick string-matching algorithm, which can build a single automaton to search for multiple strings as requested by different NetPEs. On special purpose hardware systems, such as network processors, coprocessors can be mapped on functional units or ASICs, where present. Consequently, on the one hand the efficiency of NetVM programs is significantly increased when the target platform provides the proper hardware. On the other hand, writing NetVM programs


35

represents a simple way of programming network processors or other special purpose hardware systems without having to know their hardware architectural details, yet while exploiting the benefits of their hardware specificities. Communications with NetPEs is based on a well-defined, generic (i.e., not specific of a given processor) interface based on the IN and OUT assembly primitives, while parameters are pushed on the top of the stack. This guarantees a generic invocation method for any coprocessor without the need of any dedicated instructions; therefore coprocessors can be added without modifying the NetIL bytecode. A “standard” coprocessor library (that includes a classification, a connection tracking, a string search and a checksum coprocessor, although some are still under development) is defined in the NetVM specification: a valid NetVM implementation should implement this library and each program using only coprocessors of the standard library should work on any valid NetVM. Additional coprocessors can be added to the library by NetVM implementations or third party libraries can be “linked” to a NetVM and used by applications that have been written to deploy the functionalities of non-standard coprocessors. 3.6 High Level Programming Language NetVM programs are generally written in a high level programming language designed for networking applications, specifically for packet processing. One of such language (NetPFL) enables manipulations of packets and header fields whose format is described through the Network Packet Description Language (NetPDL) [3]. Although a detailed description of NetPDL and NetPFL is outside the scope of this paper, a sample is shown in Fig. 3 to offer a glance in the complexity of using the NetVM. The code instructs the NetVM to return on its exchange port number 1 all packets that, when parsed as Ethernet frames, contain the value 0x0800 in their EtherType field. In other words, this code implements a filter for IPv4 packets. Fig. 3 shows both the syntax in the NetPFL language and the equivalent in the widely known tcpdump [2] packet filtering application. The comparison shows that, even though the NetVM provides the flexibility of a generic packet processing engine, programming a packet filter is not more complicated than specifying it for tcpdump, i.e., a utility specifically targeted and optimized for packet filtering. Hence, the increased flexibility of the NetVM is not traded for increased programming complexity, as well as for (significantly) lower performance, as discussed in the next section. NetPFL: tcpdump:

ethernet.type == 0x800 ReturnPacket on port 1 ether proto 0x800

Fig. 3. High-level code to filter IPv4 packets, in both NetPFL and tcpdump syntax

4 Performance Evaluation Although the current implementation of the NetVM is still in the early stages, a few numerical results are reported in this section in order to provide a first evaluation of

36


NetVM assembly

BPF assembly

; Push Port Handler

0) ldh

[12]

segment .push

1) jeq 2) ret 3) ret

#0x800 jt 2 jf 3 ; jump to 2) if true, else 3) #1514 ; return the packet length #0 ; return false

.locals 5 .maxstacksize 10 pop ; pop the "calling" port ID push 12 upload.16 push 2048 jcmp.eq send ret

; ; ; ; ;

send: pkt.send out1 ret Ends

; load the ethertype field

push the location of the ethertype load the ethertype field push 0x800 (=IP) cmp the 2 topmost values; jump if true otherwise do nothing and return

; send the packet to port out1 ; return

Fig. 4. NetVM and BPF code to filter IPv4 packets

the proposed architecture. To this purpose the NetVM is compared against the Berkeley Packet Filter (BPF) [1], probably the best-known virtual machine in network processing arena. Fig. 4 shows the assembly code required to implement the filter shown in Fig. 3, for both the NetVM and BPF virtual machines. A first comparison shows that the NetVM assembly is definitely richer than the BPF one, which gives an insight about the possibility of the NetVM assembly. However the resulting program is far less compact (the “core” is six instructions against tree in BPF). This shows one of the most important characteristics of the NetVM architecture: the stack-based virtual machine is less efficient of a competing registerbased VM (such as the BPF is) because it cannot rely on a set of general-purpose registers. Hence, the raw performance obtained by NetVM cannot directly compete against the ones obtained by the BPF. Table 1. NetVM Performance Evaluation Virtual Machine NetVM BPF

Time for executing the “IPv4” filter (clock cycles)

392 64

Table 1 shows the time needed to execute the programs reported in Fig. 4: as expected, the BPF outperforms the NetVM, mainly due to the additional instructions (related to the stack-based architecture) and the poor maturity of the code. However, a NetVM is intended as a reference design and we do not expect its code to be executed as it is. In order to achieve better performance, NetVM code must be translated into native code (thorough a recompilation at execution-time, i.e., AOT/JIT compiling) according to the characteristics of the target platform. This justifies the choice of a stack-based machine, which is intrinsically slower, but its instructions are much simpler to be translated into native code. Performances are expected to be much better after a dynamic recompilation. The implementation of an AOT/JIT compiler is part of our future work on the NetVM.


37

5 Conclusions This paper presents the architecture and preliminary performance evaluation of the NetVM, a virtual machine optimized for network programming. The paper discusses the motivations behind the definition of such architecture and the benefits stemming from its deployment on several hardware platforms. These include simplifying and speeding up the development of packet handling applications whose execution can be efficiently delegated to specialized components of customized hardware architectures. Moreover, the NetVM provides a unifying programming environment for various hardware architecture, thus offering portability of packet handling applications across different hardware and software platforms. Further, the proposed architecture can be deployed as a reference architecture for the implementation of hardware networking systems. Finally, the NetVM can be a novel tool for specification, fast prototyping, and implementation of hardware networking systems. Some preliminary results on the performance of a simple NetVM program shows that other simpler virtual machines targeted to networking applications outperform the NetVM that, in turn, provides higher flexibility. Ongoing work on the implementation of a JIT compiler for NetVM code aims at reversing or at least reducing this performance discrepancy. Since writing NetVM native code (bytecode) is not very handy, work is being done towards the definition of a high level programming language and the implementation of the corresponding compiler into NetVM bytecode. Finally, in order to fully demonstrate the benefits, also in terms of performance, brought by the NetVM, further work includes the implementation of the virtual machine and its AOT/JIT compiler for a commercial network processor.

References [1] McCanne, S., Jacobson, V.: The BSD Packet Filter: A New Architecture for User-level Packet Capture. In: Proceedings of the 1993 Winter USENIX Technical Conference, San Diego, CA (January 1993) [2] Jacobson, V., Leres, C., McCanne, S.: Libpcap, Lawrence Berkeley Laboratory, Berkeley, CA. Initial public release (June 1994), http://www.tcpdump.org [3] Risso, F., Baldi, M.: NetPDL: An Extensible XML-based Language for Packet Header Description. In: Computer Networks (COMNET), vol. 50(5), pp. 688–706. Elsevier, Amsterdam (2006) [4] Degioanni, L., Baldi, M., Buffa, D., Risso, F., Stirano, F., Varenni, G.: Network Virtual Machine (NetVM): A New Architecture for Efficient and Portable Network Applications. In: 8th IEEE International Conference on Telecommunications (ConTEL 2005), Zagreb, Croatia (June 2005) [5] Morris, R., Kohler, E., Jannotti, J., Kaashoek, M.F.: The Click modular router. In: Proceedings of the 1999 Symposium on Operating Systems Principles (1999)

Architecture for an Active Network Infrastructure Grid – The iSEGrid T.K.S. LakshmiPriya and Ranjani Parthasarathi Department of Computer Science and Engineering, College of Engineering, Guindy, Anna University, Chennai, India [email protected], [email protected]

Abstract. Although the net processing power in the network is increasing steadily, it is heterogeneous. Hence the immense compute-power may be underutilized at certain points while it remains inadequate at others. This paper proposes an active network-based framework that views the entire network as a single-entity to effectively utilize the network resources. The single-entity model is enabled by establishing an infrastructure grid at the network layer. Such a grid has the advantage of supporting a wide range of application-layer services in the network. Network processors and Active Network technology work in tandem to facilitate this. The network processors with their deeppacket-processing capabilities allow offloading of application-level processing into the network. Active Network technology allows this to take place ondemand. We present the design and architecture of the infrastructure grid, called iSEGrid, and illustrate its use for streaming services. We provide experimental results to indicate the potential and scope of the concept. Keywords: Network Layer Grid, Network Infrastructure Grid, Active Networking, Network Processors, and Grid Architecture.

1 Introduction and Motivation Active Networks (AN) technology has been proposed to support dynamic deployment of services in the network. This involves execution of code carried along with the data packets, at the intermediate nodes of the network. Researchers have extensively studied the potential benefits of this approach to various performance issues in the network [1,2,3]. Application specific tasks such as providing QoS, security, policy management, network resource management, translation, etc., have been shown to benefit from this approach. However, a significant challenge to this technology is the requirement for programmable network elements; especially in a scenario where the routers and switches in the network are built using ASICs and custom-hardware. Custom hardware is used to provide higher performance, however, it lacks the flexibility required for active networks. In this context, the advent of Network Processors (NPs) which provide programmability without compromising on performance, serves as a boost to the AN technology. The benefits of this marriage of NPs and AN have just begun to be explored [4]. D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 38–52, 2009. © IFIP International Federation for Information Processing 2009

Architecture for an Active Network Infrastructure Grid – The iSEGrid

39

The entire spectrum of services from basic packet processing operations (such as classification and routing) to QoS specific operations (such as scheduling and queue management) [5], to application-specific processing in the network (such as deeppacket inspection, filtering, and caching) can be supported actively using NPs. NPs with their multi-core, multi-threaded architecture targeted at network processing functions have the potential to efficiently perform these operations and much more, at wire-speed. Recently, even application layer functions have been ported onto the NPs [19]. NPs can be positioned at the network-core, at the network-edge or as an attached processor at the end systems - both client and server. The functionality at these points may vary in complexity due to the heterogeneity of the end systems, and the traffic in the network. Thus with NPs pervading the network, the processing power in the network is bound to increase manifold. However, it may not be uniformly distributed. The processing power may be underutilized at certain points, but inadequate at certain others. We propose that this imbalance be exploited by viewing the entire network of intermediate elements as a single, coordinated entity. To this end, we propose a grid-framework that pools the in-network resources, and makes the network services available as a commodity. In this framework we propose the use of AN technology for dynamic deployment of network services on the NPs to suit the varying demands of applications. It is to be noted that this proposed grid framework operates at the network layer as opposed to conventional grids (computational grids, data grids, etc), which focus on the application layer [20]. Even the Active Grid framework of the RESO project [13,14], which is aimed at providing network services for the conventional grids using AN technology, focuses on the higher layers. Thus, our proposed grid framework is different from existing grids in that it is an infrastructure-level grid of active NPs. The grid features that we exploit are: use of idle resources, large-scale sharing of heterogeneous resources spanning across different administrative domains, and a single-system view of the network. The different network devices play the role of service providers, resource brokers and coordinators depending on their processing capability and resource availability. The single-system view emphasizes end-to-end performance as opposed to localized solutions in conventional networks, and benefits both high-end and low-end clients of the network. Thus, the significant benefits that we foresee are handling of high-bandwidth applications with reduced burden on the end-systems, and offering of customized value-added services in the network, to lowend clients like handheld devices, in a transparent manner. The proposed grid operations are facilitated by the use of NPs and AN technology. The NPs with their deep-packet-processing capabilities enable application-aware processing and allow offloading of application-level services into the network. AN technology allows this to take place on-demand. The primary goal of the AN technology is to decouple the network services from the networking element thereby enabling on-demand code deployment. The re-programmable nature of the NPs qualifies them to be Active Nodes. Thus NPs and AN technology together, enable on-demand deployment of application-aware services in the network. This paper presents the conception of this infrastructure grid, describes the proposed architecture in detail, and illustrates its use for a specific application. It examines the suitability of NPs and AN technology and provides a proof-of-concept implementation of select key components. The organization is as follows. Section II

40

T.K.S. LakshmiPriya and R. Parthasarathi

presents the design of the proposed grid, its architectural components and the mode of operation. In Section III various scenarios of the iSEGrid are illustrated for multimedia traffic. This is followed by the evaluation of the iSEGrid in Section IV. Section V presents comparison with related work and Section VI concludes the paper with a briefing on work-in-progress.

2 Design of the iSEGrid – A Network Infrastructure Grid The proposed infrastructure grid consists of network entities, which are in-networkservice-aware entities (iSEs). Hence this grid is named ‘iSEGrid’. The purpose of this network infrastructure grid is to harness the tremendous network-processing power, and offer it as a commodity to the grid users - the end-systems. Here, the term ‘endsystems’ includes the server applications (iSE_user_SAs) and the client applications (iSE_user_CAs). The servers associated with the Internet service providers, media service providers, mail-service providers and content providers, along with their clients are the iSE_user_SAs. The iSE_user_CAs that benefit from the services of the iSEGrid may run on PCs, laptops, mobile phones or any other computational gadget. The grid environment is depicted in Figure 1.

iSEGrid Resource Brokers (iSE_RBs)

iSE_User_CA iSE_User_SA

iSE_Dir

iSEGrid Service Provider (iSEs)

iSE_ACR

iSEGrid Portal

Fig. 1. iSEGrid Environment and components

The iSEGrid spans across the entire Internet, edge-to-edge, consisting of all sorts of edge nodes as well as core nodes, as its grid-resources – the iSEs. These resources posses diverse characteristics in terms of processing power, memory, data rate, type of protocol handled, QoS characteristics, data medium, type of interface, etc. In addition, being part of different administrative domains, these resources, follow different policies and practices. The requirement for an in-network node to be an iSE is the availability of ‘excess’ resources that it can volunteer to the grid and the ability to be an Active Node. Resources that may be volunteered are computational threads, CPU time, memory or buffers, and ability to handle an additional flow of packets. The providers of the network infrastructure, who volunteer their resources to the iSEGrid, constitute the iSEGrid service providers.


41

The iSEGrid coordinates its heterogeneous, distributed resources, to solve a common problem – the end-to-end performance. It employs resource brokers (iSE_RBs) which are powerful intermediate nodes, for typical resource brokering operations such as managing idle resources, delegating tasks to the iSEs, aggregating services from individual iSEs, enforcing policies, resource accounting and charging, and triggering the grid activities. With the help of a rule-base, the iSE_RBs make intelligent decisions on the aggregate information collected from other iSEs. The iSE_RBs may also handle issues relating to fault tolerance, reliability and availability (esp., transient nodes) of the iSEGrid. They may cooperate with each other or form a hierarchical resource broker structure if necessary, to provide a service. In this paper, however, these extensions are not dealt with. The iSE_RBs and the iSEs must possess the necessary code modules while offering the iSEGrid services. These modules are developed as active software components and are stored in the iSE Active-Code Repositories (iSE_ACR). In addition to the storage available at the iSE Portal, nodes like storage servers may volunteer storage to this repository. The active components are deployed at the iSEGrid nodes either during registration or on-demand. From the kind of the operations performed at the various iSEGrid nodes, it is obvious that these nodes maintain a variety of information for normal operation. The data structures that maintain these data and metadata are collectively maintained as ‘directories’ (iSE-Dirs), located at various strategic points for use by the grid nodes. The entry point into the iSEGrid is a publicly accessible portal, which advertises the iSEGrid services. The in-network node owners can register their nodes as iSEs via this portal while the server apps and the client apps can register themselves as iSE_user_SA and iSE_user_CA respectively. This portal maintains the static part of the iSE_Dirs while the rest is maintained at the iSEs that volunteer storage resources to the iSEGrid. Thus the iSEGrid is seen to consist of four major functional components: iSEGrid Portal, iSEGrid Resource Brokers (iSE_RBs), iSEGrid service providers (iSEs), iSEGrid Active Code Repositories (iSE_ACR) and the iSEGrid Directories (iSE_Dir) as shown in Figure 1. 2.1 iSEGrid Service Architecture The iSEGrid service architecture is a four-layered one, which replaces the network layer in a typical layered network architecture. For instance, in the TCP/IP model, this grid can be viewed as an extended IP layer, sitting below the TCP layer and above the MAC layer. The four layers of the proposed architecture are Basic Networkprocessing (BNp) layer, Local Decision-making (LDm) layer, Aggregate Decisionmaking (ADm) layer and iSEGrid services layer as shown in Figure 2. Of the four layers, the lower two layers, namely the BNp and the LDm layers perform the normal network processing or IP functions. The other layers namely, the ADm and the iSEGrid services layers, are the grid extensions to the IP layer. The BNp layer includes services like packet processing, classification, header processing, flow identification, etc., that are performed at the individual in-network entities.

42


Above the BNp layer is the LDm layer. The services of this layer include the local policy and decision-making services. By ‘local’ services, we mean the consolidation of the BNp services that are performed at an individual iSE without the global view or interaction with other iSEs. The LDm services may be general purpose or may be specific to the applications. This layer exposes the network resources to the iSEGrid. For this purpose, in addition to the LDm services, it includes the communication and authentication protocols associated with the resources. The services of this layer include the policies for analysis of packets, the decision-making rules for operating on particular type of flow, the access-control policies and authentication mechanism for each iSE. The LDm services of the iSEs are aggregated by the coordination of the iSEs. These collective operations constitute the ADm layer and are performed by iSEs that coordinate the network processing services of individual iSEs, namely the iSE_RBs. This layer exhibits intelligence in the network. The aggregated services of the ADm layer are customized and offered as ‘iSEGrid Services’ to the iSEGrid consumers as per their requirements. These services form the iSEGrid Services Layer. It is via this layer that the iSEGrid communicates its services to its consumers. The iSEGrid architecture is hourglass shaped with the LDm layer at the neck of the hourglass. It is preferred to keep the LDm layer thin due to the development of a diverse range of in-the-net nodes, so that the set of core LDm services is small and a broad range of services at the ADm layer can be implemented on top of these. Services at each layer or across layers are developed as active code components and are made available at the iSE_ACRs. The granularity of the code varies with the requirement.

Transport layer and above

iSE Grid

iSEGrid Services Layer Aggregate Decision-making (Adm) Layer Local Decisionmaking (LDm) Layer Basic Network-processing (BNp) Layer MAC and Physical Layers Fig. 2. iSEGrid Service Architecture

2.2 iSEGrid Operations The iSEGrid operations can be explained under two phases namely the iSEGrid setup phase, which involves registration and module deployment, and the iSEGrid-inservice phase, in which the iSEGrid services are offered. The interactions between the iSEGrid nodes and consumers during these phases are depicted in Figure 3.


43

Phase 1 - iSEGrid Setup phase The iSEGrid is set up as the grid nodes (i.e., iSEs, iSE_RBs, iSE_CRs and iSE_Dirs), and the grid consumers, register (Figure 3). Network providers, the owners of a large variety of in-network entities including base stations, access points and CDNs, approach the iSE Portal to register their nodes as iSE grid nodes. Information regarding the configuration, capability, and constraints of these nodes are conveyed to the iSEGrid. Negotiations regarding security, accounting, type and service parameters are carried out. As each iSEGrid node is registered, the active code modules required for the services sought, are deployed at the respective nodes. The iSE_Dir is updated and initialization procedures are executed at the new iSEGrid node. At the time of registration of an iSE_RB, each new iSE_RB is associated with a set of iSE_user_SA. Similarly, when a new iSE_user_SA registers, the corresponding startup iSE modules are deployed and a specific iSE_RB is associated with it. The iSE_RB becomes its first point of contact to the iSEGrid. All further communications from the iSE_user_SA to the iSEGrid will take place via this iSE_RB. Initially, the known client groups of the SA are made the iSE_user_CAs. However, iSEGrid also permits adding client groups dynamically. This can be done in two ways. The iSE_RBs may automatically detect these clients by monitoring traffic at the server-edge, or receive intimation from the server on the arrival of requests from the clients. Figure 3 indicates registrations occurring in a particular order, but in practice, this varies. Participation in the iSEGrid is transient. By this we mean that grid nodes and consumers are permitted to register and deregister alternately. However, a node may deregister only after completing or migrating, the committed services.

iSE_RBs

iSE_User-SA

iSE_RBs

iSE_CR

iSEGrid Portal

iSE_User-CA

iSEs

iSE_Dir

iSE Registration iSE RB Registration iSE_User-CA Registration

Setup Phase

iSE_User-SA Registration Media Request Triggering the iSEGrid service Initiate the iSEs

Offering the services

Active Deployment

Fig. 3. iSEGrid – 2-phase Operation

In-service Phase

44


Phase 2 - iSEGrid-in-service phase Soon after registration, the iSEGrid nodes enter the iSEGrid in-service phase. Step 2 is a typical client/server request. The arrival of the client request at the server triggers the iSEGrid service. This can be done in two ways: explicitly or implicitly. Explicit triggering occurs when the iSE_user_SA requests the iSE_RB for an iSEGrid service. On the other hand, implicit triggering occurs when the iSE_RB intercepts (i.e., deep packet processing) the flow at the server-edge and detects the need for an iSEGrid service. ‘Triggering’ an iSEGrid service, involves identifying and initiating the iSE(s). Identifying the right iSE(s) necessary to service the request involves intelligent decisions. Typical rules for this purpose may be based on, proximity to the client group; iSEGrid services offered by the iSE; ability to provide the service at that point of time; or expected response time. The identification of iSEs may be performed by iSE_RBs in isolation or in coordination with others. The iSEs are identified and initiated. The parameters for the service including the location of the iSE_ACR s are then sent to these iSEs (Step 4). The iSEs begin offering the services (Step 5) after the ‘on-demand’ deployment of the iSE code modules from the iSE_CR. Once triggered, the iSE_RBs periodically probe the iSEs and maintain the services. When a service terminates, wind-up operations are done at the iSEs and the iSE_Dirs are updated to reflect this change. 2.3 iSEGrid – Modes of Usage It can be seen from the above description that global view and coordinated functions are two key characteristics of the iSEGrid. We now present different modes of usage of the iSEGrid that exploits these two characteristics. 1. Integration of services A straightforward application of the iSEGrid, would be to integrate the currently available localized mechanisms, from a global perspective. 2. Code and service movement Since the grid allows dynamic deployment of services and code movement, any of the existing network services can be moved to the appropriate location (sometimes even to multiple locations) to provide efficient service. That is, services provided at the network edge may be moved into the network or those at the end systems may be moved to the edge and vice-versa. Thus the network resources can be effectively utilized and the burden on the end systems can be reduced. This has an added advantage that services that were hitherto available only to the powerful end-systems can now be provided to less powerful end systems like the hand-held devices too. 3. Novel in-network service In order to tap the full potential of the iSEGrid, novel solutions that exploit the innetwork capabilities can be identified. One such solution is in terms of setting up a chain of services at the intermediate iSEs, along the path. These services may be aggregated or used in isolation. Even though this requires a paradigm change in the networking domain, it can be seamlessly integrated using the various features of the iSEGrid. The next section illustrates each of these modes of usage as applied to multimedia services.


45

3 iSEGrid for Multimedia Services – An illustration Multimedia traffic requires special attention especially because of the differences in its characteristics from those of other traffic in a network. Researchers have been working on various issues to improve the performance of multimedia applications by making the underlying network services, streaming-aware [6-10]. One of the major issues is timely arrival of media packets at the client node. Mechanisms like prefetching and caching; media-specific packet scheduling, network congestion avoidance using multipath-transmission, rate adaptation, and minimizing end-to-end retransmission have been proposed to reduce the latency of the packets. Yet another issue, namely high bandwidth requirement, is being handled by mechanisms like transcoding and multiple source streaming. Each of these mechanisms operates at various points along the transport path i.e., some at the end systems, some at the network edge, and some at the core. Typically they provide solutions based on a localized view of the problem. Hence they do not guarantee an end-to-end solution, which adapts to varying network conditions. It is in this situation that the iSEGrid provides an alternative. Any of the three modes of usage mentioned in the previous section could be applied. We take a few instances to illustrate each of these modes. 1. Integration of Services We consider a full-fledged application, namely, flash crowd control in a p2p network, serviced by media servers. Flash crowds occur when an unexpected number of requests hit the server within a very short duration of time. One solution to this is the maintenance of a coordinated cache at the client end, which serves the clients locally during flash crowds [11]. Here, one or more of the clients performs the coordination. The physically distributed cache, which is the key component of this service, is made up of portions of memory volunteered by each client in the peer group. An iSEGrid-based approach to this solution employs a server-side iSE_RB (SS_RB) and a client-side iSE_RB (CS_RB). The SS_RB monitors the load on the server and communicates peak-load conditions to the CS_RB. The CS_RB along with the peers in the network performs the pre-flash-crowd operations, i.e., caching the recently viewed clips at the clients and transparently maintaining their indices at the CS_RB. On the occurrence of flash crowd conditions at the media server, the SS_RB sends an intimation to the CS_RB. This intimation provides timely detection of flash crowds. The CS_RB immediately redirects further media requests to the locally existing objects, ensuring continuous delivery. Since the iSE_RB takes up most of the maintenance tasks, the load on the client is reduced. The iSEGrid-specific messages either have no payload or are light in weight and can be piggybacked. Thus, this application illustrates the unification of the load-monitoring service, which is typically performed at the server, and the coordinated cache service implemented at the client end for undisturbed service. 2. Code and Service Movement We consider three different mechanisms that can be enhanced by code/service movement – feedback-based rate adaptation, QoS mechanisms for wireless network and transcoding.

46


Feedback-based rate adaptation at the server: Feedback is normally obtained from the end system or the network edge. In the iSEGrid, this feedback generation can be moved to the iSEs in the network and an aggregated feedback can be obtained at the server. The advantage gained is that information about the entire path is available at the server for rate adaptation and adverse conditions along the path are detected earlier. Similarly, QoS mechanisms are normally deployed at the core of the network, for both wired and wireless networks. However, for a wireless network, it will be useful to move this service to the edge where the wired meet the wireless. The nodes at the junction of wired and wireless networks, which experience the varying characteristics of two different networks, are ideal iSEs, to impose QOS. These iSEs can perform QoS-specific scheduling, classification and queue management on the flows and adaptively cater to the changes in the wireless applications. The dynamic deployment feature of the iSEGrid can be used to enable the on-demand loading of the desired algorithm [5]. An iSE_RB can be used to detect the change in flow and initiate code transfer from the code repository. Transcoding is normally employed at the edges – either server or client edge – to adapt to the client requirements in terms of bandwidth and resolution. In the iSEGrid environment, this service can be moved to any position in the path – server edge or client edge or any volunteering intermediate iSE – to dynamically accommodate variation in service and demand. Prefetching and caching services can also be offered in a similar manner. Here again, an iSE_RB will be used to coordinate this adaptive service movement. 3. Novel in-Network Solution The in-network feedback generation described above is an example of an in-network chain of services. Similarly, a chain of link-cache can be maintained at the iSEs to cache high priority media packets at each link until the subsequent iSE (link) acknowledges. This provides early detection of link-level packet loss thereby avoiding end-to-end packet retransmission [12].

4 Evaluation of iSEGrid To evaluate the proposed iSEGrid, we consider two aspects – the underlying technology, and the performance benefits to an application that uses the iSEGrid. Since the idea of the grid is motivated by the use of AN and NP technologies, it is important to study the feasibility of using the NP as an iSE and as an Active node. The evaluation is based on the scenarios described in the previous section. 1. Using NP as an iSE_RB The iSE_RB functionality, illustrated in the previous section that coordinates transcoding, prefetching and caching has been developed on an Intel IXP1200 NP [17]. This iSE_RB is assumed to be located on a Base Station Controller (BSE) at the wired-wireless junction. This iSE_RB is responsible for detecting, scheduling and allocating volunteer iSEs for offering streaming service to mobile clients. This involves a sequence of events E1 to E6 as follows. The volunteers first register with the iSEGrid (E1). The media requests from the mibile are intercepted by the iSE_RB (E2). The iSE_RB then probes the volunteers for their availability (E3). On receiving a


47

response (E4), it allocates the volunteer for the service (E5) and intimates the client (E6). The volunteer iSE then begins prefetching, caching and transcoding before streaming the object to the mobile client. The ability of the IXP1200 NP-bases iSE_RB to handle these requests has been analyzed under two different scenarios: (1) a volunteering iSE is available till the end of the service (Figure 4a) and (2) the iSE leaves the system before completing the service (which requires reallocation) (Figure 4b). It is assumed that all packets arrive on 100Mbps lines with an inter packet gap of 960 nanoseconds. The µ-engines of the NP operate at 232 MHz. Figure 4 shows the time line diagram of the events that occur for scenario 1 and 2. The clock cycles at which the events occur are given. Servicing a request for an existing video

Servicing a new video request

19100,19950,20890,21585,22430 6818 7398

E1 E2

11070 12924

E3

5,000

10,000

E2 E3 E4 E5 E6

17579 18403

E4

E5 E6

20,000

15,000 Microengine cycles

25,000

(a) Scenario 1

Servicing a new video request 6818 7398

11070 12924

E1 E2

E3

5,000

10,000

Reallocation

17579 18403 19356

E5 E6 E4 (Quits)

E4

15,000 Microengine cycles

23793 24523

E5 E6

20,000

25,000

(b) Scenario 2 EVENTS a) iSEGrid setup phase : E1 - volunteering iSE registers b) iSEGrid-in-service phase : E2 to E6 (Explicit triggering) E2 - streaming request packet arrives from a mobile E3 - iSE_RB sends probe packet to the iSE E4 – iSE sends response to the iSE_RB E5 - iSE_RB sends start-service packet to the iSE E6 - iSE RB sends service-intimation packet to mobile

Fig. 4. Time line showing the events during the services of two requests

48


Scenario 1: Initially, the volunteer iSE registers (E1 at 6818). The sequence of events (E2 at 7398 to E6 at 18403), occur during the service of a video object for the first time (i.e., a new video). This is followed by another request for the same video (E2 at 19100 to E6 at 22430). The iSE_RB requires 11,005 µ-engine cycles (47.4 µ sec) for the first request, while for a subsequent request to the same object; it is only 3,330 µengine cycles (14.3 µ sec). Scenario 2: Registration and service to a new video request (i.e., E1 to E6) are the same as in previous scenario. When the iSE leaves the system, it intimates the iSE_RB (E4 at 19356) of its unavailability. The interval between the points (6,18403) and (4,19356) indicates the partial streaming interval. Since the iSE’s service has not been completed, the iSE_RB does a reallocation (i.e., 19356 onwards) and sends the serviceintimation (E6 at 24523) to the new iSE. The reallocation latency is 5167 µ-engine cycles (22.7µsec), for this scenario. The overall latency involved when a volunteer leaves, is found to be 16172 µ-engine cycles (70.1µsec). The overheads of using an NP as an iSE_RB are viewed in terms of the resources (i.e., microengines of the NP) required and in terms of the message exchanges specific to iSEGrid operation. The iSE_RB design utilizes all the six microengines of the IXP1200. Hence it is recommended to use the IXP1200 as an attached processor on the BSC or choose a higher version NP that can house both the functionality of the BSC as well as that of the iSE_RB. The iSEGrid specific message exchanges have been listed above as ‘events’. Most of these messages either do not have a payload and hence may be piggybacked or are light in weight. The probe and start-service messages have no payload. The probe-response message contains the parameters, like channel-quality, between the iSE and the mobile, and hence requires a few tens of bytes as payload. This experiment evaluates the effectiveness of NPs as RBs on the iSEGrid and shows the reduction in service. 2. Using NP as an Active iSE The adaptive QoS service applied at the edge of wireless network as illustrated in the previous section has been developed on an NP-based WLAN Access Point (AP) [5]. This receives active packets (in the ANEP format) and dynamically loads the embedded QoS function. Active modules for various classification, queue management and scheduling algorithms have been developed on the active framework for IXP1200 based NPs. An active code handler module has been developed specifically to handle the active code and load it onto the microengines. The system has been tested with various active code modules. The NP-based active test-bed was found to receive the active packets, stop the currently running algorithm and load the new one appropriately. Normally, the switching time is a major overhead of dynamic loading operations. However, the iSE_RB at the WLAN AP has been designed with two sets of queues, one for the currently running algorithm and another for the incoming algorithm to-be-loaded. Here, the feasibility of an active NP-based iSEGrid component has been established. 3. An application on the iSEGrid The flash crowd control application, as illustrated in the previous section, has been tested in an iSEGrid environment consisting of a CS_RB, an SS_RB and a P2P group of 12 clients sharing 20 media files. The effectiveness of the service is shown in the graph in Figure 5.


49

The percentage of requests that were not serviced by the server during a flash crowd, are plotted for five different bandwidth reservations at the server (data series 1). These server-rejected requests are handled by the CS_RB. The percentage of the total requests serviced by the CS_RB is indicated by the second data series in the graph. The difference between the first and the second data series indicate the usefulness of this service. The usefulness is calculated as Effective Service Percentage (ESP) of the CS_RB. No. of requests serviced by CS_RB ESP = ------------------------------------------------ x 100 No. of requests rejected by the server

90 80

70

70

% of the Total 60 no. of Messages 50 communicated 40

30 20 10 0

81

74

65

83

55 40 28

35 36

23

26 19

2 11 3 5 7 9 ServerBandwidth (no. of connections)

Percentage of total requests NOT serviced by server Percentage of total requests serviced by CS_RB Effective Service Percentage (ESP)

Fig. 5. Flash Crowd Control service of the CS_RB component

The ESP is the percentage of the server-rejected requests that are serviced by the CS_RB. The third data series gives the ESP. It can be seen that the ESP value is high when a large bandwidth is reserved at the server, and is lower otherwise. The ESP is the parameter that determines the usefulness of the CS_RB, for a given bandwidth reservation at the server. We find that the CS_RB is more useful when the bandwidth reservation at the server, is low. About 67 requests out of the rejected 167 (i.e., 40%) have been serviced by the CS_RB with a reservation of three connections. During such situations the CS_RB experiences maximum load. The CS_RB for this service has been developed on an Intel IXP1200 NP to test its performance under various scenarios and varying flash crowd durations. The design of this service requires only two microengines, indicating that any NP-based edge device that can volunteer two microengines and 12 x ‘n’ Bytes of SRAM for table lookup can play the role of such a CS_RB with a client group size of ‘n’ peers.

50


The above evaluation also showcases two out of three modes of use of the iSEGrid – integration of services and code and service movement. The third aspect in-network novel service – has also been demonstrated, but the results have been presented elsewhere [12].

5 Comparison with Related Work The goal of the infrastructure grid, proposed in this paper is to pool the network resources and to exploit the imbalance in their processing power to bring about better end-to-end performance and for enabling value addition for the applications. To do this effectively, the iSEGrid employs the positive aspects of NP and AN technologies. The idea of combining active networking with powerful network resources is not entirely new and is very close to the idea of active grids proposed by the RESO project [13, 14]. Active grids focus on offering intelligent adaptive transport services to support computational grids (grid environments and apps). While the RESO project is concentrating on developing application-aware components (AACs) for deployment at the edge nodes of the core network, the functionality of which is specifically for computational grids and their applications; iSEGrid concentrates on implementing the application-level services at the network layer thereby offering a common base for a wide range of technologies operating at the higher layer – computational grids, peer-to-peer networks, overlays, internet, and web services. It can be viewed as complementing the Active Grid by providing support at the network layer. Another architecture that is similar to the iSEGrid is the Open Pluggable Edge Services (OPES) architecture [15,16], which brings application awareness into the network. However, OPES is an overlay of application-level network intermediaries while iSEGrid is an overlay of all network intermediaries. Hence the iSEGrid has a wider scope for in network functionalities. It is a complementary technology in the sense that it can also be used to support OPES. In terms of the underlying concepts of resource sharing and coordination, the P2P computing paradigm and conventional grids are similar to the iSEGrid. However, while P2P networks operate at the end systems, iSEGrid spans across the network. In that sense the P2P concept is embedded in the iSEGrid. Similarly, conventional grids treat the entire network, as an individual resource, whereas iSEGrid goes deeper and focuses on the network components themselves. Thus the iSEGrid presents another dimension in the grid space.

6 Conclusion and Future Work This paper has introduced the iSEGrid-framework that pools the in-network resources of NPs, and makes the network services available as a commodity. This infrastructure grid allows dynamic deployment of application-aware network services using ANs to suit the varying demands of applications. In essence, it has been shown that the synergy of three different technologies namely grid technology, ANs and NPs, can be exploited cleverly to expend the capabilities of today’s networks for the future. The


51

layered architecture and the design of the proposed iSEGrid have been presented. A few multimedia-specific scenarios have been illustrated to bring out the usage of the iSEGrid. Even though the use of the iSEGrid has been showcased for multimedia applications, it is to be noted that all the above services benefit non-streaming applications as well. Further challenge lies in exploring more issues to be solved by this paradigm. The evaluation of the iSEGrid in terms of the underlying technology, and in terms of different usages of the iSEGrid, has been presented. To conclude, the iSEGrid has exposed a whole new paradigm for enabling networking services and solutions. Our architecture implies that an intelligent, efficient underlying grid is available to the application developers. The challenge now is in finding issues that can be solved better using this paradigm, and in exploring services that can be provided ‘in the network’. We have initiated activity in this direction for both wired and wireless media streaming applications. We also plan to explore support for text processing applications. Work in progress includes the development of a network level simulator for the proposed grid. Further analysis is required in terms of security issues at the iSEGrid components, storage issues at the resource brokers, and the development of effective protocols for communication between the iSEGrid components with reduced overloads.

Acknowledgement We thank M.Nithish, C.Ramakrishnan, J.Ramkumar, R.Sharmila, and V.Krishnan, for their contribution in the implementation of the iSEGrid modules.

References 1. Decasper, D., Plattner, B.: DAN: distributed code caching for active networks. In: IEEE INFOCOM 1998, Proceedings of the Seventeenth Annual Joint Conference of the IEEE Computer and Communications Societies, vol. 2, pp. 609–616 (March/April 1998) 2. La Cholter, W., Narasimhan, P., Sterne, D., Balupari, R., Djahandari, K., Mani, A., Murphy, S.: IBAN: intrusion blocker based on active networks. In: Proceedings of the DARPA Active Networks Conference and Exposition, DANCE 2002, pp. 182–192 (2002) 3. Subramaniam, S., Komp, E., Kannan, M., Minden, G.J.: Building a reliable multicast service based on composite protocols for active networks. In: Minden, G.J., Calvert, K.L., Solarski, M., Yamamoto, M. (eds.) Active Networks. LNCS, vol. 3912, pp. 101–113. Springer, Heidelberg (2007) 4. Kind, A., Pletka, R., Waldvogel, M.: The Role of Network Processors in Active Networks. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982, pp. 18–29. Springer, Heidelberg (2004) 5. Sharmila, R., LakshmiPriya, M.V., Parthasarathi, R.: An active framework for a WLAN access point using intel’s IXP1200 network processor. In: Bougé, L., Prasanna, V.K. (eds.) HiPC 2004. LNCS, vol. 3296, pp. 71–80. Springer, Heidelberg (2004) 6. Hefeeda, M.M., Bhargava, B.K., Yau, D.K.Y.: A hybrid architecture for cost-effective ondemand media streaming”, Computer Networks. The International Journal of Computer and Telecommunications Networking archive 44(3), 353–382 (2004)

52


7. Keller, R., Sumi Choi Dasen, M., Decasper, D., Fankhauser, G., Plattner, B.: An active router architecture for multicast video distribution. In: Proceedings of the Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies, INFOCOM 2000, vol. 3, pp. 1137–1146 (2000) 8. Nguyen, T.P.Q., Zakhor, A.: Distributed Video Streaming Over Internet. In: Multimedia Computing and Networking 2002, Proceedings of SPIE, San Jose, California, vol. 4673, pp. 186–195 (January 2002) 9. Chen, X., Heidemann, J.: Flash Crowd Mitigation via Adaptive Admission Control based on Application-level Observations, Technical Report, ISI-TR-2002-557 (May 2002) (updated on March 25th, 2003) 10. Korkmaz, T., Krunz, M.M.: Routing Multimedia Traffic With QoS Guarantees. IEEE Transactions On Multimedia 5(3) (September 2003) 11. Stavrou, A., Rubenstein, D., Sahu, S.: A Lightweight, Robust Peer-To-Peer System to Handle Flash Crowds. In: 10th IEEE International Conference on Network Protocols (ICNP 2002), ACM SIGCOMM Computer Communication, vol. 32(3), p. 17 (2002) 12. Nithish, M., Ramakrishna, C., Ramkumar, J., LakshmiPriya, T.K.S.: Design And Evaluation Of Intermediate Retransmission And Packet Loss Detection Schemes For MPEG 4 Transmission. In: Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC 2004), vol. 1, p. 742 (2004) 13. RESO Project, http://www.inria.fr/recherche/equipes_ur/reso.en.html 14. Bouhafs, F., Gaidioz, B., Gelas, J.P., Lefevre, L., Maimour, M., Pham, C., Primet, P., Tourancheau, B.: Designing and Evaluating An Active Grid Architecture. The International Journal of Future Generation Computer Systems (FGCS), Special issue: Advanced grid technologies 21(2), 315–330 (2005) 15. IETF OPES, http://ietf-opes.org/ 16. Nurmela, T.: Analysis of Open Pluggable Edge Services. In: Seminar On Hot Topics In Internet Protocols (2004) 17. Intel IXP1200 Network Processor, http://www.intel.com/design/network/ products/npfamily/ 18. Krishnan, V.: InGRA-Intelligent Grid resource allocation for Mobile Clients, Project Report, Dept. of CSE, CEG, Anna University, Chennai, India (May 2005) 19. Hvamstad, O., Griwodz, C., Halvorsen, P.: Offloading Multimedia Proxies using Network Processors. In: International Network Conference 2005 (2005) 20. Foster, I., Kesselman, C., Tuecke, S.: The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of Supercomputer Applications and High Performance Computing 15(3) (2001)

Network Services on Service Extensible Routers Lukas Ruf, Károly Farkas, Hanspeter Hug, and Bernhard Plattner Computer Engineering and Networks Laboratory (TIK) Swiss Federal Institute of Technology (ETH) Zurich CH-8092 Zurich/Switzerland {ruf,farkas,hhug,plattner}@tik.ee.ethz.ch

Abstract. Service creation on extensible routers requires a concise specification of component-based network services to be deployed and extended at node runtime. The specification method needs to cover the data-flow oriented nature of network services with service-internal control relations. Hence, it needs to provide the concept of functional service composition that hides the complexity of a distributed, dynamically code-extensible system. We propose the PromethOS NP service model and its Service Programming Language to answer this challenge. They provide the concepts and methods to specify a network service as a graph of service chains with service components, and service-internal control relations. In this paper, we present the concepts of our service model, the syntax and semantics of its Service Programming Language, and demonstrate their applicability by an exemplary service specification.

1 Introduction and Motivation One of the most significant problems of the Internet today is the lack of non-disruptive service creation and extension on demand on access and border routers. Non-disruptive service creation and extension have become key requirements due to the following trends: – Function shift from the end-systems to the access networks: Function is moved from the end-systems towards the network to ease site operation, and to benefit from the economy of scale user-centric network services are deployed on access routers for the three plains [3] of data-path, control and management functionality. Examples are the protection of network sites [15] and the alleviation of network management and control [1]. – Router consolidation: For a reduction of costs of network management and operation, routers are consolidated. Larger devices, hence, are needed to satisfy the demands for the interconnection of different networks. Equipped with programmable network interfaces, these network nodes1 provide suitable locations for new extended network services.

1

This work is partially sponsored by the Swiss Federal Institute of Technology (ETH) Zurich, the Swiss Federal Office for Education and Science (BBW Grant 99.0533), and the Intel IXA University Program (Research Grant 22919). PromethOS v1 has been developed by ETH as a partner in IST Project FAIN (IST-1999-10561). We refer interchangeably to a router device by the term network node.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 53–64, 2009. c IFIP International Federation for Information Processing 2009

54

L. Ruf et al.

– Enabling Technologies: Network Processors [7, 8] (NPs) appeared recently on the market. They provide generally an asymmetric programmable chip-multiprocessor architecture with functional units optimized for specific network operations. Usually, they are built of two different processor types, namely packet and control processors2 (PPs and CPs respectively), that reside in a conceptual view at two different levels. CPs are built commonly of a general purpose processor (GPP) while PPs provide the architecture of a stripped down RISC processor supported by specialized co-processors to process packets at line-speed. Network interface cards with embedded NPs (so-called NP-blades) provide, thus, the required flexibility to extend large network nodes easily and increase the processing capacity of a network node simultaneously. Router devices with NP-blades and multiple GPPs provide a powerful hardware platform. Service management and node operation, however, is complicated by the nature of these large heterogeneous network nodes. PromethOS NP [13, 14] provides the flexible router platform that enables non-disruptive service creation and extension on any programmable processor at node run-time according to an extended plugin [5] model. For the definition of network services, however, a concise specification method is required. This specification method needs to export the capabilities of the underlying service infrastructure while it must abstract from the complexity of large multi-port router devices. Moreover, it must be general enough to cope with the large variety of network nodes. Thus, it needs to describe control and data relations among service components, and needs to specify additions to previously deployed network services with specific resource constraints in a flexible way. Therefore, we present in this paper the PromethOS NP service model and propose its Service Programming Language (SPL) that is used to define and specify network services on the PromethOS NP router platform. The service model provides the concepts to deploy new network services composed of distributed service components on codeextensible routers and to extend previously deployed services with additional functionality. The SPL supplies the service programming interface of the router platform for the installation and basic configuration of new network services. We structure the remainder of this paper as follows. In Sec. 2, we revise related work in the area of service models and specifications. Then, in Sec. 3, we introduce our service model and present our service programming language (SPL) with the definition of the relevant key productions. For proof of concept, we evaluate the SPL by its application on an exemplary service program in Sec. 4. The imaginary service program illustrates part of the capabilities and the flexibility of the SPL. In Sec. 5, this paper is then completed by a summary and conclusion followed by a brief outlook to further fields of application. 2

NP vendors do not use a consistent naming scheme to refer to the code-extensible processors: the Intel IXP-architecture refers to the first-level processors as microengines while the IBM PowerNP identifies them as picoprocessors or core language processors. Second-level processors are named differently as well. For this reason, we refer to the first level of processing engines as packet processors and to those of the second level as control processors.

Network Services on Service Extensible Routers

55

2 Related Work Network service creation on active router platforms and deployment of services within the network have been a research area for quite a while. Research has been carried out on various levels of abstractions. We restrict our review of related work to four different projects in the area of service specification on active network nodes: Click [9] and NetScript [4] due to their service models and specification languages, Chameleon [2] due to its service model and process of service creation, and CORBA [11] because of its component model. 2.1 Click The Click modular router [9] approach defines two environments of code execution (EE) on Linux: one is the in-kernel EE and the other is a Linux user space EE. Both support service creation according to a service specification of interconnected Click elements. Click elements provide the function of network services. Network services are defined by the specification of their inter-connection. Click uses so-called compound elements that allow for user-specified service class definition. A compound element consists of simple elements that specify the functions. The Click specification language is a language that defines the elements and their inter-connection. Sub-classes of elements can be easily extended by own functionality, since new elements can be specified to create new functions in a C++-like style. The functions are then statically linked into the Linux kernel. Both, the in-kernel as well as the user space EE accept a Click service specification, resolve dependencies and create new network services. While Click defines arbitrary service graphs by its specification language, the expressiveness to specify resource limits is not given. Moreover, its capabilities to extend previously deployed network services is not given following the architectural limitations of the Click EEs. 2.2 NetScript NetScript [4] defines a framework for service composition in active networks that is programmed by three domain-specific languages: 1.) the dataflow composition language, 2.) the packet declaration language, and 3.) the rule-based packet classification language. The first defines a method to specify data path services as a composition of interconnected service components called boxes. The second is able to define the packet structure of network protocols, and the third defines the packet classification rules that are installed in the NetScript kernel. Boxes in NetScript provide a container for code or hardware-based service components, or other boxes in a recursive manner. For our vision of service composition on a high-performance router, the first language, the dataflow composition language, is relevant. As a linear XML [16] specification of subsequent and interconnected datapath boxes that may be code or hardware elements, the NetScript dataflow composition language provides an interesting approach to our problem. However, it lacks the abilities to define control relations among control service components controlling other service components as well as for

56

L. Ruf et al.

signalling conditions among subsequent service components. Moreover, the capabilities to extend previously deployed network services is not given, and it does not provide the expressiveness to specify resource and placement constraints of components. 2.3 Chameleon Chameleon [2] is a node level service creation and deployment framework which provides an XML-based service description specifying a network service in an abstract way. The description is based on a recursive service model with containers, so-called abstract service components (ASCs). The ASCs group the functional entities and describe dependencies. In Chameleon, service descriptions define network services as a composition of ASCs. A node local service creation engine (SCE) resolves the service description according to the local capabilities of the node into implementation service components and creates a tree like representation of them. These components are then deployed on the node by the help of a node configurator that provides the required interface towards the SCE to manage and control the platform. Service components in Chameleon are modelled as functional entities supporting two different types of interfaces with push and pull call semantics for control and data path communication. Depending on the underlying NodeOS [10], Chameleon supports the interconnection of different EEs. In its current implementation, Chameleon makes use of a Click Linux kernel EE and a proprietary Java-based EE. Chameleon focuses on the deployment of network services onto different network nodes. Thus, it provides the mechanisms and architecture to cope with a priori unknown network nodes. PromethOS NP, however, defines a specific architecture of a powerful router platform. Hence, for the modelling of network services, we need a service model that meets our needs and provides the capabilities to define the service infrastructure for heterogeneous NP-based network nodes, and, thus, resides at a different level of service modelling. 2.4 CORBA CORBA [11] has defined the Common Object Request Brokerage Architecture to interconnect various, heterogeneous, distributed components by the mechanisms of the object request broker (ORB). The CORBA component model (CCM) [12] defines a component as a meta-type model with the encapsulated respective function. For component description and interface specification the Interface Description Language (IDL) is used. The CCM provides four different component interfaces named facets, receptacles, event sources and sinks. Facets are named interfaces for client interaction, receptacles are connection points, event sources are points that emit events to one or more interested event consumers, and event sinks are the corresponding event targets. By the mechanisms of stubs and skeletons, a client-server architecture for distributed components is specified. The ORB provides the communication among distributed components in a way transparent to the creator of the CORBA service. Due to the level of abstraction, however, CORBA suffers from too much overhead for an efficient router platform.


57

3 Network Services After the review of four specific projects of related work we introduce in this section our service model and then present its Service Programming Language (SPL) that is used to export the concepts of the service model. 3.1 Service Model The goal of our service model is the modelling of a flexible service infrastructure that provides the mechanisms needed for the seamless integration of new service elements. Services are modelled as a graph of edges and vertices with edges representing chains of service components, and vertices defining the interconnection between them. The definition of network services is based on six constituent concepts: data path service components, control service components, service chains, guards, hooks, and name spaces that identify the service on an extensible router.

SCB_in

CCI_in

CCI_out

SCB_out

SCB_in

CCI_in

CCI_out

function

function data_in

data_out

(a) Data Path Service Component

SCB_out

data_in

Ctrl_out

Ctrl_in

data_out

(b) Control Service Component

Fig. 1. PromethOS NP Service Component

In Fig. 1, the models of a control and data path service component are visualized of which we refer to both by the term service component if no specific distinction is required. The service component defines a function according to the plugin model [5], but extends the interfaces provided. In addition to the data in- and output ports, our service component defines Service Control Bus (SCB) in- and output ports, and component control in- and output interfaces (CCIs). By the data in- and output ports, network traffic is received and sent out. The SCB serves for the propagation of service-internal signals between subsequent service components. The semantics of the signals on the SCB are service specific except for three signals (ACCEPT , ABORT , CHAINEND) that causes service infrastructure to accept a packet, abort the current service processing or signal the end of the service chain. The SCB interfaces allow for multiple read but only for a single write operation of the signal. Optionally, a service component exports control inand output ports. CCIs provide the control interfaces to configure and retrieve control information of a service component at run-time. Service components are defined for two different purposes: they provide data path service functionality (cf. Fig. 1(a)) or they provide service internal control functionality (see Fig. 1(b)). Control service components are either separate control components or they are inserted into the service path of data path service components, too. Control service components may be periodically triggered by timed events providing, thus, the

58

L. Ruf et al.

required flexibility of control functionality. They offer the same interfaces but export in addition two controller interfaces (Ctrl in and Ctrl out in Fig. 1(b)) that define a multiplexing semantic to control multiple other service components provided the control service component implements the required functionality. Both types of service components have specific resource requirements and characteristics. Resource requirements specify the amount of resources they need for their instantiation and their processing of network traffic while resource characteristics identify the type of resources needed. For example, different memory types exist on a NP-blade of which a service component consumes a specific amount or, as another example, different instruction set architectures (ISAs) are available on a NP depending on the processor cores implemented. Service chains provide an aggregation of one or more service components that are strongly linked. A chain of strongly linked service components refers to the fact that only signals along the SCB are propagated between service components, and between service components and the service infrastructure. No demultiplexing of network traffic is available between the elements of a service chain allowing for fast pipeline-style processing by subsequent service components. Guards provide the demultiplexing functions that control the acceptance of network traffic to enter service chains. Their definition has been inspired by the concept of guarded commands [6]. In our service model, guards are represented by service components that signal the acceptance or rejection of network traffic by the mechanisms of its SCB output port. Hence, they are the first service components of a service chain. Hooks are key elements of the respective name space. Within a name space, they are identified by their label. They are created in the service program on demand. At creation time, the dispatching semantics are specified. If ingress hooks are created, they must be bound to a network interface. Otherwise, they must refer to previously created ones. Egress hooks may be dangling if required, thus implying the discard of arriving packets. The purpose of dangling outbound links is the provisioning of a hook for later service additions to extend provided functionality. Moreover, hooks serve for the embedding of service chains. They initiate and terminate a service chain. Multiple service chains are attached to hooks. Hooks provide the dispatching of network traffic to service chains since guards steer the demultiplexing of network traffic per service chain. Dispatching semantics have been defined by two different methods to which we refer by the terms copy and first-match-first-consume, respectively. The dispatching semantics are important for the specification of network services since it is a service design decision how network traffic is processed by different service chains. We explain the difference between the two dispatching methods by the help of Fig. 2. In this figure, five service chains, enumerated from 1 to 5, are embedded between two 1 2

hook_in

4

3

5

hook_out

Guards Service Chains

Fig. 2. Hooks, Guards and Service Chains


59

hooks labelled hook in and hook out. The order of service chains is defined by the service program created by the means of our SPL that is presented next. In case of the copy method, the initiating hook dispatches network traffic to all five service chains creating copies of the packets on acceptance by the guards. On the other hand, if the firstmatch-first-consume method has been specified, packets are presented to the guards in the order of service chain specification. Upon acceptance of a packet, the processing at hook in is finished. For both methods, packets are discarded if no guard accepts a packet. Name spaces are abstract constructions of our service model that are used to avoid name collisions between services. Name collisions would occur, for example, if hooks were labelled identically for different services and then reused for extending a previously deployed service with service additions. service name space

Guard CCI_in CCI_out data_in data_out

Fc

G

Ctrl_out Ctrl_in hook3

hook1 F1 hook0

F2 SCB_in

F3 hook2 SCB_out SCB

Fig. 3. Control and Data Path Relations Among Service Components

In Fig. 3, a service graph is presented that consists of four service components named F1, F2, F3 and Fc embedded between four hooks as well as of a guard labelled G that controls the packet acceptance for its service chain. It illustrates the data path and control relations between service components with Fc controlling F2. In Fig. 3, this controlling functionality is indicated by the letter C . Moreover, the figure visualizes the SCB that accompanies service chains. 3.2 The Service Programming Language The SPL specifies a network service for the service infrastructure of the PromethOS NP router platform. It defines the Service Programming Interface (SPI) exported by the router platform for the creation and extension of new network services. EBNF 1 presents the key elements3 of the definition of the PromethOS NP Service Programming Language (SPL). The language definition is based on a modified form of the Extended Backus Naur Form (EBNF) [17] that deviates from Wirth’s definition regarding the repetition-operator of elements denoted by bracelets ({..}). According to [17], the repetition-operator contains zero or more elements. For our purposes, we redefined the repetition-operator to produce one or more elements since 3

Self-explanatory productions like, for example, BW, CYCLES or RAM are not included due to space constraints. Note that we refer to the key = value pair by the term production.

60

L. Ruf et al.

ID TIMED BW RES CPU RES RAM RES PROC TYPE CTRL INFO COMP SPEC

= = = = = = = =

COMP IDENT = SERV COMP = CTRL COMP = CTRL CHAIN = COMP STRING= GUARD = HOOK IN = HOOK OUT = SERV CHAIN =

SERVICE

=

"#" VALID NAME . " timed ="DELAY . " bwmin ="BW " bwmax ="BW [ " pps="NUMBER ] . " cpumin ="CPU " cpumax ="CPU . " type ="ID " rammin ="RAM " rammax ="RAM. ( " ia32 " | " ia64 " | " np4" | " np4_pp " | " ixp2400" | " ixp2400_pp" | . . . . ) . ( STRING | " file =" VALID NAME ) . ( " src " [ ID ] | " bin" ( PROC TYPE | ID ) ) [ "|" CPU RES ] [ { "|" RAM RES } ] . ( [ "(" COMP SPEC ")" ] VALID NAME ID | ID ) . COMP IDENT [ ":" ID ] "(" [ CTRL INFO ] ")" . [ TIMED ] SERV COMP { "!" ID "@"NUMBER } . "{" { CTRL COMP } "}" . "{" { SERV COMP } "}" . "[" [ "|" BW RES ] [ SERV COMP ] "]" . ( ID | " >" ID [ " copy " ] "?" INTF ) . ( ID | " >" ID [ " copy " ] [ "?" INTF ] ) . HOOK IN "@" [ TIMED ] [ GUARD ] COMP STRING "@" HOOK OUT . "{" ID [ "!" CTRL CHAIN ] { SERV CHAIN } "}" .

EBNF 1. The PromethOS NP Service Programming Language

the optionality-operator is defined already by pairs of brackets ([..]). Thus, the semantics of the original zero-to-many repetition-operator is expressed as [{..}] by our EBNF variant. The fundamental concept of the SPL is the linear specification of arbitrary service graphs consisting of service and control chains. Based on the concept of hooks to which service chains are attached, graphs are created out of the linear specification. The key element of the SPL is the service component specified by the SERV COMP production. It starts with the component identifier COMP IDENT . Part of the component identifier is the specification of the resources (COMP SPEC) required for its instantiation and the data format of the component. If it is specified as a reference to source code file (src), the platform assumes a component for the PromethOS NP processing environment for GPPs [13], and creates the respective binary component. Otherwise, in case of a binary component specification (bin), the SPL demands for the definition of the processor core type. This specification is relevant since different, incompatible ISAs may be available on a node. In both cases, the processor core can be specified (ID) on which the service component must be installed. This ID identifies a particular core per processor, and is required, for example, if not all processor cores are able to access particular hardware accelerators. The service component is then identified by the name of an object followed by its component instance identifier (ID). In case a service component instance is reused, the ID of a previously created instance is defined in the string of components. The router platform provides three pseudo components named NIL, DROP and CLASSIFY that exploit respective platform internal capabilities. Conceptually, they provide the interfaces like other service components, and their instances are identified by the same methods. Service components export CCIs optionally. In the SPL, they are specified by the ” : ID” term. Control information (CT RL INFO) to initialize a service component at service configuration time


61

is specified then. It represents either a string of ASCII4 characters or by a reference to an arbitrary object. Control service components (CT RL COMP) are service components that may be triggered by a timer event (T IMED), and that are bound to the control interfaces of other service components by the !ID@NUMBER statement. There, an ID references the control port exported by another service component, and NUMBER provides the control port multiplexing functionality needed to bind controlled service components to specific control mechanisms of a control component. Guards are defined by the respective GUARD production according to its model introduced above. Please note that the specification of bandwidth limits and the maximal number of packets per second (BW RES) are specified as part of the guard production since the dispatching function of hooks needs to control these limits already for the packet dispatching to guards such as to separate control from service function. Hooks are specified by their respective productions (HOOK IN and HOOK OUT ). Reuse of a hook is specified by the notion of a previously created hook identifier (ID). The creation of hooks is initiated by the literal ” > ”, followed by the hook identifier (ID), the optional specification of the ”copy” method for the hook’s dispatching semantics and the binding of a hook to an interface ”?INT F”. In case no ”copy” method is specified at hook creation time, the dispatching semantics follow the first-match-firstconsume method. Note that the definition of the dispatching semantics for outbound hooks (HOOK OUT ) is needed since they are reused for further service chains potentially. Ingress hooks bound to network interfaces receive packets from the router platform following the copy method, i.e. all hooks bound to a network interface receive every incoming network packet. Analogous to the service components, the router platform provides a pseudo hook named NIL that is used to satisfy the SPL syntax for dangling hooks that are never extended, or for service chains that do not receive but just generate data. Service chains are then specified by the SERV CHAIN production that provides the aforementioned semantics of the service chain concept. Note the optional definition of a maximal delay (T IMED) the service chain is allowed to add on a packet processed by the service chain. The optional definition of the guard production allows for the specification of catch-all service chains as required for fall-back service paths if no previously defined guard accepted a packet. The service (SERVICE) is identified by its service identifier (ID) that specifies the service name space. Optionally, a service consists of a control chain (CT RL CHAIN) that contains the control service components, followed by the definition of the constituent service chains for data path packet processing.

4 Evaluation For proof of concept of our SPL, we illustrate its capabilities by a service program and its corresponding visualization hereafter. 4

ASCII – American Standard Code for Information Interchange as defined by the ISO/IEC standard 646.

62

L. Ruf et al. Table 1. Three Parallel Service Chains Visualization

Chain 1

Chain 2

NIF1

3

component

2

component

component

1

{ # threeparallel > # hook1 hook1 demux1 demux3 ? NIF1 @/ ∗ HOOK ∗ / demux2 [ / ∗DEMUX1∗ / ] { / ∗ COMP STRING ∗ / ( bin ia32 ) component1 #instance1ID ( / ∗ CTRL INFO ∗ / ) } @/ ∗ HOOK ∗ / > # hook2 hook2 ? NIF2

/ ∗ e x t e n d hook1 ∗ / # hook1 @/ ∗ HOOK ∗ / [ / ∗DEMUX2∗ / ] { / ∗ COMP STRING ∗ / ( bin ia32 ) component2 #instance2ID ( / ∗ CTRL INFO ∗ / ) } @/ ∗ HOOK ∗ / # hook2

Chain 3 / ∗ e x t e n d hook1 ∗ / # hook1 @/ ∗ HOOK ∗ / [ / ∗ DEMUX3∗ / ] { / ∗ COMP STRING ∗ / ( bin ia32 ) component3 # instance3ID ( / ∗ CTRL INFO ∗ / ) } @/ ∗ HOOK ∗ / # hook2 } / ∗ S e r v i c e End ∗ /

NIF2

Three Parallel Service Chains. Table 1 presents a simple exemplary service program that defines a network service with three parallel service chains. The service program illustrates the linear specification of a service graph with parallel service chains. The service identifier (#threeparallel) is followed by the creation of hook1. No copy method is specified. Hence, its packet dispatching semantics follow the first-match-first-consume method in the top-down order of specified service chains. Hook1 is bound to one network interface (NIF) that is symbolized by the term NIF1. The service chain that consists of component1 is attached to hook1, first. While the figure in Table 1 illustrates the demultiplexing of flows to the particular service chains by attaching abstract demux conditions to the links between hook1 and the respective service chain, no real demultiplexing is specified in the service program. However, demultiplexing conditions are indicated in the service program by the respective comments. All service chains lead into hook2, which is bound to the second NIF (NIF2). The second and third service chains follow the same principle. Their specification differs from the first service chain by that hooks are re-used, i.e. the newly defined service chains are attached to the existing hooks.

5 Summary and Conclusions In this paper, we have introduced the PromethOS NP service model and presented its Service Programming Language (SPL) that is used to specify network services. The SPL provides, hence, the Service Programming Interface (SPI) of PromethOS NP to create new network services and to define additions to previously deployed ones on extensible routers. The service model provides the concept of a name space that is used to create the environment for network services of which multiple may reside in parallel on an extensible router platform like PromethOS NP. Within a name space, services are defined as a graph of service chains with constituent service components for data path processing. They are controlled by the service control chain realizing distributed, service internal control relations. Service chains are embedded between pairs of hooks. Hooks provide


63

the dispatching functionality of network traffic to service chains that accept packets depending on their guards. Hooks are dynamically created within a service and serve from thereon as the reference point for service additions to extend previously deployed network services. The SPL has been proposed as a context-free service programming language of our service model. Its syntax has been defined in a modified EBNF notation, and the semantics of the important production have been introduced extensively. For a proof of concept, we have applied our SPL to define an exemplary service program that illustrates the fundamental concept of a linear specification of arbitrary service graphs and their internal data path and control communications. We are convinced that our service model with the SPL provide a suitable way to specify distributed network services for service extensible routers. The model contributes to research by three novelties: 1.) flexible service extensibility based on hooks that are dynamically created, 2.) the 1:n bi-directional control relation between a control and multiple controlled service components, and 3.) the service control bus that propagates signals between subsequent data path service components. The SPL proposes a concise method to specify network services that are based on our service model. Our SPL extends previous work by the concepts resource constraints assigned to service chains. The definition of the pseudo component NIL provides the methods to define syntactically correct service programs with cut-through channels, the DROP element supports explicit packet dropping, and the CLASSIFY component is used to exploit platform internal classification mechanisms like hardware supported packet classification engines. Moreover, the CLASSIFY component together with the instance re-use method provides the capability to exploit mechanisms of advanced network processors in which multiple disjoint rules may be compiled into an advanced matrix-based packet classification that all lead to the same service component. Based on our service model, the service infrastructure of the PromethOS NP router platform has been designed and implemented. The SPL is currently used as the SPI to the PromethOS NP router platform for service creation and extension. However, we are convinced that our service model with its SPL provides the concepts for applications in a larger scope than only for node-local network service creation. As an example, we envision their use for other distributed component-based data processing applications, such as staged image processing that need service internal data and control relations.

References 1. Becker, T., Bossardt, M., Denazis, S., Dittrich, J., Guo, H., Karetsos, G., Takada, O., Tan, A.: Enabling customer oriented service provisioning by flexible code and resource management in active and programmable networks. In: IEEE International Conference on Telecommunications (ICT), Bucharest, Romania. IEEE, Los Alamitos (2001) 2. Bossardt, M., Antink, R.H., Moser, A., Plattner, B.: Chameleon: Realizing automatic service composition for extensible active routers. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982. Springer, Heidelberg (2004) 3. The FAIN Consortium. D14: Overview FAIN Programmable Network and Management Architecture (May 2003) 4. da Silva, S., Florissi, D., Yemini, Y.: Composing active services with NetScript. In: Proc. DARPA Active Networks Worshop, Tucson, AZ (March 1998)

64

L. Ruf et al.

5. Decasper, D., Dittia, Z., Parulkar, G., Plattner, B.: Router Plugins: A Software Architecture for Next Generation Routers. In: Proc. of the ACM SIGCOMM 1998 Conf., Vancouver, British Columbia, Canada. ACM Press, New York (1998) 6. Dijkstra, E.W.: Guarded Commands, Nondeterminacy and Formal Derivation of Programs. Commun. ACM 18(8) (1975) 7. IBM Corp. Datasheet IBM NP4GS3(March 2004), http://www.ibm.com 8. Intel Corp. Intel IXP2xxx hardware reference manual (2003), http://www.intel.com 9. Kohler, E., Morris, R., Chen, B., Jannotti, J., Kaashoek, M., Modular, C.: The Click Modular Router. ACM Transactions on Computer Systems 18(3) (August 2000) 10. Peterson, L. (ed.): NodeOS Interface Specification. Active Network Working Group (January 2001) 11. Object Management Group (OMG). The Common Object Request Broker: Architecture and Specification. TC Document 91.12.1, Revision 1.1, OMG (December 1991) 12. Object Management Group (OMG). CORBA Components. Technical Report Version 3.0, OMG (June 2002) 13. Ruf, L., Keller, R., Plattner, B.: A Scalable High-performance Router Platform Supporting Dynamic Service Extensibility On Network and Host Processors. In: Proc. of 2004 ACS/IEEE Int. Conf. on Pervasive Services (ICPS 2004), Beirut, Lebanon. IEEE, Los Alamitos (2004) 14. Ruf, L., Pletka, R., Erni, P., Droz, P., Plattner, B.: Towards High-performance Active Networking. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982. Springer, Heidelberg (2004) 15. Ruf, L., Wagner, A., Farkas, K., Plattner, B.: A Detection and Filter System for Use Against Large-Scale DDoS Attacks in the Internet Backbone. In: Minden, G.J., Calvert, K.L., Solarski, M., Yamamoto, M. (eds.) Active Networks. LNCS, vol. 3912, pp. 169–187. Springer, Heidelberg (2007) 16. W3C XML Working Group. Extensible Markup Language (XML). Recommendation 6, W3C (October 2000), http://www.w3c.org 17. Wirth, N.: What can we do about the unnecessary diversity of notation for syntactic definitions? Communication of the ACM 20 (1977)

A Network-Based Response Framework and Implementation Marcus Tylutki and Karl Levitt University of California, Davis, CA 95616, USA {tylutki,levitt}@cs.ucdavis.edu

Abstract. As the number of network-based attacks increase, and system administrators become overwhelmed with Intrusion Detection System (IDS) alerts, systems that respond to these attacks are rapidly becoming a key area of research. Current response solutions are either localized to individual hosts, or focus on a refined set of possible attacks or resources, which emulate many features of low level IDS sensors. In this paper, we describe a modular network-based response framework that can incorporate existing response solutions and IDS sensors. This framework combines these components by uniting models that represent: events that affect the state of the system, the detection capabilities of sensors, the response capabilities of response agents, and the conditions that represent system policy. Linking these models provides a foundation for generating responses that can best satisfy policy, given the perceived system state and the capabilities of sensors and response agents. Keywords: Autonomic response, response modeling, response framework.

1

Introduction

The first intrusion detection systems were developed as low level sensors that detected attacks by using attack signatures on low level event logs [1,2,3]. Since these sensors lacked the context of a high level system policy, correlation-based intrusion detection systems were developed, which allowed for a broader context for interpreting the higher-level effect of an observed event. Similarly, current response systems operate on a relatively small scope of possible responses and state assessment with respect to policy. As an example, the Intrusion Detection and Isolation Protocol [7] uses a simple cost model for each link and modifies firewall rules to isolate infected hosts from the rest of the network. The Light Autonomic Defense System (LADS) [8] is an effective host-based solution, but does not incorporate a system-wide policy or systemwide responses. CIRCADIA [9] is a network-wide solution that uses a simple cost model with a table lookup for determining appropriate responses. Toth and Kruegel [10] present a useful dependency-based response model that can create and modify firewall rules, kill and restart processes on individual hosts, and

This work was sponsored by NSF grant ITR-0313411.


66

M. Tylutki and K. Levitt

reset a user profile to a predetermined template. However, their attack domain is mainly limited to resource management problems and they do not present a model capable of incorporating other response systems. In addition, these response systems assume the sensors that provide their alerts are infallible. Some response agents, such as Honeynet [14,13] and the Deception Toolkit [11,12] are extremely useful response agents for a larger response model. These response agents can be refined with information from higher-level events. If a high-level IDS predicts an attacker’s goals or future targets, this information could be used to reconfigure these agents to better deceive the attacker. Other response agents, such as DDoS mitigation systems [4,5,6], can also be used and configured based on their requirements and expected performance. This paper presents the Autonomic Response Model (ARM), an expressive model that unites sensor capabilities, response agent capabilities, attack and state related events, and system policy. This allows for the model to generate a policy-based optimal response. An implementation and framework based on this model is discussed in detail, as well as some experimental results.

2

Autonomic Response Model

The decision agent for ARM receives alerts from intrusion detection systems (i.e., sensors), in addition to agents that report policy changes and model-based changes. Any resulting response set is submitted to the corresponding response agents. The decision agent also recalculates the optimal sensor configuration with respect to policy. If this differs from the previous global sensor configuration, sensor configuration updates are submitted to the appropriate sensors. 2.1

Basic Components

This model uses several components as building blocks. Event classes contain attribute/value based pairs that are used to describe attack events, policy events, and state events. Each event class also has a predetermined set of policy-derived detection constraints that must be satisfied by current sensor configurations. Event instances are instances of event classes and describe an aspect of the current perceived state of the system. Alerts from sensors are translated into event instances. Each event instance has an associated false positive probability (F P P ) that represents the probability that the corresponding event that the event instance represents does not exist. This probability is directly determined by the sensor configuration that reported it or the highest F P P of all prerequisite event instances of the event instance. Rules describe the relationship between event classes. If event instances of the prerequisite event classes exist to satisfy all of the preconditions of a rule, postrequisite event instances are generated. These postrequisite event instances are initialized from postrequisite conditions associated with the rule, which refer to attributes of the prerequisite event instances or rule-specified constant values. In addition, prerequisite event instances may be modified by a postcondition.

A Network-Based Response Framework and Implementation

67

Sensor configurations are represented by the detection thresholds for each event class it detects. A detection threshold is represented as a threshold for F P P , false negative probability (F N P ), and timeliness (T ). F P P represents the probability that an alert produced by the sensor configuration is based on an event that does not exist. F N P represents the probability that given an event exists that should have been reported as an alert, it was not. T represents the estimated time the sensor configuration takes to report the alert from the moment the event takes place. This information can be obtained from receiver operating characteristic (ROC) curves for each event class and sensor pair1 . Many attack modeling languages can be used for these components [15,16,17,18]. In addition, to make the translation from sensor alerts to event instances, a common report language adapted from CIDF [19] or IDMEF [20] can be used, despite the difficulties they have encountered in gaining widespread acceptance. 2.2

Prevention and Recovery Response Model

Alerts are translated into event instances and are processed one at a time by the decision engine. System policy is represented using event classes, rules, and event instances that represent key aspects of system state. If an event instance is created that belongs to a policy violation labeled event class, then the decision engine searches for an optimal response set to handle the problem. This response set recovers from the effects of the policy violation and prevents attempts from an identical attack vector from resulting in another policy violation. Each policy violation event class also has a field that determines the acceptable F P P threshold that the corresponding event instance’s F P P must be below to be considered as a valid policy violation. If a policy violation event instance (P V EI) does not exist, or existing P V EI F P P s surpass their corresponding thresholds, then the decision engine waits for more alerts. Finding Solutions. Each P V EI has at least one prerequisite event instance that matched a rule to create it, even if it was generated from a one-to-one rule matching. Each prerequisite may have additional prerequisites that contributed to the generation of the P V EI. This generates a tree of event instances that resulted in the generation of the P V EI. A satisfying response solution set is able to recover all event instances on a path within this tree, as well as preventing at least one of these event instances from reverting back into the state that resulted in the generation of the P V EI. Recovery responses are therefore highly relative to the context of the event instances they are recovering within the policy violation tree. Recovery responses are designed to break the conditions of the rule in which the corresponding event instance was used to generate 1

It is acknowledged that most current ROC curves for sensors describe their average overall detection capabilities, rather than being associated with specific alert types or categories. It is also acknowledged that these probabilities and values are highly dependent upon the environment in which they are recorded.

68


the P V EI. Prevention responses are designed to ensure that newly changed values do not easily revert to their previous values. Prevention responses on event instances at leaf nodes of the policy violation tree, which are not translated from an attack alert2 , are resistant to attacker influence from previous attack vectors. If a prevention response is unavailable due to the lack of information on the origin of an event instance, backchaining can be applied. Suppose a Tripwire [21] sensor reports that a filesystem has been compromised, but no other alerts can identify the source of the service that resulted in the compromised filesystem. Backchaining obtains all services with access to the compromised filesystem that may be at fault. If prevention responses are initiated for all of these services, the effect is the same as initiating a prevention response for the compromised filesystem event instance. Similarly, an anomaly-based sensor may not be able to pinpoint the origin of an event instance as well as a signature-based sensor. Alerts from a signaturebased sensor typically directly determine the specific vulnerability that the attack attempted to exploit. By comparison, an anomaly-based sensor may only be able to report generic attack behavior from a particular source to a particular host and/or service. Backchaining can be used to cover all possible attack behaviors against the targetted service. Evaluating Solutions. The response set for a particular path represents the response event classes that are associated with rules or other event classes. Each generic response event class can be initialized into a response event instance based on the values of the corresponding event instance to which it is responding, or based on the prerequisite event instances and prerequisite conditions of the corresponding rule matching within the policy violation tree. Within a specific path in the policy violation tree, different response sets are tested by temporarily adding the corresponding response event instances. After the testing of all combinations of a path are complete, new paths in the tree are tested. The response set that produces the best state assessment when tested is the response set that is initiated. A simple metric for assessing the state is the sum of all state assessment values (SAV s) of current event instances. Rather than have a SAV for all possible states, this approach has a SAV for each event instance, which corresponds to that event instance’s influence on the assessment of the overall state of the system. Event instances that are critical with respect to policy, such as critical services, have positive SAV s. Event instances that represent penalties to the system policy and impact the availability or integrity of the system, have negative SAV s. Each event instance has a SAV associated with the event class from which is it a member. Rules and policies can have exceptions to this default allocation can modify or override these values. This assessment method can be enhanced through the addition of assessment rules. These rules modify the overall SAV of a state based on the presence or 2

Alerts from system state sensors, such as sensors that scan current versions for available services, are acceptable.


69

absence of particular event instances, and can be synergistic (i.e., two event instances result in a net SAV greater than their sum) or dyssynergistic (i.e., two event instances result in a net SAV less than their sum). Cost models based on risk analysis [22] can also be adapted to determine these values. Once a global optimal response set is found, these response event instances are added to the decision agent’s current state, and each response event instance is submitted to the appropriate response agent. Each response agent that receives the response makes the appropriate changes to its local configuration. 2.3

Sensor Retargeting

Sensors can become reconfigured based on policy changes. As critical tasks for a system change, so should its policy. Some of these critical tasks may be time dependent, short term tasks, while others may be more long term tasks. These tasks are represented in the policy model and correspond to individual event instances with corresponding SAV s. In addition to their use for assessing the state of the system, SAV s can be used to prioritize the detection of particular event classes. SAV s of an event class can be used to directly determine its allowable detection thresholds. In addition, sensors have resource costs. If costs were ignored for integrity scanners, such as Tripwire, then the constant operation of these scanners are likely to impact the performance of the scanned hosts. Instead, the traditional tradeoff between performance and stability (or security in this case), is acknowledged, allowing these scanners to only run periodically. The balance of this tradeoff can be shifted depending on the SAV of the event class that the sensor attempts to detect. A higher SAV event class is more critical, and therefore results in lower detection thresholds. Si =

n

(RLr − Rk (i))

(1)

r=1

The overall cost for a set of sensor configurations can also be assessed with a more complex load balancing metric, as shown in Equation 1, where the solution set with the highest value of Si is considered the most efficient with respect to policy. A similar metric can be adapted that measures the distance between current detection capabilities of sensor configurations and event class detection thresholds. This alternative metric prefers better detecting sensor configurations over resource conserving sensor configurations. Sensors can also be preemptively retargeted. Suppose an event instance (EIn ) is generated from a rule matching of other event instances. If EIn belongs to an event class with very low detection thresholds due to its SAV , then these detection thresholds are passed down to the prerequisite event classes from the rule that generated EIn . The first step for this detection threshold propagation is to obtain γ(P, r), which represents how close prerequisite event instances in P are to creating a successful match with rule r and is defined in Equation 2. Each event class possesses an α value, which represents the event class’ relative importance

70


compared to other event classes for rule matchings3 . γ is initialized with the sum of all α values of prerequisite event classes, multiplied by a β factor4 , which is an attribute of the rule that is matched. If a prerequisite event instance matches all preconditions for the rule, the entire α value for that prerequisite’s event class is subtracted from γ. Partial matches result in only subtracting α2 . These values are also influenced by the false positive probabilities of each prerequisite event instances, as shown in Equation 2. γ(P, r) = βr (αi ) − (αj (1.0 − F P Pj )) − i∈P

k∈P artial(P,r)

j∈F ull(P,r)

α

k

2

(1.0 − F P Pk )

(2)

New detection thresholds are propagated for prerequisite event classes from each detection threshold of each postrequisite event class. The k th new propagated F P P detection threshold (N DF P Pi,k ) for prerequisite event class i is defined in Equation 3, where DF P Pj,n represents the nth F P P detection threshold for postrequisite event class j. False negative probability thresholds and timeliness thresholds are propagated using the same equation, but for their respective threshold values. γ (P, r) N DF P Pi,k = 1.0 + DF P Pj,n (3) αi 2.4

Attacks and Countermeasures

Attacks against ARM exploit the expressiveness of event classes and the established relationships between them. Even with a perfect model of event classes and their relationships, attacks may exploit the time it takes for the model to respond to an event by flooding it with trivial decisions that take a significant amount of time for the decision agent to determine. In addition, poorly designed models may cause infinite loops for exhaustive decision agents. When control systems perpetually overestimate or underestimate the current or future state of the system, increasingly inaccurate responses can occur, resulting in an unsteady state. Control systems used in chemical and electrical engineering have adapted meta-control agents that observe the behavior and results of their control system to enhance their reliability and have been able to prevent unsteady states from occuring within limited domains. Through the application of a similar meta-control agent for this model, many of the effects of these attacks can be mitigated. 3

4

As an alternative, α values could be tied to a specific prerequisite event class and rule pair which would be more precise, but would likely result in more α values to calibrate. β is considered to be greater than 0. This can result in propagating more strict detection thresholds if β is less than 1, since γ can be negative for this case. Additionally, if β is always greater than 1, the propagating detection thresholds are always less strict.


3

71

Implementation

Despite the previously mentioned response systems, and a response testbed [23], a modular response framework and testbed is not readily available. This modular response framework was developed and used in the Emulab [24] environment and is freely available upon request.

Fig. 1. Overall Response Framework

The implementation of this response framework that is presented in Figure 1 is comprised of four types of agents. The host-based agent is responsible for: simulating the effects of host and network based intrusion detection sensors, executing responses received from the response agent, and storing local host-based vulnerability profiles and sensor configurations. The aggregation agent is responsible for aggregating reports received from all host-based agents and submitting the relevant new reports to the response agent. Reports that have a higher false positive probability than a previously received report is not forwarded to the response agent. The response agent receives all sensor reports from the aggregation agent. Each report is processed individually. If a new policy violation occurs, the response agent searches for an optimal response set. If one is found, the corresponding responses are submitted to all applicable host-based agents. In addition, new sensor configurations are evaluated to determine if a new global sensor configuration better satisfies system policy. New sensor configurations are sent to the corresponding host-based agents. The controller agent is responsible for initializing all the other agents, and initiating any external attacks against the network.

72

3.1


Document Types

Messages passed between agents are in the form of XML documents. This subsection briefly describes the XML schemas used in the implementation. The event class schema contains the unique identifier for that event class, as well as all appropriate fields that are associated with the class. Fields can be of type integer, float, or string. This schema also supports detection thresholds for the event class, as well as the α value previously discussed in Subsection 2.3. The alert schema contains a unique identifier of the host and attack event that triggered it, as well as a F P P value that is associated with the probability that the alert is a false positive. Alert schemas contain fields that represent specific values that differ from the defaults of the event class from which it is derived. In addition, alert schemas are used for passing response messages from the response agent to the host-based agents. The host profile schema contains information about a host, including its IP address and services available on that IP address. This schema also mentions which filesystems each service has access to, as well as the version number of the service and its dependencies with other services. The IDS profile schema lists the identifiers of the event classes that the specific configuration detects and their corresponding detection values for F P P , F N P , and T . This sensor configuration schema also contains a generic resource cost for operating the sensor with this configuration. This schema also supports a NULL configuration for sensors that are disabled. The rule schema includes prerequisite event class identifiers, postrequisite event class identifiers, preconditions, and postconditions. Preconditions are represented by referencing the local rule identifier of the prerequisite event instance along with the name of its field that is being compared. For example, position 3 and field “Port” would refer to the rule’s third prerequisite event instance’s port value. Comparisons can be made to a constant value, or to another prerequisite event instance’s field value. The supported operators are equal, not equal, greater than or equal, less than or equal, greater than, and less than. Postconditions only support the equal operator for the initialization of postrequisite values. Postconditions can also be used to modify prerequisite event instance field values by referencing negative identifier values. In addition, rule schema include the β value of the rule that is used for preemptive sensor retargeting previously described in Subsection 2.3. The response map schema maps event classes to recovery and prevention response event class sets. It references the event class identifiers for each event class involved in the mapping, as well as additional fields for the response event classes to specify additional initialization information, as well as additional fields for the source event class that limit the applicability of the mapping. For example, a response map for an infected filesystem event class could restrict the response map to a specific filesystem. In addition, the response map specifies if the corresponding response sets are prevention response sets, recovery response sets, or both. The next two schemas were adapted from Joseph McAlerney’s thesis [25], which presented a framework for simulating and recording worm behavior using


73

agents and XML documents. The event profile schema represents the vulnerability profile of the host-based agent with respect to an individual attack event class. This schema was modified to support a requirements field, which lists the required services or filesystem needed for the corresponding attack event to succeed. The event properties schema is used for documents that represent attack events. It specifies propagation details, including the rate and amount of attacks that are initiated, if the attack event is intended to propagate. This schema was modified from the worm simulation version by adding fields to represent the effects of the attack, which correspond to creating specific event instances. This schema was also modified to represent the filesystem (including memory) that the attack resides in, if it is persistent. 3.2

Host-Based Agent

The code used for the host-based agents were adapated from the worm simulation project [25] to support responses, sensor reconfigurations, sensor simulation for false positives, false negatives, and timeliness values. The code was also adapted to support the changes to event profiles and event properties discussed at the end of Subsection 3.15 . Host-based agents are the only agents in the implementation that are multi-threaded. When a new document is received, a new thread is created to parse and process the document. Mutexes are used to ensure shared data constructs are not shared while a thread is operating in a critical section. A host-based agent is initialized with: all event class definitions used in an upcoming experiment, current IDS configurations, a host profile document describing the simulated services running on the host, and an event profile document for each attack class used in the upcoming experiment. Once an event properties document is received from either another host-based agent or the controller agent, the document is parsed into a local structure and current IDS configurations are checked to determine if any sensors successfully detect the attack. If the randomly generated probability is above the detecting sensor configuration’s F N P value for the attack’s corresponding event class, a new thread is spawned which generates the corresponding alert and submits it to the aggregation agent after sleeping for a period of time derived from the T value of the sensor configuration. If a sensor configuration fails to detect the attack, it is locally blacklisted from being able to report future occurrences with the same attack identifier6 . If the host-based agent is not vulnerable to the received attack event, the thread terminates. Otherwise, the effects of the thread get added as local event 5

6

All other agents, with the exception of the controller agent that sends arbitrary XML files to a designated host and port, were not associated with the worm simulation project. To clarify attack identifiers, suppose an experiment consisted of two worms. Each worm would have a different attack identifier. If a host-based agent received the worm from multiple hosts, each attack event would have the same attack identifier. However, if it received a different worm from the same host, it would have a different attack identifier.

74


instances, and sensor configurations that detect the corresponding event classes of these effects are examined. As above, if a sensor configuration detects an event instance, a new thread is spawned which submits the alert after sleeping. False positives are represented by receiving a non-attack event property document that mirrors a specific attack event property in every other way. If the randomly generated probability is below the F P P 7 for a given sensor configuration, an alert is generated and submitted as mentioned above, representing a false positive that appears identical to a true positive. Host-based agents are also responsible for updating local sensor configurations to those received from the response agent. In addition, host-based agents process responses from the response agent. Some responses, such as filesystem recovery responses, require a delay, which is specified in the appropriate delay-related fields of the response. Similar to alert reporting, a new thread is spawned which sleeps for the amount of time the response takes to complete. Other responses, such as firewall rule changes, are made instantaneously. In addition, since dependencies between filesystems and services are represented, responses that temporarily disable services or filesystems also disable services that require them. These filesystems and services are restored when the corresponding response is complete. Some responses require a service or filesystem to be available before it can become available again. Responses that have overlapping requirements are initiated sequentially on a first-come-first-serve basis. If a response recovers a filesystem that an attack event was residing in, the attack event ceases propagation. Prevention responses prevent future attack events from succeeding by making the host no longer satisfy the requirements for the attack event that are specified in the event profile. 3.3

Aggregation Agent

When the aggregation agent receives an alert, it compares the host and attack identifiers of the alert to previously seen alerts. If it does not find a match, it records the alert and forwards it to the response agent. If it finds a match, it compares the new alert’s F P P to the recorded alert’s F P P . If the new alert’s F P P is lower than the previous matching alert’s F P P , it passes this alert on to the response agent and overwrites the old alert with the new alert. Otherwise, the alert is dropped. 3.4

Response Agent

The response agent is initialized by receiving: event class documents defining all event classes to be used in the upcoming experiment, all IDS configuration profiles for all available sensors, the host profiles of all hosts, an event profile document for each host and attack event pair, rule documents including backchain 7

Recall that the definition provided for F P P is the probability that a given alert is a false positive, rather than the probability that a false positive alert will be generated from non-attack events. As a result, each sensor configuration could also contain these alternative false positive probabilities for this purpose.


75

rules as described near the end of Subsection 2.2, and response map documents that map event classes to available responses. When an alert document is received, it is first translated to a local event instance (EIl ). If EIl ’s values are identical to a currently existing event instance (EIp ), and EIl ’s F P P is lower than EIp ’s F P P , then EIp ’s F P P is updated to EIl ’s F P P , detection propagation thresholds are recalculated, and the response agent skips attempting to match the new event instance with other existing event instances. Otherwise, rules that require EIl ’s event class are then checked with EIl and all current event instances. As event instance combinations are tested, preemptive detection threshold propagation occurs, as discussed previously at the end of Subsection 2.3. Newly generated event instances inherit a F P P equal to the highest F P P of their prerequisite event instances. New event instances and modified event instances are added to a queue. Once all rules are checked for EIl , event instances from the queue are added one at a time, just as EIl was added, until the queue is empty. Rules that modify currently existing event instances must be designed carefully. Incorrect versions of these rules may result in an infinite loop where an event instance is constantly changed back and forth or the queue never becomes empty. All newly added and modified event instances are appended to a rollback queue as transactions. SAVoverall = (SAVi (1 − F P Pi )) (4) i∈EICurrent

If a policy violation event instance is generated, the response agent searches for a response solution set as described previously in Subsections 2.2 and 2.2. Before testing a response set, the rollback queue is cleared. After adding response event instances the system state and the resulting state is assessed, the system state is rolled back by rolling back each transaction on the rollback queue. A tested response set’s resulting system state assessment (SAVoverall ) is defined in Equation 4, where EICurrent represents the set of currently existing event instances. If a response set is found to provide a state that is estimated to be better than the current state, the responses are translated to alerts that are then submitted to the corresponding host-based agents. After the response phase, sensor configurations are analyzed with respect to all event class detection thresholds that must be upheld. If it is found that a detection threshold can not be satisfied by any existing sensor configuration, the response agent generates a local alert and the detection threshold is flagged as impossible. Some detection thresholds can also be virtual, representing the notion that they are intended to be inherited through preemptive detection threshold propagation rather than satisfied for the parent event class. All sensor configurations are then tested to determine the global sensor configuration that satisfies all detection thresholds but has the lowest impact on resources. For the purposes of this implementation, resource impact is assessed by the sum of all resource costs of sensor configurations into a single value, which could be enhanced with a more thorough cost model [22] or use of the more advanced metrics previously discussed in Subsection 2.3. If a new sensor configuration is found, the IDS profile representing the new configuration is sent to the affected host-based agents.

76

4


Experiments

A worm buffer overflow scenario was used for the experiments with this implementation. The majority of experiments were executed on a 7 node network on Emulab [24] where one node provided the aggregation agent and the response agent, and the remaining 6 nodes provided the host-based agents. 4.1

Setup

The experiments used a host-based anomaly IDS, a network-based signature IDS, and a host-based integrity IDS. The host-based anomaly IDS is similar to an anomaly-based IDS presented by Wenke Lee and Salvatore Stolfo [26]. In this case, a sliding window is used to observe anomalies in traffic patterns. The larger the traffic window, the lower the false negative and false positive probability, but results in a larger timeliness value strictly based on the size of the window, which includes window sizes of 5, 10, 30, 60, and 90 seconds. Since this sensor takes a traffic stream as input, if there exists a temporary cache of this traffic, the retargeted sensor could process old traffic with a new sensor configuration for an additional attempt to detect an attack or provide more evidence to a correlationbased sensor.The network-based signature IDS is loosely based upon Snort [27] or Bro [28] and only has default and NULL configurations. The timeliness values for this sensor is estimated to be approximately 80 milliseconds, based on a report presented in [29]. The host-based integrity IDS is Tripwire [21], which can scan a filesystem every 10, 15, 20, 30, 45, 60, 120, 240, or 720 minutes. The more frequent filesystem checks are intended for small but critical filesystems. Available responses included upgrading a service, disabling a service, and restoring a filesystem. The worms tested were run at propagation speed of one scan per 5 microseconds (fast), one scan per 50,000 microseconds (medium), and one scan per 80,000 microseconds (slow). In most experiments the vulnerability density was set to 0.5, representing 3 vulnerable nodes and 3 invulnerable nodes in the 7 node experiments. Experiments that exhibit the retargeting capabilities of the implementation used a vulnerability density of 0.83, which resulted in 5 vulnerable nodes and one invulnerable node in the 7 node experiments. 4.2

General Results

Figure 2 presents the average of 10 experiments using a 7 node experiment with a vulnerability density of 0.5 with a propagation speed of one scan per 5 microseconds. The y-axis represents the number of hosts, and the x-axis represents time in seconds on a logarithmic scale. Each graph is comprised of three lines: one for the number of infected hosts, one for the number of clean hosts, and one for the number of contained hosts. Five of these experiments under these conditions resulted in one node that failed to detect the attack with an anomaly or signature-based sensor, but where the Tripwire sensor succeeded in detecting


77

Performance of the Response Engine with a Fast Worm (Average) 6 Infected Clean Contained

5

# Hosts

4

3

2

1

0 0.001

0.01

0.1

1 Time (s)

10

100

1000

Fig. 2. Average Performance of Fast Experiments

the attack8 . In this case, the node was only recovered after sending the Tripwire sensor alert, which took ˜1800 seconds or 30 minutes with the default sensor configuration compared to the ˜0.1 seconds or less for nodes that detected the attack with an anomaly or signature-based sensor. Figure 3 presents the results of one experiment using the same experimental setup but with a propagation speed of one scan per 50,000 microseconds. In this case, the worm is caught before being able to spread to a vulnerable host, resulting in only one infection. About half of the remaining medium experiments exhibited this behavior, with the remainder representing the behavior shown for the fast worms. All but one of the slow experiments exhibited behavior similar to that of Figure 3. One of the rules used represents the generation of an unknown worm event class. This rule requires three event instances that have the same compromised filesystem but reside on different hosts. In experiments with a vulnerability density of 0.83, as this rule received more partial matches, and eventually a full match, the preemptive detection threshold propagation discussed at the end of Subsection 2.3 resulted in new sensor configuration changes, which included 8

Even though this allows for the case that a host-based anomaly IDS can miss the attack against one host, but catch the attack against another host, these discrepancies can be due to different background traffic observed on each host at the time of the attack. Similarly, this allows for the network-based signature IDS to catch an attack against some hosts, but miss them against others. This can be due to polymorphic worms where the available signature is able to detect some variants of the worm, but not all, and the worm changes form as it spreads.

78


Performance of the Response Engine with a Medium Worm (Trial 1) 6

5

# Hosts

4

3

Infected Clean Contained

2

1

0 0.001

0.01

0.1

1 Time (s)

10

100

Fig. 3. Medium Experiment #1

lowering the Tripwire timeliness values from one scan per 30 minutes to one scan per 20 minutes. For some nodes that failed to detect the attack with a signature or anomaly-based sensor, this reduced the amount of time the alert was sent from the infected node to the response agent from ˜1800 seconds to ˜1200 seconds. 4.3

Scalability Test Results

For scalability concerns, the experiment was also executed with 15 and 31 nodes with a 0.5 vulnerability density. On average, 7 node experiments resulted in the response agent calculating the last optimal response set within 0.019993 seconds. The 15 node experiment was able to calculate the last optimal response set within 0.280744 seconds, while the 31 node experiment took 2.49284 seconds resulting in about a 10 fold increase each time the number of nodes are doubled. However, it should be noted that these results were obtained with extensive debug log information, printing out timestamps and data for key points within the decision engine, including partial and full rule match information, and new detection threshold additions from propagation. With the trimming of just rule match notifications (but not information about newly generated event instances), the 31 node experiment was able to reduce the calculation time to 0.700421 seconds, which could likely be reduced further with less precise timestamps and further trimming. Note that decreasing the number of nodes or lowering the vulnerability density increases performance.


4.4

79

Advanced Scenario

The following scenario can be adapted into an experiment with this implementation with relatively minor adjustments. In this scenario, the attacker utilizes multiple attack vectors for the primary goal of obtaining access to a relatively secure workstation, halfdome. Halfdome runs a local firewall and does not provide any services that are externally visible. The network halfdome is on (N ) does not utilize any firewalls and is externally accessible. In the first step, the attacker initiates a worm similar to the worm described in the experiments within Subsections 4.2 and 4.3. Although halfdome is not compromised, pinatubo, which resides on network N, is vulnerable and becomes compromised. This attack goes undetected by quick intrusion detection sensors, but will be detected by an upcoming integrity scan. The attacker then attempts to sniff passwords from network N, but is unable to find unencrypted traffic involving halfdome. However, the attacker is able to discover that halfdome uses hawkeye for DNS requests, which happens to be a Windows 2000 DNS server. The attacker then launches a Distributed Denial of Service (DDoS) attack against hawkeye using attacks from remote hosts, as well as attempting to steal hawkeye’s IP address using pinatubo and other local, compromised hosts by spoofing ARP requests and replies. The DDoS attack is easily detected by sensors and is reported to the response agent which initiates pushback on cooperating routers [4]. Pushback provides some mitigation of the attack, but is unable to provide complete protection from the attack due to the limited domain of routers that support pushback. After the response agent receives a status alert on the partial success of the pushback response, it activates a proportional-integralderivative controller-based response [6]. This combined response towards the DDoS attacks sufficiently mitigates the attack to allow for critical services to satisfy availability levels determined by policy. During the external attack, the response agent also receives an alert of spammed ARP spoofs from hosts trying to steal hawkeye’s IP address. This event is detected, but the response agent does not initiate a response since it is unsure which ARP replies are spoofs and which are genuine. A correlation sensor is able to suggest a common service the ARP spoofing hosts shared as a possible source of infection. The response agent also receives this report, but due to the high false positive probability, it does not issue a response. During the DDoS attack, the attacker is able to poison the DNS cache of halfdome by spoofing DNS replies [30,31] from hosts that were able to temporarily successfully steal hawkeye’s IP address. Because the attacker attempts to spam the DNS replies to halfdome in an attempt that one will get through, an anomaly-based sensor detects the attack and forwards an alert to the response agent. A correlation sensor sees the anomaly-based sensor’s alert and correlates this with the ARP spoofs and the possible common compromised service to produce a low false positive report on the compromised hosts. This results in a Tripwire integrity scan of all suspicious hosts while the traffic from halfdome to external sites is temporarily throttled at halfdome’s local firewall. All suspicious hosts are soon confirmed to be infected, which results in the restoration of in-

80


fected filesystems and the disabling of the previously correlated service on the infected hosts. Alternatively, backups of the recovered systems are made with the disabled service. Once complete, an attempt is made to upgrade the vulnerable service to a more recent version. An automated testing procedure is executed to detect if dependent services are still able to function with the upgraded service. If successful, additional previously infected hosts attempt to upgrade their service as well and test for problems. If a problem occurs, the previous image is rolled back with the service disabled and the local administrator is notified to remedy the problem. In order to use this scenario with the current developed framework, a few key changes would have to be made. First, response feedback would have to be added by preserving policy violations that were responded to, observing the results of previous responses by retargeting sensors to observe the corresponding event classes, and initiating alternative responses that are stored along with the previous policy violation. Second, the response agent must be able to correlate seperate alerts into an overall attack vector, which is a problem many correlation systems have attempted to solve. Third, the event properties schema must be modified to be able to encapsulate other event properties documents, allowing for any attack scenario.

5

Conclusions and Future Work

In this paper we presented a modular, extensible response framework along with an implementation of a response system that utilizes this framework. The framework allows for various simulated or real intrusion detection systems, response agents, and aggregation agents. The response model and implementation presented demonstrated the benefits of sensor retargeting and supporting an expressive model that encompasses a wide variety of attacks, sensors, response agents, and policies. The experimental results presented could be compared for different high level response systems for specific response scenarios for purposes of evaluation. Although the experimental scenarios were relatively simple, a detailed scenario is presented that can be executed with minor modifications to the current implementation. Although attacks such as infinite loops are possible through poor design as described in Subsection 3.4, they can be prevented or mitigated with loop timeouts, or with the integration of a professional expert system that is designed to catch such loops. There are many other approaches for extending and enhancing this work, in addition to those proposed in Subsection 4.4, including the following: – Bayesian inferencing can be used to more accurately calculate the false positive probabilities of an event instance by taking several additional conditional probabilities into account. – This probabilistic model can be used to create a metric that assesses the detection or response capability of a system by comparing the probabilities


81

that a system can be recovered and prevent future attacks for a given general scenario within a specified timeframe. – The integration of a professional expert system into the response agent, which would greatly increase the efficiency of the implementation, but would make the preemptive detection threshold propagation discussed in Subsection 2.3 more difficult. – A model for making sensor configuration detection threshold values a function of state properties makes these values much more realistic and dynamic. – By modifying rules to allow for any type of computation, rather than straight-forward expert system rules, entire sensors/response engines or their components can be included in the model.

References 1. Snapp, S., Brentano, J., Dias, G., Goan, T., Heberlein, T., Ho, C., Levitt, K., Mukherjee, B., Smaha, S., Grance, T., Teal, D., Mansur, D.: DIDS (Distributed Intrusion Detection System) - Motivation, Architecture, and an Early Prototype. In: Proc. 14th National Computer Security Conference (1991) 2. Heberlein, L., Dias, G., Levitt, K., Mukherjee, B., Wood, J., Wolber, D.: A Network Security Monitor. In: Proc. IEEE Symposium on Security and Privacy (1990) 3. Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303, USA. SunSHIELD Basic Security Module Guide, Solaris 7, Part No. 805-2635-10 (October 1998) 4. Ionnidis, J., Bellovin, S.M.: Implementing Pushback: Router-based Defense against DDoS Attacks. In: Proc. The Network and Distributed System Security Symposium (2002) 5. Sterne, D., Djahandari, K., Wilson, B., Babson, B., Schnackenberg, D., Holliday, H., Reid, T.: Autonomic response to distributed denial of service attacks. In: Lee, W., Mé, L., Wespi, A. (eds.) RAID 2001. LNCS, vol. 2212, p. 134. Springer, Heidelberg (2001) 6. Tylutki, M., Levitt, K.: Mitigating distributed denial of service attacks using a proportional-integral-derivative controller. In: Vigna, G., Kr¨ ugel, C., Jonsson, E. (eds.) RAID 2003. LNCS, vol. 2820, pp. 1–16. Springer, Heidelberg (2003) 7. Rowe, J.: Intrusion Detection and Isolation Protocol: Automated Response to Attacks. In: Recent Advances in Intrusion Detection (1999) 8. Kreidl, O., Frazier, T.: Feedback Control Applied to Survivability: A Host-Based Autonomic Defense System. IEEE Transactions of Reliability 52(3) (2003) 9. Musliner, D.: CIRCADIA Demonstration: Active Adaptive Defense. In: Proc. DISCEX 2003 (2003) 10. Toth, T., Kruegel, C.: Evaluating the Impact of Automated Intrusion Response Mechanisms. In: Proc. 18th Annual Computer Security Applications Conference (2002) 11. Cohen, F., Lambert, D., Preston, C., Berry, N., Stewart, C., Thomas, E.: A Framework for Deception (July 2005) (accessed July 2005), http://www.all.net/journal/deception/Framework/Framework.html 12. Cohen, F.: Leading Attackers through Attack Graphs with Deceptions. Computers and Security 22(5), 402–411 (2003) 13. The Honeynet Project (accessed June 2005), http://www.honeynet.org

82


14. Spitzner, L.: The Honeynet Project: Trapping the Hackers. In: Proc. IEEE Symposium on Security and Privacy (2005) 15. Templeton, S., Levitt, K.: A Requires/Provides Model for Computer Attacks. In: Proc. 2000 New Security Paradigms Workshop, pp. 31–38 (2000) 16. Cheung, S., Lindqvist, U., Fong, M.: Modeling Multistep Cyber Attacks for Scenario Recognition. In: Proc. DISCEX 2003 (2003) 17. Michel, C., Mé, L.: AdeLe: An Attack Description Language for Knowledge-Based Intrusion Detection. In: Trusted Information: The New Decade Challenge: IFIP TC11 16th International Conference on Information Security (IFIP/SEC 2001), pp. 353–368 (2001) 18. Cuppens, F., Ortalo, R.: LAMBDA: A language to model a database for detection of attacks. In: Debar, H., Mé, L., Wu, S.F. (eds.) RAID 2000. LNCS, vol. 1907, pp. 197–216. Springer, Heidelberg (2000) 19. Staniford-Chen, S., Tung, B., Schanckenberg, D.: The Common Intrusion Detection Framework (CIDF). In: Information Survivability Workshop (1998) 20. Debar, H., Curry, D., Feinstein, B.: The Intrusion Detection Message Exchange Format. Internet Draft (July 2004) (accessed July, 2005), http://xml.coverpages.org/draft-ietf-idwg-idmef-xml-12.txt 21. Kim, G., Spafford, E.: The Design and Implementation of Tripwire: A File System Integrity Checker. Technical Report CSD-TR-93-071, Purdue University, West Lafayette, IN 47907-1398 22. Lee, W., Fan, W., Miller, M., Stolfo, S., Zadok, E.: Toward Cost-Sensitive Modeling for Intrusion Detection and Response. Journal of Computer Security, 5–22 (2002) 23. Rossey, L., Cunningham, R., Fried, D., Rabek, J., Lippmann, R., Haines, J., Zissman, M.: LARIAT: Lincoln Adaptable Real-time Information Assurance Testbed. In: Recent Advances in Intrusion Detection (2001) 24. White, B., Lepreau, J., Stoller, L., Ricci, R., Guruprasadm, S., Newboldm, M., Hiber, M., Barb, C., Joglekar, A.: An Integrated Experimental Environment for Distributed Systems and Networks. In: Proc. 5th USENIX Operating systems Design and Implementation Symposium (2002) 25. McAlerney, J.M.: An Internet Worm Propagation Data Model”. M.S. thesis, University of California, Davis (2004) 26. Lee, W., Stolfo, S.: Data Mining Approaches for Intrusion Detection. In: Proc. 7 th USENIX Security Symposium (1998) 27. Roesch, M.: Snort - Lightweight Intrusion Detection for Networks. In: Proc. 13th Systems Administration Conference, USENIX (1999) 28. Paxson, V.: Bro: A System for Detecting Network Intruders in Real-Time. Computer Networks 31(23-24), 2435–2463 (1999) 29. Kruegel, C., Toth, T.: Flexible, Mobile Agent Based Intrusion Detection for Dynamic Networks. In: Proc. European Wireless (2002) 30. DNS Poisoning Summary (March 2005) (accessed July 2005), http://isc.sans.org/presentations/dnspoisoning.php 31. How to Prevent DNS Cache Pollution, Article ID 241352 (accessed July 2005), http://support.microsoft.com/default.aspx?scid=kb;en-us;241352

Towards Resilient Networks Using Programmable Networking Technologies Linlin Xie1 , Paul Smith1 , Mark Banfield3 , Helmut Leopold3 , James P.G. Sterbenz1,2 , and David Hutchison1 1

2

Computing Department InfoLab21 Lancaster University Lancaster, LA1 4WA, UK {linlin.xie,p.smith,jpgs,dh}@comp.lancs.ac.uk Information Technology and Telecommunications Research Center Department of Electrical Engineering and Computer Science University of Kansas Lawrence, Kansas 66045-7621, USA [email protected] 3 Telekom Austria AG Lassallestraße 9 A-1020, Vienna, Austria {mark.banfield,helmut.leopold}@telekom.at

Abstract. Resilience is arguably the most important property of a networked system, one of the three quality of service (QoS) characteristics along with security and performance. Now that computer networks are supporting many of the applications crucial to the success of the emerging Information Society – including business, health care, education, science, and government – it is particularly important to ensure that the underlying network infrastructure is resilient to events and attacks that will inevitably occur. Included in these challenges are flash crowd events, in which servers cannot cope with a very large onset of valid traffic, and denial of service attacks which aim to damage networked system with malicious traffic. In this paper, we outline the case for mechanisms to deal with such events and attacks, and we propose programmable networking techniques as the best way ahead, illustrated by a flash crowd example. Keywords: Resilience, Survivability, Disruption Tolerance, Programmable and Active Networking, Flash Crowd and Distributed Denial of Service (DDoS) Detection and Remediation, Quality of Service (QoS).

1

Introduction

Networks have become increasingly important in our daily lives, to the extent that we depend on them for much of what we do, and we are significantly disrupted when they cease to operate properly. Current networks in general, and

http://www.comp.lancs.ac.uk/resilinets


84

L. Xie et al.

the Internet in particular, do not provide the resilience that will be needed, especially when more critical applications depend on proper network operation. Resilience is the ability of the network to provide and maintain an acceptable level of service in the face of various challenges to normal operation. These challenges include natural faults of network components (fault-tolerance); failures due to mis-configuration or operational errors; large-scale natural disasters (e.g., hurricanes, earthquakes, ice storms, tsunami, floods); attacks against the network hardware, software, or protocol infrastructure (from recreational crackers, industrial espionage, terrorism, or warfare); unpredictably long delay paths either due to length (e.g., satellite) or as a result of episodic connectivity; weak, asymmetric, and episodic connectivity of wireless channels; and high mobility of nodes and subnetworks. Addressing these challenges are required for network survivability [22]. We define resilience as survivability plus the ability to tolerate unusual but legitimate traffic load. Note, that while attack detection is an important endeavour, it is in some sense futile, since a sufficiently sophisticated distributed denial of service (DDoS) attack is indistinguishable from legitimate traffic. Thus traffic anomaly detection that attempts to detect and resist DDoS attacks simply incrementally raises the bar over which attackers must pass. Since both cases adversely affect servers and cross traffic, as well as exhaust network resources, the goal is resilience regardless of whether or not an attack is occurring. Resilient networks aim to provide acceptable service to applications, including the ability for users and applications to access information when needed (e.g., Web browsing and sensor monitoring), maintenance of end-to-end communication association (e.g., a video- or teleconference), and operation of distributed processing and networked storage. Resilient network services must remain accessible whenever possible, degrade gracefully when necessary, ensure correctness of operation (even if performance is degraded), and rapidly and automatically recover from degradation. We believe that to realise resilient services it is necessary to have programmable networks – in particular, the ability of the network to dynamically adapt in response to learnt context information – providing the motivation for this need is the main contribution of this paper. In Section 2, we discuss in more detail the programmable networking features that are necessary for resilience and why they are necessary. We present in Section 3 an example resilient networking scenario – a flash crowd event, and show how programmable networking can be used to detect the onset of the ill-effects from such an event and how these effects can be mitigated. Recently, a number of important initiatives have emerged that aim to modify the Internet architecture, which could be used to realise resilient services; the rest of this section will present an overview of these initiatives. 1.1

Resilient Networking Initiatives

A knowledge plane (KP) [19] has been proposed to supplement the Internet architecture, which self-organises to discover and solves problems automatically. The principle is that a knowledge plane could reason based on collected infor-

Towards Resilient Networks Using Programmable Networking Technologies

85

mation from all levels of the protocol stack to optimise applications, diagnose and tolerate faults and attacks, and make the network reconfigurable. The KP would use cognitive AI to work on incomplete, inconsistent, or even misleading information, behave properly in the face of inconsistent high-level goals, and proactively work with new technologies and services. The KP can be considered a way of building resilient networks in the long-term future – the development of cognitive technology is still in its early stages and the KP highly depends on it. Furthermore, challenges need to be addressed in areas such as knowledge sharing (trust issues) and reasoning on vast amounts of information (scalability issues). Work in the area of autonomic computing has largely focused on developing selfconfiguring, self-managing, and self-healing networked server systems [15]. There are now initiatives that consider making communications systems autonomic (e.g., [18,17]). These communication systems aim to understand the context in which they operate, such as user requirements and network status, and then automatically adapt to meet service goals. Clearly, techniques for enabling autonomic communication systems are relevant for building resilient network services. The COPS (Checking, Observing, and Protecting Services) project [20] aims to protect networks with devices called iBoxes, which perform observation and action operations at the network edge. COPS proposes to extend checking into the protocol domain, so that iBox functionality would migrate into future generations of routers. An annotation layer resides between the IP and transport layers for network management, which will allow annotated traffic to be appropriately processed.

2

Programmable Networks

Resilient networks need to be engineered with emergent behaviour to resist challenges to normal operation, recognise when challenges and attacks occur to isolate their effects, ensure resilience in the face of dependence of other infrastructure such as the power grid, rapidly and autonomically recover to normal operation, and refine future behaviour to better resist, recognise, and recover. We believe that programmable networking technologies will be a key enabler of the emergent and autonomic behaviour necessary for resilience. The need for programmable networking technology [24,25,26] for building resilient networks stems from the nature of the challenges that will affect normal operation. These challenges will rapidly change over time and space. In other words, the moment in time when these challenges will threaten normal service operation will rapidly and arbitrarily differ, and over time new challenges will emerge, such as new application traffic loads, forms of DDoS attacks, deployment environments, and networking technologies. Furthermore, the affected organisational entities and network services will change in an unpredictable manner. These characteristics preclude the use of a set of prescribed solutions to resiliency and mandate the use of a dynamically extensible infrastructure that can be aware of its environment.

86

L. Xie et al.

The following subsections further catalogue and motivate the need for the programmable networking facilities that are required for resiliency. 2.1

Dynamic Extensibility and Self-organisation

Programmability allows the network to respond to challenges by dynamically altering its behaviour and re-programming itself. This key ability of networks to change means that nodes do not need to be hard-coded or pre-provisioned with all the algorithms that may be needed to detect and respond to the challenges to normal operation. In fact, attempting to pre-program the complete set of resilience solutions is a futile exercise because of the dynamic and adaptive nature of the challenges to normal operation, as discussed earlier. Furthermore, we believe the network must be able to alter its behaviour without the intervention of network operators, because of the increasingly short timescales at which traffic patterns change (e.g., flash crowd) and attacks spread. Thus, it is essential that the network must be self-monitoring, self-diagnosing, self-reorganising, and self-managing. In light of this, programmable networking devices must expose interfaces that allow their behaviour to be extended in a safe manner to appropriately privileged entities. Furthermore, a service that can be used to rapidly determine the most suitable programmable network locations to deploy resilience components must be available. For example, it should be possible for a resilient networking service to request the deployment of mitigation code in proximity to the source of a DDoS attack, even when the location of the source may be mobile. Approaches to this have been proposed in [28,29], but much further work is required. By introducing dynamic extensibility and self-organisation into the network, there is a risk of making the network unstable and potentially worsening the effect of any disruption to normal service provisioning. Furthermore, exposing interfaces that enable third-party services to understand and manipulate the operation of the network introduces a new entry-point for misuse. With this in mind, programmability and dynamic behaviour should be introduced carefully and exposed interfaces must be stealthy (i.e., not expose more functionality than strictly necessary). This is consistent with moderate active networking [16], in which the ability to inject and transport dynamic programming extensions is tightly controlled by the network service provider. Inter-providerAS relationships will have to be based on authentication and trust mechanisms. 2.2

Context Awareness

Understanding the characteristics of traffic and the topology in a resilient network is important. For example, when a DDoS attack occurs it is useful to learn the source addresses of the perpetrators so that remediation services can be invoked in appropriate network locations, including toward the source. In other words, it is important to understand the network context so that the correct remediation services can be invoked with the correct parameters. To understand network context it must be possible to inspect packets at line speed, as well as be aware of topology state and network signalling messages.


87

However, understanding network context is only one part of the picture. A resilient network should use context from a range of layers. Arguably, the deeper one can look into a packet at higher-layer protocol headers and data, the greater degree of information can be obtained, and more targeted any remediation service can be. Edge network devices are commercially available that are capable of application-level packet inspection at line speed (e.g., [13,14]). So that applications and services operating at different layers can understand one-another’s context and work in harmony, interfaces that enable cross-layer interaction are necessary. Without understanding context across a range of layers, actions taken at one layer may not be complimentary at another. While it is clear about the motivation for cross-layer interaction, and there has been work in the context of specific parameters and protocols, there is no fundamental understanding of how this should be undertaken and what the benefits (performance and functional improvements) and costs (complexity and stability) are. A basic understanding of the nature of cross-layer interaction, resulting control loops, and its effect on the network needs to be gained [23].

3

Programmable Flash Crowd Detection and Mitigation

As an example to demonstrate how programmable networks can be used to build resilient services, in this section we describe an approach to detecting and mitigating the effects of a flash crowd event. To detect the ill-effects of a flash crowd event (e.g., a reduction in server response rate), we employ a mechanism that uses application and network-level information at a programmable edge device to detect a mismatch in anticipated and actual response rates from a server. We also discuss a number of approaches to mitigating the effects of flash crowd events by using the extensible nature of programmable networks. 3.1

Flash Crowd Detection

A flash crowd event [1], is characterised by a dramatic increase in requests for a service over a relatively short period of time, e.g., the sharp increase in requests for content on the CNN website immediately after the 9/11 attacks of 2001 [2]. These events can lead to a degradation or complete loss of service. It is important to detect the onset of a flash crowd event so that techniques to mitigate its effect can be invoked before a loss of service occurs. A surge in service requests could cause a bottleneck to occur in the access network to the service provider, the systems providing the service, or both. In any case, one would expect to see a significant increase in request rate in a relatively short period of time and an associated levelling off or reduction in the response rate as the network queues or server resources become saturated with requests. This behaviour is what we aim to detect and use to trigger programmable mechanisms to protect the network. The mechanism we propose detects flash crowd events that are targeted at Web servers. It makes use of application-level information, but performs the

88

L. Xie et al.

detection at the network level, and executes on a programmable edge router attached to the network that is providing the service. The mechanism inspects the volume of response traffic from a server, and based upon a difference between the expected volume of response traffic and the actual traffic, suggests the presence of a flash crowd event. In other words, if there is less response traffic than expected, we deduce the effects of a flash crowd event are beginning. Proposals in [21] also compare estimated traffic volume to the actual volume to detect the onset of traffic volume anomalies. We use a similar idea, but do not aim to detect the presence of flash crowd events per se, but rather the onset of any ill-effects they cause. In [11], it is shown that Web traffic has selfsimilarity characteristics, in other words, the requested objects follow a powerlaw distribution. We use this fact and the content-size distribution of requested objects, learnt from sampling the content-length field in HTTP response headers, to estimate the volume of response traffic. Normally, the sum of the sizes of the requested objects would form the response traffic volume, as shown in Equation 1, where v is volume of response traffic, r is the number of requests, and Sı is the size of the object associated with a request rı . We maintain the average incoming HTTP request rate for a server and use this along with the learnt content-size distribution to estimate the volume of response traffic expected. Equation 2 shows how we calculate the Exponentially Weighted Moving Average (EWMA) incoming request rate (f ), where c is the request rate at a given point in time. Equation 3 describes how we use the integer value of this average (f ) to calculate the expected volume of response traffic (e) at time t, where Gı is the estimated content-size for a request fı . By selecting an appropriate values for α, we aim to obtain a close estimate of the response traffic volume. v=

r

Sı

(1)

ı=1

f (t) = (1 − α) × f (t − 1) + α × c(t),

with

α>0

(2)

f (t)

e(t) =

Gı

(3)

ı=1

a(t) | t = 1 . . . n} ∼ N (μ, σ2 ) (4) e(t) The ratio of the observed response traffic volume (a) to the estimated traffic volume (e) should follow a normal distribution: N (μ, σ2 ), see Equation 4. The value of μ should be slightly greater than one, because we did not include the TCP/IP header size in our calculations. We use the EWMA of the ratio to smooth fluctuations caused by inaccuracies in the guessing mechanism. In Section 3.2, we show how we test the ratio distribution and calculate the parameter for the distribution and gain confidence (95% in this case), from which we can ascertain if the effects of a flash crowd are occurring. If continuous points are observed to be beyond the confidence range, it suggests the occurrence of abnormality. {


3.2

89

Simulation of Flash Crowd Mechanism

To give an indication of the effectiveness of the flash crowd detection mechanism, we simulated such an event using ns-2. HTTP traffic was generated using the PagePool/WebTraf application in ns-2. Parameters used for generating HTTP sessions follow the distributions presented in [9]. The request rate for background traffic was modified to be approximately 150 requests/sec and flash traffic to 1200 requests/sec. The request rate of flash traffic was set to be almost eight times greater than that of background traffic, which is modest for a flash crowd event as the hit-rate for CNN just after 9/11 was twenty times its normal rate [2]. The parameters used for the background and flash traffic are shown in Table 1. Table 1. Simulation parameters Traffic Type Number of Sessions

Background

1000

Flash Crowd

20000

Inter- Number Inter- Number Inter- Object session of Pages page of object Size [KB] Time [s] per Time [s] Objects Time [s] Session per Page 1 15 1 10 0.01 Avg:12 Shape: 1.2 0.025 10 1 10 0.01 Avg:12 Shape: 1.2

The simulations ran for 1200 seconds; flash traffic started at 500 seconds. We used a simple network topology, this included twenty clients, an ingress edge router, an egress edge router, and a server. The bandwidth of the links between the clients and the ingress router were set to 10 Mb/sec, the two routers were connected by a 50 Mb/sec link, and the egress router was connected to the server by a 15 Mb/sec link. A detection interval (how often we checked the ratio of actual (t) to expected (e) response traffic volumes) was set to 30 seconds and the α value was set to 0.2. The simulation with the same configuration was run three times and the mean values were used for generating the graphs. The onset of the flash crowd event can be seen at 500 seconds into the simulation in Figure 1. At 1020 seconds, the request rate starts to drop due to the sessions running out. Figure 2 shows how the normal response rate is around 1.6 Mb/sec and during the flash crowd event it reaches and stabilises at 1.8 Mb/sec. The stabilisation of the response rate is caused by the buffers on the server’s ingress link becoming saturated and subsequently dropping incoming requests. To gain an estimate of μ and σ for the normal distribution of the ratio, we ran ten thousand background traffic sessions using the parameters shown in Table 1. The value of μ was set to the average of the samples: 1.10817, and σ to the standard deviation of the samples: 0.227477. Figure 3 shows that the sample distribution appears close to the normal distribution of N (μ, σ2 ). The 95% confidence range of this distribution is [0.662315, 1.554025], which means that the possibility of the ratio value going beyond this range is 5%. We use more

90

L. Xie et al.

Fig. 1. Request rate during a flash crowd event starting at 500 seconds

Fig. 2. Response traffic rate during a flash crowd event starting at 500 seconds

than two continuous values outside the confidence range to detect the saturation of the server side. Figure 4 shows that the ratio drops shortly after the onset of the flash crowd event and subsequently oscillates around 0.2 with a small amplitude. Recall that two continuous ratio values outside the confidence range [0.662315, 1.554025] is used to diagnose that the effects of a flash crowd are being felt. Given this, with a detection interval of 30 seconds, saturation can be confirmed at 570 seconds. 3.3

Flash Crowd Mitigation Mechanism

To protect a Web server and the cross traffic in the network, we propose two strategies. The first is to drop requests that the server side is not able to manage at the ingress points of a provider’s network. The ingress points are discovered by routers that perform a pushback mechanism, the basic concept and mechanism of which are presented in [7][8]. In summary, with a slight variation, our mechanism is invoked on the server’s edge router which identifies the incoming interfaces


91

Fig. 3. The distribution of sampled ratios in normal situation

Fig. 4. Ratio of actual response traffic amount over estimated traffic

of aggregates of high volume of requests to the server. The router then sends messages to the immediate upstream routers (from which the high aggregate request volumes came from) to recursively carry out this procedure and push back requests until the provider’s ingress router is reached. The second strategy is to re-route response traffic inside the network to improve the traffic distribution and reduce the possibility of links becoming congested. The reason for the first action is straightforward – to push request traffic that cannot be served outside of the network to save network resources. The reason for the other action and the mechanisms to do it are described below. According to [12], an important metric for measuring how well traffic is distributed in a network is maximum utilisation. Larger maximum utilisation values indicate that links are more sensitive to bursts. Large amounts of flash crowd traffic would cause heavily skewed distribution in the network, which could reduce the quality of service for cross traffic. To have a better distribution we need

92

L. Xie et al.

to reduce the maximum utilisation. These strategies are the subject of future work, as discussed in Section 4. 3.4

Related Flash Crowd Detection and Mitigation Work

The implications of flash crowd events and DoS attacks for Web sites and content distribution networks (CDNs) are discussed in [3]. They propose enhancements to CDNs that make them more adaptive and subsequently better at mitigating the effects of flash crowd events. Collaborative caching mechanisms that can be used to redirect requests to appropriate caches in light of a flash crowd event are proposed in [4]. The challenge here is to make sure that the appropriate content is cached – this may be difficult to predict. The authors of [5] describe a mechanism that breaks content up into small pieces and returns each request a piece. Clients need to talk to each other for other pieces of the content. This mechanism requires servers to perform the content manipulation, and requires modifications to Web browser applications and HTTP protocol. In [6] the problems associated with flash crowds are addressed by making changes to the architecture of Web servers – approaches that allow dynamic resource allocation across multiple servers are proposed. We address the flash crowd problem from the point of a network service provider (and potentially also a third-party application service provider), and make no assumption about the Web server architecture in use. An approach to dropping requests at the server’s ingress point to a network is proposed in [9]. The rate at which requests are dropped is set dynamically. A major drawback of this approach is that it requires the inspection of application layer headers of each packet. We have shown here that you can do detection at the network level while only sampling the application layer headers occasionally.

4

Future Work

Because our flash crowd detection mechanism uses hints to determine the onset of the ill-effects of a flash crowd event – it guesses the expected volume of response traffic – there is a possibility it could give false positives. Further investigation is necessary to determine under what conditions this could occur and what effects a false positive may have. In our simulations, we set the detection interval to 30 seconds; investigating whether we could effectively reduce this interval to enable faster detection is something we plan to investigate through further simulation. As part of future work into mitigating the effects of flash crowd events, we propose to improve the distribution of response traffic by instigating multi-path routing for traffic that is tolerant to packet mis-ordering. A way to approach this is by a server’s edge router building a multi-route database, in which all possible routes between the server’s edge router to all the other edge routers along with the available bandwidths are held. The database is built by deploying active


93

code to collect routing information and available bandwidth information from programmable routers. When the server’s edge router observes or is informed that the response traffic is consuming too much bandwidth on one of the links, it could distribute the traffic over a number of routes. An approach such as this removes the need to change existing routing protocols, as in [12], which manipulates the link weights in the OSPF routing database. Investigating aspects of resilience in the context of computer networks is an emerging research topic. In the recently funded Autonomic Networking Architecture (ANA) EU research project [18], we will investigate the the use of resilience techniques and mechanisms to support autonomic networks.

5

Conclusions

In this paper, we have presented work in progress in the important area of the resilience of networked systems. In addition to presenting the basic argument that resilience is really needed in the modern networked world, we argue for programmable networking techniques as an appropriate way ahead to build resilience mechanisms. By means of a modest flash crowd example, we outline simulation results that aim to show the promise of programmable networking in this crucial area. Furthermore, the mechanism demonstrates that multi-layer cooperation is a useful tool to enable resilient networks. The simulation results indicate that our detection mechanism for flash crowd events has potential. Future work will focus on the mitigation of flash crowd events and also DDoS detection and repair. By focusing on a particular application scenario we aim to develop and prove a resilient network architecture that uses programmable networking technologies.

Acknowledgements Linlin Xie and Paul Smith are supported by Telekom Austria. We are grateful to Steven Simpson for his help and contributions with the simulations. We also appreciate the comments from the anonymous reviewers.

References 1. Niven, L.: Flash Crowd. In: Flight of the Horse. Ballantine Books (September 1973) 2. LeFebvre, W.: CNN.com: Facing A World Crisis (2001), http://www.tcsa.org/lisa2001/cnn.txt2001 3. Jung, J., Krishnamurthy, B., Rabinovich, M.: Flash Crowds and Denial of Service Attacks: Characterization and Implications for CDNs and Web Sites. In: Proceedings of The Eleventh International ACM World Wide Web Conference (ACM WWW 2002), Hawaii, USA (May 2002) 4. Stading, T., Maniatis, P., Baker, M.: Peer-to-peer caching schemes to address flash crowds. In: Druschel, P., Kaashoek, M.F., Rowstron, A. (eds.) IPTPS 2002. LNCS, vol. 2429, p. 203. Springer, Heidelberg (2002)

94

L. Xie et al.

5. Patel, J.A., Gupta, I.: Overhaul: Extending HTTP to Combat Flash Crowds. In: Proceedings of the 9th International Workshop on Web Caching and Content Distribution (WCW 2004), Beijing, China (October 2004) 6. Chandra, A., Shenoy, P.: Effectiveness of Dynamic Resource Allocation for Handling Internet Flash Crowds, University of Massachusetts Technical Report, TR0337 (2003) 7. Mahajan, R., Bellovin, S.M., Floyd, S., Ioannidis, J., Paxson, V., Shenker, S.: Controlling High Bandwidth Aggregates in the Network. In: ACM SIGCOMM Computer Communication Review, vol. 32(3), pp. 62–73 (July 2002) 8. Ioannidis, J., Bellovin, S.M.: Implementing Pushback: Router-Based Defense Against DDoS Attacks, AT&T Technical Report (December 2001) 9. Chen, X., Heidemann, J.: Flash Crowd Mitigation via Adaptive Admission Control Based on Application-Level Observation, USC/ISI Technical Report, ISI-TR2002 557 (revised version) (March 2003) 10. Mirkovic, J., Reiher, P.: A Taxonomy of DDoS Attack and DDoS Defense Mechanisms. In: ACM SIGCOMM Computer Communications Review, vol. 34(2), pp. 39–53 (April 2004) 11. Crovella, M.E., Bestavros, A.: Self-Similarity in World Wide Web Traffic: Evidence and Possible Causes. IEEE/ACM Transactions on Networking 5(6), 835–846 (1997) 12. Fortz, B., Thorup, M.: Internet Traffic Engineering by Optimizing OSPF Weights. In: Proceedings of the 19th Conference on Computer Communications (INFOCOM 2000), Tel-Aviv, Israel (March 2000) 13. Bivio Networks, http://www.bivio.net/ 14. IBM BladeCenter, http://www-03.ibm.com/servers/eserver/bladecenter/ 15. IBM Autonomic Computing, White Paper: An architectural blueprint for autonomic computing, 3rd edn. (June 2005), http://www-03.ibm.com/autonomic/ pdfs/AC%20Blueprint%20White%20Paper%20V7.pdf 16. Jackson, A.W., Sterbenz, J.P.G., Condell, M.N., Hain, R.R.: Active Network Monitoring and Control: The SENCOMM Architecture and Implementation. In: 2002 DARPA Active Networks Conference and Exposition (DANCE 2002), p. 379 (2002) 17. The Autonomic Communications Forum, http://www.autonomic-communication-forum.org/ 18. The Autonomic Networking Architecture (ANA) research consortium, http://www.ana-project.org/ 19. Clark, D., Partridge, C., Ramming, J., Wroclawksi, J.: A Knowledge Plane for the Internet. In: Proceedings of the Annual Conference of the ACM Special Interest Group on Data Communication (SIGCOMM 2003), Karlsruhe, Germany (August 2003) 20. Katz, R., Porter, G., Shenker, S., Stoica, I., Tsai, M.: COPS: Quality of service vs. Any service at all. In: de Meer, H., Bhatti, N. (eds.) IWQoS 2005. LNCS, vol. 3552, pp. 3–15. Springer, Heidelberg (2005) 21. Lakhina, A., Crovella, M., Diot, C.: Diagnosing Network-wide Traffic anomalies. In: Proceedings of the Annual Conference of the ACM Special Interest Group on Data Communication (SIGCOMM 2004), Portland, Oregon, USA (August 2004) 22. Sterbenz, J.P.G., Krishnan, R., Hain, R.R., Jackson, A.W., Levin, D., Ramanathan, R., Zao, J.: Survivable Mobile Wireless Networks: Issues, Challenges, and Research Directions. In: Proceedings of the ACM Wireless Security Workshop (WiSE) 2002 at MobiCom, Atlanta, GA, September 2002, pp. 31–40 (2002) 23. Sterbenz, J.P.G., Hutchison, D.: Towards a Framework for Cross-Layer Optimisation in Support of Survivable and Resilient Autonomic Networking, Dagstuhl Seminar 06011 (January 2006)


95

24. Calvert, K., Bhatacharjee, S., Zegura, E., Sterbenz, J.P.G.: Directions in Active Networks. IEEE Communications 36(10), 72–78 (1998) 25. Tennenhouse, D.L., Wetherall, D.J.: Towards an Active Network Architecture. ACM Computer Communication Review 26(2), 5–17 (1996) 26. Tennenhouse, D.L., Smith, J.M., Sincoskie, W.D., Wetherall, D.J., Minden, G.J.: A Survey of Active Network Research. IEEE Communications Magazine 35(1), 80–86 (1997) 27. Schmid, S.: A Component-based Active Router Architecture, PhD Thesis, Lancaster University (November 2002) 28. Smith, P.: Programmable Service Deployment with Peer-to-Peer Networks, PhD Thesis, Lancaster University (September 2003) 29. Spence, D., Crowcroft, J., Hand, S., Harris, T.: Location Based Placement of Whole Distributed Systems. In: Proceedings of ACM Conference on Emerging Network Experiment and Technology (CoNEXT 2005), Toulouse, France, pp. 124–134 (October 2005)

Towards the Design of an Industrial Autonomic Network Node Martine Chaudier, Jean-Patrick Gelas, and Laurent Lefèvre INRIA/LIP (UMR CNRS, INRIA, ENS, UCB 5668) École Normale Supérieure de Lyon 46 allée d’Italie, 69364 Lyon Cedex 07, France [email protected], [email protected], [email protected]

Abstract. Programmable and active networks allow specified classes of users to deploy dynamic network services adapted to data streams requirements. Currently most of researches performed on active networks are conducted in research laboratories. In this paper, we explore the design of IAN 2 an Industrial Autonomic Network Node able to be deployed in industrial context. Performance, dynamic programmability and fault-tolerance issues of software and hardware components have been prospected. First experimental evaluations on local platforms are presented.1

1

Introduction

Research works about active and programmable networks and evaluation of the experimental prototypes take place mostly in academical research laboratory. Currently no “plug and process” active equipments are available on the market place. In the framework of a cooperative industrial maintenance and monitoring project (TEMIC project[3]), in which we are currently involved with different academic and industrial partners, we design devices to be easily and efficiently deployable in an industrial context. Once the hardware deployed and used, it must also be easily removable at the end of the maintenance or monitoring contract. In this project, we deploy our devices in secured industrial departments, restricted areas, or in an out-of-the-way locations. These devices must act as auto-configurable and re-programmable network nodes. Thus, the equipments must be autonomic and must not require direct human intervention. The design of an autonomic network equipment must take into account specific requirements of active equipments in terms of dynamic service deployment, auto settings, self configuration, monitoring but also in terms of hardware specification 1

This project is supported by french RNRT Temic [3] project with SWI Company, INRIA, GRTC and LIFC.


Towards the Design of an Industrial Autonomic Network Node

97

(limited resources, limited mechanical parts constraints, dimension constraints), reliability and fault tolerance. This paper presents our current work on the design and adaptation of an industrial autonomic network node. We propose an adaptation of a generic high performance active network environment (Tamanoir [8]) in order to deploy on limited resources based network boxes and to increase reliability and scalability. The implementation process is based on a hardware solution provided by the Bearstech[2] company. Through this approach we propose the architecture of an Industrial Autonomic Network Node (called IAN 2 ) able to be deployed in industrial platforms. We evaluate the capabilities of IAN 2 in terms of computing and networking resources and dynamic re-programmability. This paper is organized as follows. Hardware and software are respectively described in section 2 and 3. Section 4 shows first performance evaluation of the IAN 2 . Section 5 briefly covers others works on industrial active nodes and finally the paper concludes in section 6.

2

Hardware Platform

This section describes briefly the hardware used to implement the IAN 2 industrial autonomic network node. To support a transportable solution, we use a small compact aluminium case which hosts a small motherboard (200x150 mm) featuring a VIA C3 CPU 1GHz (supporting the x86 instruction set), 256MB DDR RAM, 3 Giga Ethernet LAN port, 2 PCMCIA slot, 4 USB port and one serial port. To reduce risk of failure, we choose a fan less hardware solution. Moreover, the box does not embed a mechanical hard disk drive. The operating system, file system and execution environment are stored in a memory card (e.g Compact Flash). Figure 1 shows, on the left, an inside view of the case where we can see the small mother board and its large passive cooling system (white part) hiding

Fig. 1. Internal and connections views of the industrial autonomic network node

98

M. Chaudier, J.-P. Gelas, and L. Lefèvre

chipset and CPU. A second picture shows a backside view of the case with all connectors.

3 3.1

Software Execution Environment Operating System

The industrial autonomic network node environment runs over Btux provided by the Bearstech[2] company. Btux is based on a GNU/Linux operating system running a 2.6.12 kernel version. However the whole system has been rebuilt from scratch and designed for embedding systems (small memory footprint, selected command set available). The operating system respects standards and is remotely upgradeable to easily apply patches and updates without human intervention. For the IAN 2 node, we worked in tight collaboration with the Bearstech engineers to add a secured network wireless connection and multimedia sensors (audio and video) support. We also use information returned by internal sensors (i.e temperature) in order to take intelligent decision and do not expose our hardware to critical situation (e.g over heating). 3.2

Programmable Dynamic Environment

This section describes the software used on top of the operating system node (described above). This software is called an Execution Environment (EE) which is used to dynamically plug-in and run Active Applications (AA) also called active services. A service is deployed on demand and applied on one or several data streams. Services can run in parallel and are all executed in the EE. IAN 2 software architecture. We propose the IAN 2 Industrial Autonomic Network Node architecture (Fig. 2). This node supports switching and routing

Network Services Sandbox for deploying network services

Storage facilities

Switching and routing protocols

Fig. 2. IAN2: Industrial Autonomic Network Node


99

protocols through wire and wireless connection hardware. The limited CPU facilities are open to dynamically deploy autonomic services. Some limited storage capabilities are available to support heterogeneous classes of services. Our Execution Environment called T amanoirembedded is based on the Tamanoir [7,8] software suite written by L. Lefèvre and J.P. Gelas (from INRIA, France). The Tamanoir suite is a high-performance execution environment for active networks designed to be deployed in either local area networks or wide area networks. It is a prototype software with features too complex for an industrial purpose (clusterbased approach, Linux modules, multi-level services[11]. . . ). Due to some typical industrial constraints (e.g code maintenance), we reduce the code complexity and remove all unused classes and methods or actually useless for the Temic [3] project. It allows us to reduce the overall size of the software suite and make the maintenance and improvement of the code easier for service developers (Figure 3).

Cluster : Distributed CPU and storage JAVA / Execution Environment OS / Kernel Programmable Modules

JAVA / Execution Environment OS

NIC (Programmable)

Fig. 3. From a generic Active Network environment (Tamanoir) to an Industrial Autonomic Environment (T amanoir embedded )

T amanoirembedded is a dedicated software platform fully written in Java and suitable for heterogeneous services. Tamanoir provides various methods for dynamic service deployment. First method allows services to be downloaded from a service repository to a Tamanoir Active Node (TAN). Second method allows a TAN to request the service from the previous active node crossed by the active data stream (Figure 4). Autonomic Service Deployment

Autonomic Service Deployment

Fig. 4. Autonomic Service Deployment on wire connections

100


T amanoirembedded also supports autonomic deployment and services updating through mobile equipments (Figure 5). Inside automatic maintenance projects, we deploy wireless based IAN 2 nodes in remote industrial environments (no wire connections available). In order to download maintenance information, human agents can come near IAN 2 nodes to request informations. During this step, mobile equipments (PDA, Tablets, cellulars) are also used as mobile repositories to push new services and software inside autonomic nodes (Figure 5).

Autonomic Service Deployment

Multimedia streams

Fig. 5. Autonomic Service Deployment through mobile nodes

4

Experimental Evaluation

In this section, we present first evaluations of the industrial autonomic network node. Experimental results are divided into three categories. First, we present results in terms of network performances (wire and wireless networks). Then, we explore some preliminary results obtained with the software of the autonomic execution environment of the IAN 2 . And last, we present experimental results obtained in a multimedia industrial context. 4.1

Network Performances

We evaluate the performances of IAN 2 concerning wire and wireless network interfaces. We used the iperf[1] tool for measuring TCP bandwidth performances. Iperf can report bandwidth, delay jitter and datagram loss. We experiment network performances within two topologies (Figure 6).

Streams exchange

Streams generation

Streams generation

Forwarding IAN2

Fig. 6. back-2-back and gateway experimental local platforms


101

We call back-2-back topology when one IAN 2 is connected straight to another IAN 2 through a short (50 cm) Ethernet cable (cat 6) (Figure 6). We call gateway topology when we connect two IAN 2 through a third one. In this case we allow IP forwarding on the node in the middle. We set the TCP no delay IPerf option which disables Nagle algorithm but we didn’t noticed any significant difference. Table 1 shows bandwidth results and corresponding CPU usage under the two different topologies. We observe that back-2-back IAN 2 nodes failed to obtain a full Gbit bandwidth with TCP streams. When a third node is involved as a gateway, throughput is also more impacted. These results come mainly from the limited CPU embedded in the IAN 2 which limits the capabilities of sending large streams of data. Table 1. Raw performances shown by iperf with default values of buffer length and TCP window size Configuration. back-2-back gateway (1 stream) gateway (8 streams)

Throughput cpu send cpu recv cpu gateway 488 Mbps 90% 95% N/A 195 Mbps 29% 28% 50% 278 Mbps 99% 65% 70%

For the next experience, we use one industrial autonomic network node (IAN 2 1) to transmit two streams to another industrial autonomic network node (IAN 2 2), using only one Giga Ethernet link. We obtain 312 Mbps and 229 Mbps (total 541 Mbps) and each CPU was used to the maximum (2x50% on transmitter and receiver). We also try the full-duplex feature of our card by sending one stream from IAN 2 1 to IAN 2 2 and vice-et-versa (bidirectional connection). We obtain 196 Mbps and 247 Mbps (total 443 Mbps). About 2x50 % of CPU was used on each CPU (i.e transmitter and receiver). We notice that there are as many iperf processes running as data streams on the link, and each process shares with equity the CPU load. The figure 7 shows throughput performance reduction in function of number of streams on a back-to-back connection topology.

Throughput (Mbps)

500

Wired throughput

400 300 200 100 0 1

5

10

20 Number of streams

40

Fig. 7. Throughput performance reduction when number of stream increases between two IAN 2 connected back-to-back

102


We also did some tests with a PCMCIA wireless card (using the Orinoco Linux modules) plugged in the IAN 2 (802.11b). Best obtained throughput, when the IAN 2 is 10 meters far from the wireless Access Point was only 4.45 Mbps (without external antenna). The figure 8 shows throughput performance reduction in function of number of streams in a wireless context. We also did some bidirectional tests and surprisingly we obtain an average throughput equal to the maximum speed. Finally, we try to remove the TCP no delay option (Nagle) and obtain a slightly lower performance (3.92 Mbps). These experiments show that IAN 2 nodes must be dedicated to some specific platforms (wireless environments, xDSL, Fast Ethernet). This can be compatible with some current industrial deployments.

Throughput (Mbps)

5

Wireless throughput

4 3 2 1 0 1

5

10

20

40

Number of streams

Fig. 8. Throughput performance reduction when number of stream increases in a wireless context

4.2

Evaluating Autonomic Performances

We present some results obtained with the T amanoirembedded Execution Environment. We ran two different active services : a lightweight service (in terms of CPU usage), called MarkS, used to count and mark the packets crossing the Tamanoir node. And a heavyweight service (in terms of CPU usage), called GzipS which compresses packets payload on-the-fly using the Lempel-Ziv coding (LZ77). The Execution Environment and services run in a SUN JVM 1.4.2. Table 2 shows performance results with different payload size for both services. Table 2. Throughput (Mbps) of Tamanoir applying a lightweight service (MarkS) and a CPU consuming service (GzipS) 4kB 16kB 32kB 56kB MarkS 96 144 112 80 GzipS 9.8 14.5 15.9 16.6


103

We compare obtained results with high performance active network node platform (embedded in a Compaq DL360 (G2) Proliant, dual-PIII, 1.4GHz, 66MHz PCI bus). We used different network interfaces (Fast, Giga Ethernet) and protocols (UDP / TCP).

100

500

1 stream/TCP/Fast/P3 1 stream/TCP/Giga/P3 1 stream/TCP/IAN2

1 stream/Fast/P3 1 streams/Giga/P3 1 stream/IAN2

80

400

Mbps

Mbps

60

300

40

200

20

100

0 128B

0

1k 4k payload size (Bytes)

8k

32k

1k

4k

8k

16k

32k

payload size (Bytes)

Fig. 9. Throughput comparisons of a Fig. 10. Throughput comparisons of a lightweight service heavy service

The IAN 2 based on a reliable fan-less no disk node with a lightweight Execution Environment, shows comparable results with a slow desktop machine with a slow hard disk drive. We can see the limit of IAN 2 CPU with the GzipS service (CPU is 100% used for a bandwidth of 16 Mbps). For a lightweight service, like the MarkS service, we observe a combined limitation of the CPU and the IAN2 network interfaces cards. The major point of deception is about the network interfaces announced to support 1 Gbps and which sustain with difficulty only half of the bandwidth. Moreover, we can observe that due the modification of the Tamanoir high performance Execution Environment, the autonomic node does not benefit from some improvements (lightweight Linux modules, efficient JVM. . . ). Thus all data packets are processed inside the Java Virtual Machine. But the industrial deployment on an industrial autonomic network node can still benefit from this trade off between performances and reliability. 4.3

Performances of the IAN 2 Node within Multimedia Context Application

In our architecture, the industrial autonomic node is the point where all active services are performed, so it is a critical point. To evaluate its performances, we measure the processor load during the adapting and the transmitting of a video file (Fig 3). Results show that the CPU of the IAN 2 (VIA C3 1 GHz) is intensively used during video adapting. There is no enhancement even when the video size decreases. In table 3, the transmission with the MJPEG format is performed by the same active service, but with no adapting step. In this case, we observe

104

M. Chaudier, J.-P. Gelas, and L. Lefèvre Table 3. CPU load on the IAN 2 when adapting and transmitting a video file Format / Size Usr CPU load MJPEG / 720x480 1 different flows, a reduction in the interleaver packet delay can be potentially achieved. In this work, we will assume that all the flows have the same period tf . To fill the interleaver matrices, each flow will maintain the relative order with respect to the others. In addition, for a given flow each row will be written from left to right according to the packet sequence number. Let (f 1 , f 2 , . . . , f nf ) be the nf available audio flows, and let s be the maximum expected burst length. To simplify, let us additionally define Rji , with i = {1, . . . , nf } and {j = 1, . . . , nm }, as the number of consecutive rows that the flow f i will be assigned for filling the interleaver matrix j, being nm the number of matrices. Depending on nf and s, we will consider two different cases. 1. Whenever nf ≥ s, the interleaver will be based on just one (nf × 1) matrix (nm = 1), in which R1i = 1, ∀i = {1, . . . , nf }. For this case, the interleaver n nf 1 2 output will be given by . . ., fi1 , fj2 , . . ., fk f , fi+1 , fj+1 , . . ., fk+1 , . . ., where the subscripts i, j, . . ., k denote the sequence number for flows f 1 , f 2 , . . ., f nf . We refer to this interleaver as Type II (nf ). 2. If nf < s, we will refer to this interleaver as Type II (nf , s). Under this condition, two different cases will be considered. – If s = (nf · i), i ∈ IN ⇒ nm = 1. That is, only one interleaver (s × s) matrix will be used; – Otherwise, nm = nf square (s × s) matrices will be required. Going ahead, if we denote rem(x, y) as the remainder of the integer division x/y, the writing matrices algorithm will be as follows:

202

´ J.J. Ramos-Mu˜ noz, A.M. G´ omez, and J.M. Lopez-Soler

, for i = {1, 2, . . . , (nf − rem(s, nf ))}. Similarly, we will set R1j = nsf + 1, for j = {(nf − rem(s, nf ) + 1), . . . , (nf − 1), nf }. – If applicable, for the next j = {2, . . . , nf } additional matrices, and for – For the first matrix, we will set R1i =

i i = {2, . . . , nf } flows, if R(j−1) = ( nsf (i−1) Rji = nsf and Rj = ( nsf + 1).

s nf

(i−1)

+ 1) and R(j−1) =

s nf

then

As it can be checked, any burst of length less or equal to s will be scattered at the de-interleaver output. In this case, if we define r = rem(s, nf ) and d = (s−r)/nf , Dmax , the maximum delay will obey the following expressions - If r ≤ (nf − r) ⇒ Dmax = s · (r · (d + 1) − 1 − (r − 1) · d). - If r > (nf − r) ⇒ Dmax = s · (r · (d + 1) − 1 − ((r − 1) · d + 2 · r − nf − 1)) For a given s, the lower maximum delay that we can obtain is achieved when nf = (s−1), and when s/nf = 2 and r = 0. This delay corresponds to Dmax = s. Therefore, the maximum tolerated s, given a flow with a maximum per packet time to live dmax and a period of tf must satisfy that s < dmax tf . For the provided numerical example, in which tf = 20 ms and dmax = 300 ms, it yields that s < 15, what is significantly less demanding compared to the upper bound of s < 5 for the Type I (s) end-to-end interleaver. The period of the proposed Type 2 II (nf , s) interleaver is equal to ns f , if s ≡ 0 (mod nf ), and s2 in the other case.

3

Quality and Intelligibility Evaluation

To evaluate our VoIP interleavers we plan to use a high level criterion. In noise free conditions, Automatic Speech Recognition (ASR) rate is highly correlated to human intelligibility [7]. Based on that, we propose to use this score as the performance measure. We feel that this methodology should be definitively considered to evaluate any VoIP service enhancement. Compared to MOS subjective tests, ASR has lower cost and is more reproducible. In addition, in terms of the intelligibility perceived by the user, ASR rate can be more suitable than other quality measures like PESQ (ITU-T recommendation P.862) or the E-model [8]. Speech recognizer’s performance is measured in terms of the Word Error-Rate (WER), defined by: ni + n s + n d W ER = × 100 (1) nt where ns is the number of substituted words, ni is the number of spurious words inserted, nd is the number of deleted words and, nt is the overall number of words. Prior to the count of substitution, deletion and insertion errors, dynamic programming is used to align the recognized sentence with its correct transcription.

Intelligibility Evaluation of a VoIP Multi-flow Block Interleaver

4

203

Experimental Results

Experimental results are provided by means of simulation. A simple scenario is set. nf periodic flows arrive into the active router with period equal to tf = 20 ms. For the Type I (s) case, just one flow (nf = 1) is considered. Ideally, we assume no switching or any other routing delay. 1

Cumulative probability

0.95

0.9

0.85

0.8

0.75

0.7

0.65

Generated losses Type I(10) (Dmax=1.80 s) Type II(5) (Dmax=0.00 s) Type II(5,10) (Dmax=0.20 s)

0.6

0.55 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Burst length Fig. 1. Bursts length CDF

We adopt a single error model. It is based on a Markov chain trained with collected traces described in [9]. The bursts length CDF of the trace obtained from the trained model is shown in Fig. 1. The overall probability of loss is 8.2%. In the same figure, as an illustrative example (nf = 5 and s = 10), we plot the bursts length CDFs obtained by using the simulated interleavers. Note that T ypeI(10) is not practically applicable, T ypeII(5) although does not introduce extra delay, it has less scattering capabilities and, finally, T ypeII(5, 10) exhibits a balance between the introduced delay and the loss isolation capacity. To enhance the quality of the received flow, before ASR evaluation, whenever a loss packet is detected, the previous received packet will be artificially repeated. For ASR evaluation we use the connected digit Project Aurora 2 database [10]. After transmission, in order to reduce its inherent variability the speech signal is processed. A feature extractor segments the received speech signal in overlapped frames of 25 ms every 10 ms. Each speech frame is represented by a feature vector containing 13 Mel Frequency Cepstrum Coefficients and the log-Energy. Finally, the feature vectors are extended with their first and second derivatives. The speech recognizer is based on Hidden Markov Models (HMM). We use eleven 16-state continuous HMM word models, (plus silence and pause, that have 3 and 1 states, respectively), with 3 gaussians per state (except silence, with 6

204

´ J.J. Ramos-Mu˜ noz, A.M. G´ omez, and J.M. Lopez-Soler

gaussians per state). The HMM models are trained from a set of 8440 noise-free sentences, while the out-of-train-test set comprises 4004 noise-free sentences. In Table 1, WER and Dmax values are summarized for T ypeI(s), T ypeII(nf ) and T ypeII(nf , s) interleavers with different nf and s. For a given nf , the s value was chosen such as Dmax , expressed in seconds, would be lower than 0.300 for T ypeII(nf , s) interleaver. Note that for T ypeII(nf ), Dmax is not shown because its theoretic delay is equal to 0. It can be observed that WER performance for T ypeII(nf ) interleaver strongly depends on nf . For nf = 2, T ypeII(nf , s) can reduce the T ypeII(nf ) WER without breaking the end-to-end constraint. However, as more nf will be available, the WER difference is less noticeable. Note that although T ypeI(s) outperforms both T ypeII interleavers it can be only used for s < 5, given the VoIP end-to-end delay constraint. Table 1. WER (%) and Dmax in seconds for the three simulated interleavers II(nf ) nf WER s 3 2 5.401 5 6 3 4.333 7 4 3.419 8 5 2.875 10

II(nf , s) WER Dmax 4.610 0.060 2.892 0.200 2.255 0.240 1.831 0.280 1.848 0.160 1.567 0.200

s 3 5 6 7 8 10

I(s) WER Dmax 3.080 0.120 1.595 0.400 1.540 0.600 1.307 0.840 1.289 1.120 1.325 1.800

nf 6 7 8 9 10 12

II(nf ) WER 2.420 1.968 1.819 1.613 1.611 1.534

s 12 14 9 10 11 13

II(nf , s) WER Dmax 1.449 0.240 1.381 0.280 1.626 0.180 1.526 0.200 1.533 0.220 1.455 0.260

s 12 14 9 10 11 13

I(s) WER Dmax 1.263 2.640 1.340 3.640 1.304 1.440 1.285 1.800 1.282 2.200 1.322 3.120

Additionally, note that the T ypeII(4, 8) maximum delay (160 ms) is lower than the T ypeII(3, 7) delay (280 ms), although the s value is greater. This is due to the peculiarity of the interleaver, which results in non linear delay dependence with the number of flows and the burst length considered. Summing up, both the Type II interleavers diminish the packet interleaving delay. Although Type II (nf ) is designed to work properly when nf ≥ s, it can be suited when nf ≈ s, without introducing any additional delay. Compared to Type II (nf ), the Type II (nf , s) interleaver improves the VoIP intelligibility. It scatters a high percentage of losses patterns, and reduces the maximum length of the bursts at the de-interleaver output. Furthermore, although T ypeII(nf , s) introduces some additional delay, it can be used under conditions that T ypeII(nf ) does not tolerate (long burst length and low number of different flows). On a separate note, given the processing capabilities of the active router, it could be always possible to select which interleaver algorithm to use (T ypeII(nf ) or T ypeII(nf , s)). In this case, the network dynamics and the number of available flows should be taken into account. As a rule of thumb, we would suggest the consideration of the T ypeII(nf ) interleaver instead of T ypeII(nf , s) whenever nf ≈ s.

Intelligibility Evaluation of a VoIP Multi-flow Block Interleaver

5

205

Conclusion

In this paper the block interleaving problem for audio applications is revisited. To increase the final audio quality we aim to scatter long bursts of packet losses. We propose a new VoIP interleaver algorithm which not only diminish the per packet delay, but also allows its use under conditions where end-to-end approaches are unfeasible. Our algorithm interleaves packets from different flows. To work properly, the interleaver must be placed in a common node before the path where losses are expected to occur. We show that the resulting speech intelligibility is maximized, especially when the number of available flows is small. In this work, because of its reproducibility and low cost, we have considered automatic speech recognition in order to assess the intelligibility improvements of the proposed VoIP active service. This procedure can be extended to evaluate any other VoIP enhancement. As future work, to establish a mapping function for human to machine recognition rate remains. Similarly, the mapping functions between recognition rate and MOS score should be studied as well. By using these mapping functions, enhanced VoIP active services can be envisaged.

References [1] Liang, Y.J., Farber, N., Girod, B.: Adaptive playout scheduling and loss concealment for voice communication over IP networks. IEEE Transactions on Multimedia 5(4), 532–543 (2003) [2] Towsley, D., Kurose, J., Pingali, S.: A comparison of sender-initiated and receiverinitiated reliable multicast protocols. IEEE Journal on Selected Areas in Communications 15(3), 398–406 (1997) [3] Tennenhouse, D.L., Smith, J.M., Sincoskie, W.D., Wetherall, D.J., Minden, G.J.: A survey of active network research. IEEE Communications Magazine 35(1), 80– 86 (1997) [4] Ott, D.E., Sparks, T., Mayer-Patel, K.: Aggregate Congestion Control for Distributed Multimedia Applications. In: IEEE INFOCOM 2004, vol. 1, pp. 13–23 (March 2004) [5] Ramos-Mu˜ noz, J.J., Lopez-Soler, J.M.: Low delay multiflow block interleavers for real-time audio streaming. In: Lorenz, P., Dini, P. (eds.) ICN 2005. LNCS, vol. 3420, pp. 909–916. Springer, Heidelberg (2005) [6] Kenneth Andrews, C.H., Kozen, D.: A theory of interleavers. Technical Report 97-1634, Computer Science Department, Cornell University (1997) [7] Jiang, W., Schulzrinne, H.: Speech recognition performance as an effective perceived quality predictor. In: Tenth IEEE International Workshop on Quality of Service, pp. 269–275 (May 2002) [8] Cole, R.G., Rosenbluth, J.H.: Voice Over IP Performance Monitoring. SIGCOMM Comput. Commun. Rev. 31(2), 9–24 (2001) [9] Yajnik, M., Kurose, J., Towsley, D.: Packet loss correlation in the MBone multicast network experimental measurements and markov chain models. Tech. Rep. UMCS-1995-115 (1995) [10] Hirsch, H.G., Pearce, D.: The AURORA Experimental Framework for the Performance Evaluations of Speech Recognition Systems under Noisy Condition. In: ISCA ITRW ASR 2000, France (2000)

A Web-Services Based Architecture for Dynamic-Service Deployment Christos Chrysoulas1, Evangelos Haleplidis1, Robert Haas2, Spyros Denazis1,3, and Odysseas Koufopavlou1 1 University of Patras, ECE Department, Patras, Greece {cchrys,ehalep,odysseas}@ee.upatras.gr 2 IBM Research, Zurich Research Laboratory, Rüschlikon, Switzerland [email protected] 3 Hitachi Sophia Antipolis Lab, France [email protected]

Abstract. Due to the increase in both heterogeneity and complexity in today’s networking systems, there arises a demand for an architecture for networkbased services, that gives flexibility and efficiency in the definition, deployment and execution of the services and at the same time, takes care of the adaptability and evolution of such services. In this paper we present an approach that applies a component model to GT4, a Web-service based Grid environment, which enables the provision of parallel applications as QoS-aware (Grid) services, whose performance characteristics may be dynamically negotiated between a client application and service providers. Our component model allows context dependencies to be explicitly expressed and dynamically managed with respect to the hosting environment, computational resources, as well as dependencies on other components. Our work can be seen as a first step towards a component-based programming-model for service–oriented infrastructures utilizing standard Web services technologies.

1 Introduction In the recent years, Web service technology has gained more and more importance in the area of Grid Computing. The Open Grid Service Architecture [1] has motivated Grid architects to build environments based on a service-oriented architecture utilizing Web-service technology. The evolution of the Globus Toolkit 4 [2] towards the Web Service Resource Framework [3] was the outcome of that effort. Grids are mostly built following a service-oriented architecture using Web-services technology which has not been designed to fit the idea of a component-based plugand-play client programming framework. Services are typically discovered dynamically, using technologies like the Monitoring and Discovery System (MDS) [4] in Globus Toolkit 4, rather than created, they further do not provide means to describe D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 206–211, 2009. © IFIP International Federation for Information Processing 2009

A Web-Services Based Architecture for Dynamic-Service Deployment

207

dependencies for example in other services running outside the Grid. Web-service technology provides a versatile messaging facility but lacks an extensive component model applicable to service composition. In this paper we present a component-based architecture in order to address the above issues. Our architecture is based not only on the Globus Toolkit 4 environment, a Grid architecture for the provision of parallel applications as Grid services over standard Web-service technology, but it also makes heavy use of a component-based architecture trying to solve the problem of creating new services and the dependencies in other services and components outside the architecture we present. Our proposed Dynamic Service-Deployment Architecture is developing as part of the FlexiNET [5] IST research project and particularly as a sub-module of the FlexiNET Wireless Access Node (FWAN) module. The remainder of the paper is organized as follows: Section 2 describes what FlexiNET is. Section 3 describes the architecture regarding the Dynamic ServiceDeployment. A discussion on related work is given in section 4. Conclusions and future work are presented in section 5.

2 FlexiNET Architecture As stated in section I, the DSD module is developed for the FlexiNET Project. The primary aim of the project is to define and implement a scalable and modular network architecture incorporating adequate network elements (FlexiNET Node Instances) offering roaming connection control, switching/routing control, and advanced services management/access functions to the network access points that currently only support connectivity between user terminals and network core infrastructures [6], [7], [8]. The FlexiNET network architecture consists mainly of node instances, communication buses and data repositories. The DSD module is part of the FWAN. The FWAN architecture can be seen in Figure 1 and is based on Hitachi’s distributed router. Hitachi’s distributed router consists of two functional blocks, the basic and the extensible function block.

Fig. 1. FWAN architecture

208

C. Chrysoulas et al.

The FWAN has, as a basic functional block, a network processor, and as extended functional block, two PCs. A user will access the FWAN through an access point using either a laptop or a mobile phone. The FWAN is responsible for authenticating native and roaming users through the FLAS using an AAA proxy. The Dynamic Service Deployment Module (DSD) must be deployed on the FWAN before boot-up. The Bootstrap Process is responsible for booting up the FWAN with the AAA proxy module. In order to accomplish its task, it reads from a static configuration file which is stored in a local of the Bootstrap Process, followed by a series of commands which will be sent to the DSD Module in order to create the FWAN’s node fundamental functionalities. The Bootstrap Process mainly will trigger the install of the AAA proxy through the DSD module. The AAA Proxy Module is forwarding the Authentication packets to the FLAS Server, encapsulates the EAP Packets [9] into XML messages that are passed over Web Services, and the opposite, in order to authenticate and authorize the user. The AAA proxy service is deployed in the FWAN at boot-up time. It is stored in a local directory and deployed by the DSD module. The code will be requested from the DGWN through Web services. On boot-up the DSD module is requested by the Boot-up process to deploy the AAA proxy module. The DSD module retrieves through the DGWN the AAA proxy service code and deploys it on any of the two PCs based on specific algorithms. Also based upon the user profiles, the DSD module will deploy a Quality of Service Module (QoS), which is responsible for providing QoS to specific users. The required configuration of the network processor will be handled by the ForCEG module which receives Web Service requests from the AAA Proxy and the QoS Module and translates them into ForCES protocol messages [10].

3 DSD Architecture 3.1 DSD Definition By Dynamic Service Deployment we are referring to a sequence of steps that must be taken in order to deploy a service on demand. The necessary steps regarding the service deployment refer to service code retrieval, code installing destination according to matchmaking algorithms, and service deployment. The matchmaking algorithms provide the most efficient use of system resources by examining the available resources of the FWAN with the required resources of the service to be deployed. 3.2 Proposed DSD Architecture The following figure depicts the current proposed DSD architecture. As can be deduced from the figure the DSD is the sum of the following sub-components:


209

Fig. 2. DSD Architecture

Web Services Server The Web Services Server sub-component hosts the interfaces with the AAA Proxy and the Bootstrap Process. At this stage only these two processes will interact with the DSD Module. This server is responsible for exchanging messages between the DSD Module and the AAA Proxy Module and the Bootstrap Process. The Web Services Server sub-component has the necessary functionalities necessary to register a Web Service in a UDDI directory. This component also is capable of finding other Web Service Interfaces. DSD Manager The DSD Manager sub-component has two functions depending on whether the user’s profile is required: In the case of the AAA Proxy communicates with the DGWN, the DSD Manager must download the user profile, in order to find, which services must be deployed , and provides the request to the DSD Controller. In the case of Bootstrap Process, the DSD Manager passes the bootstrap services required for deployment to the DSD Controller The DSD Manager is responsible to check if a user has terminated the connection and undo the user’s personal configuration. DSD Controller The DSD Controller sub-component is assigned to receive the service request from the DSD Manager, to communicate with the DGWN in order to download the service code and the service requirements, to retrieve from the Node Model the available resources, to perform the Matchmaking Algorithm in order to find the most suitable resources, and finally to deploy the service. The DSD Controller is responsible for the Services, in 3 dimensions: Download, Deploy, and Configure.

210

C. Chrysoulas et al.

Resource Manager The Resource Manager sub-component is assigned to do the discovery and monitoring of the resources. It collects information, with the help of the Resource Manager Interface, from all the components of the Node model, and also from the DSD Controller. All the collected information is available to the rest of the sub-components through the WebMDS Interface it provides. Only the necessary information is passed to the Node Model. Node Model The Node Model is responsible for keeping all the information about FWAN. It provides us with a complete view regarding the FWAN. The node model contains information regarding physical resources available and used, and data about running services. User Profile User Profile is the data–storage where the downloaded User Profile is stored. It is responsible for keeping the User Profile. Service code and Requirements The Service Code and Requirements data-storage is responsible for storing the downloaded code and the requirements (in terms of physical resources) that describe a service. Running Services and Configuration The Running Services and Configuration data-storage is responsible for storing data about running services and their current configuration.

4 Discussion of Related Work Distributed component models such as Cobra [11], DCOM [12] are widely used mostly in the context of commercial applications. The Common Component Architecture developed within the CCA forum [13] defines a component model for highperformance computing based on interface definitions. XCAT3 [14] is a distributed framework that accesses Grid services e.g. OGSI [1] based on CCA mechanisms. It uses XSOAP for communication and can use GRAM [2] for remote component instantiation. Vienna Grid Environment [15] is a Web service oriented environment for supporting High Performance Computing applications. Vienna Grid Environment (VGE) has been realized based on state-of-the-art Grid and Web Services technologies, Java and XML. Globus Toolkit 4 [2] is an environment that mostly deals with the discovery of services and resources in a distributed environment rather than the deployment of the services themselves.

5 Conclusion and Future Work We presented an architecture that adds a dynamic perspective to Web service based Grid Infrastructure. Our component-based model is addressing the issue regarding the


211

dynamic deployment of new services in a distributed environment and the way they address themselves in that environment. We expect this work to be not only relevant to the Grid community but also to the Web service and the Network communities as we did not only address concerns related to Grid computing but also discussed architectural issues regarding Web service configuration and deployment. Our implementation of the model is still in prototype stage which requires further refinement and analysis. For future work we plan to provide a more sophisticated model for service deployment and selection based on QoS properties.

References 1. Foster, I., Kesselman, C., Nick, J., Tuecke, S.: The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, Globus Project (2002), http://www.globus.org/research/papers/ogsa.pdf 2. The Globus Alliance, http://www.globus.org 3. The Web Service Resource Framework, http://www.globus.org/wsrf/ 4. The Globus Alliance, http://www.globus.org/toolkit/docs/development/3.9.4/info/ wsmds.html 5. FP6-IST1 507646 FlexiNET Technical Annex 6. FP6-IST1 507646 FlexiNET D21 Requirement, Scenarios and Initial FlexiNET Architecture 7. FP6-IST1 507646 FlexiNET D22 Final FlexiNET Network Architecture and Specifications 8. Aladros, R.L., Kavadias, C.D., Tombros, S., Denazis, S., Kostopoulos, G., Soler, J., Haas, R., Dessiniotis, C., Winter, E.: FlexiNET: Flexible Network Architecture for Enhanced Access Network Services and Applications. In: IST Mobile & Wireless Communications Summit 2005, Dresden (2005) 9. RFC 3748: Extensible Authentication Protocol (EAP) (June 2004) 10. Haleplidis, E., Haas, R., Denazis, S., Koufopavlou, O.: A Web Service- and ForCES-based Programmable Router Architecture. In: IWAN 2005, France (2005) 11. CORBA Component Model, v3.0, OMG, http://www.omg.org/technology/ documents/formal/components.htm 12. COM Component Object Model Technologies, Microsoft, http://www.microsoft.com/com/default.mspx 13. The CCA Forum, http://cca-forum.org/ 14. Krishnan, S., Gannon, D.: XCAT3: A Framework for CCA Components as OGSA Services. In: Proceedings of the Ninth International Workshop on High-Level Parallel Programming Models and Supportive Environments, pp. 90–97 (April 2004) 15. Benkner, S., Brandic, I., Engelbrecht, G., Schmidt, R.: VGE - A Service-Oriented Environment for On-Demand Supercomputing. In: Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing (Grid 2004), Pittsburgh, PA, USA (November 2004)

The Active Embedded Ubiquitous Web Service Framework Dugki Min1,*, Junggyum Lee1, and Eunmi Choi2,** 1

School of Computer Science and Engineering, Konkuk University Hwayang-dong, Kwangjin-gu, Seoul, 143-701, Korea [email protected], [email protected] 2 School of Business IT, Kookmin University Chongnung-dong, Songbuk-gu, Seoul, 136-702, Korea [email protected]

Abstract. We develop an active embedded middleware framework, called the EUWS (Embedded Ubiquitous Web Service), in WinCE.NET. The EUWS seamlessly integrates home network services and the Web Services on the Internet and provides a management framework for ubiquitous web services. As the initial stage of our project, our current focus has been on designing and implementing a prototype of the EUWS in WinCE.NET. The architecture of the EUWS prototype system includes an extensible and reconfigurable Embedded Ubiquitous Web Service(EUWS) framework and an UPnP2WS processing module that seamlessly integrates the UPnP standard with the Web Service standard.

1 Introduction Recently, a number of middleware standards are proposed to implement home network. They are the UPnP(Universal Plug and Play)[1] for easy interoperability among devices, the HAVi(Home Audio and Video Interoperability)[2] for interoperability between video and audio devices, the Jini[3] for interoperability for Java applications, and the OSGI[4] for middleware framework between networked services. These recent home network middlewares are used to connect, integrate, and manage services provided by devices that are in a restricted area. However, none of them considers the seamless interconnection and integration with the external Internet services, i.e., to access home network services from the external client or to reach out the external Internet services from home network services. As the standard technology to integrate Internet services, the Web Service[5] becomes the major trend. The Web Service is platform-independent and programming languageindependent, and it is the XML-based middleware standard determined and developed by * This paper was supported by Konkuk University in 2005", and also by Microsoft Research Asia under the Grant of MSRA Joint Research Project in 2004. **Corresponding author: This work was supported the Korea Research Foundation (KRF) under Grant No. D00021 (R04-2003-000-10213-0), and also by research program and research center UICRC of Kookmin University in 2005. D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 212–217, 2009. © IFIP International Federation for Information Processing 2009

The Active Embedded Ubiquitous Web Service Framework

213

most of IT vendors. The Web Service provides the fundamental middleware standards of Internet distributed computing: SOAP[6] for the communication standard between services, WSDL[7] for description standard to define the Web Service in XML, UDDI[8] for service searching standard over Internet. Moreover, it extends up to the SOA-based application middleware standard by considering security, transaction, event, and business process management. We develop an active embedded middleware framework, called the EUWS (Embedded Ubiquitous Web Service), in WinCE.NET that can be applied to home gateways. The EUWS seamlessly integrates home network services, and the Web Services on the Internet and provides a management framework for ubiquitous web services. Through the EUWS home gateway, the device services are converted to the Web Services for external accesses, so that a remote client can control the device via the Web Services. At the same time, the EUWS gateway converts the external Web Services into the device-specific services, so that the internal devices can access and use the external services according to the device-specific protocol. As the initial stage of our research, our current focus has been on designing and implementing a prototype of the EUWS in WinCE.NET for the UPnP middleware protocol. The architecture of the EUWS prototype system includes an extensible and reconfigurable Embedded Ubiquitous Web Service(EUWS) framework and a UPnP2WS processing module that seamlessly integrates the UPnP standard with the Web Service standard. The EUWS technology will be used as an encore technology to build the Advanced Home Gateway. We have the EUWS prototype be deployed into a home gateway in our demo system where a digital audio and a digital TV can be controlled by an external remote controller. While the traditional gateway focuses on connection between internal segment and external segment at the network level, the EUWS focuses on connection between internal services and external services at the service level. The EUWS integrates various services which exist in home network environment, and integrates internal and external services. The next section presents the EUWS architecture. Section 3 presents our demo prototype system currently implemented. We conclude in the last section.

2 The EUWS Architecture In this section, we introduce the architecture of the active EUWS (Embedded Ubiquitous Web Service) framework. As shown in Figure 1, the active EUWS framework has two major parts: one is the Protocol Abstraction Sub-framework and the other is the Service Orientation Sub-framework. The Protocol Abstraction Subframework is for seamlessly integrating various devices each of which uses different middleware protocols. The Service Orientation Sub-framework is for creating a virtual service-oriented space where everything in a ubiquitous environment, e.g. devices or services, is a standard service. 2.1 Protocol Abstraction Sub-framework In order to support various ubiquitous devices that use different communication protocols, the Protocol Abstraction Sub-framework contains an Active Protocol

214

D. Min, J. Lee, and E. Choi

Fig. 1. The EUWS Framework Architecture

Reconfigurable architecture that can dynamically deploy protocol processing modules on demand. The active protocol reconfigurable architecture is composed of two dedicated modules and one or more pluggable modules. The two dedicated modules are the Protocol Detection Module and the Dynamic Protocol Deployment Module. The Protocol Detection Module is used for detecting new devices whose protocol processing module is not yet plugged-in. While the EUWS framework is running, the Protocol Detection Module periodically broadcasts a sequence of protocol-specific discovery messages one-by-one at a time. When it receives any response from a new device whose protocol execution module is not yet plugged-in, the related protocol processing module is downloaded and deployed automatically by the Protocol Deployment Module, if the related protocol processing module is available. Otherwise, error message is sent to the newly detected devices. The Protocol Detection Module can be upgraded whenever its new version is available. 2.2 Service Orientation Sub-framework The Service Orientation Sub-framework provides a service orientation environment where every distinctive device or service is recognized and treated as the same type of standard service. This framework also provides common middleware services, such as resource management service, event service, and security service. In our project, we employ the Web service as our service-orientation standard, since the Web service becomes the de-facto standard of business domain service area, and is also good at extensibility and self-description. The Service Orientation Sub-framework has three components: Service Manager, Service Container, and Middleware Services. The Service Manager is the manager of service orientation; it is in charge of transforming everything to standard service, registering and searching a registered service to the service directory, and providing metadata information of the registered services. Let us suppose that an UPnP device is newly arrived into the managed space. Then, the UPnP Processing Module detects the UPnP device and registers it to the Service Manager. The Service Manager creates a service proxy that acts as the corresponding service object for the device and uploads


215

it to the Service Container. At the same time, the WSDL of the service proxy is automatically generated. After the service proxy is deployed with WSDL into the Service Container, the Service Manager registers the device as a Web service into the UDDI. Other web services, which locate outside of the framework, consider the UPnP device as a registered Web service. Within our framework, this device is also treated as a standard service. That is, the Protocol Execution Module or the Service Manager accesses a registered device through the corresponding service proxy. However, external devices, that use their own protocols, access and use the registered device through their own protocols via the related Protocol Execution Modules. Other functions of the Service Orientation Sub-framework are the Middleware Services related to Service Container. The Service Container is in charge of system resource management and dynamic service deployment into memory if necessary. Also, the Service Container performs various management functions by detecting service invocation and generating events.

3 EUWS Prototype Implementation In this section, we introduce the EUWS prototype implemented. The EUWS prototype is a system operated on .NET framework and it contains the initial version of EUWS Framework with the UPnP execution module. In order to deploy the EUWS into a device, Win CE .NET Platform Builder is used to upload a kernel image into the board. 3.1 Development Environment The EUWS is implemented in an embedded board on top of Win CE .NET containing .NET Compact Framework. Two embedded boards are used; one is for a device and the other is for home gateway. The prototype device and home gateway are implemented on the similar boards called X-Hyper255B and X-Hyper255BTKUIII respectively. These boards have a 400MHz Intel XScale PXA255 CPU, 64MB SDRAM, 32MB flash memory, 10Base-T CS8900A and PCMCIA Slot. Detailed information is in Table 1. As for the external control client, HP iPAQ PDA is used. As a design tool, the IBM Rational Rose XDE is used, and as a development tool, the MS Visual Studio .NET is used. Table 1. Device Platform & Home Gateway Platform

Device Platform

Home Gateway Platform

3.2 Devices of Demo System As our demo systems, a digital audio and a digital TV are developed as UPnP devices (see Figure 2) Those devices contain UPnP device modules deployed on top of .NET

216

D. Min, J. Lee, and E. Choi

Compact Framework. When initially operating, their device information is transferred to the home gateway. Also, they have UPnP control point modules so that they can access web services provided by the home gateway as UPnP services. For example, the digital TV can receive channel broadcasting information service from the home gateway, and the digital audio can receive new media information.

Fig. 2. UPnP Devices (Digital TV & Digital Audio)

The home gateway contains the active EUWS framework explained in section 2. It discovers internal devices, and converts the services of the internal devices into Web services. It also converts external Web services into UPnP services. At the same time, the home gateway reads events from UPnP devices and transfers them to external clients. Especially, when an external Web service is accessed by an UPnP device, the external Web service is perceived as an UPnP service by the EUWS framework of the home gateway, that is an UPnP device including an UPnP control point can access the external Web Services as easy as UPnP services via the home gateway. In order to control digital audio and TV devices within home area, a PDA is used as external device that contains the home control application. When booting the PDA, the control application automatically begins and receives service information of home devices from the designated home gateway. The device information received by the home control application is written in the Web services of internal UPnP devices exported by the home gateway. Thus, when a user selects and invokes a service shown in the screen of the PDA, it invokes a Web service provided by the home gateway and it consequently invokes an UPnP service provided by an internal device. The Figure 3 shows the GUI of the PDA.

Fig. 3. External Devices


217

4 Conclusion In order to establish a ubiquitous home network, we developed an active embedded middleware framework, the EUWS, in WinCE.NET environment. The EUWS seamlessly integrates home network services and the Web Services on the Internet, and also provides a management framework for ubiquitous web services. In this paper, we presented a prototype of the EUWS in WinCE.NET for the UPnP middleware protocol, so that we can seamlessly integrates the UPnP standard with the Web Service standard, and work with UPnP devices and home gateway for the home network. Through our demo system, we could control a digital audio and a digital TV by an external remote controller. As an active embedded middleware framework, the EUWS achieved to integrate various existing services, internal and external services.

References [1] Miller, B.A., Nixon, T., Tai, C., Wood, M.D.: Home networking with Universal Plug and Play. Communications Magazine 39(12), 104–109 (2001) [2] HAVI, http://www.havi.org [3] Allard, J., Chinta, V., Gundala, S., Richard III, G.G.: Jini meets UPnP: an architecture for Jini/UPnP interoperability. In: Proceedings. 2003 Symposium on Applications and the Internet, pp. 268–275, January 27-31 (2003) [4] Dobrev, P., Famolari, D., Kurzke, C., Miller, B.A.: Device and service discovery in home networks with OSGi. Communications Magazine 40(8), 86–92 (2002) [5] Hung, P.C.K., Ferrari, E., Carminati, B.: Towards standardized Web services privacy technologies. In: Proceedings IEEE International Conference on Web Services, p. 174, July 6-9 (2004) [6] Box, D.: SOAP 1.1., http://www.w3.org/TR/SOAP/ [7] WSDL Verstion 2.0 Part 3: Bindings, http://www.w3.org/TR/wsdl20bindings/ [8] UDDI Technical WhitePaper, UDDI.org, http://www.uddi.org/whitepapers.html

Framework of an Application-Aware Adaptation Scheme for Disconnected Operations Umar Kalim, Hassan Jameel, Ali Sajjad, Sang Man Han, Sungyoung Lee, and Young-Koo Lee Department of Computer Engineering, Kyung Hee University Sochen-ri, Giheung-eup, Yongin-si, Gyeonggi-do, 449-701, South Korea {umar,hassan,ali,i30000,sylee}@oslab.khu.ac.kr, [email protected]

Abstract. The complex software development scenarios for mobile/ hand-held devices operating in wireless environments require adaptation to the variations in the environment (such as fluctuating bandwidth). This translates to maintenance of service availability in preferably all circumstances. In this paper we propose that a mobile computing system (for hand-held, wireless devices) must be based on the combination of reflection, remote evaluation and code mobility mechanisms such that the communication framework1 allows developers to design disconnectionaware applications which maintain service availability in case of varying circumstances by automatically redeploying essential components to appropriate locations. This not only allows the application to continue executing in varying conditions, but also in entirely disconnected modes.

1

Introduction

The complexity, size and distribution of software today is rapidly increasing. This has complemented the ubiquity of hand-held devices and promoted the growth of distributed systems and applications. One can thus think of numerous, complex software development scenarios which utilize a large number of handheld devices, such as in environment monitoring and surveying, postal services, patient monitoring etc. Such scenarios present intricate technical challenges for middleware technologies [1]. In particular, the middleware must adapt to the variations in the environment (e.g. fluctuating bandwidth) of the mobile device and service availability must be maintained in (preferably) all circumstances [1]. The conventional middleware being heavy, and relatively inflexible, fails to properly address such requirements. The fundamental reason is that traditional middleware systems have been designed adhering to the principle of transparency. Despite the fact that this design [2] [3] has proved successful for traditional distributed systems, this concept has limitations when considered in a mobile environment, where it is neither possible, nor preferred, to hide the implementation details from the user. Also, applications may posses information 1

This research work has been partially supported by KOSEF, Korea, for which Professor Sungyoung Lee is the corresponding author.


Framework of an Application-Aware Adaptation Scheme

219

that could facilitate the middleware to perform efficiently. Thus to cope with such limitations, numerous research efforts have been made [4] [5] on designing middleware systems suitable for such environments. However the solutions developed to date do not fully support the necessary level of middleware configurability and reconfigurability that is required to facilitate mobile computing and disconnected operations. Thus in our opinion a simple but dynamic solution is the need of the hour. We propose that a mobile computing system for hand-held devices must be based on the combination of reflection [6], remote evaluation [7] and code mobility [8]. The remote evaluation paradigm not only enables the clients to out-source resource intensive tasks, but also allows more client-side applications (because of their smaller footprint). Reflection is a fundamental technique that supports both introspection and adaptation. In order to maintain service availability in a distributed system, in case of varying circumstances the middleware can utilize code mobility and reflection to automatically redeploy essential components to appropriate locations defined by the application policy. Moreover, such systems can be implemented optimally if the adaptation scheme is application aware, i.e. the framework allows the developer to determine the policies, such as the constraints the components may have, dependency among components, restriction on collocation of components, how the system should react to different circumstances etc. 1.1

Code Mobility and Autonomy of Components

Under favourable circumstances, remote evaluation is one of the most appropriate solutions for mobile, hand-held devices. However in unfavourable conditions, code mobility overcomes the limits of fluctuating bandwidth and disconnections as it allows for specifying complex computations to move across a network from the server to the client end. This way, the services that need to be executed at a platform residing in a portion of the network reachable only through an unreliable link could be relocated and hence maintain Quality of Service. In particular, it would not need any connection with the node that sent it, except for the transmission of the final results of its computation. Also, autonomy of application components brings improved fault tolerance as a side-effect. In conventional client-server systems, the state of the computation is distributed between the client and the server. A client program is made of statements that are executed in the local environment, interleaved with statements that invoke remote services on the server. The server contains (copies of) data/code that belongs to the environment of the client program, and will eventually return a result that has to be inserted into the same environment. This structure leads to well-known problems in presence of partial failures, because it is very difficult to determine where and how to intervene to reconstruct a consistent state. The action of migrating code, and possibly sending back the results, is not immune from this problem. In order to determine whether the code has been received and avoid duplicated or lost mobile code, an appropriate protocol must be in place. However, the action of executing code that embodies a set of

220

U. Kalim et al.

interactions that should otherwise take place across the network is actually immune from partial failure and can permit execution even in the face of absolute disconnection. An autonomous component encapsulates all the state involving a distributed computation, and can be easily traced, check-pointed, and possibly recovered locally, without any need for knowledge of the global state. Thus to introduce the capability of dynamic reconfiguration to achieve the above mentioned objectives, the system must posses certain characteristics, such as, it should be based on a distributed object framework, the system must be able to redeploy/replace2 components3 , it should be able to recover gracefully in the case of faults and there should be a procedure to reconcile components upon reconnection.

2

Framework

In order to narrow down the scope of the problem, we distinguish between voluntary and involuntary disconnection. The former refers to a user-initiated event that enables the system to prepare for disconnection, and the latter to an unplanned disconnection (e.g., due to network failure). The difference between the two cases is that in involuntary disconnection the system needs to be able to detect disconnection and reconnection, and it needs to be pessimistically prepared for disconnection at any moment, hence requiring to proactively reserve and obtain redundant resources (if any) at the client. Here we are only focusing on voluntary disconnections and defer the task of predicting and dealing with involuntary disconnections as future work. Note that the steps for the remedy will be the same, whether the disconnection is voluntary or involuntary. 2.1

Characteristics of the Components and Their Classification

As the system comprises of components as the building blocks we propose that the primary components participating in the reconfiguration must be serializable and they must implement the DisconnectionManagement interface as shown in figure 1. This interface advertises two primary methods; disconnect and reconnect. These methods are invoked by the framework on disconnection and reconnection. The first requirement facilitates the components in relocating themselves while maintaining their state. The second requirement enables the application to prepare for disconnection. The use of disconnect is to compile the component state and transfer it in marshaled form, over the network along, with the code to be executed locally at the client. Similarly, reconnect is used to perform the process of reconciliation among components upon reconnection, details of which are explained in [9]. The components are classified with respect 2 3

The use of a component with reduced (or similar) functionality but the same interface, as the substitute to a (remote) component with reference functionality. Analogous to an object, here a component is referred to as a self contained entity that comprises of both data and procedures. Also data access has not been considered separately because data is always encapsulated in a component.

Framework of an Application-Aware Adaptation Scheme Remote Object

Disconnection Management

Application Logic (Server Implementation )

Application Logic

221

Fig. 1. Hierarchy of interfaces for disconnection-aware components

reconfigure Transferring state (as per policy)

Traversing reference graph

identify references for relocation

disconnect

initialize reconnection complete

Swapping local references with remote references

Connected

Disconnection triggered

disconnection Swapping remote references with local complete references Reconnection triggered

Disconnected

Traversing reference graph

download references Downloading reference implementation (.class files )

reconfigure identify references for relocation Reconnecting

reconnect finalize [off=true]

Transferring state (as per policy)

create instances

Creating local references

transfer state Disconnecting

Fig. 2. State-transition diagram from disconnection/reconnection management

to disconnection (Log, Substitute and Replica) and reconnection (Latest, Revoke, Prime and Merge), details of which are specified in [9].

3

Disconnection Management

When it comes to maintaining service availability in the face of a disconnection, there is a need to relocate the required server code (partially or completely) to the client, in order to make local processing possible. 3.1

Working

The state-transition diagram in figure 2 summarizes the working [9] of the framework. The mechanisms of Reflection, dynamic class loading and linking and serialization (provided by Java [10]) are employed to achieve code mobility. Once a disconnection event is fired, the framework propagates the event to all disconnection-aware references. These references then invoke the disconnect method. This method prepares the reference for the disconnection. Using the mechanisms of introspection each component and each of its contained objects are traversed recursively and a list of references to be relocated is prepared. This list is prioritized with respect to the policy determined by the application designer and each reference is treated as per its classification [9]. The framework maintains a sufficient state of each reference in order to restore the system to the state before disconnection.

222

4

U. Kalim et al.

Related Work

A substantial debt is owed to Coda [4]. The authors were among the first to demonstrate that client resources could be effectively used to insulate users and applications from the hurdles of mobile information access. Coda treats disconnection as a special case of network partitioning where the client may continue to use the data present in its cache, even if its disconnected. Odyssey [5], inspired by Coda [4], proposed the concept of application-aware adaptation. The essence of this approach is to have a collaborative partnership between the application and the system, with a clear separation of concerns. FarGo-DA [11], an extension of FarGo, a mobile component framework for distributed applications proposes a programming model with support for designing the behaviour of applications under frequent disconnection conditions. The programming model enables designers to augment their applications with disconnection-aware semantics that are tightly coupled with the architecture, and are automatically carried out upon disconnection.

5

Prototype Implementation

The framework is developed using J2SE [10] as the fundamental platform for the application; both the client and server components. Java RMI [12] is used for remote evaluation, where as the Reflection classes are used for introspection and reference management when objects are relocated (from the server to the client or vice versa) and references are swapped. Components are notified about disconnection or reconnection via event-notification mechanism. We have implemented a prototype application for patient monitoring and diagnosis service along with the framework libraries in order to verify the feasibility of our proposal. This implementation [9] is part of our ongoing research [13]. The module layout of the framework along with the application is shown in figure 3. It may be noted that the framework comprises of two sub-systems; one operating at the server end and the other at the client end. Unlike [14], our approach being simple and discreet avoids the computational overhead required to determine the component distribution in different circumstances. This is primarily due to the application aware approach, which allows the developer to determine the application policies Core Application Java (J2SE) API Java RMI

Reference Manager

Component Relocator

Resource Monitor

Event Listener

Java Virtual Machine (JVM)

Fig. 3. Module layout of the prototype implementation

Framework of an Application-Aware Adaptation Scheme

6

223

Conclusion

In this paper we proposed a mobile computing middleware-framework for handheld devices which is based on the combination of reflection [6], remote evaluation [7] and code mobility [8]. We have implemented a prototype application [9] along with the framework libraries in order to demonstrate the feasibility of the approach. The results reflect that significant benefits may be obtained by maintaining service availability even in the face of a disconnection.

References 1. Satyanarayanan, M.: Pervasive computing: Vision and challenges. IEEE Personal Communications, 10–17 (2001) 2. Reference-model: Iso 10746-1 - open distributed processing. International Standardization Organization (1998) 3. Emmerich, W.: Engineering Distributed Objects. John Wiley and Sons, Chichester (2000) 4. Kistler, J., Satyanarayanan, M.: Disconnected operation in the coda file system. In: 13th ACM symposium on Operating Systems Principles, pp. 213–225. ACM, New York (1991) 5. Noble, B., Satyanarayanan, M.: Agile application-aware adaptation for mobility. In: 16th ACM Symposium on Operating Systems Principles. ACM, New York (1997) 6. Maes, P.: Concepts and experiments in computational reflection. In: 2nd Conference on Object Oriented Programming Systems, Languages and Applications 7. Stamos, J., Gifford, D.: Remote evaluation. In: Transactions on Programming Languages and Systems, pp. 537–564. ACM, New York (1990) 8. Fuggetta, A.: Understanding code mobility. In: Transactions on Software Engineering, vol. 24, pp. 342–361. IEEE, Los Alamitos 9. Kalim, U.: Technical report: Framework of an application-aware adaptation scheme for disconnected operations, http://oslab.khu.ac.kr/xims/mgrid/techreport-disconn-umar.pdf 10. Sun-Microsystems: Java, http://java.sun.com/j2se/ 11. Weinsberg, Y., Israel, H.: A programming model and system support for disconnected-aware applications on resource-constrained devices. In: 24th International Conference on Software Engineering, pp. 374–384 (2002) 12. Sun-Microsystems: Java rmi, http://java.sun.com/products/jdk/rmi/ 13. Kalim, U., Jameel, H.: Mobile-to-grid middleware: An approach for breaching the divide between mobile and grid environments. In: Lorenz, P., Dini, P. (eds.) ICN 2005. LNCS, vol. 3420, pp. 1–8. Springer, Heidelberg (2005) 14. Marija, M.: Improving availability in large, distributed, component-based systems via redeployment. Technical Report USC-CSE-2003-515, Center for Software Engineering, University of Southern California (2003)

Kinetic Multipoint Relaying: Improvements Using Mobility Predictions Jérôme Härri, Fethi Filali, and Christian Bonnet Institut Eurécom Department of Mobile Communication B.P. 193 06904 Sophia-Antipolis, France {Jerome.Haerri,Fethi.Filali,Christian.Bonnet}@eurecom.fr

Abstract. Multipoint Relaying (MPR) is a technique to reduce the number of redundant retransmissions while diffusing a broadcast message in the network, where only a subset of nodes are allowed to forward packets. The selection is based on instantaneous nodes’ degrees, and is periodically refreshed. We propose in this chapter a novel heuristic to select kinetic multipoint relays based on nodes’ overall predicted degree, which is solely updated on a per-event basis. We illustrate that this approach significantly reduces the number of messages needed to operate the protocol, yet with similar broadcast properties that the regular MPR, such as network coverage, number of multipoint relays, or flooding capacity.

1 Introduction Multipoint relaying (MPR, [1]) provide a localized way of flooding reduction in a mobile ad hoc network. Using 2-hops neighborhood information, each node determines a small set of forward neighbors for message relaying, which avoids multiple retransmissions and blind flooding. MPR has been designed to be part of the Optimized Link State Routing algorithm (OLSR, [2]) to specifically reduce the flooding of TC messages sent by OLSR to create optimal routes. Yet, the election criteria is solely based on instantaneous nodes’ degrees. The network global state is then kept coherent through periodic exchanges of messages. Some studies showed the impact of periodic beacons on the probability of transmission in 802.11, or on the battery life [4,3]. This denotes that these approaches have major drawbacks in terms of reliability, scalability and energy consumptions. The next step to their evolution should therefore be designed to improve the channel occupation and the energy consumption. In this chapter, we propose to improve the MPR protocol by using mobility predictions. We introduce the Kinetic Multipoint Relaying (KMPR) protocol, which heuristic selects kinetic relays based on nodes actual and future predicted nodal degrees. Based

An extended version of this chapter is available as a technical report under the reference RR 05 148 at http://www.eurecom.fr/people/haerri.en.htm Institut Eurécom’s research is partially supported by its industrial members: Bouygues Télécom, France Télécom, Hitachi Europe, SFR, Sharp, ST Microelectronics, Swisscom, Texas Instruments, Thales. D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 224–229, 2009. c IFIP International Federation for Information Processing 2009

Kinetic Multipoint Relaying: Improvements Using Mobility Predictions

225

on this, periodic topology maintenance may be limited to the instant when a change in the neighborhood actually occurs. Our objective is to show that this approach is able to significantly reduce the number of messages needed to maintain the backbone’s consistency, thus saving network resources, yet with similar flooding properties as the regular MPR. The rest of the chapter is organized as follows. Section 2 describes the heuristic to compute kinetic degrees. Then, in Section 3, we describe the KMPR protocol. Finally, Section 4 provides simulation results, while Section 5 draws some concluding remarks.

2 Kinetic Nodal Degree in MANETs We explain in this section the method for modeling kinetic degrees in MANETs. We model nodes’ positions as a piece-wise linear trajectory and, as shown in [5], the corresponding trajectory durations are lengthy enough to become a valuable cost for using kinetic degrees. Over a relatively short period of time1 , one can assume that each such node, say i, follows a linear trajectory. Its position as a function of time is then described by xi + dxi · t Posi (t) = , yi + dyi · t where P osi (t) represents the position of node i at time t, the vector [xi , yi ]T denotes the initial position of node i, and vector [dxi , dyi ]T its initial instantaneous velocity. Let us consider node j as a neighbor of i. The squared distance between nodes i and j is defined as 2 2 Dij (t) = Dji (t) = Posj (t) − Posi (t)22 2 xj − xi dxj − dxi = + · t yj − yi dyj − dyi

= aij t2 + bij t + cij , 2 Considering r as nodes maximum transmission range, as long as Dij (t) ≤ r2 , nodes i and j are neighbors. Therefore, solving 2 Dij (t) − r2 = 0

gives tfijrom and tto ij as the time intervals during which nodes i and j remain neighbors. Consequently, we can model nodes’ kinetic degree as two successive sigmoid functions, where the first one jumps to one when a node enters another node’s neighborhood, and the second one drops to zero when that node effectively leaves that neighborhood. Considering nbrsi as the total number of neighbors detected in node i’s neighborhood at time t, we define nbrsi

Degi (t) =

k=0 1

1 1 · 1 + exp(−a · (t − tfk rom )) 1 + exp(a · (t − tto k ))

(1)

The time required to transmit a data packet is orders of magnitude shorter than the time the node is moving along a fixed trajectory.

226

J. Härri, F. Filali, and C. Bonnet

t=16

r

i t=4 j

t=20

k

(a) Node i kinetic neighborhood

(b) Node i kinetic nodal degree

Fig. 1. Illustration of nodes kinetic degrees

as node i’s kinetic degree function, where tfk rom and tto k represent respectively the time a node k enters and leaves i’s neighborhood. Thanks to (1), each node is able to predict its actual and future degree and thus is able to proactively adapt its coverage capacity. Fig. 1(a) illustrates the situation for three nodes. Node k enters i’s neighborhood at time t = 4s and leave it at time t = 16s. Meanwhile, node j leaves i’s neighborhood at time t = 20s. Consequently, Fig. 1(b) illustrates the evolution of the kinetic degree function over t. Finally, the kinetic degree is obtained by integrating (1) i (t) = Deg

∞ t

k=nbrs i k=0

1 1 ( · ) f rom 1 + exp(a · (t − tto 1 + exp(−a · (t − tk )) k ))

(2)

For example, in Fig. 1(b), node i kinetic degree is ≈ 32.

3 Kinetic Multipoint Relays In this section, we describe our Kinetic Multipoint Relaying protocol. It is mainly extracted from the regular MPR protocol. Yet, we adapt it to deal with kinetic degrees. To select the kinetic multipoint relays for node i, let us call the set of 1-hop neighbors of node i as N (i), and the set of its 2-hops neighbors as N 2 (i). We first start by giving some definitions. Definition 1 (Covering Interval). The covering interval is a time interval during which a node in N 2 (i) is covered by a node in N (i). Each node in N 2 (i) has a covering interval per node i, which is initially equal to the connection interval between its covering node in N (i) and node i. Then, each time a node in N 2 (i) is covered by a node in N (i) during some time interval, this covering interval is properly reduced. When the covering interval is reduced to ∅, we say that the node is fully covered. Definition 2 (Logical Kinetic Degree). The logical kinetic degree is the nodal degree obtained with (2) but considering covering intervals instead of connection intervals. In that case, tfk rom and tto k will then represent the time interval during which a node k ∈ N 2 (i) starts and stops being covered by some node in N (i).


227

The basic difference between MPR and KMPR is that unlike MPR, KMPR does not work on time instants but on time intervals. Therefore, a node is not periodically elected, but is instead designated KMPR for a time interval. During this interval, we say that the KMPR node is active and the time interval is called its activation. The KMPR protocol elects a node as KMPR a node in N (i) with the largest logical kinetic degree. The activation of this KMPR node is the largest covering interval of its nodes in N 2 (i). Kinetic Multipoint Relaying (KMPR) The KMPR protocol applied to an initiator node i is defined as follows: – Begin with an empty KMPR set. – First Step: Compute the logical kinetic degree of each node in N (i). – Second Step: Add in the KMPR set the node in N (i) that has the maximum logical kinetic degree. Compute the activation of the KMPR node as the maximum covering interval this node can provide. Update all other covering intervals of nodes in N 2 (i) considering the activation of the elected KMPR, then recompute all logical kinetic degrees. Finally, repeat this step until all nodes in N 2 (i) are fully covered. Then, each node having elected a node KMPR for some activations is then a KMPR Selector during the same activation. Finally, KMPR flooding is defines as follows: Definition 3 (KMPR flooding). A node retransmits a packet only once after having received the packet the first time from an active KMPR selector.

4 Simulation Results We implemented the KMPR protocol under ns-2 and used the NRL MPR [7] implementation for comparison with KMPR. We measured several significant metrics for Manets: The effectiveness of flooding reduction, the delay before the network receives a broadcast packet, the number of duplicate packets and finally the routing overhead. The following metrics were obtained after the population of 20 nodes were uniformly distributed in a 1500 × 300 grid. Each node has a transmission range of 250m. The mobility model we used is the standard Random Mobility Model where we made nodes average velocity vary from 5m/s to 30m/s. Finally, we simulated the system for 100s. Figure 2 illustrates the flooding reduction of MPR and KMPR. Although MPR is slightly more performing than KMPR, we can see that both protocols are close together and have a fairly good flooding reduction, both in terms of duplicate and forwarded packets. Note that the low fraction of relays in Fig 2(b) comes from the rectangular topology, where only a couple of MPRs are used as bridge in the center of the rectangle. On Fig. 3, we depicted the broadcast efficiency of MPR and KMPR. In the simulations we performed, we measured the broadcast efficiency as the time a packet takes before being correctly delivered to the entire network. As we can see, KMPR has a delivery time faster than MPR by 50%. This might comes from two properties of KMPR. Firstly, as described in [6], MPR suffers from message decoding issues, which we corrected in KMPR. Secondly, as we will see in the next figure, KMPR’s backbone maintenance is significantly less than MPR. Therefore, the channel access is faster and the probability of collisions is decreased.

228

J. Härri, F. Filali, and C. Bonnet 30

2

MPR KMPR

25

1.6

Forwared Packets ratio

Duplicate Packets ratio

MPR KMPR

1.8

20

15

10

1.4 1.2 1 0.8 0.6 0.4

5

0.2

0 10

15

20

25

30

35

0 10

40

15

20

Average Speed [s]

25

30

35

40

Average Speed [s]

(a) Duplicate reception

(b) Forwarding Nodes

Fig. 2. Illustration of the flooding reduction of MPR and KMPR 5

MPR KMPR

4.5

Delivery Delay [s]

4 3.5 3 2.5 2 1.5 1 0.5 0 10

15

20

25

30

35

40

Average Speed [s]

Fig. 3. Illustration of the broadcast efficiency of MPR and KMPR 5

x 10

4500

4

4000

3.5

3500

3

3000

# hello packets

Routing Overhead [bytes]

4.5

2.5 2 1.5

2500 2000 1500 1000

MPR KMPR

1 0.5 10

MPR KMPR

15

20

25

30

Average Speed [s]

(a) Routing overhead

35

500

40

0 10

15

20

25

30

35

Average Speed [s]

(b) Number of Hello packets

Fig. 4. Illustration of the network load for MPR and KMPR

40


229

In the two previous figures, we have shown that KMPR had similar properties than MPR in term of flooding reduction and delay. Now, in Fig. 4, we illustrate the principal benefit of KMPR: its low routing overhead. Indeed, by using mobility predictions, the routing overhead may be reduced by 75% as it may be seen on Fig. 4(a). We also show on Fig. 4(b) the number of hello messages which drops dramatically with KMPR, yet still preserving the network’s consistency.

5 Conclusions In this chapter, we presented a original approach for improving the well-known MPR protocol by using mobility predictions. We showed that the Kinetic Multipoint Relaying (KMPR) protocol was able to meet the flooding properties of MPR, and this by reducing the MPR channel access by 75% and MPR broadcast delay by 50%. We consequently illustrated that, after having been studied in other fields of mobile ad hoc networking, mobility predictions are also an interesting technique to improve broadcasting protocols.

References 1. Laouiti, A., et al.: Multipoint Relaying: An Efficient Technique for Flooding in Mobile Wireless Networks. In: 35th Annual Hawaii International Conference on System Sciences (HICSS 2001), Hawaii, USA (2001) 2. Clausen, T., Jacquet, P.: Optimized Link State Routing Protocol (OLSR), Project Hipercom, INRIA, France (October 2003), www.ietf.org/rfc/rfc3626.txt 3. Bianchi, G.: Performance analysis of the IEEE 802.11 distributed coordination function. IEEE Journal on Selected Areas in Communications 18(3), 535–547 (2000) 4. Toh, C.-K., Cobb, H., Scott, D.A.: Performance evaluation of battery-life-aware routing schemes for wireless ad hoc networks. In: 2001 IEEE International Conference on Communications (ICC 2001), June 2001, vol. 9, pp. 2824–2829 (2001) 5. Haerri, J., Bonnet, C.: A Lower Bound for Vehicles Trajectory Duration. In: IEEE VTC Fall 2005, Dallas, USA (September 2005) 6. Haerri, J., Bonnet, C., Filali, F.: OLSR and MPR: Mutual Dependences and Performances. In: Proc. of the 2005 IFIP Med-Hoc-Net Conference, Porquerolles, France (June 2005) 7. NRLOLSR, http://pf.itd.nrl.navy.mil/projects.php?name=olsr

The Three-Level Approaches for Differentiated Service in Clustering Web Server Myung-Sub Lee and Chang-Hyeon Park School of Computer Science and Electrical Engineering, Yeungnam University Kyungsan, Kyungbuk 712-749, Republic of Korea {skydream,park}@yu.ac.kr

Abstract. This paper presents three-level approaches for the differentiated Web Qos. A kernel-level approach adds a realtime scheduler to the operating system kernel to keep the priority of the user requests determined by the scheduler in the Web server. An application-level approach which uses IP-level masquerading and tunneling technology improves the reliability and response speed of the Web services. A dynamic load-balancing approach uses the parameters related to the MIB-II of SNMPand the parameters related to the load of the system resources such as memory and CPU to perform load balancing dynamically. These approaches proposed in this paper are implemented using a Linux kernel 2.4.7 and tested in three different situations. The result of tests shows that the approaches support the differentiated services in clustering web server environment. Keywords: Differentiated Qos, Dynamic load balancing, SNMP, MIBII, Realtime scheduler.

1

Introduction

Recently the technologies related to Web QoS(Quality of Service) which guarantees the quality of Web services are becoming more important[1,2,3]. Particularly for the differentiated quality of Web services, Web servers are required to be able to classify contents depending on the importance of the information and the priority of the customer and perform scheduling among the classified contents. However, most Web servers currently provide best effort services on a FIFO (First In First Out) basis only. This means that, when they are overloaded, the servers cannot provide the appropriate services for the premium user [4,5]. Hence, a new server model is needed so that it may guarantee the quality of services by classifying services according to specific criteria and providing differentiated services. Despite the rapid expansion in Web use, the capacity of current Web servers is unable to satisfy the increasing demands. Consequently

This research was supported by the MIC(Ministry of Information and Communication), Korea, under the ITRC(Information Technology Research Center) support program supervised by the IITA(Institute of Information Technology Assessment).


The Three-Level Approaches for Differentiated Service

231

even if a Web server providing differentiated services is developed, it cannot guarantee perfect service. As a resolution for Web QoS, Web server technologies employing load balancing have been proposed. However, the exiting load balancing technologies for Web servers still have some problems, such as incompatibility between different client application programs[6], inability to process overloaded servers[7], overload when processing HTTP requests/ replies [8,9,10,11], packet conversion overheads[12,13], and etc. This paper proposed three-level approaches for implementing load balancing Web servers the can guarantee differentiated Web QoS. In the first approach, a scheduling module is added to Web server, which assigns a priority to a client request according to its importance, and a realtime scheduler is inserted into the OS kernel so that the assigned priority can be kept in the OS, and thereby more efficient differentiated service Is provided. In the second approach, the load balancing Web server is configured using masquerading and tunneling technologies to distribute the load by class, thereby the reliability and response time of the Web services are improved. The third approach uses the parameters related to the MIB-II of SNMP and the parameters related to the load of the system resources such as memory and CPU to perform load balancing dynamically.

2

A Differentiated Web Service System

The proposed system uses three-level approaches: kernel-level approach, application-level approach, and load-balancing approach. 2.1

Kernel-Level Approach

For the client requests, this approach maintains their priority order determined by the Web server in the OS kernel. This approach is implemented by mapping the scheduling process in the Apache Web server to realtime scheduling processes in the OS kernel. When the client requests come through a Network Interface Card(NIC), the Web server receives them from port 80 in the TCP listening buffer classified them by connection according to specific classification policies(client IP,URL, file name, directory, user authentication, etc.), assigns the proper priority, then inserts them into the corresponding queues. Thereafter, at the same time the requests are being scheduled, the scheduling process in the Web server are mapped one-to-one the processes in the realtime scheduler(Montavista in this paper) in the Linux Os kernel. 2.2

Application-Level Approach

The load balancing Web server proposed in this paper has a high performance and expansibility by enhancing the packet transmission rate and by resolving the bottleneck in the load balancer through the use of IP-level masquerading

232

M.-S. Lee and C.-H. Park

and tunneling. In the proposed system, a single load-balancer distributes the requests to several real servers, which share a common IP address, using a masquerading techniques so that they look like a single server from the outside. IP masquerading hides the real servers behind a virtual server that acts as a gateway to external networks. 2.3

Dynamic Load Balancing Approach

The load balancer analyzes the load of the actual server, by analyzing the utilization of the ethernet and the rate of system load, after processing the MIB-II value that is related to the load of SNMPv2. The systemic load analysis proposed in this paper is the value in which the utilization of the system is added to all the utilization of the ethernet, The equation(1) for load analysis is as follows: T otal loadi = Ethernet U tilizationi + Sys U tilizationi

(1)

The ethernet utilization, given equation (2), means all the traffic amount of input and output of the load balancer. In other words, the sum of all the bit number of packets that transmitted from the sending side and all the bit number that the receiving side received is divided by the whole bandwidth of the network. The variables used to measure the utilization of the ethernet in this paper are listed in table 1. Ethernet U tilizationi = (total bit senti + total bit receivedi )/bandwidth (2) Table 1. The variables of ethernet utilization Item

Explanation

x T ifInOctets ifOutOctets sysUpTime ifSpeed

Previous polling time. Polling interval. The number of received octets. The number of transmitted octets. System boot time. Current network bandwidth.

In order to determine the utilization of an ethernet network, the input and output traffic must be added, and then the sum is to be divided by the maximum transmission speed. The ethernet traffic analysis equation is given by equation (3). (if InOctets(x+t) − if InOctets(x) + if OutOctets(x+t) − if OutOctets(x) ) × 8 × 100 (sysU ptime(x+t) − sysU pT ime(x) ) × if Speed × 10 (3)

The utilization of the system is the sum of memory utilization, CPU average utilization, and disc utilization, as shown in equation (4) The variables used to measure the utilization of the system in this paper are listed in table 2.


233

Table 2. The variables of system utilization Item

Explanation

memTotalSwap memAvailSwap memTotalReal memAvailReal memTotalFree laLoad x dskTotal dskAvail dskUsed

The The The The The The The The The

total space of swap memory. available space of swap memory. total space of physical memory. available space of physical memory. total space of free memory. average load of CPU for x minutes. total disk space. available disk space. used disk space.

Sys U tilizationi = memSwapLoadi + laLoadi + dskLoadi

(4)

In order to determine the utilization of a system, the memory utilization and CPU utilization and disk utilization must be added. The calculation equation of system utilization is given below: memSwapLoadi = memRealLoadi =

memT otalSwapi − memAvailSwapi × 100 memT otalSwapi

(5)

memT otalReali − memAvailReali × 100 memT otalReali

(6)

laLoad = laLoadx × 100 dskLoadi =

dskU sedi × 100 dskT otali

(7) (8)

Equation (5) is used to calculate the use rate of swap memory using the memTotalSwap value and the memAvailSwap value. Equation (6) is to calculate the utilization of physical memory using the memTotalReal value and the memAvailReal value. Equation (7) is to calculate the average utilization of CPU for x minutes by percent. Equation (8) is to calculate the utilization of disc using the dskTotal value and the dskUsed value.

3

Implementation and Experiment

The differentiated Web service system proposed in this paper is implemented using a Linux Kernel 2.4.7 and PCs with a Pentium-III 800Mhz processor and a 256MB RAM, while the test environment is built by networking three clients, one load balancer, two servers, and one monitoring server. An Apache Web Server 2.4.17 is modified for the Web server, and a Montavista realtime scheduler is added to the Linux kernel. In this paper, HP’s httperf program, and AB(Apache HTTP server Benchmark tool) that measure the response speed of the Apache server are used to evaluate the capability of Web server.

234

M.-S. Lee and C.-H. Park

Fig. 1. Experimental graphs of the ethernet and system utilization

Test are carried out for three cases: when the servers are not overloaded(test 1), when the servers are loaded (test 2), and when the servers are overloaded and some requests are subsequently stopped (test 3). In test 1, the virtual IP address is 165.229.192.14, the total number of connections 50000, the number of concurrent users per session 1, and the number of calls per session 50. Fig. 1(A) presents the results of the ethernet and system utilization which shows the reply changes of Web servers upon the three clients. As the servers are not overloaded, the graphs are almost the same. However, if Web servers capability 1.3 times better than the least connection scheduling, and 1.5 times better than the round-robin scheduling. In test 3, which uses same conditions as test 2. But the script code was formatted with such mechanism that the CPU load of real server 1 would increase. As shown in Fig. 1(C), the proposed mechanism realized 1.3 - 1.6 times better capability than other scheduling algorithms. It was because load balancing was precise owing to the periodical measure of present load of every real server.

4

Conclusion

To implement a differentiated Web service system that provides differentiated services according to information importance of user priority, this paper proposed three-level approaches : a kernel-level approach, an application-level approach and a dynamic load-balancing approach. In the kernel-level approach, a realtime scheduler is added to the kernel, while in the application-level approach, the load balancer is implemented using an IP-level masquerading technique and


235

tunneling technique. The performance of the load balancing system was tested in three different situations, and the results confirmed that the system supported differentiated Web services.

References 1. Fielding, R., Getys, J., Mogul, J., Frystyk, H., Berners-Lee, T.: Hypertext Transfer protocol HTTP/1.1, IETF (1997) 2. Bhatti, N., Bouch, A., Kuchinsky, A.: Integraing User perceived Quality into Web Server Design. In: Proc. of the 9th International World Wide Web Conference, Amsterdam, Netherlands, pp. 92–115 (2000) 3. Vasiliou, N., Lutfiyya, H.: Providing a Differentiated Quality of Service in a World Wide Web Server. In: Proc. of the Performance and Architecture of Web Servers Workshop, Santa Clara, California, USA, pp. 14–20 (2000) 4. Apach Group, http://www.apache.org/ 5. Bhatti, R., Friedrich, R.: Web Server Support for Tiered Services. IEEE Network, 64–71 (1999) 6. Yoshikawa, C., Chun, B., Eastharn, P., Vahdat, A., Anderson, T., Culler, D.: Using Smart Client to Build Scalable Services. In: USENIX 1997 (1997), http://now.cs.berkeley.edu/ 7. Kwan, T.T., McGrath, R.E., Reed, D.A.: NCSA’s World Wide Web Server: Design and Performance. IEEE Computer, 68–74 (1995) 8. Dahlin, A., Froberg, M., Walerud, J., Winroth, P.: EDDIE: A Robust and Scalable Internet Server (1998), http://www.eddieware.org/ 9. Engelschall, R.S.: Engelschall, Load Balancing Your Web Site: Practical Approaches for Distributing HTTP Traffic. Web Techniques Magazine 3 (1998), http://www.webtechniques.com 10. Walker, E.: pWEB - A Parallel Web Server Harness (1997), http://www.ihpc.nus.edu.sg/STAFF/edward/pweb.html 11. Andresen, D., Yang, T., Ibarra, O.H.: Toward a Scalable Distributed WWW Server on Workstation Clusters. In: Proc. of 10th IEE Intl. Symp. of Parallel Processing (IPPS 1996), pp. 850–856 (1996) 12. Anderson, E., Patterson, D., Brewer, E.: The Magicrouter: an Application of Fast Packet Interposing (1996), http://www.cs.berkeley.edu/~ eanders/magicrouter/ 13. Zhang, W.: Linux Virtual Server Project (1998), http://proxy.iinchina.net/~ wensong/ippfvs 14. Montavista Software, http://www.montavista.com

On the Manipulation of JPEG2000, In-Flight, Using Active Components on Next Generation Satellites L. Sacks1, H.K. Sellappan1, S. Zachariadis2, S. Bhatti2, P. Kirstein2, W. Fritsche3, G. Gessler3, and K. Mayer3 1

Department of Electronic & Electrical Engineering, University College London, London, UK 2 Department of Computer Science University College London, London, UK 3 IABG mbH, Ottobrunn, Germany

1 Introduction This paper describes two approaches to manipulating JPEG2000 frames with programmable and active networks. The first approach is the use of transcoding and the second is intelligent dropping. These two approaches where considered, in particular, for possible deployment with space based platforms; specifically, communication satellites which are not only IP enabled but may host active components. Each approach offers different possibilities and may be suitable for solving overlapping but different problems. The work presented here brings together a number of background technical developments from the communications satellite world, video-coding and intelligent programming models. A detailed look at the developments of satellite based communication platforms shows that there is the possibility of a fully IP enabled system, supporting multicast and quality of service in space. This not only opens a range of possibilities, but presents new challenges. Further, emerging coding schemes open up new possibilities for manipulation of content within the networks. JPEG2000 was used as an example of the next generation of scalable codecs and it has been found that it lends its self easily to helping the kind of problems considered here, although much of these developments can be applied to other coding schemes. The two scenarios considered in detail in this paper – intelligent dropping and transcoding – show two approaches to coping with varying available bandwidth, as will be available with DVB-S2. They also illustrate two approaches to programmable networks. Intelligent dropping is best performed by dedicated systems where queuing is performed (for example routers in the input to link modulators) and so is best managed through Policies. Transcoding, in contrast, is codec specific and needs to be performed with a procedural language; it is thus an excellent example of an application level active networking technology. The possibility of network level active networking is not demonstrated by these, but is considered as a general issue in this context. The work presented here was initiated and funded by the European Space Agency (ESA), European Space Research and Technology Centre (ESTEC) ARTES 1 program. The complete project report will be made available in due time. The brief was to undertake a “study addressing the use of Active and Programmable Networking in Space and Ground Segment, to improve the delivery of Multimedia Services over Satellite”. The project covered a wide range of issues including architectural issues, D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 236–246, 2009. © IFIP International Federation for Information Processing 2009

On the Manipulation of JPEG2000

237

candidate technologies, standards, performance and security. It also included two demonstrations. The work presented here reflects this project with an emphasis on the demonstrations developed (it should be noted that the intelligent dropping scenario discussed in this paper was developed with Mr. Sellappan, as part of his MSc, and is not identical with that used in the study). Section 2 discusses the architectural issues both from the high level and business model perspective and considering some details of the space segment. Section 3 reviews some technologies used in this study. In particular it looks at the evolution of satellite platforms for broadcast media, JPEG20000 and SATIN, the mobile code technology used here. Section 4 reviews a number of applications for active networking in this context and outlines in more detail the two target scenarios of intelligent dropping and transcending.

2 Architectural Issues To understand the application of active networking to satellite telecommunications it is important to develop a high level architecture and business model, describing both ways in which the technologies may be applied and the roles of organisations and players involved. It is also important to consider the detailed architecture of the space platform, as this is one of the least versatile components and has the most stringent performance requirements. 2.1 The High Level Architecture The high level architecture and context of the technologies discussed here is not well defined; but is open to a number of scenarios, depending on business and application needs. To understand the overall concept, we define the basic service scenario in which some media (still images or a video stream) is sent from a single source to one or several users; and transits a satellite link. There may or may not be wide area or local area networks on the user side as the users may, for example, be within an organisation owning a satellite receive, they may be using a VSAT device or the satellite link may be providing a distribution system between two internet service providers. In our context we define the following roles (which, of course, may be taken by one or several players depending on the details of the business model). The Media Provider owns the content which may be in any format. Optionally, the media provider may participate ‘actively’ in the service by having a server which can encode the content in JPEG2000 format. As an alternative, the server may provide content in other formats which are encoded on the fly at the satellite link ingress. For the intelligent dropping scenario, the ingress point has to be involved in order to prioritise packets and add information to the data stream to support this. In either case, the satellite is considered there to be an active component in which specific flows can be directed to programmable components for treatment (e.g. trancoding or intelligent dropping). Finally, the stream may either be re-coded to it original format at an egress active component, or may be sent directly to a terminal devices which can either directly decode the content through resident or downloaded components. The final role in this high level model is the Active Components Provider which hosts the active components to be diploid in each appropriate node as required. In practice this role may be played by a third party, the content provider or the satellite service provider.

238

L. Sacks et al.

Media Provider Ingress Nodes

Egress Node Satellite Node

Active Component Provider

Users Fig. 1. High level Architecture

2.2 The Satellite Platform Architecture For this study our primary focus was on the functional description of the satellite platform. For this we defined a detailed architecture as a starting point for developing a standard and the appropriate functional requirements. This architecture was developed so as to define the full context for active services on a satellite platform. However we did not define control and management concepts for this. The Active components are expected to be hosted in a virtual machine run time environment such as the JavaVM. Within this context we defined four types of component. The Dynamic Components are those which constitute the active service and are deployed on demand. To support these, we defined two sets of components which interact via the same semantics and interfaces as the dynamic components; the Interface and Resident components. The Interface components allow the service to interact with the infrastructure of the satellite and the Resident components allow the service to receive and send the stream data. The final class of components in the execution environment are those which manage the location and deployment of the active components themselves. Around the execution environment is the transport system and the platform infrastructure. The transport system comprises the DVB and MPEG (multiplex) capabilities; and some sense of switching or routing capability. The transport system has to be capable of re-directing appropriate flows to the active components as required and so would integrate with an active routing technology (which was not explored in this study). Further, the transport system can be controlled through policies from the active components. The control through policies represents a second, widely accepted, view of active networking and thus our system facilitates both application level active networking and policy based programmability. Both of these are useful and have been explored in this study. The infrastructure of the satellite platform is accessed to retrieve and, possibly, manipulate key capabilities. For example the action of an active

Deployer/Registrar Registrar Deployer/

Edu.UCL.satin … Edu.UCL.satin …

JVM:J2ME:CDC

239

JNI


Sat Platform

IF-LMU Platform IF

PAN Resources Dynamic -LMU Dynamic -

Res -LMU Flow - IF Processing Resources

‘IP’ Layer Comms Control

Encap/ Decap

demod demod

Switching

mod mod

Fig. 2. Satellite Active Architecture

component may need to know the quality of the down link (discussed in detail below), the state of IP queues in the switch/router or the current loading on the execution environment resources (CPU and Memory). The function of the resident components is to provide consistent interfaces to the dynamic components, which preserving the security and integrity of the satellites systems. Although components to be deployed may be checked ‘off line’ and will be certified, it is still important that the platform is capable of protecting its self. Thus the Interface components would not just provide APIs, but should restrict and schedule access to the platform; and should monitor for integrity issues such as deadlock and livelock situations.

3 Technologies This section discusses the technologies used to demonstrate transcoding and intelligent dropping with JPEG2000. The overall project reviewed a range of possible technologies, both for media transport and programmable network implementation. The SATIN mobile code platform was selected as an interesting example of a framework for reasons discussed below. JPEG2000 was selected as an interesting scalable codec, compatible with a wide range of future applications. 3.1 The Programmable Component System: SATIN We used the SATIN [1] platform to implement our active network system. SATIN is a component metamodel, which can be used to build adaptable systems. It is instantiated

240

L. Sacks et al.

as a middleware system, which can adapt itself or component based applications which run on top of it. Its use as an active networking platform was initially outlined as a case study in [2]. SATIN uses the principles of reflection and logical mobility to offer adaptation primitives, and offers them as first class citizens to applications. Reflection offers a meta-interface to the system, that allows SATIN applications discover which components are available locally, to be notified of changes in component availability, to load and discard components, to discover the interfaces that they offer and to read and write metadata attached to a component. Logical mobility allows SATIN systems to send and receive components, classes, objects and data. SATIN was designed for mobile devices and devices with limited resources, such as mobile phones and PDAs, and is implemented using Java 2 Micro Edition (Connected Device Configuration / Personal Profile). It occupies 150329 bytes of memory, and provides the following services which are relevant to an active networking system: •

• • • •

Reflection. The use of reflection allows the system to reason about what it can currently do, dynamically invoke components, use an event service which notifies when there are changes in component availability, and to discover new APIs that are offered by components. Logical Mobility. The use of logical mobility allows components to be dynamically transfered from one SATIN node to another. Dynamic Component Instantiation. Components can be dynamically discovered, instantiated and invoked. Advertising and Discovery. SATIN provides an adaptable framework for component advertising and discovery. Security. SATIN nodes can employ digital signatures and trust mechanisms to verify incoming components. Moreover, SATIN uses the Java sandbox to instantiate components in.

In conclusion, SATIN is a small footprint middleware system that can be used to build adaptable systems. It provides a minimal runtime API that can be used to discover, request, deploy and invoke new components and an interface to reason about what individual components or the system itself can do. 3.2 The JPEG2000 Codec The final component used in this study was the JPEG2000 scalable codec. The fast expansion of multimedia and Internet applications led to the development of a new still image compression standard, JPEG2000 [3]. This image coding system uses latest compression techniques based on wavelet technology. Designed to complement the older JPEG standard, JPEG2000 provides low bit-rate operation, error resilience and superior compression index. Some of the important features of JPEG2000 are lossless and lossy compression, progressive transmission by resolution or component and region-of-interest (ROI) coding. In JPEG2000, images are typically divided into multiple tiles and encoded independently. This is done to avoid the need for complex and powerful processors when loading and encoding huge images in hardware. The Discrete Wavelet Transformation (DWT) is designed for this purpose. A tile-component is referred to a tile which consists of only one colour component. Each tile-component is then further divided down to different


241

resolutions and sub-bands with the use of DWT. Each resolution is then divided into multiple precincts which identify a geometric position of a tile-component of an image. Furthermore, each sub-band at each resolution is divided into multiple code-blocks, which will be coded into individual packets. The packets are arranged in the codestream following a particular progression order specified at the encoder. Motion JPEG2000 (MJ2) has been defined in part III of the JPEG2000 standard [5] for compression and encoding of time sequences of images, like video streams. The standard was developed to generate highly scalable compressed video, which can be easily edited. Thus, MJ2 does not include motion compensation and every frame in the video stream is individually encoded [6]. The concept of intra-frame coding reduces the complexity of inter-frame interdependencies found in other video codec. Since each frame is treated like a still image, a single codec can be used for both JPEG2000 still pictures and MJ2 video compression and encoding.

Pixel Depth (SNR) coding

Code Stream Æ Sequence Progressively resolution coding

Fig. 3. JPEG2000 Coding by Resolution and SNR [4]

A key feature of JPEG2000 is that it supports two forms of scalability. The first SNR scaling can progressively reduce the amount of information per pixel. This may be performed in a number of ways, on the various coding layers. The affect of SNR scaling is shown in Figure 4. The second form of scaling is progressive resolution coding. This effectively changes then size of the transmitted frame. Illustrated in Figure 3 is the organisation of the JPEG2000 code stream. Four levels of resolution coding are shown. The dark square is a low resolution image, when combined with the neighbouring three code blocks; a higher resolution image is formed. This is then repeated with the next two sets of three code blocks. At the same time the number of bits per pixel (bpp) represents the SNR coding depth. 3.3 Satellite Transport At present, the trend of satellite communication is heading towards deployment of next generation broadband satellites that provides multimedia applications with high demands for quality and availability of service. In line with the anticipated advancement and to meet the growing demand for high data rates, much research has been focused on regenerative and full on board processing (OBP) payloads, advance mesh

242

L. Sacks et al.

antennae, high speed communication system, optical satellite links, high speed transponders and miniaturisation of satellite components [7, 8]. The first regenerative satellite payloads are operational or under construction, performing on-board MPEG-2 cell multiplexing and switching (e.g. Skyplex or AmerHis) or ATM cell switching (e.g. WEST and WEB 2000 architecture), and the UK-DMC satellite even implements an IP stack. It is foreseeable that future communication satellites will implement an IP stack and on top of this a programmable network platform. Future generations of communication satellites may support a range of new capabilities. The most immediate is the emergence of DVB-S2[9], an effective upgrade of the current Digital Video Broadcast over Satellite (DVB-S) transport technology, which is the dominant means for transporting most broadcast video to date. DVB-S2 includes adaptive Forward Error Correction (FEC) which means that the up and down link data capacities can adapt to changes in fading, for example from varying cloud cover. This also means, however, that both the up and down link transport capacities may independently vary; increasing with weaker FEC and contracting as stronger FEC is required. Each FEC frame has fixed size of either 64,800 bits for normal FEC frame or 16,200 bits for short FEC frame. Depending on the FEC code rates, the capacity of the frames may be anything between these limits. Further, work is already progressing on IP enabled capabilities for satellites. Although this may not be an obvious thing by its self, combined with developments in tuneable, multiple footprint platforms, we see a model of a satellite which not only may have to do routing, but multicast and some amount of Quality of Service management. Standards for DVB over IP are already in progress – and so we see the emergence of true IP based broadcast architecture.

4 Active Services in Satellites A wide range of applications scenarios can be considered for application in the architecture described above. The following is a list of applications considered in some detail in the study. • • •

•

•

Reliable Multicast (RM) scenario: In the RM scenario, active networking may be used to load RM protocol instances and FEC codecs to relevant network nodes on demand while runtime. Intelligent Dropping (ID) scenario: In the ID scenario, intelligent dropping processes (or just policies) that evaluated the priority of packets or streams are loaded dynamically via PAN to satellite nodes that have to drop packets. Transcoding (TC) scenario: In the TC scenario, via active networking transcoders are controlled and loaded dynamically by satellite network nodes in order to adapt parameters (e.g. codec, data rate, etc.) of multimedia streams to network conditions or user requirements. MHP scenario: In the Multimedia Home Platform (MHP) scenario an intelligent process in the satellite routes certain MHP content only to specific spot beams and performs user feedback aggregation. via active networking, the intelligent process could be loaded by the satellite and adapted to new applications. MPEG-4 scenario: In the MPEG-4 multiplexing scenario content from different sources composing a single MPEG-4 scene are multiplexed in the satellite. via


• •

243

active networking, the composition software can be loaded by the satellite and controlled from the base station. Advanced network management: In the advanced network management scenario, management or monitoring software is adapted on demand to operator needs via a active networking system. Advanced caching scenario: Caching software is loaded, updated, and controlled on demand via a active networking system in order to adapt the caching software to applications and services.

These scenarios represent a broad range of; applications, network and policy level programmable network problems. The scenarios described below focus on application level and policy level approaches. Both cases are to do with manipulating JPEG2000 images. Both where implemented on PC based test-beds and used the Java JJ2000 implementation [10] available from EPFL. At this time, there is no reference satellite platform defined for developing and testing the kind of applications discussed here; and one of the outputs from the Arties 1 project was the recommendation that such a platform be developed. 4.1 The Transcoding Scenario The issue of transcoding has been widely explored (see for example [11]). This transcoding scenario considers a stream of JPEG2000 images, possibly forming a moving image and which requires that a constant frame rate is preserved (or considers cases where the download latency is just to slow for ‘full fat’ images). Issues impeding this can arise in a satellite situation when, for example, the down-link FEC reduces the available link bandwidth. It may also occur if there is routing in the satellite platform, which may have multiple foot prints. There are then two options; reduce the resolution or change the information depth (SNR) of the picture as illustrated in Figure 4. The former of these may be preferred if, for example, the terminal devices has a small screen.

Fig. 4. SNR Progressive coding (3.55bpp, .355bpp, .0355bpp and -0.009bpp)

To implement this application the following functions are performed, with regard to the reference architecture (shown in Figure 1): • •

The Media Provider may re-code the images in JPEG2000 format. This may, optionally, be performed on the Ingress Node. The Satellite Node hosts the active components, loaded from the Active Component Provider.

244

•

L. Sacks et al.

If the stream is encoded at the Ingress Node, it should be decoded back to the originating format at the Egress Node. Otherwise the User should have the appropriate decoder.

On the satellite node, the active component is loaded as a Dynamic Component. It should then have access to the link capacity from the modulator (Figure 2) to discover the available down link capacity and decide how to transcode the image. It should, of course, also know the rate at which the images are being sent for the target stream and the overall downlink load. Implementation of the transcoding component may be approached in a number of ways. Within the scope of the ARTIS project, and expedient approach was taken and the encoder and decoder provided with [10] where used. However, the code streams of JPEG2000 are so designed that significant efficiency gains may be had. The resolution transcoding is the most straightforward as can be seen from Figure 3, this requires simply that the code stream is truncated at the right place. In this respect, it is similar to the intelligent dropping scenario below. SNR progressive scaling is more complex and detailed information about each tile is required. Never the less, these are all integer operations and so can be quite efficient from the performance perspective. 4.2 The Intelligent Dropping Scenario As with the transcoding scenario, intelligent dropping may be appropriate when constant frame rates are required in the presence of congestion or reduced link capacity. However it maybe that there are queuing mechanisms involved which by default drop packets randomly – where by randomly we mean, with out regard to the contents of the packets. The impact of this can be seen in Figure 5 in which the first image is the reference graphic and the second has 1% of packets lost at random. Of course, it is possible that dropping packets has little impact and the figure here shows a bad case, although not unusual.

Fig. 5. Intelligent Dropping (0% loss, 1% Random loss, 80% intelligent dropping)

The effect seen, can be understood with reference to Figure 3. It can be seen that if a packet containing the lowest resolution ‘thumbprint’ of the coded image is lost, recovering the graphic will be almost impossible and the impact becomes progressively less server as the outer code blocks are lost. Thus, prioritising loss progressively, following the flow of the codec would allow a more graceful information loss; and allowing for this was part of the initial intent of the JPEG2000 technology. The last image in Figure 5 has 80% of its data dropped, but using low priority packets.


245

Architecturally, the implementation of intelligent dropping is similar to the transcoding scenario. The two key changes are the introduction of an intelligent, adaptive encapsulateor at the satellite ingress point and the control of the dropping mechanism in the space segment. These are shown in Figure 5. Intelligent Dropping Service

Link Quality & Congestion Feedback

Link quality Feedback

Satellite (Active Node)

Satellite RF Link

Intelligent Dropping Service

Video Recorder (Source)

Motion JPEG 2000 Encoder

Satellite TX Terminal

Active Encapsulator

Satellite RX Terminal

LDPC & FEC feedback (max DFL)

Active Decapsulator

Motion JPEG 2000 Decoder

Video Player (Sink)

Fig. 6. The Intelligent Dropping Architecture

In this architecture [12], the active encapsultor has two jobs. The first is to decide, depending on things like link quality, how to place the JPEG2000 code stream in the IP packets. There is an important trade off here as, on the one hand, the finer the granularity this is done at the more precisely the available band width can be matched; but the overheads are increased. Too course a granularity and the quality of the image will be degraded too quickly. The second job is to add a header which describes the priority of the packets as well as which is the; first, last and sequence number of the packets of a given video frame. The ingress point can drop packets in response to the uplink quality as can the satellite platform its self. On the satellite platform, the condition of packet dropping can be controlled with policies transported via any policy management framework. Finally, the satellite egress point has to extract and reassemble the code stream.

5 Conclusions This paper has reviewed the issues which arise when considering the role of programmable and active networking in the context of satellite based telecommunications. We have motivated the plausibility of such an architecture by considering the evolutionary path of telecommunications satellites. We have also tried to motivate the advantages of considering placing active components on the satellites themselves. Indeed, throughout our project trying to understand where the business advantage come has been more difficult then considering its technical viability. However, if we consider the combination of factors such as the adaptive FEC, multiple, tuneable footprints with onboard routing or switching, the importance of on-board processing

246

L. Sacks et al.

becomes more apparent. Finally, it is important to note that the timescales of satellite deployment are long compared to those in the fixed network world, so it is very difficult to know which application level protocols will be used once the satellites are commissioned. Thus, if it is important to have intelligence in the satellite at all, it is important that that intelligence is adaptable both to protocols and codecs which might emerge in the future; and can adapt to local conditions (such as link capacity variation and congestion). To emphases these issues of adaptation we have both used a codec which is very much in development and have explored how adapting to local conditions can be used to improve application performance in the face of degraded transport (down link) quality.

References [1] Zachariadis, S., Mascolo, C., Emmerich, W.: SATIN: A Component Model for Mobile Self- Organisation. In: International Symposium on Distributed Objects and Applications (DOA), Agia Napa, Cyprus. Springer, Heidelberg (2004) [2] Zachariadis, S., Mascolo, C., Emmerich, W.: Exploiting Logical Mobility in Mobile Computing Middleware. In: Proceedings of the IEEE International Workshop on Mobile Teamwork Support, Collocated with ICDCS 2002, pp. 385–386 (July 2002) [3] Boliek, M., Christopoulos, C., Majani, E. (eds.): JPEG 2000 Part I Final Draft International Standard (ISO/IEC FDIS15444-1), ISO/IEC JTC1/SC29/WG1 N1855 (August 2000) [4] Marcellin, M., Gormish, M., Bilgin, A., Boliek, M.: An Overview of JPEG 2000. In: Proceedings of IEEE Data Compression Conference, Snowbird, Utah (March 2000) [5] Information technology - JPEG 2000 image coding system - Part 3: Motion JPEG 2000, ISO/IEC 15444-3 (2002) [6] Dagher, J., Bilgin, A., Marcellin, M.: Resource-Constrained Rate Control for Motion JPEG 2000. IEEE Transactions on Image Processing 12(12), 1522–1529 (2003) [7] Iida, T., Suzuki, Y.: Communications satellite R&D for next 30 years. Space Communications 17, 271–277 (2001) [8] Verma, S., Wiswell, E.: Next Generation Broadband Satellite Communication Systems. In: 20th AIAA International Communication Satellite Systems Conference and Exhibit, Montreal, Quebec, May 12-15 (2002) [9] ETSI: Final Draft EN 302 307 (v.1.1.1) Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications (DVB-S2) (January 2005), http://www.etsi.org [10] http://jj2000.epfl.ch/ [11] Gibson, J.D.: Multimedia Communications: Directions and Innovations. Academic Press, London (2000) [12] Sellappan, H.K.: Active Networks in Satellite Communications: Intelligent Dropping Scenario for Motion JPEG 2000 Transmission MSc. Dissertation, UCL 2005 (2005)

TAON: A Topology-Oriented Active Overlay Network Protocol Xinli Huang, Fanyuan Ma, and Wenju Zhang Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai, P.R. China, 200030 {huang-xl,ma-fy,zwj03}@sjtu.edu.cn

Abstract. Built upon overlay topologies, Peer-to-Peer (P2P) networks behave in an ad-hoc way, conduct application-layer routing, enable usercustomized decentralized resources sharing, and thus can be taken as an emerging representative of Active Networks. An important problem in current unstructured P2P networks is that, however, existing searching mechanisms do not scale well because they are either based on the idea of flooding the network with queries or because they know very little about the nature of the network topology. In this paper, we propose the Topology-oriented Active Overlay Network (TAON) which is an efficient, scalable yet simple protocol for improving decentralized resources sharing in P2P networks. TAON consists of three novel components: a Desirable Topology Construction and Adaptation algorithm to guide the evolution of the overlay topology towards a small-world-like graph, a Semanticbased Neighbor Selection Scheme to conduct an online neighbor ranking, and a Topology-aware Intelligent Search mechanism to forward incoming queries to deliberately selected neighbors. We deploy and compare TAON with a number of other distributed search techniques over static and dynamic environments, and the results indicate that TAON outperforms its competitors by achieving higher recall rate while using much less network resources, in both of the above environments.

1

Introduction

In contrast to traditional data networks, Active Networks not only allow the network nodes to perform computations on the data but also allow their users to inject customized programs into the nodes of the network, that may modify, store or redirect the user data flowing through the network [1]. These programmable networks open many new doors for possible applications that were unimaginable with traditional data networks. For example, Peer-to-Peer (P2P) overlay networks conduct application-layer routing in an ad-hoc way, enable user-customized decentralized resources sharing, and thus can be taken as an emerging representative of Active Networks.

This research work is supported in part by the the National High Technology Research and Development Program of China (863 Program), under Grant No. 2004AA104270.


248

X. Huang, F. Ma, and W. Zhang

The most dominate application in use on current P2P networks is large-scale distributed file sharing, especially the Web-based search applications. YouSearch [2] maintains a centralized search registry for query routing, making it difficult to adapt the search process to the heterogeneous and dynamic contexts of the peer users. A more distributed approach is to completely decentralize search, as in Gnutella [3]. Queries are sent and forwarded blindly by each peer. But since the peer network topology is uncorrelated with the interests of the peer users, peers are flooded by requests and cannot effectively manage the ensuing traffic. Adaptive, content based routing has been proposed to overcome this difficulty in the file sharing setting. NeuroGrid [4] employs a learning mechanism to adjust metadata describing the contents of nodes. A similar idea has been proposed to distribute and personalize Web search using a query-based model and collaborative filtering [5]. Search however is disjoint from crawling, making it necessary to rely on centralized search engines for content. The major limitation of these systems lies in their relatively poor search performance and ignorance of the nature of the underlying topology, which results in fatal scaling problem. To address the scalability limitations mentioned above, we in this paper consider the Web information retrieval problem and propose a Topology-oriented Active Overlay Network (TAON ) protocol. TAON allows for symbiotic interactions of Web crawling and searching, whereby a peer can vertically adapt to its users’s search interests, while horizontally peers can achieve better coverage by learning to collaboratively route and respond to queries. TAON consists of three key components: a Desirable Topology Construction and Adaptation algorithm to guide the evolution of the overlay topology towards a power-law graph, a Semantic-based Neighbor Selection scheme to conduct an online neighbor ranking, and a Topology-Aware Intelligent Search mechanism to forward incoming queries to deliberately selected neighbors. We predict that the resultant topology for such a network is a small world, allowing for any two peers to reach each other via a short path (small diameter) while maximizing the efficiency of communications within clustered peer communities. To evaluate the performance gains of TAON, we will deploy and compare TAON with a number of other distributed search techniques over static and dynamic environments, through extensive simulations. The rest of this paper is organized as follows: In Section 2, we detail the design of TAON. In Section 3 and 4, we present the experimental setup and the simulation results respectively. We conclude this paper in the last section.

2

TAON Design

The objective of TAON is to help the querying peer to find the most relevant answers to its query quickly and efficiently rather than finding the largest number of answers. To achieve this goal, TAON exploits both the semantic and geographical locality to construct small-world-like peer communities, by incorporating three novel techniques presented below respectively, in a very brief fashion due to the space limitation.

TAON: A Topology-Oriented Active Overlay Network Protocol

2.1

249

Desirable Topology Construction and Adaptation

The Desirable Topology Construction and Adaptation algorithm is the core component that connects the TAON node to the rest of the network. To obtain desirable overlay topology and sequentially adapt it towards a better one dynamically, we prefer to keeping the out-degree of the network following a powerlaw distribution, and expect that this unique topological property, together with the other two novel techniques (to be addressed in the Section 2.2 and 2.3), will produce the desired “small-world ” phenomena [6]. We achieve the goal by adding and deleting links in a way that the total number of outgoing links at each node is conserved. We choose a node A at random, build a link from this node to a new node B chosen by a certain metric, and then immediately delete an existing link say with C to conserve links at A. In addition, by increasing the fraction of links rewired we get the required short path length. If the fraction of links deleted and rewired is p, then for very small p the average path length L(p) comes down by orders of magnitude and is close to that of a random graph whereas the clustering coefficient C(p) is still much large similar to that of a regular graph [7]. 2.2

Semantic-Based Neighbor Selection

To decide to which peers a queries will be sent, a node ranks all its neighbors with respect to a given query. To do this, each node maintains a profile for each of its neighbor peers. The profile contains the list of the most recent past queries, which peers provided an answer for a particular query as well as the number of results that a particular peer returned. According to [8], we use the Cosine Similarity function below to compute the similarity between different queries: (q ∗ qi ) sim(q, qi ) = cos(q, qi ) = , (1) (q)2 ∗ (qi )2 where sim(q, qi ) is the similarity of the query q and the query qi , calculated by the cosine of the angle between the two vectors q and qi . Based on this similarity between queries, we then use the relevance function in [9] to rank the neighbor peers of a node P0 following: RP0 (Pi , q) = sim(qj , q)α ∗ S(Pi , qj ), (2) j

where α is a parameter allowing us to add more weight to the most similar queries, j is the ID of each query answered by Pi , S(Pi , qj ) is the number of results returned by Pi for query qj , RP0 (Pi , q) denotes the relevance rank function of Pi and is used by P0 to perform an online ranking of its neighbors. The R function allows us to rank higher the peers that returned more relevant results, and thus realizes the semantic-based neighborhood optimization. In addition, we also make this semantic-based better neighbor selection strategy be orthogonal to the physical proximity based strategy that is integrated into the Topology-aware Intelligent Search mechanism (Section 2.3).

250

2.3


Topology-Aware Intelligent Search

To make the TAON node in the overlay topology being aware of the physical proximity in the underlying network, we divide its neighbors into local neighbors and global neighbors. The fraction of neighbors that are local, called the proximity factor (α), is a key design parameter that governs the overall structure of the topology. Different values of α let us span the spectrum of this class of overlay topologies. In between these two ends of the spectrum, we foresee that the topologies, with many local links and a few global links, have desirable properties: They not only have low diameter, large search space and connectedness, but are also aware of the underlying network and can utilize these links better than the both topologies. We aim to find a suitable balance between these advantages by simulation through populating the range of α value. The combination of the Semantic-based Neighbor Selection and the Physical Proximity based Neighbor Discrimination ensure that increasing queries from a node P can be answered by its neighbor nodes or their nearby nodes in the overlay topology, and that many such answerers may be geographically close to the requester. These properties are especially useful for reducing response time and network resources consumption. Based on these techniques, we then develop a novel search mechanism, called Topology-aware Intelligent Search, to conduct a kind of bi-forked and directed search as follows: – flooding the incoming queries to all local neighbors with a much smaller TTL value than that of the standard Gnutella protocol. – forwarding the incoming queries to the first k best global neighbors using multiple random walks coupled with the mechanisms of termination checking and duplication avoiding proposed in [10]. Here, all the local and global neighbors are beforehand selected and optimized using the Semantic-based Neighbor Selection strategy, and are discriminated by their physical proximity.

3

Experimental Setup

TAON is designed to perform efficient, scalable yet simple Web-based search by exploiting the locality semantically and geographically. Hence, our experimental evaluation focuses on four performance metrics below: – recall rate, that is, the fraction of documents that the search mechanisms retrieves. – search efficiency, that is, the number of messages used to find the results as well as the required time to locate the results. – utilization of underlying network, measured by the traffic load on the links in the underlying network, according to [11]. – small-world statistics, as a indicator to show whether the network topology is being evolved towards a “small-world” graph, and measured using the factors of clustering coefficient and diameter.

TAON: A Topology-Oriented Active Overlay Network Protocol

251

Based on the PLOD topology generator [12], we create a simulator (in which the TAON protocol is implemented and deployed) that initiates a power-law overlay topology and allows users to run their queries over real indexes obtained from actual distributed Web crawlers. Our simulator takes a snapshot of the network for every time step, during which all of the peers process all of their buffered incoming messages and send them following the TAON protocol. This may include the generation of a local query as well as forwarding and responding to the queries received by other peers.

4

Simulation Results

In this section, we describe a series of experiments that attempt to investigate the performance gains of TAON over its competitors of a) Breadth First Search (BFS, i.e., Gnutella), b) Random Walks (RW), and the Most Results in Past (MRP, i.e., the technique proposed in [13]).

Fig. 1. Comparisons of Recall Rate (a), Messages (b), and Physical Latency to Results (c) between the four search techniques, and Small-World Statistics of the TAON network (d)

Fig.1.(a) and (b) indicate that BFS requires almost three times as many messages as its competitors with around 1, 230 messages per query. In contrast, all of RW, MRP and TAON use dramatically less messages but TAON is the one that finds the most documents. In addition, the curves in Fig.1.(c) shows clearly that TAON results in smaller physical latency than the other three techniques, which means a better utilization of the underlying physical network.

252


Fig.1.(d) shows that the diameter remains roughly equal to the initial random graph diameter, while the clustering coefficient increases rapidly and significantly, stabilizing around a value 100 ∼ 125% larger than that of the initial random graph. These conditions define the emergence of a “small world ” topology in the TAON network. This is a very interesting finding, indicating that the peer interactions cause the peers to route queries in such a way that communities of users with similar interests cluster together to find qualified results quickly, while it is still possible to reach any peer in a small number of steps.

5

Conclusions

The TAON protocol we proposed in this paper provably results in significant performance gains of both enhanced search efficiency and reduced traffic load, by explicitly guaranteeing the desirable topological properties like small-world properties, and by exploiting the semantic and geographical locality to form better neighborhood and peer communities dynamically.

References 1. David, L., David Sincoskie, W., Wetherall, D.J., Minden, G.J.: A Survey of Active Network Research. IEEE Transactions on Communications (1997) 2. Bawa, M., et al.: Make it fresh, make it quick searching a network of personal webservers. In: Proc. of 12th WWW (2003) 3. http://rfc-gnutella.sourceforge.net 4. Joseph, S.: Neurogrid: Semantically routing queries in Peer-to-Peer networks. In: Proc. of Intl. Work. P2P Computing (2002) 5. Pujol, J., Sang¨ uesa, R., Berm´ udez, J.: Porqpine: A distributed and collaborative search engine. In: Proc. of 12th WWW (2003) 6. Watts, D., Strogatz, S.: Collective dynamics of ‘small-world’ networks. Nature 393, 440–442 (1998) 7. Puniyani, A.R., Lukose, R.M., Huberman, B.A.: Intentional Walks on Scale Free Small Worlds. LANL archive: cond-mat/0107212 (2001) 8. Baeza-Yates, R.A., Ribeiro-Neto, B.A.: Modern Information Retrieval. ACM Press Series/Addison Wesley, New York (1999) 9. Zeinalipour-Yazti, D., Kalogeraki, V., Gunopulos, D.: Exploiting locality for scalable information retrieval in peer-to-peer networks. Information Systems 30(4), 277–298 (2005) 10. Lv, C., et al.: Search and replication in unstructured peer-to-peer networks. In: Proc. of ACM International Conference on Supercomputing (ICS) (June 2002) 11. Ripeanu, M., Foster, I., Iamnitchi, A.: Mapping the Gnutella Network: Properties of Large Scale Peer-to-Peer Systems and Implications for System Design. IEEE J. on Internet Computing, Special Issue on Peer-to-peer Networking (2002) 12. Palmer, C.R., Steffan, J.G.: Generating Network Topologies That Obey Powers. In: Proc. of Globecom 2000, San Francisco (November 2000) 13. Yang, B., Garcia-Molina, H.: Efficient Search in Peer-to-Peer Networks. In: Proc. of Int. Conf. on Distributed Computing Systems (2002)

A Biologically Inspired Service Architecture in Ubiquitous Computing Environments Frank Chiang and Robin Braun Faculty of Engineering, University of Technology Sydney, Broadway, NSW 2007, Australia [email protected]

Abstract. This paper describes the design of a scalable bio-mimetic framework in the management domain of complex Ubiquitous ServiceOriented Networks. An autonomous network service management platform - SwarmingNet is proposed. In this SwarmingNet architecture, the required network service processes are implemented by a group of highly diverse and autonomic objects. These objects are called TeleService Solons as elements of TeleService Holons, analogue to individual insects as particles of the whole colony. A group of TSSs have the capabilities of fulfilling the complex tasks relating to service discovery and service activation. We simulate a service configuration process for Multimedia Messaging Service, and a performance comparison is made between the bio-agents scheme and normal multi-agents scheme.

1

Introduction

The operational management of Next Generation Network (NGN) services is expected to be autonomous, scalable, interoperable and adaptable to the diverse, large-scale, highly distributed, and dynamically ever-changing network environment in the future. The functional management for them are also desired to be as simple as possible from the perspective of both designs and implementations. Current network management infrastructure is struggling to cope with these challenges. In contrast, social insects and biological organisms have developed relatively easy and efficient mechanisms to thrive in hostile, dynamic and uncertain environments after many years’ evolution and natural selection. Hence, taking advantages of the synthesis on full-scaled biological societies is of vital importance in achieving autonomic management in the future Ubiquitous ServiceOriented Network (USON) [1], which will dynamically connect human beings and home/office electronic appliances via distributed devices (e.g., cell phones, notebooks, PDAs) and applications running on these devices to enable services at any time, any places without constraints in quantity or frequency [2]. The aim of this paper is to propose a bio-swarming framework — SwarmingNet for network service managements. The biological platforms proposed by Suda [3] and Suzuki [4] are more emphasizing evolutionary behaviors of agents. The status of network services (mutation, clone, reproduction and replication) depends on D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 253–258, 2009. c IFIP International Federation for Information Processing 2009

254

F. Chiang and R. Braun

multi-agents’ internal states. These platforms are particularly complicated in terms of rapid practical application. We distinguish our framework from theirs by applying TeleSolon hierarchy1 concepts into hierarchical network management system which is analogue to the ecosystem in nature and colony structure in ants. We apply stigmergic ant-foraging behaviors into the threshold-based selforganization algorithm. This is much easier to be applied into practical embedded systems with industries. This paper is organized as follows: The design principles and our self-organized provisioning algorithm for event-based autonomic management architecture are mainly specified in section 2. The system-level architecture are included in section 2. Section 2.1 covers the definitions and theorem for the threshold-based self-organized algorithm. Service configuration process of MMS is simulated as an illustrative application, simulation results are shown in Section 3. Finally we conclude with performance comparisons and future work trends in section 4.

2

Design Principles

The incorporation of social insects paradigm into autonomic service configuration is believed to be the right solution to meet these requirements. This can be achieved by modelling networks as a distributed aggregation of self-organized autonomous TSS solons in our approach. This is similar to the social insects colony (networks) consisting of large amount of individual insect (solon). 2.1

Self-organized Service Provisioning and Algorithm

Future networks should not only provide basic connectivity but also intelligently and immediately enable on-demand services in pervasive computing environments at anywhere, anytime. Those services must be provisioned in a flexible and distributive way in highly dynamic runtime infrastructure. Thus, service deployment and management for devices in USON is extremely difficult since a provisioning infrastructure ought to cope with the high level of heterogeneity, degree of mobility, and also take into account limited device resources. In this context of self-organization, we describe the service provisioning as the ability to create, to remove, to reproduce, to reconfigure the instances of services at runtime. Moreover, the bio-mimetic agents running at particular network nodes, (1) measure the local demands for network services autonomically beyond other nodes; (2) reconfigure/reproduce local services when demands are detected; (3) remove the services when there are no demands of quantity. Self-organization Algorithm — This section defines the algorithm2 to enable self-organized bio-networks. This algorithm also considers the scalable design principle, such as adaptivity and robustness in distributed environment; localized 1 2

Due to the limitation of pages, details of THSs and TSSs can be referred to in the full version under requests. Details of this algorithm and proof can be referred to in full version of this paper.

A Biologically Inspired Service Architecture

255

decision making process based on neighborhood information. Hence, it is also a practical principle to consider only local customers who are not too far from the service center. The content-based event messaging system categorizes and stores the messages for different services into different space in information store (e.g., database). The following definitions as a whole define the problem domain in our service provisioning process. Our self-organization algorithm considers both the factors of time and space as follows: Definition 1. A dynamic threshold θ is configured for each requested service respectively; A parameter η is used to evaluate the keen degree for customers who require certain services; A parameter d represents Euclidean distance between available server of services and customers; The localized service zone ω is designated as ω(d) ≤ 10% · D, where D is the diameter value of the whole service area. Definition 2. A parameter τ evaluates the intensity of digital pheromone which are placed along the traces to servers in dispersed area by previous bio-agents. The intensity of digital pheromone measures how easy the service is available in the particular server the path gets to. Moreover, τ is related to the Euclidean distance d. Lemma 1. (Time) When customer requests are accumulated to the θ value, the service provisioning starts. This is a dynamic value varying in accordance with essence of specific services. For some reason, some services should be activated as soon as there is a demand for it. While some services can be activated only when there are enough number of requests; (Space) When the customer and services are both inside localized service zone, the service could be provisioned. Theorem 1. The self-organized process for service provisioning is activated successfully iff Lemma 1 and Lemma 2 are satisfied simultaneously. 2.2

System-Level Architecture

This architecture we propose here is partly depicted in Figure 1 of our paper [5]. We have to omit it due to page limitations. This systems-level architecture illustrates the combinatorial links among our three indiscerptible parts for autonomic service activation process: 1) Users; 2) Instrumentation support and measurement, monitoring; 3) Enhanced 4-layers TMF management model. Analogue to the biological society, we introduce the concept of ecosystem into the whole system which acts as the environment where agents create, live and die. We designate the energy exchange is the ”currency” between ecosystem components (e.g. swarm agents) and eco-environment.

3

Simulation and Experimental Measurement

We choose the Multimedia Messaging Service (MMS) as an evaluation application. As for the system-level architecture, the managed object in this context is MM Box (MultimediaMessaging Box); The product components are 1)

256


Gold MM Box (capacity=1000MB), 2) Silver MM Box (capacity=100MB), 3) Bronze MM Box (capacity=10MB). The events messages contain on-demanding service provisioning requests from clients, these messages include information about: 1) creation and deletion of users’ MM account in the product or 2) migration Multimedia Messaging (MM) account among the products – Gold, Silver and Bronze boxes. The service provisioning results indicate bio-inspired network management paradigm and maintain SLA compliance as well as efficient transaction time. Digital pheromone evaluates the degree of difficulty in activating or migrating MM accounts which are stored in MM servers in this context (The large intensity of digital pheromone means MM boxes are easier to be migrated from silver to gold, or from bronze to silver, etc.). The effectiveness of digital pheromone in MMS server configuration process in the framework has been tested. The service-configuration performance comparison between the bio-agents and normal agents are analyzed. Java classes R are built on the hybrid modelling platform AnyLogic . The experiment scenario is summarized here: The event messages with service requests from clients PC in our testbed will trigger the service configuration process whenever the service requests approach a service threshold θ ij where i represents the service ID, j represents the clients’ ID. We argue this is an autonomic process instead of an automatic paradigm because the θ ij value changes according to the requested service profiles and autonomic agents learn and decide the best threshold. Our adaptation strategies are not depending on a set of preconfigured rules like that in automatic system, on the contrary, the autonomy is achieved by goal setting and suggestion through learning and modification of the existing adaptation strategy. The multiplication ω of digital pheromone intensity and customer keen index will be considered as an important index in an exponential formula (e.g., exp(ω)), which determines which MM account will be configured to activate in certain MM servers. Service lifetime is calculated by multiplication of these two factors. Moreover, network vendor agents go through caché database for updated information being synchronized with our 4-layer structure which covers the specification files for products and services, and all the configuration files for resources (e.g., devices, equipment, etc.). Specifically, by taking into fact that service requests usually are provisioned by local servers, the factor d, an Euclidean distance measuring our virtual distance between service requests to MM server in the coordinate plane. If there are multiple servers meeting the requirement simultaneously, we will randomly pick up one of them. Figure 1 describes the overall simulation configurations in details. Figure 2 shows the parameters of 3 experimental scenarios which test the service provisioning. As shown in Figure 2 for Experiment 3, the number of MM servers is decreased till 100 while other parameters remain the same as above. 3.1

Experimental Results

Based on the three experimental test scenarios described in the previous subsection, the performance comparison between bio-agents and normal multi-agents

A Biologically Inspired Service Architecture

Topology

1000 virtual MM servers are uniformly distributed into an area [0, 280]

Event Parameters

Requests for on-demanding service are randomly generated by clients with fixed seed=1 over a time interval of 20 days Services lifetime are not permanent, they will deceased whenever there are no needs or termination willing from customers. {We give maximum_ service_lifetime = 1 day}

Space/Time Dynamics

Transaction time for each service requests dynamically change according to A = Customer_Keen_Index and B = Digital_Pheronmone_Intensity; In order to simplify the simulation factors, we set A=0.5; B = γ × d , (γ =0.5 or 0.6) where d = ( x − x1 ) 2 + ( y − y1 ) 2, d represents the Euclidean Distance between one particular service request and one particular MM server; Maximum duration for any certain service provisioning λ = 0.4 days Services configuration happen on those servers which are close to customers like in real world. We only provision the service distance d ≤ 30

257

Fig. 1. Experiment Description Digital_Pheromone_ Num_of_MM_Servers Initial_Value_Provision Intensity ed_Servers

Customer_Service_Keen _Index

Test 1

1000

0

0

0.5

Test 2

1000

0

0.6

0.5

Test 3

100

0

0.6

0.5

Fig. 2. Parameters for Experimental Test 1, 2 and 3

100

450

90 Service Provisioned for Services Requests (%)

Number of Current Provisioned Servers for Service Requests

Bio-inspired Service Provisioning Scheme

500

400 350 300 250 200 150 Biological agents scheme Normal agents scheme

100 50 0

Biological agents scheme Normal agents scheme

80 70 60 50 40 30 20 10

0

2

4

6

8

10

12

14

16

18

20

0 Low Client Nodes Density

High Client Nodes Density

Time in days

Fig. 3. Performance Comparison for Fig. 4. Service Configuring Percentage in Number of Servers Configured between Heterogeneous and Dynamic Network EnBiological Inspired Agents Scheme and vironment with Different Clients Density Normal Agents Scheme

258


without biological behaviors are presented in Figure 3. As we can see, the number of servers in service provisioning process is bigger for bio-inspired agent framework when the same quantity of service requests (=11692) arrives. Service configuration tasks, or workload are distributed uniformly into servers with a shorter response time, and performance for load balancing is also optimized by this bio-inspired framework. We calculate the percentage of configured service of the total number of services, which though are finally provisioned respectively in the low client node density (=100 in the fixed area) and high client node density (=1000 in the fixed area). In low client requests environment, service configured percentage is 72%, which is higher than that in high client requests environment. However, our biological agents scheme results in better service configured percentages in the same environment as those normal multi-agent schemes. Details are illustrated in Figure 4.

4

Conclusion and Future Work

Firstly, we conclude that our bio-inspired multi-agent framework provides a solution to envision future autonomic service management system. This framework outperforms the current normal multi-agent based system in terms of service discovery and service assurance for future IP networks. Secondly, this framework does not rely on particular types of insects societies or colonies, i.e. agents could be entities in USON ranging from any hardware devices to robotic agents, or biologically-inspired software elements. Finally, our future work will specifically focus on the performance comparison among Particle Swarm Optimization (PSO), Ant Colony Optimization (ACO), and Genetic Algorithm (GA) with regards to efficient service configuration issues on the basis of this framework.

References 1. Yamazaki, K.: Research directions for ubiquitous services. In: Proceedings of International Symposium on Applications and the Internet, p. 12 (2004) 2. Suzuki, K.: Ubiquitous services and networking: monitoring the real world. In: Proceedings of ISAI, p. 11 (2004) 3. Nakano, T., Suda, T.: Self-organizing network services with evolutionary adaptation. IEEE Transactions on Neural Networks 16(5), 1269–1278 (2005) 4. Makinae, N., Suzuki, H., Minamoto, S.: Communication platform for service operations systems in advanced intelligent network. In: IEEE International Conference on Communications, vol. 2, pp. 872–877 (1997) 5. Chiang, F., Braun, R., Magrath, S., Markovits, S.: Autonomic service configuration in telecommunication mass with extended role-based Gaia and Jadex. In: Proceedings of IEEE International Conference on Service Systems and Service Management, vol. 2, pp. 1319–1324 (2005)

Author Index

Ardon, Sébastien

145

Baldi, Mario 28 Banfield, Mark 83 Bhatti, S. 236 Bless, Roland 121 Bonnet, Christian 224 Boschi, Elisa 1 Bossardt, Matthias 1 Braun, Robin 194, 253 Chaudier, Martine 96 Chiang, Frank 253 Choi, Eunmi 212 Chrysoulas, Christos 206 Dedinski, I. 13 De Meer, H. 13 Denazis, Spyros 108, 206 D¨ ubendorfer, Thomas 1 Eyal, Amir

194

Farkas, K´ aroly 53 Filali, Fethi 224 Fritsche, W. 236 Gamer, Thomas 121 Gelas, Jean-Patrick 96 Gessler, G. 236 ´ G´ omez, Angel M. 200 Haas, Robert 108, 206 Haleplidis, Evangelos 108, 206 Han, L. 13 Han, Sang Man 218 H¨ arri, Jérˆ ome 224 Huang, Xinli 247 Hug, Hanspeter 53 Hutchison, David 83, 132 Jameel, Hassan

218

Kalim, Umar 218 Kim, Myung-Kyun Kirstein, P. 236

182

Kloul, Le¨ıla 168 Koufopavlou, Odysseas

108, 206

LakshmiPriya, T.K.S. 38 Leduc, Guy 156 Lee, Junggyum 212 Lee, Myung-Sub 230 Lee, Sungyoung 218 Lee, Young-Koo 218 Lefèvre, Laurent 96 Leopold, Helmut 83 Levitt, Karl 65 Lockwood, John 188 Lopez-Soler, Juan M. 200 Ma, Fanyuan 247 Martin, Sylvain 156 Mathy, L. 13 Mauthe, A. 132 Mayer, K. 236 Min, Dugki 212 Mokhtari, Amdjed 168 Park, Chang-Hyeon 230 Parthasarathi, Ranjani 38 Pezaros, D.P. 13 Phu, Phung Huu 182 Plattner, Bernhard 53 Portmann, Marius 145 Ramos-Mu˜ noz, Juan J. Risso, Fulvio 28 Ruf, Lukas 53

200

Sacks, L. 236 Sajjad, Ali 218 Sch¨ oller, Marcus 121 Sellappan, H.K. 236 Sénac, Patrick 145 Sifalakis, M. 132 Smith, Paul 83 Sproull, Todd 188 Sterbenz, James P.G. 83 Sventek, J.S. 13

260

Author Index

Tylutki, Marcus Xie, Linlin

65

Zhan, X.Y.

83

Yi, Myeongjae

Zachariadis, S. Zhang, Wenju

182

236

13 247

Zitterbart, Martina

121

Active and Programmable Networks: IFIP TC6 7th International Working Conference, IWAN 2005, Sophia Antipolis, France, November 21-23, 2005, Revised ... Networks and Telecommunications)

Active Networks, IFIP TC6 6 conf., IWAN 2004

NETWORKING 2008 Ad Hoc and Sensor Networks, Wireless Networks, Next Generation Internet: 7th International IFIP-TC6 Networking Conference Singapore, May

Component Deployment: Third International Working Conference, CD 2005, Grenoble, France, November 28-29, 2005, Proceedings

Active Networks: IFIP TC6 6th International Working Conference, IWAN 2004, Lawrence, KS, USA, October 27-29, 2004, Revised Papers (Lecture Notes in Computer Science)

Active Networks: First International Working Conference, IWAN'99, Berlin, Germany, June 30 - July 2, 1999, Proceedings

Active Networks: Second International Working Conference, IWAN 2000 Tokyo, Japan, October 16-18, 2000 Proceedings

Networks and Telecommunications

Active and Programmable Networks for Adaptive Architectures and Services

Active Networks

Active Networks

November 2005

Objects and Databases: International Symposium, Sophia Antipolis, France, June 13, 2000. Revised Papers

Microgrids and Active Distribution Networks

Wired-Wireless Multimedia Networks and Services Management: 12th IFIP IEEE International Conference on Management of Multimedia and Mobile Networks and ... Networks and Telecommunications)

UbiComp 2005: Ubiquitous Computing: 7th International Conference, UbiComp 2005, Tokyo, Japan, September 11-14, 2005, Proceedings

Network and Parallel Computing: IFIP International Conference, NPC 2005, Beijing, China, November 30 - December 3, 2005, Proceedings

Wired-Wireless Multimedia Networks and Services Management: 12th IFIP IEEE International Conference on Management of Multimedia and Mobile Networks ... Networks and Telecommunications)

Management of Multimedia Networks and Services: 8th International Conference on Management of Multimedia Networks and Services, MMNS 2005, Barcelona,

Information and Communications Security: 7th International Conference, ICICS 2005, Beijing, China, December 10-13, 2005, Proceedings

Coordination Models and Languages: 7th International Conference, COORDINATION 2005, Namur, Belgium, April 20-23, 2005, Proceedings

Formal Methods and Software Engineering: 7th International Conference on Formal Engineering Methods, ICFEM 2005, Manchester, UK, November 1-4, 2005,

Networks and Telecommunications: Design and Operation

Secure Mobile Ad-hoc Networks and Sensors: First International Workshop, MADNES 2005, Singapore, September 20-22, 2005, Revised Selected Papers

E-business and Telecommunication Networks: Second International Conference, ICETE 2005, Reading, UK, October 3-7, 2005. Selected Papers

php|architect (November 2005)

Artificial Neural Networks: Formal Models and Their Applications ICANN 2005: 15th International Conference, Warsaw, Poland, September 11-15, 2005, Proceedings,

Mechanisms for Autonomous Management of Networks and Services: 4th International Conference on Autonomous Infrastructure, Management, and Security, ... Networks and Telecommunications)

Frommer's France 2005

Data and Applications Security XX: 20th Annual IFIP WG 11.3 Working Conference on Data and Applications Security, Sophia Antipolis, France, July 31-August

Active and Programmable Networks: IFIP TC6 7th International Working Conference, IWAN 2005, Sophia Antipolis, France, November 21-23, 2005, Revised ... Networks and Telecommunications)

Active Networks, IFIP TC6 6 conf., IWAN 2004

NETWORKING 2008 Ad Hoc and Sensor Networks, Wireless Networks, Next Generation Internet: 7th International IFIP-TC6 Networking Conference Singapore, May

Component Deployment: Third International Working Conference, CD 2005, Grenoble, France, November 28-29, 2005, Proceedings

Active Networks: IFIP TC6 6th International Working Conference, IWAN 2004, Lawrence, KS, USA, October 27-29, 2004, Revised Papers (Lecture Notes in Computer Science)

Active Networks: First International Working Conference, IWAN'99, Berlin, Germany, June 30 - July 2, 1999, Proceedings

Active Networks: Second International Working Conference, IWAN 2000 Tokyo, Japan, October 16-18, 2000 Proceedings

Networks and Telecommunications

Active and Programmable Networks for Adaptive Architectures and Services

Active Networks

Active Networks

November 2005

Objects and Databases: International Symposium, Sophia Antipolis, France, June 13, 2000. Revised Papers

Microgrids and Active Distribution Networks

Wired-Wireless Multimedia Networks and Services Management: 12th IFIP IEEE International Conference on Management of Multimedia and Mobile Networks and ... Networks and Telecommunications)

UbiComp 2005: Ubiquitous Computing: 7th International Conference, UbiComp 2005, Tokyo, Japan, September 11-14, 2005, Proceedings

Network and Parallel Computing: IFIP International Conference, NPC 2005, Beijing, China, November 30 - December 3, 2005, Proceedings

Wired-Wireless Multimedia Networks and Services Management: 12th IFIP IEEE International Conference on Management of Multimedia and Mobile Networks ... Networks and Telecommunications)

Management of Multimedia Networks and Services: 8th International Conference on Management of Multimedia Networks and Services, MMNS 2005, Barcelona,

Information and Communications Security: 7th International Conference, ICICS 2005, Beijing, China, December 10-13, 2005, Proceedings

Coordination Models and Languages: 7th International Conference, COORDINATION 2005, Namur, Belgium, April 20-23, 2005, Proceedings

Formal Methods and Software Engineering: 7th International Conference on Formal Engineering Methods, ICFEM 2005, Manchester, UK, November 1-4, 2005,

Networks and Telecommunications: Design and Operation

Secure Mobile Ad-hoc Networks and Sensors: First International Workshop, MADNES 2005, Singapore, September 20-22, 2005, Revised Selected Papers

E-business and Telecommunication Networks: Second International Conference, ICETE 2005, Reading, UK, October 3-7, 2005. Selected Papers

php|architect (November 2005)

Artificial Neural Networks: Formal Models and Their Applications ICANN 2005: 15th International Conference, Warsaw, Poland, September 11-15, 2005, Proceedings,

Mechanisms for Autonomous Management of Networks and Services: 4th International Conference on Autonomous Infrastructure, Management, and Security, ... Networks and Telecommunications)

Frommer's France 2005

Data and Applications Security XX: 20th Annual IFIP WG 11.3 Working Conference on Data and Applications Security, Sophia Antipolis, France, July 31-August

Recommend Documents