Implementation Guide for the ETSI AFI GANA model: A Standardized ...

Globecom 2013 Workshop - The 5th IEEE International Workshop on Management of Emerging Networks and Services

Implementation Guide for the ETSI AFI GANA Model: a Standardized Reference Model for Autonomic Networking, Cognitive Networking and Self-Management Ranganai Chaparadza1, Tayeb Ben Meriem2, Benoit Radier3, Szymon Szott4, Michal Wodczak5, Arun Prakash 6, 7 8 9 Jianguo Ding , Said Soulhi , Andrej Mihailovic

 Abstract — This paper describes an Implementation Guide for an emerging standard for autonomic management &control of networks and services, namely the ETSI AFI GANA Reference Model for Autonomic Networking, Cognitive Networking and Self-Management (an emerging standard from ETSI). The implementation guide also takes into consideration the impact of emerging paradigms such as SDN and Virtualization. This is because as the standardized Reference Model has been published, it becomes important to provide an associated Implementation Guide that can be followed in implementing autonomic management & control in network architectures. Index Terms—Standardized Autonomics, ETSI AFI, AFI GANA Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management; GANA Implementation Guide.

I. INTRODUCTION We express “Autonomic Network Management & Control and Autonomic Networking” in the following way:  Autonomic Management & Control = Autonomics in the Management Plane + Autonomics in the Control Plane (whether distributed or centralized) Autonomic Management & Control in networks is about Autonomics (i.e. control-loops) introduced in the Management Plane as well as Autonomics (i.e. control-loops) introduced in the Control Plane (whether the control-plane is distributed or centralized). A control-loop realizes self-* features (selfconfiguration, self-optimization, etc). 1

Ranganai Chaparadza: ETSI AFI & IPv6Forum: [email protected] Tayeb Ben Meriem: Orange, AFI: [email protected] 3 Benoit Radier: Orange, AFI: [email protected] 4 Szymon Szott: AGH University, AFI: [email protected] 5 Michal Wodczak: IT Department of Poznan University of Economics, AFI: [email protected] 6 Arun Prakash: FOKUS, AFI: [email protected] 7 Jianguo Ding: University of Skövde: [email protected] 8 Said Soulhi: Ericsson, AFI: [email protected] 9 Andrej Mihailovic: KCL, AFI: [email protected] 2

978-1-4799-2851-4/13/$31.00 ©2013IEEE

Network control in emerging SDN (Software-Defined Networking) frameworks is based on a “centralized control paradigm” that leaves the fundamental E2E transport network elements with too little intelligence to self-manage so as to address problems that rather require the network elements to collaborate in a distributed fashion via distributed control algorithms (e.g. optimization algorithms). For example, experiences with OpenFlow based controllers has shown that relying only on centralized control while removing intelligence from the fundamental network elements makes the network less robust when connection to the controllers is lost. It is therefore desired to apply a hybrid model (ideally a standardized one) that enables to combine (interwork) centralized management & control with some distributed control within the fundamental network elements of transport network/data-plane (for problems that are better addressed by distributed control algorithms and distributed control-loops introduced in the fundamental E2E transport network architecture to enable some degree of in-network intelligence i.e. “in-system and in-network self-management”). From an Autonomic Management & Control point of view, a hybrid model that defines the abstraction levels at which interworking control-loops can be designed, while enabling to design nested and distributed control-loops to address complexity in design of autonomic functions, presents a holistic picture to the problem of modular approaches to designing interworking autonomic functions (realized as Decision-MakingEntities/Engines). The ETSI AFI GANA Reference Model is one such holistic hybrid model. In [8], we learn that due to complementarities of the paradigms of autonomic management & control and SDN, critical synergies can be obtained through unifying SDN concepts and frameworks with the emerging ETSI AFI GANA Reference Model [2]. As such, [8] describes Standardized Unifications of Reference Models for Autonomic Management & Control and SDN by way of integrating GANA and SDN facilitating frameworks. The paper first presents in Section II a snapshot of the emerging ETSI standard of Generic Autonomic Network Architecture (GANA), an architectural reference model for autonomic networking, cognitive networking and self-management [2]. The sections that follow describe the GANA Implementation Guide. Conclusions and insights into further work are given at the end.

935

Globecom 2013 Workshop - The 5th IEEE International Workshop on Management of Emerging Networks and Services

