Distribution Statement A: Approved for public release; distribution unlimited.
Executive Summary
Effective military operations must respond with a mix of forces, anywhere in the world, at a moment's notice. The ability for the information technology systems supporting these operations to interoperate--work together and exchange information--is critical to their success. The lessons learned from conflicts like Desert Shield/Desert Storm resulted in a new vision for the Department of Defense (DoD). Joint Vision 2010 (JV 2010) is the conceptual template for how America's Armed Forces will channel the vitality and innovation of their people, and leverage technological opportunities to achieve new levels of effectiveness in joint warfighting. The DoD Joint Technical Architecture (JTA) is crucial to achieving JV 2010.
The JTA provides DoD systems with the basis for the needed seamless interoperability. The JTA defines the service areas, interfaces, and standards (JTA elements) applicable to all DoD systems, and its adoption is mandated for the management, development, and acquisition of new or improved systems throughout DoD. The JTA is structured into service areas based on the DoD Technical Reference Model (TRM). The DoD TRM originated from the Technical Architecture Framework for Information Management (TAFIM) and was developed to show which interfaces and content needed to be identified. These are depicted as major service areas in the DoD TRM.
Standards and guidelines in the JTA are stable, technically mature, and publicly available. Standards and guidelines that do not yet meet these criteria, but are expected to mature to meet them in the near-term (within three years), are cited as "emerging standards" in the expectation that they will be mandated in future versions of the JTA.
The JTA consists of two main parts: the JTA Core, and the JTA domains. The JTA Core contains the minimum set of JTA elements applicable to all DoD systems to support interoperability. The JTA annexes contain additional JTA elements applicable to specific functional domains (families of systems). These elements are needed to ensure interoperability of systems within each domain but may be inappropriate for systems in other domains. The current version of the JTA includes domains for Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR); Combat Support; Modeling and Simulation; and Weapon Systems. Where subsets of an application domain (subdomain) have special interoperability requirements, the JTA includes subdomains containing JTA elements applicable to systems within that subdomain. The intention is that a system within a specific subdomain adopt the JTA elements contained in the relevant subdomain, the JTA elements contained in the parent domain, and the JTA elements contained in the JTA Core.
The JTA is complementary to, and consistent with, other DoD programs and initiatives aimed at the development and acquisition of effective, interoperable information systems. These include DoD's Specification and Standards Reform; Implementation of the Information Technology Management Reform Act (ITMRA); Defense Modeling and Simulation Initiative; Evolution of the DoD TRM; Defense Information Infrastructure Common Operating Environment (DII COE); and Open Systems Initiative.
Development of the JTA is a collaborative effort, conducted by the JTA Development Group (JTADG), directed by the Technical Architecture Steering Group (TASG), and approved by the Architecture Coordination Council (ACC). Members represent the DoD Components (Office of the Secretary of Defense [OSD], the Military Departments, the Office of the Joint Chiefs of Staff [OJCS], the Unified and Specified Combatant Commands, and the Defense Agencies) and components of the Intelligence Community.
The JTA is a living document and will continue to evolve with the technologies, marketplace, and associated standards upon which it is based.
Overview of the Department of Defense Joint Technical Architecture
Introduction
Warfighter battlespace is complex and dynamic, requiring timely and informed decisions by all levels of military command. There is an unprecedented increase in the amount of data and information necessary to conduct operational planning and combat decision-making. Information concerning targets, movement of forces, condition of equipment, levels of supplies, and disposition of assets--both friendly and unfriendly--must be provided to joint commanders and their forces. Therefore, information must flow quickly and seamlessly among all tactical, strategic, and supporting elements.
As shown in See : DoD Warfighter Information Technology Environment, warfighters must be able to work together within and across Services in ways not totally defined in today's operational concepts and/or architectures. They must be able to obtain and use intelligence from national and theater assets that may be widely dispersed geographically. Today's split-base/reach-back concept requires them to obtain their logistics and administrative support from both home bases and deployed locations. All of this requires that information flow quickly and seamlessly among DoD's sensors, processing and command centers, shooters, and support activities to achieve dominant battlefield awareness and move inside the enemy's decision loop.
|
|
The DoD Joint Technical Architecture (hereinafter referred to as the JTA) provides the minimum set of standards that, when implemented, facilitates this flow of information in support of the warfighter. The JTA standards promote:
The current JTA concept is focused on the interoperability and standardization of information technology (IT).
Purpose
See Overview of the Department of Defense Joint Technical Architecture provides an overview of the JTA. It includes the JTA purpose, scope, background, and applicability; introduces basic architecture concepts; and discusses the selection criteria for standards incorporated in the document.
Also addressed are the roles of the DoD Technical Reference Model and the Combined Communications-Electronics Board (CCEB).
The JTA improves and facilitates the ability of our systems to support joint and combined operations in an overall investment strategy.
Provides the foundation for interoperability among all tactical, strategic, and combat support systems.
Mandates IT standards and guidelines for DoD system development and acquisition that will facilitate interoperability in joint and coalition force operations. These standards are to be applied in concert with DoD standards reform.
Scope (Applicability)
The JTA is considered a living document and will be updated periodically as a collaborative effort among the DoD Components (Commands, Services, and Agencies) to leverage technology advancements, standards maturity, open systems, commercial product availability, and changing requirements.
The JTA is critical to achieving the envisioned objective of a cost-effective, seamlessly integrated environment. Achieving and maintaining this vision requires interoperability:
This version of the JTA mandates the minimum set of standards and guidelines for the acquisition of all DoD systems that produce, use, or exchange information. The applicable mandated standards in the JTA are the starting set of standards for a system, and additional standards may be used to meet requirements if they are not in conflict with standards mandated in the JTA. The JTA is used by anyone involved in the management, development, or acquisition of new or improved systems within DoD. Specific guidance for implementing this JTA is provided in the separate DoD Component JTA implementation plans. Operational requirements developers are cognizant of the JTA in developing requirements and functional descriptions. System developers use the JTA to facilitate the achievements of interoperability for new and upgraded systems (and the interfaces to such systems). System integrators use it to foster the integration of existing and new systems.
The JTA is updated periodically with continued DoD Component participation.
Background
The evolution of a national military strategy in the post-Cold War era and the lessons learned from conflicts like Desert Shield/Desert Storm have resulted in a new vision for DoD. Joint Vision 2010 is the conceptual template for how America's Armed Forces will channel the vitality and innovation of their people and leverage technological opportunities to achieve new levels of effectiveness in joint warfighting. This template provides a common direction to our Services in developing their unique capabilities within a joint framework of doctrine and programs as they prepare to meet an uncertain and challenging future. The Chairman of the Joint Chiefs of Staff said in Joint Vision 2010, "The nature of modern warfare demands that we fight as a joint team. This was important yesterday, it is essential today, and it will be even more imperative tomorrow."
Joint Vision 2010 (JV 2010) creates a broad framework for understanding joint warfare in the future, and for shaping Service programs and capabilities to fill our role within that framework. JV 2010 defines four operational concepts: Precision Engagement, Dominant Maneuver, Focused Logistics, and Full Dimensional Protection. These concepts combine to ensure that American forces can secure Full Spectrum Dominance, i.e., the capability to dominate an opponent across the range of military operations and domains. Furthermore, Full Spectrum Dominance requires Information Superiority, i.e., the capability to collect, process, analyze, and disseminate information while denying an adversary the ability to do the same. Interoperability is crucial to Information Superiority.
Recognizing the need for joint operations in combat and the reality of a shrinking budget, the Assistant Secretary of Defense (Command, Control, Communications, and Intelligence) (ASD[C3I]) issued a memorandum on 14 November 1995 to Command, Service, and Agency principals involved in the development of Command, Control, Communications, Computers, and Intelligence (C4I) systems. This directive tasked them to "reach a consensus of a working set of standards" and "establish a single, unifying DoD technical architecture that will become binding on all future DoD C4I acquisitions" so that "new systems can be born joint and interoperable, and existing systems will have a baseline to move toward interoperability."
A Joint Technical Architecture Working Group (JTAWG), chaired by ASD(C3I), was formed, and its members agreed to use the U.S. Army Technical Architecture (ATA) as the starting point for the JTA. Version 1.0 of the JTA was released on 22 August 1996 and was immediately mandated by the Under Secretary of Defense, Acquisition and Technology (USD[A&T]) and ASD(C3I) for all new and upgraded C4I systems in DoD.
JTA Version 2.0 development began in March 1997 under the direction of a Technical Architecture Steering Group (TASG), co-chaired by ASD(C3I) and USD(AT&L) Open Systems Joint Task Force (OSJTF). The applicability and scope of Version 2.0 of the JTA was expanded to include the information technology in all DoD systems.
JTA Version 3.0 development began in June 1998. JTA Version 3.0 includes additional subdomains and incorporated the newly developed DoD Technical Reference Model (DoD TRM). JTA Version 3.1 mandated a Gigabit Ethernet standard.
JTA Version 4.0 development began in November 1999. JTA Version 4.0 removes the Orange Book mandate and mandates the Common Criteria.
Architectures Defined
The C4ISR Architecture Framework (CAF) provides information addressing the development and presentation of architectures. The framework provides the rules, guidance, and product descriptions for developing and presenting architectures to ensure a common denominator for understanding, comparing, and integrating architectures across and within DoD.
An architecture is defined as the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time. DoD has implemented this by defining an interrelated set of views: operational, system, and technical. See : Architecture Views Relationships shows the relationship among the three views. The definitions are provided here to ensure a common understanding of the three views.1
|
|
Operational Architecture View
The operational architecture (OA) view is a description of the tasks and activities, operational elements, and information flows required to accomplish or support a military operation.
It contains descriptions (often graphical) of the operational elements, assigned tasks and activities, and information flows required to support the warfighter. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges in detail sufficient to ascertain specific interoperability requirements.
Technical Architecture View
The technical architecture (TA) view is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of requirements.
The technical architecture view provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. The technical architecture view includes a collection of the technical standards, conventions, rules, and criteria organized into profile(s) that govern system services, interfaces, and relationships for particular systems-architecture views and that relate to particular operational views.
Systems Architecture View
The systems architecture (SA) view is a description, including graphics, of systems and interconnections providing for, or supporting, warfighting functions. For a domain, the systems architecture view shows how multiple systems link and interoperate, and may describe the internal construction and operations of particular systems within the architecture. For the individual system, the systems architecture view includes the physical connection, location, and identification of key nodes (including materiel-item nodes), circuits, networks, warfighting platforms, etc., and it specifies system and component performance parameters (e.g., mean time between failure, maintainability, availability). The systems architecture view associates physical resources and their performance attributes to the operational view and its requirements following standards defined in the technical architecture.
Relationships between the C4ISR Architecture Framework 2.0 and the DoD JTA
The C4ISR Architecture Framework defines the technical architecture view and a set of standard technical products for DoD use. The JTA is one of the Universal Reference Resources named in the CAF. The JTA is the primary source document to the essential and supporting Technical Architecture products defined in the C4ISR Architecture Framework. Standards chosen from the JTA and other sources to meet system and operational requirements are incorporated into the technical architecture View.
Document Organization
The JTA is organized into a main body, followed by domains, subdomains, and a set of appendices. This section describes the structure of the document.
General Organization
The main body identifies the "Core" set of JTA elements consisting of service areas, interfaces, and standards. Each section of the main body, except for the overview, is divided into four subsections as follows:
Introduction, Purpose, Scope, and Background: These subsections are for information purposes only. They define the purpose and scope of the document and the section and provide background descriptions and definitions that are unique to this section.
Service Area and Services: This subsection describes the technical overview of the Services in this section.
Mandated Standards: This subsection identifies mandatory standards or practices. Each mandated standard or practice is clearly identified on a separate bulletized ( ) line and includes a formal reference citation suitable for inclusion within Requests for Proposals (RFPs), Statements of Work (SOWs), or Statements of Objectives (SOOs).
Emerging Standards: This subsection provides an information-only description of standards that are candidates for possible addition to the JTA mandates. Each emerging standard is clearly identified on a separate dashed ( - ) line. The purpose of listing these candidates is to help the program manager determine those areas likely to change in the near term (within three years) and suggest those areas in which "upgradability" should be a concern. The expectation is that emerging standards will be elevated to mandatory status when implementations of the standards mature. Emerging standards may be implemented, but shall not be used in lieu of a mandated standard.
Information Technology Standards
The JTA Core, or main body, addresses commercial and government standards common to most DoD information technology, grouped into categories each of which addresses a set of functions common to most DoD IT systems. The information technology categories are:
Information Processing Standards: See Information Processing Standards describes Government and commercial information processing standards DoD uses to develop integrated, interoperable systems that meet the warfighters' information processing requirements.
Information Transfer Standards: See Information Transfer Standards describes the information transfer standards and profiles that are essential for information transfer interoperability and seamless communications. This section mandates the use of the open systems standards used for the Internet and the Defense Information System Network (DISN).
Information Modeling, Metadata, and Information Exchange Standards: See Information Modeling, Metadata, and Information Exchange Standards describes the use of integrated information modeling and mandates applicable standards. Information modeling consists of activity, data, and object modeling. This section explains the use of the DoD Command and Control (C2) Core Data Model (C2CDM) and the Defense Data Dictionary System (DDDS), formerly the Defense Data Repository System (DDRS). This section also mandates information standards, including message formats.
Human-Computer Interface Standards : See Human-Computer Interface Standards provides a common framework for Human-Computer Interface (HCI) design and implementation in DoD systems. The objective is the standardization of user interface implementation options, enabling DoD applications to appear and behave in a reasonably consistent manner. The section specifies HCI design guidance, mandates, and standards.
Information Security Standards : See Information Security Standards prescribes the standards and protocols to be used to satisfy security requirements. This section provides the mandated and emerging security standards that apply to JTA sections 2 through 5.
The JTA Core establishes the minimum set of rules governing information technology across all DoD systems. Additional domain-specific mandates are found in the corresponding domains and subdomains. They include standards for information processing, information transfer, the structure of information and data, human-computer interface for information entry and display, and information system security. Information technology includes any equipment or interconnected system or subsystem of equipment used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information.
Domains and Subdomains
The JTA Core contains the common service areas, interfaces, and standards (JTA elements) applicable to all DoD systems to support interoperability. Recognizing that there are additional JTA elements common within families of related systems (i.e., domains), the JTA adopted the domain and subdomain notion. A domain represents a grouping of systems sharing common functional, behavioral, and operational requirements. JTA domains and subdomains are intended to exploit the common service areas, interfaces, and standards supporting interoperability across systems within the domain and/or subdomain.
A JTA domain contains domain-specific JTA elements applicable within the specified family of systems to further support interoperability within the systems represented in the domain--in addition to those included in the JTA Core. A domain may be composed of multiple subdomains. Subdomains represent the decomposition of a domain (referred to as the subdomain's parent domain) into a subset of related systems, exploiting additional commonalities and addressing variances within the domain. A subdomain contains domain-specific JTA elements applicable within the specified family of systems to further support interoperability within the systems represented in the subdomain--in addition to those included in the JTA Core and in the parent domain. The relationships between the JTA Core, domains, and subdomains currently in the JTA are illustrated in See : JTA Hierarchy Model.
|
|
The current domains and subdomains are listed as follows:
A program manager or engineer specifying or applying JTA standards for a specific system will first select all appropriate JTA Core elements, and then those included in the relevant domain and subdomain.
The goal is to build on these annexes by incorporating the requirements of additional domains and subdomains. Each domain and subdomain includes an introduction clearly specifying the purpose, scope, description of the domain, and background of the domain and subdomain. As necessary, each domain and subdomain provides a list of domain-specific standards and guidance in a format
consistent with the JTA Core. Domains and subdomains generally use the DoD Technical Reference Model (DoD TRM) defined in See DoD Technical Reference Model, but may also use a different or expanded model.
Appendices (Appendix A, B, C, D, E, F)
The appendices provide supporting information (e.g., how to get a copy of mandated standards) and available links to standards organizations' web site, which facilitate the use of the document, but are not mainline to its purpose.
See contains an abbreviations and acronyms list.
See now a stand-alone document on the JTA Web site, contains "currently mandated," "previously mandated," and "emerging" standards for each JTA service area.
See is a list of the organizations from which documents cited in the JTA may be obtained.
See is a list of documents (e.g., a memorandum, a publication) that directs the reader's attention to a source of more information on a subject.
See describes the relationship of the JTA to the DoD standards reform begun in June 1994 and addresses the relevance of the reform waiver policy to the JTA.
See is a list of terms with their meanings.
DoD Technical Reference Model
The DoD Technical Reference Model (TRM), Version 1.0, 5 November 1999, and the core set of standards mandated in the JTA define the target technical environment for the acquisition, development, and support of DoD information technology. The purpose of the TRM is to provide a common conceptual framework and a common vocabulary so that the diverse components within DoD can better coordinate acquisition, development, and support of DoD information technology. Interoperability is dependent on the establishment of a common set of services and interfaces that system developers can use to resolve technical architectures and related issues.
The TRM structure is intended to reflect the separation of data from applications, and applications from the computing platform--a key principle in achieving open systems. The JTA has adapted the TRM to serve as the framework for presenting JTA-mandated standards. The JTA's use of the TRM ensures the use of consistent definitions needed to define architectural and design components. The model identifies service areas (i.e., a set of capabilities grouped by functions) and their interfaces. The TRM was chosen as the framework of the JTA because of the model's inherent support of open system concepts. As illustrated in See : DoD Technical Reference Model (DoD TRM), the model is partitioned into the following: an Application Software Entity that includes both Mission Area and Support Applications; an Application Platform Entity that contains the system services (e.g., User Interface and Data Management services) and operating system services; Physical Environment Services; and External Environment; and a number of interfaces. The interfaces provide support for a wide range of applications and configurations and consist of the following: Application Program Interfaces (APIs) and External Environment Interfaces (EEIs).
The following JTA Core services are equivalent to their corresponding TRM system services contained within the Application Platform Entity:
|
|
The relationship between the sections in the JTA and the TRM service areas are as follows:
See Information Processing Standards Information Processing Standards specifies standards for the User Interface (See User Interface Services), Data Management (See Data Management Services), Data Interchange (See Data Interchange Services), Graphics (See Graphic Services), Operating System (See Operating System Services), Internationalization (See Internationalization Services), and Distributed Computing (See Distributed Computing Services) service areas, and the latter's two subordinate paragraphs become See Remote-Procedure Computing and See Distributed-Object Computing respectively. This section also references, but does not specify, any standards for the Software Engineering (See Software Engineering Services), Communications (See Communications Services), Security (See Security Services), and System Management (See System Management Services) service areas.
See : Interface Translation Table provides the interface relationships for See : DoD Technical Reference Model (DoD TRM).
See Information Transfer Standards Information Transfer Standards specifies standards for the Communications (See Communications through See Transmission Media) and Network and System Management (See Network and Systems Management) service areas applicable to both system and network management.
See Information Modeling, Metadata, and Information Exchange Standards Information Modeling, Metadata, and Information Exchange Standards addresses standards for an area that is not currently elaborated, but is supported by engineering support, data management, and software engineering services in the TRM.
See Human-Computer Interface Standards Human Computer Interface Standards complements those cited for User Interface Services in See User Interface Services User Interface Services.
See Information Security Standards Information Security Standards, specifies security standards that are relevant to the service areas discussed in See Information Processing Standards, See Information Transfer Standards, and See Human-Computer Interface Standards.
At this time, the JTA does not include standards for all of the services identified in the TRM.
Key Considerations in Using the JTA
The JTA is used to determine the mandated standards within applicable service areas for implementation within new or upgraded systems. However, there are several key considerations in using the JTA.
The mandatory standards in the JTA must be implemented or used by systems that have a need for the corresponding service areas. A standard is mandatory in the sense that if a service/interface is going to be implemented, it shall be implemented in accordance with the associated standard. If a required service can be obtained by implementing more than one standard (e.g., operating system standards), the appropriate standard should be selected based on system requirements.
The JTA is a forward-looking document. It guides the acquisition and development of new and emerging functionality and provides a baseline toward which existing systems will move. It is a compendium of standards (for interfaces/services) that should be used now and in the future. It is not a catalog of all information technology standards used within today's DoD systems. If legacy standards are needed to interface with existing systems, they can be implemented on a case-by-case basis in addition to the mandated standard.
Element Normalization Rules
As the JTA evolves, the JTA elements contained in the JTA Core, domains, and subdomains need to be periodically revisited and updated to ensure correctness. The JTA normalization rules in this section address the movement of elements from subdomain to domain, and from domains into the Core.
All standards are placed in the Core unless they are justified as unacceptable to meet domain-specific requirements. When Core standards cannot meet the requirements of a specific domain,
JTA elements are removed from the JTA Core and placed in the appropriate domain. Likewise, when domain standards cannot meet subdomain-specific requirements, those will be removed from the domain and placed in the appropriate subdomain.
The intent of the above normalization rules is as follows: (1) The Core applies to all DoD systems; (2) the JTA Core contains selected standards for as many JTA services as possible; and (3) the JTA provides the minimum number of standards for a specified service or interface.
JTA Relationship to DoD Standards Reform
The DoD standards reform was begun in June 1994 when the Secretary of Defense issued a memorandum entitled "Specifications and Standards - A New Way of Doing Business." This memorandum directs that performance-based specifications and standards or nationally recognized private-sector standards be used in future acquisitions. The intent of this initiative is to eliminate non-value-added requirements, and thus reduce the cost of weapon systems and materiel, remove impediments to getting commercial state-of-the-art technology into weapon systems, and integrate the commercial and military industrial bases to the greatest extent possible.
The JTA implements standards reform by selecting the minimum standards necessary to achieve joint interoperability. The JTA mandates commercial standards and practices to the maximum extent possible. Use of JTA-mandated standards or specifications in acquisition solicitations will not require a waiver from standards reform policies. All mandatory standards in the JTA are of the types that have been identified by the DoD standards reform as waiver-free or for which an exemption has already been obtained. Additional information on this topic can be found in See .
Standards Selection Criteria
The standards selection criteria used throughout the JTA focus on mandating only those items critical to interoperability that are based primarily on commercial open system technology, are implementable, and have strong support in the commercial marketplace. Standards will only be mandated if they meet all of the following criteria:
The following preferences were used to select standards:
Standards that are commercially supported in the marketplace with validated implementations available in multiple vendors' mainstream commercial products took precedence.
International or national industry standards were preferred over military or other government standards.
Standards that can be implemented without requiring intellectual property (patent) rights were generally preferred.
Many standards have optional parts or parameters that can affect interoperability. In some cases, an individual standard may be further defined by a separate, authoritative document called a "profile" or a "profile of a standard," which further refines the implementation of the original standard to ensure proper operation and assist interoperability.
The word "standards" as referred to in the JTA is a generic term for the collection of documents cited herein. An individual "standard" is a document that establishes uniform engineering and technical requirements for processes, procedures, practices, and methods. A standard may also establish requirements for selection, application, and design criteria of material. The standards cited in the JTA may include commercial, federal, and military standards and specifications, and various other kinds of authoritative documents and publications.
Configuration Management
The JTA is configuration-managed by the Joint Technical Architecture Development Group (JTADG), under the direction of the DoD Technical Architecture Steering Group (TASG) and approved by the Architecture Coordination Council (ACC). These groups consist of members representing DoD and components of the Intelligence Community. See : JTA Development Group (JTADG) Voting Membership shows the organizations that have voting memberships in the JTADG and TASG.
The JTA Management Plan describes the process by which the JTA will be configuration-managed. This document, as well as the charter for the JTADG, may be found on the Defense Information Systems Agency (DISA) Center for Standards (CFS) JTA Web site: http://www-jta.itsi.disa.mil .
Suggested changes to, or comments on, the JTA originating from DoD Components (Office of the Secretary of Defense [OSD], the Military Departments, the Office of the Joint Chiefs of Staff [OJCS], the Unified and Specified Combatant Commands, and the Defense Agencies) should be submitted via the appropriate official JTA Component Representative listed on the JTA Web site. These representatives will integrate and coordinate received comments for submission as official DoD Component-sponsored comments.
Where a standard is highlighted and underscored , it is hyperlinked to the DoD Joint Technical Architecture (JTA) List of Mandated and Emerging Standards (formerly Appendix B). A "link" symbol ( ) at the end of a citation for a standard indicates the hyperlink to the web site where the standard can be obtained. Clicking on the "link" symbol will access the corresponding web site.
Industry and other non-DoD suggested changes should be submitted through DISA CFS via electronic mail to: jta@www.disa.mil .
Information Processing Standards
Introduction
Purpose
The purpose of this section is to specify the Joint Technical Architecture (JTA) Government and commercial information processing standards DoD will use to develop integrated interoperable systems that directly or indirectly support the warfighter.
Scope
This section applies to mission-area, See : HCI Development Guidance support application, See : JTA Hierarchy Model and application platform service software. This section does not cover communications standards needed to transfer information between systems (defined in See Information Transfer Standards), nor standards relating to information modeling (process, data, and simulation), data elements, or military-unique message set formats (defined in See Information Modeling, Metadata, and Information Exchange Standards).
Background
Information processing standards provide the data formats and instruction-processing specifications required to represent and manipulate data to meet information technology (IT) mission needs. The standards in this section are drawn from widely accepted commercial standards that meet DoD requirements. Where necessary for interoperability, profiles of commercial standards are used. Military standards are mandated only when suitable commercial standards are not available.
Mandated Standards
The following sections provide the applicable mandated standards that shall be used for the selection of commercial off-the-shelf (COTS) or Government off-the-shelf (GOTS) software or in the development of Government software. Appendix B links to the table DoD Joint Technical Architecture List of Mandated and Emerging Standards on the JTA web site.
Application Software Entity
The Application Software Entity is one part of the DoD Technical Reference Model (TRM) that includes both mission-area applications and support applications. Mission-area applications implement specific users' requirements and needs (e.g., personnel, material, management). This application software may be COTS, GOTS, custom-developed software, or a combination of these.
Common support applications (e.g., e-mail and word processing) are those that can be standardized across individual or multiple mission areas. The services they provide can be used to develop mission-area-specific applications or can be made available to the user. The TRM defines six support application categories: Multimedia, Communications, Business Processing, Environment Management, Database Utilities, and Engineering Support. The definitions of these categories are found in the DoD Technical Reference Model, Version 1.0, 5 November 1999.
Application Platform Entity
The Application Platform Entity is the second layer of the DoD TRM, as shown in See : DoD Technical Reference Model (DoD TRM), and includes the common system services upon which required information processing functionality is built. The Application Platform Entity is composed of 11 service areas. The corresponding mandates are provided in the following subsections.
Service Areas
Eleven primary system services and operating systems services are defined within the Application Platform Entity: Software Engineering, User Interfaces, Data Management, Data Interchange, Graphics, Communications, Operating System, Internationalization, Security, System Management, and Distributed Computing Services.
Software Engineering Services
The software engineering services provide system developers with the tools that are appropriate to the development and maintenance of applications. There are no mandated standards for this service area.
Language services provide the basic syntax and semantic definition for use by developers to describe the desired software function. "Programming language selections should be made in the context of the system and software engineering factors that influence overall life-cycle costs, risks, and potential for interoperability."2 Computer languages should be used in such a way as to minimize changes when compilers, operating systems, or hardware change. To maximize portability, the software should be structured where possible so it can be easily ported.
User Interface Services
User Interface Services control how a user interfaces with an information technology system. The Common Desktop Environment (CDE) provides a common set of desktop applications and management capabilities for environments similar to the Microsoft Windows desktop environment. CDE supports The Open Group Motif-based application execution. Both CDE and Motif applications use the underlying X-Windows system. The Win32 Application Program Interface (API) set provides similar services for Microsoft Windows applications. Refer to See Human-Computer Interface Standards for Human-Computer Interface (HCI) style guidance and standards.
User Interface Service -- POSIX
The Common Desktop Environment (CDE) provides a common set of desktop applications and management capabilities for use with Portable Operating System Interface (POSIX)-based operating systems. CDE supports The Open Group Motif-based application execution. Both CDE and Motif applications use the underlying X-Windows system. The following standards are mandated for use with Portable Operating System Interface (POSIX)-compliant operating systems running (or intended to run) POSIX-compliant applications:
Currently, the CDE and Motif User Interface Service Standards are mandated; but, due to changing market conditions, they are candidates for removal in a future version of the JTA.
C323 , XCDE Services and Applications, Open Group Technical Standard, ISBN 1-85912-074-1, April 1995.
C324 , XCDE Definitions and Infrastructure, Open Group Technical Standard, ISBN 1-85912-070-9, April 1995.
C508 , Window Management (X11R5): Xlib - C Language Binding, Open Group Technical Standard, ISBN 1-85912-088-1, May 1995, as updated by X11R6.
C509 , Window Management (X11R5): X Toolkit Intrinsics, Open Group Technical Standard, ISBN 1-85912-089-X, May 1995, as updated by X11R6.
C510 , Window Management (X11R5): File Formats and Application Conventions, Open Group Technical Standard, ISBN 1-85912-090-3, May 1995.
M023 : CDE 2.1 Programmer's Overview and Guide, Open Group Product Documentation, ISBN 1-85912-183-7, October 1997.
M024A : CDE 2.1 Programmer's Reference, Volume 1, Open Group Product Documentation, ISBN 1-85912-188-8, October 1997.
M024B : CDE 2.1 Programmer's Reference, Volume 2, Open Group Product Documentation, ISBN 1-85912-193-4, October 1997.
M024C : CDE 2.1 Programmer's Reference, Volume 3, Open Group Product Documentation, ISBN 1-85912-174-8, October 1997.
User Interface Service -- Win32
User Interface API Services defines the software interfaces needed to control user interfaces with an information technology system. The Win32 API set provides User Interface Services for Microsoft Windows and Windows-compliant applications. Documentation for the Win32 APIs is found within the Microsoft Platform Software Development Kit (SDK). This documentation is mandated for use with any operating system running (or intended to run) Win32 applications:
Data Management Services
Central to most systems is the sharing of data between applications. The data management services provide for the independent management of data shared by multiple applications.
These services support the definition, storage, and retrieval of data elements from Database Management Systems (DBMSs). Application code using Relational Database Management System (RDBMS) resources and COTS RDBMSs are required to conform to Entry-Level SQL. The following standard is mandated for any system using an RDBMS:
In addition, the SQL/Call Level Interface (CLI) addendum to the SQL standard provides a standard CLI between database application clients and database servers. The following API is mandated for both database application clients and database servers:
The ISO/IEC 9075-3 mandate does not preclude the use of Open Database Connectivity (ODBC) 3.0 or Java Database Connectivity (JDBC) extensions in situations where the capabilities supported by ISO/IEC 9075-3 cannot satisfy user-functional requirements. Note that ISO/IEC 9075-3 is a subset of ODBC 3.0.
Data Interchange Services
The data interchange services provide specialized support for the exchange of data between applications and to and from the external environment. These services include document, graphics data, geospatial data, still imagery data, motion imagery data, audio data, storage media, atmospheric and oceanographic data, and time-of-day data.
Document Interchange
The Standard Generalized Markup Language (SGML) format supports the production of documents intended for long-term storage and electronic dissemination for viewing in multiple formats. SGML formalizes document mark-up, making the document independent of the production and/or publishing system. SGML is an architecture-independent and application-independent language for managing document structures. SGML is a meta-language, providing the rules for designing and applying a system of markup tags rather than the specific set of tags. The following standard is mandated:
The Hypertext Markup Language (HTML) is used for hypertext-formatted and navigational-linked documents. For hypertext documents intended to be interchanged via the Web or made available via organizational intranets, the following standard is mandated:
The Extensible Markup Language (XML) is a meta-language, based on SGML, for describing languages based on name-attribute tuples. This allows new capabilities to be defined and delivered dynamically. For domain- and application-specific markup languages defined through tagged data items, the following is a mandated standard:
See : Common Document Interchange Formats identifies file formats for the interchange of common document types such as text documents, spreadsheets, and presentation graphics. Some of these formats are controlled by individual vendors, but all of these formats are supported by products from multiple companies. In support of the standards mandated in this section, See : Common Document Interchange Formats identifies conventions for file name extensions for documents of various types. If an organization has a requirement for a given document type, the formats in See : Common Document Interchange Formats are mandated, but not the specific products mentioned:
All applications acquired or developed for the production of documents shall be capable of generating at least one of the formats listed in See : Common Document Interchange Formats for the appropriate document type.
Notes: Compound documents contain embedded graphics, tables, and formatted text. Object Linking and Embedding (OLE) linking complicates document interchange. IRV is International Reference Version. Some special fonts, formatting, or features supported in the native file format may not convert accurately.
Graphics Data Interchange
These services are supported by device-independent descriptions of the picture elements for vector and raster graphics. The International Organization for Standardization (ISO) Joint Photographic Expert Group (JPEG) standard describes several alternative algorithms for the representation and compression of raster images, particularly for imagery; JPEG images may be transferred using the JPEG File Interchange Format (JFIF). Graphics Interchange Format (GIF) and JFIF are de facto standards for exchanging graphics and images over an internet. GIF supports lossless compressed images with up to 256 colors and short animation segments. Note that Unisys owns a related patent, which requires a license for software that writes the GIF format. Portable Network Graphics (PNG) is an extensible file format for the lossless, portable, well-compressed storage of a raster image. Indexed-color, grayscale, and truecolour images are supported, plus an optional alpha channel for transparency. The PNG specification was issued as a W3C Recommendation on 1 October 1996.
For the interchange of very large still-raster images that have no geospatial context and where lossy compression is acceptable, the mandated standard is:
For the interchange of other single raster images that have no geospatial context and where lossy compression is not acceptable or is ineffective, the mandated standard is:
For the lossless interchange of raster images that have no geospatial context and where none of the above cases apply, such as the exchange of still images that can be viewed in sequence (also referred to as animation), the mandated standard is:
Geospatial Data Interchange
Geospatial services are also referred to as mapping, charting, and geodesy (MC&G) services. Raster Product Format (RPF) defines a common format for the interchange of raster-formatted digital geospatial data among DoD Components. Existing geospatial products that implement RPF include Compressed ARC Digitized Raster Graphics (CADRG), Controlled Image Base (CIB), and Digital Point Positioning Data Base (DPPDB). For raster-based products, the following standard is mandated:
Vector Product Format (VPF) defines a common format, structure, and organization for data objects in large geographic databases based on a georelational data model and intended for direct use. Existing geospatial products that implement VPF include: Vector Map (VMap) Levels 0-2, Urban Vector Map (UVMap), Digital Nautical Chart (DNC), VPF Interim Terrain Data (VITD), Digital Topographic Data (DTOP), and World Vector Shoreline Plus (WVS PLUS ). For vector-based products, the following standard is mandated:
WGS84, a Conventional Terrestrial Reference System (CTRS), is mandated for representation of a reference frame, reference ellipsoid, fundamental constants, and an Earth Gravitational Model with related geoid. Included in the Reference System are parameters for transferring to/from other geodetic datums. The National Imagery and Mapping Agency (NIMA) Technical Report (TR) 8350.2, Third Edition DoD World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems, 4 July 1997, defines the technical content of WGS 84. WGS 84 will be used for all joint operations and is recommended for use in multinational and unilateral operations after coordination with allied commands. The following standard is mandated:
FIPS PUB 10-4 provides a list of the basic geopolitical entities in the world, together with the principal administrative divisions that comprise each entity. For applications involving the interchange of geospatial information requiring the use of country codes, the following standard is mandated:
Additional information on other geospatial services not identified in the mandated standards is available in NIMAL 805-1A, NIMA GGI&S List of Products and Services, January 1997.
Still Imagery Data Interchange
The National Imagery Transmission Format Standard (NITFS) is a DoD and Federal Intelligence Community suite of standards for the exchange, storage, and transmission of digital imagery products and image-related products. Other image formats can be used internally within a single system; however, NITF is the default format for interchange between systems. NITFS provides a package containing information about the image, the image itself, and optional overlay graphics. The standard provides a "package" containing an image(s), subimages, symbols, labels, and text as well as other information related to the image(s). NITFS supports the dissemination of secondary digital imagery from overhead collection platforms. Guidance on applying the suite of standards composing NITFS can be found in MIL-HDBK-1300A. The following standards are mandated for imagery product dissemination:
MIL-STD-2500B , National Imagery Transmission Format (Version 2.1) for the National Imagery Transmission Format Standard, 22 August 1997 with Notice 1, 2 October 1998.
MIL-STD-188-196 , Bi-Level Image Compression for the National Imagery Transmission Format Standard, 18 June 1993 with Notice 1, 27 June 1996.
MIL-STD-188-199 , Vector Quantization Decompression for the National Imagery Transmission Format Standard, 27 June 1994 with Notice 1, 27 June 1996.
ISO/IEC 8632:1992 Computer Graphics Metafile (CGM) for the Storage and Transfer of Picture Description Information, as profiled by MIL-STD-2301A, Computer Graphics Metafile (CGM) Implementation Standard for the National Imagery Transmission Format Standard, 5 June 1998.
ISO/IEC 10918-1:1994 , Joint Photographic Experts Group (JPEG) as profiled by MIL-STD-188-198A, Joint Photographic Experts Group (JPEG) Image Compression for the National Imagery Transmission Format Standard, 15 December 1993 with Notice 1, 12 October 1994 and Notice 2, 14 March 1997. Although the NITFS uses the same ISO JPEG algorithm as mandated in See Graphics Data Interchange, the NITFS file format is not interchangeable with the JFIF file format.
Communication protocols for the transmission of imagery over point-to-point tactical data links in high Bit Error Rate (BER), disadvantaged communications environments are specified in See Imagery Dissemination Communications Standards.
Motion Imagery Data Interchange
Motion Imagery (MI) is defined as imaging sensors/systems that generate/process sequential or continuous streaming images at specified temporal rates (normally expressed as Frames Per Second [FPS] or hertz [Hz]) within a common field of regard. Motion Imagery defines temporal domains of 1 Hz or higher, and still imagery defines temporal domains of less than 1 Hz.
Video Systems
Video systems, defined as electro-optical motion imagery whose formats are governed by national and international standards, are divided into four categories:
Video Imagery Systems, which create, transmit, edit, store, archive, or disseminate digital video for real-time, near-real-time or for other end-user product distribution, usually in support of Intelligence, Surveillance, and Reconnaissance (ISR) activities.
Video Teleconference Systems, which provide real-time visual interchange between remote locations typically in support of meetings. When video teleconference systems are used for the display of Video Imagery, the standards in the Video Imagery section apply.
The standards and use directives for each class of video system are noted in the following sections:
Video Imagery
The following standards, as they are profiled by the Motion Imagery Standards Profile (MISP) 1.6 Chapter 2.0, Commercial Standards, Interoperability Profiles, and Recommended Practices for DoD/IC/USIGS Implementations, 27 July 2000, are mandated:
The standards for the Video Imagery section do not completely define an architecture for interoperability for low bandwidth (below 1.5 Mbps) real-time streaming applications. Standards for such low-bandwidth applications are actively under development. Until such standards are available, users may use "MPEG-1" or "MPEG-2 4:20 MP@ML Adaptive Field Frame" standards for low bandwidth video applications. DoD users who adopt proprietary video compression systems for very low bandwidth applications are cautioned that such systems are generally not supported within DoD and that the interoperability of such systems is not ensured. It is also anticipated that MPEG-4 may be used for very low data rate video dissemination applications (such as VSM 1 and VSM 2).
Video Teleconference
Video Teleconferencing (VTC) standards are specified in See Video Teleconferencing Standards.
Video Support
MPEG-1 is an open international standard for video compression that has been optimized for single- and double-speed CD-ROM data transfer rates. The standard defines a bit-stream representation for synchronized digital video and audio, compressed to fit into a bandwidth of 1.5 Mbps. This corresponds to the data retrieval speed from CD-ROM and Digital Audio Tape (DAT). With 30 FPS video at a display resolution of 352 x 240 pixels, the quality of compressed and decompressed video at this data rate is often described as similar to that of a VHS recording. A major application of MPEG is the storage of audiovisual information on CD-ROM and DAT. MPEG is also gaining ground on the Internet as an interchange standard for video clips because the shell format is interoperable across platforms and considered to be platform-independent. The following standards are mandated:
MPEG-2 Main Profile @ Main Level (MP@ML) 4:2:0 systems are fully backward-compatible with the MPEG-1 standard. MPEG-2 MP@ML can be used with all video support systems (storage, broadcast, network) at bit rates from 3 to 10 Mbps, where limited additional processing is anticipated, operating in either progressive or interlaced scan mode, optimally handling the resolution of the ITU-R 601 recommendation (i.e., 720 x 480 pixels for the luminance signal and 360 x 480 pixels for the color space). The following video support standards for compressed video are mandated:
Audio Data Interchange
Effective compression of audio data depends not only upon data compression techniques but also upon the application of a psycho-acoustic model that predicts which sounds humans are likely to be able to hear or not hear in given situations. The sounds selected for elimination depend on the bit rate available for streaming the audio data when the file is decoded and played. Therefore, the best selection of a file format depends upon the bandwidth assumed to be available on the platform that will decode the file. For audio files intended to be decoded in an environment with a target bit rate of about 56 to 64 kilobits per second (Kbps) per audio channel, the following standards are mandated:
Audio Associated with Video
The classes of audio in support of video have been subdivided into four categories:
Audio for Video Imagery Systems , which create, transmit, edit, store, archive, or disseminate audio for real-time, near-real-time, and other end-user product distribution, usually in support of Intelligence, Surveillance, and Reconnaissance (ISR) activities.
Audio for Video Teleconference Systems , which provide real-time verbal interchange between remote locations, typically in support of meetings. When video teleconference systems are used for the display of Video Imagery, the standards in the Audio for Video Imagery section apply.
Audio for Video Telemedicine Systems , which provide real-time visual interchange between remote locations in support of biomedical applications including fiber-optic and video teleconferencing.
Audio for Video Support Systems , which enable end-user applications associated with video/audio-based training, news gathering, or other non-critical functions that do not directly support the warfighter. This includes traditional studio and field productions not associated with DoD warfighting operations.
The standards and use directives for each category of audio application are given in the following sections.
Audio for Video Imagery
For audio systems associated with Video Imagery applications, the audio sub-sections of the Video Imagery Standards Profile (VISP), Version 1.5, 8 September 1999, apply.
Audio for Video Teleconference
Video Teleconferencing (VTC) standards are specified in See Video Teleconferencing Standards.
Audio for Video Support
Effective compression of audio data depends not only upon data compression techniques but also upon the application of a psycho-acoustic model that predicts which sounds humans are likely to be able to hear or not hear in given situations. The sounds selected for elimination depend on the bit rate available for streaming the audio data when the file is decoded and played. Therefore, the best selection of a file format depends upon the bandwidth assumed to be available on the platform that will decode the file. For audio files intended to be decoded in an environment with a target bit rate of about 56 to 64 Kbps per audio channel, the following standard is mandated:
Voice Encoder
The 2.4 Kbps Mixed Excitation Linear Prediction (MELP) algorithm specified in MIL-STD-3005 is intended to provide seamless interoperability, hence enabling end-to-end security, across the domains of strategic, tactical, satellite communications, including that of internetworking protocols. MIL-STD-3005 provides a common high-performance voice encoding algorithm for use across the communications infrastructure. For processing over 2.4 Kbps digital links (voice data), the following standard is mandated:
Data Interchange Storage Media
MIL-HDBK-9660B, 1 September 1997, provides additional guidance in the use of Compact Disc-Read Only Memory (CD-ROM) technology. In cases where CD-ROM/CD-RW media is used, the following file system format (at a minimum) is mandated:
Additional standards used for the exchange of multimedia data can be found in See Video Teleconferencing Standards.
Atmospheric and Oceanographic Data Interchange
The following formats are established by the World Meteorological Organization (WMO) Commission for Basic Systems (CBS) for atmospheric and oceanographic data. The WMO Format for the Storage of Weather Product Information and the Exchange of Weather Product Messages in Gridded Binary (GRIB) Form was developed for the transfer of gridded data fields, including spectral model coefficients, and of satellite images. A GRIB record (message) contains values at grid points of an array, or a set of spectral coefficients, for a parameter at a single level or layer as a continuous bit stream. It is an efficient vehicle for transmitting large volumes of gridded data to automated centers over high-speed telecommunications lines using modern protocols. It can serve as a data storage format. While GRIB can use predefined grids, provisions have been made for a grid to be defined within the message. The following standard is mandated:
The WMO Binary Universal Format for Representation (BUFR) is used for interchange of atmospheric and oceanographic data. Besides being used for the transfer of data, BUFR is used as an online storage format and as a data-archiving format. A BUFR record (message) containing observational data of any sort also contains a complete description of what those data are: the description includes identifying the parameter in question (height, temperature, pressure, latitude, date, and time); the units (any decimal scaling that may have been employed to change the precision from that of the original units); data compression that may have been applied for efficiency; and the number of binary bits used to contain the numeric value of the observation. BUFR is a purely binary or bit-oriented form. The following standard is mandated:
Time-of-Day Data Interchange
Coordinated Universal Time (UTC), traceable to UTC (USNO) maintained by the U.S. Naval Observatory (USNO), shall be used for time-of-day information exchanged among DoD systems. Time-of-day information is exchanged for numerous purposes including time-stamping events, determining ordering, and synchronizing clocks. Traceability to UTC (USNO) may be achieved by various means depending on system-specific accuracy requirements. These means may range from a direct reference via a GPS time code receiver to a manual interface involving an operator, wristwatch, and telephone-based time service. The UTC definition contained in the following standard, traceable to UTC (USNO), is mandated:
In those systems where relativistic effects matter, the following standard is mandated:
Note that the Global Positioning System (GPS) provides time-of-day information traceable to UTC (USNO). Also, note that leap seconds are inserted or deleted when necessary in UTC to keep the time-of-day system synchronized with the Earth's rotation. See Paragraph for a GPS discussion, required standards, and guidelines.
Graphic Services
These services support the creation and manipulation of graphics. The following standards are mandated for non-COTS graphics development:
Communications Services
These services support the distributed applications that require data access and applications interoperability in networked environments. The mandated standards are provided in See Information Transfer Standards.
Operating System Services
These core services are necessary to operate and administer a computer platform and to support the operation of application software. They include kernel operations, shell, and utilities. The operating system controls access to information and the underlying hardware. These services shall be accessed by applications through either the standard Portable Operating System Interface (POSIX) or Win32 APIs.
When requiring real-time operating systems, the IEEE 1003.13:1998 Standardized Application Environment Profile - POSIX Realtime Application Support standard should be considered for use. It has been designed to satisfy a wide range of real-time system requirements based upon the Application Platform's size and function. It identifies four real-time application environment profiles based on the ISO/IEC 9945-1 series of standards including: Minimal Realtime System Profile (PSE51), Realtime Controller System Profile (PSE52), Dedicated Realtime System Profile (PSE53), and Multi-Purpose Realtime System Profile (PSE54).
Not all operating system services are required to be implemented, but those that are used shall comply with the standards listed below. The following standards are mandated:
Note: References to "C language" and "Ada language" are part of the formal titles of some standards in this section, denoting the language used to define the standard. The following standards are mandated for use with POSIX-compliant operating systems running (or intended to run) POSIX-compliant applications:
ISO/IEC 9945-1:1996 , Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C language] (Mandated Services).
ISO/IEC 9945-1:1996 , (Real-time Extensions) to ISO/IEC 9945-1:1996, Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C language] (Real-time Optional Services).
ISO/IEC 9945-1:1996 , (Thread Extensions) to ISO/IEC 9945-1:1996, Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C language] (Thread Optional Services).
ISO/IEC 9945-2:1993 , Information Technology Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities, Information Technology - Portable Operating System Interface (POSIX) - Recommendations (Section 12) and Implementation Guidance (Section 13).
Documentation for the Win32 APIs is found within the Microsoft Platform SDK. This documentation is mandated for use with any operating system running (or intended to run) Win32 applications:
Internationalization Services
The internationalization services provide a set of services and interfaces that allow a user to define, select, and change between different culturally related application environments supported by the particular implementation. These services include character sets, data representation, cultural convention, and native-language support.
In order to interchange text information between systems, it is fundamental that systems agree on the character representation of textual data. The following character set coding standards, which build upon the ASCII character set, are mandated for the interchange of 8-bit and 16-bit textual information respectively:
Security Services
These services assist in protecting information and computer platform resources. They must often be combined with security procedures, which are beyond the scope of the information technology service areas, to fully meet security requirements. Security services include security policy, accountability, and assurance. (Note: Security Service standards have been consolidated in See Information Security Standards)
System Management Services
These services provide capabilities to manage an operating platform and its resources and users. System management services include configuration management, network management, fault management, and performance management. The JTA facilitates interoperability by identifying network management standards. These standards can be found in sections See Network and Systems Management and See Network Management.
Distributed Computing Services
These services allow various tasks, operations, and information transfers to occur on multiple physically or logically dispersed computer platforms. These services include, but are not limited to: global time; data, file, and name services; thread services; and remote-process services. There are two categories of Distributed Computing Services: Remote-Procedure Computing and Distributed-Object Computing.
Remote-Procedure Computing
The mandated standards for remote-procedure computing are identified in the Open Group Distributed Computing Environment (DCE) Version 1.1. The mandated standards are:
The C311 specification is included here to provide the complete definition of the DCE. See Information Security Standards, Information Security Standards, specifies the other security requirements that must be met.
When used in conjunction with the POSIX Threads Extensions, the recommendations of the Open Group's Single UNIX Specification Version 2 - 6 Vol Set for UNIX 98 are expected to integrate the DCE thread model with the POSIX thread model.
Distributed-Object Computing
The mandate for distributed-object computing is interworking with the Object Management Group (OMG) Object Management Architecture (OMA), composed of the Common Object Request Broker Architecture (CORBA), CORBAservices, and CORBAfacilities. The CORBA specification defines the interfaces and services for Object Request Brokers, including an Interface Definition Language (IDL) and the Internet Inter-ORB Protocol (IIOP). CORBAservices define interfaces and semantics for services required to support distributed objects, such as naming, security, transactions, and events. CORBAfacilities defines interfaces and semantics for services required to support functions such as compound document manipulation. Interworking is the exchange of meaningful information between computing elements (semantic integration). Application-Level Interworking, for CORBA, results in CORBA clients interacting with non-CORBA servers and non-CORBA clients interacting with CORBA servers. For OLE/COM, Application-Level Interworking results in COM/OLE clients interacting with non-COM/OLE servers and non-COM/OLE clients interacting with COM/OLE servers.
The CORBA interoperability mandate does not preclude the use of other distributed-object technologies, such as ActiveX/Distributed Component Object Model (DCOM) or Java, as long as the capability for interworking with CORBA applications and objects is maintained by the non-CORBA system. Products are available that allow interworking among distributed-object techniques. Interworking with the following specification is mandated:
When a CORBA Object Request Broker (ORB) is used, the following specifications are mandated if the corresponding object service is being implemented:
For DCE users that need to interwork with CORBA, the following standard is mandated:
For COM users that need to interwork with CORBA, the following standards are mandated:
Emerging Standards
Emerging standards are expected to be elevated to mandatory status when implementations of the standards mature and the standards meet all criteria in See Standards Selection Criteria.
Data Management
Parts one through five of the emerging SQL3 specification were completed in December 1999 and contain a number of data abstraction facilities, including user-defined data types and methods. The emerging SQL specification also contains facilities for defining and referencing object identifiers. Additionally, the emerging SQL3 specification supports knowledge-based data management and remote data access capabilities. The following SQL3 standards are emerging and have been completed and approved by ANSI, ISO, and IEC:
ANSI/ISO/IEC 9075-1:1999 , Information technology - Database languages - SQL - Part 1: Framework (SQL/Framework).
ANSI/ISO/IEC 9075-2:1999 , Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation).
ANSI/ISO/IEC 9075-3:1999 , Information technology - Database languages - SQL - Part 3: Call-Level Interface (for SQL3).
Additionally, ISO/IEC DIS 9075-9 through ISO/IEC DIS 9075-12 are in progress though they have not been completed.
SQL Multimedia (SQL/MM) is a set of extensions to the SQL3 specification and will specify packages of SQL abstract data type (ADT) definitions using the facilities for ADT specification and invocation provided in the SQL3 specification. SQL/MM intends to standardize class libraries for science and engineering; full-text and document processing; and methods for the management of multimedia objects such as image, sound, animation, music, and video. The emerging standard for SQL/MM is:
The SQL - RDA standard specifies a message format for remote communication of SQL database language statements (query and update) to a remote database. The specification defines uses of the message fields and other implementation information including sequencing and how SQL statements map to the Remote Database Access (RDA) protocol, a TCP/IP-compatible communications protocol that enables a database client to gain access to database servers. The emerging standard for SQL - RDA is:
The Object Database Management Group (ODMG) has published a third version of their standard for an Object Storage API that can work with any DBMS or tool. The ODMG has defined a comprehensive object model, described an object specification language, defined an object interchange format, defined an object query language (based on the relational query language, SQL) and worked to make the programming language bindings consistent with the ODMG model. Version 3.0 improves the ODMG model, enhances the Java bindings, and broadens the standard for use by object-relational mapping systems as well as for object DBMSs. The ODMG specification is published as a hard-cover book. The following standard is emerging:
Data Interchange
Document Interchange
XHTML (Extensible HyperText Markup Language) is the next-generation follow-on to HTML. XHTML reformulates HTML as an XML (Extensible Markup Language) application, bringing the modular capabilities of XML to Web development. A single XML data stream can be used by a variety of applications to support multiple devices, such as cellular telephones, computers, Web television, and embedded applications simply by processing the needed XHTML tags within the XML data stream. The following standard is emerging:
XForms architecture separates purpose (semantics) from presentation (syntax), and associates the capabilities of XML and the ease of HTML for a wide range of devices. The following standards are emerging:
Resource Description Framework (RDF) describes a foundation for processing WWW metadata; it supports interoperability between different applications that may need to exchange machine-understandable information on the WWW. RDF uses Extensible Markup Language (XML) for encoding its interchange syntax. RDF is a model for representing named properties (attributes of resources), property values, and relationships between properties. An RDF model can resemble an entity-relationship diagram or virtually any other information structure that can be depicted as a directed graph. The following standard is emerging:
The RDF Schema specification provides a machine-understandable system for defining "schemas" for descriptive vocabularies like the Dublin Core, a set of 15 metadata elements believed to be broadly applicable to describing Web resources to enable their discovery. It allows designers to specify classes of resource types and properties to convey descriptions of those classes, and constraints on the allowed combinations of classes, properties, and values within a data stream. This has the effect of providing a machine-understandable means of exchanging structured and structural information with respect to various persistent entities, such as DBMSs with XML. The following standard is emerging:
A Working Draft of the Extensible Stylesheet Language (XSL) Version 1.0 (Ref: WD-xsl-19981216, 16 December 1998) is being defined in the World Wide Web Consortium. XSL will be used where powerful formatting capabilities are required or for formatting highly structured information such as XML-structured data or XML documents that contain structured data. The new capabilities provided by the XSL proposal include: the formatting of source elements based on ancestry/descendency, position, and uniqueness; the creation of formatting constructs including generated text and graphics; the definition of reusable formatting macros; direction-writing, independent stylesheets; and extensible set of formatting objects.
XSL uses XML syntax and combines formatting features from Document Style and Semantics Specification Language (DSSSL). The following standard is emerging:
XML Stylesheet Language Transformations (XSLT) is a language for transforming XML documents into other XML documents and is used as a transformation part of XSL. XSLT has also been designed to be used independently, but is used primarily with XSL. The following standard is emerging:
XPath is a language for addressing parts of an XML document, designed to be used by XSLT. The following standard is emerging.
Graphics Data Interchange
Virtual Reality Modeling Language
The Virtual Reality Modeling Language (VRML) is a commercial standard with capabilities for 3-D representation of data. The following standard is emerging:
Multiple-Image Network Graphics
The Multiple-image Network Graphics (MNG) format is an extension to the PNG format, developed by the PNG Development Group, for the storage and transmission of animated graphics and complex still images. It was designed to replace GIF animation with a true animation format. The design was frozen in May 1999. The working document is MNG (Multiple-image Network Graphics) Format, PNG Development Group, 1999.
Still Imagery Data Interchange
The Basic Image Interchange Format (BIIF) is a published international standard. It provides a commercial/international foundation for interoperability in the interchange of imagery and imagery-related data among applications. BIIF provides a data format container for image, symbol, and text, along with a mechanism for including image-related support data. The following standard is emerging:
Part I of JPEG 2000 Image Coding System has been approved as an International Standard. JPEG 2000 is intended to provide a new means of image representation containing a rich set of features, all supported within the same compressed bit stream. The following standard is emerging:
Motion Imagery Data Interchange
Video Systems
Video Imagery
The following standards, as they are profiled by the Motion Imagery Standards Profile (MISP) 1.6, Chapter 2.0, Commercial Standards, Interoperability Profiles, and Recommended Practices for DoD/IC/USIGS Implementations, 27 July 2000, are emerging:
The following standard is emerging for advanced television applications:
Video Teleconference
Emerging standards for video teleconferencing are covered in the Information Transfer section of the JTA, See Video Teleconferencing Standards.
Multimedia Data Interchange
The "Draft DoD Guide to Selecting Computer-Based Multimedia Standards, Technologies, Products, and Practices," dated 15 February 1998, defines emerging standards for DoD systems employing multimedia. In this context, interactivity is a key distinguishing characteristic, in which "two or more media types (audio, video, imagery, text, and data) are electronically manipulated, integrated, and reconstructed in synchrony, where interactivity indicates an ability of a user to make decisions or selections that (can) alter the type and sequence of information or communication."
Voice Encoder
The 1.2 Kbps enhanced Mixed Excitation Linear Prediction (MELP) algorithm is based upon MIL-STD-3005 and is intended to extend seamless interoperability to bandwidth limited users (HF links, MILSATCOMs, covert ops, etc.), hence enabling end-to-end security to this user community. MIL-STD-3005 provides a common high-performance voice-encoding algorithm for use across the communications infrastructure and will be included in the current MIL-STD-3005 as an annex. For processing voice data at rates under 2.4 Kbps, the following standard is emerging:
POSIX Operating Systems
The following POSIX standards are emerging:
P1003.1a , Draft Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language] - Amendment, Draft 16, December 1998.
IEEE 1003.1d:1999 , Standard for Information Technology - Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) - Amendment d: Additional Realtime Extensions [C Language].
IEEE 1003.1j:2000 , Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) - Amendment j: Advanced Realtime Extensions [C Language].
P1003.1m , Draft Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) - Amendment m: Checkpoint/Restart Interface [C Language], Draft 2, January 1999.
P1003.1q , Draft Standard for Information Technology - Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) - Amendment x: Tracing [C Language], Draft 8, April 2000.
P1003.5g/D1 , Standard for Information Technology - Portable Operating System Interface (POSIX) - Ada Language Interfaces - Part 1: Binding for System Application Program Interface (API) -Amendment g: Realtime Extensions, September 1999.
P1003.13a/D1 , Standard for Information Technology - Standardized Application Environment Profile - POSIX Realtime Application Support (AEP) - Amendment a: Realtime Extension, September 1999.
In addition, the sponsor committee for POSIX standards (Portable Application Standards Committee), the international POSIX standards working group (JTC1/SC22/WG15), and The Open Group (TOG) are seeking to approve a new IEEE and ISO standards project to revise and consolidate those standards that make up ISO/IEC 9945-1:1996 and ISO/IEC 9945-2:1993 plus any additional supplements to those standards that are already IEEE standards or became IEEE standards by 31 December 1999.
Once this revision is approved by all three bodies, the ISO POSIX standard, the IEEE POSIX standards, and the Single UNIX Specification (SUS) will be identical in all respects. For more information, see: <http://www.opengroup.org/austin/docreg.html> .
Distributed Computing Services
Distributed-Object Computing
The CORBA 3 suite of specifications are divided into three major categories: Internet Integration; Quality of Service Control; and the CORBAcomponent architecture. The following CORBA 3 suite of specifications are emerging:
The following distributed-object computing specifications from the Object Management Group (OMG) are emerging:
Support Application Services
Environment Management
DoD 5015.2-STD, Design Criteria Standard for Electronic Records Management Software Applications, Sections 2.2.1 through 2.2.11, provides a mandatory baseline set of requirements for Records Management Application (RMA) software. RMA software may be used by DoD Components in the implementation of records management programs. Each official Component record is defined by an approved Records Control Schedule (RCS). If a Component chooses to maintain official records in an electronic form, those records must be managed by application(s) consistent with this standard. Future versions of this standard will address interoperability requirements. The following standard is emerging:
Learning Technology
Learning Technology standards provide for an integrated environment for education, training, and decision support and are considered a subset of the Environment Management services within the DoD TRM. A growing number of technical standards for this field are in varying stages of development by standards bodies including the following, each of which can be accessed on the Web at the URL indicated:
The following standards are being tracked as Learning Technology emerging standards:
IEEE 1484.1 , Architecture and Reference Model Working Group Document: "Learning Technology Systems Architecture (LTSA), Draft 5, 1999-12-08".
IEEE P1484.2 , Learner Model Working Group Document "Public and Private Information (PAPI) for Learners, Draft Version 6, 2000-06-23".
Information Transfer Standards
Introduction
Purpose
Information Transfer standards and profiles are described in this section. These standards promote seamless communications and information transfer interoperability for DoD systems.
Scope
This section identifies the information transfer standards required for interoperability between DoD information technology systems. These standards support access for end-systems including host, Video Teleconferencing (VTC), facsimile, Global Positioning System (GPS), and secondary imagery dissemination. Networking and internetworking standards are identified. Transmission media standards for MILSATCOM, Synchronous Optical Network (SONET), and radio links as well as network and systems management standards for data communications and telecommunications are identified. Finally, emerging technologies that should be monitored for future extension of information transfer capabilities are identified. This section includes the Communications Services depicted in See : DoD Technical Reference Model (DoD TRM), DoD Technical Reference Model. Security standards are addressed in See Information Transfer Security Standards.
Background
The standards are drawn from widely accepted commercial standards that meet DoD requirements. Where necessary for interoperability, profiles of commercial standards are used. Military standards are mandated only when suitable commercial standards are not available. For example, the JTA makes use of the open-systems architecture used by the Internet and the Defense Information System Network (DISN). System components are categorized here as end-systems, networks, and transmission media. End-systems (e.g., host computers, terminals) generally execute applications on behalf of users and share information with other end-systems via networks. Networks may be relatively simple (e.g., point-to-point links or subnetworks that are homogenous in protocol stacks) or have complex internal structures of diverse subnetworks. Routers interconnect two or more subnetworks and forward packets across subnetwork boundaries. Routers are distinct from hosts in that they are normally not the destination of data traffic. End-systems and networks are connected by transmission media.
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for information transfer. Each mandated standard or practice is clearly identified on a separate bulleted line and includes a formal reference that can be included within Requests for Proposals (RFPs) or Statements of Work (SOWs).
Communications
End-System Standards
This section addresses standards for the following types of end-systems: host, VTC, facsimile, imagery dissemination, and GPS.
Host Standards
Hosts are computers that generally execute application programs on behalf of users and share information with other hosts. Internet Engineering Task Force (IETF) Standard 3 is an umbrella standard that references other documents and corrects errors in some of the referenced documents. IETF Standard 3 consists of Request for Comments (RFC) 1122 and RFC 1123. This pair of documents defines and discusses the requirements for host system implementations of the Internet Protocol suite. RFC 1122 covers the communications protocol layers (link layer, IP layer, and transport layer). RFC 1123 covers the application layer protocols. The following standard is mandated:
Application Support Services
Electronic Mail
The standard for official organizational-messaging traffic between DoD organizations is the Defense Message System's (DMS's) X.400-based suite of military messaging standards defined in Allied Communications Publication (ACP) 123. The ACP 123 annexes contain standards profiles for the definition of the DMS "Business Class Messaging" (P772) capability and the Message Security Protocol (MSP). Organizational messaging is considered a high-assurance messaging service that requires authentication, delivery confirmation, and encryption. See See Information Security Standards for security standards. Since X.400 is not an Internet standard, see See Open Systems Interconnection Transport Over IP-Based Networks for operation over Internet Protocol (IP)-based networks. The following standards are mandated:
DMS has expanded its baseline to include a medium-assurance messaging service. The requirements for medium-assurance messaging are less stringent than organizational messaging and can be met by existing IP-based mail standards. This allows the augmentation of DMS to include the use of the Simple Mail Transfer Protocol (SMTP) for medium-assurance messaging. For SMTP, the following standards are mandated:
Directory Services
X.500 Directory Services
International Telecommunications Union (ITU) X.500 provides directory services that may be used by users or host applications to locate other users and resources on the network. While it is appropriate for all grades of service, it must be used for high-grade service where standards-based access control, signed operations, replication, paged results, and server-to-server communication are required. It provides the security services used by DMS-compliant X.400 implementations and is mandated for use with DMS. See See Information Security Standards for security standards. Since X.500 is not an Internet standard, see See Open Systems Interconnection Transport Over IP-Based Networks for operation over IP-based networks. The following standard is mandated:
Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP) (Version 2) is an Internet protocol for accessing online directory services. It runs directly over Transmission Control Protocol (TCP). LDAP derives from the X.500 Directory Access Protocol (DAP). It is appropriate for systems that need to support a medium grade of service in which security is not an issue, and access is only needed to a centralized server. The following standard is mandated:
Domain Name System
Domain Name System (DNS) is a hierarchical host management system that has a distributed database. It provides the look-up service of translating between host names and IP addresses. DNS uses TCP/User Datagram Protocol (UDP) as a transport service when used in conjunction with other services. Dynamic DNS enables the automation of DNS updating by introducing a new messaging mechanism to selectively insert or delete new entries into or from the DNS database. The following standards are mandated:
File Transfer
Basic file transfer is accomplished using the File Transfer Protocol, which provides a reliable file transfer service for text or binary file. FTP uses TCP as a transport service. The following standard is mandated:
Remote Terminal
For ASCII text-oriented remote-terminal services, Telecommunications Network (TELNET) provides a virtual terminal capability that allows a user to "log on" to a remote system as though the user's terminal were directly connected to the remote system. The following standard is mandated:
Network Time Synchronization
Network Time Protocol (NTP) provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet. The following standard is mandated:
Bootstrap Protocol
Bootstrap Protocol (BOOTP) is used to provide address determination and bootfile selection. It assigns an IP address to workstations with no IP address. The following standards are mandated:
Configuration Information Transfer
The Dynamic Host Configuration Protocol (DHCP) provides an extension of BOOTP to support the passing of configuration information to Internet hosts. DHCP consists of two parts: a protocol for delivering host-specific configuration parameters from a DHCP server to a host, and a mechanism for automatically allocating IP addresses to hosts. The following standard is mandated:
Web Services
Hypertext Transfer Protocol
Hyptertext Transfer Protocol (HTTP) is used for search and retrieval within the Web. The following standard is mandated:
Uniform Resource Locator
A Uniform Resource Identifier (URI) is a string identifying an abstract or physical resource on a network. Uniform Resource Locators (URLs) are the subset of URIs that identify resources via their network "location." URIs (particularly URLs) are used extensively on the Internet. RFC 2396 defines the generic syntax of URIs, while RFC 1738 defines the syntax for specific URL schemes (such as http: and ftp:). For the syntax of URIs and URLs, the following standards are mandated:
Transport Services
The transport services provide host-to-host communications capability for application support services. The following sections define the requirements for this service.
Transmission Control Protocol/User Datagram Protocol Over Internet Protocol
Transmission Control Protocol
Transmission Control Protocol (TCP) provides a reliable connection-oriented transport service. The following standards are mandated:
User Datagram Protocol
User Datagram Protocol (UDP) provides an unacknowledged, connectionless datagram transport service. The following standard is mandated:
Internet Protocol
Internet Protocol (IP) is a basic connectionless datagram service. All protocols within the IP suite use the IP datagram as the basic data transport mechanism. Two other protocols are considered integral parts of IP: the Internet Control Message Protocol (ICMP) and the Internet Group Management Protocol (IGMP). ICMP is used to provide error reporting, flow control, and route redirection. IGMP provides multicast extensions for hosts to report their group membership to multicast routers. RFC 2236, IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership. The following standards are mandated:
Furthermore, for hosts that transmit or receive multi-addressed datagrams over Combat Net Radio (CNR), the multi-addressed IP option field must be used. The following standard is mandated:
Open Systems Interconnection Transport Over IP-Based Networks
This protocol provides the interworking between Transport Protocol Class 0 (TP0) and TCP transport service necessary for Open Systems Interconnection (OSI) applications to operate over IP-based networks. The following standard is mandated:
Video Teleconferencing Standards
The ASD (C3I) mandated Federal Telecommunications Recommendation (FTR) 1080A-1998 Video Teleconferencing Profile (VCP) identifies ITU-T H.320 as the key standard to provide interoperability between Video Teleconferencing (VTC) terminal equipment, both point-to-point and multipoint configurations operating at data rates of 56-1,920 Kilobits per second (Kbps). ITU-T H.320, Narrow Band Visual Telephone Systems and Terminal Equipment, July 1997, is an umbrella standard of recommendations addressing audio, video, signaling, and control. Also in the FTR is ITU-T T.120, Transmission Protocols for Multimedia Data, July 1996, which references a family of standards for applications implementing the features of audiographic conferencing, facsimile, still image transfer, annotation, pointing, whiteboard, file transfer, audiovisual control, and application sharing.
For Video Teleconferencing Units (VTUs) and Multipoint Control Units (MCUs) operating at rates of 56 Kbps to 1,920 Kbps, except for operation over packet-based TCP/IP networks, the following standards, as they are profiled by FTR 1080A-1998, Appendix A, Video Teleconferencing Profile, October 1998, are mandated:
For applications implementing the features of audiographic conferencing, facsimile, still image transfer, annotation, pointing, whiteboard, file transfer, audiovisual control, and application sharing, operating at data rates of 9.6 to 1,920 Kbps, or operating over LANs, the following standards are mandated:
ITU-T T.81 , Information Technology - Digital Compression and Coding of Continuous-tone Still Images - Requirements and Guidelines, September 1992.
ITU-T T.82 , Information Technology - Coded Representation of Picture and Audio Information - Progressive Bi-level Image Compression, March 1993.
ITU-T T.122 , Multipoint Communications Service for Audiographic and Audio Visual Conferencing Service Definition, March 1993.
ITU-T T.123 , Protocol Stacks for Audiographic and Audiovisual Teleconferencing Applications, November 1994.
ITU-T T.124 , Generic Conference Control for Audiographic and Audiovisual Terminals and Multipoint Control Units, August 1995.
For VTC terminals operating within IP Packet Networks, the following standard is mandated:
ITU-T H.323 , Packet-based Multimedia Communications Systems, February 1998. For all other implementations of H.323, such as used over wide area networks where bandwidth, quality of service, and scalability may not be sufficient for IP-based video conferencing, see emerging standards paragraph See Video Teleconferencing Standards.
For VTC terminals operating at low bit rates (9.6 to 28.8 Kbps) the following standard is mandated:
For inverse multiplexers connected to VTC terminals, and for VTC terminals with built-in inverse multiplexers, the following standard is mandated:
For information on the ASD (C3I) VTC guidance and the Federal Telecommunications Recommendation (FTR) 1080A-1998 Video Teleconferencing Profile, see URL: <http://www.ncs.gov/n6> and URL: <http://disa.dtic.mil/disnvtc> .
Facsimile Standards
Analog Facsimile Standards
For facsimile (analog output) standards that comply with the ITU-T Group 3 specifications, the following standards are mandated:
Digital Facsimile Standards
Digital facsimile equipment standards for Type I and/or Type II modes are used for digital facsimile terminals operating in tactical, high Bit Error Rate (BER) environments and for facsimile transmissions utilizing encryption or interoperability with NATO countries. The following standard is mandated:
Imagery Dissemination Communications Standards
The Tactical Communications Protocol 2 (TACO2) is the communications component of the National Imagery Transmission Format Standard (NITFS) suite of standards used to disseminate secondary imagery. TACO2 is used over point-to-point tactical data links in high-BER disadvantaged communications environments. TACO2 is used to transfer secondary imagery and related products in which JTA transfer protocols in See Transport Services fail (e.g., TACO2 only applies to users having simplex and half-duplex links as their only means of communications). MIL-HDBK-1300A, NITFS, provides guidance to implement various Technical Interface Specifications (TISs) to connect the TACO2 host to specific cryptographic equipment. The following standard is mandated:
Global Positioning System
The CJCS (CJCSI 6130.01A, 1998 CJCS Master Positioning, Navigation, and Timing Plan) has declared that the GPS will be the primary radionavigation system source of positioning, navigation and timing (PNT) for DoD. GPS is a space-based, worldwide, precise positioning, velocity, and timing system. It provides an unlimited number of suitably equipped passive users with a force-enhancing, common-grid, all-weather, continuous, three-dimensional PNT capability. The NAVSTAR GPS provides two levels of service--a Standard Positioning Service (SPS) and a Precise Positioning Service (PPS). The following standard is mandated:
The PPS was designed primarily for U.S. military use, and DoD will control access to the PPS through cryptography. DoD GPS users with combat, combat support, or combat service support missions must acquire and use PPS-capable GPS receivers. The U.S. will enter into special arrangements with military users of allied and friendly governments to allow them use of the PPS. The following standards are mandated:
The United States discontinued the use of Selective Availability (SA); or in other words, SA errors were set to zero (e.g., SA=0). ASD(C3I) issued SA=0 policy and affirmed that Navigation Warfare (NAVWAR) is now the preferred method to prevent adversary use of GPS. NAVWAR is used to deny, degrade, and otherwise disrupt GPS Standard Positioning Service (SPS) within a theater of operations. This policy further states that it is imperative that DoD users incorporate properly keyed Precise Positioning Service receivers unless a waiver to use SPS is obtained.
For additional information associated with the acquisition and use of PPS-capable GPS receivers, including end-of-week rollover compliance, consult the GPS JPO.
Network Standards
Networks are made up of subnetworks, and the internetworking (router) elements needed for information transfer. This section identifies the standards needed to access certain subnetworks and for routing and interoperability between the subnetworks.
Internetworking (Router) Standards
Routers are used to interconnect various subnetworks and end-systems. Protocols necessary to provide this service are specified below. RFC 1812 is an umbrella standard that references other documents and corrects errors in some of the referenced documents. In addition, some of the standards mandated for hosts in See Host Standards also apply to routers. The following standards are mandated:
Security requirements are addressed in See Information Security Standards.
Internet Protocol
Internet Protocol (IP) is a basic connectionless datagram service. All protocols within the IP suite use the IP datagram as the basic data transport mechanism. IP was designed to interconnect heterogeneous networks and operates over a wide variety of networks. Two other protocols are considered integral parts of IP: ICMP and IGMP. ICMP is used to provide error reporting, flow control, and route redirection. IGMP provides multicast extensions for hosts to report their group membership to multicast routers. IETF RFC 2236, IGMP Version 2, is used by IP hosts to report their multicast group memberships to routers. It updates IETF Standard RFC 1112. IGMP Version 2 allows group membership termination to be quickly reported to the routing protocol, which is important for subnets with highly volatile group membership and high bandwidth multicast group.The following standards are mandated:
In addition, in all implementations of IP routers that transmit or receive multi-addressed datagrams over CNR, the multi-addressed IP option field must be used. The following standard is mandated:
Internet Protocol Routing
Routers exchange connectivity information with other routers to determine network connectivity and adapt to changes in the network. This enables routers to determine, on a dynamic basis, where to send IP packets.
Interior Routers
Routes within an autonomous system are considered local routes that are administered and advertised locally by means of an interior gateway protocol. For unicast interior gateway routing, the following standard is mandated:
Subnetworks
This section identifies the standards needed to access subnetworks used in joint environments.
Local Area Network Access
While no specific Local Area Network (LAN) technology is mandated, the following is required for interoperability in a joint environment. This requires provision for a LAN interconnection. Ethernet, the implementation of Carrier Sense Multiple Access with Collision Detection (CSMA/CD), is the most common LAN technology in use with TCP/IP. The hosts use a CSMA/CD scheme to control access to the transmission medium. An extension to Ethernet, Fast Ethernet provides interoperable service at both 10 Mbps and 100 Mbps. Higher-speed interconnections are provided by 100BASE-TX (two pairs of Category 5 unshielded twisted pair, with 100BASE-TX Auto-Negotiation features employed to permit interoperation with 10BASE-T). For platforms physically connected to a Joint Task Force LAN, the following standards are mandated as the minimum set for operation in a Joint Task Force:
ISO/IEC 8802-3:1996 , Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, 10BASE-T Medium-Access Unit (MAU).
IEEE 802.3u:1995 , Supplement to ISO/IEC 8802-3:1993, Local and Metropolitan Area Networks: Media Access Control (MAC) Parameters, Physical Layer, Medium Attachment Units, and Repeater for 100 Mbps Operation, Type 100BASE-T (Clauses 21-30).
Point-to-Point Standards
For full duplex, synchronous or asynchronous, point-to-point communication, the following standards are mandated:
For the serial line interface, one of the following is mandated:
Combat Net Radio Networking
Combat Net Radios (CNRs) are a family of radios that allow voice or data communications for mobile users. These radios provide a half-duplex broadcast transmission media with potentially high BERs. The method by which IP packets are encapsulated and transmitted is specified in MIL-STD-188-220B. With the exception of High Frequency (HF) networks, MIL-STD-188-220B shall be used as the standard communications net access protocol for CNR networks. The following standard is mandated:
Integrated Services Digital Network
Integrated Services Digital Network (ISDN) is an international standard used to support integrated voice and data over standard twisted-pair wire. ISDN defines a Basic Rate Interface (BRI) and Primary Rate Interface (PRI) to provide digital access to ISDN networks. These interfaces support both circuit-switched and packet-switched services. It should be noted that deployable systems might additionally be required to support other non-North American ISDN standards when accessing region-specific international infrastructure for ISDN services. The JTA recognizes that this is a critical area affecting interoperability but does not recommend specific solutions in this version. The following standards are mandated:
For signaling at the user-network interface:
ANSI T1.607-1998 , Digital Subscriber Signaling System No. 1 (DSS1) - Layer 3 Signaling Specification for Circuit Switched Bearer Service, 1998.
ANSI T1.610-1998 , DSS1 - Generic Procedures for the Control of ISDN Supplementary Services, 1998.
For signaling at node-to-node interface:
For transmitting IP packets when using ISDN packet-switched services:
For transmitting IP packets using Point-to-Point Protocol (PPP) over ISDN:
Asynchronous Transfer Mode
Asynchronous Transfer Mode (ATM) is a high-speed switched data transport technology that takes advantage of primarily low BER transmission media to accommodate intelligent multiplexing of voice, data, video, and composite inputs over high-speed trunks and dedicated user links. ATM is a layered type of transfer protocol with the individual layers consisting of an ATM Adaptation Layer (AAL), the ATM layer, and the Physical Layer. The function of the AAL layer is to adapt any traffic (video streams, data packets from upper layer protocols) into the ATM format of 48-octet payload. It also receives the cells from the ATM layer and reassembles the protocol data units. The ATM Layer adds the necessary header information used by switches and end-systems alike to transfer cells across the ATM network. The Physical Layer converts the cell information to the appropriate electrical/optical signals for the given transmission medium. The ATM Forum's User-Network Interface (UNI) Specification defines the primary specification for end-system connection to ATM networks. The Private Network-Network Interface (PNNI) Specification defines the PNNI protocol for use between private ATM switches, and between groups of private ATM switches. The PNNI supports the distribution of topology information between switches and clusters of switches to allow paths to be computed through the network. The PNNI also defines the signaling to establish point-to-point and point-to-multipoint connections across the ATM network. ATM Forum's Local Area Network Emulation supports the emulation of Ethernet, allowing ATM Networks to be deployed without disruption of host network protocols and applications. For information on the ASD (C3I) ATM guidance, see URL: <http://www.disa.mil> .
The standards below are mandated. For information on ATM-Forum-approved specifications, see URL: <http://www.atmforum.com/atmforum/specs/specs.html> .
ATM Forum, af-phy-0040.000 , Physical Interface Specification for 25.6 Mbps over Twisted Pair Cable, November 1995.
ATM Forum, af-phy-0015.000 , ATM Physical Medium Dependent Interface for 155 Mbps over Twisted Pair Cable, September 1994.
For User to Network Interface:
For Layer Management Capabilities:
For Traffic Management Functions:
For Circuit Emulation Functions:
For Private Network-to-Network Interfaces:
Gigabit Ethernet
While no specific LAN/CAN technology is mandated, when using Gigabit Ethernet (1,000 Mbps service) over fiber on a campus environment, the following physical layer and framing requirements standard is mandated:
IEEE 802.3-1998 , IEEE Standard for Information Technology (Clauses 34-42) - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (originally developed as IEEE 802.3z-1998).
When using Gigabit Ethernet over Category 5 copper cabling, the following standard is mandated:
IEEE 802.3ab-1999 , IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Physical Layer Parameters and Specifications for 1000Mb/s Operation over 4-Pair of Category 5 Balanced Copper Cabling, Type 1000BASE-T.
Transmission Media
Military Satellite Communications
Military Satellite Communications (MILSATCOM) systems include those systems owned or leased and operated by DoD and those commercial satellite communications (SATCOM) services used by DoD. The basic elements of satellite communications are a space segment, a control segment, and a terminal segment (air, ship, ground, etc.). An implementation of a typical satellite link will require the use of satellite terminals, a user communications extension, and military or commercial satellite resources.
Ultra High Frequency Satellite Terminal Standards
5-KHz and 25-KHz Service
For 5-KHz or 25-KHz single-channel access service supporting the transmission of either voice or data, the following standard is mandated:
5-KHz Demand-Assigned Multiple Access Service
For 5-KHz Demand-Assigned Multiple Access (DAMA) service, supporting the transmission of data at 75 to 2400 bps and digitized voice at 2400 bps, the following standard is mandated:
25-KHz Time Division Multiple Access/Demand-Assigned Multiple Access Service
For 25-KHz Time Division Multiple Access (TDMA)/DAMA service, supporting the transmission of voice at 2,400, 4,800, or 16,000 bps and data at rates of 75 to 16,000 bps, the following standard is mandated:
Data Control Waveform
For data controllers operating over single-access 5-KHz and 25-KHz UHF SATCOM channels, the following standard (a robust link protocol that can transfer error-free data efficiently and effectively over channels that have high error rates) is mandated:
Super High Frequency Satellite Terminal Standards
Earth Terminals
For minimum mandatory Radio Frequency (RF) and Intermediate Frequency (IF) requirements to ensure interoperability of SATCOM Earth terminals operating over C-, X-, and Ku-band channels, the following standard is mandated:
Extremely High Frequency Satellite Payload and Terminal Standards
Low Data Rate
For waveform, signal processing, and protocol requirements for acquisition, access control, and communications for Low Data Rate (LDR) (75 to 2,400 bps) Extremely High Frequency (EHF) satellite data links, the following standard is mandated:
Satellite State of Health Communication Standards
National Space Policy directed DoD to lead U.S. Government efforts to improve satellite operations interoperability among U.S. Government agencies. The National Security Space Architect's Satellite Operations Architecture Team recommended a common set of standards for low data rate satellite telemetry and commanding. These standards will allow DoD to share health and status resources with other U.S. Government agencies and with allies to enhance satellite operations while limiting costs. The standards provide a baseline for low data rate communication of health and status information between a spacecraft and the ground. These standards are mandated for S-band communication, but may be applied more generally.
For establishing the physical layer to support satellite health and status communications in the S-band during launch, early orbit, severe anomaly and disposal operations, the following standard is mandated:
For processing data being sent into distinct, easily distinguishable messages that allow reconstruction of the data with low error probability, the following standard is mandated:
For the data unit formats and functions implemented within the coding and physical layers of the satellite health and status communications, the following standard is mandated:
For procedures and data unit formats implemented within the segmentation and transfer layers of the telecommand data routing service, the following standard is mandated:
For detailed specification of the logic required to carry out command operation procedure-1 (COP-1) of the transfer layer, the following standard is mandated:
For the data unit formats and functions implemented within the application, system management, and packetization layers of the satellite command data management service, the following standard is mandated:
Packet telemetry provides a mechanism for implementing common data transport structures and protocols to enhance the development and operation of space mission systems. For facilitating the transmission of space-acquired data from source to user in a standardized manner, the following standard is mandated:
Radio Communications
Low Frequency and Very Low Frequency
For radio subsystem requirements operating in the Low Frequency (LF)/Very Low Frequency (VLF) frequency bands, the following standard is mandated:
High Frequency
High Frequency and Automatic Link Establishment
For both Automatic Link Establishment (ALE) and radio subsystem requirements operating in the High Frequency (HF) bands, the following standard is mandated:
Very High Frequency
For radio subsystem requirements operating in the Very High Frequency (VHF) frequency bands, the following standard is mandated:
Ultra High Frequency
Super High Frequency
For radio subsystem requirements operating in the Super High Frequency (SHF) frequency bands, the following standard is mandated:
Synchronous Optical Network Transmission Facilities
SONET is a telecommunications transmission standard for use over fiber-optic cable. SONET is the North American subset of the ITU standardized interfaces, and includes a hierarchical multiple structure, optical parameters, and service mapping. The following standards are mandated:
The citation of applicable ANSI standards for SONET does not ensure C4I interoperability in regions outside North America where standards for these services differ. The JTA recognizes that this is a critical area affecting interoperability but does not recommend specific solutions in this version.
Network and Systems Management
Network and Systems Management (NSM) provides the capability to manage designated networks, systems, and information services. This includes: controlling the network's topology; dynamically segmenting the network into multiple logical domains; maintaining network routing tables; monitoring the network load; and making routing adjustments to optimize throughput. NSM also provides the capability to review and publish addresses of network and system objects; monitor the status of objects; start, restart, reconfigure, or terminate network or system services; and detect loss of network or system objects in order to support automated fault recovery. A management system has four essential elements: management stations; management agents; management information bases (MIBs); and management protocols, to which these standards apply.
Data Communications Management
Data communications management stations and management agents (in end-systems and networked elements) shall support the Simple Network Management Protocol (SNMP). The following SNMP-related standard is mandated:
To standardize the management scope and view of end-systems and networks, the following standards are mandated for MIB modules of the management information base:
Telecommunications Management
Telecommunications management systems for telecommunications switches will implement the Telecommunications Management Network (TMN) framework. To perform information exchange within a telecommunications network, the following TMN framework standards are mandated:
ANSI T1.204 -1997 , OAM&P - Lower Layer Protocols for TMN Interfaces Between Operations Systems and Network Elements, 1997.
ANSI T1.208 -1997 , OAM&P - Upper Layer Protocols for TMN Interfaces Between Operations Systems and Network Elements, 1997.
ITU-T M.3211.1 , TMN management service: Fault and performance management of the ISDN access, 1996.
ISO/IEC 9595:1998 , Information Technology - Open Systems Interconnection Common Management Information Services (CMIS).
Emerging Standards
Commercial communications standards and products will evolve over time. The JTA must also evolve to benefit from these standards and products. The purpose of this section is to provide notice of those standards expected to be elevated to mandatory status when implementations of the standards mature.
End-System Standards
Internet Standards
IP Next Generation/Version 6 (IPv6). IPv6 is being designed to provide better internetworking capabilities than are currently available within IP (Version 4). IPv6 will include support for the following: expanded addressing and routing capabilities, authentication and privacy, auto-configuration, and increased quality of service capabilities. IPv6 is described by proposed and draft IETF standards including:
Lightweight Directory Access Protocol 3 (LDAPv3). The proposed standard for LDAPv3, IETF RFC 2251, supports standards-based authentication, referrals, and all protocol elements of LDAP (IETF RFC 1777). Other features still under development include standards-based access control, signed operations, replication, knowledge references, and paged results.
Mobile Host Protocol (MHP). This protocol allows the transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. A mobile IP protocol is currently available as an IETF-proposed standard, RFC 2002, entitled IP Mobility Support.
Quality of Service (QoS). QoS is the ability of a network to ensure that the predetermined traffic and service requirements of a network element (e.g., end-system, router, application) can be satisfied. Resource ReSerVation Protocol (RSVP) is used by a host to request specific qualities of service from the network for particular application data streams or flows. See See Network Quality of Service (QoS) Standards for emerging Network QoS standards. The following receiver-initiated QoS standard is emerging:
Voice Over IP (VoIP) . Voice Over IP technologies unite the telephony and data worlds, and allow voice traffic to be transmitted over corporate enterprise networks, intranets, and the Internet. Two nearly compatible approaches have been taken to bring voice to TCP/IP networks. On the one hand, the ITU has created H.323, a set of standards specifying protocols to encapsulate ISDN call signaling over an IP transport network. On the other hand, the IETF has created a set of standards to perform similar functions, under the names Session Initiation Protocol (SIP) and Media Gateway Control (Megaco). Both approaches use an IETF standard, RTP (Realtime Transport Protocol), for their voice channels. The SIP standard concerns simple call placement, but is designed so that its scope is easily expandable. Megaco neatly separates out the functions required for interoperability with legacy equipment such as Signaling System 7 circuit switches. In contrast, the H.323 standards for call placement, H.225, H.245, and Q.931 (including RAS) are explicit in the signals that may be sent and the expected responses. The following VoIP standards are emerging:
Video Teleconferencing Standards
There are three emerging standards for VTC over ATM:
ITU-T H.310 , includes underlying standards for video (MPEG2) and audio (MPEG1, MPEG2). H.310 can be used for high-quality VTC requiring > 2 Mbps infrastructure, but does not currently have much industry support.
ITU-T H.321 , specifies the operation of H.320 codecs over ATM using AAL-1 or AAL-5. H.321 uses Quality of Service to manage videoconferencing quality. It lacks industry wide support.
ITU-T H.323 , has the most industry support for VTC over ATM. It provides for two modes of operation over ATM: 1) IP over ATM media stream and 2) Real-Time Protocol (RTP) over ATM media stream transport (H.323 Annex C). Implementation of H.323 over non-LAN media (e.g., Metropolitan Area Networks [MANs] and WANs, such as the Internet, SIPRNET, JWICS) is still evolving.
Communication Protocols for High-Stress, Resource-Constrained Environments
DoD entered a cooperative effort in September 1997 with the National Aeronautics and Space Administration (NASA) and the National Security Agency (NSA) to develop Internet-based protocols for "stressed" communications links. Such links are characterized by one or more of: high bit error rates, long delays, low bandwidths, and high degrees of asymmetry. This work is also applicable for systems with limited computer processing power. The cognizant DoD office is SMC/XR. The protocol suite, called the Space Communications Protocol Specification (SCPS), increases the reliability and speed of data transfer over such links, increases interoperability with both DoD and non-DoD assets, and decreases the cost of operating our systems. This set of protocols is particularly applicable to radio frequency Internet communications in battlefield jamming environments. The suite has been issued as both Consultative Committee for Space Data Systems (CCSDS) and ISO standards (with the same content). The suite consists of the following four protocols that operate at and above the network layer of the Open Systems Interconnect (OSI) model:
The File Protocol (FP) is an application layer protocol (layer 7 in the OSI model) and is an extension of the Internet File Transfer Protocol (FTP). FP adds the ability to update individual records in a file, to suspend and resume file transfers at user request, to automatically restart file transmission in mid-transmission after a communications interruption, and to suppress the text of server replies. FP and FTP clients and servers can interoperate (at the reduced functionality of FTP, i.e., without the FP extensions).
The Transport Protocol (TP) is a transport layer protocol (layer 4 in the OSI model) and is an extension of the Internet Transmission Control Protocol (TCP). TP can provide better end-to-end throughput in a jamming or noisy radio frequency environment because it can respond to corruption and temporary link outage in addition to congestion. TP's selective negative acknowledgements increase performance in noisy and asymmetric environments. Performance in asymmetric environments is also improved by permitting reduced acknowledgement rates. TP also supports a loss-tolerant compressed TCP header and "best effort" data transfer protocol. TP and TCP clients and servers can interoperate (at the reduced functionality of TCP without the TP extensions).
The Security Protocol (SP) operates between the network and transport layers (layers 3 and 4). SP is an optional protocol that provides security capabilities (confidentiality, source authentication, and integrity) for the network layer. SP is analogous to IPSEC, but SP is a separate protocol with reduced overhead.
The Network Protocol (NP) is a network layer protocol (layer 3 in the OSI model) developed to be a bit-efficient, scalable protocol for a broad range of environments. Among other things, NP provides for selectable routing method, connectionless and managed-connection operations, corruption and congestion signaling to TP, and handling of packet precedence. NP is particularly useful in systems that have changing network connectivities. The other protocols can operate on Internet Protocol if Network Protocol is not used. In most cases IP packets and NP packets can be translated between each other using a gateway. The concept is that TCP/IP would be used in less stressed communication environments, and then translated or tunneled to NP where necessary before entering the stressed communications channel.
For stressed communications environments (such as satellite links) where high bit error rates, large delays, low bandwidth, and/or data rate asymmetry make the standard TCP/IP suite's performance unacceptable, the following standards are emerging for internetworking and file exchange:
CCSDS 713.0-B-1/ISO 15891:2000 , Space data and information transfer systems - Protocol specification for space communications - Network protocol, 5 October 2000. (Adopts MIL-STD-2045-4300)
CCSDS 713.5-B-1/ISO 15892 :2000, Space data and information transfer systems - Protocol specification for space communications - Security protocol, 5 October 2000. (Adopts MIL-STD-2045-4301)
More information is available at <http://www.scps.org> and <http://www.ccsds.org> .
Global Positioning System
The GPS Signal-in-Space (SIS) is being enhanced to accommodate next-generation security functions. These functions will significantly enhance the combatant commander's ability to use the GPS PPS capability and other GPS sensor information in all environments. These functions are exclusively supported by the Selective Availability Anti-Spoofing Module (SAASM) architecture. The following standard is being tracked as a GPS SIS emerging standard:
Network Standards
Wireless LAN
The 802.11 family of standards provide a common set of operational rules for airwave interoperability of wireless Local Area Network (LAN) products from different vendors. The original IEEE 802.11 standard was updated with editorial changes. The original physical layer was updated by IEEE 802.11a and IEEE 802.11b. The Medium Access Control (MAC) layer is currently undergoing revision and will be updated by IEEE 802.11f. The emerging standards include:
ISO/IEC 8802-11:1999 , (ISO/IEC) (IEEE Std 802.11 - 1999) Information Technology -Telecommunications and Information Exchange Between Systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
IEEE 802.11a-1999 , Supplement to Information technology - Telecommunications and Information Exchange Between Systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: High Speed Physical Layer (PHY) in the 5 GHz Band.
IEEE 802.11b-1999 , Supplement to Information technology - Telecommunications and Information Exchange Between Systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Higher Speed Physical Layer (PHY) Extension in the 2.4 GHz band.
ATM-Related Standards
The following ATM-related standards are emerging:
ATM Forum, af-sig-0076.000 , Addendum to UNI Signalling V4.0 for ABR parameter negotiation, January 1997.
For ATM Conformance Testing, the ATM Forum's conformance test suites, Protocol Information Conformance Statement (PICS) pro forma and the Protocol Implementation Extra Information for Testing (Pixit) pro forma, are available to demonstrate interoperability between vendor products.
Network Quality of Service (QoS) Standards
Quality of Service is the ability of a network to ensure that the predetermined traffic and service requirements of a network element can be satisfied. Multiple forums including the IETF and IEEE are engaged in this evolving end-to-end networking effort to enhance the current networking architecture with support for QoS. To provide services over the LAN/WAN beyond the current best-effort IP-based service, the following standard protocols currently under development to enable end-to-end QoS, are emerging:
IETF RFC 2205 , Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification, September 1997.
ISO/IEC 15802-3 , IEEE 802.1D dtd 25 JUN 1998 Information Technology -Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks - Common Specifications - Part 3: Media Access Control (MAC) Bridges (Replaces IEEE P802.1P, 802.1J-1996, 802.6K-1992, 802.11C-1998, and P802.12E).
Personal Communications Services and Mobile Cellular
Personal Communications Services (PCS), second-generation mobile systems, will support both terminal mobility and personal mobility. Terminal mobility is based on wireless access to the public switched telephone network (PSTN). Personal mobility allows users of telecommunications services to gain access to these services from any convenient terminal (either wireline or wireless). Mobile cellular radio can be regarded as an early form of "personal communications service" allowing subscribers to place and receive telephone calls over the PSTN wherever cellular service is provided. The three predominant competing worldwide methods for digital PCS and Mobile Cellular access are: Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), and Global System for Mobile Communications (GSM). Of these three, CDMA offers the best technical advantages for military applications based on its utilization of Direct Sequence Spread Spectrum (DSSS) techniques for increased channel capacity, low probability of intercept (LPI), and protection against jamming. CDMA's low transmission power requirements should also reduce portable power consumption. It should be recognized that for Operations-Other-Than-War (OOTW), a user may require support of multiple protocols to access region-specific international digital PCS/Mobile Cellular infrastructures. The following PCS/CDMA standards and PCS/Mobile Cellular Interface standards are emerging:
ANSI/J-STD-018-96 , Recommended Minimum Performance Requirements for 1.8 to 2.0 GHz CDMA Personal Stations.
ANSI/J-STD-019-96 , Recommended Minimum Performance Requirements for Base Stations Supporting 1.8 to 2.0 GHz CDMA Personal Stations.
International Mobile Telecommunications - 2000
International Mobile Telecommunications - 2000 ( IMT-2000) defines third-generation mobile systems that were scheduled to start service around the year 2000. Also known as Future Public Land Mobile Telecommunications Systems (FPLMTS), these systems will provide access by means of one or more radio links to a wide variety of telecommunication services supported by the fixed and mobile telecommunications networks (e.g., PSTN/ISDN) and to other services that may be unique to IMT-2000. A range of mobile terminal types, designed for mobile and fixed use, is envisaged linking to terrestrial- and/or satellite-based networks. A goal for third-generation mobile systems is to provide global coverage and to enable terminals to be capable of seamless roaming between multiple networks. The ability to coexist and work with pre-IMT-2000 systems is required. The Radio Communications Assembly-2000 gave final approval of Recommendation ITU-R M.(IMT.RSPC), "Detailed Specifications of the Radio Interfaces of IMT-2000" for the radio interfaces for IMT-2000 on 5 May 2000. The IMT-2000 radio interface terrestrial standard consists of a set of radio interfaces, which allow performance optimization in a wide range of radio operating environments. The family of IMT-2000 terrestrial radio transmission technologies (RTT) is as follows: CDMA Direct Spread/CDMA Multi-Carrier/CDMA Time Division Duplex (TDD)/TDMA Single-Carrier/TDMA Multi Carrier. Follow-on work on major enhancements to the RTTs' specifications is ongoing in ITU-R Working Party 8F. In addition, standards work is continuing to ensure that the RTTs will support the capability of operating with the two worldwide telecommunications networks: evolved GSM-MAP and ANSI-41. Limited trials of 3G services are expected to be commenced in various regions of the world, especially Japan, in late 2001. The European Union plans a rollout of 3G services in 2002. U.S. 3G services (e.g., 144Kbps/384 Kbps data capability) are expected to be provided in focused markets in late 2003. A mass market for 3G in the U.S. and Europe is not expected to develop until 2005.
Military Satellite Communications
SHF Satellite Terminal Standards.
The following draft standards are under development: MIL-STD-188-166 (Interface Standard, Interoperability and Performance Standard for SHF SATCOM Link Control), MIL-STD-188-167 (Interface Standard, Message Format for SHF SATCOM Link Control), and MIL-STD-188-168 (Interface Standard, Interoperability and Performance Standards for SHF Satellite Communications Mulitplexers and Demultiplexers).
Radio Communications
Link 22 Transmission Standards
Link 22 Transmission media will be used to exchange Link 22 messages. Link 22 messages, composed of F-Series formats, will be used for the exchange of maritime operational data between tactical data systems using line of sight (UHF) and beyond line of sight (HF) bands. The standard for Link 22 waveform is under development.
Network Management
Simple Network Management Protocol Version 3 (SNMPv3)
The SNMPv3 Management Framework is described in IETF-Proposed Standard RFCs 2271-2275. SNMPv3 builds on the mandate SNMPV1 and addresses the deficiencies in SNMPv2 relating to security (e.g., authentication and privacy) and administration (e.g., naming of entities, usernames and key management, and proxy relationships). Implementations of the RFCs are undergoing interoperability tests as part of the process to advance these specifications from Proposed to Draft state.
Network Management Systems for Data Communications.
The following SNMP MIB modules are identified as emerging IETF standards for implementation within systems that manage data communications networks:
IETF RFC 1471 , Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1472 , Definitions of Managed Objects for the Security Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1473 , Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1474 , Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol, June 1993.
IETF RFC 1657 ,Definitions of Management Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2, July 1994.
IETF RFC 2012 , SNMPv2 Management Information Base for the Transmission Control Protocol (TCP), November 1996.
IETF RFC 2013 , SNMPv2 Management Information Base for the User Datagram Protocol (UDP), November 1996.
Information Modeling, Metadata, and Information Exchange Standards
Introduction
Purpose
This section specifies the minimum information modeling, metadata, and information exchange standards DoD will use to develop or upgrade integrated, interoperable systems that directly or indirectly support the warfighter.
Scope
This section applies to activity models, data models, object models and data definitions used to define physical databases, and formatted messages used to exchange information among systems.
Security standards related to this section are in See Information Modeling, Metadata, and Information Exchange Security Standards.
Background
An information model is a representation at one or more levels of abstraction of a set of real-world activities, products, and/or interfaces. Within the Information System (IS) domain, there are three basic types of models frequently created: activity, data, and object.
Activity Models are representations of mission-area applications, composed of one or more related activities. The primary product of each activity model is the definition of a measurable set of products, services, and information required to support the mission-area function.
Data Models , developed from the information requirements documented in the activity model, define entities, their data elements, and illustrate the interrelationships among the entities. A data model identifies the logical information requirements and metadata, applicable to persistently stored data, which form a basis for physical database schemata and standard data elements within a relational database.
Object Models define the combined information and process requirements within a domain needed to accomplish a particular capability or set of capabilities, for example, as defined by activity models. Such models form the basis of object-oriented system implementations. They also model system interoperability by combining the metadata for shared data with the allowable interfaces for sharing that data. Such models show associations and dependencies between system interfaces and the essential business rules for exercising those relationships.
In order to provide an authoritative source for DoD data standards, DoD created the Defense Data Dictionary System (DDDS). The DDDS, managed by DISA, is a DoD-wide central database that includes standard names and definitions for data entities and data elements (i.e., attributes). The DDDS server also provides password-protected access to DoD standard data models. The DDDS is used to collect individual data standards derived from the DoD Data Model (DDM), now called the DoD Data Architecture (DDA), and to document content and format for data elements. System developers use this repository as a primary source of data element standards.
Information exchange is accomplished for the most part by sending formatted messages. The definition and documentation of these exchange mechanisms are provided by various messaging standards. Each message standard provides a means to define message form and functions (i.e., transfer syntax), which includes the definition of the message elements contained in each message. The message fields, which are currently defined in the various message standards, are not necessarily mutually consistent, nor are they consistently based on any activity or data models either within a message system or across message systems. Newer techniques provide more direct exchange of data without the user following a rigid format. A model-based structure will provide definitions that will be data element-based and will be compliant with DoD data element standards established in accordance with DoD Directive (DoDD) 8320.1, Data Administration, and associated DoD 8320.1 manuals.
Efficient execution of information exchange requirements (IERs) throughout the joint battlespace is key to evolving DoD toward the ultimate goal of seamless information exchange. The primary component of this infrastructure is the Tactical Data Link (TDL), composed of message elements/messages and physical media. However, due to the diversity of warfighter requirements, no single data link is applicable to every platform and weapon system.
Tactical Digital Information Links (TADILs), structured on bit-oriented message standards, evolved to meet critical real-time and near-real-time message requirements. The United States Message Text Format (USMTF), designed primarily for non-real-time exchange, is based on a character-oriented message format and is the standard for human-readable and machine-processable information exchange. The goal of TDLs, character-oriented/human-readable (USMTF messages), imagery, voice, and video standards is to provide a timely, integrated, and coherent picture for joint commanders and their operational forces.
Disparate data link message formats and communications media have resulted in late delivery of crucial battlefield information. This causes significant interoperability problems among the Commanders-in-Chief (CINCs), Services, Agencies (C/S/A), and allied nations. Currently, it is difficult to establish seamless information flow among diverse data-link units. Future joint operations, such as ballistic missile defense and battlefield digitization, will place greater emphasis on the need for automated C4I functions. Tomorrow's battlefields will vastly increase the burden on networks.
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for information modeling, metadata, and information exchange standards.
Activity Modeling
Activity models are used to document/model the activities, processes, and data flows supporting the requirements of process improvement and system development activities. Prior to system development or major system update, an activity model is prepared to depict the mission-area function to a level of detail sufficient to identify each entity in the data model that is involved in an activity. The activity model can form the basis for data and/or object model development or refinement. It is validated against the requirements and doctrine, and approved by the operational sponsor. IEEE 1320.1, IDEF0 Function Modeling, is the standard that describes the IDEF0 modeling language semantics and syntax, as well as associated rules and techniques, for developing structured graphical representations of a system or enterprise.
Data Modeling
Relational data models are used in software requirements analyses and design activities as a logical basis for physical data exchange and shared data structures that can benefit from a relational schema definition, including message formats and schema for shared databases. Object-oriented systems use data models to design relational data structures when there is a requirement to maintain persistent data storage for that system in a relational database. IDEF1X is used to produce a graphical information model, which represents the structure and semantics of information within an environment or system. FIPS PUB 184 is the standard that describes the IDEF1X modeling language (semantics and syntax) and associated rules and techniques for developing a logical model of data. Use of this standard permits the construction of semantic data models, which support the management of data as a resource, the integration of information systems, and the building of relational databases.
System engineering methodology internal to a system is unrestricted. The mandated standard for Data Modeling is:
DoD Data Model Implementation
The DoD Data Architecture (DDA) is an enterprise view of the data, which provides the standard definition of specific data elements to the developers of all DoD systems. The DDA has replaced the DoD Data Model (DDM) and is now available for use by the DoD Community. The DDA portrays DoD data standards grouped in functional views, which are aligned by Functional Data Administrators rather than subject areas as in the DDM. Tactical systems must incorporate applicable C2 Core Data Model (C2CDM) elements. The C2CDM is a subset of the DDA. Implementation of the DDA will be interpreted to mean that the DDA will serve as the logical reference model database schema defining the names, representations, and generalized relations of data within DoD systems. System developers comply by using this reference model database schema as a guide to reusable data structures that can form the basis of their own physical database schemas. Developers of new and existing systems will maintain traceability between data structures used in their physical database schemas and the DDA, by registering both the reuse of the data standards in the DDDS and the development/adoption of additional data structures. Information regarding access to the DDA can be obtained from the DoD Data Administration Web home page at <http://www-datadmn.itsi.disa.mil/> .
Adherence to the DDA for shared or sharable data will aid DoD Agencies in developing interoperability among all information systems. The shared or sharable data of a new or major system upgrade that are to be persistently stored in a relational or object-relational database will be documented within a data model based on the DDM. New information requirements for shared data are submitted by DoD Components and approved by functional data stewards in accordance with DoD Manual 8320.1-M-1, DoD Data Standardization Procedures. This data will be used to extend the DDA, as appropriate. System engineering methodology internal to a system is unrestricted. The following standard for DDA implementation is mandated:
DoD Data Definitions
The Defense Data Dictionary System (DDDS) is a central database that includes standard data entities, data elements, and provides access to DDM files from the DDDS server. The procedures for preparing and submitting data definitions and data models for standardization are covered in DoD Manual 8320.1-M-1. System developers shall use this repository as a primary source of data element standards.
Information Exchange Standards
Information Exchange Standards Applicability
Information Exchange Standards refer to the exchange of information among mission-area applications within the same system or among different systems. The scope of information exchange standards follows:
The exchange of information among applications using shared databases or formatted message structures shall be based on the logical data models developed from identifying information requirements through activity models, where appropriate. The data model identifies the logical information requirements, which shall be developed into physical database schemata and standard data elements.
The standard data elements shall be exchanged using the data-management, data interchange, and distributed-computing services of application platforms. (Refer to See Information Processing Standards for further guidance on these services.) The goal is to exchange information directly between information systems, subject to security classification considerations.
Information exchange between systems using object-oriented interface definitions can be based on object models depicting those interfaces and the functional dependency of those interfaces. With object models, standard data elements are typically associated with the atomic data attributes that represent shared data.
Information-Exchange standards help form the Defense Information Infrastructure (DII) Common Operating Environment (COE), ensuring the use of system or application formats that can share data. Key references include See Data Management Services, for SQL standards in Data Management Services and See Data Interchange Services for Data Interchange Services.
In distributed databases, other types of data messaging may be used as long as they remain DDDS-compliant.
Tactical Information Exchange Standards
The message standards below are joint/combined message standards that provide for the formatted transfer of information between systems. Although it must be recognized that the J-Series Family of TDLs and the USMTF Standards are not model-based and therefore do not meet the goals of standard information exchange, they must be recognized as existing standards. As more systems are developed using logical data models and standard data elements, these message standards must evolve to be data model-based if they are to continue to support joint automated systems. In distributed databases, other types of data messaging may be used as long as they remain DDDS-compliant.
Bit-Oriented Formatted Messages
The J-Series Family of TADILs allows information exchange using common data element structures and message formats that support time-critical information. They include Air Operations/Defense Maritime, Fire Support, and Maneuver Operations. These are the primary data links for exchange of bit-oriented information. The family consists of LINK 16, LINK 22, and the Joint Variable Message Format (VMF), and interoperability is achieved through use of J-Series family messages and data elements. The policy and management of this family are described in the Joint Tactical Data Link Management Plan (JTDLMP), dated 6 June 1996.
New message requirements shall use these messages and data elements or use the message construction hierarchy described in the JTDLMP. Where not addressed by another standard within the JTA (e.g., TADIL-J and VMF), the following standards are mandated as the format for transferring (though not processing) binary floating-point data:
Note: Between publications of the above mandated standards, the TADIL Interface Change Proposals (ICPs) status report lists changes to the standards. Once a TADIL ICP has the status "approved and awaiting incorporation," it is approved for implementation. The TADIL ICP Status Report is located at: <http://www-tadil.itsi.disa.mil/index.htm> .
Character-Based Formatted Messages
United States Message Text Format (USMTF) messages are jointly agreed, fixed-format, character-oriented messages that are human-readable and machine-processable. USMTFs are the mandatory standard for record messages when communicating with the Joint Staff, Combatant Commands, and Service Components. The mandated standard for USMTF Messages is:
Note: Per Service agreement, the USMTF is updated annually. Implementers have a full year from each release date to update their systems.
Binary Floating-Point Data Interchange
ANSI/IEEE 754-1985 defines formats and functional requirements for processing binary floating-point numbers including infinities and Not-a-Number values. A few standards with a larger scope define their own specialized binary floating-point format for use within the scope of that standard. Where not addressed by another standard within JTA (e.g., TADIL J and JVMF), the following standard is mandated as the format for transferring (though not processing) binary floating-point data:
Object Modeling
Object-oriented modeling techniques are used in the specification and development of object-oriented systems and to model and design the interoperability requirements of distributed components.
The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system. In an elaborative approach, developers develop models and increasingly add details until the model becomes the actual system being developed. Information may be obtained from the Web at http://www.omg.org . The following standard is mandated:
Emerging Standards
The emerging standards listed in this subsection are expected to be elevated to mandatory status when implementations of the standards mature.
Object Modeling
The XML Metadata Interchange (XMI) standard describes an information interchange model. This model allows developers using UML object technology tools to exchange programming data in a common format by defining a set of XML DTDs (Document Type Definitions) for exchanging UML information. The following standards are emerging:
DoD Data Definitions
The DISA Joint Information Engineering Organization (JIEO), in coordination with the Standards Coordinating Committee (SCC) and the Change Control Board (CCB), will develop the strategy/policy for migration from many tactical data-link (bit-oriented) and character-oriented joint message standards to a minimal family of DoD 8320.1-compliant information exchange standards. A normalized unified data/message element dictionary will be developed based on normalized Data Model and associated data element standards. The dictionary will support both character- and bit-oriented representation of the standard data and their domain values. Message standards will then establish the syntax for standard data packaging to support mission requirements (e.g., character- or bit-oriented, fixed or variable format, etc.). The unified data dictionary will ensure that multiple representations are minimized and transformation algorithms are standardized. The Data Model basis for the data elements will ensure that the information is normalized.
Information Exchange Standards
The emerging standards for information exchange are:
Multi-functional Information Distribution System (MIDS) , MIDS is a planned replacement for the Joint Tactical Information Distribution System (JTIDS). MIDS will provide secure jam-resistant communications, utilizing tactical digital data and voice. Message format standards for MIDS will not change from those of the JTIDS.
Data Modeling
IDEF1X97 is being developed by the IEEE IDEF1X Standards Working group of the IEEE 1320.2 Standards Committee. The standard describes two styles of the IDEF1X model. The key-style is used to produce information models that represent the structure and semantics of data within an enterprise and is backward-compatible with the U.S. Government's Federal Standard for IDEF1X, FIPS 184. The identity-style is a wholly new language that provides system designers and developers with a robust set of modeling capabilities covering all static and many dynamic aspects of the emerging object model. This identity-style can, with suitable automation support, be used to develop a model that is an executable prototype of the target object-oriented system. The identity-style can be used in conjunction with emerging dynamic modeling techniques to produce full object-oriented models. The following standard is emerging:
Human-Computer Interface Standards
Introduction
Purpose
This section provides a common framework for Human-Computer Interface (HCI) design and implementation in DoD automated systems. The objective is to standardize user interface design and implementation options thus enabling DoD applications within a given domain to appear and behave consistently. The standardization of HCI appearance and behavior within DoD will result in higher productivity; shorter training time; and reduced development, operation, and support costs.
Scope
This section addresses the presentation and dialogue of the Human-Computer Interface. See Information Processing Standards addresses the API definitions and protocols. See JTA See Human-Computer Interface Security Standards and Appendix A of the DoD HCI Style Guide, Security Presentation Guidelines, and other applicable portions of the DoD HCI Style Guide for HCI Security.
Background
The objective of system design is to ensure system reliability and effectiveness. To achieve this objective, the human must be able to effectively interact with the system. Humans interact with automated systems using the HCI. The HCI includes the appearance and behavior of the interface, physical interaction devices, graphical interaction objects, and other human-computer interaction methods. A good HCI is both easy to use and appropriate to the operational environment. It exhibits a combination of user-oriented characteristics such as intuitive operation, ease and retention of learning, facilitation of user task performance, and consistency with user expectations.
The need to learn the appearance and behavior of different HCIs used by different applications and systems increases both the training burden and the probability of operator error. What is required are interfaces that exhibit a consistent appearance and behavior both within and across applications and systems.
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for human-computer interfaces. Each mandated standard or practice is clearly identified on a separate bulleted line and includes a formal reference that can be included within Requests for Proposals (RFPs) or Statements of Work (SOWs).
General
The predominant types of HCIs include graphical user interfaces (GUIs) and character-based interfaces. Although GUIs are the preferred user interface, some specialized devices may require use of character-based interfaces due to operational, technical, or physical constraints. These specialized interfaces shall be defined by domain-level style guides and further detailed in system-level user interface specifications. In order to present a consistent interface to the user, application software shall not mix command line user interfaces and GUIs.
Graphical User Interface
When developing DoD automated systems, the graphical user interface shall be based on one commercial user interface style guide consistent with See Commercial Style Guides. Hybrid GUIs that mix user interface styles (e.g., Motif with Microsoft Windows) shall not be created. A hybrid GUI is composed of toolkit components from more than one user interface style. When selecting commercial off-the-shelf (COTS)/Government off-the-shelf (GOTS) applications for integration with developed DoD automated systems, maintaining consistency in the user interface style is highly recommended. An application delivers the user interface style that matches the host platform (i.e., Motif on a UNIX platform and Windows on an NT platform). This style conforms to commercial standards, with consistency in style implementation regardless of the development environment used to render the user interface. Applications that use platform-independent languages such as Java deliver the same style as the native application on the host platform.
See See User Interface Services for mandated GUI standards.
GUI Style Guides
An HCI style guide is a document that specifies design rules and guidelines for the look and behavior of the user interaction with a software application or a family of software applications. The goal of a style guide is to improve human performance and reduce training requirements by ensuring consistent and usable design of the HCI across software modules, applications, and systems. The style guide represents "what" user interfaces should do in terms of appearance and behavior and can be used to derive HCI design specifications defining "how" the rules are implemented in the application code.
See : HCI Development Guidance illustrates the hierarchy of style guides that shall be followed to maintain consistency and good HCI design within DoD. This hierarchy, when applied according to the process mandated in DoD's HCI Style Guide, provides a framework that supports iterative prototype-based HCI development. The process starts with top-level general guidance and uses prototyping activities to develop system-specific design rules.
The interface developer shall use the selected commercial GUI style guide and the appropriate domain-level style guide for specific style decisions, along with input of human factors specialists to create the system-specific HCI. The following paragraphs include specific guidance regarding the style guide hierarchy levels.
Commercial Style Guides
A commercial GUI style shall be selected as the basis for user interface development. The GUI style selected is usually driven by the mandates specified in See Information Processing Standards (User Interface Services and Operating System Services).
X-Window Style Guides
If an X-Windows-based environment is selected, the style guide corresponding to the selected version of Motif is mandated. The following Motif style guides are mandated:
M027 : CDE 2.1/Motif 2.1 - Style Guide and Glossary, The Open Group ISBN 1-85912-104-7, October 1997.
|
|
Domain-Level Style Guides
The JTA allows for the development of domain-level HCI style guides. These styles, when developed, will reflect the consensus on HCI appearance and behavior for a particular domain within DoD. The domain-level style guide will be the compliance document and may be supplemented by a system-level style guide. Domain-level style guides that make use of commercial standards, COTS products, graphical user interfaces, windows, and/or conventional displays should be developed as extensions to the User Interface Specification for the DII. Domain-level style guides should be complementary and nonconflicting with DoD HCI Interface and applicable commercial standards. The following domain-level style guide is mandated for HTML, Motif, and Windows-based systems:
System-Level Style Guides
System-level style guides provide the special tailoring of commercial, DoD, and domain-level style guides. These documents include explicit design guidance and rules for the system, while maintaining the appearance and behavior provided in the domain-level style guide. If needed, the Motif-based system-level style guide will be created in accordance with the User Interface Specification for the DII.
The process of developing effective system-level style guidance and specifications is dependent upon a proper process for human systems integration engineering, as shown in See : HCI Development Guidance. ISO 13407, "Human-centred design processes for interactive systems," provides a flexible model for inclusion of critical human systems integration issues into the design process. Use of this process leads to interactive systems that are easier to use, requires lower training and support costs, as well as improve user satisfaction and productivity. The process includes active involvement of users to achieve clear understanding of user/task requirements, appropriate allocations of function between users and technologies, and allows for iterative/multi-disciplinary design solutions to achieve the systems' interoperability and cost goals.
Emerging Standards
Symbology
The Geospatial Symbols for Digital Displays (GeoSym) specification defines the format and content of symbol graphics and symbol assignment tables. GeoSym symbols were created for use with VPF products and are designed to complement Common Warfighting Symbology (MIL-STD-2525B). For nonwarfighting, geospatial symbology, the following standard is emerging:
Currently, research is underway to investigate nontraditional user interfaces. Such interfaces may be gesture-based and may involve processing multiple input sources, such as voice and spatial monitors. Ongoing research and investigation includes the use of virtual reality and interface agents. Interface agents autonomously act on behalf of the user to perform various functions, thus allowing the user to focus on the control of the task domain. DoD will integrate standards for nontraditional user interfaces as research matures and commercial standards are developed.
Information Security Standards
Introduction
Purpose
This section provides the information security standards necessary to implement security at the required level of protection.
Scope
The standards mandated in this section apply to all DoD information technology systems. This section provides the security standards applicable to information processing, transfer, modeling, metadata, exchange, and Human-Computer Interfaces (HCI). This section also addresses standards for security audit and key management mechanisms. See Mandated Standards addresses mandated security standards, and See Emerging Standards addresses emerging security standards.
Background
Interoperability requires seamless information flow at all levels of information classification without compromising security. The goal is to protect information at multiple levels of security, recognizing that today's DoD systems are "islands" of system-high solutions.
The concept of security assurance provides confidence that the security features do what they are supposed to do, and that they do not do what they are not supposed to do. While assurance has been largely associated with product security, it is an equally important concept applied to system security since it is unlikely that integrated products will retain their individual assurance characteristics.
Systems that process sensitive data must be certified and accredited before use. Certification is the technical evaluation of security features and other safeguards, made in support of the accreditation. Accreditation is the authorization by the Designated Approving Authority (DAA) that an information system may be placed into operation. By authorizing a system to be placed into operation, the DAA is declaring that the system is operating under an "acceptable level of risk." Therefore, system developers should open dialog with the Certifier and DAA concurrently with their use of the Joint Technical Architecture (JTA), as DAA decisions can affect the applicability of standards within specific environments. The DoD Information Technology Security Certification and Accreditation Process (DITSCAP) is defined in DODI 5200.40.
DoD systems should have adequate safeguards to enforce DoD security policies and system security procedures. System safeguards should provide adequate protection from user attempts to circumvent system access control, accountability, or procedures for the purpose of performing unauthorized system operations.
Security requirements and engineering should be determined in the initial phases of design. The determination of security services to be used and the strength of the mechanisms providing the services are primary aspects of developing the specific security architectures to support specific domains. See Information Security Standards of the JTA is used after operational architectural decisions are made regarding the security services needed and the required strengths of protection of the mechanisms providing those services.
The proper selection of standards can also provide a basis for improved information protection. Although few specific standards for the general topic of "information protection" exist within Defensive Information Warfare, selecting standards with security-relevant content contributes to the overall improvement of the security posture of information systems.
For more information on implementing information systems and networks to provide defense-in-depth, see the Information Assurance Technical Framework (IATF), available at <http://www.iatf.net> .
Mandated Standards
This subsection identifies the mandatory standards, profiles, and practices for information security standards. Each mandated standard or practice is clearly identified on a separate bulleted line and includes a formal reference that can be included within Requests for Proposals (RFPs) or Statements of Work (SOWs).
The Evaluation Criteria for Information Technology Security (Common Criteria) represents the outcome of efforts to develop criteria for evaluation of IT security that are widely useful within the international community. It is an alignment and development of a number of existing European, U.S., and Canadian criteria (ITSEC, TCSEC, and CTCPEC) respectively. The Common Criteria is a meta-standard (a standard of standards) as it is essentially a list of selectable security requirements (functional and assurance), plus definitions and requirements for how to document security capabilities and needs (as Security Targets and Protection Profiles respectively). The following standard is mandated for (1) defining common security requirements across multiple commercial or governmental implementations, by defining a Protection Profile (PP), and for (2) defining evaluation documentation demonstrating that a given system implements PP requirements through its Security Target (ST):
Introduction
This section contains the mandatory information security standards and protocols that shall be implemented in systems that have a need for the corresponding interoperability-related services. If a service is to be implemented, then it shall be implemented at the required level of protection using the associated security standards in this section. If a service is specified by more than one standard, the appropriate standard should be selected based on system requirements. See Mandated Standards is structured to mirror the overall organization of the JTA so that readers can easily link security topics with the related subject area in the sections of the JTA (information processing; information transfer; information modeling, metadata, and information exchange; and human-computer interface) and their sub-sections.
Information Processing Security Standards
Application Software Entity Security Standards
If FORTEZZA services are used, the following standards are mandated:
Application Platform Entity Security Standards
For the application platform entity, security standards are mandated for authentication services. Security is an important part of other application platform service areas, but there are no standards for the other service areas.
Authentication Security Standards
Authentication supports tracing security-relevant events to individual users. If Open Software Foundation DCE Version 1.1 is used, the following authentication standard is mandated:
If DCE Version 1.1 is not used, the following authentication standard is mandated:
Additional guidance documents: NCSC-TG-017 - A Guide to Understanding Identification and Authentication in Trusted Systems: NCSC-STD-002 DoD Password Management Guidance.
Information Transfer Security Standards
This section discusses the security standards that shall be used when implementing information transfer security services. Security standards are mandated for the following information transfer areas: end-system (host standards) and network (internetworking standards).
End-System Security Standards
Security standards for host end-systems are included in the following subsections.
Host Security Standards
Host end-system security standards include security algorithms, security protocols, and evaluation criteria. The first-generation FORTEZZA Cryptographic Card is designed to protect information in messaging and other applications.
For systems required to interface with Defense Message System for Organizational Messaging, the following standards are mandated:
Security Algorithms
To support interoperability using encrypted messages, products must share a common communication protocol. This protocol must include a common cryptographic message syntax, a common cryptographic algorithm, and a common mode of operation (e.g., cipher block chaining).
This section identifies security standards that shall be used for the indicated types of cryptographic algorithms: hashing, message digest, digital signatures, message encryption, and key exchange. If message digest or hash algorithms are required, Key Recovery will be implemented in a certificate management hierarchy. In FORTEZZA applications the following standards are mandated.
Note: Both the Key Exchange Algorithm (KEA) and the SKIPJACK Algorithm (FIPS-185) were declassified on 23 June 1998.
Security Protocols
The following standard is mandated for DoD systems required to exchange security attributes; for example, sensitivity labels:
Establishment of a certificate and key management infrastructure for digital signature is required for the successful implementation of the security architecture. This infrastructure is responsible for the proper creation, distribution, and revocation of end-users' public-key certificates. The following standard is mandated:
The Message Security Protocol (MSP) Version 4.0 has been revised to accommodate, in part, Allied requirements. All of MSP 4.0 features have been incorporated into Allied Communications Publication 120, Common Security Protocol. The following messaging security protocol is mandated for DoD message systems required to exchange sensitive but unclassified and classified organizational messaging:
The following standard is mandated for individual messages that use digital certificates issued by the DoD PKI to protect sensitive but unclassified individual messaging (e-mail):
Network Security Standards
Systems processing classified information must use Type 1 NSA-approved encryption products to provide both confidentiality and integrity security services within the network.
When network-layer security is required, the following security protocol is mandated:
The following standard is mandated for DoD systems required to exchange security attributes; for example, sensitivity labels:
Information Modeling, Metadata, and Information Exchange Security Standards
At this time, no information modeling, metadata, and information exchange standards are mandated. Process models and data models produced should be afforded the appropriate level of protection.
Human-Computer Interface Security Standards
At this time, no human-computer interface security standards are mandated.
Web Security Standards
The Secure Sockets Layer (SSL) protocol allows client/server applications to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. It is currently the de facto standard used by most browsers and popular e-mail packages that are associated with the browser. RFC 2246, The TLS Protocol, Version 1.0, January 1999, is an Internet Engineering Task Force (IETF) Proposed Standard and is expected to supersede SSL as a mandated standard within 2 years. Since Netscape is supporting TLS development, it is expected that there will be no further development of the SSL protocol by Netscape. The following standard is mandated:
Emerging Standards
The emerging standards listed in this subsection are expected to be elevated to mandatory status when implementations of the standards mature.
Introduction
The emerging security standards described in this section are drawn from work being pursued by ISO, IEEE, IETF, Federal standards bodies, and consortia such as the Object Management Group (OMG). See Emerging Standards is structured to mirror the overall organization of the JTA so that readers can easily link security topics with the related subject area in the sections of the JTA (information processing; information transfer; information modeling, metadata, and information exchange; and human-computer interface) and their subsections.
Information Processing Security Standards
Information processing security standards are emerging in applications software and application platform entity areas.
Application Software Entity Security Standards
Emerging application software entity standards include Web security standards.
Web Security Standards
RFC 2246, The Transport Layer Security (TLS) Protocol Version 1.0, January 1999, is an Internet Engineering Task Force (IETF)-Proposed Standard that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. It is based on the SSL 3.0 Protocol Specification as published by Netscape. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). TLS runs above the transport layer. TLS is expected to supersede SSL as a mandated standard within 2 years. Since Netscape is supporting TLS development, it is expected that there will be no further development of the SSL protocol by Netscape. The following standards are emerging:
Application Platform Entity Security Standards
For the application platform entity, security standards are emerging for software engineering, operating systems, and distributed computing services.
Software Engineering Services Security
For software engineering services, security standards are emerging for Generic Security Service (GSS)-Application Program Interface (API) and POSIX areas.
Generic Security Service-Application Program Interface Security
The Generic Security Service-Application Program Interface (GSS-API), as defined in RFC 1508, September 1993 (IETF), provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. RFC 1508 defines GSS-API services and primitives at a level independent of an underlying mechanism and programming language environment. RFC 2743, "GSS-API, Version 2.0," J. Linn, Update 1 January 2000, revises RFC 1508, making specific, incremental changes in response to implementation experience and liaison requests. The following standard is emerging:
The IETF, "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)," C. Adams, December 1998, extends the GSS-API (RFC 1508) for non-session protocols and applications requiring protection of a generic data unit (such as a file or message) independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. An example application is secure electronic mail in which data needs to be protected without any online connection with the intended recipient(s) of that data. Subsequent to being protected, the data unit can be transferred to the recipient(s)--or to an archive--perhaps to be processed as unprotected days or years later. The following standard is emerging:
Operating System Services Security
Operating system services security standards are emerging in the following areas: evaluation criteria and authentication.
Evaluation Criteria Security Standards
See See Mandated Standards for a description of the Common Criteria. More information on Common Criteria Protection Profiles is available on NIST's Web home page.
For the application platform entity, the following standards are considered emerging for the acquisition of operating systems consistent with the required level of trust:
Authentication Security Standards
IETF RFC 2289, "A One-Time Password System," February 1998, provides authentication for system access (login)--and other applications requiring authentication--that is secure against passive attacks based on replaying captured reusable passwords. The One-Time Password System evolved from the S/KEY One-Time Password System released by Bellcore. The following standard is emerging:
When Remote Dial-In Authentication is required, the following standard is emerging:
Distributed Computing Services Security Standards
Distributed Computing Environment (DCE) Authentication and Security Specification C311, August 1997, is a draft Open Group Specification for DCE.
The Common Object Request Broker Architecture (CORBA) Security Services define a software infrastructure that supports access control, authorization, authentication, auditing, delegation, non-repudiation, and security administration for distributed-object-based systems. This infrastructure can be based on existing security environments and can be used with existing permission mechanisms and login facilities. The key security functionality is confined to a trusted core that enforces the essential security policy elements. Since the CORBA Security Services are intended to be flexible, two levels of conformance may be provided. Level 1 provides support for a default system security policy covering access control and auditing. Level 1 is intended to support applications that do not have a default policy. Level 2 provides the capability for applications to control the security provided at object invocation and also for applications to control the administration of an application-specific security policy. Level 2 is intended to support multiple security policies and to provide the capability to select separate access control and audit policies. The following standards are emerging:
Information Transfer Security Standards
Security standards are emerging for the following information transfer areas: end-systems (host standards) and network (internetworking standards).
End-System Security Standards
Emerging end-system security standards include host standards discussed in the following subsection.
Host Security Standards
Emerging security standards for host end-systems in security protocols are discussed in the following subsection.
Security Protocols
In mid-1996, some significant improvements were proposed to the Secure/Multipurpose Internet Mail Extensions (S/MIME) messaging security protocol and the underlying encapsulation protocol, PKCS#7. With these improvements, S/MIME will provide a business-quality security protocol for both the Internet and X.400 messaging environments. The improvements include: (1) algorithm independence, (2) support for digitally signed receipts, (3) support for mail lists, and (4) support for sensitivity labels in signed and unsigned/encrypted messages. This effectively merges S/MIME and Message Security Protocol (MSP) 4.0/ACP-120. In November 1997, the IETF formed the S/MIME security protocol working group to create Internet standards based on S/MIME and these improvements. The following is an emerging standard:
It is expected that the Trusted Systems Interoperability Group (TSIG), Trusted Information for Exchange for Restricted Environments (TSIX (RE) 1.1) will adopt MIL-STD-2045-48501 as a replacement for its Common Internet Protocol Security Options (CIPSO) labeling standard.
The following IEEE-approved standard for Local Area Network (LAN) security and Metropolitan Area Network (MAN) security is emerging:
This IEEE standard provides specifications for security association management (Manual, Key Distribution Center, and Certification-based), security labeling and security services including data confidentiality, connectionless integrity, data origin authentication and access control. The Key Management Protocol (KMP) defined in Clause 3 is applicable to the Secure Data Exchange (SDE) protocol contained in the standards as well as other security protocols.
Medium-Assurance Public-Key Infrastructure Security Standards
Background
A public-key infrastructure (PKI) comprises the people, policies, procedures, and computing/telecommunications resources needed to manage public keys used by information systems. A PKI supports the following security services: authentication, data integrity, non-repudiation, confidentiality, and (optionally) authorization.
A PKI supports "X.509 public-key certificates," as defined in International Telecommunications Union-Telecommunications (ITU-T) Recommendation X.509. A public-key certificate is a data structure that binds a subject (people, applications programs, machines, etc.) and the subject's public key. A public-key certificate may contain additional attributes of the subject, such as address, phone number, and authorization (access control) data.
A PKI may support X.509 attribute certificates. An attribute certificate binds a subject and the subject's authorization data, such as group membership, roles, clearances, privileges, and restrictions. The authorization data does not guarantee access to information resources, as the decision to grant or deny access is made by the application that uses the certificate. Attribute certificates do not contain public keys.
A private key is used to digitally sign data, such as messages, files, and transactions. The corresponding public key is used to verify the signature. A private key can also be used to decrypt data encrypted with the corresponding public key. In the DOD medium-assurance PKI, the public/private-key pairs used for non-repudiation or digital signature services will be distinct from the pairs used for encryption/decryption services. Public/private-key pairs are also used in algorithms that automatically distribute symmetric, secret keys.
X.509 public-key certificates are signed and issued by a special user called a certification authority (CA). A CA may also revoke certificates. X.509 attribute certificates are signed, issued, and revoked by an attribute certificate issuer.
The DoD medium-assurance PKI is authorized to protect unclassified and certain types of sensitive but unclassified (SBU) information, in accordance with the DoD Class 3 level of information assurance. The DoD medium-assurance PKI may also be used for digital signature services, user authentication, and community of interest separation within certain types of classified networks protected by Type I cryptography. The U.S. DoD X.509 Certificate Policy specifies the permitted uses of a medium-assurance (Class 3) PKI in encrypted and unencrypted networks.
The standards listed below are the ones actually being used in the DoD medium-assurance pilot PKI. The standards are grouped according to the categories defined in the Internet Draft entitled "Internet X.509 Public Key Infrastructure PKIX Roadmap," <draft-ietf-pkix-roadmap-02.txt>, 23 June 1999, plus additional categories not mentioned in the Roadmap. Additional information on PKI policy can be found at <http://www-pki.itsi.disa.mil> .
Certificate Profiles
The DoD medium-assurance certificate profile implements the Federal PKI certificate profile, which in turn implements the Internet Engineering Task Force (IETF) profile, which in turn implements the ITU-T X.509 profile. Emerging certificate profile standards are:
Operational Protocols and Exchange Formats
Operational protocols deliver certificates and certificate revocation lists (CRLs) to certificate-using systems. The medium-assurance pilot uses RFC 2559, a profile of RFC 1777, Lightweight Directory Access Protocol, version 2, (LDAPv2), as its operational protocol. The following operational protocol is emerging:
Certificates and CRLs are stored in LDAP servers, which are accessed by certificate-using systems through LDAPv2. RFC 2587 specifies the minimal schema required to support certificates and CRLs in an LDAP server. An emerging standard for LDAP PKI servers is:
Certificates, private keys, and other personal data must be protected when they are moved between computers or removable media, such as smart cards or floppy disks. For secure or authenticated exchange of such personal data, the following standards are emerging:
Management Protocols
Management protocols support transactions involving management entities, such as CAs, Registration Authorities (RAs), and Local Registration Authorities (LRAs). Typical transactions are user registration, certificate enrollment, and certificate revocation. The following management protocols are emerging:
Although RFC 2315 and 2314 are based upon de facto standards from RSA Laboratories, Inc., the IETF is incorporating them into open, consensus-based standards, such as the Internet draft for "Certificate Management Messages over Cryptographic Message Syntax (CMC)." As the CMC draft matures, it will be considered for adoption as an emerging standard.
Application Program Interfaces (APIs)
API standards allow programmers to incorporate PKI services into their applications in a manner that supports applications portability. The following standard is emerging:
Cryptography
The following standards are emerging:
RSA Laboratories Public Key Cryptography Standard (PKCS) #1 , RSA Cryptography Standard, Version 2.0, 1 October 1998.
The following standard is emerging for PKI Class 3 implementations:
The following standard is emerging for encryption of sensitive but unclassified (SBU) data:
Network Security Standards
Emerging network standards are listed in See Internetworking Security Standards.
Internetworking Security Standards
IETF RFC 2401, "Security Architecture for the Internet Protocol," S. Kent and R. Atkinson, November 1998, describes the security mechanisms for IP and the services that they provide. Each security mechanism is specified in a separate document. RFC 2401 also describes key management requirements for systems implementing those security mechanisms. It is not an overall Security Architecture for the Internet, but focuses on IP-layer security.
This RFC specifies the base architecture for IPsec-compliant systems. It also describes the security services offered by the IPsec protocols and how these services can be employed in the IP environment. IPsec is designed to provide interoperable, high-quality, cryptographically based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper-layer protocols. These objectives are met through the use of two traffic security protocols: the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols.
The Internet Draft RFC 2402, "IP Authentication Header," S. Kent and R. Atkinson, November 1998, describes a mechanism for providing integrity and authentication for IP datagrams. An AH is normally inserted after an IP header and before the other information being authenticated. The AH is a mechanism for providing strong integrity and authentication for IP datagrams. It might also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed.
IETF RFC 2402 "IP Authentication Header," November 1998. The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams, and to provide protection against replays. AH may be applied alone, in combination with the IP Encapsulating Security Payload (ESP), or in a nested fashion through the use of tunnel mode. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP may be used to provide the same security services, and it also provides a confidentiality (encryption) service. The primary difference between the authentication provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields.
IETF RFC 2406, "IP Encapsulating Security Payload (ESP)," November 1998, S. Kent and R. Atkinson, discusses a mechanism for providing integrity and confidentiality to IP datagrams. In some circumstances, depending on the encryption algorithm and mode used, it can also provide authentication to IP datagrams. Otherwise, the IP AH may be used in conjunction with ESP to provide authentication. The mechanism works with both IPv4 and IPv6. The ESP header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP AH [KA97b], or in a nested fashion, e.g., through the use of tunnel mode. Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. However, use of confidentiality without integrity/authentication (either in ESP or separately in AH) may subject traffic to certain forms of active attacks that could undermine the confidentiality service.
IETF RFC 2104, "HMAC: Keyed-Hashing for Message Authentication," February 1997, H. Krawczyk (IBM), M. Bellare (UCSD), R. Canetti (IBM). This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function.
IETF RFC 1829, "The ESP DES-CBC Transform," P. Karn (Qualcomm), P. Metzger (Piermont), W. Simpson (Daydreamer), August 1995. The Encapsulating Security Payload (ESP) provides confidentiality for IP datagrams by encrypting the payload data to be protected. This specification describes the ESP use of the Cipher Block Chaining (CBC) mode of the U.S. Data Encryption Standard (DES) algorithm (FIPS PUB 46, FIPS PUB 46-1, FIPS PUB 74, FIPS PUB 81). All implementations that claim conformance or compliance with the ESP specification must implement this DES-CBC transform. RFC 2451, "The ESP CBC-Mode Cipher Algorithms," R. Periera and R.Adams, November 1998 and RFC 2405, "The ESP CBC-Mode Cipher Algorithm with Explicit IV," C. Madson and N. Doraswamy, November 1998, are examples of encryption algorithms used for ESP.
Draft FIPS 46-3 Data Encryption Standard (DES). For those systems required or desiring to use a cryptographic device to protect privacy act information and other unclassified, non-Warner Act exempt information, the Data Encryption Standard (DES) may apply. The DES is found in draft FIPS 46-3 Data Encryption Standard. IETF RFC 2420. The PPP Triple-DES Encryption Protocol (3DESE) is a complement to FIPS 46-3.
The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure, yet it has no strong security mechanisms to ensure data integrity or authentication. IETF RFC 2065, "DNS Security Extensions," D. Eastlake, C. Kaufman, January 1997, describes extensions to the DNS that provide these services to security-aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security-aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public-key distribution service as well as DNS security.
IETF RFC 2408,"Internet Security Association and Key Management Protocol (ISAKMP)," Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, 21 February 1998, describes a protocol utilizing security concepts necessary for establishing Security Associations (SAs) and cryptographic keys in an Internet environment. It is expected that the IETF will adopt this protocol as the Internet standard for key and security association management for IPv6 security.
The IETF Draft, "The Resolution of ISAKMP with Oakley," D. Harkins, D. Carrel (Cisco Systems), February 1997, describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec Domain of Interpretation (DOI). ISAKMP provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key-exchange-independent; that is, it is designed to support many different key exchanges. Oakley describes a series of key exchanges--called "modes"--and details the services provided by each (e.g., perfect forward secrecy for keys, identity protection, and authentication).
RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP," D. Piper, November 1998, details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. The ISAKMP defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given DOI. The following standards are emerging:
The following IEEE-approved standard for Local Area Network (LAN) security and Metropolitan Area Network is emerging:
RFC 2228, File Transfer Protocol, October 1997, defines extensions to the FTP standard (STD9/RFC 959). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels. RFC 2228 also introduces new optional commands, replies, and file transfer encodings. The following standard is emerging:
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The following standard is emerging for securing specific terminal and X-Windows sessions:
Firewall Standards
The following emerging standards will apply to Firewall devices in Basic Robustness environments:
The following emerging standards will apply to Firewall devices in Medium Robustness environments:
Human-Computer Interface Security Standards
Refer to See Medium-Assurance Public-Key Infrastructure Security Standards for information pertaining to Medium-Assurance Public-Key Infrastructure Security Standards.
C4ISR: Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance Domain
Domain Overview
Purpose
The C4ISR Domain identifies elements (i.e., standards, interfaces, and service areas) specific to the functional areas of command, control, communications, computers, intelligence, surveillance, and reconnaissance that are additions to those standards listed in the JTA Core. These additions are common to the majority of C4ISR systems and support the functional requirements of C4ISR systems.
Background
The scope and elements listed in JTA Version 1.0 focused on C4I. Version 2.0 expanded the scope to include the areas of C4ISR, Modeling and Simulation, Weapon Systems, and Combat Support. The sections describing these areas are referred to as domain annexes.
Domain Description
The C4ISR Domain consists of those integrated systems of doctrine, procedures, organizational structures, personnel, equipment, facilities, and communications whose primary focus is on one or more of the following functions:
Support properly designated commanders in the exercise of authority and direction over assigned and attached forces across the range of military operations.
Collect, process, integrate, analyze, evaluate, or interpret available information concerning foreign countries or areas.
This will specifically address the information technology (IT) aspect of the C4ISR Domain. It should be noted that this does not include those systems or other IT components specifically identified as belonging to the Combat Support Domain or whose primary function is the support of day-to-day administrative or support operations at fixed-base locations. Examples of such systems include acquisition, finance, human resources, legal, logistics, and medical systems, and items such as general-purpose LANs, computer hardware and software, telephone switches, transmission equipment, and outside cable plant. The position of the C4ISR Domain in the JTA Hierarchy Model is shown in See : JTA Hierarchy Model.
|
|
Scope And Applicability
The elements listed in this domain are mandated for use on all emerging systems or upgrades to existing systems developed to meet the functional area of C4ISR. Users of this document are encouraged to review other domain annexes to better gauge which domain is applicable.
Technical Reference Model
This domain uses the DoD Technical Reference Model cited in See DoD Technical Reference Model of the JTA as its framework. Additional service areas required to support the C4ISR Domain are addressed in See Domain-Specific Service Areas, Domain-Specific Service Areas.
Domain Organization
The C4ISR Domain consists of three sections. C4ISR.1 contains the overview, C4ISR.2 contains Information Technology standards that are additions to those contained in the JTA Core, and C4ISR.3 is reserved for those elements that are domain-specific because they do not map directly to the JTA Core service areas.
Additions to the JTA Core
Introduction
The following sections map to the service areas of the main body of the JTA. They identify standards, profiles, and practices that are applicable to the C4ISR Domain, but have not yet been selected for inclusion in the JTA Core.
Information Processing Standards
Introduction
The information processing standards and profiles described in this section promote seamless interoperability for C4ISR systems through the use of standardized interfaces for application platforms and software.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for information processing that shall be used in the development and acquisition of C4ISR systems. These are in addition to those listed in the Core, which are mandated for all systems that utilize information technology.
Still Imagery Data Interchange
The National Imagery Transmission Format Standard (NITFS) allows for Support Data Extensions (SDEs), which are a collection of data fields that provide space within the NITF file structure for adding functionality. Documented and controlled separately from the NITFS suite of standards, SDEs extend NITF functionality with minimal impact on the underlying standard document. SDEs may be incorporated into an NITF file while maintaining backward compatibility because the identifier and byte count mechanisms allow applications developed prior to the addition of newly defined data to skip over extension fields they are not designed to interpret.
Imagery Chip, Version B (ICHIPB) is a system-independent NITF SDE that, when included with NITF image chips, will support mensuration of non-dewarped imagery. This NITF SDE holds the support data analysts need when using imagery software to mensurate or determine detailed geospatial parameters on pixel-based features within image chips. There is no mechanism in the standard NITF format to pass a standardized set of data with an image chip such that a user can easily apply imagery software to that image. The following standard is mandated for NITF systems that use National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery:
The Profile for Imagery Access Extensions (PIAE) SDE is designed to provide an area to place fields not available in the NITF but which were documented in the canceled Standards Profile for Imagery Access (SPIA). The PIAE was developed to align the SPIA and NITF for product information and adds descriptive detail associated with products. The following standard is mandated for NITF systems that use imagery from National Technical Means (NTM), Tactical/Airborne imagery, or Commercial Satellite imagery:
The Airborne SDE supersedes the VIMAS SDE and SAR SDEs described in version 1.0 of the NITFS Compendium of Controlled Extensions. The Airborne SDE incorporates all NITF tagged records relevant to SAR, Electro-Optical, Multispectral, and Hyperspectral primary imagery. Systems that use NITF imagery from airborne sensors shall be designed to extract data from the records described in this SDE. The following standard is mandated for NITF systems that exploit Tactical/Airborne imagery:
The History Tag, Version A (HISTOA) Softcopy History Tag, provides a history of any softcopy-processing actions applied to an NITF image. These extensions describe the format for support information within an NITF file containing National System Imagery. The following standard is mandated for NITF systems that exploit NTM:
Emerging Standards
The Air Group IV/SIAR Working Group under the NATO Air Force Armaments Group (NAFAG) has developed NATO Secondary Imagery Format (NSIF) STANAG 4545. The aim of this agreement is to achieve interoperability for transmission of Electronic Secondary Imagery among NATO C3I Systems. This STANAG was developed in cognizance with the International Organization for Standardization (ISO) Basic Imagery Interchange Format (BIIF) and the US MIL-STD-2500B on National Imagery Transmission Format (NITF). The following standard is emerging:
Common Ground Moving Target Indicator Data Format
The Common Ground Moving Target Indicator (CGMTI) Data Format is emerging as a de facto U.S./NATO data format for the dissemination of GMTI imagery from airborne and spaceborne GMTI sensor platforms. It is being developed as a product of the CGMTI Format Working Group, which was established to define and develop a standard that facilitates the transmission, processing, fusion, and display of GMTI data. Details of the Working Group are available at the CGMTI Web site, URL <http://www.rl.af.mil/programs/cgmti/> .The following document is identified as an emerging standard for systems that disseminate GMTI data:
Information Transfer Standards
Introduction
The information transfer standards and profiles described in this section promote seamless communications and information transfer interoperability for C4ISR systems through the use of standardized interfaces for end-systems, networks, transmission media, and systems management.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for information transfer that shall be used in the development and acquisition of C4ISR systems. These are in addition to those listed in the Core, which are mandated for all systems that utilize information technology.
Transmission Media
Transmission media refers to the physical paths used to transfer information among Components within the same system or among different systems.
Radio Communications
This section addresses standards that facilitate the interoperability of C4ISR systems that utilize the portion of the electromagnetic spectrum below 300 GHz for wireless communication.
Common Data Link Standards
The Common Data Link (CDL) is a flexible, multipurpose radio link-based digital communication technology developed by the Government for use in imagery and signals intelligence collection systems. It provides standard waveforms that follow a line-of-sight microwave path (link) and allows both full-duplex and simplex communications between airborne/space-based platforms and surface-based terminals. The CDL system supports air-to-land/sea surface, and air-to-satellite (relay/beyond line-of-sight) communications modes.
The term CDL refers to a family of interoperable data link implementations that offer alternate levels of capabilities for different applications/platforms. Five classes (Class I through Class V) of CDL have been defined. The Class I CDL standard addresses land/sea surface terminals that provide remote operation of airborne platforms operating up to 80,000 feet at mach 2.3 or less. The current land-based implementation of Class I CDL is the Miniature Interoperable Surface Terminal (MIST). The current sea-based implementation of Class I CDL is the Common High Bandwidth Data Link Surface Terminal (CHBDL-ST). Classes II through V cover the remainder of the defined CDL systems and are based on maximum altitude ceilings and sometimes platform mach number: Class II to 150,000 feet at mach 5 or less; Class III to 500,000 feet; Class IV to 750 nautical miles and is part of a satellite; lastly Class V that operates above 750 nautical miles and is part of a relay satellite. The majority of DoD CDL interoperability and standardization efforts have been focused on the Class I line-of-sight CDL system specification.
The Office of the Assistant Secretary of Defense for C3I (OASD[C3I]) designated CDL as the DoD standard in a policy memorandum (OASD/C3I Common Data Link Policy Memorandum, 13 December 1991). A similar policy memorandum was released to mandate the use of the Tactical CDL (OASD[C3I] Tactical Data Link Policy Memorandum, 18 October 1994). The following mandated standards apply for unified configuration control and standardized communications paths between airborne reconnaissance platforms that contain multiple sensors:
Unattended MASINT Sensor Communication Standards
Unattended Measurement and Signature Intelligence (MASINT) Sensors (UMSs) are small, autonomously powered, disposable systems that can be deployed by airborne platforms or ground personnel. UMS can contain one or more types of sensors (seismic, acoustic, IR, magnetic, chemical, or radiological) that transmit alarm messages or data when triggered by enemy activity. The SEIWG-005 standard specifies the frequencies, data formats, and protocols for this class of sensors in order to relay the data back via communication links and data relays, to a common exploitation station. The following standard is mandated for use in UMS systems:
Emerging Standards
The Program Management Office for Night Vision/Reconnaissance and Target Acquisition (PM NV/RSTA) has developed the Sensor Link Protocol (SLP) for use as a common local network interface between RSTA sensor systems and a host computer system. It is anticipated that SLP will evolve to provide a stable sensor interface baseline within the Intelligence and Electronic Warfare (I/EW) community. The following standard is emerging:
Information Modeling, Metadata and Information Exchange Standards
Introduction
The information modeling, metadata, and information exchange standards and profiles described in this section facilitate interoperability between C4ISR systems through the use of standardized activity models, data models, data definitions, and formatted messages.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for information modeling, metadata, and information exchange that shall be used in the development and acquisition of C4ISR systems. These are in addition to those listed in the, which are mandated for all systems that utilize information technology.
Information Exchange Standards
Information Exchange refers to the exchange of information among mission-area applications within the same system or among different systems.
Target/Threat Data Interchange Standards
The National Target/Threat Signature Data System (NTSDS) has been designated as a migration system, in accordance with guidance from ASD (C3I) and by the Intelligence Systems Board (ISB). NTSDS provides the DoD signature data community (e.g., ISR and MASINT) signature data from multiple, geographically distributed sites via a unified national system. NTSDS Data Centers employ standard data parameters and formats for stored target signatures for national and DoD customers. The following data standards are mandated for the DoD signature data community when interchanging national target/threat data:
Human-Computer Interface Standards
Introduction
The human-computer interface standards and profiles described in this section facilitate interoperability between C4ISR systems through the use of standardized user interfaces, style guides, and symbology.
Information Security Standards
Introduction
The information security standards and profiles described in this section facilitate interoperability between C4ISR systems through the use of standardized security interfaces for systems that process, transport, model, or exchange information.
Domain-Specific Service Areas
Introduction
The following sections map to service areas that apply to the C4ISR Domain, but not to the JTA Core. The standards, profiles, and practices identified are applicable only in the context of these service areas.
Payload-Platform Interface
Introduction
The interface standards identified in this section address interoperability requirements for the integration of a C4ISR payload (e.g., sensor package, communications relay) into a manned or unmanned aerospace platform. It is recognized that vehicle interface characteristics are often driven by the requirements of legacy technologies or other onboard systems. In these cases, the JTA rule set described in See Overview of the Department of Defense Joint Technical Architecture of the JTA Core, and as interpreted by individual Service/Agency JTA Implementation Plans, should be used to determine mandate applicability.
Mandated Standards
The following sections identify the mandatory standards, profiles, and practices for the integration of a C4ISR payload into a manned or unmanned aerospace platform. It should be noted that the standards in this section apply to the platform only to the extent to which they directly affect the interoperability of onboard C4ISR systems.
At the present time, these mandates apply only to airborne reconnaissance systems.
Internal Communications
Internal communications provide information transfer capabilities between the platform and the onboard C4ISR systems, subsystems, and components. This section identifies the standards necessary to facilitate interoperability within and between these entities.
Fibre Channel
Fibre Channel is an efficient, high-speed, serial data communication technology for use in many environments including near-real-time high-speed data transfer, and local/campus networking environments. The Fibre Channel Physical and Signaling standards pertain to first three layers of the Fibre Channel stack (FC0, FC1, and FC2). FC0 addresses the physical media, FC1 discusses the data-encoding scheme, and FC2 addresses the framing protocol and flow control. The media chosen for Fibre Channel can accommodate speeds of 133, 266, and 531 Mbps and 1.06, 2.12, and 4.25 Gbps. The following standard is mandated for network communications internal to airborne reconnaissance platforms where Fibre Channel is used:
FireWire
FireWire describes a serial bus that provides the same services as modern IEEE-standard parallel buses. It has a 64-bit address space, control registers, and a read/write/lock operations set that conforms to IEEE Std 1212-1991, Command and Status Register (CSR). The following standard is mandated for serial bus communications internal to airborne reconnaissance platforms where FireWire is used:
Vehicle/Sensor Telemetry
Commands to various SIGINT, IMINT, and MASINT front-end equipment flow through airborne telemetry systems to onboard LANs. Sensor commands and acknowledgments may include position changes, mode changes, fault isolation commands, and others. The following telemetry standard is mandated for airborne reconnaissance systems:
Telemetry Group, Range Commanders Council, Telemetry Standards , IRIG 106-96, Secretariat, Range Commanders Council, U.S. Army White Sands Missile Range, New Mexico, Chapter 4, Pulse Coded Modulation Standards, Chapter 8 - MIL-STD-1553 Department of Defense Interface Standard for Digital Time Division Command/Response Multiplex Data Bus, 21 March 1996.
Mission Recorder
Mission recorders are used to capture the raw, pre-processed sensor data together with associated navigation, timing, and ancillary data. Additionally, a computer-controlled interface for basic recorder functions such as start, stop, shuttle, fast-forward, and rewind is included.
In conjunction with recording the raw sensor data, timing data will be recorded (on a separate track) in accordance with the standards defined below. The DCRSi 240 rack mount and modular ruggedized systems are one inch, transverse scan, rotary digital recorders capable of recording and reproducing at any user data rate from 0 to 30 Mbytes/s (0-240 Mbps). Specific compatibility information on the DCRSi 240 recorder can be found in the published AMPEX Digital Instrumentation Recorder DCRSi 240 User Manual. The ANSI digital recording standard, providing data compatibility and tape interchangeability, is provided by the X3.175 series. The Instrumentation Group IRIG-B standard was written specifically for analog magnetic tape storage. In conjunction with the migration to all digital systems, mission-recorder standards will be re-evaluated to emphasize digital and de-emphasize analog.
C4ISR.CRY: Cryptologic Subdomain
Subdomain Overview
The Cryptologic Subdomain supports the objectives that provide the framework for meeting the Cryptologic community's requirements.3 First, the Cryptologic Subdomain provides the foundation for interoperability and the seamless flow of information between and among all cryptologic systems and the associated service components in a collaborative and secure environment. Second, it establishes the minimum set of standards and technical guidelines for development and acquisition of new, upgraded, and demonstration systems necessary to achieve interoperability as well as reductions in costs and fielding times. Finally, it promotes interoperability with other components of the Intelligence Community (IC).
Purpose
The Cryptologic Subdomain mandates the minimum set of standards and guidelines for cryptologic systems and subsystems. This includes National and Tactical Cryptologic systems and subsystems. The provides the technical foundation for migrating United States Cryptologic System (USCS) systems toward a common Unified Cryptologic System architecture as directed by the Director, NSA (DIRNSA) and the Director, Central Intelligence (DCI).
Background
Faced with the challenges of keeping pace with changing intelligence requirements, budgetary uncertainty, and technological revolutions, the Director, National Security Agency, under the auspices of the Deputy Secretary of Defense and the Director, Central Intelligence, commissioned the Unified Cryptologic Architecture (UCA) study. The primary goal of the UCA study was to provide an architecture that would ensure an interoperable and secure USCS by 2010. The result of this study was the introduction of the UCA Operational, Systems, and Technical Architectures. The UCA Technical Architecture (UCA-TA) is complementary to the JTA and will be used in conjunction with the JTA Core and the JTA C4ISR Domain by all members of the Cryptologic community.
Subdomain Description
The Cryptologic Subdomain mandates standards for the Cryptologic community. The objective is to facilitate the exchange and exploitation of cryptologic data across the IC and the Department of Defense (DoD).
Scope
The scope of this includes the service areas of the JTA Core and C4ISR Domain, (Information Processing, Information Transfer, Information Modeling, Metadata and Information Exchange, human-computer Interface and Information Security Standards). This also addresses additional areas unique to the Cryptologic community including Special-Purpose Devices, backplanes, and circuit cards.
Applicability
This subdomain applies to all National and Tactical cryptologic systems, subsystems, and demonstration systems. It applies to all new acquisitions and upgrades to existing systems and subsystems that perform SIGINT and/or SIGINT-related activities. A cryptologic system is defined as any system within DoD that collects, processes, and/or manages SIGINT.
Subdomain Organization
The subdomain is divided into three sections. Section 1 contains the overview. This section defines the purpose and scope of the annex and provides background information. Section 2 contains standards for the Cryptologic community that are in addition to the standards in the JTA Core and the C4ISR domain service areas. Section 3 contains services and interfaces unique to the Cryptologic community.
Standards in Addition to the JTA Core and C4ISR Domain
Introduction
This part of the Cryptologic Subdomain establishes the minimum set of rules governing the information technology for cryptologic systems. The scope includes standards for information processing; information transfer; information modeling, metadata, and information exchange; information security; and human-computer interface.
Information Processing Standards
Information Transfer Standards
Information Modeling, Metadata, and Information Exchange Standards
Human-Computer Interface Standards
Subdomain-Specific Services and Interfaces
Introduction
Some cryptologic processing is performed using special-purpose devices (SPDs) that may be embedded within larger host systems or remotely located devices. Cryptologic systems encompass both real-time and non-real-time SPDs. The communications processing, signal processing, and mathematical analysis are performed in real-time by embedded systems that require speeds at least three orders of magnitude higher than traditional C4I systems. Real-time systems also require deterministic scheduling and robust fault tolerance.
Mandated Standards
Small-Scale Special-Purpose Devices
A Small-Scale Special-Purpose Device (SPD) consists of one or more special-purpose boards (may be Government-developed) hosted by a DII COE-compliant computer. These boards use Application Specific Integrated Circuits (ASICs) and Programmable Logic Devices (PLDs) typically designed and developed for the cryptologic community.
Cryptologic systems using PCI cards shall comply with the following mandated standard:
Cryptologic systems using PCMCIA cards shall comply with the following mandated standard:
Backplanes and Circuit Cards
To keep pace with a dynamic threat environment, Cryptologic systems often require the ability to quickly insert new technology. Standards for backplanes and circuit cards facilitate interoperability and modernization and can provide a "plug and play" capability.
Cryptologic systems using VME backplanes and circuit cards shall comply with the following mandated standard:
Cryptologic systems using VXI backplanes and circuit cards shall comply with the following mandated standard:
C4ISR.NCC: Nuclear Command and Control Subdomain
Subdomain Overview
Purpose
The Nuclear Command and Control (NCC) Subdomain identifies elements (i.e., standards, interfaces, and service areas) specific to the functional areas of nuclear command and control that are additions to those standards listed in the JTA Core and in the C4ISR Domain. These additions support the functional requirements of nuclear command and control (C 2 ) systems.
Background
This NCC Subdomain to the Joint Technical Architecture (JTA) has been developed to provide standards for programs being developed or maintained by USAF/AFMC/ESC/ND.
Subdomain Description
The NCC Subdomain to the JTA mandates the minimum set of standards and guidelines for nuclear C 2 systems.
Scope and Applicability
This part of the C4ISR Domain establishes the minimum set of rules governing information technology within nuclear command and control systems. The scope includes standards for information processing; information transfer; information modeling, metadata, and information exchange; human-computer interface; and information security.
The Nuclear Command and Control Subdomain constitutes only a part of the larger command and control part of C4ISR. As such, this subdomain does not cover technical architecture details for any part of the C4ISR spectrum other than the nuclear C 2 portion. Nuclear C 2 can use a variety of strategic and tactical C 2 systems, but the standards listed in this subdomain apply to these systems when used for nuclear C 2 missions. This annex covers nuclear C 2 from the JCS and nuclear CINC down to the last human in the loop prior to the nuclear weapon. The scope of this subdomain excludes the following:
The JTA mandates the minimum set of standards and guidelines for the acquisition of all DoD systems that produce, use, or exchange information. The main body of the JTA (the "Core") provides the standards that are applicable across the entire DoD information technology spectrum. If a service area in the Core applies to an NCC system being developed, and there is no corresponding service area in the C4ISR Domain, then the standard(s) listed in a Core service area apply. The mandates found in the C4ISR Domain are intended to augment those found in the Core. If additional service area standards are found in the C4ISR Domain, the developer must select the service area standards from both the Core and the C4ISR Domain. Similarly, the NCC Subdomain is intended to augment the C4ISR Domain. Applicable service area mandates found in the NCC Subdomain must be used in addition to the service area mandates found in the C4ISR Domain and the Core. When multiple mandates are required in this process, the mandate selection offering the best technical and business solution is the preferred decision.
The NCC Subdomain may list multiple standards for individual service areas. Similarly, the Core and the subdomain may offer multiple solutions within a single service area. For these cases, it is not required that the developer implement all standards listed. A subset should be selected based on technical merit and design/cost constraints. Future versions of this subdomain will have detailed information on standards implementation and standards profiles. The intent, as previously stated, is to promote a minimum set of standards for interoperability among NCC systems.
Technical Reference Model
This subdomain uses the DoD Technical Reference Model cited in See DoD Technical Reference Model of the JTA as its framework.
Subdomain Organization
The organization of this subdomain is intended to mirror the organization of the C4ISR Domain to the greatest extent possible. Each section of the subdomain, except for Part 1 (Overview), is divided into three subsections as follows. The first subsection, Introduction, is for information only. It defines the purpose and scope of the subsection and provides background descriptions and definitions unique to the section. The second subsection contains additional mandated standards for the identified service area. The third subsection, Emerging Standards, provides an abbreviated description of candidates that are expected to move into the mandated subsection within a short period. As defined within the JTA Core, this transition should occur within three years of publication of the standard in the emerging subsection.
C4ISR Application Platform Entity service areas are addressed in Section C4ISR.NCC.2 as additions to the JTA Core and C4ISR Domain. Additional application software entity service areas required to support NCC subdomain systems will be addressed in Section C4ISR.3, Domain-Specific Service Areas.
Additions to C4ISR Domain Service Areas
Introduction
This section provides standards available to this subdomain in addition to those listed in the JTA Core and C4ISR Domain.
Information Processing Standards
Information Transfer Standards
Introduction
Proper handling of NCC information is vital to national security. Information transfer standards and profiles described in this section cover dissemination and data link mandates for NCC systems. This section identifies systems and the interface standards required for interoperability between and among NCC systems and are in addition to the systems described in the JTA Core and the C4ISR Domain.
Mandated Standards
Additional mandated standards for information transfer for the NCC Subdomain are provided in this section.
For radio subsystems operating in the LF/VLF frequency bands, the following standards specify the special modes used by Air Force and Navy forces in support of the USSTRATCOM mission.
For sending and receiving High Data Rate (HIDAR)-mode communications the following standard is mandated:
For sending and receiving Minimum Essential Emergency Communications Network (MEECN) Message-Processing Mode (MMPM) communications the following standard is mandated:
Information Modeling, Metadata, and Information Exchange Standards
Introduction
This section identifies standards applicable to information modeling and exchange of information for NCC systems. Information Modeling, Metadata, and Information Exchange Standards pertain to activity models, data models, data definitions, and information exchange among NCC systems.
human-computer Interface Standards
Introduction
This subsection identifies the mandatory standards, profiles, and practices for human-computer interfaces within the NCC subdomain. The human-computer interface (HCI) is an extremely important NCC function.
Mandated Standards
This section will provide standards that uniquely apply to the HCI of NCC systems.
Information Security Standards
Introduction
Information security standards protect information and the processing platform resources. They must often be combined with security procedures, which are beyond the scope of the information technology service areas, to fully meet operational security requirements. Security services include security policy, accountability, assurance, user authentication, access control, data integrity and confidentiality, non-repudiation, and system availability control.
C4ISR.SR: Space Reconnaissance Subdomain
Subdomain Overview
Purpose
The Space Reconnaissance (SR) Subdomain (SRS) to the C4ISR Domain identifies the minimum set of technical supporting interfaces between SR information technology (IT) systems and other Department of Defense (DoD) systems. The IT definition used within the SRS is found in JTA See .The standards contained here are mandated for SR IT interfaces in addition to those standards found in the C4ISR Domain and in the JTA. The SRS will provide the foundation for the seamless flow of information and interoperability among all future and upgraded SR space and associated ground IT systems, IT technology concept demonstrations, and with related DoD IT systems. Standards used by SR legacy systems to support internal interfaces (i.e., interfaces to non-DoD systems) have not been examined and cannot be presumed to be JTA-compliant.
Background
Space Reconnaissance IT standards represent the communities engaged in all aspects of creating, deploying, and employing space reconnaissance assets for national defense. The standards within JTA (including the SRS) support a range of functions. The SRS supplies a special focus on space-related functions unique within JTA. The SRS identifies additional standards that have been determined to be unique to SR communications and data processing. Standards not unique to SR are contained in the C4ISR Domain or in the JTA Core. The location and application of standards within the JTA Core, C4ISR Domain and SRS are in accordance with the element normalization rules described in See Element Normalization Rules. Future versions of the SRS will address standards not previously identified, or not yet mature (under the JTA rule set), but expected to be developed into SRS-mandated standards. When identified, these standards will be placed in the emerging standards sections in each of the subdomain's service areas.
Subdomain Description
The SRS adds to the standards and guidance required for the Space Reconnaissance Subdomain and is meant to complement both the C4ISR Domain and the JTA Core. The SRS contains information on standards implementation and standards profiles.
The SRS will be maintained by the SRS Working Group chaired by the National Reconnaissance Office (NRO) with all changes made in concert with the normal JTA revision procedures. Modifications to the SRS will be coordinated with the established working group for the SRS.
Scope and Applicability
JTA compliance, where applicable, is required for acquisition of upgraded and new SR IT systems as well as advanced technology demonstrations. The SRS scope comprises SR IT system standards for interfaces external to DoD IT systems. The standards mandated in the JTA Core, C4ISR Domain, and SRS are applicable to the external SR IT interfaces. The SRS includes those pending SRS IT systems whose system specifications and design are intended for near-term acquisition and which include DoD interfaces, where appropriate. The SRS is also applicable where needed for the seamless flow of information and interoperability among SR systems with airborne and other intelligence, surveillance, and reconnaissance systems and is intended to complement their subdomains to the C4ISR Domain.
DoD Technical Reference Model
The DoD Technical Reference Model (TRM) is derived from the original Technical Architecture Framework for Information Management (TAFIM) reference model and Society of Automotive Engineers (SAE) Generic Open Architecture (GOA) model. GOA provides extensions to support real-time computing environments such as those found in weapon systems. The TRM is primarily a software-based model. It was originally developed to cover information technology within DoD. The TRM framework concept can be extended to cover SR external interface with DoD systems. However, domain-specific standards such as those required to cover all national space reconnaissance systems do not fully fit within this software-based model and so work continues as noted below.
SR TRM Defined
Various reference models are being evaluated for SR applicability. In the interim, the SRS uses the DoD Technical Reference Model (TRM) to cover SR system external interfaces with DoD IT systems. Where exceptions to the TRM are required, it will be noted in this subdomain. The DoD TRM is shown in See : DoD Technical Reference Model (DoD TRM) of the JTA.
Subdomain Organization
The organization of this Subdomain follows the JTA-approved format for developing domain and subdomains. The SRS contains three parts. C4ISR.SR.1 is the Overview. C4ISR.SR.2 includes mandatory standard profiles, practices, and emerging standards that are applicable to the SR Subdomain. Emerging standards provide an abbreviated description of candidates expected to move into the mandated subsection within a short period. As defined within the Core of the JTA, this transition should occur within three years of publication of the standard in the emerging subsection. C4ISR.SR.3 is reserved for those mandates that are subdomain-specific because they do not map directly to the JTA Core service areas.
Additions to C4ISR Domain Service Areas and JTA Core
Introduction
The SRS, in conjunction with the JTA Core and the C4ISR Domain, provides the technical foundation for migrating SR IT systems toward a technical architecture that provides interoperable interfaces to DoD systems. This section of the SRS lists the minimum, mandatory set of standards for SR systems. This section includes information processing; information transfer; information modeling, metadata, and information exchange; human-computer interface; and information security standards. This part of the SRS does not contain rules for the physical, mechanical, or electrical components of systems, even when these are related to information technology.
Information Processing Standards
Information Transfer Standards
Introduction
Information transfer standards are used to disseminate National and Tactical intelligence information to Joint service tactical units. This section identifies interface standards required for interoperability between SR IT and other DoD ISR systems in addition to the standards cited in the JTA Core and C4ISR Domain.
Information Modeling, Metadata, and Information Exchange Standards
Human-Computer Interface Standards
CS: Combat Support Domain
Domain Overview
Purpose
The Combat Support (CS) Domain has been developed to integrate agile combat support elements and other domains with a common technical architecture for information exchange. The goals for the Combat Support (CS) Domain are: 1) improve applications interoperability, promote improved business practices, and reduce operations costs within the Combat Support Domain, and 2) improve interoperability and increase combat support information access with C4ISR systems.
Background
There are numerous information technology services that support warfighter activities. These services need to be interoperable with the rest of the DoD community.
Domain Description
The Combat Support Domain addresses those specific elements necessary for the production, use, or exchange of information within and among systems supporting personnel, logistics, and other functions required to maintain operations or combat. The Combat Support domain consists of automated systems that perform combat service support and administrative business functions, such as acquisition, finance, human resources management, legal, logistics, transportation, and medical functions. As illustrated in See : JTA Hierarchy Model, the domain has three subdomains: Automatic Test Systems (CS.ATS), Defense Transportation System (CS.DTS), and Medical (CS.MED).
|
|
Scope and Applicability
The Combat Support Domain identifies standards applicable to DoD Combat Support Elements (e.g., Logistics, EDI, CALS, Medical, Transportation).
Technical Reference Model
This domain uses the Technical Reference Model (TRM) cited in See DoD Technical Reference Model of the JTA as its framework. Combat Support Application Platform Entity service areas are addressed in Section CS.2 as additions to the JTA Core. Additional Application Software Entity service areas required to support Combat Support Domain systems are addressed in Section CS.3 as domain-specific service areas.
Domain Organization
The Combat Support Domain consists of three sections. CS.1 contains the overview, CS.2 contains those information technology mandated and emerging standards that are additions to the standards contained in the Core, and CS.3 is reserved for those mandated and emerging standards for combat support that are domain-specific, not associated with a Core service area.
Additions to JTA Core
Introduction
The Combat Support Domain embraces the principles established in the JTA Core. Only those paragraphs from the Core that have additions are included below.
Information Processing Standards
Mandated Standards
Document Interchange
Continuous Acquisition and Life-Cycle Support (CALS) has developed a set of standards that apply to this service area. CALS Standard Generalized Markup Language (SGML) profiles the standard ISO 8879 by selecting a particular Document Type Definition (DTD) and other parameters that help standardize the development of technical manuals for DoD. CALS also developed a handbook for applying CALS SGML (MIL-HDBK-28001, 30 June 1995). Although Hypertext Markup Language (HTML) is also a subset of SGML, it is not sufficiently robust enough for Technical Manual (TM)/ Technical Order (TO) development. [Extensible Markup Language (XML) may replace both CALS SGML and HTML in the future.] CALS also has a standard for archiving documents (MIL-STD-1840C). The mandated standards for the CALS Document Interchange Service Area are:
Graphics Data Interchange
CALS has developed a metadata standard, MIL-PRF-28003B, which profiles the ISO Computer Graphics Metafile (CGM) standard (ISO 8632). Also, a CALS Raster Standard, MIL-PRF-28002C, puts raster graphics into a binary format. The mandated standards for the CALS Graphics Data Interchange service area are:
ISO/IEC 8632-1:1999 , Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 1: Functional specification, as profiled by MIL-PRF-28003B, Digital Representation for Communication of Illustration Data: CGM Application Profile, 30 April 2000.
ISO/IEC 8632-3:1999 , Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 3: Binary encoding, as profiled by MIL-PRF-28003B, Digital Representation for Communication of Illustration Data: CGM Application Profile, 30 April 2000.
ISO/IEC 8632-4:1999 , Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 4: Clear text encoding, as profiled by MIL-PRF-28003B, Digital Representation for Communication of Illustration Data: CGM Application Profile, 30 April 2000.
Product Data Interchange
Several standards exist for exchanging product data. The ANSI/US PRO/IPO-100-1996 and MIL-PRF-28000B standards define a neutral data format that allows the digital exchange of information between Computer-Aided Design (CAD) and Computer-Aided Manufacturing (CAD/CAM) systems. ANSI/US PRO-100-1996 supports digital design and manufacturing information about an object sufficient to support manufacturing and construction only. MIL-PRF-28000B contains applications subsets and protocols that form profiles of IGES Version 5.3. The following standard is mandated:
A standard for circuit board description in digital form is ANSI/IPC-D-350D. An associated standard for describing hardware product data in an unambiguous way is ANSI/IEEE 1076. Other product data can be stored digitally using MIL-STD-1840C. The following standards are mandated:
Bar code standards are used to identify packages and products. They can be used to help identify products being shipped and stocked. MIL-STD-1189B was canceled, but the notice directed the user to AIM BC-1, a linear bar code standard. (See See Product Data Interchange for two-dimensional standard.) The following standard is mandated:
Electronic Data Interchange
Electronic Data Interchange (EDI) is a new Base Service Area specializing in the computer-to-computer exchange of business information using a public standard. EDI is a central part of Electronic Commerce (EC), the paperless exchange of business information. FIPS PUB 161-2 establishes the Federal EDI Standards Management Coordinating Committee (FESMCC) to harmonize the development of EDI transaction sets and message standards among Federal agencies, and the adoption of Government-wide implementation conventions. The Federally approved Implementation Conventions may be viewed on the Web at <http://snad.ncsl.nist.gov/dartg/edi/fededi.html> .
The DoD EDI Standards Management Committee (EDISMC) was established to coordinate EDI standardization activities within DoD. The EDISMC supports the development, adoption, publication, and configuration management of EDI implementation conventions for DoD. The DoD EDISMC manages the efforts of several Functional Working Groups (FWGs). DoD FWGs have been established in the following areas: Logistics, Finance, Healthcare, Transportation, Procurement, and Communication, Command and Control. EDISMC-approved implementation conventions may be submitted to the FESMCC for approval as Federal implementation conventions. Not all DOD ICs are submitted to the FESMCC for federal approval. For more information, visit the web site at <http://www-edi.itsi.disa.mil> .
FIPS PUB 161-2, 22 May 1996, Electronic Data Interchange (EDI) adopts, with specific conditions, ANSI ASC X12, UN/EDIFACT and ANSI HL7. HL7 can be found in Combat Support Medical Subdomain. The following standards are mandated: