FORCEnet Implementation Strategy (2005)

If FORCEnet is to be the architectural framework for naval warfare in the information age, it must deliver performance, information assurance, and quality-of-service guarantees unprecedented in a system with the nodal diversity evidenced in the joint force. This challenge is best met incrementally so that existing capability is not degraded nor information security ever compromised. The design and implementation of complex systems for purposes of warfighting require a dedicated core of warfighters and system engineers trained in the art of operations analysis. Together, warfighters and engineers make decisions about when and how to introduce new capabilities as technologies and operational concepts evolve in independent but integrated spirals, as described in Chapter 2. Traditional, rigid system engineering cannot accommodate the technology cycle as it applies to complex IT-enabled systems. However, the fundamental principles of system engineering still apply. This chapter addresses the following topics: technical characteristics that are required to achieve the full realization of FORCEnet, architecture definition and process, the status of efforts to realize the FORCEnet architecture, system engineering principles and considerations, managing operations, facilities, and technical dangers and solutions.

It is imperative to recognize that a network-centric force is a network-dependent force. Network dependency demands access and quality-of-service guarantees that can be adjusted to reflect mission and COI priorities. Suggested metrics

for quality of service are addressed elsewhere (see Table 3.3, Table 6.3, and “Network Quality of Service and Resource Management in a Military Context” under Section 6.2.1.1), but whatever the final set, all network warfighting nodes must have the capability to know the state of health of the force combat system of which they are a part.

Guaranteed quality of service requires, among other things, guaranteed bandwidth availability. Experience has shown that availability of bandwidth has been problematic in the naval environment, and that is not expected to change in the near future. The Congressional Budget Office and the U.S. Army have estimated military bandwidth demand at up to 20 times greater than forecast capacity.¹ DISA estimated that more than 80 percent of the bandwidth consumed during OIF was supplied by commercial sources, and even then there were bandwidth brownouts.²

Current plans for bandwidth expansion to naval forces do not adequately address the requirements of a mobile network-centric force prior to the launch of the TSAT. Initial TSAT operational capability is scheduled for 2012 or later, which seems out of sync with plans for near-term initial releases of horizontal data fusion and enterprise services as envisioned by the ASD(NII). Horizontal data fusion and enterprise services will further increase the demand for bandwidth. For example, Extensible Markup Language (XML) encoding of data can easily increase message size by a factor of 10 or more, and it has been estimated that Littoral Combat Ships (LCSs) will each require bandwidth of 8 megabits per second (Mb/s) continuous and 20 Mb/s burst when they are deployed. Where will this bandwidth come from? What happens to the Web services environment and the LCS investment if it is not available?

The committee was not able to uncover good estimates of the bandwidth and quality of service required for the envisioned networked services. NMCI leveled the QoS playing field between disadvantaged and advantaged users ashore. A similar effort is required to level the quality of service playing field between fixed and mobile users that project power to the edge. Since there will likely never be enough bandwidth to satisfy all needs simultaneously, agile bandwidth allocation and distribution schemes are necessary, as is disciplined design control of bandwidth demand. Since the LCS will likely be the first ship class that is highly dependent on external networks and resources to accomplish its mission, it is an excellent candidate for the application of bandwidth-demand control techniques.

The term “interdependence” requires high levels of system and operator maturity as well as an information assurance architecture and concepts of operations that are agile and robust enough to respond to emerging information assurance threats, while at the same time supporting information sharing. A risk– benefit analysis should be conducted before a decision is made to field a design that makes a fighting unit dependent on assets that it does not control. It is not yet clearly understood what can go wrong or how to assess FORCEnet value in light of such risks, but it is known that denial-of-service attacks are real and must be considered in the risk analysis. Since there is no known 100-percent-effective defense against denial-of-service attacks, graceful degradation from connected to independent operations must be a critical parameter in the design of the information assurance architecture and concepts of operations. The FORCEnet security architecture work that is in progress is commendable and must continue with high priority throughout the design and implementation process. The security architecture must permeate FORCEnet end to end, from network access controls through applications access to data access within applications.

In order to ensure quality of service in FORCEnet, there must be much higher levels of availability of network assets than have been achieved in the past. This change will require the addition of redundancy and graceful degradation, including automatic network reconfiguration, for occasions when failures occur. FORCEnet must be built with network management in mind. The warfighting value of FORCEnet capabilities and the speed of implementation will be paced by bandwidth availability.

An example of requisite availability is “multi-nines” for critical functions, such as weapon midcourse control, for which only a few hours or minutes per year are tolerated. A more typical wireless availability of 90 percent would generally imply that connectivity is down about 36 days per year, generally for short intervals, and that this level of availability is adequate for the networked functions. To achieve even the case of a 90 percent available design requires accommodation for propagation fading and rerouting.

Distributing system functionality for systems that were not originally designed to be part of a distributed system generally reduces the overall availability of the functions performed, unless redundancy is introduced. This is simply because there are more mission-critical parts in the system. Increased capability, however, can offset lower availability and increase the probability of mission success. The probability of mission success for a system can be thought of in terms of three independent variables: the probability that the system is available times the probability that the system has the capability to perform the mission

times the probability that the operators will perform without error. The probability of mission success cannot be higher than the lowest of any of these variables. Capability increase through the networking of assets is frequently a high-return-on-investment option for increasing the probability of mission success.

