military randbook survivable adaptable fiber optic...

PE-1MIL-HDBK-818 -1

31 October 1992

MILITARY RANDBooK

SURVIVABLE ADAPTABLE FIBER OPTICEMBEDDED NETWORK

(6mENET)NETWORK DEVELOPMENT GUIDANCE

AMSC N/A AREA MCCRDISTRIBUTION STATEMENT’ A. Approved for public release; distribution isunlimited.

Downloaded from http://www.everyspec.com

MIL-HDBK-818-1

FOREWORD

1. This military handbook is approved for use by allDepartments and Agencies of the Department of Defense.

2. Beneficial comments (recommendations, additions,deletions) and any pertinent data which may be of use inimproving this document should be addressed to: Space and NavalWarfare Systems Command, Code 231-2B2, Washington, D.C., 20363-5100, by using the self-addressed Standardization DocumentImprovement Proposal (DD Form 1426) appearing at the end of thisdocument or by letter.

3. This document provides guidance for the development offiber optic local area networks which are intended for use insupport of mission critical computer resources. It is acompanion document to MIL-STD-2204, the SAFENET standard.

ii


MIL-HDBK-818-1

CONTENTS

PARAGRAPH a

1. SAFENETOVERVIEW . . . . . . . . . . . . . . . . . . . . 11.1 Background . . . . . . . . . . . . . . . . . . . . 1l.2 Network features. . . . . . . . . . . . . . ...11.3 SAFENET profile . . . . . . . . . . . . . . . . . . 21.4 Profile selection . . . . . . . . . . . . . . ...2

2. SAFENET USER SERVICES.. . . . . . . . . . . . . . . ..52.1 Introduction . . . . . . . . . . . . . . . . . ..52.2 User services overview . . . . . . . . . . . . . . 52.3 Components of user services . . . . . . . . . . . . 11

3. NETWORK MANAGEMENT . . . . . . . . . . . . . . . . . . . 153.1 Introduction . . . . . . . . . . . . . . . . . . . 153.2 Network management overview . . . . . . . . . . . . 153.3 Limitations. . . . . . . . . . . . . . . . . . . . 19

4. SAFENET LIGHTWEIGHT APPLICATION SERVICE DEFINITION . . . 214.1 Introduction . . . . . . . . . . . . . . . . . . . 214.2 Service definitions . . . . . . . . . . . . . . . . 214.3 Lightweight application services . . . . . . . . . 22

5. NATO NETWORK INDEPENDENT INTERFACE . . . . . . . . . . . 375.1 Introduction . . . . . . . . . . . . . . . . . . . 375.2 NIIFservices. . . . . . . . . . . . . . . . . . . 385.3 NIIF specification . . . . . . . . . . . . . . . . 43

6. XTP Implementation Notes . . . . . . . . . . . . . . . . 476.1 Introduction . . . . . . . . . . . . . . . . . . . 476.2 Context Identification . . . . . . . . . . . . . . 476.3 Retry Frenzy . . . . . . . . . . . . . . . . . . . 476.4 Context Termination . . . . . . . . . . . . . . . . 476.5 Multicast Reliability . . . . . . . . . . . . . . . 48

7. SAFENET TRANSFER SERVICES . . . . . . . . . . . . . . . . 497.1 Introduction . . . . . . . . . . . . . . . . . . . 497.2 Traneport layer services . . . . . . . . . . . . . 497.3 Network layer services . . . . . . . . . . . . . . 527.4 Logical link control services . . . . . . . . . . . 54

8. SAFENET CONFIGURATION OPTIONS . . . . . . . . . . . . . . 558.1 Introduction . . . . . . . . . . . . . . . . . . . 558.2 Criteria for Selection . . . . . . . . . . . . . . 558.3 Fiber. . . . . . . . . . . . . . . . . . . . . . . 558.4 Cable topology . . . . . . . . . . . . . . . . . . 59

iii


MIL-HDBK-818-1

9.

10.

11.

12.

8.5 Network devices and connection options . . . . . . 60

SAFENET OPTICAL POWER BUDGET . . . . . . . . . . . . . . 639.1 Introduction . . . . . . . . . . . . . . . . . . . 639.2 Power budget calculations . . . . . . . . . . . . . 639.3 Repeater placement . . . . . . . . . . . . . ...70

SAFENET RECONFIGURATION AND SURVIVABILITY . . . . . . . 7310.1 Introduction. . . . . . . . . . . . . . . . . . . 7310.2 Background. . . . . . . . . . . . . . . . . . . . 7310.3 Survivability technique . . . . . . . . . . . . . 75

SAFENET SECURITY GUIDANCE . . . . . . . . . . . . . . . 8511.1 Introduction. . . . . . . . . . . . . . . . . . . 8511.2 Applicable Documents . . . . . . . . . . . . . . . 8511.3 Acronyms. . . . . . . . . . . . . . . . . . . . . 9211.4 Background. . . . . . . . . . . . . . . . . . . . 9311.5 Security design process . . . . . . . . . . . . . 9311.6 Threats and services . . . . . . . . . . . . . . . 9611.7 Standards . . . . . . . . . . . . . . . . . . . .1OO11.8 Architectural considerations . . . . . . . . . . . 108

SAFENETTIME SERVICE . . . . . . . . . . . . . . . . . . 11512.1 Introduction. . . . . . . . . . . . . . . . . . .11512.2 The SAFENET timescale . . . . . . . . . . . . . . 11512.3 Reference time. . . . . . . . . . . . . . . . . . 11612.4 SyStem configuration “. . . . . . . . . . . . . . . 11612.5 Performance parameters . . . . . . . . . . . . . . 11812.6 Network clock implementation . . . . . . . . . . . 11912.7 Management of the STS . . . . . . . . . . . . . . llg

..

iv


MIL-HDBK-818-1

LIST OF FIGURES

Figure 1. Alternate Profiles . . . . . . . . . . . . .Figure 2. Systems Management Interactions . . . . . .Figure 3. Management and the Application Layer . . . .Figure 4. Time Seguence Diagrams for SAFENET ServicesFigure 5. Location of NIIF in the 0S1 Reference ModelFigure 6. Connectionless Mode Data Transfer PrimitiveFigure 7. Connection Mode Data Transfer Primitives . .Figure 8. NIIF Management Primitives . . . . . . . . .Figure 9. NIIF Local Profile Model . . . . . . . . . .Figure 10. Diagram of the Minimum Link . . . . . . . .Figure 11. Diagram of the Variable Link . . . . . . .Figure 12. Basic Network Topology . . . . . . . . . .Figure 13. Basic Dual Homing Topology . . . . . . . .Figure 14. Dual Homed Topology . . . . . . . . . . . .Figure 15. Multiple Subnetwork Topology . . . . . . .Figure 16. Concentrator Tree Topology . . . . . . . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

3182023373941424465667475778082

Figure 17. The CascadeProblem~ . ~-. . . . . . . . . . . . 109Figure 18. The Nesting Problem . . . . . . . . . . . . . . . 109

LIST OF TABLES

Table I. Correlation Between Threats and Security Services. .101

v


MIL-HDBK-818-1

vi


1.

MIL-HDBK-818 -1

SAFENET OVERVIEW

1.1 Background. SAFENET is a network standard defined inMIL-STD-2204 . It defines standards for a set of components whichcan be used in subsystems of mission critical computer resources.Historically, Navy computers have usually been interconnectedwith point-to-point interfaces. However, the distributedarchitectures of modern Navy combat systems reguire a greaterdegree of system integration than’these point-to-point interfacescan support. For instance, the degree of connectivity of somesystems is currently limited by the number of 1/0 ports in thecomputers. The SAFENET standard was developed to solve theseconnectivity and system integration problems by providing thesecomputers with the capability to communicate with multipleapplication programs and devices over a single 1/0 port throughthe use of a computer network.

SAFENET provides standards for an integrated set ofcomponents for use in communication subsystems which use a localarea network (LAN) for intercomputer and computer to peripheraldata transfer. It is based on existing and proposed commercialnetwork standards to permit the use of commercial componentswhere applicable. The basic element of SAFENET is a dual-ringtoken passing LAN which interconnects the attached computers andperipherals.

1.2 Network features. In addition to reducing the numberof 1/0 ports required to achieve interconnectivity, SAFENETprovides several other features:

a. Flexible implementation - Except for the physical mediumspecification, the SAFENET standard does not restrictthe hardware aspects of an implementation in any way.All requirements (other than for physical medium) arein terms of logical interfaces and protocoldefinitions, which restrict software functionalityrather than the actual hardware. This means that aSAFENET interface can be implemented either as anembedded interface within a host computer, or as astand-alone interface unit to which devices can beconnected.

b. Survivability - SAFENET contributes to systemsurvivability by providing automatic fault isolationand reconfiguration as a function of its dual-ring LAN.Additional survivability may be required in someapplications, and SAFENET accommodates this possibilityby defining the physical topology components from which

1


MIL-HDBK-818 -1

a network nay be built, rather than defining thetopology itself.

c. Fiber optics - SAFENET employs a fiber optic transmissionmedium. This medium has many advantages over coppercable including low weight, high bandwidth, andinsensitivity to electromagnetic interference (EMI).

d. Multiple vendors - SAFENET is based on commercialstandards and does not reguire any proprietarytechnology. For these reasons it should be possible toobtain SAFENET compliant networks and components frommultiple vendors.

e. Coexistence with alternate 1/0s - Use of SAFENET on oneor more of a computers 1/0 ports should not interferewith that computer’s ability to communicate point-to-point over other 1/0 ports.

1.3 SAFENET Drofile. SAFENET employs a layered protocolarchitecture which is based on the ISO Open SystemsInterconnection (0S1) reference model (1S0 7498) for computernetworks. Within this layered architecture SAFENET specifies oneor more protocols at each layer. The complete set of SAFENETspecified protocols is known as the SAFENET profile.

SAFENET provides some implementation options in the form ofdifferent profiles. For instance, the 0S1 profile is availablefor full 0S1 compliant networking, while the lightweight profilecan be used to support real-time data transfer. A SAFENETstation may implement either of these profiles alone, or both ofthem (the combined profile). Note that both the 0S1 andlightweight profiles use the same token ring LAN for actual datatransfer. The concept of alternate 0S1 and lightweight profilesis illustrated in Figure 1.

SAFENET also provides flexibility in the implementation ofits physical topology. Rather than defining a limited number ofspecific topologies, components are defined from which to build anetwork. Thus the network may be designed for optimum use in anyspecific application.

1.4 Profile selection. The following paragraphs provideguidance on the selection of SAFENET profiles. It is intended tohelp system designers determine the appropriate profile for therequirements of their network.

1.4.1 Features common to all Drofiles. There are “severalfeatures which are common to all SAFENET profiles. Foremost

2


MIL-HDBK-818 -1

SAFENETUSER

0s1 LIGHTWEIGHT

PROFILE PROFILE

Figure 1. Alternate Profiles

among these is the local area network and the logical linkcontrol protocol. Because all SAFENET stations share commonprotocols through the physical and data link layers, it ispoesible to attach stations which imulement different Drofiles tothenotuse

thefor

same LAN. Of course, stations u;ing different pro?iles maybe able to interoperate, but they will be able to share theof the LAN.

Another important feature which is common to all profiles isSAFENET Time service. This service provides the capabilityall the stations on the LAN segment to synchronize their

clocks .

1.4.2 0S1 Drofile. The 0S1 profile is intended forsituations where either the interoperability of independentlydeveloped SAFENET nodes is a driving consideration, or thefunctionality of File Transfer, Access, and Management (FTAM) isrequired, or the system is of such complexity that networkmanagement is required. While the 0S1 profile provides thesecapabilities, it does so at the expense of increased data

3


MIL-HDBK-818 -1

transfer latency and an inability to send the same data tomultiple users simultaneously (multicast).

Within the 0S1 profile, the FTAM protocol provides robustfile transfer and management services. Additionally, the PrivateCommunication (Private Comm) interface provides a user with thecapability to directly establish connections with remote usersfor the purpose of passing messages. The services of the SAFENET0S1 profile can be used to support additional OSI-definedapplication.layer services such,ae” Message Handling System (MHS)(x.400), which provides an e-ma~l.capability. Some of theseservices may require extensions to the underlying presentationand session services. This is permissible as long as suchimplementations are interoperable with other implementations ofSAFENET at the intersection of their capabilities. Finally, thenetwork management services provide a user with the capability tomanage the network resources.

1.4.3 Lic?htweiqht urofile. The lightweight profile isintended for situations where either data transfer latency iscritical, or multicast data transfer is required, or systemspecific support services need to be implemented in place of 1S0standard session, presentation, and application layer services.While the lightweight profile provides these capabilities, itdoes so at the loss of the 1S0 standard protocols and networkmanagement mechanisms. Furthermore, since the lightweightprofile permits system specific implementation, interoperabilityis limited to those stations which have implemented identicallightweight profiles.

Within the lightweight profile, the lightweight applicationservice definition provides the user with streamlined access tothe transport layer services, while permitting the use of systemspecific support services at the application layer.Additionally, Xpress Transfer Protocol (XTP) and the 1S0Connectionless (CL) transport protocol are available forefficient, low latency data transfer, along with multicast datatransfer capabilities.

1.4.4 Combined Drofile. The combined profile is intendedfor situations where the capabilities of both the 0S1 andlightweight profiles are required. In the combined profile, allthe services and capabilities described above are available tothe user. In addition, this profile provides management supportfor the protocols which comprise the lightweight profile. Therobust functionality of the combined profile comes at the expenseof the complexity of the system and the cost of its development.

4


MIL-HDBK-818 -1

2. SAFENET USER SERVICES

2.1 Introduction. The purpose of this section is toprovide an overview of the application, presentation, and sessionlayers of SAFENET, which are collectively called the SAFENET userservices.

2.2 User services overview.

2.2.1 Assumptions and guidelines. The general assumptionsmade and guidelines followed in specifying ths SAFENET userservices and application interfaces are described below.

First, the physical implementation of the SAFENETenvironment has no effect upon the SAFENET environmentapplication interface. This does not mean that the physicalimplementation does not affect the SAFENET environment user, butonly that it does not affect the application interface to theSAFENET environment subsystem. For example, the actual physicalimplementation might affect the overall performance of theapplication Pro9ram involved and therefore might have to be takeninto account during program analysis and design.

Second, the physical location of the information objectsremote to a SAFENET environment user is transparent to that user.The global name or logical name is all that the user needs toknow. This information object might be resident in a peripheraldevice, a remote computer, or within the local computer itself.

Third, the user services perform all functions reguiringcommunication with remote nodes through the transfer services.This means that the only interface between the SAFENETenvironment users and the lower layers of the 0S1 reference modelis through the transfer services interface.

Fourth, all SAFENET environment users will be providedaccess to the capabilities of SAFENET either through the MAPaPPl~cation interface or through an application interfacespecific to the lightweight application services.

2.2.2 Conformance. interoDerabilitv and Performance. Theissues of conformance, interoperability, and performance need tobe considered at several levels in a system design. Thefollowing points are given as examples.

First, interoperability at the application layer interfaceusing a standard application layer protocol does not guaranteethat two processes in different application programs can operate

5


MIL-HDBK-818 -1

together. Information of the type found in InterfaceRequirements Specifications (IRSS) and Interface Design Documents(IDDs) are also required.

Second, the use of an application layer service such as FTAMor Directory Services may considerably ease the problem of makingtwo application programs operate together over a SAFENETenvironment.

Finally, performance neede to be considered from severalpoints of view, including the amount of capability orfunctionality offered by a eervice and the resources (e.g., time,memory, tranenission bandwidth) required to carry out thefunctionality.

It is the intent of SAFENET to offer the syetem designer anumber of options eo that an appropriate balance among the oftenconflicting system requirements for performance andinteroperability can be achieved. However, doing this in theface of the incomplete state of 0S1 standards and the GovernmentOpen Systems Interconnection Profile (GOSIP) upon which this workis based means that certain key components cannot be specified.Therefore, interoperability of all SAFENET functions is notguaranteed simply by conformance to current SAFENET definitions.

Two examples follow. First, the area of network managementservices is not adequately define”d. Second, time efficient userservices, tailored to current Navy practice in inter-processmeseage passing, do not exist in the 0S1 protocol set.Therefore, the concept of lightweight user services ie necessaryto permit the local definition of the needed servicee andprotocols. This represent a direct tradeoff of performance forinteroperability.

2.2.2.1 SAFENET environment structure. In discussing theissues of conformance, interoperability, and performance inSAFENET a brief discussion of the structure of a real open systemas it might appear in Navy applications using SAFENET isrequired. The real open systems of primary concern to SAFENETwill generally be found within the confines of a single ship orsubmarine. They will also be found in land-based test ordevelopment sites for the above.

Open systems for Navy applications will be designed underthe guidance of MIL-STD-490A and DOD-STD-2167A. These standardscall out a series of documente which together establish thefunctionality and performance requirements of the eystem orsubsystem being designed and implemented, how its componentsinteract with each other, and how the system and its components

6


MIL-HDBK-818 -1

interact with other systems or subsystems with which it nay bejoined to carry out higher level functions. These documentsinclude the System/Segment Specification (SSS) , SoftwareRequirements Specification (SRS), Software Top Level DesignDocument (STLDD), Interface Requirements Specification (IRS), andInterface Design Document (IDD). At the level of theapplication-program in an open system these establishconformance, interoperability, and performance requirements.They indicate the type, direction, and meaning of informationflow among system components. This-type of design information isa necessity whether the data transmission media is shared memory,a computer backplane bus, or a LAN eegment using SAFENETcomponents.

Issues of performance, interoperability, and conformance atthe system and application program level are the responsibilityof the system designer. SAFENET assists the system designer bysupplying data transmission components of known performancecharacteristics and interoperability upon which the system can bebuilt.

An open system using SAFENET components is considered to bebuilt of nodes. Depending on the complexity of the system thenodes may all be on one LAN segment or may be on a number of LANsegments interconnected by routers. In addition to usingSAFENET, the nodes may be connected through the use of othercommunication media. In addition to being connected to a SAFENETLAN segment a node could be connected to a non-SAFENET LANsegment so that it could process information from both sources.It is also possible that a single SAFENET LAN segment or a set ofinterconnected LAN segments could be shared by nodes belonging toseveral different independently developed syetems. These systemscould be completely separate, except for sharing the network, orthey could be cooperating in performing some higher level systemfunction.

2.2.2.2 Conformance. The term conformance is used in twodifferent senses. In the first sense it indicates whether aservice, function, or component is required in a node so that itmay be called a SAFENET node. In the second sense it means thatan item, if implemented, must be in accordance with itsspecification. In certain cases, to permit maximum tailoring tospecific user needs or because of the lack of adequate definitionin existing standards, SAFENET provides only a functionaldescription. In such cases, interoperability is a local matterand is solely the concern of the system designer and implementer.

2.2.2.3 InteroDerabilitv. Typical Navy mission criticalcomputer resource systems are composed of networks, or

7


MIL-HDBK-818 -1

hierarchies of independently developed systens, built bydifferent vendors under different constraints. Since options areavailable within the SAFENET standard there is a need to ensureinteroperability among component systems. A major impetus behindstandardization comes from the desire to have different vendor’sequipment communicate with each other.

As stated earlier, SAFENET constitutes a communicationarchitecture consisting of a set of standardized options whichwill be integrated into Navy systems. Interoperability cantherefore be achieved only when different nodes demonstrate thefollowing characteristics. First, the nodes share the sameprotocol stack. Second, the data flows established areconfigured with the same parameters. Third, policiesadministered throughout the network are implemented consistently.

At a different level, the phrase *,SAFENET interoperability’fmust be qualified by the system environment for which thecomponent is intended. Components designed for different systemarchitectures that include the sane protocols may be capable ofexchanging data but are not necessarily interoperable. Possibledesign tradeoffs involve issues such as performance, policy(including management policy), parameterization, operatingsystem, and implem.entation architecture (embedded or non-embedded) .

2.2.2.3.1 ADwlication DKOCeSS iniXKODe13bility. After theneed for and meaning of information interchange has beenestablished by an appropriate design document, interoperabilityamong different application processes, including those inapplication programs, on a SAFENET network is ensured byadherence to SAFENET protocols. Nodes which do not provide theMAP 3.0 application interface, along with any necessary userdefined interface, must then provide a defined interface to thelightweight application services. This then becomes the minimumlevel of functionality required for interconnection betweenapplication programs on .sIwmm’r. It must be noted that thislevel of functionality will not provide interoperability withouta further definition of at least directory service functions. Inthe current version of SAFENET this definition is a local matter.

2.2.2.3.2 LAN seem ent interoDerabilitv. Physical andlogical interoperability among SAFENET LAN segments and betweenSAFENET and non-SAFENET LAN segments can be accomplished with theuse of routers. For effective communication, the applicationprocesses must use common protocols and be in agreement as to themeaning of the communication. Interoperability betweenapplication Processes on different sAFENET LAN segments will befacilitated by common use of SAFENET protocols. Interoperability

8


MIL-HDBK-818-1

between SAFENET and non-SAFENET application processes nay also befacilitated through use of SAFENET protocols by both parties.Any other scheme for achieving interoperability is beyond thescope of SAFENET and will not be treated further in thisdocument.

2.2.2.4 Coexistence of 0S1 and liuh twe iaht protocols . Both0S1 and lightweight protocols can coexist in the same transferservices partition with the understanding that end-usercomponents which use either protocol will be able to communicateonly with end-user components using the same protocol. Access tothe 0S1 connection-oriented transport protocol can only be gainedthrough the MAP application interface. Accese to the lightweighttransport protocols, XTP and 0S1 connectionless transport, canonly be gained through the lightweight application services,which may be implemented to provide only those services requiredby a specific application. In many cases, it is expected thatthis application specific set of services will effectively allowdirect access to the desired lightweight transport service.

2.2.3 User services functions. The SAFENET user servicesare the vehicle through which the designer of a subsystem or realopen system using the SAFENET environment as a component providescommunication capabilities to an application program. The userservices, using the available lower layer functions of theSAFENET environment, provide the following capabilities within areal open system: information transfer, LAN node management, andsystem coordination. ,

It should be noted that in a specific system designadditional functions will usually be required and some of thefunctions listed may not be needed or may only be required in avery limited form. Non-SAFENET components may also participatein providing the above functions. Thus in order to balancetiming, cost, reliability, damage resistance, and other neededsystem properties a number of SAFENET and non-SAFENETcommunication options are needed. These permit the systemdesigner the capability of selecting the most suitable solutionto the requirements of the system being designed.

The remaining paragraphs in this section provide a briefdescription of the features of each of these functions. Notethat this functional view of an implementation of SAFENET has amany-to-many mapping to the components as they are implemented inaccordance with the 0S1 reference model.

2.2.3.1 Information transfer. The information transferfunction is concerned with the transfer of information amongSAFENET environment users. This information may consist only of

9


MIL-HDBK-818 -1

data, or it may indicate the need for, or cause, an action orchange of state of the user. Data which needs to be exchanged orshared may range from a simple message or set of variables tocomplex file structures. Timing requirements for theaccomplishment of the desired service can range from millisecondsto minutes and can be either real time or non-real time. Aspecific system may have a wide range of requirements. For thesereasons several different data transfer services are offered bySAFENET.

2.2.3.2 LAN node iuanaaement. The LAN node managementfunction is concerned with the control of the total set offunctions in a LAN node. This includes subfunctions such asenabling or disabling the LAN node in the SAFENET environment,reconfiguration within the LAN node in the SAFENET environmentoperations, local and network error monitoring and display, errorthreshold determination and assignment, and processing of localSAFENET environment status information.

2.2.3.3 Svstem coordination. The system coordinationfunction is concerned with the operation and synchronization ofthe real open system as a whole. This includes subfunctions suchas software reconfiguration within the system, downloading andinitialization of software across the SAFENET environment,communication coordination with peripheral devices connecteddirectly to the SAFENET environment, initial start-up proceduresof the system including its SAFENET environment, timesynchronization of users within the network, and global controlof the hardware, firmware and software contained within thesystem. It is also concerned with such issues as logical-nameregistration and resolution to physical N-address, prioritydefinition and assignment, and service type resolution.

2.2.4 Application vroqram computational model. It isexpected that in an open system of any complexity a variety ofcomputational models or designs will be required in theapplication Pro9ram to carrY out the needed functions. IfSAFENET user services are used at each node in such a system thenthe various implementations of the user services will have tointerface not only with each other through their transferservices but to the application programs with their varyingcomputational models.

