Project Number:            IST – 2001 – 38142 – CONTEXT

Project Title:             Active Creation, Delivery and Manageme...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Specification, design and implementation of the necessary components for the enhancement of an active platform for the
val...
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Annex A
Upcoming SlideShare
Loading in …5
×

Annex A

2,128 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,128
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Annex A

  1. 1. 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: annex-a2733.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 • 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 5/8/2010
  2. 2. 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 • 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
  3. 3. 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 DOCUMENT HISTORY Date 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 © 2002 CONTEXT Consortium
  4. 4. 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 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. Copyright © 2002 CONTEXT Consortium
  5. 5. 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 TABLE OF CONTENTS 1 INTRODUCTION..................................................................................................................1 2 ANALYSIS OF SCENARIOS AND ACTIVE LAYER REQUIREMENTS CAPTURE 3 2.1 MOVING CAMPUS SCENARIO....................................................................................................3 2.1.1 Scenario Description.................................................................................................3 2.1.1.1 CA-Conference Set Up.......................................................................................3 2.1.1.2 CA-Announcement Service................................................................................4 2.1.2 Functionality required from the DINA brokers.........................................................4 2.2 CRISIS HELPER SCENARIO.......................................................................................................8 2.2.1 Scenario description..................................................................................................8 2.2.2 Functionality required from the DINA brokers.......................................................10 2.3 SUPER MOTHER SCENARIO....................................................................................................11 2.3.1 Description..............................................................................................................11 2.3.1.1 Initial Stage.......................................................................................................12 2.3.1.2 Pre-handover Stage...........................................................................................12 2.3.1.3 Handover Stage.................................................................................................12 2.3.1.4 Post-handover Stage..........................................................................................12 2.3.2 Functionality Required from the Brokers................................................................16 2.4 SERVICES TO ALL SCENARIO..................................................................................................17 2.4.1 Scenario Description...............................................................................................17 2.4.1.1 Step 1. Deployment and configuration of Condition Evaluators......................17 2.4.1.2 Step 2. Service Invocation................................................................................18 2.4.1.3 Step 3. Enforcement of actions.........................................................................18 2.4.1.4 Step 4. Execution of the service logic object....................................................19 2.4.1.5 Step 5. Service assurance..................................................................................19 2.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...........................................................................................27 3.2 THE ABLE PLATFORM........................................................................................................32 3.2.1 The Session Broker .................................................................................................34 3.2.2 The Info Broker .......................................................................................................34 3.2.3 The Control Broker .................................................................................................35 3.2.4 The Diverter and Linux Filtering System ...............................................................35 4 DINA: THE AN PLATFORM FOR THE CONTEXT PROJECT.................................36 4.1 THE ACTIVE PLATFORM.......................................................................................................36 4.1.1 DINA Active Packets................................................................................................37 4.1.1.1 UDP/IP Header.................................................................................................38 4.1.1.2 ANEP Header....................................................................................................38 4.1.1.3 DINA Header....................................................................................................38 4.1.1.4 Class Length and Class URL Option................................................................39 4.1.1.5 Active Payload..................................................................................................40 4.1.2 Diverter....................................................................................................................40 Copyright © 2002 CONTEXT Consortium
  6. 6. 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 4.1.3 The Session Broker..................................................................................................40 4.1.3.1 Session Broker Channels..................................................................................40 4.1.3.2 Session Database...............................................................................................41 4.1.3.3 Aging Mechanism.............................................................................................42 4.1.4 URL Class Loader...................................................................................................42 4.1.5 Execution Environment............................................................................................42 4.1.5.1 Java EE..............................................................................................................42 4.1.6 Brokers.....................................................................................................................42 4.2 CODE AND SERVICE EXECUTION SUPPORT.................................................................................44 4.2.1 API specification......................................................................................................44 4.3 MANAGEMENT OF ACTIVE NODES............................................................................................44 4.3.1 AN management.......................................................................................................44 4.3.1.1 Management Broker..........................................................................................45 4.4 SECURITY ARCHITECTURE.....................................................................................................46 4.4.1 Introduction.............................................................................................................46 4.4.1.1 Relevant Entities...............................................................................................46 4.4.1.2 Relevant Objects...............................................................................................47 4.4.1.3 Objectives of Security Functions......................................................................47 4.4.2 DINA Security Requirements...................................................................................47 4.4.2.1 Authentication and Verification of Integrity.....................................................48 4.4.2.2 Replay Protection..............................................................................................48 4.4.2.3 Identification of Active Code and Active Service............................................48 4.4.2.4 Access Control..................................................................................................49 4.4.3 Architectural Specification .....................................................................................49 4.4.3.1 Overall Architecture..........................................................................................49 4.4.3.2 Access Rights Management..............................................................................50 4.4.3.3 Authentication and Verification of Integrity.....................................................50 4.4.3.4 Identification of Active Code and Active Service............................................52 4.4.3.5 Access Control..................................................................................................52 4.5 DINA ADAPTATION TO IPV6................................................................................................53 4.5.1 IPv6 Overview.........................................................................................................53 4.5.2 Porting Application to Understand IPv6.................................................................54 4.5.2.1 Socket Address Structures................................................................................54 4.5.2.2 Socket Functions...............................................................................................56 4.5.2.3 Address Conversion..........................................................................................56 4.5.2.4 Name Resolution...............................................................................................56 4.5.3 Context View for IPv6..............................................................................................57 4.5.3.1 Changes in DINA for IPv6................................................................................57 4.5.3.2 DINA Active Packet Formats...........................................................................57 4.6 IP API..............................................................................................................................59 4.6.1 Info Broker...............................................................................................................59 4.6.1.1 API specification...............................................................................................59 4.6.1.2 API Implementation details..............................................................................61 4.6.2 Control Broker.........................................................................................................61 4.6.2.1 API specification...............................................................................................61 4.6.2.2 API implementation details for Linux routers..................................................63 4.6.2.3 API implementation details for CISCO routers................................................63 4.6.3 Network Broker........................................................................................................66 Copyright © 2002 CONTEXT Consortium
  7. 7. 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 4.6.3.1 API specification...............................................................................................66 4.6.3.2 API implementation details...............................................................................68 4.6.4 SIP broker................................................................................................................68 4.6.4.1 API specification...............................................................................................69 4.6.4.2 API implementation details...............................................................................70 4.7 FILTERING AND QOS............................................................................................................70 4.7.1 Filter broker.............................................................................................................70 4.7.1.1 API specification for LINUX routers................................................................70 4.7.1.2 API specification for CISCO routers................................................................71 4.7.1.3 API Implementation details..............................................................................72 4.7.2 QoS broker...............................................................................................................72 4.7.2.1 API specification...............................................................................................73 4.7.2.2 API implementation details...............................................................................78 4.8 CONTEXT SUPPORT...............................................................................................................78 4.8.1 Context broker.........................................................................................................78 4.9 ACTION BROKER..................................................................................................................79 4.9.1 API specification......................................................................................................79 4.9.2 API implementation details......................................................................................80 4.10 WIRELESS SUPPORT............................................................................................................80 4.10.1 WLAN broker ........................................................................................................80 4.10.1.1 API specification.............................................................................................81 4.10.1.2 API implementation details for CISCO APs...................................................85 4.10.2 GPRS broker..........................................................................................................88 4.10.2.1 API specification.............................................................................................89 4.10.2.2 API implementation details.............................................................................89 TABLE OF FIGURES FIGURE 1: CONTEXT FUNCTIONAL ARCHITECTURE..............................................2 FIGURE 2: CONTEXT-AWARE CONFERENCE SETUP SERVICE IN THE MOVING CAMPUS SCENARIO...........................................................................................5 FIGURE 3: CONTEXT-AWARE ANNOUNCEMENT SERVICE IN THE MOVING CAMPUS SCENARIO.............................................................................................................6 FIGURE 4: INTERACTIONS BETWEEN APPLICATIONS AND DINA BROKERS IN THE CRISIS HELPER SCENARIO......................................................................................9 FIGURE 5: DIAGRAM SHOWING THE DISTRIBUTION OF THE BROKERS AND CONTEXT CONTROL OBJECTS (CCOS) FOR THE SUPERMOTHER SCENARIO. 11 FIGURE 6: SEQUENCE DIAGRAM OF THE INITIAL STAGE OF THE SUPER MOTHER SCENARIO..........................................................................................................13 FIGURE 7: SEQUENCE DIAGRAM FOR THE PRE-HANDOVER STAGE OF THE SUPERMOTHER SCENARIO.............................................................................................14 FIGURE 8: SEQUENCE DIAGRAM FOR THE HANDOVER STAGE OF THE SUPERMOTHER SCENARIO.............................................................................................15 Copyright © 2002 CONTEXT Consortium
  8. 8. 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 FIGURE 9: SEQUENCE DIAGRAM FOR THE POST-HANDOVER STAGE OF THE SUPERMOTHER SCENARIO.............................................................................................15 FIGURE 10: CONDITION EVALUATOR DEPLOYMENT INTERACTIONS IN THE SERVICES TO ALL SCENARIO........................................................................................17 FIGURE 11: SERVICE INVOCATION INTERACTIONS IN THE SERVICES TO ALL SCENARIO....................................................................................................................18 FIGURE 12: ACTION ENFORCEMENT INTERACTIONS IN THE SERVICES TO ALL SCENARIO....................................................................................................................19 FIGURE 13: SERVICE LEVEL OBJECT EXECUTION INTERACTIONS IN THE SERVICES TO ALL SCENARIO........................................................................................20 FIGURE 14: ENDING TX FILE INTERACTIONS IN THE SERVICE TO ALL SCENARIO 20 FIGURE 15: SERVICE ASSURANCE INTERACTIONS IN THE SERVICES TO ALL SCENARIO 21 FIGURE 16: P1520 PROJECT REFERENCE MODEL AND THE L-INTERFACE ABSTRACTION MODEL.....................................................................................................25 FIGURE 17: FORCES ARCHITECTURAL REPRESENTATION OF THE NETWORK ELEMENT........................................................................................................26 FIGURE 18: BASIC ACTIVE NODE ARCHITECTURE.................................................26 FIGURE 19: MAIN CLASSES OF THE ABLE ACTIVE SERVER................................33 FIGURE 20: DINA ACTIVE PLATFORM ENVIRONMENT.........................................36 FIGURE 21: DINA BLOCK DIAGRAM ARCHITECTURE...........................................37 FIGURE 22: DINA PACKET FORMAT.............................................................................37 FIGURE 23: THE ANEP PACKET HEADER FORMAT.................................................38 FIGURE 24: THE DINA PACKET HEADER FORMAT.................................................39 FIGURE 25: JAVA EXECUTION ENVIRONMENT IN DINA.......................................43 FIGURE 26: OVERALL ARCHITECTURE OF DINA SECURITY...............................49 FIGURE 27: CODE AND PACKET SIGNATURES IN THE DINA SECURITY MECHANISM51 FIGURE 28: IPV4 & IPV6 CLIENT/SERVER INTEROPERABILITY.........................55 FIGURE 29: SOCKET ADDRESS STRUCTURES FOR IPV4 AND IPV6.....................55 FIGURE 30: DINA PACKET STRUCTURE FROM SESSION BROKER TO SESSION BROKER INTERFACE.........................................................................................................58 FIGURE 31: DINA PACKET STRUCTURE TO COMMUNICATE FROM SESSION BROKER INTERFACE TO SESSION BROKER .............................................................58 FIGURE 32: EXAMPLE OF VPNAPP ACTIVE APPLICATION PACKET FORMAT 59 FIGURE 33: DIFFSERV DOMAIN......................................................................................73 Copyright © 2002 CONTEXT Consortium
  9. 9. 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 FIGURE 34: ASSOCIATION OF VLANS, SERVICE SETS AND ACCESS LISTS IN A WLAN ACCESS POINT........................................................................................................81 TABLE OF TABLES TABLE 1: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE MOVING CAMPUS SCENARIO...........................................................................................6 TABLE 2: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE CRISIS HELPER SCENARIO..............................................................................................10 TABLE 3: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE SUPERMOTHER SCENARIO.............................................................................................16 TABLE 4: METHODS TO BE SUPPORTED BY THE DINA BROKERS IN THE SERVICES TO ALL SCENARIO........................................................................................21 TABLE 5: METHODS USED TO SUPPORT CISCO ROUTERS THROUGH THE CONTROL BROKER............................................................................................................63 TABLE 6: MAPPING BETWEEN API WLAN METHODS AND CISCO ACCESS POINT COMMANDS............................................................................................................85 ANNEXES A:References ………………………………………………………………………..91 B: dina code distribution and availability…………………………………………..94 C: partner´s contribution to this deliverable………………………………………….95 Copyright © 2002 CONTEXT Consortium
  10. 10. 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 TERMS AND ACRONYMS AN 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 Copyright © 2002 CONTEXT Consortium
  11. 11. 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 EXECUTIVE SUMMARY This 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 Copyright © 2002 CONTEXT Consortium
  12. 12. 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 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. Copyright © 2002 CONTEXT Consortium
  13. 13. 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 1INTRODUCTION 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 107
  14. 14. 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 we have adopted the DINA programmable platform based on concepts used in the ABLE and ABLE++ systems A 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. Copyright © 2002 CONTEXT Consortium 2 of 107
  15. 15. 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 2ANALYSIS 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.1Moving Campus scenario To characterise this scenario we have conceived two services, namely a Conference Start-up and the subseqüent Announcement Service. 2.1.1Scenario Description 2.1.1.1CA-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 Copyright © 2002 CONTEXT Consortium 3 of 107
  16. 16. 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 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.2CA-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.2Functionality 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. Copyright © 2002 CONTEXT Consortium 4 of 107
  17. 17. 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 Conference_Setup_SLO Context Broker Action Broker Customized wi th: part icipants li st, start_time, duration_time For each noti fy(parti ci pant is connected) conference participant username Receive Notification: particant connected, access net,ip_address trigger_action(QoS_setup) For each noti fy(parti cipant_change net_ac cess) connected participant Receive Notification: particant chang ed connecti on, new acces net,new ip_addres s s trigger_action(QoS_reconfigure) For each WLAN that notify(WLAN_loaded) users are connected Receive Notification: WLAN1 l oaded, particants connected, alternative access ne t trigger_action(deliver_message) trigger_action(QoS_remove) Conference ended Figure 2: Context-Aware conference setup service in the Moving Campus scenario Copyright © 2002 CONTEXT Consortium 5 of 107
  18. 18. 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 Announcement_SLO Context Broker Action Broker Customized with: Username notify(announcement_matching) notify(username_change access_net) Receive Notification: particant changed connection, new access net,new ip_address 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 Method Name Description Broker CCO registers the type of context register_new_context_object() information that it provides Context consumer retrieves the current Context Broker get_current_value() value of a context object Context consumer subscribes to get a notify() notification about related to a context object Context producer delivers a notification, give_context_value() or the updated value of a context object Broker Action Executes the action code as issued by the trigger_action() SLO with the specified parameters Copyright © 2002 CONTEXT Consortium 6 of 107
  19. 19. 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 This method retrieves the ingress getIngress() interface. getEgress() This method retrieves the egress interface. resetINGRESS() Resets an ingress interface. Broker QoS 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 Terminates the TCP connection with the finish() QoS Broker. Given the MSISDN returns true if the isUserConnected() specified user is connected to the GPRS network Wrapper GPRS Given the MSISDN returns the network getUserIPAddress() address of the user’s subnetwork Given the MSISDN returns the user’s getUserLocation() location in geographical coordinates. Given the MSISDN and the message to sendMessage() deliver, delivers an SMS message to the user Given the MAC of the user, returns the IP getUserIP() address of a terminal, which is connected to network through a WLAN network card Wrapper WLAN The bytes per second of the radio interface of the Access Point from the AP to the getLoad() clients (the radio downstream). This load is going to be measured in kbps. Given the user MAC, it returns the quality getSignalQuality() of the signal received from the client (the quality is measured from 0 to 100 in %) Copyright © 2002 CONTEXT Consortium 7 of 107
  20. 20. 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 2.2Crisis Helper scenario 2.2.1Scenario 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. Copyright © 2002 CONTEXT Consortium 8 of 107
  21. 21. 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 CHListener CHmain SIPBroker Context Broker SIP CCO getProxyServers() [] SipProxyID_List sessionStateInfo (SIPProxyID) sessionState register_new_context_object(SIPProxyID.stat eInfo) delegate_new_context_object(SIPProxyID.stateInfo) getProxyServers() [] SipProxyID_List get_current_value(SIPProxyID.stateInfo) SIPProxyID.stateInfo CHListener processes SIP info High establishment of 112 calls detected CHmain invocation via CEC get_current_value(SIPProxyID.stateInfo) SIPProxyID.stateInfo TerminateAllCalls(SIPProxyID) configurationResult configureCallBloc k (SIPProxyID, callType, [] condition) configurationResult configureCallAccept (SIPProxyID, callType, [] condition, bandWidth) configurationResult Figure 4: Interactions between applications and DINA brokers in the Crisis Helper Scenario Copyright © 2002 CONTEXT Consortium 9 of 107
  22. 22. 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 2.2.2Functionality required from the DINA brokers Table 2: Methods to be supported by the DINA brokers in the Crisis Helper scenario DINA Method Name Description Broker Context consumer subscribes to receive a subscribe notification for a context object CCO registers the type of context register_new_context_object Context Broker information that it provides Context consumer retrieves the current get_current_value value of a context object Context consumer subscribes to get a deliver_notification notification related to a context object Context producer delivers a notification, supply_context_value or the updated value of a context object SLO uses this method to close all current terminateAllSessions sessions SIP Broker uses this method to ask the acceptCall SLO if a call must be accepted SLO and SICE use this method to learn getProxyServers SIP Broker the IDs of the SIP softswitches Used by the CCO to gather SIP related sessionStateInfo info (number of 112 calls) Used by the SLO to subscribe to the SIP setCallAcceptanceDiverter Broker Used by the SLO to inform the SIP Broker applyDivertor that diversion must start from this point onwards Copyright © 2002 CONTEXT Consortium 10 of 107
  23. 23. 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 2.3Super Mother scenario 2.3.1Description 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. Home Agent VPN FTP Server Monitor Context broker session broker Office DINA node WLAN broker WLAN broker session broker session broker CCO CCO MobileIP Hospital ISP DINA node DINA node WLAN AP WLAN AP Katherine 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 Copyright © 2002 CONTEXT Consortium 11 of 107
  24. 24. 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 2.3.1.1Initial 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.2Pre-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.3Handover 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.4Post-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 Copyright © 2002 CONTEXT Consortium 12 of 107
  25. 25. 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 Figure 6: Sequence diagram of the initial stage of the Super Mother scenario Copyright © 2002 CONTEXT Consortium 13 of 107
  26. 26. 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 Figure 7: Sequence diagram for the pre-handover stage of the SuperMother scenario Copyright © 2002 CONTEXT Consortium 14 of 107
  27. 27. 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 FTP MIP ISP Hospital FTP Home VPN client client AP AP server Agent monitor 1: CEPPHO HC 2: CEPPHO HO 3: MIP_register_request 4: MIP_register_reply 5: CEPPHO status 6: FTP login, FTP upload Figure 8: Sequence diagram for the handover stage of the SuperMother scenario. (CEPPHO stands for Cello Protocol for Planned Handovers Command) FTP MIP ISP Hospital FTP Home VPN client client AP AP server Agent monitor 1: CEPPHO HC 2: CEPPHO HO 3: MIP_register_request 4: MIP_register_reply 5: CEPPHO status 6: FTP login, FTP upload Figure 9: Sequence diagram for the post-handover stage of the SuperMother scenario (CEPPHO stands for Cello Protocol for Planned Handovers Command) Copyright © 2002 CONTEXT Consortium 15 of 107
  28. 28. 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 2.3.2Functionality 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 recData() Receives data. getProg() Obtains the applications from the Session active payload. Broker getInitVars() Obtains data from the active payload. send() Sends an active packet. WLAN isUserAssociated() Returns true if the client Broker identified is connected to a WLAN AP. getUserIP() Returns the IP address of the client connected to the WLAN AP. Context consumer subscribes to subscribe() receive a notification for a context object CCO registers the type of context register_new_context_object() that it provides Context consumer retrieves the Context get_current_value() current value of a context object Broker Context producer sends a deliver_notification() notification of a change in a context value Context producer delivers to the supply_context_value() Context Broker the updated value of a context object setVPN() Starts or stops VPNs between the laptop and the VPN server. Control Broker addTempRoute() Adds an entry to the routing table for a specific period of time between the laptop and VPN server. Copyright © 2002 CONTEXT Consortium 16 of 107
  29. 29. 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 2.4Services to All scenario 2.4.1Scenario 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.1Step 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. PBSM Session Action WLAN GPRS Layer Broker Broker Broker Broker configureCE(CE, ServiceCodeLocation) parse(ActivePacket) retrieve(ServiceCode) download(ServiceCode) Inform(ANInformation) inform(ANInformation) retrieve(WLAN Information) getWLAN(UserStatus) inform(WLANInformation) parse(ActivePacket) getGPRS(UserStatus) inform(GPRSInformation) Figure 10: Condition Evaluator deployment interactions in the Services to All scenario Copyright © 2002 CONTEXT Consortium 17 of 107
  30. 30. 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 2.4.1.2Step 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. WLAN GPRS Session PBSM Broker Broker Broker Layer getWLAN(UserStatus) inform(WLANInformation) getGPRS(UserStatus) inform(GPRSInformation) invocation(CEconditions) check(Policies) enforce(PolicyActions) Figure 11: Service Invocation interactions in the Services to All scenario 2.4.1.3Step 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. Copyright © 2002 CONTEXT Consortium 18 of 107
  31. 31. 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 PBSM Session Action Layer Broker Broker Enforce(PolicyAction) Parse(ActivePacket) Retrieve(ServiceCode) execute(SLO) Figure 12: Action enforcement interactions in the Services to All scenario 2.4.1.4Step 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.5Step 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.6Step 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. Copyright © 2002 CONTEXT Consortium 19 of 107
  32. 32. 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 PBSM Session Information Control WLAN GPRS Layer Broker Broker Broker Broker Broker send(SLO) get(ANInformation) askAN(ANstatus) give(ANInformation) retrieve(WLANInformation) getWLAN(UserStatus) inform(WLANInformation) retrieve(GPRSInformation) getGPRS(UserStatus) inform(GPRSInformation) getRouting(searchRoute) configure(route) makeTunnel(IPTunnel) Figure 13: Service Level Object execution interactions in the Services to All scenario Action Session PBSM Broker Broker Layer inform(ANStatus) endingReport(status) Figure 14: Ending Tx File interactions in the Service to All scenario Copyright © 2002 CONTEXT Consortium 20 of 107
  33. 33. 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 QoS WLAN GPRS PBSM Session Action Broker Broker Broker Layer Broker Broker retrieve(WLAN Information) getWLAN(UserStatus) inform(WLANInformation) getGPRS(UserStatus) inform(GPRSInformation) report(QoSParameters) checkService(actions) Enforce(PolicyAction) Parse(ActivePacket) Retrieve(ServiceCode) download(ServiceCode) execute(ServiceCode) Inform(ANInformation) Figure 15: Service Assurance interactions in the Services to All scenario 2.4.2Functionality required from the DINA brokers 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 Copyright © 2002 CONTEXT Consortium 21 of 107
  34. 34. 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 recData() Method used to receive data. iMDone() Method used to kill control messages. getProg() Method used to extract applications from the active payload. Session Broker 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. 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. Information Broker 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 setRoute() Method used to add and delete entries from the routing table of the active node. Control Broker addTempRoute() Method used to add an entry to the routing table for a specific period of time. After that the entry is removed. Copyright © 2002 CONTEXT Consortium 22 of 107
  35. 35. 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 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 WLAN Broker 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. 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 GPRS Broker 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 Copyright © 2002 CONTEXT Consortium 23 of 107
  36. 36. 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 3ACTIVE 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 A 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 A in 1996, the DARPA ActiveNets Program (1997 – 2003) and a number of European Research projects including: FAIN – Future Active IP Networks project (2000-2003) A, CASPIAN project (2001-2002) A and ANDROID project (2000-2003) A. The first reference book on Programmable Networks is published in 2004 by Artech House A. Programmable networks as a term was used widely by the Opensig A 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 A. 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. Copyright © 2002 CONTEXT Consortium 24 of 107
  37. 37. 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 V USERS Interface Applications invoking methods on objects below U Interface Policy-Based RSVP Differentiated Customized Routing or Other Services Routing Algorithms per-flow Scheduling protocol L Interface Low Service-specific building blocks Degree of Abstraction Resource building blocks Base building blocks CCM High Interface Controller Hardware and other resources Routing table Data 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” AA. The NE is a collection of components A 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. Copyright © 2002 CONTEXT Consortium 25 of 107
  38. 38. 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 Network Element Fr CE 1 CE 2 CE 3 Fp Fi FE 1 FE 2 FE 3 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 A. Figure 18: Basic active node architecture A basic architecture for active nodes A 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 Copyright © 2002 CONTEXT Consortium 26 of 107

×