Reliable Binary Wire Protocol

This section describes carrying OpenLCB™ across a transport mechanism that is reliable (all bytes are guaranteed to arrive in their original order) and can carry binary bytes.

Examples of this include:

Reliable binary links can carry the full OpenLCB protocol. Messages are carried in full common format.

The reliable binary wire protocol is meant to attach multiple segments of the entire OpenLCB instance. Using this protocol, messages can be moved from one gateway to another, where one or more additional OpenLCB nodes can be reached through the gateway(s).

It is meant for applications from attaching a single remote console to interconnecting large modular layouts totaling 500 or more segments and 10's of thousands of devices. As such, it must have no addressing limitations beyond those built into the OpenLCB common message format and node serial number format.

This wire protocol makes no assumptions about the available bandwidth. In particular, it must work, with perhaps limited effectiveness, when the link bandwidth is small compared to the capacity on the other side of the gateways.

No assumption is made that this wire protocol is being used over point-to-point connections. Broadcast and multicast connections between nodes via this protocol are also permitted.

Message Form

Individual messages are preceded by a preamble that contains:

Format and protocol for other messages

Monitoring of other protocols

There's a need to be able to pass non-common OpenLCB messages over binary links. For example, a CAN-Ethernet bridge may want to pass CAN frames through to the Ethernet unchanged for monitoring purposes. This includes both the CAN frame(s) that correspond to OpenLCB common messages, and also other frames that are used for alias reservation, etc.

Gateway-Gateway Messages

The TCP/IP gateway to gateway links effectively partition the overall OpenLCB into smaller "segments". OpenLCB nodes in any of these must be able to communicate with each other via any OpenLCB common message, including over intermediate wire-protocols that differ.

Gateway-to-gateway messages (will be) defined for control operations to make this communication transparent. These messages are used to carry information between gateways on a link, and do not propagate beyond that.

Control of gateway nodes is done via direct messages to those nodes.

Note that these are not available on e.g. CAN links.

Possible uses:

Control messages to individual nodes, not gateway-gateway communication, will be used for:

(More needed here, most likely)


Section contains work in progress, notes-to-self, and background information.

Relationship with Ethernet Connections

Imagine you have five OpenLCB CAN segments, connected by small boxes to an Ethernet: You can use an Ethernet-specific protocol (e.g. ala Ethertalk, etc), or you can use IP connections (probably TCP/IP).

The TCP/IP solution seems to require more overhead, but it works about the same on a single Ethernet segment and across multiple segments, wide area links, etc.

The Ethernet-protocol solution seems somewhat simpler (though getting a protocol certified is a lot of work), but can't get traffic off the local Ethernet segment. It spans hubs, but not switches, and would require another protocol for OpenLCB-specific devices to connect to the larger Internet. So although an Ethernet-specific protocol seems simpler to create, in practice you'd still need to create Ethernet to Internet routers, resulting in an overall increase in engineering effort.

Where Ethernet-specific protocol might be useful is in reducing the configuration load for single-segment implementations. It would be nice if people could plug e.g. five OpenLCB CAN-Ethernet adapters into a single Ethernet and have them find and configure themselves to interconnect. This doesn't require new OpenLCB-specific protocols; it's much more likely that a robust solution could be created using e.g. Bonjour (a form of ZeroConf) and similar standard protocols. Some recommendations here would improve interoperability of implementing devices.

These ideas are being developed in another document.

1. General review of Networking, this page describes Network Broadcasting and Multicasting.

Site hosted by

This is SVN $Revision: 1850 $