Ranganai Chaparadza: Can Autonomicity help Migration, and what could be a possible Evolution Path?

Can Autonomicity help Migration, and what could be a possible Evolution Path? Ranganai Chaparadza ( Fraunhofer FOKUS ) {Ranganai.Chaparadza@fokus.fraunhofer.de; ran4chap@yahoo.com} Presentation at FIA-GHENT: Migration Session: 17 December 2010

Outline 1. The GANA Reference Model :  Standardizable Evolvable Architectural Reference Model for Autonomic Networking and Self-Management. A Blueprint of Design Principles for Autonomic Management and Control of Resources 2. How GANA can be applied for the Evolution of Network Protocols and Paradigms towards Self-Managing Multi-Service Networks of the Future (Future Internet). 3. Ongoing (pre)- Standardization Efforts

Key Building Blocks of an Autonomic/Self-Managing Network The Generic Autonomic Networking Architecture ( GANA ) GANA = An evolvable holistic Architectural Reference Model for Autonomic Network Engineering and Self-Management  1. A Hierarchical Autonomic Management and Control Architectural Framework  2. A Blueprint of Design Principles for Autonomic Management and Control of Resources

Today’s Management Paradigms versus the sought GANA Principles The known Restrictions of the state of the art and paradigm shift required for Self-management The Management Paradigms of today are based on the Relationship: NMS (Network Management System)  NE (Network Element) : No Manager  Managed-Entity Concepts and Relations and aspects at different levels of functionality abstractions, including within individual node/device architectures , down to the microscopic level of individual Protocols and System Functions. GANA defines management and manageability aspects at different levels of node/device and network functionality and introduces Autonomic Manager Components (Elements) that are designed following Hierarchical , Peering , and Sibling Relations among each other and are characterised by autonomic control of their associated Managed-Entities, and co-operate with each other in driving the Self-Managing features of the Network(s). Managed Entities (MEs) in GANA are not just physical Network Elements(NEs) but also include protocol modules, etc

Review of related approaches A review of today’s known approaches to Autonomic Networking EFIPSANS reviewed different approaches including clean-slate approaches (both pure and non-pure): such as, FOCALE, 4D, ANA, CONMan, Knowledge Plane for the Internet, etc, Non of these approaches proposes a holistic Reference Model that defines and distinguishes between diverse Autonomic Elements/Managers and their associated Managed-Entities (MEs) for different levels of abstractions within node/device architectures and network architectures. The required GANA Reference Model should define and fix the Levels at which to introduce Autonomic Elements/Managers in a holistic way . GANA Unifies within a single Holistic Framework , concepts from IBM-MAPE Model, 4D model, CONMan, FOCALE, Knowledge Plane for the Internet, GENI

The GANA Reference Model and Key Building Blocks of an Autonomic/Self-Managing Network

Generic Model of an Autonomic Networked System (with the “DE” as key Building Block )

High-Level State Transitions of a Decisions Element (DE)

The Generic Model can be applied at “4” different Levels of Abstractions The GANA fixes Four Basic Hierarchical Levels of abstractions for which Decision Elements (DEs), Managed Entities (MEs) and Control-Loops can be designed in GANA, with all DEs inter-working with each and forming the Decision-Plane of the network : GANA Level-1: Protocol Level (the lowest level) by which self-management is associated with the network protocol itself (whether monolithic or modular). There is growing opinion, however, that future protocols need to be simpler (i.e. with no decision logic embedded) than today’s protocols which have become too hard to manage due undesired emergent behaviour during operation and interaction with other protocols. This means, there is a need to rather implement decision logic at a level higher (i.e. outside the individual protocols)[ Refer to sources such as CONMan, 4D, etc.] GANA Level-2: Abstracted Network Functions (directly above the protocol(s)-level) that abstract some protocols and mechanisms associated with a particular network function e.g. routing, forwarding, mobility management, etc—whereby we can reason about autonomic routing, autonomic forwarding, etc. DEs at this Level are called Function-Level-DEs GANA Level-3: Node/Device Level— t he level of the node/device’s overall functionality and behaviour i.e. a node or system as a whole is also considered as level of self-management functionality. DEs at this Level are called Node-Level-DEs (Node-Main-DEs) GANA Level-4: Network Level –t he level of the network’s overall functionality and behaviour (the highest level). DEs at this Level are called Network-Level DEs .

Example illustration of Hierarchy, Peering and Sibling Relations between DEs (i.e. Control-Loops) at different GANA Levels The Interfaces depicted belong to the Decision Plane , and these interfaces call for standardized Specifications

Example “instantiation” of GANA DE(s) : Autonomic management and control for Routing Mechanisms ) in IPv6 Networks

Hierarchies of Network-Level-DEs, DE-to-DE interactions managing border relationships between different network technologies to assure services and maintain QoS

GANA Node Structure

Model of a Decision Element (DE)

Model of a Managed Entity(ME) at GANA’s lowest layer

CONMan: Simplify Protocols: Future Protocol Model [3]

Ongoing work on: Incorporating the CUBE Model [5] into GANA

Incorporating the CUBE Model [5] into GANA Ongoing work on:

Some of the Reference Points in GANA

Some of the Reference Points in GANA Reference Point : Rfp_NodeMainDE-to-NodeMainDE Reference Point : Rfp_FunctionLevelDE-to-FunctionLevelDE

The GANA has been “ instantiated ” and “ validated” by EFIPSANS, for autonomic management and control of different types of Managed Entities (Protocols, Stacks and Mechanisms at GANA’ lowest level/layer”) for diverse network environments (Fixed/Mobile/Wireless Networks): The instantiations mean specification and design of GANA DEs for a specific autonomic functionality and level of operation in the GANA Decision Plane Hierarchy ): Example cases and types of Networks: [ GANA instantiation for 3GPP/LTE/SAE ], [ GANA for autonomic management and control of IPv6 and the supporting lower layer Transport Protocols and Mechanisms in Wired Networks ]; [ GANA for other types of Networks and Devices …..] Examples (DEs for specific autonomic functionality and level of operation in the GANA Decision Plane Hierarchy): DEs for Autonomic Mobility Management, DEs for Autonomic QoS Management , DEs for Autonomic Routing , DEs for Auto-Discovery, Auto-Configuration/Self-Configuration , DEs for Autonomic Resilience and Survivability , DEs for Autonomic Fault-Management , DEs for Autonomic Monitoring , DEs for Autonomic Security Management . Experiences gained via the Instantiation of GANA in diverse networking environments

What is “ Generic ” in the GANA Reference Model What is implied by being “ Generic ” =: Specification and Description Models of the Building Blocks (Decision Elements) and Interfaces leave out the implementation-oriented details ; Fundamental Interfaces and Operations of the DEs must be generic to support different types of Data Models used later in the actual implementation ; The DEs that can be instantiated by design, for a particular network device/node, are decided upon by the context and role the device/node can play in the network.

GANA Mappings and implications to the TMN Logical Layered Architecture (LLA) , The FCAPS Framework in the GANA architecture, Network Governance , Service Management View, and the Use of Policies, Policy Frameworks, and Profiles in GANA, Virtualization in GANA, Knowledge Plane as part of the GANA Decision Plane , Cognition in GANA, Decision Notification in GANA for the “Human in the Loop”, Service Management and Network Management Levels Cooperation , The possibility of having Hierarchies of Network-Level-DEs , GANA and Network Management Systems (NMS’s) and the implications of evolutions, GANA and OSS’s and the implications of evolutions, Definitions of different types of Reference Points relevant in the evolved GANA, Federation in GANA, Fusing the GANA Concepts into the NGN to create an Autonomicity-enabled NGN. Evolution of the GANA Reference Model through ETSI AFI