Inevitably it will be too expensive to deploy new capability to every fighting unit simultaneously. Thus, there will always be a mix of old and new that must work together without degrading legacy performance. These realities will likely lead to the need for a transition architecture that may be missing desired characteristics and capabilities, but which will start the process of getting capability into the fleet. For example, a hub-and-spoke configuration with ad hoc networking could support near-term capability enhancements.

Multiple hubs supported by an airborne relay could provide needed redundancy, while allowing limited satellite bandwidth to be shared between assets within a 200 mile radius of the relay. This configuration could also support incremental deployment, since a node that is part of two subnetworks of varying link configurations can be designated as the communications filter between old and new configurations.³ (Mobile ad hoc networks are discussed in Chapter 6.)

The Navy and DOD have worked for 12 years to develop a single integrated air picture and have yet to do so. Many factors contribute to interoperability and to the lack thereof. One factor, however, seems clear: absent the market pressure of the commercial marketplace, the complexity of the problem of interoperability is greater than can be solved by the enforcement of standards. To illustrate the complexity, assume that one wants to fuse data from multiple sensors. If data from multiple sensors are to be fused and not just presented in their native form, all of the sensors must “know” where they are relative to all other sensors, must know what time it is, and must know with what precision they are reporting location, time, and the position. Since most of today’s sensors, identification algorithms, track correlation algorithms, databases, time standards, and so on were not designed with the idea of fusion in mind, the statistical confidence in the reported data is not known, and thus the statistical confidence in the fused data is unknowable. FORCEnet must establish and implement standards and information architectures that result in deterministic outcomes when data are fused. These

go far beyond communications standards. The proper allocation of functions, as discussed in Section 6.2, will facilitate the process, but the variables determining interoperability are so numerous that it should not be expected that these issues will be corrected by planned FORCEnet activities. Matters such as processor speeds and buffer size, in addition to the more obvious transport-layer and data-definition issues, will present additional challenges. A common transport reduces the number of interfaces that have to be maintained from an O(n²) problem to an O(n) problem, where n is the number of systems that are to interoperate. Functional partitioning that results in common boundaries for common functions and common data definitions reduces the data fusion complexity from O(n³) to something more manageable.

The FORCEnet information architecture should be thought of as a boundary between layers of functionality that is held invariant (over long periods of time), thus allowing developments to proceed independently on all sides of the boundary. In the committee’s view, architecting FORCEnet is the process of defining thin waists, or boundaries, that are invariant and, when coupled with selected industrial standards and throttled with a network control system, would enable FORCEnet to evolve with advances in technology. The boundaries standardize the interfaces between the functions common to all warfare systems so as to facilitate interoperability and information sharing. Examples of boundaries that should be established include those between sensor/intelligence networks, command-and-control networks, fire-control networks, displays, and databases, as shown in Figure 5.1. The open-architecture initiative of the PEO for Integrated Warfare Systems (IWS), discussed later in this chapter, is an application of this concept at a lower level of system detail.

The establishment of the boundaries shown in Figure 5.1, populated with designs that are compliant with the Networks and Information Integration (NII) Net-Centric Checklist and validated with performance modeling and sensitivity analysis, would provide a solid foundation for the FORCEnet information architecture. The network control system could then be designed to route and throttle information across the boundaries on the basis of mission priorities and available capacity and capability. As envisioned, any sensor could be accessed by any command-and-control system, which in turn can direct any fire-control system through a human in the loop. Multiple echelons are reflected in communities of interest related by the common boundaries that they share.

There are several areas in which boundaries can be defined in a service-oriented architecture, but with too many boundaries there is insufficient homogeneity to operate as an enterprise. In the commercial marketplace, market pressure

FIGURE 5.1 Examples of boundaries between functions in the FORCEnet information architecture.

limits the number of boundaries. In the DOD, governance must be relied on to limit them.

As briefed to the committee, several groups felt that they were in control of the architecture definition process. “Generate-and-test” is a costly trial-and-error approach. Architectures are best defined by a small group of bright, experienced designers. Architectural principles can be defined and applied in a systematic manner to create architectural integrity. A prime example is the development of the Internet. Commencing with the vision for a communications infrastructure that could survive attacks by adversaries, packet switching (breaking data into packets for independent routing) became the architectural principle. Ten years later, IP became the architectural definition.

An example of an effective process is one called user-centered design, in which desired functionality is defined in terms of “use cases.” The Navy sometimes calls these use cases Design Reference Missions, and the joint community calls them mission threads. Capability requirements are derived from the use

cases, and the architecture is synthesized to provide these capabilities. Design and implementation experts select technologies and standards to realize the architecture. Components are created to support unique requirements. Glue logic, which can take the form of middleware or concepts of operations, is synthesized to tie together existing technology that is not interoperable until the maintenance burden of the glue becomes greater than the value of the interoperability. When the maintenance burden becomes high, functional boundaries need to be modified to reduce interoperability issues and cost. If the boundaries are set correctly, this should be an infrequent event. Since the existing functional boundaries were set when the definition of system did not extend beyond a warfighting platform, many functional boundaries are in need of redefinition. By analogy, when every home had a well, the interface between the water supply and the kitchen was a bucket; the bucket could still be used when a public water supply became available, but why would one do so?

It appears to the committee that the Air Force Command and Control, Intelligence, Surveillance, and Reconnaissance Center (AF C2ISR) has the closest to a user-centered design process of any of the Services. The threads of the AF C2ISR are examples of use cases. In order to be robust and provide room for growth, more visionary use cases and mission threads should be defined for FORCEnet prior to architecture synthesis.

