WeOS
5.20.1

# ECN Subnetting

Within this document supplemental information is provided that aims to aid users in understanding the concept of spitting IEC61375 ECN subnets into smaller subnets within the same ECN. This document assumes a deep understanding of the -2-3 and -2-5 sections of the standard.

## Background and use cases

Consider the following, standard, IEC61375 train topology:

      +---------------------------+       +---------------------------+
      |         Consist 1         |  ETB  |         Consist 2         |
      |       +-----------+  +----|-------|----+  +-----------+       |
      |       |+---------+|  |+---|-------|---+|  |+---------+|       |
      |       ||         ||  ||   |       |   ||  ||         ||       |
      | +-----++-+     +-++--++-+ |       | +-++--++-+     +-++-----+ |
      | |  ETBN  |     |  ETBN  | |       | |  ETBN  |     |  ETBN  | |
      | |   #1   |     |   #2   | |       | |   #3   |     |   #4   | |
      | |        |     |        | |       | |        |     |        | |
      | +-+--+---+     +---+--+-+ |       | +----+---+     +----+---+ |
      |   |  |             |  |   |       |      |              |     |
      |   |  | 10.0.0.0/21 |  |   |       |      | 10.0.0.0/18  |     |
      |   |  |    ECN 1    |  |   |       |      |    ECN 1     |     |
      |   |  +---------+---+  |   |       |      +--+-----------+     |
      |   |            |      |   |       |         |                 |
      |   |       +----+---+  |   |       |  +------+-+               |
      |   |       |        |  |   |       |  |        |               |
      |   |       |  ED A  |  |   |       |  |  ED C  |               |
      |   |       |        |  |   |       |  |        |               |
      |   |       +--------+  |   |       |  +--------+               |
      |   | 10.0.8.0/21       |   |       +---------------------------+
      |   |    ECN 2          |   |
      |   +------------+------+   |
      |                |          |
      |           +----+---+      |
      |           |        |      |
      |           |  ED B  |      |
      |           |        |      |
      |           +--------+      |
      +---------------------------+

Assume that the train reference direction is to the left; the ETBNs will then get the train scope ETBN IDs indicated in the figure. Consequently, ECNs 1 and 2 in Consist 1 will become train scope subnets 1 and 2, while the ECN in Consist 2 becomes subnet 3. Let us assume that ETBNs 1 and 3 are the master routers for their corresponding ECNs (ETBN 1 for both its ECNs). For the purposes of this discussion, assume also that all end devices use address .100 on their local network.

The topology above will result in the end devices being reachable at the following addresses after -2-5 inauguration:

Device | Local scope | Train scope | Subnet
--- | --- | --- | ---
ED A | 10.0.0.100 | 10.128.64.100 | 1
ED B | 10.0.8.100 | 10.128.128.100 | 2
ED C | 10.0.0.100 | 10.128.192.100 | 3

Now consider if the ECN in Consist 2 was to be divided into two parts, with a router in between. This need could be motivated for instance by certain cyber security requirements, such that one part of the ECN could communicate with the other part, but not necessarily with the remainder of the train. While this would be policed by the aforementioned router (also acting as a firewall), the IEC61375 software stack will need to accommodate such a setup.

### ECN subnetting

In this topology it can be seen how within Consist 2 ECN 1 has been split into two smaller subnets.

      +---------------------------+       +---------------------------+
      |         Consist 1         |  ETB  |         Consist 2         |
      |       +-----------+  +----|-------|----+  +-----------+       |
      |       |+---------+|  |+---|-------|---+|  |+---------+|       |
      |       ||         ||  ||   |       |   ||  ||         ||       |
      | +-----++-+     +-++--++-+ |       | +-++--++-+     +-++-----+ |
      | |  ETBN  |     |  ETBN  | |       | |  ETBN  |     |  ETBN  | |
      | |   #1   |     |   #2   | |       | |   #3   |     |   #4   | |
      | |        |     |        | |       | |        |     |        | |
      | +-+--+---+     +---+--+-+ |     _ | +----+---+     +----+---+ | _
      |   |  |             |  |   |    /  |      |              |     |  \
      |   |  | 10.0.0.0/21 |  |   |    |  |      |              |     |  |
      |   |  |    ECN 1    |  |   |    |  |      |    ECN 1     |     |   >
      |   |  +---------+---+  |   |    |  |      +--+--------+--+     |  | \
      |   |            |      |   |    |  |         |        |        |  |  \
      |   |       +----+---+  |   |    |  |  +------+-+      |        |  |   \
      |   |       |        |  |   |    |  |  |        |      |        |  |    |
      |   |       |  ED A  |  |   |    |  |  |  ED C  |      |        |  |    |
      |   |       |        |  |   |   <   |  |        |   +--+-----+  |  |    |
      |   |       +--------+  |   |  / |  |  +--------+   | ECN    |  | _/    |
      |   | 10.0.8.0/21       |   |  | |  |               | router |  | _     |
      |   |    ECN 2          |   |  | |  |               |        |  |  \    |
      |   +------------+------+   |  | |  |               +--+-----+  |  |    |
      |                |          |  | |  |                  |        |   >   |
      |           +----+---+      |  | |  |               +--+-----+  |  | \  |
      |           |        |      |  | |  |               |        |  |  | |  |
      |           |  ED B  |      |  | |  |               |  ED D  |  |  | |  |
      |           |        |      |  | |  |               |        |  |  | |  |
      |           +--------+      |  | \_ |               +--------+  | _/ |  |
      +---------------------------+  |    +---------------------------+    |  |
                                     |                                     |  |
                                     |                      ECN 1 part b --/  |
                                     |                      10.0.8.0/21       |
                                     |                                        |
                                     \--- ECN 1             ECN 1 part a -----/
                                          10.0.0.0/18       10.0.0.0/21

