Paul Mueller Integrated Communication Systems Lab Dept. of Computer Science University of Kaiserslautern Paul Ehrlich Bld. 34, D Kaiserslautern, Germany Tel , Fax FutureNetworkArchitectures Introduction to future network Architectures Kaiserslautern 05/03/2012

2 Paul Mueller, University of Kaiserslautern The challenge … We can't solve problems by using the same kind of thinking we used when we created them.

3 Paul Mueller, University of Kaiserslautern A really good idea can be recognized by the fact that its realization seems impossible in the first place

4 Paul 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)

5 Paul Mueller, University of Kaiserslautern What is the Right Glue? Content The Service Paradigm The Internet Ecosystem Communication Workflows First answer

6 Paul Mueller, University of Kaiserslautern Internet ecosystem applications economy society/ politics 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 architecture Network Architecture

7 Paul Mueller, University of Kaiserslautern The Internet evolution … P2P telnet WWW MPLS mPλS Wireless QoS Mobile GMPLS IPTV demands capabilities what is the right glue ? … first answer …… but over time …

8 Paul Mueller, University of Kaiserslautern Problem statement Problem: It is hard to integrate new mechanisms into 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!

9 Paul 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 ):  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“

10 Paul 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.

11 Daniela 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

12 Paul 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

13 Paul 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

14 Paul 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

15 Paul 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

16 Paul 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 / 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 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

17 Paul Mueller, University of Kaiserslautern Basic Concepts A Spiral Approach  Develop an architecture for future networks including (according to ANSI/IEEE Std ) :  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

18 Paul 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 Loose coupling achieved by: Building Blocks & Workflow- Descriptions Foster long term flexibility

19 Paul Mueller, University of Kaiserslautern Framework  Workflow processing  Management of BB  Interface to application and network Repository of building blocks Msg1Msg2Msg3 Events Handler & Timers Events Handler & Timers From previous node To successor node Shared Data Structures Physical or virtual link Workflow Engine To Application receivesend From Application Msg1’Msg3’Msg2’

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

21 Paul 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 InitiatorNext Node Msgs Selection & Composition Framework Msgs Gateway Node Selection & Composition Framework Msgs Dynamic adaption achieved by: Run Time Selection& Composition & Run Time processing of Workflow- Descriptions Foster short term flexibility Dynamic adaption achieved by: Run Time Selection& Composition & Run Time processing of Workflow- Descriptions Foster short term flexibility

22 Paul 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 MPLS mPλS Wireless QoS Mobile GMPLS IPTV demands capabilities

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

24 Paul 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

25 Paul 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

26 Paul 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