II. THE ETSI-AFI GANA ARCHITECTURAL REFERENCE MODEL IN A NUTSHELL The AFI standardization group [3] has a taken the following methodology in standardizing frameworks for autonomic networking (Figure 1). Autonomicity-Enabled Reference Architectures are the result of “instantiating” selected or all Functional Blocks and Reference Points defined in the AFI GANA Reference Model onto a target implementation-oriented standardized Reference Architecture.

Figure 1: AFI Methodology on standardizing Autonomics

management” from “implementation strategies, details and methods” that can be used to implement them, i.e. it is not constrained by any implementation-oriented architecture and to the extent possible avoids inheriting the limitations of today’s technology-specific network architectures. In a similar view for contrast, in the history of telecommunications, the OSI Reference Model serves the purpose of a “generic model” for the “domain of networking” i.e. a reference model (in the true sense of a reference model by virtue of being a generic framework) that can then be instantiated in implementing various types of implementation-oriented technologyspecific reference architectures such as the PSTN, GSM, UMTS architectures. The GANA Model serves as a “blueprint model” that prescribes the design and operational principles of “autonomic decision-making manager components/elements” called Decisionmaking Elements (DEs), responsible for “autonomic” management and adaptive control of systems and network resources & services. Autonomic behaviours include Auto-Discovery of network objectives specified by the operator, policies and resource capabilities; SelfConfiguration; Self-Diagnosing; SelfHealing/Self-Repair; Self-Optimization; and Self-Protection, etc., all of which must be performed by individual Network Elements (NEs)’s embedded DEs and by the collaboration of NEs’ DEs along an E2E path, in

The AFI GANA Reference Model [2] defines certain Generic Functional Blocks and their associated Reference Points and Hierarchy of Decision Characteristic Information, specific Network Elements (DEs) Governance Knowledge Plane to enabling Autonomics, Cognition Interface and Self-Management in a target ONIX MBTS architecture, when they are Network Level Routing Management DE “instantiated” onto an Network Level Fault Management DE implementation-oriented reference GANA Other Network Level DEs Network Level DEs Profile architecture such as BBF e.g. Network Level QoS Management DE (GANA Level-4) Administrator/Network (Broadband Forum), NGN/IMS, or Operator 3GPP architecture, etc. to create Outer Control Loop various types of AutonomicityNE (router, terminal, switch, NE (router, host, switch, Enabled Reference Architectures. gateway, base-station, etc.) gateway, base-station, etc.) Some of the various Functional Node Level DEs Blocks in the Reference Model Node_Main_DE Node_Main_DE (GANA Level-3) would need to be implemented by OSS vendors, others by equipment manufacturers and others by Network Element (NE) Function Level DEs Function-Level DE, e.g. QoS Function-Level DE, e.g. QoS (GANA Level-2) network operators and service Management DE Management DE providers. Some of the Functional Blocks are bound to enhance or Managed Entities (MEs)/ Managed Entities (MEs) Protocol Level DEs Managed Entities (MEs) evolve EMSs or NMSs/OSSs. The Resources, i.e. Protocols, Stacks & (partitioned and assigned (partitioned and assigned (GANA Level-1) generic Functional Blocks and Mechanisms, and Applications to specific upper DEs) to specific upper DEs) Reference Points can also be Figure 2: Snapshot of the AFI GANA Reference Model, and Modularization of logically centralized Control applied in Software (GANA Knowledge Plane) designing future collaboration with autonomic behaviors coordinated at the EMS network architectures that must exhibit self-management and NMS levels. Automation and Autonomicity (adaptive control capabilities from the dawn (outset) of their design. GANA is a of resources and behaviors) are the key aspects. Figure 2 presents generic model in the sense that it defines and separates “generic the abstraction levels at which interworking hierarchical/nested concepts and associated architectural principles” for the “domain control-loops can be designed. In general, self-manageability in of autonomic networking, cognitive networking and selfGANA is achieved through instrumenting the network elements Vertical Reference Point

Horizontal Reference Point

936

Globecom 2013 Workshop - The 5th IEEE International Workshop on Management of Emerging Networks and Services

The lowest level DEs are at the Protocol Level. They represent protocols, services, and other fundamental mechanisms that exhibit intrinsic control-loops, possibly already implemented in the network of today. A protocol-Level DE is simply any protocol that embeds its own intrinsic control-loop. OSPF, with its intrinsic control-loop can be considered an example of the instantiation of a Protocol Level DE. These DEs, together with any type of MEs at this “resources” layer, are managed by Function Level DEs such as the Routing Management DE,

with autonomic DEs that collaboratively work together. DEs may form “peers” along a path within the fundamental E2E transport architecture. The DE-to-DE peers need not necessarily be hop-byhop neighbours (i.e. resident/instantiated in on-link neighbouring nodes) but the peer relationships may relate to e.g. borderrelationships management in a heterogeneous network or may be related to some DEs in certain network elements interacting along an E2E path (e.g. for inter-domain collaborative management of resources and network behaviours). In designing DE-2-DE

Reference Point: Rfp_GANA-Level2_AccessToProtocolsAndMechanisms: This interface MAY be open to enable DEs loaded into the node/device (e.g. by a second party) to access and autonomically manage and control the MEs (Protocols, Stacks and Mechanisms) of the device. Some of the Information/Data and Parameters exposed by the MEs and accessible to the loaded DEs, may be standardized.

NODE_MAIN_DE

Information / Knowledge Repository

Initialization & Orchestration

Self-Description & Self-Advertisement

NODE_LEVEL_SEC_M_DE

Control Loop

Control Loop

FUNC_LEVEL_QoS_M_DE

GANA Level-3 Node Level

NODE_LEVEL_FM_DE

Controls Level-2 DEs

FUNC_LEVEL_MOM_DE FUNC_LEVEL_MON_DE

GANA Node

NODE_LEVEL_R&S_DE

NODE_LEVEL_AC_DE

FUNC_LEVEL_GCP_M_DE

FUNC_LEVEL_SM_DE FUNC_LEVEL_DPM_DE

Control Loop

FUNC_LEVEL_RT_M_DE Control Loop

Control Loop

Services/ Applications

Control Loop

Control Loop BGPv4

GANA Level-1 Protocol Level

RIPng

TCP, UDP etc

Monitoring Tools / Components

IPv4/IPv6 etc MPLS, etc Ethernet, Frame Relay, ATM, PPP, etc PHY

NODE_LEVEL_AC_DE – Node-Level Auto-Configuration Decision-Element

GANA Level-2 Function Level

Control Loop

Layer 4 Protocols OSPFv3

GMPLS

Other Control Plane Protocols

Any type of stack on which the control protocols are running e.g. an IP based transport (data plane), which is autonomically managed by the FUNC_LEVEL_DPM_DE

Layer 3 Protocols Layer 2.5 Protocols 0

Layer 2 Protocols PHY

FUNC_LEVEL_MOM_DE – Function-Level Mobility Management Decision-Element

NODE_LEVEL_R&S_DE – Node-Level Resilience & Survivability Decision-Element FUNC_LEVEL_QoS_M_DE – Function-Level Quality of Service-Management Decision-Element NODE_LEVEL_SEC_DE – Node-Level Security Decision-Element

FUNC_LEVEL_DPM_DE – Function-Level Data Plane-Management Decision-Element

NODE_LEVEL_FM_DE – Node-Level Fault-Management Decision-Element

FUNC_LEVEL_SM_DE – Function-Level Service-Management Decision-Element

FUNC_LEVEL_MON_DE – Function-Level Monitoring Decision-Element

FUNC_LEVEL_RT_M_DE – Function-Level Routing-Management Decision-Element

FUNC_LEVEL_GCP_M_DE – Function-Level Generalized Control Plane-Management Decision-Element

Figure 3: Structure of a GANA Node and Visualization of place-holders for Control-Loops interactions, control-loops in various nodes/devices may actually interact in a distributed fashion along an E2E path. When DEs are designed to horizontally interact, in order to collaboratively synchronize and/or negotiate settings for the parameters of their respective Managed Entities (MEs) or managed resources, they somewhat exhibit behaviour of a protocol, acting as Protocol Entities (PEs) while still at the same time realizing some local/autonomous decisions in their own respective control-loops. The GANA Reference Model defines a hierarchy of DEs, i.e., four basic levels of self-management: the protocol, function, node, and network levels. Each DE manages one or more lowerlevel DEs through a control loop. These lower-level DEs are therefore considered MEs of upper DEs. “Function-Level DEs” directly manage protocols, stacks, mechanisms, applications at the underlay resource layer. Over the control loop’s specific MEs, the DE sends commands, objectives, and policies to an ME and receives feedback in the form of monitoring information or other type of knowledge. Each DE realizes some specific controlloop(s), and therefore, represents an “Autonomic Activity” or “Autonomic Function” (AF). Examples of Autonomic Functions: Autonomic QoS Management-DE; Autonomic Security Management-DE; Autonomic Fault Management-DE; Autonomic Mobility Management-DE, etc.

Monitoring DE, and QoS Management DE. Currently there are seven Function Level DEs defined in the AFI GANA Reference Model, apart from the QoS Management DE shown on the Figure 2 (which autonomically manages QoS related protocols and mechanisms on the node). Each of them is present in every Network Element depending on the type of the Managed Entities (MEs) abstracted and assigned to specific Function-Level DEs responsible for autonomically managing them. The orchestration of the Function Level DEs is performed by a Node Level DE (the Node-Main-DE), which exists in only one instance in every Network Element. At the highest DE level, the Network Level DEs address similar aspects to the Function-Level-DEs but on a wider scope. Therefore there is a Network Level Routing Management DE, Network Level Monitoring DE, Network Level QoS Management DE, etc. In the process of the instantiation of DEs onto target implementation-oriented architectures such as the Broadband Forum (BBF) reference architecture, the DEs that must be instantiated in particular nodes must be chosen on the basis of a criterion such as the managed networking resources (including protocol stacks and mechanisms) a node/device supports and its point of attachment, as well as its role in the network topology. Once this decision has been made, the DE behaviours and behaviours of other autonomics-specific

937

Globecom 2013 Workshop - The 5th IEEE International Workshop on Management of Emerging Networks and Services

but the three levels indicated are the most important ones when one considers not to embed a control-loop into an individual protocol (i.e. avoiding “protocol-intrinsic control-loops”/protocollevel-DEs since they may complicate network manageability and may create undesired emergent behaviour in complex protocol interaction scenarios as known today). Control loops within Network Elements are fast-control-loops and as we go up the GANA Decision Plane Hierarchy into the Knowledge Plane, control-loops become slower, but more sophisticated due to the net-wide scope of the processed info in realizing selfoptimization. Techniques for addressing stability of control-loops and avoiding oscillations are discussed in [7] and are elaborated further in the GANA specification. The place-holders for internal control-loops (inside a Network Element) depicted by the Reference Model enable to design and embed “node-local” Self-Management behaviors/algorithms, including node-local Self-Optimization, i.e. some degree of network element intelligence through the internal Decision Elements (DEs) that realize the internal control-loops. Example node-scoped Self-* behaviours that may not necessarily require collaboration/negotiation with other network elements include: Plug-n-Play; Energy Savings through autonomic functions; Autonomic Security Management (self-protection and selfdefending behavior); Autonomic Fault-Management and Resilience (proactively and reactively), etc. For more details of the Reference Model and how it was developed as a unified model that accommodates various autonomics concepts and principles from diverse frameworks, we refer the reader to the AFI GANA Specification [2]. The EFIPSANS project [6] validated various aspects of the earlier version of the GANA Model by deriving, prototyping and validating autonomic behaviours of specific DEs in GANA-oriented frameworks for various autonomic functions in various network architectures and environments: Instantiated DEs for Autonomic Mobility Management [Mobility-Management DE(s)] and Autonomic QoS Management [QoS Management DE(s)]; DEs for Autonomic Routing [Routing-Management DE(s)]; DEs for Auto-Discovery, AutoPrioritized Reference Point: Configuration/Self-Configuration Rfp_ModelBasedTranslationService-to-NodeMainDE (a refinement of Rfp_NetworkLevelDE-to-NodeMain-DE) [NODE_MAIN_DE]; DEs for Autonomic Resilience, Survivability [Resilience & Survivability DE(s)]; DEs for Autonomic Fault-Management [Fault-Management DE(s)]; DEs for Autonomic Monitoring Autonomic BNG [Monitoring DE(s)]; DEs for Autonomic Security Management [SecurityManagement DE(s)]. For more details on the AFI GANA Reference Model we refer the reader to [2].