SPAWAR is developing a series of reports to help define the FORCEnet architecture. The Version 1.1 release of November 18, 2003, consists of the first two volumes:

• Volume I—Operational and Systems View describes FORCEnet as a standards-based open architecture.⁴ Volume I consists primarily of a high-level survey of military systems that would form components upon which FORCEnet will be realized. The output of the FORCEnet Baseline Process, briefed to the FORCEnet EXCOMM on June 23, 2004, will undoubtedly modify the list as systems are placed in compliance categories.

• Volume II—Technical View is a list of almost 300 mandated standards that FORCEnet compliant systems must support.⁵

Neither Volume I nor Volume II appears to define the Navy-specific or joint invariants or boundaries in the FORCEnet architecture. Invariants allow technology to evolve on all sides of architectural boundaries, sometimes by orders of magnitude, and still maintain functionality. Following is a summary of the contents of these two volumes, as well as suggestions on Navy-specific invariants that could be defined.

The preface to Volume I states that “the FORCEnet Architecture will incorporate common engineering, information, protocols, computing, and interface standards…” and that “the FORCEnet Architecture is based on a commercial Distributed Services model.” Further, FORCEnet is called a “standards based open architecture.”⁶

As listed in Volume I, the following FORCEnet architectural principles have been adopted:

• Standard, published interfaces;

• Separation of interface from implementation;

• Open architecture;

• Task-centered design at the presentation layer;

• Database independence;

• Joint interoperability;

• Uniformity in architecture and design; and

• Recognition of diversity.

Volume I indicates that six core architectural elements have been identified: ISR (intelligence, surveillance, and reconnaissance) systems; weapon systems; command-and-control and support systems; network services; networks; and communications systems. In addition, a dozen IT service categories have been defined: networking, identity management, security, operating system, user (person)-to-computer interface, data management, data interchange, multimedia/

graphics, communications, document management, support, and hardware. Service components are identified for each of these service categories. A service component is made up of standards, interfaces, protocols, and product specifications. Examples of possible service components by service category include the following:

• Networking: network management, address management, and routing protocols;

• Identity management: federated directory service;

• Security: identification, authentication, audit trail creation and analysis, access controls, cryptography management, virus protection, intrusion prevention and detection;

• Operating system: kernel operations, fault management, utilities, backup and recovery;

• User (person)-to-computer interface: dialogue support, window management, and multimedia; and

• Data management: metadata, data dictionary, directory services, database management system.

The FORCEnet functional architecture is based on MCPs. These are not the MCPs that the Warfare Integration Unit under the DCNO for Warfare Requirements and Programs (N70) uses for program assessment. Instead, two operationally oriented scenarios have been defined to validate the FORCEnet architecture: (1) time-critical targeting employing persistent sensors and (2) cruise missile defense.

The approach in Volume I, Operational and Systems View, is to list current and emerging programs that either will form the FORCEnet infrastructure or will have to interface with the infrastructure. The architecture builds on existing systems and proposes upgrade roadmaps in the following areas:

• Communications and networks: migration and consolidation from existing systems and their planned extensions, including NMCI (land-based); NCTAMSs/Navy computer and telecommunications stations (ships at pierside and underway); FLEETnet global IP routing; tactical data links; and radio;

• ISR: DOD DCGS; GIG-enterprise services (GIG-ES) (access, analysis, storage, dissemination); joint C2 (warehouse of information, including force tracking, intelligence, maps, weather, socioeconomic, and cultural). Data will be in an XML infrastructure that manages data types by using wrappers and encryption for each data object; and

• Distributed services: based on Service-oriented architecture with registration, discovery, and Service interface; dozens of networking standards are listed. The Open Architecture Computing Environment (OACE) is the basis for services in FORCEnet. The GIG-ES could supply many of the basic services.

Volume I includes numerous systems that are deployed and/or under development. This committee finds it difficult to understand how the pieces fit together and what is architecturally tying them together. One possible description of FORCEnet is that it is a system of systems, but the interactions between these systems may be more opportunistic than systematic. Definition of invariant boundaries as suggested in Section 5.2.1 would greatly enhance the value of both volumes.

Volume II focuses on information technology standards (as opposed to capabilities). Standards were selected on the basis of their supporting interoperability and interchangeability, their maturity, ease of implementation, public availability, and consistency with public law and regulations. The FORCEnet technical working group will review new standards proposed for inclusion. In addition, a FORCEnet Compliance Process and Checklist is under development.

Almost 300 standards are mandated in Volume II. They cover such areas as data formats; operating system services; sensor interfaces; position, navigation, and time; information assurance; and information transfer. In areas in which standards are mature, they are mandated. For example, some of the mandated standards in the area of data formats include the following:

• Databases (Structured Query Language);

• Documents (Standard Generalized Markup Language, Hypertext and Extensible Markup Languages);

• Geospatial information (raster, vector, maps);

• Audio;

• Atmospheric and oceanographic data;

• Time of day;

• Floating point numbers; and

• Graphs.

Volume II is an extensive list of standards that FORCEnet-compliant systems must support. The list includes required standards and emerging standards that might migrate to the required list. As standards evolve, the list becomes a moving target, almost guaranteeing interoperability problems.

The process of using standards to achieve interoperability has not always been successful in the past in the DOD. In the commercial arena, standards

achieve interoperability through market pressure that does not exist for DOD-unique standards. Any deviation from widely used commercial standards will likely yield unsatisfactory results.

