TA_Standard_v0.8.0_01-29-10.pdf

integrated Network Enhanced Telemetry (iNET)

Test Article Standards Working Group

Test Article Standard Proposed version 0.8.0

January 29, 2010

Environment: Aeronautical Environment

Approved By:

Myron Moodie TASWG 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 Test Article Standards Area Director or the iNET Program Office.

Test Article Standard, version 0.8.0

See Distribution Statement C on cover page ii

Revision History Version Date Sections

Affected Comments

0.0.1 6/04/08 Closed CPs Updated for May 2008 TASWG face-to-face Working Group meeting.

0.0.2 6/18/08 All Minor changes/clarifications.

0.0.3 7/21/08 Closed CPs Updated for July 2008 TASWG face-to-face Working Group meeting.

0.0.4 10/09/08 Closed CPs Updated for September 2008 TASWG face-to-face Working Group meeting.

0.5.0 12/19/08 Closed CPs Updated for December 2008 TASWG face-to-face Working Group meeting.

Revised version numbering scheme to use major number for release (Experimental = 0, Proposed = 1, Draft = 2, Final = 3), first minor number to represent number of face-to-face Working Group meetings held to date, and second minor number to represent versioning between face-to-face Working Group meetings.

0.5.1 12/19/08 All Refactored version of v0.5.0.

0.6.0 3/03/09 All Incorporated initial feedback from 2009 February TASWG face-to-face Working Group meeting.

0.6.1 3/20/09 All Incorporated additional feedback from 2009 February TASWG face-to-face Working Group meeting.

0.7.0 6/02/09 Closed CPs Updated for May 2009 TASWG face-to-face Working Group meeting.

0.7.1 6/16/09 All Minor clerical updates.

0.7.2 7/08/09 All Structural revisions to support referencing from Component

Interfaces Standard. Revision of data delivery protocols to support parametric data retrieval and playback.

0.7.3 7/30/09 All Formatting and grammatical updates

0.7.4 10/08/09 All Added definitions for MDID, PDID, and MeasurementID;

updated common definitions and acronyms; added Appendix A to TOC; removed “that support IPv4” wording;

corrected Reserved bit range; spelled out URI in first use;

accepted CP-036 changes except parametric data extraction;

added Section 5.3 Information Assurance; added clarification wording to parametric data extraction.

0.7.5 11/9/09 All Updated common definitions; added Section 5.4 Voice Services.

0.7.6 12/1/2009 All Added TmNSdeliverymdid and TmNSdeliverypdid to the TmNS_URI format and removed TmNSdestmdid from the TmNS_URI format; added wording to clarify PDE requests by MDID, PDID, and MeasID; Section 5.2.3

See Distribution Statement C on cover page iii

Version Date Sections Affected

Comments

DataDeliveryControlChannel; clarified handling of

MessageFlags, ApplicationDefinedFields, and

StatusFlags; allowed all three request types for LTCControlChannel; Corrected TmNS_URI to match requirement wording.

0.7.7 12/7/2009 All Updated Timestamp definitions for both Messages and Packages; updated tmnslist portion of TmNS_URI; updated common definitions and acronyms.

0.8.0 01/29/2010 All Updates from December 2009 face-to-face Working Group meeting.

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.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 Usage of Message Fields

3.4.3 Scope of References

3.4.4 Usage of Note Boxes

3.5 Octet and Bit Ordering

4. General Requirements

4.1 General

4.1.1 Test and Operating Requirements

4.1.2 Core Technology

4.1.3 Defined Technology Versions

4.2 Physical and Electrical Characteristics

4.2.1 Ethernet

4.2.1.1 10 Mbps Ethernet

4.2.1.1.1 10BASE-T

4.2.1.1.2 10BASE-FL

4.2.1.2 100 Mbps Ethernet

4.2.1.2.1 100BASE-TX

See Distribution Statement C on cover page v

4.2.1.2.2 100BASE-FX

4.2.1.2.3 100BASE-LX10

4.2.1.3 Gigabit Ethernet

4.2.1.3.1 1000BASE-T

4.2.1.3.2 1000BASE-SX

4.2.1.3.3 1000BASE-LX

4.2.1.4 10 Gigabit Ethernet

4.2.1.4.1 10GBASE-X/10GBASE-T

4.2.1.4.2 10GBASE-R

