Annex A

Project Number: IST – 2001 – 38142 – CONTEXT

Project Title: Active Creation, Delivery and Management of Efficient Context Aware Services

Specification, design and implementation of the necessary components for the

enhancement of an active platform for the validation of the project approach

Editor: UPC

Document Id: CONTEXT-WP4-UPC-D4.2-101204Del

File Name: document.doc

Version: 006

Organization: UPC

Date: 10.12.2004

Document type: Deliverable

Security: CO

Abstract:

This document aims to present the work carried out in CONTEXT WP4 (“Active Application Layer”) concerning the specification, design and development of enhancements and adaptations of an existing Active Network Platform to support the CONTEXT project approach. Therefore, it describes how the following objectives of WP4 have been addressed

4/10/2023

Specification, design and implementation of the necessary components for the enhancement of an active platform for the validation of the project approach

Doc. id:CONTEXT-WP4-UPC-D4.2-101204Del

Identification of the requirements and functionality required in an active network infrastructure and the IP layer to support the efficient configuration, operation and delivery of context-aware service

Specification, design and implement of the AN API offering the capabilities for realising service context.

Specification, design and implement of the IP API, exhibiting a subset of the P1520 L standard, to allow the programming of the behaviour of IP routers.

Adaptation of the available active network infrastructure to support the above mentioned AN and IP APIs.

Specification, design and implementation of the necessary enhancements in the available network management system to support policy-based operation, to enable the automated configuration, customisation and instantiation of the active network infrastructure with service-related objects and policies, and to manage the infrastructure itself to the end of ensuring efficient service operation and delivery.

Keyword list:

Active Networks, Active Nodes, Network Management, Router, WLAN Access Point, GPRS Access Point, SIP Server

Copyright 2002 CONTEXT Consortium



DOCUMENT HISTORYDate Version Status Comments

15.09.2003 000 Draft Start up of deliverable preparation

30.04.2004 001 Draft Initial version for partners’ comments

15.05.2004 002 Draft Addition of AN state of the art

20.05.2004 003 Draft Addition of GPRS broker, Context broker, the ABLE platform and other minor items

10.10.2004 004 Draft Chapter 2 (Requirements from scenarios) first version

New Security architecture description (chapter 4.4)

Modification of sub section 4.7.1 to include the filter broker API for CISCO routers

New QoSBroker API (chapter 4.7.2.1 and 4.7.2.2)

10-11-2004 005 Draf Update of sections 2.2.2, 4.1.1.3.1, 4.1.1.4, 4.1.4, 4.3.2, 4.6.4,

01-12-2004 006 Draft Update of section 2.3

10-12-2004 Final Fixed Final version




Copyright CONTEXT Consortium: VTT Information Technology, Telefónica Investigación y Desarrollo S.A Unipersonal, VODAFONE-PANAFON Hellenic Telecommunications Company S.A., ALGONET S. A., University College of London, TECHNION Israel Institute of Technology, Universitat Politècnica de Catalunya, Institute of Communication and Computer Systems/National Technical University of Athens.




TABLE OF CONTENTS1 INTRODUCTION.............................................................................................................1

2 ANALYSIS OF SCENARIOS AND ACTIVE LAYER REQUIREMENTS CAPTURE ...........................................................................................................................3

2.1 MOVING CAMPUS SCENARIO.......................................................................................32.1.1 Scenario Description..........................................................................................3

2.1.1.1 CA-Conference Set Up....................................................................................32.1.1.2 CA-Announcement Service............................................................................4

2.1.2 Functionality required from the DINA brokers..................................................42.2 CRISIS HELPER SCENARIO...........................................................................................8

2.2.1 Scenario description...........................................................................................82.2.2 Functionality required from the DINA brokers................................................10

2.3 SUPER MOTHER SCENARIO........................................................................................112.3.1 Description........................................................................................................11

2.3.1.1 Initial Stage...................................................................................................122.3.1.2 Pre-handover Stage.......................................................................................122.3.1.3 Handover Stage.............................................................................................122.3.1.4 Post-handover Stage......................................................................................12

2.3.2 Functionality Required from the Brokers.........................................................162.4 SERVICES TO ALL SCENARIO.....................................................................................17

2.4.1 Scenario Description........................................................................................172.4.1.1 Step 1. Deployment and configuration of Condition Evaluators..................172.4.1.2 Step 2. Service Invocation............................................................................182.4.1.3 Step 3. Enforcement of actions.....................................................................182.4.1.4 Step 4. Execution of the service logic object................................................192.4.1.5 Step 5. Service assurance..............................................................................192.4.1.6 Step 6. End of service process......................................................................19

2.4.2 Functionality required from the DINA brokers................................................21

3 ACTIVE AND PROGRAMMABLE NETWORK TECHNOLOGY AND FACILITIES .........................................................................................................................24

3.1 REVIEW OF EXISTING PLATFORMS.............................................................................273.2 THE ABLE PLATFORM..............................................................................................32

3.2.1 The Session Broker...........................................................................................343.2.2 The Info Broker.................................................................................................343.2.3 The Control Broker...........................................................................................353.2.4 The Diverter and Linux Filtering System..........................................................35

4 DINA: THE AN PLATFORM FOR THE CONTEXT PROJECT............................364.1 THE ACTIVE PLATFORM............................................................................................36

4.1.1 DINA Active Packets.........................................................................................374.1.1.1 UDP/IP Header.............................................................................................384.1.1.2 ANEP Header................................................................................................384.1.1.3 DINA Header................................................................................................384.1.1.4 Class Length and Class URL Option............................................................394.1.1.5 Active Payload..............................................................................................40




4.1.2 Diverter.............................................................................................................404.1.3 The Session Broker...........................................................................................40

4.1.3.1 Session Broker Channels..............................................................................404.1.3.2 Session Database...........................................................................................414.1.3.3 Aging Mechanism.........................................................................................42

4.1.4 URL Class Loader.............................................................................................424.1.5 Execution Environment.....................................................................................42

4.1.5.1 Java EE..........................................................................................................424.1.6 Brokers..............................................................................................................42

4.2 CODE AND SERVICE EXECUTION SUPPORT.................................................................444.2.1 API specification...............................................................................................44

4.3 MANAGEMENT OF ACTIVE NODES............................................................................444.3.1 AN management................................................................................................44

4.3.1.1 Management Broker......................................................................................454.4 SECURITY ARCHITECTURE........................................................................................46

4.4.1 Introduction.......................................................................................................464.4.1.1 Relevant Entities...........................................................................................464.4.1.2 Relevant Objects...........................................................................................474.4.1.3 Objectives of Security Functions..................................................................47

4.4.2 DINA Security Requirements............................................................................484.4.2.1 Authentication and Verification of Integrity.................................................484.4.2.2 Replay Protection..........................................................................................484.4.2.3 Identification of Active Code and Active Service........................................484.4.2.4 Access Control..............................................................................................49

4.4.3 Architectural Specification...............................................................................494.4.3.1 Overall Architecture......................................................................................494.4.3.2 Access Rights Management..........................................................................504.4.3.3 Authentication and Verification of Integrity.................................................504.4.3.4 Identification of Active Code and Active Service........................................524.4.3.5 Access Control..............................................................................................52

4.5 DINA ADAPTATION TO IPV6.....................................................................................534.5.1 IPv6 Overview...................................................................................................534.5.2 Porting Application to Understand IPv6..........................................................54

4.5.2.1 Socket Address Structures............................................................................544.5.2.2 Socket Functions...........................................................................................564.5.2.3 Address Conversion......................................................................................564.5.2.4 Name Resolution...........................................................................................56

4.5.3 Context View for IPv6.......................................................................................574.5.3.1 Changes in DINA for IPv6...........................................................................574.5.3.2 DINA Active Packet Formats.......................................................................57

4.6 IP API........................................................................................................................594.6.1 Info Broker........................................................................................................59

4.6.1.1 API specification...........................................................................................594.6.1.2 API Implementation details..........................................................................61

4.6.2 Control Broker..................................................................................................614.6.2.1 API specification...........................................................................................614.6.2.2 API implementation details for Linux routers..............................................634.6.2.3 API implementation details for CISCO routers............................................63




4.6.3 Network Broker.................................................................................................664.6.3.1 API specification...........................................................................................664.6.3.2 API implementation details...........................................................................68

4.6.4 SIP broker.........................................................................................................684.6.4.1 API specification...........................................................................................694.6.4.2 API implementation details...........................................................................70

4.7 FILTERING AND QOS.................................................................................................704.7.1 Filter broker......................................................................................................70

4.7.1.1 API specification for LINUX routers...........................................................704.7.1.2 API specification for CISCO routers............................................................714.7.1.3 API Implementation details..........................................................................72

4.7.2 QoS broker........................................................................................................724.7.2.1 API specification...........................................................................................734.7.2.2 API implementation details...........................................................................78

4.8 CONTEXT SUPPORT....................................................................................................784.8.1 Context broker..................................................................................................78

4.9 ACTION BROKER........................................................................................................794.9.1 API specification...............................................................................................794.9.2 API implementation details...............................................................................80

4.10 WIRELESS SUPPORT...................................................................................................804.10.1 WLAN broker....................................................................................................80

4.10.1.1 API specification.......................................................................................814.10.1.2 API implementation details for CISCO APs............................................85

4.10.2 GPRS broker.....................................................................................................884.10.2.1 API specification.......................................................................................884.10.2.2 API implementation details.......................................................................89

TABLE OF FIGURESFIGURE 1: CONTEXT FUNCTIONAL ARCHITECTURE..................................................................2FIGURE 2: CONTEXT-AWARE CONFERENCE SETUP SERVICE IN THE MOVING CAMPUS

SCENARIO.............................................................................................................................5FIGURE 3: CONTEXT-AWARE ANNOUNCEMENT SERVICE IN THE MOVING CAMPUS SCENARIO..6FIGURE 4: INTERACTIONS BETWEEN APPLICATIONS AND DINA BROKERS IN THE CRISIS

HELPER SCENARIO..............................................................................................................9FIGURE 5: DIAGRAM SHOWING THE DISTRIBUTION OF THE BROKERS AND CONTEXT CONTROL

OBJECTS (CCOS) FOR THE SUPERMOTHER SCENARIO......................................................11FIGURE 6: SEQUENCE DIAGRAM OF THE INITIAL STAGE OF THE SUPER MOTHER SCENARIO....13FIGURE 7: SEQUENCE DIAGRAM FOR THE PRE-HANDOVER STAGE OF THE SUPERMOTHER

SCENARIO...........................................................................................................................14FIGURE 8: SEQUENCE DIAGRAM FOR THE HANDOVER STAGE OF THE SUPERMOTHER

SCENARIO...........................................................................................................................15FIGURE 9: SEQUENCE DIAGRAM FOR THE POST-HANDOVER STAGE OF THE SUPERMOTHER

SCENARIO...........................................................................................................................15FIGURE 10: CONDITION EVALUATOR DEPLOYMENT INTERACTIONS IN THE SERVICES TO ALL

SCENARIO...........................................................................................................................17FIGURE 11: SERVICE INVOCATION INTERACTIONS IN THE SERVICES TO ALL SCENARIO..........18




FIGURE 12: ACTION ENFORCEMENT INTERACTIONS IN THE SERVICES TO ALL SCENARIO........19FIGURE 13: SERVICE LEVEL OBJECT EXECUTION INTERACTIONS IN THE SERVICES TO ALL

SCENARIO...........................................................................................................................20FIGURE 14: ENDING TX FILE INTERACTIONS IN THE SERVICE TO ALL SCENARIO....................20FIGURE 15: SERVICE ASSURANCE INTERACTIONS IN THE SERVICES TO ALL SCENARIO..........21FIGURE 16: P1520 PROJECT REFERENCE MODEL AND THE L-INTERFACE ABSTRACTION MODEL

...........................................................................................................................................25FIGURE 17: FORCES ARCHITECTURAL REPRESENTATION OF THE NETWORK ELEMENT..........26FIGURE 18: BASIC ACTIVE NODE ARCHITECTURE.....................................................................26FIGURE 19: MAIN CLASSES OF THE ABLE ACTIVE SERVER.....................................................33FIGURE 20: DINA ACTIVE PLATFORM ENVIRONMENT.............................................................36FIGURE 21: DINA BLOCK DIAGRAM ARCHITECTURE................................................................37FIGURE 22: DINA PACKET FORMAT..........................................................................................37FIGURE 23: THE ANEP PACKET HEADER FORMAT...................................................................38FIGURE 24: THE DINA PACKET HEADER FORMAT....................................................................39FIGURE 25: JAVA EXECUTION ENVIRONMENT IN DINA...........................................................43FIGURE 26: OVERALL ARCHITECTURE OF DINA SECURITY......................................................49FIGURE 27: CODE AND PACKET SIGNATURES IN THE DINA SECURITY MECHANISM...............51FIGURE 28: IPV4 & IPV6 CLIENT/SERVER INTEROPERABILITY................................................55FIGURE 29: SOCKET ADDRESS STRUCTURES FOR IPV4 AND IPV6.............................................55FIGURE 30: DINA PACKET STRUCTURE....................................................................................58FIGURE 31: DINA PACKET STRUCTURE TO COMMUNICATE BETWEEN SESSION BROKERS.......58FIGURE 32: DINA ACTIVE PACKET FORMAT............................................................................59FIGURE 33: DIFFSERV DOMAIN.................................................................................................73Figure 34: Association of VLANs, Service Sets and Access Lists in a WLAN access point. .81

TABLE OF TABLESTABLE 1: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE MOVING CAMPUS

SCENARIO.............................................................................................................................6TABLE 2: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE CRISIS HELPER

SCENARIO...........................................................................................................................10TABLE 3: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE SUPERMOTHER

SCENARIO...........................................................................................................................16TABLE 4: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE SERVICES TO ALL

SCENARIO...........................................................................................................................21TABLE 5: METHODS USED TO SUPPORT CISCO ROUTERS THROUGH THE CONTROL BROKER. 64Table 6: Mapping between API WLAN methods and CISCO access point commands..........85

ANNEXES4.10.2.2Annex A:References

………………………………………………………………………..92




4.10.2.2Annex B: dina code distribution and availability…………………………………………..95

4.10.2.2Annex C: partner´s contribution to this deliverable………………………………………….96




TERMS AND ACRONYMSAN Active Network (also Active Node depending on context)

ANEP Active Network Encapsulation Protocol

AP Access Point

API Application Program Interface

CA Certification Authority, a body who issues and signs certificates

CANP Context-aware Active Network Provider

CAS Context Aware Service

CASP Context-aware Active Service Provider

CCM Connection Control and Management (Interface of the P1520 reference model)

CCO Context Control Object

CE Control Element (functional part of a NE)

CLI Console Language Interface

EE Execution Environment

EE Execution Environment

FE Forwarding Element (functional part of a NE)

ForCES Forwarding and Control Element Separation (Working Group of the IETF)

JVM Java Virtual Machine

JVM Java Virtual Machine

MIB Management Information Base

NE Network Element (generic denomination of the active network node)

OS Operating System

PACL Permitted Access Control List

PKI Public Key Infrastructure

Root CA Highest level certificate authority

SIP Session Initiation Protocol

SLO Service Level Object

SNMP Simple Network Management Protocol

TLV Type Length Value

URL Uniform Resource Locator

VPN Virtual Private Network

X509 A standardised encapsulation format for public keys







EXECUTIVE SUMMARYThis deliverable contains the specification and design of the active network layer intended to support context aware service delivery in the framework or the IST CONTEXT project. Therefore it is aligned with Deliverable D2.2 “Solution for Provisioning and Delivery of Context Aware Services” in the sense that the former established the global system architecture of which the active network layer is a part. Also this deliverable is related to the IR4.1 “Initial Specifications of Active Platform Capabilities for the Provisioning of Context-aware Services” because the former was the starting point on the specification work and this initial specification has been embedded into the current deliverable. Finally, this deliverable is a complement of deliverable D3.2 “Design and Implementation of Components for the Proof of Concept of Provisioning and Management of Context Aware Services” because D3.2 and D4.2 constitute the complete specification and design of the CONTEXT project solution.

This document is structured around four sections. Section 1 is the introduction where we present in context the Active Layer. This layer collectively supports Execution Environments that offer a controlled way to host code for the purpose of running and managing the context-aware services.

Section 2, the “Analysis of Scenarios and Active Layer Requirements Capture” presents the minimum set of requirements dictated by four scenarios envisaged in the project, namely the “Super Mother”, the “Crisis Helper” the “Moving Campus” and the “Services to All”. Each of these scenarios is supported by pieces of code (Service Logic Objects) that need to interact with the Active Layer. And each of these interactions must be supported by subsystems (brokers as termed hereafter) through appropriated methods. Besides this minimum set of requirements that at least would ensure the support of the above mentioned scenarios, others have been proposed to show the system capability for future or enhanced context-aware services. The full functionality of the brokers is dealt in Section 4.

Section 3, “Active and Programmable Network Technology and Facilities” presents the result of the survey conducted to review the state of the art in the field and, as a consequence, to select an active network platform to be the core of our Active Layer. Remember that the purpose of the CONTEXT project was not to build an active platform but to select an already existing one and enhance it for the project objectives. Almost thirty platforms are considered. As the ABLE platform was finally selected, we devote more in depth description of its architecture and facilities.

Section 4, “DINA: The AN Platform for the CONTEXT Project” constitutes the core of the deliverable because it presents the modifications and enhancements that were introduced in the ABLE platform to become DINA, the name we gave to the new platform. The active platform is an application that enables active node to deploy, control, operate and manage context-aware services. DINA active platform consists of an Active Engine and a Forwarding Element, namely router, WLAN access point, media gateway, etc. The Active Engine is constituted by a set of applications called Brokers that interact between themselves and also with the active code residing in the Execution Environment. Some of these brokers were already existing in the ABLE platform like the Session Broker, Info Broker and the Control Broker, and needed different types of adaptations only. Other brokers were developed on purpose for this project. Examples of this type are the Context Broker, the Action Broker, the WLAN Broker and the GPRS Broker or the SIP Broker. In this Section 4 we take these




brokers one by one, present their functionality, the API allowing the broker interaction with active applications and provide some implementation details. Also, other important issues like security, access control and management are also covered.




1 INTRODUCTION

This deliverable reflects the work carried out in one of the layers proposed in the CONTEXT project architecture. Figure 1 shows this architecture as being composed by three layers, namely the Service Creation layer, the Service Management layer and the Service Execution layer. The Service Creation layer and the Service Management layer are under the scope of deliverable D3.2 whereas the specification and design of the Service Execution layer is the purpose of this D4.2 deliverable.

The Service Creation Layer is intended for the automatic generation of the code needed for all the phases of a service. Context aware services, based on a context model that is one of the novelties presented in this work, are conceived as policy-based applications. In fact, the policy conditions are based on context variables. Therefore, the service reacts to context evolution. Moreover, as the service lifecycle will be also under the control of policies as mentioned hereafter, the Service Creation Layer includes the generation of policies for the execution and management of the service. Both code and policies will be derived from predefined templates that will be instantiated with service dependent parameters introduced by the service provider.

The Service Management layer is composed of four main building blocks as reflected in Figure 1. The Code Distributor is intended to download the generated code to the appropriate code repositories and/or storage points. This installation process is a precondition for a service to be delivered. Code repositories will be distributed along the network infrastructure. Therefore, the Distributor will need to keep track of the URLs where code was installed. The Invocation Service Listener is the unit intended to capture any of the different types of triggers that may cause service activation. The Code Execution Controller is the functional entity that will allow the downloading of the service logic from one of the code repositories in the Service Execution layer and as a consequence will activate the service. Finally, the Service Assurance module is believed to keep track of the quality of service. All processes of this management layer will be policy controlled. Appropriated condition evaluators will be deployed. These conditions will be context related. Actions will be executed when conditions are met. The usual sequence of events would start with the detection of a trigger (perhaps caused by an explicit or implicit consumer request) by the Invocation Service Listener that would inform the Code Execution Controller about the required service by means of information extracted from the trigger itself. The Code Execution Controller would compose and forward an activation request message to the appropriate Execution Environment in the Service Execution layer, which in turn would retrieve the code from the repository and execute it, starting the service provisioning phase. As soon as the service had been started, the Service Assurance module would keep track of its behaviour.

The Service Execution layer is supported by a mixture of active network nodes (AN) and dedicated servers. This layer collectively supports Execution Environments that offer a controlled way to host code for the purpose of running and managing the service. The motivation for selecting active technology has been the advantages that if offers as far as context collection, processing and storage is concerned. This is a novel approach and constitutes one of the main contributions of this research work.

The specific execution environments for context-aware computation are hosted in the network, which becomes context-aware. Although many solutions would be feasible

Copyright 2002 CONTEXT Consortium 1 of 110



we have adopted the DINA programmable platform based on concepts used in the ABLE and ABLE++ systems [48] to provide the programmable context-network functionality. DINA is a programmable middleware, which can be attached to different types of routers and makes them active routers. This characteristic provides to the system the ability to integrate and deploy applications on active nodes and in this way to explode all the AN facilities, accessibility, and efficiency.

Figure 1: CONTEXT functional architecture

The APIs of the DINA platform allow the service logic an easy and unified access to local network and context information, and allow also to perform actions (such as network level configurations) as needed. This allows us to use context-aware services with a variety of network technologies and applications.




2 ANALYSIS OF SCENARIOS AND ACTIVE LAYER REQUIREMENTS CAPTURE

The service execution layer is provided by DINA nodes. The DINA node contains an active engine constituted by cooperating entities, namely the brokers. Any context aware service will be provided by the appropriate interaction of all or a subset of these brokers and the corresponding SLO downloaded on the execution environment of DINA. Moreover, these interactions will be facilitated by the appropriated APIs defined for each of the above mentioned brokers. Hence, the APIs must exhibit the necessary functionality to support a given service.

According to the above rationale we followed the process here summarised to get the requirements dictated by each scenario on the DINA platform

Description of the different scenarios as a sequence diagram among the involved brokers and SLOs.

Each of the above identified interactions can be seen as a method call. Hence we identify each supporting method assigning a name and describing its purpose.

2.1 Moving Campus scenarioTo characterise this scenario we have conceived two services, namely a Conference Start-up and the subseqüent Announcement Service.

2.1.1 Scenario Description

2.1.1.1 CA-Conference Set Up

The Conference Setup Service provides the QoS guarantees for a specific time period, in order to hold a conference session between the members of a group.

All the conference participants should have already registered to the service utilizing the Conference Setup Service web interface. When a user registers to this service, he/she enters: a) personal information (name, address etc) and b) information about the network cards he/she owns and is able to utilize, in order to connect to the network: MAC addresses for WLAN/LAN network cards and MSISDN numbers for GPRS cards c) service level (user chooses among several service levels which correspond to different accounting policies).

The conference session is scheduled by a registered user (service consumer) who utilizes the Conference Setup Service web interface in order to introduce the necessary information for the conference session. Specifically, he/she enters the conference start time, the conference duration and the participants’ names. Once the service consumer schedules a conference session, a customized SLO is created. Then, the SLO’s source code is distributed and stored to the specified storage points. Moreover, a listener is launched that produces a “Start Time” event, when the specified moment for the service execution comes (Start time). This event causes the invocation of the SLO.




