Subject: [lp-wan] Why a new WG?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Jun 2016 07:18:00 +0000

Dear all:

Suresh, Alex and I have been discussing rationale to form a new WG vs. distributing the work over existing ones. 
This is certainly a critical topic for the BoF and we'd like to gather additional ideas and feedback. Here's what we got:

People
-        LPWAN will attract a new crowd at the IETF; these new people will have focused interests and expect dedicated sessions
-        There will be 4 technologies represented, with both common points and specificities. This is a lot to learn and digest as a group.
-        We need to stay focused on those technologies, none of which is really covered today at the IETF.

6lo
 
-        6lo technologies are relatively high throughput, and symmetrical links. LPWAN are real slow and unbalanced.
   =>       Neither 6LoWPAN ND nor HC can apply to (most of) LPWAN technologies
-        We cannot rely on adding many bits to the air protocol (sometimes the IP stack has to be fully implicit in the air) 
    =>      We'll be compressing a limited number of well-known frames, all the way to CoAP
    =>      More like a RoHC with no learning phase, and yet a context distribution like 6lo (via ND for 6loHC) and ROLL (via RPL for 6LoRH)
-        There's lots of work ahead, and not much room at 6lo
 
Core, Netconf, Cose, ROLL?,  ...
 
-        We are not changing the protocols, we'll be compressing them
-        if there is a need to add something in such protocols we'll work within the appropriate WG
 
6TiSCH
 
-        6TiSCH builds architectures and best practices for the upper MAC and above, leveraging TSCH, 6LoWPAN and ROLL.
-        Initially LPWAN will be doing a similar work but without the components above
-        Yet there is a great potential for interactions:
    -       e.g. Full 6TiSCH over 802.15.4g, scheduling and/or meshing LoRa or SIGFOX, ...
    -       LPWAN may propose work on a scheduled version that leverages 6TiSCH (problem statement, justification...)
    >      and we'll see whether and how we move work to 6TiSCH

Any point we missed?

Pascal

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Jun 2016 11:32:39 -0500

Hi Pascal,

 My comments inline.

Regards,

Behcet

> -        There will be 4 technologies represented, with both common points and specificities. This is a lot to learn and digest as a group.

One of them is NB-IoT, right?
NB-IoT is being designed to work in Cellular Internet of Things.
I am not sure how much work 3GPP needs from IETF other than IPv6 operation?

>    =>       Neither 6LoWPAN ND nor HC can apply to (most of) LPWAN technologies

You mean not at all?
Does this mean that a new LPWAN-ND needs to be developed?
I have trouble believing in such a thing, you need to convince me?

You may remember that RFC 6775 was completed in November 2012
 the triggering work in

draft-shelby-6lowpan-nd-00

was published in 2008. So you are talking about another good 4 years?

> -        if there is a need to add something in such protocols we'll work within the appropriate WG

OK

>     >      and we'll see whether and how we move work to 6TiSCH
OK

>
> Any point we missed?
>
> Pascal
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 22 Jun 2016 09:23:16 +0200

Hi Behcet,

On Tue, Jun 21, 2016 at 6:32 PM, Behcet Sarikaya <[email-masked]>
wrote:

> > -        6lo technologies are relatively high throughput, and
> symmetrical links. LPWAN are real slow and unbalanced.

 You are right, standard takes time to be published and the goal is not to
publish new things just for the pleasure. But I see some drawback the use
of neighbor discovery even adapted to 6LoWPAN. One is related to the
payload size. One of the challenge for 6LoWPAN was to put RA in 127 bytes.
In LP-WAN we do not have so much space; 50 Bytes is a more realistic limit.
This impose to redesign not only the header compression but the way the
send valuable information on the radio link.

Laurent