The NII Net-Centric Checklist (see Table 3.2 in Chapter 3) was prepared by the OSD to help DOD program managers understand what attributes are needed for acquisition programs that must fit into the emerging network-centric system. It was also prepared to help ensure that programs are aligned with the DOD’s Net-Centric Data Strategy. This checklist is a living document that will be updated as needed. The committee reviewed its most recent version to determine whether, in the committee’s view, the checklist is a help or hindrance to the Navy and Marine Corps as they build FORCEnet. Following are the committee’s observations on this question.

The checklist is a fairly demanding document, containing perhaps a hundred or more questions, each of which will require some thoughtful effort to answer. Typical questions are, “Describe how the visible data assets are made available to other users outside the Community of Interest with a need for the data” and “Does the service offering depend on or use any other services provided by a different program or service provider—if so, explain how this works.”⁷

The NII checklist covers a wide variety of topics, ranging from questions such as the example given above about how data will be made available to external applications, through scalability of services, to specifics of information assurance and datagram transport. Specific protocols are called out for compliance (e.g., IPv6 and XML), as are broader umbrellas such as the Joint Technical Architecture and JTRS specification. No checklist is ever complete, of course, but this document is extensive and highly detailed.

In the view of the committee, the NII checklist provides a valuable tool for the Navy and Marine Corps. It will certainly take hard work for a program manager to complete, and additional hard work will be required in the assessment of responses. However, the checklist does accurately capture many of the key attributes needed for truly open information systems. Certainly if a program manager provides deficient or questionable responses to a significant number of these questions, the Navy and Marine Corps have ample reason to doubt that the program is compatible with open systems architecture.

The committee believes that the Navy and Marine Corps should take this checklist seriously, assess programs on the basis of their checklist responses, and

favor those programs that stack up well according to this checklist over those that fare poorly. This is a valuable tool for weeding out legacy and emerging legacy systems from programs that will be most useful in FORCEnet moving forward.

The FORCEnet Compliance Checklist builds on FORCEnet Architecture and Standards: Volume II, Technical View. In addition to the list of standards, the Compliance Checklist includes questions on human–computer interaction (called human–systems integration), spectrum, interoperability, and documentation.

Besides the substantial overlap in the two checklists, there is also a substantial difference in approach. Whereas the NII Net-Centric Checklist focuses on capability, the FORCEnet Compliance Checklist focuses on the “What.” The NII checklist is designed to understand and guide the design philosophy of the designer. The FORCEnet checklist indicates the artifacts that have to be included—for example, data types, protocols, and even aspects of documentation. Table 5.1 provides examples of the difference in approach between the checklists.

The committee prefers the NII Net-Centric approach over that of the FORCEnet Compliance Checklist. Design philosophies consistent with an information architecture, as described below in Section 5.4, and verified by test prior to deployment have historically produced better results than have detailed checklists. The more items on the checklist, the more often it is likely to change, with resulting impacts in terms of cost and interoperability.

The committee was briefed by PEO IWS concerning its open architecture effort. The committee believes this work to be important and fundamental to FORCEnet success. The impetus for the open architecture initiative—namely, high acquisition and support costs, costly and time-consuming refresh, interoperability problems, and old architectures that are difficult to change—are similar challenges to those faced by FORCEnet. Consequently, many of the processes and policies for functional partitioning reflected in the “Open Architecture Computing Environment Design Guidance” pre-release of September 2003 are applicable to the FORCEnet architecture as well.⁸ Although the scope of that document is limited to the computing environment, the critical thinking that it evidences relative to functional partitioning and interface control is exactly what is required, although missing, in the FORCEnet architecture and standards documentation.

The open architecture initiative addresses software reuse as well as refresh. As a result, the granularity of partitions to that utilized in legacy architectures increases and raises concerns—the number of boundaries to be maintained may exceed the number that can be reasonably managed, and the functional partitions may not be optimally placed. In particular, the committee believes that as long as functional partitioning supports the higher-level aggregation of interoperable functions, as suggested in Figure 5.1, it is acceptable, but the number of unique partition definitions should be minimized. The open architecture functional architecture shown in Figure 5.2, coupled with the FORCEnet information architecture described above, will, when implemented, greatly simplify the implementation of FORCEnet.

On February 19, 2004, the ASN(RDA) issued a summary of decisions and actions from the first meeting of the FORCEnet EXCOMM. Many of the obser-

vations in the summary parallel those in this report. The decisions and actions provide a focus on the future, communicating an urgency for FORCEnet implementation that was not apparent in many of the briefings that the committee received during the period of this study. The decisions went beyond those reflected in the SPAWAR FORCEnet Business Strategy Version 1.0 and expanded the number and scope of FORCEnet pilot programs. Near-term pilots for the Marine Corps, the DCGS, and the JFN were added, and a decision was made to reallocate funds to support FORCEnet implementation.

The EXCOMM decisions, vigorously implemented, will do much to make FORCEnet a reality. Early evidence of outputs from the FORCEnet baseline process indicates that good progress is being made in identifying the tools and data necessary to implement the ASN(RDA)’s direction.

The ASN(RDA) is to be commended for the leadership displayed and actions taken. One concern is the relatively low level of participation by fleet and Marine Corps warfighter leadership in the FORCEnet EXCOMM. The actions necessary to move FORCEnet forward in a fixed-resource environment could impact near-term fleet readiness and must be accomplished in partnership with the warfighters.

