From Autonomic Computing to Autonomic Networking

From Autonomic Computing to Autonomic Networking: an Architectural Perspective David Raymer1, John Strassner1, Sven van der Meer2 Motorola Labs, Network Infrastructure Research Lab Schaumburg, IL, USA {david.raymer, john.strassner}@motorola.com 2 TSSG, Waterford Institute of Technology Waterford, Ireland [email protected]

1

Abstract This paper aims to provide a roadmap on how to extend our understanding of the biological analogy applied to a single computing platform (Autonomic Computing) towards a larger scale of a network supporting distributed application sets. We will draw from our experience in autonomic networking and autonomic management, and discuss how the ACF Architecture Expert’s Group plans to provide architectural specifications and guidelines that allow for the modeling, design, implementation and deployment of an autonomic network.

1 Introduction When applied to computer-based systems and networks (CBSN), self-healing is one aspect of the set of capabilities exhibited by autonomic computational systems. It is often represented by the phrase self-*, which include self-protecting, self-configuring, selfhealing, and self-optimizing [11]. The basics of autonomic computing, as established by IBM and others, draws on biology to describe an autonomic computer as a computer that is self-governing, in the same manner that a biological organism is selfgoverning [12]. In the wild, biological organisms compete for resources, which is the fundamental basis that lead Darwin to his theories on the origin of species through a process Darwin dubbed natural selection [1]. Obviously, the application of concept of survival of the fittest to a computer network is dangerous, since this connotes the ability of one element within the computational system to starve another element of resources that it needs, to the benefit of the first

element and the detriment of the second element. This is certainly not ideal, and will likely lead to undesirable consequences in terms of the ability (or lack thereof) of the entirety of the system to accomplish the purpose or purposes it is intended to serve. In [2] and [11], the authors state that in order for a system to be autonomic, the self-awareness embodied by being self-protecting, self-configuring, self-healing, and self-optimizing is insufficient. In fact, to enable the creation of self management systems, the autonomic elements within the system must also be environmentally-aware. Environmental awareness is manifested as three additional capabilities: knowledge of itself and the environment, self-monitoring, and self-adjusting. A common representation and understanding of knowledge is crucial for autonomic operation, since this provides common information for what the capabilities of the system are, what functionality is required of it by its users, and what limitations are imposed on the system by the environment. Therefore, for the purposes of this paper, an autonomic computer-based network or system is one that is self-configuring, self-optimizing, selfprotecting, self-healing, self-monitoring and selfadjusting. Collectively, this set of capabilities enables self-governance. In order to standardize an architecture that enables self-governance, it must be possible to specify all aspects of said architecture in a normative fashion. The ultimate goal of the ACF Architecture Expert Group (AEG) is to produce a set of specifications and models that define a normative reference architecture for self-governing computer based systems and networks along with a set of guidelines for how that reference architecture can be used to build autonomic

networks of autonomic computer based systems. A normative specification of such an architecture requires that the structure, capabilities, and behaviors of a system that conforms to said architecture be captured in a non-ambiguous declarative format that can be correctly and completely understood by both practitioners and automated tooling. This ensures that specifications of the architecture of the autonomic system can be conceptualized by the architects and captured in tooling such that the models of the architecture do not omit any concepts identified by the architects and that the models of the architecture do not introduce side effects into the concepts.

2 State of the Art As previously noted, the fundamental problem facing the AEG is the specification of a normative reference architecture for autonomic networking and communications which can be used to build a basis of interoperability, scalability, and extensibility as well as an objective measurement of compliance. Historically, reference models of networking and communication reference architectures have been informal block diagrams which require subjective analysis against a given system in order to determine compliance or lack thereof. The lack of an objective capability to assess and measure compliance in networking and communication reference architectures inevitably leads to interoperability problems between supposedly compliant implementations of a given reference architecture. From the perspective of the research community there has been some amount of effort to develop models and reference models for autonomic computer based systems and networks. One of the preeminent efforts has been in the wireless realm, and is called POEM [6], the Performance-oriented Reference Model for Autonomic Wireless Communication. POEM features a novel, declarative top-down approach to enable through the application of policy and closed loop control. The POEM reference model is constructed using the OPNET Modeler and does not represent a general purpose solution which can be easily standardized. It is, however, very well suited to simulation and experimentation, and the numerous papers produced as part of the POEM project provide a rich source of information and experience from which the ACF will be able to draw. The European Union has supported research for Autonomic Networking and Communications within several projects of the 6th Framework Programme (FP6), namely CASCADAS and ANA. CASCADAS,

started in 2006, investigates new conceptual serviceoriented architectures for the next generation Internet. The main goal of CASCADAS is to develop an innovative component model to support the creation of autonomic systems. ANA focuses on the development of a post-IP approach for networking. Static IP protocol stacks will be replaced by variable composable networking functions. Network nodes will grouped into so-called compartments (e.g., domains with a common set of functions, policies, and mechanisms). ANA has released documentation on autonomic functional blocks and information flow specifications, which provide a substantial technical basis for post-IP and autonomic networks. In the industrial/standardization space, there has not been, to date, specific efforts to establish a standardized reference architecture for autonomic computer-based systems and networks. However, there has been a flurry of work with regards to the establishment of standardized reference architectures for computer-based networks and systems, particularly in the information technology and telecommunications sectors. Beside two now historic standards, RM-ODP and TINA, the TeleManagement Forum NGOSS program as described in [8] and [9] has a wellarticulated methodology to address the needs of different stakeholders (e.g., business, system, etc.) throughout the lifecycle of a solution. Previous and current efforts [11] have addressed the potential link between NGOSS and autonomic computing, but have not addressed how to manage and integrate diverse knowledge present in the environment. One of the difficulties in dealing with complexity is accommodating legacy hardware and software. Current approaches to network configuration and management are technology-specific and network-centric, and do not take business needs into account. For example, SNMP and CLI are currently unable to express business rules, policies and processes, which make it impossible to use these technologies to directly change the configuration of network elements in response to new or altered business requirements [11] [21]. This disconnects the main stakeholders in the system (e.g., business analysts, who determine how the business is run, from network technicians, who implement network services on behalf of the business). One paradigm is common amongst all efforts in specifying autonomic systems: an autonomic operation of a system or component is achieved using a selfadjusting control loop [11], [12]. Inputs to the control loop consist of various status signals from the system or component being controlled, along with (usually policy-driven) management rules that orchestrate the behavior of the system or component. Outputs are

commands to the system or component to adjust its operation, along with status to other autonomic systems or components. For an extensive summary in the state-of-the-art of autonomic networking the reader is referred to [10] and [13]. Both publications analyze the fast-moving area from different angles, [10] providing an overall survey and [13] focusing on recent, specific advances in the field of autonomic communications.

3 A Notional View of the ACF Autonomic Networking Architecture The straw-man notional view of the ACF Architecture can be quantified as a component-based distributed interface oriented architecture [9]. The ACF architecture is inspired by the FOCALE architecture, as described in [5]. The promise of autonomics as applied to large scale distributed computer-based systems and networks is to remove or mitigate the decreased reliability of such systems that arises from the cumulative of effect of errors in the myriad disparate components of said system.

3.1 Foundation We contend that the essence of autonomic management is the ability for a system to self-govern

its behavior, but only within the constraints of the (human-specified) goals that the system as a whole seeks to achieve. The ACF has initiated two working groups (the Policy Expert Group and the Semantics Working Group) that investigate how the use of information and ontological modeling can capture knowledge relating to network capabilities, environmental constraints and business goals/policies; this knowledge is then used and enhanced by various reasoning and learning techniques. Hence, the knowledge base is not static, but instead is inherently dynamic, enabling the knowledge base to accommodate new knowledge as well as correcting existing knowledge. Knowledge embedded within system models is used by policy-based network management systems incorporating translation/code generation and policy enforcement processes that automatically configure network elements in response to changing business goals and/or environmental context. This realizes an autonomic control loop in which, as depicted in Figure 1, the system senses changes in itself and its environment, analyses this information to ensure that business goals and objectives are being met, expedites changes should these goals and objectives be threatened, and, closing the loop, observes the result. We believe that the combination of information and ontological modeling will deliver considerable improvements over existing manually configured

