PhD TopicTemplate Based Composition

PhD Course

5th March – 9th March 2012 , Kaiserslautern

2Abbas Siddiqui, University of Kaiserslautern

Motivation

Application Demands

Inflexibility of Current Internet Architecture

Goals- Enable adaptation according to demands and conditions (Short -

Term Flexibility)- Enable extendibility to add, change and remove protocols (Long-

Term Flexibility)

Functional Composition, An approach towards flexible Internet Architecture

3Abbas Siddiqui, University of Kaiserslautern

Functional Composition

Decomposes stack into so called fine-grain functionality

Composing on demand

Likely optimized Selection of a functionality

Application

Functional CompositionPolicies

Offerings

Requirements

Protocol Graph

4Abbas Siddiqui, University of Kaiserslautern

Epochs for Functional Composition Approaches

Epochs for Selection and Composition Process- Design-time- Deployment-time- Run-time

Functional Composition Approaches- Design-time (e.g. Netlet)- Run-time (e.g. SILO, RNA, ANA)- Intermediate Approach (Template Based Composition)

5Abbas Siddiqui, University of Kaiserslautern

Template Based Composition

Place-holder: An Abstraction between implementation and a service

Composition at design-time

Selection of implementation at run-time

TemplatePlace-Holder

6Abbas Siddiqui, University of Kaiserslautern

Place-Holder

Well-defined ports

Port consists of provided and offered effects (i.e. bidirectional)

Enabling and Disabling a functionality

Miscellaneous ports (e.g. monitoring, administration)

7Abbas Siddiqui, University of Kaiserslautern

Application

RequirementsDomain Name

Template Description

API

Selection of Template

RequirementsDescription

Domain BasedPolicies

Selection ofBB(s) to fillPlaceholder(s)

8Abbas Siddiqui, University of Kaiserslautern

Tradeoffs in Selection & Composition Approaches

9Abbas Siddiqui, University of Kaiserslautern

Complexity

Design-Time Composition- Likely to be performed manually with the help of design tools

Run-Time Composition- Automatic composition requires relatively complex algorithm- Additional information (e.g. requirements, requirements,

offerings)- For optimized composition required QoS, QoE parameters - Inerdepencies resolution- Description of Methods

Template Based Composition- No complex algorithm for composition- No Interdepencies resolution- Process for selection of suitable method

10Abbas Siddiqui, University of Kaiserslautern

Information Availability

Design-Time Composition- Early binding, lack of information (e.g. network capacity, delay,

available services)- No inclusion or exclusion of a functionality

Run-Time Composition- Late-binding - Chances of failure (i.e. missing required but insignificant

information may terminate the process)

Template Based Composition- Run-time information for selection of a functionality- No extra functionality can be added- Functionality can be disabled- Relatively higher chances of successful SC

11Abbas Siddiqui, University of Kaiserslautern

Adaptability

Design-Time Composition- No adaptability , likely configurability of certain functionality- Slightest change in a requirement will need new protocol graph- Unable to accomodate varying QoS, QoE- Not suitable for an enviroment with rapidly context changing

Run-Time Composition- Highly adapatable

Template Based Composition- Good choice for changing QoS and QoE parameter but no

changing the functionalities

12Abbas Siddiqui, University of Kaiserslautern

In Action

Design-Time Composition- Presence of BB + Inclusion in a composed stack- Not suitable for heterogenous environment

Run-Time Composition- Less time required (i.e. as soon as selcted by a SC algorithm)

Template Based Composition- Ready to be used as soon as added in the repository

13Abbas Siddiqui, University of Kaiserslautern

Scenario

Filtering

Traffic Clasification

Flow-IDIP Address

Addressing

Legacy Support

Monster (application)

RequirementsAPI

FilteringController

Priority Controller

SensorPT

Network

Data

Integrated Communication Systems ICSY

University of KaiserslauternDepartment of Computer ScienceP.O. Box 3049D-67653 Kaiserslautern

Phone: +49 (0)631 205-5143Fax: +49 (0)631 205-30 56

Email: dfleuren@informatik.uni-kl.deInternet: http://www.icsy.de

15Abbas Siddiqui, University of Kaiserslautern

Linearity of Graph is not appropriate (Just a conceptual distribution)

Flexibility (Dynamic)

Inflexibility (Static)

Complexity (Time-Requiredfor Set-up a communication)

Design-Time Composition (e.g. TCP/IP stack)(i.e. Selection and composition and design time)

Dynamic Composition (i.e. selection and composition at runtime)

Template-Based Functional Composition(i.e. Composition at design-time and selection and runtime)

•Complexity•Information Availability•Adaptability•In Action

16Abbas Siddiqui, University of Kaiserslautern

Extra Slides

17Abbas Siddiqui, University of Kaiserslautern

Requirement Analyzing

Granularity is not a trivial question

Classification of requirements- What can be asked by whom ( application requirements,

network requirements, administrator requirements, domain-based requirements)

- Placement of functionality (i.e. place a functionality at the edge node or in the intermediate devices, at application , at network)

18Abbas Siddiqui, University of Kaiserslautern

Classification of Requirements (1/2)

19Abbas Siddiqui, University of Kaiserslautern

Classification of Requirements (2/2)

20Abbas Siddiqui, University of Kaiserslautern

Template Description Language

Composition is performed by connections tag defined in the language

21Abbas Siddiqui, University of Kaiserslautern

Building Block Selection

No QoS parameters are considered for the entire workflow- QoS for independent capabilities can be covered, it would help

to select more appropriate implementation to fill a place-holder- QoS based selection for the entire workflow makes it impossible

to have independent selection of a building-block in a place-holder

Pre-Selection of suitable BBs at deployment time

Selection- First suitable match- Any simple MCDA approach (i.e. for performance testing)

22Abbas Siddiqui, University of Kaiserslautern

Terminology

Selection: is to choose a functionality out of given pool, a functionality can be implemented by a building block (BB)

Composition: is a placement (i.e. ordering) of BBs in addition to, compatible interconnectivity for the expected interaction among BBs.

Protocol graph: a protocol graph is a sequence of instructions which may require specialized engine to understand and execute it.

Effect/Capability: Visible outcome of a functionality