The following has been assumed concerning the applicationprogram computational model in selecting the SAFENET userservices standards.

First, the SAFENET user services will be interfaced toapplication Programs which pre-date the definition of SAFENET to

10


MIL-HDBK-818-1

support the integration of existing combat system elements withnew elements. It will be, however, most frequently interfacedwith application-programs written specifically with SAFENET inmind.

Second, the SAFENETtasking environment thatcoordination.

user services will be used in a multi-supports inter-process communication and

Third, the SAFENET user services are targeted for use withapplication programs written in programming languages that Canassociate multiple data structures with the same data space. Thelanguage must also allow the users to define data types andcomplex data structures. Examples of euch languages are C andAda.

Finally, the design of the user services at any given timecannot address all possible application program requirements.Therefore it muet be extensible to meet new requirements.

2.3 Components of user services.

2.3.1 AuDlication laver. The ISO application layerprovides those services which are directly visible to the enduser. When the user ie a process or program an ApplicationProgram Interface (API) or set of calling sequences is needed toprovide access to the services offered by application layerservices. Since euitable standards were not available at thetime of publication of this document SAFENET does not requirestandard API~s for the application layer services it requiresexcept for the Private Communication interface derived from theMAP 3.0 specification. This is supplied to provide a simplemessage passing capability in the 0S1 profile. The followingsections provide a brief description of the SAFENET definedservices in the application layer.

2.3.1.1 Association Control Service Element. TheAssociation Control Service Element (ACSE) is a component of the0S1 profile which provides services for the establishment andtermination of application associations. ACSE is intended toprovide a standard service for applications to communicate commonparameters, such as titles, N-addresses and application context,during the request for an association.

2.3.1.2 Directorv services. In the 0S1 profile, theNational Institute of Standards and Technology StableImplementation Agreements directory system provides a repositoryfor information about network objecte. A typical directory userwould supply an application-entity title and get back the

11


MIL-HDBK-818 -1

presentation address of the entity. The typical directoryconsists of a Directory Information Base (DIB) , a directoryservice called the Directory System Agent (DSA) , and severalDirectory User Agents (DUAS).

The lightweight profile must also be supported with someform of directory services. How this capability is provided is alocal matter. This could be implemented within lightweight userservices as a fixed table provided as a part of the systemdesign, or as a dynamic eystem similar to the directory systemdiscussed above.

2.3.1.3 Private Communications. In the 0S1 profile, thePrivate Comm Application Interface is designed to supportcommunications between two application processes which need toexchange messages in a manner which requiree the fullfunctionality of the 0S1 profile. It allows applicationprocesses virtually direct access to the ACSE services for theestablishment of associations (connections) , and to thepresentation services for the exchange of data.

2.3.1.4 File Transfer, Access and Management. In the 0S1profile, the FTAM protocol provides a set of services fortransferring information conveniently between applicationprocesses and filestores. It supports several file typesincluding sequential, random access, and single key indexedsequential files. FTAM provides the ability to: work withbinary or text files, create and delete files, transfer entirefiles, read and change file attributes, erase file contents, andwork with specific records within a file.

2.3.1.5 Common Management Information Service Element.The Common Management Information Service Element (cMISE)provides a common message framework for management proceduressupplying both data-manipulation and notification/operation-oriented services.

2.3.1.6 Svstem Management ADD lication Service Element. TheSystem Management Application Service Element (SMASE) specifiesthe management functions which are eupported in a system node,and defines the semantics and abstract syntaxes of informationtransferred as relevant to 0S1 management.

2.3.1.7 Remote ODerations Service Element. The RemoteOperations Service Element (ROSE) provides a simple, uniformservice for remotely invoking operations and then receivingcorrelated replies to those operations.

12


MIL-HDBK-818-1

2.3.2 Presentation and session laver. In the 0S1 profilethe presentation and session layers must adhere to 0S1 standards.In the lightweight profile these layers are null.

2.3.3 Transfer services interface. The interface toSAFENET transfer services is based upon the NATO NetworkIndependent Interface (NIIF) whenever it is required to bedefined.

13


MIL-HDBK-818-1

14


MIL-HDBK-818 -1

3. NETWORK MANAGEMENT

3.1 Introduction. The purpose of this section is toprovide an overview of SAFENET network management.

3.2 Network management overview. The SAFENET architectureincludes a network management structure which supports thedevelopment of network performance measurement, fault tolerance,dynamic configuration control; and network security. Thisstructure is defined in ISO/IEC 7498-4 Management Framework andISO/IEC 10040 System Management Overview. While aspects ofnetwork management as defined by ISO standards are stillevolving, enough is stable to provide a sound and useful basisfor managing complex networks. The following subsections providean overview and general requirements derived from the currentNIST OIW Stable Implementation Agreements and from the underlyingISO standarde (1S0 7498, ISO/IEC 7498-4, ISO/IEC 10040, ISO/IEC10165-1).

3.2.1 Structure. Network management can be viewed as theset of operational and administrative mechanisms neceesary to:

a. bring up, enroll,b.

and/or alter network resources,keep network resources operational,

c. fine tune these resources and/or plan for theirexpansion,

d. manage the accounting of their use, ande. manage their protection from unauthorized use/tampering.

The structure provided in the current 1S0 standards and inthe NIST OIW Implementation Agreements is designed to support allthe above functions. The mechanisms included in the SAFENETprofile will primarily support a subset of the capabilities inthe first three areas.

A complete set of management capabilities in a networksystem will require 1S0 system management functions, 1S0 layermanagement functions, and local or system node managementfunctions. This last is outside the scope of the ISO standards.

System management in the 1S0 standards is based on thefollowing concepts:

f. managed objects,layer management,

:: managing applications,i. management agent applications,

15


MIL-HDBK-818 -1

j. capability in each instantiation of a communicationservice (or equipment) to carry out management actionsor provide management information,

k. protocols for communication between managingapplications and agent applications,

1. interfaces between the agent application and layermanagement entities in the same system node.

3.2.1.1 Manaaed obiects. A managed resource is anyresource such as a layer entity, a connection, or an item ofphysical communication equipment within the managed system thatis subject to management. A managed object is the abstractedview of such a resource that represents its properties as seenby, and for the purposes of, management. The ISO standardsinclude a subset (ISO/IEC 10165-1, 2, 4) which describe howobjects are to be defined. It is the responsibility of the groupdefining a communication service or device to provide thedefinition of the managed object classes required by that entity.The definition of a managed object class includes its attributes(for example the parameters which can be read or set), controlactions which can be taken on the real entity it represents, andnotifications of important events which can be transmitted to amanaging application. Thus the definition of the managed objectclasses relevant to an entity define the management operationswhich can be used with respect to that entity and thenotifications which the entity will make available to a managingprocess.

The set of managed object class definitions representing themanaged resources in a real open system is referred to as itsManagement Information Base (MIB). This is a conceptual groupingof all the information, actions, and notifications. It is notintended to imply any particular way of storing information. Inparticular it does not imply a central storage of allinformation.

The NIST OIW includes in its implementation agreements anon-nonnative appendix which provides the definitions of certainmanaged object classes. This listing is referred to as theManagement Information Library (MIL). Object definitions to beused in SAFENET are provided in MIL-STD-2204.

3.2.1.2 Laver management. The 1S0 architecture recognizesthat some management functions will need to be carried outprimarily within specific layers of a profile. The specificationof such functions is included in the standards for the layer inguestion. Any managed object definitions required should be inaccordance with the rules for defining managed objects as definedin MIL-STD-2204. In SAFENET, LAN station management (SMT) is an

16


MIL-HDBK-818 -1

important example of this. This is defined in FDDI SMT. Amongother things SMT controls the initialization and reconfigurationprocesses for the LAN. Nhile some aspects of this can becontrolled by system management much is carried out withoutdirect reliance on system management.

3.2.1.3 Manaaina aDD lication. System network managementwill be carried out by some combination of people and softwareimplementing system policy. The eoftware implementing orassisting people in implementing management policy may becentralized, federated, or distributed. The 1S0 standards allowfor all casee. The managing applications which make up thissoftware, and the definition of policies to be implemented bysuch software, are outside the scope of ISO communicationstandards. The 1S0 standards define the capabilities availableto carry out policy and provide the communication protocolsneeded. There may be a number of system nodes which containmanaging application procesees. Each one may, for example, beconcerned with a different aspect of system management (e.g.,security, fault recovery) or be concerned with managing a subsetof the nodes in the system.

3.2.1.4 Manaciement aaent process. An agent application isan application making use of system management services, whichfor a particular exchange of systems management informationperforms management operations on managed objects and emitsnotifications of events on behalf of managed objects. Thisdefinition and the standards allow for the case in which anapplication acts as both manager and agent. The same applicationprocess may take on the managing role and agent role in differentinstances of management communication.

In the 0S1 profile each SAFENET LAN node should have amanagement agent process. This agent process ehould carry outall supported management interactions with the managed objects inthe LAN node of which it is a part. The management interaction(cervices) supported are defined in MIL-STD-2204. Figure 2 showsthe relationships between a process acting in the manager roleand one acting in the agent role. Layer management or localmanagement functions is not shown in this figure.

3.2.1.5 Laver mana.aement entities. Any instantiation of acommunication service should provide the capability to carry outmanagement actions and provide the management informationspecified in the definition of the managed object classesrelevant to it. The instantiation of theee capabilities isreferred to as the layer management entity. The SMT of FDDI isan example of a layer management entity. The layer managemententity does not have to be a separately defined and identified

17


MIL-HDBK-818 -1

F~:: 8.,=,MANAGING MANAGED OSJECTS

OPEN SYSTEM

COMMUNICATIONS MANAGED

OPEN SYSTEM

Figure 2. Systems Management Interactions

part of an implementation.

The managed object class definition provides the semanticsand syntax of the information, and describes actions which thecommunication object may be required to carry out and the eventsfor which it will generate notifications. The specification ofthe layer management entity interface to the local managementagent application is a local matter. If both are softwareentities, then the interface may be the eubject of otherstandards.

3.2.1.6 Svstem management communication Drotocols. The ISOstandards provide the communication protocols and servicedefinitions for interchanges between applications acting in themanaging and agent roles. That portion of the applicationprocess which implements these standards and is logically a partof the application layer is called the System ManagementApplication Entity (sMAE). Figure 3 shows application layerservices that are included in the SMAE. The SMAE includes themanagement services and protocols defined by the ISO etandardswhich are used by an application process acting in the manager

18


MIL-HDBK-818 -1

role, agent role, or both. The 1S0 standards do not define theapplication interfaCe between the SMAE or its components and theremaining functions of the management application process. TheSMAE is logically comprised of Common Management InformationService Element (cMISE), System Management Application ServiceElement (SMASE), Remote Operation Service Element (ROSE), andAssociation Control Service Element (ACSE). These last twoapplication service elements are also intended to be used byother application layer capabilities (for example FTAM anddirectory services). In addition to the services included in theSMAE a system management application process may make use ofother services such as FTAM. An instantiation of the SMAE mayalso contain locally defined capabilities such as the mechanismfor gaining access to local managed objects. The 1S0 standardsdo not specify whether or how managing processes in differentsystem nodes will communicate with each other when multiplemanagers exist in a system. Within the scope of SAFENET, FTAM orthe Private Communications application interface could be usedfor this purpose. Capabilities defined in other 1S0 applicationlayer standards such as Transaction Processing (ISO/IEC 10026parts 1-4) could also be used but are outside the ecope ofSAFENET. The components of the SNAE are defined in MIL-STD-2204.

3.2.1.7 Local interfaces. The means by which anaPPl~cation actin9 in either the managing role or the agent rolecarries out management operations or receives notificationswithin the system node in which it is resident is a local matter.The exception to this is when the Network Independent Interface(NIIF) is reguiredr in which case management information shouldbe passed between lower layer entities and the application bymeans of the NIIF management operations.

3.3 Limitations. A conforming implementation of SAFENETshould provide mechanisms for carrying out network management.Some capabilities, such as providing selected fault detection andrecovery functions, are inherent in the layer standardsthemselves and are available whenever the layer standard isimplemented. For example, a conforming FDDI implementationautomatically reconfigures to recover from certain breaks in thecable plant. As outlined in the following paragraph, thecomplete provision of network management in a system reguiresmuch additional capability beyond that supplied if only thefunctions and mechanisms specified in the SAFENET profile areimplemented.

System designers and implementors using components based onSAFENET need to establish their requirements for the way in whichnetwork components are interconnected, and for capabilities suchas system initialization, dynamic configuration control, fault

19


MIL-HDBK-818 -1

MANAGEMENT APPLICATION PROCESSES(MANAGERJAGE~

..-----.------

IMPLEMENTOR SPECIFIED APPLICATION INTERFACES

---------------_. SAFEN=

SMAEDIRECTORY

UGllTbYEIGHT USEFIs

SERVICES

H

APPUCATIONSERVlCE5

ACSE CMISE T SERWOE,—ATION

s IMPLEMENTORMm

ROSE SMASEOEFINEO

Frm MANAGEMENT

CAPABIUIY

------------------

Figure 3. Management and the Application Layer

detection and recovery, survivability, ~afety, se~urity, and timeof day distribution which are supported by network management.The selection of the components to be connected to the network,the network topology, and the management policies to beimplemented in managing processes will determine the extent towhich system requirements can be achieved by a LAN based on theSAFENET profile. The selection process, management policies, andthe functions implemented in managing processes are outside thescope of this handbook.

20


MIL-HDBK-818 -1

4. SAFENET LIGHTWEIGHT APPLICATION SERVICE DEFINITION

4.1 Introduction. The purpose of this section is toprovide guidance on the implementation of the SAFENET LightweightApplication (SLd) service definition.

4.2 Service definitions. The SLA services provide servicedefinitions in accordance with ISO/IEC TR 8509. Elements of aservice definition are described below.

4.2.1 Service Primitives. A service primitive is anabstract, implementation independent representation of aninteraction between a service user and the service provider. Aprimitive has associated with it a direction, which may be from aservice user to the service provider or from the service providerto a service user, and one or more parameters. The four types ofprimitives used in SAFENET service definitions are listed below:

a. Request: An interaction in which a service user requestssome action of the service provider. The directionassociated with this primitive type is from serviceuser to service provider.

b. Indicate: An interaction in which the service providerindicates to a service user that it has performed someaction. The action performed may have been initiatedeither by the service provider itself or by a serviceuser at a remote service access point. The directionassociated with this primitive type is from serviceprovider to service user.

c. Response: An interaction in which a service user reportsto the service provider that it has completed someaction in response to an indicate primitive. Thedirection associated with this primitive type is fromservice user to service provider.

d. Confirm: An interaction in which the service providerreports to a service user the completion of some actionpreviously initiated by a request primitive. Thedirection associated with this primitive type is fromservice provider to service user,.

4.2.2 Service parameters. Each primitive of a particularservice has associated with it a set of service parameters, andeach of these parameters has a particular applicability.Parameter definitions are provided along with the specific

21


service definitionsused in SAFENET are

MIL-HDBK-818 -1

(see 4.3.1.1). The parameter applicabilitiesdescribed in the following paragraph.

4.2.3 Parameter aDDliCabilitieS. Associated with eachparameter used in the service primitives is an applicabilitywhich describes that parameters status with respect to theprimitive in which it is named. The applicabilities relevant tothe primitives of SAFENET service definitions are listed below:

a. Mb. Uc. =

indicates the parameter is mandatory)indicates the parameter is user optional)indicates that the value supplied in an indication or

confirm primitive is always identical to thatsupplied in the previous reguest or responseprimitive issued at the peer service access point)

d. NA (indicates the parameter is not applicable)

4.2.4 Time-seau ence diaqrams. Time-sequence diagrams areused in conjunction with service definitions to illustrate theinteractions of service primitives over time. The time-sequencediagrams which apply to SAFENET services are shown in Figure 4.

4.3 Liqhtweiaht aDD lication services. The SLA servicedefinition describes services which can be provided by thelightweight profile to a SAFENET user. These services aredivided into two categories: data transfer services anddirectory services. The lightweight data transfer services areservices which are essentially exported from the transport layerto the application layer (see 4.3.2). The lightweight directoryservices include registration and deletion of both individual andgroup logical names (see 4.3.3). In any application in which aprocess should be coded independent of its own network address orof the network addresses of processes with which it mustcommunicate, a directory service capability is required. Most ,if not all, fault tolerant designs have this as a requirement.Thus it is expected that implementations of the SAFENETlightweight suite will implement both a data transfer service anda matching directory service.

4.3.1 Liqhtweiaht service Parameters. The parametersassociated with the lightweight application service primitivesand the selections associated with the QOS parameter are definedbelow. See 4.2 for additional information on primitives,parameter applicabilities, and time-sequence diagrams.

4.3.1.1 Licrhtweiqht service narameter definitions. Thedefinitions of the parameters used in the lightweight applicationservice definition are given in the following paragraphs.

22


MIL-HDBK-818 -1

-t-’-4-nreqwst

Indicate

-+’’’r””‘NMkate

Figure3(a) Figure3(b)

Figurs3(c) Figure 3(4

‘$Olnfinn

Figure3(e)

F’i~ure 4. Time Sequence Diagrams for SAFENET Services

23


MIL-HDBK-818 -1

4.3.1.1.1 Connect-ID. This value is used to identifyuniquely the local end of a connection.

4.3.1.1.2 Disconnect-Mode. This specifies to the serviceprovider the mode of disconnect desired. The two possible modesare graceful and immediate. The graceful node specifies that theuser expects any data pending on the connection to be deliveredbefore the connection is terminated, and the immediate modespecifies that the connection should be terminated withoutattempting to deliver any additional data.

4.3.1.1.3 Dst-Lo~ical-Name. “’This logical name is used toidentify the destination entity in a peer to peer servicerequest.

4.3.1.1.4 Grouv-Name. This logical name is used to specifya multicast group.

4.3.1.1.5 Loaical-Name. This name uniquely identifies anapplication entity and freeS the application user from the burdenof having to specify complete network addresses.

4.3.1.1.6 MembershiD-List. This list of application entitylogical names is used as a mechanism for restricting membershipin multicast groups.

4.3.1.1.7 Messaqe. This is”a single unit of user data. Norestrictions on the size or content of a message are defined herenor are there intended to be any implications on transmissioncharacteristics such as reliability.

4.3.1.1.8 ~. This set of selections is used to specifyto the service provider the quality of service expected by theuser of a given service primitive. The QOS selections may beeither absolute requirements or indications to the serviceprovider of the relative importance of the request.

4.3.1.1.9 Reason This parameter is used to identify thenature of a fail~~est or aborted connection.

4.3.1.1.10 Reou est-ID. This parameter is used to identifythe local end of a unitdata transfer request. It is used toidentify uniquely the recipient of an asynchronous notification.

4.3.1.1.11 Requ est-Messaqe. This is a message associatedwith a transaction request primitive.

4.3.1.1.12 ReSDOnSe-MeSSacfe. This is a message associatedwith a transaction response primitive.

24


MIL-HDBK-818 -1

4.3.1.1.13 Result This parameter is used to report thesuccess or failur-”service reguest.

4.3.1.1.14 Src-Loqical-Name. This parameter is used tospecify the logical name of the service user invoking aprimitive.

4.3.1.1.15 .Status. This parameter is used to indicatedelivery status information to lightweight service users.

4.3.1.1.16 Transaction-ID. This parameter is used toidentify uniquely the local end of a transaction. This parameteris used by the service provider to associate a reguest andresponse(s) .

4.3.1.1.17 T-Service. This parameter is used in theunitdata primitives to specify the use of the 1S0 connectionlesstransport protocol instead of the default XTP.

4.3.1.1.18 XTP-Control. The following parameters specifyoptions or mechanisms offered by XTP that could be useful to anapplication. In all cases there must be default modes or values,should an application not epecify them, so that the protocol willoperate properly.

4.3.1.1.18.1 Checksum. This parameter enables/disables thedata checksum within an XTP or CLTP packet. Because of theprocessor time required to calculate the data checksum, anapplication may choose to disable the checksum function. Notethat this parameter is applicable to both XTP and CLTP.

4.3.1.1.18.2 Flow-Control. This parameter determineswhether flow control is used by XTP to limit the amount of datathat can be transmitted before it is acknowledged.

4.3.1.1.18.3 Aqcrressive-Acknowledgement. This parameterallows the receiver of data to respond with an acknowledgement ofa missing packet as soon as it receives an out of order packet,rather than waiting for an acknowledgement request from thesender.

4.3.1.1.18.4 Reservation. This parameters mandates the useof flow control based on available application buffer spaceinstead of XTP buffer space.

4.3.1.1.18.5 SDecial-Data. This parameter specifies aneight octet value, supplied by the application, to be transferredto the receiver(s) in the btag field of an XTP packet, anddelivered to the receiving application(s).

25


MIL-HDBK-818 -1

4.3.1.1.18.6 Acknowledgement-Policv. This parameterspecifies the means by which data transmission will bea&nowledged. This p~rameter is divided into

a) the granularity of acknowledgements -messages, or once, andb) the number of granularity units to bean acknowledgement is reguested.

two patis:

octets, packets,

transmitted before

4.3.1.1.18.7 Rate-Control. This parameter allows thereceiver to specify a transmission data rate to the sender. Thiscan be used to prevent overflow of a elow receiver because of afaster transmitter.

4.3.1.2 Qualitv of service selections. The quality ofservice (QOS) parameter is defined to be a set of values fromwhich the lightweight application service ueer should select tospecify to the service provider certain performance andreliability characteristics. Each selection may be furtherqualified to indicate to the service provider whether theselection imposes an absolute requirement on transmissioncharacteristics or is simply guidance to the service provider.The set of available selections depends upon the service beingrequested. The QOS selections available to the user and theservices to which thev apDlv are shown in Table II. These QOSselections are define: b~io;.

Table II. Quality of Service Selections

QOS Selections

Service I SAC I TD

SLA-CONNECTSLA-DISCONNECTSLA-STREAM-DATASLA-UNITDATASLA-MCAST-UNITDATASLA-MCAST-STREAMSLA-TRANSACTIONSLA-NOTIFY

x

xxxx

xxxzNXL PR

x xxxxxx

x xx

4.3.1.2.1 Selectable acknowledqm ent control [SAC) Thisselection provides a mechanism for a user to specify the desiredlevel of acknowledgment control. The two primary settinge areacknowledged transfer and unacknowledged transfer. Acknowledgedtransfer here indicates acknowledgement by the peer service

26


MIL-HDBK-818 -1

provider. h implementor may provide for intermediate levels ofacknowledgement in the case of multicast transfers. That is, themulticast may be considered a euccees if some subset of the totalpotential set of transfers is successful.

4.3.1.2.2 Transit delav (TD). This selection specifies amaximum time for delivery of a single message to a remote user.

4.3.1.2.3 Maximum latencv (MXL). Thie selection specifiesa maximum time between a requeet and its corresponding confirm.

4.3.1.2.4 Priority 7PRL. This selection epecifies thepriority of the primitive relative to other transfer requests.

4.3.2 Liahtweiaht data transfer servicee. The lightweightdata transfer services are those services which apply directly tothe transfer of messages between two or more lightweightapplication service users. These services are all supported byXTP . Only the SLA-UNITDATA and SLA-MCAST-UNITDATA services aresupported by the 1S0 connectionless transport protocol.

4.3.2.1 SLA-CONNECT service. The SLA-CONNECT serviceallows a service user to establish a connection between itselfand another service user for the purpose of exchanging data.upon successful completion of the connection establishment, aconnection ID should be supplied to the user by the serviceprovider to identify the local end of the connection. As a meansof identifying the connection in the event that a disconnectneeds to be initiated by the service provider before theconnection is established, the service user should propose aconnection ID. Multiple connections may exist simultaneouslybetween the same peer service users. Once a connection is made,the peer service users may exchange messages over the connectionwith the assurance that all messages should be deliveredcorrectly and in the order in which they were submitted. Theservice user has the option of sending data along with theconnection request. If this option is used, the service providershould not wait for a successful connection to be established butinstead should attempt to deliver the user’s data along with theconnect indicate. The QOS selections which apply to thisprimitive are selectable acknowledgment control, maximum latency,and priority.

4.3.2.1.1 SLA-CONNECT Primitives. The service primitivesused to describe the SLA-CONNECT service should be request,indicate, response, and confirm. Their interactions are shown inthe time-sequence diagram of Figure 4(a) (see 4.2.4).

27


MIL-HDBK-818 -1

4.3.2.1.2 SLA-CONNECT Parameters. The SLA-CONNECT serviceparameters and their applicabilities should be as listed below:

