Future Network Architectures Introduction to future network Architectures

Paul Mueller Integrated Communication Systems Lab

Dept. of Computer ScienceUniversity of Kaiserslautern

Paul Ehrlich Bld. 34, D-67663 Kaiserslautern, Germany Tel.+49 631 205 2263, Fax. +49 631 205 3056

www.ICSY.de

FutureNetwork Architectures

Introduction tofuture networkArchitectures

Kaiserslautern 05/03/2012

2Paul Mueller, University of Kaiserslautern

The challenge …

We can't solve problems by using the same kind of thinking we used when we created them.


A really good idea can be recognized by the fact that its realization seems impossible in the first place


The Current Internet is governed by the following design principles:

- Modularization by relaxed layering - Connectionless datagram forwarding - Network of collaborating networks

(Interconnection via gateways services)- End to end principle/fate sharing principle

combined with intelligent end systems (user stateless network)

- Simplicity principle - Loose coupling principle - Locality principle (local cause(s) shall result in

local effects)


What is the

Right Glue?

Content

The Service Paradigm

The Internet

Ecosystem

CommunicationWorkflows

Firstanswer


Internet ecosystem

applications

economyso

ciet

y/

polit

ics

technology

• Huge innovations in applications– the Web– File sharing / overlays– VoIP, Triple play, …

• Ossification of the core protocolls

• Permanent evolution of the underlying technologies– Wireless / mobile– All over ethernet– Optical

– …the future is Web2.0/3.0 …

– … the future is optical/mobile …

• Internet core architectureNetworkArchitecture


The Internet evolution …

P2P

telnet

WWW

eMail

MPLS mPλS

Wireless

QoS

Mobile

GMPLS

IPTV

dem

ands

capa

bilit

ies

what is the right glue ?

… first answer …… but over time …


Problem statement

Problem:It is hard to integrate new mechanisms

into the current InternetCause:

- lots of implicit dependencies, i.e. tight coupling

- The problem is not limited to specific protocols or mechanisms

It is an architectural issue!


We are talking about architecture …

Generic definition of the term architecture:- The art and science of designing and modeling structures

In computer science, architecture is the(adopted from: ANSI/IEEE Std 1471-2000):- fundamental organization of a system- relationship of components (to each other and environment)- design and evolution principles

Question for dynamic software systems?- how much system specific information (functionality, environment,

usage, ... ) must or should be considered by an architecture ? • some information must be considered• too much specific information might cause inflexible systems

We assume the Internet as a

„largely distributed software system“


The Internet: A Distributed (SW)System

Basic idea: apply SE methods for designing a new software architecture for the Internet core:- Apply SOA principles* to communication

systems (requires new techniques) - A communication system made of loosely

coupled services (functionalities) A communication system based on the

SOA paradigm:- Service should be self-contained- Define explicit interfaces and interaction

between elements of the architecture Minimize assumptions about other services

Dynamically interacting services replace the concept of layers * Don‘t equate SOA with Web Services. SOA is an approach to

designing systems, Web services is an implementation technology.

11Daniela Fleuren, University of Kaiserslautern

Service Approach for the Future Internet

Avoid complex protocols- There is no need to bundle

functionality that might be used independent of each other

- Protocol decomposition to micro protocol is not new, e.g.• Dynamic Network Architecture

(O’Malley & Perterson)• Dynamic Configuration of

Light-Weight Protocols (Plagemann, Plattner, Vogt, Walter)

• …

… but …

The service approach is more general- Replacing implicit assumptions by

explicit references does not reduce functionality

Avoid to presuppose where some functionality is placed- The end-to-end argument postulates

that some functionality can only be implemented in end systems. But is the location of a functionality a principle that never changes?• Moors argues that the end-to-

end argument is mainly derived from trust and not from technical issues → what is acceptable depends on requirements!

- The architecture should not presuppose where some functionality is located, because this may change (but an application may do so).

- In consequence: a layered structure is no longer appropriate


The Service Paradigm: Reloaded

Data Link

Network

Transport

Session

Presentation

Physical

Overlay & Mediation

Application

Application Services Cloud

Mediation Services Cloud

Connectivity Services

Cloud

demands

capabilities

Service domains distinguish responsibilities for creating, maintaining and providing services- Application domain, represent services of

application developers, may be reused by other applications

- Mediation domain, map application demands to transport (connectivity) capabilities• represent services of network providers

(e.g. todays ISPs)- Connectivity domain, represent services

related to a specific transport technology (e.g. maintainer of an Ethernet-infrastructure, wireless or dark-fiber)

There is no fixed assignment of functionality to domains, e.g. routing may be implemented in the mediation or in the application domain


(Supposed) Types of Services

In general consider services to be elements of an architecture The term service implies a „result oriented view“ on such

