IMEA OneNet Beta Test DRAFT Standard Test … imea beta test package.pdfDRAFT Standard Test Announcement Application ... manufacturer of a product utilizing the BETA Test ... for interoperability

IMEA OneNet® Beta Test DRAFT Standard

Test Announcement Application

Documentation Package

The IMEA OneNet Standard is the property of NMEA.

20160928 BETA TEST LETTER AND CONTRACT ses _ v44 9/8282016

IMEA OneNet® Beta Test DRAFT Standard Test Announcement

and Application

On September 21, 2016 at the NMEA International Conference and Expo at Naples Grande Beach Resort in Naples Florida, during the NMEA Luncheon Meeting, NMEA’s Director of Standards and the IMEA OneNet Standards Committee announced a call for BETA Testers from any potential equipment manufacturer of a product utilizing the BETA Test Draft of the IMEA OneNet Standard.

Beta testing is a critical and comprehensive validation of the OneNet Standard. Products be developed and tested to work properly and meet the OneNet requirements. In addition, there will be Plugfests to test products for interoperability and interconnectivity. The OneNet standard contains of a number of interrelated and complex modules. For a basic description see the BETA Base Module and the BETA Device Architecture Module which are attached (See Appendix B). Feedback and input to the standard is the number one goal for the acceptance and successful launch of the OneNet Standard for all stakeholders. The IMEA OneNet Standard is the property of NMEA.

A maximum of ten (10) BETA tests slots are available for manufacturers desiring to participate as a BETA Tester. If all ten (10) slots are not filled by October 30, 2016 then we will close the call and proceed with those manufacturers that have signed on.

Objectives:

1. Functional Tests

Verifies that the standard meets its functional/feature requirements

2. Configuration Tests

Assures all functions work under the combinations within the standards


3. Fix and/or change the requirements of the standard as discovered

4. Fix and/or change the language for enhanced interpretation and clarity

Minimize ambiguity within the standard

Scope:

All requirements and functionality in the OneNet Beta Test Standard in all modules (except Gateways) are expected to be implemented within the respective product(s)

Gateways will need to fulfill all the functionalities of the Gateway module and all relevant modules

Manufacturers are expected to maintain a table of issues/questions and possible solutions during the product development phase of the Beta Test. This document will be called Beta Issue Table (BIT).

Manufacturers are expected to share this table with other Beta Test manufacturers and with NMEA.

Manufacturers may create scenarios which can help clarify the solution of an issue/question.

The BIT might result in an applications document.

Final evaluation for the “public” release of the OneNet Standard

To qualify, a company must:

Sign the NMEA Confidentiality Agreement (if not already on record)

Sign the NMEA Copyright Assignment Agreement (if not already on record)

Agree to design and develop a product utilizing the IMEA OneNet Standard

Have design engineers attend at least 2 working group meetings to be held in USA during calendar year 2017

These will essentially be for discussion to share issues found

First meeting will be held November 29, 30, 2016 at the USCG R&D Center in New London,CT.

Participate in regular Go to Meetings as determined

Attend at least 2 OneNet Beta Test Plugfests for interconnectivity and interoperability

Participate in the bulletin board, Trello

This encourages collaboration on a regular basis with all members of the Beta Test

Participate in the collaboration email application, Slack

Openly share test results with NMEA, Beta Test Members, and the NMEA OneNet Standards Committee

Not talk to the press during the Beta Test Program


May not share the Beta Test Standard with other manufacturers. If needed for product development purposes, manufacturers should contact NMEA and receive permission in writing.

Complete a short exit survey

Included in this Package

Appendix A: Beta Tester Contract

Appendix B: IMEA Base Module and IMEA Device Architecture Module

Appendix C: General IMEA Onenet Product Certification Categories

Appendix D: Plan and Timeline

Appendix E: Beta Issues Table

Time:

Applications open from October 1 to October 31, 2016. The BETA Test period will run from December 1, 2016 thru May 5, 2017. See the Plan and Timeline which is attached (See Appendix D). Actual times may be adjusted based on actual testing results and feedback.

Manufacturer Investment: To participate a manufacturer will provide an investment of $5,000 to NMEA. At the successful completion of the Beta Test, the manufacturer will be credited for this investment towards other NMEA standard’s fees. Successful completion is defined as bringing an IMEA OneNet product to market. If the manufacturer does not complete the Beta Test, or fails to bring a OneNet product to market, the manufacturer will forfeit this investment.

