SONATE Euro-NF PhD Course

University of Kaiserslautern, GermanyDepartment of Computer ScienceIntegrated Communication Systems ICSYhttp://www.icsy.de

SONATEEuro-NF PhD Course

University of Kaiserslautern06 March 2012

Dr. Bernd Reuther

2Bernd Reuther, University of Kaiserslautern

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

Considered Problem Approach Conclusion

Project Beyond-IP 1997-1999


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


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


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 2001-2003


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!


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 cite is German: Innovation ist die Durchsetzung einer technischen oder organisatorischen Neuerung.


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


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”


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

ApplicationApplication

Avoid tight coupling today?

Application

MiddlewareCommunication System

Middleware Middleware Middleware


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


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


Services, Mechanisms, Techniques

Service(the visible effects)

Mechanisms(algorithms / protocols)

Code(bits & bytes)

implement

implement

Example: reliable transferof a byte stream

Example: TCP

Example: Linux Kernel-Modulfor TCP

A „service“ denotes an abstraction level (like in the ISO/OSI model).

abst

ract

ion


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


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 Mechanisms

Services

1

n


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 2001-2003Abstraction of communication protocols


b) Service brokering

3

SOA-Paradigm

Support of three key functionalities

ServiceUser

ServiceProvider

ServiceBroker

1

2

a) S

ervi

ce d

escr

iptio

n

4

5

c) Interface


A service oriented Approach for Abstraction ofCommunication Protocols in the Internet

1. Description of offered services

2. Description of requested services

3. Broker result4. Configuration of

TSP5. Utilization


Key-Functionality: Service description

ServiceUser

ServiceProvider

ServiceBroker

a) S

ervi

ce d

escr

iptio

n


Steps of Service Brokering

Set of all appropriate

Service offerings

Ordered list of Service offerings

Mandatoryrequirements

Wantedrequirements

Set of all Service offerings

Set of all available Service offerings

Service usage

Preconditions+dynamic data


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


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:

],[ RR ublbx

],[ OO ublbx

],[],[ OORR ublbublb


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:

]1,0[iw

]1,0[,kiq

n

i kiiqw1 ,

→ wi determined by application developers

→ qi,k determined by …


Determine the Quality of an Offering

Subjective method: qi,k „defined by experts“ Objective method based on benchmarks

- Benchmark Bi 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´

)(, kiki TSPBQ

)( ,, kiki Qfq ]1,0[:)( xf

rating

Quality q

Spec

ific

mea

sure


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

BasisService

User

Endsystem

Network

Configuration

Service-Option

Service-Option

Service-Option

Service


Key-Functionality: Brokering and configuration of services

b) Service brokering

ServiceUser

ServiceProvider

ServiceBroker

a) S

ervi

ce d

escr

iptio

n


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


Selection of Service-Options

iSOminiSO max

iSOEstimate effect of

