Subject: [lp-wan] RuleID description; draft-ietf-lpwan-schc-over-lorawan-02

From: <[email-masked]>
Date: Tue, 16 Jul 2019 14:04:06 +0000

Hello authors,

I've read draft-ietf-lpwan-schc-over-lorawan-02. Thanks for providing this
improved version! 
This comment is related to the Rule ID description (more general comments
to come in a separate mail).

Section 5.2 states that the Rule ID is on 6 bits. However, when
FPortUpShort is used, RuleID is actually expressed on 0 (zero) bits.
Besides, this document is mostly about adaptation to the underlying layer,
i.e. Specifying Fragmentation. The requirements for compression mostly
stem from the upper layers, which this document does not address.
Therefore, the specification that 62 rules are available for compression,
and that the compression RuleIDs are expressed on 6 bits, looks premature
to me.
I therefore suggest you describe the RuleID with something like
"The RuleID is of variable length, and lengths of 8 and 14 bits are used
for fragmentation.
The SCHC RuleID overlaps with the LoRaWAN Fport field and potentially with
some of the LoRaWAN payload.
The SCHC RuleID only uses three Fport values called FPortUpShort,
FPortUpDefault and FPortDown, which are taken from the available range
specified by LoRaWAN.
By default, these values are 0x20, 0x21 ad 0x22, respectively.
The following RuleIDs are used for the various combinations of flow
direction (uplink vs. downlink) and SCHC messages:

< - - - Rule ID - -
< - -  Fport - - > < - LoRaWAN payload
+-----------------+-------------------
| 0 0 1 0 0 0 0 0 |                       # short uplink fragmentation
message (FPort = FPortUpShort)
| 0 0 1 0 0 0 0 1   0 0 0 0 0 0 |         # standard uplink fragmentation
message (FPort = FPortUpDefault)
| 0 0 1 0 0 0 0 1   1 1 1 1 1 1 |         # uplink uncompressed
unfragmented SCHC Packet (FPort = FPortUpDefault)
| 0 0 1 0 0 0 0 1   (any other pattern) |  # uplink compressed
unfragmented SCHC Packet (FPort = FPortUpDefault)
| 0 0 1 0 0 0 1 0   0 0 0 0 0 0 |         # downlink fragmentation message
(FPort = FPortDown)
| 0 0 1 0 0 0 1 0   1 1 1 1 1 1 |         # downlink uncompressed
unfragmented SCHC Packet (FPort = FPortDown)
| 0 0 1 0 0 0 1 0   (any other pattern) |  # downlink compressed
unfragmented SCHC Packet (FPort = FPortDown)
+-----------------+-------------------
"

One could even argue that the "uncompressed unfragmented" RuleID would be
better left to the compression draft, together with the other compression
RuleIDs.

Comments, opinions?
Best regards

Dominique

Le 08/07/19 22:55, « lp-wan on behalf of [email-masked] »
<[email-masked] on behalf of [email-masked]> a écrit :

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the IPv6 over Low Power Wide-Area Networks
>WG of the IETF.
>
>        Title           : Static Context Header Compression (SCHC) over
>LoRaWAN
>        Authors         : Olivier Gimenez
>                          Ivaylo Petrov
>	Filename        : draft-ietf-lpwan-schc-over-lorawan-02.txt
>	Pages           : 22
>	Date            : 2019-07-08
>
>Abstract:
>   The Static Context Header Compression (SCHC) specification describes
>   generic header compression and fragmentation techniques for LPWAN
>   (Low Power Wide Area Networks) technologies.  SCHC is a generic
>   mechanism designed for great flexibility, so that it can be adapted
>   for any of the LPWAN technologies.
>
>   This document provides the adaptation of SCHC for use in LoRaWAN
>   networks, and provides elements such as efficient parameterization
>   and modes of operation.  This is called a profile.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-lorawan/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-lpwan-schc-over-lorawan-02
>https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-lorawan-0
>2
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-schc-over-lorawan-02
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>lp-wan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lp-wan

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Olivier Gimenez <[email-masked]>
Date: Tue, 23 Jul 2019 16:02:27 +0000

> -----Original Message-----
> From: [email-masked] <[email-masked]>
I agree that ruleId length should be moved on upper layer, not on SCHC over LPWAN. If nobody disagree I will remove them from the draft.

Regarding the way to express ruleId and FPort, I wonder if we can use another approach:

ruleId is variable length, minimum 2 bits, FPortUpDefault is used.
RuleId=0 => No frag/compression
RuleId=1 => Fragmentation with short header ( current FPortUpShort)
RuleId=2 => Fragmentation with X bytes header, X depending on ruleId size. ( current FPortUpDefault)
All other rules are available to the application for compression, up to 2^N-1 where N is ruleId size, selected by the application.

The trick is to use FPortUpShort as RuleId 1 identifier: if a SCHC gateway receives a payload on port FPortUpShort the rule number 1 must be used for reassembly. So it might be easier to express all rules in the same way.

What is your opinion ?

Thank you
Olivier

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

---

From: Ana Minaburo <[email-masked]>
Date: Tue, 23 Jul 2019 14:39:35 -0400

Hello Olivier,

Just one point a Rule Id cannot be used for compression and fragmentation.
The Rule ID =0 could be used for no compressed packet, if you do not need
fragmentation, means that your packet fits in the L2 PDU and is sent.
You do not need to specify that your packet has not been fragmented but you
must specified that your packet has been not compressed

Ana

On Tue, Jul 23, 2019 at 12:02 PM Olivier Gimenez <[email-masked]>
wrote:

> I agree that ruleId length should be moved on upper layer, not on SCHC
> over LPWAN. If nobody disagree I will remove them from the draft.
>
> All other rules are available to the application for compression, up to
> 2^N-1 where N is ruleId size, selected by the application.
>
> The trick is to use FPortUpShort as RuleId 1 identifier: if a SCHC gateway
> receives a payload on port FPortUpShort the rule number 1 must be used for
> reassembly. So it might be easier to express all rules in the same way.
>
> What is your opinion ?
>
> Thank you
> Olivier
>
> To view our privacy policy, including the types of personal information we
> collect, process and share, and the rights and options you have in this
> respect, see www.semtech.com/legal.