[6lo] Updating the subject, and some comments (Re: Call for adoption of draft-wachter-6lo-can-00 by 6Lo WG)

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

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