ETSI Industry Specification Group onAutonomic network engineering for

self-managing Future Internet(ETSI ISG AFI)

Ranganai Chaparadza1, Laurent Ciavaglia2, Micha l Wodczak3, Chin-ChouChen4, Brian A. Lee5, Athanassios Liakopoulos6, Anastasios Zafeiropoulos6,

Estelle Mancini7, Ultan Mulligan7, Alan Davy8, Kevin Quinn8, Benoit Radier9,Nancy Alonistioti10, Apostolos Kousaridas10, Panagiotis Demestichas11, KostasTsagkaris11, Martin Vigoureux3, Laurent Vreck7, Mick Wilson12, Latif Ladid13

1Fraunhofer FOKUS, 2Alcatel-Lucent, 3Telcordia Technologies, 4Chunghwa TelecomLabs, 5Telefon AB LM Ericsson, 6GRNET, 7ETSI, 8Waterford Institute of

Technology, 9France Telecom, 10University of Athens, 11University of PiraeusResearch Center, 12FUJITSU Laboratories of Europe, 13IPv6 Forum

Abstract. The research area of Autonomic Networking/Self-ManagingNetworks is becoming more and more important across the industry andacademia, motivated by the need for a Self-Managing Future Internet.Momentum on the subject is on the rise. The previous developments andcurrent research in this very vital field of Autonomics and Self-ManagingNetworks are still not harmonized and we are still sensing conflicting (andeven seemingly chaotic) approaches and thinking.

Key words: autonomic networking, self-management, industry specifi-cation group

1 Introduction

The research area of Autonomic Networking/Self-Managing Networks is becom-ing hotter and hotter across the industry and academia, thereby calling for aSelf-Managing Future Internet design. Momentum on the subject is on the rise.The previous developments and current research in this very vital field of Au-tonomics and Self-Managing Networks are still not harmonized and we are stillsensing conflicting (and even seemingly chaotic) approaches and thinking. Thereare a number of issues and related developments, however, which can be har-monized through a well-focused Special Working Group that should seek toestablish a common understanding on what an autonomic behavior is and howan autonomic/self-managing network should be engineered. Such a group shouldserve as a focal point for the development of common specifications and engi-neering frameworks that guarantee interoperability.

2 ETSI ISG AFI

2 Rationale and Vision

There has been a very strong need for the creation of a dedicated and well fo-cused Industry Specification Group (ISG) on Autonomic Network Engineeringfor the Self-Managing Future Internet [9] within a well-established Standard-ization Body such as ETSI. The arguments, reasons and different aspects areoutlined and discussed in the following subsections.

2.1 Need for the development of an architectural Reference Modelfor Self-Management

Many of the key industrial players and other stakeholders seem to be verymuch in favor of hearing about evolution paths for today’s network modelsand paradigms, rather than revolutionary approaches, for reasons which arevery well-known. Some of the reasons are: the huge costs associated with anyrevolutionary undertaking, the fear of jeopardizing proven and well satisfyingbusiness models, the fear of drowning into complex technologies that might atthe end of the day prove to be difficult to test, validate, maintain and even trust,etc. Therefore, unless an architectural reference model for a generic autonomicnetwork architecture is defined and a viable roadmap of an evolution path con-sidering today’s network architectural models is proposed, a lot of key playerswill not be persuaded to quickly join in the call for the Self-Managing FutureInternet, even though they like the vision very much. This is because they willnot be in a position to quickly understand how the challenges for designing theSelf-Managing Future Internet can be addressed and how they can support theassociated efforts/developments through a well-focused and harmonized WorkingGroup such as an ISG. To this end:

– An architectural Reference Model of a Generic Autonomic Network Archi-tecture (GANA) is developed that defines the framework for autonomic ele-ments, together with their relationships, and the associated self-manageabilityproperties of the Future Internet, as well as the characteristics described laterin Section 3. An architectural reference model is meant to serve the followingmain purposes: to establish common understanding on what an autonomicbehavior is, and how an autonomic/self-managing network should be en-gineered. Looking towards Future Multi-Service Networks, it is becomingclearer that autonomicity is an enabler for the self-manageability propertiesof such networks. Clearly, whether revolutionary/clean-slate or evolutionaryapproaches should be taken towards the design of Future Multi-Service Net-works, a reference model on how to design autonomic/self-managing featureswithin node and network architectures is required. Reference model mustserve two main purposes: (1) to guide both the evolutionary approaches andthe revolutionary/clean-slate approaches towards further architectural re-finements and implementations, and (2) to establish common understandingand allow for the production of standardizable specifications of architecturalfunctional entities and interfaces. The ”generic nature” of the Specifications

ETSI ISG AFI 3

of the elements of the GANA should clearly separate ”Specification Issues”of the elements and Interfaces from ”Implementation Issues”. Therefore, forthe creation of the required architectural Reference Model of a Generic Au-tonomic Network Architecture, stakeholders from both, the evolutionary ap-proaches and the revolutionary approaches, will be involved in the creationof the Reference Model.

– A viable roadmap of an evolution path is defined considering today’s net-work architectural models with protocols such as IPv6, and paradigms asnecessitated by the Reference Model. The roadmap should include func-tional models and guidelines for addressing implementation issues such asthe appropriate systems engineering methodologies for autonomic network-ing software/systems, and estimates of the cost of evolving today’s networkmodels and protocols, etc.

Without having these two aspects well-defined, a lot of key players willnot quickly understand how the challenges for designing the Self-ManagingFuture Internet can be realized and how they can support the associated ef-forts/developments through a well-focused and harmonized Working Group suchas the ISG. Currently most of these key players are members of the well estab-lished and renowned Standardization Bodies. Therefore, there is actually a crit-ical need to find ways to attract a large base of most of them. The reason whywe need to reach out to them, by getting to where they are currently very muchpresent, is that over the years, experience has shown that most industrial playershave extensive knowledge, regarding the design of architectures that meet perfor-mance and scalability demands required of production networks. When properframeworks and harmonized Working Groups such as this ISG, that support theacademia and the industry to share knowledge and work together, are in place,the results obtained out of the co-operation are always far reaching.

2.2 The need to encourage harmonization and pragmatism

There is a need to encourage harmonization and pragmatism in the circles ofboth, the evolutionary approaches and revolutionary approaches in order to havewell focused goals. For example, those targeting the creation of clean-slate typeof architectures should clearly have their own space of thinking, as compared tothose going for an evolutionary approach to the design of the Future Internet.The two could first work together in the creation of a Generic ArchitecturalReference Model (i.e. the GANA) of Autonomic/Self-Managing Nodes, Devices,or Networks. They could then follow different approaches in terms of how tomove from the Generic Architectural Reference Model to implementation issues,one of which may be based on evolving today’s network models and protocolsin an incremental way or following a clean-slate implementation. However, bothshould be guided by a common Generic Architectural Reference Model (i.e. theGANA) if possible. The two circles should continue to exchange ideas alongthe way, until a commonly accepted Future Internet architecture finally emergesthrough a final consensus.

4 ETSI ISG AFI

2.3 The time is right

It is now a crucial moment for the creation of harmonized evolutionary ap-proaches towards the Future Internet design, in order to come up with a roadmapon the evolution of today’s network models, paradigm and protocols. The timingis right because momentum is here, because industry and academics are alreadycollaborating in EU projects and that SDOs (Standards Development Orga-nizations) must accompany the trend rather than post-specify vendor specificdevelopments.

2.4 The support is available from well-established StandardizationBodies like ETSI

ETSI has recently launched the initiatives of Industry Specification Groups(ISGs). An ISG is a new form of ETSI committee which sits alongside ETSI’sexisting Technical Organization. An ISG enables ETSI members (most of thekey industrial players we seek to involve in the Future Internet design) to de-velop ETSI Group Specifications while using ETSI’s world renowned IPR Policyand Standardization Support Tools. As ETSI puts it, ”months of expensive le-gal negotiation are avoided by establishing an ISG instead of an industry forum,and upgrading an ISG to an ETSI Technical Body is so much easier”. Someof the support ETSI provides, are Guidance-rules, procedures and partnershipforming; Meeting Rooms; Meeting support; Meeting Management Tools, Specifi-cations Management; Dedicated secure work area on the ETSI Portal; E-mail listservice, Processing and Publication of ETSI Group Specifications (GSs); Meet-ing secretary; Technical Editor; Rapporteur; Dedicated web site and ProjectManagement.

2.5 Regarding Co-operation between the AFI ISG and Bodies suchas ACF, IETF, etc

The AFI ISG will seek and will be open to co-operate with Forums such as theACF and Standardization Groups and Bodies such as IETF, etc. The AFI ISGwill work in parallel with activities in Groups like the ACF, and should alsocontribute (e.g. make visible) its Specifications to such Groups. For example,ACF activities that are deemed relevant by both parties could be processedthrough the AFI ISG.

3 Properties of the required Reference Model of a holisticGeneric Autonomic Network Architecture (GANA)

Whether an evolutionary approach or revolutionary approach could be taken to-wards designing the Future Internet [2], [5], there is a requirement for a GenericAutonomic Network Architecture (GANA) as a Reference Model that allowsfor the production of ”Standardizable” Specifications of Autonomic Behaviors

ETSI ISG AFI 5

i.e. Self-* functions of context-aware, policy-driven Decision-Making-Elements(DMEs)-potentially with cognitive properties, designed for the self-managementof diverse networking environments. From such a common, unified ReferenceModel, either clean-slate based architectural refinements and implementations orincremental evolutionary architectural refinements and implementations shouldthen be derived, such that the experiences gained during the implementationscan then be used for the evolution and further development of the GANA Refer-ence Model. In [3], the authors present the rationale behind the call for contribu-tions to the development of a Standardizable Reference Model for autonomic net-work engineering that should be used as a guide for creating an Evolution Pathtowards the Self-Managing Future Internet. In [3], different instantiations of theGANA approach are presented, which demonstrate its use for the managementof a wide range of functions and services, including both, basic network servicessuch as Autonomic Routing and Autonomic Monitoring, as well as enhancedones such as Autonomic Mobility and Quality of Service (QoS) Management.

3.1 The Vision of a Self-Managing Future Internet

The vision of the Future Internet is a vision of a self-managing network whosenodes and/or devices are designed/engineered in such a way that all the so-calledtraditional network management functions, defined by the FCAPS managementframework (Fault, Configuration, Accounting, Performance and Security) [8], aswell as the fundamental network functions such as routing, forwarding, moni-toring, discovery, fault-detection and fault-removal, are made to automaticallyfeed each other with information (knowledge) such as goals and events, in or-der to effect feedback processes among the diverse functions. These feedbackprocesses enable reactions of various functions in the network and/or individualnodes/devices, in order to achieve and maintain well defined network goals. Insuch an evolving environment, it is required the network itself to help detect,diagnose and repair failures, as well as to constantly adapt its configurationand optimize its performance. Looking at Autonomicity and Self-Manageability,we see that autonomicity (i.e. control-loops and feed-back mechanisms and pro-cesses, as well as the information/knowledge flow used to drive control-loops)[7], becomes an enabler for self-manageability of networks. As such, even theFCAPS functions become diffused within node/device architectures, apart frombeing part of an overall network architecture, whereby traditionally, a distinctmanagement plane is engineered separately from the other functional planes ofthe network. Since even the management functions become inherent functions ofthe fundamental node/device architectures, it means that the functional planesof a self-managing network, would need to be (re)-defined and re-factored (referto [2] and [5]). New concepts, functional entities and their associated archi-tectural design principles that facilitate Self-Management at different levels ofnode/device and network functionality and abstractions, are required. Also, in[3], the authors describe the need for the continued further development of theGANA by calling for contributions to its specifications, from diverse researchinitiatives (past, present and future).

6 ETSI ISG AFI

3.2 The emerging GANA-an evolvable holistic architecturalReference Model for Self-Management within node/device andnetwork architectures

The adopted Generic Autonomic Network Architecture (GANA) [2], sets thefundamental principles and guidelines that need to be followed towards realizingour vision of the Self-Managing Future Internet, and does not intend to provideany specific solution or implementation. In contrast to any other of today’s bestknown approaches, including clean-slate approaches (both pure and non-pure)such as 4D [5], ANA [10], CONMan [1], a Knowledge Plane for the Internet [4],FOCALE [11], [7], a Situatedness-based Knowledge Plane for autonomic net-working [6], the approach adopted in GANA introduces Autonomic ManagerComponents for different abstraction levels of functionality, which are designedfollowing the principles of Hierarchical, Peering, and Sibling relationships amongeach other within a node/device or network. Moreover, these components are ca-pable of performing autonomic control of their associated Managed-Entities, aswell as co-operating with each other in driving the self-managing features of theNetwork(s). None of today’s approaches, such as the ones mentioned above, pro-poses a holistic Reference Model that defines and distinguishes between diverseAutonomic Elements/Managers and their associated Managed-Entities (MEs)for different levels of abstractions within node/device architectures and networkarchitectures. Among GANA objectives is to address the following problemsand issues: (1) Complexity, by defining some abstractions for autonomic/self-management functionality at four hierarchical levels as described later; (2) Howto ensure that the decision-making-processes for autonomicity (self-managementbehaviours) within a node/device and the network as a whole, are conflict-free;(3) How to incorporate design principles that enable ”in-network management”and define constraints and boundaries for in-network management; (4) Captur-ing the kind of perspectives offered to end-users or operators of autonomic/self-managing networks, such as the interfaces that are meant to allow humans todefine network-level objectives that govern the operation of an autonomic (self-managing) network under the control of an administrative domain. In GANA,four levels of abstractions for which DMEs, MEs and Control-Loops can be de-signed, are described below (following a bottom up approach):

– Level-1: Self-manageability issues may be associated with some implementa-tion of a single network protocol (whether monolithic or modular). This levelis the lowest level of abstraction of functionality in GANA and is associatedwith the manifestation of control-loops (by design), as depicted in Figure 1.

– Level-2: The concepts of a Control Loop, Decision-Making Element, Managed-Entity(ies), as well as the related self-manageability issues may be associatedwith a higher level of abstraction than a single protocol (see Figure 1). Thismeans that the aspects of Autonomicity/Self-management may be addressedat the level of ”abstracted networking functions” (or ”network functions”)such as routing, forwarding, mobility management, QoS management, etc.At such a level of abstraction, what is managed by an assigned DME are a

ETSI ISG AFI 7

MainDecisionElement of the

Node (Node-DE)

Objectives,Policies from a

high er level (n etwo rk-level-DE)

Decision Element

of an abstracted

Network Functione.g. Routing

Main DecisionElement of the

Node (Node-DE)

Objectives, Policies from a hig her

level (network-level-DE)

DecisionElement

of an abstracted

Network Functione.g. Routing

Decision Element

intrinsic to aRouting Protocol

e.g. OSPF

DecisionElement

intrinsic to aRouting Protocol

e.g. OSPF

Peers

Peers

Peers

Node X Node Y

DecisionElement

intrinsic to a

Routing Protocole.g. OSPF

Decision

Element ofan abstracted

Network

Funtion e.g.QoS

Management

Example in teraction

between Sibl in g

Decision Elements

GANA’s lowest level/

layer MEs: Protocols,

Protocol S tacks, and

mechanism s

Fig. 1. Examples of Hierarchical, Peering, Sibling Relationships and Interfaces of DEsin GANA, calling for Specifications

group of protocols and mechanisms that are collectively wrapped by whatwe may call a Function Block or Functional Block, and are considered tobelong to the functionality of the abstracted networking functions e.g. allrouting protocols and mechanisms of a node become managed by a Decision-Making-Element (Routing Management DE) assigned and designed to man-age only those protocols and mechanisms. This level of abstraction allowsus to talk about autonomicity of self-managing properties at this particularlevel of abstracted network function e.g. autonomic routing, autonomic for-warding, autonomic QoS management, autonomic mobility management, inthe node/network. We call the DEs operating at this level, the ”Functions-Level” DEs.

