PARAGRAPH PAGE

D.1 GENERAL. 451D.1.1 Scope. 451D.1.2 Applicability. 451D.2 APPLICABLE DOCUMENTS. 451D.2.1 General. 451D.2.2 Government documents. 451D.2.2.1 Specifications, standards, and handbooks. 451D.2.2.2 Other Government documents, drawings, and publications. 452D.2.3 Non-Government publications. 452D.2.4 Order of precedence. 454D.3 DEFINITIONS. 454D.3.1 Standard definitions. 454D.3.2 Abbreviations and acronyms. 454D.4 GENERAL REQUIREMENTS. 456D.4.1 Introduction. 456D.4.2 Networking controller. 456D.4.2.1 Data structures. 457D.4.2.1.1 Routing table. 457D.4.2.1.2 Path quality matrix. 457D.4.2.2 Route selection. 457D.4.2.3 Message store and forward. 458D.4.2.4 Automatic message exchange (AME). 458D.4.2.5 Connectivity exchange. 458D.4.2.6 Standard levels of capability. 458D.4.2.7 Link selection. 458D.4.2.8 Interface to link controllers. 459D.4.2.8.1 Link control. 459D.4.2.8.2 Link quality reporting. 459D.4.2.8.3 Network messages. 459D.4.3 Interface to other media. 460D.4.4 Network management. 460D.4.4.1 Network management functions. 460D.4.4.2 Network management application program capabilities. 460D.4.4.3 Simple Network Management Protocol (SNMP). 461D.4.5 Multiple-media networks. 461D.5 DETAILED REQUIREMENTS. 462D.5.1 Introduction. 462D.5.2 Networking functions. 462D.5.2.1 Route and link selection. 462D.5.2.1.1 Path quality matrix. 463D.5.2.1.2 Routing table. 465D.5.2.1.2.1 Organization. 465D.5.2.1.2.2 Manual entries. 465TABLE OF CONTENTS(continued)PARAGRAPH PAGED.5.2.1.2.3 Automatic updates. 466D.5.2.2 Indirect calling. 466D.5.2.3 Network layer header. 466D.5.2.4 Connectivity exchange. 466D.5.2.4.1 Voice path quality. 467D.5.2.4.2 Data path quality. 467D.5.2.4.3 CONEX message format (Optional). 470D.5.2.4.4 CONEX broadcast. 472D.5.2.4.5 CONEX handshake. 472D.5.2.5 Message delivery. 473D.5.2.5.1 AME header. 473D.5.2.5.2 Message store and forward. 474D.5.2.5.3 Null store and forward function. 475D.5.2.5.3.1 Outgoing messages. 475D.5.2.5.3.2 Incoming messages. 475D.5.2.5.4 AME. 475D.5.2.5.4.1 Outgoing messages. 476D.5.2.5.4.2 Incoming messages. 476D.5.2.6 Relay management protocol. 476D.5.2.6.1 HRMP address field. 477D.5.2.6.1.1 Message destination. 477D.5.2.6.1.2 Message source. 477D.5.2.6.1.3 Desired destination. 477D.5.2.6.2 HRMP message identification field. 477D.5.2.6.3 HRMP length field. 478D.5.2.6.4 HRMP commands. 478D.5.2.6.5 Checksum. 480D.5.2.6.6 HRMP operation. 480D.5.2.6.6.1 Routing queries. 480D.5.2.6.6.2 Repeater control. 480D.5.2.6.6.3 Connectivity monitoring. 481D.5.2.7 Station status protocol. 482D.5.2.8 Network broadcast address. 483D.5.2.9 Checksum computation. 483D.5.2.10 Data transmission order. 483D.5.3 Network management. 483D.5.3.1 Terminology. 484D.5.3.2 Management protocol. 484D.5.3.2.1 Inside local HF station. 484D.5.3.2.2 Outside local HF station. 485D.5.3.3 Management information. 485D.5.3.3.1 HF Management information base (MIB). 486TABLE OF CONTENTS(continued)PARAGRAPH PAGED.5.3.3.2 Encoding rules. 486D.5.3.4 Proxy management. 486D.5.3.5 Access control. 487D.5.3.5.1 Administrative model. 487D.5.3.5.2 Authentication. 487D.5.3.5.2.1 Trivial authentication. 488D.5.3.5.2.2 Personal identification number (PIN) authentication. 488D.5.3.5.2.3 Cryptographic authentication. 488D.5.3.6 Traps. 488D.5.4 HFNC interface to local equipment (station data bus). 489D.5.4.1 Station network message format. 490D.5.4.2 Station data link protocol. 490D.5.4.2.1 HDLC mode for SDLP. 490D.5.4.2.2 Bus arbitration. 491D.5.4.2.3 PPP numbers. 491D.5.4.2.4 PPP configuration options. 491D.5.4.2.5 SDLP link establishment. 491D.5.4.3 Station physical layer. 492D.5.4.4 Examples. 492D.5.5 Multiple-media operation. 494D.6 NOTES. 494

TABLE D-I. Levels of HF networking controller functional capability. 459TABLE D-II. Network layer header characters. 466TABLE D-III. Voice path quality cascading. 468TABLE D-IV. Examples of data path quality computations. 470TABLE D-V. Age field encoding. 472TABLE D-VI. Port numbers in AME header. 474TABLE D-VII. Relay management commands. 478TABLE D-VIII. Encoding of HRMP arguments. 479TABLE D-IX. Station status codes. 482

FIGURE D-1. Functional block diagram of an automated HF station. 456FIGURE D-2. Networking controller. 457FIGURE D-3. Network connectivity example. 463FIGURE D-4. Path quality matrix example. 464FIGURE D-5. Routing table example. 465FIGURE D-6. Structure of CONEX message. 470FIGURE D-7. CONEX header. 471FIGURE D-8. CONEX station or network ID. 471TABLE OF CONTENTS(continued)PARAGRAPH PAGEFIGURE D-9. CONEX report. 472FIGURE D-10. Example AME message header and address record. 474FIGURE D-11. HF relay management protocol message format. 477FIGURE D-12. Station status message format. 482FIGURE D-13. Event time encoding. 482FIGURE D-14. Interrelationship of protocols. 485FIGURE D-15. Station data bus. 489FIGURE D-16. SDLP frame structure. 490FIGURE D-17. Station network message format. 490FIGURE D-18. Station data bus example. 493FIGURE D-19. Menu-driven remote tech control. 494

D.1 GENERAL.

D.1.1 Scope.

This appendix contains the requirements, prescribed protocols, and directions for the implementation of adaptive networking functions for high frequency (HF) radio. Networking represents the more advance technical capabilities of automated HF radio.

D.1.2 Applicability.

This appendix is a mandatory part of MIL-STD-188-141 whenever networking is a requirement to be implemented into the HF radio system. None of the features and functions described in this appendix are mandatory requirements for the user in the acquisition of an HF radio systems, however, if the user has a requirement for the features and functions described herein, they shall be implemented in accordance with the technical parameters specified in this appendix.

D.2 APPLICABLE DOCUMENTS.

D.2.1 General.

The documents listed in this section are specified in D. 3, D. 4, and D. 5 of this standard. This section does not include documents cited in other sections of this standard or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, document users are cautioned that they must meet all specified requirements documents cited in D. 3, D. 4, and D. 5 of this standard, whether or not they are listed.

D.2.2 Government documents.

D.2.2.1 Specifications, standards, and handbooks.

The following specifications, standards, and handbooks form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) and supplement thereto, cited in the solicitation.

STANDARDS
	FEDERAL
			FED-STD-1037	Telecommunications: Glossary of Telecommunication Terms
	DEPARTMENT OF DEFENSE
			MIL-STD-188-110	Interoperability and Performance Standards for HF Data Modems
			MIL-STD-187-721	Interoperability and Performance Standards for Advanced Adaptive HF Radio

Unless otherwise indicated, copies of federal and military specifications, standards, and handbooks are available from the Naval Publications and Forms Center, ATTN: NPODS, 5801 Tabor Avenue, Philadelphia, PA 19120-5099.

D.2.2.2 Other Government documents, drawings, and publications.

The following other Government documents, drawings, and publications form a part of this document to the extent specified herein. Unless otherwise specified, the issues are those cited in the solicitation.

None.

D.2.3 Non-Government publications.

Application for copies should be addressed to the EIA, Engineering Dept., 2001 Pennsylvania Ave., N.W., Washington, D.C. 20006.

	ISO/IEC 3309:1991	Information Technology-Telecommunications and Information Exchange Between Systems-High Level Data Link Control (HDLC) Procedures-Frame Structure
	ISO/IEC 8824	Information Technology-Open Systems Interconnection-Specification of Abstract Syntax Notation One (ASN.1)
	ISO/IEC 8825	Information Technology-Open Systems Interconnection-Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)

