1 / 72

SONATE Euro-NF PhD Course

SONATE Euro-NF PhD Course. University of Kaiserslautern 06 March 2012. Dr. Bernd Reuther. Outline. Project Beyond-IP 1997-1999 Project DANCE 2001-2003 Motivation Terminology : Service, … Abstraction of communication protocols SONATE Problem statement and goals

liv
Download Presentation

SONATE Euro-NF PhD Course

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. SONATEEuro-NF PhD Course University of Kaiserslautern 06 March 2012 Dr. Bernd Reuther

  2. Outline • Project Beyond-IP 1997-1999 • Project DANCE 2001-2003 • Motivation • Terminology: Service, … • Abstraction of communication protocols • SONATE • Problem statement and goals • Overview of Basic Concepts • Building Block Interface • Service Selection • Service Composition

  3. Considered Problem • Approach • Conclusion • Project Beyond-IP 1997-1999

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

  7. Motivation • Terminology: Service, … • Abstraction of communication protocols Application of the SOA paradigm Service description Brokering and configuration of services • Project DANCE 2001-2003

  8. Project DANCE 2001-2003 • Generalize Problem of Beyond-IP Project: • New (transport) protocols require adaption of applications • Without users (applications) there is no incentive for innovation!

  9. Innovation within Transport and Network Protocols • Innovation in the Internet • New Applications • New Network-Technologies • Few innovation within transportand 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 NetworkProtocols Network Technologies Innovation is the implementation of new technical or organizational developments* (Schumpeter, 1934) * Original citeis German: Innovation ist die Durchsetzung einer technischen oder organisatorischen Neuerung.

  10. 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. 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. Avoid tight coupling today? • 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 Application Application Middleware Middleware Middleware Middleware Communication System

  13. 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. 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)

  15. Common terms: • Service, Mechanisms, Techniques “Our” terms: • Service Elements • Service Description • Communication Services • Terminology

  16. Services, Mechanisms, Techniques A „service“ denotes an abstraction level (like in the ISO/OSI model). Service(thevisibleeffects) Example: reliabletransferof a bytestream implement Mechanisms(algorithms / protocols) Example: TCP abstraction implement Code(bits & bytes) Example: Linux Kernel-Modulfor TCP

  17. 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. Service Description • Mapping between Mechanism and Service • Approaches for descriptions • Mechanisms + Interface resulting in a unique service • Service + Interface may by implemented byseveral mechanisms→ need to select appropriate mechanisms Services 1 n Mechanisms

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

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

  21. SOA-Paradigm ServiceUser b) Service brokering 2 4 3 c) Interface a) Service description ServiceBroker 5 ServiceProvider 1 • Support ofthreekeyfunctionalities

  22. A service oriented Approach for Abstraction ofCommunication Protocols in the Internet • Description of offered services • Description of requested services • Broker result • Configuration of TSP • Utilization

  23. Key-Functionality: Service description ServiceUser a) Service description ServiceBroker ServiceProvider

  24. Steps of Service Brokering Set of all Service offerings Preconditions+dynamic data Set of all available Service offerings Mandatoryrequirements Set of all appropriate Service offerings Wantedrequirements Ordered list of Service offerings Service usage

  25. Service Description • A communication service S is defined as a set of properties Ei:S = {E1 ,..., En } • 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

  26. Attributes of Inherent Properties • Unique identification of a property Ei using a URI • Bsp: http://www.icsy.de/xml/SOCS/IProp/tp/MTU • Optional: absolute boundaries • In requirements • lbR lower boundary, ubR upper boundary • Semantic with Ei valid for x • In offerings • lbO lower boundary, ubO upper boundary • Semantic with Ei valid for x • An offering is appropriate if:

  27. Attributes of Qualitative Properties • Unique identification of a property Ei using a URI • Bsp: http://www.icsy.de/xml/SOCS/QProp/Loss • Relative rating • In requirements • Weights of properties Ei • Relative rating of properties • In offerings • Quality of a property Ei of a TSPk • Relative rating of TSP regarding one specific property • Quality of an offering: → wi determined by application developers → qi,kdetermined by …

  28. Determine the Quality of an Offering • Subjective method: qi,k„defined by experts“ • Objective method based on benchmarks • BenchmarkBi 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

  29. Description of Service Provider • 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 Service Configuration Environmental data BasisService Service-Option User Service-Option Endsystem Service-Option Network

  30. Key-Functionality: Brokering and configuration of services ServiceUser b) Service brokering a) Service description ServiceBroker ServiceProvider

  31. 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 {SO1 ,..., SOn} • Permutation are irrelevant • Dependencies of Service-Options SOi among each other • Independent • Semantically dependent→ must be specified explicitly • Implicitly dependent, i.e. mutual influence of ratings → will be recognized automatically

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

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

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

  35. Problem statement and goals • Overview of Basic Concepts • Building Block Interface • Service Selection • Service Composition • SONATE • Service oriented Network Architecture

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

  37. Problem Statement It is hard to integrate new mechanismsinto 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 limitedto specific protocols ormechanisms • It is an architectural issue!

  38. Implementing new developments • Extendableprotocol header • Application Level Framing • New Layers • Dynamic composition of building blocks • Not available today • Issue of:Future Network research

  39. Goal • A future network architecture should be flexible: • Long term flexibility:Support evolution of networks • Short term flexibility:Dynamically adapt to requirements and constraints

  40. 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 / providersReasons: • 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

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

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

  43. 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 BB Description (XML)→ the service, what application and other BB „see“ #17 BB identifier→ reference the mechanism, communicating parties must use the same protocol BB impementation→ local code

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

  45. Framework • Protocol-graph processing • Management of BB • Interfaces implemented as building blocks ToApplication FromApplication Msg1’ Msg3’ Msg2’ Msg3 Msg1 Msg2 To successor node From previous node P-Graph Engine receive send Timer, Events,debugging support, … Management Physical orvirtual link Physical orvirtual link Repository of building blocks

  46. Selection & Composition • Create Protocol-Graph descriptions • Select building blocks to be used • Compose (connect) building blocks • Adapt to (current) requirements andconstraints Application: Requirements Network: Constraints … Selection & Composition

  47. 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 Selection & Composition Selection & Composition Functional Composition& Processing of Workflow-Descriptions → Foster short term flexibility Framework Framework Framework Msgs Msgs Msgs Msgs Gateway Node Initiator Next Node

  48. 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, …

  49. Building block interaction • Ports • Connections • Threading • SONATE • 3. Building Block Interface

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

More Related