Re: [6lo] draft-wachter-6lo-can

[Alexander Wachter <[e-mail]>]

Hello Patrik,

thank you very much for the feedback!
You can find a reply to your questions in the inline text.

On 06.11.19 13:23, Flykt, Patrik wrote:
> 
> 	Hi,
> 
> I read through draft-wachter-6lo-can-00, and some of the descriptions
> were a bit harder to understand than others when reading the draft from
> top to bottom. And as a disclaimer I have about zero knowledge of CAN
> buses in the first place.
> 
> In 1.2, does the ISO 11898-1:2015 Controller Area Network specification
> apply any formatting on CAN identifiers? If yes, then add a mention
> that it does, and whether there is a multicast bit similar to the node
> addressing in section 2. If not, add a mention that there is no
> formatting of the identifiers. It makes the addressing discussion in
> section 2. easier to digest.

The CAN specifications don't specify any format or pattern on the 
identifier. The draft defines the way the identifier is formed.

> In section 2., there is probably a trivial reasoning why the node
> addresses with more leading zeros have higher precedence on the CAN bus
> than the ethernet translator, LLDAD, and, if I got it correctly,
> multicast. If so, add it for clarity.

The multicast bit is indeed at the highest bit position to lower the 
priority of multicast traffic. LLDAD and the translator are at a higher 
address to allow high priority frames in the reserved lower area.
I can clarify the decision.

> In section 3., the Remote Transmission Request RTR is a CAN method for
> requesting a transmission to happen, right? Since I know essentially
> nothing about CAN, can perhaps the RTR frame and its practical use in
> CAN be introduced in Section 1.? It probably turns up as a bit field in
> practise, but maybe the bit or bit sequences that make it an RTR frame
> with an (implicit? explicit?) lenght of zero could be presented in
> section 1., if there are any structure to speak of? Not every bit field
> in the CAN frame, though, just enough to point out which bits make it
> an RTR frame, if any. If it's just a "number" instead of discreet bits,
> then mention that instead. Maybe add a forward pointer to section 6.
> and describe RTR there?

RTR frames are marked with the RTR-bit set in the CAN arbitration field 
(first part of the CAN header). RTR frames may have a data length 
greater than zero. I'll add a short explanation to section one.

> In section 6. the sentence "Single-Frame packets are only useful for
> CAN-FD because the eight octets of classical CAN are too small for any
> IPv6 header." is a bit confusing, would turning it around to "Only CAN-
> FD Single-Frame packets are useful due to their payload size of up to
> XXXX octets, since the eight octet payload of classical CAN is too
> small to carry any IPv6 headers."?

Indeed, the sentence is confusing. I'll replace it.

> In section 6.7, are there any particular values for BS and ST min that
> are useful when sending IPv6 packets? What is the recommended value for
> these fields when sending 6LowCAN/IPv6?

The BS and STmin are inherited from the ISO-TP standard.
Useful values depend on the receiver's capabilities.
Smaller BS can be useful for devices with small memory, for example.
However, it only makes sense if the stack can interpret the data "on the 
fly". STmin can be used to share the bus-load. I can't give any advice 
here without knowing the use-case. Maybe recommend zero value when the 
devices are capable of handling the load.

> In section 7., after the first sentence, it would be smoother if a
> textual description of the figure immediately after the text itself
> were to be given, like "The ISO-TP header is immediately followed
> by..., ..., and ...". Also one could append " and followed by the
> LOWPAN compressed IP packet." or similar to the end of the sentece
> "...directly after the ISO-TP Header." Now it's a bit of a quick
> emergency stop in the sentence after the appearance of the MAC header
> in the text.

I'll try to rewrite.

> In section 8., while borrowing the upper 34 bits of the Ethernet Border
> Translator's MAC address, do we ensure there are no other Ethernet
> nodes whose MAC addresses are identical to the 34 upper bits + 14 CAN
> address bits?

No. It's the network administrator's responsibility. The probability of 
choosing a unique address with a 34-bit random variable (equally 
distributed) with 128 nodes on the same network is 0.99999952. With 256 
nodes, it is still 0.9999981.

> Also in section 8., it seems there is a direct forwarding based on the
> lowest 14 bits of the MAC address. This implies that the host on the
> 6LoCAN must have successfully completed its LLDAD and has allocated a
> unique 14 bit CAN identifier before communicating, right?

Right. The first thing a node does is verifying the uniqueness of its 
tentative 14-bit node address. The host on the Ethernet side needs to 
find out the 14-bit node address then. For this, a Neighbor Discovery is 
performed.

> Also in section 8., after figure 17 there is a reference to "Section 8
> shows a translation CAN...", but we are still inside section 8., so
> this referencing seems a bit redundant? Or did you actually mean Figure
> 18 here? The next sentence "The translator MAC address for this example
> is 02:00:5E:10:3D:F0." is a bit confusing, as 3DF0 happens to be the
> reserved CAN id for the ethernet translator. Could the lower part of
> the address be something else in order not to confuse anybody? Is the
> address itself necessary here, as it does not show up in the Figure 18
> at all?

You are right. It is confusing. I'll change it to define a prefix MAC 
address rather than using the MAC address of the translator.
In the example, the prefix would be 02:00:5E:10, and the MAC address of 
the translator is 02:00:5E:10:3D:F0. It makes sense to use the 3DF0 as 
the Ethernet MAC address for the translator to avoid conflicts with the 
CAN node-addresses.

> Also in section 8., I feel something should be said about Neighbor
> Caches in the 6LowCAN hosts and ethernet tranlators. Basically that the
> NC now contains two kinds of entries, one set for the hosts on the
> 6LoCAN network and one for the rest of the devices on the other side of
> the ethernet border translator. One can't store "regular" 48 bit MAC
> address "equivalents" into the NCs, since the MAC address of the
> ethernet border translator might not be known if all the communication
> happens inside the 6LoCAN only, or since it is not evident which 48-bit
> MAC address "equivalents" would be in 6LoCAN and which on the other
> side of the ethernet border translator, right? Is there anything that
> needs to be said about Neighbor Discovery, or does it continue to work
> as just before?

The entries in the cache only differ in their size. For the reference 
implementation in Zephyr, I didn't change anything in the caches.
The CAN node has to check the node address, and if it matches the border 
translator, it uses the inline source address instead of the one in the 
CAN identifier. In my particular implementation, the network stack 
checks the interface type and address length to decide if the packet is 
sent to another node on the CAN bus or the border translator.

The Neighbor Discovery works across the CAN-Ethernet border.
The only thing to mention here is that the ND messages are analyzed by 
the translator, and the Source Link-Layer Address Option and the 
Destination Link-Layer Address Option are extended by the translator.

> In section 10., any IPv6 packet based security applied will be broken
> when the Ethernet Border Translator decides to rewrite an IPv6 link-
> layer address option.

That's true.

> 
> Cheers,
> 
> 	Patrik
> 

Cheers,

Alex

-- 
Alexander Wachter, BSc

Student of Information and Computer Engineering
Graz University of Technology