In addition, upon completion of the Beta Test and publication of the OneNet Standard the manufacturer will also receive the Manufacturer Incentives as listed below.

To participate, the manufacturer must complete, sign and send the BETA Test Application which is attached. (See Appendix A)

Manufacturer Incentives: NMEA will provide the following incentives:

The BETA DRAFT OneNet Standard FREE

The “PUBLISHED’ OneNet Standard FREE

The NMEA Product Code FREE

If the equipment manufacturer brings a product to market, the OneNet Product Certification will be FREE

As a participating BETA Test company, further benefits to consider include:

Being amongst the leading edge development and implementation of a new International Standard

Assisting in debugging a new product

Developing one of the earliest OneNet products in the market


Other: A tentative Product Certification list is attached (See Appendix C) This list approximates the tentative OneNet product certification generalities. This Appendix C provides a rough insight into some the technical requirements which may be part of the OneNet Product Certification Program. This listing was derived by studying the detailed requirements in the BETA Standard. The items in Appendix C are subject to change.

Contact: To become a BETA Test participant, please contact Steve Spitzer, NMEA Director of Standards. Steve Spitzer Phone: (425) 417-8042 E-mail: [email protected]


APPENDIX A

APPLICATION FOR PARTICIPATION IN

ONENET BETA DRAFT STANDARD BETA TEST PROGRAM

We have read and agree with the conditions as expressed in this three (3) page document. MANUFACTURER NAME: _________________________________________________________________ MANUFACTURER AUTHORIZED PERSON: (PRINT NAME AND TITLE) NAME: ___________________________________________________________ TITLE: ___________________________________________________________ MANUFACTURER ASSIGNED ENGINEER (S) FOR BETA TEST PROGRAM (PRINT NAME) NAME: ___________________________________________________________ NAME: ___________________________________________________________ NAME: ___________________________________________________________ MANUFACTURER AUTHORIZED PERSON: (SIGNATURE) _____________________________________________________________ DATED: ____________________________________________________ ACCEPTED BY NMEA: ________________________________________ DATED: ___________________________________________________


APPENDIX B

ONENET BETA DRAFT STANDARD BASE DOCUMENT MODULE

And DEVICE ARCHITECTURE MODULE

Confidential. Do Not Redistribute or Copy

This OneNet Standard is the property of NMEA. This is a Draft Standard and should not be construed as anything but a draft. NMEA has provided this draft as a working document to the person who has signed the NMEA Non-Disclosure Agreement (NDA) and the NMEA Copyright Assignment Agreement (CAA). This Draft Standard shall not be copied. The Draft Standard shall not be redistributed. This Draft Standard shall not be used for any product development. NMEA has provided this Draft Standard as a Working Document ONLY to solicit technical input from the individuals who have signed the NDA and CAA for the purpose of technical improvements if required. NMEA develops its Standards on a consensus basis and will abide by its ANSI’s Policy and Procedures.

NATIONAL MARINE ELECTRONICS ASSOCIATION

INTERNATIONAL MARINE ELECTRONICS ALLIANCE

IMEA OneNet® Standard

for

IP Networking of Marine Electronic Devices

IMEA OneNet Base Module Version 0.013 October 2016

Trademark References:

IMEA OneNet – is a Registered Trademark of the National Marine Electronics Association, Inc. NMEA 2000 – is a Registered Trademark of the National Marine Electronics Association, Inc. NMEA - is a Registered Trademark of the National Marine Electronics Alliance, Inc. IMEA – is a Registered Trademark of the International Marine Electronics Alliance, Inc.

Copyright NMEA 2016

Copyright IMEA 2016

IMEA One Net Standard and all modules related to IMEA OneNet are the property of NMEA.


This IMEA OneNet Standard is the property of NMEA. This is a BETA TEST Draft Standard and should not be construed as anything but a draft. NMEA has provided this draft as a working document to the person who has signed the Beta Test Contract, NMEA Non-Disclosure Agreement (NDA) and the NMEA Copyright Assignment Agreement (CAA). This Draft Standard shall not be copied. The Draft Standard shall not be redistributed. This Draft Standard shall be used for any product development for BETA Testing purposes only. NMEA has provided this Draft Standard as a Working Document ONLY to solicit technical input from the individuals who have signed the NDA and CAA for the purpose of technical improvements if required. NMEA develops its Standards on a consensus basis and will abide by its ANSI’s Policy and Procedures.

2



3

TABLE OF CONTENTS

1 INTRODUCTION ..................................................................................................................................................... 4

1.1 ONENET GOALS ............................................................................................................................................... 5

1.2 KEY BENEFITS ................................................................................................................................................. 5

2 ORGANIZATION OF THE STANDARD ...................................................................................................................... 5

2.1 REQUIREMENTS TERMINOLOGY ....................................................................................................................... 8

3 DEFINITIONS ......................................................................................................................................................... 8

4 REVISION HISTORY ............................................................................................................................................. 10

TABLE OF FIGURES

FIGURE 1: ONENET EDITIONS .................................................................................................................................. 6



4

1 Introduction 1

The need exists for standardized data communications between various electronic devices onboard vessels 2 which will enhance communications for safety aboard vessels. This IMEA OneNet® standard was created 3 by an international consortium of marine electronic manufacturers, government and private industries, and 4 the IMEA OneNet Standard Committee. It represents the natural technological evolution of marine 5 interface standards from NMEA 0183 to NMEA 2000 to NMEA OneNet. This standard is maintained by 6 the IMEA OneNet Standard Committee and interested marine electronics manufacturers, expert groups like 7 the United States Coast Guard, and other interested organizations for the primary purpose of boating safety. 8 NMEA 0183 (IEC 61162-1) provides serial-data distribution from a single transmitter to multiple receivers. 9 NMEA 2000 (IEC 61162-3) is Controller Area Network (CAN) based open real-time deterministic CAN 10 networking standard for the maritime industry. 11

The OneNet Standard for IP Networking of Marine Electronic Devices Network Standard is an open 12 industry standard based upon Internet Version IPv6 and the IEEE 802.3 Ethernet Local Area Network. 13 OneNet provides a common network infrastructure for marine devices and/or services on IPv6. All OneNet 14 application protocols, such as PGN Messages, are designed to use a standard IPv6 network protocol stack. 15 This allows OneNet to coexist with other protocols and services that operate in parallel on the same network 16 (including other marine standards such as IEC 61162-450). 17

Finally, the standard also specifies mechanisms for connecting NMEA OneNet networks, NMEA 2000 18 networks, and other networks via gateway devices. 19



5

1.1 OneNet Goals 20

To specify the transport of NMEA PGN Network Messages over IPv6 21

To utilize standard IP network and addressing infrastructure 22

To facilitate the safe and secure communication and operations among equipment 23

To co-exist with other IP protocols / services on the same cable 24

To discover devices and services automatically to create an extendible and scalable network 25 architecture 26

To define an open interface to interoperate with current and upcoming open services 27

To deliver interoperability with the established industry standards including NMEA 2000 (i.e., 28 establishing gateway rules between NMEA 2000 and OneNet and other protocols) 29

To support high-bandwidth applications such as audio/video data transport 30

1.2 Key Benefits 31

Standardized architecture. Transport of NMEA PGN Network Messages as well as other 32 protocols over IPv6-based networks (this aligns with M2M, IoT industry trends). 33

Greater bandwidth. With a range of 100 Megabit to 10 Gigabit transfer speeds directly to OneNet 34 Devices, Ethernet is about 400 to 40,000 times faster than NMEA 2000. 35

Much greater number of potential devices (addresses). NMEA OneNet allows larger and more 36 complex networks to be created than can be achieved with the 252 address limitation on NMEA 37 2000. NMEA OneNet contains PGN Virtual Devices that communicate on the network through a 38 single OneNet Device. 39

Greater power capacity. With Power over Ethernet (PoE), each Physical Device may be 40 separately powered up to 25.5 Watts directly from the Ethernet Switch.(Refer to IEE 802.3at) 41

Ubiquitous technology. Ethernet is used everywhere in homes, offices and industrial 42 environments and is well understood. Many marine electronic products already implement and 43 support Ethernet. 44

2 Organization of the Standard 45

OneNet contains separate but interrelated documents called “modules.” Each module defines minimum 46 requirements and identifies specific capabilities for product development. Normative and informative 47 references are included in each module as appropriate. The complete set of the modules constitutes an 48 Edition. The OneNet Standard, as a whole, will have its own Edition Number. Each individual module 49 will also have its own version number and change history. Any change in a module will effect a change in 50 its version number as well as in the Edition Number (See Figure 1: OneNet EditionsFigure 1 below). 51



6

52

Figure 1: OneNet Editions 53

Any device that a manufacturer desires to be OneNet Certified must adhere to the requirements within the 54 modules of this edition through validation by NMEA or IMEA. 55

For this edition of OneNet, the current modules are as follows: 56

