Future Network Architectures Introduction to future network Architectures

1. Future Network Architectures • Introduction to • future network • Architectures • Kaiserslautern 05/03/2012

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

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

4. The Current Internet is governed by the following design principles: • Modularization by relaxed layering • Connectionless datagram forwarding • Network of collaborating networks (Interconnection via gatewaysservices) • 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. Content The Internet Ecosystem What is the Right Glue? Communication Workflows First answer The Service Paradigm

6. Internet ecosystem • Hugeinnovations in applications • the Web • File sharing / overlays • VoIP, Triple play, … applications • …thefutureis Web2.0/3.0 … society/ politics economy • Ossificationofthecoreprotocolls • Internet core architecture NetworkArchitecture • Permanent evolution of the underlying technologies • Wireless / mobile • All overethernet • Optical technology • … thefutureisoptical/mobile …

7. The Internet evolution … … but over time … … firstanswer … IPTV demands P2P eMail WWW what is the rightglue ? Mobile capabilities telnet QoS Wireless GMPLS MPLS mPλS

8. 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!

9. Wearetalkingaboutarchitecture … • 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 Weassumethe Internet as a „largelydistributedsoftwaresystem“

10. The Internet: A Distributed (SW)System • Basic idea: apply SE methods for designing a new softwarearchitecture 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‘tequate SOA with Web Services. SOA is an approach to designing systems, Web services is an implementation technology.

11. 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. The Service Paradigm: Reloaded • 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 Application Services Cloud Application Overlay & Mediation Presentation demands Mediation Services Cloud Session Transport Network Connectivity Services Cloud capabilities Data Link Physical

13. (Supposed) Typesof 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. The ICSY way: Proposed Solution • Enable add, change and remove of (network) functionality • Learn from software engineering • Apply concepts of Service Oriented Architectures (SOA) • Deal with heterogeneous network nodes(especially according available functionality) • Dynamically interacting services replace the concept of layers

15. 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. Flexibility 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 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

17. 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

18. 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

19. Framework • Workflow processing • Management of BB • Interface to application and network ToApplication FromApplication Msg1’ Msg3’ Msg2’ Msg3 Msg1 Msg2 To successor node From previous node Workflow Engine receive send Events Handler & Timers Shared Data Structures Physical orvirtual link Physical orvirtual link Repository of building blocks

20. 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) Application: Requirements Network: Constraints … Selection &Composition

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

22. what is the right glue? our answer: IPTV demands • A set of basic functionalities which can be discovered and composed bring the service idea from very external into very inherent P2P eMail WWW Mobile capabilities telnet QoS Wireless GMPLS MPLS mPλS

23. Prof. Dr. Paul Mueller Phone: +49 (0)631 205-2263 Fax: +49 (0)631 205-30 56 Email: pmueller@informatik.uni-kl.de Internet: http://www.icsy.de

24. Status ofthe Approach (1) 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 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

25. Status ofthe 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. 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