Parameter NameSrc-Logical-NameDst-Logical-NameConnect-ID@3sMessageChecksumFlow-ControlAggressive

AcknowledgementReservationSpecial-DataAcknowledgement

-PolicyRate-Control

Reouest1.!MMuuuu

uuu

uu

Indicate..M.——NANA

NA..

NANA

ReSDOIISeMM.

.

NANANA

NANANA

NANA

Confirm..M——NANANA

NANANA

NANA

4.3.2.2 SLA-DISCONNECT service. The SLA-DISCONNECT serviceallows either an application service user to terminate anexisting connection between itself and another service user(called a normal close), or the service provider to terminate anexisting connection between peer eervice users (called anabnormal close) . The reason parameter should indicate at aminimum whether the connection is being closed normally orabnormally. A normal close shoul”d occur when the service userdetermines that the connection is no longer needed, while anabnormal close should be initiated by the service provider inresponse to an error condition or the inability to maintain thereguired level of service. The only QOS selection which appliesto this service is priority.

4.3.2.2.1 SLA-DISCONNECT Primitives. The serviceprimitives used to describe the SLA-DISCONNECT service should berequest and indicate. Their interactions are shown in the time-seguence diagrams of Figure 4(b) for a normal close, and Figure4(c) for an abnormal close (see 4.2.4).

4.3.2.2.2 SLA-DISCONNECT Parameters. The SLA-DISCONNECTservice parameters and their applicabilities should be as listedbelow:

Parameter Name Reou est IndicateConnect-ID M MDisconnect-Mode u .Reason NA M

28


UIL-HDBK-818 -1

4.3.2.3 SLA-STRE AM-DATA service. ‘The SLA-STREAM-DATAservice allowe peer service users to exchange data overpreviously established connections. The service providerguarantees that the user’s data is delivered to the receivingentity in the same order in which it was submitted and that thedata is delivered reliably within the quality of serviceselections set during connection establishment. A disconnectinitiated by the service provider should inform the user when thereliable delivery eervice cannot be provided or when any reguiredQOS constraints can no longer be met. Priority is the only QOSselection which may be set on individual stream-data requests.Specifying this selection should not affect the ordering of datatransferred over the connection: however, the current priority ofthe connection may be varied over time using this option.

4.3.2.3.1 SLA-STREAM-DATA Primitives. The serviceprimitives used to describe the SLA-STRi?AM-DATA service should berequest and indicate. Their interactions are shown in the tine-sequence diagram of Figure 4(b) (see 4.2.4) .

4.3.2.3.2 SLA-STREAM- DATA Parameters. The SLA-STREAM-DATAservice parameters and their applicabilities should be as listedbelow:

Parameter Name Reau est IndicateConnect-ID M HQOS u .Message u .Special-Data u .Rate-Control u NA

4.3.2.4 SLA-UNITDATA service. The SLA-UNIT-DATA serviceallows peer service users to exchange messages without theoverhead of maintaining a connection. This service should notprovide for the ordered delivery of messages transferred betweenthe same two service users. The QOS selections which apply tothe unitdata service are selectable acknowledgment control,transit delay, and priority. Failure to meet these requirementsshould be reported to the user via the notify service.

While XTP should be the default provider of this service,the user may alternately select the 1S0 connectionless transportprotocol as the service provider. If 1S0 connectionlesstransport is selected the user should ensure that the messagebeing transferred will fit within the constraints of the datafields of the underlying data transfer protocols.

4.3.2.4.1 SLA-UNITDATA Primitives. The service primitivesused to describe the SLA-UNITDATA service should be request and

29


MIL-HDBK-818 -1

indicate. Their interactions are shown in the time-sequencediagram of Figure 4(b) (see 4.2.4).

4.3.2.4.2 SLA-UNITDATA Parameters. The SLA-UNITDATAservice parameters and their applicabilities should be as listedbelow:

Parameter NameSrc-Logical-NameDst-Logical-NameQosRequest-ID‘T-ServiceMessageChecksumSpecial-Data

RequestMMuMuMuu

Indicate...M..NA.

4.3.2.5 SLA-MCAST-UNITDATA service. The SLA-MCAST-UNITDATAservice allows a service user to exchange messages with membersof a multicast group. The service provider should attempt todeliver the message to each active member of the multicast group.The QOS parameters which apply to this service are electableacknowledgment control, transit delay, and priority. Failure tomeet these requirements should be reported to the user via thenotify service.

While XTP should be the default provider of this service,the user may alternately select the 1S0 connectionless transportprotocol as the service provider. If 1S0 connectionlesstransport is selected the user should ensure that the messagebeing transferred will fit within the constraints of the datafields of the underlying data transfer protocols.

4.3.2.5.1 SLA-MCAST-UNITDATA Primitives. The serviceprimitives used to describe the SLA-MCAST-UNITDATA service shouldbe a request followed by zero or more indicates. Theirinteractions are shown in the time-sequence diagram of Figure4(d) (see 4.2.4).

4.3.2.5.2 SLA-MCAST-UNITDATA Parameters. The SLA-MCAST-UNITDATA service parameters and their applicabilities should beas listed below:

30


MIL-HDBK-818 -1

Parameter NameSrc-I.ogical-NameGroup-NameQOSReguest-IDT-ServiceMessageChecksumSpecial-Data

ReouestMMuMuMuu

Indicate...M..NA.

4.3.2.6 SLA-MCAST-STREAM service. The SLA-MCAST-STREAMservice allows a user to establish a connection with groupmembers and send data over the connection. The service providerguarantees that the user’s data is delivered to the group in thesame order in which it was submitted. The reliability is basedon the XTP multicast reliability paradigm and, with selectableacknowledgement control set to acknowledged, will guaranteedelivery to at least one of the group members with a high degreeof confidence of delivery to other active group members. The QOSselections which apply to this service are selectableacknowledgement control, maximum latency, and priority.

4.3.2.6.1 SLA-MCAST-STREAM primitive. The serviceprimitives used to describe the SLA-MCAST-STREAM shall be arequest followed by one or more indicates. Their interactionsare shown in the time-sequence diagram of Figure 4(d) (see4.2.4).

4.3.2.6.2 SLA-MCAST-STREAM parameters. The SLA-MCAST-STREAM service parameters and their applicabilities shall be aslisted below:

Parameter NameSrc-Logical-NaneGroup-NameQOSConnect-IDMessageChecksumFlow-ControlAggressive AcknowledgementReservationSpecial-DataAcknowledgement-PolicyRate-Control

Re ouestMMuMMuuuuuuu

Indicate...M——NANANA..NANA

4.3.2.7 SLA-TRANSACTION service. The SLA-TRANSACTIONservice allows a service user to initiate a reguest/responsesequence with a peer service user. The response may optionally

31


MIL-HDBK-818 -1

contain a user message. The service provider should beresponsible for associating the request and response and ensuringthe completion of the service within the QOS selectionsepecified. The orderly delivery of requeste with identicalquality of service from a source eervice user to a destinationservice user should be guaranteed. The parameter transaction-IDis similar to a connection-ID in that it is a local identifierand is used to match the transaction response to the transactionreguest. The notify service may be used to inform the user of aninability to complete successfully the transaction service withinany reguired QOS constraints. The QOS selections which apply tothe transaction service are selectable acknowledgment control,maximum latency, and priority.

4.3.2.7.1 SLA-TRANSACTION primitives. The eerviceprimitives used to describe the SLA-TRANSACTION service should berequest, indicate, response, and confirm. Their interactions areshown in the time-seguence diagram of Figure 4(a) (see 4.2.4) .

4.3.2.7.2 SLA-TRANSACTION Parameters. The SIA-TRANSACTIONservice parameters and their applicabilities should be as listedbelow:

Parameter NameSrc-Logical-NameDst-Logical-NameQOSReguest+fessageTransaction-IDRequest-IDResponse-MessageChecksumSpecial-Data

ReouestMMuMMFlNAuu

Indicate.=..

MMNANA.

ReSDOIISE!HM.

NA.——uNANA

Confirm...

NAM..NANA

4.3.2.8 SLA-NOTIFY service. The SLA-NOTIFY eervice is usedto provide service users with information concerning datagram andtransaction reliability. This service should minimally advisethe user of failures by the transaction or unitdata cervices. Inaddition, in the case of multicast services, the notify primitiveshould be used to provide the user with information on partialdelivery status. The only QOS selection applicable to thisservice is priority.

4.3.2.8.1 SLA-NOTIFY primitives. The service primitiveused to describe the SLA-NOTIFY service should be indicate. Itstime-sequence diagram is shown in Figure 4(c) (eee 4.2.4).

4.3.2.8.2 SLA-NOTIFY Parameters. The SLA-NOTIFY serviceparameters and their applicabilities should be as listed below:

32


MIL-HDBK-818 -1

Parameter Name IndicateRequest-ID l.!Status MReason M

4.3.3 Licfhtweiqht directorv services. The lightweightdirectory services describe functions which are not provided bythe traneport layer protocols of the lightweight profile, butwhich are necessary for use of the lightweight data transferservices. The directory services provide two types offunctionality. The first is logical name to address mappingwhich frees the user from ‘the burden of having to know andspecify fully gualified addresses for peer to peer processcommunication. The second function is to provide the capabilityfor minimal group management. If a system uses only the combinedprofile, 0S1 directory services may be used to provide thisfunctionality. In all other cases lightweight directory servicesand 0S1 directory services should be independent.

The use of multicast transport services will reguire theimplementation of all the directory services listed below. Ifonly point to point services are used then only the SLA-REGISTERand SLA-CANCEL services are required.

This section lists the services to be supplied, but does notprovide the protocols which will be needed in many cases toimplement theee services when only the lightweight suite isimplemented. AI-Iexplicit protocol and explicit implementation ofthe services are not required if static tables are used toprovide mapping. In general, static tables supply very limitedfault tolerance and will usually not be satisfactory in missioncritical applications where fault tolerance is important.

4.3.3.1 SLA-REGISTER service. The SLA-REGISTER serviceallows an application process to identify itself to the network.Associated with each logical name in the local entity’s databaseshould be the names of any multicast groups to which it belongs.An application process may register more than one logical name,but the logical names for each registration should be unique.Once an application process has identified itself to the network,it may begin exchanging messages with other application processesvia its logical name.

4.3.3.1.1 SLA-REGISTER Primitives. The service primitivesused to describe the SLA-REGISTER service should be request andconfirm. Their interactions are showndiagram of Figure 4(e) (see 4.2.4).

in the time-se~-ence

33


MIL-HDBK-818 -1

4.3.3.1.2 SLA-REGISTER parameters. The SIA-REGISTERservice parameters and their applicabilities should be as listedbelow:

Parameter Name Reouest ConfirmLogical-Name M .Result NA M

4.3.3.2 SLA -CANCEL service. The SIA-CANCEL service allowsan application process to remove its logical names from thenetwork. Once an application process has removed its name ornames completely from the network, it should not be allowed toexchange data with other application processes. All openconnections involving the withdrawing application process shouldbe closed as a result of the completion of this service.

4.3.3.2.1 SLA-CANCEL ?mimitives. The primitives used todescribe the SLA-CANCEL service should be reguest and confirm.Their interactions are shown in the time-sequence diagram ofFigure 4(e) (see 4.2.4).

4.3.3.2.2 SLA-CANCEL parameters. The SLA-CANCEL serviceparameters and their applicabilities should be as listed below:

Parameter Name Reouest ConfirmLogical-Name M .Result NA M

4.3.3.3 SLA-OPEN-GROUP service. The SLA-OPEN-GROUP serviceallows an application process to establish a new multicast group.This service should identify the new group name to the networkand establish the requesting application process as the firstmember of the newly opened multicast group. An applicationprocess may send messages to any group, but it should onlyreceive messages addressed to one of the groups to which itbelongs. The application process which opens the multicast groupshould have the ability to restrict membership in that group byincluding a group membership list which should be consulted whena join reguest is issued. If a non-null membership list isassociated with the group, an application should not be permittedto join unless its logical name appears in the membership list.

4.3.3.3.1 SLA-OPEN-GROUP Primitives. The serviceprimitives used to describe the SLA-OPEN-GROUP service should bereguest and confirm. Their interactions are shown in the time-sequence diagram of Figure 4(e) (see 4.2.4).

34


MIL-HDBK-818 -1

4.3.3.3.2 SLA-OPEN-GROUP parameters. The SLA-OPEN-GROUPservice parameters and their applicabilities should be as listedbelow:

Parameter Name Reouest ConfirmLogical-Name M ——Membership-List u NAGroup-Name l’1 .Result NA M

4.3.3.4 SLA-CLOSE-GROUP service. The SLA-CLOSE-GROUPservice providee the user with the capability to delete a groupfrom the network.

4.3.3.4.1 SLA-CLOSE-GROUP primitives. The serviceprimitives used to describe the SLA-CI.OSE-GROUP service should berequest and confirm. Their interactions are shown in the time-seguence diagram of Figure 4(e) (see 4.2.4) .

4.3.3.4.2 SLA-CLOSE-GROUP Parameters. The SLA-CLOSE-GROUPservice parameters and their applicabilities should be as listedbelow:

Parameter Name Reouest ConfirmLogical-Name M ——Group-Name M ——Result NA M

4.3.3.5 SLA-JOIN-GROUP service. The SLA-JOIN-GROUP serviceallows an application process to add itself to a multicast group.This service should establish the requesting application processas an active member of the desired multicast group. happlication process may send messages to any group, but it shouldonly receive messages addressed to one of the groups to which itbelongs. If the group is a restricted group, the logical name ofthe application process issuing the join request should have toaPPear in the membership list in order to gain admittance to thegroup.

4.3.3.5.1 SLA-JOIN-GROUP Primitives. The serviceprimitives used to describe the SLA-JOIN-GROUP service should bereguest and confirm. Their interactions are shown in the time-sequence diagram of Figure 4(e) (see 4.2.4) .

4.3.3.5.2 SLA-JOIN-GROUP parameters. The SLA-JOIN-GROUPservice parameters and their applicabilities should be as listedbelow:

35


MIL-HDBK-818 -1

Parameter Name Reouest ConfirmLogical-Name M .

Group-Name M ——Result NA F!

4.3.3.6 SLA-LEAVE-GROUP service. The SLA-LEAVE-GROUPservice allows an application process to leave any multicastgroup to which it belongs. This service should remove therequesting application process from the active membership list ofthe specified multicast group.

4.3.3.6.1 SLA-LEAVE-GROUP Primitives. The serviceprimitives used to describe the SLA-LEAVE-GROUP service should berequest and confirm. Their interactions are shown in the tine-seguence diagram of Figure 4(e) (see 4.2.4) .

4.3.3.6.2 SLA-LEAVE-GROUP Parameters. The SLA-LEAVE-GROUPservice parameters and their applicabilities should be as listedbelow:

Parameter Name Re ouest ConfirmLogical-Name M .Group-Name M .Result NA M

36


MIL-HDBK-818 -1

5. NATO NETWORX INDEPENDENT INTERFACE

5.1 Introduction. The NATO Network Independent Interface(NIIF) defines the complete interface between a user systemimplementing 0S1 layer; 5-7 and a Data Transfer System- (DTS)imDleInentina 0S1 lavers I-4, as shown in Fiaure 5. Note that aus~r system-(as defined here) corresponds t; SAFENET userservices, and a DTS corresponds to SAFENET transfer services plusLAN services. In this section, the terms user system and datatransfer system will be used to conform with the NATO documents, .

USER SYSTEM A

APPUCATION IPRESENTATION I

SESSIONI

ETRANSPORT

NETWORK

DATA UNK

PHYSICM

USERSYSTEMB

II APPUCATION I

l=TRANSPORT

NETWORK

DATA UNK

PHYSICALL 1 I J

4A 4

DATATRANSFER SYSTEM(DTS) F

Figure 5. Location of NIIF in the 0S1 Reference Model

Access to the data transfer functions of the DTS through theNIIF allows user systems to transfer information to other usersystems. The NIIF promotes interoperability of separately

37


MIL-HDBK-818 -1

developed ueer system and DTS equipment. Use of the NIIF isrequired in SAFENET whensver these portions of the SAFENETarchitecture are implemented independently.

The concept of the NIIF is compatible with the layeredstructure of the 0S1 reference model and its associated peer topeer protocol standards. The 0S1 protocol standards apply onlyto communication between cooperating peer entities. They do notidentify, define, or otherwise refer to explicit interfacesbetween adjacent layers. These interfaces are considered to be alocal matter to be solved in the specific implementations. Thus ,the NIIF constitutes an explicit definition of a verticalinterface which can be applied to specific implementations.

5.2 NIIF services. The link between the NIIF and the 0S1reference model is through the associated NATO Naval TransportService Definition. This document is part of the family ofdocumente that define the NIIF. It identifies the servicesprovided by the transport layer to the seesion layer. A serviceis actually the method by which the user system gains access to aparticular protocol entity within the DTS. This transportservice definition allows the user system to access the fullrange of services available from the data transfer system. TheNIIF services are: connectionless mode data transfer service,connection mode data transfer service, real-time data transferservice, and management service.

5.2.1 Connectionless mode data transfer service. Theconnectionless mode data transfer service provides the usersystem with the ability to transmit a single unit of data withoutthe requirement of establishing a connection. For the NIIF, thisservice is defined in the Proposed Draft Standard for NATO NavalIntraship Transport Service Definition - Addendum 1 to Annex A:Connectionless Mode Data Transmission. This addendum definesdata transfer services based on the Connectionless Mode ServiceAddendum to 1S0 8072.

In this mode messages will be individually handled, andsequential delivery is not assured. The user system is notassured of notification of the loss or duplication of a message.All information necessary for delivery of the data unit ispresent at the time of invocation of the service. No connectionestablishment is reguired in order to exchange data, and norelationship exists between successive uses of the service.

5.2.1.1 T-UNIT-DATA Drimitive. The T-UNIT-DATA primitiveis the only primitive defined for the connectionless modeservice. The T-UNIT-DATA primitive is used to transfer a singleTransport Service Data Unit (TSDU) from the source Transport

38


MIL-HDBK-818 -1

Service Accese Point (TSAP) to the destination TSAP in a singleinvocation of the service. Use of the T-UNIT-DATA primitive isdiagramed in Figure 6.

T4JNIT-0ATAF4eqIMsIkl.---.--—-T-UNiT.OATAlr@CIUMI

TRANSPORT

SERVER

Figure 6. Connectionless Mode Data Transfer Primitive

5.2.2 Connection mode data transfer service. Theconnection mode data transfer service Drovides the user svstemwith reliable, sequential data transfe; within the limits-of thequality of service (QOS) parameters established for theconnection. For the NIIF, this service is defined in theProposed Draft Standard for NATO Naval Intraship TransportService Definition - Annex A: Connection Mode Data Transmission.This annex defines data transfer servicee based on the 1S0 8072Connection Mode Transport Service.

The NIIF provides for fixed and selectable guality ofservice parameters, but no negotiation. The service depends onthe implementation to be aware of its sDecific limitations withrespect to the available services. In ;ther words, the availableQOS should be known for the specified system or a range of valuesfrom which to choose should be available for the user system atthe invocation of the service.

The connection mode service allows the user system toestablish connections with other user systems within a virtual

39


MIL-HDBK-818 -1

address environment. Virtual addresses are independent of theunderlying physical address structure and are identified to thedata transfer system during the connection establishment phase.

Primitives for the connection mode eervice fall into threeclasses: connection establishment, data transfer, and connectionrelease. Use of the connection mode primitives is diagramed inFigure 7.

5.2.2.1 T-CONNECT urimitive. The T-CONNECT primitiveprovides a mechanism for establishing connections between two (ormore) user systems. This service definition allows for selectionof a specific set of QOS parameters. The other parameters arefixed by the eystem design.

5.2.2.2 Data transfer Primitives. Once a connection hasbeen established the T-DATA and T-EXP-DATA primitives may be usedfor the exchange of TSDUS.

5.2.2.3 T-DISCONNECT Drimitive. At the completion of thedata transfer process, or in response to faults, the T-DISCONNECTprimitive may be used to release a connection.

5.2.3 Hanaaement service. The management service providesthe user system the means with which to manage the resources ofthe DTS. For the NIIF, this service is defined in the ProposedDraft Standard for NATO Naval Intraship Transport ServiceDefinition - Annex B: Management Service Definition. Thesemanagement services are defined in the context of current 0S1 andIEEE network management standards.

The management service provides access to the LayerManagement Entities (LMEs) of each local protocol entity withinthe data transfer system, as well as those of remote protocolentities. Since this service provides for layer managementwithin the local protocol entities, it is not strictly a peer-to-peer communication. The management service primitives consist ofthe following groups: parameter control, action control, andevent reporting. Use of management primitives is diagramed inFigure 8.

5.2.3.1 Parameter control Primitives. Parameters thatcontrol specific characteristics and attributes of the layerservice providers within the DTS can be set, conditionally set,and examined using this group of primitives. The specificparameter encodings are defined in the resource specification.All parameter control Invoke primitives are processed by theappropriate LME, and a Reply primitive is returned.

40


MIL-HDBK-818 -1

TU3NNECT.WWSSI.<.---. ------- —------‘.‘,, % T.00NNECT.lndkalkm

,,’

,/’ T-LXSCONNEOT..%WSS!-.----------- —----—-.

T.DISCONNECT.lndkalbn<T_NECT.lkFU)W

------------------------

T.00NNECT.CeoJtmx

T-DATA-w

T-ExP-DATARequeat ------------------------ T.DATAlnd&brIa

T-EXP.DATAlndlcatlon

T-DISCONNECT.RequW

-----------------------

= T-DISCONNW.lndkaUm

T-DI~NNECT.Indlcafan faull T-Dl=NECT.lndlcalm

TRANSPORTSERVER

Figure 7. Connection Mode Data Transfer Primitives

41


MIL-HDBK-818 -1

M-G17.invoke M-GET. ReplyM-S13.invoke M-S~.ReplyM-COMPARE-AN D-SET.invoke M-COMPARE-AND-Si3. RepiyM-ACTION.invoke M-ACTION. Reply

M-EVENT. Notify

USER SYSTEM

DTS

,------- ...............LME PROTOCOLENTITY

i RESOURCE LME PROTOCOL ENTITY

~MANAGEMENT ~!

LME PROTOCOL ENTITY

Figure 8. NIIF Management Primitives

5.2.3.1.1 M-GET Drimitive. This primitive allows the usersystem to obtain the value of a specific resource parameter.

5.2.3.1.2 M-SET urimitive. This primitive allows the usersystem to perform a set operation on a specific layer parameter.

5.2.3.1.3 M-COMPARE-AND-SET Drimitive. This primitiveallows the user system to compare the value of a parameter to aspecified value and, if they are equal, to perform a setoperation on a specific resource parameter.

5.2.3.2 Action control urimitive. The M-ACTION primitiveallows the user system to invoke a specified state transition orsequence of events within the specified resource.

42


FIIL-HDBK-818 -1

5.2.3.3 Event reuortina nrimitive. The M-EVENT primitiveallowe the DTS to report significant evente occurring within aspecified resource to the user system.

5.3 NIIF specifications. The NIIF is intended to supportboth external and embedded network interfaces. It alsocapitalizes on readily available physical interface standards(e.g., VME bus, STANAG 4153). The NIIF specifications aredivided into the following two groups: interface data unitspecifications, and local profile specifications.

5.3.1 Interface data unCt sr.edifications. The NIIF datatransfer and management primitives are passed between the usersystem and the DTS in the form of Interface Data Units (IDUS) .These IDUS explicitly define the format and content of eachprimitive. Within an IDU, parameters have specified fieldpositions and field sizes. Usually, the range and meaning ofparameter values will also be specified. An IDU may also containa Protocol Data Unit (PDU). In a specific network implementationwhich employs the NIIF, the implementer must define values andranges for the QOS parameters and management parameters.

5.3.2 Local Drofile specifications. The transfer of IDUSacross the NIIF between the user system and the DTS reguires eachside to provide functions equivalent to the lower two layers ofthe 0S1 reference model. The physical transfer mechanism isselected for a specific implementation through a local profile.

Figure 9 illustrates the NIIF local profile model. Theexchange of IDUs between a user system and a DTS may be baeedupon any one of a number of profiles, with each profilesupporting a different physical interface. Each side (usersystem or DTS) of an NIIF local profile is partitioned into threesegments: the logical segment, convergence segment, and physicalsegment.

