Pipeline Publishing, Volume 5, Issue 4

	This Month's Issue:
	Enabling Innovation

The co-Evolution of Networks and Devices: Autonomics and Device Management

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

behaviors of both. Both must respond to external actions with conscribed and pre-determined reactions, but when a human is pushing the buttons, the potential of complex aggregations of behaviors greatly increases. And, of course, service of the device is more difficult, because the expectations of the human drive the satisfaction of service and along with the human capabilities, the utility of any specific fix.

Management processes in this environment are going to be incredibly complex. Cisco has attempted to define all the process needed to configure and support the devices used in their Enterprise Class Teleworker (ECT) product. These were shared in a presentation at the TeleManagement World conference in Nice this year. But this product manages only a subset of devices that will interact and many of the Teleworker participation devices will have lives and roles outside of telecommunicating. Likely, the entire process approach just fails under the weight of this complexity. Some of this can be absorbed into substituting a policy model for process via mechanisms the authors have discussed in earlier papers. But the only full answer must include Autonomics.

We have looked for some out-of-the-box-thinking reference models and toyed with either cars in a system of highways or schools of fish. Both involve autonomous control within the element (fish brain or car driver). One must conform to policy as embodied in traffic law and tradition. The other conforms to policy reactions derived from evolution. Both systems allow the device to learn new behaviors. Both are examples of complexity systems. Small changes in parameters can have large system consequences, or large system perturbations can be damped by systematic minute adjustments in existing policies.

Systems' Models and Autonomic Behavior

The presentations at the Management World's Device Management track put stakes in the ground in our collective search for an encompassing architecture; one that will be the center of a future-proof Device Management Framework. Accenture proposed the New "4Ps": (1) Pods – Digital Networked Devices; (2) Panels – User Interface & Controls; (3) Plexes – Servers for the Data, Content & Services; and (4) Pipes – The Network that links them together. Certainly all these need to be included, but clearly this is just too simple an approach. HP proposed the use of the Resource Description Framework (RDF) of the W3C with its description of devices via Composite Capabilities/preference profiles (CC/PP). Valuable, but just one facet of the jewel we seek. Of those contributed presentations, the future likely lies with the suggestions of the Siemens team to start with and follow on from the work of the European Celtic-Madeira project.

Today's natural advantage of the network service provider is fast eroding. With it might go most opportunities for revenue from providing new services on devices.

"The goal of Madeira is to provide novel technologies for Network Management Systems, enabling them to facilitate the provision of self managed services and networks in a world of increased network scale, heterogeneity and transience... to provide an innovative architectural framework, requisite interface protocols and/or standards and a reference software platform with prototypical implementations for a distributed network management system based on a non-hierarchical peer-to-peer paradigm... [in order] to scale to huge mesh networks, in terms of both the network topology and number of network elements managed."

The Madeira Platform was an architecture of component services that correspond to those usually included in autonomic self-* systems: containers, life-cycle, code distribution, security, notification, directory, persistence, naming, specification, monitoring/health, & policy. They add key additional services similar to those suggested by the 2001 TMForum FineGrain catalyst project implementation: visualization, connectivity and grouping. Central to their architecture was an Adaptive Management Component on board the device, locally serviced by utilities and information repositories.

Unfortunately there have been no postings to Celtic-Madeira web site since 2006 and their program was left incomplete. Hopefully these teams are continuing their work in another venue.

Where we depart from Celtic-Madeira is the insistence that all these services be on-board the autonomic device. Autonomic behavior can also be reached by having the device seek and find these utility services in the network group in which it participates. This is the approach first realized by the now open source Jini Network Architecture. It is also found in the concept of the service registry and realized in Microsoft's CSF.

These services are architectural building blocks, but they themselves do not guarantee an autonomic technical implementation. They must serve a broad concept that all devices interwork in multiple overlapping and/or orthogonal systems. Devices need to become semiautonomous artifacts, controlled by policy to react with adaptive behaviors, including and using well

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.