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