5.3.2.1 Loqical seqm ent. The logical segment providesstandard procedures for the control of the exchange of dataacross the interface that are independent of the physical mediumbeing used. This segment is common to all interface profiles.This is analogous to the logical link control sublayer of the 0S1data link layer (layer 2).

5.3.2.2 Convergence seqm ent. The convergence segmentimplements the functions needed to interface a particularphysical interface with the logical segment. A differentconvergence segment is required for each type of physicalinterface. This is analogous to the media access controlsublayer of the 0S1 data link layer.

43


MIL-HDBK-818 -1

USERSYSTEM

t

IDUS

1

MEN LomcMSEGMENT

USER~R4CE UsEscowmQENcE UsERccwEts3EwESEGMEhT SEGusw SEGMENT

(sTANAG41ss) (WEWs) (FUTURESUS+)

USERPHYsCU. USERPWSICU USSR—SEGMENT SEOMENT SEGAIEST

FmN4G41ss) WE SUS) (WNREWS+)

A A AN!lF NIIF NI!$Incu IsCu. l.ocuPSWUE PROFILE PNomE#l #a ●44

v v vm’sPNWlcu DTsPNYSISM MSPHYSICMsEmENl SEf3MENl SEQMEST

(STASAG41ES) (WEGus) m-+)

Ems~ENCE DTSCOtWERGEN~ DTsCotWEsGEF4tESEGMENT SEGNW SEGMENT

(ST- 415S) (VMESW) m=+)

DTSUQICMSEGMW

i

f

IDUS

DATATRANSFER SYSTEM

Figure 9. NIIF Local Profile Model

44


MIL-HDBK-818 -1

5.3.2.3 Phvsical seement. The physical segment providesthe specific electrical or optical interface being used totransfer data. The physical segment is expected to be a readilyavailable interface specification which can be used to attach theuser system and the DTS. It may be a standard type ofinput/output (such as RS-232) or a standard backplane (such asVMs) . This is analogous to the 0S1 physical layer (layer 1).

5.3.2.4 Phvsical interface selection. The NIIF neitherstipulates, nor limits, the choice for the local physicalinterface. However, the NIIF has specified certain physicalinterfaces for which it has defined an appropriate convergencesegment. Selection of a physical interface which is notspecified by NIIF will require that the implementer define anappropriate convergence segment.

45


MIL-HDBK-818 -1

46


MIL-HDBK-818-1

6. XTP Implementation Notes

6.1 Introduction. XTP providee SAFENET users with fast,efficient service for those systems which may need this type offunctionality. XTP implementors have documented certainbehaviors of the XTP protocol which may not be immediatelyobvious. In some cases, unexpected results occur. Theseanomalies are not protocol problems, but are conditions whichshould be understood by XTP users and implementors. Some ofthese behaviors are presented in this section.

6.2 Context Identification. The source NSAP address andkey are used by the destination host to identify a context.Suppose multiple network interfaces are available at a given nodeand each interface uses a different NSAP. If an interface otherthan the one on which a connection is established is used (i.e.,due to FDDI reconfiguration, load sharing across the interfaces,etc.) , context identification fails. Data may be deliveredincorrectly or duplicate data may be delivered.

A number of implementation solutions exist. Systemdesigners must select a solution which meets their uniquerequirements.

6.3 Retry Frenzv. It is possible for an excessive numberof retry packets to be generated if reliable transfer of a largemessage is attempted to an off-line node. Suppose for examplethat Node A is trying to establish an implicit connection withNode B to send a large block of data reliably. Node A sends aFIRST packet followed by a number of DATA packets. If Node B ispowered down, the packets are lost. When WTIMER expires in NodeA, the FIRST and DATA packets are sent again. If retry_count isset sufficiently high, this process could unnecessarily usebandwidth.

To reduce the amount of traffic generated in cases likethis, a number of implementation epecific solutions exist. Onecould, for example, set retry count to some low number. Whilethis reduces the amount of ba~dwidth used by the process, it maynot be suitable for all applications. An alternative approachwould be to limit the amount of traffic sent by lengthening thetime between FIRST packet retransmissions. An exponentiallyincreasing timer could be introduced.

6.4 Context Termination. If a system designer decides touse a series of reliable datagrams, there could be a contextresource problem if a large number of high rate messages are sent

47


MIL-HDBK-818 -1

to the sane destination. Since a context must be maintaineduntil CTIMER expires after a connection is closed, a large numberof closed contexts may have to be maintained in a node. Thisproblem does not occur if a three-way handshake is used.

6.5 Multicast Reliability. A potential problem exists withmulticast return key mapping. Received return keys, that isthose that are “primed”, are aesumed to be unigue since they arederived from the unique non-primed keys previously generated atthat node. Multicast violates this principle, however, in thatpackets with return keys can be broadcast to the entire group,not just the originating node.

Suppose Node A and Node B are both multicast senders. NodeC is a multicast receiver. Node A sources group 1, or Gl, andNode B eources group 2, or G2. Node A, Node B, and Node C aremembers of both G1 and G2. Suppose Node A and Node B both selectthe same key, say K, to identify the group. When Node C sends aCNTL packet with key=K’ to G1 or G2, the recipients can not tellif it is for G1 or G2.

SAE’ENET solves this problem by sending the multicast grouporiginator’s MAC address in the XROUTE and XKEY fields of CNTLpackets. The MAC address is used to identify connections usingthe same return key and group address.

48


MIL-HDBK-818 -1

7. SAFENET TRANSFER SERVICES

7.1 Introduction. The purpose of this section is toprovide an overview of the transport, network, and logical linkcontrol layers of SAFENET, which are collectively called theSAFENET transfer services. This section primarily describes the0S1 protocols specified for use in SAFENET.

7.2 TransDort laver services.

7.2.1 0S1 transDort Drotocols . In SAFENET the transportlayer includes two 0S1 protocols: connection-oriented 0S1Transport Class 4 (TP4) defined by ISO 8073 and connectionlesstransport defined by 1S0 8602. TP4 provides the necessaryconnection-oriented services for the SAFENET 0S1 profile, whichsupports applications requiring reliable, acknowledgedinformation transfer. Connectionless transport provides a basicdatagram service for the SAFENET lightweight profile, whichsupports applications where messages fit into one network packetand the reliability of the underlying network service isadequate.

The 0S1 model is often divided into the lower layerprotocols and the upper layer protocols. The transport layer isconsidered the highest of the lower layer protocols. Thetransport layer provides an end-to-end protocol, i.e., a protocolbetween the source and the ultimate destination. ISO 7498states, @,The transport-service provides transparent transfer ofdata between session-entities and relieves them from any concernwith the detailed way in which reliable and cost effectivetransfer of the data is achieved.” The higher layer protocolscan assume a communications system which is reliable enough tomeet their needs.

7.2.1.1 TranSDOrt Class 4 Dr Otocol . ‘She functionsperformed by the 0S1 TP4 protocol which are applicable to theSAFENET environment are establishment and release of transportconnections, error detection and recovery, flow control,segmentation and reassembly of messages, in-order delivery ofmessages, expedited data service, provision of user requestedQuality of Service (QOS), and an optional checksum.

One TP4 entity communicates with another via TransportPrOtOCOl Data Units (TPDUS). The connection is established bythe exchange of a Connection Reguest (CR) and a ConnectionConfirm (CC) TPDU. The error detection and recovery and flowcontrol functions are accomplished using Alz (acknowledge) TPDUStransmitted by the receiving station. Each DT (data) TPDU has a

49


MIL-HDBK-818 -1

field containing a sequence number. Every AK TPDU contains thevalue of the next sequence number expected by the receiver,thereby acknowledging the receipt of all DT TPDUS with lowersequence numbers. The AK also contains a credit field. Thetransmitting station is allowed to send DT TPDUS with sequencenumber K where:

AK seq no < K < (AK seq no + AK credit)

Thie range of sequence numbere is known as the window.There are transmission timers on the transmitting station whichare restarted when AKs are received. If an AK is not receivedbefore the retransmission timer expires, then unacknowledged DTTPDUS are retransmitted.

The user may wish to send Transport Service Data Units(TSDUS) which are too large to send in a single Network ServiceData Unit (NSDU). The maximum size of the NSDU is dependent onthe type of network. The NSDU plus lower layer headers must fitinto one network packet. One of the services offered by TP4 isto segment TSDUS which are too large to fit into a single NSDUinto multiple TPDUS which do fit into single NSDUS. At thedestination the TPDUS are reassembled into a TSDU and deliveredto the user.

A transport connection is normally disconnected by exchangeof a Disconnect Request (DR) TPDU” and a Disconnection Confirm(DC) TPDU. The transport level may also issue indications toboth users that the connection has been disconnected. This is anon-graceful close, i.e. , all pending TPDUS are discarded.

The user may request that an Expedited Data (ED) TSDUcontaining 1 to 16 bytes of user data be sent. ED TPDUS areacknowledged by Expedited Acknowledge (EA) TPDUS. Only one EDTPDU may be outstanding at a time on a connection. The rule fortransmission of an ED TSDU is that it may not be delivered to thedestination user after DT or ED TSDUS which were submittedsubsequently to the transport layer on that transport connection.So the ED TSDU must be served at least in FIFO order. Thetransport layer expedited data service was not intended to be ageneral purpose service for sending high priority messages;rather, it was intended to support synchronization features inthe session layer.

One of the interesting features of TP4 is how much is leftto the implementor. For example, the amount of credittransmitted in AK TPDU can be based on the amount of buffer spacethe receiver has but it may also be based on otherconsiderations. The destination system may send any credit it

50


MIL-HDBK-818 -1

pleases; the amount is not specified in the protocol. Anotherexample is retransmission timers. It is possible to have a timerfor each TPDU or one timer per connection. When the timerexpires (assuming one timer per connection) , there are differentpossible strategies. One is to reset the timer and start sendingfrom the first unacknowledged DT TPDU and continue until allunacknowledged DT TPDUS have been retransmitted or an AK isreceived. Another etrategy is to reset the timer, send only thefirst unacknowledged DT TPDU, and wait for an AK. Each DT TPDUdoes not have to be acknowledged by a separate AK TPDU. An AKTPDU can acknowledge more than one DT TPDU. When to send AKs isup to the implementor. Fewer AKs can result in higher throughputbecause of less AK processing. However, fewer AKs can also meanthat an error takes longer to detect. All these choices haveadvantages and disadvantages depending on the environment. Itshould be noted that SAFENET permits the use of any TP4acknowledgement strategy which conforms to the standard.

7.2.1.1.1 TP4 oualitv of service parameters. Ideally, atransport protocol implementation should be able to provide therequested Quality of Service (QOS) to the ueer, monitor whetherthe QOS goals are being met, take corrective action if QOS goalsare not met, and inform the user if QOS cannot be met.Unfortunately, this is a research topic and no currentimplementation of TP4 does these things. QOS is an area wherethe 0S1 standards are likely to change. The following QOSparameters are specified in the transport service standard ISO8072:

a.b.c.d.e.f.

9.

h.i.j.

k.

Transport Connection (TC) establishment delayTC establishment failure probabilityThroughputTransit delayResidual error rate (corruption, duplication, 10SS)

Resilience of the TC (probability of transport serviceinitiated disconnect)

Transfer failure probability (probability that QOS goalsare not met during an observation period)

TC release delayTC release failure probabilityPriority (order in which connections shall have their QOS

degraded if necessary to meet the QOS requirements ofhigher priority connections. The use of a higherpriority does not imply that the connection will beserved before a connection of lower Drioritv.)

TC protection (extent to whichprovider attempts to preventmanipulation of user data)

a trans~ort se-m;ceunauthorized monitoring or

51


MIL-HDBK-818 -1

It should be noted that in ISO 8072, QOS is negotiated amongthe two transport service users and the transport serviceprovider.

7.2.1.2 Connectionless transDort Drotocol. The 0S1connectionless transport protocol is specified in 1S0 8602 andthe service is specified by 1S0 8072/ADDl. The connectionlesstransport protocol is very simple and offers an unreliabledatagran service. Each T.SDU must fit into an NSDU SinCeconnectionless transport does not provide segmentation andreassembly.

The user may reguest QOS parameters for transit delay,protection, residual error probability, and priority. In theconnectionless transport case, a TSDU of a higher priority isprocessed by the transport service provider before one of a lowerpriority. If the network service provider is unable to provide aguality of service to meet the residual error rate specified bythe transport service user, the connectionless transport protocolwill insert a checksum field that must be checked at thedestination.

7.3 Network layer services.

7.3.1 0S1 network urotocol. The full connectionlessnetwork layer protocol defined by 1S0 8473 is the network layerprotocol required by 0S1 TP4. If” connectionless transport isused in a SAFENET implementation, it is reguired that allmulticast transmissions be over a single local area network.Unicast connectionless transport is not restricted to a singleLAN segment.

7.3.2 Connectionless network services. The connectionlessnetwork layer provides an unreliable datagram service to deliverNSDUS to Network Service Access Point (NSAP) addresses which maybe either on the same subnetwork or on a different eubnetwork.The network layer user may also epecify the following QOSparameters for each NSDU: transit delay, protection (security),cost , residual error probability, and priority. In contrast tothe priority parameter specified in the transport QOS, use ofpriority in the network service may imply that a NSDU with higherpriority is serviced before an NSDU of lower priority.

The primary functions performed by the connectionlessnetwork layer are forwarding Network Protocol Data Units (NPDUS)according to the routes determined, NPDU lifetime control, andthe segmentation and reassembly of NPDUS which are too large tofit into the subnetwork service data units. Additional functionswhich may be optionally provided are security, complete or

52


MIL-HDBK-818 -1

partial source routing, complete or partial route recording,priority, error reporting, congestion notification, QOSmaintenance, and NPDU header padding. The capability to add achecksum for the NPDU header must be present. It is only used,however, when selected by the originating network entity.

7.3.2.1 Network laV er routing. The primary service of thenetwork layer is to route a P13U to its destination, even ifintervening subnetworks are involved. TWO basic strategies canbe employed: adaptive routing and-source routing.

Adaptive routing is the tlefault strategy for 0S1connectionless network service. It requires that the sendersupply only the address of the destination. When the NPDUarrives at the router, that router makee the decision on where tosend it next. This continues until the PDU arrives at thedestination.

Source routing requires that the sender supply a list ofintervening routers that must be visited on the way to thedestination. Partial source routing occurs when this list ofintervening routers is incomplete. Nhen partial source routingis used every router on the list must be visited, and additionalrouters may also be visited.

7.3.2.2 Seam entation and reassembly. At the source networkentity or at any intermediate network entity, the size of theNPDU may be larger than the maximum service data unit sizesupported by the underlying subnetwork service being used totransmit the NPDU. In this case, the NPDU is segmented intosmaller NPDUS by the network protocol (unless the non-segmentingsubset is being used). Segmentation could take place severaltimes. Generally, reassembly of the smaller NPDUS into theoriginal NPDU takes place at the final destination, butreassembly can take place at some intermediate point. Each NPDUhas a data unit identifier which is not reused within thelifetime of the NPDU. The data unit identifier plus the eourceand destination NSAP addresses identify the individual segmentsof an original NPDU. The individual segments are also numberedin order. When the first segment of an NPDU shows up at areassembly point, a timer is set. If the timer expires beforeall the segments are received, all received segments of the NPDUare discarded on the assumption that some segments have beenlost.

7.3.2.3 NPDU lifetime control. Every NPDU is initializedwith a counter. Each time that an NPDU is processed by anintermediate system, the counter is decremented by at least one.When the counter is decremented to zero the NPDU is removed by

53


MIL-HDBK-818-1

the next intermediate system. This keeps NPDUS from circulatingin the network indefinitely.

7.3.2.4 Congestion control. When congestion is encounteredby an NPDU at an intermediate system a bit in the QOS maintenancefield may be set which reports this congestion to the destinationstation. It is not specified in the standard how to determinewhether congestion has occurred, although some guidance is given.This congestion information could be used to make routingdecisions. However, in SAFENET use of the QOS maintenance fieldfor routing decisions is specifically forbidden.

7.4 Loaical link control services.

7.4.1 Loaical Link Control Drotocol. The SAFENET LogicalLink Control (LLC) sublayer consists of the type 1 connectionlessLLC protocol specified in the IEEE 802.2 standard. The mainfunction provided by LLC is protocol stack selection throughassignment of Link Service Access Points (LSAPS) to protocolstacks. The 0S1 connectionless network protocol uses LLC type 1services.

LSAP FE (hex) is used to identify the 0S1 ConnectionlessNetwork Protocol Entity and the Associated 0S1 routing protocolsspecified by SAFENET. LSAP AA (hex) is used to identify thedirect use of LLC services by XTP.

54


MIL-HDBK-818 -1

8. SAFENET CONFIGURATION OPTIONS

8.1 ~ntroduction. SAFENET provides a number of optionswhich allow the systetu designer to meet the specific requirementsfor a particular system. Options are available which allow theissues of survivability, availability, cost, weight, and physicalsize to be traded off for a particular system. These options areprovided to make SAFENET useful in environments which, forexample, require very little survivability and also inenvironments which require the highest level of survivability.This section is intended to familiarize the system designer withthe options that are available for consideration.

8.2 Criteria for Selection. SAFENET is intended to providethe tools necessary to build a survivable system for missioncritical applications. Because some SAFENET applications may notfall into this category, it is not desirable to limit them onlyto mission critical applications. To keep land based and non-mission critical systems simple and inexpensive, SAFENET providesfor options to meet the budget and needs of a particularapplication.

A system designer should determine the environment of aparticular system in order to select proper options and toolsfrom the SAFENET standard. The following items should be takeninto consideration when determining the best components for asystem:

Availability - what is required in order for the system toremain operational,

Level of criticality - how critical is it that the systemremain operational,

Expense - how much will components and cabling cost,Required robustness in connection - what type of station

connections are available,Required robustness in reconfiguration - can stations be

connected after primary paths are broken,Ability for future expansion - will the network grow over

time,Area of installation - what type of barriers or equipment

are near the cables,Ease of maintenance - what is involved in maintaining the

cable plant and stations.

8.3 Fiber There are many important considerations when— .designing a local area network. Among them are theinterconnection of fibers, cable topology, connection ofstations, use of trunk coupling units, and optical power budget.

55


MIL-HDBK-818 -1

8.3.1 Fiber eDlicee vs. connectors. Unlike copper cabling,which has traditionally been used in networking environments,fiber optic cables are not as easily maintained or modified.When a fiber is cut, either for installation or as a result ofdamage, either the fiber can be spliced together or a connectorcan be used. The manipulation of fibers may require chemicals orother materials which may be prohibited under certaincircumstances. The type of splice or connector used also affectsthe optical power budget.

8.3.1.1 SDlices. Splices connect two fibers by heatwelding, chemical fusing, or mechanical pressure. These methodsproduce the best type of fiber connection and result in low loss.However, splicing requires both an experienced technician andaccurate equipment. Additionally, each type of splice has itsown characteristics for loss. Although splicing results in lowloss , some loss is encountered and the number of splices on asingle cable is limited. Splices have the limitation that oncemade, they cannot be removed easily without breaking the fiberanother time. For long runs of fiber, splices should be used toreduce the overall loss of the connection. Splicing is therecommended method for connection in survivable networke.

8.3.1.2 Connectors. Connector are mechanical couplingdevices which connect two fibers together. When used, thenetwork can be maintained through-simple replacement of shortcables. Since connectors are mechanical devices which hold twofiber cables together, they are easy to open up quickly to allowfor data monitoring. This is useful for monitoring stations anddiagnosing problems. Additionally, once a connector is installedon a fiber, the fiber can be relocated to a different area andthe interconnection of fibers can be accomplished more easily inthe field than is possible with splices. Connectors are bestsuited to benign environments where devices are relocatedfrequently, and networks that can generally handle shortinterruptions.

8.3.2 Connections at stations. Stations can be connectedto the data path using either an ST connector, a Media InterfaceConnector (MIC), or a Fiber Optic Interface Connector (FOIC).

8.3.2.1 ~. The ST connector is the easiest connector toattach to a fiber and is the least expensive. This connector isfrequently used in benign environments because it is unkeyed(making the fiber usable for either transmit or receive) and selfcontained. It is often used for network monitoring taps or forattaching to a single fiber for repairs when splicing is notused. The ST connector has the advantage that when multi-fiber

56


MIL-HDBK-818 -1

cables are used, the fibers can be usedeither transmit or receive.

interchangeably for

