1 / 22

PhD Topic Template Based Composition

This course explores advanced techniques for adapting the internet's current architecture to meet dynamic application demands. Emphasizing both short-term and long-term flexibility, we investigate methods to compose functional components on demand, facilitate protocol adaptation, and enable easy modifications in response to changing requirements. Key topics include design-time and run-time composition strategies, adaptability to QoS and QoE variations, and the use of placeholder abstractions. Join us to delve into innovative approaches that aim to overcome the limitations of existing internet frameworks.

brock
Download Presentation

PhD Topic Template Based Composition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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. FunctionalComposition • Decomposesstackinto so calledfine-grainfunctionality • Composing on demand • LikelyoptimizedSelectionof a functionality Application Requirements FunctionalComposition Protocol Graph Policies Offerings

  4. EpochsforFunctionalCompositionApproaches • 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. Template Based Composition Template • Place-holder: An Abstraction between implementation and a service • Composition at design-time • Selection of implementation at run-time Place-Holder

  6. 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. Requirements Description Application Requirements Domain Name Domain Based Policies API Template Description Selection of Template Selection of BB(s) to fill Placeholder(s)

  8. Tradeoffs in Selection & CompositionApproaches

  9. Complexity • Design-Time Composition • Likelytobeperformedmanuallywiththehelpof design tools • Run-Time Composition • Automaticcompositionrequiresrelativelycomplexalgorithm • Additional information (e.g. requirements, requirements, offerings) • ForoptimizedcompositionrequiredQoS, QoEparameters • Inerdepenciesresolution • Description ofMethods • Template BasedComposition • Nocomplexalgorithmforcomposition • NoInterdepenciesresolution • Processforselectionofsuitablemethod

  10. Information Availability • Design-Time Composition • Early binding, lack ofinformation (e.g. networkcapacity, delay, availableservices) • Noinclusionorexclusionof a functionality • Run-Time Composition • Late-binding • Chancesoffailure (i.e. missingrequired but insignificantinformationmayterminatetheprocess) • Template BasedComposition • Run-time informationforselectionof a functionality • No extra functionalitycanbeadded • Functionalitycanbedisabled • RelativelyhigherchancesofsuccessfulSC

  11. Adaptability • Design-Time Composition • Noadaptability , likelyconfigurabilityofcertainfunctionality • Slightestchange in a requirement will neednewprotocolgraph • UnabletoaccomodatevaryingQoS, QoE • Not suitablefor an enviromentwithrapidlycontextchanging • Run-Time Composition • Highlyadapatable • Template BasedComposition • GoodchoiceforchangingQoSandQoEparameter but nochangingthefunctionalities

  12. In Action • Design-Time Composition • Presence of BB + Inclusion in a composedstack • Not suitableforheterogenousenvironment • Run-Time Composition • Less time required (i.e. assoonasselctedby a SC algorithm) • Template BasedComposition • Readytobeusedassoonasadded in therepository

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

  14. 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. Linearity of Graph is not appropriate (Just a conceptual distribution) • Complexity • Information Availability • Adaptability • In Action Dynamic Composition (i.e. selection and composition at runtime) Flexibility (Dynamic) Template-Based Functional Composition (i.e. Composition at design-time and selection and runtime) Design-Time Composition (e.g. TCP/IP stack) (i.e. Selection and composition and design time) Inflexibility (Static) Complexity (Time-Required for Set-up a communication)

  16. Extra Slides

  17. 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. Classification of Requirements (1/2)

  19. Classification of Requirements (2/2)

  20. Template Description Language Composition is performed by connections tag defined in the language

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

More Related