University of Kaiserslautern, Germany Department of Computer Science Integrated Communication Systems ICSY SONATE Euro-NF PhD Course University of Kaiserslautern 06 March 2012 Dr. Bernd Reuther

2 Bernd Reuther, University of Kaiserslautern Outline  Project Beyond-IP  Project DANCE  Motivation  Terminology: Service, …  Abstraction of communication protocols  SONATE  Problem statement and goals  Overview of Basic Concepts  Building Block Interface  Service Selection  Service Composition

 Considered Problem  Approach  Conclusion Project Beyond-IP

4 Bernd Reuther, University of Kaiserslautern Considered Problem  ATM (Asynchronous Transfer Mode) a “new” technology with many new properties  Several service classes (CBR,VBR,UBR,ABR)  Bandwidth reservation  Virtual Channels in Virtual Paths on top of physical infrastructure  Connection oriented  New address types for hosts and services  Applications were design for TCP/IP  ATM was used as “just another Layer-2 technology” → Nearly no application was able to utilize ATM features

5 Bernd Reuther, University of Kaiserslautern Approach  A common interface for accessing TCP/IP as well as ATM networks  Superset of the BSD socket API  A layer on top of ATM emulating TCP/IP behavior  A protocol for reliable transfer like TCP  Emulating TCP and UDP behavior Transparent connection establishment for UDP behavior A Protocol for emulating TCP Halfclose Rebuild Nagles Algorithm for TCP behavior Interception of socket options and manage parameters  An extension of the socket API for QoS request  Use if ATM is available  Ignore if IP is used  Mapping of addresses using DNS, and a proprietary approach for port-numbers  Protocol selection: use ATM if available locally and the remote site has registered an ATM-Address with DNS

6 Bernd Reuther, University of Kaiserslautern Conclusion  Achievement:  Running native TCP/IP application on top of ATM possible  But:  Several proprietary protocols required  Still not all ATM features supported  No motivation to create native ATM applications  Imitate functionality of “standard” protocols is no appropriate evolution path  No incentive for application developers to support “new protocols”  Is costly because of emulating “all specific details” of old protocols

 Motivation  Terminology: Service, …  Abstraction of communication protocols  Application of the SOA paradigm  Service description  Brokering and configuration of services Project DANCE

8 Bernd Reuther, University of Kaiserslautern Project DANCE  Generalize Problem of Beyond-IP Project:  New (transport) protocols require adaption of applications  Without users (applications) there is no incentive for innovation!

9 Bernd Reuther, University of Kaiserslautern Innovation within Transport and Network Protocols  Innovation in the Internet  New Applications  New Network-Technologies  Few innovation within transport and network protocols  Extensions were possible only if they are transparent for users and other systems  Alternatives are available  The problem is to implement new developments in practice and not the development itself! Applications Transport and Network Protocols Network Technologies Innovation is the implementation of new technical or organizational developments* (Schumpeter, 1934) * Original cite is German: Innovation ist die Durchsetzung einer technischen oder organisatorischen Neuerung.

10 Bernd Reuther, University of Kaiserslautern Considered Problem  Why is it so hard to implement new technical developments of transport and network protocols?  Precondition: Benefit of new development > effort of implementation  Problem: enormous effort is required  Tight coupling of applications and transport protocols  Limited availability of new protocols

11 Bernd Reuther, University of Kaiserslautern Reason 1: Tight Coupling  Today application are tightly coupled to protocols  Because of the BSD Socket Interface, e.g.: Specification of the protocol type Address types are not transparent (e.g. port numbers) Connection less and connection oriented behavior is not transparent Protocol options (TCP_NODELAY, TCP Window Scaling)  Because of application logic, e.g.: When taking into account the Maxium Transfer Unit (MTU) for UDP/IP When using TCP „halfclose“ for End-of-File signaling  Applications have to be adapted to new protocols! Reality: few applications support “new protocols”

12 Bernd Reuther, University of Kaiserslautern  Application design  Protocol independent BSD Socket API  Selection of protocols by applications  Protocol options (and thus optimization) not applicable  Middleware provides abstraction of communication protocols  Specialized for certain application classes, many MW exists  Technically usually part of applications Application Avoid tight coupling today? Application Middleware Communication System Middleware

13 Bernd Reuther, University of Kaiserslautern Reason 2: Limited Availability  Some functionalities are not available everywhere  Stepwise introduction of for example: IPv6 Explicit Congestion Notification (ECN) SCTP, UDPLite, DCCP,...  Limitations exist even for established functionality Blocking UDP or ports ≠ 80 NATs are blocking server  Applications must decide which (new) protocols may be used! Reality: use commonly available protocols, e.g. TCP Port 80 or HTTP