The SLO logic requests to get notified when each of the participants is detected in the campus (he/she has network access). Additionally the access network and the used IP address are acquired. Then, the SLO triggers the relevant QoS configurations. In case that one of the connected users decides to change the access network, the SLO is accordingly notified about it and issues the new QoS configurations to be performed. Moreover, in case one of the connected users is accessing the network through a WLAN, the SLO asks to get notified in case it could suggest to the user a better network connection than the current WLAN connection. In case this happens the SLO delivers the relevant information to the user. Finally, when the conference ends, the SLO triggers the removal of the performed QoS configurations.

The SLO interacts with the ContextBroker through the ContextBrokerInterface, in order to acquire the context information required by its logic and with the Action Broker through the ActionBrokerInterface, in order to trigger an action.

2.1.1.2 CA-Announcement Service

While participating in the conference, the involved parties are able to receive asynchronous notifications/announcements about events of their interest. The CA-Announcement Service provides this functionality. Once users have registered to this service and an announcement for an event comes up, the informing notification will be delivered to the mobile phone or the WLAN device a participant carries, if it is inferred that it fits his/her interests.

A user may register to this service utilizing the Announcement Service web interface. The user enters personal information (name, address, profile), information for the network cards he/she owns and is able to utilize in order to connect to the network (MAC addresses for WLAN network cards, MSISDN numbers for GPRS cards), and the desired service duration (e.g. 6 months), which determines the user’s accounting details.

Once a user registers to the service, a customized per user SLO is created. Then, the corresponding source code is distributed and stored to the specified storage points. Moreover, a listener is launched that produces a “User in Campus_A” event when the registered user is detected in Campus_A Campus. This event causes the invocation of the SLO.

As soon as a user is detected in Campus_A, the SLO subscribes to be notified when an informing notification comes up that fits the user’s interests and preferences. In this sense, it is required that once an announcement is produced, it is checked whether it fits the user’s interests. In case of a match, the system consults the user’s profile and agenda, while at the same time retrieving his/her location, in order to verify potentially prescheduled activities and proceed with the forwarding of the announcement to the current device, if his/her profile permits it. When the user leaves Campus_A, the SLO should be notified in order to stop checking for relevant announcements.

2.1.2 Functionality required from the DINA brokers

In Table 1, we have identified the functionality of the DINA Brokers that will be used for the Moving Campus scenario. More specifically, the method names of the Broker Interfaces that will be used by all the interacting applications are presented.




Conference_Setup_SLO Action BrokerCustomized with: participants list, start_time, duration_time

For each conference participant username

Receive Notification:particant connected, access net,ip_address

trigger_action(QoS_setup)

Receive Notification:particant changed connection, new access net,new ip_address

Context Broker

notify(participant is connected)

notify(participant_change net_access)

notify(WLAN_loaded)

trigger_action(QoS_reconfigure)

For each connected participant

For each WLAN that users are connected

Receive Notification:WLAN1 loaded, particants connected, alternative access net

trigger_action(deliver_message)

Conference ended

trigger_action(QoS_remove)

Figure 2: Context-Aware conference setup service in the Moving Campus scenario




Announcement_SLO Context Broker Action Broker

Customized with:Username

notify(announcement_matching)

Receive Notification:particant changed connection, new access net,new ip_address

notify(username_change access_net)

Receive Notification:announcement to deliver

trigger_action(send_message)

Figure 3: Context-Aware announcement service in the Moving Campus scenario

Table 1: Methods to be supported by the DINA brokers in the Moving Campus scenario

DINA

BrokerMethod Name Description

Con

text

Bro

ker

register_new_context_object()CCO registers the type of context information that it provides

get_current_value()Context consumer retrieves the current value of a context object

notify()Context consumer subscribes to get a notification about related to a context object

give_context_value()Context producer delivers a notification, or the updated value of a context object

Act

ion

Bro

ker

trigger_action()Executes the action code as issued by the SLO with the specified parameters

QoS

Bro

ker getIngress() This method retrieves the ingress

interface.




getEgress() This method retrieves the egress interface.

resetINGRESS() Resets an ingress interface.

resetEgress() Resets an egress interface.

initINGRESS() Initializes the interface as ingress.

installDSMARK() Initializes the interface as egress.

addMarkerPolicer() Adds a policy/marker

removeMarkerPolicer() Remove a policy/marker

finish()Terminates the TCP connection with the QoS Broker.

GP

RS

Wra

pper

isUserConnected()Given the MSISDN returns true if the specified user is connected to the GPRS network

getUserIPAddress()Given the MSISDN returns the network address of the user’s subnetwork

getUserLocation()Given the MSISDN returns the user’s location in geographical coordinates.

sendMessage()Given the MSISDN and the message to deliver, delivers an SMS message to the user

WL

AN

Wra

pper

getUserIP()

Given the MAC of the user, returns the IP address of a terminal, which is connected to network through a WLAN network card

getLoad()

The bytes per second of the radio interface of the Access Point from the AP to the clients (the radio downstream). This load is going to be measured in kbps.

getSignalQuality()Given the user MAC, it returns the quality of the signal received from the client (the quality is measured from 0 to 100 in %)




2.2 Crisis Helper scenario

2.2.1 Scenario description

In this scenario there is a context publisher CCO in each node, the SIP CCO, that is in charge of publishing in the Context Broker the information about ongoing SIP sessions. The SIP CCO starts by contacting the SIPBroker and obtains a list of existing SIPProxys. The SIP CCO gets periodically information about SIP sessions from the SIP Broker and publishes it for each SIPProxy and period in the Context Broker.

The CHlistener starts its execution when the corresponding execution policy is fullfilled. CHlistener contacts the SIPBroker and obtains a list of existing SIPProxys. During its lifetime, the CHlistener contacts the Context Broker periodically to get information about ongoing SIP sessions in each SIP Proxy. The CHlistener processes that information, and if it detects a high number of calls to a public help number (i.e. the 112), it sends a notification to the CEC, containing the crisis zone identifier. The crisis zone is all the area covered by the SIPProxy responsible to detect a high number of calls to the 112, so the zone is identified by that SIPProxy identifier. This event fires the CHmain execution policy.

Once it is running, CHmain asks the Context Broker for info about ongoing sessions in the SIPProxy that is responsible for the alarm. CHmain processes this data and keeps on asking periodically for ongoing sessions information. CHmain stores an always-updated list of ongoing connections. This list contains information about the type of session, the caller, the calleé and the used bandwidth. CHmain also stores the occupied bandwidth in %. When appropriate, CHmain will take an action. Taking an action implies that CHmain has to contact with the SIPBroker. The action can be one out of three, namely to terminate all calls, to configure a call block or to configure a call accept.

When CHmain detects that the crisis is solved, it contacts the CEC to reconfigure the CHlistener. From now onwards, the CHlistener will monitor again the SIPProxy that was responsible of the crisis just solved.




CHListener CHmain SIPBroker Context Broker SIP CCO

High establishment of 112 calls detected

CHmain invocation via CEC

TerminateAllCalls(SIPProxyID)

configureCallAccept (SIPProxyID, callType, [] condition, bandWidth)

configurationResult

CHListener processes SIP info

configurationResult

configureCallBlock (SIPProxyID, callType, [] condition)

configurationResult

getProxyServers()

[] SipProxyID_List

get_current_value(SIPProxyID.stateInfo)

SIPProxyID.stateInfo

getProxyServers()

[] SipProxyID_List

sessionStateInfo (SIPProxyID)

sessionState

register_new_context_object(SIPProxyID.stateInfo)

delegate_new_context_object(SIPProxyID.stateInfo)

get_current_value(SIPProxyID.stateInfo)

SIPProxyID.stateInfo

Figure 4: Interactions between applications and DINA brokers in the Crisis Helper Scenario





Table 2: Methods to be supported by the DINA brokers in the Crisis Helper scenario

DINA

BrokerMethod Name Description

Con

text

Bro

ker

subscribeContext consumer subscribes to receive a notification for a context object

register_new_context_objectCCO registers the type of context information that it provides

get_current_valueContext consumer retrieves the current value of a context object

deliver_notificationContext consumer subscribes to get a notification related to a context object

supply_context_valueContext producer delivers a notification, or the updated value of a context object

SIP

Bro

ker

terminateAllSessionsSLO uses this method to close all current sessions

acceptCallSIP Broker uses this method to ask the SLO if a call must be accepted

getProxyServersSLO and SICE use this method to learn the IDs of the SIP softswitches

sessionStateInfoUsed by the CCO to gather SIP related info (number of 112 calls)

setCallAcceptanceDiverterUsed by the SLO to subscribe to the SIP Broker

applyDivertorUsed by the SLO to inform the SIP Broker that diversion must start from this point onwards




2.3 Super Mother scenario

2.3.1 Description

Katherine is a mobile user who is uploading a large file from her laptop to the FTP server located in Katherine’s office network. The network provides a VPN service to secure Katherine’s FTP traffic in the backbone. At first, Katherine is connected to the office network via the ISP’s WLAN network. This network has a low bandwidth as it simulates a GPRS network. As she approaches the hospital which contains a high bandwidth WLAN network, her WLAN interface is configured and then a handover to the hospital’s WLAN network is performed. However, Katherine’s FTP connection and the VPN service remain functional during the handover, and handover side effects are minimised. The following diagram shows the distribution of the brokers, CCOs and SLOs for the SuperMother scenario.

Figure 5: Diagram showing the distribution of the brokers and Context Control Objects (CCOs) for the SuperMother scenario.

The SuperMother scenario is split into four stages as follows:

The initial stage

The pre-handover stage

The handover stage

The post-handover stage


Context broker session broker

ISP DINA node WLAN AP

Home Agent

FTP Server

Office DINA node

Katherine

VPN Monitor

Hospital DINA node WLAN AP

WLAN broker session broker

CCO

MobileIP

WLAN broker session broker

CCO



2.3.1.1 Initial Stage

In this stage Katherine’s laptop is in the ISP WLAN network. The WLAN broker notices that the laptop has joined the network and passes this contextual

information to the context broker through a CCO located in the DINA node in the ISP’s network.

A VPN tunnel is built between the ISP DINA node and the office DINA node and data is sent from the laptop to the FTP server in the office.

2.3.1.2 Pre-handover Stage

The CCO on the ISP DINA node constantly monitors the location of Katherine’s laptop (here location means which WLAN access point coverage area it is in). When the laptop enters the hospital’s WLAN a new network interface is brought up and configured (via DHCP).

The VPN monitor through the context broker sets up a new VPN tunnel between the hospital DINA node and the office DINA node.

2.3.1.3 Handover Stage

Katherine performs the mobile IP registration and moves outbound traffic to the new active network interface

The home agent starts routing Katherine’s inbound traffic via the hospital’s WLAN network. The VPN monitor receives an acknowledgement from the laptop.

2.3.1.4 Post-handover Stage

The VPN tunnel between the ISP DINA node and the office DINA node is taken down. The VPN monitor receives an acknowledgement from Katherine’s laptop




laptop W

LAN client

laptop FTP client

ISP AP

ISP W

LBISP SB

ISPCCO

OfficeCoB

Context Broker

VPNm

onitorOffice

SBOffice FTP

Server

1: register2: register_new_context_object

3: isUserAssociated

4: notify5: notify

6: buildVPN

7: sendCode

8: setVPN

9: FTP login, FTP upload

Figure 6: Sequence diagram of the initial stage of the Super Mother scenario




Figure 7: Sequence diagram for the pre-handover stage of the SuperMother scenario


WLAN

clientHospital

APHospitalW

LAN BHospital

SBHospital

CCOO

fficeCoB

OfficeSB

Office

FTP serverContextBroker

VPNM

onitorNetworkinterface

1: register2: register

3: Interface Up

6: isUserAssociated

7: notify

4: DHCP request

5: DHCP reply

8: notify

9: buildVPN



HomeAgent

VPN monitor

FTPclient

MIP client

ISPAP

Hospital AP

FTP server

1: CEPPHO HC

2: CEPPHO HO

3: MIP_register_request

4: MIP_register_reply

5: CEPPHO status


Figure 8: Sequence diagram for the handover stage of the SuperMother scenario.

(CEPPHO stands for Cello Protocol for Planned Handovers Command)

MIP client

HomeAgent

VPN monitor

FTPclient

ISPAP

Hospital AP

FTP server

1: CEPPHO HC

2: CEPPHO HO

3: MIP_register_request

4: MIP_register_reply

5: CEPPHO status


Figure 9: Sequence diagram for the post-handover stage of the SuperMother scenario

(CEPPHO stands for Cello Protocol for Planned Handovers Command)







2.3.2 Functionality Required from the Brokers

Table 3 gives an overview of the functionality that will be used from each of the brokers in the SuperMother scenario.

Table 3: Methods to be supported by the DINA brokers in the SuperMother scenario

DINA Broker Method Name Description

Session Broker

recData() Receives data.

getProg() Obtains the applications from the active payload.

getInitVars() Obtains data from the active payload.

send() Sends an active packet.

WLAN Broker isUserAssociated() Returns true if the client identified is connected to a WLAN AP.

getUserIP() Returns the IP address of the client connected to the WLAN AP.

Context Broker

subscribe()Context consumer subscribes to receive a notification for a context object

register_new_context_object()CCO registers the type of context that it provides

get_current_value()Context consumer retrieves the current value of a context object

deliver_notification()Context producer sends a notification of a change in a context value

supply_context_value()Context producer delivers to the Context Broker the updated value of a context object

Control Broker

setVPN() Starts or stops VPNs between the laptop and the VPN server.

addTempRoute() Adds an entry to the routing table for a specific period of time between the laptop and VPN server.




2.4 Services to All scenario

2.4.1 Scenario Description

This scenario support user´s quotidian life like buying any goods, getting tickets, reading selected news, etc. As far as the interaction with the DINA brokers, we decompose this generic scenario into six steps. Each step is illustrated with the corresponding sequence diagram as follows. The precondition of this sequence of steps is that the service is already created, deployed and the user subscribed.

2.4.1.1 Step 1. Deployment and configuration of Condition Evaluators

The service management system deploys and configures the Condition Evaluators to support for service invocation. The following sub-steps would take place:

PBSMS sends an active packet to Session Broker. Session Broker parses the Active Packet. Action Broker retrieves service code and executes it. The WLAN Broker senses user status. The GPRS Broker senses user status.

Figure 10: Condition Evaluator deployment interactions in the Services to All scenario


PBSM Layer

configureCE(CE, ServiceCodeLocation)

Session Broker Action

Broker WLAN Broker GPRS

Broker

parse(ActivePacket) retrieve(ServiceCode)

inform(ANInformation)

download(ServiceCode) Inform(ANInformation)

getWLAN(UserStatus) retrieve(WLAN Information)

inform(WLANInformation)

getGPRS(UserStatus) inform(GPRSInformation)

parse(ActivePacket)



2.4.1.2 Step 2. Service Invocation

The PBSMS receives the service invocation and executes actions as response. The WLAN Broker sends the user’s status. The GPRS Broker sends the user’s status. The Session Broker sends the condition evaluator conditions. The service management layer checks service invocations conditions and relates with policy. The service management layer sends to the execution environment layer the policy actions to

be enforced.

Figure 11: Service Invocation interactions in the Services to All scenario

2.4.1.3 Step 3. Enforcement of actions

In this step, the service management layer enforces the policy actions.

PBSMS sends the policy actions to be enforced in Active Packets. Session broker parse the active packet and retrieve WLAN user’s information. Action Broker retrieves service code and executes the SLO.


Session Broker

PBSM Layer

WLAN Broker

GPRS Broker

getWLAN(UserStatus)


getGPRS(UserStatus)

inform(GPRSInformation)

invocation(CEconditions)

check(Policies)

enforce(PolicyActions)



Figure 12: Action enforcement interactions in the Services to All scenario

2.4.1.4 Step 4. Execution of the service logic object

The service level object (SLO) is executed. PBSM send the Active Packet to the session broker to inform execute SLO. Session Broker parses the active packet and executes the SLO. Session Broker gets the Active Node Information from Information Broker. Session Broker gets the WLAN User Status from WLAN Broker. Session Broker gets the GPRA User Status from GPRS Broker. Control Broker configures the Active Node to make the routing necessary.

2.4.1.5 Step 5. Service assurance

The Service Assurance process is executed. QoS Broker asks the WLAN User Status. QoS Broker asks the GPRS User Status. QoS Broker reports the QoS parameters to the PBSM system. PBSM System realtes the QoS Policy Conditions with its respèctive Policy Actions. PBSM System Enforce Policy Actions. The Cycle Policy Enforce Actions is executed.

2.4.1.6 Step 6. End of service process

The user is informed that the service is completed. Action broker inform to Session broker the File Tx end. Session broker end report to the PBSM Layer. PBSM Layer sends to the GUI the ending report of the service.


PBSM Layer Session

Broker Action Broker

Enforce(PolicyAction) Parse(ActivePacket)

Retrieve(ServiceCode)

execute(SLO)



Control Broker Session

Broker Information Broker PBSM

Layer send(SLO)

getRouting(searchRoute)

askAN(ANstatus) get(ANInformation)

give(ANInformation)

configure(route) makeTunnel(IPTunnel)

WLAN Broker GPRS

Broker

getWLAN(UserStatus)

getGPRS(UserStatus)

retrieve(WLANInformation)

retrieve(GPRSInformation)

inform(GPRSInformation)


Figure 13: Service Level Object execution interactions in the Services to All scenario

Figure 14: Ending Tx File interactions in the Service to All scenario


PBSM Layer Session

Broker Action Broker

inform(ANStatus) endingReport(status)



Action Broker PBSM

Layer Session Broker QoS

Broker

report(QoSParameters) checkService(actions)

Enforce(PolicyAction) Parse(ActivePacket)

Retrieve(ServiceCode)

Inform(ANInformation)

download(ServiceCode) execute(ServiceCode)

WLAN Broker GPRS

Broker

getWLAN(UserStatus) retrieve(WLAN Information)


getGPRS(UserStatus) inform(GPRSInformation)

Figure 15: Service Assurance interactions in the Services to All scenario


This section contains the identified methods description, in natural language, the purpose of the method, the input and the output parameters if any for the scenario.

Table 4: Methods to be supported by the DINA brokers in the Services to All scenario

DINA Broker Method Name Description

Session Broker recData() Method used to receive data.

iMDone() Method used to kill control messages.

getProg() Method used to extract applications from the active payload.

getInitVars() Method used to extract data from the active payload.




send() Method used to send an active packet.

distrubute() Method used to broadcasting an active packet to every interface of the active node.

Information Broker

snmpGet() Method used to query for information on network entity via SNMP.

getNumIf() Method used to get all the interfaces (active or non active) of the local active node.

getRouterName() Method used to know the name of the router associated with local active node.

getIPAddrs() Method used to receives an interface number and return a list of IP addresses, which is associated with that interface.

getStatus Method used to receive an index number of an interface and returns the status. 1=up, 2=down, 3=testing.

getDestAddrs() Method used to receives an interface number and returns a list of destination addresses that use that interface

Control Broker

setRoute() Method used to add and delete entries from the routing table of the active node.

addTempRoute() Method used to add an entry to the routing table for a specific period of time. After that the entry is removed.

WLAN Broker

isUserAssociated() Method that rerurns rue if the client identified is associated to the WLAN AP.

getUserMAC() Method that returns the MAC address of the client connected to the WLAN AP.

getUserIP() Method that returns the IP address of the client connected to the WLAN AP.

establishVLAN() Method that establises a VLAN for clients accessing through the WLAN Access Point.

removeVLAN() Method that remves an existent VLAN.




GPRS Broker

isUserConnected() Method that returns true if a user is connected to the GPRS network.

getUserMAC() Method that returns the MAC address of the client connected to the GPRS network.

getUserIPAddress() Method that returns the GPRS assigned IP address for a connected user to the GPRS.

getUserConnectedTime() Method that returns the time (seconds) since the user is connected to the GPRS network.

disconnectUser() Method that disconnects a connected user to the GPRS network.

Action Broker retrieve() Method that retrieves the service logic object




3 ACTIVE AND PROGRAMMABLE NETWORK TECHNOLOGY AND FACILITIES

Network programmability refers to executable mobile code that is injected into the network elements in order to create the new functionality at run time. The basic idea is to enable third parties (end users, operators, service providers, service and network environments) to inject application-specific services, in the form of code, into the network. Programmable or active networks allow dynamic injection of code as a mechanism of realizing application-specific service logic, or performing dynamic service provision on demand. As such, network programming provides unprecedented flexibility in telecommunications. However, viable architectures for programmable networks must be carefully engineered to achieve suitable trade-offs between flexibility, performance, security, and manageability.

The first mobile code executed in network elements was utilised as part of an early ad-hoc research network SOFTNET [49] at Linköping University, Sweden (1981-85). This initial active/programmable network research project was based on the idea of moving code and executing it at suitable places. Active networks were re-discovered by Tennenhouse and Wetherall [32] in 1996, the DARPA ActiveNets Program (1997 – 2003) and a number of European Research projects including: FAIN – Future Active IP Networks project (2000-2003) [12], CASPIAN project (2001-2002) [33] and ANDROID project (2000-2003) [29]. The first reference book on Programmable Networks is published in 2004 by Artech House [34].

Programmable networks as a term was used widely by the Opensig [19] community to characterize networks built on a minimal set of layers, allowing the services residing in each layer to be accessible through open interfaces—providing the basis for service creation (composition). Results from the Opensig community were formalized by the IEEE Project 1520 standards initiative for programmable network interfaces and its corresponding reference model [7]. This IEEE P1520 reference model (RM) provides a general framework for mapping programming interfaces and operations of networks, over any given networking technology.

The IEEE P1520 reference model, depicted in Figure 16 defines the following four interfaces:

CCM interface: The connection control and management (CCM) interface is a collection of protocols that enable the exchange of state and control information at a very low level between the network element and an external agent.

L-interface: This defines an application program interface (API) that consists of methods for manipulating local network resources abstracted as objects. The abstraction isolates upper layers from hardware dependencies or other proprietary interfaces.

U-interface: This mainly provides an API that deals with connection setup issues. The U-interface isolates the diversity of connection setup requests from the actual algorithms that implement them.

V-interface: This provides a rich set of APIs to write highly customized software, often in the form of value added services.




Figure 16: P1520 project reference model and the L-Interface abstraction model

In 2002 a working group of IETF, called Forwarding and Control Element Separation (ForCES) was formed with a similar objective to that of P1520, namely, “to define a set of standard mechanisms for control and forwarding separation, ForCES will enable rapid innovation in both the control and forwarding planes. A standard separation mechanism allows the control and forwarding planes to innovate in parallel while maintaining interoperability” [15][16].

The NE is a collection of components [24] of two types: control elements (CE) and forwarding elements (FE) operating in the control and forwarding (transport) plane, respectively. CEs host control functionality like routing and signalling protocols, whereas FEs perform operations on packets, like header processing, metering, and scheduling when passing through them. CEs and FEs may be interconnected with each other in every possible combination (CE-CE, CE-FE, and FE-FE), thus forming arbitrary types of logical topologies as in Figure 17. Every distinct combination defines a reference point, namely, Fr, Fp, and Fi. Each one of these reference points may define a protocol or a collection thereof, but the ForCES protocol is only defined for the Fp reference point.




Figure 17: ForCES architectural representation of the Network Element

There exist two main approaches to realise active networks: in the first solution, programs are injected into the programmable active node separately from the actual packet. This approach uses existing network packet formats and provides a discrete mechanism for downloading programs to the active nodes. User first stores the program to the network node. The program is executed when data packets associated to it arrives at the node. In the second solution, the capsule approach, a program is integrated into every packet. Encapsulation leaves present packet formats behind and replaces them with midget programs that are encapsulated to the transmission frames. When capsule arrives to the node, an Execution Environment interprets the program and executes it. In this approach, active node has build-in mechanism to load the encapsulated code, en execution environment to execute the code and a relative permanent storage where capsules can retrieve or storage information. Regardless of the approach, the main idea stays the same, the AN customises its content and the behaviour of the network can be altered dynamically by injecting new programs to the network nodes. The ability to inject software to the nodes gains benefits such as rapid application and protocol deployment, software updates and customisation by downloading user specific programs that are downloaded only when needed. A hybrid approach has also been proposed [1].

Figure 18: Basic active node architecture

A basic architecture for active nodes [8] is depicted in Figure 18. This model understands an active network as a mixture of active and legacy (i.e. non active) nodes. The active nodes run




the node operating system (NodeOS)—not necessarily the same—while a number of execution environments coexist at the same node. Finally, a number of active applications (AA) make use of services offered by the EEs. The NodeOS undertakes the task of simultaneously supporting multiple EEs. Its major functions are to provide isolation among EEs through resource allocation and control mechanisms, and to provide security mechanisms to protect EEs from each other. In addition, it provides other basic facilities like caching or code distribution that EEs may use to build higher abstractions to be presented to their AAs. All these capabilities are encapsulated by the node interface through which EEs interact with the NodeOS. This is the minimal fixed point at which interoperability is achieved. In contrast, EEs implement a very broad definition of a network API ranging from programming languages to virtual machines like the Spanner VM in smart packets and byte codes, to static APIs in the form of a simple list of fixed-size parameters [9]. To this end, EE takes the form of a middleware toolkit for creating, composing, and deploying services. The AN reference architecture [8] is designed for simultaneously supporting a multiplicity of EEs at a node. Furthermore, only EEs of the same type are allowed to communicate with each other, whereas EEs of different types are kept isolated from each other.

The following is a brief description of the facilities of the existing programmable networks platforms, including: Node Operating Systems, Node Execution Environments and Management of Programmable Networks.

3.1 Review of existing platforms Exokernel: Exokernel [50] multiplexes physical resources by providing a so-called library

operating system that exports interfaces that are as close to the hardware as possible—thus introducing as little as possible overhead. A clear disadvantage is code redundancy and the requirement to reimplement basic functionality found in legacy operating systems.

Moab/Janos: Moab [30] is a research operating system based on the OSKit. It exports an interface as required for the Janos [23] operating system. Janos creates a Java virtual machine with resource control in mind.

Nemesis: Nemesis [50] is a research operating system for multimedia, low latency communication. It introduced the fbuf structure to allow inter-process communication with zero-copy mechanisms. Nemesis was extended by a Resource Controlled Active Network Environment (RCANE) for resource control issues.

Scout: Scout [51]is based on xkernel v2, implements the path abstraction. It is a single address space research operating system without resource control mechanisms.

Bowman: Bowman [18] implements the active network interface specification in user space of Linux.

Crossbow/ANN: Crossbow [11] follows the ideas of Scout and the path abstractions. Flows can be bound to plug-in chains. Crossbow forms the conceptual basis of PromethOS. No resource control mechanisms are foreseen. Due to its implementation, Crossbow is deeply bound to a specific release of NetBSD.




Lara++: Lara++ [22] provides an active node operating system that is implemented on Windows. It provides an execution environment (called a processing environment) into which active components are loaded. These components are interconnected to form a graph similar to the concepts of Scout.

Pronto: Pronto [52] provides a framework for node programmability. It is based on Linux and runs in kernel space. It follows the plug-in approach by providing its own execution environment.

PromethOS: PromethOS [17] extends the standard netfilter architecture of Linux by adding, at run time, programmability and extensibility to the Linux kernel for unknown components. The whole framework is inherently portable, strictly allowing the interfaces of netfilter. The performance of the PromethOS framework is comparable to the standard Linux networking environment; only one additional hash table lookup has been introduced to schedule the PromethOS plug-ins.

SILK: SILK [2] extends the Linux kernel by providing the path abstraction in the kernel space. By SILK, the Scout architecture has been ported to a widely used operating system. Basically, the architecture can be compared to the Linux netfilter architecture for packet mangling. The NodeOS interface specification is mapped from user space on the Linux kernel by SNOW. Scout and SILK intercept the system call interface of Linux for communication with the user space; the GENI interface on the other end is connected to the input port at the Linux network stack. However, SILK does not provide resource control mechanisms. VERA provides an interface to the Intel IXP1200 network processor. It is attached to SILK by providing a virtual device in Linux. With use of VERA, the programming of the microEngines in the IXP1200 is achieved

ANTS: ANTS [3] is a Java-based toolkit for constructing an active network and its applications. ANTS is based on an aggressive capsule approach, in which code is associated with packets and run at selected IP routers that are extensible. The latest version of ANTS (version 2.x) relies on the Janos Java NodeOS.

ASP: ASP [6] is implementing the “strong EE model” by offering a user-level operating system to the AAs via a Java-based programming environment. The underlying capabilities of NodeOS and Java are enhanced (e.g., usage of Netiod [5][4] to replace the socket interface) and complex control plain functionality such as signaling and network management can be realized. Customized security manager, out of band code loading, routing of active packets via IP and virtual connectivity [user datagram protocol/Internet protocol (UDP/IP) tunneling] are some more features of the ASP EE.

CANES: CANES [10]seeks an approach to active networks that supports high performance while also permitting dynamic modification of network behavior to support specific applications and/or provide new services. The CANES execution environment runs on the Bowman [18] implementation of the NodeOS specifications, and is specifically built for composing services within the network [25].

FAIN EE: One of the key concepts defined by the future active IP networks (FAIN) architecture [12] is the execution environment and the virtual environment (VE) as a group of EEs. In FAIN, drawing from an analogy based on the concepts of class and object in object-oriented systems, we distinguish EEs between the EE type and the EE instances thereof. An EE type is characterized by the programming methodology and the programming environment that is created as a result of the methodology used. The EE type is free of any implementation




details. In contrast, an EE instance represents the realization of the EE type in the form of a run-time environment by using specific implementation technology; for example, programming language and binding mechanisms to maintain operation of the run-time environment. Accordingly, any particular EE type may have multiple instances, while each instance may be based on different implementations. This distinction allowed us to address the principles that must govern next generation NEs and the properties that they must possess, separate from the issue of how to build such systems. The programming methodology that was used as part of the FAIN EE type was the building block approach, in which services break down into primitive, distinct blocks of functionality, which may then be bound together in meaningful constructs. To this end, services can be rebuilt from these primitive forms of functionality; that is, the building blocks, while the building blocks may be reused and combined together in a series of different arrangements as dictated by the service itself. In FAIN, we have built two different EE instances: a Java EE and a Linux kernel-based EE, of this particular EE type [20]. The FAIN architecture also allows EEs to reside in any of the three operational planes; namely, transport, control, and management, while they may interact and communicate with each other either across the planes or within a single plane. In fact, it is not the EEs that communicate, but rather distributed service components hosted by them—a subset of the deployed network services that can be accessed by applications or higher level services by means of the network API they export. EEs (instances) are the place where services are deployed.

PLAN: PLAN [13] is a functional scripting language (based on Caml) with limited capabilities, designed to execute on routers. The fundamental construct in the language is one of remote evaluation of delayed functional applications [14]. PLAN is designed to be a public, authentication-free layer in the active network hierarchy, so it has limited expressive power to guarantee that all programs will terminate. PLAN can also be used as a “glue” layer that allows access to higher level services (which may or may not require authentication). This combination allows much of the flexibility of active networking, without sacrificing security.

SNAP: SNAP [21]is an active networking system where traditional packet headers are replaced with programs written in a special-purpose programming language. The SNAP language has been designed to be practical and with a focus on efficiency, flexibility, and safety. Compared to PLAN, SNAP offers significant resource usage safety, and achieves much higher performance at the cost of flexibility and usability. A PLAN-to-SNAP compiler has also been developed [14].

Tamanoir EE: This is based on Java language. Tamanoir active nodes (TAN) provide persistent active nodes that are able to handle different applications and various data streams at the same time [26][27]. Two main transport protocols [transmission control protocol (TCP) and user datagram protocol (UDP)] are supported by the TAN for carrying data. The active network encapsulated protocol (ANEP) format is used to send data over active networks. The injection of new functionalities, called services, is independent from the data stream: Services are deployed on demand when streams reach an active node, which does not hold the required service. There are two ways for service deployment: with a service repository, where TANs send all requests for downloading required services; and without, in which case the TAN queries the active node that sent the stream for the service. When the service is installed in memory, it is ready to process the stream. It is worth noting that a stream can cross equally a classical router, obviously, without any processing actions. TAN has an original approach regarding on-the-fly storage in the network, as it takes advantage of the Internet backplane protocol (IBP) project results concerning network storage management; a project that aims to expose network storage resources in an Internet-style way.




LANE – Light Active Node Engine is an active network platform developed at VTT Technical Research Centre of Finland. It is a result of two years work and two active networking projects: Caspian [33] and MAO. Caspian was a project in which was produced an Active Network prototype and “Mobile Active Mail”- Active Application (AA). The MAO-project was VTT’s internal project which aim was to produce a whole new active network platform and active services for demonstration and testing purposes. The main benefits of using active network instead of traditional passive network are rapid development and especially deployment of new services; new service types are enabled by AN technology and an far more enhanced network management. In an active network, services can be located ideally, customised to meet subscriber’s needs, and relocated as needed by a mobile user. High-level design divides the system to two main active components: Active Server (AS) and Active Router (AR), thus the execution environment and the activity of the network are separated. The benefit of the separation is that the tasks that require lot of processing power are handled in the server, while resources of the router are conversed, thus keeping the routing delays low. A rule of thumb is that IP-layer actions lay in the Active Router and actions above are located in the Active Server. In addition to Active Server and Active Router, there also exists some supporting and testing tools such as IP Packet Tester and Active Server Management tool.

ABone Management - ABone [35] is a DARPA-funded virtual testbed for the active networks research program. It is composed of a set of computer systems configured into virtual active networks. The ABone nodes are administered locally, but can be used by remote users to start up execution environments and launch active applications. Each core ABone node is configured with seven UNIX-specific accounts. Each account runs an instance of the Anetd active network management daemon. These daemons allow remote EE and AA developers to install, configure, and control EE instances in these nodes. The Anetd client, sc, can be used to communicate with Anetd on these machines and perform the required functions. Anetd performs two major functions: deployment, configuration, and control of network software, in particular EE prototypes; and demultiplexing of active network packets encapsulated using the Active Network Encapsulation Protocol to multiple EEs located on the same network node.

ANDROID - The Active Network DistRibuted Open Infrastructure Development (ANDROID) project [29] proposes a policy- and event-driven architecture for the management of Application Layer Active Networking (ALAN) [42] networks. The project is mainly focused on the management of active servers, where programmability up to the application-level is allowed. Nonetheless, they also consider a reduced management of the active routers; that is, configuration of users’ routes toward their assigned active server. The ANDROID management framework is policy based and event driven. Policies and events are introduced into a new eXtensible Markup Language (XML) document called a notification. When a user wants to install a new service on an active server, it sends an event to the network operator. The operator initiates the resources and security checks, based on available policies, and then loads the active service. Active services are continuously monitored, so that if unexpected behaviour is detected, corrective policies can be enforced to correct this behaviour.

AVNMP -The Active Virtual Network Management Prediction (AVNMP) [37][40] algorithm is a proactive management system; in other words, it provides the ability to solve a potential problem before it impacts the system, by modeling network devices within the network itself, and running that model ahead of real time. Predictions range from network performance to possible network or node faults. Such a proactive management approach is particularly useful in many applications. For example, in the case of handovers in a mobile environment, if the handover is prepared in advance, the service quality degradation is minimized. Similarly in QoS-sensitive applications, particularly those that are affected by an excessive or variable delay, the management system can avoid congestion before it actually happens. The system is




composed of different types of active nodes with different targets. Some active nodes realize predictions based on the information they have, and publish it on the network. These predictions can either be about the network or about an offered service. Then, a second type of active node captures these predictions and introduces them into the management algorithms that have been implemented. The algorithms basically compare the actual state of the network with previous predictions. If a previous prediction was incorrect, the configuration actions caused by this prediction are removed from the network. This correction is done through special kinds of messages called antimessages.

HIGCS -The hierarchical iterative, gather-compute-scatter procedure (HIGCS) uses a distributed, out-of-band approach to service deployment at the network-level. Similar to hierarchical routing schemes, nodes build clusters and elect a cluster leader to aggregate information (e.g., node capabilities) and to represent it to the upper hierarchy level. The information exchange is based on a specific control protocol (e.g., an extension to a hierarchical routing protocol), and therefore an out-of-band approach. It is distributed because cluster leaders process (aggregate, distribute) information relevant to service deployment within their cluster. As HIGCS is intended for the network-level deployment, a discussion of the node-level service deployment is not applicable. Furthermore, HIGCS is targeted toward programmable networks, and, as a consequence, does not deal with code deployment.

NESTOR -Network Self Management and Organization (NESTOR) [44][45] is an architecture for network self-management and organization. The NESTOR system seeks to replace labor-intensive configuration management with one that is automated and software intensive. Configuration management is automated by policy rules that access and manipulate respective network elements via a resource directory server (RDS). The RDS provides a uniform object-relationship model of network resources, and represents consistency in terms of constraints; it supports atomicity and recovery of configuration change transactions, and mechanisms to ensure consistency through changes. RDS pushes configuration changes to network elements using a layer of adapters that translate operations on its object-relationship model to actions on respective elements. NESTOR has been implemented in two complementary versions, and is now being applied to automate several configuration management scenarios of increasing complexity, with encouraging results.

PLANet/SwitchWare Management- SwitchWare [43] is an architecture that combines active packets with active extensions to define networked services. Active packets contain code that may call functions provided by active extensions. Active extensions may be dynamically loaded onto the active node. PLANet implements this architecture using a safe, resource-bounded scripting language (called PLAN) in the active packets, and a more expressive language to implement active extensions. At the network-level, service deployment is implemented in a distributed, in-band way, using active packets similar to ANTS and ANN. An interesting service deployment characteristic of the SwitchWare architecture is found at the node-level. In fact, both in-band and out-of-band service deployment are used to combine the advantages of both worlds. Active packets contain code (in-band) that can be used like a glue to combine services offered by dynamically deployed active extensions (out-of-band). Similar to ANN and ANTS, the content of active packets may be modified by active extensions. Therefore, the choice between a centralized and distributed way of deployment is left to the service designer.

Smart Packets -Smart packets [38] focus on applying active networks technology to network management and monitoring without placing undue burden on the nodes in the network. The management applications developed are oriented to diagnostic reporting and fault detection. The framework is based on active packets carrying programs that are executed at nodes on the




path to one or more target hosts. Smart packet programs are written in a tightly encoded safe language (spanner), specifically designed to support network management and avoid dangerous constructs and accesses. The spanner code is obtained after compiling the program written in a high-level programming language specifically created for the project: sprocket. Smart packets are generated by management or monitoring applications and are encapsulated in ANEP. The ANEP daemon is responsible for receiving and forwarding smart packets correctly. Security is achieved through the limitations imposed by the tightly encoded safe language, and through a prudent execution of smart packets code: If the virtual machine does not know how to proceed with the code, then it stops the execution. Additionally, further security checks are realized such as user authentication and data integrity checks.

SENCOMM -The main objective of the Smart Environment for Network Control, Monitoring and Management framework is to implement a network control, management, and monitoring environment using active networks. SENCOMM is somehow a continuation of smart packets, since it reuses much of the smart packets system. User-written network management and monitoring programs generate smart probes, which are encapsulated in ANEP frames. The probes are demultiplexed to the local SENCOMM management EE, which injects the smart probes into the network. A probe can be sent to be executed only at the destination or at every active node running the SENCOMM management EE (measurements and control operations might be taken in a single packet’s traversal of the network). The probe contains directives to access loadable libraries of functions on the node, and registers to receive incoming packets that meet a filter specification, and optionally inject the packet back into the network. Probe packets can be sent either to unicast or multicast addresses. The information content returned by probes to the management center can be tailored in real time to the current interest of the center.

VAN -The virtual active network (VAN) management framework[39] allows customers, on the one hand, to access and manage a service in a provider’s domain, and, on the other hand, to outsource a service and its management to a service provider. VAN supports generic, that is service-independent, interfaces for service provisioning and management, and customized service abstractions and control functions, according to a customer’s requirements. Only two types of EE exist in the management architecture: the management EE that works on the management plane, and the service provider EE that works on the data transfer as well as on the control plane. The tasks of the management EE are limited to node configuration and the management of virtual active networks in the active network provider’s domain. Note that in this context VAN management means the creation, modification, monitoring, and termination of virtual active networks. The management EE is not concerned with the management of active services running in the virtual active networks. In the VAN architecture, a service and the corresponding service management run in the same instantiation of a service provider EE.

3.2 The ABLE platformThe Active Bell Labs Engine (ABLE) [36][41] proposes a novel active network architecture that primarily addresses the management challenges of modern complex networks. Its main component is an active engine that is attached to any IP router to form an active node. The active engine is designed and implemented to execute programs that arrive from the network. The engine facilities and executed programs are oriented to the monitoring and control of the attached router. The active code is implemented in Java, and active packets are encapsulated in a standard ANEP header over UDP.




ABLE runs adjacent to a hardware or a software router and extends its basic forwarding functions with the active networking functionality. ABLE supports long lived, mobile active applications. A code of an active program is encapsulated in an active packet (or several active packets if it is too big for one) and sent to the destination active router. It can be captured by the intermediate active routers on the way, (if it is sent to the special destination port), which analyze the captured active packets, extract the contained active program and if it has appropriate permissions, run its code in the router secured active environment. An active program could then access the adjacent router system resources and read or change the necessary information through the well defined ABLE API. It can also distribute itself to other active routers and communicate with the program instantiations on other routers.

Figure 19: Main classes of the ABLE Active Server

The ABLE system architecture consists of three Brokers a Session Broker, an Info Broker, a Control Broker and a Diverter unit (see Figure 19). A “Broker” is defined in the system as a processing entity that completes tasks on behalf of a requester. The Session Broker creates, manages and cleans up the processing environment and system resources as well as manages the live active session. The Info Broker provides an monitoring channel by exporting local state to active sessions and mediating all the queries for local state information. The Control Broker provides a secure channel for control operations by exporting a set of control methods and associated policies. The Diverter unit redirects active packets that were caught by the router filter to the Session Broker. Process management, information queries and control requests all are handled by different brokers because there is a functional differentiation between these activities. In addition each task requires a different set of security restrictions and performance metrics. The communication between active sessions, the diverter unit and




the brokers is done using TCP or UDP sockets. Therefore the ABLE system can support active applications written in any language as long as it supports the socket interface. However, all active applications that were written for the system are Java programs since this is widespread programming language and Java programs could be executed in the limited environment of the Java Virtual Machine. In the following sections we briefly describe each of the existed components in the ABLE system.

3.2.1 The Session Broker

The Session Broker manages the initiation, behavior, communication and termination of all active sessions. The ABLE architecture is designed to support long lived, mobile active sessions. Network management and (possibly other applications) must be long lived in order to implement any ongoing monitoring services. The aspect of mobility is essential to propagate a distributed application throughout the network. ABLE allows active sessions to control code distribution. Therefore, the Session Broker’s responsibilities can be divided into two parts: managing active sessions (the metaBroker) and exporting mechanisms for communication and mobility.

As a manager of active sessions the Session Broker initializes new sessions, allocates local resources (CPU, memory, bandwidth) to them, monitors their activities and deals with active sessions termination. A session is terminated when its code is naturally ended or if it tries to use too many resources or attempts to violate security restrictions. Aging timers are used to monitor active session activities to prevent excess resource consumption or termination of a session that did not free its allocated resources. To control session execution all session code written in Java (which is the only language for programming active sessions supported by ABLE) is run through Java virtual machine.

The second role of the Session Broker is to control the communication and the mobility of active sessions through a well defined API. It supports functionality that enables active sessions to distribute their own code to all active nodes that are neighbours of the node where this session is running, or to distribute it to a specific active node. The Session Broker prevents a simultaneous execution of multiple copies of the same application on a single node. The Session Broker API also contains functions for exchanging messages between the same instantiation of an active program on different active nodes and a specialized report sending function.

3.2.2 The Info Broker

The Info Broker is used to export local device information to active sessions. Specifically, the Info Broker specializes in retrieving information or state from local devices and supplying it, when requested to the active sessions. Without the Info Broker, active session programmers must deal with writing low level code in order to retrieve data from the specific local devices. The three components of the Info Broker are: Engine, Interface and Cache are abstracting these details away from the application programmer while providing an infrastructure for efficient information retrieval. The Engine is the “intelligence” of the Info Broker. It determines the best avenue to handle the request, retrieves the information and finally transmits it back to the active session. The best way to handle the request is selected based on




the volatility of data, i.e., the length of time it can be cached before its value is expected to change. In addition, the Engine also abstracts the instrumentation details of the low level managed device communication protocols away from the programmer. The Interface provides API for the application to access the requested data. The API functions combine several atomic operations in one function to provide more efficient access to local device state. The small local cache serves to decrease query response time at the application level and to reduce the query load of the managed device.

3.2.3 The Control Broker

The Control Broker is a bidirectional channel that enables active sessions to control the behavior of the router. This allows authorized active sessions to perform network engineering tasks such as changing IP route or modifying the QoS parameters in the router. A special security mechanism should be used in order to enable access to this extended power only to authorized applications.

The overall structure of the Control Broker is very similar to that of the Info Broker. It has an Interface that is a collection of classes used by the active session to request the service, an Engine which process requests and a Security Manager.

The Engine receives a request, checks whether it is legal by both authenticating the sender session and verifying no conflicts with previous, active requests and then executes it using the best available underlying method or indicates that an error has been found.

3.2.4 The Diverter and Linux Filtering System

The role of the Diverter unit in the ABLE system is to redirect active packets that were caught by the appropriate rules in the router filter to the Session Broker. Its implementation depends on the hardware system on which ABLE is installed. In the software router implementation using Free BSD the diverter unit is implemented in software. This is done using a built in firewall package.

WE found the basic architecture of this system to be best suit for the need of CONTEXT as described in the previous sections. However, an extensive effort was needed in order to define and develop a system that could support all the different functionality as needed from a distributed service execution platform. The specification and implementation details of the new active system built for the CONTEXT project is described in the next section.




4 DINA: THE AN PLATFORM FOR THE CONTEXT PROJECT

The DINA active platform was developed by the CONTEXT project based on concepts and ideas used in the Active Bell-Labs Engine (ABLE) system (as described in the previous section). In developing DINA, we put a strong emphasis on the missing components needed in order to create a scalable platform that allows the easy deployment of network related context aware survives.

