Object Services and Consulting, Inc.

Survivability in Object Services Architectures

Contact Information

Object Services and Consulting, Inc
Principal Investigator: David Wells
Project Team: Steve Ford David Langworthy

Survivability in Object Services Architectures (contract F30602-96-C-0330) is funded by DARPA ITO.

Project Overview

The military of the future will increasingly rely upon "information superiority" to dominate the battlespace. Achieving information superiority will require software applications that are far larger, far more complex, and far more distributed than comparable applications in existence today. The size and complexity of such systems makes them highly vulnerable to the loss or degradation of hosts, networks, or processes due to physical and information warfare attacks, hardware and infrastructure failures, and software errors. Since loss or degradation is inevitable, it is essential that such systems behave well when this occurs. A system that can repair itself or degrade gracefully to preserve as much critical functionality as possible in the face of attacks and failures is called a survivable system.

We are developing software mechanisms to ensure the survivability of such systems that go well beyond the traditional approaches of fault tolerance and replicated services. Those techniques, while valuable, are in themselves insufficient to respond to the full range of problems that can face a system since they create "islands of availability" but do nothing to address system-wide concerns. The following two examples illustrate the kinds of issues addressed by our survivability work.

Mission planning for a sortie in regional conflict with multiple coalition partners requires many resources, among them a map server. Assume the local map server becomes unavailable and that the backup map server is located at a remote location and reachable only over slow communication lines. There is a coalition map server available with good performance characteristics, but its data is considered to be of lower quality and the labels are specified in a foreign language. Under many circumstances, it would be desirable to use the coalition map server, but existing systems cannot switch an active connection and are limited to exact substitutes for a service. A survivable system needs to be able to switch compatible services in an established connection and substitute acceptable alternatives.

The ability to substitute services is only one aspect of survivability. Consider an information warfare attack focused on NT machines. As the NT machines begin to fail, essential processing must be moved over to UNIX machines. This in turn requires terminating or delaying non essential processing on those machines. However, there are many different threats, each with its own optimal response, and more than one threat may materialize at the same time. Addressing this in an ad hoc manner is not possible. A survivable system must be able to dynamically adapt to the threats in its environment to reallocate essential processing to the most robust resources.

This project is developing software mechanisms to make military and commercial software applications based on the popular Object Services Architecture (e.g., OMG's CORBA) model far more survivable than is currently possible, while at the same time maintaining the flexibility and ease of construction that characterizes OSA-based applications.

The keys to making systems survivable are:

design patterns with well designed "joints" between components to make reconfiguration possible
monitors to detect when failure or degradation has occurred
models of client needs and resource capabilities to allow alternate configurations to be found
multiple reconfiguration strategies with different "goodness" characteristics applicable in different situations
the ability to select and execute a good reconfiguration strategy that attempts to satisfy application requirements, make good
use of resources, and avoid vulnerable configurations

We have developed a comprehensive approach to satisfying these requirements consisting of: a survivable object abstraction in which survivable services and applications can be developed; a collection of models describing capabilities, needs, and threats; and the architecture of a Survivability Service that manages the survival of systems constructed in accordance with the survivable object abstraction. Our goal is to demonstrate the feasibility of this approach by building and demonstrating a prototype Survivability Service consisting of all of the above capabilities except monitoring, which we assume will be developed elsewhere. To maximize the utility of the Survivability Service, we are leveraging related work such as fault tolerance techniques, OMG CORBA & Object Services, failure detectors, and various system models. We plan to propose the Survivability Service specification to the Object Management Group and to make the prototype available as a reference implementation.

Papers

The following papers have been written over a period of approximately 18 months. As our understanding of the technology increased, both our terminology and design have been refined. The result is that there are some inconsistencies between the papers; these will be resolved in a subsequent report.

OSA Survivability Project - September 1996
This report describes the goals, approach, and anticipated results of the project "Survivability in Object Services Architectures".

OSA Compositon Model - September 1996
This report describes the static properties of a survivable object abstraction that extends standard object models in several ways to allow objects and applications to be reconfigured to recover from or protect against failures. Survivable objects are the basis for constructing survivable applications.

OSA Evolution Model - September 1996
This report describes the dynamic properties of the survivable object abstraction (introduced in OSA Compositon Model) that it possible to safely migrate a running application from one legitimate configuration into another legitimate configuration. Both semantically identical and semantically similar transformations are possible under this model, which allows applications to continue to survive in degraded mode when system resources become unavailable due to attack or failure.

OSA Survivability Service - January 1997
This report describes the architecture of a Survivability Service that manages survivable objects and applications constructed using the survivable object abstraction. The Survivability Service is compatible with existing work in failure detection and classification, fault tolerance, and highly available systems. Portions of the Survivability Service are being prototyped as part of this project.

QoS & Survivability - March 1998, Revised August 1998
This report describes recent research in service-level quality of service and the relationship between survivability and quality of service.

Notes on a Command Post Scenario - 1998
This report is a working paper describing the likely software environment of a future military command post, the connectivity between a command post and its outside environment, and a typical activity that takes place within the command post. This will be used to derive the survivability requirements of a command post and define a scenario for demonstrating the Survivability Service.

Survivability is Utility - 1998
The paper explores how Utility Theory (a sub-discipline of microeconomics) can be exploited to define metrics to evaluate the successfulness of survivable systems and that can be used by Survivability Management Systems to plan actions to ensure system survivability.

Estimating Failure Probability - 1999
In the process of creating and maintaining survivable configurations, the Survivability Service needs to predict the likelihood that, within some time interval, a service will be damaged to an extent that it cannot provide the required level of service. This paper discusses a basic model of how services are provided by resources, how threats against those services are modeled, and how the probability of service failure is computed from the threat model.

Presentations

Formal Methods Workshop (1996) - DARPA Formal Methods Workshop, Lake Placid, NY, July 1996.
Rome Lab Technical Exchange (1996) - Rome Laboratory C3AB Technical Exchange Meeting, Uttica, NY, December 1996.
Wrapper Workshop (1997) - DARPA Wrapper Workshop, Lake Tahoe, CA, July 1997.
Rome Lab Technical Exchange (1997) - Rome Laboratory C3AB Technical Exchange Meeting, Uttica, NY, December 1997.
OMG SecSIG (1998) - Object Management Group Security SIG Orlando, FL, June 1998.

© Copyright 1997-1999 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this document.

This research is sponsored by the Defense Advanced Research Projects Agency and managed by Rome Laboratory under contract F30602-96-C-0330. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, Rome Laboratory, or the United States Government.

Last updated 5/13/99 sjf