PhD Topic Template Based Composition

PhD TopicTemplate Based Composition

PhD Course 5th March – 9th March 2012 , Kaiserslautern

2Abbas Siddiqui, University of Kaiserslautern

Motivation

Application DemandsInflexibility of Current Internet ArchitectureGoals- 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


Functional Composition

Decomposes stack into so called fine-grain functionalityComposing on demandLikely optimized Selection of a functionality

Application

Functional CompositionPolicies

Offerings

Requirements

Protocol Graph


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)


Template Based Composition

Place-holder: An Abstraction between implementation and a serviceComposition at design-timeSelection of implementation at run-time

TemplatePlace-Holder


Place-Holder

Well-defined portsPort consists of provided and offered effects (i.e. bidirectional)Enabling and Disabling a functionalityMiscellaneous ports (e.g. monitoring, administration)


Application

RequirementsDomain Name

Template Description

API

Selection of Template

RequirementsDescription

Domain BasedPolicies

Selection ofBB(s) to fillPlaceholder(s)


Tradeoffs in Selection & Composition Approaches


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


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


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


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


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: [email protected]: http://www.icsy.de


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


Extra Slides


Requirement Analyzing

Granularity is not a trivial questionClassification 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)


Classification of Requirements (1/2)


Classification of Requirements (2/2)


Template Description Language

Composition is performed by connections tag defined in the language


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 timeSelection- First suitable match- Any simple MCDA approach (i.e. for performance testing)


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

PhD Topic Template Based Composition

Documents