This section presents DINA’s software architecture, its various software modules and explains the way in which these modules interact. It also presents the data flow of active services from creation to termination with emphasis on the interaction with the IP and AN API.

DINA is a modular and scalable software architecture that enables to deploy, control, and manage active services (sometimes called sessions or active sessions) over networks entities such as routers, WLAN access point, media gateways, and servers that support such services in IP-based networks. In addition to the deployment control and management capabilities, DINA provides a scalable, platform independent, interfaces that can be used by the active services in order to mange, control, retrieve information or perform other operations in the local node.

4.1 The Active PlatformThe active platform is an application that enables active node to deploy, control, operate and manage context-aware services. DINA active platform consists of an Active Engine and a Forwarding Element, namely router, WLAN access point, media gateway, etc. (see Figure20).

Figure 20: DINA Active Platform environment

The modular design of DINA allows the different components to be logically separated. In particular the Active Engine and the Forwarding Element can be either physically separated or co-located at the same machine. This kind of architecture enables DINA to support different


Forwarding Element

Active Engine

Execution Environment Interface

Filter

MIB CLI



platforms of different vendors using almost an identical software components implementation.

Figure 21: DINA block diagram architecture

DINA is modular software that consists of two main components, the Session Broker and the Diverter that runs in parallel on each active node. In addition to these two components, other brokers can run (in parallel) and give enhanced services to the active sessions using broker interfaces. The communication between DINA’s modules is usually done by UDP transactions and TCP connections, although other methods can be used as well.

4.1.1 DINA Active Packets

DINA active packets are UDP packets whose payload consists of an ANEP header followed by an active payload.

Since ANEP is a general encapsulation protocol for active networks, a dedicated DINA header extends the ANEP header and it is considered to be an ANEP option.

Figure 22: DINA packet format


Execution Environment Interface

OS

SessionBroker

InformationBroker

ControlBroker

QOSBroker

AS1

Session

Broker

Interface

Information

Broker

Interface

AS2

Session

Broker

Interface

Control

Broker

Interface

...Diverted packets

ANEP HeaderUDP HeaderIP HeaderANEP Option: DINA Header

Header

DINA Option: Class Length

Active Payload

Divertor

Execution Environment



4.1.1.1 UDP/IP Header

DINA active packets are identified as UDP packets with destination port 3322, 3323 or 3324. The destination port of the UDP packets distinguishes between three kinds of active services. In the first case, where the destination port of the packet is 3322, the packet is captured by the first active node in the route of the packet. In the second case, where the destination port of the packet is 3323, only the destination host receives the packet, while all other active (and non active) nodes in the route forward the active packet to its destination like any IP packet. In the last case where the destination port of the packet is 3324, the packet is captured by every active node in the route of the packet. Namely the active packet is forwarded to its destination and each active node on the path creates a local copy.

4.1.1.2 ANEP Header

ANEP is a mechanism for encapsulating active networks frames for transmission over different media.

Figure 23: The ANEP packet header format

The current version of ANEP, which is described here, and should be set in the ‘Version’ field, is one.

The ‘Type ID’ field indicates the environment of the message. DINA environment ID is 62.

The ‘Flags’ field indicates what the active node should do if it receives a packet with unrecognized type ID. The node can forward the packet to other nodes (using its standard routing mechanism) or it can discard the packet.

The ‘Header Len’ specifies the length of the ANEP header, including all the options in 32-bits words.

The ‘Packet Len’ specifies the length of the packet, starting from the ANEP header (included), in bytes.

An ANEP header may contain one or more options in the format TLV (Type Length Value). The length of the Type and the Length fields are 16 bits (each) and they describe the type of the option and its length respectively. The length of the option value varies and depends on the option type.

4.1.1.3 DINA Header

Every ANEP packet that has type ID of 62 (i.e. extended ABLE environment) must contain a DINA option. The value of this option has the following format.


Version Flags

Header Len

Type ID

Packet Len

Options



Figure 24: The DINA packet header format

The ‘Version’ field contains DINA version, which is currently one.

The ‘Language’ field determines the type of the payload and it can be zero for data payload or one for Java application payload. The different types are discussed in more detail in Section 4.1.1.5.

As described in Section 4.1.2, in order to capture active packets, an active node, which is not the destination of the packet, should filter these packets using a policy-based routing mechanism. This filtering is done according to criteria that are based on information from the UDP (and IP) header. This mode of operation can lead to a problem when IP fragmentation is used. In this case only the first fragment contains the UDP header and therefore intermediate active nodes will not be able to capture the entire packet.

In order to overcome this problem a fragmentation mechanism has been employed in DINA header that enables to fragment active packets in the application layer. This way every fragment contains IP, UDP and ANEP (include DINA option) headers (i.e. only the payload is fragmented).

The ‘Flags’ and the ‘Segment Number’ fields are used for the purpose of fragmentation. The ’Flags’ field indicates if the current fragment is the last one, while the ‘Segment Number’ field indicates the reference number of the segment is the packet.

The ’Session Sequence’ and the ‘Session ID’ fields are used to uniquely identify the service in the active environment, namely no two services have the same values of these fields.

A DINA header may contain one or more options in the format TLV. The length of the options varies and depends on the option type.

4.1.1.4 Class Length and Class URL Option

An active code is a set of classes that should be executed by the active node. These classes contain a main class that is the first class in the active packet followed by accessory classes (see Section 4.1.1.5).

The Class Length Option and the Class URL Option contain the length of a class or the length of the URL that is presented in the payload. If the payload contains more than one class, then a few option fields are concatenated


Version Language

Session Sequence

Session ID

Flags Segment Number

Options



4.1.1.5 Active Payload

As mentioned above, the ‘Language’ field in the DINA header determines the type of the payload, which can be one of the following options:

A new active service. In this case the payload contains an application that should be executed by the receiver active node. This application may be followed by a set of parameters for this application. Currently DINA supports Java application. The application consists of one or more classes in which the first class is the main class to be executed by the active node, while all other classes are used by the main class. Each class can appear explicitly (i.e. the payload contains the bytecode of the class) or implicitly (i.e. the payload contain a reference to the class).

Data for an existing service. In this case the payload contains a set of parameters. When an active node receives such packet, it forwards the parameters to the related active service, which is already running on the node.

4.1.2 Diverter

DINA active packets that should be captured by active nodes in the route are identified as UDP packets with destination ports 3322, 3323 or 3324 (see Section 4.1.1.1).

In order to capture such packets, an active node should employ a policy-based routing mechanism that enables to filter and capture packets according to predefined rules. Using this kind of mechanism, an active node should captures such active packets and direct them to the Session Broker.

The Diverter is a simple application that receives active packets, which were captured by an active node and forwards them to the Session Broker. The Diverter may perform supplementary filtering in order to retrieve non-active packets to the network.

The implementation of the Diverter depends on the platform and the interface with the policy-based routing mechanism, in which the active node is employed.

4.1.3 The Session Broker

The Session Broker is the core on the active node. It receives and parses active packets, handles and manages existing services, and it distributes active packets according to requests of the services.

The Session Broker is an event driven application that receives events from different communication channels and from an aging mechanism.

It communicates with the services via the Session Broker Interface of each service. Unlike other brokers, the Session Broker interface is essential for the execution of any service in the system.

4.1.3.1 Session Broker Channels

The Session Broker has fix communication channels.




The external communication channel is used to receive and send active packets. An active node can receive such packets from other active nodes or from the originator host. Active packets are sent to other active nodes, according to services requests.

The data channel and the admin channel are used to communicate with the services. The data channel is used in order to send active payload from the Session Broker to the active session and vice versa. Using the admin channel, a service can send control messages to the Session Broker. The following control messages can be sent.

‘New’. When the Session Broker establishes a new active session, the session enters to a ‘Pending’ state. In this state the service is not yet ready to receive and handle data, and therefore the Session Broker drops any active packets that contain data, which is directed to this service. When the Session Broker receives a ‘New’ control message from an active session it changes the session state to ‘Alive’. Once the session is in this state, it can receive active packets from the Session Broker.

‘Refresh’. The Session Broker employs an aging mechanism in order to terminate old and unused active session (see Section 4.1.3.3). In order to avoid termination due to aging, an active session should refresh itself by sending a ‘Refresh’ control message from time to time.

‘Kill’. An active session sends a ‘Kill’ control message in order to terminate itself.

The JVM channel is used to communicate with the JVM’s that are attached to the Session Broker and used to execute Java type active services (see Section 4.1.5.1).

The management broker channel is used to communicate with management broker interfaces that may be used by the active services, to receive request and retrieve information regarding the current status of the Session Broker (see Section 4.3.1.1).

One or more classes in the active packet may be referred by a URL. In this case instead of sending the class in the active packet, one can send a URL in which the class can be found. This URL can be a HTTP or a FTP server or a file in the local file system. The URL Class Loader (UCL) communication channel is used by the Session Broker to extract the set of classes that are referred by the URL in the active packet.

4.1.3.2 Session Database

The Session Broker maintains a database, which contains information regarding all active services that are currently present at the system. For each service the following information is kept:

State. This field describes the state of a service and it can be one of the following options: ‘Pending’ state or ‘Alive’ state (see Section 4.1.3.1).

Aging. This field contains aging information of a service, namely the service time to live. When this time is expired, the Session Broker should terminate the service. A service can renew its time to live by sending a ‘Refresh’ control message to the Session Broker (see Section 4.1.3.1).

Sequence number & Session ID. The combination of sequence number and the session ID uniquely identifies the service in the active node. These fields are extracted from the DINA header (see Section 4.1.1.3).




IP address and UDP port. These fields are used in order to send data to a service (via data channel).

JVM. This field contains information regarding the JVM that runs the service when the active code is written in Java (see Section 4.1.5.1). The Session Broker uses this information to control the service (e.g. terminate it) when it is necessary.

4.1.3.3 Aging Mechanism

In order to prevent old, unused services from utilizing the active node resources the Session Broker employs an aging mechanism. The aging mechanism allows the Session Broker to terminate services, which are considered to be unused. A service can avoid from termination as a result of aging by sending a ‘Refresh’ control message to the Session Broker (via the admin channel) from time to time.

4.1.4 URL Class Loader

In case that the active payload contains one or more classes that are referred by a URL, the active node should obtain these classes before it execute the active application. In order to avoid blocking, this operation is done by a separated process, the URL Class Loader. This process is called by the Session Broker and downloads all the necessary classes. When the URL Class Loader obtains all the classes it sends them to the Session Broker.

4.1.5 Execution Environment

The Execution Environment (EE) is the actual environment in which the active applications are being executed. In order to support a few types of active application, more than one EE can be used.

4.1.5.1 Java EE

The Java Execution Environment is a set of JVM’s (Java Virtual Machines) that are attached to a single Session Broker and run Java type active services. Each JVM can handle more than one service using Java thread mechanism, and there may be more than one JVM attached to a single Session Broker. In addition, these JVM’s may run on different machines (see Figure25). For each service the Session Broker can determine which JVM to use according to its internal policy (e.g. finding the JVM with minimum active services, finding the JVM with minimum load).

The Session Broker communicates with the JVM’s using its JVM channel (see Section 4.1.3.1). This channel enables the Session Broker to control and maintain the JVM’s and it allows adding and removing JVM dynamically.

4.1.6 Brokers

The brokers are modules that give active services the capability to utilize host information and resources and perform operations in the local environment. The concept of using brokers has the following advantages:




Figure 25: Java Execution Environment in DINA

Improving the system security and protecting it against harmful services that may cause (deliberately or accidentally) problems in the active node. The usage of brokers, in addition to other security mechanisms (Section 4.4), prevents services a direct access to sensitive information or resources in the local environment. If a service needs to access such resources, it must use the appropriate broker that can decide, based on its policy, whether to perform the required request or to deny it.

Enabling advanced access control, based on the services and the required resources or information. In addition to a basic binary access control that determines which services and which users can run services on an active node, each broker can determine its own policy for utilizing its resources.

Providing identical, homogeneous, platform independent, interfaces that can be used transparently by the services. Resource and information utilization is differing from one platform to another. The usage of brokers enable service to access these resources regardless to the platform and the system that hosts the service. Moreover, once the broker is implemented for a specific platform, services can transparently use it without any change.

Scalability and Stability. Each broker provides a set of operations that can be performed by the services using the interface broker API. When a new operations need to be added according to the requirement of new services, this may be done by implementing new brokers that will meet these requirements. In addition, when a broker fails, it impacts only services that use this broker while other services that do not use this broker can continue their work transparently.

Each broker module consists of a broker interface and may include other components as well.

For instance, a typical implementation of a broker consists of broker interface and a broker application that interact using UDP transactions or TCP connections. Nevertheless, other implementations are accepted and may be employed as well.


Host III Host I Host II

Session Broker

JVM 1 JVM 2

AS Code

AS Code

JVM 3 JVM 4

AS Code

AS Code

AS Code

ASCode

JVM 5 JVM 6

AS Code

AS Code

AS Code

AS Code

AS Code



4.2 Code and service execution supportAs explained before, the service logic is translated into active code that is executed in DINA nodes to deliver the service as needed. In order to compile and send active packets into the network, one should use the code invocation support package that provides a unique interface to compile and send active packets.

This package allows creating active packets using its constructor, adding classes or data to the active packet, and sending it to a specific active node. In addition it supports fragmentation of the active packet as it described in section 4.1.1.3.

Although one can create active packets without using the code invocation support package, it is recommended to use it in order to be compatible with future changes in the active platform and in the packet format. As such, the code invocation support package will be used by the service creation modules of the CONTEXT system, as described in Deliverable D3.2, in order to generate and deploy the code representing the service logic.

4.2.1 API specification

The constructor ‘activePacket’ creates an active packet with a specific sequence number and session id. Then, using the methods ‘addClass’ and ‘addUrl’, one can add classes and references to classes to the active packet respectively. When more than one class is added the first class in considered as the main class that will be executed by the execution environment in the active platform. Using the ‘adData’ Method one can add data to the active packet. This data must be added in the end (i.e. after all the classes) and it is extracted by the active. Finally, the ‘send’ methods send the active packet to an active node.

public class activePacket{public activePacket(int seq, int sid);public void addClass(String fileName);public void addClass(URL url);public void addUrl(URL[] url);public void addData(InetAddress d);public void addData(byte d);public void addData(short d);public void addData(int d);public void addData(String d);public byte[] getBuf();public int getLength();public void send(InetAddress dest, int port);public void send(InetAddress dest, int port, int mtu);}

4.3 Management of active nodes

4.3.1 AN management

As described before, the collection of active platforms is the distributed environment in which the service logic is executed. Thus, in order to ensure that the service is available, one needs




to manage the active nodes. Managing active networks is a very challenging field, one has to verify both that each node is operating properly, and that the overall network components, such as code invocation and communications are operating within the designed scope. In order to manage the active platform, a distributed management application is implemented and run on every managed active node. An active code belonging to this application is sent into each active node. In each node the management code retrieves local information, and controls the active platform. The interaction of the management application and the active node platform is done using the management broker as described below.

4.3.1.1 Management Broker

The Management Broker Interface provides a management active service the capability to control the active environment. It contains an API to control and retrieve information regarding the overall system resources utilization or regarding a specific session.

4.3.1.1.1 API specification

The following methods have been specified for this API: ‘systemNumActSessions’ returns the number of active sessions in the system. ‘systemGetActSessions’ returns the session ID and the sequence number of the active sessions

in the system. ‘systemNumPendingSessions’ returns the number pending sessions in the system. ‘systemGetPendingSessions’ returns the session ID and the sequence number of the pending

sessions in the system. ‘systemNumAgedSessions’ returns the number of active sessions that has been terminated due

to aging. ‘systemNumActivePackets’ returns the number of active packets that has been received in the

system. ‘systemNumDroppedSegments’ returns the number of active packets that has been received

and dropped in the system. ‘sessionAge’ returns the age of a specific active session. ‘sessionState’ returns the status of a specific active session. ‘sessionNumOfRefreshes’ returns the number of refreshes that has been done by an active

session. ‘sessionTimeToLive’ returns the time to live of an active session. ‘sessionReceiveActivePacket’ returns the number of active packets that has been sent to a

specific active session. ‘sessionSendActivePacket’ returns the number of active packets that has been sent from a

specific active session. ‘sessionCpuUtilization’ returns the average CPU utilization of an active session. ‘sessionTerminate’ terminates an active session.

The interface follows hereafterpublic class mngBrokerInterface {public mngBrokerInterface();public int systemNumActSessions();public String [] systemGetActSessions();public int systemNumPendingSessions();public String [] systemGetPendingSessions();public int systemNumAgedSessions();public int systemNumActivePackets();




public int systemNumDroppedSegments();public int sessionAge(String sessId);public int sessionState(String sessId);public int sessionNumOfRefreshes(String sessId);public int sessionTimeToLive();public int sessionReceiveActivePacket(String sessId);public int sessionSendActivePacket(String sessId);public int sessionCpuUtilization(String sessId);public int sessionTerminate(String sessId);}

4.3.1.1.2 API Implementation details

The management broker retrieves information and controls the session broker and its attached JVM. Thus, the management broker is implemented as part of the session broker and it maintains global information (per active platform) and information per active session in the active platform.

4.4 Security Architecture

4.4.1 Introduction

The concept of active nodes that host external active applications makes these nodes vulnerable to malicious services that can use this fact in order to harm the node and use it for various attacks. To prevent such attacks, DINA uses several security mechanisms that enable controlling active services.

Here, security refers to authenticity and integrity of messages, authenticity of identity and control an object’s access to resources. Secrecy, privacy and non-repudiation of messages are not considered. More specifically, this architecture describes how a DINA node is able to verify the source and integrity of an active packet, verify the identity of the encapsulated active code, and apply the correct access control policy as the active code is executed in the execution environment.

Cryptographic mechanisms are utilised to implement these objectives.

4.4.1.1 Relevant Entities

“Context-aware Active Service Provider (CASP)” is the source of active programs. CASP is a logical entity that may encapsulate a number of nodes that all belong to the same administrative domain.

“Context-aware Active Network Provider (CANP)” manages the DINA nodes and any supporting elements. The CANP administrator manages policy rules and access control information that are stored in a repository.

“DINA node” is the active node where the active code is executed. DINA nodes retrieve policy rules and access control information from the CANP repository.

“Public Key Infrastructure (PKI)” is a network of Certificate Authorities (CA) and Certificate Repositories. Its function is to manage, store and deliver X.509 certificates and




Certificate Revocation Lists (CRL) that enable secure public key based authentication and encryption.

4.4.1.2 Relevant Objects

“Active Service” is the program that is executed in the DINA node. An active service is implemented by active code. Active code consists of a number of Java classes, or it is a native binary application. The active code accesses different brokers of the DINA node. Active code is created and compiled by CASP.

“Active Code Parameters” are arguments to the active code. Parameters may originate from CASP, and parameters may be added, removed, or modified by another DINA node.

“X.509 Certificates” encapsulate public keys and associated attributes.

“Permitted Access Control List (PACL)” contains all the access control related attributes. It is managed by the CANP administrator, and it is internal to the CANP.

“Static Security Policy File” determines the active node resources that can be used by the active service.

“Java Virtual Machine Security Manager” is a class that allows Java applications to implement and enforce a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed. The application can allow or disallow the operation.

4.4.1.3 Objectives of Security Functions

The objective of the security functions is to control an active code’s access to resources of the DINA node. The dynamic and static security mechanisms prevent the active code’s direct access to active node resources (such as I/O, network and file system resources). These mechanisms enforce active services to use the different brokers in order to utilise these resources. The static and the dynamic security mechanism complement each other but they differ in their operation. The static system detects security violation before the execution of the active session by parsing the active code. In contrast the dynamic system detects security violations on-line, namely during the execution of the active code. The policy of these security mechanisms is configurable and can be changed using configuration files.

From the CANP point of view, the objectives of authentication and access control are to prevent unauthorised use of resources, to prevent the active code from performing harmful functions, and to verify that the active code conforms to rules and policies agreed between the CANP and the CASP. Possible threats to a CANP are hackers, and software bugs in active code.

From the CASP point of view, the objective of access control is to assure that the active code does not perform functions that may harm the CANP or any third party. A possible threat is software bugs in active code that could bring the DINA node in to unstable state, or e.g. flood the network, and thereby cause harm.




4.4.2 DINA Security Requirements

This section describes the requirements for the authentication and access control functions.

4.4.2.1 Authentication and Verification of Integrity

R-A.1: The DINA node must have means to authenticate the source of an active packet. This is necessary to verify the claimed identity of the source of the active code and related parameters.

R-A.2: The DINA node must have means to verify the integrity of the active packet. That is, the DINA node must be able to detect if an unauthorised party has tampered the packet.

R-A.3: The DINA node must have means to verify the source (the creator) of the active code.

R-A.4: The DINA node must have means to verify the integrity of the active code.

R-A.4.1: The DINA node must have means to verify the integrity of active code that is fetched from a remote repository.

The requirements listed in this subsection relate to protecting the active packet while it travels in the network. There is an existing trust relationship between the DINA node and a set of source nodes. The DINA node must have means to authenticate the source in order to verify that the source is who it claims to be. Similarly, the integrity check must be performed to verify that the received code and parameters are identical to those the source sent.

Note that the active parameters may be modified in flight by an intermediate DINA node, whereas the code will remain unmodified. Thus there must be separate authentication and integrity check means for active code and for parameters.

4.4.2.2 Replay Protection

R-RP.1: The system must provide protection against replay attacks.

In a replay attack the attacker captures a valid active packet, and stores a number of these packets. Later the attacker resends these packets. As the packets contain valid signatures the DINA node accepts them and executes the active code.

Replay attacks may be used to bring the DINA node in to an unstable state. Even if the active code would not perform any unwanted operations, it wastes computing and storage resources, which may be used for example in a denial of service attack.

4.4.2.3 Identification of Active Code and Active Service

R-I.1: The DINA node must have means to verify the identity of the active code.

R-I.2: The DINA node must have means to identify the active service that the active code implements.

R-I.3: The identification must not rely on information provided by the source of the active code.

Correct identification of active code and active service is required since the necessary access permissions depend on identity of the code that is executed in the DINA execution environment (EE). During this step, the DINA node can not trust the source to provide a correct identity for the code and service. The identification must be performed internally to




the DINA node as otherwise a misbehaving but trusted source could bypass access control by providing false identity information.

4.4.2.4 Access Control

R-AC.1: The DINA node must have means to control the use of DINA node system resources.

R-AC.2: The DINA node must have means to map the identity of the active code to the set of policy rules that specify what the code is allowed to do in the DINA node.

R-AC.3: The DINA node must have means to enforce the policy rules for each active service that is executed in the DINA EE.

During these steps the DINA node fetches a set of rules, which define the access control policy. First, the Static Security Policy file is checked and required actions are performed. Second, the access control policy is specified in the PACL, and is internal to a CANP. The access control policy is enforced in the DINA EE.

4.4.3 Architectural Specification

4.4.3.1 Overall Architecture

The overall architecture is shown in Figure 26.

Figure 26: Overall architecture of DINA security

The sequence of security actions done by DINA Node are the following:

1. Active Applications code is fetched from the Service Provider.

2. Get X.509 certificate of the CASP from the PKI Infrastructure.




3. Verify the packets and codes auhentication and integrity