“OneNet Base Module” – provides context for the OneNet standard, defines the basic scope, and 57 explains requirement terminology used throughout all of OneNet Standard modules. Lastly, the Base 58 Module will also contain all definitions for all of the OneNet Standard modules. 59

“OneNet Device Architecture Module” – introduces the components that comprise a OneNet Device, 60 explains how they are related to each other, and lists the module where the component is described in 61 detail. Also contains requirements for the network protocol stack that each OneNet Device must use 62 to communicate on a OneNet network. 63

“OneNet Physical Layer Module” – includes the environmental considerations, EMI, Auto-64 negotiation, MDIX and signaling rates. This module provides a recommendation for a standard 65 connector on the device. 66

“OneNet Discovery Module” – identifies OneNet discovery of devices, applications and services on 67 the OneNet Network. Discovery provides clients on a local area network with an extendable way to 68 learn what OneNet Devices are present on a network, what each device is, and what its capabilities and 69 services are. Discovery is built on top of the widely adopted protocols mDNS (RFC 6762 Multicast 70 DNS), DNS-SD (RFC 6763 DNS-Based Service Discovery), HTTP (RFC 2616 Hypertext Transfer 71 Protocol), and JSON (RFC 7159 JavaScript Object Notation). 72

“OneNet Application Information Service Module” – This module describes a service, the OneNet 73 Application Information Service, which provides information about a OneNet Application including 74 product name, NMEA product code, model, NMEA manufacturer code, manufacturer name, serial 75 number, and other metadata. 76

“OneNet Datagram Protocol Module” – is built on top of IP's User Datagram Protocol (UDP), but 77 defines the extension header mechanisms needed to support security and the PGN transport. 78

One

Net

Sta

ndar

d E

diti

on x

xx

OneNet Module Version xxx





7

“OneNet PGN Transport Module” – specifies the minimum requirements for implementing NMEA 79 Parameter Group Messages identified by their Parameter Group Number (PGN). These requirements 80 include the IPv6 PGN extension header, utilizing discovery services with the NMEA NAME, 81 application of the ISO Address Claim PGN (NMEA NAME), and minimum required PGNs. 82

“OneNet Application Security Module” – describes the security model used in OneNet and the 83 protocols needed for OneNet Applications to operate within that model. By default, OneNet 84 Applications operate in an insecure state. The user may transition them into a secure state, known as 85 Secure Mode. Once in Secure Mode, Applications are in possession of a Master Key, which is then 86 used by other modules to authenticate and encrypt network communications. 87

“OneNet Datagram Security Module” – describes how Datagram Services operating in Secure Mode 88 safeguard the datagrams they send using authenticated encryption. The Master Key is used to establish 89 secure relationships between Datagram Services, known as Security Associations. All datagrams are 90 encrypted and transmitted within the context of a Security Association. 91

“OneNet Gateway Module” – A OneNet certified gateway will need to meet the requirements in the 92 following modules “Datagram, “Discovery”, “Gateway” “PGN Transport”, “Physical”, “ “Datagram 93 Security”, “Certification and Test” and “Certification Verification”. Gateways connected to OneNet 94 convert data bi-directionally to and from the OneNet protocol format with other protocols, such as 95 NMEA 2000. 96

“OneNet Certification Verification Module” – describes how a Public-Key Infrastructure is used to 97 verify the certification status of OneNet Applications. It contains requirements for storing and 98 distributing a digital certificate issued as part of the certification process, as well as requirements for 99 retrieving certificates from other Devices or Applications and reporting on their certification status. 100

“OneNet Certification and Test Module” – contains test method documentation and required results 101 for certifying OneNet Devices. In future versions, OneNet certification may include requirements from 102 other modules than those in this version. 103

Future versions of this standard may resolve outstanding issues or integrate other technologies. Additional 104 modules will be created and published to meet technology innovations and continual changing needs of the 105 market. Topics may include: 106

Functionality to deliver data to remote devices (WAN connectivity) 107

OneNet switches, including power and protocol 108

OneNet Application configuration through web pages 109

Redundant implementation of OneNet networks 110

Wireless connectivity 111

The OneNet standard utilizes the PGN Messages documented in the NMEA PGN Network Message 112 Database. It is not the intention of the IMEA OneNet Standard Committee that the reader possess either a 113 full copy or any prior knowledge of the NMEA 2000 standard. To that end, certain aspects of NMEA 2000 114 operation are described in the OneNet documents. 115



8

2.1 Requirements Terminology 116

The keywords "MAY", "MUST", "OPTIONAL”, "RECOMMENDED, "REQUIRED", "SHALL", 117

"SHALL NOT", and "SHOULD" are to be interpreted as follows in all modules of the NMEA OneNet 118

Standard: 119

May. The OneNet standard observes the following convention for use of the word “may” related 120 to OneNet requirements: Alternatives and optional items that are allowed in a OneNet Device. 121

Must. The OneNet standard observes the following convention for use of the word “must” related 122 to OneNet requirements: Items that are required in the device. 123

Optional. The OneNet standard observes the following convention for use of the word “optional” 124 related to OneNet requirements: Alternative items that are allowed in an NMEA device. 125

Recommended. The OneNet standard observes the following convention for use of the word 126 “recommended” related to OneNet requirements: A suggestion that if followed could ease 127 development or improve the operation of the device in some manner. 128

Required. The OneNet standard observes the following convention for use of the word “required” 129 related to OneNet requirements: Items that are mandatory in the device. 130

Shall. The OneNet standard observes the following convention for use of the word “shall” relate 131 to OneNet requirements: Items that are mandatory in the device. 132

Shall not. The OneNet standard observes the following convention for use of the words “shall 133 not” related to OneNet requirements: Items that are prohibited in the device. 134

Should. The OneNet standard observes the following convention for use of the word “should” 135 related to OneNet requirements: A suggestion that if followed could ease development or improve 136 the operation of the device in some manner. 137

An implementation is not compliant if it fails to satisfy one or more of the MUST, REQUIRED or SHALL 138 or SHALL NOT level requirements for the protocols it implements. 139

3 Definitions 140

CAN (Controller Area Network) - A Controller Area Network (CAN bus) is a vehicle bus 141 standard designed to allow microcontrollers and devices to communicate directly with each other. 142 It is a message-based protocol, designed originally in 1983 at Robert Bosch GmbH. 143

Headless Device - A OneNet Application that does not possess the capabilities of a Human 144 Interface Device. 145

Human Interface Device (HID) - A OneNet Application that provides the combined capability of 146 accepting basic user input and presenting non-rudimentary output. 147

NMEA NAME - A unique 64-bit entity that identifies a specific instance of a PGN Virtual Device 148 on NMEA OneNet or a NMEA 2000 Virtual Device on NMEA 2000 networks. It contains 149 information regarding the manufacturer, the device function, and the instance of that function on a 150



9

given network. Instance fields of the NMEA NAME may be programmed by the installer of the 151 equipment. The NMEA NAME is described fully in the PGN Transport Module. 152

OneNet Application - Software that satisfies the requirements documented in these OneNet 153 modules: 154

Device Architecture 155 Discovery 156 Application Information 157 Datagram Service 158 PGN Transport 159 Application Security 160 Datagram Security 161 Certification Verification 162 Certification and Test 163

This could be an application on a general-purpose computing device or software on an embedded 164 system. 165

OneNet Datagram Service - A function of the OneNet Application which implements the OneNet 166 Datagram Protocol Module. A OneNet Application may contain multiple independent OneNet 167 Datagram Services. 168

OneNet Device - A physical device that executes at least one NMEA-certified OneNet Application. 169

OneNet Network - Two or more OneNet Devices connected via Internet Protocol, Version 6 170 (IPv6). 171

PGN - Abbreviation for Parameter Group Number. Identifies a specific PGN Message. 172

PGN Message - A single packet message as specified in IPv6 that contains the Parameter Group 173 information to be communicated from a Network Address. The message contains a message 174 priority code, a Parameter Group Number, a destination Network Address, a source Network 175 Address, and data fields. The destination Network Address may be a specific unicast or multicast 176 (Refer to the NMEA PGN Network Message Database). 177

PGN Virtual Device - A PGN Virtual Device is a OneNet Datagram Service that implements the 178 PGN Transport Module. A OneNet Application may contain multiple independent PGN Virtual 179 Devices. PGN Virtual Device functionality is identified by the Product Class and Function codes 180 in the NAME field of the Address Claim PGN. 181



10

4 Revision History 182

Date Section Description

183 End of the Base Document 184



NATIONAL MARINE ELECTRONICS ASSOCIATION

INTERNATIONAL MARINE ELECTRONICS ALLIANCE

IMEA OneNet® Standard

for

IP Networking of Marine Electronic Devices

IMEA OneNet Device Architecture Version 0.003 October 2016

Trademark References: IMEA OneNet – is a Registered Trademark of the National Marine Electronics Association, Inc. NMEA 2000 – is a Registered Trademark of the National Marine Electronics Association, Inc. NMEA - is a Registered Trademark of the National Marine Electronics Alliance, Inc. IMEA – is a Registered Trademark of the International Marine Electronics Alliance, Inc. Copyright NMEA 2016 Copyright IMEA 2016



2

TABLE OF CONTENTS

REFERENCES ........................................................................................................................................................ 3

1.1 NORMATIVE REFERENCES ................................................................................................................................... 3

1.2 INFORMATIVE REFERENCES ................................................................................................................................ 3

SCOPE .................................................................................................................................................................... 3

ONENET DEVICE ARCHITECTURE .................................................................................................................. 3

NETWORK PROTOCOL STACK ......................................................................................................................... 6

4.1 DATA LINK LAYER .............................................................................................................................................. 6

4.2 NETWORK LAYER ............................................................................................................................................... 6

IPV6 LINK-LOCAL ADDRESSING ................................................................................................................ 6

IPV6 GLOBAL ADDRESSES ......................................................................................................................... 6

4.3 TRANSPORT LAYER ............................................................................................................................................. 6

REVISION HISTORY ............................................................................................................................................ 7

TABLE OF FIGURES

FIGURE 1: ONENET DEVICE ARCHITECTURE ..................................................................................................................... 5



3

References 1

1.1 Normative References 2

IEEE Standard for Ethernet (IEEE Std. 802.3) 3

IEEE 802.1Q-2011: Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks 4

RFC 768: User Datagram Protocol 5

RFC 793: Transmission Control Protocol 6

RFC 2460: Internet Protocol, Version 6 (IPv6) Specification 7

RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 8

RFC 4291: IP Version 6 Addressing Architecture 9

RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 10 Specification 11

RFC 4861: Neighbor Discovery for IP version 6 (IPv6) 12

RFC 4862: IPv6 Stateless Address Autoconfiguration 13

1.2 Informative References 14

RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 15

Scope 16

OneNet Devices consist of several components that coordinate to provide all required functionality. This 17 module introduces each of these components, explains how they are related to each other, and lists the module 18 where the component is described in detail. It also contains requirements for the network protocol stack that 19 each OneNet Device must use to communicate on a OneNet network. 20

OneNet Device Architecture 21

OneNet Devices are composed of a series of interrelated elements. The predominant element of a OneNet 22 Device is the OneNet Application. The OneNet Application is a software process that both satisfies the 23 requirements put forth in the OneNet standard and provides some domain-specific functionality for the user. 24 The exact relationship between the OneNet Device and the OneNet Application depends on the nature of the 25 OneNet Device. Certain OneNet Devices are dedicated for maritime use and in most cases these will contain 26 a single OneNet Application. Other OneNet Devices are general-purpose computing platforms that may 27 execute one or more OneNet Applications in parallel with general-purpose software applications. 28

Both designs require the OneNet Application to interact with a network protocol stack (see §4 of this module) 29 and an mDNS service (described in the Discovery module). These components may be provided by a host 30



4

operating system, by third-party software integrated into the OneNet Device, or embedded into OneNet 31 Application firmware (again, depending on the nature of the OneNet Device). 32

In addition, OneNet Applications must provide several services that communicate through an HTTP 33 connection: 34

Application Information Service (see the module of the same name) 35

Certification Service (see the Certification Verification module) 36

Key Service (see the Application Security module) 37

Session Key Service (see the Datagram Security module) 38

The first two services provide metadata about the OneNet Application and the second two help facilitate the 39 secure communication of application data. 40

Finally, each OneNet Application contains one or more Datagram Services that are responsible for 41 transmitting and receiving application data (see the Datagram Service module). Each Datagram Service has 42 its own ephemeral UDP port to send & receive unicast messages and send multicast messages. All Datagram 43 Services share IANA-assigned UDP port 10111 to receive multicast messages. 44

The only Datagram Service currently supported is the PGN Virtual Device, which sends application data 45 formatted as PGN Messages (see the PGN Transport module). Future versions of standard may define 46 additional Datagram Service types. 47

Note: The formats of all PGN Messages are documented in the NMEA PGN Network Message Database. 48 Within this database each message is assigned a Destination. Messages marked as “Global” are sent as 49 multicast messages on OneNet. Messages marked as “Address” (as in “addressable”) may be sent either as 50 unicast or multicast (see the PGN Transport module for more detail). 51

The various components that comprise a OneNet Device are summarized in Figure 1(below) 52



5

53

