architectures for autonomic communications visa holopainen, [email protected]
TRANSCRIPT
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
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
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
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
The architecture
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
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
1) The mapping of high-level policies to network level objectives2) 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)
The APA architecture
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
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.
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
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 problems1) How to handle a wide variety of systems using external control
2) 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
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
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
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, …)
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
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
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
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
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
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)”
Host-side components
Sentinels retreive dynamic data (like the speed of the node from GPS) and generate events based on the data
Policy master 1) receives events (like Transition-
to-pedestrian-speed-event) from sentinels
2) Decides the possible actions to execute
3) 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
Example sentinel code