8.3.2.2 Media Interface Connector (MICL. The MIC connectoris the ANSI X3T9.5 approved connector for all commercialhardware. This is the most popular type of connector. Theconnector contains both the transmitting and receiving fiber inone shell. The MIC receptacle is polarized to prevent improperattachment of input and output fibers. The MIC receptacle alsoprovides a physical key to prevent improper MIC-plug --attachment,and to control the types of FDDI ports (such as A, B, S, or M)which can be attached with the ‘fiber. Additionally, theseconnectors offer a quick connect/disconnect which makes them veryuseful for equipment or networks which are frequently relocated.Land based operations which do not require environmentalprotection benefit from these connectors because they containboth fibers (transmit and receive), are keyed so that the usercannot connect the wrong station to the network, and are quick toconnect and disconnect.

8.3.2.3 FOIC The Fiber Optic Interface Connector is acircular, hea~~~y, multi-fiber connector specified in MIL-STD-2204. This connector provides for backup fibers which can beused in the event of damage to the cable. This is the connectorreguired by SAFENET for severe environments in whichsurvivabilitv is Daramount. Due to the MIL qualification, thisconnector is-the ~ost expensive of the three:

8.3.3 Trunk couplina units. A trunk coupling unit (TCU)a device which contains fiber optic switches which either passdata around the station (when the station is disabled orreinserted from the network) or allow the data to paes to thestation (when the station is enabled and inserted onto thenetwork) . The TCU is needed for survivable interconnection ofconcentrators or stations on the trunk ring of a network, orconcentrators connected using the concentrator tree topology,

is

because they allow for devices to be powered off witho~t b~~akingthe token path for an extended period. Due to the nature of theoperation of a fiber optic switch, a TCU presents a considerableoptical power loss in the data path and if several serial TcU’Sare used some compensation will be required, either withrepeaters or extended power levels. A trade-off is requiredrelative to the use of TCUJS between survivability requirements,COSt Of TCUS VS. repeaters, and the use and cost of extendedpower levels. TCUS also require an additional electrical cableinterface to provide power to the switches to control stationinsertion.

57


MIL-HDBK-818-1

The internal functionality of concentrators allow them tocontrol the attachment of stations which are powered down, oroperating in error, without the use of TCUS. Additionally, whsnthe tNnk ring is composed of three or less stations, the use ofa TCU is unnecessary. The intercomection of three or lessdevices by a trunk ring does not present the isolation problemswhich exist in larger systems.

8.3.4 Power levels. SAFENET provides for three differentpower levels which allow complete-interconnection of components.These power levels range from standard FDDI to increased power atthe transmitter and increased sensitivity at the receiver. Thevarious power levels provide for increased survivability in casemore than one node needs to be bypassed.

8.3.4.1 Standard FDDI. Standard FDDI power levels arethose specified by FDDI PMD (1S0 9314-3). These are consideredto be a commercial standard and are required for the minimum FDDItransmitting power and minimum receiver sensitivity to guaranteea power budget of 11 dBm. Since this power level is consideredthe FDDI standard, it is obviously the most common power levelavailable in commercial equipment.

8.3.4.2 Increased receiver sensitivity. To allow for atleast one station to be bypassed between active stations andstill meet the military requirements on optical power tolerances,the sensitivity of the receiver may be increased. The benefit ofusing this increased sensitivity is realized in systems whererepeaters are extensively used, or when it is unlikely that morethan one station will be down between active stations.Increasing the receiver sensitivity effectively increases thedynamic range by 4 dBm.

8.3.4.3 Increased transmitter Dower/receiver sensitivity.Increasing the transmitter vower and the receiver sensitivitvallows SA~ENET networks to bypass more stations without loss-ofthe network. For mission critical stations connected to thetrunk ring, this is the recommended SAFENET configuration. Thisincreases the dynamic range by 8 dBm over that of FDDI. See MIL-STD-2204 for a complete definition of the three power levelsdescribed above.

8.4 Cable touoloqy. Cables typically contain more than onefiber. The system designer must choose the proper number offibers per cable to minimize the cost of installing the cableplant, maintaining the fibers and connectivity, and allowing forexpansion.

58


MIL-HDBK-818-1

8.4.1 Dual fiber Dair cables. Under the basic FDDIreconfiguration policies, the fibers of the network are normallyrun in dual fiber pairs (i.e., FDDI linked pairs). In this casethe primary and secondary data path fibers are located in thesame cable. Since the FDDI reconfiguration mechanism known aswrap bypassee both fibers when one of the fibers is broken, theundamaged fiber is unused when this occurs. Consequently, thereis no inherent advantage in separating the individual fibers.Using dual fiber cables makes overall cable plant managementeasier and reduces the number “of actual cablee to be pulled for anetwork. This is the most common cable plant for commercialnetworks.

8.4.2 Multi-fiber cables. Multi-fiber cables normallycontain multiples of two fibers and can save on the overall costof pulling the cable plant through an installation. The multi-fiber cables can be used to provide backup fibers or forincreasing the number of FDDI linked pairs in a single cable.For harsh environmente, multi-fiber cables are primarily used toallow for standby replacement fibers, but require humanintervention to switch to another fiber. In benign environments,multi-fiber cables can be used to connect a number of stations ina close location to the network without having to pull fibers foreach station.

8.4.3 Diverse routinq vs. sincrle cable toDoloqies.Implementors may choose to install SAFENET with the opticalfibers either in a single cable, or in two cables routedseparately to the network stations. Factors which may affectthis decision are the location where the network is to beinstalled, cost of components, and pre-existing constraints onthe physical layout, which may occur on a ship.

One option is to enclose the FDDI dual rings together in thecame cable. This will save on component cost, since less fiberoptic cable is necessary. In some cases it may be the onlyviable option, for example if the number of available cable wayson a ship is severely limited. There are survivabilityimplications to consider for this case. Having only one cablereduces the total number of places where the network can sustaindamage, but if damage does occur it is quite likely that bothrings will be severed.

The other option is to have separately routed dual rings.Since there is roughly twice as much cable in this configuration,this increases the exposure to probable damage. This alsoincreases the component cost. If the implementor so chooses, theFDDI global hold policy may be employed in thie configuration.

59


MIL-HDBK-818-1

This survivability feature provides benefit only if the rings arecabled separately.

8.5 Network devices and connection outions. Networkstations and network devices such as repeaters are connected to aSAFENET network through various techniques. This section coversthe types of devices and connections within a system.

8.5.1 ReDeaters. Repeaters can be used to boost theoptical power to allow for more stations to be bypassed a% anytime. Repeaters are recommended at any point in the networkwhere available power to a downstream station ie a concern.

Repeaters can be built using a variety of methods, and theyshould permit Line States to be retransmitted without filtering(i.e., disabling the repeat filter function from the PHY). Theclock frequency and symbol jitter should meet FDDI PHYrequirements.

8.5.2 Concentrators. Concentrators allow single attachmentdevices to connect to the FDDI data path while still maintainingthe fundamental FDDI linked pairs. Concentrators in SAFENETcontain a minimum of one MAC. The internal functionality ofconcentrators allow them to control the attachment of stationswhich are powered down, or operating in error, without the useTCUS .

of

8.5.2.1 Sinale NAC. Single MAC concentrators cannotperform the more advanced functions such as multiple local pathmanagement. Single MAC concentrators are the least expensiveconcentrators allowed in a SAFENET system and provide minimalfunctionality.

8.5.2.2 Dual MAC. A concentrator with two or more MACSprovides functionality beyond that of a single MAC concentrator.It has the additional capability of using one of the NACS fordiagnostics, and for management of additional local data paths.One advantage of having multiple MACS within a concentrator iethat the network can be separated into subnetworks using a localpath such that the MAC can test equipment prior to inserting itonto the operational ring.

8.5.3 Station attachment. Stations may be either singleattached or dual attached to the FDDI data path. Further, dualattached stations may be connected in such topologies as thetrunk ring or the concentrator tree, or may be dual-homed.

8.5.3.1 Sinale attachment. Single attachment stationsconnect to the network through a concentrator. They are

60


MIL-HDBK-818-1

particularly useful for duplicated resources where loss of onestation is tolerable.

8.5.3.2 Dual attachment. A dual attachment station can beconnected as either a peer or a slave connection. The robusttypes of connections which can be made with a dual attachmentstation make them essential for a survivable system.

8.5.3.2.1 Trunk ring. When a station is attached to thetrunk ring, it is connected to both the primary and-secondaryrings and participates in trunk ring reconfiguration. A stationwhich attachee to the trunk ring must also provide an electricalconnection for controlling a TCU if it is to be used for atactical mission critical system.

8.5.3.2.2 Dual hominq. A station which is attached to twoconcentrators is dual homed and provides a standby port forreconfiguration. A dual homed station does not reguire anelectrical interface because a TCU is not required forattachment, though TCU’S may be used if desired in this case.

8.5.3.2.3 Concentrator tree. Concentrators having bothports connected to one other concentrator form the basis for theconcentrator tree topology. This topology usee TCUS to preventsegmentation when one of the concentrators is powered down.Stations may be dual homed or single attached to theconcentrators in the tree, or the concentrators may act asstations independently. The concentrator tree uses thecharacteristics of dual-homing to achieve a survivable topology.

8.5.4 MUltiDle subnetworks. The use of multiplesubnetworks is the connection of multiple independent FDDInetworks through the use of routers. Multiple subnetworksprovide the advantage that each ring may be independentlydesigned without concern about the impact on other components orsystems in the network. Each subnetwork contains its own tokenand all data is maintained on the individual rings independentlyof data on other subnetworks. Data is passed to other networksonly when the destination address is not on the local network.

61


MIL-HDBK-818 -1

62


MIL-HDBK-818-1

9. SAFENET OPTICAL POWER BUOGET

9.1 Introduction. System optical power budget calculationsfor SAFENET are preeented in this section for two purposes. Thefiret is to demonstrate that the network will operate as requiredusing the signal and component values specified in SAFENET. Thesecond is to provide the system deeigner with some insight intothe problem of determining the placement of repeaters in thenetwork. In the calculations shown; the physical media consistsof worst case cable lengths. Tuned splices are used forconnections to TCUS.

9.2 Power budqet calculations.

9.2.1 ODeratina conditions. A correct implementation ofSAFENET will provide for a substantial unallocated power marginin the power budget. This power margin (M) allows for losses dueto factors such as component ageing, environmental conditions,power supply variation, and repairs made to the physical medium.This power margin does not include losses due to temperaturevariation since each component is required to remain withinspecification over its operating temperature range. For aSAFENET network operating under normal conditions the powermargin (M) is as follows:

lf=6Db

This margin may not be adequate for a SAFENET networkoperating in an extremely adverse environment. The effect of asuch an environment on the power margin is diecussed in 9.2.3.

Any multi-mode optical link is subject to higher order modeloss (HOL). This term accounts for the loss of power due to thedissipation of higher order optical modes as an equilibrium modedistribution ie approached in the optical link. For SAFENET, thehigher order mode loss will be assumed to have the followingmaximum value:

HOL = 1.0 dB

In SAFENET the loss due to signal dispersion (i.e., thedispersion power penalty) is not taken into account. It isassumed that the station receiver sensitivity is appropriatelyderated to account for this loss.

All other values used in the following calculations will betaken directly from the physical layer signaling requirementsand the physical medium requirements specified in the SAFENET

63


MIL-HDBK-818 -1

standard, MIL-STD-2204. These values will be cited in 9.2.2below.

9.2.2 Worst case svstem Dower budqet. The worst casesystem power budget is significant because it shows whether ornot a SAFENET implementation using the specified signals andcomponents will work under normal operating conditions. Thefunctional requirement is that the optical link between thetransmitting and receiving stations be able to operate with atleast four intervening bypassed stations.

The first step is to compute the power budget (P) availableto the optical link. The equation is as follows:

P = [ Po(min) - Pi(min) ] - M (Eq. 1)

Po(min) is the minimum required output signal powerPi(min) is the minimum required input signal powerM is the unallocated power margin

Po(min) = -16 dBm (see MIL-STD-2204)Pi(min) = -35 dBm (see MIL-STD-2204)M=6Db

so: P= [-16- (-35)] -6 ; P=13dB

The next step is to compute the link budget to ensure thatthe link losses do not exceed the available power budget (P).However, optical links in SAFENET are of variable length,depending upon the presence of intervening bypassed stations inthe link. For this reason, the optical link will be consideredin two parts: the minimum link (ML), and the variable link (VL).

The minimum link is diagramed in the Figure 10. AS shown,the minimum link in SAFENET is a link between physically adjacentstations on a ring. The optical signal on this link will passthrough, in order, the following components:

-- an FOIC and an optical interface cable-- 2 splices and a TCU (transmit path)-- a trunk cable-- 2 splices and a TCU (receive path)-- an optical interface cable and an FOIC

64


MIL-HDBK-818 -1

;+ . . . . u . .. ...F.

. .. ...).+ .. .. .. .. Tcu %TRUNK \/ TCU

1CASE

, ‘-”* x’””-’-

*A \ / A

...L...

OPTICAL \ / )+( ~INTSFIFACS

I u

> X-SPUCS

T? ;

FOIC

[’FOIC

f’STAllW STATNNOurPur INFVTSW4AL slew

Figure 10. Diagram of the Minimum Link

Therefore, the minimum link equation is as follows:

ML = (Lt+2Li)*Cf + 2SW + 4SP + 2C0 + HOL (Eq. 2)

Lt is the length of a trunk cable runLi is the length of an optical interface cable runCf is the lenath-deuendent loss of the fiber oDtic cableSw is the optical p~wer loss of a bypass switch (TCU) along

the bypass, transmit, and receive pathsSp is ths optical power loss of an spliceCo is the optical power loss of an FOICHOL is the higher order mode loss

Lt = 0.2 Km (max)Li = 0.1 Km (max)Cf = 2.0 dB/Km (max)SW = 0.8 dB (max)SP = 0.2 dB (max)CO = 1.0 dB (max)HOL = 1.0 dB

(see(see(see(see(see(see

65

MIL-STD-2204)MIL-STD-2204)MIL-STD-2204)MIL-STD-2204)MIL-STD-2204)MIL-STD-2204 )


So for the worst

ML = (0.4)*2.O +

MIL-HDBK-818 -1

case:

2(0.8) + 4(0.2) + 2(1.0) + 1.0 ; ML= 6.2 dB

The variable link is diagramed in Figure 11. As shown, thevariable link is that series of optical components which will beinserted into the optical link when a station is bypassed at itsTCU . The variable link consists of a trunk cable run, a TCU(bypass path), and two splices. Therefore, the variable linkequation is as fol10w5:

VL = Lt*Cf + SW + 2Sp (Eq. 3)

All terms and values are as defined above. So for the worstcase:

VL = (0.2)*2.O + 0.8 + 2(0.2) ; VL = 1.6 dB

:+ . . . . . . . . . u .........E.

mm I 1 TO

UPSTREAMTRUNK

v vmw

TCU CASE - STREAN

Tcu, ,..-.., ,

)-w;!

TCU!,

IN BYPASS x -SPL!CE

1;aTAnoNLOOPBACK

Figure 11. Diagram of the Variable Link

An expression for a total link (L) can be written in termsof the minimum link and the variable link. The equation for thetotal link is as follows:

66


MIL-HDBK-818 -1

L = ML + N*VL (Eq. 4)

N is the number of variable links in the total link, i.e.,it is the number of bypassed stations intervening between thetransmitting and the receiving station.

For a SAFENET network to operate in the worst case, itshould be able to maintain an optical link when N = 4. That is,the following condition must be net:

P2L:

which gives:

P 2 ML + 4*VL (Eq. 5)

Using the calculations given above:

L = 6.2 + 4*(1.6) ; L= 12.6 dB

Since P = 13 dB, P is greater than L, and the conditioncited in Equation 5 has been met. Therefore, even with worstcase component losses a SAFENET network should be able to operatewith four consecutive bypassed statione.

A different way to show thiswould be to solve for themaxixnum number of bypassed stations which could be allowed in anoperating optical link. This will occur when P = L, which leadsto the following equation:

P=ML+N*VL;

which gives:

N = (P-ML)/VL

For the worst case values this gives:

N=(13- 6.2)/(1.6) : N=4

As shown before, even in the worst case a correctimplementation of SAFENET should be able to operate in thepresence of four consecutive bypassed stations.

(Eq. 6)

9.2.3 Adverse environmental conditions. The system powerbudget under extremely adverse environmental conditions issimilar to the worst case power budget calculated in 9.2.2 fornormal operating conditions. The primary difference is that apower margin of 6 dB may not be sufficient to include all the

67


MIL-HDBK-818 -1

losses which could be caused by these environmental conditions.Conditions which may be of interest to a system implementerinclude shock, vibration, humidity, sand and dust, compression,mechanical stress, and nuclear radiation.

To account for the effect of these conditions, a loss marginvalue must be sssigned to each optical component in the system.This component margin represents the additional loss which acomponent may be expected to contribute to the link budget as aresult Of the simultaneous occurrence of all the above adverseenvironmental conditions. Under these conditions, a componentsloss will equal its normal loss plus its loss margin.

An assumed value will be assigned to each component for thepurpose of illustrating the effect on the system power budget.The loss margins given below are not intended to include theeffects of radiation. These component loss margins are definedas follows:

Mcf is the length-dependent loss margin assumed for fiberoptic cable

Msw is the loss margin assumed for a bypass switch (TCU)along the bypass, tranemit, and receive paths

Msp is the loss margin assumed for an spliceMco is the loss margin assumed for an FOIC

Mcf = 1.3 dB/kmMSW = 0.7 dBMsp = 0.1 dBMcO = 0.25 dB

Using these component margins, a composite lees margin canbe determined for a minimum link by modifying Equation 2 asfollows:

M(ml) = (Lt+2Li)*Mcf + 2MSW + 4MSp + 2MC0 (Eq. 7)

Using the loss margins listed above:

M(ml) = (.4)*1.3 + 2*(.7) + 4*(.1) + 2*(,25)

so: M(ml) = 2.82 dB

Similarly, a composite loss margin can be determined for avariable link by modifying Equation 3 as follows:

M(v1) = Lt*Mcf + MSW + 2MSP (Eq. 8)

so: M(v1) = (.2)*1.3 + 0.7 + 2*(.1); M(vl) = 1.16 dB

68


MIL-HDBK-818 -1

To finish computing the system power budget for adverseenvironmental conditions, new values for available power budget(P)r minimum link (ML), and variable link (VL) need to bedetermined. These will be called Pa, MLs, and VLS to representthe adverse condition. Pa is determined by using Equation 1.

Pa = [ Po(min) - Pi(min) ] - Ma

Ma is the unallocated margin in adverse environmentalconditions. Since component losses are now being consideredseparately, Ma only needs to account for active device aging andany gradual degradations which occur in the link. The followingvalue is assigned:

Ma=3dB

Thus : Pa = [-16 - (-35)] - 3; Pa = 16 dB

MLs is simply computed by adding the previously determinedvalue of ML to the minimum link margin calculated above.

MLs = ML + M(ml) ,(Eq. 9)

MLe = 6.2 + 2.82: MLs = 9.02 dB

VLS is computed in similar fashion.

VLS = VL + M(v1) (Eq. 10)

VLa = 1.6 + 1.16; VLS = 2.76 dB

Using these values, the number of stations which can bebypassed in the worst case under these adveree environmentalconditions (Na) can be determined by using Equation 6.

Na = (Pa - MLa)/VLa

so: Na = (16 - 9.02)/(2.76); Na=2

Therefore, this calculation demonstrates that given thecomponent loss margins assumed above a SAFENET network should beable to operate an optical link with two intervening bypassedstations, even under extremely adverse environmental conditions.Two points need to be emphasized regarding thie calculation.

First, a calculation like this can only be meaningful if thecomponent loss margins used represent the known, measuredcharacteristics of the actual components under the adverse

69


conditions. Currentlyrfor most components and

Second. these loss

MIL-HDBK-818-1

this type of information is not availablemust be estimated, modelled, or assumed.

marciins represent the optical response ofthe network” components to t~e simultaneous occu~rence of &.everalunrelated adverse environmental conditions. The system designershould consider carefully whether designing to meet this set ofconditions is necessary to ensure the reliable operation of thenetwork.

9.3 ReDeater Dlacement. It was shown in 9.2.2 that undernormal operating conditions even a worst case implementation ofSAFENET will be able to maintain an optical link across fourbypassed stations. The system designer can use this informationto determine the interval at which repeaters should be insertedin the network. For the case given above, a repeater should beattached at every fifth TCU to ensure network continuity.

However, not all SAFENET installations will need to bedesigned for worst case link losses. For example, suppose it isknown that a specific SAFENET installation is going to be limitedto the following cable run lengths:

Lt = 0.03 Km (max)Li = 0.02 Km (max)

Using this information, the maximum number of bypassedstations (N) can be recomputed. For the following linkcalculations all component loss values will be held to thepreviously cited maximums. The new minimum link value can becalculated from Eguation 2, resulting in:

TheEguation

ML = 5.54 dB

new variable link value can be calculated from3, resulting in:

VL = 1.26 dB

To find the new value for N, Equation 6 is used as follows:

N=(13- 5.54)/(1.26) ; N=5

These calculations show that a SAFENET network with thesemaximum run lengths should be able to operate in the presence offive consecutive bypassed stations. Thus , the system designerwould only have to use repeaters at every sixth TCU, rather thanevery fifth TCU. Of course, similar computations of N can be

70


MIL-HDBK-818 -1

performed for other conditions, such as using components whoseoptical losses are known to be less than the specified maximums.

71


MIL-HDBK-818 -1

72


MIL-HDBK-818 -1

10. SAFENET RECONFIGURATION AND SURVIVABILITY

10.1 Introduction. This section ie provided to illustratesome of the different methods of using the FDDI reconfigurationpolicy and the components defined by SAFENET to producesurvivable systems. It is by no means an exhaustive list anddoes not intend to preclude legal topologies that may be desiredby some system designers. This section does not discuss alllegal topologies that may be of use in systems which do notreguire survivability beyond what can be obtained with standardFDDI components.

MIL-STD-2204 provides implementation flexibility by definingallowable components rather than specific topologies.Recognizing that different systems may have unique sets ofrequirements, the system designer is allowed this flexibility eoas not to preclude implementations that may meet survivabilityrequirements of a particular system.

10.2 Background. In SAFENET, the FDDI LAN standardincludes mechanisms which support operating the token ringnetwork as a pair of counter-rotating rings. This dual-ringarchitecture provides the capability for the network toreconfigure automatically in the presence of faults, such as abreak in the trunk cable. This automatic reconfigurationcapability is inherent in FDDI, where upon a failure or casualtyto either ring the stations on either side of the break ieolateit from the network by connecting the two rings together. Thisis referred to as ring wrap. This is also an important andinherent survivability feature of SAFENET.

The SAFENET topology provides additional survivability byrequiring each station that attaches to the trunk ring to connectby way of a trunk coupling unit (TCU), as shown in Figure 12. Inthe event of a station failure the TCU can be used to isolate thefailed station from the ring using a procedure known as stationbypass. A SAFENET station is capable of transmitting data to areceiving station past multiple bypassed stations, as describedin section 9.

The SAFENET topology provides additional survivability bypermitting the connection of stations and concentrators asdefined in the FDDI Station Management (SMT) standard and shownin Figure 13. Nhen a device is dual homed to concentrators in anFDDI network, in the event of a failure such that theconcentrator attached to the B port becomes isolated from thetrunk ring, the device will switch to receive data from the A

73


MIL-HDBK-818-1

port. Essentially, this method provides simple redundancy byproviding a backup link to the data path.

NETWOFIK NHWORK NETWORK NEIWORK

STATION 8TAmON STAllON STATION

NWORK NETWORK NETWORK NWORK

STATION STATION STATION STATION

Figure 12. Basic Network Topology

The SAFENET topology also provides survivability bypermitting the key network components to be located apart fromeach other. The tmnk coupling units can be located away frontheir attached stations and concentrators can be located withattached stations but away from the trunk ring. While thenetwork components can be located aDart from each other. it isrecommended-that the trunk ring fib;rs be cabled together (unlessthe FDDI Global Hold policy is implemented) so as to providefewer places for the network to absorb damage. In addition,SAFENET allows the implementation of multiple subnetworks foradded survivability. All of these features allow the network toabsorb some damage without losing its ability to operate.

10.3 Survivability techniuu es. A SAFENET network consistsof the components defined in MIL-STD-2204. These components may

74


MIL-HDBK-818 -1

r

● OQ

CONCENTRATOR CONCENTRATOR

1A

It ~j’1’

NEIWORK● 00 ‘~

NEIWORKSIAllON STATION STATION

Figure 13. Basic Dual Homing Topology

be implemented in various configurations, some of which may bemore survivable than others. ExamDles of some survivabletopologies are given below. This ;s”not intended to provide anexhaustive listing of network topologies and should be consideredonly as a sampling of the techniques available. Otherimplementation techniques are poesible and are not intended to beprecluded by SAFENET.

10.3.1 Dual homed touoloav. An example dual homed physicaltopology is shown in Figure 14. As shown, this topology is basedon the use of an FDDI dual-ring, with the primary and secondaryrings of this dual-ring cabled together to form a single FDDIdual-ring trunk. Dual homed DASS, concentrators, and SASS can beused in the dual homed topology.

10.3.1.1 Dual homina reconfi cfuration. The dual homingreconfiguration method employs the standard FDDI connection rulesto enable network stations to switch their communications fromone attachment on the FDDI dual-ring (via a concentrator) to asecond such attachment in the case of a hard fault in the firstattachment. Implementation of the dual homing reconfiguration

75


method does not reguiremechanisms beyond thosedescription of the dualfollowing paragraphs.

MIL-HDBK-818-1

any particular protocol extensions orprovided by the FDDI standards. Ahoming mechanism is provided in the

10.3.1.2 Dual homina mechanism. The dual homing mechanismis based on the connection rules established in the FDDIstandard. A SAFENET defined dual homed dual attachment stationwill include two FDDI defined ports: an A Port and a B Port.Each of these ports is attached to anM Port on two differentconcentrators. Thus, two FDDI connections are formed: an A-to-Mconnection and a B-to-M connection. FDDI defines theseconnections to be redundant tree connections, and further statesthat the B-to-M connection will have precedence over the A-to-Mconnection in a single MAC node.

The result of these connection rules is that a properlyconnected dual homed network station will be actively inserted onthe FDDI LAN through the concentrator to which it has attachedits B Port through a tree connection. Furthermore, it will haveestablished a back-up connection to the FDDI LAN through theconcentrator to which it has attached its A Port. With theseconnections in place, the following fault responses will beperformed automatically in accordance with the FDDI protocols:

a. In the event of a fault on the dual-ring trunk, thestations on both sides of the fault will perform wrapreconfiguration.

b. In the event of a fault to a dual-homed DAS’S A Port treeconnection or to the concentrator attached to the dualhomed DAS’S A Port, no reconfiguration will occur asthese provide the back-up tree connection.

c. In the event of a fault to a dual-homed DAS’S B Port treeconnection or to the concentrator attached to the dualhomed DAS’S B Port, the station’s communications willswitch to the back-up tree connection (supporting APort ).

10.3.1.3 Dual hominq components. The components of thedual homed topology are concentrators and attached networkstations. See MIL-STD-2204 for complete definitions of thesecomponents and methods of interconnecting them.

10.3.1.3.1 Dual homed dual attachment stations (DASS ).Dual homed DASS used in the dual homing topology are attached totwo separate concentrators through tree connections. Each dualhomed DAS uses two tree connections, one for each concentratorconnection. The concentrators to which the dual homed DAS is

76


MIL-HDBK-818-1

SINGLEFDDI DUAL-RING

--------------------------- - ,...~~--~~ ---------------------------------,------- -----

/

: CONNECTW

.. ..

mNcENmATcM CONCENTRATOR

. .

1 r

WALI+OMW DUALkNEODUAL DUAL

ATTACHED AITACHED i●

STATK3N STATWN●

● ●

●

A

●

WAL-NOMED WAL.NOMEDDuAl DUAL b,

AITACHED ATTACHEOSTATION STATICU

CONCENTRATOR WNCENTPATOR

OUAL-RINQTRUNKCASLE

t\

wJ

Figure 14. Dual Homed Topology

77


MIL-HDBK-818 -1

attached should be located apart from each other to avoidsimultaneous damage.

10.3.1.3.2 Concentrators. Each concentrator used in thedual homed topology is attached to the dual-ring, through a trunkconnection, by a trunk coupling unit (TC!U), or dual homed toconcentrators through tree connections. Thus each concentratoruses one trunk connection and one or more tree connections, oronly tree connections, depending on the number of attachedstations being supported and ite position in the topology.

10.3.1.3.3 Sinqle attachment stations (SASS) . SAFENETallowe the use of SASS. If the function of a station is notmission-critical or is duplicated elsewhere in the network it maybe desirable to connect it as a SAS. Connection of a SAS is to aconcentrator through a tree connection. Figure 14 illustratesthe connection of SASS in this reconfiguration approach.

It is important to note that a SAS, though allowed in thedual homed topology, is not itself a dual homed station. Theconcentrator to which the SAS is attached, the SAS itself, andthe corresponding tree connection are single points of failure,and damage to any one will result in loss of communication to thestation.

10.3.2 MultiDle subnetwork toDoloqv. An example multiplesubnetwork physical topology is shown in Figure 15 for a twosubnetwork implementation. As shown, this topology is based onthe use of two or more FDDI dual-rings, with the primary andsecondary rings of each dual-ring cabled together to form a setof two or more FDDI dual-ring trunks. The multiple subnetworktopology may use any combination of the SAFENET networkattachment types. The attachment technigue used for theindependent networks may be the same (as shown in Figure 15), orthey nay use different techniques. It is acceptable to connectsome stations in a multiple subnetwork topology to only one ofthe subnetworks.

10.3.2.1 MUltiDle subnetwork reconfiqu ration. The multiplesubnetwork reconfiguration method employs the dynamic routingcapabilities of the network layer protocols defined in SAFENET.This enables network stations to route their communicationsdynamically among two or more independent FDDI LANs (subnetworks)to which they are attached. Implementation of the multiplesubnetwork reconfiguration method does not reguire any particularprotocol extensions or mechanisms beyond those provided by thenetwork layer protocols required by SAFENET. A description ofthe multiple subnetwork mechanism is provided in the followingparagraphs.

78


MIL-HDBK-818 -1

10.3.2.2 MultiDle subnetwork mechanism. The multiplesubnetwork mechanism is based on the requirement that the networkstations implement more than one complete FDDI station. Within agiven multiple dual attachment network station or multiple singleattachment network station there will reside at least twocomplete and independent DAS/SAS entities. Each of these DAS/SASentities will include its own SMT entity, and it will beassociated with its own LLC protocol entity. Every DAS/SASentity within the station will be associated with the same set ofnetwork layer protocols through their associated LLC entities.

This arrangement provides the network layer of a multipleDAS or multiple SAS with a direct interface to two or more FDDIsubnetworks. The network layer protocols will therefore be ableto select, through their dynamic routing capabilities, which ofthese subnetworks to use for each instance of data transfer. Theresult is that in the event of a failure of a particularsubnetwork, a multiple DAS or multiple SAS will already have atleast one other subnetwork available for its communications.Note that multiple SASS connect via concentrators.

10.3.2.3 MUltiDle subnetwork components. The components ofthe multiple subnetwork topology are multiple network stationsand concentrators. See MIL-STD-2204 for complete definitions ofthese components and methods of interconnecting them.

10.3.2.3.1 MultiDle network” stations. When multiplenetwork stations are used in this topology, each network stationis attached to a different FDDI network. Multiple DAS’S may beattached to a different network through trunk connections or by apair of concentrators via tree connections. Multiple SAS’S maybe connected by concentrators via tree connections.

10.3.2.3.2 Concentrators. When concentrators are used inthe multiple subnetwork topology to support the use of multipleDAS’S or SASS, they may be attached to a dual-ring, through atrunk connection, by a TCU. Thus each concentrator may use onetrunk connection and one or more tree connections, depending onthe number of multiple DAS’S or SASS being supported.

10.3.2.4 MultiDle subnetwork routinq. This information isnot intended to be the complete definition of SAFENET routing,but is provided here for convenience. Other network designswhich do not reguire the updating of routing tables, or which useother routing schemes, are not intended to be precluded.Complete information on routing is found in MIL-STD-2204.

Access to a subnetwork is gained via the sAFENET Networklayer protocol (CINP) through a subnetwork point of attachment

79


MIL-HDBK-818 -1

: .,

CONNECTION: \: :

.. ..

03NcENnumu : :

,..,: :: :

: :

\ &&SENlllY ~ ~LIAsENrrrY{ ~ clAi&lTw /..--. --. -.-------, !----------------- .----------------, .----.-----------,

MULTIPLEG#S MuLTIPLEGAS MIAllPLED&s MULTIPLEMS

,.----------------; ,.------- .. -------1 ~--------------- ,----------------1 sAs EN-rrtY j ~lMSEM7TY: !

-1{sAs ENnrT’! MsENm-f :, ,

A A

COK=NIWTOR

TRUNKDUAL*ING CCUPLING

TRUNKC4M.E UNIT

t v i vv

FDDI DUAL-RING #2

COO04

Figure 15. Multiple Subnetwork Topology

80


MIL-HDBK-818-1

(5NPA) . Any one subnetwork is totally independent of any othersubnetwork and thus does not share any Data Link or Physicalcomponents.

Stations attached to multiple subnetworks can be either EndSystems or Intermediate Systems. Nhile the multiple subnetworksprovide the redundant data paths to support survivability andavailability, a means of dynamically changing the network layerrouting tables is needed. In SAFENET the ES/IS routing exchangeprotocol is required and meets the end systems’ routing needs.In order to reroute data units dynamically when the underlyingFDDI rings undergo segmentation, a number of 1Ss are required andthe 1S/1S routing exchange protocol is needed to provide dynamicroute determination. This type of reconfiguration capabilityreguires that multiple interconnected 1Ss survive on all of theisolated segments. System implementors need to design the numberand placement of 1Ss to meet the survivability requirements ofthe system being developed.

Stations which use multiple subnetwork routing do notprovide standardized methode for users to select which subnetworka particular communication will take. QOS capabilities (ifimplemented) may affect such a selection. It is permissible fora local means to be supplied by SAFENET product suppliers toinfluence the selection of specific subnetworks for specific datatransfers.

10.3.3 Concentrator tree touoloay. An example concentratortree topology is shown in Figure 16 for a four concentratorimplementation. As shown, this topology uses the mechanisms ofdual-homing for dual attachment stations. Although the devicesin Figure 16 are shown as concentrators, they actually maycontain the full SAFENET protocol stack and function as stationson the network.

10.3.3.1 Concentrator tree reconfiguration. Theconcentrator tree topology provides reconfiguration by using thedual homing policy to provide for a segment hop (switching to abackup fiber segment) when faults occur. This is achieved due tothe FDDI SMT rules, which state that a single MAC station favorsthe B port for data transfer and uses the A port only in theevent of loss of activity on the B port. Effectively, theconcentrators withhold the A port as long as the B port isactive.

In figure 16, in the event that a break occurs on one of thecables on the B side of the concentrator, the concentrator whichfalls directly after the break will switch to the A port. By thenature of the operation of a concentrator, all M ports are placed

81


MIL-HDBK-818 -1

kTcu

-

Concentrator TCU

w

A B

Concentrator

MM MM m

Figure 16. Concentrator Tree Topology

82


MIL-HDBK-818 -1

in the active data path and the A port immediately becomes theactive input of the concentrator. The other concentratorattachments in the tree remain active through the B ports. The Mports of the affected concentrator are switched to the active Aport and data transfer resumes. Additionally, the M port abovethe break is removed from the data path due to the break and thedata path is.not broken by the M port.

10.3.3.3 Concentrator tree conmo nents. The components ofthe concentrator tree topology are concentrators and TC!US. SeeMIL-STD-2204 for definition of a concentrator and methods ofinterconnection.

The concentrators are connected through TCUS (as shown infigure 16). Tree connections are used to connect the ports ofthe concentrator to the TC!U and an electrical interface cable isused to control the actions of the TCU. Note that the TCU is theexact same device as used on the tmnk ring, but the treeconnection to the TC!U is different than that of a standardstation connection.

83


MIL-HDBK-818 -1

84


MIL-HDBK-818 -1

11. SAFENET SECURITY GUIDANCE

11.1 Introduction. This section provides guidance forspecifying and developing implementations of SAFENET profileswhich provide added support in achieving data security. Anapproach is provided for identifying the necessary securityservices and allocating the services to the SAFENET protocols andmanagement elements. Implementation alternatives are alsoprovided. .-

11.2 ADDliCable Documents. The following is a partiallisting of applicable documents that may be of interest to thoseimplementing a system with security needs.

11.2.1 Government Documents.

11.2.1.1 Specifications, Standards, and Handbooks.

DOD 5200.28-STD Department of Defense TrustedComputer System EvaluationCriteria. December 1985.

CSC-STD-002-85 Department of Defenee PasswordManagement Guideline. 12 April1985.

CSC-STD-003-85 Computer Security Requirements -Guidance for Applying theDepartment of Defense TrustedComputer System Evaluation Criteriain Specific Environments. 25 June1985.

CSC-STD-004-85 Technical Rational Behind CSC-STD-003-85 Computer SecurityRequirements - Guidance forApplying the Department of DefenseTrusted Computer System EvaluationCriteria in Specific Environments.25 June 1985.

(Applications for copies should be addressed to the INFOSECAwareness Division, ATTN:IAOC, Ft. George G. Meade, MD 20755-6000. )

DOD 5200.28 Security Requirements for AutomatedInformation Systems (AISS). March1988.

85


MIL-HDBK-818 -1

MIL-STD-2204 Survivable Adaptable Fiber OpticEmbedded Network.

(Unless otherwise indicated, copies of federal and militaryspecifications, standards, and handbooks are available from theStandardization Documents Order Desk, Bldg. 4D, 700 Robbins Ave.,Philadelphia, PA 19111.)

11.2.1.2 Other Government Documents, r u .D awin s andPublications.

NATIONAL COMPUTER SECURITY-CENTER

NCSC-TG-001 A Guide to Understanding Audit inTrusted Systems. 1 June 1988.

NCSC-TG-002 Trusted Product Evaluations, AGuide for Vendors. 22 June 1990.

NCSC-TG-003 A Guide to UnderstandingDiscretionary Access Control inTrusted Systeme. 30 September1987.

NCSC-TG-004

NCSC-TG-005

NCSC-TG-006

NCSC-TG-007

NCSC-TG-008

NCSC-TG-009

Glossary of Computer SecurityTerms. 21 October 1988.

Trusted Network Interpretation ofThe Trusted Computer SystemEvaluation Criteria. 31

A Guide to UnderstandingConfiguration ManagementSystems. 28 March 198S.

A Guide to UnderstandingDocumentation in Trusted2 October 1988.

July 1987.

in Trueted

DesignSystems.

A Guide to Underetanding TrustedDistribution in Trusted Systems.15 December 1988.

Computer Security SubsystemInterpretation of the TrustedComputer System EvaluationCriteria. 16 September 1988.

86


MIL-HDBK-818 -1

NCSC-TG-011 Trusted Network InterpretationEnvironments Guideline -- GuidanceFor Applying the Trusted NetworkInterpretation. 1 August 1990.

NCSC-TG-013 Rating Maintenance Phase ProgramDocument. 23 June 1989.

NCSC-TG-014 Guidelines for Formal VerificationSystems. 1 April 1989.

NCSC-TG-015 A Guide to Understanding TrustedFacility Management. 18 October1989.

NCSC-TG-017 A Guide to UnderstandingIdentification and Authenticationin Trusted Systems. September1991.

NCSC-TG-019 Trusted Product EvaluationQuestionnaire. 16 October 1989.

NCSC-TG-025 A Guide to Understanding DataRemanence in Automated InformationSystems. September 1991.

NCSC-TG-026 A Guide to Writing the SecurityFeatures User’s Guide for TrustedSystems. September 1991.

C Technical Report 79-91 Integrity in AutomatedInformation Systems.September 1991.

(Applications for copies should be addressed to the INFOSECAwareness Division, ATTN:IAOC, Ft. George G. Meade, MD 20755-6000. )

DEPARTMENT OF THE NAVY

OPNAVINST 5239.1A Department of the Navy AutomatedData Processing Security Program.August 1982.

(Applications for copies should be addressed to the NationalTechnical Information Service, 5285 Port Royal Rd. , Springfield,VA 22161.)

87


MIL-HDBK-818 -1

SECNAVINST 5239.2 Department of the Navy AutomatedInformation System (AIS) SecurityProgram (Draft IRM/Cl). 15November 1989.

(Applications for copies ehould be addressed to the NavyPrinting Office, Standardization Documents Order Desk, Bldg. 4D,700 Robbins Ave., Philadelphia, PA 19111.)

Computer Security=uidebook forMission-Critical Computer ResourcesManaged Under the Research,Development, and AcquisitionProcess. 28 October 1990.

(Applications for copies should be addressed to the Spaceand Naval Warfare Systems Command, Warfare Systems EngineeringPolicy Division (SPAWAR 2241), Washington, DC 20363-5100.)

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

SDN.301 Rev 1.5 Secure Data Network System -Security Protocol 3. May 15, 1989.

SDN.401 Rev 1.3 Secure Data Network System -Security Protocol 4. May 2, 1989.

SDN.801 Rev 1.3 Secure Data Network System - AccessControl Concept. July 26, 1989.

SDN.802 Rev 1.0 Secure Data Network System - AcceesControl Specification. Ju~y 25,1989.

SDN.802/l Secure Data Network System - AccessControl Specification - AccessControl Information SpecificationAddendum 1. July 25, 1989.

SDN.902 Rev 3.2

SDN.903 Rev 3.2

Secure Data Network System - KeyPlanagement Protocol - Definition ofServices Provided by the KeyManagement Application ServicesElement. August 1, 1989.

Secure Data Network System - KeyBlanagement Protocol - Specificationof the Protocol for ServicesProvided by the Key Management

88


MIL-HDBK-818-1

Application Services Element.August 1, 1989.

(Applications for copies should be eddressed to the NationalTechnical Information Service, 5285 Port Royal Rd., Springfield,VA 22161.)

GOSIP 2.0 - U. S. Government Open Systems InterconnectionProfile (GOSIP), Federal InformationProcessing Standards Publication (FIPS PUS)146-1, 3 Apr 1991

(Applications for copies should be addressed to the U. S.Department of Commerce, National Technical Information Service(NTIS), 5285 Port Royal Road, Springfield, VA 22161)

11.2.2 Non-Government Publications.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (1S0)

1S0 7498

1S0 7498-2

1S0 9594-7

1S0 DIS 10164-7

1S0 DIS 10164-8

ISO/IEC JTC1/SC21N6693

Information Processing Systems -Open Systems Interconnection -Basic Reference Model. October 15,1984.

Information Processing Systems -0S”1 Reference Model - Part 2:Security Architecture. July 19,1988.

Information Technology - OpenSystems Interconnection - TheDirectory - Part 7: AuthenticationFramework. 1990 (e).

Information Technology - OpenSystems Interconnection - SystemsManagement - Part 7: SecurityAlarm Reporting. July 1991.

Information Technology - OpenSystems Interconnection - SystemsManagement - Part 8: SecurityAudit Trail Function. June 1991.

Information Technology - OpenSystems Interconnection - SecurityFrameworks in Open Systems - Part1: Overview. November 1991.

89


MIL-HDBK-818 -1

ISO CD 10181-2

1S0 CD 10181-3





1S0 DIS 10736

1S0 DIS 10736 PDAM 1

1S0 CD 10745

Information Technology - OpenSystems Interconnection - SecurityFrameworks in Open Systems - Part2: Authentication. May 13, 1991.

Information Technology - OpenSystems Interconnection - SecurityFramework in Open Systems - Part3: Access Control. June 24, 1991.

Information Technology - OpenSystems Interconnection - SecurityFrameworks in Open Systems - Part4: Non-Repudiation. November1991.

Information Technology - OpenSystems Interconnection - SecurityFrameworks in Open Systems - Part5: Integrity. November 1991.

Information Technology - OpenSystems Interconnection - SecurityFrameworks in Open Systems - Part6: Confidentiality. November1991.

Information Technology - OpenSystems Interconnection - SecurityFrameworks in Open Systems - Part7: Audit. May 1991.

Information Technology -Telecommunications and informationexchange between eystems - OpenSystems Interconnection - TransportLayer Security Protocol. October11, 1991.

Information Technology -Telecommunications and informationexchange between systems - OpenSystems Interconnection - TransportLayer Security Protocol - Amendment1: Security AssociationEstablishment. December 1991.

Information Technology - OpenSystems Interconnection - Upper

90


MIL-HDBK-818 -1

ISO CD 11577

ISO/IEC

ISO/IEC

ISO/IEC

ISO/IEC

JTCI}SC21N6587

J’1’Cl/SC21N6588

JTC1/SC21N6589

JTC1/SC21N6590

Layers Security Model. June 28,1991.

Information Technology -Telecommunications and InformationExchange Between Systetns - OpenSystems Interconnection - NetworkLayer Security Protocol. November13, 1991.

Second Working Draft - SecurityExchange Overview and SpecificationFramework (GULS Part 1). December5, 1991.

Second Working Draft - SecurityExchange Service Element ServiceDefinition (GULS Part 2). December5, 1991.

Second Working Draft - SecurityExchange Service Element ProtocolSpecification (GULS Part 3).December 6, 1991.

Second Working Draft - SecurityTransfer Syntax, EncodingProcedures, and Syntax Notation(GULS Part 5). December 5, 1991.

(Application for copies of International Organization forStandardization (1S0) documents should be addressed to theAmerican Nationai Standards Institute, 1430 Broadway, New York,NY 10018)

AMERICAN NATIONAL STANDARDS INSTITUTE

X3T4/92-007 Nonrepudiation using SymmetricEncipherment Algorithms. December13, 1991.

(Applications for copies of American National StandardsInstitute (ANSI) documents should be addressed to the AmericanNational Standards Institute, 1430 Broadway, New York, NY 10018)

INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS

P802.10B/D6 IEEE Standard for InteroperableLocal Area Network Security Part B

91


MIL-HDBK-818 -1

P802.1OC

- Secure Data Exchange. November16, 1990.

IEEE Standard for InteroperableLecal Area Network Security Part C- Key Management Proposal. May 21,1991.

(Applications for copies of Institute of Electrical andElectronic Engineers (IEEE) ‘documents should be addressed to theInstitute of Electrical and Electronic Engineers, 445 Hoes lane,Piscataway, NJ 08854-4150)

11.3 Acronvms. The following acronyms are ueed in thissection of the handbook.

AISANSICDCLNPCOMSECDISDoDDosESFDDIGOSIPGULSIBACIECIEEE

IS1S0

JTC1KNPLANNLSPNSA0S1PDUQOSRBACSAFENET

SDNSSDUSILS

Automated Information SystemAmerican National Standards InstituteCommittee DraftConnectionless Network ProtocolCommunications SecurityDraft International StandardDepartment of DefenseDenial of ServiceEnd SystemFiber Optic Distributed Data InterfaceGovernment 0S1 ProfileGeneric Upper Layer SecurityIdentity Based Access ControlInternational Electrotechnical CommissionInstitute of Electrical and ElectronicsEngineersIntermediate SystemInternational Organization forStandardizationJoint Technical Committee 1Key Management ProtocolLocal Area NetworkNetwork Layer Security ProtocolNational Security AgencyOpen Systems InterconnectionProtocol Data UnitQuality of ServiceRule Based Access ControlSurvivable, Adaptable, Fiber Optic, EmbeddedNetworkSecure Data Network SystemSecure Data UnitStandard for Interoperable LAN Security

92


MIL-HDBK-818 -1

sP3SP4TLSPTNITNIEG

TP4WDXTP

Security Protocol 3Security Protocol 4Transport Layer Security ProtocolTrusted Network InterpretationTrusted Network Interpretation EnvironmentsGuidelinesTransport Protocol Class 4Working DraftXpress Transfer Protocol

11.4 Background. The Survivable Adaptable Fiber OpticEmbedded Network (SAFENET) set of communication services offerslimited support in meeting the eecurity needs of a system thatmust process information subject to Department of Defense (DoD)regulations concerning data security. Capabilities of publishednational and international standards for communication services~:~;~dble to the provision of security services are currently

. A secure implementation of a system that uses SAFENETwill require security issues to be addressed at the SAFENETinterfaces and at the interfacing elements (e.g., operatingsystem, database management system, network management) .

As with the other sections of the handbook, this section isinformative only. To ensure a secure SAFENET implementation,specific language detailing the security requirements should beincluded in procurement specifications. This section providesguidance for specifying the necessary security requirements(i.e., security services) for SAFENET implementations.

In addition to providing technical support in meeting thesecurity needs of a system that uses the SAFENET protocols, anetwork may require certification/accreditation by appropriateauthority before being deployed. Depending on the securitypolicy in effect for a particular SAFENET installation and theownership of the network and connecting systems, this may be doneas part of the security certification/accreditation of the systemor it may be done separately.

11.5 Security desicrn urocess. This section describes afive step process that leads to specification of all necessarysecurity services in a system security design while maximizingthe use of standards and products. The five steps - policydevelopment, risk assessment, security eerviceselection/allocation, security standards and products selection,additional security mechanism selection (to fill any residualsecurity holes) - are described in detail below.

11.5.1. Policy development. The first step in the SAFENETsecurity design process is the development of a system security

93


MIL-HDBK-818-1

policy based on the operational concept for the system, highlevel threat knowledge, and guiding DoD security policy. Thesystem security policy should address types of data to beprocessed by the network, levels of each type of information andhow it should be protected, and network connectivity. Systemsecurity policy must address:

a. information and eguipment protection policy (e.g.confidentiality, integrity)

, b. human and eguipment/process access controlc. human authenticationd. system availabilitye. assurance levelsf. system interface policy.

System security policy must also identify the system users,their clearance levels and the type of access each type of userwill be allowed. Navy security policy is defined in OPNAVINST5239.1A and SECNAVINST 5239.2.

11.5.2 Risk assessment. The risk assessment process spansthe entire system life cycle. Risk assessments are conducted todetermine the degree of risk associated with threats andvulnerabilities in the system during the specification, design,implementation, and installation/operation phases. The followingitems should be considered when conducting a risk assessment.

11.5.2.1 Threats. A threat is any circumstance or eventwith the potential to cause harm to a system in the form ofdestruction, disclosure, or modification of information oreguipment, or denial of service. A description of some possiblethreats to systems that will be SAFENET-compliant is provided inparagraph 11.4.1.

11.5.2.2 Existina securitv countermeasures. A securitycountermeasure is anything that reduces the vulnerability of asystem to known threats. When designing a system that willinclude SAFENET, it is important to identify any knowncountermeasures inherent in the system concept or operatingenvironment. Countermeasures may be provided through physicalmechanisms, host computer systems, or particular products to beused in the system.

11.5.2.3 Vulnerabilities and vulnerability points. Avulnerability is a weakness in the system that could be exploitedby a threat. A vulnerability point is the system component wherea vulnerability exists. Each vulnerability and vulnerabilitypoint within the system should be identified and documented.

94


MIL-HDBK-818 -1

11.5.2.4 Threat scenarios. A threat scenario is apostulated series of events which collectively result insubversion of the system security. Applicable threat scenariosshould be defined to illustrate the perpetration of successionsof threats at multiple vulnerability pointe that result inunauthorized disclosure, modification or destruction ofinformation or eguipment, or denial of service.

11.5.2.5 Evaluation of risk. Risk is the potential forsuccessful exploitation of a vulnerability, given the ‘identifiedand proposed countermeasures. The damage that may be associatedwith system risks include unauthorized disclosure of information,unauthorized modification or destruction of information oreguipment, and denial of system services. The potential risk ofeach vulnerability being exploited should be determined from ananalysis of existing countermeasures identified and theireffectiveness in countering the vulnerability. The degree ofrisk (i.e., a combination of the sensitivity of the vulnerableinformation, eguipment, or communication service and theprobability of exploitation) associated with a particularthreat/vulnerability scenario should be divided into threecategories:

a. Low . The threat scenario is considered to be veryunlikely to occur, to have a low impact if it doesoccur, or to be completely controlled by existingcountermeasures.

b. Medium. The threat scenario is considered to have amoderate likelihood of occurrence, to have a moderateimpact if it does occur, or to be partially controlledby existing countermeasures.

c. High. The threat scenario is considered to have a highlikelihood of occurrence, to have a significant impactif it does occur, or not to be controlled by existingcountermeasures.

11.5.3 Securitv service selection/allocation. Once therisk assessment has been completed, the appropriate securityservices may be chosen and allocated to system elements. Theservices ehould be chosen and allocated to reduce the risk ofsystem vulnerabilities, to supplement existing countermeasures,and to optimize the performance and cost objectives for thesystem. A description of security services is provided inparagraph 11.4.2.

11.5.4 Securitv Standardslp roducts selection. Followingidentification of desired security services and their allocation

95


MIL-HDBK-818 -1

to system elements, appropriate standards or products must bechosen to provide these security services. SAFENET encouragesuse of products that conform to national or internationalstandards rather than proprietary products. A discussion ofavailable security standards is provided in paragraph 11.5.

11.5.5 Additional securitv mechanism selection. In somecases, the existing security standards and products will not besufficient to provide all required security services. “In thesecases, it becomes necessary to-define system-specific securitymechanisms to ‘tfill the holes!!. Any system-specific securitymechanisms should be presented to the appropriate standardsorganization to encourage standardization of the mechanism.

11.6 Threats and services. The following paragraphsidentify the threats that may exist in a SAFENET system.Following the discussion of threats is a discussion of securityservices in paragraph 11.4.2. The security services are thenmatched with the threats in paragraph 11.4.3.

11.6.1 Threats. The following paragraphs outline threatsthat should be considered when conducting a risk assessment.

11.6.1.1 Svstem access. Threats to system access includeattacks on the system from an intruder with access to theapplication software or operating system. This assumes anintruder has access to some form of user-machine interface in thesystem.

11.6.1.1.1 Browsing. Browsing includes attempts by a useror intruder to gain unauthorized access to network information.

11.6communica.purposes.executionfunctions

11.6

1.1.2 M:suse. Misuse is the use of processing orion services for other than official or authorizedMisuse includes both inadvertent and intentional

of malicious functions, performance of undesirableand errors of commission, omission, and oversight.

1.1.3 Penetration. System penetration includesattacks by unauthorized persons attempting to gain system accessby defeating the system security perimeter. Penetration couldlead to the realization of other threats (e.g., browsing,misuse) .

11.6.1.2 Communication access. The communication accessthreat includes passive and active attacks on informationtransferred over communication channels. The definition of thisthreat assumes an intruder has access to communication media orcomponents.

96


MIL-HDBK-818-1

11.6.1.2.1 Eavesdrou ping. Eavesdropping is the passivesurveillance of communication channels to gain illicit access totransmitted information. It is perpetrated through physical,electrical, and radio frequency taps into the conununicationchannel.

11.6.1.2.2 Traffic analvsis. Traffic analysis is thepassive collection, analysis, and interpretation of communicationpatterns to infer operational and logistics-related information.It is perpetrated through eavesdropping.

11.6.1.2.3 Emanations attacks. Emanations attacks areperpetrated through passive collection, analysis, andinterpretation of electromagnetic emissions from electrical andelectronic equipment.

11.6.1.2.4 SDurious communication. Spurious communicationincludes intruder attempts to establish communication connectionsor associations using a false identity through replay oflegitimate initiation sequences or communication messages.

11.6.1.2.5 Messaue stream modification. Message streammodification includes attempts to modify, delete, or insertinformation into a message stream while it is in transit over acommunication channel.

11.6.1.2.6 Denial of service attacks. Denial of Service(DOS) attacks prevent or delay the performance of legitimate orcritical communication services and includee the flooding of acommunication path with unauthorized messages.

11.6.1.3 TamDerinq. Tampering includes attacks on physicaland logical components in the network including substitutingrogue components in place of legitimate components, physicaltheft of components, damage to components, and electrical probingwithin the system. This assumes that an intruder has physical orelectrical access to the system components and their internalstructures.

11.6.1.3.1 Damaae. Damage attacks against systemcomponent destroy them or render them unable to perform theirintended mission.

11.6.1.3.2 Substitution. Substitution is the introductionof unauthorized and potentially malicious components to interceptcommunications, generate incorrect or misleading information,masquerade as legitimate components, or perform other undesirablefunctions.

97


MIL-HDBK-818 -1

11.6.1.3.3 Theft. Theft is the unauthorized removal ofsystem components.

11.6.1.3.4 Probing. Probing attacks on internal systemcomponents either obtain sensitive information contained withinthe components or explore the details of sensitive technology.

11.6.2 Securitv services. Security services are applied toa system to prevent or reduce a system’s -vulnerability to threatsand the resulting damage to the system or its information:Security services are categorized into access control,accountability, confidentiality, -data ‘integrity, and serviceavailability.

11.6.2.1 Access control. Access control is the preventionof unauthorized use of a resource, including the prevention ofuse of a resource in an unauthorized manner.

11.6.2.1.1 Identitv based access control. Identity BasedAccess Control (IBAC) limits access of epecific users to systemresources based on the user’s identity and need-to-know.

11.6.2.1.2 Rule based access control. Rule Based AcceseControl (RBAC) limits the access of users to system reeourceebased on the user possessing specific privileges (e.g. userclearance) that comply with the corresponding system accessrules.

11.6.2.1.3 Labelinq. Labeling is a service that supportsaccess control. Labels are markings bound to information, systemresources, or users that name or designate its eecurityattributes.

11.6.2.2 Accountability. Accountability ie the servicethat enables security-relevant activities on a system to betraced to individuals who may then be held responsible for theiractions.

11.6.2.2.1 Authentication. This process establishes thevalidity of a claimed identity. The are two parts toauthentication are described below.

11.6.2.2.1.1 Peer-entitv authentication. This corroboratesthat a peer entity in an association is the one claimed. Thisservice, when provided by the (N)-layer, provides corroborationto the (N+l)-entity that the peer entity is the claimed (N+l)-entity.

98


MIL-HDBK-818- 1

11.6.2.2.1.2 Data oriciin authentication. This corroboratesthat information transmitted over the network has beentransmitted by the claimed source.

11.6.2.2.2 Audit—. This service maintains system security-relevant activity information in audit logs and provides outputs,both in report and alarm formats, depending on the criticality ofthe information.

11.6.2.3 Confidentiality. The confidentiality serviceensures information is not made available or disclosed tounauthorized individuals, entiti”es, or processes.

11.6.2.3.1 Connection-oriented confidentiality. Thisservice protects all (N)-senice data units from unauthorizeddisclosure during communication between (N+l) peer entities,where a security association is established for the transfer ofdata and for the application of confidentiality service betweenthe entities themselves, and between each entity and the physicallayer.

11.6.2.3.2 Connectionless confidentiality. This serviceprotects (N)-service data units from unauthorized disclosureduring transmission from one (N+l)-entity to one or more (N+l)-entities, where each entity has an association with the physicallayer, and no association is established for the transmission ofdata or for the application of the confidentiality servicebetween the layer peer-entities themselves.

11.6.2.3.4 Traffic flow confidentiality. This serviceprotects information which might be derived from the observationof traffic flows by hiding information or providing misleadinginformation.

11.6.2.4 Data intecrrity. Data integrity is the propertythat verifies data has not been altered or destroyed in anunauthorized, undetected manner.

11.6.2.4.1 Connection-oriented intearity. This serviceprovides for the integrity of all (N)-service data on a securityassociation and detects any modification, insertion, deletion, orreplay of any data within an entire Secure Data Unit (SDU)sequence.

11.6.2.4.2 Connectionless inteclrity. This service providesfOr the integrity of a single SDU. Normally, connectionlessintegrity determines whether or not the received SDU has beenmodified.

99


MIL-HDBK-818 -1

11.6.2.4.3 Non-repudiation. This process providesunforgeable proof of information receipt or origin.

11.6.2.4.3.1 Non-reDudiation of OriUin. Thie processprovides unforgeable proof of information origin to either therecipient or a third party.

11.6.2.4.3.2 Non-reDudiation of receiDt. This processprovides unforgeable proof of information receipt to either theoriginator or a third party.

11.6.2.5 Service availability; Service availability is theability of the system to detect, recover from, and resist DOSconditions.

11.6.2.5.1 Protocol based denial of service Dr otection.Protocol based DOS protection is the ability of communicationprotocols to identify or support the identification of a DOScondition.

11.6.2.5.2 Continuity of operations. Continuity ofoperations is the ability of a system to recover from DOSconditions, and to continue operation following the detection ofa DOS condition.

11.6.2.5.3 Phvsical security. Physical security, whilebeyond the scope of the SAFENET standard, can be used to provideprotection against a number of threats identified in paragraph11.4.1. Physical security includes such things as guards,combination locks, protected spaces, and TEMPEST protection.

11.6.3 Relatinu services to threats. Table I illustratesthe correlation between threats and the security services usuallyapplied to reduce the vulnerability of a system to these threate.

11.7 Standards. The 1S0 eecurity architecture frameworkdoes not specify security protocols for the implementation ofsecurity services. However, for open systems to make use ofsecurity services, the format of security information in ProtocolData Unite (PDUS) of existing open system standard protocols, aswell as any security protocols, will have to be standardized.The following sections provide information on existing andproposed standards for security services and protocole.

The following eections include a number of references to theSecure Data Network System (SDNS) and two protocols from 1S0, theTransport Layer Security Protocol (TLSP) and the Network LayerSecurity Protocol (NLSP). The SDNS project was initiated by theNational Security Agency (NSA) to investigate methods of

100


MIL-HDBK-818 -1

Table I. Correlation Between Threats and Security Services

Threat Services to Mitigate Threat

System Access

System Browsing IBAC, RBAC, Labeling

System Bfieuse Audit, IBAC, RBAC, Labeling

System Penetration Authentication

Communication Access

Eavesdropping Connection-OrientatedConfidentiality, ConnectionlessConfidentiality

Traffic Analysis Traffic Flow Confidentiality

Emanations Physical Security (TEMPEST)

Spurious Authentication, Connection-OrientedCommunications Integrity, Connectionless Integrity

Message Stream Non-Repudiation, Connection-Modification Oriented Integrity

Denial of Service Continuity of Operations, ProtocolAttack Based 00S Protection

Tampering

Damage Physical Security

Substitution Authentication, Physical Security

Theft Physical Security

Probing IBAC, RBAC, Authentication

implementing security in distributed computer networks for U.S.Government and private sector users. However, some of the SDNSspecifications are not complete nor totally consistent with anumber of other security projects in the national andinternational standards arena. As a result, the SDNSspecifications are subject to modification for various reasons asthey progress through the standards process. For example, 1S0NLSP is derived from SDNS Security Protocol - Layer 3 (SP3), butthere are differences between the two protocols. The GovernmentOpen systems Interconnection Profile (GOSIP) intende to conform

101


MIL-HDBK-818 -1

to ISO Open Systems Interconnection (0S1) protocols to provideinteroperability in a heterogeneous environment. Therefore, itis very likely that 1S0 instead of SDNS security protocols willbe incorporated in later versions of GOSIP.

International Standards nay take a number of yeare to gofrom a new proposal to a final standard in the internationalcommunity. Standards in the international community require aminimum of four years to reach the international standard stage.There is no maximum amount of time. Draft standards-are-normallyconsidered stable when they have reached the Draft InternationalStandard (DIS) stager though this may vary depending on thedocument and the support for it within the internationalcommunity. The information in this section is intended toprovide information on work that is completed as well as workthat is in progress. Thus, Working Drafts (WD) and CommitteeDrafts (CD) have been included in the discussion. It should benoted that WDS are at least three years and CDs are at least twoyears from being an international standard.

11.7.1 Access control. Access control ie an importantconsideration in any system. It is necessary to guarantee thatonly authorized individuals gain access to classified orsensitive information. There is one proposed standard for theuse of access control in open systems, the Access ControlFramework. This document discusses both IBAC and RBAC.

The SDNS has published a set of access control documents,covering both IBAC and RBAC in the SDNS environment. Thefollowing paragraphs discuss these protocols.

Generic Upper Layers Security (GULS) ie an evolving securitystandard that deals with a generic application layer securityexchange. GULS could be used as a mechaniem for exchange ofaccess control information and labels between two applicationlayer entities.

11.7.1.1 Identitv based access control. Most standards ofIBAC deal with access to files within a computer system. IBACcould also be used to provide users with the ability to refuseconnections with other users or to refuse incoming messages.These capabilities would reside at the application layer.Implementation should be done with care so as to allow importantor emergency messages to override the IBAC function.

IBAC may also be provided at the transport layer. IBAC atthe transport layer is based on host identities and can be usedto limit network connectivity.

102


MIL-HDBK-818 -1

11.7.1.2 Rule based access control.implementations should allow users accesssensitive information based on clearance,

SAFENE!Tto classified orauthorization, and

need-to-know attributes. In a network environment these conceptsneed to be applied not only to the local system but also whenaccess is reguested to other users, hosts, and channels.

R8AC for user-to-user access is an application layerservice. Thie service is important when a user operating at ahigher security levei communicates with a user operatingat alower security level, whether or not information at the higherlevel is potentially transferred.

RBAC for host access and RBAC for channel access can betransport or network layer services. These services providechecks to make sure that a host is authorized to receive thelevel of information being sent or ie authorized to sendinformation to a destination host, and make sure a channel canprotect the level of information being transmitted. Thefollowing standards can be used, in conjunction with keymanagement and distribution, to provide this service.

11.7.1.2.1 Transport laver securitv Drotocol. The TLSP isa layer 4 protocol. By using the eecurity label field of theTLSP protocol, TLSP will verify that the level parameter fallswithin the set of acceptable security levels for the channel. Ifnot, the data is discarded.

11.7.1.2.2 Network laver securitv Drotocol. The NLSP is alayer 3 protocol. By using the security label field of the NLSPprotocol, NLSP will verify that the level parameter falls withinthe set of acceptable security levels for the channel. If not,the data is discarded.

11.7.1.2.3 Security Drotocol 4. The SDNS Security Protocol4 (SP4) is a layer 4 protocol. By using the security label fieldof the SP4 protocol, SP4 will verify that the level parameterfalls within the set of acceptable security levels for thechannel. If not, the data is discarded.

11.7.1.2.4 Security Drotocol 3. The SDNS SP3 is a layer 3protocol. By using the security label field of..the SP3 protocol,SP3 will verify that the level parameter falls within the set ofacceptable security levels for the channel. If not; the data isdiscarded.

11.7.1.3 Labeling. Labeling is required to support bothIBAC and RBAC. In the SAFENET context, users, hosts, channels,data packets, and files may require labels. Version 2.0 of GOSIP

103


MIL-HDBK-818 -1

includes a section on security labeling. Thie section dealsprimarily with labeling at the network layer (specifically,through extensions to the Connectionless Network Protocol(CI.NP)). If used in conjunction with SAFENET, it would bepoesible to use these labels at the application, transport andnetwork layers to indicate the eecurity level of all users,hosts, channels, data packets and files. Future versions ofGOSIP are expected to expand the security labeling etructure.

11.7.2 Accountability. The following paragraphs-discussprotocols which provide various accountability services.

11.7.2.1 Authentication. Authentication Framework is theone proposed standard for the use of authentication in opensystems. This document discusses all variations ofauthentication in a network or host system.

The Directory includes an authentication service. Thisservice can be used to authenticate hosts and ueers on a network.It reguires that a repository (either central or distributed) fordirectory information be maintained. The central repositorywould include an authentication certificate for each user or hostthat could be verified during the authentication process. Thedirectory is already part of the SAFENET standard.

As noted in the access control discussion, GULS is anevolving security standard that i“dentifies a generic applicationlayer security exchange. GULS could be used as a mechanism forexchange of authentication certificates between two applicationlayer entities.

11.7.2.2 Audit Audit Framework is the one proposedstandard for th~”of audit in open systems. This documentdiscusses the audit mechanism and the type of events that shouldbe audited in an open system.

The Audit Trail Function provides a description of auditevent logs and formats to be used in creating an audit trail.This document does not discuss the uses of audit or specificauditable events.

Once the audit trail has been captured, it needs to beprotected and analyzed. The audit trail is usually protectedfrom modification or even examination by any system user. Aseparate System Auditor is usually the only user allowed acceseto the file. The analysis of the file can be long and difficult.When large systems are involved an automated analysis tool is theonly way to provide complete analysis of the file in a realistictime period. The file can get very large even when care isexercised in selecting events to be audited. Any system should

104


MIL-HDBK-818 -1

contain the capability to select audited events. The systemshould allow events to be chosen for individuals, hosts, or theentire system.

11.7.3 Confidentialitv. Confidentiality may be providedthrough physical or encryption oriented methods. Physicalmethods include protection of the communication media fromdetection or the disabling of the communication media when acompromise is detected. Specific methods for implementingphysical protections-are beyond the ecope of this-document. - Thefollowing paragraphs will discues standards associated withencryption oriented methods for providing confidentiality.

The Confidentiality Framework is currently a WD. Itprovides an overview of confidentiality services and a discussionof the characteristics of encryption algorithms. It does notdiscuss specific encryption algorithms.

11.7.3.1 Data confidentiality. The following sectionsdiscuss the characteristics of existing protocol standards inthis area.

11.7.3.1.1 TransDort layer Securitv Drotocol. TLSP is alayer 4 protocol. It is specified as an addition to existinglayer 4 prOtOCOIS (such as Transport Protocol Class 4 (TP4)). Itis intended to provide algorithm independent connection orientedand connectionless confidentiality. TLSP can not be used withthe Xpress Transfer Protocol (XTP) in the lightweight profile.

11.7.3.1.2 Network laver eecuritv Drotocol. NLSP ie alayer 3 protocol. It can be implemented at either the top (aboveCLNP) or bottom (below CLNP) of the network layer. Since SAFENETrequires CLNP, it is necessary for NLSP to be used in theconnectionless mode. If NLSP is implemented at the bottom of thenetwork layer, data must be decrypted when in transit throughrouters since the routing would be done above NLSP. NLSP is alsoalgorithm independent.

11.7.3.1.3 Securitv Drotocol - laver 4. SP4 is a layer 4protocol. It is similar to TLSP and provides both connectionoriented and connectionless confidentiality. SP4 is algorithmindependent. SP4 can not be used with XTP in the lightweightprofile.

11.7.3.1.4 Securitv Drotocol - laver 3. SP3 is a layer 3protocol. SP3 is implemented at the top of the network layer.SP3 is algorithm independent and provides connectionlessconfidentiality.

105


MIL-HDBK-818 -1

11.7.3.1.5 Standard for htSrODf2rablf? 10Ctil area networksecur itv. The Standard for Interoperable Local Area Network(LAN) Security (SILS) is a layer 2 security protocol. It isdesigned to provide encryption over a ~ and provideconnectionless confidentiality. If used in SAFENET, SILS couldbe implemented as part of either the 0S1 or lightweight profiles,but all traffic would have to be decrypted as it passed from oneSAFENET LAN segment to another.

11.7.3.2 Traffic ’flow-confide ntiality.- Traffic flowconfidentiality has an inherent weakness on any LAN. Since alltraffic is essentially broadcast traffic, every station has theability to monitor traffic flow. Any attempt to prevent thiswould require extensive modification to the LAN protocol concept.

If traffic flow confidentiality is required on trafficbetween LAN segments, it is possible to disguise the size of thetraffic, but not the fact that traffic is occurring. NLSPprovides a traffic flow function that pads out each message to apredetermined length.

If a SAFENET system is to be implemented as a series ofinterconnected Ms., it is possible to use selective routing tobypass one LAN in favor of a more secure route. These types ofimplementations could use the existing routing protocols, EndSystem (ES)/Intermediate System(IS) and 1S/1S, to do this. BothDrotocols would be reouired to make routina decisions based on;ecurity parameters. “SAFENET does not spe;ify routingsecurity.

11.7.4 Intearitv. The following paragraphs willstandards associated with maintaining data integrity.

based on

discuss

11.7.4.1 Data inteuritv. Data integrity deals specificallywith the identification of errors or intentional modifications tothe data as it passes across the communication system. Whilemost communication protocols include mechanisms to check forerrors, these mechanisms are well known and may be circumventedwhen an intentional modification is made.

The Integrity Framework is currently a WD. It provides anoverview of integrity services. The following sections discussthe characteristics of existing standards in this area.

11.7.4.1.1 ‘1’ranSDOrt laver securitv Protocol. As noted inparagraph 11.5.3.1.1, TLSP is a layer 4 protocol. As a functionof the cryptographic algorithm, it can provide connectionoriented and connectionless integrity detection. TLSP can not beused with XTP in the lightweight profile.

106


MIL-HDBK-818 -1

11.7.4.1.2 Network layer securitv urotocol. As noted inparagraph 11.5.3.1.2, NLSP is a layer 3 protocol. As a functionof the cryptographic algorithm, it can provide connectionlessintegrity detection. If connection oriented integrity isdesired, a seguence number can be added to the integrity checkvia a Quality of Service (QOS) parameter.

11.7.4.1.3 Securitv Drotocol - laver 4. As noted inparagraph 11.5.3.1.3, SP4 is a layer 4 protocol. Through itscryptographic algorithm, SP4 can provide connection oriented’orconnectionless integrity detection. SP4 can not be used with XTPin the lightweight profile.

11.7.4.1.4 Securitv Drotocol - laver 3. As noted inparagraph 11.5.3.1.4, SP3 is a layer 3 protocol. ‘Through itscryptographic algorithm, SP3 can provide connectionless integritydetection.

11.7.4.1.5 Standard for interoDerable LAN security. Asnoted in paragraph 11.5.3.1.5, SILS is a layer 2 securityprotocol. Through its cryptographic algorithm, SILS can provideconnectionless integrity detection. If used in SAFENET, SILScould be implemented as part of either the 0S1 or lightweightprofiles.

11.7.4.2 Non-reDudiatio~. Guidance for non-repudiation isprovided in the Non-Repudiation Framework. This document is aWD . The framework provides information on non-repudiationmechanisms and issues surrounding the implementation of a non-repudiation service. There are currently no standards for non-repudiation mechanisms. Work is ongoing in 1S0 and ANSI onstandards for non-repudiation mechanism, but only one workingdraft is currently available. This document is calledNonrepudiation Using Symmetric Encipherment Algorithm.

11.7.5 Service availability. The following paragraphs willdiscuss standards associated with service availability.

11.7.5.1 Protocol based denial of service Protection.There are no standards that discuss Drotocol based DOSprotection. However, existing commufiication protocols, such asTP4 and Fiber Distributed Data Interface (FDDI), provide activeacknowledgements of receipt of data units. Any type of activeacknowledgement or negative acknowledgement provides a measure ofprotection. The key is to identify when a host, link, or routergoes down eo that the network manager can be notified andalternative means of communication implemented as quickly aspossible to minimize service loss or information loss.

107


MIL-HDBK-818 -1

11.7.5.2 Continuity of Operations. As with protocol basedDOS protection, there are no standards for continuity ofoperations. Existing communication protocols can be used toprovide some measure of protection. The protection provided islimited by the architecture of the system. If there are noalternate routes, operations can not be continued if the primarylink goes down. FDDI provides a measure of protection (throughits reconfiguration capabilities) as do routing protocols such as1S/1S and ES/IS (through the use of alternate routes). Systemarchitecture should be defined to use SAFENET reconfigurationoptions in a manner suitable to provide the required continuityof operations.

11.8 Architectural considerations. The interconnection ofa distributed set of nodes on a network plays an important rolein aggregate system security. Appropriate levels of informationclassification, user clearances, and system assurances must beconsidered in defining permissible network connections.Management of network information may require communicationbetween groups of systems that might otherwise not be required tocommunicate. Distributed directory and network managementdatabases may contain sensitive information that must beadequately protected. The distribution and management of keymaterial and access control certificates must be accomplishedthrough secure communication services. Security managementpolicies must be established to assist the network eecuritymanager in properly controlling information flow through multipleSAFENET interconnections.

The information contained in this section represents only asubset of the architectural security issues that apply to SAFENETimplementations. Each system will require security engineeringto ensure that the architecture and subsegment design andimplementation is tailored to address the specific threatenvironment.

11.8.1 Connectivity. Nhen integrating systems on anetwork, each communicating system must provide adequateassurance to comply with the aggregate risk index as defined bythe Trusted Network Interpretation Environmental Guidelines(TNIEG). The permissible connections should be defined in thenetwork security policy to limit host and user accesses to onlythose required to support the intended system mission.

The cascade problem, as defined in the Trusted NetworkInterpretation (TNI) , should be mitigated through strict networkhost access controls that permit only those hosts processinginformation at the proper levels and assurances to communicate.The problem exists when a penetrator can take advantage of

108


MIL-HDBK-818 -1

network connections tocompromise information acrossa range of eecurity levelsthat is greater than theaccreditation range of any ofthe component systems he mustdefeat to do eo. Figure 17chows how information may betransferred from System A toSystem B. The TOP Secretinformation in System A may becompromised to Confidential ifa Penetrator iS able to defeatthe protections of the twosystems. Figure 18 shows anexample of the nestingcondition. The nestingcondition is eatisfied if the

SYSTEM A

ElTS SYSTEM B

s

“--”-””---”-m

sc

Figure 17. The Cascade Problem

accreditation ranges of every node pair within a network areeither disjoint (have no common elements) or nested (one is asubset of the other) . The nesting condition ie one method ofprotecting against the cascade problem.

Host accese controls should be implemented according to aclearlv defined network securitv Dolicv. The network securitvadmini~trator should be respons~bie fo~ executing this policy-through careful control of the diis.tribution of key material, hoetauthentication certificates and RBAC. Controlled access to endsyetem services by users is an important matter that must behandled outside the implementation of SAFENET by the hostoperating systems andapplications eoftware.

11.8.2 Management.Nhile the SAFENET handbookservice definitions provide abasis for constructing securenetworks, additional controlsmust be properly implementedand managed. Theadministration of systemsecurity will include thedistribution of securityinformation, management ofaudit repository, andimplementation of accesscontrols to network securityinformation. The functionsprovided by the security

an

Figure 18. The Nesting Problem

109


managersuppo*

11.

MIL-HDBK-818-1

must be distinctly separated from those provided tothe remainder of the network management functions.

8.2.1 Distribution of securitv information. Privatelyheld information will be necessarY to control access to sensitiveand critical information and proc~sses distributed across thenetwork. Security control information may include usercertificates for authentication, host certificates for hostaccess controls, audit information, and access control lists. Toensure resources protected by thie-information remain adequatelyprotected, the distribution, management, and storage of security-relevant information must”be adequately protected through accesscontrols, confidentiality, and integrity services.

The distribution of security information may take one ofthree forms:

a. Physical distribution, where security information isdirectly loaded into each host participating in secureprocessing and communications

b. Distributed information transfer, where securityinformation is transferred to all hosts by some centralsecurity manager or managers

c. Distributed through a combination of physicaldistribution for initial ltboot!iinformation, followedby network distribution of remaining information.

Each of these approaches has positive and negative impactson system security and management. Physical distribution of allinformation may involve a significant amount of phyeicaldistribution of information, presenting a large administrativeburden to the security manager in tracking the physical locationof the media containing the security information. On-linedistributed transfers, while minimizing administrative burdens,may increase the risk of information disclosure or modificationwhile security information is transferred over the network. As acompromise, a combination of distribution methods may bestminimize administrative burden and system security risk. Thecombination may additionally provide the necessary protection tosecurity information transferred over the network. The specifictechniques chosen for a given network implementation must bebased on a trade-off of network complexity, physical proximity ofhosts, cost, performance, and sensitivity and criticality ofinformation and processes.

In general, security control information should be treatedat the level of sensitivity and criticality of the information

110


MIL-HDBK-818 -1

and processes that.it protects. The following paragraphsdescribe the security control information that should be managedand protected.

11.8.2.1.1 Authorized host con nections. Authorized hostconnection information nay take the form of ES/ES permissibleinterconnect tables, additional host access control lists, andcryptographic key linkages. Since this information providesinitial access to an end system, it should be protected to thelevel of the most sensitive information or processes-residing onthe host system.

11.8.2.1.2 Subiect certificates. The authenticationframework discusses subject certificates to authenticate subjectsresiding on a network, which are subsequently used by accesscontrol mechanisms as unique, unforgeable identifiers. Thesubject certificates may optionally be contained within adistributed directory service database, if the access controlswithin the database are managed to permit only the securitymanager and the authentication process to gain direct access toinformation contained within the certificate. Individualsubjects should reguire only indirect access to this informationto prompt the process to perform some form of authentication.This access may take the form of a direct reference by name,provided the operating system provides local authentication ofthe requesting subject to prevent local (within the same host)misuse of the certificate.

11.8.2.1.3 Host certificates. Host certificates, when notunder the control of approved Communications Security (COMSEC)mechanisms, should be controlled to limit access to only atrusted implementation of the network layer software andhardware. When the host certificates take the form of Type ICOMSEC keye, the certificates should be managed following themeasures described in the key management discussion (seeparagraph 11.6.2.4). Since the certificates provide a controlpoint for all information entering a given host, physicaldistribution methods should be used to load the certificates intoeach host. After the initial physical distribution, on-linesecure network-based transfers may be used to distributeadditional host certificates.

11.8.2.2 Audit cauture. Implementation of mechanisms tocapture audit information will require the definition of theamount, type, and storage location of security-relevantinformation to be captured. In general, all audit informationmust initially be captured in all network componentsparticipating in the SAFENET LAN segment. While this is the mostexpedient method of developing and certifying a collection

111


MIL-HDBK-818 -1

mechanism, analysis of the information to identify and controlpotential security probleme may reguire some form of centralizedcollection and processing of information. To ease the burden onsecurity personnel in processing audit information, anapplication may be necefsa~ to collect audit information usingnetwork management serv~ces and to generate audit information.Distributed security management applications may be necessary toidentify critical events and transmit alarm messages to acentralized security manager.

..

11.8.2.3 Manaaer connectivity. When a network based onSAFENET comprises multiple, operationally independent collectionsof interconnecting hosts, the addition of dedicated hosts toprovide network and security management services poees apotential risk to system eecurity. The alternative inconnecting network and security management systems include:

a. Separate network manager hosts for each group ofcommunicating systems

b. A central repository that only collects information andis incapable of transmitting (another system would beresponsible for issuing audit information requests tobe directed to the recipient)

c. A highly trusted central network management host.

The choice of alternatives will depend on the architectureof the overall system. Accese to network manager systems shouldbe limited to those individuals cleared to the level of the mostclassified or sensitive information contained within the eyetems.Since this information may contain records of user levelconnections and information transfers, the network/securitymanagement personnel should be authorized to obtain access to theinformation prior to accessing the network management facility.

11.8.2.4 Kev management. If cryptographic mechanisms areused in the system, some form of key management will be required.The key management system functions include key generation, keydistribution, key transfer, key update, rollover, destruction,periodic modification of, and accounting for all keys used by theencryption services provided within the system. The followingsections discuss the three existing key management standards.

11.8.2.4.1 Secure data network svstem kev manaciementprotocol. The SDNS Key Management Protocol (KMP) was designed toprovide key management services for all SDNS protocols (SP3,SP4) . It is an application layer protocol and can be used to

112


MIL-HDBK-818 -1

provide services to support cryptographic mechanisms (for dataconfidentiality and integrity) at any layer of the 0S1 model.

11.8.2.4.2 Standard for interoDerable LAN securitv. SILSalso provides a key management standard. It was originallydesigned to support the cryptographic mechanisms of SILS but canbe used with cryptographic mechanisms at any layer. It is alsoan application layer protocol.

11.8.2.4.3 Transport laVer eeCUritV Drotocol addendum. 1S0has been working on a security association establishment protocolfor use with TLSP. This protocol is specific to TLSP andoperates at the transport layer.

11.8.3 Assurance. Assurance is the method of determiningthe trust that can be placed in a processing device and software.The assurance of a device or system depends on the design,analysis, testing, and performance of the installed devices.Assurance is not determined by the security services that areimplemented within a system. The final arbitrator of theassurance of a system is the Certification Authority or theDesignated Approving Authority.

The level of assurance required by a eystem depends on thetype and classification level of data that it will carry and theclearance level and type of users that will be allowed access tothe eystem. The TNIEG can be used to determine the requiredlevel of assurance for a given application.

113


MIL-HDBK-818 -1

114


MIL-HDBK-818 -1

12. SAFENET TIME SERVICE

12.1 Introduction. The purpose of this section is toprovide a discussion on some of the critical aspects for systemengineers working with the SAFENET Time Service (STS). There area number of factors of the STS that require the attention of thesystem engineer. The performance and stability of this serviceis heavily influenced by decisions made at the time of systemdesign and deployment. Additional guidance on the implementationof NTP can be found in RFC 1305.

For the purposes of this discussion, the followingdefinitions are provided. Precision (referred to as clockgranularity in MIL-STD-2204) is the resolution of the value ofGlobalTime provided by the network clock. Stability is a measureof how well a network clock maintains a constant frequency.Accuracy is how closely GlobalTime compares with the desiredreference time for the system. The concept of reference time isdiscussed further in 12.3. A host is considered the networkclock in the local SAFENET node; a peer is the network clock inthe remote SAFENET node with which the NTP protocol machine inthe local node is exchanging time information. A synchronizationsubnet is the logical tree structure organized for the purposesof synchronizing all the nodes in a SAFENET system. Epoch is thedate chosen for the beginning of the SAFENET timescale (January1, 1970).

12.2 The SAFENET timescale. MIL-STD-2204 defines aspecific timescale for the STS. This timescale is based on thedefinition of GlobalTime. The two factors that distinguish thistimescale are the origin and the manner in which leap seconds arehandled. The SAFENET timescale has an origin of January 1, 1970.It is initialized to zero at O hours, O minutes, and 0.0 secondson that day, and counts consecutive seconds continuously fromthat point. This approach results in a continuous timescale thatcovers approximately 136 years. This timescale is defined foruse within the boundaries of the STS. Conversions to and fromother time formats are outside the scope of SAFENET. However,the system engineer must be aware of Coordinated Universal Time(UTC) and the difference between GlobalTime and UTC in order touse external references and design conversion routineseffectively.

UTC is the conventional civil timescale. UTC is generatedby national standards bodies using very precise atomicoscillators. As a result of slight variations in the speed ofrotation of the earth, the timescale generated by these atomicoscillators must be adjusted. This adjustment is referred to asa leap second. Nhen the error approaches 0.7 seconds, a leap

115


MIL-HDBK-818 -1

second is added to or deleted .from the UTC timescale on the lastday of either June or December. This event is determined inadvance and notification is distributed by various standardsorganizations including the U.S. Naval Observatory.

To avoid one second discontinuities in clocks in SAFENETnodes, the STS chose not to incorporate leap seconds. The STSmaintains a continuous timescale. When a leap second is added toor deleted from UTC, this information is distributed to allinstances of the STS using the NTP protocol; however, thisinformation does not have any impact on the value of GlobalTimein the network clock. Leap second information is maintained bythe time manager for use by routines that perform conversions toother time formats and from external references. Leap eecondsare an issue only at the boundaries of the STS.

12.3 Reference time. Reference time is an abstraction usedhere to help the reader visualize the functioning of the STS.The clock synchronization service in essence synchronizes thenetwork clocks in a SAFENET network to a reference time.Reference time can be either a time standard or an ensembletimescale. A time standard can be an external source of timeinformation such as the Global Positioning System (GPS) or acalibrated atomic clock. Alternatively, a time standard can be aparticular network clock designated as the reference for thatsystem. Reference time could also be an ensemble timescale. Anensemble timescale is one that is” derived from a number ofsources using a predefine mechanism (election, arbitraryselection, etc.) . There are a number of ways to define anensemble timescale. In any case, it is the responsibility of thesystem engineer to evaluate the requirements of the system andchoose an approach for providing reference time to that system.The provision of a form of reference time to a system is outsidethe scope of SAFENET.

12.4 Svstem configuration. Proper configuration of thesynchronization subnet is critical for acceptable performance ofthe STS. There are two aspects of configuration that snust beaddressed by the system engineer. For each SAFENET node or hostin the SAFENET system, the set of peers with which the particularhost will exchange information must be defined. In addition, thetype of service employed between each host/peer pair must bespecified. Based on this configuration information and thecurrent conditions in the SAFENET network, a synchronizationsubnet is dynamically formed. This synchronization subnetreconfigures within the limits established by the configurationchosen. Finally, the behavior and performance of thesynchronization subnet is affected by a number of parameterchoices within the NTP protocol.

116


MIL-HDBK-818 -1

12.4.1 Peer selection. The first aspect of configurationis the choice of peers with which a particular host (SAFENETnode) will communicate for the purpose of exchanging timeinformation. In the current NTP specification there is no meansfor automatically discovering time servers in the network. Amanager needs to specify manually the set of peers with whicheach host will exchange NTP PDUS. This specification can be donevia a configuration file or through manipulation of managedobjects. Considerations to be made when choosing the set ofpeers include the distance between the two nodes, the expectedquality of the peer’s network clock, the accuracy requirementsfor the host’s network clock, and the expected synchronizationload at the peer. Each host should maintain associations with atleast three peers for better results when selecting asynchronization source and during various failure scenarios.

12.4.2 Modes of service. The second aspect ofconfiguration is choosing the type of service used between eachhost/peer pair. There are three service classes available in theNTP protocol. These service classes are a procedure callservice, a symmetric service, and a multicast service. Theseservice classes are implemented using a selection of five modesof service (server, client, symmetric active, symmetric passive,and broadcast) . Each network clock can operate in multiple modesof service based on its configuration and that of the variouspeers with which it is communicating. From that set of peers, ahost will select a synchronization source using the peerselection algorithms. This selection will be based on the rulesassociated with the various modes of service. In addition, onlychoices of modee of service that form an identified class ofservice are allowable within NTP.

The procedure call class of service defines the interactionbetween nodes acting in the server and client modes of service.In this case, the server is willing to provide synchronization tothe client but not to accept it. The client, on the other hand,is willing to accept synchronization from the server but notprovide it. The client makes a request to the server and theserver responds. In this class of service, the accuracy benefitsof the two way exchange of time are achieved; however, theconfiguration is more static because only the server can bechosen as a synchronization source.

The symmetric class of service is a more generalizedsituation. In this class of service, a host, operating in eithers-~tric active Or smetric passive modes, is willing toprovide synchronization to or accept synchronization from a peer,also operating in either symmetric active or symmetric passivemodes. This relationship aleo benefits from the two way exchange


MIL-HDBK-818-1

of time. In addition, a Ildynanically reconfigurable~

hierarchically distributed” configuration can be achieved becaueeindividual nodes are willing to both provide synchronization andreceive it.

The final class of service provided by NTP ie multicast. Inthis situation, a server is willing to provide synchronization toclients but not to accept NTP PDUe from that client. The clientuses an aesumed delay instead of calculating it based on the two-way exchange of time. This mode of service may be lees accurate:however, it is simpler and may be suitable for some systems orfor a subset of the machines in a system.

12.4.3 Hierarchal structure. The NTP system forms ahierarchal synchronization subnet following the conventions ofthe telecommunications industry. Using the peer eelectionalgorithms, each host selects a single peer as itssynchronization source. Based on these choices, asynchronization subnet is formed. The servers closest toexternal sources or to reference time are assigned a low number,called stratum, indicating their proximity to the root of thetree and indirectly their accuracy. As one progresses outwardtoward the leaves in the tree, each successive eerver encounteredhas a stratum number that is the stratum value of its ownsynchronization source, incremented by one. As a result, thestratum of a particular network clock dynamically reflects howfar that node is from the root of”the synchronization subnet.The system engineer can manipulate the structure of thesynchronization subnet by the choice of peers and modes ofservice. The network clocks close to the root of thesynchronization subnet should be some of the better gualityclocks in the system in order to promote good accuracy andstability.

12.4.4 Parameter values. There are a number of parameterdefined in the NTP specification. The values of these parametershave been explicitly engineered for the Internet environment.MIL-STD-2204 requires that the STS be able to modify theseparameters. For the best results, at least a few of theseparameters will need to be adjusted for the SAFENET environment.The system engineer will need to spend some time characterizingthe requirements of the specific syetem and engineering theparameter values appropriately. It is noted here that somecurrent implementations of NTP treat these parameter as compiletime constants. It is the intention of the STS that these bemodifiable during execution. Some of the parameters that mayreguire special engineering for a SAFENET system are brieflydiscussed below. This is only overview material. Additionalguidance is provided in RFC 1305.

118


MIL-HDBK-818-1

12.4.4.1 Protocol parameters. There are a number ofprotocol parameters that have an impact on the performance of theSTS . The minimum and maximum polling intervals affect howguickly the STS can initialize and react to changing conditionsin the synchronization subnet. Another consideration whenmodifying this parameter is the network traffic that will resultwhen smaller intervals are used. In addition to the pollingintervals, the maximum distance parameter is used to control howmany exchanges between the host and peer occur before the clockconeiders itself initialized. Ae a result, this parameter isalso used to help specify the initialization time. If the valueis set to the maximum dispersion value, initialization can occurafter a single exchange of timestamps. Each time thie value ishalved, the number of timestamp exchanges required is increasedby one. The next parameter, the maximum clockage, identifiesthe amount of time after a server has become disconnected from asynchronization source that it considers itself to have correcttime. This also affects how long a client will continue toaccept time from a server when that server has lost itssynchronization source. The maximum skew parameter specifies themaximum frequency variation permitted by a client. It isspecified as the maximum offset error that can occur over theinterval specified by the maximum clock age. The minimum andmaximum dispersion parameters affect a number of things,including the number of timestamps that muet be exchanged beforeinitialization or tracking and the importance of various samplesin the peer selection process.

There are also a number of parameters that affect theconfiguration of the synchronization subnet. The maximum stratumparameter limits the depth of the synchronization subnet. Forwell managed systems, it may be acceptable to have a more shallowsynchronization subnet than is currently used in the Internet.The minimum and maximum select clock parameters control thenumber of peers that a host will consider when choosing asynchronization source. Appropriate use of these parametersallows the system to use enough peers to maintain a robust systemwithout using too large a number and consuming an excessiveamount of resources.

12.4.4.2 Clock Parameters. The local clock model used inNTP has a number of relevant parameters. These need to beexamined when building a Network Clock implementation forSAFENET. Of particular interest are the adjustment interval andthe maximum aperture. The adjustment interval specifies theamount of time between each clock adjustment. The maximumaperture specifies the interval over which an offset can begradually applied to the Network Clock. If the offset value

119


MIL-HDBK-818-1

determined is greater than the maximum aperture, a stepadjustment may be required.

12.5 Performance Parameters. The following performanceparameters are recognized as being vital to the operation of theclock synchronization service. While no performance requirementsare imposed by the STS, these parameters need to be specified ina system design in order to determine the correct operationalparameters of the time synchronization protocol.

12.5.1 Clock synchronization accuracy. The required clocksynchronization accuracy needs to be specified. Thisspecification is made by identifying the following condition.The network clock in a LAN node shall be maintained such that thedifference between any two network clocks sharing a peer pathdoes not exceed a given value (i.e., 0.5 binary milliseconds).Also , the difference between any two clocks in a SAFENET system(including those residing on separate interconnected LANsegments) shall not exceed twice the given value (i.e., 1.0binary millisecond) relative to a common frame of reference.

12.5.2 Clock initialization and fault detection times. Theclock initialization time and the fault detection time parametersneed to be specified in order to determine appropriate pollingrates for the tine synchronization protocol in a specificnetwork. These two parameters are related but distinct. Clockinitialization time refers to the time that it takes for anetwork clock to bs synchronized to within the clocksynchronization accuracy upon initialization or reset. Faultdetection time refers to the time it takes to recognize a faultyclock in an operational network. The first of these parametersimpacts the polling interval during initialization, and thesecond impacts the polling interval during normal operation ofthe network. Also impacting these parameters is theconfiguration of the system. Care must be taken when configuringthe system in order to obtain reasonable initialization timesacross multiple LAN segments.

12.5.3 Use of an external time reference. The process ofsynchronizing a network clock in a SAFENET network to an externaltime reference is a local matter. While SAFENET establishes noperformance requirements for this function when it is present,the system engineer needs to choose external time references thatmeet the synchronization requirements of the system. Inaddition, the STS will need the specifications of any externalrefereIICeS chosen in order for the protocol to select reliablepeers. This would include such things as the frequency toleranceand the synchronization distance.

120


MIL-HDBK-818-1

12.6 Network clock imulementatioq. A Network Clock is thecombination of the hardware and software used to provide a localsource of time. The implementation of a Network Clock is a localmatter. However, some guidance on this topic is provided here.Additional guidance is provided in RFC 1305.

The two basic characteristics of a clock are phase andfreguency. In this context, to synchronize a clock is tosynchronize both its phase and ite frequency. As stated in MIL-STD-2204, the network clock must be implemented in such a waythat both the phase and freguency corrections provided by theclock synchronization service have a positive impact on theperformance of the network clock. The phase of an individualnetwork clock can be synchronized in a relatively short period oftime; however, synchronizing the frequency of a clock requiressignificantly longer periods of time. The system engineer needsto make design trade-offs between quality of synchronizationachievable, the time reguired to achieve that reguired level ofsynchronization, the expense of any specialized components used,and the network resources used in the process.

Once the system engineer has implemented the network clock,certain performance characteristics of that network clock need tobe identified and specified for the accurate performance of theSTS . In particular, the system engineer needs to be able tobound the freguency offset of the network clock implementationsin the absence of any outside synchronization. This ie in orderto maintain correct error bounds and provide accuracy guarantees.In addition, such parameters as stability, wander, jitter, andavailability are used to characterize a particular network clock.

12.7 Management of the STS. The management aspects of theSTS are an important part of this service. MIL-STD-2204specifies managed objects for use by the time manager. Allremaining specification is left to the system engineer. A numberof functions that should be supported are presented below. Inaddition, a few critical issues are discussed. Additionalspecification is needed for a completely interoperableimplementation of the time manager.

12.7.1 Time management functions. A number of functionsare necessary for an implementation of a time manager. Some ofthese functions are specified below. The method of implementingthese functions is not specified. Additional functions may berequired for a complete realization of the STS. These additionalfunctions are also not specified.

12.7.1.1 Time synchronization DrOtocOl configuration. Thetime manager needs to provide mechanisms for the dynamic

121


MIL-HDBK-818 -1

manipulation of peers, polling intervals, and modes of operation.The time manager needs to have the capability, within limitationsspecified at eyetem design time, to change these selectionsdynamically during operation of the eystem.

12.7.1.2 Time synchronization Drotocol Parameters. Thetime manager needs to provide access to the basic parameters ofthe time synchronization protocol. For efficient operation, allinstantiations of the protocol neede to use the same parametervalues. The time manager neede to-have mechanisms to set theseparameters dynamically and distribute them to all instantiationsof the protocol.

12.7.1.3 LeaD second indication. The time manager needs toprovide a mechanism for a network manager to set an indicationthat a leap second is about to be added to or deleted from theUTC timescale. The time synchronization protocol (NTP) thenhandles distribution of this indication to all cliente. The timemanager also needs to keep track of the total number of leapeeconds that have accumulated in the UTC timescale. Thie ie tofacilitate the conversion to and from other time formats.

12.7.1.4 STS initialization. The time manager needs toprovide support for initialization of the STS. In particular,the time manager needs to be able to support various values ofprotocol parameters in order to meet the requirements for timeinitialization. The sequence of events for this procese is yetto be defined.

12.7.2 Critical issues. There are a number of criticalissues involved with the time manager. A few of these arebriefly discussed here. First, there is no interface specifiedbetween NTP and the time manager. Some guidance is provided inRFC 1305: however, this is not enough to ensure independentinteroperable implementations of the time manager. In addition,there is no standard method to stop and restart an STS entity.In order to support dynamic reconfiguration of modes of serviceand parameter values in an interoperable manner, this must bespecified. These are currently unspecified in MIL-STD-2204. Thesystem engineer needs to be aware of these issues.

122


MIL-HDBK-818-1

Custodians:Army - ERNavy - ECAir Force - 10

Review Activities:Army - TM, SC, IE, ET, ACNavy - CG, TDAir Force - 02, 17, 21, 23, 26

Preparing Activity:Navy - EC(Project - MCCR 0037)

123


STANDARDIZATION DOCUMENT IMPROVEMENT PROPOSAL

T. The preparing activity must complete blocks 1, Z. 3, and & In block 1, both the document number and revisionletter should be given.

2 The submitter of this form must complete blocks 4,5,6, and 7.

3. The preparing activity must provide a reply wtthm 30days from receipt of the form.

NOTE: This form may not be used to request copies of documents, nor to request waivers, or clarification ofrequirements on current contracts. Comments submitted on this form do not constitute or imply authorization towaive any portion of the referenced document or to amend contractual requirements.

OOCUMENT TITL3Survivable Adaptable Fiber Opt ic Embedded Network ( SAFENET) Network Development Guidance

NATURE OF CNANG f ( I d e n t i f yparagraph number ●id include proposed m write, If possWe. AStach ●x7r4 ShWU 4$ M*&d.)

REASON FORRICOMMENOAIION

-. 1“S203Ledwg ;ike,Suiw 1403,Falls church,VA Z20S1-3~66Teleohone(703)756-2344 AUTOVON289-2340

Form 1426, OCT 89 Previous ●ditmns ●m obso(ete. 1ss?90
