1. PhD Topic Template Based Composition PhD Course 5 th March – 9 th March 2012, Kaiserslautern

2. 2 Abbas 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

3. 3 Abbas 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 Composition Policies Offerings Requirements Protocol Graph

4. 4 Abbas 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)

5. 5 Abbas 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 Template Place-Holder

6. 6 Abbas 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)

7. 7 Abbas Siddiqui, University of Kaiserslautern Application Requirements Domain Name Template Description API Selection of Template Requirements Description Domain Based Policies Selection of BB(s) to fill Placeholder(s)

8. 8 Abbas Siddiqui, University of Kaiserslautern Tradeoffs in Selection & Composition Approaches

9. 9 Abbas 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

10. 10 Abbas 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

11. 11 Abbas 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

12. 12 Abbas 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

13. 13 Abbas Siddiqui, University of Kaiserslautern Scenario Filtering Traffic Clasification Flow-ID IP Address Addressing Legacy Support Monster (application) Requirements API Filtering Controller Filtering Controller Priority Controller Sensor PT Network Data

14. Integrated Communication Systems ICSY University of Kaiserslautern Department of Computer Science P.O. Box 3049 D-67653 Kaiserslautern Phone:+49 (0)631 205-5143 Fax:+49 (0)631 205-30 56 Email:dfleuren@informatik.uni-kl.de Internet:http://www.icsy.de

15. 15 Abbas Siddiqui, University of Kaiserslautern Linearity of Graph is not appropriate (Just a conceptual distribution) Flexibility (Dynamic) Inflexibility (Static) Complexity (Time-Required for 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

16. 16 Abbas Siddiqui, University of Kaiserslautern Extra Slides

17. 17 Abbas 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)

18. 18 Abbas Siddiqui, University of Kaiserslautern Classification of Requirements (1/2)

19. 19 Abbas Siddiqui, University of Kaiserslautern Classification of Requirements (2/2)

20. 20 Abbas Siddiqui, University of Kaiserslautern Template Description Language Composition is performed by connections tag defined in the language

21. 21 Abbas 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)

22. 22 Abbas 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