IPv6 Basic enabling Features for Self-Managing Future Internet IPv6 offers a lot of rich communication features and extensible communication possibilities beyond what is available in IPv4. The following features in IPv6 can be considered as enablers for designing large-scale networks in which the basic attributes of scalability and some automated discovery and auto-configuration are required as enablers for more advanced autonomic/self-managing network behaviours : neighbor discovery, auto-configuration, support for dynamic network re-numbering, improved routing mechanisms, improved QoS (Quality of Service) handling, improved transport efficiency, improved security, F lexiblity for protocol extensions , support for large address space, advanced addressing schemes and route aggregation, true End-to-End communication, concepts for realizing “locator/identifier split”, Bootstrapping Mechanisms, etc. Validated Concepts from “ Clean-Slate” approaches can be used in the Evolution of IPv6 Protocols !!!!!!!!!!!!

Autonomic Management and Control of IPv6 Protocols, and EFIPSANS Proposed Extensions to IPv6 Protocols (IPv6++) Autonomic management and control of IPv6 protocols, stacks and mechanisms as so-called Managed Entities (MEs) at GANA’s lowest level/layer, is based on the assignment of specific IPv6 protocols and mechanisms to specific Decision Elements (DEs) that autonomically manage and regulate/control the behaviour of the different MEs. In EFIPSANS, some ideas on Extensions to IPv6 emerged: As early draft IPv6 Extension Headers (new IPv6 protocols that complement existing IPv6 protocols), Newly added protocol Options in the Extension Headers that support the notion of Options, Extensions to the “management interfaces” of some protocols for ensuring enriched access to the protocols and autonomic management and control of the protocols by associated Decision-Making-Elements (DMEs/DEs), and network architectural extensions such as cross-layering , etc. Examples of IPv6 protocol Extensions for self-managing networks being proposed by EFIPSANS include ICMPv6++ for advanced control information exchange, ND++ for advanced Auto-Discovery, DHCPv6++ for advanced Auto-Discovery and Auto-Configuration, PMIPv6++, IPv6 Extension Header for carrying advanced QoS Options , Other types of Newly added Options, some recommendations for Extensions to protocols like OSPFv3, and some newly proposed Extension Headers, etc.

Acknowledgement European Commission (EC)-funded FP7-IP Project Contract: INFSO-ICT-215549 EFIPSANS stands for: E xposing the F eatures in IP version S ix (IPv6) Protocols that can be exploited/extended for the purposes of designing/building A utonomic N etworks and S ervices. http://www.efipsans.org/

Thank You ……..!

References [1] [GANA Model]: R. Chaparadza, S. Papavassiliou, T. Kastrinogiannis, M. Vigoureux , E. Dotaro, A. Davy, K. Quinn, M. Wodczak, A. Toth: Creating a viable Evolution Path towards Self-Managing Future Internet via a Standardizable Reference Model for Autonomic Network Engineering. Published in the book by the Future Internet Assembly (FIA) in Europe: Towards the future internet - A European research perspective. Amsterdam: IOS Press, 2009, pp. 136-147. [2] [4D architecture] A. Greenberg et al, “A clean slate 4D approach to network control and management,” ACM SIGCOMM Computer Comm. Review, vol. 35(5), pp.41-54, 2005. [3] [CONMan] H. Ballani, and P. Francis, “CONMan: A Step Towards Network Manageability,” ACM SIGCOMM Computer Comm.Review, vol. 37(4), pp.205-216, 2007. [4] [Example Instantiation of GANA] Gábor Rétvari, Felicián Németh, Ranganai Chaparadza, Róbert Szabó: OSPF for Implementing Self-adaptive Routing in Autonomic Networks: a Case Study. In proceedings of the 4th IEEE International Workshop on Modelling Autonomic Communication Environments (MACE 2009), October 26-27 2009, Venice, Italy. [5] Rui L. Aguiar, Hans Joachim Einsiedler, Jose Ignacio Moreno: A Requirements Analysis for the Protocol Stack of the Future Internet

Ranganai Chaparadza: Can Autonomicity help Migration, and what could be a possible Evolution Path?

by FIA2010 on Jan 10, 2011

Accessibility

Upload Details

Usage Rights

Statistics

Ranganai Chaparadza: Can Autonomicity help Migration, and what could be a possible Evolution Path? — Presentation Transcript