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

Alexander Wachter <alexander@wachter.cloud> Sun, 20 October 2019 15:23 UTC

Return-Path: <alexander@wachter.cloud>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91DD120090 for <6lo@ietfa.amsl.com>; Sun, 20 Oct 2019 08:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y32kn2rcy6Oa for <6lo@ietfa.amsl.com>; Sun, 20 Oct 2019 08:23:26 -0700 (PDT)
Received: from gienah.uberspace.de (gienah.uberspace.de [185.26.156.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43B01200F1 for <6lo@ietf.org>; Sun, 20 Oct 2019 08:23:25 -0700 (PDT)
Received: (qmail 9771 invoked from network); 20 Oct 2019 15:23:22 -0000
Received: from localhost (HELO ?192.168.0.13?) (127.0.0.1) by gienah.uberspace.de with SMTP; 20 Oct 2019 15:23:22 -0000
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
References: <7de413c1-726e-8595-fe21-0a6f3fe97dcd@wachter.cloud> <d76a963526245134d3f2d2d4f8941f5e.squirrel@webmail.entel.upc.edu> <70401c68-c343-b55a-5ca0-e0f58e3e43fa@wachter.cloud> <86202eb00717994a75a75877943be4b0.squirrel@webmail.entel.upc.edu>
Cc: 6lo@ietf.org
From: Alexander Wachter <alexander@wachter.cloud>
Message-ID: <dba6a13a-dcdc-f133-b59f-76b1e21fa18b@wachter.cloud>
Date: Sun, 20 Oct 2019 17:24:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <86202eb00717994a75a75877943be4b0.squirrel@webmail.entel.upc.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Uqxyje-fHUWttnYPVbZW2JJSQfQ>
Subject: Re: [6lo] Call for feedback to draft-wachter-6lo-can-00
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Oct 2019 15:23:28 -0000

Dear Carles,


On 20.10.19 15:37, Carles Gomez Montenegro wrote:
> 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.

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.

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

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

> Cheers,
> 
> Carles
> 
> 
>> Dear Carles,
>>
>> On 17.10.19 18:16, Carles Gomez Montenegro wrote:
>>
>>   > Thanks for your new Internet Draft submission!
>> Thanks for the quick feedback.
>>
>>   > I have a few clarifying questions:
>>   >
>>   > - 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.
>>
>>   > - 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)?
>>
>> 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

Student of Information and Computer Engineering
Graz University of Technology