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

Alexander Wachter <alexander@wachter.cloud> Sun, 20 October 2019 16:20 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 AD0BA1200F9 for <6lo@ietfa.amsl.com>; Sun, 20 Oct 2019 09:20:28 -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 Oq9XJ2BJ66cM for <6lo@ietfa.amsl.com>; Sun, 20 Oct 2019 09:20:27 -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 AE3C81200F5 for <6lo@ietf.org>; Sun, 20 Oct 2019 09:20:26 -0700 (PDT)
Received: (qmail 440 invoked from network); 20 Oct 2019 16:20:23 -0000
Received: from localhost (HELO ?192.168.0.13?) (127.0.0.1) by gienah.uberspace.de with SMTP; 20 Oct 2019 16:20:23 -0000
References: <1c1341f8-c57e-b5f2-7ed1-c98ba3cfff0c@wachter.cloud>
To: 6lo@ietf.org
From: Alexander Wachter <alexander@wachter.cloud>
X-Forwarded-Message-Id: <1c1341f8-c57e-b5f2-7ed1-c98ba3cfff0c@wachter.cloud>
Message-ID: <05224830-f81f-60d0-63ae-178330086e69@wachter.cloud>
Date: Sun, 20 Oct 2019 18:21:29 +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: <1c1341f8-c57e-b5f2-7ed1-c98ba3cfff0c@wachter.cloud>
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/ReCq7JGvh_j3TU4shH_7LsobO6U>
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 16:20:29 -0000

Dear Carles,

On 20.10.19 17:54, Carles Gomez Montenegro wrote:
> Dear Alexander,
> 
>> 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.
> 
> Your draft proposes using a subset of ISO-TP for fragmentation and
> reassembly.
> 
> Clarifying question: is ISO-TP part of the CAN protocol (stack)?

The CAN specification does only define the data-link-layer. ISO-TP is an 
ISO-Standard (ISO 15765-2:2016). It defines a transport protocol and 
network layer services. 6LoCAN uses the fragmentation/reassembly and 
flow-control mechanism defined in this standard. Flow-control is only 
applied on unicast packets.

>>> 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.
> 
> I see. Anyway, there is the need to comply with the 1280-byte IPv6 MTU
> requirement, but it is already satisfied in your draft.
> 
>> 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.
> 
> 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.).


[1] https://en.wikipedia.org/wiki/ISO_15765-2

-- 
Alexander Wachter, BSc

Student of Information and Computer Engineering
Graz University of Technology