FORCEnet and the fighting units and command-and-control structure that it supports are all subsystems of a joint battle force. Systems engineering is a process for allocating functionality to subsystems that are bounded by system architecture so that the probability of mission success is optimized within available resources. A battle force performs three major functions: it manages battle, dominates battlespace, and sustains control over the battlespace over time. FORCEnet functionality is a subset of battle force functionality that can contribute to battle management, battlespace dominance, and sustainability. FORCEnet cost and contribution to battle management, battlespace dominance, and sustainability should provide a basis for implementation decisions. As a subsystem, FORCEnet must interface seamlessly with the remainder of the force while increasing the probability of mission success more than alternative investments. Understanding and defining the interfaces between what is in the FORCEnet subsystem and what is outside of it will be an ongoing process. This top-down view of FORCEnet, together with the bottom-up work that is being done at the information architecture boundaries, is necessary to explain and quantify the warfighting value. Demonstrations of value with frequent delivery of incremental capabilities are an important way to validate systems engineering practices and maintain support for progress over the long term.

The first and perhaps most important job of the system engineer is to determine the few independent variables that control the overall effectiveness of a design. The reaction time of the battle force as a system is proposed as a primary, design-driving independent variable for FORCEnet. Given a fixed set of assets, the reaction time of the battle force as a system is directly related to the validity and timeliness of the information that FORCEnet will gather and deliver to decision makers and executers. The volume of battlespace that a fixed force can dominate is determined by the reaction time of the force. Therefore, the mission effectiveness of FORCEnet is directly related to the force’s reaction time and is measurable as described below in Section 5.5. The components of reaction time may change in definition for different mission areas but should always be readily measurable. The programmatic implication of the description of FORCEnet mission effectiveness given above is that the FORCEnet investment portfolio that minimizes force reaction time will be the same one that maximizes mission value.

It is useful to think of the “net” part of FORCEnet as a collection of subnetworks that share the same transport layer: a collaborative sensor/intelligence subnetwork requiring high volume, a command-and-control subnetwork requiring high security, and a fire-control subnetwork requiring deterministic latency. Each of these subnetworks might themselves have subnetworks that are part of a community of interest. The fire-control subnetwork has attributes and independent verification and validation (IV&V) requirements characteristic of a manned-safety-rated system. Thus, the attributes are expensive to achieve and take a long time to test to adequate levels of confidence. Inserting a human into the interface between the command-and-control subnetworks and the fire-control loops provides a means to couple the two functions loosely and thus reduce the IV&V burden.

However FORCEnet ends up being delivered in terms of product and capability, there will be interfaces to maintain. Once it is known what battle force functions are to be assumed by FORCEnet, the set of interfaces that must be maintained to allow the horizontal integration of display and data and the vertical integration of subnetwork functionality by mission area will be understood. It is already known that some of the interfaces that must be controlled are internal to ongoing acquisition programs and directly impact the architecture of the software and hardware that comprise these programs. In effect, some existing systems could be torn apart and their functionality rearchitected to support horizontal

integration. Or, a decision could be made that the value of the information that these systems generate or the functions that they perform do not improve the probability of mission success enough to be shared across the force. Or, a decision could be made that integrating other system information or functionality with the legacy system does not improve mission success sufficiently to justify the cost. In some cases it may be possible to use software wrappers to extract the desired data and functionality from a system so that it can contribute to mission success. Although this approach adds maintenance cost since there are more lines of code to maintain and that can degrade performance, it can often be done more quickly and with less up-front investment than is required for wholesale re-architecture.

The committee suspects that a large percentage of legacy systems would not pass a cost–benefit analysis for inclusion in FORCEnet, and that fewer yet would have a high return on investment. Integration should begin with legacy systems that have a high return on investment and new developments. A rigorous and disciplined return-on-investment process by a nonadvocate will be required in order to achieve maximum return on investment and to control total ownership cost. The point here is that interfaces are difficult and expensive to maintain. The complexity and latency of evolutionary development grow exponentially with the number of unique interfaces that must be maintained, and a process must be in place to ensure that value to the fighting force can trump individual program advocacy.

Change management for FORCEnet will require an engineering authority at a higher level of system than has ever been achieved in the DOD. Change management is the most important engineering discipline relative to maintaining information security. A construct for the way that change will be managed for FORCEnet functional partitions and standards in the context of the GIG and joint force must be developed in concert with the FORCEnet designated approval authority.

It is expected that one or more control facilities will be required to manage the performance of the FORCEnet infrastructure. Based on the methods for managing the U.S. telecommunications infrastructures as well as satellite networks (e.g., the Defense Satellite Communications System), the management centers will be highly automated, subject to human monitoring and override. Control facilities should have the capability to measure and manage to specified metrics. Automatic network measurement and management tools abound; however, tools

for measuring mission effectiveness in a network-centric force are not yet mature. The flexibility of a network-centric force can provide unprecedented options to the operational commander if the tools to monitor actions and outcomes are in place. A minimum set of operational metrics for FORCEnet is provided below.

Following are the metrics recommended for communications transport:

• Availability—High (multiple nines) for time-critical warfighting functions versus lower for routine messages. Availability of communications should be viewed from the end user’s perspective and managed to mission priority.

• Packet round-trip time—Packet round-trip time is a measure of the congestion of the network and is an end users’ view of quality. It is impacted by bandwidth, routing efficiency, and firewall settings. It must be tightly managed for time-critical messages. Note that for stream data such as ISR imagery, it may be necessary to maintain circuit-switched rather than packet-switched subnetworks.

• Packet (or message) loss percentage—Packet (or message) loss percentage is an indication of problems that will ultimately impact packet round-trip time and customer satisfaction as available bandwidth is consumed. Usually every packet or message lost has to be resent. Packet loss over 1 percent is a problem that can often be corrected with rerouting. Some critical functions will require acknowledgment such as pulling posted information or acknowledging a command for which a commercial IP such as Transmission Control Protocol is appropriate. Other data sharing, as for collaborative sensor networks, may not require that every data message be received—User Datagram Protocol, for example, may be the appropriate IP in this case.

The following three interoperability metrics for the antiair-warfare area are an example of those recommended for measurement of the warfighting effectiveness of FORCEnet. The sum of the three metrics is a representation of battle force reaction time. The definition of the elements that make up reaction time will vary from warfare area to warfare area, but in each case their sum should be a representation of battle force reaction time and should include the latency of critical mission-information sharing, the latency generated by command-and-decision-tool interoperability issues, decision-maker latency to analyze and act on information presented, and the length of time it takes to communicate the execution decision to the executor. The sum of these parts should decrease as battle force interoperability improves with FORCEnet. Faster is always better. As VADM Arthur Cebrowski, USN (retired), once said, “Show me a person who does not

FIGURE 5.3 Battle force reaction time. SOURCE: Joseph Cipriano and Jerry Krill. 1999. Battle Force Interoperability and Net-Centricity, Defense Systems and Equipment International, Applied Physics Laboratory, Johns Hopkins University, Laurel, Md., pp. 261–270.

think speed is important, and I will show you someone who has never been shot at.”⁹ The interoperability metrics for the antiair-warfare area are these:

• Battle force track time—The time from the first detection of an unknown by any battle force unit to the time when all designated battle force participants hold the detection and track, if applicable (connectivity availability and the effectiveness of correlation algorithms are measured).

• Battle force identification time—The time from the first correct identification of a detection by a battle force unit until all requiring units hold a correct identification (interoperability of identification algorithms and message round-trip time are measured).

• Engagement decision time—The time from when sufficient information is available to the time when an engagement decision is made (quality and completeness of data presentation and operator training are measured).

When battle force reaction time is degraded, more assets must be allocated to defend the battlespace (see Figure 5.3). If a FORCEnet capability does not improve battle force reaction time, it should not be deployed.