4.2.2 Auto-Negotiation

4.2.2.1 Copper Auto-Negotiation

4.2.2.2 Fiber Auto-Negotiation

4.3 Protocols

4.3.1 Core Requirements for NetworkNodes and NetworkDevices in a Test Article Network

4.3.1.1 Core Requirements for NetworkNodes in a Test Article Network

4.3.1.2 Core Requirements for NetworkDevices in a Test Article Network

4.3.2 Data Link Protocols

4.3.2.1 Frame Structure

4.3.2.2 Media Access Control (MAC)

4.3.2.3 Logical Link Control (LLC)

4.3.2.4 Link Layer Switching

4.3.2.5 Link Layer Flow Control

4.3.3 Network Protocols

4.3.3.1 Internet Protocol version 4 (IPv4)

4.3.3.2 IP Datagram Transmission

4.3.3.3 Internet Control Message Protocol (ICMP)

4.3.3.4 Internet Group Management Protocol (IGMP)

4.3.3.4.1 IGMP Snooping

4.3.4 Transport Protocols

4.3.4.1 Transmission Control Protocol (TCP)

4.3.4.2 User Datagram Protocol (UDP)

4.4 Network Services

4.4.1 Address Resolution and Configuration

4.4.1.1 Address Resolution

4.4.1.2 Host/Address Configuration

4.4.1.2.1 Static Configuration

4.4.1.2.2 Dynamic Configuration

4.4.2 Name Services

4.4.3 File Transfer

5. Detailed Requirements

5.1 Time Synchronization

5.1.1 Network Time Synchronization Interfaces

See Distribution Statement C on cover page vi

5.1.1.1 IEEE 1588 Master Clock

5.1.1.2 IEEE 1588 Slave Clock

5.1.1.3 IEEE 1588 Boundary Clock

5.1.1.4 One Pulse-Per-Second (1 PPS) Outputs on IEEE 1588 Devices

5.1.2 External Time Synchronization Interface

5.2 Data Transfer

5.2.1 TmNSDataMessage Structure

5.2.1.1 TmNSDataMessageHeader

5.2.1.1.1 MessageVersion Field (4 bits)

5.2.1.1.2 OptionWordCount Field (4 bits)

5.2.1.1.3 Reserved Field (8 bits)

5.2.1.1.4 MessageFlags Field (16 bits)

5.2.1.1.5 MessageDefinitionID Field (32 bits)

5.2.1.1.6 MessageDefinitionSequenceNumber Field (32 bits)

5.2.1.1.7 MessageLength Field (32 bits)

5.2.1.1.8 MessageTimestamp Field (64 bits)

5.2.1.1.9 ApplicationDefinedFields Field (OptionWordCount*32 bits)

5.2.1.2 TmNSDataMessagePayload

5.2.1.2.1 Package Structure

5.2.1.2.2 PackageHeader

5.2.2 TmNSDataMessage Delivery

5.2.3 DataDeliveryControlChannel

5.2.3.1 DataDeliveryControlChannel Request Types

5.2.3.1.1 MessageDefinitionID Request (TmNSmdid)

5.2.3.1.2 PackageDefinitionID Request (TmNSpdid)

5.2.3.1.3 MeasurementID Request (TmNSmeasid)

5.2.4 Latency/Throughput Critical (LTC) Delivery Protocol

5.2.4.1 LTC Delivery Protocol Data Channel (LTCDataChannel)

5.2.4.2 LTC Delivery Protocol Control Channel (LTCControlChannel)

5.2.4.3 LTC Playback Control

5.2.5 Reliability Critical (RC) Delivery Protocol

5.2.5.1 RC Delivery Protocol Data Channel (RCDataChannel)

5.2.5.2 RC Delivery Protocol Control Channel (RCControlChannel)

5.2.6 Quality of Service (QoS)

5.2.6.1 DiffServ

5.2.6.2 DiffServ Code Point (DSCP) Assignments

5.3 Information Assurance

5.4 Voice Services

6. Notes

7. Index

See Distribution Statement C on cover page vii

List of Figures

Figure 1.1. Relationship of the TmNS Standards

Figure 1.2. TmNS Networks

Figure 1.3. Test Article Standard Protocol Map

Figure 5.1. TmNSDataMessage Overview

Figure 5.2. TmNSDataMessageHeader Field Structure

Figure 5.3. PackageHeader and PackagePayload Structure

Figure 5.4. Standard PackageHeader Field Structure

List of Tables

Table 5.1. "option-kind" Details

See Distribution Statement C on cover page 8

1. INTRODUCTION

The Telemetry Network System (TmNS) is governed by a collection of standards documents. This Test Article Standard provides a document that implementors and range users of TmNS equipment shall reference to ensure interoperability between network nodes. The standards in this document are intended to provide a set of technologies and protocols for transporting data within the TmNS. This document is not intended to provide operational details for any TmNS network node.

The Test Article Standard protocols are augmented by the management principles defined in the System Management Standard. The Test Article Standard is further augmented by the test description and configuration information used to setup the TmNS as defined in the Metadata Standard. Metadata is used by the System Management Standard for configuration of data transport information. The Test Article Standard, along with the other standards shown in Figure 1.1, provide a complete framework for a TmNS.

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

C M

P

C M

P n

Figure 1.1. Relationship of the TmNS Standards

1.1 Background

The Test Article Standards Working Group (TASWG), through the process of change proposal (CP) creation and acceptance, created this document. During the process of standardization, it was decided that the format of the original Test Article 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 TASWG documentation (presentation material, CP documents, and meeting minutes available through the TASWG web portal), constitutes all information supplementary to this standard.

See Distribution Statement C on cover page 9

1.2 Responsibility

The TASWG 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 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, the 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. The 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 the TmNS provides an interface to the gNET. The main functionality of the 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, the TmNS supports many different types of applications and Peripherals that reside outside the TmNS but have an integral role in the operation of the TmNS. System Management is used across the 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 the 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 A pplications

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 network operations within the TAS of the TmNS architecture. It encompasses the physical, electrical, protocol, and interface aspects of the Vehicle Network to ensure interoperability across the network.

https://www.inetprogram.org/�

See Distribution Statement C on cover page 10

Figure 1.3 provides an overview of the protocols specified in this standard document; the exceptions are Simple Network Management Protocol (SNMP) and Hypertext Transfer Protocol (HTTP), which are requirements placed by the System Management Standard.

Figure 1.3. Test Article Standard Protocol Map

See Distribution Statement C on cover page 11

2. APPLICABLE DOCUMENTS

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

2.1 Government Documents

2.1.1 Specifications

• NAVSTAR Global Positioning System (GPS) Interface Specification IS-GPS-200

• High Assurance Internet Protocol Encryptor (HAIPE) Interoperability Specification (IS) version 3

2.1.2 Standards

iNET Standards (version 0.8.0):

• System Management Standard

• Metadata Standard

• Component Interfaces Standard

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 802.1D-2004

• IEEE 802.2-1998

• IEEE 802.3-2005

• IEEE 802.3-2008

• IEEE 1588-2002

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

• RFC 768: User Datagram Protocol

• RFC 791: Internet Protocol: DARPA Internet Program Protocol Specification

• RFC 792: Internet Control Message Protocol

• RFC 793: Transmission Control Protocol

• RFC 826: Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet

Address for Transmission on Ethernet Hardware

• RFC 894: A Standard for the Transmission of IP Datagrams over Ethernet Networks

• RFC 919: Broadcasting Internet Datagrams

• RFC 922: Broadcasting Internet Datagrams in the Presence of Subnets

• RFC 950: Internet Standard Subnetting Procedure

See Distribution Statement C on cover page 12

• RFC 959: File Transfer Protocol (FTP)

• RFC 1034: Domain names – concepts and facilities

• RFC 1035: Domain names – implementation and specification

• RFC 1042: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks

• RFC 1122: Requirements for Internet Hosts – Communication Layers

• RFC 1123: Requirements for Internet Hosts – Application and Support

• RFC 1350: The TFTP Protocol (Revision 2)

• RFC 1812: Requirements for IP Version 4 Routers

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

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

• RFC 2131: Dynamic Host Configuration Protocol

• RFC 2326: Real Time Streaming Protocol (RTSP)

• RFC 2347: TFTP Option Extension

• RFC 2348: TFTP Blocksize Option Requests for Comments (RFCs)

• RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

• RFC 2475: An Architecture for Differentiated Services

• RFC 2581: TCP Congestion Control

• RFC 2597: Assured Forwarding of PHB (Per Hop Behavior) Group