Functional Blocks must be further specified in more detail (while further elaborating on the generic behaviours and characteristic information exchanged on reference points) based on analysing various use case scenarios and requirements for autonomics and self-management in the particular target reference architecture. Fundamental DE behaviours that need to be standardized versus those behaviours (e.g. customized DE algorithms) that cannot be standardized, need to be discussed and agreed in the standardization process. Characteristic Information exchanged over the reference points and the protocols used to convey it become more concrete and detailed in the instantiations and requirements analysis phase. The Network Level DEs constitute the Functional Blocks of the Knowledge Plane, together with ONIX (Overlay Network for Information eXchange) and MBTS (Model-Based-Translation Service). [5] defines the Knowledge Plane as a pervasive system within the network that builds and maintains high-level models of what the network is supposed to do, in order to provide services and advice to other elements of the network.. ONIX is a distributed scalable system of information servers that form an Overlay Network for Information eXchange and provides information publish/subscribe paradigm as a service that enables various entities to query and find information and/or to store information that can be shared, to effect advanced AutoDiscovery. MBTS forms an intermediation layer between the Knowledge Plane and the Network Elements for the purpose of translating information and commands/responses (more details are given in the AFI GANA specification [2]). According to the Reference Model, the 3-Levels of Hierarchical Control-Loops (GANA Level-2 to Level-4) that are realized by the corresponding Decision-making-Elements (DEs), which collaboratively work together from within a Network-Element (NE) up to the “Network-Level/Knowledge Plane”, demonstrate how Autonomics/Cognition/Self-Management can be gracefully (nondisruptively) introduced in today’s existing architectures. The Reference Model defines Four Basic Levels of Self-Management,

Outer ControlLoop

Objectives, Policies from a higher level (network-level)

Reference Point: Rfp_GANA-Level2_AccessToProtocolsAndMechanisms: This interface MAY be open to enable DEs loaded into the node/device (e.g. by a second party) to access and autonomically manage and control the MEs (Protocols, Stacks and Mechanisms) of the device. Some of the Information/Data and Parameters exposed by the MEs and accessible to the loaded DEs, may be standardized.

NODE_MAIN_DE

Information / Knowledge Repository

Initialization & Orchestration

Self-Description & Self-Advertisement NODE_LEVEL_R&S_DE

NODE_LEVEL_AC_DE

NODE_LEVEL_SEC_M_DE

Control Loop

NODE_LEVEL_FM_DE

Controls Level-2 DEs

GANA Level-3 Node Level

FUNC_LEVEL_GCP_M_DE

FUNC_LEVEL_MON_DE

Control Loop

FUNC_LEVEL_QoS_M_DE

FUNC_LEVEL_DP&FWD_M_DE

Control Loop

FUNC_LEVEL_RT_M_DE

Control Loop

Control Loop

Control Loop

Routing Protocol?

Monitoring Tools / Components

IPv4/IPv6 etc MPLS, etc 802.1ad

Ethernet, etc PHY

NODE_LEVEL_AC_DE – Node-Level Auto-Configuration Decision-Element

GANA Level-2 Function Level

GANA Level-1 Protocol Level Layer 4 Protocols

Control Plane Protocols Any type of stack on which the control protocols are running e.g. an IP based transport (data plane), which is autonomically managed by the FUNC_LEVEL_DP&FWD_ M_DE

Layer 3 Protocols Layer 2.5 Protocols 0

Layer 2 Protocols PHY

Protocol Stacks and Mechanisms

Exposing “Views”

FUNC_LEVEL_QoS_M_DE – Function-Level Quality of Service-Management Decision-Element

NODE_LEVEL_R&S_DE – Node-Level Resilience & Survivability Decision-Element NODE_LEVEL_SEC_DE – Node-Level Security Decision-Element

FUNC_LEVEL_DP&FWD_M_DE – Function-Level DataPlane&Forwarding-Management Decision-Element

NODE_LEVEL_FM_DE – Node-Level Fault-Management Decision-Element FUNC_LEVEL_MON_DE – Function-Level Monitoring Decision-Element

FUNC_LEVEL_RT_M_DE – Function-Level Routing-Management Decision-Element

FUNC_LEVEL_GCP_M_DE – Function-Level Generalized Control Plane-Management Decision-Element

Figure 4: Prioritized Reference Point on the Southbound interface of the Knowledge Plane, with illustration for a BBF autonomic BNG

938

