














              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
                                                    CDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDD4
                                                    3               3                   3

                                                                                        37
 






                                                    3   N+2         3                   3
                                                    3               3                   3     Basic Information
                                                    3   N+I+1       3                   3
                                                    @DDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDY
                                                     
                                      Table 6.4  Format - Basic Portion
            6.3.1  Basic Type Indicator
             
            The value of this field identifies  this as the Basic Portion of the  Security
            Option. 
             

            6.3.2  Length of Basic Information 
             
            This length field, when present, indicates the length, in octets, of the Basic
            Information field.  The Basic Information field  is variable in length and has
            a minimum length of two octets. 
              
            6.3.3  Basic Information 
             
            The  Basic  Information  field   consists  of  two  subfields  as   Table  6.5
            illustrates. 


                                                  Bits 8765  4321
                                  ZDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
                                  3Octets       3                 3
                                  3 B           3   1000  0010    3  Basic Type Indicator
                                  3             3                 3
                                  CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
                                  3             3                 3
                                  3  B + 1      3   Len = F + 1   3  Length of Basic Information
                                  3             3                 3  (Minimum = 2 Octets)
                                  CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 
                                  3             3                 3                                      3 
                                  3  B + 2      3                 3  Classification Level                3
                                  3             3                 3                                      3
                                  CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4                                   Basic    
                                  3             3                 3                                Information
                                  3B + 3        3                 3                                      3 
                                  3             3                 3   Protection Authority Flags         3
                                  3B + F + 2    3                 3                                      3
                                  @DDDDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD  
                                            Table 6.5  Format - Basic Information Field 
             
            6.3.3.1  Classification Level
             
            The Classification  Level  field specifies  the U.S.  classification level  to
            which the PDU must be  protected.  The information in the PDU  must be treated
            at this level unless it is regraded in accordance under the procedures of  all
            the  authorities identified by  the Protection Authority Flags.   The field is
            one octet in length. Table 6.6 provides the encodings for this field. 

                                                  38
 







                      ZDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDD?
                      3    VALUE            3      LEVEL         3
                      3 Bits 8765 4321      3                    3
                      CDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDD4
                      3      0000 0001      3   RESERVED 4       3
                      3      0011 1101      3   TOP SECRET       3
                      3      0101 1010      3   SECRET           3
                      3      1001 0110      3   CONFIDENTIAL     3
                      3      0110 0110      3   RESERVED 3       3
                      3      1100 1100      3   RESERVED 2       3
                      3      1010 1011      3   UNCLASSIFIED     3
                      3      1111 0001      3   RESERVED 1       3
                      @DDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDY
                                            Table 6.6  Classification Levels 

            6.3.3.2  Protection Authority Flags 
             
            The Protection Authority  Flags field indicates the National Access Program(s)
            or Special Access Program(s) whose rules  apply to the protection of the  PDU.
            Its  field length  and source  flags  are described  below.   To  maintain the
            architectural  consistency  and  interoperability  of  DoD  common  user  data
            networks, users  of these networks  should submit requirements  for additional
            Protection Authority  Flags to  DCA DISDB,  Washington, D.  C. 20305-2000  for
            review and approval.

                A.  Field Length:  The Protection Authority Flags field is variable  in
                length.  The  low order bit (Bit  1) of an octet  is encoded as "0"  if
                the  octet is the  final octet in  the field.   If there are additional
                octets,  then the low  order bit is  encoded as "1".   Currently, there
                are  less  than  eight  authorities.   Therefore,  only  one  octet  is
                required and the low order bit of this octet is encoded as "0".
             
                B.  Source  Flags:  Bits  2 through 8  in each octet  are flags.   Each
                flag is associated with  an authority as indicated  in Table 6.7.   The
                bit corresponding to an authority is "1" if the  PDU is to be protected
                in accordance with the rules of that authority. 
                               
                           ZDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 
                           3   Bit     3                  3                                                  3
                           3 Number    3   Authority      3     Point of Contact                             3
                           CDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4 
                           3           3                  3                                                  3
                           3   8       3GENSER            3  Designated Approving Authority                  3
                           3           3                  3  per DoD 5200.28                                 3
                           3           3                  3                                                  3
                           3   7       3SIOP-ESI          3  Department of Defense                           3
                           3           3                  3  Organization of the                             3
                           3           3                  3  Joint Chiefs of Staff                           3
                           3           3                  3  Attn: J6T                                       3
                           3           3                  3  Washington, D.C.                                3
                           3           3                  3                                                  3

                                                                           39
 






                           3   6       3 SCI              3  Director of Central Intelligence                3
                           3           3                  3  Attn: Chairman, Information Handling Committee  3
                           3           3                  3  Intelligence Community Staff                    3
                           3           3                  3  Washington, D. C. 20505                         3
                           3           3                  3                                                  3
                           3   5       3 NSA              3  National Security Agency                        3
                           3           3                  3  9800 Savage Road                                3
                           3           3                  3  Attn: TO3                                       3
                           3           3                  3  Ft. Meade, MD 20755-6000                        3
                           3           3                  3                                                  3
                           3    4      3 DOE              3  Department of Energy                            3
                           3           3                  3  Attn: DP343.2                                   3
                           3           3                  3  Washington, D.C. 20545                          3
                           3           3                  3                                                  3
                           3  3 , 2    3 Unassigned       3                                                  3
                           3           3                  3                                                  3
                           3    1      3 Extension Bit    3  Presently always "O"                            3
                           @DDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
                             Table 6.7  Protection Authority Bit Assignments                   
                  

            6.4  EXTENDED PORTION OF THE SECURITY OPTION 
             
            Table 6.8 illustrates  the format for the  Extended Portion.  To  maintain the
            architectural consistency of  DoD common user  data networks, and to  maximize
            interoperability, users of  these networks should  submit their plans for  the
            use of  the Extended Portion of the Security  Option to DCA DISDB, Washington,
            D.C. 20305-2000 for review and approval.  Once approved, DCA DISDB will assign
            Additional Security Information Format Codes to the requesting activities. 
























                                                  40
 






                                                 Bits 8765  4321
                                   ZDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
                                   3    Octets   3                 3
                                   3  N          3    1000  0101   3  Extended Type Indicator
                                   CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
                                   3             3                 3
                                   3   N+1       3   Len = I       3  Length of Extended Information
                                   3             3                 3
                                   CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
                                   3   N+2       3                 3
                                   3             3                 3  Extended Information
                                   3   N+I+1     3                 3
                                   @DDDDDDDDDDDDDADDDDDDDDDDDDDDDDDY
                                        Table 6.8  Format - Extended Portion 

            6.4.1  Extended Type Indicator

            The value  of  this field  identifies  this as  the  Extended Portion  of  the
            Security Option. 
             
            6.4.2  Length of Extended Information 
             
            This length field indicates the length, in octets, of the Extended Information
            field.  The  Extended Information field is  variable in length with  a minimum
            length of two octets. 
             
            6.4.3  Extended Information
             
            The  Extended  Information field  consists  of  three subfields  as  Table 6.9
            illustrates.  These  three fields form a  sequence.  This sequence  may appear
            multiple times, forming a set, within the Extended Information field. 






















                                                  41
 






             
                                       Bits 8765  4321
                         ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
                         3   Octets                       3
                         3  E                1000  0101   3  Extended Type Indicator
                         CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
                         3   E+1            Len =  (B -  A) +  1   3   Length of  Extended
            Information
                         3                                3    (Minimum = 2 Octets)
                                                                                   
            CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
            DDDDDDDDD?
                         3                                 3                              
                                 3
                   A       3  E+2                                  3   Additional Security
            Information Format Code        3
                         3                                 3                              
                                 3
                         CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                               
                                 3
                         3                                 3                              
                                 3
                         3  E+3       Len = I             3  Length of Additional Security
            Information          3
                         3                                 3                              
                                 3
                         CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                               
                                 3
                         3                                 3                              
                                 3
                         3  E+4                           3                               
                                 3
                         3                                         3   Additional Security
            Information                    3
                         3  E+I+3                         3   (Zero or more octets)       
                                 3
                         @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY                               
                                 3
                         .                                 .                              
                                 3
                         .     (Additional Sequences      .                               
                              Extended
                         .    of the above three fields)  .                               
                            Information
                         .                                .                               
                                 3
                         ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?                              
                                 3
                         3   E+N                                     3 Additional Security
            Information Format Code        3
                         CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                              
                                 3

                                                  42
 






                         3                                 3                              
                                 3
                         3 E+N+1       Len = J             3 Length of Additional Security
            Information          3
                         3                                 3                              
                                 3
                         CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                              
                                 3
                         3 E+N+2                           3                              
                                 3
                         3                                           3 Additional Security
            Information                    3
                  B       3 E+N+J+1                         3   (Zero or more octets)     
                                 3
                                                                                   
            @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
            DDDDDDDDDY
                                    Table 6.9  Format - Extended Information Field
             
            6.4.3.1  Additional Security Information Format Code 
                  
            The value of the Additional Security  Information Format Code corresponds to a
            particular format and meaning  for a specific Additional Security  Information
            field.   Each format  code is assigned  to a  specific controlling  activity. 
            Once assigned, this  activity becomes the authority for  the definition of the
            remainder of  the Additional Security  Information identified  by that  format
            code.  A single  controlling activity may be  responsible for multiple  format
            codes.  However, a  particular format code may  appear at most once in  a PDU.
            For  each  Additional  Security  Information   Format  Code  an  authority  is
            responsible  for,  that   authority  will  provide  sufficient   criteria  for
            determining whether a CLNP PDU marked with  its Format Code should be accepted
            or rejected.  Whenever possible, this criteria will be Unclassified.   
             
            Note: The bit  assignments for  the Protection  Authority flags  of the  Basic
            Portion  of  the  Security Option  have  no  relationship  to the  "Additional
            Security Information Format Code" of this portion. 
             
            6.4.3.2  Length of Additional Security Information 
             
            This  field  provides  the length,  in  octets,  of  the "Additional  Security
            Information" field immediately following. 

            6.4.3.3  Additional Security Information 
             
            The Additional  Security Information  field contains  the additional  security
            relevant information specified  by the authority identified by the "Additional
            Security Information Format Code."  The format, length, content, and semantics
            of this field  are determined by that  authority.  The minimum length  of this
            field 
            is zero. 
             
            6.5  USAGE GUIDELINES 

                                                  43
 






             
            A PDU is "within the range" if 
             
                           MIN-LEVEL <= PDU-LEVEL <= MAX-LEVEL 
             
                  where  MIN-LEVEL and  MAX-LEVEL  are the  minimum  and maximum  security
            levels, respectively, that the system  is accredited for.  The term  PDU-LEVEL
            refers  to the  security level of  the PDU.   In  this context,  the "security
            level" may involve the combination of three factors:

                1)  classification level
                2)  protection authorities
                3)  additional security  labelling information as required  and defined by
            the responsible activity.

            The authorities responsible for accrediting a  system or collection of systems
            are also responsible for determining whether and how these factors interact to
            form a security level or security range.  A PDU should be accepted for further
            processing only if it is within range.  Otherwise, the  Out-of-Range procedure
            described in Paragraph 6.6 should be followed.
             
            6.5.1  Basic Portion of the Security Option 
             
            Use of  the information contained in the Basic  Portion of the Security Option
            requires that an end system be aware of: 
             
                A.   the classification  level, or  levels, at  which it  is permitted  to
            operate, and 
             
                B.  the protection authorities responsible for its accreditation. 
             
            Representation of this configuration information is implementation dependent.

            6.5.2  Extended Portion of the Security Option 
             
            Use of  the Extended  Portion of  the Security  Option requires  that the  end
            system  configuration accurately reflects  the accredited  security parameters
            associated with communication  via each network interface.   Representation of
            the security parameters  and their binding  to specific network interfaces  is
            implementation dependent.

            6.6  OUT-OF-RANGE PROCEDURE 
             
            If the Out-Of-Range condition was triggered by: 

                A.   A  required,  but missing,  Security Option  or Basic  or Extended
                Portion of  a Security Option,  then the PDU  should be discarded.   In
                addition, a CLNP  Error Report or other form of  reply is not permitted
                in this case.  However,  a local security policy may permit data  to be
                delivered  or a CLNP Error Report PDU  to be processed provided a reply
                is not sent.


                                                  44
 






                B.   A PDU whose security level  is less than the  end system's minimum
                security level, then the  PDU should be discarded.  In addition, a CLNP
                Error Report  or other form  of reply  is not  permitted in this  case.
                However,  local security policy  may permit  data to be  delivered or a
                CLNP Error Report PDU to be processed provided a reply is not sent. 
                   
                C.    A PDU  whose  security level  is  greater than  the  end system's
                maximum security level, then: 

                  1.   If a  CLNP Error Report  PDU triggered the  Out-of-Range condition,
                then no reply is permitted and the PDU  should be discarded.  A CLNP Error
                Report PDU must not be sent in this case.
                   
                  2.  Otherwise, discard the  PDU and send a CLNP Error Report  PDU to the
                originating CLNP  entity.   The  first  octet of  the Reason  for  Discard
                parameter is  set as  specified in Table  6.1.   The second  octet of  the
                Reason  for Discard parameter identifies  the Out-of-Range  portion of the
                Security Option.   It  should point  to the  first octet  (i.e., the  type
                indicator) of the Out-of-Range  portion.  Alternatively, the second  octet
                can be  set to  zero. The response  is sent at the  maximum classification
                level of the end system which received the PDU.   The protection authority
                flags  are set  to  be the  intersection of  those for  which the  host is
                accredited and those present in the PDU which triggered this response.

                  Example:  PDU = "Secret, GENSER"
                        End System Level = "Unclassified, GENSER".
                        Reply  = "Unclassified, GENSER".

            These  are  the   least  restrictive  actions  permitted   by  this  protocol.
            Individual end systems,  system administrators, or protection  authorities may
            impose  more stringent restrictions on responses and in some instances may not
            permit any response at  all to a PDU which is outside  the accredited security
            range of an end system.

            6.7  TRUSTED INTERMEDIARY PROCEDURE 
             
            Certain devices  in an internetwork may act as intermediaries to validate that
            communications between two end  systems is authorized.  This decision is based
            on  a combination of knowledge of  the end systems and  the values in the CLNP
            Security Option.   [The  Blacker Front  End (BFE)  is  one example  of such  a
            trusted device.]  These  devices may receive CLNP PDUs which  are in range for
            the  intermediate device, but are  either not within  the accredited range for
            the source or the destination.  In the former case, the PDU  should be treated
            as described  in Paragraph 6.6.  In  the latter case, a CLNP  Error Report PDU
            should be sent to the originating CLNP  entity.  The first octet of the Reason
            for Discard parameter should be set to 1101 0010.   This code indicates to the
            originating  CLNP   entity  that   communication  with   the  end   system  is
            administratively prohibited (refer to Table  6.1).  The security range  of the
            interface  on  which the  reply will  be  sent determines  whether a  reply is
            allowed and at what security level it should be sent.



                                                  45
 






                                              REFERENCES


            National Institute of Standards and Technology

                  1.  NIST  Special Publication 500-177, Stable  Implementation Agreements
            for Open Systems Interconnection Protocols,  Version 3.  This document can  be
            purchased from National Technical Information Service (NTIS), U. S. Department
            of Commerce,  5285 Port  Royal Road,  Springfield,  VA 22161.   For  telephone
            orders call: (703)  487-4650.  This  document may also  be purchased from  the
            IEEE Computer Society, Order Department, phone: 1-800-272-6657.

                  2.   FIPS l07, Local  Area Networks:   Baseband  Carrier Sense  Multiple
            Access   with   Collision   Detection  Access   Method   and   Physical  Layer
            Specifications and  Link Layer  Protocol, NTIS,  U.S. Department  of Commerce,
            5285 Port Royal Road,  Springfield, VA  22l6l. 
               
                  3.  FIPS l00, Interface  Between Data Terminal Equipment (DTE) and  Data
            Circuit-Terminating Equipment  (DCE) For  Operation With  Packet-Switched Data
            Communications Networks,  NTIS, U.S. Department  of Commerce, 5285  Port Royal
            Road, Springfield, VA 22l6l. 
               
                  4.   Implementation Agreements Among  Participants of OSINET,  NBSIR 89-
            4158, National Institute of Standards and Technology.

                  5.  Military Supplement to ISO Transport Protocol, National Institute of
            Standards and Technology,  National Computer Systems  Laboratory, ICST/SNA-85-
            17, 1985.

                  6.  Implementation Guide for ISO Transport  Protocol, National Institute
            of Standards and  Technology, National Computer Systems  Laboratory, ICST/SNA-
            85-18, 1985.

                  7.     NIST  Special   Publication  500-163   Government  Open   Systems
            Interconnection  User's  Guide.   This  document  can  be  purchased from  the
            National Technical Information  Service (NTIS), U. S. Department  of Commerce,
            5285 Port Royal Road, Springfield, VA 22161.  For telephone orders call (7023)
            487-4650.  The NTIS order number is PB90-111212. 

                  8.    GOSIP  Conformance and  Interoperation  Testing  and Registration,
            NCSL/SNA 90-2, 1990.

                  9.    NIST   Special  Publication  500-182,  Message   Handling  Systems
            Implementation  Evaluation  Guidelines.   See  [NIST  7]  for   NTIS  ordering
            information.

            National Communications System

            Federal Standard FED-STD 1041, Interface Between Data Terminal Equipment (DTE)
            and  Data  Circuit-Terminating  Equipment  (DCE)  For Operation  With  Packet-
            Switched Data Communications Networks, National Communications System.


                                                  46
 






            Institute of Electrical and Electronic Engineers, Inc.
                 
            Binary Floating Point  Arithmetic (ANS1 Approved),  IEEE 754, March 21,  1985,
            Institute of Electrical and Electronics Engineers.
               
            The above document may be obtained from: IEEE Standards Office, 345  East 47th
            Street, New York, N.Y.  l00l7. 

            Electronic Industries Association

            Interface between  Data Terminal  Equipment and  Data Communication  Equipment
            Employing Serial Binary Data Interchange, EIA-232C.
            American National Standards Institute

                1.  Integrated  Services Digital Network - Basic Access Interface  for Use
            on  Metallic  Loops for  Application on  the  Network Side  of the  NT-Layer 1
            Specification, ANS T1.601-1988.

                2.  Integrated Services Digital Network  - Basic Access Interface at S and
            T Reference Points - Layer 1 Specification, ANS T1.605-1988.
               
                3.   Carrier to  Customer Installation -  DS1 Metallic  Interface, ANS T1.
            403-1989.

            International Organization for Standardization

                1.  Information Processing Systems  - Open Systems Interconnection - Basic
            Reference Model, Ref. No. ISO 7498-1984(E).
               
                2.  Information Processing Systems - Data Communications - Use  of X.25 to
            provide the OSI Connection Mode Network Service, IS 8878.
               
                3.    Information Processing  Systems  -  Open  Systems  Interconnection -
            Network Service Definition, IS 8348.

                4.    Information  Processing  Systems -  Open  Systems Interconnection  -
            Addendum  to  the  Network  Service  Definition Covering  Connectionless  Data
            Transmission, ISO 8348 Addendum 1.
               
                5.    Information  Processing Systems  -  Open Systems  Interconnection  -
            Addendum to  the Network Service Definition Covering Network Layer Addressing,
            ISO 8348 Addendum 2. 

                6.    Information Processing  Systems  - Open  Systems  Interconnection  -
            Internal Organization of the Network Layer, DIS 8648, N3985, Feb., 1986. 
               
                7.    Information Processing  Systems  -  Open  Systems  Interconnection -
            Protocol  for Providing the  Connectionless Network  Service, IS  8473, N3998,
            March, 1986.       

                8.  Information Processing  Systems - Open Systems  Interconnection - Data
            Communication - X.25  Packet Level Protocol  for Data Terminal Equipment,  ISO

                                                  47
 






            8208.    

                9.  7-bit Coded Character  Set for Information Processing Interchange, ISO
            646, l973. 
               
                10.     Information   Interchange  --   Representation   of   Local   Time
            Differentials, ISO 3307, l975. 

                11.   Information  Processing  Systems -  Open Systems  Interconnection  -
            Working Draft -  End System to  Intermediate System Routing Exchange  Protocol
            for use in Conjunction with ISO 8473.
               
                12.   Information  Processing Systems  - Open  Systems  Interconnection  -
            Transport Service Definition, ISO 8072, l984. 

                13.   Information Processing  Systems  -  Open Systems  Interconnection  -
            Transport Protocol Specification, ISO 8073, l984. 
               
                14.    Information  Processing Systems  -  Open Systems  Interconnection -
            Session Service Definition, ISO 8326, l987(E). 

                15.   Information  Processing Systems  - Open  Systems  Interconnection  -
            Session Protocol Specification, ISO 8327, l987(E). 
               
                16.  Information Processing Systems  - Open Systems Interconnection - File
            Transfer, Access and Management Part 1:  General Introduction, ISO 8571-1. 

                17.  Information Processing Systems  - Open Systems Interconnection - File
            Transfer, Access and Management Part 2:  The Virtual Filestore Definition, ISO
            8571-2.
               
                18.  Information Processing Systems  - Open Systems Interconnection - File
            Transfer, Access and Management Part 3:   File Service Definition, ISO 8571-3.


                19.  Information Processing Systems  - Open Systems Interconnection - File
            Transfer, Access  and Management  Part 4:   File  Protocol Specification,  ISO
            8571-4.
               
                20.   Information  Processing Systems  - Open  Systems  Interconnection  -
            Connection-Oriented Presentation Service Definition, ISO 8822.
               
                21.   Information Processing  Systems  -  Open Systems  Interconnection  -
            Connection-Oriented Presentation Protocol Specification, ISO 8823. 

                22.    Information  Processing Systems  -  Open Systems  Interconnection -
            Service  Definition  for  Association  Control  Service  Element   -  Part  2:
            Association Control, ISO 8649.
               
                23.    Information Processing  Systems  - Open  Systems Interconnection  -
            Protocol  Specification for Association  Control Service  Element: Association
            Control,  ISO 8650.

                                                  48
 






               
                24.   Information  Processing  Systems  - Open  Systems  Interconnection -
            Specification of Abstract Syntax Notation One (ASN.1), ISO 8824.

                25.  Information Processing Systems - Open Systems Interconnection - 
            Specification  of  Basic  Encoding  Rules for  Abstract  Syntax  Notation  One
            (ASN.1), ISO 8825.

                26.   Information Processing  Systems - Data  Communications -  High-Level
            Data Link Control  Procedures -  Description of the  X.25 LAPB-compatible  DTE
            Data Link Procedures, ISO 7776.

                27.  Information  Processing Systems -  Data Interchange -  Structures for
            the Identification of Organizations, ISO 6523, 1984.
              
                28.    Information Processing  Systems  - Local  Area  Networks -  Part 2:
                Logical 
            Link Control, DIS 8802/2.

                29.    Information Processing  Systems  - Local  Area Networks  -  Part 3:
            Carrier Sense Multiple Access With Collision Detection, ISO 8802/3

                30.  Information Processing Systems - Local Area Networks - Part 4: Token-
            passing Bus Success Method and Physical Layer Specifications, ISO 8802/4.

                3l.   Information Processing  Systems - Local Area Networks  Part 5: Token
            Ring Access Method and Physical Layer Specifications, ISO 8802/5.

                32.   Information  Processing  Systems  - Open  Systems  Interconnection -
            Virtual Terminal Services - Basic Class, ISO 9040.

                33.    Information Processing  Systems  - Open  Systems Interconnection  -
            Virtual Terminal Protocol - Basic Class, ISO 9041.

                34.   Information  Processing  Systems  -  Open  Systems  Interconnection.
            Virtual Terminal Service, Basic Class, ISO 9040, Addendum 1, 1988.

                35.   Information  Processing  Systems  -  Open  Systems  Interconnection,
            Virtual Terminal Protocol, Basic Class, ISO 9041, Addendum 1, 1988.

                36.   Information Processing  -  Text and  Office  Systems-Office-Document
            Architecture (ODA) and Interchange  Format - Part 1: Introduction  and General
            Principles, ISO 8613-1, 1988.

                37.   Information Processing  -  Text and  Office  Systems-Office-Document
            Architecture (ODA) and  Interchange Format -  Part 2: Document Structures  ISO
            8613-2, 1988.

                38.   Information Processing  -  Text and  Office  Systems-Office-Document
            Architecture (ODA)  and Interchange  Format -  Part 4:  Document Profile,  ISO
            8613-4, 1988.


                                                  49
 






                39.   Information Processing  -  Text and  Office  Systems-Office-Document
            Architecture  (ODA)  and   Interchange  Format  -  Part   5:  Office  Document
            Interchange Format (ODIF), ISO 8613-5, 1988.

                40.   Information Processing  -  Text and  Office  Systems-Office-Document
            Architecture  (ODA)  and  Interchange  Format  -  Part  6:  Character  Content
            Architectures, ISO 8613-6, 1988.

                41.   Information Processing  -  Text and  Office  Systems-Office-Document
            Architecture (ODA) and  Interchange Format -  Part 7: Raster Graphics  Content
            Architectures, ISO 8613-7, 1988.

                42.   Information Processing  -  Text and  Office  Systems-Office-Document
            Architecture (ODA) and Interchange Format - Part 8: Geometric Graphics Content
            Architectures, ISO 8613-8, 1988.

                43.    Information Processing  Systems -  Protocol  Identification  in the
            Network Layer, DTR 9577.

                44.  Information  Processing Systems -  End System to  Intermediate System
            Routing Exchange Protocol for use with ISO 8473, IS 9542.

                45.  Information Processing  Systems - Data Communications  - Provision of
            the OSI  Connection-mode Network  Service, by  Packet Mode  Terminal Equipment
            connected to an Integrated Services Digital Network (ISDN), DIS 9574.

                46.    Information  Processing  Systems  -  Transport  Service  Definition
            covering Connectionless Mode Transmission, ISO 8072/ADD.

                47.    Information  Processing  Systems  -   Protocol  for  Providing  the
            Connectionless Mode Transport Service, ISO 8602.

                48.  Information  Processing Systems -  Telecommunications and information
            exchange between systems - OSI Routing Framework, ISO/TR 9575.

                49.    Information Processing  Systems Telecommunications  and information
            exchange between systems  - Intermediate systems to Intermediate system Intra-
            Domain routing exchange protocol  for use in conjunction with the protocol for
            providing the Connectionless mode Network Service ISO/IEC JTC1/SC6 DP 10589.

            The above documents may be obtained from: 
               
                              ANSI Sales Department 
                              1430 Broadway
                              New York, NY 10018
                              (212) 642-4900

            International Telephone and Telegraph Consultative Committee
                  
                  1.    CCITT Recommendation  X.25-1984,  Interface Between  Data Terminal
            Equipment (DTE)  and Data  Circuit-Terminating Equipment  (DCE) for  Terminals
            Operating in the Packet Mode on Public Data Networks. 

                                                  50
 






               
                  2.   CCITT  Recommendation  X.400, (Red  Book,  1984), Message  Handling
            Systems: System Model-Service Elements. 
               
                  3.   CCITT  Recommendation  X.40l, (Red  Book,  1984), Message  Handling
            Systems: Basic Service Elements and Optional User Facilities. 
               
                  4.   CCITT  Recommendation  X.408, (Red  Book,  1984), Message  Handling
            Systems: Encoded Information Type Conversion Rules. 
               
                  5.   CCITT  Recommendation  X.409, (Red  Book,  1984), Message  Handling
            Systems: Presentation Transfer Syntax and Notation. 

                  6.   CCITT  Recommendation  X.4l0, (Red  Book,  1984), Message  Handling
            Systems: Remote Operations and Reliable Transfer Server. 

                  7.   CCITT  Recommendation  X.4ll, (Red  Book,  1984), Message  Handling
            Systems: Message Transfer Layer. 

                  8.   CCITT  Recommendation  X.420, (Red  Book,  1984), Message  Handling
            Systems: Interpersonal Messaging User Agent Layer. 
               
                  9.   CCITT  Recommendation  X.430, (Red  Book,  1984), Message  Handling
            Systems: Access Protocol for Teletex Terminals. 

                  10.   CCITT Recommendation X.214,  (Red Book,  1984), Transport  Service
            Definition for Open Systems Interconnection for CCITT Applications. 
               
                  11.   CCITT Recommendation X.224,  (Red Book, 1984),  Transport Protocol
            Specification for Open Systems Interconnection for CCITT Applications. 
               
                  12.    CCITT  Recommendation X.215  (Red  Book,  1984),  Session Service
            Definition for Open Systems Interconnection for CCITT Applications. 
               
                  13.   CCITT  Recommendation  X.225 (Red  Book,  1984), Session  Protocol
            Specification for Open Systems Interconnection for CCITT Applications. 
               
                  14.  CCITT Recommendation X.400 - Series Implementor's Guide (Version 6,
            November 1987). 
               
                  15.    CCITT  Recommendation  X.121   (Red  Book,  1985),  International
            Numbering Plan for Public Data Networks.

                  16.  CCITT Recommendation V.35 - Data Transmission at 48 kilobits/second
            using 60-108 kHz group band circuits.

                  17.    CCITT  Recommendation  T.410  (Blue  Book,  1988)  Open  Document
            Architecture (ODA) and Interchange Format - Overview

                  18.    CCITT  Recommendation  T.411  (Blue  Book,  1988)  Open  Document
            Architecture  (ODA)  and   Interchange  Format  -  Introduction   and  General
            Principles

                                                  51
 







                  19.    CCITT  Recommendation  T.412  (Blue  Book,  1988)  Open  Document
            Architecture (ODA) and Interchange Format - Document Structures

                  20.    CCITT  Recommendation  T.414  (Blue  Book,  1988)  Open  Document
            Architecture (ODA) and Interchange Format - Document Profile

                  21.    CCITT  Recommendation  T.415  (Blue  Book,  1988)  Open  Document
            Architecture (ODA) and Interchange Format - Document Interchange Format (ODIF)

                  22.    CCITT  Recommendation  T.416  (Blue  Book,  1988)  Open  Document
            Architecture (ODA) and Interchange Format - Character Content Architectures

                  23.    CCITT  Recommendation  T.417  (Blue  Book,  1988)  Open  Document
            Architecture  (ODA)  and   Interchange  Format   -  Raster  Graphics   Content
            Architectures.

                  24.    CCITT  Recommendation  T.418  (Blue  Book,  1988)  Open  Document
            Architecture  (ODA)  and  Interchange  Format  -  Geometric  Graphics  Content
            Architectures.

                  25.  CCITT  Recommendation Q.921  (I.441) (Blue Book,  1988) ISDN  User-
            Network Interface Data Link Layer Specification.

                  26.  CCITT  Recommendation Q.931  (I.451) (Blue Book,  1988) ISDN  User-
            Network Interface Layer 3 Specification for Basic Call Control.

                  27.  CCITT Recommendation X.31 (Blue  Book, 1988) Support of Packet Mode
            Terminal Equipment by an ISDN.

            The above  documents may  be obtained  from: International  Telecommunications
            Union, Place des Nations, CH l2ll, Geneve 20 SWITZERLAND.  

            Miscellaneous

                  1.  Manufacturing Automation Protocol

                  2. Technical and Office Protocols, Specification Version 3.0

            For copies of the  two documents listed above, contact:   Corporation for Open
            Systems, 1750 Old Meadow Road, McLean, VA 22102-4306.
              











                                                  52
 






                                      FOREWORD TO THE APPENDICES


            Appendices  1-5  describe U.  S.  Government advanced  requirements  for which
            adequate specifications have yet  to be developed.   This section, revised  by
            the GOSIP  Advanced Requirements  Group, gives  an updated  and more  complete
            summary of protocols planned for inclusion in future versions of the document.
            Each summary states the requirements for including the protocol in GOSIP and a
            plan of work to meet those requirements.  

            New versions of GOSIP will be issued  no more frequently than once a year  and
            the comments  of manufacturers,  government agencies  and the  public will  be
            solicited  before each new version is released.

            The following protocols are candidates for inclusion in Version 3 of GOSIP.

                  1.  Directory Services
                  2.  Optional Class 2 Transport Protocol
                  3.  CGM
                  4.  Virtual Terminal (X3, page, scroll profiles)
                  5.  MHS extensions based on 1988 CCITT Recommendations
                  6.  FTAM extensions
                  7.  FDDI
                  8.  Network Management (Also the subject of a separate FIPS.)
                  9.  Optional Security Enhancements
                  10.  SGML 
                  11.  Manufacturing Message Specification
                  12.  Intra-domain Dynamic Routing
                  13.  EDI

            The following protocols are candidates for inclusion in Version 4 of GOSIP. 

                  1.  Transaction Processing
                  2.  Remote Database Access
                  3.  Additional Optional Security Enhancements
                  4.  Additional Network Management Functions
                  5.  Inter-domain Dynamic Routing

            The  purpose of  Appendices  1-5 is  to assist  federal  agencies in  planning
            decisions relating to the acquisition of implementations of OSI protocols.  

            Appendix 6 specifies a list of acronyms.

            These appendices are not part of the Federal Information Processing Standard.









                                                  53
 






                                         APPENDIX 1.  SECURITY

             
            1.1  BACKGROUND
             
            The Open Systems Interconnection Security Architecture is now an International
            Standard (IS 7498/2).  This document provides a  general architecture that may
            be used  in implementing  security  services in  OSI networks.   Five  primary
            security services are specified in the architecture as well as the  OSI layers
            at which security services could be offered.  The document also discusses many
            security mechanisms which can be used in providing the services.   

            The OSI Security Architecture provides a basis for developing  security but it
            does not  provide specifications  for implementing  security.   A  significant
            level of effort is  required before specifications for security  are available
            that can be used in standards.  This appendix addresses the need  for security
            standards, the status  of standards being  developed and plans for  developing
            additional required standards. 
             
            While the term "Open Systems" implies  that users of such systems intend  that
            the systems be open to others, the users always want to provide access to such
            systems  only  to authorized  users  for  authorized purposes.    Systems that
            process  sensitive and  valuable  data, especially  classified  data, must  be
            protected from  a wide variety  of threats.   Vulnerabilities of  open systems
            include unauthorized access and denial of service.  Vulnerabilities of data in
            open systems  include unauthorized  disclosure, modification  and destruction,
            both accidentally and intentionally. 
             
            Computer programs designed to obtain, modify or destroy data or to simply deny
            service to  authorized users are a  threat to networks  of computers.   Such a
            program is often called a Virus or  a Worm.  Computers which allow programs to
            be executed that  have been imported from  an external source, either  via the
            network  or through  a storage  medium, may  be vulnerable  to such  programs.
            Users  should  always have  back-up  copies of  valuable data  in  an off-line
            storage facility in case the on-line  data is modified or destroyed.   Trusted
            systems with isolation  and controlled  sharing mechanisms should  be used  to
            minimize the threat of a Virus or a Worm. 
             
            Security is an option in GOSIP.  As such, security services may be provided at
            one or more  of the layers 2,  3, 4, 6 and 7.   The Appendix 1  figure depicts
            placement of security  in the overall  profile by augmenting  Figure 3.2  with
            optional security in order  to form the Government OSI  security architecture.
            The  security  architecture described  here suggests  a  range of  choices for
            security services and their placement.  It is expected  that a subset of these
            services and layers  will adequately  satisfy specific security  requirements.
            Because  security  inherently restricts  access  and if  applied  at different
            layers  will  prohibit  interoperability,  it  is  the  responsibility  of  an
            acquisition authority to insure  that the security options chosen  provide the
            desired interoperability as well as the required security.

            1.2  REQUIREMENTS 
             

                                                  54
 






            The  primary  security  services   that  are  defined  in  the   OSI  security
            architecture are  authentication, access  control, confidentiality,  integrity
            and non-repudiation.    These are  defined  in detail  in  IS 7498/2  and  are
            summarized, with simple examples given, below: 
             
              *Data  confidentiality  services  protect against  unauthorized  disclosure.
            Protecting the details of an attempted corporate takeover is an example of the
            need for confidentiality. 
             
              *Data  integrity   services  protect   against  unauthorized   modification,
            insertion  and deletion.   Electronic  funds transfer  between banks  requires
            protection against modification of the information. 
             
              *Authentication services verify the identity  of communicating peer entities
            and the source of data.  Owners  of bank accounts require assurance that money
            will be withdrawn only by the owner. 

             
              *Access  control  services allow  only  authorized communication  and system
            access.    Only  financial  officers  are  authorized access  to  a  company's
            financial plans. 
             
              *Non-repudiation with proof of origin provides to the recipient proof of the
            origin of  data and protects against any attempt  by the originator to falsely
            deny sending the data  or its contents.  Non-repudiation with  proof of origin
            can be used to prove to a judge that a person signed a contract. 
             
            Requirements have been identified for government  applications for all five of
            these services, especially  the first  four.  Authentication,  confidentiality
            and integrity  services may be  implemented in layers  3, 4 and  7 of the  OSI
            architecture while  access control  and non-repudiation  services are  offered
            only at layer 7.  Applications,  such as Electronic Message Handling  Systems,
            can be  provided all  security services  at layer  7.   Providing security  at
            either layer  3 or  4  is generally  required but  not at  both  layers.   The
            selection of  security  services  at  specific layers  must  be  made  by  the
            acquisition  authority  and  depend on  the  benefits  derived  and the  costs
            encountered.   
             
            1.3  STATUS
             
            Interoperability standards are  required for security at layers 2, 3, 4, and 7
            of  the OSI architecture.   Specifications for  security at layers  3 and 4 as
            well as for  Electronic Message Handling Systems have been prepared within the
            Secure Data Network System  project.  (See NISTIR 90-4250)  Specifications for
            security  at layer 2 are being drafted by the IEEE 802.10 LAN Security Working
            Group  developing   a  Standard   for  Interoperable   LAN  Security   (SILS).
            Specifications for authentication of data have been issued in standards by the
            National Institute of Standards and  Technology (formerly the National  Bureau
            of  Standards)  (FIPS  113) and  ANSI  (ANSI  X9.9).   Specifications  for key
            management protocols have been issued in a standard by ANSI (X9.17).   

            The OSI Implementors' Workshop Special Interest Group in Security is reviewing

                                                  55
 






            the specifications of  SDNS (See NISTIRs 90-4259  and 90-4262) as they  become
            public.   It  is also  reviewing proposals  on security  management.   It  has
            reviewed several security  frameworks and architectures  that may be used  for
            future security standards development. 
             
            1.4  PLANS FOR ACHIEVEMENT

            The specifications  and standards  referenced above  will be  reviewed by  the
            security  staff of  NIST,  by the  members  of the  OSI  Implementors Workshop
            Security SIG and  by members of  the GOSIP committee for  inclusion in one  or
            more  of  the  following:   Federal  Information  Processing  Standards;  ANSI
            Standards; and ISO Standards.  The following outlines the plans for satisfying
            the requirements for security in OSI, the development of public specifications
            and the development of standards incorporating the specifications. 

            1.4.1  OSI Security Architecture
             
            The OSI  Security Architecture  (IS 7498/2)  was adopted  as an  International
            Standard in 1988.  This document is included in the Implementors Agreements as
            being the basis for all OSI security development. No further work is needed on
            this document at this time. 
              
            1.4.2  OSI Security Frameworks
             
            A set of security  frameworks of specific information  processing applications
            are planned by the  ISO/IEC/JTC 1/SC21/WG1 Security Group.   An authentication
            framework is an example of  such a framework.  The Security SIG  will continue
            to review these  frameworks for adoption in the Implementors  Agreements or to
            develop frameworks that are needed but are not in development in ISO. 





            1.4.3  Data Link Layer Security
             
            An IEEE  Standard for Interoperable LAN  Security is being  developed over the
            next 1-2 years by the IEEE 802.10  LAN Security Working Group.  A Standard for
            Interoperable LAN Security could be ready in 1990 for consideration by the OSI
            Implementors Workshop Security SIG. 
               
            1.4.4  Network Layer Security
                  
            The  SDNS  Network Layer  Security protocol  document  (SP3) is  available for
            public  use.   This protocol  was presented  to  ANSI in  1989.   The protocol
            encapsulates the T-PDUs just like the Transport Layer security protocol except
            that  it can  also add network  addresses to  the protocol header  for network
            routing.  The protocol may  be implemented in intermediate gateway  systems as
            well as end  systems.   A Network  Layer Security protocol  standard could  be
            ready in 1991. 
             
            1.4.5  Transport Layer Security 

                                                  56
 






             
            The SDNS Transport  Layer Security  protocol document (SP4)  is available  for
            public use and a FIPS is being proposed based on this work.  This protocol was
            presented to ANSI  and ISO in 1989.   The protocol encapsulates  the Transport
            Protocol Data Units, adds  an integrity code if integrity is desired, encrypts
            the  entire T-PDU if confidentiality is desired, and then puts the result in a
            SE T-PDU  (SE  stands for  security  envelope  or secure  encapsulation).    A
            receiver  that has  the correct cryptographic  key can  decrypt the  SE T-PDU,
            verify its integrity and then process the resulting T-PDU.  A  Transport Layer
            Security protocol standard could be ready in 1991. 
               
            1.4.6  Electronic Message Handling System Security 
             
            The X.400  Electronic Message Handling System security recommendations and the
            DARPA Mail Security RFC  1040 are available for public use.   The SDNS Message
            Handling Security protocol specifications  are also available for  public use.
            A standard format for secure electronic messages could be ready in 1992. 
             
            1.4.7  Cryptographic Key Management Protocols 
             
            The  ANSI  X9.17  Key  Management  Protocol, which  is  based  on  private key
            cryptographic  algorithms,  and several  public  key management  protocols are
            being reviewed by the NIST security staff.  A key management protocol based on
            public key cryptographic algorithms could be ready in 1993 for implementation.





























                                                  57
 






                                 Figure A.1  Framework for OSI Security




















































                                                  58
 






                                 APPENDIX 2.  SYSTEM AND ARCHITECTURE


            2.1  Network Management

            OSI management functionality  supports the location and  correction of faults,
            the establishment and adjustment of configurations, the measurement and tuning
            of performance, the  management of security,  and collection and reporting  of
            billing and  accounting information.   Such  functionality is  in end  systems
            (hosts), intermediate  systems (routers),  and other  network elements  (e.g.,
            network services, bridges,  switches, modems, and multiplexors).   The primary
            goal for a  Federal Government network  management specification is to  create
            the ability for managing multi-vendor computer and telecommunications networks
            remotely without undue use of proprietary management protocols.  The scope  of
            a network management specification for use by the U.S. Government will include
            protocols for exchanging management information and  the definition and format
            of information to be exchanged. 

            Note:    The  primary  vehicle  for  this  specification  will  be  a  Federal
            Information Processing Standard  (FIPS).  This  FIPS will reference GOSIP  and
            will be  referenced by  GOSIP.   (The FIPS  is discussed  further below  under
            "Plan".)

            Requirements

            Requirements for  OSI network management are described in detail within a NIST
            report, Management  of Networks  Based on Open  Systems Interconnection  (OSI)
            Standards: Functional Requirements and Analysis (NIST Special Publication 500-
            175,  November   1989).    Requirements   exist  for  an   overall  management
            architectural  framework  model  including fault,  accounting,  configuration,
            security, and performance management services. 

            Status

            The OSI management standards are in an intermediate stage of their development
            and  are  progressing  rapidly.    Key  areas  for  management  standards  are
            architecture, protocols,  system management  functions, and  the structure  of
            management information.   The following table  lists the latest available  ISO
            schedule for management standards approved at the Sixth SC 21/WG 4  Meeting in
            Florence, October 31 - November 9, 1989.

                                                                                 TARGET
            DATES

                                                                        DP     DIS    IS
            Management Architecture
            Management Framework                                        9/86  6/87  10/88
            Systems Management Overview                                             7/90
            4/91

            Management Protocol
            Common Management Information Service                                    

                                                  59
 






            1/90   
              Addendum 1:  CancelGet                                                9/89
            7/90
              Addendum 2:  Add/Remove                                               9/89
            7/90
            Common Management Information Protocol
            1/90
               Addendum 1:  CancelGet                                               9/89
            7/90
               Addendum 2:  Add/Remove                                              9/89
            7/90

            Structure of Management Information
            Part 1:  Management Information Model                                   5/89
            1/90   1/91
            Part 2:  Definition of Management                                       7/90
            4/91
                  Information       
            Part 4:  Guidelines for the Definition                                  11/89
            1/91   1/92
                  of Managed Objects
                                                                              TARGET DATES

                                                                          DP   DIS    IS
            Management Functions
            Configuration Management 
              Systems Management - Part 1:                                           
            7/90   7/91
                Object Management Function                 
              Systems Management - Part 2:                                          7/90
            7/91
                State Management Function
              Systems Management - Part 3:                                           
            7/90   7/91
                Relationship Management Function
            Fault Management
              Systems Management - Part 4:                                           
            7/90   7/91
                Alarm Reporting Function
              Systems Management - Part 5:                                           
            7/90   7/91
                Event Report Management Function
              Systems Management - Part *:                                           7/90
            4/91   4/92
                Confidence and Diagnostic Testing Function
              Systems Management - Part 6:                                          11/89
            7/90   7/91
                Log Control Function
            Security Management                                  
              Systems Management - Part 7:                                    11/89 7/90
            7/91
                Security Alarm Reporting Function

                                                  60
 






              Systems Management - Part *:                                     7/90 4/91
            4/92
                Security Audit Trail Function
            Accounting Management                                              
              Systems Management - Part *:                                     7/90 4/91
            4/92
                Accounting Metering Function
            Performance Management
              Systems Management - Part *:                                     7/90 4/91
            4/92
                Workload Monitoring Function
              Systems Management - Part *:                                           7/90
            4/91   4/92
                Measurement Summarization Function

            As can be seen from the above  schedule, there are several important standards
            that have now reached, or soon will reach, International Standard (IS) status.
            However, many others are still two years away from IS.   Still others that are
            planned, e.g., Software  Management (including "down-line load"), have not yet
            been  added  to  the schedule.    It  is  important  to note  that  the  Draft
            International Standards (DISs)  scheduled to be available  by the end  of 1990
            comprise a  subset that  will make  it possible  for vendors  to build  useful
            systems to solve many immediate network management problems.

            Standards for the specification of managed objects are now being developed  by
            ISO,  ANSI, CCITT, and the IEEE,  as well as by  the Internet Engineering Task
            Force of  the Internet  Activities Board  (for management  of TCP/IP  oriented
            networks).    In   general,  full  specifications  and  standards  from  these
            organizations are expected  to lag the  above SC21/WG4 management schedule  by
            more than a year.

            Another  important aspect  of  network management  standards  activity is  the
            development of implementation agreements (IAs).  The network management SIG of
            the NIST OIW  is developing  IAs based  upon the  emerging network  management
            standards.    These  agreements are  being  developed  according  to a  phased
            approach that aligns with  the ISO standards as  they progress from DP  to IS.
            The  OSI/NM   Forum  is   also  developing   a  set   of  agreements   (termed
            specifications) for  network management.   These agreements, based  on earlier
            ISO  documents and original Forum work,  are to be used  as a basis for Forum-
            sponsored interoperable management demonstrations planned for 1990 and beyond.
            Both formal and informal liaison between the NMSIG of the OIW and the NM Forum
            has proved mutually beneficial in advancing  each set of agreements, including
            identifying and correcting errors and omissions. 

            Plan

            There is an urgent need today for products to manage multi-vendor computer and
            telecommunications networks.   The  U.S. Government  requires initial  network
            management  specifications  that  provide a  useful  subset  of  the full  OSI
            management functionality.   It is desirable  to specify the initial  subset in
            such  a way that it is easy to add other capabilities to reach the full set of
            management  functionality.    Such additional  functionality  may  include the

                                                  61
 






            management of future technologies  such as ISDN and FDDI, and  may include new
            management services such as software management and time management. 

            The U.S. Government intends to propose an initial FIPS based on the OIW stable
            network  management IAs.   The OIW will  include at most the  following in its
            agreements to be completed in 1990 (from phase one of the OIW IAs):
             
                Management Functions: 
                  Object  Management,  State  Management, Relationship  Management,  Error
                  Reporting and Event Control 

                Management Information: 
                  Information Model, Naming, Guidelines and  Template for Defining Managed
                  Objects 

                Management Communication: 
                  CMIS/P, Association Policies, and Services Required 

                Management Objects: 
                  Support  Objects  required   for  above  and  selected   Managed  Object
                  Definitions under development by the OSI MIB WG 

                Conformance Criteria:
                  TBD depending on the progress of relevant ISO documents. 

            It is  planned  that the  initial network  management FIPS  will  be based  on
            portions of  the above  phase one stable  agreements.   The FIPS  will include
            specifications for a  management protocol based on OIW IAs  for CMIS/CMIP, and
            it  will  include management  function specifications  based  on the  OIW IAs.
            Also, the  FIPS  will include  a  library of  management  objects (MIL).    In
            addition, other portions of the agreements may be cited in the FIPS.

            GOSIP profiles will  be cited in the  FIPS to specify the  protocol stack upon
            which management information will be conveyed  and to include OSI applications
            suitable to support management of networks. 

            Once an initial management FIPS has been established, portions of future GOSIP
            versions  may  reference management  FIPS  as  appropriate.   For  example, to
            specify  management  of  network  end  system  (host) computers,  GOSIP  might
            reference the Network  Management FIPS sections on  the use of CMIS/CMIP  as a
            method for conveying information  and sections on system management  functions
            for specific management services.   GOSIP might also reference  the management
            FIPS for appropriate managed object definitions.   Likewise for the management
            of  network routers,  GOSIP might  reference the  FIPS for  use of  CMIS/CMIP,
            management functions and managed object definitions.  

            These are possible initial examples.  As both the FIPS and GOSIP mature, GOSIP
            will  likely  make  many  additional  references  to  newer  versions  of  the
            management FIPS.   (And  the FIPS  can be  expected to additionally  reference
            newer versions of GOSIP as well.)

            2.2  REGISTRATION

                                                  62
 







            OSI  Registration  procedures   are  the  key  to   creating  globally  unique
            identifiers  for  OSI  objects.    Most  OSI  objects  are  identified  via  a
            hierarchically structured  label.  Specific procedures must  be established to
            ensure that  GOSIP identifiers fit  within an internationally  recognized plan
            and uniquely identify GOSIP objects.
            Requirement

            Procedures  are  required  for  the  registration  of  OSI  objects,  such  as
            organization  numbers and  names.   The specific  complete list of  objects is
            subject to  further study  and is  likely to  evolve over  time, as  directory
            services  are  adopted.   For  the  first version  of  GOSIP,  procedures were
            required for registration of organization identifiers for use in NSAPs, labels
            for electronic mail private body parts,  and organization names for electronic
            mail  addresses.   The  third  version of  GOSIP  will require  extending  the
            procedures to include directory distinguished names.  An immediate requirement
            not specific  to GOSIP is registration  procedures for objects defined  in the
            OSI Implementor's Agreements.

            Status

            A standard for registration procedures is under  development in ISO.  The NIST
            is already maintaining a  small registration service for OSINET members.   The
            NIST  has secured three international code  designators (ICDs) as follows:  1)
            four (4) allocated to OSINET and the NIST/OSI Implementor's Workshop;  2) five
            (5) allocated to the U. S. Government,  and 3) fourteen (14) allocated to  the
            OSI Implementors' Workshop (OIW). 

            Plan

            The NIST is updating the GOSIP User's Guide for  publication with Version 2 of
            GOSIP.  One section of the guide will detail GOSIP registration procedures.  A
            registration SIG in the NIST OSI Implementors' Workshop has identified objects
            requiring registration and established detailed procedures for registering the
            objects.

            2.3  ADDRESSING

            GOSIP  network  addressing  is  limited  to  defining  NSAPs.    The  existing
            assumption is that NSAPs will be retrievable from a directory service and that
            each NSAP  will address a  single host.  Nothing  within GOSIP is  designed to
            preclude multi-homed or  mobile end systems.   The problem is that  no routing
            protocol exists  to deal  with mobile  hosts at  the speed  required for  some
            applications.  At the present time,  there is no definition for the  semantics
            and syntax of multi-cast addressing within the network layer.

            Requirement

            Multi-cast addressing  is required to support operation  on broadcast networks
            with connectionless protocols.

            Status

                                                  63
 







            No work is underway in this area.

            Plan

            Study  inclusion of  multi-cast NSAPs  for operation  over broadcast  networks
            (e.g., local networks) in conjunction  with connectionless transport, network,
            and data link protocols.













































                                                  64
 






                                      APPENDIX 3.  UPPER LAYERS 


            3.1  X.400 EXTENSIONS

            Message Handling System specifications in Version 2 of GOSIP are based  on the
            1984 CCITT Recommendations.   GOSIP MHS extensions will be based  on the CCITT
            1988  Recommendations.    These   recommendations  provide  new   capabilities
            including  security,  delivery  to  a  physical  delivery service,  use  of  a
            directory service, delivery  to a message store, and an OSI architecture which
            includes ACSE and the Presentation layer.

            Requirements

            A requirement  exists for  MHS security  features such  as message  originator
            authentication, checks  against  unauthorized disclosure  and verification  of
            content integrity.  It is also highly desirable to have message store delivery
            which will allow personal  computers without full User Agent  functionality to
            have access to MHS services.  The DOD requires that military precedence levels
            and  preemption features  be incorporated  into the  Message Handling  Systems
            standard  and that a  method be developed  of passing this  information to the
            connectionless network layer protocol for processing.

            Status

                A.    Standards   -   The  1988  CCITT MHS  Recommendations were  formally
            approved in late 1988.

                B.  Implementors' Agreements  -  In 1989, the MHS SIG issued implementors'
            agreements which provided a minimally conformant 1988 Message Handling System.
            These  implementors'  agreements do  not  include significant  additional user
            services, but allow interworking  with implementations conforming to the  NIST
            Stable Implementation Agreements  for CCITT 1984 X.400-based  Message Handling
            Systems and provide a firm basis for the introduction of further 1988 services
            and features.  Further implementors' agreements based on CCITT  1988 X.400 are
            expected in 1990.

            Plan

            As an interim measure,  NSA and NIST should determine whether  the SDNS method
            of sending security information in a  new special-purpose User Agent satisfies
            all GOSIP advanced security  requirements for electronic mail.   This approach
            would  allow  security information  to  be  sent on  Message  Handling Systems
            implemented according to  the CCITT  1984 Recommendations.   However, the  new
            User Agent would not be based on an international standard.

            There already exists the capability of sending and receiving X.400 mail from a
            personal computer attached  to a  host by using  terminal emulation  software.
            The User Agent  is co-located  with the MTA  and the terminal  interface is  a
            local matter.   The GOSIP Advanced Requirements Group plans  to investigate to
            what extent this architecture satisfies current government requirements.


                                                  65
 






            There is also  a proposal to  include a message  store (i.e., standard  remote
            User Agent)  capability in a  future MHS implementors'  agreement.   A message
            store would provide a standard software  package with standard error recovery.
            When implementors' agreements for message store are adopted, the functionality
            in those agreements will be incorporated into GOSIP.

            The  DoD requirement for  expansion of precedence levels  will be forwarded to
            the  CCITT  committee  on  Message  Handling  Systems.    The  GOSIP  Advanced
            Requirements  Group  will  request  the  NIST/OSI  Implementors'  Workshop  to
            determine how Application-level precedents  can be passed to the  lower layers
            for processing.



            3.2  FTAM (FILE TRANSFER, ACCESS AND MANAGEMENT)

            The File Transfer,  Access and Management protocol and service  allow users on
            different networks  to communicate  about files (and  transfer files)  without
            requiring that one  user know the  detailed file characteristics of  the other
            user.  A generic  file organization is defined for  communication; elements of
            this virtual file model are mapped to corresponding elements of the local file
            system.  A  comprehensive set of file attributes and  file activity attributes
            are defined; in  addition, a  large number of  actions is possible  on a  wide
            variety of file types.

            Requirement

            Implementation profiles are defined for user  requirements as follows:  simple
            file  transfer, positional  file  transfer, full  file  transfer, simple  file
            access,  full  file  access,  and  management.   Each  implementation  profile
            contains  a different  combination of document  types, attributes  and service
            classes.  An FTAM implementation for  the GOSIP should require support of  the
            positional file  transfer (which includes  simple file transfer),  simple file
            access  and  management implementation  profiles.   Future  versions  of GOSIP
            should  include  overlapped  access,  filestore   management  (including  file
            directory query  capability), error  recovery capability, concurrency  control
            capability, and File Access Data Unit (FADU) locking capability.

            Status

                A.  Standards - FTAM  has been released as an International Standard  from
            ISO;  currently  FTAM  comprises  five  parts: general  introduction,  virtual
            filestore definition,  file service  definition, file protocol  specification,
            and protocol  information  conformance  statement  proforma.   There  are  two
            prospective  addenda  which are  overlapped  access and  filestore management.
            Filestore  management  should reach  IS status  in  late 1991,  and overlapped
            access should reach IS status in early 1992.

                B.   Implementors' Agreements  -  FTAM  Phase 2  (based  on IS  text)  was
            completed as of December 1988, and maintained since then with the inclusion of
            several errata.  This agreement provides for all core services defined  in the
            FTAM standard except  for restart, recovery  and concurrency.  Facilities  for

                                                  66
 






            full file transfer and record-level access are provided; three different FTAM,
            and four different NIST document types are  defined.  FTAM Phase 2 is included
            in Version 3 of the workshop agreements, available after December 1989.   FTAM
            Phase 3 provides restart, recovery and concurrency capabilities, and  enlarges
            on the set of  document types currently defined.  FTAM Phase  3 is complete as
            of  March 1990.  FTAM Phase 2 Agreements are upwardly compatible to FTAM Phase
            3 Agreements at the intersection of their functional capabilities.

            Plan

            FTAM Phase 2 is currently included in versions 1 and  2 of GOSIP; reference is
            made  to the  Phase  2  FTAM (based  on  IS) as  it  appears  in the  workshop
            agreements.  A  file directory service capability  is planned for in  a future
            version of GOSIP; it is  also anticipated that a number of new  document types
            will be included  in the future.   Possibly, full file transfer  and full file
            access  implementation  profiles  will be  mandated.    Recovery, restart  and
            concurrency control capabilities may also be required.  It is anticipated that
            Version  3 of  GOSIP will  mandate  the FTAM  Phase 3  specification  from the
            Workshop Agreements. NIST personnel  will work with the FTAM  Special Interest
            Group at the  NIST/OSI Implementors' Workshop  to expedite the development  of
            implementation  agreements  and  to insure  that  government  requirements are
            included.

            3.3  VIRTUAL TERMINAL

            The  Basic  Class Virtual  Terminal  Protocol  allows terminals  and  hosts on
            different networks to  communicate without  requiring that one  side know  the
            terminal characteristics handled by the other side.  A generic set of terminal
            characteristics is defined for communication which is mapped to local terminal
            characteristics for  display.  An addendum to Basic  Class VT provides a forms
            mode capability.



            Requirement

            The service options  to be  selected include  type of negotiation  and the  VT
            profiles to be specified.   Additional implementation profiles for  GOSIP will
            include profiles  for page and  scroll terminals  in addition to  the existing
            TELNET and forms profiles.  No negotiation capability is required.

            Status

                A.  Standards -  All comments on Basic Class VT and on  addendum 1 (forms)
            have been resolved and the service and protocol documents for Basic  Class and
            the addendum have been merged.

                B.  Implementors'  Agreements - Stable  agreements were completed  for the
            TELNET, Transparent, and Forms  profiles in December 1988.   Stable Agreements
            for the X3 profile were completed in December 1989.

            Plan

                                                  67
 







            Version 3 of  GOSIP is expected to  include the X3, scroll  and page profiles.
            Additional options may  be added to the  TELNET profile.  NIST  personnel will
            work with the VT Special Interest Group in the NIST/OSI Implementors' Workshop
            to expedite the  development of implementation  agreements and to insure  that
            government requirements are included.

            3.4  THE DIRECTORY

            A  directory  is a  collection of  attributes  (i.e., information)  about, and
            relations  between,  a named  set  of  addressable objects  within  a specific
            context.  A  directory can be viewed  as a data  base containing instances  of
            record types.  The most typical relationship  between a directory user and the
            directory itself is  that of an information user  and an information provider.
            The user supplies  an unambiguous or ambiguous  key to the directory,  and the
            directory returns the information labeled by the  key.  The directory user may
            filter the available information to access only the most essential fields.

            Requirement

            The requirements for  a GOSIP directory service  are much too  complicated and
            voluminous  to  include here.    The  NIST  has  developed a  separate  report
            specifying the requirements.  From the complete  requirement set, the NIST has
            identified an initial  subset for inclusion into  GOSIP.  In summary,  for the
            initial directory, requirements  include:   1) functions provided  by the  DoD
            "whois" service  (a name  to data  record mapping),  and the  DoD domain  name
            service (host name to network address mapping), 2) service name to T-selector,
            S-selector,  and P-selector  mapping, 3)  inclusion of  a  host's capabilities
            within the host  directory entry, and 4)  the ability to resolve  mailing list
            names  into  a  set of  electronic  mail  addresses.   For  the  initial GOSIP
            directory, access  control, simple  authentication, and  replication are  also
            required.

            Status

            The Directory is an IS  in ISO (ISO 9594) and has been issued  by CCITT as the
            X.500 series of  Recommendations.   Workshop Agreements exist  based on  these
            documents.  ISO  and CCITT  are jointly developing  extensions to the  current
            standard in areas where it is known  to be deficient, such as access  control,
            replication, and the information model.   Additional implementation agreements
            are needed to cover the extensions.

            Plan

            The plan is to  improve the directory implementor agreements as  necessary and
            to get  needed changes  into the  ISO and  X.500 versions  of the  standard to
            support the initial GOSIP requirements.  These goals should be accomplished in
            1991 and 1992  so that an initial directory specification can be included in a
            subsequent version of GOSIP.

            3.5  REMOTE DATABASE ACCESS


                                                  68
 






            Remote  Database  Access   (RDA)  allows   the  interconnection  of   database
            applications  among  heterogeneous  environments  by  providing  standard  OSI
            Application  layer  protocols  to  establish  a  remote connection  between  a
            database client and a database server.   The client is acting on behalf of  an
            application program while the server is interfacing to a process that controls
            data transfers to and from a database.

            Requirement

            There is a strong  requirement to share information among  Database Management
            Systems from different  vendors which  are widespread in  both government  and
            industry.  The  Remote Database Access  protocol allows  that data sharing  by
            providing a neutral "language" by which heterogeneous systems can communicate.

            An  extension of  the above requirement  is the need  for distributed database
            capability.  This will be achieved in  the long-term by extending the existing
            RDA model,  and through RDA's  harmonization with  the Transaction  Processing
            protocol.

            Status

            The RDA standard  is specified in two  documents, a generic RDA  for arbitrary
            database  connection  and  an  SQL  specialization  for  connecting  databases
            conforming  to the  standard  database language  SQL.   Both  the generic  RDA
            standard and the RDA specialization for  SQL include functionality required by
            Federal agencies.

            The generic RDA  standard reached DP status  in 1987 and is  expected to reach
            DIS status in 1990.  The RDA specialization for SQL is also  expected to reach
            DP  status in 1990.   Final adoption  of ISO International  Standards for both
            documents is expected in 1992.

            Plan

            Vendors, particularly SQL vendors, plan to have implementations  conforming to
            the ISO International Standard  available at the  earliest possible time.   An
            RDA SIG  was formed  within the  NIST OSI  Implementors' Workshop  in 1989  to
            assist in this process.

            3.6  TRANSACTION PROCESSING

            Requirement

            The  specific  requirements  within  the  U.  S.  Government  for  transaction
            processing are still under investigation.

            Status

            Current plans are for Transaction  Processing to move to IS status  in 1990 or
            in 1991.

            Plan

                                                  69
 







            NIST  is working  with Federal  agencies to  determine transaction  processing
            requirements and  is representing  the interests  of Federal  agencies in  the
            national and  international standards committees.   The first step  is for the
            federal  agencies  that  have transaction  processing  requirements  to become
            knowledgeable about the  TP services  specified in the  evolving TP  standards
            documents  and to determine  whether these  services meet  the needs  of their
            organization.    NIST is  willing  to assist  other  federal  agencies in  the
            process.

            A Transaction Processing SIG has been formed within the NIST/OSI Implementors'
            Workshop. 



            3.7  ELECTRONIC DATA INTERCHANGE

            Electronic  Data Interchange  (EDI) describes  the  rules and  procedures that
            allow computers to send  and receive business information in  electronic form.
            Business information  includes the full  range of information  associated with
            buyer/seller  relationships (e.g.,  invoices,  Customs declarations,  shipping
            notices, purchase orders).

            Requirements

            The Office of  Management and Budget is proposing to issue a guidance document
            that states that  Federal agencies shall,  to the maximum extent  practicable,
            make   use   of   Electronic   Data    Interchange   with   supporting   GOSIP
            telecommunications   networks   for   the   processing   of   business-related
            transactions.

            Status

                A.   Standards - 1)   ANSI committee X12  has developed and  is developing
            standard formats for business-related messages.  There is also an ISO standard
            (IS  9735) for Electronic Data for Administration, Commerce and Transportation
            (EDIFACT).  The JTC1  special working group on EDI is  developing a conceptual
            model for Electronic  Data Interchange.  2)  CCITT Study Group VII established
            a Rapporteur Group to work on a  solution on how to perform EDI using  Message
            Handling Systems.   The group completed  work on a  set of recommendations  in
            June  1990.    This group  established  a  new  content  type for  EDI  and  a
            corresponding content protocol  (currently designated PEDI).  PEDI  will provide
            service elements and  heading fields for EDI  similar to those provided  by P2
            for interpersonal messages.

                B.  Implementors'  Agreements -   The  NIST Workshop  Agreements currently
            contains basic guidelines     for  adopting 1984  X.400  as  the interim  data
            transfer mechanism between EDI applications.

            Plan

            If products based on the CCITT Interim Recommendations are available  in 1992,

                                                  70
 






            EDI will  be included in Version 3 of GOSIP;   Otherwise, EDI is scheduled for
            inclusion in Version 4 of GOSIP.

            3.8  MMS SERVICES

            The  Manufacturing Message  Specification  (MMS) application  can  be used  to
            obtain  and/or  manipulate  objects related  to  a  manufacturing environment.
            These objects  include, but  are not  limited to,  variables semaphores,  data
            types,  and  journals.    Although  MMS   was  designed  for  a  manufacturing
            environment, these objects have applicability outside of manufacturing.

            Requirements

            Although the government  is not a primary manufacturer,  MMS has usefulness in
            the acquisition  of point of measurement  quality data, in  military depots at
            the Department of Energy,  and Department of Defense sites.  Additionally, the
            Deep Space  Network Data  Systems group  of the  Jet Propulsion  Laboratory is
            investigating the use of MMS for on-board control and telemetry.

            Status

            MMS is currently at the IS level in ISO and has implementors' agreements ready
            for inclusion in the NIST/OSI Stable Implementor Agreements in 1990.

            There are implementations available based upon DIS-9506(MMS) which are already
            installed.   A  mechanism for backwards  compatibility has been  agreed and is
            ready  to progress into  the Stable Agreements  document.  Work  is ongoing to
            establish agreements on all 86 services that are contained within MMS.


            Plan

            The  plan is  to  augment  and improve  the  MMS  implementors' agreements  as
            required.  Additionally, abstract test cases will be reviewed and generated as
            necessary to further refine the definition  of MMS conformance.  This work  is
            ongoing with anticipated  completion of a subset  of services in 1990  so that
            MMS can be included in Version 3 of GOSIP. 

            3.9  INFORMATION RETRIEVAL

            Information retrieval supports the open interconnection of database users with
            database  providers  by  specifying  an OSI  application  layer  protocol  for
            intersystem  search  and  retrieval of  records  from  a remote  bibliographic
            database.

            Requirement

            Information retrieval functionality is required by Federal agencies which need
            to retrieve information from remote bibliographic databases.

            Status


                                                  71
 






            The OSI Information  Retrieval service and protocol  is specified in the  ANSI
            standard: Z39.50-1988 - Information Retrieval Service Definition and Protocols
            Specification  for Library Applications.   A  corresponding ISO  standard (ISO
            10162  and  10163:  Search  and  Retrieve  Service  Definition  and   Protocol
            Specification)  has  reached  DIS status.    Final  adoption  as international
            standards is expected by early 1991.

            Plan

            Vendors are now  developing implementations  conforming to Z39.50.   A  Z39.50
            implementor's group has  been formed, represented  by more than 20  companies.
            Options will be investigated to include bibliographic  searching within GOSIP.
            Agencies  are   encouraged  to   bring  forth   other  information   retrieval
            requirements.







































                                                  72
 






                                     APPENDIX 4.  EXCHANGE FORMATS


            The  following  standards are  not OSI  standards,  but they  provide services
            required by Federal agencies  and the format information that they specify can
            be transferred by OSI Application layer protocols, such as FTAM and MHS.

            4.1  ODA EXTENSIONS

            ODA allows  for the  interchange of  compound documents (documents  containing
            text, facsimile, and  graphics) which have been generated by  diverse types of
            office products,  including word  processors and  desktop publishing  systems.
            Interchange of ODA  documents may be  by means of  data communications or  the
            exchange of storage media.  ODA documents may be in processable form (to allow
            further processing such as editing or reformatting) or in final form (to allow
            presentation as intended by the originator) or in both forms.  The key concept
            in the document architecture is that of structure -- the division and repeated
            subdivision  of  the content  of a  document  into increasingly  smaller parts
            called  objects.   Two  structures  are  defined by  ODA:  these  are  logical
            structure (contents  are divided based  on meaning, e.g.,  chapters, sections,
            paragraphs) and layout  structure (contents are  divided based on form,  e.g.,
            pages, blocks).

            Requirement

            A Document  Application Profile (DAP)  specifies the  constraints on  document
            structure and  content according to the rules of  the ODA standard.  Different
            DAPs  can  be  created  that apply  to  different  classes  of  document.   As
            extensions to ODA  are made, they will be incorporated into the DAPs specified
            in the Workshop Agreements.

            Status

                A.  Standards -  ODA is an international  standard; however, several areas
            within ODA are currently being studied, enhanced and/or extended.  The primary
            emphasis  on   extensions  includes   new  content   architectures  (such   as
            spreadsheets and  audio) and new features  such as variant  of styles, complex
            tables,  alternative  representation,  computed  data  in  documents,  and  an
            interface to EDI.  Several addenda are planned to cover these extensions.

                B.  Implementors' Agreements - The ODA SIG will examine extensions as they
            are  developed to determine whether  or not to  incorporate such extensions in
            DAPs.

            Plan

            The plan  is to  contribute  to the  work on  extensions  to ODA  through  the
            Workshop by informing standards groups of deficiencies and inadequacies of the
            standard  and to  incorporate developed extensions  into applicable  DAPs when
            these extensions are  mature.  GOSIP will reference applicable  DAPs which the
            National Computer Systems Laboratory (NCSL) plans  to issue for Federal agency
            use.

                                                  73
 







            4.2  GRAPHICS

            The  graphics requirements  for GOSIP include  the Computer  Graphics Metafile
            (CGM).    The  purpose of  CGM  is  to  facilitate  the  transfer  of  picture
            description   information  between   different  graphical   software  systems,
            different  graphical  devices and  different computer  graphics installations.
            CGM  specifies  a  file  format  suitable  for the  description,  storage  and
            communication  of  picture  description  information  in a  device-independent
            manner.

            Requirement

            FIPS PUB  128 announces  the adoption of  the American  National Standard  for
            Computer  Graphics  Metafile,  ANSI  X3.122-1986,  as  a  Federal  Information
            Processing Standard (FIPS).   This  standard is intended  for use in  computer
            graphics applications  that are either  developed or  acquired for  government
            use.    When  computer  graphics  metafile  systems for  GOSIP  are  developed
            internally,  acquired  as  part of  an  ADP  system  procurement, acquired  by
            separate procurement, used under an ADP  leasing arrangement, or specified for
            use in contracts for programming services, they shall conform to FIPS PUB 128.

            Status

                A.  Standards  - Computer  Graphics Metafile  (CGM) ANSI  X3.122-1985, ISO
            8632/1-4-1987, FIPS 
            128-1987.

                B.    Application  Profiles   -  MIL-D-28003  "Digital  Representation  of
            Communication of Illustration Data: CGM Application Profile" 30 December 1988.

            Plan

            An Application Profile (AP) defines additional requirements beyond ANSI CGM to
            ensure  interoperability   of  implementations   for  specific   applications.
            Currently, two  major application profiles exist for CGM;  the TOP AP, and the
            CALS AP (MIL-D-28003).   As these APs and other  APs which are applicable  for
            Federal  agency use are promulgated, they will  be incorporated into FIPS 128.
            GOSIP will  reference applicable  APs for CGM  which NCSL  plans to  issue for
            Federal agency use.

            4.3  STANDARD GENERALIZED MARKUP LANGUAGE (SGML) APPLICATION PROFILE

            Description

            The Standard Generalized  Markup Language (SGML) standardizes  the application
            of the generic coding and generalized markup concepts.  It provides a coherent
            and unambiguous  syntax for  describing whatever  a user  chooses to  identify
            within  a  document.   It is  a  metalanguage for  describing the  logical and
            content structure of a document in a machine processable syntax.  The Standard
            Generalized  Markup Language can  be used for documents  that are processed by
            any  text  processing or  word  processing system.    It will  be particularly

                                                  74
 






            applicable to:

                o documents  that  are  interchanged  among  systems with  differing  text
            processing languages

                o documents  that are  processed  in  more than  one  way,  even when  the
                  procedures use the same text processing language.

            Requirement

            FIPS  PUB   152  announces  the   adoption  of  the   International  Standards
            Organization Standard Generalized Markup Language (SGML), ISO  8879-1986, as a
            Federal Information Processing Standard (FIPS).  This standard is intended for
            use in documents  that are processed by  any text processing systems  that are
            either developed  or acquired for government  use.  When  SGML text processing
            systems for GOSIP are developed internally, acquired  as part of an ADP system
            procurement,  acquired by  separate  procurement, used  under  an ADP  leasing
            arrangement, or specified for use in  contracts for programming services, they
            shall conform to FIPS PUB 152.


            Status

                  A.   Standards  -  Information Processing  - Text  and office  systems -
            Standard Generalized Markup Language (SGML), ISO 8879-1986 (E),FIPS 152-1988.

                  B.    Application  Profiles  -  MIL-M-28001A, "Markup  Requirements  and
            Generic  Style Specification  for Electronic  Printed Output  and  Exchange of
            Text," December 1989.

            MIL-M-28001A,  "Markup  Requirements  and  Generic  Style  Specifications  for
            Electronic Printed  Output and Exchange of Text," established the requirements
            for the digital  data form of  page oriented technical military  publications.
            Data  prepared  in  conformance  to  these requirements  will  facilitate  the
            automated  storage,  retrieval,  interchange,  and   processing  of  technical
            documents from heterogeneous data sources.  MIL-M-28001A requirements include:

                o procedures and  symbology for markup  of unformatted text  in accordance
                  with  this  specific  application  of  the Standard  Generalized  Markup
                  Language;

                o SGML  compatible  codes  that  will  support  encoding  of  a  technical
                  publication  to  specific  format requirements  applicable  to technical
                  manuals;

                o output processing requirements that will format a conforming SGML source
                  file to the style and format  requirements of the appropriate Formatting
                  Output Specification Instance (FOSI).

            Plan

            An Application Profile (AP)  defines additional requirements beyond  FIPS SGML

                                                  75
 






            to  ensure interoperability of implementation.   MIL-M-28001 is an Application
            Profile for technical military publications.   The plan is to develop an  SGML
            Document Application Profile (SDAP) by extending MIL-M-28001 to be more useful
            for  generic documents and to incorporate the  SDAP into FIPS 152.  GOSIP will
            reference applicable SDAPs which NCSL plans to issue for Federal agency use.
















































                                                  76
 






                                  APPENDIX 5.  LOWER LAYER PROTOCOLS


            5.1  IS-IS DYNAMIC ROUTING PROTOCOLS

            Within  OSI networks,  systems of  routers (intermediate  systems) enable  the
            effective and efficient interconnection  of a diverse set of  subnetwork types
            (e.g., CSMA/CD,  token ring, token bus, and  X.25) into internetworks.  Within
            such an  internetwork, messages are  sent like postal  letters from router  to
            router.  At each router a message is examined and the next router is selected.
            The effect  of such a  scheme is that  each message may  follow an independent
            route.  As  conditions within the internetwork  change (e.g., link, host,  and
            router failures and activations), the possibility exists for messages to reach
            their destination despite  failure of  network elements.   Such potential  can
            only be achieved if the system of routers exchanges information concerning the
            state  of  routes.   Protocols for  exchanging information  concerning varying
            route  conditions  are  known  as  dynamic  routing  protocols.    Within  OSI
            standards,  dynamic  routing  protocols  are   named  intermediate  system  to
            intermediate system (IS-IS) protocols.

            Requirement

            Dynamic routing is required within GOSIP to support the needs of several large
            government  internetworks.   Two  kinds of  routing  support are  required: 1)
            dynamic  routing  within  an administrative  domain,  and  2) dynamic  routing
            between administrative domains.  Routing requirements within an administrative
            domain  are  well understood,  and  two  generally  acceptable schemes  exist.
            Routing  requirements  between administrative  domains  are not  widely agreed
            upon, although ECMA has produced a technical report.

            Status

            An intra-domain dynamic routing protocol was submitted to ISO from ASC X3S53.3
            in January 1988.  The submission is based on DEC's Phase V link state routing.
            It was discussed at the November  ISO SC6/WG2 meeting and was registered as  a
            DP in January 1990.

            ECMA developed  an inter-domain  technical report  (TR50), based  on an  NIST-
            developed model.  It was submitted by ECMA as a liaison to ISO WG2 in May 1989
            as the proposed basis for an ISO inter-domain standard.

            Plan

            The NIST will support the progression  of the DEC submission toward an  ISO IS
            through work in  standards committees and  laboratories.   The NIST will  also
            prepare  for establishing implementor agreements  as the document reaches DIS.
            The NIST  will continue  to support  development of  the inter-domain  routing
            protocol within ECMA, ANSI, and ISO.

            The  GOSIP  will  adopt intra-domain  dynamic  routing  protocols  as soon  as
            implementor agreements  are  in place.    The projected  date  is 1991.    The
            adoption of an inter-domain routing protocol for GOSIP should occur one to two

                                                  77
 






            years following adoption of an intra-domain protocol.

            5.2  FIBER DISTRIBUTED DATA INTERFACE (FDDI)

            FDDI is a 100 Mbit/s token ring network utilizing multimode fiber optic media.
            Three  standards,  Physical Medium  Dependent  (PMD), Physical  Layer Protocol
            (PHY),  and Medium Access  Control (MAC)  specify the  Physical and  Data Link
            layers  of  the  Open  Systems  Interconnection  Reference Model.    A  fourth
            standard, Station Management  (SMT) interfaces  to the first  three layers  to
            control   initialization  and   configuration  of   the  ring,   as   well  as
            reconfiguration around faults, and will  provide management services to higher
            layer management protocols.



            Requirement

            MAC, PHY and PMD have a few options which require  selection (e.g., 48 bit vs.
            16 bit  addressing) and  a  few timers  and parameters  which require  further
            definition (particularly of  their default values) to  ensure interoperability
            in  an OSI  environment.   One  class of  service (Restricted  Token  Mode) is
            inappropriate in an OSI environment.

            SMT  is  more complex,  and  will  probably offer  many  options, particularly
            regarding network policies, which will require some selection.  In many cases,
            this will simply mean selecting the default option or policy.

            Status

                A.   Standards - The MAC (X3.139-1987) PHY (X3.148-1988)  and PMD (X3.166-
            1989) standards  are approved.   SMT is still  under development and  probably
            will be forwarded  in June 1990 and  approved in 1991.   Products implementing
            FDDI are now widely available.

                B.     Implementors'  Agreements  -  NIST  has  drafted  an  implementors'
            agreement covering  MAC, PHY  and PMD.   This  was accepted  into the  ongoing
            agreements by the Lower Level SIG and should be incorporated in Version 3.0 of
            GOSIP.  Although products are now starting to appear, SMT is not approved, but
            is "stable", so work could begin on an implementors' agreement by mid-1990.
             
            Plan

            NIST will draft a proposed implementors'  agreement covering SMT after SMT  is
            forwarded to approval,  which will probably occur in June.  The ANSI standard,
            moreover, will not be completely stable until some time in 1990 or 199l, since
            the public review  usually results  in changes.   That means  that closure  on
            implementors'  agreements cannot be  reached before some  time in 1991  at the
            earliest.   This is  not  ideal, because  there  will be  significant  product
            shipments in 1990.  

            Since SMT  is largely  software, vendors  expect to  update equipment  already
            shipped before SMT  is finalized, by  distributing new software (often  on ROM

                                                  78
 






            chips).

            5.3  TRANSPORT PROTOCOL CLASS 2

            The transport protocol, class 2, for  use over the connection-oriented network
            service (CONS)  is accepted  by several OSI  profiles (e.g.,  UK GOSIP).   The
            transport protocol, class 2, is also used with CONS in several U.S. Government
            applications, where communication is confined to a single logical subnetwork.

            Requirement

            The transport protocol, class 2, is desired in GOSIP as an  optional transport
            protocol  for use  with  CONS, where  communication  is confined  to a  single
            logical  subnetwork.   The  transport protocol,  class  4, operating  over the
            connectionless network  service (CLNS),  will remain  the sole  mandatory data
            transport service for purposes of interoperability among U. S. GOSIP-compliant
            computer systems.  The specification of the transport protocol, class 2, as an
            option in GOSIP, is intended to  enable interoperability among U.S. Government
            computer systems, when using class 2 transport over CONS.  Such specifications
            would be intended to prevent the spread of non-interoperable class 2 transport
            implementations  within the  U. S.  Government.   The  ability  to choose  the
            correct transport protocol  class for a  given instance of communication  will
            require a prior knowledge  on the part of the transport  connection initiator,
            until directory services are included in GOSIP.

            Status

            Although a few  U.S. vendors provide implementations of the  class 2 transport
            protocol,  the  overwhelming  majority offer  class  4  transport  only.   The
            Workshop Agreements endorse class 4 transport for use over 

            CLNS and CONS, and class 0 transport  for use over CONS when direct access  to
            public messaging systems is required.

            Plan

            Interested  government agencies brought the  requirement for class 2 transport
            implementation  agreements to  the attention  of the  Lower Layer  SIG  of the
            NIST/OSI Implementors' Workshop.   Workshop  Agreements are now  in place,  so
            consideration  canbe  given to  inclusion  of  an optional  class  2 transport
            capability into GOSIP, Version 3.0.  

            5.4  INTEGRATED SERVICES DIGITAL NETWORK

            Integrated  Services Digital  Networks  (ISDN),  supporting integrated  voice,
            data,  image, and  video  are expected  to  be  deployed on  a  wide scale  in
            ubiquitous public offerings and in private  network offerings, as services and
            as components  from which private ISDN  networks can be  constructed.  Initial
            offerings  will  be  a switched  64  kbps  service delivered  to  a customer's
            terminal  at a  basic rate  (16 Kbps signaling  channel and  two 64  KBPS data
            channels) or a  primary rate (24 64  Kbps channels, one used  for signalling).
            Later offerings, now in the development  phases, will offer higher capacities,

                                                  79
 






            estimated at 150 Mbps to 622 Mbps.

            Requirement

            One use for ISDN is to provide a bearer service for OSI data protocols;  thus,
            ISDN is included in  GOSIP as a lower layer service.   Other ISDN applications
            include integrated voice,  image, data, and  video, and, therefore,  non-GOSIP
            ISDN applications can be expected.  NIST plans to issue a variety of FIPS that
            enable the government to exploit the full technical capabilities of ISDN.  The
            initial focus aims at switched 64 Kbps  service for voice, voice/data, and, in
            GOSIP,  OSI data.    Both the  basic  and primary  rates  are needed.    Later
            broadband ISDN (B-ISDN) is needed.   The initial fundamental requirements are:
            1) specifications enabling multi-vendor  interconnection compatibility between
            terminal  equipment  and switching  equipment  and 2)  specifications enabling
            multi-vendor interconnection compatibility between switching equipment.  

            Status

            The North American ISDN Users Forum  (NIU-FORUM), comprising a user's workshop
            (IUW) and  an implementor's  workshop (IIW),  is addressing  issues of  multi-
            vendor  terminal equipment-to-switch  and switch-to-switch  interoperation and
            ISDN application  profiles.   Some implementation  agreements and  application
            profiles are expected by the end of 1990.

            Plan

            The GOSIP FIPS will reference appropriate IIW agreements and ISDN FIPS as they
            become available.  NIST plans to issue  ISDN FIPS for integrated voice, image,
            data,  and video and  non-OSI data, as appropriate  agreements are achieved in
            the IIW and IUW.   The primary requirement for  ISDN in GOSIP is as  a network
            bearer service accessible via terminal equipment and switching equipment  that
            can be connected readily, regardless of  the specific vendor.  The GOSIP  FIPS
            will evolve to account for availability of B-ISDN and the Synchronized Optical
            Network (SONET).



















                                                  80
 






                                         APPENDIX 6.  ACRONYMS


            ACSE        Association Control Service Element
            AE          Application Entity
            AFI         Authority and Format Identifier
            ANSI        American National Standards Institute
            AP          Application Profile
            ASCII       American Standard Code for Information Interchange
            ASN         Abstract Syntax Notation
            BRI         Basic Rate Interface
            CCITT       Consultative Committee for International Telegraph & Telephone
            CGM   Computer Graphics Metafile
            CLNP        Connectionless Network Protocol
            CLNS        Connectionless Network Service
            CLTP        Connectionless Transport Protocol
            CLTS        Connectionless Transport Service
            CMIP        Common Management Information Protocol
            CMIS        Common Management Information Services
            CONS        Connection-Oriented Network Service
            COTS        Connection-Oriented Transport Service
            CSMA/CD     Carrier Sense, Multiple Access with Collision Detection
            DAP         Document Application Profile
            DIS         Draft International Standard
            DOD   Department of Defense
            DOE         Department of Energy
            DP          Draft Proposal
            DSP         Domain Specific Part
            DTR         Draft Technical Report
            ECMA        European Computer Manufacturers Association
            EIA         Electronic Industries Association
            ES-IS       End System-Intermediate System
            FADU        File Access Data Unit
            FAR         Federal Acquisition Regulation
            FDDI        Fiber Distributed Data Interface
            FIB         Forwarding Information Base
            FIPS              Federal Information Processing Standard
            FIRMR       Federal Information Resources Management Regulation
            FTAM        File Transfer, Access, and Management 
            GENSER      General Service
            GOSIP       Government Open Systems Interconnection Profile
            GSA         General Services Administration
            HDLC        High Level Data Link Control
            ICD         International Code Designator
            IDI         Initial Domain Identifier
            IDP         Initial Domain Part
            IEC         International Electrotechnical Commission
            IEEE        Institute of Electrical and Electronic Engineers
            IRV         International Reference Version 
            IS          International Standard
            IS          Intermediate System
            IS-IS             Intermediate System-Intermediate System

                                                  81
 






            ISDN        Integrated Services Digital Network
            ISO         International Organization for Standardization
            JTC         Joint Technical Committee
            LAN         Local Area Network
            LAPB        Link Access Procedure B
            LAPD        Link Access Procedure D 
            MAC   Medium Access Control
            MAP         Manufacturing Automation Protocol
            MHS   Message Handling Systems
            MMS   Manufacturing Message Specification
            NCS         National Communications System
            NIST        National Institute of Standards and Technology
            NMSIG       Network Management Special Interest Group
            NPDU        Network Protocol Data Unit
            NPAI        Network Protocol Access Information
            NSA         National Security Agency
            NSAP        Network Service Access Point
            ODA         Office Document Architecture
            OSIO        Open Systems Interconnection
            PCI         Protocol Control Information
            PDN         Public Data Network
            PDU         Protocol Data Unit
            PHY         Physical Layer Protocol
            PLP         Packet Level Protocol
            PMD   Physical Medium Dependent
            PRI         Primary Rate Interface
            PSAP        Presentation Service Access Point
            RDA         Remote Database Access
            RFP         Request For Proposal
            RIB         Routing Information Base
            SAP         Service Access Point
            SC          Steering Committee
            SCI         Special Compartmented Information
            SDNS        Secure Data Network Service
            SGML        Standard Generalized Markup Language
            SIG         Special Interest Group
            SILS              Standard for Interoperable LAN Security
            SIOP-ESI    Single Integrated Operational Plan-Extremely Sensitive Info.
            SMT         Station Management
            SNPA        Subnetwork Point of Attachment
            SQL         Structured Query Language
            SSAP        Session Service Access Point
            SVC         Switched Virtual Circuit
            TC          Technical Committee
            TOP         Technical and Office Protocols
            TP          Transaction Processing
            TSAP        Transport Service Access Point
            TTY         Teletype
            VT          Virtual Terminal
            WAN   Wide Area Network
            WG          Working Group
            WYSIWYG     What You See Is What You Get

                                                  82
 



























































                                                  83
 