Business Goals/Policies K now le dge Information Processing

Learning & Reasoning

Ontologies

Foundation

Observe

Compare

B usiness P olicies

Act

Policy Processing Analysis

Behavior

Knowledge Generation / Analysis

Conflict Elaboration

Policy Continuum Business

Contracts

Policies Services

Processes

Patterns

System Conflict Detection

Administrator Device

Conflict Resolution

Resources

Instance

Deployment

C ontext

C onfiguratio n

Communications Networks

Communications Networks

Figure 1. Conceptual Autonomic Control Loop

network management systems, since it will support context-driven reconfiguration of networks with minimal human intervention at all but the high-level business view [5] [11] [21]. Nevertheless, in order to deliver full autonomic networking capabilities, we believe it is also necessary to introduce decentralized processes and algorithms into the network infrastructure to maintain optimal or near-optimal behavior in terms of global stability, improved performance and adaptability, robustness and security. As described by Babaoglu et al. [14], many of these processes and algorithms can be modeled on various biological processes found in the natural world. However, to ensure that they act in accordance with business goals, we argue that such processes and algorithms should themselves be modeled, so that their operation can be automatically configured via appropriate management policies. The next section shows the transition from the Autonomic Loop towards a conceptual representation of an autonomic network system.

3.2 Conceptual Representation of an Autonomic Network System Figure 2 presents a conceptual representation of an autonomic network system. Its autonomic control loop is enabled by the presence of one or more system models and ontologies that abstract the static structure, functionality, and dynamic behavior of the underlying network infrastructure, management functionality, and Context Manager Normalized Information

Policy Context Information C ontrol

Normalized Data

Model-based Information Processing (Semantic Fusion and Normalization)

Policy Manager

Business Goals

User Interface

C ontrol App licatio n of In te llige nce

Autonomic Manager C ontrol

Analyze Data and Events

Maintenance

S upp ort

offered services. These models and ontologies are continuously updated by the Model-based Information Processing component in response to the changing operational context of the network. This component gathers raw context information from managed resources (e.g., SNMP alarms) and, using various analysis techniques, infers the impact, or potential impact, of this information (e.g., a network failure means that customer X is not being delivered the QoS level indicated in their SLA for service Y). It then passes normalized data relating to current operational context to the Event Analysis component, which employs ontological engineering, in conjunction with learning and reasoning techniques, to analyze whether the system’s actual state corresponds to the desired state (as indicated by currently deployed set of policies). The control loop described above is controlled by an Autonomic Manager, which influences the deployment of the policies that effect decision making within the loop. The entire system, but particularly the Model-based Information Processing component, is reliant on the presence of information and data models that embody the knowledge necessary to represent managed resources (routers and other network devices) and their control using autonomic principles. The knowledge derived from the models is augmented with knowledge from one or more ontologies, thereby enabling semantic reasoning to be performed [5] [11]. Finally, we note that the model-centered approach outlined above primarily provides for explicit control

C ontrol

Compare Actual State to Desired State

Adjustment

S upp ort Learning and Reasoning Ontological Comparison

S upp ort

Model-based Policy Processing (Policy Continuum)

DEN-ng Models and Ontologies

Vendorspecific Data

Vendorspecific Configuration

Managed Resource(s)

Figure 2. Conceptual Representation of an Autonomic Network System

Autonomic Management Element Eve nt State Action Manager Manager Manager R easo ner Autonomic Manager

DEN-ng Information Model Object Models

L ea rner

System Ontology

Policy Analyzer & PDP

Vendorneutral Data

System Policies

Vendor-neutral Commands

Model-based Translation Layer Vendorspecific Data

Vendor-specific Commands

Managed Resource(s) Figure 3. FOCALE Autonomic Network Management Element of network behavior and, as such, can be viewed as an evolution of traditional network management approaches. However, this approach is limited by the capabilities (and configurability) of the network devices and the ability to maintain up-to-date information and ontological models of very complex and highly dynamic network topologies. True autonomic network management will, we believe, additionally require the deployment of processes and algorithms within network devices themselves. These would act in a highly distributed manner, serving to optimize network behavior with respect to stability, performance, robustness and security – in effect providing the kind of self-management functionality. A more detailed description of the conceptual representation can be found in [15].

3.3 A Brief Examination of FOCALE In [5], Strassner, et al, provide the following description of the FOCALE architecture. “FOCALE stands for Foundation, Observation, Comparison, Action, and Learning Environment. [It] … assumes that any Managed Element (which can be as simple as a device interface, or as complex as an entire system or network) can be turned into an Autonomic [Management] Element (AME).” In other words, an AME is FOCALE’s modular building block, which shields the vendor-specific nature of the managed resource from the autonomic system and vice versa. This is done by interfacing the functionality of the managed resource to the functionality of the

Autonomic Manager (AM) using a Model-based Translation Layer (MBTL), as shown in Figure 3. By embedding similar (interoperable) AM and MBTL engines into each AME, we provide uniform network (management) functionality throughout the whole Autonomic Network System. As Figure 4 shows, AMEs can be modularized to first form a uniform Autonomic Management Domain (AMD), and then to an Autonomic Management Environment; with each level containing policy, security, discovery, context, and analysis services that serve to harmonize the operation of the AMEs/AMDs. Each AM realizes the autonomic network (management) functionality via an Event Manager, a State Manager, an Action Manager, a Reasoner, a Learner, and various policy components, such as a policy analyzer, policy decision component, policy execution component, and policy verification component. All these sub-components can communicate with each other and have access to the overall information model (we currently use DEN-ng [21], which will later be replaced by the ACF standard information model; note that DEN-ng serves as the main input to the ACF) . When the AM receives sensor information via the MBTL, it tries to attach a context to this information. This enables the Policy Analyser to better understand the significance of the sensed data. The Policy Analyser then examines the information, applies any inferencing that is required, and then looks to see if the conditions of any deployed policies are satisfied. If they are, those policies are triggered by

constructing an appropriate event. If not, monitoring continues. If the context is not recognized, then the AM contacts the Event and State Managers. If the system is not in a desired state, the State Manager employs the Reasoner to identify actions that will lead the system back towards a desired state. The Action Manager coordinates the enforcement of these. Subsequently, the Learner monitors the effectiveness of actions identified in this manner; if successful, these actions are codified as one or more policies that are then added to the set of system policies. The AM can also seek the help of other AMs (e.g., look at global data to establish the state) to coordinate activities such as analysis of global network state, or introduction of new policies.

3.4 An Exemplar Application of FOCALE Motorola has realized a case study, applying FOCALE in a complex environment, namely beyond 3G (B3G) networks. This environment enables user access to a portfolio of Internet Multimedia Subsystems (IMS) services from a variety of different access networks (UMTS, WiFi, WiMax, DSL), owned by different operators. The deployed Management systems are likely to be heterogeneous even for the same technology, as operators are not necessarily using the same management system and, more importantly, not the same information model. Hence, supporting end-to-end quality of service is a big challenge for service providers. The management of this environment can became very complex, as the number

of components to manage individually and globally can be large and complex, going well beyond the capacity of the human operators. Figure 5 shows the B3G domains. For sake of simplicity and brevity, rather than examining how the FOCALE architecture can be applied to all the domains, we will focus on the domains most relevant to the core business of a wireless network equipment provider – the Access Network domains (using a DSL access network and a mobile access network), the Core Transport Network domain, and the IMS domain. The concepts of this paper are applied as follows: • the Autonomic Management Environment ensures end-to-end service assurance • the Autonomic Management Domain (AMD) is responsible for the autonomic management of a particular administrative domain • the Autonomic Management Element (AME) which is responsible for the autonomic management of resources (note that AMEs can be contained inside other AMEs, and are also contained in AMDs) There are a number of ways to decompose the above environment into domains. For example, a bottom up approach, starting from the Managed Element, can be defined, where the granularity is a function of the AME and the minimum size of the AMD. Then, each AME can be grouped into an AMD; each AMD can similarly be recursively grouped into an Autonomic Management Environment. A provider can thus manage the appropriate entity (AME, AMD,

Autonomic Management Environment Event Service Policy Service

Policy Service

Context Service

Analysis Service

Autonomic Management Domain

Event Service

Event Service

Security Service

Autonomic Management Element

Reas oner

Discovery Service


E vent S tate A ction Manager Manager Manager

Autonomic Manager

Security Service

Learner


Discovery Service

Context Service

Analysis Service

Autonomic Management Element E vent S tate A ction Manager Manager Manager

Reas oner Autonomic Manager

Learner


Policy Service

Security Service

Discovery Service



Learner


Context Service

Analysis Service



Learner


Model-based Translation Layer




Managed Resource(s)

Managed Resource(s)

Managed Resource(s)

Managed Resource(s)

Figure 4. FOCALE Autonomic Management Environment

Application Server Plan

AS

Sh

Signaling Media Session Control Plan

Cx UE

Gm

P-CSCF

Mk

Mw

I-CSCF

Cx

Mw

Mi S-CSCF

Mr

BGCF

Mj

Mb Mb

(transit) Core Transport Network

Mb

Autonomic Management Environment

MRFC

Mn

Mb

Core Transport Network

PSTN

MGCF

Mn

MRFP

AME IP Connectivity Access Network DSL, 3G, Wifi,

PSTN Transport

ISC

HSS

Core Transport Network

MGW

Mb Mb

Autonomic Management Domain Other IPnetwork

Figure 5. The 3GPP Beyond 3G Reference Network Architecture networking domain. At the top level, the business or management environment) that best corresponds to objectives described in term of goals are enforced in their real-world deployment. It is also possible to the autonomic system and translated down to the construct an management environment to reflect a managed resource. This translation is realized by the cross-domain system; however, the relation between Policy Continuum [16] [21], which guides the AMDs can be very complex as only a limited behavior transformation of goals into policies, which contain adaptation (through goal enforcement) can be actions that are enforced at the appropriate control permitted between the various AMDs (i.e., in case of a point. virtual service provider operating on the top of several In this use case, dominant relationships can be network provider operators). Figure 6 gives an found between autonomic domains inside the UMTS example of the FOCALE instantiation in this complex domain, while peering relations can be found in the environment that shows how recursive process can be case of the Autonomic Management Environment applied top-down and/or bottom up to build an end-towhere the underlying AMDs could be operated by end IMS services autonomic environment. Note that different operators (e.g., the management environment the autonomic capability that has been added to each operated by the service provider and the AMD network domain is just that, an addition. The existing operated by the UMTS operator, WiMax operator or network elements identified in each domain are not DSL operator). changed by the application of autonomics. This is a key feature of the FOCALE approach, and the primary reason for selection of FOCALE as the basis for the 4 The ACF Architecture Expert’s Group ACF architecture. FOCALE was intended from its inception to be equally applicable to previously The ACF has chartered the Architecture Expert deployed networks, planned network deployments, and Group to develop a framework of methodologies, future network deployments. models, documents, implementations, and testbeds that The recursive deployment of FOCALE architecture collectively enable interested parties to develop simplifies managing a complex B3G network solutions for Autonomic Communications. environment. A bottom-up approach starts turning network equipment and servers into AMEs, and then 4.1 The Goal grouping the AMEs into an AMD. The service provider can start with a top-down approach defining The rationale of this goal is that technological the high-level Autonomic Management Environment; trends and societal demands both require software, the system then maps this definition to the desired systems, and services that are autonomic, selfbehavior of the AMDs. The actions at this level will adapting, and self-managed. They are autonomic by become goals at the lower level, and so forth, until we means of interactions with the user, with resources, reach AMEs. Then, each operation is transformed by and with other services. They are self-managed by the MBTL into models whose behavior is orchestrated means of configuration, scalability, fault tolerance, and through reconfiguration. Each operator will define his security. The underlying communication environments own business goals to enforce in his autonomic

Autonomic Management Domain Event

Policy Service

Security Service

Service

Context Service

Discovery Service

Analysis Service

Autonomic Management Domain Event Service Policy Service

Security Service

Discovery Service

Context Service

ACE


ACE

Event

UMTS UMTS Network Network SGSN Domain Domain

UE

Analysis Service

Policy Service

GGSN

Security Service

Service

Discovery Service

Context Service

Analysis Service

ACE

ACE


AS

Event Service Policy Service

Security Service

Discovery Service

Context Service

IMS AR

ACE

ACE

WiMax WiMax Network Network Domain Domain

UE

IP CN BB

WAG

Security Service

Discovery Service

PC

Context Service

Analysis Service

ACE

DSL DSL Access Access Domain Domain

ACE

AS

Core DiffServ/MPLS IP

Event Service

ACE

IMS IMS Domain Domain

AS

Autonomic Management Domain Policy Service

ACE

ACE

Analysis Service

UMTS: Universal Mobile Telecommunication System IMS: IP Multimedia Subsystem GGSN: Gateway GPRS Support Node AS: Application Server AR: IMS Access Router

AR

Figure 6. Mapping FOCALE to an Exemplar B3G System can be characterized by the term ‘disappearing infrastructure’. This reflects the constant evolution of communication infrastructure to become more and more invisible to the users (and service providers), which in turn means that they are evolving towards a self-managed environment that follows business goals.

4.2 The Mission The mission of the AEG comprises three parts: a) support the evolution of the ACF towards an internationally recognized standards body by leveraging Academia and Industry; b) develop a holistic view of the who/what/where/when/why/how of Autonomic Communications; and c) strengthen the influence of the ACF as a key element of the information society.

4.3 Structure of Deliverables The output of the AEG will be a set of deliverables. Each deliverable will be classified by packages, describing: • Requirements and concepts, • Technology neutral specifications, and • Mapping to technologies. Each package must contain a document describing the package by means of: motivation, goal, approach, definitions, results, experiments, annexes for references, and other required documentation, and may contain one or more of the following components: • Definitions and specifications in an agreed graphical representation • Models and Specifications in an agreed graphical representation and/or in an agreed textual format

• Implementations or part of implementations in an agreed descriptive, scripting, or programming language, plus documentation • Descriptions and/or Specifications in an agreed format that explain how the package can be tested and/or simulated • Showcases, best current practice documents, studies, and other material that might help to understand the concepts and results of the package

4.4 First Phase Output The following list of deliverables is required for the first phase of the AEG: • Baseline document specifying and explaining the documentations of the AEG, introducing structure and concepts for each type of deliverable • Baseline documentation that specifies and explains the underlying methodology used in the deliverable • Baseline documentation that specifies and explains the underlying architectural concepts • Documentation that captures the ACF requirements with regard to architectural concerns, based on contributions from other ACF groups

4.5 Current Work Items of the AEG The AEG started working at the end of 2007. The first item on our agenda is, as discussed and advised by the ACF Architecture Board, to provide documentation on the concepts and principles of Autonomic Communication Environments. This document will provide a normative reference model and definition of the architecture of such environments, acting as a “Rosetta Stone” for the set specifications that will be subsequently developed by the AEG. In other words, this document will serve as the seed document from which subsequent specification requests will be developed.

5 Conclusions and Next Steps One obvious conclusion is that the ACF AEG has a great deal of work in front of it. However, the AEG already has some very experienced members who have taken part in similar efforts, thus enabling the application of “lessons learned” to help jump start this group. Another reason for optimism is the emphasis on collaboration between academia and industry. In fact, the bylaws of the ACF mandate that all working and expert groups (which develop non-normative and normative specifications, respectively) must from their inception have two co-chairs, one from industry and

one from academia. This enables the ACF to balance research with products. Outside of beginning work on the first phase output, the co-chairs of the ACF AEG will be spending a great deal of effort to expand the membership in the AEG. In some ways, this paper represents the beginning of that recruitment effort. If your university, college or company is interested in finding out more about the ACF and/or participating in the work of the AEG, please contact one of the authors.

6 Acknowledgements This work is partially sponsored by Science Foundation Ireland under under grant number 03/CE3/I405.

7 References [1] C. Darwin. “On the Origin of Species by Means of Natural Selection, or the Preservation of Favoured Races in the Struggle for Life” 1859. Accessible online at http://www.literature.org/authors/darwin-charles/the-originof-species/ [2] M. Hinchey, R. Sterritt, “Autonomicity – an Antidote for Complexity?” Proceedings of Computational Systems Bioinformatics Conference, Workshops and Poster Abstracts. IEEE, August 2005, pp. 283-291. [3] C. Szyperski, “Component Software, Beyond ObjectOriented Programming”. ACM Press, Addison-Wesley Publishers, Pearson Education Limited, 1999., [4] F. Bachman, et al., “Volume II: Technical Concepts of Component-based Software Engineering” 2nd. Edition. CMU/SEI-2000-TR-008, May 2000. [5] J. Strassner, N, Agoulmine, E. Lehtihet, “FOCALE - A Novel Autonomic Networking Architecture”. The Latin American Autonomic Computing Symposium (LAACS 2006) Campo Grande, MS, Brazil, July 18-19, 2006. [6] http://www.ibr.cs.tu-bs.de/projects/poem/ [7] T. Marshall and Y.S. Dai, “Reliability Improvement and Models in Autonomic Computing”, Proceedings of Intl. Conf. on Parallel and Distributed Systems, 2005. pp. 468472. [8] TMF (Ed: Joel Fleck), “The NGOSS Lifecycle and Methodology”. GB927, Ed. NGOSS R6.0, Document Version 4.5, November 2004.

[9] TMF (Ed: Sven van der Meer), “NGOSS Technological Neutral Architecture”. TMF053, Ed. TNA Release 6.3 (NGOSS R6.1), Document Version 5.7, November, 2006. [10] S. Dobson et al., “A Survey of Autonomic Communications”, ACM Transactions on Autonomic Adaptive Systems, Vol. 1, No. 2, Dec. 2006, pp. 223-259. [11] J. Strassner, “Autonomic Networking – Theory and Practice” [tutorial], Proc. 2008 IEEE/IFIP Network Operations and Management Symp. (NOMS 2008), IEEE, April 2008. [12] IBM, “An Architectural Blueprint for Autonomic Computing”, v7, June 2005 [13] M. Calisti, S. van der Meer, J. Strassner (Eds.), “Advanced Autonomic Networking and Communication”. Whitestein Series in Software Agent Technologies and Autonomic Computing. Birkhäuser, Basel, 2008 [14] O. Babaoglu et al.: “Design patterns from biology for distributed computing”, ACM Trans. Auton. Adapt. Syst., vol. 1, no. 1, Sep. 2006, pp. 26-66. [15] B. Jennings, S. van der Meer, S. Balasubramaniam, D. Botvich, M. Ó Foghlú, W. Donnelly, and J. Strassner: “Towards Autonomic Management of Communications Networks.” IEEE Communications Magazine, Vol. 45, Issue 10, October, 2007, pp 112-121. [16] K. Barrett, S. Davy, J. Strassner, B. Jennings, S. van der Meer, and W. Donnelly, “A Model Based Approach for Policy Tool Generation and Policy Analysis”. in Proc. of 1st IEEE International Conference on Global Information Infrastructure (GIIS 2007), Marrakech, Morocco, July 2-6, 2007, IEEE Press: pp 99-105, ISBN 1-4244-1375-3. [17] http://www.cascadas-project.org/ [18] http://www.ana-project.org/ [19] ITU-T, “RM-ODP – Reference Model for Open Distributed Systems”, X.900 [20] TINA – Telecommunication Information Networking Architecture – http://www.tinac.com/ [21] J. Strassner, “Policy Based Network Management”, Morgan Kaufman Publishers, Sept. 2003, ISBN 1-55860-859