14 Bernd Reuther, University of Kaiserslautern Goal of DANCE Applications should benefit of new technical developments in networks, without the need to adapt applications. Steps:  Achieve abstraction of protocols: „Use communication services instead of protocols “  Autonomous selection and configuration of Transport Service Provider (TSP) at runtime Transport Service Provider (TSP) = protocol stack (OSI terminology)

Common terms:  Service, Mechanisms, Techniques “Our” terms:  Service Elements  Service Description  Communication Services Terminology

16 Bernd Reuther, University of Kaiserslautern Services, Mechanisms, Techniques Service (the visible effects) Mechanisms (algorithms / protocols) Code (bits & bytes) implement Example: reliable transfer of a byte stream Example: TCP Example: Linux Kernel-Modul for TCP A „service“ denotes an abstraction level (like in the ISO/OSI model). abstraction

17 Bernd Reuther, University of Kaiserslautern Service Roles Ambiguous use of the term “service” in informatics  Service instance  Algorithms and resources  Service result  Immaterial benefit  Abstraction of Mechanisms  Interface  Defines communication

18 Bernd Reuther, University of Kaiserslautern Service Description  Mapping between Mechanism and Service  Approaches for descriptions  Mechanisms + Interface resulting in a unique service  Service + Interface may by implemented by several mechanisms → need to select appropriate mechanisms Mechanisms Services 1 n

19 Bernd Reuther, University of Kaiserslautern Communication service The major benefit of a communication service is the transport of data. Describe a communication service by: Type of data to be transported Endpoint entities involved Properties of data exchange Assume: There is one generic interface for all communication services

 Key-functionality  1. Service description  2. Brokering and configuration of services  3. Interface Project DANCE Abstraction of communication protocols

21 Bernd Reuther, University of Kaiserslautern Interface Principles Application Protocol Stack BSD Socket API data control BSD Socket Interface Application Protocol Stack Broker SOCS SPI Requirements Offerings data control SOCS API Service Oriented View

22 Bernd Reuther, University of Kaiserslautern b) Service brokering 3 3 SOA-Paradigm  Support of three key functionalities Service User Service Provider Service Broker a) Service description c) Interface

23 Bernd Reuther, University of Kaiserslautern A service oriented Approach for Abstraction of Communication Protocols in the Internet 1.Description of offered services 2.Description of requested services 3.Broker result 4.Configuration of TSP 5.Utilization

24 Bernd Reuther, University of Kaiserslautern Key-Functionality: Service description Service User Service Provider Service Broker a) Service description

25 Bernd Reuther, University of Kaiserslautern Steps of Service Brokering Set of all appropriate Service offerings Ordered list of Service offerings Mandatory requirements Wanted requirements Set of all Service offerings Set of all available Service offerings Service usage Preconditions+ dynamic data

26 Bernd Reuther, University of Kaiserslautern Service Description  A communication service S is defined as a set of properties E i : S = {E 1,..., E n }  Extendable  Types of properties (inherent and qualitative) support the service brokering  Inherent properties (mandatory / guaranteed)  Determine appropriate services  Example: supported data or address types, upper or lower bounds for MTU, costs or loss rate  Qualitative Properties (wanted / rating)  Determine ordering of service according to rating  Example: quality of cost level, quality of loss rate, efficiency

27 Bernd Reuther, University of Kaiserslautern Attributes of Inherent Properties  Unique identification of a property E i using a URI  Bsp:  Optional: absolute boundaries  In requirements lb R lower boundary, ub R upper boundary Semantic with E i valid for x  In offerings lb O lower boundary, ub O upper boundary Semantic with E i valid for x  An offering is appropriate if:

28 Bernd Reuther, University of Kaiserslautern Attributes of Qualitative Properties  Unique identification of a property E i using a URI  Bsp:  Relative rating  In requirements Weights of properties E i Relative rating of properties  In offerings Quality of a property E i of a TSP k Relative rating of TSP regarding one specific property  Quality of an offering: → w i determined by application developers → q i,k determined by …

29 Bernd Reuther, University of Kaiserslautern Determine the Quality of an Offering  Subjective method: q i,k „defined by experts“  Objective method based on benchmarks  Benchmark B i is neutral, delivers measurements Used to compare TSP, no prediction  Interpreting measurements by Offerings must specify an interpretation f Requirements may specify an alternative interpretation f´ rating Quality q Specific measure

