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
3Abbas Siddiqui, University of Kaiserslautern
Functional Composition
Decomposes stack into so called fine-grain functionalityComposing on demandLikely 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 serviceComposition at design-timeSelection of implementation at run-time
TemplatePlace-Holder
6Abbas Siddiqui, University of Kaiserslautern
Place-Holder
Well-defined portsPort consists of provided and offered effects (i.e. bidirectional)Enabling and Disabling a functionalityMiscellaneous 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: [email protected]: 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 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)
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 timeSelection- 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