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:
TCP/IP point-to-point links
High-bandwidth wireless links
Program-to-program links within computers
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.
Individual messages are preceded by a preamble that contains:
Originating gateway Node ID – the Node ID of the gateway that send/forwarded this message onto the point-to-point or multicast link. May or may not be the original source of the message.
Message capture time at originating gateway - a 64-bit number of monotonic milliseconds since (before) the connection was created; no time synchronization with other nodes implied; could have been a sequence number
Flags - 16 bit quantity, the most-significant 15 bits are reserved. The least significant bit indicates whether the remaining message is a common OpenLCB message or some other message.
Remaining message length in bytes
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.
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:
Redirecting point-to-point links: “I'm going offline now, you should connect to him”
Negotiating buffer sizes and traffic levels; flow control.
Control messages to individual nodes, not gateway-gateway communication, will be used for:
Turning filtering on and off in gateways so that all messages can be forwarded
Turning gateway message logging on and off
Retrieving status and history information
(More needed here, most likely)
Section contains work in progress, notes-to-self, and background information.
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.
References:
1. General review of Networking, this page
describes Network Broadcasting and Multicasting.
http://www.comptechdoc.org/independent/networking/guide/netbroadcasting.html
Site hosted by
This is SVN $Revision: 1850 $