• RFC 3140: Per Hop Behavior Identification Codes

• RFC 3246: An Expedited Forwarding PHB

• RFC 3376: Internet Group Management Protocol, Version 3

• RFC 3986: Uniform Resource Identifier (URI): Generic Syntax

• RFC 4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery

(MLD) Snooping Switches

• RFC 4594: Configuration Guidelines for DiffServ Service Classes

• RFC 4601: Protocol Independent Multicast – Sparse Mode (PIM-SM) Protocol Specification (Revised)

• RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

Telecommunications Industry Association/Electronic Industries Alliance (TIA/EIA)

• TIA/EIA-568-B.2-2001 (except where conflicting with IEEE 802.3, in which case IEEE 802.3 takes precedence).

See Distribution Statement C on cover page 13

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.

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

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.

See Distribution Statement C on cover page 14

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

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.

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 15

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 16

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 17

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 18

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 19

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 20

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 Usage of Message Fields

Names of specific fields within the TmNSDataMessage structure are indicated by an Arial font. Some field names are the same as terms defined in Section 3.1. When a statement refers to a field, the field name will adhere to this convention. It will not be italicized.

3.4.3 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.4 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.

3.5 Octet and Bit Ordering

Octet ordering is important for correct interpretation of multi-octet fields in the TmNSDataMessage. The TmNS is an Internet Protocol (IP) network and, therefore, uses the big-endian convention for octet (byte) order as specified in RFC 791. The big-endian convention states that whenever a multi-octet field represents a numeric quantity, the following order is used:

• The most significant octet is transmitted first.

• The left-most bit of the whole field is the most significant bit.

To illustrate big-endian ordering, consider a 16-bit field whose decimal value is 258, or 0x0102. This field is transmitted over the IP network in the octet order 0x01, 0x02.

TmNSDataMessageHeader and PackageHeader fields of the TmNSDataMessage specified in this document shall be treated as values rather than byte strings and, therefore, shall be transmitted in big-endian order.

PackagePayloads and fields described in MDL Instance Documents, however, are often based on acquisition data from non-IP-network systems and, therefore, are not required to comply with the big-endian convention.

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

See Distribution Statement C on cover page 21

For all figures in this document, a field containing a numeric quantity is shown with the most significant bit (MSB) on the left, unless otherwise noted. When specific bits of fields are numbered, the MSB gets the highest number, unless otherwise noted.

See Distribution Statement C on cover page 22

4. GENERAL REQUIREMENTS

4.1 General

4.1.1 Test and Operating Requirements

All requirements specified herein shall be valid over the environmental conditions in which the NetworkNodes in a Test Article Network shall be required to operate.

4.1.2 Core Technology

NetworkNodes in a Test Article Network shall use the Internet Protocol version 4 (IPv4) suite as a base technology.

Any implementation with Internet Protocol version 6 (IPv6) networks that connect to the Test Article Network shall contain external methods for handling gateway services to adapt between IPv6 and IPv4.

IPv4 security concerns are addressed in Section 5.3.

4.1.3 Defined Technology Versions

This document defines the following versions for specific technologies:

• Version “1” of TmNSDataMessage (TmNSDataMessageHeader and standard PackageHeader) – see Section 5.2.1.*.

• Version “1.0” of the TmNS_URI – see Section 5.2.3.

4.2 Physical and Electrical Characteristics

Connectors and cable media should meet the electrical or optical properties of the standards referenced herein.

However, applicability to the operational environment will place additional constraints on the selection of the connectors and cable media. A list of flight-qualified cables that have been suggested by implementers of previous networked telemetry applications is included in Section 6.

It is anticipated that future versions of this Standard will allow for other variants of Physical and Electrical protocols.

4.2.1 Ethernet

NetworkNodes in a Test Article Network shall support one or more of the bit rate and physical protocol standards specified in Sections 4.2.1.1.* through 4.2.1.4.*.

See Distribution Statement C on cover page 23

4.2.1.1 10 Mbps Ethernet

4.2.1.1.1 10BASE-T

Copper media connections using 10BASE-T Ethernet shall comply with IEEE 802.3-2005, Section 1, Clause 14.

4.2.1.1.2 10BASE-FL

Multi-mode or single-mode fiber media connections using 10BASE-FL Ethernet shall comply with IEEE 802.3- 2005, Section 1, Clause 18.

4.2.1.2 100 Mbps Ethernet

4.2.1.2.1 100BASE-TX

Copper media connections using 100BASE-TX Ethernet shall comply with IEEE 802.3-2005, Section 2, Clause 25.

4.2.1.2.2 100BASE-FX

Multi-mode fiber media connections using 100BASE-FX Ethernet shall comply with IEEE 802.3-2005, Section 2, Clause 26.

4.2.1.2.3 100BASE-LX10

Single-mode fiber media connections using 100BASE-LX10 Ethernet shall comply with IEEE 802.3-2005, Section 5, Clause 58.

4.2.1.3 Gigabit Ethernet

4.2.1.3.1 1000BASE-T

Copper media connections using 1000BASE-T Ethernet shall comply with IEEE 802.3-2005, Section 3, Clause 40.

4.2.1.3.2 1000BASE-SX

Multi-mode fiber media connections using 1000BASE-SX Ethernet shall comply with IEEE 802.3-2005, Section 3, Clause 38.

4.2.1.3.3 1000BASE-LX

Multi-mode or single-mode fiber media connections using 1000BASE-LX Ethernet shall comply with IEEE 802.3- 2005, Section 3, Clause 38.

4.2.1.4 10 Gigabit Ethernet

4.2.1.4.1 10GBASE-X/10GBASE-T

Copper media connections using 10 Gigabit Ethernet shall comply with one of the 10GBASE-X or 10GBASE-T physical standards defined in IEEE 802.3-2008.

4.2.1.4.2 10GBASE-R

Fiber media connections using 10 Gigabit Ethernet shall comply with one of the 10GBASE-R physical standards defined in IEEE 802.3-2008.

See Distribution Statement C on cover page 24

4.2.2 Auto-Negotiation

4.2.2.1 Copper Auto-Negotiation

Copper media connections, as described in the preceding sections, shall support auto-negotiation of speed, duplex, and flow control in the manner specified in IEEE 802.3-2005, Section 2, Clause 28.

4.2.2.2 Fiber Auto-Negotiation

Gigabit fiber media connections, as described in the preceding sections, should support auto-negotiation of speed, duplex, and flow control in the manner specified in IEEE 802.3-2005, Section 3, Clause 37.

4.3 Protocols

4.3.1 Core Requirements for NetworkNodes and NetworkDevices in a Test Article Network

4.3.1.1 Core Requirements for NetworkNodes in a Test Article Network

NetworkNodes in the Test Article Network with host functionality shall conform to the following standards that specify host functionality requirements:

• RFC 1122: Requirements for Internet Hosts – Communication Layers

• RFC 1123: Requirements for Internet Hosts – Application and Support

4.3.1.2 Core Requirements for NetworkDevices in a Test Article Network

NetworkDevices in the Test Article Network shall conform to the following standard that specifies routing functionality requirements:

• RFC 1812: Requirements for IP Version 4 Routers

4.3.2 Data Link Protocols

NetworkNodes in a Test Article Network shall support the Ethernet data link protocols as specified in IEEE 802.3- 2005.

4.3.2.1 Frame Structure

NetworkNodes in a Test Article Network shall support the frame structure, field definitions, and MAC conventions specified in IEEE 802.3-2005.

• Data link frames shall support 48-bit locally and universally administered addresses in a manner consistent with

IEEE.802.3-2005.

• Data link frame structures shall support type-encapsulated and length-encapsulated frames as specified in IEEE 802.3-2005.

4.3.2.2 Media Access Control (MAC)

NetworkNodes in a Test Article Network shall support the MAC protocols specified in IEEE 802.3-2005, Clauses 2, 3, and 4.

• The MAC protocols shall convey type- and length-encapsulated frames to support IP network layer protocols.

4.3.2.3 Logical Link Control (LLC)

NetworkNodes in a Test Article Network shall support the LLC protocols as specified in IEEE 802.2-1998 to the extent necessary to support IP network layer protocols.

See Distribution Statement C on cover page 25

4.3.2.4 Link Layer Switching

NetworkDevices in a Test Article Network shall conform to the requirements set forth in IEEE 802.1D-2004 for transparent bridging and Rapid Spanning Tree Protocol (RSTP) functionality.

4.3.2.5 Link Layer Flow Control

NetworkNodes in a Test Article Network that support full-duplex Ethernet shall support flow control “PAUSE” frames as specified in IEEE 802.3-2005, Clause 31.

NetworkDevices in a Test Article Network with sufficiently large queuing buffers should be chosen to handle the “burstiness” of the traffic within the latency constraints of a particular implementation.

4.3.3 Network Protocols

4.3.3.1 Internet Protocol version 4 (IPv4)

NetworkNodes in a Test Article Network shall conform to the following IPv4 core standards:

• RFC 791: Internet Protocol

• RFC 919: Broadcasting Internet Datagrams

• RFC 922: Broadcasting Internet Datagrams in the Presence of Subnets

4.3.3.2 IP Datagram Transmission

NetworkNodes in a Test Article Network shall conform to the following core standards for the transmission of IP datagrams:

• RFC 894: A Standard for the Transmission of IP Datagrams over Ethernet Networks

• RFC 1042: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks

4.3.3.3 Internet Control Message Protocol (ICMP)

NetworkNodes in a Test Article Network shall conform to the following core ICMP standard:

• RFC 792: Internet Control Message Protocol

4.3.3.4 Internet Group Management Protocol (IGMP)

NetworkNodes in a Test Article Network that consume or forward dynamically configured IPv4 multicast datagrams shall conform to the following core IGMP standard:

• RFC 3376: Internet Group Management Protocol, Version 3

The use of IP multicast between local and remote routers shall conform to the following core Protocol Independent Multicast (PIM) standard:

• RFC 4601: Protocol Independent Multicast – Sparse Mode (PIM-SM) Protocol Specification (Revised)

See Distribution Statement C on cover page 26

4.3.3.4.1 IGMP Snooping

NetworkDevices in the Test Article Network should use IGMP “snooping” as presented in:

• RFC 4541: Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches

IGMP Snooping is recommended for performance considerations in a dynamically configured IPv4 multicast environment.

4.3.4 Transport Protocols

4.3.4.1 Transmission Control Protocol (TCP)

NetworkNodes in a Test Article Network that implement TCP shall conform to the following core TCP standard:

• RFC 793: Transmission Control Protocol

NetworkNodes in a Test Article Network using TCP shall conform to the following standard for TCP congestion control mechanisms:

• RFC 2581: TCP Congestion Control

4.3.4.2 User Datagram Protocol (UDP)

NetworkNodes in a Test Article Network that implement UDP shall conform to the following core UDP standard:

• RFC 768: User Datagram Protocol

4.4 Network Services

4.4.1 Address Resolution and Configuration

4.4.1.1 Address Resolution

NetworkNodes in a Test Article Network shall conform to the following core address resolution standard:

• RFC 826: Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware

4.4.1.2 Host/Address Configuration

NetworkNodes in a Test Article Network should conform to the following addressing standard:

• RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

Although address configuration may be done manually, dynamic protocols allow devices to be added to the network with minimal or no manual configurations.

See Distribution Statement C on cover page 27

4.4.1.2.1 Static Configuration

NetworkNodes in a Test Article Network requiring IPv4 address configuration shall support static IP address assignment, conforming to the following core addressing standard:

• RFC 950: Internet Standard Subnetting Procedure

4.4.1.2.2 Dynamic Configuration

The Test Article Network shall support dynamic IP address assignment, conforming to the following standard for automatic host configuration:

• RFC 2131: Dynamic Host Configuration Protocol

The Test Article Network requires a Dynamic Host Configuration Protocol (DHCP) service, but no other NetworkNodes connected to the Test Article Network require DHCP servers or clients. This allows the choice of static or dynamic IP address assignment.

4.4.2 Name Services

NetworkNodes in a Test Article Network that use domain name labels shall conform to the following core name service standards:

• RFC 1034: Domain names – concepts and facilities

• RFC 1035: Domain names – implementation and specification

4.4.3 File Transfer

NetworkNodes in a Test Article Network that support file transfer services shall support at least one of the following protocols:

• RFC 959: File Transfer Protocol (FTP)

• RFC 1350: The TFTP Protocol (Revision 2)

The original Trivial File Transfer Protocol (TFTP) has a file size limit of 32 megabytes (MB), which may be extended by option negotiation (RFC 2347) and block-size negotiation (RFC 2348), allowing a maximum file size of 4 gigabyte (GB) and potentially higher throughput.

See Distribution Statement C on cover page 28

5. DETAILED REQUIREMENTS

5.1 Time Synchronization

5.1.1 Network Time Synchronization Interfaces

The Test Article Network shall support network time synchronization as specified in IEEE 1588-2002.

IEEE 1588-2002 is the most widely deployed version of the IEEE 1588 standard. The more recent IEEE 1588-2008 standard is not directly backward compatible with the IEEE 1588- 2002 standard.

5.1.1.1 IEEE 1588 Master Clock

NetworkNodes in a Test Article Network performing as IEEE 1588 masters shall support the master clock interface as specified in IEEE 1588-2002. IEEE 1588 master clocks shall be synchronized by an external source, as specified in Section 5.1.2. IEEE 1588 master clocks shall use the Precision Time Protocol (PTP) epoch when performing as the IEEE 1588 grandmaster clock.

Master clocks shall run freely using the last known time in the absence of an external time synchronization reference.

5.1.1.2 IEEE 1588 Slave Clock

NetworkNodes in a Test Article Network requiring time synchronization to an IEEE 1588 master clock shall support the slave clock interface as specified in IEEE 1588-2002.

Slave clocks shall continue to run freely using the last known time in the absence of a grandmaster clock on the network.

5.1.1.3 IEEE 1588 Boundary Clock

NetworkDevices in a Test Article Network that transport time synchronization data to devices requiring a high degree of synchronization shall support boundary clock techniques as specified in IEEE 1588-2002 or approaches that are interoperable with boundary clocks (e.g., transparency implementations).

5.1.1.4 One Pulse-Per-Second (1 PPS) Outputs on IEEE 1588 Devices

NetworkNodes in a Test Article Network with IEEE 1588 master or slave clocks should support external 1 PPS outputs to allow verification of time signal lock between distributed clocks within 1 microsecond.

• 1 PPS outputs should be compatible with standard transistor-transistor logic (TTL) levels.

• The rising edge of the pulse shall define the beginning of a second, and the duty cycle of the 1 PPS signal shall be between 5% and 95%.

• The pulse rise time between the 10% and 90% amplitude points shall be less than or equal to 1 microsecond.

See Distribution Statement C on cover page 29

5.1.2 External Time Synchronization Interface

IEEE 1588-2002 master clocks should synchronize with the Global Positioning System (GPS) external time reference. GPS external time reference interface shall implement the GPS RF waveform interface and GPS Space Segment/Navigation User Interface as specified in the NAVSTAR GPS Interface Specification IS-GPS-200.

Other external time synchronization interfaces may be used for implementations that do not readily accommodate a GPS external time reference.

5.2 Data Transfer

5.2.1 TmNSDataMessage Structure

EndNodes shall support the TmNSDataMessage structure as specified in Sections 5.2.1.1.* through 5.2.1.2.*. An overview of TmNSDataMessage structure is shown in Figure 5.1.

TmNSDataMessagePayloadTmNSDataMessageHeader

Package 5Package 4Package 3Package 2Package 1 Package N

Figure 5.1. TmNSDataMessage Overview

5.2.1.1 TmNSDataMessageHeader

The TmNSDataMessageHeader shall contain the fields and associated bit-widths as outlined in Figure 5.2.

Sections 5.2.1.1.1 through 5.2.1.1.9 provide the definition of each of the TmNSDataMessageHeader fields.

See Distribution Statement C on cover page 30

ApplicationDefinedFields (Optional, {OptionWordCount}*32 bits)

MessageTimestamp (64 bits)

MessageLength (32 bits)

MessageDefinitionSequenceNumber (32 bits)

32 bits

MessageDefinitionID (32 bits)

MessageFlags (16 bits)

Reserved (8 bits)

Option Word Count (4 bits)

MessageV ersion (4 bits)

Figure 5.2. TmNSDataMessageHeader Field Structure

(see Section 3.5 for bit ordering conventions)

5.2.1.1.1 MessageVersion Field (4 bits)

The MessageVersion field shall specify the version of the TmNSDataMessage protocol. This document addresses Version 1 (i.e., “0001”).

5.2.1.1.2 OptionWordCount Field (4 bits)

The OptionWordCount field shall specify the number of 32-bit words in the ApplicationDefinedFields.

