OpenLCB Example: CAN/TCP/CAN/TCP Communication

Consider a OpenLCB installation with two CAN segments A and B connected via gateways and a TCP/IP link. In addition, a program is attached via a TCP/IP link and additional gateway to CAN segment B.

It's required that the program be able to fully communicate with all OpenLCB nodes on both segments A and B. This example shows how the gateways can do that. The first section is for "transparent" gateways, that forward all traffic back and forth doing only the necessary translation. The second section includes "firewall" gateways, that only transfer needed traffic.

For simplicity, we'll use the labels on the figure as if they were the full NID of the node, e.g. "GB1" for the left gateway on segment B. Frames and messages are represented by [“source address”, “content”, “optional destination address”] triplets

Transparent Case

Both segments come up, assign the numbers 1,2,3 as aliases to their local nodes, 10 to gateway GA and 20 to gateway GB1 on segment B. The gateways have learned these for the nodes on their local segment, but don't know anything else.

P1 wants to ensure B1 is reachable, so sends a packet with ["P1","Verify B1", global]. This goes to GB2.

GB2 assigns "50" as the local alias for P1. Since this is the first time that traffic from P1/50 is being sent on the CAN segment, GB2 sends ["50","Alias Map Definition (AMD)", "P1"]. It can then forward the Verify message as ["50","Verify B1", global] on CAN B.

GB1 notices that "50" now exists from the AMD frame and marks it as locally present with full NID "P1".

GB1 gets the Verify message, forwards it to GA1 and CAN segment A as ["P1","Verify B1", global] where it transmitted but causes no reaction.

B1 sees the Verify message for "B1", replies with a ["1", "Verified B1", global]

GB2 maps "1" back to "B1" and forwards the message to P1 as ["B1", "Verified B1", global].

P1 receives the Verified message, and has located B1.

GB1 sees the Verified message and updates its routing maps to indicate that B1 is present on this segment if that's not already known. It then forwards the Verified message to GA1, and hence on to CAN segment A.



Next, P1 wants to ensure A2 is reachable, so sends a packet with ["P1","Verify A2", global] which goes to GB2.

GB2 sends ["50","Verify A2", global] on CAN B.

GB1 gets the Verify message, forwards it to GA1 as ["P1","Verify A2", global]. (In this part of the example, P1 is already known on segment A, due to the previous interactions)

GA1 forwards the Verify message using the known alias for P1: ["61","Verify A2", global].

A2 sees the Verify message for "A2", replies with a ["2", "Verified A2", global].

GA1 maps "2" back to "A2" and forwards the message to GB1 as ["A2", "Verified A2", global].

GB1 assigns "51" as the local alias for A2. Since this is the first time that traffic from A2/51 is being sent on the CAN segment, GB1 sends ["51", "AMD", "A2"] and then sends ["51", "Verified A2", "global"] on CAN B.

GB2 sees the AMD updates its routing tables for A2.

GB2 sees the Verified message as coming from this link, so translates it and sends it to P1.

Gated Exchange of Events Case

Both segments come up, assign the numbers 1,2,3 as aliases to their local nodes, 10 to gateway 1 and 20 to gateway 2 on segment B. For simplicity, A1 produces event X, which A2 and B2 want to consume.

Case 1: All nodes initialized before link established, event X is sent

The A-B gateways initialize their internal tables.

A1 sends X. GA receives it. Because GA hasn't seen X before, X is forwarded across the link to GB, followed by an “Identify Consumers of X” message.

GB puts the X message on the CAN segment, and B2 consumes it.

GB puts the “Identify Consumers of X” message on the CAN segment.

B2 responds with “Consumer of X Identified”

GB receives “Consumer of X Identified”, forwards to GA, which marks its tables to continue forwarding these. GA forwards that message on the CAN segment in case there are other listeners for it.

Case 2: Node B2 comes up, after event X has been sent in the example above

The gateways are up, but don't know about B2. GA has seen X sent by A1, but has marked it as “do not forward” because there was no consumer for it on B.

B2 comes up, gets a NID alias assigned, sends “AMD”.

B2 sends “Consumer of X Identified”. GB forwards that to GA.

GA remembers that event X must be forwarded across this link if seen.

A1 sends X, GA receives it, forwards it across link.

Case 3: Node A1 comes up, then event X is sent

The gateways are up, but don't know about A1 or X.

A1 comes up, gets a NID alias assigned, sends “AMD”.

A1 sends “Producer of X Identified”. GA forwards that to GB.

GA notes that event X must be forwarded across this link if seen.

A1 sends X. GA receives it. Because GA hasn't seen X before, X is forwarded across the link to GB, followed by an “Identify Consumers of X” message.

The rest of this proceed like case 1.


Site hosted by

This is SVN $Revision: 2802 $