Re: [6lo] Call for feedback to draft-wachter-6lo-can-00

[Alexander Wachter <[e-mail]>]

Dear Alex,

On 21.10.19 15:56, Alexandre Petrescu wrote:
> Hi,
> 
> Might be appropriate to run this through the IPWAVE WG, too.

Although CAN is mostly known for its use in the automotive domain, I 
didn't target automotive applications. I got the idea for 6LoCAN while I 
was thinking about using CAN for building automation. Nevertheless, 
posting a message about the draft to the IPWAVE group is a good idea.
Thanks for pointing me towards this WG.

> One question that comes to mind is how to make sure that the QoS of an 
> IP packet on 802.11-OCB (wireless outside the car) is mapped to the 
> right QoS of an IP packet on CAN inside the car.  This would help to 
> send an IP packet from a Remote Controller straight into the brake of 
> the car, with the appropriate priority and given the necessary credentials.

Generally, CAN frames are prioritized by their frame identifier.
Lower number identifiers have precedence over higher numbers.
The identifier is composed by the destination "node address" and the 
sender "node address" and does not contain any QoS measurements.
There is a time-slicing protocol called TTCAN (Time-Triggered CAN), 
where hard real-time can be assured. 6LoCAN does not consider TTCAN and 
therefore has no guarantees for a reliable QoS.

> I want to ask you whether the CAN has a notion of CAN address and if 
> yes, on how many bits is it represented (16?)?  This might help in 
> thinking about how to form an Interface ID to be used with SLAAC on CAN. 
>   One may think that should be 64bit, but I think not necessarily.

Usually, CAN uses identifiers, identifying the content of the frame 
instead of address identifying nodes. These identifiers can either have 
a length of 11 bits or 29 bits. 6LoCAN uses 29 bits identifiers only.
Section 2 (Addressing) defines the way to form identifiers from the 
destination- and source-node-address. The node address has a length of 
14 bits. M is the multicast-bit and indicates to threat the first 14-bit 
field as a multicast-group instead of a destination address.

     0|0            1|1            2|
     0|1            4|5            8|
    +-+--------------+--------------+
    |M|     DEST     |     SRC      |
    +-+--------------+--------------+
Figure 1: Addressing Scheme

Section 4 (Stateless Address Autoconfiguration) specifies how the 
interface ID is formed from the 14-bit node-address. See RFC4291 for 
more details.
The reason why 6LoCAN uses a 14-bit node-address is that a 
frame-identifier must always be unique on the bus. A unique identifier 
can be guaranteed by combining the unique source- and 
destination-node-address.
A violation of this rule would cause collisions outside the arbitration 
field that can't be resolved.

Despite this limited address-space of 14 bits, a random address 
assignment is possible due to a Link-Layer Duplicate Address Detection 
(LLDAD), defined in section 3.

> I want to ask you whether you think that the end to end principle is a 
> good thing for the Internet, and if yes, whether Ethernet Border 
> Translators might have an impact on that principle.

The Ethernet Border Translator is optional for a 6LoCAN network.
I designed the Border Translator out of the lack of router capabilities 
of the Zephyr RTOS. This principle allows pushing complexity towards 
already existing network equipment and infrastructure.

Sincerely,

Alexander


> Le 17/10/2019 à 17:25, Alexander Wachter a écrit :
>> Dear 6Lo WG,
>>
>> I recently submitted a draft for IPv6 over Controller Area Network and 
>> would like to call for adoption by the 6Lo WG.
>> The title of the document is draft-wachter-6lo-can-00 [1].
>>
>> Controller Area Network (CAN) is a widely used field bus initially 
>> designed for the automotive domain. It has a payload length of eight 
>> bytes for classic CAN and 64 bytes for CAN-FD. CAN only describes the 
>> data-link-layer, but various protocols already exist on top. The 
>> submitted draft introduces IPv6 over CAN (6LoCAN),  a 
>> 6lo-adaption-layer to send IPv6 packets over the constrained CAN-bus. 
>> 6LoCAN uses a subset of the already widely used ISO-TP standard for 
>> fragmentation and reassembly to meet the 1280 minimum MTU requirement 
>> of IPv6. It also uses the IPHC (RFC6282) to reduce the protocol 
>> overhead of IPv6.
>>
>> A broad range of devices, from small and cheap MCUs to big application 
>> processors, already have CAN controllers onboard. With 6LoCAN, it is 
>> possible to create networks of resource-constrained MCUs that can 
>> leverage the broad range of protocols and security mechanisms built on 
>> top of the IP.
>> Additionally, multiple 6LoCAN networks can be connected together or 
>> even to the internet by utilizing the routing capabilities of IP 
>> networks.
>>
>> A reference implementation of 6LoCAN already exists in the mainline 
>> Zephyrproject RTOS [2] tree. It includes a sample server-client 
>> application. The source for it is located under [3] and can be used on 
>> any boards supporting CAN.
>>
>> I am looking forward to your comments on the draft.
>>
>> Kind regards,
>> Alexander
>>
>> [1] https://datatracker.ietf.org/doc/draft-wachter-6lo-can/
>> [2] https://www.zephyrproject.org/
>> [3] 
>> https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/sockets/echo_client 
>>
>>
> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo