Subject: [6lo] Call for adoption of draft-wachter-6lo-can-00 by 6Lo WG

From: Alexander Wachter <[email-masked]>
Date: Thu, 17 Oct 2019 17:25:20 +0200

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

-- 
Alexander Wachter, BSc

Student of Information and Computer Engineering
Graz University of Technology

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 17 Oct 2019 18:16:33 +0200

Dear Alexander,

Thanks for your new Internet Draft submission!

As a chair, I would like to clarify one procedural detail. When working
group (WG) chairs want to verify whether there exists WG consensus for
adopting a document as a WG document, the chairs issue a (somewhat) formal
"Call for adoption" email. It must be noted that your email below does not
correspond to a "Call for adoption" in the usual terms, and at this stage
you rather *mean* "Call for feedback".

Other than that, and with or without a particular hat, I think that what
you wrote below (and in the draft) is already useful to start assessing
whether 6Lo is the appropriate WG for your document. By the way, the CAN
MTU characteristics do correspond to significant constrainedness!

It is very positive that there exists already a reference implementation
available.

I have a few clarifying questions:

- What type of power sources can we expect for CAN devices?

- What bit rate/rates is/are typical in CAN?

- What kind of errors (e.g. due to BER) can we expect? Would CAN be
categorized as a lossy technology, or rather as a very low error rate
technology (e.g. Ethernet-like)?

Thanks,

Carles

> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Alexander Wachter <[email-masked]>
Date: Thu, 17 Oct 2019 19:10:45 +0200

Dear Carles,

 > Thanks for your new Internet Draft submission!
Thanks for the quick feedback.

 > - What type of power sources can we expect for CAN devices?

They are usually mains-powered. In the automotive domain, it could be 
that nodes are battery-powered, but the battery is not a constraining 
factor.

 > - What bit rate/rates is/are typical in CAN?

The bit rate depends on the used cables, cable length, environment, ...
125 kbaud should work for long lines, 1 Mbaud for classic CAN and short 
lines, and up to 8 Mbaud for CAN-FD.

 > technology (e.g. Ethernet-like)?

Bit errors may occur, but that heavily depends on the wiring and 
environment. Usually, we can expect a low BER [1]. Errors during 
transmission are detected, and the frame is retransmitted automatically. 
All nodes have an error counter and disconnect from the bus when the 
counter exceeds the limit. The bus is hard-wired, and nodes do not 
disappear.

Kind regards,
Alexander

[1] 
https://pdfs.semanticscholar.org/c16e/1c68ddfe5e525d3e4cc9c3478250f5ad36df.pdf

-- 
Alexander Wachter, BSc

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Sun, 20 Oct 2019 15:37:53 +0200

Dear Alexander,

Thanks for your responses.

To some extent, I see similarities between the environment you are
considering (CAN) and MS/TP. Few years ago, the 6Lo WG produced RFC 8163,
which specifies IPv6 over MS/TP.

I understand that using header compression reduces the amount of IPv6
packets that will require fragmentation. Also, it provides a more
efficient use of the bus. Interesting!

Cheers,

Carles

---

From: Alexander Wachter <[email-masked]>
Date: Sun, 20 Oct 2019 17:24:28 +0200

Dear Carles,

> which specifies IPv6 over MS/TP.

The main difference I see between CAN and MS/TP is the packet/frame 
size. MS/TP satisfies the minimal requirements of 1500 octets minimal 
MTU where CAN only has 8 octets of payload per frame. 6LoCAN therefore 
defines a fragmentation an reassembly.

> efficient use of the bus. Interesting!

IPHC helps to reduce the number of frames needed to send an IPv6 packet. 
Nevertheless, sending an IPv6 packet in a single frame is only possible 
for CAN-FD (up to 64 bytes payload). Classical CAN always needs 
fragmentation and reassembly.

In my opinion, 6LoCAN is the right WG because it defines a 
"6lo-adaption-layer". It specifies a fragmentation and reassembly as 
other 6lo technologies do.

Kind regards,

Alexander

-- 
Alexander Wachter, BSc

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Sun, 20 Oct 2019 17:54:54 +0200

Dear Alexander,

> defines a fragmentation an reassembly.

Your draft proposes using a subset of ISO-TP for fragmentation and
reassembly.

Clarifying question: is ISO-TP part of the CAN protocol (stack)?

> fragmentation and reassembly.

I see. Anyway, there is the need to comply with the 1280-byte IPv6 MTU
requirement, but it is already satisfied in your draft.

> other 6lo technologies do.

I actually mentioned MS/TP and the (6Lo-produced) RFC 8163 to emphasize
the potential similarities with CAN (and 6LoCAN), since the 6Lo WG has
also dealt with technologies with somewhat different characteristics (e.g.
wireless, mesh topologies, energy-constrained devices, etc.).

Kind regards,

Carles

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 21 Oct 2019 15:56:00 +0200

Hi,

Might be appropriate to run this through the IPWAVE WG, too.

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.

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.

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.

Yours,

Alex

---

From: Alexander Wachter <[email-masked]>
Date: Mon, 21 Oct 2019 18:22:28 +0200

Dear Alex,

> 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.

> 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.

>   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.

> 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

>> 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.
>>
>> Additionally, multiple 6LoCAN networks can be connected together or 
>> even to the internet by utilizing the routing capabilities of IP 
>> networks.
>>