Multiplex communications – Network configuration determination
Reexamination Certificate
1999-05-14
2002-12-10
Ngo, Ricky (Department: 2664)
Multiplex communications
Network configuration determination
C370S465000, C709S220000, C709S223000
Reexamination Certificate
active
06493323
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to the configuration control of highly reliable distributed systems and, in particular, to a system for providing asynchronous configuration control of highly reliable, distributed systems, using an object oriented paradigm.
PROBLEM
It is a problem in the field of highly reliable, distributed systems to provide a consistent and easily managed maintenance environment. As the world of highly reliable computing continues to expand with many vendors providing products, it is desirable to combine a number of these highly reliable computing products to implement a more complex system to obtain increased computing power, broader functional scope and physical distribution. The problem with combining off-the-shelf hardware and software into a highly reliable distributed computing system is that none of these products are designed to be combined into a large/complex highly reliable system with other vendor products. Each vendor's product has its own maintenance environment and all of them assume they are under the intelligent control of “someone else”. That is, in a system environment, each subsystem has no way of knowing what other system elements are dependent upon that subsystem. Thus, even if a single subsystem is reliable, it is easy to make a mistake during routine maintenance or fault recovery and remove, restore or switch the wrong subsystem bringing the entire system down. The larger and more complex systems become, the more critical this issue of subsystem interaction becomes.
Coordination of maintenance activities (e.g., removal or restoral of units) is typically the job of the Configuration Control component of the system. Configuration Control assures that inter-subsystem dependencies are taken into account when reconfiguring the system to perform maintenance or recover a faulty unit. Typically, even in systems which are wholly developed by a single vendor, the Configuration Control is fractured along some functional boundaries. When this is done, inevitably each function has its own notion of subsystem states, request interfaces, behavior and control hierarchy. Furthermore, systems are almost always centrally controlled. So, if the central control is lost, maintenance operations in the individual subsystems must be halted.
Making these disparate subsystems in a complex system communicate with each other to coordinate activities and communicate with a user interface is exceedingly challenging and expensive. Since each subsystem has its own view of state, behavior, relationships, and request interfaces, there is no standard protocol for one subsystem to establish a relationship and request services of another subsystem. Each interface is a custom development and therefore, any change affecting these interfaces causes major coordination headaches. The software which controls these subsystems is typically developed with an assumed configuration and behavior. That is, the subsystem configuration and its response to a maintenance stimulus is hard-coded. Changing a system comprising a plurality of individual subsystems is very costly and usually entails years of work. Consequently, technological evolution is impeded because it is expensive and takes a long time.
The prior art solution to these problems is to write custom Configuration Control software for every subsystem in the system. It is common to have multiple notions of state, dissimilar request interfaces and hardcoded relationships and behavior. Every piece of configuration control code is custom made. Consequently, the same algorithms which are common to all Configuration Control are implemented and reimplemented over and over, each time with changes introduced by the present developer. Control is centralized with, typically, only one maintenance request allowed to execute at any one time.
Typical high-reliability systems such as a telecommunications switch have about 80% of their cost sunk into maintenance software, of which Configuration Control is a major and key part. In the typical system where infrastructure is already in place, Configuration Control software may account for as much as 30%-50% of the cost of adding a new subsystem element. It has been estimated that from 50%-80% of the cost of writing Configuration Control software can be eliminated and development intervals reduced by using a standardized approach. This provides the potential commercial benefits of reduced product development cost and reduced product development intervals. The standardized Configuration Control protocol could be integrated into network management products to produce very intelligent network element behavior. In addition, a commercial version of the standardized Configuration Control protocol could be packaged and sold to vendors of highly reliable products and network management products. However, to date there is no standardized Configuration Control protocol.
SOLUTION
The above described problems are solved and a technical advance achieved by the system for providing asynchronous configuration control of highly reliable distributed systems using an object oriented paradigm (termed “configuration control system” herein). In this configuration control system, the maintenance configuration control protocol is implemented in an environment of multiple hardware platforms and operating systems and can be used to control hardware, software, data and system abstractions. The configuration control system gives the appearance of a unified maintenance environment even though it is controlling hardware and software from many vendors with multiple maintenance environments. The configuration control system works equally well for an embedded subsystem, a distributed switching system or a network of processors. It is designed to control the configuration of any system where there are dependencies among subsystems and loss of a subsystem has the potential to interrupt service.
The maintenance configuration control protocol developed unifies Configuration Control to allow any subsystem to communicate with any other subsystem and to the user interface using a common messaging interface. It creates a common state model, relationship model, behavior model and request/response messaging interface for all subsystems whether they are hardware, software, or an abstraction. Furthermore, the maintenance configuration control protocol permits distributed maintenance which is data-driven. That is, it does not depend on a central intelligence to make Configuration Control decisions. Each subsystem is empowered to approve/disapprove a maintenance request and execute it autonomously based on its own data. That data includes its state and its relationships to other subsystems. Because each subsystem is autonomous, it is possible to have many concurrent configuration control requests executing in parallel. Race conditions and conflicts are handled by the common software representing the subsystem. A coordinating entity (a Maintenance Request Administrator) is not a requirement.
The maintenance configuration control protocol standardizes the state, communication interfaces, relationships and behavior. Further, the relationships are captured in data which can be changed in a running system. Thus, Configuration Control behavior can be changed on-the-fly. Configuration Control is distributed so there is no dependency on a central processing elements and multiple maintenance requests may execute simultaneously.
The problems which this configuration control system solves are:
Coordination of dissimilar (different vendors, multiple platforms and maintenance systems) subsystem configuration changes during a maintenance request (remove, restore, switch) to assure service continuity.
Dependency on one system coordinating entity which creates a bottleneck and restricts concurrency.
Creating interfaces and dependencies between subsystems which have different notions of state, relationships, behavior and request interfaces.
Complex hard-coded Configuration Control logic which is expensive to change/evolve, impeding technolo
Dobrowolski Gregory Joseph
McKiou Kevin Wayne
Lucent Technologies - Inc.
Ngo Ricky
Patton & Boggs LLP
LandOfFree
Asynchronous object oriented configuration control system... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Asynchronous object oriented configuration control system..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Asynchronous object oriented configuration control system... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2985641