Architectures for Autonomic Communications

1. Architectures for Autonomic Communications Visa Holopainen, visa@netlab.tkk.fi

2. What is autonomic computing (communications) • Continuous automatic improvement of the system functioning based on measured feedback and pre-defined goals • Any types of improvement goals can be set • Hierarchical systems possible (Managers of manager) • The manager(s) can be software or hardware component(s) • External manager component enhances modularity • The conversion/mapping layer makes the system more platform-independent • The basic concept is simple, algorithms (code) make the difference in any particular autonomic architecture

3. Why autonomic computing • A study made in 2002 estimates that half of all network outages result from configuration errors made by administrators [1] • Most autonomic architectures try to tackle the increasing complexity of network configurations by adding some (complicated) distributed software to the network • Issue: Will there be problems in code base management (security, updates, etc.) • The objective is to get to a point in which only high-level configurations are injected into the network and the network figures out independently what should be done at physical level • Issue: more powerful configuration commands -> more potential for network-wide problems • Solution: architecture should contain reversible operations and should allow easy access for administrators if needed

4. AUTONOMIA: An Autonomic Computing Environment, X. Dong, S. Hariri, L. Xue, H. Chen, M. Chang, S. Pavuluri, S. Rao, 2003 • Provides control and management services to support the development and deployment of smart (intelligent) applications • Application developer can specify the application’s autonomic requirements (e.g. self-optimizing and self-healing) through Application Management Editor (AME) • The next step is to utilize the Autonomic Middleware Service (AMS) to build the appropriate application execution environment that can dynamically control the allocated resources to maintain the application requirements during application execution • Self-healing • For each fault type (system, component or agent), there is a software agent (fault handler) that is responsible for executing the procedures • During the monitoring phase, the appropriate fault handler focuses on detecting faults once they occur • Recovery procedures are run if fault is detected • Self-optimization • Similar software agents than in self-healing

5. The implementation • The mobile agent system (MAS) for Autonomia is designed to provide mobile agents a uniform execution environment independent of the underlying hardware architecture and operating system • Java/Jini platform used • Jini (http://www.jini.org/) • A network architecture for the construction of distributed systems where scale, rate of change and complexity of interactions within and between networks are extremely important • The interaction can use any type of networking technology such as RMI, CORBA, or SOAP

6. The architecture

7. Self-aware management of IP networks with QoS guarantees, F. Krief, 2004 • Self-aware management • Allows network to react and adapt to changes of situation • Operators can focus on defining high-level policies (operational objectives) • Faster & cheaper • Policy-based management • Business policy -> Network level policy -> Low-level policy • Agent may transport business policies so that the negotiation and the decision can be carried out locally (no need for policy exchange protocol) • An architecture was described in the paper that implements the principles of self-aware mgmt and policy-based mgmt • Each logical component improves itself and alerts the component upper in the hierarchy if SLA cannot be satisfied without modifications to upper level objectives • The solution is said to allow the self-configuration, self-provisioning and self-monitoring of service as well as proactive SLA management • No testing, just a framework

11. An automated policy-based management framework for differentiated communication systems, N. Samaan, A. Karmouch, 2005 • Main theme: policy based management • Policies can be created dynamically (in contrast to traditional model in which policies must be created statically) • A framework was proposed to decouple • The mapping of high-level policies to network level objectives • The functionality of adapting network components behavior • The component that takes care of decoupling is Automated Policy Adaptor (APA) • Network operators can inject business objectives to APA using a Graphical User Interface • Users/user applications can also specify requirements to APA in form of policies • User preferences ans business goals for QoS are translated into network-level objectives • APA can modify policies at runtime based on feedback from the network • Novelty of the proposition lies in that given sets of objectives, constraints and policies are assembled at runtime -> flexibility to network control • Both fixed and wireless networks can be handled by the architecture • Slight increase in network throughput when APA was compared to static configuration (using a simulator)

12. The APA architecture

13. The testing scenario (in simulator) • Initially, 40%, 30%, and 30% of the available bandwidth are set for EF, AF, and BE, respectively, for domains A, B, and C • Traffic was generated from D to A with sending rate of 6 Mb/s, while A is moving from domain A to B at t=50, and then from B to C at t=80 • As the user moves from one domain to the other, the policy P is translated to different network-level objectives by the APA at domain A depending on the location of the user. • See the paper for detailed testing parameters

14. Simulation results • Throughput comparison between the statically configured network and the proposed scheme. (a) = Achieved throughput in case of static configurations. (b) = Achieved throughput in case of APA.

15. An Architecture for Coordinating Multiple Self-Management Systems, S. Cheng, A. Huang, D. Garlan, B. Schmerl, P. Steenkiste, 2004 • Some possible self-management systems and their responsibilities • Self-configuring system • Adapt automatically to changes in the environment • Self-healing system • Discover, diagnose and react to disruptions • Self-optimizing system • Monitor and tune resources automatically • Self-protecting system • Anticipate, detect, identify and protect itself from attacks • How to deal with (possibly) conflicting decisions coming from different self-management modules? • Solution: separate logical layers for data presentation (translation) and system access

17. Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure, D. Garlan, S. Cheng, A. Huang, B. Schmerl, P. Steenkiste, 2004 • Mechanisms that support self-adaptation currently exist in the form of programming language features such as exceptions and in algorithms such as fault tolerant protocols • These mechanisms are often highly specific to the application and tightly bound to the code. As a result, self-adaptation in today’s systems is costly to build, difficult to modify, and usually provides only localized treatment of system faults • The Rainbow-architecture tries to solve two problems • How to handle a wide variety of systems using external control • How to make 1) in a cost-effective manner • The solution: re-usable infrastructure with a mechanism to customize the infrastructure to particular application’s needs

18. Reusable Rainbow units • System-layer infrastructure • Low-level system information can be published by or queried from the probes. Additionally, a resource discovery mechanism can be queried for new resources based on resource type and other criteria • Architecture-layer infrastructure • Gauges aggregate information from the probes and update the appropriate properties in the architectural model • Translation infrastructure • Translation repository maintains translations

19. Architectural style • While reusable infrastructure helps reduce the costs of adding self-adaptation to systems, it is also possible to leverage commonalities in system architecture to encapsulate adaptation knowledge for various system classes • To capture system commonalities, Rainbow adapts the notion of an architectural style • An architectural style characterizes a family of systems related by shared structural and semantic properties

20. Case study 1: Client-server system • The client and server components are implemented in Java and provide remote method invocation (RMI) interfaces for the effectors to use in performing adaptation operations • Clients connected to a server group send requests to the group’s shared request queue, and servers that belong to the group grab requests from the queue • Focus on response time that clients percieve • Architectural style created for the system (Client.responseTime, Server.load, ServerGroup.load, Link.bandwidth, ServerGroup.addServer(), Client.move(),…) • If response time for a client is too long, the Adaptation Engine executes a response strategy (move client to another group, add server to group, …)

21. Towards a Model-Driven Architecture for Autonomic Systems, D. Gračanin, S. Bohner, M. Hinchey, 2004 • COUGAAR • Agents (program code) running on Java virtual machines • Virtual machines are located in nodes of the network • Tasks sent between agents • One must locate the most suitable agent for the task • COUGAAR supports hierarchical task decomposition • COUGAAR provides facilities to measure and propagate performance metrics collected at all levels of the architecture • Platform specific measurements are taken by the computer system level instrumentation and are translated into device-independent values. • Measured data is used by a Servlet (web) and adaptation engine • provides adaptive control through the Adaptivity Engine that makes use of the measurements collected by the metrics service • COUGAAR agents • An agent consists primarily of a blackboard and a set of plugins. The blackboard is essentially a container of objects that adheres to publish/subscribe semantics • Agents can move from one node to another through serialization

22. Autonomic WWW Server Management with Distributed Resources, T. Araki, 2004 • Problem: Computing resources aren’t share effectively across organization boundaries (only within organizations) • Solution: A working and tested concept that provides means to share computing (server) resources across organization boundaries • Computing resources are rented from different organizations (new business model) • Supports J2EE systems • Main component: Autonomic Web Server Manager • Monitors QoS (response time to client requests) • Autonomically manages the computational resources (addition, removal) based on the response time

24. Hierarchical Model-based Autonomic Control of Software Systems, M. Litoiu, M. Woodside, T. Zheng, 2005 • A system to • Autonomically react to workload changes • Search for resource-optimal configurations • Used in • Information- and transaction-based software applications • E-commerce, insurance claim submission, web banking, etc. • Provisioning Controller • Adds and removes hardware components to the system at runtime (for example web servers to a cluster) • Application Contoller • Balances resources and workload across system • Component Controller • Adjusts components’ run time parameters to achieve desired QoS level

26. A Framework for Self-Management of Hybrid Wireless Networks Using Autonomic Computing Principles, C. Shen, D. Pesch, J. Irvine, 2005 • Hybrid Wireless Networks • Scalable and adaptive wireless network architecture utilizing a mixture of cellular and ad hoc multi-hop routing (less base stations needed) • Drawbacks: routing complexity, radio resource heterogenity, network infrastructure design growth -> difficult to manage • A framework proposition for the autonomic management of hybrid wireless networks • In the paper the authors state that they are going to use Artificial Intelligence techiques (neural networks, fuzzy logic and Q-learning) in the management of hybrid wireless networks to ease the management burden • Q-learning • A variant of reinforcement learning • Autonomy is supposed to be implemented at MAC, routing and application levels independently • No algorithms, implementation or testing is presented

27. Autonomic system for mobility support in 4G networks, P. Vidales, J. Baliosian, J. Serrat, G. Mapp, F. Stajano, A. Hopper, 2005 • Excellent paper with detailed description of the concept • Access technologies in 4G networks will be heterogenous (Satellite, UMTS, IEEE 802.16a, IEEE 802.11, etc.) • Heterogenous networks introduce additional complexities • Many different types of available access points, handover triggered by multiple events, execution methods depend on context, etc. • More intelligence needed to handle these complexities • An architecture called PROTON was presented • The architecture is supposed to • ”know” itself, it’s environment and context • Configure and reconfigure itself under varying and unpredictable conditions • Optimizes it’s functionality constantly • … • Architecture divided to network- and host side components

28. Network side components • A policy specification language is used by operator to insert policies to the network side of the architecture through the policy editor • Model Deployment Module sends suitable policies to mobile devices Policy master that acts as a PDP • Sending is done by sending a Java object through JNI • An example of a policy: ”Mobile devices that are treveling at speeds over 90 km/h should never connect lo lower level access point (like from GSM cell to WLAN-hotspot)”

29. Host-side components • Sentinels retreive dynamic data (like the speed of the node from GPS) and generate events based on the data • Policy master • receives events (like Transition-to-pedestrian-speed-event) from sentinels • Decides the possible actions to execute • Sends these actions to the Enforcement Layer • Enforcement Layer acts as a PEP • The Enforcement Layer captures router advertisements before they reach the IPv6-handover-module and hand only ”legal” information to the hadover procedure

30. Example sentinel code