Future Network Architectures Introduction to future network Architectures

Future Network Architectures Introduction to future network Architectures Kaiserslautern 05/03/2012 Paul Mueller Integrated Communication Systems Lab Dept. of Computer Science University of Kaiserslautern Paul Ehrlich Bld. 34, D-67663 Kaiserslautern, Germany Tel. +49 631 205 2263, Fax. +49 631 205 3056 www. ICSY. de

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

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

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) Paul Mueller, University of Kaiserslautern 4

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

Internet ecosystem • Huge innovations in applications – – Network Architecture technology Paul Mueller, University of Kaiserslautern economy society/ politics applications the Web File sharing / overlays Vo. IP, Triple play, … …the future is Web 2. 0/3. 0 … • Ossification the core Internet coreofarchitecture protocolls • Permanent evolution of the underlying technologies – – Wireless / mobile All over ethernet Optical … the future is optical/mobile … 6

The… Internet evolution … but firstover answer time… … … demands IPTV P 2 P WWW what is the right glue ? e. Mail telnet Qo. S Wireless MPLS Paul Mueller, University of Kaiserslautern m. PλS GMPLS capabilities Mobile 7

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! Paul Mueller, University of Kaiserslautern 8

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 We assume the Internet as a (adopted from: ANSI/IEEE Std 1471 -2000): - fundamental organization of a system - relationship of components (to each other and environment) - design and evolution principles „largely distributed system“ Question forsoftware 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 Paul Mueller, University of Kaiserslautern 9

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 * Don‘t equate SOA with Web Services. SOA is an approach to the concept of layers designing systems, Web services is an implementation technology. Paul Mueller, University of Kaiserslautern 10

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 Daniela Fleuren, University of Kaiserslautern 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-toend 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 11

The Service Paradigm: Reloaded Service domains distinguish Application responsibilities for creating, maintaining and providing services Overlay & Mediation - - Application domain, represent services of application developers, may be reused by Presentation other applications Mediation domain, map application demands to transport (connectivity) Session capabilities • represent services of network providers Transport (e. g. todays ISPs) Connectivity domain, represent services Network related to a specific transport technology (e. g. maintainer of an Ethernetinfrastructure, wireless or dark-fiber) Data Link There is no fixed assignment of functionality to domains, e. g. Physical routing may be implemented in the mediation or in the application domain Paul Mueller, University of Kaiserslautern Application Services Cloud demands Mediation Services Cloud capabilities Connectivity Services Cloud 12

(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 Paul Mueller, University of Kaiserslautern 13

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 Paul Mueller, University of Kaiserslautern 14

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 Paul Mueller, University of Kaiserslautern 15

Flexibility Long Term Flexibility Short Term Flexibility Support evolution of a new inter Dynamic adaption of a new inter networking architecture to: - 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 Paul Mueller, University of Kaiserslautern - 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 16

Basic Concepts A Spiral Approach Develop an architecture for future networks including (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 Paul Mueller, University of Kaiserslautern 17

Building Blocks and Workflows Functionality is provided by selfcontained building blocks (BB) - Micro-protocols (e. g. flow-control, retransmission or a video codec) - Other functionality (e. g. monitoring or lookup services) Loose coupling BB have generic and well-defined interfaces Interaction of BB is defined by a workflow description achieved - Order ofby: building blocks - Possible data exchange Building Blocks & Workflow Descriptions can change Descriptions easier than code Placement Foster long term flexibilityof a functionality is not fixed At last there is no difference between an application BB and network BB like access or routing. Paul Mueller, University of Kaiserslautern 18

Framework Workflow processing Management of BB Interface to application and network To Application From Application Msg 1 Msg 2 Msg 3 From previous node receive Workflow Engine Events Handler & Timers send Shared Data Structures Msg 1’ Msg 2’ Msg 3’ To successor node Physical or virtual link Repository of building blocks Paul Mueller, University of Kaiserslautern 19

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) Daniela Fleuren, University of Kaiserslautern Application: Requirements Network: Constraints … Selection & Composition 20

Signal Workflows Be independent of selection & composition algorithms Intermediate nodes may - alter workflows, i. e. act as gateways - provide Dynamic feedback, i. e. adaption request different behavior achieved by: Run Time Selection& Composition Selection & & Run Time processing of Workflow. Composition Descriptions Foster short term flexibility Framework Msgs Initiator Paul Mueller, University of Kaiserslautern Framework Next Node Msgs Framework Msgs Gateway Node 21

what is the right glue? our answer: demands IPTV P 2 P WWW e. Mail telnet Qo. S Wireless MPLS m. PλS GMPLS capabilities Mobile A set of basic functionalities which can be discovered and composed bring the service idea from very external into very inherent Paul Mueller, University of Kaiserslautern 22

Prof. Dr. Paul Mueller Integrated Communication Systems ICSY University of Kaiserslautern Department of Computer Science P. O. Box 3049 D-67653 Kaiserslautern Phone: +49 (0)631 205 -2263 Fax: +49 (0)631 205 -30 56 Email: pmueller@informatik. unikl. de Internet: http: //www. icsy. de

Status of the Approach (1) The Framework Generic interface of BB Currently available Building Blocks Application adapter Network adapter (using UDP sockets) Infrastructure services - Timer Switching - BB repository Reliable transmission - Provision of node status (e. g. name of a node, routing tables, Loss detection …) Loss reduction - Management of known network Loop avoidance and application interfaces Instantiation of a workflow Error logging - Message, Value and Event passing - Compilation of Workflow. Description Workflow processing Paul Mueller, University of Kaiserslautern There is an SDK for developing building blocks 24

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 Paul Mueller, University of Kaiserslautern 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 keyfunctionality only • Means that the placement of functionality is predefined Compose workflow patterns • Reuse common combinations of BB, i. e. reduces number of alternatives 25

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 Paul Mueller, University of Kaiserslautern 26