Figure 1: OneNet Device Architecture 54

mDNS Service

OS

PGN Virtual Device 01

Application Information Service

HT

TP

OneNet Application nn

●●●

OneNet Application 02

OneNet Application 01

Network Protocol Stack

OneNet Device

UDP Port 10111 UDP Port n1

PGN Virtual Device 02 UDP Port 10111 UDP Port n2

PGN Virtual Device nn UDP Port 10111 UDP Port nn

Other Datagram Service UDP Port 10111 UDP Port xx

UDP Port 5353

TCP Port m1 Certification Service

Key Service

Session Key Service HT

TP

S

TCP Port m2

●●●

Key

UDP Port n1 – Ephemeral UDP port assigned by IPv6 stack

TCP Port m1 – Ephemeral TCP port assigned by IPv6 stack

UDP Port 5353 – Multicast UDP port specified by RFC 6762

UDP Port 10111 – Multicast UDP port assigned by IANA



6

Network Protocol Stack 55

OneNet Applications shall utilize a network protocol stack to facilitate communication with the network. This 56 section documents requirements for each layer of the protocol stack. 57

4.1 Data Link Layer 58

All OneNet communications shall use 802.3 Ethernet frames. In addition, Devices shall support receiving 59 Ethernet frames with IEEE 802.1Q tags. 60

4.2 Network Layer 61

The network layer of the protocol stack shall support the following functionality: 62

Internet Protocol Version 6 (IPv6) as described in RFC 2460 63

ICMPv6 Echo Request and Echo Reply as described in RFC 4443 64

Link-Local Addressing as described in RFC 4291 65

Neighbor Discovery as described in RFC 4861 66

IPv6 Stateless Address Autoconfiguration as described in RFC 4862 67

Duplicate Address Detection as described in RFC 4862 68

Multicast Listener Discovery Version 2 (MLDv2) as described in RFC 3810 69

IPv6 Link-Local Addressing 70

All OneNet Devices shall have at least one IPv6 Link-Local address as described in RFC 4291. This address 71 shall be configured with IPv6 Stateless Autoconfiguration and Duplicate Address Detection as described in 72 RFC 4862. 73

OneNet Applications shall use the Link-Local address for all OneNet communications. 74

IPv6 Global Addresses 75

If the local network contains an IPv6 router or DHCPv6 server then it is possible that one or more global 76 unicast addresses (as defined by RFC 4291 §2.4) may be assigned to the OneNet Device. OneNet Applications 77 must remain operable in this occurrence but are otherwise not required to support global unicast addresses. 78

4.3 Transport Layer 79

The protocol stack shall provide the following transport layer protocols: 80

User Datagram Protocol (UDP) as described in RFC 768 81

Transmission Control Protocol (TCP) as described in RFC 793 82



7

Revision History 83

Date Section Description

84

End of the Device Architecture Module 85


APPENDIX C

ONENET BETA TEST GENERAL ONENET PRODUCT CERTIFICATION CATEGORIES

TENTATIVE LIST

Certification Configuration Information

Model Number Description NMEA OneNet Edition Number NMEA OneNet Modules Versions NMEA Device Class & Function Code Database Version NMEA PGN Message Database Version PGN Virtual Device NMEA PGN Messages Transmitted Proprietary Message Certification Custom PGN Settings (When Different than Default Settings) Enhanced Features or Capabilities

Physical Layer Environmental Extended Storage Temperature Radio Frequency Interference Unwanted EMI Immunity to Electromagnetic Environment Power over Ethernet (PoE) External Power Standalone switches shall provide PoE capability Embedded Switch PoE OneNet Physical Device Connector Requirements Alternative Connector

o Connector Documentation o Auto_MDIX o Fiber Optic Connecor o Signaling Rate

Discovery Responder Application ID DNS-SD Service Instance Name Services

Application Information Application Information Service

Datagram Protocol Multicast Listener Socket Ephemeral Port

o Multicast Messages o Unicast Messages

Publishing through OneNet Discovery OneNet Fixed Datagram Header


OneNet Extension Header PGN Transport

Datagram Protocol Compliance PGN Virtual Device Class and Function PGN Extension Header

o PGN Number o PGN DB Version o PGN Sequence Number o PGN Priority o PGN Reserved

NMEA NAME o Encoding NAME for Discovery

PGN Transport Protocol NAME Implementation o Unique Number o Manufacturer Code o Device Instance o Device Function o Reserved o Device Class o System Instance o Industry Group o Reserved Field o Field Programmability of the NAME Instance Fields. o Non-Volatile Memory

PGN Transport Requirement Destination Address o Multicast Message Request o Unicast Message Request

Required OneNet PGN Virtual Device Messages o Multicast Address Claim Request o Unicast Address Claim Request

OneNet PGN Virtual Device Proprietary Messages o Proprietary format o Proprietary Certification o Proprietary Messages 8 Bytes or Less o Proprietary Messages 9 Bytes of More

Address to NAME Association Presence Announcement

o Response to Request o Requesting NAME – Initial Multicast Request o Requesting NAME – Subsequent Unicast Request o Presence Announcement Process Restart

Application Security o OneNet Application Requirements o Master Key o OneNet Key Service o Enabling Secure Mode o Disabling Secure Mode on a HID o Disabling Secure Mode on the Network o Forcing Secure Mode to be Disabled on Headless Devices

Datagram Security


Application Requirement Security Associations

o Creation o Transition

OneNet Session Key Service OneNet Message Encryption and Decryption Encryption Decryption ESP Message Format

Gateway Gateway between NMEA 2000 and OneNet NMEA 2000 Virtual/PGN Virtual Creation

o OneNet Discovery and NMEA 2000 Virtual Device Creation o NMEA 2000 address claim and PGN Virtual Device Creation

PGN Translation Requirements o Rules for Broadcast PGN Conversion o Rules for Destination Address PGN Conversion o Fast Packet on NMEA 2000 o Transport Protocol on NMEA 2000

Field Configurable Capability Buffering Gateway between NMEA 0183 and OneNet

Certification Verification o OneNet Application Requirements


2016 2017Sep Oct Nov Dec 2017 Feb Mar Apr May Jun

Survey DueJun 8

Announce Beta Test ProgramSep 21

Beta Applications BeginSep 22

Beta Applications EndOct 30

Beta Standard Sent Nov 4

First Meeting of Applicants Nov 29

2nd Meeting if requiredJan 27

1st Plug FestApr 7

2nd Plug FestMay 4

End of Beta TestMay 5

EvaluationMay 5

Publish OneNet Standard

Jun 15

Sep 22 - Oct 30Beta Test Applications

Nov 4 - Nov 6Meeting Notice to Applicants

Nov 29 - Nov 301st Beta Test Meeeting

Jan 23 - Jan 272nd Beta Test Meeting (if required)

Apr 4 - Apr 71st Physical PlugFest

May 1 - May 52nd Physical PlugFest with Certification Verification

May 7 - May 26Fix and/or ChangeOneNet Standard

Jun 1 - Jun 7Send Survey

Appendix DOneNet Beta Test Timeline

September 21, 2016 to

June 15, 2017Note: This timeline is subject to change based on a number of factors including, participant input, meeting requirements and Plug Fest evaluations.


Milestone(s)

Date Description

09/21/2016 Announce Beta Test Program

09/22/2016 Beta Applications Begin

10/30/2016 Beta Applications End

11/04/2016 Beta Standard Sent

11/29/2016 First Meeting of Applicants

01/27/2017 2nd Meeting if required

04/07/2017 1st Plug Fest

05/04/2017 2nd Plug Fest

05/05/2017 End of Beta Test

05/05/2017 Evaluation

06/08/2017 Survey Due

06/15/2017 Publish OneNet Standard

Task(s)

Duration Start Date End Date Description

39 09/22/2016 10/30/2016 Beta Test Applications

3 11/04/2016 11/06/2016 Meeting Notice to Applicants

2 11/29/2016 11/30/2016 1st Beta Test Meeeting

5 01/23/2017 01/27/2017 2nd Beta Test Meeting (if required)

4 04/04/2017 04/07/2017 1st Physical PlugFest

5 05/01/2017 05/05/2017 2nd Physical PlugFest with Certification Verification

20 05/07/2017 05/26/2017 Fix and/or ChangeOneNet Standard

7 06/01/2017 06/07/2017 Send Survey

Appendix D OneNet Beta Test Timeline


APPENDIX E

ONENET BETA TEST BETA ISSUES TABLE

(BIT) TENTATIVE LIST

MANUFACTUTER: COMMENT ENTERED

BY: DATE ENTERED: ISSUE: SECTION NAME

LINE NUMBER PROPOSED SOLUTION

Documents

IMEA OneNet Beta Test DRAFT Standard Test … imea beta test package.pdfDRAFT Standard Test Announcement Application ... manufacturer of a product utilizing the BETA Test ... for interoperability