III. IMPLEMENTATION GUIDE FOR THE AFI GANA MODEL What needs to be understood about the GANA Model The GANA Model is not like a protocol that needs to be fully implemented in order for intended functionality to be rendered operational, but rather, the GANA Model can be implemented step by step in order to incrementally introduce or implement autonomicity in a networked system and the network as a whole. The incremental

Globecom 2013 Workshop - The 5th IEEE International Workshop on Management of Emerging Networks and Services

implementation enables to realize low degree autonomicity in a node/device and in the network by instantiating selected DEs first until full-fledged autonomicity with higher degree of autonomicity is achieved as more DEs get instantiated and implemented, and as each instantiated DE’s self-* features are enhanced in the long term. The points described below offer a first attempt to creating guidance on how to implement the GANA Model.

2.

(a) Steps to follow in Instantiation of the GANA Model onto target architecture 1.

Static instantiation of certain types of Decision Elements (DEs) into network nodes/devices by design is based on examining the types of resources (virtualized or not) i.e. Managed Entities (MEs) such as protocols, stacks, mechanisms and applications/services that are assumed to be supported and be “persistently” operated in a particular node/device during its lifetime, as the instantiated DEs would become the autonomic managers for their “specifically assigned MEs and their configurable and controllable parameters”. This type of Instantiation is rather “static” because the assumption of the “persistence” in the orchestration and lifetime of some types of MEs holds true in such cases. However, there are cases whereby such an assumption and other assumptions may not hold, and that the instantiation of certain types of Decision Elements (DEs) may need to be “dynamically” decided at runtime based on discovered capabilities of MEs, context, environment and situations in which the role of a node/device and associated MEs to orchestrate and employ should be determined dynamically. Some examples of such cases include on-demand networks. Wherever there is a depiction of a Decision-Element (DE) in GANA, a Control-Loop for the DE can be designed. A Table is needed that provides a “one-toone” mapping/assignment between each specific instantiated DE and its specifically assigned types of Managed Entities (MEs) and their Configurable and Controllable Parameters over which a control-loop can be designed for the particular DE. Such a Table can be structured into sub-tables according to the node/device types of the network which need to be under the autonomic management & control of the GANA Knowledge Plane. A mappings Table needs to be developed for each instantiation of GANA and become standardized and maintained by ETSI AFI. The Table is a basis for implementing DE-to-DE coordination functions which require that in realizing global self-optimization and other self-* features of DEs the DEs bound by the algorithm being applied must synchronize and negotiate parameter value changes or ME (re)-configuration changes. The coordination should follow the principles described in [2] w.r.t Assignment of Managed Entities (MEs) and their Configurable and Controllable Parameters to specific Decision Elements (DEs) in GANA (1to-1 Mapping). The Table of DEs to ME-Parameters mappings needs to be derived and elaborated on the basis of the generic Table provided in the AFI GANA Model specification [2]. The generic Table in [2] is the basis for determining what sort of Level-2 DEs (function-level) should be instantiated for a particular node/device in the targeted architecture. We consider “implementation of GANA” as consisting of an “instantiation of the GANA Model (whether partial instantiation or full instantiation)” plus a separate further process by which selected instantiated GANA Functional Blocks and Reference Points are then implemented by way of software and actual run-time components/sub-systems (i.e. “component/sub-system implementation phase”). During the instantiation process/phase, selected DEs from those defined on the GANA Level-2 need to be instantiated or all the Level-2 DEs defined may be instantiated at the same time.

3.

For wired network segments (e.g. BBF and 3GPP Mobile backhaul and core network segments), the GANA Knowledge Plane should be instantiated with its Functional Blocks and Reference Points. Selected Network-Level DEs can be instantiated according to the Managed Entities (MEs) assumed to operate in the network nodes/devices to be under the autonomic management & control of the Knowledge Plane. The MEs of a node/device and their configurable and controllable parameters known should be assigned to specific Level-2-DEs, which are mirrored on the Network-Level (i.e. by corresponding DEs in the Knowledge Plane). Initial focus should be on a single domain Knowledge Plane (i.e. for a single administrative domain or simply a Knowledge Plane designed to operate over a particular scope of nodes/devices under its control) and then later move on to KnowledgePlane-toKnowledgePlane Interface implementations. For wireless network segments such as ad-hoc wireless networks, the nodes/devices themselves may be part of Knowledge Plane formation, and such a Knowledge Plane that is intrinsically formed by such nodes/devices may need to interwork with an explicit standalone Knowledge Plane for wired network segments. The Network Governance Interface i.e. the Northbound Interface of the Knowledge Plane needs to be considered at the early stages of implementing the Knowledge Plane so that the aspects associated with the automated generation of GANA Network Profiles (as described in [2]) can be addressed while taking into consideration vendor specific configuration methods for legacy devices as well as the need for “co-existence” of the traditional NMS and Knowledge Plane during the migration phase to autonomic management (the subject is covered in [2]).

