U. S. Government Open Systems Interconnection Profile (GOSIP) VERSION 2.0 October 1990 TABLE OF CONTENTS LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 PURPOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 EVOLUTION OF THE GOSIP . . . . . . . . . . . . . . . . . . . . . 1 1.4 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 APPLICABILITY . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.6 GOSIP VERSION 2 FUNCTIONALITY . . . . . . . . . . . . . . . . . 2 1.7 GOSIP Version 1 Errata . . . . . . . . . . . . . . . . . . . . . 3 1.8 SOURCES OF PROTOCOL SPECIFICATIONS . . . . . . . . . . . . . . . 3 1.8.1 Primary Source . . . . . . . . . . . . . . . . . . . . . . . 3 1.8.2 Secondary Sources . . . . . . . . . . . . . . . . . . . . . 3 1.8.3 Tertiary Sources . . . . . . . . . . . . . . . . . . . . . . 4 2. TESTING OF GOSIP-COMPLIANT PRODUCTS . . . . . . . . . . . . . . . . . 5 2.1 CONFORMANCE TESTING . . . . . . . . . . . . . . . . . . . . . . 5 2.2 INTEROPERABILITY TESTING . . . . . . . . . . . . . . . . . . . . 5 2.3 PERFORMANCE TESTING . . . . . . . . . . . . . . . . . . . . . . 6 2.4 FUNCTIONAL TESTING . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 VENDOR ENHANCEMENTS . . . . . . . . . . . . . . . . . . . . . . 6 3. DESCRIPTIONS OF ARCHITECTURE AND PROTOCOLS . . . . . . . . . . . . . 7 3.1 ARCHITECTURE DESCRIPTION . . . . . . . . . . . . . . . . . . . . 7 3.2 PROTOCOL DESCRIPTIONS . . . . . . . . . . . . . . . . . . . . . 10 4. PROTOCOL SPECIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 USE OF THE LAYERED PROTOCOL SPECIFICATIONS . . . . . . . . . . . 12 4.1.1 Protocol Selection . . . . . . . . . . . . . . . . . . . . . 12 4.1.2 Service Interface Requirements . . . . . . . . . . . . . . . 12 4.1.3 Performance Requirements . . . . . . . . . . . . . . . . . . 13 4.2 END SYSTEM SPECIFICATION . . . . . . . . . . . . . . . . . . . . 13 4.2.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3 Network Layer Service . . . . . . . . . . . . . . . . . . . 14 4.2.3.1 Connectionless Mode Network Service . . . . . . . . 14 4.2.3.2 Connection-Oriented Network Service . . . . . . . . 14 4.2.3.3 Network Layer Protocol Identification . . . . . . . 15 4.2.3.4 Special Provisions For Integrated Services Digital Networks . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.4 Transport Layer . . . . . . . . . . . . . . . . . . . . . . 16 4.2.4.1 Connection-Oriented Transport Service . . . . . . . 16 i 4.2.4.2 Connectionless Mode Transport Service . . . . . . . 16 4.2.5 Session Layer . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.6 Presentation Layer . . . . . . . . . . . . . . . . . . . . . 17 4.2.7 Application Layer . . . . . . . . . . . . . . . . . . . . . 17 4.2.7.1 Association Control Service Elements . . . . . . . . 17 4.2.7.2 File Transfer, Access, and Management Protocol (FTAM) 17 4.2.7.3 Message Handling Systems . . . . . . . . . . . . . . 17 4.2.7.4 Virtual Terminal (VT) Basic Class . . . . . . . . . 18 4.2.8 Exchange Formats . . . . . . . . . . . . . . . . . . . . . . 18 4.2.8.1 Office Document Architecture (ODA) . . . . . . . . . 18 4.3 INTERMEDIATE SYSTEM SPECIFICATION . . . . . . . . . . . . . . . 19 5. ADDRESSING REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . 20 5.1 NETWORK LAYER ADDRESSING AND ROUTING . . . . . . . . . . . . . . 20 5.1.1 NSAP Address Administration, Routing Structures and NSAP Address Structure . . . . . . . . . . . . . . . . . . . . . . 20 5.1.2 NSAP Address Registration Authorities . . . . . . . . . . . 22 5.1.2.1 Responsibilities Delegated by NIST . . . . . . . . . 22 5.1.3 GOSIP Routing Procedures . . . . . . . . . . . . . . . . . . 23 5.2 UPPER LAYERS ADDRESSING . . . . . . . . . . . . . . . . . . . . 23 5.2.1 Address Structure . . . . . . . . . . . . . . . . . . . . . 23 5.2.2 Address Assignments . . . . . . . . . . . . . . . . . . . . 24 5.2.3 Address Registration . . . . . . . . . . . . . . . . . . . . 24 5.3 IDENTIFYING APPLICATIONS . . . . . . . . . . . . . . . . . . . . 24 5.3.1 FTAM and File Transfer User Interface Identification . . . . 24 5.3.2 MHS and Message User Interface Identification . . . . . . . 24 6. SECURITY OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1 REASON FOR DISCARD PARAMETERS . . . . . . . . . . . . . . . . . 26 6.2 SECURITY PARAMETER FORMAT . . . . . . . . . . . . . . . . . . . 27 6.2.1 Parameter Code . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.2 Parameter Length . . . . . . . . . . . . . . . . . . . . . . 27 6.2.3 Parameter Value . . . . . . . . . . . . . . . . . . . . . . 27 6.2.3.1 Security Format Code . . . . . . . . . . . . . . . . 28 6.2.3.2 Basic Portion . . . . . . . . . . . . . . . . . . . 28 6.2.3.3 Extended Portion . . . . . . . . . . . . . . . . . . 28 6.3 BASIC PORTION OF THE SECURITY OPTION . . . . . . . . . . . . . . 28 6.3.1 Basic Type Indicator . . . . . . . . . . . . . . . . . . . . 28 6.3.2 Length of Basic Information . . . . . . . . . . . . . . . . 29 6.3.3 Basic Information . . . . . . . . . . . . . . . . . . . . . 29 6.3.3.1 Classification Level . . . . . . . . . . . . . . . . 29 6.3.3.2 Protection Authority Flags . . . . . . . . . . . . . 29 6.4 EXTENDED PORTION OF THE SECURITY OPTION . . . . . . . . . . . . 30 6.4.1 Extended Type Indicator . . . . . . . . . . . . . . . . . . 31 6.4.2 Length of Extended Information . . . . . . . . . . . . . . . 31 6.4.3 Extended Information . . . . . . . . . . . . . . . . . . . . 31 6.4.3.1 Additional Security Information Format Code . . . . 32 6.4.3.2 Length of Additional Security Information . . . . . 32 6.4.3.3 Additional Security Information . . . . . . . . . . 32 6.5 USAGE GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . 33 6.5.1 Basic Portion of the Security Option . . . . . . . . . . . . 33 6.5.2 Extended Portion of the Security Option . . . . . . . . . . 33 ii 6.6 OUT-OF-RANGE PROCEDURE . . . . . . . . . . . . . . . . . . . . . 33 6.7 TRUSTED INTERMEDIARY PROCEDURE . . . . . . . . . . . . . . . . . 34 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 iii APPENDICES FOREWORD TO THE APPENDICES . . . . . . . . . . . . . . . . . . . . . . . 41 APPENDIX 1. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 42 APPENDIX 2. SYSTEM AND ARCHITECTURE . . . . . . . . . . . . . . . . . . 46 APPENDIX 3. UPPER LAYERS . . . . . . . . . . . . . . . . . . . . . . . 50 APPENDIX 4. EXCHANGE FORMATS . . . . . . . . . . . . . . . . . . . . . . 56 APPENDIX 5. LOWER LAYER PROTOCOLS . . . . . . . . . . . . . . . . . . . 59 APPENDIX 6. ACRONYMS . . . . . . . . . . . . . . . . . . . . . . . . . . 62 iv LIST OF FIGURES Figure 3.1 GOSIP Version 1 OSI Architecture . . . . . . . . . . . . . . 8 Figure 3.2 GOSIP Version 2 OSI Architecture . . . . . . . . . . . . . . 9 Figure 5.1.1 NSAP Address Structure . . . . . . . . . . . . . . . . . . 20 Figure 5.1.2 The NIST ICD Addressing Domain . . . . . . . . . . . . . . 21 Figure 5.1.3 GOSIP NSAP Address Structure . . . . . . . . . . . . . . . 21 Figure 5.2.1 Upper Layers Address Structure . . . . . . . . . . . . . . 24 Figure A.1 Framework for OSI Security . . . . . . . . . . . . . . . . . 45 v LIST OF TABLES Table 5.3 Required O/R Name Attributes . . . . . . . . . . . . . . . . . 25 Table 6.1 Extended Values in the Reason For Discard Parameter . . . . . 26 Table 6.2 Security Parameter Format . . . . . . . . . . . . . . . . . . 27 Table 6.3 Format - Parameter Value Field . . . . . . . . . . . . . . . . 27 Table 6.4 Format - Basic Portion . . . . . . . . . . . . . . . . . . . . 28 Table 6.5 Format - Basic Information Field . . . . . . . . . . . . . . . 29 Table 6.6 Classification Levels . . . . . . . . . . . . . . . . . . . . 29 Table 6.7 Protection Authority Bit Assignments . . . . . . . . . . . . . 30 Table 6.8 Format - Extended Portion . . . . . . . . . . . . . . . . . . 31 Table 6.9 Format - Extended Information Field . . . . . . . . . . . . . 32 vi FOREWORD The U.S. Government Open Systems Interconnection (OSI) Advanced Requirements Group was established by the National Institute of Standards and Technology (NIST) in cooperation with the Information Resource Managers of the Federal agencies. The group's purpose is to coordinate the acquisition and operation of OSI products by the Federal government. This document specifies the U. S. Government OSI profile. A profile is a cross-section of functional applications pertaining to a particular environment. It is expected that the Administrator of the General Services Administration (GSA) will provide for the implementation of Open Systems Interconnection (OSI) according to this profile. The National Institute of Standards and Technology (NIST) will issue this profile as a Federal Information Processing Standard (FIPS). This is Version 2 of the Government Open Systems Interconnection Profile. It contains an updated specification of the OSI protocols that meet government needs. Products based on these protocols are or soon will be available from major vendors. Organizations contributing to the development of this profile are given below. Department of Agriculture Department of Commerce Department of Defense Department of Energy Department of Education Department of Health and Human Services Department of Housing and Urban Development Department of the Interior Department of Justice Department of Labor Department of Transportation Department of the Treasury Environmental Protection Agency General Services Administration Library of Congress National Aeronautics and Space Administration National Communications System National Science Foundation Office of Management and Budget Veterans Administration vii PREFACE This is a Federal Government procurement profile for open systems computer network products. Section 1 contains introductory material, the purpose and scope of the profile, and the sources of the protocol specifications contained in the profile. Section 2 contains general statements on conformance, interoperation and performance of network systems covered by this profile. Section 3 contains a brief description of the OSI architecture and protocols that apply to this profile. The network protocols are specified in section 4, the principal part of this profile. Accompanying each protocol implementation reference is a statement of conformance identifying the required functional units of that protocol. section 5, Addressing Requirements, is also an integral and mandatory part of this profile. Technical Support Personnel to Acquisition Authorities must be familiar with the terminology and ideas expressed in sections 4 and 5. Section 6 defines security options that, if needed, must be explicitly requested in Requests For Proposals. This profile will change with improvements in technology and with the evolution of network protocol standards. Appendices specify future work items needed to enrich the profile, and thus, improve its utility to the agencies. viii GLOSSARY The terms defined below are used frequently throughout this profile. They are defined here to aid the lay reader. Other terms appearing in sections 4 and 5 are defined in Federal Standard 1037A and ISO 7498 and must be thoroughly understood by the Technical Support Personnel to Acquisition Authorities. Protocol In the Open Systems Interconnection reference model, the communication functions are partitioned into seven layers. Each layer, N, provides a service to the layer above, N+1, by carrying on a conversation with layer N on another processor. The rules and conventions of that N-layer conversation are called a protocol. End System An end system (ES) contains the application processes that are the ultimate sources and destinations of user oriented message flows. The functions of an end system can be distributed among more than one processor/computer. Intermediate System An intermediate system (IS) interconnects two or more subnetworks. For example, it might connect a local area network with a wide area network. It performs routing and relaying of traffic. A processor can implement the functions of both an end system and an intermediate system. A system implementing all seven layers of protocol may provide service directly to users (acting as an end system), and it may connect subnetworks (acting as an intermediate system). When it performs the functions of an intermediate system, only the lower three layers of protocol are exercised. Open System An open system is a system capable of communicating with other open systems by virtue of implementing common international standard protocols. End systems and intermediate systems are open systems. However, an open system may not be accessible by all other open systems. This isolation may be provided by physical separation or by technical capabilities based upon computer and communications security. Federal Government Terminology The following definitions are informal and generic and are provided for the benefit of private sector organizations that review the profile. Agency regulations and any contract should be referred to for precise terms and their usage. Also, other terms may be used in lieu of these in agency regulations and in specific contracts. Acquisition Authority ix An Acquisition Authority, commonly known as a contracting officer, is an individual who, under Federal law and acquisition regulations, has the authority to enter into, administer, and/or terminate a government contract. Federal Acquisition Regulation (FAR) The FAR is applicable to Executive departments and agencies of the Federal Government in the area of acquisition, leasing, and rental of personal property and services. Many departments and agencies have supplementary regulations that apply to their acquisitions. Federal Information Resources Management Regulation (FIRMR) The FIRMR is applicable to federal departments and agencies in the areas of management, acquisition and use of information resources, including automatic data processing and telecommunications equipment and services. Requests For Proposals (RFP) Requests For Proposals are documents issued by the government to request bids for products or services. x 1. INTRODUCTION 1.1 BACKGROUND Both the government and the private sector recognize the need to develop a set of common data communication protocols based on the International Organization for Standardization's seven-layer Open Systems Interconnection (OSI) Basic Reference Model [ISO 1]. In the past, vendor-specific implementations of data communication protocols led to isolated domains of information, very difficult and expensive to bridge. Recent advances in communication technology based on the OSI model offer alternatives to vendor-specific network solutions. Most significantly, advances in open systems allow the interoperation of end systems of different manufacture, when required. This Government Open Systems Interconnection Profile (GOSIP) is based on agreements reached at the National Institute of Standards and Technology (NIST) Workshop for Implementors of Open Systems Interconnection. Each new version of GOSIP will reference the latest appropriate version of the Stable Implementation Agreements for Open Systems Interconnection Protocols [NIST 1], hereafter referred to as the Workshop Agreements. The Workshop Agreements record stable implementation agreements of OSI protocols among the organizations participating in the NIST Workshop for Implementors of OSI. A new version of the Workshop Agreements is created each year at the December OSI Implementors' Workshop meeting. It is the intent of the NIST Workshop that new versions of the Workshop Agreements will be backwardly compatible with previous versions. New editions of the same version of the Workshop Agreements are published at regular intervals during the year. These new editions contain errata and clarifications to the original agreements that are approved by the Workshop plenary. The latest editions are being distributed to all workshop attendees and are available through the National Technical Information Service (NTIS). See NIST Reference 1 for ordering information. GOSIP is also consistent with and complementary to industry's Manufacturing Automation Protocol (MAP) [MISC 1] and Technical and Office Protocols (TOP) [MISC 2] specifications. 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 described herein exist as standard products or are close enough to market that they can be proposed by vendors. 1.2 PURPOSE This profile is the standard reference for all federal government agencies to use when acquiring and operating ADP systems or services and communication systems or services intended to conform to ISO Open Systems Interconnection protocols which provide interoperability in a heterogeneous environment. 1.3 EVOLUTION OF THE GOSIP The GOSIP FIPS will be updated by issuing new versions at appropriate intervals to reflect the progress being made by vendors in providing OSI 1 products with new services useful to Federal agencies. A new version of GOSIP will supersede the previous version of the document because it will include all of the protocols in the previous version plus additional new protocols. Procurement of the new protocols is mandated in Federal procurement requests initiated eighteen months after the version of GOSIP containing those protocols is promulgated as a FIPS. Every new version of GOSIP will specify the architecture and protocols that were included in each of the previous versions so that Federal agencies can easily determine the applicable compliance date for each protocol. It is a goal that a new version of GOSIP will be upwardly compatible with the previous versions. However, changes may be required to correct errors and to align with activity in the international standards organizations. Any errata required to a previous version of GOSIP will be identified in the new GOSIP version. Unless otherwise stated, the mandatory compliance date of the previous version of GOSIP also applies to the errata. These errata will not be included without ensuring that they have the strong support of the vendors who are providing OSI products so that users can be confident that these changes will not inhibit interoperability. See section 1.7 for the GOSIP Version 1 errata. 1.4 SCOPE In an increasingly complex world, the need to exchange information has become an ever more important factor in conducting business. Federal agencies need to share information not only with other Federal agencies, but with state and local governments and commercial organizations as well. Until recently, computer networking technology has not kept pace with this need to communicate. Even now, many Federal agencies have "islands" of computer systems built by different vendors, or by the same vendor, that cannot interoperate. The GOSIP, in addition to being a Federal mandate, is an alert that the vendor community has developed a nonproprietary solution for this requirement to exchange information. The solution is the OSI protocols upon which GOSIP is based. Version 1 of GOSIP (FIPS 146) provided electronic mail and file transfer services using the OSI standards for Message Handling Systems (MHS) and File Transfer, Access, and Management (FTAM). Version 1 of GOSIP provided interoperability among users on X.25, 802.3, 802.4, and 802.5 subnetworks. In addition, Version 1 of GOSIP created a foundation upon which to build new protocols providing new services useful to Federal agencies. Version 2 of GOSIP (FIPS 146-1) uses that foundation to provide a remote terminal access capability using the Virtual Terminal (VT) standard. At the network layer, Version 2 of GOSIP extends interoperabity to include ISDN subnetworks. Future versions of GOSIP will add new user services such as Directory Services, Transaction Processing, Electronic Data Interchange and Remote Data Base Access as well as allow interoperability among users served by other network technologies. GOSIP does not mandate that government agencies abandon their favorite 2 computer networking products. GOSIP does mandate that government agencies, when acquiring computer networking products, purchase OSI capabilities in addition to any other requirements, so that multi-vendor interoperability becomes a built-in feature of the government computing environment, a fact of life in conducting government business. The OSI protocols have the potential to change the way the Federal Government does business. It is essential that Federal agencies make a strategic investment in OSI beginning now, so that they will be well positioned to take advantage of the new services provided by the OSI protocols as they become available. Planning the integration of OSI may require considerable time and effort, but this work will be more than offset by the benefits provided by the new technology. 1.5 APPLICABILITY GOSIP specifies a set of OSI protocols for computer networking that is intended for acquisition and use by government agencies. It must be used by all Federal government agencies when acquiring products and services which provide equivalent functionality to the OSI protocols referenced in this document. For a more detailed statement of applicability, see FIPS 146. 1.6 GOSIP VERSION 2 FUNCTIONALITY Version 2 of GOSIP contains the following functionality not included in Version 1. 1. The Virtual Terminal Service (TELNET and Forms profiles); 2. The Office Document Architecture (ODA); 3. The Integrated Services Digital Network (ISDN); 4. The End System-Intermediate System protocol (ES-IS), and as user options; 5. The Connectionless Transport Service (CLTS); and, 6. The Connection-Oriented Network Service (CONS). The compliance information for GOSIP Version 2 functions is stated in the FIPS announcement. Since the Connectionless Transport Service and the Connection- Oriented Network Service are provided as optional user services, there is no mandatory compliance specified. All GOSIP protocols not included in the above list are bound by the GOSIP Version 1 compliance date which is August 15, 1990. Figure 3.1 illustrates the GOSIP Version 1 architecture and protocols. Figure 3.2 illustrates the GOSIP Version 2 architecture and protocols. 1.7 GOSIP Version 1 Errata 1. Since Version 1 of the Stable Implementation Agreements for OSI Protocols was published, errata have been added to those agreements, primarily by the FTAM and Upper Layer Special Interest Groups (SIGs) of the NIST OSI Implementors' Workshop to correct problems in the original agreements and to align with agreements being developed internationally. Version 1 of GOSIP will now reference the relevant sections of Version 3 of the Stable Implementation Agreements. Text for these sections is available from the 3 Government Printing Office and NTIS. 2. Version 1 of GOSIP (section 5.3.2) required that private messaging systems within the government be capable of routing on administration name, private domain name, organization name, organization unit and personal name. The requirement that private messaging systems be capable of routing based on personal name has been deleted. This change expands the range of messaging systems that are GOSIP compliant. 3. GOSIP Version 1 implementations should use the Network Service Access Point (NSAP) Address structure in Figure 5.1.3 of GOSIP Version 2. This change was made to align with the routing standards currently being developed by the ISO. 4. Version 1 of GOSIP (section 4.2.3) required that processing of Protocol Data Units by the Connectionless Network Layer Protocol be in order of priority. This requirement has been deleted. 5. Version 1 of GOSIP describes a general architecture for OSI security, defines a set of optional security services that may be supported within the OSI model, and outlines a number of mechanisms that can be used in providing the service. Users should now refer to the updated Security Options section in Version 2 of GOSIP. It should be noted that, even in Version 2 of GOSIP, the security section is optional and is considered a placeholder for future security specifications. 1.8 SOURCES OF PROTOCOL SPECIFICATIONS 1.8.1 Primary Source The primary source of protocol specifications in GOSIP is the Stable Implementation Agreements for Open Systems Interconnection Protocols [NIST 1]. This source document was created and is maintained by the NIST Workshop for Implementors of Open Systems Interconnection. It provides implementation specifications that are derived from service and protocol standards issued by the International Organization for Standardization (ISO), the Consultative Committee for International Telegraphy and Telephony (CCITT), and the Institute of Electrical and Electronics Engineers, Inc. (IEEE). By primary source, it is meant that where GOSIP uses a given protocol, it cites that protocol by reference as specified in the above-named Workshop Agreements. The primary source is used in all instances where the protocol of interest has been specified in the Workshop Agreements. Section 4 of this profile gives conformance statements for each protocol that, in some cases, are augmented from the minimal conformance statements in the Workshop Agreements in order to provide the functionality required for government computer networking. 1.8.2 Secondary Sources GOSIP must be complete in that open systems procured in accordance with it must interoperate and must provide service generally useful for government 4 computer networking applications. The Workshop Agreements continue to evolve, but they are still incomplete. (The appendices of GOSIP cite needed work.) Thus, where the Workshop Agreements do not provide completeness, GOSIP may augment protocol and service specifications from the following sources, listed in precedence order. o International Standards and Recommendations o Draft International Standards Since this profile is one of open systems, the secondary sources include specifications that are international standards or are advancing to become international standards. They are included in GOSIP, where needed, to help satisfy the criterion of completeness, and thus, utility. Note that secondary sources exclude protocols, however mature, that are not a part of the international standards process. 1.8.3 Tertiary Sources Even the secondary sources named above may not provide a complete and useful networking system today. It may be necessary for GOSIP to augment protocol and service specifications from the following sources, listed in precedence order. o ANSI Standards o Draft Proposed International Standards o Federal Information Processing Standards o Military Standards For example, security protocols might be incorporated from a FIPS issued by NIST. The use of protocols from other than the primary and secondary sources is undesirable. It is expressly intended that these omissions from standards work be brought to the attention of the international standards bodies so that acceptable international standards may be developed as rapidly as possible. The GOSIP Advanced Requirements Group will replace all tertiary source protocols in GOSIP with suitable primary and secondary source substitutes, when available. 5 2. TESTING OF GOSIP-COMPLIANT PRODUCTS Conformance testing verifies that an implementation acts in accordance with a particular specification, such as GOSIP. Interoperability testing duplicates the "real-life" environment in which an implementation will be used. Performance testing measures whether an implementation satisfies the performance criteria of the user. Functional testing determines the extent to which an implementation meets user functional requirements. NIST issued GOSIP Version 1.0 testing guidance in GOSIP Conformance and Interoperation Testing and Registration [NIST 8]. Consult that reference for detailed procedures, instructions for GOSIP product suppliers, and recommendations for Acquisition Authorities. A future revision to GOSIP Conformance and Interoperation Testing and Registration will add procedures, instructions, and recommendations for the new protocols included in GOSIP Version 2.0. Until such revision occurs, Federal agency personnel should use, for testing GOSIP Version 2.0 additions, the interim guidance supplied below in sections 2.1 and 2.2. NIST issued Message Handling Systems Evaluation Guidelines [NIST 9] to assist Federal agency personnel to evaluate the degree to which specific Message Handling Systems products meet the specific performance and functional requirements of an agency procurement. Further guidelines are planned; File Transfer, Access and Management will be the next. If a guideline is not yet available for an application of interest, Federal agency personnel should use the interim guidance supplied in sections 2.3, 2.4, and 2.5. 2.1 CONFORMANCE TESTING Conformance is shown by the vendor having passed conformance tests adequate for the purpose of exercising the functional units specified in section 4. Conformance to the GOSIP will only apply to the profile defined by the Acquisition Authority. For the purposes of testing conformance to the protocols required by GOSIP Version 2.0, the Acquisition Authority will provide documentation which identifies specific testing requirements. Conformance tests and test systems are currently being developed by several testing organizations. When these test systems for GOSIP Version 2.0 are completed, NIST will specify the tests, test systems and testing organizations that are accredited to perform conformance testing of GOSIP protocols. For the interim, the Acquisition Authority shall require that vendors substantiate any claim of GOSIP conformance. The Acquisition Authority shall also be responsible for determining that acceptable test results are available as a prerequisite to awarding of a final procurement contract. 2.2 INTEROPERABILITY TESTING The Acquisition Authority should specify a detailed set of requirements that 6 will serve to test interoperability of GOSIP Version 2.0 protocols. The Acquisition Authority must specify the following for this testing: - the products to be used for the interoperability testing, including hardware and software versions and components, - a detailed description of planned test scenarios to be run between implementations in the interoperability testing, including the results expected, and - criteria for passing or failing the testing. NIST will recommend vehicles particularly suitable for interoperability testing. 2.3 PERFORMANCE TESTING The principal thrust of OSI is to provide interworking of distributed applications using heterogeneous, multi-vendor systems. GOSIP does not cite performance criteria. Note that protocol definitions include quality of service parameters and other tunable functions. The Acquisition Authority must determine and specify those performance related features that are desired to be under user or application process control and those desired to be under system operator control. The Acquisition Authority may also wish to specify benchmarking criteria as evidence of satisfying performance requirements. 2.4 FUNCTIONAL TESTING The GOSIP specification mandates for each protocol a minimum set of functions to meet general government requirements. In many instances additional functions might be supported within the Workshop Agreements and/or the protocol standard. The Acquisition Authority must determine and specify such additional functions that are required within an acquisition. The Acquisition Authority is responsible for determining that the vendor products proposed meet any and all functional requirements. 2.5 VENDOR ENHANCEMENTS It is expected that most vendors will update their products, for example, from a Draft International Standard version to an International Standard version, as implementation specifications are completed in the Workshop Agreements. Also, some vendors may provide additional functionality. Implementations that go beyond the functional units stated in section 4 must be implemented according to the Workshop Agreements and must interwork with implementations that strictly comply with section 4. Requests For Proposals should encourage vendor enhancements where required to meet user needs. 7 3. DESCRIPTIONS OF ARCHITECTURE AND PROTOCOLS This section briefly describes the GOSIP architecture and protocols. For a more thorough understanding, consult the Government Open Systems Interconnection User's Guide [NIST 7] and other references cited in this profile. 3.1 ARCHITECTURE DESCRIPTION Figure 3.1 illustrates the GOSIP Version 1 architecture and protocols. Figure 3.2 shows how new protocols providing new services have been added to GOSIP Version 2 while maintaining compatibility with GOSIP Version 1. Achieving OSI within the government is best accomplished by using a single method (one protocol profile at each OSI layer) to perform the functions of routing and reliable data transfer. Fig. 3.2 shows that these functions are provided by the transport class 4, and connectionless network layer protocols. Mandatory use of a single transport protocol class (class 4) and a connectionless network layer protocol (CLNP) assures interoperable data transfer between government computer systems for a variety of applications across a variety of subnetwork technologies. Optional use of additional transport and network layer protocols is not precluded by GOSIP; in fact, as shown in Figure 3.2, GOSIP now includes specifications for an optional connectionless transport service and an optional connection-oriented network service. The specifications give sufficient detail for achieving interworking among government computer systems implementing these options. It is useful to enable user selection from among a set of lower layer subnetwork technologies for local and wide area networking. These different technologies exhibit physical, performance, and cost differences that render one technology more appropriate than others for particular uses. Fig. 3.2 illustrates six subnetwork technologies specified by GOSIP. These are the packet data network (X.25), the point to point (Pt-Pt) LAP B Subnetwork, the Integrated Services Digital Network (ISDN), the Token Bus (ISO 8802/4), the Token Ring (ISO 8802/5) and the Carrier Sense Multiple Access with Collision Detection (ISO 8802/3). When a point to point or local area subnetwork technology is selected, the CLNP end system to intermediate system (CLNP ES- IS) routing protocol [ISO 44] is also required. Other lower layer subnetwork technologies may be used, but the Acquisition Authority must provide proper specification to ensure procurement of an effective product, that is, a product able to support operation of transport class 4, the connectionless network protocol, and the GOSIP upper layer protocols. Interconnection of multiple wide-area networks to form the appearance of a single logical wide-area network may be accomplished by any technically appropriate means such as X.75 gateways. Interconnection of remote local area networks to form the appearance of a single logical network may be accomplished by any technically appropriate means, such as MAC bridges. In all other instances, the GOSIP mandates subnetwork interconnection by means of the CLNP and the network access methods appropriate for the specific networks being interconnected. 8 At the application layer, many protocols are expected to be included in GOSIP over time, each applying to different uses. In Fig. 3.2, the current application protocols are File Transfer, Access and Management (FTAM) based on the ISO International Standard [ISO 16-19], the Basic Class Virtual Terminal Protocol based on the ISO International Standard [ISO 32-35], and Message Handling Systems based on the 1984 CCITT Recommendations [CCITT 2-9]. Each application may require a different selected set of services from the application control service elements and the presentation and session control layers. Thus, layers 5, 6, and 7 may be thought of as an integral package of GOSIP upper layer protocols for each specific application. 9 Figure 3.1 GOSIP Version 1 OSI Architecture 10 Figure 3.2 GOSIP Version 2 OSI Architecture 11 The Office Document Architecture (ODA) standard based on the ISO International Standards [ISO 36-42, CCITT 17-24] is also included in GOSIP. Although ODA is not an OSI protocol, it is included in GOSIP because it provides services required by Federal agencies, and the information specified by the standards can be transported by the OSI FTAM and MHS Application layer protocols. A goal of this profile is to permit an Acquisition Authority to issue unambiguous procurement requests for standard applications operating over networks using standard protocols. The Acquisition Authority determines the required applications and the required networks and the GOSIP defines the required protocols. For example, if an Acquisition Authority requires a general purpose File Transfer Access and Management application on a CSMA/CD subnetwork, the GOSIP defines that layer 7 FTAM is required along with certain services from the application control service elements, presentation, and session protocols. To perform the data transfer function, GOSIP mandates the Class 4 transport protocol and the connectionless network layer protocol, and defines a subset of the ISO 8802/2 link layer, and the ISO 8802/3 CSMA/CD protocol. 3.2 PROTOCOL DESCRIPTIONS Following are brief narratives of the general services provided by protocols in each layer of the GOSIP architecture to the layer above. The Application layer (layer 7) allows for protocols and services required by particular user-designed application processes. Functions satisfying particular user requirements are contained in this layer. Representation and transfer of information necessary to communicate between applications are the responsibility of the lower layers. See References [NIST 1; ISO 1, 16-19, 22- 25, 32-35; CCITT 2-9, 14]. The Presentation layer (layer 6) specifies or, optionally, negotiates the way information is represented for exchange by application entities. The presentation layer provides the representation of: 1) data transferred between application entities, 2) the data structure that the application entities use, and 3) operations on the data's structure. The presentation layer is concerned only with the syntax of the transferred data. The data's meaning is known only to the application entities, and not to the presentation layer. See References [NIST 1; ISO 1,20,21,24,25]. The Session layer (layer 5) allows cooperating application entities to organize and synchronize conversation and to manage data exchange. To transfer the data, session connections use transport connections. During a session, session services are used by application entities to regulate dialogue by ensuring an orderly message exchange on the session connection. See References [NIST 1; ISO 1,14,15; CCITT 12,13]. The Transport layer (layer 4) connection-oriented service provides reliable, transparent transfer of data between cooperating session entities. The transport layer entities optimize the available network services to provide the performance required by each session entity. Optimization is constrained by the overall demands of concurrent session entities and by the quality and 12 capacity of the network services available to the transport layer entities. In the connection-oriented transport service, transport connections have end- to-end significance, where the ends are defined as corresponding session entities in communicating end systems. Connection-oriented transport protocols regulate flow, detect and correct errors, and multiplex data, on an end-to-end basis. See References [NIST 1; ISO 1,12,13; CCITT 10,11]. The transport layer also supports a simple connectionless transport service [ISO 46-47]. The Network layer (layer 3) provides message routing and relaying between end systems on the same network or on interconnected networks, independent of the transport protocol used. The network layer may also provide hop-by-hop network service enhancements, flow control, and load leveling. Services provided by the network layer are independent of the distance separating interconnected networks. See References [NIST 1,3; ISO 1-8,11; CCITT 1; NCS 1]. The Data link layer (layer 2) provides communication between two or more (multicast service) adjacent systems. The data link layer performs frame formatting, error checking, addressing, and other functions necessary to ensure accurate data transmission between adjacent systems. Note that the data link layer can operate in conjunction with several different access methods in the physical layer. See Figure 3.2 for examples. See References [NIST 1-3,5; ISO 1,26,28; CCITT 1]. The Physical layer (layer 1) provides a physical connection for transmission of data between data link entities. Physical layer entities perform electrical encoding and decoding of the data for transmission over a medium and regulate access to the physical network. See References [NIST 1-3; ISO 1; ISO 29-31; IEEE 1]. 13 4. PROTOCOL SPECIFICATIONS 4.1 USE OF THE LAYERED PROTOCOL SPECIFICATIONS The individual protocol and interface specifications in this section shall be used directly in Requests For Proposals. However, Acquisition Authorities must take additional steps to ensure an adequate specification for their intended purpose. The following items must be supplied by the Acquisition Authority. 4.1.1 Protocol Selection The architecture described in section 3 suggests a range of protocol choices at different layers of the OSI Reference Model. A subset of these protocols may adequately satisfy an individual acquisition requirement, and may be used. If a subset of the protocols and interface profiles is chosen, it is the Acquisition Authority's responsibility to ensure that all paths through the architecture are complete, i.e., (1) that protocols from layer 1 through layer 7 are included for end systems and at least layers 1 through 3 are included for intermediate systems, and (2) that the appropriate service interface specifications for the selected protocols are also included, as indicated in section 4.1.2 below. With respect to selecting protocols, at least one lower layer technology must be chosen, i.e., CSMA/CD (carrier sense, multiple access with collision detection) [NIST 1, 2; ISO 28, 29], Token Bus [NIST 1; ISO 28, 30], Token Ring [NIST 1; ISO 28, 31]; X.25 [NIST 1, 3; CCITT 1; ISO 8]; HDLC LAP B point to point (Pt-Pt) subnetwork [ISO 26] or ISDN [NIST 1, ANSI 1-3, CCITT 25-27, ISO 45]. Additional lower layer technologies may be used to meet special requirements. The following protocol layers are mandatory for compliance with GOSIP: the connectionless network layer protocol, transport class 4, and session. Transport class 0 and the Connection Oriented Network Service (CONS) [ISO 2,3] are mandated only in conjunction with public data network messaging; see section 4.2.7.3, Message Handling Systems. Presentation protocol and association control service elements are required for all applications except messaging. At least one application layer specific protocol is required to support the intended application. For example, if messaging is required, specify MHS; if file transfer is required, specify FTAM; and, if the Virtual Terminal Service is required, specify VT. The provision of the CONS, for general use, and the Connectionless Transport Protocol (CLTP) are options that may be specified in addition to the GOSIP mandatory Connectionless Network Service (CLNS) and Transport (class 4), respectively. More detailed specification guidance is provided in sections 4.2 and 4.3. 4.1.2 Service Interface Requirements GOSIP mandates no service interface accessibility beyond that indicated in the Workshop Agreements; therefore, any additional service interface accessibility requirements must be clearly stated and mandated by the Acquisition Authority. For example, GOSIP mandates no specific direct access to transport services. If the Acquisition Authority requires direct access to transport services, 14 such a requirement must be included in a solicitation. The issues involved in determining such a requirement are complex. Refer to the GOSIP Users' Guide for a discussion of these issues. Should the Acquisition Authority not request direct access to service interfaces, such access might or might not be provided at the discretion of individual vendors. For example, some vendors may provide access to session services, others may provide access to transport and network services, and still others may limit access to association control services only. Of course, some vendors may provide direct access to service interfaces at the human user interface only. When there is no requirement for a service interface between layers, vendors might merge multiple layer implementations. Such a merger is often implemented to accrue performance benefits to the user. Should the Acquisition Authority request direct access to a specific service interface, care should be taken to specify the general functional and operational objectives of the interface; otherwise, particular vendor interface implementations might or might not meet user requirements. While specifying the general functional and operational objectives for a service interface should enable the vendor to meet a user's functional requirements, such a specification will not ensure portability of software, written to the interface, across product lines from multiple vendors. Work underway in the IEEE 1003.8 POSIX networking services interface committee should create, in the future, a series of service interface specifications that will enable portability of software written to those specifications. In the interim, Acquisition Authorities requiring service interfaces that enable software portability must include a very detailed and explicit interface specification within the solicitation. Such a specification is difficult and expensive to produce, and will limit the number of vendors that bid on a solicitation. Thus, this practice is not recommended. A more prudent course, at the present time, is to specify the general functional and operational objectives of a service interface, leaving implementation decisions to the vendor. 4.1.3 Performance Requirements The Acquisition Authority must specify performance requirements. Performance of an open system is a function of: 1) the source end system, 2) the destination end system, and 3) the communications links, subnetworks, and intermediate systems between the two end systems. The Acquisition Authority's best strategy, given these difficult-to-control factors, is to specify performance requirements for the principal operating environment of the end system. For example, if the communicating end systems will generally be on the same token bus network, detailed performance profiles should be developed for that environment. If these systems must occasionally communicate over a packet data network between local area networks (LANs), then a test for correct interoperation in this occasional environment, without strict performance requirements, should also be included. 4.2 END SYSTEM SPECIFICATION 4.2.1 Physical Layer 15 GOSIP does not mandate any specific physical interface standard. However, the Acquisition Authority must specify physical layer requirements in a solicitation. The following interfaces are recommended. The three standards most commonly used in conjunction with X.25 are Electronic Industries Association (EIA) RS-232-C [EIA 1] for line speeds up to 19.2 kilobits/second, V.35 [CCITT 16] for line speeds above 19.2 kilobits/second, and EIA RS-530 for transfer rates above 20 kilobits/second. For IEEE 802 LANs, the physical interface characteristics are identified in ISO 8802/3 for CSMA/CD, ISO 8802/4 for token bus, and ISO 8802/5 for token ring, [ISO 29-31]. Additional specifications for these interfaces, including subsets, options, and parameter settings are included in the Workshop Agreements [NIST 1]. For ISDN, GOSIP provides for the basic rate interface (BRI) at the S, T, and U reference points [ANSI 1-2] and the primary rate interface (PRI) at the U reference point [ANSI 3]. The BRI provides a 16 kilobits/second signalling (D) channel and up to two 64 kilobits/second switched (B) channels. The PRI provides a 64 kilobits/second signalling (D) channel and up to twenty-three 64 kilobits/second switched (B) channels. Other, non-proprietary, physical interface standards may be selected depending upon unique requirements of the Acquisition Authority; however, the Acquisition Authority must take special care to ensure appropriate operation of such interfaces within a procured system. The Acquisition Authority is advised to make a selection from the set of recommended physical interfaces. 4.2.2 Data Link Layer The data link layer protocols shall be selected by the Acquisition Authority from among the following: 1) High Level Data Link Control (HDLC) Link Access Procedure B (LAP B), in conjunction with X.25 [NIST 1,3; ISO 26] and Pt-Pt subnetworks; 2) ISO 8802/2 (LLC 1) in conjunction with ISO 8802/3, ISO 8802/4, or ISO 8802/5 [NIST 1; ISO 28], and 3) Q.921 (LAPD) [CCITT 25] for operation on the ISDN D channel and ISO 7776 (LAP B) for operation on ISDN B channels. These protocols shall conform to the Workshop Agreements. 4.2.3 Network Layer Service For GOSIP end systems, the connectionless network service (CLNS) is mandated for Government-wide interoperability and provides the required means of interconnecting logically distinct local and long-haul subnetworks. When a GOSIP end system is connected to a local area or Pt-Pt subnetwork, the CLNP end system to intermediate system (CLNP ES-IS) dynamic routing protocol is required. The connection-oriented network service is an option available to GOSIP end systems directly connected to an X.25 subnetwork or ISDN. The technology for providing X.25 and ISDN subnetworks may be used to support the mandated CLNS and the optional CONS; in either case certain subnetwork access protocols are required. These topics are elaborated in the following paragraphs. 4.2.3.1 Connectionless Mode Network Service 16 The Connectionless Mode Network Service (CLNS) shall be provided by the ISO Connectionless Network Protocol (CLNP) [NIST 1; ISO 4,7]. The CLNP must be implemented and used for internetworking of concatenated subnetworks. For operation on a single logical subnetwork, the CLNP also must be implemented. When an end system is connected to a local area or Pt-Pt subnetwork the CLNP ES-IS protocol must be implemented and used. 4.2.3.1.1 Provision of the Connectionless Network Service This service shall be provided according to the Workshop Agreements, section 3.5, with the following modifications and additions: Add to the first bullet of section 3.5.1(2), the following: o An End System must provide a configuration mechanism to control the value to be assigned to the Lifetime parameter for PDUs which it originates. Replace the first bullet of section 3.5.1(3) Optional Functions with the following: o The use of the security parameter shall be in accordance with section 6 of this specification, if required by the Acquisition Authority. Add as section 3.5.2(4): o The CLNS shall be provided with interfaces to the 1984 CCITT Recommendation X.25, HDLC LAP B (ISO 7776), ISO 8802.2 and Draft International Standard (DIS) 9574 (ISDN), as selected by the Acquisition Authority. When interface to DIS 9574 is provided, the provisions of ISO 8878 are not used. Section 3.5.3 of the Workshop Agreements is to be implemented by those systems operating over X.25. Section 3.5.4 of the Workshop Agreements is to be implemented by those systems operating over ISDN. 4.2.3.1.2 Provision of The End System To Intermediate System Routing Service For end systems connected to local area and Pt-Pt subnetworks, the end system to intermediate system (CLNP ES-IS) routing service shall be provided by the ES-IS protocol ISO 9542 [ISO 44] implemented as specified in the Workshop Agreements section 3.8.1. For end systems connected to wide-area networks, provision of an end system to intermediate system routing service is network specific. 4.2.3.2 Connection-Oriented Network Service The CONS is an additional, optional service that may be specified for end systems that are directly connected to X.25 wide area networks and ISDNs. Use of this service can, under certain circumstances, avoid the overhead 17 associated with CLNP and may permit interoperation with end systems that do not comply with GOSIP (i.e., do not implement CLNP). When an Acquisition Authority specifies the CONS option, CONS shall be provided by the X.25 Packet Level Protocol (PLP) [ISO 2]. The mapping of the elements of the CONS to the elements of the X.25 PLP is according to ISO 8878 [ISO 8]. This service shall be provided as specified in section 3.6.1 of the Workshop Agreements with the following modifications: o Section 3.6.1.3 does not apply. When providing CONS in an ISDN, the considerations for control of B and D channels shall be provided by DIS 9574 [ISO 45] and implemented according to section 3.6.1.4 of the Workshop Agreements. (Note that use of X.25 in GOSIP is consistent with FIPS 100-1 which requires CCITT X.25-1984, ISO 7776, and ISO 8202 until January 1, 1993. After that time, additional items covered in CCITT X.25-1988 are mandated by FIPS 100- 1.) 4.2.3.3 Network Layer Protocol Identification OSI systems require the ability to identify which OSI protocols and services are used in a particular instance of communication. These rules for identification are specified in ISO DTR 9577 [ISO 43]. GOSIP systems shall implement the protocol identification rules as specified in section 3.9.2.2 of the Workshop Agreements. 4.2.3.4 Special Provisions For Integrated Services Digital Networks Integrated services digital networks (ISDN) enables X.25 PLP data to be sent across the D channel, sharing the channel with signaling data, and across a B channel. The Acquisition Authority must specify whether one or both of these capabilities are required. When operation of X.25 over a B channel is selected, the B channel can be provided as a switched service or a permanent service. The Acquisition Authority must specify whether one or both of these capabilities are required. (Note that at the present time switched access to the B channel is available from most ISDN vendors, but not in a standard fashion; thus, multi-vendor interoperability between terminal equipment and switching equipment is not widely available today. Work underway in the North American ISDN Implementors' Workshop (IIW) is expected to improve this situation in the future. As appropriate IIW Agreements are developed, and related ISDN FIPS are issued by NIST, GOSIP will be updated accordingly.) ISDN provides the possibility of a BRI (16 Kbps D-channel + 2 64 Kbps B- channels) or a PRI (64 Kbps D-channel + 23 64 Kbps B-channels). The Acquisition Authority must specify whether BRI or PRI is required for each system. The BRI service interface might be available at the S, T, or U reference point. The Acquisition Authority must specify the physical interface required for each BRI system. 18 ISDN B-channel services can be used by a GOSIP end system in any of six ways: 1) circuit-switched access to a packet handler integral to an ISDN switch; 2) circuit-switched access to a packet handler separate from an ISDN switch; 3) circuit-switched access directly to another GOSIP end system, or GOSIP intermediate system; 4) dedicated circuit access to a packet handler integral to an ISDN switch; 5) dedicated circuit access to a packet handler separate from an ISDN switch, and 6) dedicated circuit access to another GOSIP end system or GOSIP intermediate system. The Acquisition Authority must specify the B-channel access capabilities required for any GOSIP end system intended for use with ISDN B-channel services. For ISDN physical layer access at the S, T, and U reference points, sections 2.7.2.1 and 2.7.2.2 of the Workshop Agreements apply. For data link layer access on the D channel, section 2.7.2.4 of the Workshop Agreements applies. For signaling on an ISDN interface, section 2.7.2.5 of the Workshop Agreements applies. For data link layer access on a B channel, section 2.7.2.6 of the Workshop Agreements applies. The PLP for use on ISDN B and D channels shall be implemented as specified in section 2.7.2.7 of the Workshop Agreements. 4.2.4 Transport Layer For GOSIP end systems, the connection-oriented transport service (COTS), as provided by Transport class 4, is mandated for Government-wide interoperability and is the required means of providing a reliable end-to-end data communications path between end systems. The connectionless transport service (CLTS) is an option available for GOSIP end systems. 4.2.4.1 Connection-Oriented Transport Service The vendor shall provide Transport class 4 [NIST 1; ISO 12,13] according to section 4.5.1 of the Workshop Agreements, with the modifications and additions stated below. Transport class 0 [NIST 1; CCITT 10,11] is to be used as appropriate in accordance with the CCITT X.400 recommendations (see section 4.2.7.3 of this profile). Replace the sixth bullet of the Workshop Agreements section 4.5.1.2.1 with the following: o It is recommended that implementations not send user data in the CR or CC TPDU. Any user data received in a CR or CC TPDU will be made available to the Transport Service user. 19 Replace the seventh bullet of the Workshop Agreements section 4.5.1.2.1 with the following: o It is recommended that implementations not send user data in the DR TPDU. Any user data received in a DR TPDU will be made available to the Transport Service user. Add, as the thirteenth bullet of the Workshop Agreements section 4.5.1.2.1, the following: o Transport expedited shall be provided as an optional service for the Transport Service user. In specifying operator and higher layer protocol access controls in transport, the Acquisition Authority should be guided by the implementation guide and military supplement [NIST 5,6]. 4.2.4.2 Connectionless Mode Transport Service The Acquisition Authority may specifiy the optional connectionless mode transport service (CLTS) for GOSIP end systems [ISO 46]. This option may be specified only as an addition to the connection-oriented transport service. Although no GOSIP mandated protocols require the CLTS, a number of non-GOSIP protocols widely available in industry can use CLTS as an efficient means of communicating across local area networks. The Acquisition Authority must determine the need for CLTS to support non-GOSIP protocols. The CLTS option shall be implemented using IS 8602 [ISO 47] according to section 4.6 of the Workshop Agreements [NIST 1]. 4.2.5 Session Layer The vendor shall provide the Session protocol as specified in section 5.9 and section 5.12 of the Workshop Agreements. Application layer protocols determine the session layer functional units needed for their support. Current and future needs should be considered when selecting Session layer functional units. [NIST 1; ISO 14,15; CCITT 12,13]. 4.2.6 Presentation Layer The vendor shall provide the Presentation protocol as specified in section 5.8 and section 5.12 of the Workshop Agreements. See References [NIST 1; ISO 20, 21, 24, 25]. 4.2.7 Application Layer 4.2.7.1 Association Control Service Elements (ACSE) The ACSE, as specified in section 5.5 and section 5.12 of the Workshop Agreements, is required to support all applications except Message Handling Systems. See section 4.2.7.3 of this profile. See References [NIST 1; ISO 20 22-25]. Section 5.12.1.1 of the Workshop Agreements defines a fixed value for the Application Entity (AE) Title in order to satisfy the FTAM requirement for exchanging fields of this type; however, for compatibility with non-GOSIP systems, and to ease compatibility with future versions of GOSIP, GOSIP systems must allow locally configurable AE Titles to be generated and received. 4.2.7.2 File Transfer, Access, and Management Protocol (FTAM) The following categories of FTAM systems are defined for procurement purposes: (1) limited-purpose systems, and (2) full-purpose systems. These categories are defined by their support requirements given below. All FTAM systems in these categories are bound by the language and conditions for Phase 2 FTAM implementations contained in section 9 of the Workshop Agreements. [NIST 1] (Hereafter section 9.) A limited-purpose FTAM system provides the functions of simple file transfer and management. Such a system must support at least Implementation Profiles T1 (Simple File Transfer) and M1 (Management) as defined in section 9. Support requirements for Implementation Profiles are given in Table 9.7 of section 9. A full-purpose FTAM system provides the functions of positional file transfer (including simple file transfer), simple file access, and management. Such a system must support at least Implementation Profiles T2 (Positional File Transfer), A1 (Simple File Access), and M1 (Management), as these are defined in section 9. A limited-purpose FTAM system is able to interoperate with a full-purpose FTAM system at the intersection of their capabilities. FTAM implementations (whether full-purpose or limited-purpose) can operate as an initiator of remote file activity, as a responder to requests for remote file activity, or as both initiator and responder. Further, FTAM implementations can operate as senders (of data to receivers), receivers (of data from senders), or as both. Thus, any of four possible roles may be assumed as follows: initiator-sendor, initiator-receiver, responder-sender, and responder-receiver. The Acquisition Authority must determine the requirements for each FTAM device and must specify such requirements in terms of initiator, responder, sender, and receiver, as well as in terms of limited- purpose or full-purpose. 4.2.7.3 Message Handling Systems The vendor shall provide all Message Transfer Services and Interpersonal Messaging Services specified in section 7 of the Workshop Agreements. [NIST 1] Communication between two Message Transfer Agents, one or both of which reside entirely and exclusively within a public message domain administered by a public data network, takes place as specified by CCITT Recommendation X.410 (1984). CCITT mandates that transport class 0 and the Connection Oriented Network Service (CONS) [ISO 2, 3] be used by end systems when messaging over public messaging domains on public data networks. All end systems on private management domains must use transport class 4. Private management domain end systems that are also connected to public messaging domains conforming to CCITT Recommendation X.410 must also implement and use transport class 0 when 21 acting as a messaging relay between the two domains. Specifically, the Message Transfer Agent in the system connected to both the private and public messaging domain performs the relay; there is no transport relay involved. 4.2.7.4 Virtual Terminal (VT) Basic Class The following categories of VT systems are defined for procurement purposes: 1) simple systems, and 2) forms capable systems. All VT systems in these categories are bound by the language and conditions contained in section 14 of the Workshop Agreements. A simple system provides the functions of a TTY compatible device. It supports a dialogue which is a simple line or character at a time. Such a system uses the control character (single) functions from the ASCII character set, such as "carriage return," "form feed," "horizontal tab," and "back space." A simple system supports the TELNET profile specified in section 14.8.1 of the Workshop Agreements. The TELNET profile requires the Asynchronous mode (A-mode) of operation (i.e., no token handling protocols are needed) and specifies simple delivery control. A forms-capable system is intended to support forms-based applications with local entry and validation of data by the terminal system. A forms-capable system supports functions such as "cursor movement," "erase screen," and "field protection." A forms-capable system supports the forms profile specified in section 14.8.3 of the Workshop Agreements. The forms profile requires the Synchronous mode (S-mode) of operation and specifies simple delivery control. The Basic Class VT International Standard [ISO 32] specifies three negotiation options which are independent of the VT profiles. These are No Negotiation, Switch Profile, and Multiple Interaction Negotiation. Multiple Interaction Negotiation is not addressed by the Workshop Agreements, but any system claiming support of this negotiation option must also support the Switch Profile and No Negotiation options. Any system supporting Switch Profile Negotiation must also support the No Negotiation option. Seven bit USASCII, as well as the International Reference Version (IRV) of ISO-646 graphic repertoires, must be supported by both simple and forms capable systems. 4.2.8 Exchange Formats Exchange formats are not OSI standards. They are included in GOSIP because the information that they describe can be transported by the OSI FTAM and MHS protocols either as the content of a file or as the body part of a message. The GOSIP contains only that information about exchange formats that are required to provide this capability. For detailed specifications on the exchange formats, consult the appropriate standards documents or the Workshop Agreements. Version 2 of GOSIP includes information on how to identify and transport the ODA exchange format. Future versions of GOSIP will include information on how 22 to identify and transport additional formats such as Computer Graphics Metafile (CGM) and the Standard General Markup Language (SGML). For further details, see Appendix 4. ODA information can also be transported by other mechanisms which are outside the scope of the GOSIP. 4.2.8.1 Office Document Architecture (ODA) The ODA Standard [ISO 36-42, CCITT 17-24] specifies rules for describing the logical and layout structures of documents as well as rules for specifying character, raster, and geometric content of documents, thus, providing for the interchange of complex documents. The interchanged documents may be in formatted form (i.e., for presentation such as printing, displaying), in processable form (i.e., for further processing such as editing) or in formatted processable form (i.e., for both presentation and further processing). To transfer an ODA file, the services provided by either the MHS or FTAM application can be used. If the MHS application is used, OdaBodyParts are encoded for transmission over a CCITT X.400-1984 service as a single body part with tag 12 in the P2 protocol. Oda [12] IMPLICIT OCTETSTRING The content of the OCTETSTRING is a SEQUENCE of OdaBodyPart Parameters and OdaData components with a value of type OdaBodyPart. OdaBodyPart :: = SEQUENCE { OdaBodyPart Parameters, OdaData } The OdaBodyPart Parameters component is a SET containing the document- application-profile and the document-architecture-class identifiers OdaBodyPart Parameters :: = SET { document-application profile [0] IMPLICIT OBJECT IDENTIFIER document-architecture-class [1] IMPLICIT INTEGER { formatted (0), processable (1), formatted-processable (2) }} The OdaData component is a SEQUENCE of Intercharge-Data Element as defined by IS 8613-5 [ISO 39] OdaData :: = SEQUENCE of Interchange-Data-Element In the P1 protocol, both the undefined bit (bit 0) and the ODA bit (bit 10) of the Encoded Information Type must be set when an ODA document is present in P2. 23 When using FTAM to transfer an ODA file, the FTAM-3 (ISO FTAM unstructured binary) document type should be specified; however, since files that are not ODA files can have the same document type, it is left up to the user of application programs that remotely access files using FTAM to know that a given file contains ODA information. 4.3 INTERMEDIATE SYSTEM SPECIFICATION Intermediate systems shall operate in connectionless mode. That is, the connectionless network protocol is used regardless of whether the underlying technology operates in connectionless (e.g., CSMA/CD, token ring) or connection-oriented (e.g., X.25, LAP B) mode; however, the connectionless mode need not be used to interconnect X.25 subnetworks to form a single logical subnetwork. Also note that local area network bridges may be employed to form a single logical subnetwork. Intermediate systems may use any combination of the lower layer technologies as specified in the above sections of this profile: 4.2.1 Physical Layer, 4.2.2 Data Link Layer, and 4.2.3 Network Layer. That is, agencies may interconnect local and wide area networks. Implementation profiles for these protocols are contained in the Workshop Agreements and are referenced in the above sections of this profile. Implementation specifications for connectionless-mode intermediate systems are given in section 3.5 of the Workshop Agreements. Addressing structure and Address Registration Authorities are specified in section 5 of this profile. A system that serves as both end system and intermediate system must satisfy the mandatory requirements of sections 4.2 and 4.3 of this profile. 24 5. ADDRESSING REQUIREMENTS 5.1 NETWORK LAYER ADDRESSING AND ROUTING This section specifies the Network Layer addressing scheme and its administrative and routing implications. It also identifies authorities responsible for the administration of the scheme and how subauthorities will be assigned and which responsibilities shall be delegated to them. 5.1.1 NSAP Address Administration, Routing Structures and NSAP Address Structure Network Service Access Point (NSAP) addresses specify the points where the communication capability of the Network Layer (i.e., the Network Service) is made available to its users. In effect they address the direct users of the Network Service, normally transport entities. The semantics of NSAP addresses are encoded into Network Protocol Address Information (NPAI) and conveyed in the appropriate protocol data units (PDUs) between protocol entities providing the Network Service. The basic principles of Network Layer addressing, as defined in Addendum 2 to the Network service definition [ISO 5], include: o NSAP address administration is based on the concept of hierarchical Addressing Domains. An Addressing Domain is a set of addresses interrelated by virtue of being administered by a common authority. The term authority refers to the entity that specifies the structure and ensures the uniqueness of identifiers in the associated domain. In practice the structure of NSAP addresses reflects this administrative hierarchy in that, at any level of the hierarchy, an initial part of the address unambiguously identifies the Addressing (sub) Domain. o The first three levels of the NSAP addressing domain are standardized and result in the NSAP address structure in Figure 5.1.1. The Initial Domain Part (IDP) of the address consists of two parts, the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI). The AFI specifies the format of the IDI, the authority that is responsible for allocating IDI values, and the syntax used to represent the Domain Specific Part (DSP). The IDI is interpreted according to the value of the AFI and its value identifies the authority responsible for the structure and assignment of DSP values. The DSP is allocated and assigned by the authority specified by the IDP part. 25 ZDDDDDDDDDDDDDDDD? 3 IDP 3 CDDDDDDDDBDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDD? ISO/CCITT NSAP ADDRESS 3 AFI 3 IDI 3 DSP 3 @DDDDDDDDADDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDY Figure 5.1.1 NSAP Address Structure The National Institute of Standards and Technology (NIST) has been designated as the authority to administer the addressing domain identified by IDI value 0005 under AFI 47. The AFI value of decimal 47 specifies that the IDI part is interpreted as a four decimal digit International Code Designator (ICD) and that the DSP has a binary abstract syntax. ICDs are allocated and assigned by ISO [ISO 27] and identify international organizations that are the authorities for address administration for an addressing subdomain. The addressing domain identified by ICD 0005 shall be available for use by all of the Federal Government. The NIST shall specify the structure and semantics of the DSP associated with ICD 0005 and delegate the task of administering the assignment of DSP values to the General Services Administration (GSA). This is summarized in Figure 5.1.2. 26 ZDDDDDDDDDDDDDD? 3 IDP 3 CDDDDDDDBDDDDDDEDDDDDDDDDDDDDDDDDDDD? ISO/CCITT NSAP Address 3 AFI 3 IDI 3 DSP 3 CDDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4 Fed. Govt. NSAP Address 3 47 3 0005 3structure specified 3 3 3 3by GOSIP 3 @DDDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY Figure 5.1.2 The NIST ICD Addressing Domain NSAP addresses, encoded as NPAI in appropriate NPDUs, serve as the primary input to the routing and relaying functions of protocol entities providing the Network Service. As such, the semantics of NSAP addresses must convey information required for routing as well as address administration. The basic principles of Network Layer routing, as defined in the OSI Routing Framework [ISO 48], include: o The global OSI environment will consist of a number of Administrative Domains. An Administrative Domain consists of a collection of End Systems (ESs) and Intermediate Systems (ISs), and subnetworks operated by a single entity or Administrative Authority. The Administrative Authority is responsible for the organization of ESs and ISs into Routing Domains; the further structuring and assignment of NSAP addresses; the policies that govern the information that is collected and disseminated both internally and externally to the Administrative Domain; and, the establishment of subdomains and the corresponding delegation of responsiblities. o A Routing Domain is a set of ESs and ISs which operate according to the same routing procedures and which is wholly contained within a single Administrative Domain. An Administrative Authority may delegate to the entity responsible for a Routing Domain the responsibilities to further structure and assign NSAP addresses. The hierarchical decomposition of Routing Domains into subdomains may greatly reduce the resources required in the maintenance, computation and storage of routing information. This GOSIP makes provisions for the establishment of Administrative Domains, Routing Domains and one level of routing subdomains (called Areas). This decomposition of the routing environment allows, where appropriate, administrative entities to request the delegation of responsibility for the organization and administration of their systems and subnetworks. The provision of two levels of routing structures within an Administrative Domain will allow Administrative Authorities to engineer routing configurations that best serve their individual needs. Figure 5.1.3 depicts the GOSIP NSAP address structure. This structure is 27 mandatory for addresses allocated from the ICD 0005 addressing domain. ZDDDDDDDDDDDDDD? 3 IDP 3 CDDDDDDBDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 AFI 3 IDI 3 DSP 3 CDDDDDDEDDDDDDDEDDDDDDDDDDDBDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDBDDDDDDDDDDDDDDDBDDDDDDDD4 3 47 3 0005 3 DFI 3 Admin Author. 3 Reserved 3 Routing Domain 3 Area 3 System 3 NSel 3 CDDDDDDEDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDD4 Octets 3 1 3 2 3 1 3 3 3 2 3 2 3 2 3 6 3 1 3 @DDDDDDADDDDDDDADDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDADDDDDDDDDDDDDDDADDDDDDDDY Figure 5.1.3 GOSIP NSAP Address Structure 28 The DSP Format Identifier (DFI) specifies the structure, semantics and administration requirements associated with the remainder of the DSP. This field provides for graceful support of future DSP structures should the need arise. Currently, only one DSP format (DFI=10000000) is defined under ICD 0005. The remainder of this section describes this DSP format. The Administrative Authority field identifies the entity that is responsible for the organization of ISs and ESs into Routing Domains and Areas; the allocation and assignment of the remaining portion of the DSP; and the policies that govern the dissemination of information within and external to the Administrative Domain. Note that it is unlikely that a large number of Federal Government organizations will establish their own Administrative Domains. Instead, it is more likely that Administrative Domains will be established for collective organizations that autonomously operate large inter-networks and that individual organizations would correspondingly be delegated authority for Routing Domains or Areas. The Reserved field is positioned to be available for encoding higher level routing structures above those of the routing domain or to be used to expand either the Administrative Authority or the Routing Domain fields in future DSP formats should the need arise. The Routing Domain field identifies a unique Routing Domain within an Administrative Domain. The Area field identifies a unique subdomain of the Routing Domain. The System field identifies a unique system (ES or IS) within an Area. The format, value, structure and meaning of this field is left to the discretion of its administrator. The NSAP Selector field identifies a direct user of the Network Layer service, usually a Transport entity. (The NSAP Selector may also identify other direct users of the Network Service if required by the Acquisition Authority.) GOSIP allows a system administrator to configure NSAP Selector-to-Transport entity mappings because, for example, several transport entities may co-exist in some systems. 5.1.2 NSAP Address Registration Authorities This section names the GSA as the GOSIP Address Registration Authority, and specifies how subauthorities shall be assigned, and which responsibilities transfer to them. Under its delegated authority as Address Registration Authority for ICD 0005, GSA shall, upon request, assign, maintain, and publicize unique Administrative Authority identifiers for Federal Government entities that require distinct Administrative Domains. Contact GSA at: Telecommunications Customer Requirements Office U. S. General Services Administration IRMS 29 Office of Telecommunications Services 18th & F Sts. N.W. Washington, D. C. 20405 for the procedures for requesting the assignment of an Administrative Authority identifier. They are also included in Version 2 of the GOSIP User's Guide. 5.1.2.1 Responsibilities Delegated by NIST The management responsibilities delegated by the NIST, via the GSA, to Federal Government entities issued an Administrative Authority identifier under ICD 0005 are given below. o The entity must designate and register with the GSA a specific point of contact for its Administrative Authority. o The entity must ensure that procedures exist to establish appropriate routing structures and to delegate, if required, responsibliities to the administrators of individual Routing Domains or Areas. o The entity must ensure that addresses are assigned uniquely and are kept current and accurate. o The entity must ensure that policies are defined and procedures exist for making addresses and routing information known to other administrative domains. o The entity may, on a voluntary basis, supply such information to the GSA for government-wide compilation and dissemination. The GOSIP Users' Guide [NIST 7] lists the factors that Administrative Authorities should consider before requesting this service and the procedures to be followed if the service is required. 5.1.3 GOSIP Routing Procedures This GOSIP specifies dynamic routing procedures for the exchange of configuration information between ESs and ISs connected via local area and point to point (pt-pt) subnetworks and hierarchical, static routing procedures for the establishment of routing information among ISs. These routing procedures shall be provided according to section 3.8 of the Workshop Agreements, with the following additions after the paragraph of section 3.8.2: o The Routing Information Base (RIB) shall be capable of associating arbitrary sets of NSAPs, described as NSAP address prefixes, with next hop forwarding information for use by the ISO 8473 Route PDU Function. In addition, the RIB must be capable of supporting a default entry that is used in forwarding PDUs containing destination NSAP addresses that do not match any other RIB entries. 30 Nonstandard dynamic routing procedures, in addition to the static capabilities specified above, may be used to establish RIBs within ISs in the interim period while OSI IS-IS dynamic routing protocols are still under development. It should be noted that the GOSIP supported routing structures and DSP addressing structure are in alignment with the OSI IS-IS intra-domain routing protocol [ISO 49] currently under development and that later versions of this profile will mandate the use of standardized OSI IS-IS routing protocols. The routing procedures required for GOSIP systems to communicate with non- GOSIP OSI-compliant systems are discussed in Version 2 of the GOSIP User's Guide. 5.2 UPPER LAYERS ADDRESSING The following sections provide guidance on certain upper layer addressing issues. 5.2.1 Address Structure The address structure for the Session Service Access Point (SSAP) and Transport Service Access Point (TSAP) Selector is two octets for each field, encoded in binary as shown on Fig. 5.2.1. Other lengths conforming to the limits specified in the Workshop Agreements, may be assigned by an end system administrator. 31 PSAP SSAP TSAP ZDDDDDDDDDDDD? ZDDDDDDDDDDDD? ZDDDDDDDDDDDD? 3 binary 3 3 binary 3 3 binary 3 @DDDDDDDDDDDDY @DDDDDDDDDDDDY @DDDDDDDDDDDDY 2 octets 2 octets 2 octets Figure 5.2.1 Upper Layers Address Structure 5.2.2 Address Assignments Service access point (SAP) selectors specify the addresses of standard service interfaces. Values are assigned by an end system administrator and must be configurable in GOSIP end systems. T-selectors and S-selectors are each encoded as a string of octets. The octet string may be specified as an unsigned integer; if so, the high order octet precedes low order octets. P- selectors are encoded in Abstract Syntax Notation (ASN).1 type OCTETSTRING as per the Presentation protocol specification [ISO 21]. The Application Context Name can be used to distinguish the Application entities that use the common application services of ACSE. The Application Context Names for FTAM and VT, as specified in sections 5.12.1.1 and section 5.12.1.4 of the Workshop Agreements, are "ISO FTAM" and "ISO VT." Note that applications which require additional Application Context information may define them, even if they make use of FTAM and/or VT. 5.2.3 Address Registration As an interim measure, until Directory Service implementations are available, federal agencies that wish to have their PSAP address (upper layer SAP selector values plus full NSAP address) accessible to other agencies may register these addresses with GSA. GSA shall catalog, maintain, and disseminate these addresses. 5.3 IDENTIFYING APPLICATIONS 5.3.1 FTAM and File Transfer User Interface Identification The FTAM service definition [ISO 18] includes an optional parameter called the initiator identity. GOSIP recommends the use of this parameter in FTAM implementations to identify users of the service. Generally, an identifying name or group of names is provided in this field. The name identifies the particular user in such a way that two different users may readily be distinguished. In the standard there are no restrictions on what may be included. The initiator identity is encoded as an ASN.1 [ISO 25] variable length graphic string with characters from the ISO646 set [ISO 9]. These names are normally inserted as needed by end systems, and this profile makes no provision for registration. The content is system-dependent. 5.3.2 MHS and Message User Interface Identification The MHS Recommendations [CCITT 2-9] identify a user to a Message Transfer Agent by means of a parameter called the Originator/Recipient Name (O/R Name). 32 The O/R Name is encoded as a set of attributes describing the originator and receiver of the message. The attributes which must be supported by all implementations are the country name, the administration name, private domain name, organization name, organizational units, and personal name. The administration name attribute shall contain one blank when the originator and/or recipient are attached only to a private domain. The private domain name attribute must also be supported by all implementations, and be included when the originator and/or the recipients are located within different private domains. This information is summarized in Table 5.3. ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 Attribute Maximum ASCII Character Length 3 3 3 3 country name 3 3 3 administration name 16 3 3 private domain name 16 3 3 organization name 64 3 3 sequence of org. units 32 each 3 3 personal name 64 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY Table 5.3 Required O/R Name Attributes Private messaging systems within the government shall be capable of routing on the administration name, private domain name, organization name and organizational unit attributes taken in their hierarchical order. They shall also be capable of routing on or delivering based on the personal name attribute; that is, they shall act as Class 2 or Class 3 MTAs as defined in section 7.7.3.3 of the Workshop Agreements. The General Services Administration (GSA) shall be the Address Registration Authority for organization names. GSA shall delegate Address Registration Authority to the organization indicated by the organization name to assign organization unit and personal names. In assigning the organizational unit personal name space, the Address Registration Authorities shall follow the same rules stated earlier for NSAP addresses, except that organizational unit and personal names are not registered with GSA. Typically, a unique personal name is a surname or surname followed by given name, but it could also be an identifier of a particular office within the organization unit. CCITT assigns country name and administration name to public message service providers. Administrations assign private domain names to private messaging systems that wish to interoperate across the administration. The administration may also provide a registration service for government assigned organization names that wish to interoperate across or between administrative domains. A method for assigning private domain names in the absence of an administrative name is given in section 8.4.2 of Version 2.0 of the GOSIP User's Guide. 33 6. SECURITY OPTIONS Security is of fundamental importance to the acceptance and use of open systems in the U.S. Government. Part 2 of the Open Systems Interconnection reference model (Security Architecture) is now an International Standard (IS 7498/2). The standard describes a general architecture for security in OSI, defines a set of security services that may be supported within the OSI model, and outlines a number of mechanisms than can be used in providing the services. However, no protocols, formats or minimum requirements are contained in the standard. The text below describes one security option that may be optionally specified when security services are incorporated in the OSI network layer. This chapter does not describe at this time a complete set of security options that a user might desire nor a description of the security services and protocols that are associated with the specified parameter. It is a parameter that has been identified as being needed if certain security services (e.g., confidentiality, access control) are incorporated in the network layer. The parameter should be used where required, but this chapter should be considered as a placeholder for future security specifications. Appendix 1 provides further information on what specifications are considered needed for OSI security. As defined by ISO, security features are considered both implementation and usage options. An organization desiring security in a product that is being purchased in accordance with this profile must specify the security services required, the placement of the services within the OSI architecture, the mechanisms to provide the services and the management features required. An acquisition authority desiring Connectionless Network Protocol (CLNP) security should specify the following described security option(s). When specifying the CLNP security option, the acquisition authority must ensure that all necessary Security Format Codes are provided. 6.1 REASON FOR DISCARD PARAMETERS The implementation of the security option requires assigning new parameter values to the Reason for Discard parameter in the CLNP Error Report PDU. The first octet of the parameter value contains an error type code as described in IS 8473. Values beyond those assigned in the standard are shown in Table 6.1. The second octet of the Reason for Discard parameter value either locates the error in the discarded PDU or contains the value zero as described in the standard. ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDD? 3 Parameter Values 3 3 3 CDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDD4 3 3 3 Octet 1 3 Octet 2 3 Class of 3 Meaning 3 3Bits 8765 4321 3 Bits 8765 4321 3 Error 3 3 3 3 3 3 3 CDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDD3 34 3 1101 0000 3 Discarded PDU 3 Security 3 Security Option 3 3 3 Offset or Zero 3 3 Out-of-Range 3 3 3 3 3 3 3 1101 1010 3 0000 0000 3 Security 3 Basic Portion 3 3 3 3 3 Missing 3 3 3 3 3 3 3 1101 1101 3 0000 0000 3 Security 3 Extended Portion 3 3 3 3 3 Missing 3 3 3 3 3 3 3 1101 0010 3 0000 0000 3 Security 3 Communication 3 3 3 3 3 Administratively 3 3 3 3 3 Prohibited 3 3 3 3 3 3 @DDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDY Table 6.1 Extended Values in the Reason For Discard Parameter 6.2 SECURITY PARAMETER FORMAT IS 8473 defines the format of the CLNP security parameter. This parameter consists of the three fields shown in Table 6.2. Bits 8765 4321 ZDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDD? 3 Octets 3 3 3 3 1100 0101 3 Parameter Code 3 N 3 3 CDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4 3 3 3 3 N + 1 3 Len = M 3 Parameter Length 3 3 3 CDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4 3 N + 2 3 3 3 3 3 Parameter Value 3 N + M + 1 3 3 @DDDDDDDDDDDDDDADDDDDDDDDDDDDDDDY Table 6.2 Security Parameter Format 6.2.1 Parameter Code IS 8473 assigns the value "1100 0101" to the Parameter Code field to identify the parameter as the Security Option. 6.2.2 Parameter Length This octet indicates the length, in octets, of the Parameter Value field. 6.2.3 Parameter Value The Parameter Value field contains the security information. IS 8473 defines only the first octet of the Parameter Value field. This section completes the 35 definition of this field. Table 6.3 illustrates the format of the Parameter Value field within the Security Parameter. Bits 8765 4321 ZDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDD? 3 Octets 3 3 3N 3 1100 0101 3 Parameter Code CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4 3 3 3 3N+1 3 Len = B + E + 1 3 Parameter Length 3 3 3 CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 3 3 3 3 3N+2 3 XX00 0000 3 Security Format Code 3 3 3 3 3 CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4 3 3N+3 3 3 Parameter 3 3 3 Basic Portion (Optional) Value 3N+B+2 3 3 3 CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4 3 3N+B+3 3 3 3 3 3 3 Extended Portion (Optional) 3 3N+B+E+2 3 3 3 @DDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD Table 6.3 Format - Parameter Value Field 36 6.2.3.1 Security Format Code As described in IS 8473, the high order two bits of the first octet of the Parameter Value field specify the Security Format Code. The standard reserves the remaining six bits and specifies that they must be zero. 6.2.3.2 Basic Portion The Basic Portion of the Security Option identifies the U.S. classification level to which a PDU is to be protected and the authorities whose protection rules apply to that PDU. This portion is optional and appears at most once in a PDU. When the Basic Portion appears in the Security Option of a PDU, it must be the first portion in the Parameter Value field of the Security Parameter. Paragraph 6.3 defines the format of the Basic Portion. 6.2.3.3 Extended Portion The Extended Portion permits additional security labelling information, beyond that present in the Basic Portion, to be supplied in a CLNP PDU to meet the needs of registered authorities. This portion is optional and appears at most once in a PDU. The Extended Portion must follow the Basic Portion, if present, in the Parameter Value field of the CLNP Security Parameter. In addition, if this portion is required by an authority for a specific system, it must be specified explicitly in any Request for Proposal for that system. Paragraph 6.4 defines the format of the Extended Portion. 6.3 BASIC PORTION OF THE SECURITY OPTION The Basic Portion is used by the components of an internetwork to: A. Transmit from source to destination, in a network standard representation, the common security labels required by computer security models. B. Validate the PDU as appropriate for transmission from the source and delivery to the destination. C. Ensure that the route taken by the PDU is protected to the level required by all protection authorities indicated on the PDU. Table 6.4 shows the format of the Basic Portion of the Security Option. Bits 8765 4321 ZDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDD? 3 Octets 3 3 3 N 3 1000 0010 3 Basic Type Indicator 3 3 3 CDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDD4 3 3 3 3 N+1 3 Len = I 3 Length of Basic Information 3 3 3