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.
3Paul Mueller, University of Kaiserslautern
A really good idea can be recognized by the fact that its realization seems impossible in the first place
4Paul Mueller, University of Kaiserslautern
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)
5Paul Mueller, University of Kaiserslautern
What is the
Right Glue?
Content
The Service Paradigm
The Internet
Ecosystem
CommunicationWorkflows
Firstanswer
6Paul Mueller, University of Kaiserslautern
Internet ecosystem
applications
eco
nom
ysoci
ety/
p
oliti
cs
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
7Paul Mueller, University of Kaiserslautern
The Internet evolution …
P2P
telnet
WWW
MPLSMPLSmPλSmPλS
WirelessWireless
QoSQoS
MobileMobile
GMPLSGMPLS
IPTV
dem
ands
capa
bilit
ies
what is the right glue ?
… first answer …… but over time …
8Paul Mueller, University of Kaiserslautern
Problem statement
Problem:
It is hard to integrate new mechanismsinto the current Internet
Cause:- lots of implicit dependencies, i.e. tight coupling
- The problem is not limited to specific protocols or mechanisms
It is an architectural issue!
9Paul Mueller, University of Kaiserslautern
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“
10Paul Mueller, University of Kaiserslautern
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
12Paul Mueller, University of Kaiserslautern
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
13Paul Mueller, University of Kaiserslautern
(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
14Paul Mueller, University of Kaiserslautern
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
15Paul Mueller, University of Kaiserslautern
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
16Paul Mueller, University of Kaiserslautern
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
17Paul Mueller, University of Kaiserslautern
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
18Paul Mueller, University of Kaiserslautern
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
19Paul Mueller, University of Kaiserslautern
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
…
21Paul Mueller, University of Kaiserslautern
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
Selection &Composition
Framework FrameworkMsgs
Gateway Node
Selection &Composition
FrameworkMsgsMsgs
Dynamic adaption achieved by:
Run Time Selection& Composition& Run Time processing of Workflow-
Descriptions
Foster short term flexibility
22Paul Mueller, University of Kaiserslautern
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
MPLSMPLSmPλSmPλS
WirelessWireless
QoSQoS
MobileMobile
GMPLSGMPLS
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
24Paul Mueller, University of Kaiserslautern
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
25Paul Mueller, University of Kaiserslautern
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
26Paul Mueller, University of Kaiserslautern
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