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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