– Level-3: On a higher level of autonomic networking functionality than thelevel of ”abstracted networking functions” of a node/network, the conceptsof a Control-Loop, Decision-Making Element, Managed-Entity(ies), as wellas the related self-manageability issues may be associated with a system(node) as a whole. Figure 1 illustrates that at this level of self-management(autonomic) properties, the lower level Decision-Making-Elements operatingat the level of abstracted networking functions become the Managed Au-tomated Tasks (Managed-Entities) of the main Decision-Making-Element(DME) of the system (node). This means the node’s main DME has accessto the ”views” exposed by the lower level DMEs and uses its overall knowl-

8 ETSI ISG AFI

edge to influence (enforce) the lower level DMEs to take certain desireddecisions, which may in turn further influence or enforce desired behaviourson their associated Managed-Entities, down to the lowest level of individualprotocol behaviour. A ”Sibling” relationship simply means that the entitiesare created or managed by the same upper level Decision-Making-Element(DME/DE). This means that the entities having a sibling relation can stillform other types of peer relationship within the autonomic node or withother entities hosted by other nodes in the network, according to the proto-col defined for their needs to communicate with other DEs.

– Level-4: The next level of self-manageability (autonomicity) after the ”nodelevel” described above, is the ”network level”. There may exist a logicallycentralized Decision-Making-Element or isolated decision plane/cloud suchas the one proposed in the 4D network architecture [6] that knows (throughsome means) the objectives, goals or policies to be enforced by the whole net-work. The objectives, goals or policies may actually require that the main(top-level) DMEs of the nodes of the network covered by the centralizedDME or plane export ”views” such as events and state information to thecentralized DME or plane. This may happen in order for the centralizedDME to influence or enforce the DMEs of the nodes to take certain desireddecisions following specific network policies that may in turn have an effectof inductive decision changes on the lower level DMEs of individual nodes i.e.down to protocol level decisions. A distributed network-level Control-Loopmay be implemented following the above set-up, while another case of imple-menting a distributed Control-Loop would involve the main Decision-MakingElements of nodes working co-operatively to self-organize and manage thenetwork without the presence of a logically centralized DME or an isolateddecision plane that manages the whole network (i.e. the possibility for per-forming ”in-network” management).

In [2], the Functional Planes of the GANA are defined, namely: the DecisionPlane; the Discovery Plane; the Dissemination Plane and the Data Plane, all ofwhich are inspired by the 4D’s functional planes [5], but are defined differentlyfor the GANA.

4 The way forward

The Autonomic Network Engineering for the Self-Managing Future Internet ISGwill develop ETSI pre-standards and specifications for Autonomic Network Engi-neering for the Self-Managing Future Internet. The activities carried out withinETSI ISG AFI aim to:

– Encourage the harmonization and pragmatism in inviting for contributionsfrom the circles of both the evolutionary approaches and revolutionary ap-proaches to Future Internet design, towards developing common Specifica-tions.

ETSI ISG AFI 9

– Develop a Reference Model of a Generic Autonomic Network Architecturethat defines the autonomic elements and the associated self-manageabilityproperties of the Future Internet. Individuals from both the evolutionary ap-proaches and the revolutionary approaches should be involved in the procesof Reference Model creation.

– Define Interfaces for Governance (i.e. the kind of perspectives offered toend-users or operators of autonomic/self-managing networks, such as theinterfaces of Future Internet nodes/devices that are meant to allow humansto define network-level objectives that govern the operation of an autonomic(self-managing) network under the control of an administrative domain ordomains). Also worthy for consideration is the aspect of interfaces betweenthe Services Layer and the underlying network services. Interfaces shouldbe developed taking account of the need to translate business goals intonetwork-level objectives, and should have a focus on self-management forimproved delivery of services over the network.

– Develop and pre-standardize the GANA Meta-Model, Information Models(including Ontologies, etc), and potentially Policy-based Control Frame-works associated with the Reference Model.

– Define of a viable roadmap of an evolutionary path for today’s network mod-els, architectures, protocols such as IPv6 and paradigms as necessitated bythe Reference Model. The definition of a roadmap of an evolutionary pathshould be achieved through Recommendations that can then be consideredby the relevant Bodies towards the evolution of the protocols recommendedfor evolution or extensions. For this, the ISG would liaise with relevant Bod-ies such as IETF, 3GPP, etc. .

– Develop Advanced Systems Engineering Methodologies for the engineering ofContext-aware autonomic Decision-Making-Elements (DMEs) - potentiallywith cognitive properties, their Control-Loops, etc, including the applicationof methods like the OMG’s MDA approaches and Formal Description Tech-niques (FDTs) towards Simulations and Validations of complex autonomicbehaviours, as well as Code-Generation from formal models of Context-awareDMEs for diverse networking environments, and design principles for the”evolvability” of components (e.g. the DMEs).

– Define Use Cases and Scenarios, which can be used for further refinementsor evolution of both the GANA Reference Model and/or the Roadmap of anevolution path.

– Measure the Benefits of Autonomics/Self-Management: For example, bycarrying out Cost related Calculations or Estimations with respect to e.g.OPEX/CAPEX reduction (savings) and cost savings on shortening Time-To-Market for service/product delivery, thanks to Autonomics/Self-Managementin networks.

5 Conclusion

The reasons given above explain why there is now a need to create a well focusedSpecial Group within a long-established standardization body. Establishing the

10 ETSI ISG AFI

Special Group as an ISG will enable us to attract a large base of most of thekey industrial players who are currently members of the well established Stan-dardization bodies like ETSI. This will also enable the new ISG to liaise withexiting ETSI Groups such as 3GPP, TISPAN, etc. As mentioned earlier the ISGwill need to work in parallel with activities in the ACF, and should also makeits Specifications available to the ACF, while ACF activities that are deemedrelevant by both parties could be processed through the ISG.

References

1. H. Ballani and P. Francis. CONMan: A Step Towards Network Manageability.ACM SIGCOMM Computer Comm.Review, 37(4):205–216, 2007.

2. R. Chaparadza. Requirements for a Generic Autonomic Network Architec-ture (GANA), suitable for Standardizable Autonomic Behaviour Specifications ofDecision-Making-Elements (DMEs) for Diverse Networking Environments. Inter-national Engineering Consortium (IEC) in the Annual Review of Com., 61, De-cember 2008.

3. R. Chaparadza, S. Papavassiliou, T. Kastrinogiannis, M. Vigoureux, E. Dotaro,A. Davy, K. Quinn, M. Wodczak, A. Toth, A. Liakopoulos, and M. Wilson. Cre-ating a viable Evolution Path towards Self-Managing Future Internet via a Stan-dardizable Reference Model for Autonomic Network Engineering. FIA Prague 2009Conference, published in the Future Internet Book produced by FIA.

4. D. D. Clark, C. Partridge, J. C. Ramming, and J. T. Wroclawski. A KnowledgePlane for the Internet. Proc. of ACM SIGCOMM 2003, Karlsruhe, Germany,August 2007.

5. A. Greenberg et al. A clean slate 4D approach to network control and management.ACM SIGCOMM Computer Comm. Review, 35(5):41–54, 2005.

6. T. Bullot et al. A situatedness-based knowledge plane for autonomic networking.International Journal of Network Management, John Wiley & Sons, 2008.

7. B. Jennings, S. van der Meer, S. Balasubramaniam, D. Botvich, M.O. Foghlu,W. Donnelly, and J.Strassner. Towards Autonomic Management of Communica-tions Networks. IEEE Communications Magazine, 45:112–121, October 2007.

8. The FCAPS management Framework. Itu-t rec. m. 3400.9. AFI ISG: Autonomic network engineering for the self-managing Future Inter-

net (AFI). http://portal.etsi.org/afi.10. European IST FP6 ANA(Autonomic Network Architecture) Project.

http://www.ana-project.org/.11. J. C. Strassner, N. Agoulmine, and E.Lehtihet. FOCALE - A Novel Autonomic

Networking Architecture. In proc of the Latin American Autonomic ComputingSymposium (LAACS), Campo Grande, MS, Brazil 2006.