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.220.127.116.11 Routing table. 457D.18.104.22.168 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.22.214.171.124 Link control. 459D.126.96.36.199 Link quality reporting. 459D.188.8.131.52 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.184.108.40.206 Path quality matrix. 463D.220.127.116.11 Routing table. 465D.18.104.22.168.1 Organization. 465D.22.214.171.124.2 Manual entries. 465TABLE OF CONTENTS(continued)PARAGRAPH PAGED.126.96.36.199.3 Automatic updates. 466D.5.2.2 Indirect calling. 466D.5.2.3 Network layer header. 466D.5.2.4 Connectivity exchange. 466D.188.8.131.52 Voice path quality. 467D.184.108.40.206 Data path quality. 467D.220.127.116.11 CONEX message format (Optional). 470D.18.104.22.168 CONEX broadcast. 472D.22.214.171.124 CONEX handshake. 472D.5.2.5 Message delivery. 473D.126.96.36.199 AME header. 473D.188.8.131.52 Message store and forward. 474D.184.108.40.206 Null store and forward function. 475D.220.127.116.11.1 Outgoing messages. 475D.18.104.22.168.2 Incoming messages. 475D.22.214.171.124 AME. 475D.126.96.36.199.1 Outgoing messages. 476D.188.8.131.52.2 Incoming messages. 476D.5.2.6 Relay management protocol. 476D.184.108.40.206 HRMP address field. 477D.220.127.116.11.1 Message destination. 477D.18.104.22.168.2 Message source. 477D.22.214.171.124.3 Desired destination. 477D.126.96.36.199 HRMP message identification field. 477D.188.8.131.52 HRMP length field. 478D.184.108.40.206 HRMP commands. 478D.220.127.116.11 Checksum. 480D.18.104.22.168 HRMP operation. 480D.22.214.171.124.1 Routing queries. 480D.126.96.36.199.2 Repeater control. 480D.188.8.131.52.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.184.108.40.206 Inside local HF station. 484D.220.127.116.11 Outside local HF station. 485D.5.3.3 Management information. 485D.18.104.22.168 HF Management information base (MIB). 486TABLE OF CONTENTS(continued)PARAGRAPH PAGED.22.214.171.124 Encoding rules. 486D.5.3.4 Proxy management. 486D.5.3.5 Access control. 487D.126.96.36.199 Administrative model. 487D.188.8.131.52 Authentication. 487D.184.108.40.206.1 Trivial authentication. 488D.220.127.116.11.2 Personal identification number (PIN) authentication. 488D.18.104.22.168.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.22.214.171.124 HDLC mode for SDLP. 490D.126.96.36.199 Bus arbitration. 491D.188.8.131.52 PPP numbers. 491D.184.108.40.206 PPP configuration options. 491D.220.127.116.11 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
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.
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.
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
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.
|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,
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
|EIA/RS-485||Electrical characteristics of generators and receivers for use in balanced digital multipoint systems|
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 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.
|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.
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.
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.
|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|
|CRC||cyclic redundancy check|
|CSMA/CD||carrier sense multiple access with collision detection|
|DBM||data block message|
|DII||Defense Information Infrastructure|
|DoD||Department of Defense|
|DTM||data terminal message|
|HDLC||high-level data link control|
|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|
|LCP||link control protocol|
|LQA||link quality analysis|
|MRU||Maximum Received Unit|
|MSB||most significant bit|
|NRM||Normal Response Mode|
|NSAP||network service access point|
|OSI||open systems interconnections|
|PIN||personal identification number|
|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|
|UDP||User Datagram Protocol|
|UTC||universal time, coordinated|
Networked operation supports indirect routing to deliver traffic
when propagation does not support direct links.
A networking controller performs the networklayer 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
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.18.104.22.168.3. The interactions among the various functions and data structures within the networking controller are shown on figure D-2.
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.
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.22.214.171.124 for detailed requirements
for the routing table.
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 directlyreachable relay station. These path quality
estimates shall be based upon link quality measurements reported
by the link controllers in accordance with D.126.96.36.199.
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.188.8.131.52.
The route selection function supports both indirect calling and
various types of relaying, including analog repeaters, frame repeaters,
and message store and forward.
The message store and forward function provides message delivery
service for users or transportlayer processes (the term
transport message is used in all cases). This function may buffer
intransit 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
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 (socalled "discovery mode").
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
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 lowernumbered levels.
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.
(No routing table)
(No path quality matrix)
|Controls ALE radio (including indirect calling)
Remote data fill support
Automatic message exchange
Null store and forward
Internet protocol (optional)
Controls HF data modem (optional)
(No path quality matrix)
|(All capabilities of Level 1 HFNC) -plus-
Route selection using static routing table
Message store and forward
Routing table data fill
Repeater control (optional)
Controls multiple radios and modems (optional)
|(All capabilities of Level 2 HFNC) -plus-
Path quality matrix
Connectivity exchange (CONEX)
|(All capabilities of Level 3 HFNC) -plus-
Routing via alternate media
Internet protocol (mandatory)
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.
The networking controller shall be able to request the establishment
and termination of links, specifying desired destinations using
the appropriate linklevel 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).
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.
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 datalink 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.
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.
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.
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.
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.
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
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.
HF networking technology includes HFNC functions, the HF Network
Management Protocol, and a data link protocol for use within automated
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
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 networklayer 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).
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 locallyoriginated messages,
whether or not the station intends to relay messages for other
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.184.108.40.206 and D.220.127.116.11. Note that unidirectional path
qualities (A to destination) are shown. Normally, path qualities
in both directions will be stored and used.
*KEY: Voice Quality, Data Quality, Relays, Age
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
TRAFFIC VIA *
TRAFFIC VIA *
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
A means shall be provided for operator entry of routing table
data. These entries shall be retained in nonvolatile 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 nonadaptive 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
When adaptive routing is employed, alternative routes to reachable
destinations shall be reevaluated whenever new path quality
data arrives (e.g., via CONEX), and the routing table shall be
updated as appropriate.
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.
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 onecharacter header to determine the format
and protocol to use in interpreting the remainder of the message.
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.
| Connectivity exchange|
User message (with AME header)
Station status message
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.18.104.22.168.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.22.214.171.124b).
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.
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.
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
BER ARQ Repeats Estimate
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:
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).
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
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.
In the seven layer reference model, the network layer performs
endtoend 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 connectionoriented
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.
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 singlecharacter 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
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
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.
|Port Number||Transport Message Destination|
| Operator Terminal
Automatic Message Exchange Control Channel
HF Transport Protocol (HFTP)
Connectionless Network Protocol (CLNP)
Internet Protocol (IP)
HF Network Management Protocol (HNMP)
Reserved Until Standardized
The store and forward process accepts messages from, and delivers
messages to, users (or transportlevel 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
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.
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.
For each outgoing message, the null store and forward function
shall create an AME header with preprogrammed 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 sourcerouting. If
the user is able to override the source address, this capability
should normally be restricted to selecting one of a set of preprogrammed
addresses (to preclude impersonation of other stations).
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.)
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.
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
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.
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.126.96.36.199. 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
|Msg. Dest.||Msg. Source||Desired
|Msg. ID||Msg. Length|
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
The addresses of all three stations shall be encoded as AME address
records in accordance with D.188.8.131.52.
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.
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.
The Desired Dest. field on figure D-11 shall always contain the
address of the Distant station, with a Destination flag.
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.
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.
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.184.108.40.206.
Type, QOS, precedence
Type, QOS, precedence
Rept. No., type, QOS, status
Type, QOS, precedence
Rept No., reason code
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.
|Reason code||8-bit unsigned|| 0 - No connectivity
1 - Precedence too low
2 - Inappropriate
255 - Not equipped
|Type||2-bit unsigned|| 0 - Analog repeater
1 - Digital repeater
(Usually frame repeater)
2 - Store and forward
|QOS||6-bit field||Each bit independently selects a quality-of-service aspect; if bit = 1, better than normal performance in this aspect is requested
QOS1: (MSB) Delay
QOS6: (LSB) (Reserved)
|Precedence||8-bit unsigned|| 0 - Routine (lowest)
64 - Priority
128 - Immediate
192 - Flash
250 - Flash override
254 - Reserved for inter-network control use
255 - Reserved for network control use*
|Connectivity||8-bit unsigned|| 0 - Discovered direct connectivity
1 - Discovered indirect connectivity
254 - Lost direct connectivity (have indirect)
255 - Lost all connectivity
| 0 - Broadcast all changes of connectivity to distant stations
1- Broadcast only lose or discovery of connectivity:
do not report transactions between direct and indirect
|128 - Report all changes in connectivity
129 - Do not report connectivity changes
|Repeater No.||8-bit unsigned||Repeater reference number assigned by relay station|
| 0 - Repeater fully operational
1 - Requesting link to distant station
2 - Link to distant station failed; attempting to re-establish link
3 - Repeater preempted
255 - Repeater not available
* NOTE: Any number from 1 through 253, except those standardized herein (0, 64, 128, 192, and 250) may be used for user unique precedence requirements.
The 16-bit Checksum shall be computed in accordance with D.5.2.9.
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.
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.
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.220.127.116.11.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.
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
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
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.
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.18.104.22.168) 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.
Assumed net control (from non-net control stations)
Relinquishing net control (from net control station)
Alternate scan set 1
Alternate scan set 2
Alternate scan set 3
Out of service
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.
(0 - 9)
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.
Where permitted by network layer protocols, the broadcast address
"@ ? @" (identical to ALE Allcall address) may be used
to collectively refer to all reachable stations.
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.
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.
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.
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).
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.22.214.171.124. 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.
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.
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.
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.126.96.36.199. 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.188.8.131.52.
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.
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 184.108.40.206.220.127.116.11 (which traces the following path: iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) sys(1) sysDescr(1)).
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")
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).
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.
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.
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.
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.
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.18.104.22.168.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.
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.
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.
The protocols specified in this section provides an optional interoperable
mechanism to support the functionality specified in D.22.214.171.124
through D.126.96.36.199 for interconnecting an HFNC to one or more external
link controllers (see figure D-15), as well as to other external
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.188.8.131.52 and D.184.108.40.206 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
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).
|HNMP or Network Msg||Message|
|HDLC||Flag||Addr||Ctrl||CRC (32 Bits)||Flag|
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.
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.
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).
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).
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
Network messages shall use the network-layer PPP number assigned
for HF AME.
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
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.
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.
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).
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.220.127.116.11).
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.18.104.22.168.1 Routing Queries, D.22.214.171.124.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.