5.2.1.1.3 Reserved Field (8 bits)

This field is reserved for future use.

5.2.1.1.4 MessageFlags Field (16 bits)

The MessageFlags field shall provide indicators of TmNSDataMessage options and/or conditions. Using the bit-numbering convention specified in Section 3.5, the bits are defined as follows:

• Reserved for future use (bits 15-8)

• StandardPackageHeaderFlag bit (bit 7)

• “0” – Uses a PackageHeader completely described in an MDL Instance Document (See Section 5.2.1.2.2.)

• “1” – Uses standard PackageHeaders (See Section 5.2.1.2.2.1.*.)

See Distribution Statement C on cover page 31

• PlaybackDataFlag bit (bit 6)

• “0” – Live data

• “1” – Playback data

• MessageFragmentationFlags bits (bits 5-4)

• “00” – Complete TmNSDataMessage

• “01” – First fragment of a TmNSDataMessage

• “10” – Middle fragment of a TmNSDataMessage

• “11” – Last fragment of a TmNSDataMessage

• DataSourceSimDataFlag bit (bit 3) *

• “0” – Acquired data in this TmNSDataMessage

• “1” – Simulated data in this TmNSDataMessage

• DataSourceTimeLockFlag bit (bit 2) *

• “0” – DataSource time locked to IEEE 1588 master clock

• “1” – DataSource time NOT locked to IEEE 1588 master clock

• DataSourceHealthFlag bit (bit 1) *

• “0” – No error in the portion of the DataSource generating this TmNSDataMessage

• “1” – Error in the portion of the DataSource generating this TmNSDataMessage

• EndOfDataFlag bit (bit 0)

• “0” – Normal TmNSDataMessage

• “1” – End-of-data TmNSDataMessage

* MessageFlags bits 1, 2, and 3 shall indicate conditions of the original acquisition DataSource generating TmNSDataMessages. These DataSource-specific MessageFlags provide a consolidated indicator of all data contained in the TmNSDataMessagePayload (i.e., TmNSDataMessages flagged with a condition of “simulation”, “time not locked”, or “error” notifies that one or more samples were taken during a condition of “simulation”, “time not locked”, or “error”). DataSources that combine data from multiple TmNSDataMessages into a new TmNSDataMessage shall bitwise-OR the DataSource-specific MessageFlags from the original messages to form the resultant DataSource-specific MessageFlags.

5.2.1.1.5 MessageDefinitionID Field (32 bits)

The MessageDefinitionID field shall contain the MessageDefinitionID of the TmNSDataMessage.

5.2.1.1.6 MessageDefinitionSequenceNumber Field (32 bits)

The MessageDefinitionSequenceNumber field shall provide a non-negative integer which increments by 1 for each instance of a TmNSDataMessage with this particular MessageDefinitionID, including TmNSDataMessage fragments (see MessageFragmentationFlags bits of MessageFlags field). The MessageDefinitionSequenceNumber field shall be reset to 0 upon:

• The power-up of the device generating the corresponding MessageDefinitionID.

• The configuration or re-configuration of the device generating the corresponding MessageDefinitionID.

The value of the MessageDefinitionSequenceNumber field shall wrap to 0 after 232 – 1. The wrapping of the value of the MessageDefinitionSequenceNumber field to 0 shall not indicate a loss.

See Distribution Statement C on cover page 32

TmNSDataMessages copied and sent to an additional destination address (transport) shall use the same values of the MessageDefinitionSequenceNumber field as the original TmNSDataMessages.

5.2.1.1.7 MessageLength Field (32 bits)

The MessageLength field shall provide the length (in bytes) of the TmNSDataMessage (or fragment), including the TmNSDataMessageHeader and TmNSDataMessagePayload (including padding).

“Padding” shall be used if a TmNSDataMessage does not fall on a 32-bit boundary.

5.2.1.1.8 MessageTimestamp Field (64 bits)

The MessageTimestamp field shall provide the message base time (in seconds and nanoseconds). The field shall use the IEEE 1588-2002 specified time format using the PTP epoch with a non-negative nanosecond portion.

All TmNSDataMessage fragments (see MessageFragmentationFlags bits of MessageFlags field) shall include the same value of MessageTimestamp in their TmNSDataMessageHeaders.

The value of the MessageTimestamp field of a given TmNSDataMessage shall be no earlier…