In classical systems engineering, the subsystems are typically brought together in a laboratory setting with scripted drivers to ensure proper integration via strict test processes. This integration buildup, especially for subsystems delivered by different, physically separated organizations, must be carefully planned and well resourced (e.g., Aegis integration and testing at Moorestown, New Jersey; Aegis Computer Center at Dahlgren, Virginia; and Aegis Combat System Center (ACSC), Wallops Island, Maryland. Early in the integration and testing of both Navy Link 16 and Cooperative Engagement Capability, a limited testbed link between ACSC/Wallops and Fleet Combat Direction Systems Support Activity at Dam Neck, Virginia, allowed these networks to operate with Aegis and carrier Advanced Combat Direction System combat systems with scripted and live scenarios. These proved critical to the early success in formal testing of these systems.

However, there was no mechanism for more extensive testing other than onboard ships of a battle group. Since each deploying battle group configuration is different, this resulted in key interoperability issues that were not discovered or addressed until a battle group began predeployment workups. Instrumentation for problem detection and time for correction prior to deployment were limited. Increasing numbers of such events in the late 1990s resulted in the establishment by the Naval Sea Systems Command (NAVSEA) of a DEP and a battle-group-specific deployment-minus-30-month countdown configuration management and test process for combat and C4I systems planned for deployment.

Thirty months prior to deployment, the fleet commander identified the platform assets that would make up a battle group. A battle group action officer was then assigned by NAVSEA to manage the configuration and certification testing of the combat and C4I systems on the designated platforms in the DEP using scripted scenarios in concert to drive real-time interactive testing. The battle group staff observed the DEP testing and developed concepts of operations and communications plans based on the observed capabilities and limitations. After critical deficiencies were corrected, the battle force system engineer would certify a particular battle group configuration as safe and effective for deployment. The DEP proved able to baseline the systems of a deploying battle group and to ensure correction of key deficiencies. However, the DEP does not have sufficient capacity to support the originally intended additional uses, such as the early testing of concept models and prototypes and the verification of engineering compliance and interoperability during the development cycle for systems intended for eventual deployment. It has been consumed assuring near-term readiness.

The DOD has identified the need for a JDEP to leverage the demonstrated value of the Navy’s DEP in preparation for joint operational deployments, as well as for the verification and risk-reduction activities earlier in the development

cycles of joint and Service-specific systems in a joint setting. However, the definition and focus of the JDEP have been slow in realization of their intended capabilities. Further, the JDEP is not currently anticipated to be sufficient in scale and availability to serve anticipated Navy needs for FORCEnet according to the process identified above. Given the experience with the DEP, the Navy should play a lead role in realizing an extended joint DEP by first extending the Navy DEP.

To reiterate, the extended Navy DEP for FORCEnet would provide for the following:

• Early exploration of concepts and concepts of operations against future threat scenarios,

• Integration testing and risk-reduction evaluations of prototypes and models of conceptual FORCEnet elements,

• Baselining of configurations prior to critical field experiments and data collections,

• Verification of compliance with FORCEnet standards and architecture boundaries and interfaces,

• Integration and test buildup to operational tests,

• Baseline testing and fixes prior to deployments,

• Training to new capabilities and doctrine, and

• Problem replication and fix verification for deployed systems.

The extended DEP would provide the following additional features relative to the existing DEP:

• Both simulated and actual networks and routers/hubs,

• Wrap-around network-wide simulation drivers of the networks as well as system applications,

• Interfaces to the eventual JDEP,

• More nodes especially for the contractors for verification during development as a risk reduction activity,

• Connection to facilities such as Aegis ASCS/Wallops for live radar and weapon systems,

• Interface to corresponding national assets test sites, and

• Potential to connect to predeployed combatants for further verification testing.

Every time new assets are added to a networked system, new vulnerabilities can be added as well. To offset this risk, networks offer increased opportunities for implementing security in depth. The FORCEnet architecture must support

security at access points, and it must do so in the transport and application layers as well as at the data layer. Concepts and mechanisms for maintaining access controls to network, applications, and data must be developed and built in up-front.

Whenever needed by warfighters—and especially at intervals of high warfighting stress—the network and its information must be available and trustworthy. Operators must be able to rely on the network and its information without constant concern that the information they are using has been poisoned by deliberate acts of an adversary, that an adversary is inside the network, or that the entire network might suddenly collapse spontaneously or under enemy attack.

Although there are many possible ways to categorize the vulnerabilities of large, networked systems, the major dangers fall under the following headings:

• Unexpected fragility,

• Worms and viruses,

• Insider threats,

• Threat of poisoned data, and

• Denial-of-service attacks.

As sets of plausible attacks gradually become apparent, information assurance mechanisms and policies can be developed to counter them. At present, however, there is a noticeable lag between new attacks and the implementation of corresponding defenses, since fresh software is constantly being installed and its vulnerabilities only become apparent over time. A key challenge will be to reduce this lag until it is small enough so that adversaries find it infeasible to mount attacks during the undefended interval.

The committee notes that information assurance policies and technologies provide protection against risk at some cost (burden), in terms of both efficiency and restrictions on operator activities. Do the policies need to be applied the same way in all circumstances? How may a commander control the risk or burden trade-off to suit changing situations? All of these are currently open issues needing attention.

As strange as it may seem, possibly the greatest danger to FORCEnet may be its own spontaneous collapse or malfunction, without any obvious external cause. In the past, large-scale distributed systems, such as networks and electrical systems, have often proved to be surprisingly fragile. Seemingly trivial accidents in a minor part of the system can quickly cascade into overall systemic failure. This inherent fragility should be of great concern to the Navy as it continues to rely more and more on large, interconnected information systems.

Several well-known cautionary examples are listed below. It is important to recognize that in each of these cases, a stable, well-engineered, well-run system underwent a rapid and totally unexpected collapse. Although triggered by trivial, transient events, total system outages often lasted for days.

• Northeast power outage of 2003—Two discrete and unrelated minor events led to the loss of power to 50 million customers for 3 days.

• AT&T nationwide failures, 1990 and 1998—Software flaws introduced in system upgrades resulted in nationwide loss of AT&T long distance for 9 hours in one case and took thousands of businesses offline for 6 to 26 hours in another.

• Baltimore tunnel fire in 2001—A chemical spill and fire severed three major fiber-optic lines for the East Coast. Telephone call centers from Maryland to New Jersey lost service for half a day.

Although the Navy and Marine Corps do not currently appear to be particularly vulnerable to such catastrophes, it does not take too much imagination to picture how such cascading failures might affect the Navy once all naval platforms are networked. What if router software for all platforms in a battle group were upgraded to the same release, and then a minor anomaly led to a 24-hour outage of communications across the battle group? It happened to AT&T twice. What if a single fiber cut in the continental United States led to day-long outages and slowdowns for accessing Web databases or for important centralized services such as chat rooms? It happened to the largest, best-run Internet providers in the United States. What if simple viruses and worms entered the Secure Internet Protocol Router Network and brought e-mail to a crawl—or even clogged essential communications links to tactical platforms? It happened to NMCI.

Nonspecialists may think that these are remote and unlikely situations, but experience has shown precisely the opposite. Large and complex systems are surprisingly fragile. They require great care in their design and operation.

The previous subsection listed a number of technical dangers that will threaten FORCEnet for the foreseeable future. These dangers cannot be eliminated, but imposing the following four requirements on FORCEnet and its operations can ameliorate them:

• The network infrastructure must be extremely robust, with sufficient redundancy and diversity to adapt to losses of component portions. There must be specific plans and processes in place for adapting to each potential loss.

• Since a loss of a portion of the network is very likely to reduce the capacity of the network and of the communications capability to some of its

users, each adaptation plan must include the changes in operations that are required to adjust to the reduction in communications, and training must include the operations at each level of reduced capability.

• Since there is a significant likelihood that some ends of the network at some time will lose connectivity totally, sufficient local capability must be provided to allow effective operation in such a mode for a period of time.

• A “one-size-fits-all” solution of hardware or software is not recommended, since one vulnerability in a common component can lead to the complete crippling of the entire system. Thus, some level of heterogeneity is needed to help combat worms and viruses.

Following are the findings and observations of the committee with respect to FORCEnet architecture and system design:

• The process and tools for translating FORCEnet operational concepts into products, services, and warfighting capabilities have yet to be fully developed. Systems engineering is a process for allocating functionality to subsystems that are bounded by a system architecture. The current SPAWAR architecture document is difficult to follow, overspecifies standards, and provides incomplete identification and specification of architectural boundaries to support FORCEnet systems engineering. NAVSEA open architecture work reflects a process for establishing boundaries and partitioning functionality that is representative of what is required for FORCEnet. The system engineering expertise, disciplines, and lessons learned that NAVSEA has developed in support of open architecture would help fill the gaps in the current FORCEnet systems engineering process.

• The complexity of the complex system providing FORCEnet capabilities makes executing systems engineering a great challenge. The number of unique interfaces that must be maintained need to be carefully selected and kept to an absolute minimum, or evolution will be hindered by expensive and lengthy integration and testing. One way to do this is to require that systems must partition common functions in a common way. Web service architectures are a good example of this principle.

• The warfighting value of FORCEnet capabilities and speed of implementation are paced by bandwidth availability, and yet little has been done to estimate bandwidth requirements and to develop solutions to support the implementation of a network-dependent force.

• There has been little attempt to characterize how FORCEnet will function in terms of network management, data flow, traffic control, nodal performance,

or data access. This information is required to engineer the FORCEnet network-management system.

• It is not evident that existing facilities are adequate to support the engineering, training, and phased deployment of FORCEnet capabilities. With the fast pace of change in C4I and IWS, it remains necessary to perform high-fidelity land-based testing to ensure interoperability prior to deployment as is currently done in the NAVSEA DEP. Current facilities are not capable of handling an increased workload.

• The NII Net-Centric Checklist provides an excellent tool for the early evaluation of systems proposed for inclusion in FORCEnet and the GIG.

• The FORCEnet EXCOMM is a laudable start at a governance process for FORCEnet, but it does not have the proper level of representation from the fleet to function effectively with the challenges ahead. The leadership of ASN(RDA) in this effort is vital and commendable.

• The FORCEnet network controls do not provide the capability to meter and to prioritize data flow across boundaries, and FORCEnet behavior models are not developed to project performance and to support sensitivity analysis.

• The FORCEnet architecture does not provide redundant and diverse communication paths to guard against network vulnerabilities and degradation—for example, by furnishing alternatives to satellite communications for the last mile.

• The reaction time of the joint force to sensor input is not a design-driving requirement for FORCEnet or an evaluation factor for the prioritization of activities.

• A FORCEnet roadmap has not been developed, showing the schedule for design and analysis deliverables and the incremental delivery of capability.

Based on the findings presented above and on the issues described in this chapter, the committee recommends the following:

• Recommendation for the CNO and the ASN(RDA): Take measures to strengthen the FORCEnet architecture in terms of its ability to represent overall structural relationships among force components. To this end, the CNO and ASN(RDA) should designate NAVSEA, drawing on its open architecture experience, as having a major role in developing the FORCEnet architecture, particularly as pertains to its representation of invariant boundaries and the ability to allocate functionality. Furthermore, SPAWAR and NAVSEA should be directed to specify the technical interrelationship between the FORCEnet architecture and the combat systems open architecture.

• Recommendation for OPNAV: Adopt the Net-Centric Checklist of the ASD(NII) in place of the OPNAV FORCEnet Compliance Checklist, adapting it

if necessary to accommodate specific aspects of naval warfare. This design guidance, together with a focus on architectural boundaries, should help promote the development of FORCEnet architectural products.

• Recommendation for the ASN(RDA), with the support of the systems commands and the relevant PEOs (primarily PEO C4I & Space and PEO IWS): Develop the capability necessary to effect FORCEnet systems engineering. Very high standards, commensurate with the challenge, should be set for the systems engineering staff, who can come from the systems commands, program offices, and outside sources, as necessary. This systems engineering capability would work directly in support of any organization developed to integrate the Navy’s program formulation and acquisition functions more closely (as discussed in Section 4.8.5).

• Recommendation for the ASN(RDA), the systems commands, and the relevant PEOs (primarily PEO C4I & Space and PEO IWS): Pay particular attention to the following in establishing the FORCEnet systems engineering capability:

  • Instituting a change management authority responsible for the full set of FORCEnet functional partitions and standards. The decisions of this authority will affect a broad range of naval programs, unprecedented in any prior DOD systems engineering. This authority is key to maintaining the integrity of overall FORCEnet capabilities.

  • Providing for the frequent delivery of system capability (e.g., in 6-month increments). This will reinforce the value of the systems engineering process and is in keeping with the need for evolutionary development (discussed, e.g., in Section 7.3.2.3).

  • Achieving a mission focus in the analysis and allocation of functionality. For example, each mission can be characterized by a few key variables (e.g., battle force tracking and identification times in antiair warfare) that should be optimized in system design.

  • Establishing a rigorous process, independent of individual programs, for recommending the future course of legacy programs—phaseout, retention as is, upgrading, or merger into another program—based on the mission utility of each program.

  • Establishing means, involving both process and technology development, to recognize and deal with the vulnerabilities and fragilities that could cause significantly degraded overall capabilities.

• Recommendation for the CNO and the CMC: Establish a joint operations research capability for complex distributed systems. The operations research organization would be resourced to develop the concepts of operation, design reference missions, and performance models necessary to validate and prioritize operational requirements, including bandwidth requirements, for a network-centric force.

• Recommendation for the ASN(RDA), in conjunction with the systems commands and the relevant PEOs (primarily the PEO C4I & Space and PEO IWS): Develop a FORCEnet DEP by generalizing the concepts and approaches used in the current DEP. Since the ongoing joint distributed engineering plant effort does not appear adequate to meet FORCEnet needs (e.g., in terms of scale), the Navy should play a lead role in realizing an extended JDEP by first extending the Navy DEP.

• Recommendation for the ASN(RDA): Invite the fleet community to provide a senior flag officer to participate in the FORCEnet EXCOMM decision process.