elements, i.e. a very abstract view which is independent of its implementation- Interfaces must be designed careful!

Types of services- Related to application functionality, provides basic services that can

(and should) be reused by several application specific services, e.g. authentication, there is no need to implement services locally

- Related to network functionality but independent of specific flows, e.g. perform routing decision or lookup services, usually implemented by some local code (a local agent using distributed services is possible)

- Related to data transport, e.g. modify data or perform signaling, usually implemented by (micro-) protocols


The ICSY way: Proposed Solution

1. Enable add, change and remove of (network) functionality- Learn from software engineering- Apply concepts of Service Oriented Architectures (SOA)

2. Deal with heterogeneous network nodes(especially according available functionality)

3. Dynamically interacting services replace the concept of layers


The ICSY way: Goal

Find the right glue (a new architecture) between applications and the transport networks

A future inter networking architecture should be flexible:

- Long term flexibility:the capability of a system to evolve with updated protocols and network capabilities

- Short term flexibility:the capability of a system to adapt itself and react to network conditions and application requirements


Flexibility

Long Term Flexibility Support evolution of a new inter

networking architecture- 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 a new inter

networking architecture 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


Basic Concepts

A Spiral Approach

Develop an architecture for future networksincluding (according to ANSI/IEEE Std. 1471-2000) :- fundamental organization of a system- relationship of components (to each other and

environment)- design and evolution principles

Find and implement mechanisms enabling such an architecture- Improve insight of tackled problems- Proof of concept


Building Blocks and Workflows

Functionality is provided by self-contained building blocks (BB)- Micro-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

At last there is no difference between an application BB and network BB like access or routing.

Interaction of BB is defined by a workflow description- Order of building blocks- Possible data exchange

Descriptions can change easier than code

Placement of a functionality is not fixed

Loose coupling achieved by:

Building Blocks & Workflow-Descriptions

Foster long term flexibility


Framework

Workflow processing Management of BB Interface to application and network

Repository of building blocks

Msg1 Msg2 Msg3

Events Handler & Timers

From previous node

To successor nodeShared Data

Structures

Physical orvirtual link

Physical orvirtual link

WorkflowEngine

ToApplication

receive send

FromApplication

Msg1’ Msg3’Msg2’

20Daniela Fleuren, University of Kaiserslautern

Selection & Composition

Create workflow descriptions- At run time,

because then most Information is available (dynamic)

- Enable (re-)use of predefined workflow descriptions

- At design time, to create workflows for bootstrap (static)

Selection &Composition

Application: Requirements

Network: Constraints

…


Signal Workflows

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

Dynamic adaption achieved by:

Run Time Selection& Composition& Run Time processing of Workflow-

Descriptions

Foster short term flexibility


what is the right glue? our answer:

A set of basic functionalities which can be discovered and composed bring the service idea from very external into very inherent

P2P

telnet

WWW

eMail

MPLS mPλS

Wireless

QoS

Mobile

GMPLS

IPTV

dem

ands

capa

bilit

ies

Integrated Communication Systems ICSY

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

Prof. Dr. Paul Mueller

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

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


Status of the Approach (1)

The Framework

Generic interface of BB- Message, Value and Event passing

Infrastructure services- Timer- BB repository- Provision of node status (e.g.

name of a node, routing tables, …)- Management of known network

and application interfaces Instantiation of a workflow

- Compilation of Workflow-Description

Workflow processing

Currently available Building Blocks Application adapter Network adapter (using UDP

sockets) Switching Reliable transmission Loss detection Loss reduction Loop avoidance Error logging

There is an SDK for developing building blocks


Status of the Approach (2)

Selection & Composition Analysis of dependencies

among BB (not finished)- Impact on placement of

functionality- Impact on selection of

functionality Validation of workflows Qualitative measurement of

workflow Composition using a genetic

algorithm- Randomly modify a given

workflow- Fixing missing links

Selection & Composition open issues How to describe

- services of BB and workflows?- Application requirements and network

constraints?- Preliminary work on describing

communication services is available Further approaches for workflow

composition- Select one of predefined workflows

• This is like selecting a protocol stack

- Use templates and select key-functionality only• Means that the placement of

functionality is predefined- Compose workflow patterns

• Reuse common combinations of BB, i.e. reduces number of alternatives


The term “Service”

A unit of work done by a service provider to achieve desired end results for a service consumer. The results of a service are usually the change of state for the consumer but can also be a change of state for the provider or for both

Benefit: Loose coupling between the participating software agents, enabled by:

- A small set of simple and ubiquitous interfaces. - Descriptive messages constrained by an extensible schema delivered

through the interfaces. None, or only minimal, system behavior is prescribed by messages.

- Extensibility- Service discovery

Focus on exposing business functions, not technology

Documents

Future Network Architectures Introduction to future network Architectures