Application for copies should be addressed to the International Organization for Standardization, Geneva, Switzerland.

	IEEE STANDARDS
		IEEE 802.2	Logical Link Control (LLC) and Medium Access Control (MAC)
		IEEE 802.3	Carrier Sense Multiple Access with Collision Detection (CSMA/CD)

Application for copies should be addressed to the IEEE, Inc., 345 East 47 Street, New York, NY 10017.

	INTERNET DOCUMENTS
		RFC-768	User Datagram Protocol
		RFC-1321	MD5 Messafe - Digest Algorithm
		RFC-1441	Introduction to Version 2 of the Internet-standard Network Management Framework
		RFC-1442	Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1443	Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1444	Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1445	Administrative Model for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1446	Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1447	Party MIB for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1448	Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1449	Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1450	Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)
		RFC-1451	Manager-to-Manager Management Information Base
		RFC-1452	Coexistence Between Version 1 and Version 2 of the Internet-Standard Network Management Framework
		RFC-1570	Internet Official Protocol Standard
		RFC-1662	PPP in HDLC-Like Framing

May be obtained by anonymous ftp from nis.nsf.net or nic.ddn.mil.

D.2.4 Order of precedence.

In the event of a conflict between the text of this document and the references cited herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained.

D.3 DEFINITIONS.

D.3.1 Standard definitions.

None.

D.3.2 Abbreviations and acronyms.

The abbreviations and acronyms used in this document are defined below. Those listed in the current edition of FED-STD-1037 have been included for the convenience of the reader.

	ACK	acknowledge character
	ALE	automatic link establishment

ALQA

Advanced Link Quality Assessment

AME

automatic message exchange

ARQ

automatic retransmission request

ASCII

American Standard Code for Information Interchange

ASN.1

Abstract Syntax Notation One

b/s

bits per second

BER

bit error ratio

CLNP

Connectionless Network Protocol

CONEX

connectivity exchange

CRC

cyclic redundancy check

CSMA/CD

carrier sense multiple access with collision detection

dB

decibel

DBM

data block message

DII

Defense Information Infrastructure

DoD

Department of Defense

DTM

data terminal message

HDLC

high-level data link control

HF

high frequency

HFDLP

HF Data Link Protocol

HF MIB

HF Management Information Base

HFNC

HF Networking Controller

HFTP

HF Transport Protocol

HNMP

HF network management protocol

HRMP

HF relay management protocol

HSSP

HF station status protocol

ICMP

Internet Control Message Protocol

ID

identification

IP

internet protocol

LCP

link control protocol

LQA

link quality analysis

MRU

Maximum Received Unit

MSB

most significant bit

NAK

negative-acknowledge character

NRM

Normal Response Mode

NSAP

network service access point

OSI

open systems interconnections

P/F

poll/final

PIN

personal identification number

PPP

point-to-point protocol

QOS

quality of service

SDLP

station data link protocol

SINAD

signal-plus-noise-plus-distortion to noise-plus-distortion ratio

SNMP

Simple Network Management Protocol

SNMPv2

Simple Network Management Protocol version 2

SNRM

Set Normal response mode

UA

unnumbered acknowledge

	UDP	User Datagram Protocol
	UTC	universal time, coordinated

D.4 GENERAL REQUIREMENTS.

D.4.1 Introduction.

Networked operation supports indirect routing to deliver traffic when propagation does not support direct links.

D.4.2 Networking controller.

A networking controller performs the network­layer functions relating to traffic routing and relaying. In the simplest case, the network layer functions reside within a radio and have access only to the links achievable by that radio. A more advanced radio may include both ALE and HF data modems, along with a networking controller that is capable of establishing links using the ALE modem and protocols and is capable of switching to the data modem for data communication (see figure D-1). Such a networking controller could use either of the modems (via its respective data link layer entity) to carry traffic for the local user or to relay others' traffic within the network. A still more sophisticated networking controller could manage several radios in a major communications hub, routing traffic through the radio that has the best path to the destination. Such a networking controller could be generalized to act as a multiple-media gateway, routing traffic over media such as wire, fiber, microwave, and satellite links as well as HF links.

The principal functions performed within the networking controller are route selection and link selection, automatic message exchange (AME) and message store and forward, and connectivity tracking. Note that the connectivity tracking function employs the connectivity exchange protocol described in D.5.2.4 and the connectivity monitoring protocol described in D.5.2.6.6.3. The interactions among the various functions and data structures within the networking controller are shown on figure D-2.

D.4.2.1 Data structures.

Depending upon the level of functional capability of a networking controller (see D.4.2.6), it shall implement one or both of the following data structures.

D.4.2.1.1 Routing table.

The networking controller shall maintain a routing table that stores the preferred route from that station to other reachable stations (DO: also alternate routes); specifically, for each reachable station the routing table shall indicate how traffic destined for that station should be routed. Separate entries shall be maintained for voice and for data traffic. The routing table entries shall be individually programmable as static (entered manually by the operator or downloaded verbatim from other stations) or adaptive (computed automatically by the networking controller using the path quality matrix). See D.5.2.1.2 for detailed requirements for the routing table.

D.4.2.1.2 Path quality matrix.

The central data structure supporting adaptive routing is the path quality matrix. This matrix shall be organized to separately record voice and data path quality to any reachable destination via each directly­reachable relay station. These path quality estimates shall be based upon link quality measurements reported by the link controllers in accordance with D.5.2.1.1.

D.4.2.2 Route selection.

The route selection function routes voice and data traffic through networks using direct or indirect paths as required. While accomplishing this, it uses and maintains the routing table discussed in D.4.2.1.1. The route selection function supports both indirect calling and various types of relaying, including analog repeaters, frame repeaters, and message store and forward.

D.4.2.3 Message store and forward.

The message store and forward function provides message delivery service for users or transport­layer processes (the term transport message is used in all cases). This function may buffer in­transit messages for varying periods of time depending upon the storage facilities available within the network controller.

The store and forward process at each networking controller employs the route selection function to determine routes through the network for messages, and employs the automatic message exchange process to actually deliver messages over HF links. When full store and forward functionality is not required, a null store and forward function provides the interface to automatic message exchange (see D.5.2.5.3).

D.4.2.4 Automatic message exchange (AME).

Automatic message exchange refers to the network layer function that accepts network messages from the store and forward function for delivery to a specified directly reachable station (relay or final destination), and automatically delivers each message when a link is available to that station. When a link cannot be established to the requested station, the automatic message exchange function may either reject the network message, allowing the store and forward function to attempt delivery by alternate means, or it may store the message for future delivery when the desired link is established (so­called "discovery mode").

D.4.2.5 Connectivity exchange.

Information about routes to stations that are not directly reachable, and which have not routed traffic through the local station recently, can sometimes be obtained from the connectivity data stored by a directly reachable station. This data may be shared either upon request or by periodic broadcast. When stations report their path quality matrix contents to other stations, this is termed connectivity exchange (CONEX). When, on the other hand, a station asks for replies from stations with connectivity to a specified destination this is termed query routing (e.g., "Who can reach Joe?"). Protocols for both functions are specified in D.5.

D.4.2.6 Standard levels of capability.

The standard levels of functional capability listed in table D-I are defined for HF Networking Controller (HFNC). Note that each level includes the capabilities of all lower­numbered levels.

D.4.2.7 Link selection.

The link selection function of the network controller shall interact with local data link controllers to request the establishment and status of links. It shall use data from the path quality matrix to select among available data link controllers for data transfer to the distant station. The link selection function makes no routing decisions per se.

D.4.2.8 Interface to link controllers.

The following functions form a minimal interface between a networking controller and the link controllers that it uses. Because of the wide range of implementations possible, the specifics of this interface are not yet fully standardized.

D.4.2.8.1 Link control.

The networking controller shall be able to request the establishment and termination of links, specifying desired destinations using the appropriate link­level addresses. However, artifacts of particular link controllers (e.g., padding ALE addresses on the right with "@" characters) shall not be required of networking controllers. Link controllers should report the success or failure of link establishment and the identities of linked stations (e.g., stations responding to an ALE net call).

D.4.2.8.2 Link quality reporting.

The networking controller requires reports from the link controllers regarding the quality of links to other stations available from each link controller. These reports shall specify the data necessary for path quality matrix entries (e.g., BER and SINAD), but shall not contain data such as channel numbers that are relevant only to the link controller.

D.4.2.8.3 Network messages.