4. Check if the code is allowed to run in this node. Permissions are handled with PACL (Permitted Access Control List).

5. If the PACL is not found in the local repository, it will be fetched from the CASP's repository.

6. Enforce the Access Control Policy instructed by PACL's.

7. Execute the Active Code / Application.

The following sections explain the subfunctions in detail.

4.4.3.2 Access Rights Management

The access control policies within a CANP domain are managed by the CANP administrator.

Before access rights are granted for a new active service, the CASP contacts the CANP administrator and asks CANP to grant a set of access rights for an active code that implements the active service. The CANP administrator verifies that the active code is safe and valid, and grants the necessary access rights for the code. The access control policies are added to the PACL, and the CANP network is ready for the execution of the active code.

The CANP administrator may also add default policies for unknown active services. The policies may be per CASP, per DINA node, or even global policies with no restrictions.

4.4.3.3 Authentication and Verification of Integrity

4.4.3.3.1 General Description

Authentication between the CASP and DINA nodes is based on PKI, X.509 certificates, and digital signatures.

A digital signature provides authentication of the identity, and protects the content from unauthorised modifications. The data is signed at two levels:

Code Signature: The CASP signs the code when creating the code, and the DINA node verifies the signature before the retrieval of the access control policy for the active code.

Packet Signature: The sending node signs the whole packet (headers, code, parameters). The sender is either the CASP or an intermediate DINA node. The receiving DINA node verifies the signature upon reception of the active packet.

Code signing does not introduce significant computing overhead, since the signature is computed only once by the CASP. The code and its signature remain unchanged.

There are two modes to transfer the active code in to the DINA node. The code signature is handled somewhat differently in each mode:

1 The active code is sent in the active packet. In this case the code signature is attached with the active code in to the active packet.

2 The active packet contains an URL-pointer to the active code, and the DINA node uses this URL to fetch the active code. In this case the code signature is attached with the




URL-pointer in to the active packet. The DINA node uses the signature to verify that the fetched code is authentic and unmodified.

Figure 27 shows the two authentication modes.

Packet signing ensures that the packet can not be modified in flight without computation of a new signature. Packet signature must be recomputed only when the contents of the packet is changed. Simple forwarding of an active packet does not require the recomputation of the packet signature.

Figure 27: Code and Packet Signatures in the DINA security mechanism

Both the code signature and the packet signature must identify the signer. A plain output of a digital signature is not sufficient. The signature must be encapsulated with signer identifying data, which is also protected by the signature.

4.4.3.3.2 Description of Operation

CASP creates a key pair for digital signing purposes, and publishes the public key as a X.509 certificate, which is signed by a certificate authority. There must be chain of trust between the CASP and a root CA that the DINA node trusts.

CASP computes a signature for the active code during the creation of the code.

CASP builds an active packet with ANEP and DINA headers, the active code (or a URL reference to it), the code signature, and active parameters. CASP computes a packet signature for the active packet, fragments it (if necessary) and sends the packet to network. Every DINA node that modifies the active packet must recompute the packet signature.

When receiving an active packet, the DINA node verifies the packet signature. First, the source’s X.509 certificate is fetched from the PKI. Next, the validity and authenticity of the certificate is verified by forming a chain of trust between the source and the root CA, and by checking the certificate revocation lists (CRL) of the root CA and each intermediate CA. At last, the DINA node uses the source’s public key to verify the packet signature.




The code signature is checked in a similar way, except that the signer is the CASP (which may differ from the source of the active packet).

Low-level functions such as fragmentation and reassembly of an active packet must not require the recomputation of the packet signature. Thus the packet signature cannot cover all fields of the ANEP and DINA headers. Rather, a pseudo-header must be used in the signature computation.

4.4.3.3.3 Replay Protection

An active packet contains a unique identifier that distinguishes two packets form each other. The DINA node maintains state information about the identifiers of received packets.

A packet sequence number provides sufficient protection. The source node stores the sequence number of the last packet it has sent, and the destination node stores the sequence number of the last received active packet that was valid. Upon reception of a new packet the sequence number of the packet is compared to the stored sequence number. The packet sequence number is considered valid if it is larger (taking rollover in to account) than the stored sequence number.

An alternative method is to use daytime as the packet sequence. This way the source node does not have to store the sequence number. However, this method is sensitive to clock adjustment at the source node.

4.4.3.4 Identification of Active Code and Active Service

The active code that implements an active service is either a binary application or a set of Java bytecode classes. Furthermore, the code may be customised in CASP. That is, the active service consists of a base code and customised code.

In case of Java active services, the service consists of base classes and customised classes. The active service can be identified by the code signatures of the base classes.

4.4.3.5 Access Control

4.4.3.5.1 Permitted Access Control List (PACL)

All access control related information is stored in the PACL (in the CANP repository).

The PACL contains mappings from a set of parameters to a set of access control policy rules. The parameters needed to identify a set of policy rules are:

1. Active Code identity

2. Source of code: The CANP can define different access control policies for different CASPs.

3. DINA node: The CANP can define policies based on the attributes of the EE (e.g. location of DINA node in the network, amount of computing resources, etc.)

Parameters may contain wildcards, thus allowing default policies (per CASP for example). The PACL is accessed in the order of parameter accuracy. That is, policy rules for a specific (code, source, node)-triple override the default policies.




The CASP may also maintain a PACL, which contains the CASP’s preferred access control policies for each of the CASP’s active codes. The CANP may utilise this PACL to get access control policies for active code that is unknown but is originated from a trusted CASP. This form of PACL chaining allows the CASP to control that the execution of the active code does not cause significant harm even in case the code does not behave as designed.

The access control policy rules define what functions the active code is allowed to perform in the DINA EE. For example, an active service may be granted to call certain Java methods, connect to some remote servers, or send data via network at a specified maximum rate.

4.4.3.5.2 Static Access Control Enforcement

The static security mechanism parses the active code and finds a security violation before the execution of the code. In particular, it detects if the active code tries to access the system resources directly (i.e. without using the different brokers). This security system is employed in the session broker according to predefined security policy that can be dynamically changed using a static security configuration file. This configuration file determines the resources that can be used by the active service.

In Java EE, where the active code is a set of Java classes, the static security system checks each one of the classes in the active payload and extracts the instances that are used by these classes. If an instance is not determined in the static security policy file then the static security system denies the execution of the service and drops it.

The static access control must be extended such that the access control policy from the PACL can be used as input when applying the static access control to the active code.

4.4.3.5.3 Dynamic Access Control Enforcement

The dynamic security system detects a security violation during the execution of the active code. In Java EE, the implementation uses the Security Manager mechanism. Every time a system resource is used the security manager checks if the caller is one of the brokers (and then it accepts the operation). If not the operation is rejected.

4.5 DINA adaptation to IPv6

4.5.1 IPv6 Overview

Today the Internet is predominantly based on IPv4. As a result, most of end systems and network devices are able to exchange packets all together in a global network. When IPv4 was developed about 20 years ago, the designers had the forethought to give it a 32-bit address, which is sufficient to provide about 3.8 billion unique IP addresses.

Currently, great amount of this address space has been allocated. For the last several years the both short and long term solutions to this addressing problem and also the problems of the ever expanding routing tables in the Internet backbone routers has been explored. The long-term solution was the IP version 6 (IPv6) - a new version of the IP protocol.




The most obvious improvement in IPv6 is that addresses are 128 bit long, and therefore, offers a much larger address space. In addition to the needed larger address space, the IPv6 also provides new features that are needed for the evolving Internet such as:

IP Multicast support is an integral part of IPv6

IP level security support (both authentication and encryption)

Improved support for auto configuration of IPv6 addresses

Support for mobile nodes at the IP level i.e. all IPv6 nodes are able to move through the network without loosing connectivity

Efficient handling of packets with differing Quality of Service requirements through the use of a Flow label in the IPv6 packet header [46]

However, there is no a single global IPv6 network on the same scale than IPv4 network and it will take some time to get it. Therefore, new applications should be designed to work in all environments: single IPv4, single IPv6 or mixed communication when group collaborative applications are considered.

IPv6 and IPv4 are two completely separate protocols. IPv6 is not backward compatible with IPv4, and IPv4 hosts and routers will not be able to deal directly with IPv6 traffic (and vice versa). Therefore for a long period of time, there will be a network in which two protocols will be operating side by side. During the transition period, the IPv4 and IPv6 nodes are going to need to communicate with each other. Dual IP stacks have been proposed to solve this problem. They provide IPv4 and IPv6 stack implementations, allowing the sending and receiving of IPv4 and IPv6 packets. Most dual-stack implementations work following two operation modes:

1. IPv4 packets going to IPv4 applications on a dual-stack node use IPv4 stack. IPv6 packets going to IPv6 applications that are running on a dual- stack node use IPv6 stack. In summary: IPv4 applications run as if they were on an IPv4-only node while IPv6 applications run as if they were on an IPv6-only node.

2. IPv4 packets going to IPv6 applications on a dual-stack node, reach their destination because their addresses are mapped to IPv6 ones (using IPv4-mapped IPv6 addresses) inside dual-stack node, IPv4-mapped IPv6 addresses are IPv6 addresses built from IPv4 ones using the following format: from x.y.z.w IPv4 address the ::FFFF.x.y.z.w IPv4-mapped IPv6 address is built [47]

Figure 28 presents the interoperability of the different host running either IPv4, IPv6 of dual stack.

4.5.2 Porting Application to Understand IPv6

When porting IPv4 application to understand the IPv6, the changes in at least socket address structures, socket functions, address conversion functions and in the name resolving are needed.




4.5.2.1 Socket Address Structures

Functions provided by socket API use socket address structures to determine the communication service access point. Since different protocols can handle socket functions, a generic socket address structure, sockaddr, is used as argument of these functions for any of the supported communication protocol families.

Although socket functions handle generic socket address structure, developers must fill the adequate socket address structure according to the communication protocol they are using to establish the socket. Concretely, the IPv4 sockets use the structure sockaddr_in, and the IPv6 sockets use the structure sockaddr_in6.

Figure 28: IPv4 & IPv6 Client/Server interoperability

The sockaddr_in or sockaddr_in6 structures are utilised when using respectively IPv4 or IPv6. Existing applications are written assuming IPv4, using sockaddr_in structure. They can be easily ported changing this structure by sockaddr_in6. However, when writing portable code, it is preferable to eliminate protocol version dependencies from source code. There is a new data structure, sockaddr_storage large enough to store all supported protocol-specific address structures and adequately aligned to be cast to the a specific address structure. Hence, portable applications should use sockaddr_storage structure to store their addresses, IPv4 or IPv6 ones. This new structure hides the specific socket address structure that the application is using. All socket address structures all illustrated in Figure 29. [47]




Figure 29: Socket address structures for IPv4 and IPv6

4.5.2.2 Socket Functions

The socket API has not been changed since it handles generic address structures, independent from the protocol it is using. However, applications should change the arguments used to call the socket functions. First, applications should allocate enough memory to store the appropriate socket address structure, and before calling the socket functions, the specific socket address structure should be cast to the generic one, which is accepted by the socket functions as an argument.

Three specific modification types to be made with socket functions have been identified: creating a socket, socket address structure passed from application to kernel, and socket address structure passed from kernel to application. The difference between creating an IPv4 and an IPv6 socket is the value of the family argument in the socket call: IPv4 uses PF_INET and IPv6 uses PF_INET6 family. When socket address structures are passed from application to kernel and vice versa, the generic sockaddr_storage should be used instead of the protocol dependent sockaddr_in and sockaddr_in6. [47]

4.5.2.3 Address Conversion

The address conversion functions convert between binary and text address representation. Binary representation is the network byte ordered binary value, which is stored in the socket address structure and the text representation, named presentation, is an ASCII string.

The IPv4 address conversion from text to IPv4 binary representation is done with inet_aton and from IPv4 binary to text representation with inet_ntoa. The new address conversion functions, which work with both IPv4 and IPv6 addresses are inet_pton and inet_ntop. However, the use of these functions should be avoided. The new name resolution functions getnameinfo and getaddrinfo should be used instead. The inet_* functions work with IPv4 and IPv6, however they are protocol dependent, it means you need to specify which kind of resolution should be made, v4 or v6. Besides these inet_* functions do not work with scoped addresses, so getaddrinfo and getnameinfo are highly recommended. [47]




4.5.2.4 Name Resolution

From applications point of view the name resolution is a system-independent process. Applications call functions in a system library known as the resolver, typically gethostbyname and gethostbyaddr, which is linked into the application when the application is built. The resolver code is the burden of making the resolution dependent of the system configuration.

There are two new functions to make name and address conversions protocol independent, getaddrinfo and getnameinfo. Besides, the use of these new ones instead of gethostbyname and gethostbyaddr is recommended because the latter are not normally re-entrant and could provoke problems in threaded applications.

The getaddrinfo function returns a linked list of addrinfo structures, which contains information requested for a specific set of hostname, service and additional information stored in an addrinfo structure. [47]

The getnameinfo function is defined for address to node name translation. Its functionality is a reverse conversion of getaddrinfo. Getnameinfo function looks up an IP address and port number provided by the caller in the DNS and system-specific database, and returns text strings for both in buffers provided by the caller.

4.5.3 Context View for IPv6

IPv6 is the one of the key points in the CONTEXT project. From the technical point of view, the CONTEXT solution spans into three domains, namely: the Service Layer domain, the Active Application domain, and the IPv6 domain. In the Service Layer domain, the most important functions are the creation of context aware services and the management of these services. Further, the Active Application Layer offers the solution for support of context aware services and appropriate APIs for control the IPv6 domain.

In order to provide efficient delivery of context based services, the active service platform DINA was selected to be used in the project. To meet all the requirements of the project, some modification was however needed. One of these required features was the IPv6 compatibility.

In the following chapters, the changes made in DINA are described in more detailed. To facilitate the understanding of the DINA platform, also the main features of the packet handling are presented.

4.5.3.1 Changes in DINA for IPv6

The most important modification in the DINA was to change “struct sockaddr” to “struct sockaddr_storage”. The name-to-address and vice versa functions were also modified to be protocol independent. The recommended functions getaddrinfo( ) and getnameinfo( ) were used. The inet_ntop( ) is also allowed to use, but getnameinfo( ) was more suitable for name / address resolutions.

All modifications needed in the main DINA system are done. The next list includes modified files and the most important modification done.

sessionBroker.co Added one byte when sending between sessionBroker <-> sessionBrokerInterface.

This byte will tell the version of the followed IP-address.o Socket creation and binding modified to work with protocol independent functions.o sockaddr_in to sockaddr_storage




sessionBroker.ho sockaddr_in to sockaddr_storage

mgmtHandler.co sockaddr_in to sockaddr_storage

mgmtHandler.ho sockaddr_in to sockaddr_storage

sessionBrokerInterface.javao Added one byte when sending between sessionBroker <-> sessionBrokerInterface.

This byte will tell the version of the followed IP-address.

4.5.3.2 DINA Active Packet Formats

To give a better understanding of the DINA active packet handling, the DINA active packet structures are presented in this chapter.

DINA active packets are UDP packets whose payload consists of an ANEP header followed by the DINA header, DINA options and an active payload. Inside the Session Broker (sessionBroker.c and sessionBrokerInterface.java), the structure illustrated in Figure 30 is used when communicating from Session Broker to Session Broker Interface. The normal DINA active packet is added with two fields: IP address type (one byte) and IPv4/IPv6 address. Depending on the address type, the field contains either integer 4 or 6. The length of the IP address field is dynamically allocated depending on the address type.

Figure 30: DINA packet structure from Session Broker to Session Broker Interface

The following packet structure is used when an Active Application needs to distribute itself to the other active nodes. The Active Application uses the Session Broker Interface to accomplish the actual sending. The Session Broker Interface builds the structure illustrated in Figure 31 and sends it to the Session Broker. The Session Identification (Session ID) is the variable that the Session Broker has given to the Session Broker Interface identifying the active application when it is created. The type field is one of the following: DINA.TYPE_DATA = 0, DINA.TYPE_JAVA = 1 or DINA.TYPE_URL = 2. The version field informs the version of the following IP address. The IP address field and the last field before the active payload (Port) tells where to send the active packet.




Figure 31: DINA packet structure to communicate from Session Broker Interface to Session Broker

From the upper packet structure the Session Broker constructs the normal DINA Active Packet (which is illustrated in Figure 22) and sends it to the network.

Figure 32 illustrates the format of the packet that is sent between DINA active nodes. The IP and UDP headers are excluded for the sake of simplicity. The packet includes the ANEP/DINA headers, Active Application and its parameters. The data after the classfile is specific to the Active Application, in this case VpnApp.class. This field is used for transmitting configuration variables for the Active Application. In this example, the variables include:

Version of IP address type (IPv4 / IPv6) Length of the Report IP address Report IP address (could be the textual representation of IP-address or DNS-name).

This is used for reporting the status of Active Application (if needed) Length of the Destination IP address Destination IP address (could be the textual representation of IP-address or DNS-

name). From this address the Active Application can check if final destination is reached.

VPNApp parameters: <VpnApp>....</VpnApp>

Figure 32: Example of VPNApp Active Application packet format

4.6 IP API

4.6.1 Info Broker

The Information Broker Interface provides services to retrieve information such as the MIB of the active host.




4.6.1.1 API specification

The following methods have been specified for this API: public infoBrokerInterface(): constructor. public String snmpGet(String s): uses the SNMP GET Request to query for information on

network entity.o String s: An object id.

public String [] snmpGet(String [] s): uses the SNMP GET Request to query for information on network entity.

o String[] s: An array of object id. public String snmpGetNext(String s): uses the SNMP GET NEXT Request to query for

information on network entity.o String s: An object id.

public String [] snmpGetNext(String [] s): uses the SNMP GET NEXT Request to query for information on network entity.

o String[] s: An array of object id. public int getNumIf(): returns the number of all the interfaces (active and non active) of the

local active node. public String getRouterName(): returns the name of the router associated with local active

node. public String [] getIpAddrs(int ifnum): receives an interface number and returns a list of IP

addresses, which is associated with that interface.o int ifNum: The number of the interface.

public String [] getIpMask(int ifnum): receives an interface number and returns a list of IP masks, which is associated with that interface.

o int ifNum: The number of the interface. public int getIfNumber(String ipaddr): receives IP address and returns the index of the

interface that is associated with this address. If no association exists, the method returns 0.o String ipaddr: The IP address.

public String getNextHopAddr(String dest): receives a destination IP address and returns the IP address of the next hop. If destination is not in routing table, 0.0.0.0 is returned.

o String dest: The destination IP address. public int getNextHopIf(String dest): receives a destination IP address and returns the index of

the interface for the next hop. If destination is not in routing table, 0 is returned.o String dest: The destination IP address.

public float getLoad(int ifNum): receives an index number of an interface and returns the current load of this interface.

o int ifNum: The number of the interface. public int getStatus(int ifNum): receives an index number of an interface and returns the

current status. 1 = up, 2 = down, 3 = testing.o int ifNum: The number of the interface.

public String [] getActiveNeighborsAddrs(): returns a list of active neighboring addresses for all active interfaces (excluding localhost) or for a specific interface. If a neighbor has multiple addresses aliased to one interface, all addresses are returned.

public String [] getActiveNeighborsAddrs(int ifNum ): returns a list of active neighboring addresses for all active interfaces (excluding localhost) or for a specific interface. If a neighbor has multiple addresses aliased to one interface, all addresses are returned.

o int ifNum: The number of the interface. public boolean isLocalLoopback(String addr): returns true if the IP address is associated with

local loopback interface. Otherwise returns false.o String addr: The IP address.




public boolean isLocalLoopback(int ifnum): returns true if the interface is associated with local loopback interface. Otherwise returns false.

o int ifNum: The number of the interface. public String [] getDestAddrs(int ifnum): receives an interface number and returns a list of

destination addresses that use that interface.o int ifNum: The number of the interface.

