Re: [6lo] 6lo and SCHC

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Mon, 21 September 2020 12:38 UTC

Return-Path: <carlesgo@entel.upc.edu>
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 EE58B3A0DD1 for <6lo@ietfa.amsl.com>; Mon, 21 Sep 2020 05:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3K0WR9xy2jTQ for <6lo@ietfa.amsl.com>; Mon, 21 Sep 2020 05:38:50 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD2F3A0DCA for <6lo@ietf.org>; Mon, 21 Sep 2020 05:38:49 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 08LCcluB035780; Mon, 21 Sep 2020 14:38:47 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id A118A1D53C1; Mon, 21 Sep 2020 14:38:46 +0200 (CEST)
Received: from 95.126.92.38 by webmail.entel.upc.edu with HTTP; Mon, 21 Sep 2020 14:38:47 +0200
Message-ID: <4c0e8f69095c1d28cdbf14de9cacd6e4.squirrel@webmail.entel.upc.edu>
In-Reply-To: <CABONVQYewJT=cmnWwrLRfRc9Xp+4u+qTb8PLDH4TuCnyF3heKw@mail.gmail.com>
References: <CABONVQYewJT=cmnWwrLRfRc9Xp+4u+qTb8PLDH4TuCnyF3heKw@mail.gmail.com>
Date: Mon, 21 Sep 2020 14:38:47 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Laurent Toutain <laurent.toutain@imt-atlantique.fr>
Cc: 6lo@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Mon, 21 Sep 2020 14:38:48 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/McNe9gqiyygzaTCDFAz6YEX4iLE>
Subject: Re: [6lo] 6lo and SCHC
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: Mon, 21 Sep 2020 12:38:52 -0000

Hi Laurent,

Thanks a lot for your comments!

(And sorry for the late response.)

Please find below my inline responses:

> Hi Carles,
>
> Thank you for the draft, it shows that 6lo and SCHC can work together.
> I've
> few comments on the draft:
>
> - NALP
>
> I don't think we should impose the size of the ruleID in 6lo header, for
> instance if a 6lo network is relaying a SCHC packet, it should know the
> rule size to fill the field. if it does not care, it just copy the SCHC
> packet after the NALP.
>
> I will be more in favor of a NALP of 1 byte long then the SCHC packet.

Yes, I agree with your vision.

I just updated the draft. As per this update (-01), a 1-byte Dispatch Type
is (or would be) used for SCHC header compression:
https://datatracker.ietf.org/doc/draft-gomez-6lo-schc-dispatch

This approach exploits the RFC 8025 concept of pages. The current proposal
is allocating a whole page as SCHC Dispatch Type, with the aim to minimize
header overhead.

> We can specify some recommendations at it is currently done for LoRaWAN,
> Sigfox or PPP to carry SCHC packet over 6lo.

Agreed!

One consideration is that the draft focuses only on the use of SCHC header
compression (i.e. not fragmentation), since 6LoWPAN fragmentation was
designed taking into account a set of requirements that is different from
those in LPWAN. In addition, 6LoWPAN fragmentation functionality is being
extended with draft-ietf-6lo-fragment-recovery.

Therefore, I understand that the document that you suggest (e.g. a profile
for SCHC header compression over 802.15.4?) would only focus on the SCHC
header compression part, Rule ID sizes, padding, etc., and not on SCHC
fragmentation.

And the LPWAN WG should probably be involved...

Thoughts?

> - HC
>
> Could be nice to have a HC_SCHC which keeps IPv6 header compression with
> 6lo and allows route-over. Same as for NALP, the SCHC format decoding is
> done by SCHC.

Yes, that is also an interesting approach, probably for a separate document.

Thanks,

Carles (as a WG participant)