>
>
> > -        We cannot rely on adding many bits to the air protocol
> (sometimes the IP stack has to be fully implicit in the air)
> >     =>      More like a RoHC with no learning phase, and yet a context
> distribution like 6lo (via ND for 6loHC) and ROLL (via RPL for 6LoRH)
> > -        6TiSCH builds architectures and best practices for the upper
> MAC and above, leveraging TSCH, 6LoWPAN and ROLL.
> >     -       LPWAN may propose work on a scheduled version that leverages
> 6TiSCH (problem statement, justification...)

-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit
:
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Jun 2016 13:12:44 +0000

Hello Behcet,

Some IETF work takes longer than other. 

I was there working on 6LoWPAN ND from day one (my draft was adopted if you remember). There were all sorts of reasons for the time it took.

You can't just take for granted that work on ND at LPWAN would take 4 years. 

Now, we have not chartered ND related work yet.

Cheers,

Pascal

> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: mardi 21 juin 2016 18:33
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: lp-wan <[email-masked]>
> Subject: Re: [lp-wan] Why a new WG?
> 
> Hi Pascal,
> 
>  My comments inline.
> 
> 
> Regards,
> 
> Behcet
> 
> > Suresh, Alex and I have been discussing rationale to form a new WG vs.
> distributing the work over existing ones.
> > -        LPWAN will attract a new crowd at the IETF; these new people will have
> focused interests and expect dedicated sessions
> > -        There will be 4 technologies represented, with both common points and
> specificities. This is a lot to learn and digest as a group.
> 
> You may remember that RFC 6775 was completed in November 2012  the
> triggering work in
> 
> > -        We cannot rely on adding many bits to the air protocol (sometimes the IP
> stack has to be fully implicit in the air)
> > -        6TiSCH builds architectures and best practices for the upper MAC and
> above, leveraging TSCH, 6LoWPAN and ROLL.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Jun 2016 10:47:06 -0500

Hi Laurent,

On Wed, Jun 22, 2016 at 2:23 AM, Laurent Toutain
<[email-masked]> wrote:
> publish new things just for the pleasure. But I see some drawback the use of
> neighbor discovery even adapted to 6LoWPAN. One is related to the payload
> size. One of the challenge for 6LoWPAN was to put RA in 127 bytes. In LP-WAN
> we do not have so much space; 50 Bytes is a more realistic limit.

 if we are limited to 50 byte since  IPv6 header is 40 bytes, how can
you make IPv6 work on those links? Maybe layer 2 operation with
something like CoAP is more realistic?

Regards,

Behcet

> This
> impose to redesign not only the header compression but the way the send
> valuable information on the radio link.
>
> Laurent
>>
>>
>>

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 22 Jun 2016 18:44:59 +0200

Hi Behcet,

> as published in 2008. So you are talking about another good 4 years?
> >
> >

You are right, CoAP and COMI/CoOL are good candidates to configure the End
System.
IPv6/UDP will not be removed, but drastically compressed, which means that
the other end can reconstruct it. See our proposal
https://tools.ietf.org/html/draft-toutain-6lpwa-ipv6-static-context-hc-01
The UDP/IPv6 header can be compressed in 0 or 1 byte.

Laurent

> >> >     =>      We'll be compressing a limited number of well-known
> frames,
> >> > all the way to CoAP

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Jun 2016 11:51:20 -0500

Hi Laurent,

> The UDP/IPv6 header can be compressed in 0 or 1 byte.

I'll try to read your draft.
My idea is to use CoAP proxy and then Layer 2 operation between the
Proxy and the nodes. LPWAN architecture easily lends itself for such
an operation.

I think IPv6, especially ND is very heavy in such environments?

Regards,

Behcet
>> >> >     -       e.g. Full 6TiSCH over 802.15.4g, scheduling and/or
>> >> > meshing
>> >> > LoRa or SIGFOX, ...

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 22 Jun 2016 19:04:00 +0200

Hi Behcet,

<snip>

> I think IPv6, especially ND is very heavy in such environments?

Yes, for relatively challenged LPWAN scenarios, ND can be very heavy. Some
related information is available here:
https://tools.ietf.org/html/draft-gomez-lpwan-ipv6-analysis-00

Cheers,

Carles