Messages to be sent from one networking controller to another over a link shall be delivered to a link controller in two parts: a network message (which is handled transparently by the link controller); and control information which specifies to the link controller the data­link layer addressee of the message as well as other requirements for the transmission. The link controller is presumed to assume custody of each message that it accepts for transmission. Received messages delivered by link controllers to an HFNC shall be accompanied by the link layer address of the sender of the message.

D.4.3 Interface to other media.

The HF networking controller is capable of providing a subnetwork service to Internet routers. This subnetwork need not consist solely of HF links. When other media links are included in a subnetwork, the networking controller should route calls and traffic to optimize use of each type of link.

D.4.4 Network management.

D.4.4.1 Network management functions.

Automated network management functions support the efficient control of automated HF networks. The tools for network management specified in D.5 include protocols for the following functions:

a. Monitoring and reporting network status (e.g., topology, capabilities, congestion, and faults).

b. Downloading ALE controller data.

c. Updating network routing tables.

d. Identifying software versions and updating the software in ALE and networking controllers.

e. Re-keying linking protection scramblers.

f. Remotely controlling station operations.

g. Adjusting transmitter power of linked stations.

h. Hand-off from ALE modems to other modems.

i. Transition among security modes.

D.4.4.2 Network management application program capabilities.

The network management application program (often running on networking controller hardware) integrates the monitoring, reporting, and control capabilities of attached networking and link controllers to allow the network manager to view and adjust the operation of a network. These capabilities include the LQA, ALQA, Version, and Capabilities functions of the ALE controller, and the CONEX function of the networking controller. Network management programs employ the data communication capabilities of networking and link controllers to exchange network management messages.

D.4.4.3 Simple Network Management Protocol (SNMP).

All HF radio equipment should implement the SNMP, as specified in Request for Comments 1441-1452 (RFC-1441) with the HF-specific enhancement specified in D.5.3.2. This combination of SNMP with HF radio enhancements is hereafter denoted HF network management protocol (HNMP). Equipment not implementing HNMP may be managed through the use of proxy agents, which translate between HNMP commands and equipment-specific commands.

NOTE: An HFNC is the platform for proxy agents because of its connections to most other equipment at a station.

Every HFNC that implements HNMP shall also implement the HF AME protocol if carrying traffic over HF.

D.4.5 Multiple-media networks.

Multiple-media networks support the efficient integration of all available transmission media for end-to-end communications.

a. From a user's perspective, a communication system should seamlessly integrate any available media to provide end-to-end service. In addition to this general requirement for static multiple-media interoperability, many Government systems (especially military and law enforcement agency systems) require robust networks that can sustain communications in the face of widespread loss of assets, and that can be rapidly extended into new locales using any available facilities. It is this dynamic element that distinguishes so called "any media" networks from the more common multiple-media networks.

b. Because of the dynamic characteristics of ionospheric propagation, HFNCs are designed specifically to cope with fluctuating connectivity. This makes the HFNC especially suitable for service as a router in any-media networks.

c. HF radio may be integrated with other media in two complementary ways:

(1) A network of HFNCs may contain not only HF links, but also wireline, microwave, tropo- or meteor-scatter, and satellite links. Such HF networks use HF links for mobile or remote stations and for contingencies, with other media used as dictated by tactics and economics.

(2) A network of HFNCs may serve as a subnetwork in a larger internet (such as the Internet). Such an "HF" subnetwork may of course employ any of the media listed above. The HF component of such internets provides an inexpensive means to extend the network to remote or mobile users. Examples include Defense Information Infrastructure (DII) entry and providing access to the commercial telephone system from remote regions of the world (e.g., northern Canada).

When multiple media or any media networking is required, the other media shall be interconnected to HF assets via HFNCs. For fully automatic internetworking, the HFNC level of

functional capability must be level 2 or above (see table D-I). A level 4 HFNC is required for internet gateways in the case of paragraph D.4.5.b above.

D.5 DETAILED REQUIREMENTS.

D.5.1 Introduction.

HF networking technology includes HFNC functions, the HF Network Management Protocol, and a data link protocol for use within automated HF stations.

D.5.2 Networking functions.

The functions implemented within a networking controller include automatic route and link selection, indirect calling, connectivity monitoring, connectivity exchange, routing queries, repeater control, message store and forward, automatic message exchange, and station status reporting.

D.5.2.1 Route and link selection.

The router is the central entity of the networking controller, in the sense that almost every other networking function either relies upon it or supports it. The router performs two functions: route selection and link selection. The route selection function finds routes through networks for user and orderwire traffic, using connectivity data from the path quality matrix, operator entries, and broadcast queries to maintain the routing table. The link selection function simply chooses the best data link available to each destination selected by the route selector.

The following examples of network­layer operations refer to the hypothetical network connectivity from station A shown on figure D-3. The arrows indicate the direction(s) of connectivity; the pair of numbers on each arrow indicates voice and data path quality, respectively (in accordance with the link quality functions in MIL-STD-187-721, paragraph on Link Quality Functions).

D.5.2.1.1 Path quality matrix.

The path quality matrix is organized with a row for each directly reachable relay station, and a column for each destination of interest. When multiple data link controllers are available to the networking controller, a separate path quality matrix may be maintained for each, or a single path quality matrix may be maintained. The single path quality matrix contains the best path scores over all link controllers, along with indications of the specific link controller to use for each path.

A path quality matrix is needed by every networking controller that provides adaptive routing for locally­originated messages, whether or not the station intends to relay messages for other stations.

Figure D-4 illustrates how the network connectivity on figure D-3 may be summarized in the path quality matrix at station A. The path qualities are computed in accordance with the algorithms given in D.5.2.4.1 and D.5.2.4.2. Note that unidirectional path qualities (A to destination) are shown. Normally, path qualities in both directions will be stored and used.

DESTINATION:	B	C	D	E	F	G	H
RELAY:
B*	14 14 0 1 s	13 13 1 59 m	9 8 2 5 hr	7 7 3 5 hr	- - - -	6 6 4 5 hr	4 5 5 1 d
C*	1 1 1 5 hr	3 2 0 30 m	1 1 1 5 hr	0 0 2 5 hr	- - - -	0 0 3 5 hr	0 0 4 5 hr
D*	4 1 1 2 hr	4 5 1 3 hr	5 6 0 12 hr	4 5 1 5 m	- - - -	3 4 2 5 hr	1 3 3 5 hr
E*	- - - -	- - - -	- - - -	- - - -	- - - -	- - - -	- - - -
F*	- - - -	- - - -	- - - -	- - - -	- - - -	- - - -	- - - - -
G*	- - - -	- - - -	- - - -	- - - -	- - - -	- - - -	- - - -
H*	- - - -	- - - -	- - - -	- - - -	- - - -	- - - -	- - - -

*KEY: Voice Quality, Data Quality, Relays, Age

D.5.2.1.2 Routing table.

A routing table is maintained by the networking controller for use in route selection. An example routing table is shown on figure D-5, corresponding to the path quality matrix example on figure D-4.

DESTINATION	B	C	D	E	F	G	H
ROUTE VOICE TRAFFIC VIA *	B 14 0 1 s	B 13 1 59 m	B 9 2 5 hr	B 7 3 5 hr	- - - -	B 6 4 5 hr	B 4 5 1 d
ROUTE DATA TRAFFIC VIA *	B 14 0 1 s	B 13 1 59 m	B 8 2 5 hr	B 7 3 5 hr	- - - -	B 6 4 5 hr	B 5 5 1 d
*KEY: Relay Address Path Quality Relays Age

D.5.2.1.2.1 Organization.

The routing table is organized for quickly determining where to send traffic destined for any reachable station. It is indexed by a reachable station address. The entry for each station contains (at least) the best relay(s) for voice and data traffic destined for that station. In addition, routing table entries may contain alternate relays and candidates for indirect calls when no relays are available.

D.5.2.1.2.2 Manual entries.

A means shall be provided for operator entry of routing table data. These entries shall be retained in non­volatile storage when the network controller is powered off and shall not be overwritten by automatic updates to the routing table from path quality matrix data; this may be implemented by flagging non­adaptive routing table entries. The operator shall also be able to view, edit, and delete manual routing table entries. The requirements of this paragraph do not apply when the mission, power, or weight limitations contraindicate.

D.5.2.1.2.3 Automatic updates.

When adaptive routing is employed, alternative routes to reachable destinations shall be re­evaluated whenever new path quality data arrives (e.g., via CONEX), and the routing table shall be updated as appropriate.

D.5.2.2 Indirect calling.