The difference here, as can be seen, is that the ECN in Consist 2 has been split into two subnets, named parts a and b. While the ETBNs in this consist will still report there being one local ECN in the consist, the parts have disjoint address ranges - two /21 subnets of the /18 ECN. Note that in this specific case, part of the /18 ECN does not exist, even though it is addressible (specifically, the address range 10.0.16.0 through 10.0.63.255, inclusive), which leads to the addresses being effectively wasted. This could be solved by, for instance, making the two /21 subnets larger (10.0.0.0/19 and 10.0.32.0/19 respectively) or by adding several more ECN parts and routers (in parallel to part b), but this has been omitted here for simplicity.

The new ECN router needs two interfaces, one facing each part of the ECN. Let us assume that it uses address .200 on both its interfaces. From the perspective of the ETBNs in Consist 2, the entirety of the ECN is still reachable through the same interface as before; the only change from before is that an additional route is needed, to 10.0.8.0/21 (part b of the ECN) via 10.0.0.200 (the IP address of the ECN router, facing part a).

The entirety of the ECN will be mapped onto one train scope subnet, leading to the following addresses being used:

Device | Local scope | Train scope | Subnet
--- | --- | --- | ---
ED A | 10.0.0.100 | 10.128.64.100 | 1
ED B | 10.0.8.100 | 10.128.128.100 | 2
ED C | 10.0.0.100 | 10.128.192.100 | 3
ECN router | 10.0.0.200, 10.0.8.200 |  |
ED D | 10.0.8.100 | 10.128.200.100 | 3

The network configuration in this case is a little bit interesting. The ETBNs see the ECN as one large /18 network, but they have a better (more specific) route to part b (a subnet of the ECN). End devices on part a, such as ED C, however see the network as a /21, with the ETBN as their default gateway. This also applies to the ECN router. While this seems to work when tested, it could pose problems in certain cases (e.g. due the broadcast addresses being different). The ECN router itself will also use the ETBNs as the default gateway, in addition to having link scope routes to both parts of the ECN. As discussed previously, a new route will need to be added on the ETBNs in the consist, to allow for part b of the ECN to be reachable via the ECN router. The remainder of the ECN will be reachable via the regular link scope ECN interface route. In redudant setups this route is manually installed in all ETBNs in the consist.

Additionally, for -2-3 purposes the static consist configuration on the ETBNs must be adjusted. Since EDs C and D are in the same subnet for TTDP purposes, they must both have the same cnId value in the static consist configuration. ED D will however need to have its fctId value added to 2048 (8<<8), to make the IP address resolution work. This is may seem convoluted, but creates the correct behavior.

An advantage of this solution is that the IEC61375 RNAT rules can remain as they are; 10.128.200.100 in the table above will be NATed to 10.0.8.100 as usual, and in turn be routed through the ECN router. There will however be a need for a new configuration setting in the ETBNs, to allow for the new required route.

These routes is not added in TTDP but instead something that is statically configured as would be done in the normal route management for each ETBN, if needed.

The consist can contain several ECNs, just as before, with some or all of them using this new concept. There is also no change in regards to redundant routers. The concept should work the same regardless of whether the ECN is served by one ETBN or a set of redundant ETBNs. However, it would not be possible to have the union of several different ECN parts served by different ETBNs (or sets of redundant ETBNs) be portrayed as a single train scope subnet. Fundamentally, this would be confusing considering how the ETBN-to-CN map works in TTDP, but this can be worked around, as will be discussed later.

« Previous