30 Bernd Reuther, University of Kaiserslautern  A service provider (TSP) may offer many services  Depended on environment, e.g. available bandwidth  Configuration (Service-Options)  Preconditions test if a service provider is applicable or if Service- Options are applicable Environmental data Description of Service Provider Basis Service User Endsystem Network Configuration Service-Option Service

31 Bernd Reuther, University of Kaiserslautern Key-Functionality: Brokering and configuration of services b) Service brokering Service User Service Provider Service Broker a) Service description

32 Bernd Reuther, University of Kaiserslautern Brokering of Services  For all service providers determine an optimal service configuration  Assume: there are “few” service providers (TSP)  Selection of Service-Options ( SO ) per service provider  Problem: 2 n possibilities for {SO 1,..., SO n } Permutation are irrelevant  Dependencies of Service-Options SO i among each other Independent Semantically dependent → must be specified explicitly Implicitly dependent, i.e. mutual influence of ratings → will be recognized automatically

33 Bernd Reuther, University of Kaiserslautern Selection of Service-Options Estimate effect of worst: best: IF THEN do not apply : IF AND not semantically depended to any THEN apply : FOR EACH INITIALZE 1. Sequential testing of applicability of SO 2. Test remaining combination of SO

34 Bernd Reuther, University of Kaiserslautern Performance Example: best case, independent SO max. ~ 0,6ms Plattform: 1 Core 2,44 Ghz CPU Linux Timer: High resolution Per process No dependencies Number of Service-Options Time needed for brokering [µs]

35 Bernd Reuther, University of Kaiserslautern Performance Example: worst case, only dependent SO max. ~ 200ms Plattform: 1 Core 2,44 Ghz CPU Linux Timer: High resolution Per process Time needed for brokering [µs] Number of Service-Options No dependencies Dependencies among all Service-Options

1.Problem statement and goals 2.Overview of Basic Concepts 3.Building Block Interface 4.Service Selection 5.Service Composition SONATE Service oriented Network Architecture

 Problem Statement  Implementing new developments  Goals of the SONATE approach SONATE 1. Problem statement and goals

38 Bernd Reuther, University of Kaiserslautern Problem Statement It is hard to integrate new mechanisms into the current Internet (and even harder to change existing ones) Cause:  Many implicit dependencies (i.e. tight coupling) between existing mechanisms  The problem is not limited to specific protocols or mechanisms  It is an architectural issue!

39 Bernd Reuther, University of Kaiserslautern Implementing new developments  Extendable protocol header  Application Level Framing  New Layers  Dynamic composition of building blocks  Not available today  Issue of: Future Network research

40 Bernd Reuther, University of Kaiserslautern Goal  A future network architecture should be flexible:  Long term flexibility: Support evolution of networks  Short term flexibility: Dynamically adapt to requirements and constraints

41 Bernd Reuther, University of Kaiserslautern Long Term Flexibility  Support evolution of networks  Enable: stepwise introduction of new functionality  Easy introduction of new functionality without being dependent on agreements with vendors / providers Reasons: Enable utilization even of highly specific or experimental functionality Reduce time to market Opportunity even for small companies to provide (network-) services  Of course standardization is still required

42 Bernd Reuther, University of Kaiserslautern Short Term Flexibility  Dynamic adaption of Networks to  Requirements of current application, e.g. Different behavior for regular or emergency phone calls  Current network constraints, e.g. Mobile or wired network access A Network may require to use authentication, when prioritization is requested  Capabilities of currently involved nodes Adapt to supported functionality. This is important to utilize new functionality

 Building Blocks  Protocol-Graphs  SONATE Framework  Signalling Protocol-Graphs SONATE 2. Overview of Basic Concepts

44 Bernd Reuther, University of Kaiserslautern Building Blocks  Functionality is provided by self-contained building blocks (BB)  Protocols (e.g. flow-control, retransmission or a video codec)  Other functionality (e.g. monitoring or lookup services)  BB have generic and well-defined interfaces #17 BB Description (XML) → the service, what application and other BB „see“ BB identifier → reference the mechanism, communicating parties must use the same protocol BB impementation → local code

45 Bernd Reuther, University of Kaiserslautern Protocol-Graph  Interaction of BB is defined by a protocol-graph description  Order of building blocks  Possible data exchange  Descriptions can change easier than code  Placement of a functionality is not fixed Building Blocks & Protocol-Graph-Descriptions → Foster long term flexibility Building Blocks & Protocol-Graph-Descriptions → Foster long term flexibility

46 Bernd Reuther, University of Kaiserslautern Framework  Protocol-graph processing  Management of BB  Interfaces implemented as building blocks Repository of building blocks Msg1Msg2Msg3 Timer, Events, debugging support, … From previous node To successor node Management Physical or virtual link P-Graph Engine To Application receivesend From Application Msg1’Msg3’Msg2’

