SM_Standard_v0.8.0_01-29-10.pdf

integrated Network Enhanced Telemetry (iNET) System Management Standards Working Group

System Management Standard

Proposed version 0.8.0

January 29, 2010

Environment: Aeronautical Environment

Approved By:

Allison Bertrand SMSWG Chairman

Thomas Grace Area Director

Distribution Statement C Distribution authorized to U.S. Government Agencies and their contractors for the purposes of reviewing and commenting on this working document. Administrative protections are employed to limit premature dissemination. Other requests for this document shall be referred to the System Management Standards Area Director or the iNET Program Office.

System Management Standard, version 0.8.0

See Distribution Statement C on cover page ii

Revision History Version Date Comments

0.1.0 3-19-08 Baseline document developed after the initial February 2008 face-to-face Working Group meeting.

0.2.0 6-03-08 Updated with CP changes approved at the May 2008 face-to-face Working Group meeting.

0.3.0 8-01-08 Updated with CP changes approved July 2008 face-to-face Working Group meeting. Affected sections: 4.2 (CP-003), 5.2 (CP-007), 5.3.2 (CP-009), 7 (CP-013). Previously labeled v0.7.

0.4.0 10-01-08 Updated with CP changes approved at October 2008 face-to-face Working Group meeting and the follow-up 10/08/08 telecon. Affected sections: 5.1 (CP-005 and CP-006), 9.9 (CP-020), 9.10 (CP-021), 3.1 (CP-031). Previously labeled v0.8.

0.5.0 12-19-08 Initial draft issue. Updated with CP changes approved at December 2008 face-to-face Working Group meeting. Affected sections: 2.2 (CP-017), 3.1 (CP-

035), 4.1 (CP-032), 4.2 (CP-032), 5.1 (CP-038, CP-039), 5.2 (CP-036), 5.3

(CP-029), 6 (CP-012), 9.2 (CP-024), 9.3 (CP-016), 9.4 (CP-028), 9.5 (CP-017),

9.6 (CP-018), 9.7 (CP-019), 9.8 (CP-030), 9.9 (CP-037), 9.10 (CP-037), 9.11

(CP-029), 9.12 (CP-025), 9.14 (CP-027), 9.15 (CP-022), 9.16 (CP-023), 9.17

(CP-034).

0.5.1 12-23-08 • Updated TBDs.

• The ethSpeed status variable was removed because the same functionality is available in the ifSpeed variable in the required IF-MIB (RFC 2863).

• Replaced tmnsSwitch with tmnsNetworkDevice.

• Replaced Data Stream ID with MessageDefinitionID.

0.5.2 2-16-09 Refactored document.

0.5.2a 2-19-09 • Variable types updated to match SNMP definitions.

• XML tags applied to allow automated MIB generation.

• Missing IEEE 1588 Jitter variables added.

0.5.2b Draft 2-26-09 Comments and updates from February 2009 face-to-face Working Group meeting.

0.6.0 3-9-09 Integrated comments from February 2009 face-to-face Working Group meeting.

0.6.1 5-20-09 Added index, replaced PTP terminology with the term “IEEE 1588”, updated non-SNMP technology note and fixed small typos.

0.7.0 5-26-09 Updates from May 2009 face-to-face Working Group meeting.

0.7.1 7-02-09 Updates from the Component Interface Document development.

0.7.2 7-30-09 Updated MIB syntax.

0.7.3 9-23-09 Removed obsolete faultTable “No Error” entry, corrected DSCP management compliance from NetworkNode to NetworkDevice.

See Distribution Statement C on cover page iii

Version Date Comments

0.7.4 10-08-09 Added Simultaneous Sampling controls (CP-59) and Information Assurance information (CP-56).

0.7.5 11-08-09 Added Simultaneous Sampling power interrupt handling and a note clarifying QoS status and control usage (CP-057).

0.7.6 12-07-09 Updated common definitions and acronyms lists. Added Table 5.21. SST Receiver Command Set for SST Rx management, rfNET tables, and DAU calibration modes. Updated Consolidated Management, Simultaneous Sampling, LTC status indexing, and clarified roleID usage.

0.7.7 draft 12-08-09 updated during the December 2009 face-to-face Working Group meeting.

0.8.0 WIP Updated from December 2009 face-to-face Working Group meeting. Updates to common definitions, acronyms, and document conventions. Fixed page number location. MIB variables “testIdentifier” and “tmnsInstance” have been removed and replaced with “messageDefinitionDomainName” in Section

4.3.1.1.3. Replaced “Event” with “Notification”. Corrected inconsistencies in enumeration numbering. Corrected formatting issues. Removed concept of shutdown command and shutdown notification. Changed rfNET to RAN.

See Distribution Statement C on cover page iv

Table of Contents

1. Introduction

1.1 Background

1.2 Responsibility

1.3 General

1.4 Scope

2. Applicable Documents

2.1 Government Documents

2.1.1 Specifications

2.1.2 Standards

2.1.3 Plans

2.2 Non-Government Documents

2.2.1 Specifications

2.2.2 Standards

3. Definitions, Abbreviations, and Conventions

3.1 Definitions

3.2 Abbreviations and Acronyms

3.3 Standards Key Words

3.4 Document Conventions

3.4.1 Usage of Defined Terms

3.4.2 Scope of References

3.4.3 Usage of Note Boxes

3.4.4 SNMP Conventions

4. General Requirements

4.1 General

4.1.1 Core Technology Leveraged By SNMP

4.1.1.1 Core Technology 26

4.1.1.2 Core Technology Registered Object Identifiers 26

4.1.1.3 Core Technology Management Information Base Support 26

4.1.1.4 Core Technology Error Values 26

4.1.1.5 Core Technology Properties 26

4.1.2 Non-SNMP Technology

4.2 Defined Constants and Defaults

4.2.1 Defined Constants

4.2.2 Defined NetworkNode Types

4.2.3 Default Values

See Distribution Statement C on cover page v

4.3 Common Interfaces and Protocols

4.3.1 System Management Interfaces

4.3.1.1 Identification 29

4.3.1.1.1 General Identification

4.3.1.1.2 NetworkNode Capabilities

4.3.1.1.3 NetworkNode Accounting Identification

4.3.1.2 Fault Handling 31

4.3.1.2.1 Fault Collection

4.3.1.2.2 Fault Notifications

4.3.1.2.3 Time Lock Fault Notifications

4.3.1.2.4 Temperature Fault Notifications

4.3.1.2.5 Fault Notification History

4.3.1.3 Configuration 43

4.3.1.3.1 Configuration Transport Mechanisms

4.3.1.3.2 Configuration Protocol

4.3.1.3.3 Handling of Configuration Faults

4.3.1.3.4 Multiple Configurations

4.3.1.3.5 Configuration Export

4.3.1.3.6 Configuration Error Checking

4.3.1.3.7 Notification Destination Configuration

4.3.1.3.8 IP Address Configuration

4.3.1.3.9 IEEE 1588 Configuration

4.3.1.4 Control of Test Elements 52

4.3.1.4.1 NetworkNode General Controls

4.3.1.4.2 NetworkNode Management Control

4.3.1.4.3 Simultaneous Sampling Control

4.3.1.5 Network Inventory 59

4.3.1.5.1 Inventory

4.3.1.6 State and Status 61

4.3.1.6.1 Status Collection

4.3.1.6.2 Time Status Collection

4.3.1.6.3 IEEE 1588 Time Status Collection

4.3.1.6.4 Self-Test Status Collection

4.3.1.7 Performance Management 65

4.3.1.8 Security 65

4.3.1.8.1 SNMP Security

4.3.1.8.2 Intrusion Detection

4.3.1.8.3 Information Assurance Management

5. Detailed Requirements

5.1 TmNS Segment Interfaces

5.1.1 Consolidated Management

5.1.1.1 Managed NetworkNodes 69

5.1.1.2 Consolidated SNMP Operations 69

See Distribution Statement C on cover page vi

5.1.1.3 Consolidated Management Variables 69

5.1.2 TmNS System Management

5.1.3 TAS System Management

5.1.3.1 TAS Antenna Management 73

5.1.4 GSS System Management

5.1.4.1 GSS Antenna Management 75

5.1.5 RAN System Management

5.1.5.1 RAN Management Variables 76

5.1.5.2 Radio Management Variables 87

5.2 TmNS Element Interfaces

5.2.1 NetworkDevice System Management

5.2.1.1 Multicast Routing 87

5.2.1.1.1 Multicast Routing Control and Status

5.2.1.1.2 IGMP Control and Configuration

5.2.1.1.3 Rules for Multicast Status Table Ports

5.2.1.2 Differentiated Services 94

5.2.1.3 Topology 94

5.2.2 Radio System Management

5.2.3 vNET System Management

5.2.4 gNET System Management

5.2.5 Antenna System Management

5.2.5.1 Antenna Tracking Mode Details 98

5.2.6 SST System Management (Transmitter and Receiver)

5.2.6.1 SST Transmitter Command Set 98

5.2.6.1.1 SST Transmitter Basic Command Set

5.2.6.1.2 SST Transmitter Extended Command Set

5.2.6.2 SST Receiver Command Set 104

5.2.7 Master Clock System Management

5.2.8 TmNS Adapter Management

5.3 Peripheral Interfaces

5.3.1 Latency/Throughput Critical DataSource (LTCDataSource) System Management

5.3.2 Latency/Throughput Critical DataSink (LTCDataSink) System Management

5.3.3 Reliability Critical DataSource (RCDataSource)

5.3.4 DAU System Management

5.3.4.1 DAU Calibration Mode 120

5.3.5 Recorder System Management

5.3.5.1 Recorder Media and Partition Status 120

5.3.5.1.1 Multiple Media and Partitions

5.3.5.1.2 Media Sessions

5.3.5.1.3 Media Status

5.3.5.2 Recorder Control 123

5.3.5.2.1 Recorder Control Details

5.3.5.3 Recorder Status 125

See Distribution Statement C on cover page vii

6. Index

See Distribution Statement C on cover page viii

List of Figures

Figure 1.1. Relationship of the TmNS Standards

Figure 1.2. TmNS Networks

Figure 1.3. System Management Standard Context

Figure 5.1. TmNS Segment Management Context

Figure 5.2. TmNS Element Management Context

Figure 5.3. Peripheral Management Context

See Distribution Statement C on cover page ix

List of Tables

Table 4.1. Current Version Strings

Table 4.2. NetworkNode Types with Specific Management

Table 4.3. NetworkNode Identification

Table 4.4. NetworkNode Capabilities

Table 4.5. Account Management Variables

Table 4.6. Fault Information

Table 4.7. Required Fault Numbers and Strings

Table 4.8. Required Fault Notifications

Table 4.9. Required Fault Notification Variables

Table 4.10. Time Lock Lost Fault Notification Variables

Table 4.11. IEEE 1588 Offset Fault Notification Variables

Table 4.12. IEEE 1588 Jitter Notification Variables

Table 4.13. Temperature Fault Notification Variables

Table 4.14. Required Fault Notification Information for all NetworkNodes

Table 4.15. File Transfer Protocols

Table 4.16. Configuration Variables

Table 4.17. Multiple Configuration Variables

Table 4.18. Variables for Configuration Export

Table 4.19. Variables for Setup Checks and Error Detection

Table 4.20. IP Address Configuration Variables

Table 4.21. IEEE 1588 Configuration

Table 4.22. Required Controls for all NetworkNodes

Table 4.23. NetworkNode Management Table

Table 4.24. Simultaneous Sampling Control Table

Table 4.25. NetworkNode Internal Inventory Variables

Table 4.26. State Numbers and Strings

Table 4.27. General State Information Variables

Table 4.28. Time Status Information

Table 4.29. IEEE 1588 Time Status Information

See Distribution Statement C on cover page x

Table 4.30. Self-Test Status

Table 4.31. Intrusion Variables

Table 5.1. Consolidated Commands

Table 5.2. Consolidated Manager Variables

Table 5.3. TAS Antenna Variables

Table 5.4. GSS Antenna Variables

Table 5.5. tmnsRAN Variables

Table 5.6. RAN Link Variables

Table 5.7. Link Available End Points Table

Table 5.8. Mission Service-Level Profile Variables

Table 5.9. MSLP Ingress and Egress Variables

Table 5.10. Service-Level Profile Variables

Table 5.11. SLP Capacity

Table 5.12. SLP Quality of Service Variables

Table 5.13. RAN Bearers

Table 5.14. RAN Queue Variables

Table 5.15. NetworkDevice Multicast Status Table

Table 5.16. NetworkDevice Configuration and Status

Table 5.17. NetworkDevice IGMP Controls

Table 5.18. TmNS Antenna Variables

Table 5.19. SST Transmitter Basic Command Set

Table 5.20. SST Transmitter Extended Command Set

Table 5.21. SST Receiver Command Set

Table 5.22. Master Clock Configuration and Status

Table 5.23. Adapter Device Variables

Table 5.24. LTCDataSource Variables

Table 5.25. LTCDataSink Variables

Table 5.26. RC Data Session Status

Table 5.27. DAU Calibration Mode Variables

Table 5.28. Required Media Session Variables

Table 5.29. Required Media Status Variables

See Distribution Statement C on cover page xi

Table 5.30. Required Recorder Control Variables

Table 5.31. Required Recorder Status Variables

See Distribution Statement C on cover page 12

1. INTRODUCTION

The Telemetry Network System (TmNS) is governed by a collection of standards documents. This System Management Standard provides a document that implementors and range users of TmNS equipment shall reference to ensure management interoperability between network nodes. The standards in this document are intended to provide a set of technologies, protocols, and variables for exchanging management information within a TmNS.

This document is not intended to provide operational details for any TmNS network nodes.

The System Management Standard protocols are founded upon the networking principles defined in the Test Article Standard. The Metadata Standard provides a test description and configuration information to be used by the System Management Standard. The System Management Standard, along with the other standards shown in Figure

1.1 , provides a complete framework for a TmNS.

SystemsSupporting Elements

Segments

Elements

Components

MetaData System Management TmNS

GSS TAS

MDSWG SMSWG

Sys. Mgmt.

MetaData

Sys. Mgmt.

MetaData

Sys. Mgmt.

MetaData iAMT

Antenna

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

Radio

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

RFNE

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

SST

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

gNET Interface

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

SST

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

vNET

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

Time Source

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

Time Source

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

Encryptor

Sys. Mgmt.

MetaData

C M

P

C M

P n

MD

SM

MD

SM

RANS

Sys. Mgmt.

MetaData

CLSWG

TASWGRNETGGSSWG

Figure 1.1. Relationship of the TmNS Standards

1.1 Background

This document was created by the System Management Standards Working Group (SMSWG) through the process of change proposal (CP) creation and standardization. During the process of standardization, it was decided that the format of the System Management Standard should change from a single, all-encompassing document to a format similar to other existing standards. As a matter of completeness, an additional artifact was created with rationale, history, and usage information removed from the previous version of the standard. This additional artifact, along with all SMSWG documentation (presentation material, CP documents, and meeting minutes available through the SMSWG web portal), constitutes all information supplementary to this standard.

1.2 Responsibility

The SMSWG is responsible for the content and changes to this standard. The government shall not be responsible for any ambiguities in this document. If any ambiguities are identified, the burden is on the user of the standard to

See Distribution Statement C on cover page 13 bring the ambiguities to the attention of the government. Additional copies of this document may be obtained from the integrated Network Enhanced Telemetry (iNET) Program Web Portal (https://www.inetprogram.org).

1.3 General

Architecturally, a TmNS is divided into three segments: the Test Article Segment (TAS), the Ground Station Segment (GSS) and the Radio Access Network Segment (RANS); along with two supporting entities: System Management and Metadata. A TmNS focuses primarily on two networks: the Vehicle Network (vNET) and Radio Access Network (RAN). The RAN has the ability to control one or more radios which are the heart of the Radio Frequency (RF) communications. The Ground Network (gNET) that interfaces into the RAN varies from range to range and thus a TmNS provides an interface to the gNET. The main functionality of a TmNS is moving data. The vNET transfers data between Peripherals (end nodes) on a Test Article and the RAN. The RAN transfers data between the vNET and gNET. Generally, these networks operate autonomously. Additionally, a TmNS supports many different types of applications and peripherals that reside outside a TmNS but have an integral role in the operation of a TmNS. System Management is used across a TmNS to manage NetworkDevices that provide fault, configuration, utilization, performance, and security management. The applications (or managers) in the system communicate with Agents in managed devices such as Peripherals and NetworkDevices. In general, Metadata is used to describe configurations and measurements. A simplified illustration of a TmNS and the supporting elements with representative users of the networks is shown in Figure 1.2.

Vehicle

Network Ground Network

Ground Network

R epresentative Applications

Metadata

System Management

R ep re se nt at iv e

P er ip he ra ls

Test Article Segment

Ground Station Segment

Radio

N etw ork

Radio AccessN etw ork

Radio Access

Radio

N etw ork

Radio AccessN etw ork

Radio Access

Radio Access Network Segment

Figure 1.2. TmNS Networks

1.4 Scope

This standard establishes the requirements for the System Management (SM) of the iNET architecture. It encompasses the protocols and interfaces required to manage a TmNS. Figure 1.3 illustrates TmNS System Management. The management interfaces provided in this standard allow range users and applications to drive the system and apply range policies. The protocols supporting management are provided by the Test Article Standard.

The Metadata Standard provides management information about the system. The TmNS standards work together to enable the management of TmNS devices.

https://www.inetprogram.org/�

See Distribution Statement C on cover page 14

TmNS Devices

TAS Devices

Peripherals

GSS Devices

Users

Range Applications

Range Users

Range Policies

System Management

Supporting Protocols

SNMP

HTTP

FTP

TFTP

ICMP

Commands, Queries, Events

Faults

Control

Status

Security

Identification

Configuration

Inventory and Topology

Performance

Figure 1.3. System Management Standard Context

See Distribution Statement C on cover page 15

2. APPLICABLE DOCUMENTS

The following documents are referenced in this standard. Unless otherwise noted, all documents referenced have equal precedence. Unless otherwise noted, this document takes precedence over all referenced documents.

2.1 Government Documents

2.1.1 Specifications

None identified in this document.

2.1.2 Standards

iNET Standards (version 0.8.0):

• Test Article Standard

• Metadata Standard

• Communication Link Standard

• RF Network Element Standard

• Component Interfaces Standard

Range Commanders’ Council (RCC) Telemetry Group

• Telemetry Standard RCC Document 106-09, Appendix N, April 2009

• RCC 106-09 standard Appendix N shall supersede and fill in details (such as string formats) not described in this document.

2.1.3 Plans

System Management Component Validation Plan (release TBD)

2.2 Non-Government Documents

2.2.1 Specifications

None identified in this document.

2.2.2 Standards

Institute of Electrical and Electronics Engineers (IEEE):

• IEEE 1588-2002

• IEEE 1588-2008

Internet Engineering Task Force (IETF) Request For Comments (RFCs):

• RFC 959: File Transfer Protocol (FTP)

• RFC 1122: Requirements for Internet Hosts – Communication Layers

• RFC 1213: Management Information Base for Network Management of TCP/IP-based internets: MIB-II

• RFC 1350: THE TFTP PROTOCOL (REVISION 2)

• RFC 1901: Introduction to Community-based SNMPv2

See Distribution Statement C on cover page 16

• RFC 2119: Key Words for use in RFCs to Indicate Requirement Levels

• RFC 2131: Dynamic Host Configuration Protocol

• RFC 2475: An Architecture for Differentiated Services

• RFC 2578: Structure of Management Information Version 2 (SMIv2)

• RFC 2579: Textual Conventions for SMIv2

• RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1

• RFC 2863: The Interfaces Group MIB

• RFC 2981: Event MIB

• RFC 3289: Management Information Base for the Differentiated Services Architecture

• RFC 3376: Internet Group Management Protocol, Version 3

• RFC 3411: An Architecture for Describing Simple Network Management Protocol (SNMP) Management

Frameworks

• RFC 3413: Simple Network Management Protocol (SNMP) Applications

• RFC 3414: User-based Security Model (USM) for version 3 of the Simple Network Management Protocol

(SNMPv3)

• RFC 3415: View-based Access Control Model (VACM) for the Simple Network Management Protocol

(SNMP)

• RFC 3416: Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)

• RFC 3418: Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)

• RFC 3826: The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security

Model

• RFC 4022: Management Information Base for the Transmission Control Protocol (TCP)

• RFC 4113: Management Information Base for the User Datagram Protocol (UDP)

• RFC 4188: Definitions of Managed Objects for Bridges

• RFC 4293: Management Information Base for the Internet Protocol (IP)

See Distribution Statement C on cover page 17

3. DEFINITIONS, ABBREVIATIONS, AND CONVENTIONS

Definitions, abbreviations, and document conventions in this standard document are common across the Test Article, System Management, and Metadata Standards. Not all definitions and abbreviations in this section are referenced in this document.

3.1 Definitions

Agent – A Simple Network Management Protocol (SNMP) process that provides a management interface on a NetworkNode.

Connector – A physical point of physical transport connection.

Consolidated Manager – a NetworkNodeManager that brings together into a single whole multiple information sources and control

DataDeliveryControlChannel – The common elements of the communication mechanisms for the setup, tear-down, and operation of the RC and LTC Delivery Protocols.

DataSink – An EndNode that consumes TmNSDataMessages.

DataSource – An EndNode that produces TmNSDataMessages.

EndNode – A NetworkNode that produces and/or consumes TmNSDataMessages.

Ground Network (gNET) – An external network outside the TmNS over which TmNSDataMessages flow which may use System Management and Metadata to interact with a Test Article Network.

Latency/Throughput Critical (LTC) Delivery Protocol – The TmNS-specific application-level method of delivering TmNSDataMessages via User Datagram Protocol (UDP).

LTCControlChannel - The communication mechanism for the setup, tear-down, and operation of the LTC Delivery Protocol.

LTCDataChannel – The communication mechanism for delivery of TmNSDataMessages using the LTC Delivery Protocol. See the Test Article Standard.

LTCDataSink – A DataSink that utilizes the LTC Delivery Protocol.

LTCDataSource – A DataSource that utilizes the LTC Delivery Protocol.

Management Information Base (MIB) – A “Structure of Management Information” (SMI) formatted text file used by the SNMP Agents and NetworkNodeManagers to define a common communication language for exchanging management information.

MeasurementData – A digital representation of a measurement.

MeasurementID – A numerical identifier that refers to a specific MeasurementData.

MessageDefinition – Corresponds to the structure, content, and mapping of content to structure of the TmNSDataMessage.

MessageDefinitionDomain (MDD) – An Operational Domain over which a set of RoleIDs and a set of MessageDefinitionIDs are unique..

MessageDefinitionID (MDID) – A numerical identifier that refers to a specific MessageDefinition.

See Distribution Statement C on cover page 18

Message Time – The Time in the MessageTimestamp field of the TmNSDataMessageHeader for that particular TmNSDataMessage. This time alone does not necessarily represent a specific acquisition event but can be used to represent the time of acquisition events in TmNSDataMessages when combined with other event markers.

Metadata – Information that describes a system and the data used by the system defined in the Metadata Standard.

Metadata Description Language (MDL) Instance Document – A document that complies with the language defined in the Metadata Standard.

NetworkConnection – A physical connection between Connectors and PhysicalNetworkPorts.

NetworkDevice – A NetworkNode that provides network and/or data link layer service and interconnectivity, without modifying data above the network layer. See Open Systems Interconnection (OSI) model.

NetworkInterface – A module that implements an interface, both logical and physical, between a NetworkNode and a TmNS.

NetworkNode – Any device that contains a NetworkInterface that is connected to a TmNS.

NetworkNodeManager – An entity which manages NetworkNodes.

Notification – An asynchronous SNMP message generated by a NetworkNode.

Operational Domain – A collection of data (e.g., streams over a network, a database, a file on a disk, etc.) that is observed in a logical and/or physical configuration at a specific time.

Package – A container for data that is composed of “0 or 1” PackageHeaders and “0 or 1” PackagePayloads.

PackageDefinition – Describes the structure and content of a Package and is fully specified with an MDL Instance Document.

PackageDefinitionID (PDID) – A numerical identifier that refers to a specific PackageDefinition.

PackageField - A logical grouping of related items within a Package.

PackageHeader – Fields in a Package that describe a PackagePayload.

PackagePayload – A structure in a Package that encapsulates MeasurementData and any required padding bits.

PackageStructure – A set of fields that make up the Package and can carry data.

Package Time – For Packages that use the standard PackageHeader, this is the time that is the sum of the Message Time for that particular TmNSDataMessage and the PackageTimeDelta field of the PackageHeader for that particular Package. This time alone does not necessarily represent a specific acquisition event but can be used to represent the time of acquisition events in TmNSDataMessages when combined with other event markers.

Path – A set of NetworkConnections that a TmNSDataMessage is transported on.

Peripheral – An EndNode connected to the TmNS that produces and/or consumes TmNSDataMessages and performs actions upon the TmNSDataMessagePayload, such as acquisition, storage, retrieval, and processing.

(Examples - Data acquisition units (DAUs), recorders, multi-function displays, processors, etc.)

PhysicalNetworkPort – A physical point of connection between NetworkNodes.

RCControlChannel – The communication mechanism for the setup, tear-down, and operation of the RC Delivery Protocol.

RCDataChannel – The communication mechanism for delivery of TmNSDataMessages using the RC Delivery Protocol. See the Test Article Standard.

See Distribution Statement C on cover page 19

RCDataSink – A DataSink that utilizes the RC Delivery Protocol.

RCDataSource – A DataSource that utilizes the RC Delivery Protocol.

Reliability Critical (RC) Delivery Protocol – The TmNS-specific application-level method of delivering TmNSDataMessages via Transmission Control Protocol (TCP).

RoleID – A string that refers to the role of a NetworkNode.

Telemetry Network System (TmNS) – The transport for a set of subsystems: Ground Station Segment (GSS), Radio Access Network Segment (RANS), Test Article Segment (TAS) and Serial Streaming Telemetry (SST); supported by System Management Elements and Metadata Elements.

Test Article – A unit under test.

Test Article Network – a vNET and all connected NetworkNodes physically residing on a Test Article.

TmNSDataMessage – A network-independent structure composed of a TmNSDataMessageHeader and a TmNSDataMessagePayload.

TmNSDataMessageHeader – Fields in a TmNSDataMessage that describe a TmNSDataMessagePayload.

TmNSDataMessagePayload – Composed of one or more Packages.

TmNS_URI – The uniform resource identifier (URI) that describes the request specification as defined by the LTC and RC Delivery Protocols.

Vehicle Network (vNET) – A network within a TmNS that interconnects the Peripherals within the Test Article.

3.2 Abbreviations and Acronyms

ACU Antenna Control Unit

AES Advanced Encryption Standard

AF Assured Forwarding

AGC Automatic Gain Control

ARINC Aeronautical Radio, Incorporated

ARP Address Resolution Protocol b Bit

B Byte

BIPM Bureau International des Poids et Mesures

BIT Built-In Test

BNF Backus-Naur Form

CIDR Classless Inter-domain Routing

CLSWG Communication Link Standards Working Group

CP Change Proposal

See Distribution Statement C on cover page 20

DAC Digital to Analog Converter

DAU Data Acquisition Unit dB Decibels dBm Decibel milliwatt

DHCP Dynamic Host Configuration Protocol

DiffServ Differentiated Services

DNS Domain Name System

DS Differentiated Services (DiffServ)

DSCP DiffServ Code Point

EF Expedited Forwarding

EIA Electronic Industries Alliance

EU Engineering Units

EUI Extended Unique Identifier

FTP File Transfer Protocol

GB Gigabytes (1024 x 1024 x 1024 bytes) gNET Ground Network

GPS Global Positioning System

GS Ground Station

GSE Ground Support Equipment

GSS Ground Station Segment

GSWG Ground Systems Working Group

HAIPE High Assurance Internet Protocol Encryptor

HTTP Hypertext Transfer Protocol

HTML Hypertext Markup Language

IANA Internet Assigned Number Authority

ICMP Internet Control Message Protocol

ID Identifier

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IGMP Internet Group Management Protocol iNET Integrated Network Enhanced Telemetry

See Distribution Statement C on cover page 21

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

IRIG Inter-Range Instrumentation Group

IS Interface Specification

ITU International Telecommunication Union kbps kilobits-per-second (1000 bits per second)

LLC Logical Link Control

LSB Least Significant Bit

LTC Latency/Throughput Critical

MAC Media Access Control

MB Megabytes (1024 x 1024 bytes)

Mbps Megabits-per-second (1,000,000 bits per second)

MDD Message Definition Domain

MDID MessageDefinitionID

MDL Metadata Description Language

MDSWG Metadata Standards Working Group

MFD Multi-Function Display

MFOI Maximum Frequency Of Interest

MIB Management Information Base

MIL-STD Military Standard

MLD Multicast Listener Discovery

MSB Most Significant Bit

MSLP Mission Service-Level Profile

NOP No Operation

NPT Normal Play Time

OID Object Identifier

OSI Open Systems Interconnection

PCM Pulse Code Modulation

PDID PackageDefinitionID

PHB Per-Hop Behavior

See Distribution Statement C on cover page 22

PIM Protocol Independent Multicast

PIM-SM Protocol Independent Multicast – Sparse Mode

PPS Pulse-Per-Second

PTP Precision Time Protocol

QoS Quality of Service

RAN Radio Access Network

RANS Radio Access Network Segment

RC Reliability Critical

RCC Range Commanders’ Council

RF Radio Frequency

RFC Request for Comments rfNET Radio Frequency Network

RNETG RF Network Element Technical Group

RSTP Rapid Spanning Tree Protocol

RTP Real-time Transport Protocol

RTSP Real Time Streaming Protocol

SANS SysAdmin, Audit, Networking, and Security

SI Units International System of Units

SIP Session Initiation Protocol

SLP Service-Level Profile

SMI Structure of Management Information

SMPTE Society of Motion Picture and Television Engineers

SMSWG System Management Standards Working Group

SNMP Simple Network Management Protocol

SST Serial Streaming Telemetry

T&E Testing and Evaluation

TA Test Article

TAS Test Article Segment

TASWG Test Article Standards Working Group

TBD To Be Determined

TBR To Be Reviewed

See Distribution Statement C on cover page 23

TCP Transmission Control Protocol

TDMA Time Division Multiple Access

TFTP Trivial File Transfer Protocol

TIA Telecommunications Industry Association

TmNS Telemetry Network System

TTL Transistor-Transistor Logic

UDP User Datagram Protocol

URI Uniform Resource Identifier

UTC Coordinated Universal Time

UTP Unshielded Twisted Pair vNET Vehicle Network

W3C World Wide Web Consortium

XML eXtensible Markup Language

XSD XML Schema Definition

3.3 Standards Key Words

In many sections of this document, key words are used to signify the requirements in the standard. This section defines these words (derived from RFC 2119) as they should be interpreted in iNET standards. Note that the force of these words is modified by the requirement level of the standard in which they are used.

• SHALL: This word means that the definition is an absolute requirement of the standard.

• SHALL NOT: This phrase means that the definition is an absolute prohibition of the standard.

• SHOULD: This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

• SHOULD NOT: This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

• MAY: This word means that an item is truly optional. One implementation may choose to include the item because a particular marketplace requires it or because the implementation enhances the product while another implementation may omit the same item. An implementation which does not include a particular option SHALL be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein, an implementation which does include a particular option SHALL be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).

See Distribution Statement C on cover page 24

3.4 Document Conventions

3.4.1 Usage of Defined Terms

The words defined in Section 3.1 “Definitions” are reserved for specific use and will be italicized when they appear throughout the iNET standard documents. The use of italics is reserved exclusively for words that appear in Section 3.1 “Definitions”.

3.4.2 Scope of References

A reference to a section number from any of the iNET standard documents includes only that specific section and not its subsections. A reference to a section number followed by an asterisk (e.g., see Sections 4.3.2.*) indicates that the section referenced (e.g., Section 4.3.2) and all of its subsections are included in the context of the reference.

3.4.3 Usage of Note Boxes

Throughout the iNET standard documents, Note boxes such as the one below will appear with information relevant to the material being presented in the surrounding text. These Note boxes will act as a supplement to guide the reader with rationale and advisories where they are deemed useful; however, the content of the Note boxes is purely informational. Either by their presence and/or removal, the Note boxes shall not augment the rules and specifications presented in the iNET standard documents in any way.

This is an example of a Note box that appears in the iNET standard documents.

3.4.4 SNMP Conventions

This document uses a set of conventions when defining SNMP variables.

• For each variable, a “Type” and a “Read-Write” value is indicated. These values are defined by the SNMP RFCs and are only restated here for clarity.

• Type (of SNMP variables) – NOTIFICATION-TYPE, Counter64, Integer32, and Unsigned32 are defined by SNMPv2-SMI (RFC 2578). TestAndIncr, TruthValue, and DisplayString are defined by SNMPv2-TC (RFC 2579). INTEGER is an enumerated form of Integer32.

• Read-Write (of SNMP variable) –read-only, read-write, read-create, not-accessible, and accessible-for-notify are SNMP variable access levels (RFC 2578). The first two types are self-explanetory. The term “read-create” indicates a table entry may be read, created, or modified. The term “not-accessible” means the variable is used internally by the SNMP Agent (such as a table index), but is not retrievable through SNMP network commands. The term “accessible-for-notify” means the variable is used as part of an SNMP notification and is not retrievable through SNMP network commands.

• To define the structure of the SNMP MIB tree, the following convention is used:

• [Bracketed Description] – Description entries in variable tables surrounded with square brackets indicate the variable’s placement in the TmNS MIB. For example: [tmnsCommonFault 2] indicates that the variable is the second variable on the tmnsCommonFault branch.

• Conventions used in place of table values include:

See Distribution Statement C on cover page 25

• Blank String (“”) – A blank or empty string is indicated as double-quotes with no characters. This is commonly used to initialize a string before a value is assigned.

• N/A – Not Applicable. For example, this value is given for the default state of tables indicating that the table has no rows, and so has no default values. N/A is also given for read-only variables which are expected to hold constant properties of the device (such as the NetworkNode type).

See Distribution Statement C on cover page 26

4. GENERAL REQUIREMENTS

4.1 General

4.1.1 Core Technology Leveraged By SNMP

4.1.1.1 Core Technology

NetworkNodes shall use the following core technology for management:

• Either Simple Network Management Protocol version 3 (SNMPv3) over User Datagram Protocol (UDP) or Simple Network Management Protocol version 2c (SNMPv2c) over UDP may be used independently or both versions may be used on the same network.

• SNMPv3 is described by the IETF RFC 3411.

• SNMPv2c is described by the IETF RFC 1901.

4.1.1.2 Core Technology Registered Object Identifiers

The base of the TmNS SNMP Management Information Base (MIB) has the following Object Identifier (OID) registered with Internet Assigned Number Authority (IANA):

• Telemetry Network System: iso.org.dod.internet.private.enterprise.31409 (1.3.6.1.4.1.31409)

4.1.1.3 Core Technology Management Information Base Support

NetworkNodes shall implement the following to provide general SNMP support:

• SNMPv2-MIB snmpBasicComplianceRev2 defined by RFC 3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP).

4.1.1.4 Core Technology Error Values

Error handling is detailed by the SNMP RFCs in this document. Some key SNMP protocol error cases are emphasized here for clarity:

• The SNMP exception value of noSuchObject(0) shall be returned for each variable not implemented, as stated in RFC 3416.

• Unsupported enumerations or value ranges shall return an SNMP error-status of inconsistentValue(12), as stated in RFC 3416.

4.1.1.5 Core Technology Properties

Two properties of the System Management interface need to be defined in order to ensure interoperability. These two properties are:

Implementations may consist of both versions as security issues may affect procurement decisions.

See Distribution Statement C on cover page 27

• Idempotency

• Persistence

The idempotency property means that sending the same command twice shall have the same effect as sending the command once. A contiguous, exactly repeated SNMP command shall not cause a device fault. Furthermore, the act of querying an SNMP variable on a device shall not change the value being queried. This will ensure consistency when multiple NetworkNodeManagers exist on the network. The idempotency property applies to all TmNS SNMP variables except where specifically noted.

The persistence property means that the value is retained across resets and loss of power. Not all SNMP variables need be persistent. The TmNS-MIB variables shall be designated as persistent or not persistent. Variables designated persistent shall be stored in non-volatile memory as soon as they are set. Persistent variables shall not retain their value if the device is reset back to its default configuration. After a reset to default, the default values for all variables on a device shall be set regardless of their state or persistence before the reset to default was initiated.

When implementing RFC MIBs on NetworkNodes, idempotency and persistence rules defined within each RFC shall apply for those MIBs.

4.1.2 Non-SNMP Technology

NetworkNodes shall use Hypertext Transfer Protocol (HTTP) 1.1 (RFC 2616) and may use other standardized web technologies to provide complementary or additional features.

4.2 Defined Constants and Defaults

4.2.1 Defined Constants

Version strings specified in this document are given in Table 4.1. TmNS implementations based on this document shall use these values.

Table 4.1. Current Version Strings

Variable Description Version String tmnsVersion (Table 4.19) TmNS Version 0.8.0 Proposed tmnsSSTTx::sstTxRCCVersion (Table 5.19) RCC Document Version RCC 106-09

4.2.2 Defined NetworkNode Types

NetworkNode types specifically called out in the System Management Standard are listed in Table 4.2. A NetworkNode shall indicate any relevant types it supports in the networkNodeTypeTable (Section 4.3.1.1.2) and may support one or more of the types in this table. NetworkNodes shall meet both the general and detailed

The intent of specifying a supplemental non-SNMP technology is to define a common protocol through which users can access advanced or implementation-specific management information on any device.

See Distribution Statement C on cover page 28 requirements (Section 4 and its subsections and Section 5 and its subsections). Other NetworkNode types not specifically mentioned in this table shall meet the general requirements (Section 4 and its subsections).

Table 4.2. NetworkNode Types with Specific Management tmnsDeviceType MIB Enumeration

Description tmnsNull 0 A device that should be displayed in the network, but not actively managed (network printers, e.g.).

tmnsNetworkDevice 1 NetworkNode that passes data. tmnsNetworkDevices may have different levels of differentiated services (DiffServ) and multicast routing support (See Section 5.2.1).

tmnsRAN 2 RAN tmnsAntenna 3 Antenna tmnsTAS 4 Test Article Segment tmnsGSS 5 Ground Station Segment tmnsDAU 6 Source Peripheral such as a DAU tmnsRecorder 7 Sink Peripheral such as a recorder tmnsMasterClock 8 External Time Source Master tmnsEncryptor 9 Encryptor tmnsMFD 10 Multi-Function Display tmnsGSE 11 Ground Support Equipment tmnsSSTTx 12 SST Transmitter tmnsSSTRx 13 SST Receiver tmnsTmNS 14 Telemetry Network System tmnsAdapter 15 Interface which adapts more than one device to provide full TmNS support tmnsRCDataSource 16 NetworkNode which serves as an RCDataSource tmnsLTCDataSource 17 NetworkNode which serves as an LTCDataSource tmnsLTCDataSink 18 NetworkNode which serves as an LTCDataSink tmnsConsolidatedManager 19 Consolidated Manager of a group of TmNS NetworkNodes tmnsRadio 20 Radio

Devices that return other NetworkNode type identifier strings not listed in Table 4.2 shall implement (at a minimum) the common System Management interfaces defined in Section 4.3.1.

See Distribution Statement C on cover page 29

4.2.3 Default Values

Default values are given for all variables unless otherwise indicated. For instance, the default value for a table is an “empty” state because it has no rows.

In the case of read-only variables which report status, the defaults shall be applied during NetworkNode initialization; the actual status value shall replace the default value once the NetworkNode is able to acquire that status.

In the case of controls or settings, the default values listed shall be applied to the NetworkNode when the “reset to default” command is issued.

4.3 Common Interfaces and Protocols

4.3.1 System Management Interfaces

The interfaces specified in this section and its subsections shall be available on all NetworkNodes unless otherwise noted. Variables in this section and its subsections are part of the TmNS Common MIB subtree.

4.3.1.1 Identification

System Management Interfaces on NetworkNodes shall provide information which identifies and describes a NetworkNode through the following SNMP variables:

4.3.1.1.1 General Identification

The NetworkNodes shall implement the MIB variables in Table 4.3 for information generally identifying the NetworkNode. The variables in this section shall not be set with an MDL Instance Document unless explicitly stated in the table.

Table 4.3. NetworkNode Identification

Variable Name Description Type Read- Write

Default Value

Persist (Y/N) inventoryID An identifier string used for tracking of NetworkNodes in range inventories.

[tmnsCommonIdentification 1]

DisplayString

(SIZE(0..255))

read-write

“” Y networkNodeDescription A string giving a human-readable name or description of the NetworkNode. This assists operators in identifying a NetworkNode (e.g. ‘Left Wing DAU’). This string may be set with the MDL Instance Document during configuration [tmnsCommonIdentification 2]

DisplayString

(SIZE(0..255))

read-write

“” Y manufacturerIdentifier Manufacturer name.

[tmnsCommonIdentification 3]

DisplayString

(SIZE(0..255))

read-only

“” Y

See Distribution Statement C on cover page 30

Variable Name Description Type Read- Write

Default Value

Persist (Y/N) modelIdentifier Model identifier.

[tmnsCommonIdentification 4]

DisplayString

(SIZE(0..255))

read-only

“” Y serialIdentifier Serial identifier.

[tmnsCommonIdentification 5]

DisplayString

(SIZE(0..255))

read-only

“” Y ieeeEUI64 Optional IEEE extended unique identifier (EUI)-64 value of the NetworkNode (not the network adapter). Blank if not supported.

[tmnsCommonIdentification 6]

OCTET

STRING

(SIZE(0 | 8))

read-

4.3.1.1.2 NetworkNode Capabilities

The NetworkNodes shall implement the MIB variables in Table 4.4 to represent their capabilities.

Table 4.4. NetworkNode Capabilities

Variable Name Description Type Read- Write

Default Value

Persist (Y/N) networkNodeTypeTable A table of standard strings giving the type(s) of the NetworkNode. This string can be used by a topology algorithm.

[tmnsCommonIdentification 7]

Table not-accessible

N/A Y networkNodeTypeTable::

networkNodeIndex

Index for the networkNodeTable.

[networkNodeTypeEntry 1]

Unsigned32 not-accessible

1 Y networkNodeTypeTable::

networkNodeType

A standard string giving the type of the NetworkNode.

The basic set of NetworkNodes is listed in Table 4.2.

[networkNodeTypeEntry 2]

TmNSDeviceType read-only N/A Y

4.3.1.1.3 NetworkNode Accounting Identification

The NetworkNodes shall provide account management information to track the MessageDefinitionDomain with which a NetworkNode is associated (Table 4.5).

See Distribution Statement C on cover page 31

Table 4.5. Account Management Variables

Variable Name Description Type Read- Write

Default Value

Persist (Y/N) messageDefinitio nDomainName

Key to identify the MessageDefinitionDomain with which the NetworkNode is associated. This identifier allows the NetworkNode to identify its MessageDefinitionDomain within the configuration MDL Instance Document and shall not be set by the MDL Instance Document.

[tmnsCommonIdentification 9]

DisplayString

(SIZE(0..255))

read-write

4.3.1.2 Fault Handling

The values reported in the faultTable and the faultNotification are designed to allow extensibility in the standard by naming well-known faults while leaving room for the definition of future faults.

4.3.1.2.1 Fault Collection

A NetworkNode shall support the collection of fault information by providing a table of the current faults of the NetworkNode. The faultTable and its fault entry variables are described in Table 4.6. Current system faults shall be listed in the faultTable. The faultTable contains the variables faultNumber and faultString. The NetworkNode shall clear faults from this table when they are no longer relevant.

Table 4.6. Fault Information

Variable Name

Description Type Read- Write

Default Value

Persist (Y/N) faultTable Table of fault numbers and strings. [tmnsCommonFault 1]

Table not-accessible

N/A N

This standard does not specify a format for the messageDefinitionDomainName string.

Uniqueness of this identifier should be addressed by range policy.

The messageDefinitionDomainName allows the NetworkNode to identify its particular MessageDefinitionDomain within an MDL Instance Document during configuration. The messageDefinitionDomainName may be set once for the lifetime of the device or changed for a given test, configuration, or other event, according to range practices. Since the messageDefinitionDomainName is a persistent value, a NetworkNodeManager is not required to set the messageDefinitionDomainName before each configuration.

See Distribution Statement C on cover page 32

Variable Name

Description Type Read- Write

Default Value

Persist (Y/N) faultTable::

faultIndex

Index for the faultTable.

Table entries shall retain the index originally assigned until the entry is cleared. The index shall be initialized to one and otherwise follow the rules for a Counter32.

[faultEntry 1]

Counter32 not-accessible

N/A N faultTable::

faultNumber

Numerical fault value.

[faultEntry 2]

INTEGER

{timeLockFault (1), configurationFault (2), deviceFault (3), invalidInput (4)} read-only N/A N faultTable::

faultString

Description of fault given by faultNumber. [faultEntry 3]

DisplayString

(SIZE(0..255))

read-only N/A N

Table 4.7 indicates the standard values which the Fault Information variables shall (at a minimum) contain.

Table 4.7. Required Fault Numbers and Strings

Fault Number Fault String Description

1 “Time Lock Fault” The device is not locked to the external time source.

2 “Configuration Fault” A fault occurred during configuration.

3 “Device Fault” The device is in an error state not represented by other specifically named general errors.

4 “Invalid Input:[Variable]”

Unrecognized command or parameter where the [Variable] field provides the name of the command which caused the error.

5 through

Not Defined Reserved for future standards expansion.

4.3.1.2.2 Fault Notifications

Faults that shall be reported by NetworkNodes through the faultNotification type are shown in Table 4.8.

Notification destination configuration is defined in Section 4.3.1.3.7.

See Distribution Statement C on cover page 33

Table 4.8. Required Fault Notifications

Fault Notification Type

Description

“Power Fault” Abnormal power fluctuations.

“Invalid Input:[Variable]”

Unrecognized command or parameter where the [Variable] field provides the name of the command which caused the error.

Table 4.9 lists the fault Notification variables that shall be implemented by the NetworkNodes.

See Distribution Statement C on cover page 34

Table 4.9. Required Fault Notification Variables

Variable Name Description Type Read-Write Default Value

Persist (Y/N) faultNotification Notification which provides the fault Notification time and the fault Notification type.

[faultNotificationBranch 1]

NOTIFICATION-TYPE,

OBJECTS {

networkNodeTime, faultNotificationType }

N/A N/A N faultNotificationType A string describing the fault. Standard fault strings are given in Table 4.8. [faultNotificationBranch 2]

DisplayString

(SIZE(0..255))

accessible-for-notify

“” N faultNotificationEnabl eFlag

Enable or disable fault Notifications, (1) true = enable, (2) false = disable. [tmnsCommonFault 2]

TruthValue read-write false Y faultNotificationInterv al

Sets the interval between repeated fault Notifications of this fault instance in milliseconds.

[tmnsCommonFault 3]

Unsigned32 read-write

5000 Y faultNotificationRepe at

Sets the number of repeats allowed for a fault Notification instance. [tmnsCommonFault 4]

Unsigned32 read-write 1 Y

See Distribution Statement C on cover page 35

4.3.1.2.3 Time Lock Fault Notifications

Time lock fault Notifications are called out as separate fault types due to the high importance of time lock in the system.