worst: best:

),(),( maxi

RR SOSSMSSM

iSO iSOOptionenOptionen \:IF

THEN do not apply :

iSO OptionenSO j

),(),( mini

RR SOSSMSSM

iSO ii SOOptionenOptionenSOSS \:;:

IF

AND not semantically depended to any

THEN apply :

OptionsSOi FOR EACH

},...,{:: 1 nSOSOOptionsServiceBasisS INITIALZE

1. Sequential testing of applicability of SO

2. Test remaining combination of SO


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

Tim

e ne

eded

for b

roke

ring

[µs]


Performance Example: worst case, only dependent SO

max. ~ 200ms

Plattform:•1 Core•2,44 Ghz CPU•Linux

Timer:•High resolution•Per processTi

me

need

ed fo

r bro

kerin

g [µ

s]

Number of Service-Options

No dependenciesDependencies among all Service-Options

1. Problem statement and goals2. Overview of Basic Concepts3. Building Block Interface4. Service Selection5. Service Composition

SONATEService oriented Network Architecture

Problem Statement Implementing new developments Goals of the SONATE approach

SONATE1. Problem statement and goals


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!


Implementing new developments

Extendableprotocol header

Application Level Framing

New Layers

Dynamic composition of building blocks- Not available today- Issue of:

Future Network research


Goal

A future network architecture should be flexible:

- Long term flexibility:Support evolution of networks

- Short term flexibility:Dynamically adapt to requirements and constraints


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


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

SONATE2. Overview of Basic Concepts


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


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


Framework

Protocol-graph processing Management of BB Interfaces implemented as building blocks

Repository of building blocks

Msg1 Msg2 Msg3

Timer, Events,debugging support, …

From previous node

To successor nodeManagement

Physical orvirtual link

Physical orvirtual link

P-GraphEngine

ToApplication

receive send

FromApplication

Msg1’ Msg3’Msg2’


Selection & Composition

Create Protocol-Graph descriptions- Select building blocks to be

used- Compose (connect)

building blocks Adapt to (current)

requirements andconstraints

Selection &Composition

Application: Requirements

Network: Constraints

…


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

Initiator Next Node

Msgs


Framework FrameworkMsgs

Gateway Node


FrameworkMsgsMsgs

Functional Composition& Processing of Workflow-Descriptions

→ Foster short term flexibility


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

SONATE3. Building Block Interface


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


Building block interaction (2)

AES256

plain

crypt

key


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


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

up

down

value

other Building block




Building block scope

?

1 2

3

4


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“


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

FilterSender threadReceiver thread

Mes

sage

Service selection motivation Steps of service selection Analytical hierarchy process

SONATE4. Service Selection


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- …


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


Support several Protocol-Graph „generators“

Application

Requirements

Conventional

TCP/IPUDP/IPSCTP/IP…

Compound Template S&C

…

ServiceBroker

Offerings

Network Abstraction API

SelectedService

Requirements

Workflow

generators

Access SONATE Framework

Similar to selecting a protocol stack,but generators may take some time→ define time limitations


Steps of Service Selection

Set of all possible Service offerings

Set of all available Service offerings

Mandatory & Wanted RequirementsService Composition

Set of all appropriate

Service offerings

Mandatoryrequirements

Check mandatoryrequirements

Service usage

Ordered list of Service offerings

Wantedrequirements

Multi-criteriadecision


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


Service Selection: AHP

Fig. Analytic Hierarchy Process (AHP)

Absolutely More

Absolutely Less

9753-1 or 1-3-5-7-9

Moderately Less

Moderately MoreEqual

Fig. Pairwise comparison scale


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


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

+/- 1

9

-9

HintsMeasured value

Prio

rity

Manual composition Evolutionary algorithm Template approach Early definition of partial protocol graphs

Service Description per BB Required

SONATE5. Service Composition


Evolutionary algorithm (1)

Evolutionary algorithms1. Create new solutions by mutating existing ones2. Rank solutions using a metric3. Retain only the best solutions4. 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


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


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


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 dataEffects: loss =0, MTU’ = MTU-16

Type: bin data

Type: avg_loss rate (optional)

Type: on/off


Requirements Domain

(e.g. Telephony)

Application

Template Description

API

Selection of Template

Requirement Description+ Policies

Selection ofBB(s) to fillPlaceholder(s)

Domain specific templates

Pool ofBB


Service Description per BB Required

Similar to descriptions of communication services

Describe modification of a Service

Describe modification ofParameters / Requirements

Determine effects analytically or by measurements

ARQavgLossRate <= 0,1%

avgLossRate’ = 0,0%

ARQavgPacketRate’ = 50+x/s

avgPacketRate = 50/s

Integrated Communication Systems ICSY

University of KaiserslauternDepartment of Computer ScienceP.O. Box 3049D-67653 Kaiserslautern

Dr. Bernd Reuther

Phone: +49 (0)631 205-2161Fax: +49 (0)631 205-30 56

Email: [email protected]: http://www.icsy.de

Date post:	23-Feb-2016
Category:	Documents
Upload:	liv
View:	53 times
Download:	0 times

SONATE Euro-NF PhD Course

Documents