When a link controller fails to establish a link requested by the networking controller, the routing table (and path quality matrix as required) may be used to identify candidate station(s) for indirect calling. Initiation of an indirect call by the networking controller may be automatic upon linking failure or it may be initiated by the operator. When an automatic indirect call succeeds in establishing a link with a candidate station, the operator should be notified that the link established is to a third party rather than to the desired destination.

D.5.2.3 Network layer header.

All messages sent from one networking controller to another shall be preceded by a single ASCII character denoting the type of message to follow. When a networking controller receives a message, it examines this one­character header to determine the format and protocol to use in interpreting the remainder of the message. (See D.4.2.)

The defined network layer header characters are listed in table D-II. Header characters not listed are reserved and shall not be used until standardized.

D.5.2.4 Connectivity exchange.

The CONEX protocol allows relay stations to exchange lists of other stations they can contact. However, CONEX exacts a price in overhead channel usage that may be unacceptable under many conditions. Normally, relay stations use static routing table entries with notification-based protocols (see D.5.2.6.6.3 and D.5.2.7) and HF network management requests. CONEX is useful only for those relay stations equipped with a Level 3 or 4 HFNC (see table D-I), and is recommended only for those networks that cannot use normal routing table maintenance (also see D.5.2.4.1b).

a. Networking controllers exchange the contents of their path quality matrices using the following CONEX protocol. Note that CONEX messages may be carried on any type of data link that connects the parties to the exchange. Because these messages may be relatively large, a high speed modem should be used for CONEX whenever possible; the ALE modem should only be used when no other data link is available.

b. A CONEX report pertains to the path from one station to another, which may consist of a single link (a "direct path") or of multiple links (an "indirect path") through one or more intermediate (relay) station(s). In all cases, each CONEX report includes the number of relay stations included in the path, estimates of the path quality for voice and for data, and the age of the oldest data used to estimate these path qualities.

D.5.2.4.1 Voice path quality.

The voice quality for a path is an estimate of the end-to-end SINAD of the path. For SINAD less than 2 dB, the voice path quality is 0; for 2 through 26 dB, the quality is 1/2 SINAD (in dB); for SINAD greater than 27 dB, the quality is 14; and when the end-to-end SINAD is unknown, the quality is 15 (1111) (default value). Voice quality shall be computed as follows:

a. For a single-link path, the mean SINAD for that link (median SINAD if ALQA data is available) shall be obtained from the link controller and converted directly to a path quality code.

b. For a multilink path, the voice quality obtained in a CONEX report from the best relay station for the ultimate destination shall be combined with the quality of the best link to that station to obtain the resulting voice path quality as specified in table D-III. (Note that a multilink path will never have quality 14.) The "best relay" is the station among all potential relays that gives the highest result quality after the qualities of links to those stations have been included.

D.5.2.4.2 Data path quality.

a. The data quality for a path is an estimate of the efficiency of the path in passing data traffic. The data path quality code used is based upon estimates of the time required to pass messages over each link in the path; the resulting code reflects several measures of importance to data networks: data throughput, message latency, and resource utilization (stations and channels).

b. Computing the end-to-end data path quality through one or more relay stations shall proceed as follows. Assume that station "A" receives a CONEX report from "B" about the best data path from "B" to "X." Station "A" computes its path quality to "X" through "B" by combining the quality of its link to "B" with the report from "B" about "B's" best path to "X:"

(1) Station "A" computes the quality of its link to "B" as described in paragraph e below, and compares the result to the quality of the path from "B" to "X" as reported by "B."

(2) If either quality is 0, the result is 0. Likewise, if either is 31 (unknown), the result is 31.

(3) In all other cases, the quality of the path from "A" to "X" through "B" is 1 less than the lower path quality of the two components.

c. The quality of a single data link is computed from the nominal data rate and measured error characteristics of that link obtained from the link controller. The result of the following formula shall be truncated to an integer in the range of 0 through 30, inclusive (e.g., if the result is less than zero, 0 shall be used).

d. The "nominal speed" term in the formula is obtained from the nominal data rate (in bits per second (b/s)) as follows. The result shall be rounded to the nearest integer. Note that the logarithm is taken with a base of 2.

e. The "ARQ repeats" term in the formula is the mean number of error-induced retransmissions per message of the messages sent over that link during the past hour. If no messages were sent over the link during the past hour, the ARQ repeats term may be estimated using the BER of the link (measured before error correction):

BER ARQ Repeats Estimate

<0.1 0

0.1< BER < 0.199 BER - 0.1

0.2 - BER

> 0.199 100 (link unusable)

Table D-IV illustrates the use of this formula:

D.5.2.4.3 CONEX message format (Optional).

a. A CONEX message consists of a header, identifier(s) of the net or specific stations reported, and reports of path quality to those stations. When a net is named, the reports for the stations in the net are listed in the standard order for that net, without sending the individual station identifiers. A flow diagram for the structure of a CONEX message is shown on figure D-6. CONEX messages are formatted in even multiples of 8 bits to simplify the insertion of these reports into the natural data blocks of the links likely to be available.

b. The CONEX message header contains a 16-bit Control field, followed by the name of the sending station, as shown on figure D-7. The first bit is set to 1. The second bit is set to 1 to request CONEX from responding stations, or to 0 to suppress such responses. The third bit is set to 1 to indicate that CONEX reports follow the sending station name; if this bit is 0, no reports are included in this message. The next five bits in the Control field contain a count of the characters in the sending station name (a count of 0 indicates a 32-character address).