47 Bernd Reuther, University of Kaiserslautern Selection & Composition  Create Protocol-Graph descriptions  Select building blocks to be used  Compose (connect) building blocks  Adapt to (current) requirements and constraints Selection & Composition Application: Requirements Network: Constraints …

48 Bernd Reuther, University of Kaiserslautern Signal Protocol-Graphs  Be independent of Selection & Composition algorithms  Intermediate nodes may  alter workflows, i.e. act as gateways  provide feedback, i.e. request different behavior InitiatorNext Node Msgs Selection & Composition Framework Msgs Gateway Node Selection & Composition Framework Msgs Functional Composition & Processing of Workflow-Descriptions → Foster short term flexibility Functional Composition & Processing of Workflow-Descriptions → Foster short term flexibility

49 Bernd Reuther, University of Kaiserslautern Protocol-Graph Signaling Considerations  Similar to Protocol-IDs used in layering  Many BB (nodes) and description of connections (edges) result in more complex description  Use heuristics to minimize signaling data  List BB identifiers  Define default connections, list exceptions only Based on sequence of BB list (up – down) Based on data types  Efficient (flat) numbering of ports in an graph BB1.Port1 → 1, BB1.Port2 → 2, BB2.Port1 → 3, …

 Building block interaction  Ports  Connections  Threading SONATE 3. Building Block Interface

51 Bernd Reuther, University of Kaiserslautern Building block interaction (1)  BBs are self-contained, i.e. must not use implementation details of other BBs  A framework must manage data transfer between BBs  Incoming data (usually) triggers activity  Data flow and threading is related  Building blocks need to distinguish the meaning of data  Example: AES256 building block Is the data plaintext, ciphertext or the key? What should the building block do with it? Where to send the result?  Attach „meaning tag“ to data?  Meaning is building block specific  Meaning does not depend on data type  Better: use different „Ports“ to distinguish meaning of data

52 Bernd Reuther, University of Kaiserslautern Building block interaction (2) AES256 plaincrypt key

53 Bernd Reuther, University of Kaiserslautern Port details  Ports can be used to communicate  Arbitrary data types possible  Simple or standardized typed should be used  MessageList: default data type for networking data  Contains a list of „fields“ (byte arrays)  Field 0 used for payload  Can be (de)serialized to send over network or to apply transformations  Data types must match  Framework will only do simple conversions

54 Bernd Reuther, University of Kaiserslautern Building Block Connections and Scope  Building blocks are hidden  BBs only see connections, not what‘s behind  Rest of the graph is hidden  Connections are enumerated  Allows to distinguish different partners Building block updown value other Building block Building block scope ?

55 Bernd Reuther, University of Kaiserslautern Threading (1)  Threading is needed  Parallel streams  Parallel activities within a protocol-graph  When to do threading?  One thread per BB inefficient  How to synchronize threads?  Different BBs need different synchronization paradigms  Framework should not define paradigm  Leave it to the building blocks  „Filters“

56 Bernd Reuther, University of Kaiserslautern Threading (2)  Filters  Part of the port  Are called when messages come in  Filter called by the sender  No unnecessary thread change  Code defined by the receiver  Can implement any synchronization paradigm (Queuing, Blocking)  Can inspect messages before switching threads  Can simply „use“ the calling thread to circumvent threading Building block Port Filter Sender thread Receiver thread Message

 Service selection motivation  Steps of service selection  Analytical hierarchy process SONATE 4. Service Selection

58 Bernd Reuther, University of Kaiserslautern Service Selection Motivation (1)  Selection & Composition Approaches  Manually (supported by tools)  Templates (predefined structure, delayed completion)  Evolutionary algorithms (automatic but time consuming process)  Compose few coarse grain modules / partial protocol-graphs  Compose fine grained building blocks  …

59 Bernd Reuther, University of Kaiserslautern Service Selection Motivation (2)  Trade off: time available vs information available  Design time: Info: general requirements and protocols are known Time: Nearly arbitrary time available  Deployment time: Info: also system constraints are known Time: Several seconds available  Run time: Info: also user requirements are known and available resources may be known Time: should not exceed ~ 100ms  Approaches differ regarding  Flexibility  Quality of results  Effort for calculation  It is unlikely that one approach is always optimal

60 Bernd Reuther, University of Kaiserslautern Support several Protocol-Graph „generators“ Application Requirements Conventional TCP/IP UDP/IP SCTP/IP … Conventional TCP/IP UDP/IP SCTP/IP … Compound Template S&C … Service Broker Offerings Network Abstraction API Selected Service Requirements Workflow generators Access SONATE Framework Similar to selecting a protocol stack, but generators may take some time → define time limitations

61 Bernd Reuther, University of Kaiserslautern Steps of Service Selection Set of all possible Service offerings Set of all available Service offerings Mandatory & Wanted Requirements Service Composition Set of all appropriate Service offerings Mandatory requirements Check mandatory requirements Service usage Ordered list of Service offerings Wanted requirements Multi-criteria decision

62 Bernd Reuther, University of Kaiserslautern Multi-Criteria Decision Analysis  Selecting a service by comparing more than one criteria is a multi-criteria decision making problem  For solving such a problem, Multiple Criteria Decision Analysis (MCDA) methods exist  Several algorithms (MAUT, AHP, ELECTRE III, Evamix) exist for doing this  Analytical Hierarchy Process (AHP) allows interdependent criteria  Checking consistency of evaluation measures  AHP must be adapted for automatic service selection  Was designed for human decision processes

63 Bernd Reuther, University of Kaiserslautern Service Selection: AHP Fig. Analytic Hierarchy Process (AHP) Absolutely More Absolutely Less or Moderately Less Moderately More Equal Fig. Pairwise comparison scale

64 Bernd Reuther, University of Kaiserslautern Service Selection: Usage of AHP  AHP in service description and selection  Input: a set of effects Requirements: importance of effects Offerings: level of “quality”  Requirements Importance of effects given by application Defined pairwise  Offerings Effects should be measured in well defined scenario Mapping of measured values to level of “quality”  Defines an interpretation of what is “good” and what is “bad”  Output A service with the highest priority value

65 Bernd Reuther, University of Kaiserslautern Mapping of measured values  The mapping must be generic  The mapping must be monotonic  A linear mapping is in general not adequate  Use monotonic interpolation/extrapolation  Enable simple as well precise mapping functions  Mapping parameters are part of requirements specification Fig. Values in terms of hints +/ Hints Measured value Priority

 Manual composition  Evolutionary algorithm  Template approach  Early definition of partial protocol graphs  Service Description per BB Required SONATE 5. Service Composition

67 Bernd Reuther, University of Kaiserslautern Evolutionary algorithm (1)  Evolutionary algorithms 1.Create new solutions by mutating existing ones 2.Rank solutions using a metric 3.Retain only the best solutions 4.Got back to 1.  Can handle NP hard problems  Main issues when applied to protocol-graphs  How to evaluate a protocol graph?  How to mutate a protocol graph?  Building block interaction model needed  Calculate expected effects of building blocks  Part of BB description  Or as functions of BBs

68 Bernd Reuther, University of Kaiserslautern Evolutionary algorithm (2)  Generators  Create preliminary solutions  Used to fill the solution pool  Improvement cycle  Create new solutions by mutation  Try to fix mistakes  Retain only the best solutions  Runs very fast, thousands of cycles possible per second  Termination criteria  Target quality  Number of improvement cycles  Limited time  Combinations possible

69 Bernd Reuther, University of Kaiserslautern Template Based Composition  Protocol-Graph with place- holders instead of Building Blocks  Split Composition between design- and run-time  Composition at design-time  Selection of implementation at run-time  Place-Holder examples  Codecs or Encryption mechanisms Required “strength” Availability of codecs  Functionality for reducing loss Codecs sensibility to loss Type of access network Template Place-Holders

70 Bernd Reuther, University of Kaiserslautern Place-Holder  Well-defined ports  Defines provided effects  Defines allowed data types  Place-Holder also acts as container  Enabling and Disabling a functionality at runtime  Provide generic ports (e.g. monitoring, administration) Type: bin data Effects: loss =0, MTU’ = MTU-16 Type: bin data Type: avg_loss rate (optional) Type: on/off

71 Bernd Reuther, University of Kaiserslautern Requirements Domain (e.g. Telephony) Application Template Description API Selection of Template Requirement Description + Policies Selection of BB(s) to fill Placeholder(s) Domain specific templates Pool of BB

72 Bernd Reuther, 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

73 Bernd Reuther, University of Kaiserslautern Service Description per BB Required  Similar to descriptions of communication services  Describe modification of a Service  Describe modification of Parameters / Requirements  Determine effects analytically or by measurements ARQ avgLossRate <= 0,1% avgLossRate’ = 0,0% ARQ avgPacketRate = 50/s

Integrated Communication Systems ICSY University of Kaiserslautern Department of Computer Science P.O. Box 3049 D Kaiserslautern Dr. Bernd Reuther Phone:+49 (0) Fax:+49 (0) Internet: