Architectures for Autonomic Communications

1
Architectures for Autonomic Communications

• Visa Holopainen, visa_at_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 -gt
  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
  applications 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 -gt Network level policy -gt
  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

8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
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 -gt 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 t50, and then from B to C at t80
• 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

16
(No Transcript)
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 todays 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 applications 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 groups 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. Gracanin, 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 arent 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

23
(No Transcript)
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

25
(No Transcript)
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 -gt 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, its environment and context
• Configure and reconfigure itself under varying
  and unpredictable conditions
• Optimizes its 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-spe
  ed-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