The second 8 bits of the header begin with 2 bits set to 1 and 0 respectively, followed by the Max Age and Max Relays fields. The Max Age and Max Relays fields apply to CONEX requests; the responding station shall only return reports whose Age and Relays fields do not exceed these limits (all 1's in a field means no limit). The Control field is followed by the number of ASCII characters indicated in the Count field, with a 0 most significant bit (MSB) placed before each 7-bit character.

c. Station and network IDs have a structure similar to the CONEX header. Each begins with an 8-bit Control field, which is followed by the ASCII characters composing the name of that station or network (see figure D-8). The first bit is set to 1. The second bit is set to 0 for an individual station identifier, and to 1 for a network identifier. The third bit is set to 0 in the last ID in the CONEX message, and to 1 for all of the preceding station and network IDs. The last five bits in the Control field contain a count of the characters in the station or network name. The Control field is followed by the number of ASCII characters indicated in this count, with a 0 MSB placed before each 7-bit character.

d. Each report in a CONEX message refers to the best path from the sending station to a specified destination. When the report is preceded by a station ID, the report pertains to the best path to that station. When the report is one of a sequence of reports following a network ID, the destination station is known implicitly from the position of the report in that sequence.

e. Each report contains four fields as shown on figure D-9: the minimum number of relays between the sending station and the destination station (3 bits); end-to-end quality of the best path(s) to the destination for voice or data use (4 bits for voice quality and 5 bits for data quality); and the age of the oldest data used to compute the voice and data path qualities (3 bits). Note that the first bit is always set to 0.

f. The Age field uses the encoding as shown in table D-V. For 0 through 5 relays in the path, the Relays field contains the number of relays. For 6 or more relays, the Relays field contains 110 (6). When the number of relays is unknown, the Relays field is set to 111 (7).

D.5.2.4.4 CONEX broadcast.

a. Stations may periodically broadcast CONEX messages containing reports of path quality to selected destinations (e.g., net control stations, gateways to other networks, or distant network members that are difficult for some members to reach). The rate of such broadcasts, the channels used, and the stations included in the CONEX report may be selected by the operator or may be determined adaptively by the networking controller. A CONEX broadcast will typically use an ALE scanning call to a net or group. The CONEX message may be sent using DTM or DBM with the ALE modem; however, an HF data modem should always be used when available.

b. A station receiving a CONEX broadcast should update its path quality matrix using the data received along with link quality data from the link controller receiving the broadcast, as described above.

D.5.2.4.5 CONEX handshake.

A CONEX handshake is used to exchange connectivity data among networking controllers. The request bit is set to 1 to request connectivity, and the Max Age and Max Relays fields may be used to restrict the number of reports received. ALE is used to establish the link(s) used, as required; the CONEX messages may be conveyed using either the ALE modem (with DTM or DBM) or a data modem.

D.5.2.5 Message delivery.

In the seven layer reference model, the network layer performs end­to­end message delivery, using one or more data links in tandem to carry each message. When HF links are employed, the inherent error rates involved require the use of connection­oriented data links for efficient use of the medium. Such data link protocols guarantee that those blocks of a message that are delivered to the network layer at the destination arrive in order and without duplication. (The DTM and DBM ALE protocols using CRC and ARQ satisfy these requirements, as do other data link protocols used in advanced modems.)

However, data links occasionally fail, so the data link layer cannot guarantee message delivery within a bounded time. A mechanism is required at the network or transport layer to detect and deal with data link failures through the use of retransmission, alternate routing, etc. In the existing DoD internet, this function is performed in the transport layer. Therefore, the HF network layer need only provide datagram service, and its principal function is message routing.

D.5.2.5.1 AME header.

The AME header (see D.4.2.4) carries the information used by the network layer for message routing and delivery. This header immediately follows the single­character network layer header (which will be 'M' to indicate that an AME header follows). The AME header contains the following fields:

Quality of A single bit indicating whether to emphasize

Service (QOS) speed of delivery (QOS = 0) or minimum probability of loss or error (QOS = 1) in handling the message.

Precedence A 3-bit code with 0 as lowest precedence. Used for queuing at relay nodes and determining order of link establishment, order of delivery, etc.

Port A 4-bit code designating destination port within network controller, analogous to network service access point (NSAP) in the seven layer model. Assigned port numbers are listed in table D-VI.

Header Length An 8-bit count of the bytes in the AME header, starting with the precedence/port byte and ending with the last character of the source address record.

Message Length A 16-bit count of the bytes in the transport message following the AME header (does not include the network layer header or AME header bytes).

Relay(s) Zero or more address records (see address record format description). When relays are specified, they may be either suggested relays or mandatory relays. When mandatory relays are specified, the message must be routed through the relays listed in the order given. Suggested relays are offered for consideration by the route selector in addition to alternatives found in the routing table.

Destination(s) One or more address records. The message body should be delivered to all destination addressees.

Source One address record, specifying the address of the station that originated the message.

An address record is structured as an 8-bit flag, followed by a network layer address of ASCII characters with a 0 MSB placed before each 7-bit character. The MSB of the flag is a 1. The next two bits encode the record type: 0 for a source address record, 1 for a mandatory relay, 2 for a suggested relay, and 3 for a destination. The five least-significant bits contain a count of the characters in the address. Address characters have MSB = 0. An example of an AME header and address record is shown on figure D-10.

D.5.2.5.2 Message store and forward.

The store and forward process accepts messages from, and delivers messages to, users (or transport­level processes). Each transport message to be sent is accompanied by the network layer addresses of its destination(s). For each transport message to be sent, the store and forward function groups the network layer destination address(es) according to the first relay on the path to each addressee (obtained from the route selection function), or the final destination if a direct path is the best path. For each such group, an AME header is formed. The header contains the destinations that share an initial relay station. The transport message is appended to this header to compose a network message. These network messages are passed to the local AME process for delivery.

As network messages arrive from other stations and are delivered to the store and forward function by the local AME process, the AME header of each is removed and processed as follows:

a. If any of the destination addresses in the header are self addresses, the embedded transport message is delivered locally as specified in other fields (precedence and port) of the header.

b. All self addresses are removed from the header.

c. If any destinations remain, those addresses and the transport message are handled as discussed above for a new outgoing message.

D.5.2.5.3 Null store and forward function.

A null store and forward function may be used in place of the message store and forward process described above when automatic message routing is not needed. The null store and forward function shall form AME headers for outgoing messages and process the AME headers from incoming messages as follows.

D.5.2.5.3.1 Outgoing messages.

For each outgoing message, the null store and forward function shall create an AME header with pre­programmed values in all fields, except that the header length and message length fields shall be computed for the actual message and AME header. The user (or transport layer process) shall be able to override the default values. Normally, the user will override only the default destination address, the precedence, and the port fields. A user may insert relay addresses for manual source­routing. If the user is able to override the source address, this capability should normally be restricted to selecting one of a set of pre­programmed addresses (to preclude impersonation of other stations).

D.5.2.5.3.2 Incoming messages.

The destination and relay address records in the AME header of each incoming message shall be examined. If a self address is found in any of these address records, the message and the AME header shall be delivered to the user. (This permits users to manually relay messages.)

D.5.2.5.4 AME.

AME is the network layer function concerned with single-link message delivery. It works with either a full store and forward process or a null store and forward process. In the following paragraphs, the term "store and forward process" refers to either implementation of the store and forward functionality.

NOTE: AME provides a simple datagram service, with no acknowledgments, error checking, or flow control.

D.5.2.5.4.1 Outgoing messages.

Each network message passed to the AME process from the store and forward process contains an AME header and a transport message. The AME process shall interpret the first address record in the AME header as the desired destination for that message.

Outgoing messages from the store and forward process shall be queued by the AME process for transmission in order of precedence. The AME process requests a link to the destination of each message from the link selection function. When the link selection function indicates that a link to that destination is available, the AME process shall attach a network layer header (the character "M") to the front of the message, translate the network layer address to a data link layer address appropriate for the selected data link controller, and provide the network message and the translated address to that controller for transmission.

If a direct link cannot be established to the destination, the AME process shall take one of two actions:

a. Return the message to the store and forward process as undeliverable (appropriate if the store and forward process can attempt alternate routing).

b. Store the message for later delivery when a link can be established.

In the latter case, messages should be stored in separate queues for each destination so that only one series of linking retries is made for each destination (rather than one for each queued message). The first retry shall be made after a time sufficient for a busy station to have resumed listening for linking attempts. To minimize use of the spectrum for futile linking attempts, subsequent retries shall occur at intervals sufficient for propagation to have measurably improved. (The retry interval may be shortened when a queue contains high-priority messages.)

When contact is eventually made with the desired destination, whether through a successful linking retry or through connectivity discovered by reception of a message from that station, messages queued for that destination shall be sent in decreasing priority order.

D.5.2.5.4.2 Incoming messages.

Incoming messages are delivered to the AME process when their network layer header is "M" (user messages). The AME process shall simply strip this single-character network layer header and pass each received message to the store and forward process for processing.

D.5.2.6 Relay management protocol.

The HF relay management protocol (HRMP) shall be used by HF networking controllers to inquire about connectivity through prospective relay stations, to manage repeater operation, and to preempt repeater circuits, as described in D.5.2.6.6. HRMP is a connectionless protocol, although it can be used to set up analog tandem circuits or data virtual circuits.

Every HRMP message refers to three stations: the first is the Relay station (actual or potential); the second is the Control station managing the relay; the third is the Distant station to which access is provided by the relay. HRMP messages are exchanged between the Control station and the Relay station.

HRMP messages shall be formatted as shown on figure D-11. The fields in HRMP messages shall be encoded as described in the following paragraphs.

Msg. Dest.

Msg. Source

Desired Dest.

Msg. ID

Msg. Length

Command

Arguments

Checksum

D.5.2.6.1 HRMP address field.

Three station addresses are present in every HRMP message: that of the station sending the message (Msg. Source), that of the station to which an indirect path is sought or desired (Desired Dest.), and that of the station receiving the message (Msg. Dest.). The Desired Dest. shall always be the Distant station. The Msg. Source and Msg. Dest. shall be the Control and Relay stations, respectively, for Control-to-Relay messages, and vice versa for Relay-to-Control messages.

The addresses of all three stations shall be encoded as AME address records in accordance with D.5.2.5.1.

D.5.2.6.1.1 Message destination.

The Msg. Dest. field on figure D-11 shall contain the address of the Relay station, with a suggested Relay flag, when the message direction is Control-to-Relay. For Relay-to-Control messages, the Msg. Dest. field shall contain the address of the Control station with a source flag.

D.5.2.6.1.2 Message source.

The Msg. Source field on figure D-11 shall contain the address of the Control station, with a source flag when the message direction is Control-to-Relay. For Relay-to-Control messages, the Msg. Source field shall contain the address of the Relay station with a suggested Relay flag.

D.5.2.6.1.3 Desired destination.

The Desired Dest. field on figure D-11 shall always contain the address of the Distant station, with a Destination flag.

D.5.2.6.2 HRMP message identification field.

The Msg. ID on figure D-11 field shall contain an 8-bit number used by the Control station to match responses with requests. Responses from the Relay station shall contain the same Msg. ID as is found in the corresponding Request from the Control station. Messages from the Relay station other than responses shall set this field to all 1s.

D.5.2.6.3 HRMP length field.

The Msg. Length field on figure D-11 shall contain the number of bytes in the entire HRMP message, from the first byte of the Msg. Dest. field through the last byte of the Checksum.

D.5.2.6.4 HRMP commands.

The HRMP command field on figure D-11 shall contain one of the 8-bit codes listed in table
D-VII. (Unlisted codes are reserved and shall not be used until standardized.) The use of these commands is described in D.5.2.6.6.

The encoding of the arguments to these commands is given in table D-VIII. (Unlisted codes are reserved and shall not be used until standardized.) Arguments shall be sent in the order listed in table D-VIII.

D.5.2.6.5 Checksum.

The 16-bit Checksum shall be computed in accordance with D.5.2.9.

D.5.2.6.6 HRMP operation.

Allowed exchanges are listed in the following paragraphs for each of the classes of relay control actions supported by the HRMP. HRMP exchanges are one of two types:

a. Request-response. A control station sends a request to a Relay station and starts a timer. If a response is received before the timer expires, the protocol completes successfully. Otherwise, the Control station should abort the exchange. Lack of a response indicates loss of connectivity to the Relay station; thus, a retransmission should not be initiated until sufficient time has elapsed for connectivity to be restored (either improved propagation or resumption of operations at the Relay station).

b. Notification. A Relay station sends an unsolicited message to a Control station to announce an event asynchronously. Such events include preemption of a repeater in use by the Control station or loss of connectivity to a Distant station being monitored at the request of the Control station.

D.5.2.6.6.1 Routing queries.

A station seeking to find an indirect path to a Distant station sends a query to prospective relay(s). A station receiving a query shall respond with a NAK in any of the following cases:

a. It lacks the facilities to provide the services requested (reason code = not equipped).

b. It has facilities, but they are not available for a request of the stated precedence (reason code = precedence too low).

c. It has available facilities, but has no connectivity to the requested Distant station (reason code = no connectivity).

A station having available facilities that at least approximate the requested service and having connectivity to the requested Distant station, shall return a query response that describes the type and quality of service it can provide. Note that routing queries may be made for either message store and forward service or repeater service.

D.5.2.6.6.2 Repeater control.

Both analog and digital repeaters may be remotely controlled through the use of the Repeater control commands. When a repeater is engaged using HRMP, the Relay station shall assign a repeater number (analogous to a virtual circuit number) for unambiguous reference to the circuit established.

a. A repeater request shall specify the type and quality of service desired (just as in a query). If the repeater can be engaged, the Relay station shall return a repeater status response which contains the assigned repeater number and type and quality of service actually provided. Otherwise, (see conditions in D.5.2.6.6.1) a NAK shall be returned.

NOTE: A repeater request specifying store and forward shall elicit a NAK with a reason code of "inappropriate" because the store and forward function cannot be seized.

b. A repeater status request sent by a Control station to inquire about the operational status of a previously engaged repeater shall carry the repeater number assigned when it engaged that repeater. The Relay station shall respond with a NAK if the specific repeater is not currently assigned to the Control and Distant stations specified in the message; otherwise, it shall respond with a repeater status message that describes the type, quality of service, and current status of the specific repeater.

c. A Control station shall release an engaged repeater by sending a release repeater message. The Relay station shall send a NAK under the conditions described above for repeater status requests; otherwise, the Relay station shall terminate the link to the Distant station, disengage the repeater, and return a repeater status message containing a status code of "repeater not available."

d. When a Relay station cannot sustain a previously engaged repeater service, it shall send a repeater lost message to the affected Control and Distant stations. For each intended recipient of the repeater lost message, the address of that station shall be encoded as the Msg Dest using a source address record, and the third party to the repeater service shall be encoded as the Desired Dest using a Destination address record. If the repeater service is terminated because of loss of connectivity, the reason code shall be "no connectivity." If the repeater was preempted, the reason code shall be "precedence too low."

Loss of a link to one party of a repeater service shall not result in a repeater lost message and termination of the repeater service until attempts to automatically re-establish the link have failed. During link re-establishment, the repeater status shall be reported as code 2 in responses to repeater status requests.

D.5.2.6.6.3 Connectivity monitoring.

Connectivity monitoring is a notification-based alternative to connectivity exchange (D.5.2.4). A Monitor Connectivity message requests that the named Relay station monitor (or cease monitoring) its connectivity to the named Distant station. Notification options include broadcasting connectivity changes to all stations, or reporting changes to a named control station, or cease reporting changes in its ability to reach that Distant station. If the Distant Station field contains the network broadcast address (D.5.2.8), the Relay station shall perform the indicated command for all stations.

Notification of a change in connectivity shall be sent in a connectivity change message. A connectivity change message may be broadcast by addressing it to the network broadcast address (D.5.2.8). The arguments defined for the monitor connectivity and connectivity change

messages support two levels of detail in this service: notification only of loss and discovery of connectivity, or notification of transitions between direct and indirect connectivity as well.

D.5.2.7 Station status protocol.

The HF station status protocol (HSSP) shall be used to notify network members of changes in the operating mode of a station. HSSP messages shall be formatted as shown on figure D-12.

Source Addr	D	New Status	Event Time	Duration	Checksum

a. The Source Addr field shall contain the address of the station sending the message, encoded in an address record (see D.5.2.5.1) with a source flag.

b. The "D" bit shall be set to 1 if and only if the Duration field is present.

c. The 7-bit New Status field shall report the new status of the reporting station as of the date and time indicated in the Event Time field, using the codes listed in table D-IX.

d. The Event Time field (24 bits) shall contain the date and time that the new status will be effective for the station in accordance with figure D-13, except that an Event Time field containing all 1's indicates that the new status is effective immediately after the message was sent. The Event Time shall be encoded in Zulu time (i.e., universal time, coordinated (UTC)), with the year digit holding the least-significant digit of the event year.

4	4	5	5	6
Year (0 - 9)	Month	Day	Hour	Minute

e. The optional Duration field (24 bits) shall be encoded in accordance with figure D-13 to indicate the expected duration of the status change.

f. The 16-bit Checksum shall be computed in accordance with D.5.2.9.

NOTE: No length field is needed to determine the number of bytes contained in an HSSP message because the only variable-length field in the message is the Source address record, which contains an internal length field.

D.5.2.8 Network broadcast address.

Where permitted by network layer protocols, the broadcast address "@ ? @" (identical to ALE Allcall address) may be used to collectively refer to all reachable stations.

D.5.2.9 Checksum computation.

The 16-bit Checksum in network layer messages shall be computed as the 16-bit 1's complement of the one's complement sum of all relevant 16-bit words (either all words in the AME header or all words in the message for HRMP or HSSP). If the Checksum is to be computed over an odd number of bytes, the final byte shall be padded on the right with a 0-filled byte. For purposes of computing the checksum, the Checksum field itself shall be filled with 0 bits.

D.5.2.10 Data transmission order.

The order of transmission of the headers and data composing the messages described in this section (i.e., connectivity exchange, AME, relay management, and station status messages) is resolved to the octet or character level.

The bytes of these messages shall be transferred in the order left-to-right then top-to-bottom, just as English words are read. In the case of multibyte fields, this means that the most significant (i.e., left-most) byte is transferred first.

CONEX messages consist of 7-bit "characters" while messages from the other protocols consist of 8-bit bytes. In all cases, the bytes (or characters) of these messages shall be transferred in the order left-to-right then top-to-bottom, just as English words are read. In the case of

multibyte (multicharacter) fields, this means that the most-significant (i.e., left-most byte (character) is transferred first.

NOTE: The order of bit transmission within these units is determined by the data link protocol used and is transparent to network layer protocols. For example, ALE conveys data most significant bit first, while the HF Data Link Protocol (HFDLP) and most computer serial ports convey data least significant bit first. The HFDLP is contained in Appendix G. Although this data link protocol orders multibyte values within its own header least significant byte first, network layer messages are conveyed to data link protocols as individual bytes (i.e., multibyte fields appear only as a sequence of bytes to the data link protocol), and are carried on the data link in the order determined by the network layer entity.

D.5.3 Network management.

Programs that provide network management functionality are not standardized. Interoperation among such network management systems, however, requires the standardization of protocols for examining and changing the state of network elements, and of the abstract data objects (management information) manipulated using the HNMP protocol. The protocol requirements are identified in D.5.3.2, and the management information requirements are defined in D.5.3.3.

D.5.3.1 Terminology.

Managed network elements (e.g., radios, ALE controllers, data modems, and networking controllers) are monitored and controlled by embedded network management agents (processes) which have access to the operating data of the elements and can initiate actions in those elements. Network management stations communicate with the agents to request the values of operating data, and to request that operating data be changed. Actions in management elements are produced as side effects when operating data are changed. For example, changing the antenna Mode value for a rotatable antenna causes the antenna to rotate (see Management Information Base (MIB), Appendix H, for the definition of antenna mode).

D.5.3.2 Management protocol.

SNMPv2, in accordance with RFC 1441 through 1452 shall be employed for HF network management, with the following additional requirements (see D.4.4.3).

a. An agent receiving a SetRequest that selects a non-existent row in a table shall automatically create the requested row subject to resource availability, setting column objects in the new row to their default values unless other valid values are specified in the SetRequest message. However, if any value in the SetRequest message specifies an invalid value for any column object in the new row, the new row shall not be created, and a GetResponse message shall be returned indicating the erroneous variable binding.

b. Table rows invalidated by a SetRequest shall not be reported in responses to GetNextRequests (i.e., from the point of view of management stations, invalidated rows are deleted from the table).

c. Object identifiers for objects defined in the HF MIB (see Appendix H) may be encoded for transmission within HF networks only using the truncated encoding scheme of D.5.3.3.2. Gateways that connect HF networks to non-HF networks, however, shall ensure that object identifier encodings in messages entering non-HF networks use the full encoding of ISO/International Electrotechnical Commission (IEC) 8825; SNMP messages entering HF networks may be translated to use truncated encodings.

d. Retransmission timeouts in network management programs shall be adjusted to allow time for link establishment, and for the transmission of requests and responses over modems that may be able to achieve throughputs of 100 b/s or less.

D.5.3.2.1 Inside local HF station.

The relationship of the network management protocol to the other protocols in use within an HF station is shown on figure D-14. HNMP requires only a connectionless datagram transport service (e.g., the UDP). Consequently, figure D-14 shows HNMP using UDP for a Transport-layer protocol, IP for an Internet-layer protocol, and the HF AME protocol (D.5.2.5) as the Network-layer protocol. IP datagrams sent through the HF AME protocol shall use port number 5 in the network message header (AME header). Figure D-14 also shows integration of IEEE 802 protocols as an illustration of the use of HNMP over an Ethernet local area network. Other network protocols may be integrated similarly.

D.5.3.2.2 Outside local HF station.

When interoperation with management stations outside the local HF sub-network is not required, UDP and IP may be eliminated to reduce the overhead of network management messages. In this case, messages shall be directed to AME port number 6, which is a direct connection to HNMP.

Application	HNMP
Presentation
Session
Transport	UDP
Internet	IP
Network	AME
Data Link	ALE	HFDLP Appendix G	IEEE 802.2
Physical	ALE Modem	MIL-STD-188-110 Modem	IEEE 802.3 (CSMA/CD)
	MIL-STD-188-141 Radio

D.5.3.3 Management information.

SNMP functions by reading and writing data structures defined for each item of controlled equipment. These data structures are defined using an abstract syntax so that the details of how the data are stored by individual network components are hidden. For example, aleScanRate (the rate at which an ALE controller scans channels as defined in the HF MIB, Appendix H) is simply defined to be an integer, with no indication of byte order, or even the number of bytes used to represent it on any particular ALE controller.

a. Furthermore, some ALE controllers may store channel dwell time instead of scan rate, in which case a conversion from dwell time to or from scan rate is made whenever aleScanRate is read or written. This illustrates the fact that the objects manipulated by a network management station need not correspond directly to the internal data structures of managed elements. A principal function of agents in managed elements is the translation between the abstract objects used in the management protocol and the actual data structures used in equipment.

b. The objects that may be read and written using HNMP are defined in modules using Abstract Syntax Notation One (ASN.1), ISO/IEC 8824. RFC-1450 defines the objects commonly used to manage TCP/IP internets. The standard objects for HF network management are identified in the HF MIB, D.5.3.3.1. Objects specific to each manufacturer's equipment are specified in a MIB provided by that manufacturer. A management station integrates MIB modules from the elements it manages, resulting in access to a wide-ranging and dynamic set of management data. The structure of MIBs is defined in RFC-1442.

c. When data is exchanged over the air (or some other medium), all parties involved in the exchange shall use the same encodings for the data. The HNMP encoding rules are specified in D.5.3.3.2.

D.5.3.3.1 HF Management information base (MIB).

The HF MIB is contained in Appendix H. The MIB module contains groups of objects for radios (and related RF equipment), ALE controllers, linking protection, HF data modems (and associated data link controllers), and networking controllers. HF equipment complying with this paragraph shall implement the corresponding group of objects from the HF MIB, although access to these objects may be provided by proprietary protocols rather than HNMP (requiring proxy management, D.5.3.4). As a DO, new equipment should support HNMP directly.

D.5.3.3.2 Encoding rules.

Object names and values sent in HNMP messages shall be encoded in accordance with the Basic Encoding Rules for ASN.1, found in ISO/IEC 8825, with an optional truncated encoding for OBJECT IDENTIFIERs of objects from the HF MIB, as specified in the following text. Such truncated encodings shall not be used in messages outside HF networks.

a. The object names used in variable bindings in HNMP messages are OBJECT IDENTIFIERs, which authoritatively identify each object named by specifying the location of its definition in a tree of standards. For objects defined in the HF MIB, the OBJECT IDENTIFIER may employ a truncated path that begins in the HF MIB, using the unique code 123 (decimal) to indicate that the path to the definition begins in the HF MIB. For example, the ALE self address table may be identified as 123.2.16.

b. For an object defined for general use (i.e., not HF-specified), HNMP messages shall carry the normal OBJECT IDENTIFIER for the object. For example, the sysDescr object shall be identified as 1.3.6.1.2.1.1.1 (which traces the following path: iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) sys(1) sysDescr(1)).

D.5.3.4 Proxy management.

When elements do not implement HNMP, they may still be managed by using proxy agents that translate the standard HNMP messages into proprietary messages understood by the non-HNMP ("foreign") elements.

NOTE: As HNMP management of HF radio networks is phased in, few network elements will initially implement HNMP. Proxy agents will be needed to extend the management capability to current-generation equipment. As a general rule, the proxy agent for any foreign network element should reside in the lowest-level controller (see figure D-14) that has a control path to that element.

a. In operation, HNMP traffic that is directed to a foreign element will be delivered to the proxy agent. The proxy agent shall translate the request into an appropriate message for the target element, in terms of the native control protocol for that element, and pass the translated message to the foreign element over any available control circuit. Responses received from the foreign agent shall be translated into HNMP messages and passed to the requesting management station.

b. For efficiency purposes, proxy agents may cache frequently requested variables from foreign elements so that some traffic on the control paths within a station is eliminated.

NOTE: Variable caching necessitates messages from the foreign element to the caching proxy agent to either update or invalidate cached copies when cached variables are changed by other than the proxy agent (e.g., from an element front panel).

D.5.3.5 Access control.

Access to the management information of network elements is controlled in HNMP at two levels.

a. The first level is an administrative model that restricts the objects at each element that are accessible to other parties and the operations that may be performed by those parties.

b. The second level of access control is authentication of messages, that is, determination that a message actually comes from the party named in the message.

D.5.3.5.1 Administrative model.

HNMP agents and management applications shall employ the administrative model of RFC-1445. Object identifiers for parties and contexts shall be assigned by network administrators, who shall in turn obtain space in the tree of object identifiers from the preparing activity of this standard. Transport domain identifiers specific to HF networks are defined in the HF MIB.

D.5.3.5.2 Authentication.

The following three authentication schemes should cover the range of requirements for HF networks. Management stations shall employ only the trivial authentication protocol in HNMP messages, unless the addressed party is known to support a more secure authentication protocol. All HNMP agents must therefore support the trivial authentication protocol, although the access permitted trivially-authenticated parties to management information may be restricted.

NOTE: Since HNMP uses a broadcast medium, it is susceptible to injection of false messages by hostile forces. HF networks should strive for the highest possible level of authentication necessary for the mission to minimize this risk.

D.5.3.5.2.1 Trivial authentication.

When trivial authentication is employed, an agent receiving an HNMP message shall compare the Transport-layer address of the originator of the message to a list of authentic Transport-layer addresses for the party sending the message. If a match is found, the agent shall assume the message is authentic. When Transport-layer addresses are not used, agents may either use lower-layer addresses for authentication, or simply assume that all messages are authentic, as determined by network management policy for each network.

D.5.3.5.2.2 Personal identification number (PIN) authentication.

An intermediate level of security may be achieved through the use of PIN authentication. When PIN authentication is employed, network management programs shall prompt the station operator to enter a PIN. The network management program shall then insert this PIN as the authInfo in every SnmpAuthMsg that carries a request protocol data unit (PDU). Agents receiving these requests shall compare this PIN to a list of authentic PINs for the named party as in D.5.3.5.2.1 above.

Response and trap messages from agents shall carry the serial number of the responding device in place of a PIN. These serial numbers should be verified using a local table before assuming that a response or trap message is authentic.

NOTE: This scheme can be easily spoofed by duplicating PINs and serial numbers intercepted from prior traffic. Because SetRequests may be more important to authenticate than responses and traps, the lists of valid PINs should be varied with time to heighten protection against bogus request messages.

D.5.3.5.2.3 Cryptographic authentication.

A secure authentication scheme for SNMP is specified in RFC-1446, section 3. This digest authentication protocol includes a digest of each authenticated message at the beginning of the message (authInfo in the SnmpAuthMsg). This digest is computed from the message contents and a secret initialization vector in such a way that it is considered computationally infeasible to "spoof" the authentication system. A time-of-day mechanism is included as well to limit the effects of replay attacks.

When cryptographic authentication of HNMP traffic is required, the digest authentication protocol of RFC-1446 shall be employed, using the MD-5 Message Digest Algorithm of RFC-1321. Initialization vector distribution is beyond the scope of this standard.

D.5.3.6 Traps.

HNMP messages containing traps are sent by managed elements to management applications to announce exceptional events, such as equipment failures or degradation of operating parameters beyond programmed thresholds. Trap messages may be used to reduce the required rate of polling for most such events.

D.5.4 HFNC interface to local equipment (station data bus).

The protocols specified in this section provides an optional interoperable mechanism to support the functionality specified in D.4.2.8.1 through D.4.2.8.3 for interconnecting an HFNC to one or more external link controllers (see figure D-15), as well as to other external equipment.

NOTE: Use of this optional communication interface is dependent on the system configuration and performance requirements. This interface will not normally be used between devices interconnected by a high-speed "backplane" bus.

The specific functions specified in D.4.2.8.1 and D.4.2.8.2 should be implemented using HNMP and the following objects from the HF MIB:

a. Link control should use the aleConnectionTable for management of ALE links, and hfdlpLinkState and hfdlpOtherAddress for management of HFDLP links.

b. Link quality reporting should use the aleLqaMatrix for link quality data.

Access to these MIB objects in local equipment shall employ HNMP messages sent directly to those devices using the station data link protocol specified in D.5.4.2. These messages will not use the network-layer header, AME header, and optional IP and UDP headers that are needed for sending messages through the network. That is, these are not "network messages."

Network messages (messages sent to other stations) should use the station network message format specified in D.5.4.1. Network messages in this format are carried over the station data bus (D.5.4.3) within the data link frames of the Station Data Link Protocol (see D.5.4.2 and figure D-16).

D.5.4.1 Station network message format.

The standard format for network messages passing between HFNCs and link controllers is shown on figure D-17. The first octet contains a count of the number of address octets in the link layer address of the distant station (destination of a message from HFNC to link controller, or source of a message from link controller to HFNC). This is followed by the indicated number of address octets, which is in turn followed by the network layer header and the remainder of the body of the network message.

Address Length

Link Layer Address

Network Layer Header

Message . . .

When a link controller receives a network message that specifies a destination to which it is not currently linked, a request to establish that link should be inferred.

D.5.4.2 Station data link protocol.

The point-to-point protocol (PPP) HDLC-like framing in accordance with RFC-1662 is recommended for use as a station data link protocol (SDLP) to carry traffic among devices in a station. In this scheme, HNMP and network messages are encapsulated within PPP packets, which are in turn carried in the Information field in HDLC frames (see figure D-16).

Some modifications to this scheme are necessary for SDLP, as detailed below. Padding at the end of the PPP packet is neither necessary nor desirable, and shall not be inserted.

NOTE: Padding can complicate the task of the receiving device.

D.5.4.2.1 HDLC mode for SDLP.

Links established by the HFNC shall operate in HDLC Normal Response Mode (NRM) in accordance with ISO/IEC 3309:1991, in which the HFNC acts as the "primary" device and polls the other "secondary" devices. The full range of HDLC frame types is used for SDLP, rather than solely Unnumbered Information frames as specified in RFC-1662.

Octet stuffing in accordance with RFC-1662 shall be used for transparency. This eliminates the need for bit stuffing (commonly required in other implementations of HDLC).

NOTE: The underlying physical layer will normally be asynchronous (rather than octet or bit-synchronous).

D.5.4.2.2 Bus arbitration.

Devices within the station shall be assigned one-octet HDLC addresses (the LSB must be 1), with address 1 reserved for the HFNC. The address field in the HDLC frames shall always contain the address of the secondary device (not the HFNC).

PPP links within a station shall be established only by the HFNC; other devices shall transmit frames on the station data bus only in response to "poll" frames from the HFNC (i.e., frames from the HFNC having the poll/final (P/F) bit in the HDLC Control field set to 1).

D.5.4.2.3 PPP numbers.

HNMP messages directed to local devices shall be sent using the network control PPP number assigned for HF (see Assigned Numbers RFC). Note that HNMP messages directed to remote devices will be embedded within network messages, following AME and possibly other headers.

Network messages shall use the network-layer PPP number assigned for HF AME.

D.5.4.2.4 PPP configuration options.

The following options (at least) should be configured during SDLP link establishment:

a. Cyclic Redundancy Check (CRC). Default is 16-bit CRC. SDLP implementations should negotiate use of 32-bit CRC in accordance with RFC-1570.

b. Maximum Received Unit (MRU). Default is 1500 octets. SDLP implementations should negotiate an MRU appropriate to the station error environment.

D.5.4.2.5 SDLP link establishment.

The following sequence of frames shall be sent on the station data bus to establish a link from the HFNC to a link controller.

a. The HFNC selects a link controller by sending a Set Normal response mode (SNRM) HDLC frame addressed to that link controller with the P/F bit set to 1.

b. The link controller responds with an unnumbered acknowledge (UA) HDLC frame with the P/F bit set to 1.

c. The HFNC attempts to open a PPP connection by sending an Information HDLC frame that contains a link control protocol (LCP) Configure-Request packet. This packet will specify the PPP configuration options (if any) that the HFNC wishes to change from their default values.

d. The link controller responds with an Information HDLC frame that carries its response to the Configure-Request (often a Configure-ACK). The HDLC frame from the HFNC is acknowledged in the HDLC header of the response.

e. Additional PPP LCP packets may be exchanged to continue to negotiate, or to authenticate the link establishment. (The details of HDLC Normal Response Mode are implied and not repeated here.)

The SDLP link is established when LCP Configure-Ack packets have been sent and received. Thereafter, HDLC Information frames are used to carry PPP packets carrying HNMP and network messages as described in D.5.4.3.

NOTE: Because the HFNC must poll a link controller before the link controller may transmit, links may remain in existence between uses, and this link establishment procedure need not be executed before each message is transferred.

D.5.4.3 Station physical layer.

The physical layer protocol of the station data bus employs full duplex asynchronous transmission of 8-bit characters (octets) with no parity and one stop bit. The least significant bit of each octet shall be sent first. All devices should support a data rate of 9600 b/s; other data rates are optional (DO: automatically send and adapt to the data rate in use).

The electrical interface shall be RS-485. The only circuits required are Transmitted Data (balanced), Received Data (balanced), Signal Ground, and Protective Ground. The HFNC shall drive the Transmitted Data circuit, and the other devices shall drive the Received Data circuit.

D.5.4.4 Examples.

Figure D-18 shows an example application of the station data bus concept in a large, unmanned (lights out) communication station. Because of electrical loading, more than a single station data bus would be required to connect the Message Switch/Node Controller to all of the assets shown.

Figure D-19 shows a conceptual "pop-up menu" oriented user interface for remotely controlling such a station. For each "level" of equipment, the operator selects devices by choosing from a menu of available devices of each type (e.g., crypto, modems, and radios), and links them together by clicking a mouse button between the rectangles shown. Each connection displayed is numbered with the index of the corresponding entry in the connection figure for the site (see HF MIB).

D.5.5 Multiple-media operation.

HFNCs (level 2 or above) shall be capable of automatically routing voice and data traffic via any available data link(s).

a. Level 2 HFNCs (with static routing tables) must be programmed to use specific media for each destination node. This may be accomplished by any combination of manual or remote programming (e.g., using HNMP).

b. Level 3 and above HFNCs shall automatically evaluate links of any medium for adaptive routing using the Path Quality formulas (paragraphs D.5.2.1 and D.5.2.4.2).

NOTE: The CONEX messages that carry the data necessary for path quality calculations will be less costly in terms of overhead on high-band-width alternate media than on HF links. In many applications, connectivity exchanges should be restricted to such high-bandwidth links, with query and notification-based protocols employed generally to discover and adapt to changing network topology and connectivity (see D.5.2.6.6.1 Routing Queries, D.5.2.6.6.3 Connectivity Monitoring, and D.5.2.7 Station Status Protocol).

c. Level 4 HFNCs shall implement the IP and the Internet Control Message Protocol (ICMP), and shall be capable of routing traffic via any available subnet.

D.6 NOTES.

None.