The interface is as followspublic class infoBrokerInterface{public infoBrokerInterface();public String snmpGet(String s);public String [] snmpGet(String [] s);public String snmpGetNext(String s);public String [] snmpGetNext(String [] s);public int getNumIf();public String getRouterName();public String [] getIpAddrs(int ifnum);public String [] getIpMask(int ifnum);public int getIfNumber(String ipaddr);public String getNextHopAddr(String dest);public int getNextHopIf(String dest);public float getLoad(int ifNum);public int getStatus(int ifNum);public String [] getActiveNeighborsAddrs();public String [] getActiveNeighborsAddrs(int ifNum );public boolean isLocalLoopback(String addr);public boolean isLocalLoopback(int ifnum);public String [] getDestAddrs(int ifnum);

4.6.1.2 API Implementation details

The Information broker retrieves information from the active platform using SNMP client. In addition, it maintains a cache in order to reduce the amount of queries.

4.6.2 Control Broker

The Control Broker Interface enables active services to control and configure the routing tables and VPN connections. It is possible to install two kind of routes to the routing tables: temporary and permanent. The validity of the temporary route is done with different method includeng one extra parameter. VPN connections can be established also in same manners. If timeToLive is defined as 0, the tunnel is permanent.


The following methods have been specified for this API public ControlBrokerInterface(): contructor. public String setRoute(int cmd, inetAddr net, inetAddr netmask, inetAddr gw, String if):

enables to add and delete entries from the routing table of the active node. o int cmd: the identification of the command (ADD, DEL).




o inetAddr net: address of the destination network.o inetAddr netmask: network mask of the destination network.o inetAddr gw: gateway (next hop) to the destination network.o String if: interface to the destination network.

public String setRoute(int cmd, inetAddr net, inetAddr netmask, String if): enables to add and delete entries from the routing table of the active node.

o int cmd: the identification of the command (ADD, DEL).o inetAddr net: address of the destination network.o inetAddr netmask: network mask of the destination network.o String if: interface to the destination network.

public String setRoute(int cmd, inetAddr net, inetAddr netmask, inetAddr gw): enables to add and delete entries from the routing table of the active node.

o int cmd: the identification of the command (ADD, DEL).o inetAddr net: address of the destination network.o inetAddr netmask: network mask of the destination network.o inetAddr gw: gateway (next hop) to the destination network.

public String addTempRoute(int timeTolive, inetAddr net, inetAddr netmask, inetAddr gw, String if): add an entry to the routing table for a specific period of time. After that the entry is removed.

o int timeTolive: the validity period of the route.o inetAddr net: address of the destination network.o inetAddr netmask: network mask of the destination network.o inetAddr gw: gateway (next hop) to the destination network.o String if: interface to the destination network.

public String addTempRoute(int timeTolive, inetAddr net, inetAddr netmask, String if): add an entry to the routing table for a specific period of time. After that the entry is removed.

o int timeTolive: the validity period of the route.o inetAddr net: address of the destination network.o inetAddr netmask: network mask of the destination network.o String if: interface to the destination network.

public String addTempRoute(int timeTolive, inetAddr net, inetAddr netmask, inetAddr gw): add an entry to the routing table for a specific period of time. After that the entry is removed.

o int timeTolive: the validity period of the route.o inetAddr net: address of the destination network.o inetAddr netmask: network mask of the destination network.o inetAddr gw: gateway (next hop) to the destination network.

public String getRoutingTable(): method returns the current routing table of the router. public String setVPN(int timeToLive, int tunnelType, int cmd, inetAddr destIP, inetAddr

destNet, inetAddr netmask): method enables to start and stop VPN tunnels and to show certain or all VPN connections of the active node.

o int timeToLive: the validity period of the VPN tunnel.o int tunnelType: type of VPN tunnel (IPIP, GRE, IPSEC).o int cmd: the identification of the command (START, STOP, SHOW).o inetAddr destIP: end point IP of the VPN tunnel.. o inetAddr destNet: address of the destination network.o inetAddr netmask: network mask of the destination network.

public String setVPN(int tunnelType, int cmd, inetAddr destIP, inetAddr destNet, inetAddr netmask): method enables to start and stop VPN tunnels and to show certain or all VPN connections of the active node.

o int tunnelType: type of VPN tunnel (IPIP, GRE, IPSEC).




o int cmd: the identification of the command (START, STOP, SHOW).o inetAddr destIP: end point IP of the VPN tunnel.. o inetAddr destNet: address of the destination network.o inetAddr netmask: network mask of the destination network.

public String setVPN(int cmd, inetAddr destIP, inetAddr destNet, inetAddr netmask): method enables to start and stop VPN tunnels and to show certain or all VPN connections of the active node.

o int cmd: the identification of the command (START, STOP, SHOW).o inetAddr destIP: end point IP of the VPN tunnel.. o inetAddr destNet: address of the destination network.o inetAddr netmask: network mask of the destination network.

public void close( ): closes interface’s socket to the Broker. public String getLastError( ): returns last error from Broker.

The interface adopts the following structure:

public class controlBrokerInterface{public static int ADD_ROUTE = 0;public static int DEL_ROUTE = 1;

public static int VPN_IPIP = 0;public static int VPN_GRE = 1;public static int VPN_IPSEC = 2;

public static int START_VPN = 0;public static int STOP_VPN = 1;public static int SHOW_VPN = 2;

public controlBrokerInterface();public String setRoute(int cmd, inetAddr net, inetAddr netmask, inetAddr gw, String if);public String setRoute(int cmd, inetAddr net, inetAddr netmask, String if);public String setRoute(int cmd, inetAddr net, inetAddr netmask, inetAddr gw);public String addTempRoute(int timeTolive, inetAddr net, inetAddr netmask, inetAddr gw, String if);public String addTempRoute(int timeTolive, inetAddr net, inetAddr netmask, String if);public String addTempRoute(int timeTolive, inetAddr net, inetAddr netmask, inetAddr gw);public String getRoutingTable();public String setVPN(int timeToLive, int tunnelType, int cmd, inetAddr destIP, inetAddr destNet, inetAddr netmask);public String setVPN(int tunnelType, int cmd, inetAddr destIP, inetAddr destNet, inetAddr netmask);public String setVPN(int cmd, inetAddr destIP, inetAddr destNet, inetAddr netmask);public void close();public getLastError( );}




4.6.2.2 API implementation details for Linux routers

Currently VPN tunnel is implemented as IP-IP tunnel and IPSec tunnel. IPSec functionality is done by using manually distributed keys. The Control Broker is implemented to the Linux.

4.6.2.3 API implementation details for CISCO routers

The Control Broker is able to support CISCO routers by means of a wrapper designed on purpose. In our case, the class CISCOWrapper is the implementation for CISCO routers. This class is used to communicate to CISCO routers and send CISCO IOS commands to configure this type of network devices.

The CISCOWrapper class will provide a set of methods giving support to the capabilities specified for the ControlBroker API. The CISCOWrapper will communicate with the router opening a telnet connection in order to send all the needed CISCO OS commands in order to perform the desired configuration.

Table 5 presents a detailed description of the relevant methods provided by the CISCOWrapper class.

Table 5: Methods used to support CISCO routers through the Control Broker

Method Main commands

public CISCOWrapper(String router, int port, String user, String pass, String passConf, int debug, String prompt)

This is a constructor of the class. The Input parameters are:

router: ip address of the router. port: port to be used in telnet communication. user: user name for login. pass: password for login. passConf: password for login enable mode. debug: debug level of the communication.

o If 0 any message will be displayed.o If 1 progress messages will be displayed.o If 2 every string send or received will be

displayed.o prompt: name of the router in the prompt.

public CISCOWrapper (String fileName) throws CISCOWrapperException

This is a constructor of the class. The Input parameters are:

fileName: the path including name of the file containing the configuration parameters.

The format of the file should be the following:

ROUTER_IP=ip address of the router

PORT=port to be used in telnet communication

USER=user name for login

LOGIN_PASSWD=password for login

ENABLE_PASSWD=password for login enable




mode

PROMPT=name of the router in the prompt

DEBUG=debug level of the communication.

If 0 any message will be displayed. If 1 progress messages will be displayed. If 2 every string send or received will be

displayed.

The ‘ROUTER_IP’ and ‘PROMPT’ parameter is compulsory in config file. The other parameter are optional. If PORT or DEBUG isn’t present, a default value will be used (23 and 0). If USER or LOGIN_PASSWD or ENABLE_PASSWD are not present, it will be assumed that they are not needed in order to login or login enable mode.

public boolean setRoute(int cmd, String net, String netmask, String nextHop, String intf) throws CISCOWrapperException

This method is used to create or remove one ip route. The input parameters are:

cmd: numeric value indicating the operation to perform. Two static parameters can be used to this purpose. ‘ADD_ROUTE’ and ‘DEL_ROUTE’ static parameters.

net: ip address of target network. netmask: network mask of to apply. nextHop: next hop in the path. intf: id of the interface that will be used to forward

the packets.

This method throws the CISCOWrapperException when something goes wrong during the configuration process.

If the cmd parameter is ADD_ROUTE, then the commands to be sent are:

“config terminal” “ip route “+net+” “+netmask+” “+intf+” “+nextHop “exit”

If the cmd parameter is DEL_ROUTE, then the command to be sent is the string:

“config terminal” “no ip route “+net+” “+netmask+” “+intf+”

“+nextHop “exit”

public boolean setVPN(int cmd, String destIP, String destNet, String

This method is used to configure or remove a tunnel to a remote network. GRE tunneling protocol is used. The




netmask, int tunnelID) throws CISCOWrapperException

input parameters are:

cmd: numeric value indicating the operation to perform. Two static parameters can be used to this purpose. ‘START_VPN’ and ‘STOP_VPN’ static parameters.

destIP: destination IP address of the tunnel. destNet: destination network to be reached through the

tunnel. netmask: network mask to be applied to destination

network. tunnelID: numeric identificator of the tunnel.

This method throws the CISCOWrapperException when something goes wrong during the configuration process.

If the cmd parameter is START_VPN, then the commands to be sent are:

//creating a GRE tunnel

o “configure terminal”o “interface Tunnel “+tunnelIDo “tunnel mode gre ip”o “tunnel destination “+destIP

//creating a route to destNet

o “exit” o “ip route “+destNet+“ “+netmask+“

Tunnel“+tunnelIDo “exit”

If the cmd parameter is STOP_VPN, then the commands to be sent are:

//remove route

o “configure terminal”o “no ip route “+destNet+” “+netmask+”

Tunnel”+tunnelID

//remove the tunnel

o “no interface Tunnel “+tunnelIDo “exit”




4.6.3 Network Broker

The Network Broker Interface provides active services interface to communicate services such as TCP connections, UDP transactions and connection with other active services.


The following methods have been specified for this API public networkBrokerInterface( ): constructor. public int socket(byte type): receives socket type and returns a socket descriptor.

o byte type: socket type (’SOCKET_UDP’ or ‘SOCKET_TCP’). public int setSocketTimeout(int sd, int timeout):

o int sd: a socket descriptor.o int timeout: a maximum period of time when socket operations waits before returning.

public int connect(int sd, InetAddress dest, short port): associates a socket with a remote host.o int sd: a socket descriptor.o InetAddress dest: an IP address of the remote host.o short port: a port of the remote host.

public int bind(int sd, short port): associates a socket with a local port.o int sd: a socket descriptor.o short port: a local port.

public int accept(int sd): is a blocking method that returns when a TCP client connects to the server. It returns a new socket descriptor that is used to send and receive messages.

o int sd: a socket descriptor. public int send(int sd, byte[] buf, int length): is used to transmit messages to another socket.

o int sd: a socket descriptor.o byte[] buf: a message.o int len: a length of the message.

public int sendTo(int sd, byte[] buf, int length, InetAddress addr, short port): is used to transmit messages to another socket.

o int sd: a socket descriptor.o byte[] buf: a message.o int len: a length of the message.o InetAddress addr: an IP address of the destination.o short port: a port of a destination.

public int receive(int sd, byte[] buf, int len): is used to receive messages from connected socket (the same sender all the time).

o int sd: a socket descriptor.o byte[] buf: a message.o int len: a length of the message.

public int receivefrom(int sd, byte[] buf, int len, InetAddress addr, short port): is used to receive messages from another socket.

o int sd: a socket descriptor.o byte[] buf: a message.o int len: a length of the message.o InetAddress addr: a source address.o short port: a source port.

public int sendUDPpacket(byte[] buf, int length, InetAddress dest, short port): sends UDP message.

o byte[] buf: a message.o int length: a length of the message.




o InetAddress dest: a destination IP address.o short port: a destination port.

public int close (int sd): closes the interface’s socket to the Broker.o int sd: a socket descriptor.

public String getLastError( ): return last error received from the Broker.

The interface adopts the following structure:public class networkBrokerInterface{public static final byte SOCKET_UDP = 17;public static final byte SOCKET_TCP = 6;public networkBrokerInterface();public int socket(byte type);public int setSocketTimeout(int sd, int timeout);public int connect(int sd, InetAddress dest, short port);public int bind(int sd, short port);public int accept(int sd);public int send(int sd, byte[] buf, int length);public int sendto(int sd, byte[] buf, int length, InetAddress addr, short port);public int receive(int sd, byte[] buf, int len);public int receivefrom(int sd, byte[] buf, int len, InetAddress addr, short port);public int sendUDPpacket(byte[] buf, int length, InetAddress dest, short port);public int close (int sd);public String getLastError ();}

4.6.3.2 API implementation details

The implementation of the Network Broker is for Linux. In the API there exist socket functions that can be used only with particular protocol (UDP). If the used protocol is not supported, the user is informed.

4.6.4 SIP broker

The SIP Broker interfaces between the Active Application layer and the SIP software that is used to implement the Crisis Helper scenario. The broker provides to the Active Services the capability to control and manage the SIP entities such as proxy servers, and user agents. The SIP Broker provides the SLOs the capability to obtain information from the SIP softswitch and to control aspects of call control during a crisis situation.

It inserts a hook into SIP softswitch in order to delegate call admision to the SLOs. It also enables the provision of information on the SIP sessions that are taking place in the system.

The SIP broker has three primary functionalities. The first is to provide information on the SIP softswitch and the SIP users. The SIP softswitch is the software that controls call admission, control and signalling using the Session Initiation Protocol (SIP). The second function is to terminate calls and the third is to delegate call admission to the SLOs. To satisfy the first functionality, it contains the methods; userStatus, getUserIP, maxSessions, totalSessions, getProxyServers, sessionStateInfo. These are all informational methods as they




obtain information on the state of the system or the SIP user. Hence, the SIP broker provides an interface to provide information to the SLOs.

The second functionality is the ability to terminate sessions (calls). This is done either on a call by call basis using the method terminateSession when passed the sessionID of the call and the caller and callee SIP address. This method provides to the SLO, the ability to terminate specific calls during a crisis situation. All the calls that originate from a specific domain (and thus handled by a specific SIP proxy server) can be terminated using the terminateAllSessions method. It takes the SIPProxyID as a parameter and provides to the SLOs the ability to terminate all sessions in a domain during a crisis situation. This can be useful if the network is overwhelmed by traffic from neighbouring domains during a crisis. It might be useful to terminate all calls in that domain to allow the domain(s) that have the crisis more network resources.

The third functionality is the primary function of the SIP broker; the ability to delegate to the SLOs the session admission capabilities during a crisis situation. During a crisis situation, the session admission capabilities are delegated to a SLO called the CH_Main through a SIPCallDivertor object. This object contains the logic to accept and reject calls on a call by call basis. For example, calls to and from the emergency services are allowed but not to and from ordinary users. The CH_Main instantiates a SIPCallDiverter and pass it to the broker by invoking the setCallAcceptanceDiverter method. The SIP broker accepts this object replacing the previous one if it exits. When the CH_Main is ready for call admission control, it will invoke the applyDiverter(true) method of the SIP broker. This forces the SIP softswitch to delegate call admission to the SIPCallDiverter object. When the crisis is over, the SIP broker will then remove the admission redirection when the CH_Main invokes the applyDiverter(false) method and the softswitch retains call admission control.

The design allows for better context information utilisation by SLO, not brokers as the main goal of the project is to provide context-aware SLOs


The following methods have been specified for this API: public int userStatus(SIPUrl SIPUserAddr): returns the status of a SIP user, whether he is

disconnected, in an active session or in an inactive session public InetAddress getUserIP(SIPUrl SIPUserAddr): returns the IP address of the host that the

SIP user is logged into during the SIP session given his SIP address. public int maxSessions(): returns the maximum number of SIP sessions, which is allowed by

the SIP softswitch. public int totalSessions(): returns the number of current SIP sessions currently handled by the

SIP softswitch. This is a rough measure of the traffic through the system. public String[] getProxyServers(): returns an array of proxy servers found in the domains that

the SIP softswitch serves. public String[] sessionStateInfo(String sessionID) and public Hashtable sessionStateInfo(String

SIPProxyID): returns information regarding ongoing SIP sessions. The information contains the state of the SIP session, the caller and the callee, session id, media description etc. The first method returns the status of a particular session, given the session ID while the other method returns a hash table of all the session IDs and the status of their sessions within a particular domain.

public boolean terminateSession(String sessionID, SIPUrl CallerAddr, SIPUrl CalleeAddr): terminates a session according to the sessionID, the initiator (caller) and the recipient (callee).




public boolean terminateAllSessions(String SIPProxyID): terminates all the ongoing sessions in that are in the domain of a certain SIP proxy server.

public void setCallAcceptanceDiverter (String SIPProxyID SIPCallDiverter diverter): this method sets the particular SIPCallDiverter. The SLO instantiates this SIPCallDiverter object and passes it to the SIP broker.

public void applyDiverter (String SIPProxyID boolean apply): this method is invoked by the SLO when a crisis condition occurs. Then all call admission tasks go through the diverter.

The interface adopts the following structure:public class SipBrokerInterface {//User statuspublic static int USER_ACTIVE = 0;public static int USER_INACTIVE = 1;public static int USER_DISCONNECTED = 2;

public SipBrokerInterface();public int userStatus(SIPUrl sipUserAddr);public InetAddress getUserIP(SIPUrl SIPUserAddr);public int maxSessions();public int totalSessions();

public String[] getProxyServers();public String[] sessionStateInfo(String sessionID); public Hashtable sessionStateInfo(String SIPProxyID);public boolean terminateSession(String sessionID, SIPUrl CallerAddr, SIPUrl CalleeAddr);public boolean terminateAllSessions(String SIPProxyID);public void setCallAcceptanceDiverter (String SIPProxyID SIPCallDiverter diverter);public void applyDiverter (String SIPProxyID boolean apply); }


The SIP broker was implemented on top of the Siptrex SIP implementation. The Siptrex SIP implementation is a complete Java implementation of a SIP stack, SIP user agents and servers. Only voice sessions are supported by the Siptrex SIP implementation and hence no video traffic, web traffic or SMS sessions can be controlled using the SIP broker.

The SIPCallDivertor is a Java interface, not a class, with the different SLOs containing a class that extends this interface. As the funcionality of diverting calls is useful to many SLOs, the SIPCallDiverter is an interface. Its API is as follows:

public SIPCallDivertor { public SipBrokerCallDivertor (); public virtual boolean acceptCall (SipUrl caller, SipUrl callee);};




4.7 Filtering and QoS

4.7.1 Filter broker

The Filter Broker Interface provides ways to control a router to filter traffic. According to what is explained in the subsection devoted to implementation details, we have provided two distinct APIs, one for LINUX routers and another one for CISCO routers

4.7.1.1 API specification for LINUX routers

The following methods have been specified for this API: public String getDataFlow() public String addRawIPTableRule(String rule, int durationTime) public String addRawIPTableRule(String rule) public String getAllRules() public String addIPTableGetFlowRule(String chain, String filter, boolean withHeaderData, int

durationTime) public String addIPTableGetFlowRule(String chain, String filter, boolean withHeaderData) public String addIPTableGetPartialFlowRule(String chain, String filter, boolean

withHeaderData, int partSize, int durationTime) public String addIPTableGetPartialFlowRule(String chain, String filter, boolean

withHeaderData, int partSize) public String addIPTableGetProbabilisticFlowRule(String chain, String filter, boolean

withHeaderData, int rate, int durationTime) public String addIPTableGetProbabilisticPartialFlowRule(String chain, String filter, boolean

withHeaderData, int partSize, int rate, int durationTime) public String addIPTableAcceptRule(String chain, String filter, int durationTime) public String addIPTableAcceptRule(String chain, String filter) public void removeIPTableRule(String handle) public void refreshIPTableRule(String handle) public void resetRuleCounter() public int getStatistics(String handle) public String getRule(String handle) public String getTypeofRouter()

4.7.1.2 API specification for CISCO routers

String getTypeofRouter(): This method returns either ‘LINUX’ or ‘CISCO’ public String addRawIPTableRule(String Rule, String duration): This method adds a rule to the

route table of the CISCO Router. The format of the rule string is the following:

‘permition ipsource masksource ipdestination maskdestination portnumber interface nextHopIP AccessListID routeName’

o permition: This can be ‘permit’ or ‘deny’o ipsource: IP Address where the packets come from: ‘xxx.xxx.xxx.xxx’ or ‘any’o masksource: This can be a mask ‘xxx.xxx.xxx.xxx’ or ‘null’o ipdest: IP Address where the packets are going to: ‘xxx.xxx.xxx.xxx’ or ‘any’o maskdestination: This can be a mask ‘xxx.xxx.xxx.xxx’ or ‘null’.o portnumber: Port identification where the packets are being directed <0 – 65535>o interface: Interface of the router where we want to apply the filter rule.o nextHopIP: Address where we want to send the packet that is going to be filtered.




o AccessListID: Using ipsource and ipdest data that is provided above, the router is going to create a list that must be named. This ID is an string to naming the Access List e.g. ‘john’.

o routeName: The filter rule is going to be configured in the router as a route rule that also needs a name e.g. ‘DINA2’.

The duration parameter is not used. However, it must be provided in order to follow the interfaces proposed above in this document.

public String removeIPTableRule(String RuleId): This method is used to remove an existing Filter Rule from the CISCO Router. The data that we must provide is the following:

‘accessListID routeName’ where:

o AccessListID: Using ipsource and ipdest data that is provided above, the router is going to create a list that must be named. This ID is a string to naming the Access List e.g. ‘john’.

o routeName: The filter rule is going to be configured in the router as a route rule that also needs a name e.g. ‘DINA2’.

The interface is as follows hereafter. Nevertheless, note that in case of CISCO routers, only the boldfaced methods are supported

public class filterBrokerInterface {public filterBrokerInterface();string getTypeofRouter();handle addIPTableGetFlowRule(chain, filter, duration);handle addIPTableGetPartialFlowRule(chain,filter, withHeaderData, partSize, duration);handle addIPTableGetProbabilisticFlowRule(chain, filter, rate, duration);handle addIPTableAcceptRule(chain, filter, duration);handle addRawIPTableRule(rule, duration);data getDataFlow(timeout);int getStatistics(handle);void resetRuleCounter(handle);void refreshIPTableRule(handle);void removeIPTableRule(handle);}

4.7.1.3 API Implementation details

The Filter broker was first implemented for LINUX routers. Later on this broker was tried to be adapted also for CISCO routers. Nevertheless, the adaptation process became difficult because the former API was oriented to accept LINUX commands and also because most of the functionality in LINUX routers was not available for CISCO. Therefore the adopted solution was to work with two distinct and independent APIs. Only one method would be shared by both API. The purpose of this method would be to retrieve the type of router (LINUX or CISCO). Therefore, to contact the filter broker the application should know the type of router and then use the appropriate API.




4.7.2 QoS broker

The QoS Broker Interface provides active services with the capability to configure and manage the routers’ network interfaces in order to support QoS functionality. The QoS configurations refer to the Differentiated Services (DiffServ) architecture.

The basic principle of DiffServ is the simplicity in the core network, while the complex functions are pushed to the edges. Generally, a DiffServ domain comprises of the core and the edge routers (Figure 33). The core routers’ functionality is limited to the classification of the incoming packets accordingly to the TOS (Type Of Service) field of the IP header. The TOS value is read and the packets are forwarded with different priority, which depends on the value of this field (Per Hop Behaviour: PHB). On the other hand, the edge routers are configured to support more complicated functionality. Rules are defined in the edges for the incoming packets (for example: for the incoming packets with source IP address a and destination IP address b, the rate should not exceed X Kbps and their TOS field should be set to the x value). The installed meters measure the incoming traffic, the installed policers police (drop/shape) the traffic (if necessary) and finally the installed markers mark (set the packets’ TOS field) the traffic according to the defined rules.

source destination

EDGE-1 CORE CORE EDGE-2

source destination

EDGE-1 CORE CORE EDGE-2

Figure 33: DiffServ domain

The QoSBrokerInterface API provides to the service developer a set of methods that can be classified into four main categories:

Router identification: The methods of this category can be used in order to identify the type of the current router (core, edge-1, edge-2 or out of source-destination path).

Interfaces identification: The methods of this category can be used to discover the network interface that should be configured.

Routing: These methods can be used in order to guide the active packets towards the source or the destination host.

Configuration: These methods can be used to install DiffServ queuing disciplines/classes/filters in order to set-up classifiers, policers, markers etc.


All the methods herein described can be applied to a Linux or a CISCO router, if not specified otherwise.

public QoSBrokerInterface(InetAddress src, InetAddress dst, int port): establishes a TCP connection with the QoSBroker (constructor). Moreover, in case of a CISCO router, a telnet connection is established with the managed CISCO router.

o InetAddress src: the source’s IP addresso InetAddress dst: the destination’s IP addresso int port: the TCP port for the connection between the QoSBroker and the application.




public QoSBrokerInterface(int port): establishes a TCP connection with the QoSBroker (constructor). Moreover, in case of a CISCO router, a telnet connection is established with the managed CISCO router.

o int port: the TCP port for the connection between the QoSBroker and the application. public void setSource(InetAddress src): sets the source’s IP address.

o InetAddress src: the source’s IP address. public void setDestination(InetAddress dst): sets the destination’s IP address.

o InetAddress dst: the destination’s IP address. public boolean resetInterfaceDiffServ(String iface): resets all the installed queuing disciplines

(qdisc) to the interface iface for a Linux router. In case of a CISCO router, all DiffServ configurations that are bound to the interface iface are removed.

o String iface: the interface’s name. public boolean resetAllDiffServ(): resets all the installed queuing disciplines (qdisc) to all

interfaces of the controlled router in case of a Linux router. In case of a CISCO router, all DiffServ configurations are removed.

public boolean initINGRESS(String ingress): initialises an interface as ingress.o String ingress: the ingress interface’s name.

public boolean resetINGRESS(String ingress): resets an ingress interface.o String ingress: the ingress interface’s name.

public boolean installDSMARK(String egress): initialises an interface as egress.o String egress: the egress interface’s name.

public boolean resetEgress(String egress): resets the egress interface egress. String egress: the egress interface’s name. public boolean isLinuxController(): returns true if the active engine controls a Linux router. public boolean isEdge1(): returns true if the active node is the source’s gateway. public boolean isEdge2(): returns true if the active node is the destination’s gateway. public boolean isCore(): returns true if the active node is a core router for the source-

destination path. public String getIngress(): returns the ingress interface of an active node (taking into account a

source destination path). public String getEgress(): returns the egress interface of an active node (taking into account the

source destination path). public String getNextHopFor(InetAddress target): returns the next hop for the target address.

o InetAddress target: the target’s IP address. public boolean installCBQ(String egress, double bandwidth): installs a CBQ class to an egress

interface for a Linux based router. Normally, it is called after an “installDSMARK” method in order to set up the DiffServ classes. In case of a CISCO router, this step is not necessary and should be left out (The method returns true in case of a CISCO router).

o String egress: the egress interface in which the CBQ scheduler will be installed.o double bandwidth: the allocated bandwidth for the CBQ class (in Mbps).

public boolean setAFxClass(int AF_x, String egress, double bandwidth, double rate, int prio, boolean bounded, int DPs, int default_DP): installs an Assured Forwarding class. Returns true if the class has been added successfully. In case of Linux based router, this class is a GRED qdisc and it is a child of the installed CBQ class.

o int AF_x: the AF Class id (the GRED queue’s id)o String egress: the interface that will be configured.o double bandwidth: the total available bandwidth (Mbps) of the parent CBQ class.o double rate: the assigned rate for this AF class(in Mbps)o int prio: the priority of the AF_x classs (priority i-1 is higher than priority i).o boolean bounded: true if the class is bounded.o int DPs: the number of virtual queues of this GRED queue.




o int default_DP: the default virtual queue of this GRED queue. public boolean setAFxyClass(int AF_x, int AF_y, byte DSCP_byte, String egress, int limit, int

min_limit, int max_limit, int burst, double bandwidth, double probability, int prio): installs a virtual GRED qdisc as a child of the installed Assured Forwarding class x. Returns true if the qdisc has been added successfully.

o int AF_x: the parent AF class of this subclass (identifier of the real GRED queue)o int AF_y: the identifier of this subclass (virtual queue id).o byte DSCP_byte: the DSCP value of this class’ packets.o String egress: the interface that this class is installed into.o int limit: the hard maximum virtual GRED queue length (in KBytes) (e.g. 60 means

60*1024 bytes for the maximum RED queue length).o int min_limit: the minimum average queue length for the virtual GRED queue (in

KBytes).o Int max_limit: the maximum average queue length for the virtual GRED queue (in

KBytes).o int burst: the burst size (in packets).o double bandwidth: the available bandwidth in Mbits as bytes (e.g.

10Mbits=(10*1024*1024)/8).o double probability: the drop probability for the packets of this virtual queue.o int prio: the priority of this virtual queue.

public boolean setBEClass(String egress, double bandwidth, double be_rate, int limit, int min_limit, int max_limit, int be_burst, double probability): installs the Best Effort class as a child of the installed CBQ class with the lowest priority. Returns true if the class has been added successfully.

o String egress: the interface that this class is installed into.o double bandwidth: the available bandwidth of RED queue in Mbits as bytes/sec(e.g.

10Mbits=(10*1024*1024)/8).o double be_rate: the BE rate in Mbits as bytes/sec (e.g. 10Mbits=(10*1024*1024)/8).o int limit: the hard maximum RED queue length (in KBytes) (e.g. 60 means 60*1024

bytes for the maximum RED queue length).o int min_limit: the minimum average queue length for the RED queue (in KBytes).o int max_limit: the maximum average queue length for the RED queue (in KBytes).o int be_burst: the burst size (in packets).o double probability: the drop probability for the packets of this class.

public boolean setEFClass(String egress, double ef_rate, int ef_burst, double ef_mtu, int ef_limit): installs the Expedited Forwarding class. Returns true if the class has been added successfully.

o String egress: the interface that this class is installed into.o double ef_rate: the token bucket rate (in Mbit/sec).o int ef_burst: the maximum burst size (in Kbytes).o double ef_mtu: the Maximum Transit Unit in bytes.o int ef_limit: the token bucket limit in bytes.

public boolean resetAccessLists(): resets all the previously defined access lists. public int createAccessList(int accesslist_id, String protocol, String source_ip, String

destination_ip, int source_port, int destination_port): creates an access list. The accesslist_id value is returned if the access list has been successfully created, else the zero value is returned. Note that the protocol field matters only for CISCO routers: the default value (ip) is used in case of Linux based routers.

o int accesslist_id: the identification number for the access list.o String protocol: the protocol type (udp, tcp, or ip).




o String source_ip: the IP address of the source. (The null value corresponds to any IP address).

o String destination_ip: the IP address of the destination. (The null value corresponds to any IP address).

o int source_port: the source port (TCP or UDP). (The zero value corresponds to any port).

o int destination_port: the destination port (TCP or UDP). (The zero value corresponds to any port).

public void removeAccessList(int access_list_id): removes an access list with id: access_list_id , which was previously created within the current active session.

o int accesslist_id: the identification number of the access list that will be removed. public int addMarker(int index, int accesslist_id, byte TOS, String egress, String ingress, int

prio ): adds a class marker. The index is returned if the marker has been added successfully, else the zero value is returned.

o int index: the index of the marker.o int accesslist_id: the identification number for the access list.o byte TOS: the value of TOS byte that the packets will be marked with.o String egress: the interface that will forward the marked packets.o String ingress: the interface that receives the incoming (non-marked) packets.o int prio: the priority of the installed marker (prio>1).

public boolean removeMarker(int index): removes a class marker that was added within the current active session. Returns true if the marker has been successfully removed, else the “false” value is returned.

o int index: the index of the class marker that will be removed. public boolean removeMarker(int index, int accesslist_id, byte TOS, String egress, String

ingress, String prio): removes a class marker. Returns true if the marker has been successfully removed, else the “false” value is returned.

o int index: the index of the marker that will be removed.o int accesslist_id: the identification number for the access list.o byte TOS: the value of the Type of Service byte.o String egress: the egress interface that forwards the marked packets.o String ingress: the ingress interface that receives the incoming (non-marked) packets.o String prio: the marker’s priority.

public int addMarkerPolicer(int index, String egress, String protocol, String src, String dst, int sport, int dport, int rate, int burst, int tos, int prio, String policy): adds a marker-policer (ONLY FOR LINUX). Returns the index value if the marker-policer has been successfully added, else the zero value is returned.

o int index: the index of the policer.o String egress: the interface that the policer will be installed into.o String protocol: the protocol field (in IPv4 header) of the packets (ip,udp,tcp).o String src: the source IP address of the incoming packets. (The null value corresponds

to any IP address).o String dst: the destination IP address of the incoming packets. (The null value

corresponds to any IP address).o int sport: the source port number of the packets. (The zero value corresponds to any

port).o int dport: the destination port number of the packets. (The zero value corresponds to

any port).o int rate: the rate bound (in Kbps).o int burst: the burst bound (in Kbytes).




o int tos: the value of the TOS byte that they packets will be marked with. o int prio: the priority of the marker-policer. The marker-policers with higher priority

(lower prio value) are applied before the marker-policers with lower priority (higher prio value).

o String policy: “continue” or “drop” packets. public int addMarkerPolicerCISCO(int index, int accesslist_id, int rate, int min_burst, int

max_burst, int conform_dscp, int exceed_dscp, int violate_dscp, String egress): adds a marker-policer (ONLY FOR CISCO). Returns the index value if the marker-policer has been added successfully, else the zero value is returned.

o int index: the index of the policer.o int accesslist_id: the access list id of the packets that the marker-policer is applied into.o int rate: the rate of the incoming packets that belong to the access list accesslist_id (in

bps).o int min_burst: the minimum burst size (in bytes).o int max_burst: the maximum burst size (in bytes).o int conform_dscp: 1: transmit traffic, -1: drop traffic, else: the DSCP value for traffic

marking.o int exceed_dscp: 1: transmit traffic, -1: drop traffic, else: the DSCP value for traffic

marking.o int violate_dscp: 1: transmit traffic, -1: drop traffic, else: the DSCP value for traffic

marking.o String egress: the interface that the marker-policer is installed into.o public boolean removeMarkerPolicer(int index): removes a marker-policer that was

previously created within the current active session (ONLY FOR LINUX). o int index: the index of the marker-policer.

public boolean removeMarkerPolicerCISCO(int index): removes a marker-policer that was previously created within the current active session (ONLY FOR CISCO).

o int index: the index of the marker-policer. public boolean removeMarkerPolicer(int index, String egress, int prio): removes a marker-

policer.o int index: the index of the marker-policer.o String egress: the egress interface that the marker-policer is installed into.o int prio: the priority of the marker-policer.

public String monitorQdiscs(String iface): returns all the installed queuing disciplines to the interface iface.

o String iface: the interface that will be monitored. public String monitorClasses(String iface): returns all the installed classes to the interface

iface.o String iface: the interface that will be monitored.

public String monitorFilters(String iface): returns all the installed filters to the interface iface (ONLY FOR LINUX) .

o String iface: the interface that will be monitored. public void finish(): terminates the TCP session with the QoSBroker. In case of a CISCO

router, the established telnet connection is also terminated.

The QoSBrokerInterface adopts the following structure:public class QoSBrokerInterface{public QoSBrokerInterface(InetAddress src, InetAddress dst, int port);public QoSBrokerInterface(int port);




public void setSource(InetAddress src);public void setDestination(InetAddress dst);public boolean resetInterfaceDiffServ(String iface);public boolean resetAllDiffServ();public boolean initINGRESS(String ingress);public boolean resetINGRESS(String ingress);public boolean installDSMARK(String egress);public boolean resetEgress(String egress);public boolean isLinuxController();public boolean isEdge1();public boolean isEdge2();public boolean isCore();public String getIngress();public String getEgress();public String getNextHopFor(InetAddress target);public boolean installCBQ(String egress, double bandwidth);public boolean setAFxClass(int AF_x, String egress, double bandwidth, double rate, int prio, boolean bounded, int DPs, int default_DP);public boolean setAFxyClass(int AF_x, int AF_y, byte DSCP_byte, String egress, int limit, int min_limit, int max_limit, int burst, double bandwidth, double probability, int prio);public boolean setBEClass(String egress, double bandwidth, double be_rate, int limit, int min_limit, int max_limit, int be_burst, double probability);public boolean setEFClass(String egress, double ef_rate, int ef_burst, double ef_mtu, int ef_limit);public boolean resetAccessLists();public int createAccessList(int accesslist_id, String protocol, String source_ip, String destination_ip, int source_port, int destination_port);public void removeAccessList(int access_list_id);public int addMarker(int index, int accesslist_id, byte TOS, String egress, String ingress, int prio );public boolean removeMarker(int index);public boolean removeMarker(int index, int accesslist_id, byte TOS, String egress, String ingress, String prio);public int addMarkerPolicer(int index, String egress, String protocol, String src, String dst, int sport, int dport, int rate, int burst, int tos, int prio, String policy);public int addMarkerPolicerCISCO(int index, int accesslist_id, int rate, int min_burst, int max_burst, int conform_dscp, int exceed_dscp, int violate_dscp, String egress);public boolean removeMarkerPolicer(int index);public boolean removeMarkerPolicerCISCO(int index);public boolean removeMarkerPolicer(int index, String egress, int prio);public String monitorQdiscs(String iface);public String monitorClasses(String iface);public String monitorFilters(String iface);public void finish();}





The QoS Broker utilizes “tc” commands to setup DiffServ rules to the Linux based routers. The “tc” command tool is included in the iproute2 software package. Iproute2 package provides the users with numerous tools for networking configurations for Linux machines. Moreover, the QoS Broker utilizes the CISCO IOS commands of the “CISCO Release version 12.1” to configure the CISCO routers. Specifically, a telnet connection is established with the CISCO router utilizing the CISCOWrapper interface.

4.8 Context support

4.8.1 Context broker

The Context Broker implements the mechanism for enabling a CAS to access the necessary context information, which is offered by the various context sources. Thus, the Context Broker provides the methods that enable context producers to register and supply their context information and context consumers (CASs acting as active services) to retrieve all the necessary context information, in order to perform their tasks and achieve their objectives.

The services don’t need to be aware of where or how this information is stored or gathered respectively, so the Context Broker interface offers an abstraction layer that isolates the service, and also the service creator, from the complexity derived from the gathering, management and delivery of this kind of information. The values of the context requested through these methods can be retrieved either from the local active host (MIBs, DataBase, etc.), or from remote context information providers if necessary (in case that the information demanded can’t be found in the local active host). The requests that are addressed by the Context Broker could be either context queries or context events (pull or push mechanism, respectively). Moreover, there are two options that are offered to context information producers to provide their information: they could provide their context upon request or they could delegate the Context Broker to serve the submitted requests, which in this case stores the updated values.

The design and implementation of this mechanism are part of WP3. Therefore, the detailed presentation, as well as the offered APIs and the implementation analysis are included in deliverable D3.2.

4.9 Action brokerThe Action Broker is responsible for implementing a set of predefined actions. These actions are generic enough so that it is reasonable to implement them apart from each specific SLO. In this way the SLO will be maintained as light as possible, and only the very specific actions needed by each SLO will be implemented in its own code. The rest of needed actions will be accessible and implemented by the Action Broker. Therefore, different SLOs can use this broker to enforce different generic actions, instead of implementing them in its own code. The Action Broker will hide the complexity of all these actions. It would only require the action name and a list of initial parameters.




4.9.1 API specification

The following methods have been specified for this API public actionBrokerInterface( ): constructor. public String trigger_action(String actionName, String[] parameters): this method is used to

specify an action to be taken. It must be specified the action name and its parameters. The method returns the result, if any, of the action enforced. The string returned may also contain an error message pointing that either the action name or the parameters are wrong or they are not the expected ones, or the action specified is not supported or it is unknown.

o String actionName: contains the name of the action to be triggered.o String[] parameters: contains an array of strings, each of one containing one needed

parameter in order to enforce the specified action.

The interface adopts the following structure:public class actionBrokerInterface{

public actionBrokerInterface();public String trigger_action(String actionName, String[] parameters);

}

4.9.2 API implementation details

The implementation of the Action Broker is for Linux. The format of the returned String by the method ‘trigger_action’ is to be specified. The specific actions supported by the Action Broker will be only the necessary ones in order to implement the different scenarios. The way in which the Action Broker internally implements or invokes each action is to be decided.

4.10 Wireless supportThe wireless support facilities include the wireless LAN (WLAN) broker and the GPRS broker.

4.10.1 WLAN broker

The WLAN Broker provides active services capability to control and manage WLAN Access Points and the Wireless Network. We recall that a VLAN (Virtual LAN) can be regarded as a group of devices on different physical LAN segments which can communicate with each other as if they were all on the same physical LAN segment. In other words, a VLAN can be thought as a broadcast domain that exists within a defined set of devices. A VLAN consists of a number of end systems, either hosts or network equipment, connected by a single bridging domain.

Let us consider now the intervention of a WLAN to constitute a VLAN. The WLAN Access Points are Layer 2 devices. At this level, in order to provide VLAN, we have to encapsulate the packets following the 802.1Q extension of the 802.1D standard. The 802.1Q defines the architecture for Virtual LANs and services provided in there.




According to the aforementioned, we can say that in order to allow a WLAN be part of a VLAN we need to activate the 802.1Q tag awareness in the AP of this WLAN. As depicted in Figure 34, the activation consists of a binding between an existing VLAN and a particular Service Set. Service Sets are associated to VLANs in a one-to-one basis. Simultaneously, a Service Set, which is a logical coverage area, is bind to an Access List, which will contain the MAC Addresses of all the users that are allowed to connect to this Service Set. Moreover, a given WLAN AP can also have Service Sets which are not associated to any VLAN. Frames from the wired network with destination to clients belonging to different VLANs are transmitted by the AP to different Service Sets. Only clients associated to a particular SS can receive those packets that belong to a particular VLAN. Conversely, packets coming from clients accessing via the WLAN are 802.1Q tagged before they are forwarded onto the wired network.

QoS in a WLAN AP can be assigned in two ways. First, it can be assigned globally to the VLAN. This means that the flows of all users assigned to this VLAN will have the same QoS. On the other hand, we can also assign QoS to individual users regardless of the fact that they belong or not to any of the existing VLANs

In order to provide a service with a given quality it is necessary to keep a set of indexes within given thresholds. In other words, there are some parameters that must be configured and monitored in the network in order to assure the QoS. In packet networks these parameters are mainly delay, bandwidth, jitter and packet loss. In this stric sense, an AP of the 802.11a,b standard has no means to provide QoS . The AP can only establish different packet priorities based on one of the following three mechanisms: DSCP value (Differentiated Services Code Point), client identification or the priority value on the 802.1Q / 802.1p tag.

Figure 34: Association of VLANs, Service Sets and Access Lists in a WLAN access point

All packets tagged with the same priority will be treated in the same way, but better than packets tagged with a lower priority. However, this priority doesn’t assure the total amount of bandwidth that they are going to share or even how much bandwidth they will be able to use. The amount of bandwidth that a given class is sharing is not guaranteed because it depends on the distribution of traffic among the different traffic classes.





The following methods have been specified for this API public boolean isUserAssociated(String ClientIPAddr): returns true if the client identified by

the ClientIPAddr is associated to the WLAN AP. A client is associated to an AP when the first two layers (PHY and MAC) are currently active.

public String[] getAssociatedUserAddrs(): returns the MAC Addresses of all the clients that are associated to the WLAN Access Point.

public String getUserMAC (String ClientIPAddr): returns the MAC address of the client connected to the WLAN AP with the IP Address specified by ClientIPAddr.

public String getUserIP (String ClientMACAddr): returns the IP Address of the client connected to the WLAN AP with the MAC Address specified by ClientMACAddr. The MAC Address should be expressed in the following format: ffff.ffff.ffff and the letters should be lowercase.

public boolean createSS(String SSID, String AutType, String AccessListID, String MaxAssoc): creates a new Service Set on the WLAN Access Point. It returns ‘true’ if the action is executed and ‘false’ in any other case. In order to create a Service Set, the following parameters are needed:

o String SSID: Identification of the Service Set.o String AuthType: The type of authentication <<empty>,< Mac-Address>>. If it is

empty, there will be no authentication. empty means an empty String (“”). In case of mac-address, the clients are going to be authenticated with their MAC Addresses in the AP, when associating to it. The format of the MAC Address will be the same as in the previous methods.

o String AccessListID: The Id of the Access List that is going to use the Service Set. It is not needed if the AuthType is ‘empty’. empty has the same meaning than in the previous parameter. The Access List is a list of mac-addresses related to permission or denegation to associate it to the AP.

o String MaxAssoc: Maximum number of clients that can be associated to a Service Set at the same time.

public boolean removeSS(String SSID): removes an existing Service Set, which is identified by the SSID. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

public String getClientSSID(String ClientMACAddr): will return the SS to which a given user, who is identified by its MAC Address, is associated. The format of the MAC Address will be the same as in the previous methods.

public boolean establishVLAN (String VLANId, String SSID): establishes a VLAN for clients accessing through the WLAN Access Point. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case. The parameters needed are:

o String VLANId: The identification of the VLAN.o String SSID: Identification of the Service Set related to the VLAN, as far as every

VLAN has to be associated to a Service Set. public boolean removeVLAN (String VLANId, String SSID): removes an existent VLAN. The

parameters are the same as in the previous method. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

public boolean addAccessList (String AccessListID, String permition, String MACAddr): creates a new access list or adds a new client to an existing Access List. It returns ‘true’ if the action finishes correctly and ‘false’ in any other case. The parameters are:

o String AccessListID: Identification of the Access List. It must be a number between 700 and 799.

o String Permition: The kind of permission associated to the MAC Address. It can be permit or deny.




o String MACAddr: Client MAC Address that we want to add to the Access List. The format of the MAC Address will be the same as in the previous methods.

public String[] getAccessList (): gets all the Access Lists that are defined in the Access Point. public boolean removeAccessList (String AccessListID): remove the Access List identified by

AccessListID. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

public String snmpGet (String community, String host, String oid): makes a get of SNMP from the specific host and the provided oids. The parameters are:

o String community: Community of the SNMP. It can be public.o String host: IP Address of the AP from we want to retrieve information.o String [] oids: an array of strings containing all the oids that we want to consult.

public float getLoad(): This method returns the bytes per second of the radio interface of the Access Point from the AP to the clients (the radio downstream). This load is going to be measured in kbps.

public float getLoadPerConnectionfromAP (String ClientMACAddr): this method returns the bytes per second [kbps] of the traffic from the AP to the Client.

public float getLoadPerConnectionfromClient (String ClientMACAddr): this method returns the bytes per second [kbps] of the traffic from the Client to the AP.

public int getSignalQuality (String ClientMACAddr): gets the quality of the signal received from the client identified by ClientMACAddr. The format of the MAC Address will be the same as in the previous methods. This quality is measured from 0 to 100 in %.

public int getInterfaceStatus (int ifNum): gets the status of the interface determined by ifNum. It can be 1 if up or 0 if down. If ifNum is ‘0’ it refers to the FastEthernet interface, if it is ‘1’ it refers to the 802.11b interface and ‘2’ refers to the 802.11a interface.

public boolean setInterfaceStatus (int ifNum, boolean status): sets the status determined on the heading of the radio interface, that is also determined on the heading, following the instructions of the previous method. It returns ‘true’ if the action is executed and ‘false’ in any other case.

public boolean setChannel(String ChannelNumber, int ifNum): set the channel (frequency) that is going to be used by the AP. In the case of 802.11b ChannelNumber must be a number between 1 and 13. In the case of 802.11a ChannelNumber must be one of the following list: 36, 40, 44, 48, 52, 56, 60 or 64. The ‘ifNum’ follows the coding described on the previous method. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

public boolean isChannelActive(int ChannelNumber, int ifNum): checks if the channel specified in the heading is active. In other words, if it is the channel that it is in use at the moment. In the case of 802.11b ChannelNumber must be a number between 1 and 13. In the case of 802.11a ChannelNumber must be one of the following list: 36, 40, 44, 48, 52, 56, 60 or 64. The ‘ifNum’ follows the coding described on the previous method. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

public boolean setMACFilter (String FilterName, String[] MACAddress, String AccessListID): establish a Filter that is going to be used to select the client’s MACAddress for QoS purposes. It creates a new user access list for the user selected or adds the user to an existing access list. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case. The parameters are:

o String FilterName: The name that we want to give to the filter.o String[] MACAddress: List of Clients’ MAC Addresses that we want to include in the

filter. The format of the MAC Address will be the same as in the previous methods.o String AccessListID: Identification of the Access List. It must be a number between

700 and 799. public boolean setVLANFilter (String FilterName, String VLANId): establish a Filter that is

going to be used to select the VLAN for QoS purposes. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case. The parameters are:

o String FilterName: The name we want to give to the filter.




o String VLANId: Identification of the VLAN that we want to assign QoS. public boolean removeFilter(String FilterName): removes a filter created using one of the two

last methods. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

public boolean setQoSPolicy (String PolicyName, String FilterName, String Priority): sets a policy to provide QoS. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case. The parameters are:

o String PolicyName: The name that we want to give to the policy.o String FilterName: The name of an already existing filter, that we want to bind to the

policy.o String Piority: Which priority level (0...7) we want to assign to this policy: ‘0’ is the

lowest and ‘7’ the highest. public boolean removeQoSPolicy (String PolicyName): removes a policy created by the

previous method. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

public boolean bindQoS (int ifNum, String direction, String PolicyName): binds a policy, created by the ‘setQoSPolicy’ method with an Interface and a direction on the flow of data. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case. The parameters are:

o int ifNum: Which interface we want to bind to the policy defined in the previous method. ‘0’ refers to Fast Ethernet, ‘1’ to 802.11b and ‘2’ to 802.11a interfaces respectively.

o String direction: In which direction we want to apply the policy. ‘input’ if it is the direction to the AP, ‘output’ if it is the direction from the AP and ‘both’ if we want to apply it to both directions.

o String PolicyName: Name of the police, that already exists, which define the QoS. public boolean unbindQoS (int ifNum, String direction, String PolicyName): undoes the action

made by the previous method, i.e., removes QoS from a specific interface and direction. The parameters have the same meaning as in the previous method. It returns ‘true’ if the action finishes in a correct way and ‘false’ in any other case.

Finally, the interface adopts the following structure:

public class WLANBrokerInterface{public WLANBrokerInterface(InetAddr APAddr, String confPasswd);public boolean isUserAssociated(String ClientIPAddr);public String[] getAssociatedUserAddrs();public String getUserMAC (String ClientIPAddr);public String getUserIP (String ClientMACAddr);public boolean createSS(String SSID, String AutType, String AccessListID, String MaxAssoc);public boolean removeSS(String SSID);public String getClientSSID(String ClientMACAddr); public boolean establishVLAN (String VLANId, String SSID);public boolean removeVLAN (String VLANId, String SSID);public boolean addAccessList (String AccessListID, String permition, String MACAddr);public String[] getAccessList ();public boolean removeAccessList (String AccessListID);public String snmpGet (String community, String host, String oid);




public float getLoad();public float getLoadPerConnectionfromAP(String ClientMACAddr)public float getLoadPerConnectionfromClient (String ClientMACAddr);public int getSignalQuality (String MACAddress);public int getInterfaceStatus (int ifNum);public boolean setInterfaceStatus (int ifNum, boolean status);public boolean setChannel(String ChannelNumber, int ifNum);public boolean isChannelActive(int ChannelNumber, int ifNum);public boolean setMACFilter (String FilterName, String[] MACAddress, String AccessListID);public boolean setVLANFilter (String FilterName, String VLANId);public boolean removeFilter (String FilterName);public boolean setQoSPolicy (String PolicyName, String FilterName, String Priority);public boolean removeQoSPolicy (String PolicyName);public boolean bindQoS (int ifNum, String direction, String PolicyName);public boolean unbindQoS (int ifNum, String direction, String PolicyName);}

4.10.1.2 API implementation details for CISCO APs

After explaining with detail all the methods proposed for the WLAN Broker, is time now to give more detail about the implementation of this broker looking at a particular vendor. In our case, the class WLANCISCOWrapper is the implementation of the WLAN Wrapper for CISCO Access Points.

The WLANCISCOWrapper class is composed by a series of methods which corresponds to the capabilities of the AP that are offered to DINA nodes. This Wrapper is going to communicate with the Access Point in two different ways: In the case of methods designed for configuration, it will open a Telnet session and send CISCO OS Commands; in the case of monitoring methods it mainly will use SNMP.

Hereafter we present Table 6 containing the mapping between the API methods and the commands and services supported by the target device.

Table 6: Mapping between API WLAN methods and CISCO access point commands

Method Main commands

boolean isUserAssociated (String ClientIPAddress)

show dot11 associations all-client | include IP

public String getUserMAC (String ClientIPAddr)

show dot11 associations all-client | include Address

String getUserIP (String ClientMACAddr)

show dot11 associations all-client | include Address

String [] getAssociatedUserAddrs() show dot11 associations all-client | include Name




int getNumberofClients() oids[0]=”.1.3.6.1.4.1.9.9.273.1.1.2.1.1.1”;

this.snmpget(“public”,this.ROUTER,oids)[0];

String [] getAccessList() show access-lists

int getInterfaceStatus(int ifNum) show interfaces FastEthernet 0 | include FastEthernet

boolean setInterfaceStatus(int ifNum, boolean status)

configure terminal

interface FastEthernet 0

if (status = false) then no shutdown

if (status = true) shutdown

end

boolean isChannelActive(int ChannelNumber, int ifNum)

show controllers Dot11Radio 0 | include Channel

int getSignalQuality(String MACAddress)

show dot11 associations “+MACAddress+” | include Quality

boolean createSS(String SSID, String AutType, String AccessListID, String MaxAssoc)

configure terminal

interface Dot11Radio 0

“ssid “+SSID

authentication open “+ AutType +” “+ AcessListID

“max-associations “ +MaxAssoc

end

boolean removeSS(String SSID) configure terminal

interface Dot11Radio 0

“no ssid “+SSID

end

String getClientSSID (String ClientMACAddr)

show dot11 associations “+ClientMACAddr+” | include SSID

boolean establishVLAN (String VLANId, String SSID)

“configure terminal”

“interface Dot11Radio 0”

“ssid “+SSID

“vlan “+VLANId

“exit”

“interface Dot11Radio 0.”+VLANId

“encapsulation dot1q “+VLANId

“exit”

“interface fastEthernet 0.”+ VLANId

“encapsulation dot1q “+VLANId




“end”

boolean removeVLAN (String VLANId, String SSID)


“interface dot11radio 0”

“ssid “+SSID

“no vlan “+VLANId

“exit”

“interface dot11radio 0.”+VLANId

“no encapsulation dot1q “+VLANId

“exit”

“interface fastEthernet 0.”+VLANId

“no encapsulation dot1q “+VLANId

“exit”

“end”

boolean addAccessList (String AccessListId, String permition, String MACAddr)


“access-list “+ AccessListId+ “ “ + permition+ “ “ + MACAddr

“end”

boolean removeAccessList(String AccessListId)


“no access-list “+ AccessListId

“end”

boolean setChannel(String ChannelNumber, int ifNum)



“channel “+ChannelNumber

“end”

String [] snmpget(String community, String host, String[] oids )

return snmpget( 2, community, 0, 0, 0, null, null, null, null, 0, host, oids );

float getLoadPerConnectionfromClient(String ClientMACAddr)

oids[0]=this.OidConstructor(ClientMACAddr,this.getClientSSID(ClientMACAddr),”273.1.3.1.1.7”);

this.snmpget(“public”,this.ROUTER,oids)[0]);

Thread.sleep(10000);

this.snmpget(“public”,this.ROUTER,oids)[0]

The action consists in ask for the transmitted data from the client to the AP twice in 10 seconds. The difference of this data will help us to calculate the load of the link from the client to the AP.

float getLoadPerConnectionfromAP (String ClientMACAddr)

oids[0]=this.OidConstructor(ClientMACAddr,”urbion”,”273.1.3.1.1.9”);




Thread.sleep(10000);

Ans2=(this.snmpget(“public”,this.ROUTER,oids)[0]);

float getLoad() In order to implement this method, we have taken profit from the previous one.

boolean setMACFilter (String FilterName, String [ ] MACAddress , String AccessListID)


“access-list “+ AccessListID + “ deny 0000.0000.0000 ffff.ffff.ffff”

“class-map “+ FilterName

“match access-group “ + AccessListID

“exit”

“end”

boolean setVLANFilter(String FilterName, String VLANId)


“class-map “+ FilterName

“match vlan “ + VLANId

“exit”

“end”

boolean removeFilter(String FilterName)


“no class-map “+ FilterName

boolean setQoSPolicy(String PolicyName, String FilterName, String Priority)


“policy-map “+ PolicyName

“class “+ FilterName

“set cos “+ Priority);

“exit”

“exit”

boolean removeQoSPolicy(String PolicyName)


“no policy-map “+PolicyName

boolean bindQoS (int ifNum, String direction, String PolicyName)


switch ( ifNum ) {

case 1:


“service-policy “+ direction + “ “ + PolicyName

“exit”

“exit”

boolean unbindQoS (int ifNum, String direction, String PolicyName)


switch ( ifNum ) {




case 1:



“no servicepolicy “+ direction + “ “ +PolicyName

“exit”

4.10.2 GPRS broker

The GPRS Wrapper Interface API enables active services to retrieve information about the GPRS users and send them SMS messages. The retrieved information refers to the user’s location (geographical coordinates) and IP address. The requests for location information acquisition are forwarded to the Mobile Network Operator (MNO) server of the GPRS network. The MNO server calculates the users’ location utilizing triangulation techniques.


The following methods have been specified for the GPRSWrapperInterface API: public GPRSWrapperInterface(): constructor. private String sendRequest(String MSISDN): sends an HTTP POST message to

VODAFONE’s MNO server and returns the server’s reply. The message contains a request for the location of a (VODAFONE) GPRS user in XML format.

o String MSISDN: the GPRS user’s MSISDN number. private String sendRequest(String MSISDN, String message): sends an HTTP POST message

to VODAFONE’s message server and returns the server’s reply. This message triggers the message server to send an SMS to a GPRS user.

o String MSISDN: the GPRS user’s MSISDN number.o String message: the text of the SMS message that will be sent to the user.

public boolean isUserConnected(String MSISDN): Returns true if a user is connected to the network through VODAFONE’s GPRS network.

o String MSISDN: the GPRS user’s MSISDN number. public String getUserLocation(String MSISDN): returns the GPRS user’s location in

geographical coordinates and the timestamp of the measurement separated with commas (“X, Y, t”). If the user is offline, a notification message (“user is offline”) is returned instead.

o String MSISDN: the GPRS user’s MSISDN number. public String getUserIPAddress(String MSISDN): returns the IP address of the packets that

leave VODAFONE’s GPRS network. It is a hard-coded value: all the packets that are sent from VODAFONE’s GPRS users always leave VODAFONE’s network with the same IP address. If the user is offline, a notification message (“absent subscriber”) is returned instead.

o String MSISDN: the GPRS user’s MSISDN number public boolean sendMessage(String MSISDN, String message): sends an SMS to a

(VODAFONE) GPRS user. Returns true if the SMS was successfully sent to the user.o String MSISDN: the GPRS user’s MSISDN number.o String message: the text of the SMS.

The GPRSWrapperInterface adopts the following structure:public class GPRSWrapperInterface{




private final String VODAFONE_MNO= “http://x.x.x.x/send_sms_locate.ref”;private final String VODAFONE_MESSAGER=“http://x.x.x.x/send_sms.ref”;private String sendRequest(String MSISDN);private String sendRequest(String MSISDN, String message);public GPRSWrapperInterface();public boolean isUserConnected(String MSISDN);public String getUserLocation(String MSISDN);public String getUserIPAddress(String MSISDN);public boolean sendMessage(String MSISDN, String message);}


The active packet which contains methods of the GPRSWrapperInterface API should be executed in a DINA node that has access to VODAFONE’s servers. Moreover, we note that the location calculation procedure requires more than half minute. Hence, it is necessary to increase the SESSION_TTL parameter for the DINA nodes where the GPRSWrapperInterface methods will be executed into (or the utilization of the refresh method of the sessionBrokerInterface API).


http://x.x.x.x/send_sms.ref

http://x.x.x.x/send_sms_locate.ref



ANNEX A REFERENCES

[1] Alexander, D. S., et al., “The SwitchWare Active Network Architecture,” IEEE Network Special Issue on Active and Controllable Networks, Vol. 12, No. 3, 1998, pp. 29-36. http://www.cis.upenn.edu/~switchware/papers/switchware.ps.

[2] Bavier, A., et al., SILK: Scout Paths in the Linux Kernel, Technical Report 2002-009, Uppsala University, February 2002.

[3] AIN Release 1 Service Logic Program Framework Generic Requirements, Bell Communications Research Inc., FA-NWT-001132.

[4] Berson, S., Braden, B., and Ricciulli, L., Introduction to the ABone, June 15, 2000. http://www.isi.edu/abone/DOCUMENTS/ABoneIntro.ps.

[5] Berson, S., Braden, B., and Gradman, E., The Network I/O Daemon–Netiod, October 11, 2001, Draft version. http://www.isi.edu/abone/DOCUMENTS/netiod.ps.

[6] Braden, B., Faber, T., and Handley, M., “From Protocol Stack to Protocol Heap–Role Based Architecture,” HotNets I, Princeton University, October 2002. http://www.cs.washington.edu/hotnets/papers/braden.pdf

[7] Biswas, J., et al., “The IEEE P1520 Standards Initiative for Programmable Network Interfaces,” IEEE Communications, Special Issue on Programmable Networks, Vol. 36, No 10, October 1998. http://www.ieee-pin.org/.

[8] Calvert, K. L. (ed.), Architectural Framework for Active Networks, Draft version 1.0, July 27, 1999, http://protocols.netlab.uky.edu/~calvert/arch-latest.ps.

[9] Calvert, K., et al, “Directions in Active Networks,” IEEE Communications Magazine, 1998, http://www.cc.gatech.edu/projects/CANEs/papers/Comm-Mag-98.pdf.

[10] Composable Active Network Elements Project (CANES). http://www.cc.gatech.edu/projects/canes/.

[11] Decasper, D., et al., “A Scalable, High-performance active Network Node,” IEEE Network, January/February 1999.

[12] FAIN Project, http://www.ist-fain.org.

[13] Hicks, M., et al., “PLAN: A Packet Language for Active Networks,” Proc. of the Third ACM SIGPLAN International Conference on Functional Programming Languages, pp. 86-93, ACM, September 1998, http://www.cis.upenn.edu/~switchware/papers/plan.ps.

[14] Hicks, M., Moore, J.T., and Nettles, S., “Compiling PLAN to SNAP,” IWAN’01, September/October 2001. http://www.cis.upenn.edu/~jonm/papers/plan2snap.ps.

[15] IETF ForCES, draft-ietf-forces-framework-04.txt, December 2002. http://www.ietf.org/Internet-drafts/draft-ietf-forces-framework-04.txt.

[16] IETF ForCES. http://www.ietf.org/html.charters/forces-charter.html.

[17] Keller, R., et al., “PromethOS: A Dynamically Extensible Router Architecture Supporting Explicit Routing,” Proc. of the Fourth Annual International Working Conference on Active Networks (IWAN 2002), Springer Verlag, Lecture Notes in Computer Science, 2546, Zurich, Switzerland, December 4-6, 2002.


http://www.ietf.org/html.charters/forces-charter.html

http://www.ietf.org/Internet-drafts/draft-ietf-forces-framework-04.txt

http://www.cis.upenn.edu/~jonm/papers/plan2snap.ps

http://www.cis.upenn.edu/~switchware/papers/plan.ps

http://www.ist-fain.org/

http://www.cc.gatech.edu/projects/canes/

http://www.cc.gatech.edu/projects/CANEs/papers/Comm-Mag-98.pdf

http://protocols.netlab.uky.edu/~calvert/arch-latest.ps

http://www.ieee-pin.org/

http://www.cs.washington.edu/hotnets/papers/braden.pdf

http://www.isi.edu/abone/DOCUMENTS/netiod.ps

http://www.isi.edu/abone/DOCUMENTS/ABoneIntro.ps

http://www.cis.upenn.edu/~switchware/papers/switchware.ps



[18] Merugu, S., et al., “Bowman: A Node OS for Active Networks,” Proc. of IEEE Infocom 2000, Tel Aviv, Israel, March 2000. http://www.cc.gatech.edu/projects/CANEs/papers/bowman.pdf.

[19] Open Signaling Working Group. http://www.comet.columbia.edu/opensig/.

[20] An Architecture for Differentiated Services, RFC 2475, 1998. http://www.ietf.org/rfc/rfc2475.txt.

[21] SNAP: Safe and Nimble Active Packets, http://www.cis.upenn.edu/~dsl/SNAP/.

[22] Schmid, S., et al., “Flexible, Dynamic, and Scalable Service Composition for Active Routers,” Proc. Fourth Annual International Working Conference on Active Networks (IWAN 2002), Zürich, Switzerland, Lecture Notes in Computer Science 2546, Springer Verlag, December 2002.

[23] Tullmann, P., Hibler, M., and Lepreau, J., “Janos: A Java-Oriented OS for Active Networks,” IEEE Journal on Selected Areas of Communication. Vol. 19, No. 3, March 2001.

[24] Vicente, J., et al., “Programming Internet Quality of Service,” 3 rd IFIP/GI International Conference of Trends toward a Universal Service Market, Munich, Germany, September 12-14, 2000. http://comet.ctr.columbia.edu/~campbell/papers/usm00.pdf.

[25] Zegura, E. (ed.), Composable Services for Active Networks, AN Composable Services Working Group, September 1998. http://www.cc.gatech.edu/projects/CANEs/papers/cs-draft0-3.ps.gz.

[26] Gelas, J., and Lefevre, L., “TAMANOIR: A High-Performance Active Network Framework,” Active Middleware Services, Kluwer Academic Publishers, August 2000.

[27] Gelas, J-P., and Lefèvre, L., “Toward the Design of an Active Grid,” Lecture Notes in Computer Science, Computational Science - ICCS 2002, Vol. 2230, April 2002, pp. 578-587.

[28] Marshall, I.W., and Roadknight, C.M., “Provision of Quality of Service for Active Services,” Computer Networks, Vol. 36, No. 1, June 2001, pp. 75-87.

[29] ANDROID project, Active Network Distributed Open Infrastructure Development, www.cs.ucl.ac.uk/research/android.

[30] Moab. http://www.cs.utah.edu/flux/janos/moab.html.

[31] Brunner, M., et al., “Service Management in Multi-Party Active Networks,” IEEE Communications Magazine, March 2000.

[32] Tennenhouse David, Smith Jonathan: “A survey of Active Network Research”, IEEE Communications Magazine, January 1997

[33] Caspian project: http://www.eurescom.de/public/projects/P900-series/P926/default.asp

[34] Galis, A., Denazis, S., Brou, C., Klein, C. (ed) – “ Programmable Networks for IP Service Deployment“ ISBN 1-58053-745-6; pp450, May 2004 by Artech House Books; www.artechhouse.com

[35] Introduction to the ABone, http://www.isi.edu/abone/intro.html.

[36] ABLE: The Active Bell Labs Engine, http://www.cs.bell-labs.com/who/ABLE/.


http://www.cs.bell-labs.com/who/ABLE/

http://www.isi.edu/abone/intro.html

http://www.artechhouse.com/

http://www.eurescom.de/public/projects/P900-series/P926/default.asp

http://www.cs.utah.edu/flux/janos/moab.html

http://www.cs.ucl.ac.uk/research/android

http://www.cc.gatech.edu/projects/CANEs/papers/cs-draft0-3.ps.gz

http://www.cc.gatech.edu/projects/CANEs/papers/cs-draft0-3.ps.gz

http://comet.ctr.columbia.edu/~campbell/papers/usm00.pdf

http://www.cis.upenn.edu/~dsl/SNAP/

http://www.ietf.org/rfc/rfc2475.txt

http://www.comet.columbia.edu/opensig/

http://www.cc.gatech.edu/projects/CANEs/papers/bowman.pdf



[37] Bush, S., F., and Kulkarni, A., Active Networks and Active Network Management: A Proactive Management Framework, Norwell, MA: Kluwer Academic/Plenum Publishers, 2001.

[38] Schwartz, B., et al., “Smart Packets for Active Networks,” OpenArch ’99, March 1999.

[39] Brunner, M., Plattner, B., and Stadler, R., “Service Creation and Management in Active Telecom Environments,” Communications of the ACM, March 2001.

[40] Galtier, V., et al., “Prediction and Controlling Resource Usage in a Heterogeneous Active Network,” MILCOM 2001, October 2001.

[41] Kornblum, J., Raz, D., and Shavitt, Y., “The Active Process Interaction with Its Environment,” IWAN 2000, October 2000.

[42] Application-Level Active Networks, http://dmir.it.uts.edu.au/projects/alan/.

[43] Alexander, D., S., et al., “The SwitchWare Active Network Architecture,” IEEE Network Special Issue on Active and Controllable Networks, Vol. 12, No. 3, 1998, pp. 29-36. http://www.cis.upenn.edu/~switchware/papers/switchware.ps.

[44] Nestor Project: http://www1.cs.columbia.edu/dcc/nestor.

[45] Yemini, Y., Konstantinou, A., and Florissi, D., “NESTOR: An Architecture for NEtwork Self-managemenT and Organization,” IEEE Journal on Selected Areas in Communications, Vol. 18, No. 5, 2000.

[46] Sun Microsystems, Porting Networking Applications to the IPv6 APIs, October 1999.

[47] Porting applications to IPv6 HowTo, http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html.

[48] ABLE: The Active Bell Labs Engine, http://www.cs.bell-labs.com/who/ABLE/.

[49] Zander, J & Forchheimer, R, ”SOFTNET - an approach to high-level packet communication”, 2nd ARRL Amateur Radio Computer Networking Conference, San Francisco, CA, 1983

[50] “DARPA Active Networks Conference and Exposition,” DANCE Proc. – IEEE Computer Society Number PR01564, May 2002. Leslie, I., et al., The Design and Implementation of an Operating System to Support Distributed Multimedia Applications. http://www.cl.cam.ac.uk/Research/SRG/netos/old-projects/nemesis/documentation.html.

[51] Montz, A., et al., “Scout: A Communications-Oriented Operating System,” IEEE HotOS Workshop, May 1995.

[52] Hjalmtysson, G., “The Pronto Platform – A Flexible Toolkit for Programming Networks Using a Commodity Operating System,” OpenARCH 2000.


http://www.cl.cam.ac.uk/Research/SRG/netos/old-projects/nemesis/documentation.html

http://www.cs.bell-labs.com/who/ABLE/

http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html

http://www1.cs.columbia.edu/dcc/nestor

http://www.cis.upenn.edu/~switchware/papers/switchware.ps

http://dmir.it.uts.edu.au/projects/alan/



ANNEX B DINA CODE DISTRIBUTION AND AVAILABILITY

The DINA code, as well as other code components developed in the IST Context project, will be made publicly available, under the licensing terms and conditions that will be determined within the consortium.




ANNEX C PARTNER´S CONTRIBUTION TO THIS DELIVERABLE

VTT Security Architecture

DINA adaptation to IPv6

Control Broker

Network Broker

TID Inputs from Crisis Helper to Chapter 2

VODAFONE

ALGONET

UCL Inputs from Super Mother to Chapter 2

Chapter 3

SIP broker

TECHNION The ABLE platform

The Active Platform

Code and service execution support

Management

Security Architecture

Info Broker

Filter broker for Linux routers

UPC Edition of this document

Inputs from Services to All to Chapter 2

Formulation of requirements for Chapter 2

Control Broker for CISCO routers

WLAN broker

Filter Broker for CISCO routers

ICCS Inputs from Moving Campus to Chapter 2

QoS broker

Context broker

GPRS broker


Documents

Annex A