MIL-HDBK-59A APPENDIX D APPENDIX D CONTRACT REQUIREMENTS FOR DELIVERY MODES 171 MIL-HDBK-59A APPENDIX D THIS PAGE INTENTIONALLY LEFT BLANK. 172 MIL-HDBK-59A APPENDIX D 10 SCOPE 10.1 Applicability. This appendix provides guidance to government activities on the use of physical media and telecommunication networks for delivery of technical data in digital form, or digital access to technical information data bases. It is applicable to all Department of Defense (DoD) components which acquire weapon systems and related major equipment items, and their associated technical data. 10.2 Purpose. This appendix is intended to suggest the best methods for defining statement of work (SOW) requirements, and tailoring the wording of DoD Requests for Proposal (RFPs) and | Contract Data Requirement Lists (CDRLs) to allow and encourage | the integrated preparation and submission of, or access to, technical data in digital form. 20 REFERENCED DOCUMENTS See list of references appearing in Appendix A. 30 DEFINITIONS See the list of terms and acronyms appearing in Appendix A. 40 GENERAL GUIDANCE 40.1 Access and delivery of digital data. A major thrust of the Computer-aided Acquisition and Logistic Support (CALS) program is access to, and delivery of, weapon system technical data in digital form. This appendix provides guidance for contracting for the delivery alternatives discussed in Section 5 and Appendix B of this handbook. 173 MIL-HDBK-59A APPENDIX D 50 DETAILED GUIDANCE 50.1 Organization of guidance sections. This appendix is organized into two major sections that address physical media and telecommunications alternatives for data delivery or access. These sections can be used separately or together to contract for technical data in digital form. 50.1.1 Options. The Decision Template for Acquisition of Digital Data reflects two options available for delivery of digital documents and processable data files, together with a single option for interactive access to contractor and | government data bases through CITIS. The technology for both | options has advantages for the user, and limitations on the ability to benefit from those advantages. 50.1.1.1 Physical media. Older types of physical media (i.e., magnetic tape) provide a mature, stable technology in which the user can place great confidence. Unfortunately, this media form is also slow, bulky, and cumbersome. Newer types of physical media (i.e., WORM optical disk and CD-ROM) hold great promise because of their much greater storage capability, but standard data formats are only now beginning to emerge, and interoperability remains a problem. Unlike magnetic tape, where system hardware investment is largely a sunk cost, use of WORM optical disk or CD-ROM may involve substantial investment costs. 50.1.1.2 Telecommunications. Secure, on-line transmission of the full volume of technical data for major weapon systems is technically feasible, but beyond the economical capability of current telecommunication networks in DoD and industry. In the near term, telecommunications will be limited to file transfer | and electronic mail exchange of high priority technical data, | and interactive access where traffic volume is limited to queries, selective review and approval of data, or other clearly defined uses. In the longer term, cost effective and secure telecommunications capability will be essential for successful implementation of the IWSDB. Substantial amounts of government and industry research are underway to provide this capability. CALS is helping to define user requirements in | this area. A CALS Telecommunications Plan is being developed | to provide guidance for the design of telecommunications and | intelligent gateway (IG) architectures for transmitting and | using the vast amounts of data among the many distributed and | heterogeneous data base environments supporting a weapon system | acquisition program. Development and implementation of DoD | telecommunications capability is the responsibility of the | Defense Communications Agency, under the policy guidance of the 174 MIL-HDBK-59A APPENDIX D Assistant Secretary of Defense for Command, Control, Communications, and Intelligence. The National Institute of Standards and Technology can provide additional information on existing and planned commercial and government capabilities. 50.2 Physical media. 50.2.1 Physical media options. Physical media options include magnetic tape, magnetic disk, and several forms of optical media. Magnetic tape is the preferred physical medium for delivery of technical data in digital form because it is a mature, stable technology that is able to handle the large volumes of data typically involved in a major weapon system acquisition. Standards are well defined and usually well implemented, and little investment cost will be involved because almost all contractor source systems and government | destination systems provide magnetic tape read/write hardware. Magnetic disk is also widely implemented on personal computers and work stations, and may be the physical medium of choice for small business contractors. Several primary de facto magnetic disk formats are available, but no official standard has been accepted. Compatibility problems exist, but can be overcome with only moderate effort. Optical media is used here as a generic term to include CD-ROM (compact disk, read only memory), CDI and DVI (compact disk interactive and digital video interactive), WORM (write once and read many times), and erasable optical disk. 50.2.1.1 Magnetic tape. Magnetic tape includes three principal tape densities, only two of which are acceptable for delivery of technical data in digital form. The oldest is 800 characters per inch. Though still in use in many government and industry automated data processing systems, CALS government and industry users have decided that this is essentially obsolete technology, and is no longer an acceptable tape density for the large volumes of technical data that CALS data deliverables will typically encompass (see MIL-STD-1840). Instead, acceptable tape densities are 1600 and 6250 characters per inch, written on 9-track tapes in accordance with the Federal Information Processing Standards listed in MIL-STD- 1840, paragraph 5.2.1. MIL-STD-1840 also includes specific instructions on single and multi-volume tapes, and data file organization. To acquire digital deliverables on magnetic tape, Block 16 of the CDRL (DD Form 1423) should be modified to incorporate the appropriate language from MIL-STD-1840. 50.2.1.2 Magnetic disk. The revolution that has changed 1970's mainframe computing to 1980's distributed, desktop computing has made magnetic disk a viable alternative for 175 MIL-HDBK-59A APPENDIX D interchange of digital technical data. Although most large companies have implemented local area networks (LAN's) to interconnect individual users, magnetic disk (floppy disk and removable hard disk) remains a major medium for moving digital data among personal computers and work stations. For small business, where LAN's are not yet as widely implemented, magnetic disk remains the dominant exchange medium. Magnetic disk may have only a limited role to play in delivery of technical data in digital form to the government, but it may have a major role in exchange of digital data among prime contractors and subcontractors. Most government destination systems are not prepared to receive digital data on magnetic disk, although jury rig solutions are not difficult. Acquisition managers should examine closely the role that magnetic disk could play as a digital delivery medium in specific program applications. 50.2.1.3 Optical media. For simplicity, the term optical media is used in this handbook to encompass several categories of physical media that have distinctly different physical and technical characteristics. Usually these categories are not lumped together, and computer specialists will draw major distinctions between each form. However, with the exception of | MS-DOS PC-based CD-ROM, these forms share one important | characteristic: they are not yet ready for widespread use as a medium for digital delivery of technical data. Four categories are addressed in the following sections. 50.2.1.3.1 CD-ROM. DoD is conducting demonstrations and prototypes of CD-ROM technology for distribution of technical publications and other forms of technical data. CD-ROM disks are produced in a mastering studio, the investment cost of which remains significant. CD-ROM players are approaching the status of "standard option" on personal computers. However, data on a CD-ROM disk cannot be changed. The disk itself cannot be updated, only replaced. CD-ROM should be considered | where multiple copies of data are required . | 50.2.1.3.2 CDI and DVI. This is a very new technology, which combines the capabilities of CD-ROM with video. It is still expensive because it has not yet left the research and development phase, and it has limitations on the amount of information it can communicate. CDI and DVI are competing approaches for providing a standard implementation of this technology. As the technology matures, and its cost declines, CDI will probably find its first application in digital training products. 50.2.1.3.3 WORM. This form of optical disk will be the first 176 MIL-HDBK-59A APPENDIX D to be routinely used for delivery of digital data. It is the basis for DoD's automated engineering data repositories, and is being widely implemented by large contractors. (It is not as widely implemented as CD-ROM among smaller contractors and individual users.) Unlike CD-ROM, WORM optical disks can be updated at the user's work station. However, updating consists of writing a new file and file directory onto the disk. The old data is not replaced, so eventually an optical disk becomes full. To offset this disadvantage, the inability to erase or replace data means that every configuration change is permanently documented. Current technology includes several WORM disk sizes. Twelve inch disks and the newer fourteen inch disks are primarily used for data storage by central repositories, and will be the medium for data delivery in only a few cases where (literally) huge volumes of data are being delivered. Five-and-a-quarter (5 1/4) inch disks will be used by DoD to exchange data between primary and secondary reposi- tories, and will be a storage medium for digital technical data at desktop work stations. Even smaller disk sizes are now appearing. These are the disk sizes that will probably become the primary physical medium for data delivery in the near future. However, the investment cost for optical disk read/write hardware remains a barrier to implementation. Also, standards for physical formatting and logical formatting of optical disks are still being defined. 50.2.1.3.4 Erasable optical disk. This is another new technology, the routine application of which remains several years away. This category of optical disk can be both read and written at the individual work station, just as a magnetic disk is today. DoD and industry will implement this technology in the future, and most probably will eventually make it the principal physical medium for exchange of digital data. However, the technology itself is still emerging; standardization remains several years away. 50.3 Telecommunications. 50.3.1 CALS Telecommunications Plan. A CALS Telecommunications Plan is being developed for DoD. The plan | details an approach to the development of capabilities and | telecommunications services required to support CALS | activities, consistent with the phased DoD migration to Open | Systems Interconnection (OSI) standards. For DoD and industry | to gain the full benefits from the CALS initiative, | accommodating telecommunications services must be put in place. | | | Telecommunication planning for CALS requires three essential | 177 MIL-HDBK-59A APPENDIX D concepts to incorporate effective services: | | ù A CALS telecommunications model; | | ù A uniform approach to managing the interface between | sites and the long-haul network; and | | ù A capacity estimation methodology for inter-site | information flows. | | The telecommunications model for CALS describes the services | site processes required for a successful implementation. CALS | applications require end-to-end processes that necessitate | certain telecommunication services. These services are | described by modeling site configurations and interactions. | | The uniform approach to managing the interface between sites | and the long-haul network is based on the ISO network | management model. The ISO categories of accounting, | configuration, fault, performance, and security management are | combined with user requirements management to complete the | management interface model. By populating each category with | approved procedures, the critical management interface between | the sites and the long-haul network can be standardized. As a | management concept, it is independent of the technology used. | | The capacity estimation approach classifies CALS sites by | readily available information, including the number and | functions of the people involved. The manpower data is used to | determine communication link locations and relative sites. | This straightforward technique permits quick updates as | business procedures evolve under CALS. | 50.3.2 Telecommunication options. In the current environment, the user of telecommunications for either data delivery or access has three options. The government and the contractor must work together to select the option that best fits user requirements and available capabilities, consistent with DoD | policy guidance. | 50.3.2.1 Contractor-specific networks. The first option is use of an existing, oftentimes non-standard network already established by the contractor. The government, in effect, is hanging terminals onto the contractor's system, and becoming another node of the network accessible through CITIS. In this | case, the acquisition manager has the advantage of using an existing investment and a proven data architecture, and the disadvantage of being a captive audience. Nonetheless, this is a highly practical solution to an immediate requirement. 178 MIL-HDBK-59A APPENDIX D Depending on the type of terminal and software used, and the procedures established for system and data protection and integrity (see Appendix E), processable data files can be downloaded onto physical media (e.g., a magnetic disk). The data are then available for additional processing and transformation under the control of the acquisition manager. 50.3.2.2 TCP/IP-based DDN. The second option is providing the contractor with an interface to the Defense Data Network (DDN). Because the DDN is a DoD network, sized to support defense requirements within available funding, the acquisition manager must provide sponsorship for defense contractor nodes, and must satisfy Defense Communications Agency requirements to justify and schedule connection to the network. The DDN is currently based on the Transmission Control Protocol and Internet Protocol (TCP/IP) standards which are widely supported in government and industry with many commercial, off-the-shelf products. However, DoD has committed to accompany industry in the transition to Open System Interconnection (OSI) compatible products, implemented through new standards such as the Government OSI Profile (GOSIP). 50.3.2.3 OSI compatibility. The third option for telecommunications is OSI compatibility, the telecommunications technology that industry as well as government is moving | rapidly to implement. FIPS Standard Number 146 (FIPS 146) | adopts the Government Open Systems Interconnection Profile | (GOSIP) Version 1 for government use. GOSIP defines a common | set of data communications protocols which enable computer | systems developed by different vendors to interoperate and | exchange data. GOSIP version 1.0 includes requisite information | for acquisition of the OSI FTAM (File Transfer and Access | Management) and VT (Virtual Terminal) applications as well as | the various lower layers of protocol to support them. This | suite of protocols include the most popular physical media | including token ring, broadband, and Ethernet. | | Support for FDDI (Fiber Distributed Data Interface), RDA | (Remote Data base Access), TP (Transaction Processing), X.500 | (directory or 'name' services), and X.400 (electronic mail), as | well as MHS (Message Handling System), are likely to be | included in future networks. | | OSI, and specifically GOSIP, should be the sole, mandatory, | interoperable protocol suite for new procurements involving new | AISs (automated information systems) or major upgrades to | existing AISs including network services. Other protocols may | be procured in addition to GOSIP where operational needs | require backward compatibility. | 179 MIL-HDBK-59A APPENDIX D 50.3.3 DDN compatibility. The DDN was developed in the 1960's to satisfy DoD telecommunication requirements. DoD helped pioneer this technology. Like most pioneers, DoD implemented systems from which later computer and telecommunication experts learned the improvements that would be needed to make widespread, standardized telecommunications technology more effective and more efficient. DoD will transition to the new OSI-compatible technology, but the legacy investment in TCP/IP- based technology means that this will not happen overnight. Each DoD component has developed specific implementing technical language to accommodate its network-specific needs within a common DDN architecture. The following sections summarize (and generalize) that component-specific language. This information is not intended to substitute for component- specific technical requirements, but rather is intended to inform the acquisition manager of the general framework of capabilities that should be required. These generic requirements are for the current TCP/IP-based DDN only, and do not include requirements for migration to the OSI standards. They include DDN protocols up to and including the file transfer protocol, simple mail transfer protocol, internet control message protocol, and TELNET. They do not address environmental considerations, performance requirements, training manuals, maintenance/warranty provisions, special security, installation, or network control. 50.3.3.1 Interface with the DDN. The contractor should provide the appropriate number of DDN interfaces for each host, node, or LAN. Long-haul or packet-oriented LAN communications capability will be provided by the DDN. The contractor should supply all required hardware, software, and accessory equipment necessary to achieve DDN operability for the proposed system. Each DDN interface node or host within the proposed configuration will be connected by the contractor to a DDN access circuit, which will be extended by the government to the site wherein the proposed system is installed. The contractor should provide the necessary cabling between the DDN access circuit terminus and the designated interface node or host. 50.3.3.1.1 Data protection and integrity. All hosts interfaced to DDN should be capable of being certified at an appropriate security level by an agreed upon date. Hardware, software, and procedures should be adequate to prevent misuse or abuse of both the system (computers and telecommunications) and data resident in the system (Appendix E). 50.3.3.1.2 Topology. If LAN topology is proposed, a gateway to DDN should serve as the interface device. Neither a LAN nor 180 MIL-HDBK-59A APPENDIX D a gateway is required; only the DDN interface itself is a requirement. Another topology may be proposed. If a LAN is proposed that is packet-oriented, each designated DDN host on a particular LAN should have MIL-STD-1777/1778 installed for intra-LAN information transfer, along with internet control message protocol, MIL-STD-1780/1781/1782. If an Ethernet LAN is proposed, Request For Change 826 should provide address resolution between IP and LAN media access control. The Ethernet LAN will be IEEE 802.3 compliant. 50.3.3.1.3 Gateways. Users need to be able to use a single | query language and data base schema to efficiently access data | in preexisting data bases, their data base management systems | (DBMSs), or their application programs. An Intelligent Gateway | (IG) is a system that facilitates retrieval and analysis of | data from systems using dissimilar hardware and software. An IG | may include communications gateway functions along with the | higher level application programs written to support the | required user interfaces. IGs handle transparent log-ons, | translate user-prompted queries into a form that can be read by | data base retrieval programs, and in some cases, provide | downloading and post-processing of the retrieved information. | All IGs have the same purpose: to make the complexities of on- | line searching transparent to users. | If a DDN LAN gateway is proposed, the contractor should provide the hardware and software necessary to serve as a DDN gateway between the proposed system and the DDN, and should interface the gateway to both the proposed system and the DDN packet switching node. The gateway should be implemented in contractor-provided equipment independent of the proposed system. The contractor should supply all appropriate gateway protocols to allow full communication between hosts and terminals on the proposed system and those on the DDN. The proposed system interfaces should provide transparent internetwork addressing and complete functional interconnectivity to the user. The gateway should be connected to the LAN, should support a minimum of 256 logical connections simultaneously, and should implement the channel access protocol for interfacing the gateway with the LAN. Hardware and software used to connect the gateway to the LAN should be provided. The connection to the LAN should support the minimum data transfer rate specified for the full-duplex gateway to DDN packet switching node interface. 50.3.3.1.4 Interfaces. The data link and network interface should comply with the DDN X.25 host interface specification. The physical interface should also comply with EIA RS-449, and should be capable of transmitting and receiving binary data at 181 MIL-HDBK-59A APPENDIX D all of the following discrete data transmission rates: 4800, 9600, 19200, 50000, and 56000 bits per second. The electrical interface should comply with EIA RS-422-A and MIL-STD-188-114. The DDN exterior gateway protocol and all internet protocol (MIL-STD-1777 and supporting Defense Communications Agency interpretations) should be implemented in the gateway. The IP software should be able to automatically operate with receiving IP's that have not implemented identical IP options. Internet control messages should conform to the requirements of the internet control message protocol, and should be capable of receiving all message protocol message types. 50.3.3.2 DDN protocols. The contractor should provide the necessary protocol support to achieve the specified level of service interface with DDN. The network, TCP, and IP (as appropriate) protocols must be accessible by the user from higher layer services and user-developed code via service access protocols within each respective protocol in order to permit localized adaptations to the interface. Specific software procedures required to use the services of applicable protocols should be documented and made available to the government. 50.3.3.2.1 Transport service. For transport service, all TCP options specified in MIL-STD-1778 should be implemented, and all TCP systems parameters should be settable. The TCP software should be able to automatically operate with a receiving TCP that has not implemented identical TCP options. 50.3.3.2.2 Application level protocols. Terminal-to-host service should conform to MIL-STD-1782, including DoD-approved | TELNET options. Functions available to locally connected users | should also be available selectively to remote users at all | locations following successful implementation of both system and application sign-on procedures. Some application functions may not have specific sign-on procedures. File transfer service should conform to MIL-STD-1780. At a minimum, ASCII and image data representations should be accepted. Electronic mail service should conform to MIL-STD-1781. In addition, an end-user mail handler that utilizes the facilities of simple mail transfer protocol and the local file system should be provided, and should establish and maintain user mailboxes as required, and support appropriate mail host administrator functions. The end-user mail handler should automatically send or receive mail via MIL-STD-1781 ports, with logical-to-network address translation. 50.3.3.3 Host-to-host front-end protocol interface (network and data link and physical layers). The physical interface 182 MIL-HDBK-59A APPENDIX D should conform to EIA RS-449 and MIL-STD-118-114. The interface should be capable of transmitting and receiving binary data at one or more of the following discrete data transmission rates: 4800, 9600, 19200, 50000, 56000, and 64000 bits per second. Data link, network interfaces, and service access for host-to-host front-end protocol communication should conform to the DDN host front-end protocol and service access protocols. The host front-end protocol link should conform to FED-STD-1041 (FIPS PUB 100-1). Two way simultaneous operation should be supported. 50.3.3.4 Subscriber interface. These requirements apply only to systems requiring Defense Communications Agency-approved interfaces. Government users who need unique, custom-designed DDN connections should define the specific characteristics of that interface following the DDN layered hierarchy description. Examples of Standard DDN Protocols Physical RS-449, RS-232-C Data Link High-level data link control Network DDN X.25 (Standard) Transport TCP/IP Session Local Presentation (and) TELNET Application File Transfer Protocol, Simple Mail Transfer Protocol, Native Mode, Special User Applications as Required 50.3.3.5 System-specific modification. The protocols listed above are examples of a DDN standard configuration. Where special needs exist, they should complement, not replace, the basic DDN protocol structure. The system definition may require modification based on the unique needs of each acquisition, but the overall layered protocols used by DDN will be intact. Special, non-approved vendor protocols cannot substitute for listed DDN protocols. They must exist, if needed, outside the DDN domain. 50.3.4 OSI compatibility. The future standard for | telecommunications media access and delivery are protocols that provide Open System Interconnection (OSI) compatibility. OSI protocols have been developed by international standards organizations, primarily the International Organization for Standardization (ISO) and the Consultative Committee on International Telephone and Telegraph (CCITT). To provide OSI compatible networking capability for government users, a government OSI profile (GOSIP) Version 1 has been published as 183 MIL-HDBK-59A APPENDIX D a federal information processing standard. GOSIP defines the initial suite of protocols through which DoD and other government agencies will transition from current heterogeneous telecommunication systems to an OSI architecture. 50.3.4.1 Origin of GOSIP. GOSIP defines a common set of OSI data communication protocols which enable systems developed by different vendors to interoperate and enable the users of different applications on these systems to exchange information via communication links. GOSIP is based on agreements reached | by vendors and users of computer networks participating in the National Institute of Standards and Technology's Workshop for Implementors of Open System Interconnection. To provide completeness, GOSIP is augmented with material from international standards and documents progressing toward international standard status. 50.3.4.2 General application. The GOSIP (FIPS 146) is effective as of February 25, 1989. For a period of eighteen months thereafter, until application of GOSIP becomes compulsory and binding, agencies are permitted to acquire alternative protocols that provide equivalent functionality. However, agencies are encouraged to use the standard for solicitation and contracts for new network products and services to be acquired after the effective date. For the indefinite future, agencies will be permitted to buy network products in addition to those specified by GOSIP and its successor documents. This includes other non-proprietary protocols, proprietary protocols, and OSI features and options not yet included in GOSIP. 50.3.4.3 DoD application. Waivers to FIPS may be granted under certain exceptional circumstances. However, DoD policy on the use of GOSIP was established even before the GOSIP FIPS was published. GOSIP was adopted in 1987 as an experimental co-standard to the TCP/IP protocols that provide similar services within the current structure of the Defense Data Network. GOSIP could be specified in addition to, in lieu of, or as an optional alternative to the DDN protocol standards. Now that the GOSIP FIPS has been formally published, it is a full DoD co-standard, and after the established transition period will become the sole mandatory interoperable protocol suite. However, a capability for interoperation with the DDN protocols has been provided to ensure that existing systems can continue to function fully and effectively. 50.3.4.4 Industry compatibility. GOSIP is consistent with, and complementary to, industry's manufacturing automation 184 MIL-HDBK-59A APPENDIX D protocol (MAP) and technical and office protocol (TOP). MAP/TOP addresses a broader range of functionality, and defines more advanced technology as a way to establish guidelines for future commercial product development. 50.3.4.5 GOSIP implementation and extension. GOSIP addresses the need of the federal government to move immediately to multi-vendor interconnectivity without sacrificing essential functionality already implemented in critical networking systems. All capabilities specified in GOSIP exist as standard products or are close enough to market that they can be proposed by vendors. OSI protocols providing additional functionality will be added to GOSIP as implementation specifications for those protocols are developed by the OSI Implementors Workshop. For each incremental extension to GOSIP, an eighteen month transition period will be applicable. Appendices to the GOSIP specification describe advanced requirements for which adequate profiles have not yet been developed. 50.3.4.6 GOSIP functionality. Currently, GOSIP addresses file transfer, access, and management (access and movement of information files among network users), and message handling systems (electronic mail or messaging between network users). GOSIP provides enough functionality to be generally useful for all government computer networking needs. If additional functionality is required to meet CALS technical data interchange and access needs, it can also be specified by the acquisition manager. 50.3.4.7 Contracting for OSI delivery. To require OSI/GOSIP compatibility as a delivery or access mode, FIPS PUB 146 should be cited. The GOSIP architecture supports a range of protocol choices at different protocol layers. A subset of these protocols may adequately satisfy an individual program requirement. If a subset of the GOSIP protocols and service interface profiles are chosen, it is the acquisition manager's responsibility to ensure that all paths through the architecture are complete. 50.4 Transition to or Implementation of CALS GOSIP Protocols. | This section provides information for the DoD program | acquisition manager related to the implementation and | transition to the Government Open System Interconnection | Profile (GOSIP) protocols. Even though presently available | network bandwidth will not generally support the requirement to | transfer full CALS conforming deliverables (which could amount | to many megabytes of data), networks should not be ruled out as | cost-effective tools to be used during the preparation and | 185 MIL-HDBK-59A APPENDIX D review phases. GOSIP, based on the International Standards | Organization (ISO) Open System Interconnection (OSI) reference | model, has been designated Federal Information Processing | Standard (FIPS) 146. It took effect as a Federal standard in | February 1989. The standard is optional until August 1990 | after which it will be mandatory for newly acquired Federal ADP | and communications systems. | | For administrative and technical information for implementing | or transitioning to GOSIP the reader should refer to the CALS | Program Acquisition Manager's Guideline for Implementing CALS | Communication. The report provides detailed guidance for | implementing GOSIP networks with a description of types of | CALS/GOSIP conforming network components and the range of | possible network topologies. The report also provides | additional information on the CALS Building Blocks, or | groupings of elements of the CALS standards, which provides a | means to determine whether a product is conforming to the | specifications. Both current and future specifications defined | by GOSIP are addressed as well as gateways to connect to TCP/IP | networks. The report includes summary of Dod-to-OSI protocol | migration/transition considerations as outlined in The | Department of Defense Open System Interconnection (OSI) | Implementation Strategy report developed by the Defense | Communication Agency. | | 50.4.1 Relationship of CALS/MAP/TOP/GOSIP. CALS is consistent | and will interwork with systems that are MAP/TOP and GOSIP | conformant. GOSIP specifies the more stable subset of the TOP | specification building blocks with extensions for government | use. MAP and TOP have always has it as their charter to | interwork. Figure 10 illustrates the scope of each program. | TOP addresses interchange formats and the network utilities | required to correctly transfer the data. GOSIP addresses the | same network utilities, while CALS primarily focuses upon data | compatibility relying on GOSIP for the communications | utilities. All three programs/specifications are based upon | the same international standards and testing. | | 50.4.2 Telecommunications Considerations. The decision to | transition a network currently supported by TCP/IP to one that | conforms to the GOSIP standard, must be done with consideration | of: | | ù Availability of necessary functionality under GOSIP | | ù Requirement for interoperability with other networks | 186 MIL-HDBK-59A APPENDIX D FIGURE 10. CALS/MAP/TOP/GOSIP Relationship | | ù Current and planned investment in hardware, software, | and user training | | ù Stability and support needed in the new environment | | The TCP/IP protocols, along with certain applications that are | written to run in the environment, provide services to users | that may be a mandatory part of their operations. Before a | transition to the newer GOSIP environment can occur, the system | manager must evaluate the corresponding services to be sure | that those that are necessary are available. | | Some elements of Open System essential to the configuration, | operation, and management of complex networks are still being | developed. The most prominent of these protocols are | management, security, internetwork routing, and application | support beyond file transfer and messaging. The CALS | telecommunications requirements employ GOSIP to provide the | basic communications protocols. An interim solution is needed | to provide for the above noted elements until the base | standards, functional specifications, and test systems are | completed, and until they appear in full releases of GOSIP as | stable protocols. | | There are a number of possible alternatives that yield short | term solutions. The recommended alternative is to empty the | 187 MIL-HDBK-59A APPENDIX D proprietary protocols in conjunction with requiring a clear and | feasible migration plan. For example, some recently announced | OSI (GOSIP-compatible) products allow their OSI objects to be | managed by the vendor's proprietary systems. This approach | provides as a more seamless transition to the later OSI | protocols as these functions are missing from the existing DoD | protocols. | | Existing manufacturers' solutions for network management, for | example, provide a platform of functions upon which the | manufacturers should be required to incorporate OSI specific | functions as the mature. The program manager should require a | migration from proprietary protocols and conformance and | adherence to FIPS 146 and the appropriate MIL SPECs as the | standard are defined and products become available. | | 50.4.3 Specification. The CALS Building Blocks group elements | of the CALS standards into functional units that are assured of | interoperability with each other, when chosen according to the | building block binding rules. The CALS Building Blocks are | depicted in Figure 11. The building blocks benefit both | vendors and users -- a user can express needs in terms of | functionality, and vendors can build products that supply the | functionality defined to CALS specifications. The | specification building block is a tool intended to provide | basic choices without jeopardizing interoperability. | | A CALS Building Block is described by its name and three | attributes: | | ù Function - What an implementation based on the | building block will accomplish for the user in a CALS | environment. | | ù Standards Reference - The specific standards to | reference together with the required set of selected | options and parameters. | | ù Binding Rules - The technical constraints the define | the associations of the building block with other | building blocks in forming valid CALS contributions. | | A CALS environment will include: one or more GOSIP or TCP/IP | building blocks covering Layers 1, 2, 2 and 4; and at least one | corresponding building block covering Layer 5, 6 and 7. | Selections from the gateways, interchange formats and | 188 MIL-HDBK-59A APPENDIX D FIGURE 11. CALS Lower Layer Telecommunications Building Blocks | FIPS 146 (GOSIP) Version 1 | | application interface building blocks are optional. For | example, the specification of a particular CALS End System may | consist of the CALS/GOSIP CSMA/CD Subnetwork Access Building | Block (802.3), the CALS/GOSIP Remote File Access Building Block | and the CALS Computer Graphics Metafile Interchange Format | (CGMIF) Building Block. | | CALS Building Blocks relate to the specification for the | interconnection of open systems and do not imply that actual | implementations or products should be structured within a | system according to the boundaries of the CALS Building Blocks. | In particular, the software or hardware elements implemented in | a given system according to the CALS Building Blocks are not | required to be (nor prevented from being) interchangeable with | functionally equivalent elements from other vendors. More | complete information on the functionality of the Building | 189 MIL-HDBK-59A APPENDIX D Blocks and relationships is provided in the Program Acquisition | Manger's Guidelines for Implementing CALS Communications. | 50.4.3.1 CALS/GOSIP Version 1 Specification. | | 50.4.3.1.1 CALS/GOSIP Version 1 Lower Layer Protocol | Specification. The CALS/GOSIP Version 1 lower layer building | blocks specify four available OSI lower layer protocols. They | provide the functions necessary for a reliable use of specific | subnetworks by End Systems. The specifications of one or more | of these building blocks for CALS/GOSIP End System is | mandatory. These building blocks are based upon the GOSIP FIPS | Version 1. | | ù CALS/GOSIP CSMA/CD Subnetwork Access End System | Building Block | | ù CALS/GOSIP Version 1 Token-Passing Ring Subnetwork | Access End System Building Block | | ù CALS/GOSIP Version 1 Token-Passing Bus Subnetwork | Access End System Building Block | | ù CALS/GOSIP Version 1 X.25 Packet-Switching Subnetwork | Access (DDN) End System Building Block | | ù Binding Rules - Shall be bound with at least one of | the following: | | - CALS/GOSIP Remote Terminal Access Building Block | - CALS/GOSIP Remote File Access Building Block | - CALS/GOSIP Electronic Mail Building Block | | ù Standards Reference - FIPS PUB 146. | | 50.4.3.1.2 CALS/GOSIP Version 1 Upper Layer Protocol | Specification. The CALS/GOSIP Version 1 upper layer | telecommunications building blocks specify the transfer of data | and network operations functions. The specifications of one or | more of these building blocks for CALS/GOSIP End System is | mandatory. | | ù CALS/GOSIP Version 1 Electronic Mail Building Block | | ù CALS/GOSIP Version 1 Remote File Access Building | Block | | ù Binding Rules - Shall be bound with at least one of | the following: | 190 MIL-HDBK-59A APPENDIX D - CALS/GOSIP CSMA/CD Subnetwork Access End System | Building Block | | - CALS/GOSIP Token-Passing Ring Subnetwork Access | End System Building Block | | - CALS/GOSIP X.25 Packet-Switching Subnetwork | Access End System Building Block | | - CALS/GOSIP Token-Passing Bus Subnetwork Access | End System Building Block | | May be bound with any of the following: | | - CALS CGMIF (Computer Graphics Metafile | Interchange Format) Building Block | - CALS PDIF (Product Definition Interchange | Format) Building Block | - GOSIP ODIF (Office Document Interchange Format) | Building Block | | ù Standards Reference - FIPS PUB 146 | | 50.4.3.1.3 CALS/GOSIP Version 1 Intermediate System | Telecommunications Specifications. The CALS/GOSIP Intermediate | System telecommunications building blocks provide the functions | necessary to interconnect two or more subnetworks at the | Network Layer and route/relay data. The specification of one | or more of these building blocks for a Intermediate System is | mandatory. This specification is based upon GOSIP Version 1. | | ù CALS/GOSIP Version 1 CSMA/CD Subnetwork Access | Intermediate System Building Blocks | | ù CALS/GOSIP Version 1 Token-Passing Ring Subnetwork | Access Intermediate System Building Block | | ù CALS/GOSIP Version 1 X.25 Packet-Switching Subnetwork | (DDN) Access Intermediate System Building Block | | ù CALS/GOSIP Version 1 Token-Passing Bus Subnetwork | Access Intermediate System Building Block | | ù Binding Rules - Shall be bound with one or more of | the following: | | - GOSIP CSMA/CD Subnetwork Access Intermediate | System Building Block | 191 MIL-HDBK-59A APPENDIX D - GOSIP Token-Passing Ring Subnetwork Access | Intermediate System Building Block | | - X.25 Packet-Switching Subnetwork Access | Intermediate System Building Block | | - GOSIP Token-Passing Bus Subnetwork Access | Intermediate System Building Block | | ù Standards Reference - FIPS PUB 146 | | 50.4.3.2 CALS Data Interchange Formats Specifications. Listed | next are the CALS interchange format building blocks. They | define the structures, data types and encoding for data | interchange. They are intended to be used in conjunction with | the Remote File Access and Electronic Mailing Building Block. | The specifications of these building blocks for CALS End | Systems is optional. | | ù CALS Computer Graphics Metafile Interchange Format | Building Block | | - Standards Reference - MIL-D-28003 | | ù CALS Product Definition Interchange Format Building | Block | | - Standards Reference - MIL-D-28000. | | ù CALS Technical Publications Interchange Format | Building Block | | - Standards Reference - Primary, MIL-D-28000 | Secondary, MIL-STD-1840A | MIL-D-28000 | MIL-D-28003 | MIL-R-28002 | | ù CALS Raster Interchange Format Building Block | | - Standards Reference - MIL-R-28003. | | ù Binding Rules - Shall be bound to one or more of the | following: | | - CALS/GOSIP Remote File Access Building Block | - CALS/GOSIP Electronic Mail Building Block | - TCP/IP Remote Fie Access Building Block | - TCP/IP Electronic Mail Building Block. | 192 MIL-HDBK-59A APPENDIX D 50.4.3.3 CALS/GOSIP Version 2 Specification | | 50.4.3.3.1 CALS/GOSIP Version 2 and Future Lower Layer | Protocol Specifications. The CALS/GOSIP Version 2 and future | lower layer telecommunications building blocks specify OSI | lower layer protocols expected to be included in Version 2 of | the approved FIPS 146. The Version 1 Building Block | functionality introduced may be improved or enhanced. If there | is any incompatibility introduced between Version 1 and 2, new | building blocks will be created. Upon approval of Version 2, | this section will be revised to remove the distinction between | Versions 1 and 2. The specifications of these building blocks | for a CALS environment will be mandatory when Version 2 of the | GOSIP FIPS is approved. Future Building Blocks are provided | only as guidance for implementors and users. Future Building | Blocks will be modified to conform with approved FIPS and MIL | STDs language. | | ù CALS/GOSIP Version 2 CSMA/CD Subnetwork Access End | System Building Block | | ù CALS/GOSIP Version 2 Token-Passing Ring Subnetwork | Access End System Building Block | | ù CALS/GOSIP Version 2 Token-Passing Bus Subnetwork | Access End System Building Block | | ù CALS/GOSIP Version 2 X.25 Packet-Switching Subnetwork | Access (DDN) End System Building Block | | ù Binding Rules - Shall be bound with at least one of | the following: | | - CALS/GOSIP Remote Terminal Access Building Block | - CALS/GOSIP Remote File Access Building Block | - CALS/GOSIP Electronic Mail Building Block. | | ù CALS/GOSIP Fiber Distributed Digital Interface | Subnetwork Access End System Building Block (FUTURE) | | ù CALS/GOSIP Integrated Services Digital Network (ISDN) | B-Channel Packet and Circuit Mode Subnetwork Access | End System Building Block | | ù CALS/GOSIP Integrated Services Digital Network (ISDN) | D-Channel Packet Mode Subnetwork Access End System | Building Block | | 193 MIL-HDBK-59A APPENDIX D ù Binding Rules - Shall be bound with at least one of | the following: | | - CALS/GOSIP Remote Terminal Access Building Block | - CALS/GOSIP Remote File Access Building Block | - CALS/GOSIP Electronic Mail Building Block. | - CALS/GOSIP Directory Services Building Block | - CALS/GOSIP Network Management Building Block. | | ù Standards Reference - FIPS PUB 146 | | 50.4.3.3.2 CALS/GOSIP Version 2 and Future Upper Layer | Protocol Specifications. The CALS/GOSIP Version 2 and Future | upper layer telecommunications building block specify the | transfer of data and network operations functions expected to | be included in Version 2 of the approved FIPS 146. The Version | 1 Building Block functionality may be improved or enhanced. If | there is any incompatibility introduced between Version 1 and | 2, new building blocks will be created. Upon approval of | Version 2, this section will be revised to remove the | distinction between Versions 1 and 2. The specification of | these building blocks for a CALS End System will be mandatory | when Version 2 of the GOSIP FIPS is approved. Future Building | Blocks are provided only as guidance for implementors and | users. Future Building Blocks will be modified to conform with | approved FIPS and MIL STDs language. | | ù CALS/GOSIP Version 2 Electronic Mail Building Block | | ù CALS/GOSIP Version 2 Remote File Access Building | Block | | ù Binding Rules - Shall be bound with one or more of | the following: | | - GOSIP CSMA/CD Subnetwork Access Intermediate | System Building Block | - GOSIP Token-Passing Ring Subnetwork Access | Intermediate System Building Block | - X.25 Packet-Switching Subnetwork Access | Intermediate System Building Block | - GOSIP Token-Passing Bus Subnetwork Access | Intermediate System Building Block. | | ù CALS/GOSIP Version 2 Remote Terminal Access Building | Block | | ù CALS/GOSIP Directory Services Building Block (FUTURE) | 194 MIL-HDBK-59A APPENDIX D ù CALS/GOSIP Network Management Building Block (FUTURE) | | ù Binding Rules - Shall be bound with at least one of | the following: | | - CALS/GOSIP CSMA/CD Subnetwork Access End System | Building Block | - CALS/GOSIP Token-Passing Ring Subnetwork Access | End System Building Block | | - CALS/GOSIP X.25 Packet-Switching Subnetwork | Access End System Building Block | - CALS/GOSIP Token-Passing Bus Subnetwork Access | End System Building Block. | | ù Standards Reference - FIPS PUB 146. | | 50.4.3.3.3 CALS/GOSIP Version 2 and Future Data Interchange | Formats Specifications. Listed next are the CALS/GOSIP | interchange format and Application and Interface building | blocks which are expected in the GOSIP Version 2 FIPS. They | define the structures, data types and encoding for data | interchange. They are intended to be used in conjunction with | the Remote File Access and Electronic Mail Building Blocks. | The specification of these building blocks for CALS End System | is optional. | | ù GOSIP Version 2 Office Document Interchange Format | Building Block | | ù Binding Rules - Shall be bound with at least one of | the following: | | - CALS/GOSIP Remote File Access Building Block | - CALS/GOSIP Electronic Mail Building Block. | | ù Standards Reference - FIPS PUB 146. | | 50.4.3.3.4 GOSIP Version 2 Application Interface Building | Blocks (FUTURE). The GOSIP Application Interface building | blocks deal with application interfaces. The specifications of | these building blocks for a CALS End System is optional. | | ù GOSIP Computer Graphics Application Interface | Building Block | | ù Binding Rules - Shall be bound with the following: | | - CALS CGMIF Building Block | 195 MIL-HDBK-59A APPENDIX D ù Standards Reference - FIPS PUB 146. | | 50.4.3.4 TCP/IP | | 50.4.3.4.1 TCP/IP Lower Layer Specification. The TCP/IP lower | layer building blocks specify the four lower layer protocols. | They provide the functions necessary for a reliable use of the | TCP/IP lower layer building blocks for an End System on a | TSP/IP network is mandatory. | | ù TCP/IP CSMA/CD Subnetwork Access End System Building | Block | | ù TCP/IP X.25 Subnetwork Access End System Building | Block | | ù TCP/IP Token Bus Subnetwork Access End System | Building Block (FUTURE) | | ù TCP/IP Token Ring Subnetwork Access End System | Building Block (FUTURE) | | ù TCP/IP FDDI Subnetwork Access End System Building | Block (FUTURE) | | ù TCP/IP Packet Radio Subnetwork Access End System | Building Block (FUTURE) | | ù TCP/IP BBN 1822 Subnetwork Access End System Building | Block | | ù TCP/IP Packet Satellite Subnetwork Access End System | Building Block (FUTURE) | | ù Binding Rules - Shall be bound with at least one of | the following: | | - TCP/IP Remote Terminal Access Building Block | - TCP/IP Remote File Access Building Block | - TCP/IP Electronic Mail Building Block | | ù Standards Reference - MIL-STD-188-114-A, Physical | Layer. | | 50.4.3.4.2 TCP/IP Upper Layer Specifications. The TCP/IP | upper layer building blocks specify the transfer of data and | network operations functions by utilizing the services provided | by the Subnetwork Access End System Building Blocks. The | specification of one or more of the TCP/IP upper layer building | 196 MIL-HDBK-59A APPENDIX D blocks for a CALS TCP/IP network is mandatory. | | ù TCP/IP Remote Terminal Access Building Block | | - Standards Reference - MIL-STD-1782. | | ù TCP/IP Remote File Access Building Block | | - Standards Reference - MIL-STD-1780. | | ù TCP/IP Electronic Mail Building Block | | - Standards Reference -MIL-STD-1871. | | ù Binding Rules - Shall be bound with at least one of | the following: | | - TCP/IP CSMA/CD Subnetwork Access End System | Building Block | - TCP/IP X.25 Packet-Switching Subnetwork Access | End System Building Block. | | 50.4.3.4.3 TCP/IP Intermediate System Building Block. The | TCP/IP Intermediate System building blocks provide the | functions necessary to interconnect two or more subnetworks at | the Network Layer and route/relay data. The specifications of | one or more of these building blocks for an Intermediate System | on a TCP/IP Subnetwork is mandatory. | | ù TCP/IP CSMA/CD Subnetwork Access Intermediate System | Building Block | | ù TCP/IP X.25 Packet-Switching Subnetwork (DDN) Access | Intermediate System Building Blocks | | ù Binding Rules - Shall be bound with one or more of | the following: | | - X.25 Packet-Switching Subnetwork Access | Intermediate System Building Block | | - TCP/IP CSMA/CD Subnetwork Access Intermediate | System Building Blocks | - TCP/IP BBN 1822 Subnetwork Access Intermediate | System Building Block. | | ù Standards Reference - MIL-STD-188-114-A, Physical | Layer. | 197 MIL-HDBK-59A APPENDIX D 50.4.3.4.4 GOSIP to TCP/IP Gateway Building Blocks. The GOSIP | to TCP/IP gateway building blocks specify the functions and | combination of building blocks which must be present on an End | System to perform proper conversion from OSI to TCP/IP and vice | versa. These shall be used as tools to aid in the transition | from TCP/IP to OSI. | | ù GOSIP to TCP/IP Electronic Mail Gateway Building | Block | | - Standards Reference - MIL-STD-1781. | | ù GOSIP to TCP/IP Remote File Transfer Building Block | | - Standards Reference - MIL-STD-1780, ICST/SNA-86- | 6. | | ù GOSIP to TCP/IP Virtual Terminal Building Block | (FUTURE) | | ù Binding Rules - Shall be bound with at least one of | the following: | | - GOSIP CSMA/CD Subnetwork Access End System | Building Block | - GOSIP Token-Passing Ring Subnetwork Access End | System Building Block | - X.25 Packet-Switching Subnetwork Access End | System Building Block | - GOSIP Token-Passing Bus Subnetwork Access End | System Building Block. | | ù Standards Reference - FIPS PUB 146. | | 50.4.4 CONTRACTUAL LANGUAGE. One of the basic purposes of | MIL-HDBK-59 is to facilitate the procurement of CALS conforming | information products. This appendix contains the necessary | technical detail that allow it to be used as a procurement tool | by users developing procurement instruments (e.g., RFPs). The | Building Blocks are a key concept which is intended to | facilitate the establishment of procurement instruments. | Because of the variety of protocols and subnetwork | technologies available, both vendors and users are faced with | numerous choices when determining the appropriate protocols, | functional units and options necessary to specify a product | that meets the needs of the user and is CALS conforming. The | CALS Building Block provide a means to relate the user's | requirements to the specification of a product able to satisfy | these requirements. | 198 MIL-HDBK-59A APPENDIX D After the decision to implement GOSIP to TCP/IP is made, | three essential aspects of a product's functional requirements | must be satisfied: | | ù The type(s) of subnetwork to which the equipment is | intended to be connected | | ù The type(s) of data transfer services required by the | applications resident on this equipment | | ù The type(s) of interchange formats these applications | will exchange with remote systems. | | As an example, suppose a CALS End System is to be used in | an environment where office documents have to be generated, | stored, retrieved, revised and distributed electronically. | Suppose also that a Service-wide CALS electronic mail system | exists to which the new system is to be connected. These user | requirements can be translated into the following functional | requirements: | | ù Connect to an existing 802.3 LAN | | ù Transfer Electronic Mail messages to other CALS mail | servers | | ù Support applications that need to access remote files | | ù Exchange documents in electronic messages and store | them in remote files. | | The following CALS Building Blocks should be listed in the | procurement instrument to specify these functional | requirements: | | ù CSMA/CD Subnetwork Access End System Building Block | as specified in FIPS 146 | | ù CALS/GOSIP Electronic Mail Building Block as | specified in FIPS 146 | | ù CALS/GOSIP Remote File Access Building Block as | specified in FIPS 146 | | ù CALS Technical Publications Interchange Format | Building Block as specified in FIPS 146. | | The CALS Building Block approach addresses the major | aspects of the functional specifications of CALS products. | 199 MIL-HDBK-59A APPENDIX D Depending on the building blocks required, additional | options/features may have to be specified. | | The specification of a product's functional requirements | must not be confused with the specifications of a product's | configuration requirements. The CALS Building Blocks are not | intended to address the structure/packaging or configuration of | a product (hardware/software interface). As an example, the | functionality of an Intermediate System (IS) is specified by | the selection of the appropriate intermediate system building | blocks. If the purpose of an IS is to connect two or more | 802.3 Subnetworks, a CSMA/CD Subnetwork Access Building Block | must be specified. The selection of the building block | specifies the functions to be performed by this device and the | protocols, functional units and options that are required to | provide this functionality. A procurement instrument for this | IS must also include configuration data that would call for | multiple 802.3 hardware interfaces and the necessary software | drivers to support multiple 802.3 subnetwork attachments. | 200