(b) Fundamental Functional Blocks that need to be put in place for GANA implementation and enabling Network Management migration to Autonomic Management

939

1.

2.

3.

The legacy devices architectures and existing management architectures needs to be considered. The AFI GANA Specification [2] provides an illustration of a possible migration scenario involving integrating today’s Network Management Systems (NMS’s) and GANA, and how NMS’s will evolve over the time as their components become integrated as part of the Network-Level-DE, i.e. how the “migration” of an NMS or “co-existence” of the traditional NMS and Knowledge Plane could happen. New device architectures supporting open interfaces to load second party control software/logic, and supporting virtualization, imply that a GANA Node_Main_DE and/or Level-2-DEs can be instantiated and loaded into a node/device as second party control software running special algorithms from the second party (i.e. as customized autonomic functions). In [2], the subject of loadable control strategies is described. The Internal Reference Point defined for a GANA Node (see figure 3) may be supported by a device vendor in various ways, including through a virtualization layer, to enable second party control-logic (Level-2 DEs and or Node_Main_DE) to be loaded into the device/node and run as run-time processes or as run-time executable behavioural models that get interpreted and executed by the device vendor’s own supplied DEs that may come embedded in the device/node or could be obtained from the device vendor and uploaded into the device. The Functional Blocks, MBTS and ONIX need to be considered early enough in implementations in order to implement Network-Level-DEs in such a way that their control logic may be developed in a way that is agnostic to the actual management & control protocol to employ (as this aspect should be addressed by MBTS function libraries). There are already a number of libraries for popular protocols like SNMP,

Globecom 2013 Workshop - The 5th IEEE International Workshop on Management of Emerging Networks and Services

CMIP, COPS, NETCONF, OpenFlow, etc, that can already be integrated to start building an MBTS.

(c) Prioritization of Control-Loops to implement first, and how to handle legacy node/device architectures 1. The outer control-loop i.e. between the GANA Knowledge Plane and a node/device, and the Reference Point on the southbound interface of the Knowledge Plane, need to be prioritized. An example illustration with the BBF BNG node/device is illustrated on figure 4. 2.

The next control-loops to consider are the Node-Level (NodeMain-DE), and then selected control-loops on the GANA Level-2-DEs.

(d) The proposal on which DEs to implement first 

Follow a top-down approach in the implementation of the GANA Model onto a target architecture. It is necessary to consider implementation of GANA incrementally using a top down approach due to the fact that the emerging paradigms on logically centralized control-software (e.g. the case of SDN) are already taking shape in implementations, and this is the time to align paradigms like SDN & NFV with the GANA Autonomics Reference Model. However, from a technical point of view and incremental introduction of autonomics in nodes/devices, GANA Level-2 and Level-3 (Node_Main_DE) can also be considered as well while implementing the GANA Knowledge Plane. The ETSI AFI Group will seek to produce a Table of prioritized DEs for incremental implementations.

(e) Self-* features to start with and their associations to DEs Note: Each DE has a number of Self-* features that it must realize in collaboration with other GANA Functional Blocks. Behaviours associated with auto-discovery, autoconfiguration/self-configuration and then self-optimization during the operation phase of the node/device and the network are fundamental to each DE. The Self-* features to consider for each instantiated DEs, step-by-step, are as follows: 1.

2.

DE behaviours at initialization phase, i.e. when the DEs are initialized. These include Auto-Discovery and SelfAdvertisement of capabilities of their assigned MEs and then Self-Configuration (Auto-Configuration) based on having received the GANA Network Profile or a sub-profile thereof (see [2] for these expected behaviours) during the configuration phase. After implementing the fundamental behaviours of instantiated DEs, developers can then move on to implement DE’s SelfOptimization behaviours they must exhibit in optimizing something about their MEs (for both, the aspects requiring autonomous optimization by a DE, and those requiring a collaboration of multiple DEs). DE algorithm developers/providers can provide DEs as DE Libraries.

(f) The need to implement function-call hooks that should then be fully implemented at a later stage of implementation The GANA spec [2] specifies the interfaces of a DE by presenting a Model of a DE and the Primitives that should be supported on DE interfaces. In implementing a DE, it is necessary to consider initially implementing the primitives as skeleton hooks (without actual behaviour implementation) and enable them to be called by functions involving DE-to-DE interactions for example, so that the interaction of GANA Functional Blocks may be observed and verified using skeleton code for some interface methods/primitives. Coordination functions between DEs can initially have skeleton hooks implemented so that the behaviour of a DE that involves the DE attempting to perform a synchronization action with an upper DE (for example) can be observed [7].

The AFI GANA Reference Model takes into consideration the impact of virtualization on network architecture. There are various dimensions of virtualization that need to be considered. For example, a virtual node (e.g. a virtual machine) may require that an associated instantiation of the GANA Level-2 DE(s) and/or level-3 DEs be created and bound to the virtual node as its own DEs. In [2] a way to use a Hypervisor to implement the Level-2 and Level-3 DEs is provided. In the fusing together of Network Management and Control (as the operations get performed by the same system), the GANA Knowledge Plane would also need to autonomically manage and control the VNFs coming from the NFV (Network Functions Virtualization) Paradigm, while autonomically managing the legacy physical nodes/devices as well.

Regarding the impact of SDN and the SDN enablers defined in the AFI GANA Reference Model, we refer the reader to [8] and to the spec itself [2].

IV. CONCLUSION AND FURTHER WORK The GANA Implementation Guide will continue to be reviewed, evolved and published by the ETSI AFI Group. Readers should follow up on this. The application of the GANA Framework in Cloud computing environments also needs to be further elucidated in the light of bridging the GANA Model with the work being done by DMTF [9], for example. For example, how the DMTF Cloud Infrastructure Management Interface (CIMI) can relate to the concept of GANA Network Profiles and how input specified through CIMI can be translated into elements of the GANA Network Profiles used in network resource configurations and orchestration. GANA can bring a new way to manage and implement clouds. Cloud computing needs Autonomics and GANA can fill the gap by the Autonomics Functional Blocks and Reference Points and interfaces it defines. Cloud Orchestrators can interwork with the GANA Knowledge Plane and Network Governance Interface defined in GANA.

REFERENCES [1]

[2]

[3] [4] [5] [6] [7]

[8]

[9]

(g) Consideration of the impact of Virtualization and SDN 940

R. Chaparadza, S. Papavassiliou, T. Kastrinogiannis, M. Vigoureux , E. Dotaro, A. Davy, K. Quinn, M. Wodczak, A. Toth, A. Liakopoulos, M. Wilson: 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. ETSI GS AFI 002: Autonomic network engineering for the selfmanaging Future Internet (AFI): GANA Architectural Reference Model for Autonomic Networking, Cognitive Networking and SelfManagement. This ETSI Specification is publicly available since April 2013:http://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/ gs_afi002v010101p.pdf ETSI AFI Industry Specification Group: Autonomic network engineering for the self-managing Future Internet (AFI): (http://portal.etsi.org/afi) John C Strassner, Nazim Agoulmine, and Elyes Lehtihet. FOCALE – A Novel Autonomic Networking Architecture. In LAACS, Campo Grande, MS, Brazil, 2006. David D. Clark, Craig Partridge, and J. Christopher Ramming. A knowledge plane for the Internet. In SIGCOMM, pages 3–10, 2003. EFIPSANS deliverables accessible under: http://www.efipsans.org/ Nikolay Tcholtchev, Ranganai Chaparadza, and Arun Prakash. Addressing Stability of Control-Loops in the Context of the GANA Architecture: Synchronization of Actions and Policies. In IWSOS ’09: Proceedings of the 4th IFIP TC 6 International Workshop on SelfOrganizing Systems, pages 262–268, Berlin, Heidelberg, 2009. Springer R. Chaparadza et al: SDN Enablers in the ETSI AFI GANA Reference Model for Autonomic Management & Control (emerging standard), and Virtualization Impact: 5th IEEE MENS Workshop at Globecom 2013, Atlanta, Georgia, USA. DMTF Cloud Management Working Group (CMWG): http://www.dmtf.org/standards/cmwg