Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt

From: [email-masked]
Date: Fri, 05 May 2017 11:01:05 -0700

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 of the IETF.

        Title           : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP
        Authors         : Ana Minaburo
                          Laurent Toutain
                          Carles Gomez
	Filename        : draft-ietf-lpwan-ipv6-static-context-hc-03.txt
	Pages           : 36
	Date            : 2017-05-05

Abstract:
   This document describes a header compression scheme and fragmentation
   functionality for IPv6/UDP protocols.  These techniques are
   especially tailored for LPWAN (Low Power Wide Area Network) networks
   and could be extended to other protocol stacks.

   The Static Context Header Compression (SCHC) offers a great level of
   flexibility when processing the header fields.  Static context means
   that information stored in the context which, describes field values,
   does not change during the packet transmission, avoiding complex
   resynchronization mechanisms, incompatible with LPWAN
   characteristics.  In most of the cases, IPv6/UDP headers are reduced
   to a small identifier.

   This document describes the generic compression/decompression process
   and applies it to IPv6/UDP headers.  Similar mechanisms for other
   protocols such as CoAP will be described in a separate document.
   Moreover, this document specifies fragmentation and reassembly
   mechanims for SCHC compressed packets exceeding the L2 pdu size and
   for the case where the SCHC compression is not possible then the
   IPv6/UDP packet is sent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-03

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/

---

From: "weigengyu" <[email-masked]>
Date: Sat, 13 May 2017 11:42:40 +0800

Hi all,

There is a question, maybe a silly question.

Does the end-device in Lora, Sigfox, or the like networks need the 
facilities of UDP protocol?
It is heard that it generally is simple one function device,
the port multiplexing is required or not?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: [email-masked]
Sent: Saturday, May 06, 2017 2:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt

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 of 
the IETF.

        Title           : LPWAN Static Context Header Compression (SCHC) and 
fragmentation for IPv6 and UDP
        Authors         : Ana Minaburo
                          Laurent Toutain
                          Carles Gomez
Filename        : draft-ietf-lpwan-ipv6-static-context-hc-03.txt
Pages           : 36
Date            : 2017-05-05

Abstract:

_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: "weigengyu" <[email-masked]>
Date: Sat, 13 May 2017 13:57:56 +0800

HI,

In draft-ietf-lpwan-ipv6-static-context-hc-03,
3.  Static Context Header Compression

Figure 1 based on [I-D.ietf-lpwan-overview] terminology represents the 
architecture for compression/decompression.

In draft-farrell-lpwan-overview-04,
2.1. LoRaWAN
[[Ed: Text here is from [I-D.farrell-lpwan-lora-overview]]]

In draft-farrell-lpwan-lora-overview-01,
2. Terminology
o End-device: a LoRa client device, sometimes called a mote. Communicates 
with gateways.

o Classes A, B and C define different device capabilities and modes of 
operation for end-devices. End-devices can transmit uplink
messages at any time in any mode of operation (so long as e.g., ISM band 
restrictions are honoured). An end-device in Class A can
only receive downlink messages at predetermined timeslots after each uplink 
message transmission. Class B allows the end-device
to receive downlink messages at periodically scheduled timeslots. Class C 
allows receipt of downlink messages at anytime. Class
selection is based on the end-devices’ application use case and its power 
supply. (While Classes B and C are not further
described here, readers may have seen those terms elsewhere so we include 
them for clarity.)

Based on the descriptions above, it is not clear for me to see whether the 
end-device requires the UDP facilities.

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Saturday, May 13, 2017 11:42 AM
To: [email-masked]
Subject: Re: [lp-wan] I-D Action: 
draft-ietf-lpwan-ipv6-static-context-hc-03.txt

Hi all,

Regards,

Gengyu WEI
-----原始邮件----- 
From: [email-masked]
Sent: Saturday, May 06, 2017 2:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt

Abstract:

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Sat, 13 May 2017 13:26:44 +0000

Hi,

Not all devices need to implement the IP stack. 

In Chicago we demonstrated how two type of devices, one Raspberry Pi (with full IP stack) and one simple sensor with a microcontroller (with no IP stack, UDP, etc.), were able to communicate with a CoAP/UDP/IPv6 Internet application by using SCHC rules.

Best,

Juan Carlos 

> -----Original Message-----
> From: lp-wan [mailto:[email-masked]] On Behalf Of weigengyu
> Sent: May 12, 2017 11:43 PM
> To: [email-masked]
> Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt
> 
> Hi all,
> 
> Does the end-device in Lora, Sigfox, or the like networks need the facilities of
> UDP protocol?
> It is heard that it generally is simple one function device, the port multiplexing
> is required or not?
> 
> Regards,
> 
> Gengyu WEI

---

From: "weigengyu" <[email-masked]>
Date: Sat, 13 May 2017 23:39:59 +0800

Hi Juan，

〉were able to communicate with a CoAP/UDP/IPv6 Internet application by 
using SCHC rules.

One node being able to communicate with another one means two nodes should 
share some contexts.
What are they, the IPv6 context, or UDP/IPv6 contexts, or CoAP/UDP/IPv6 
contexts.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Juan Carlos Zuniga
Sent: Saturday, May 13, 2017 9:26 PM
To: weigengyu ; [email-masked]
Subject: Re: [lp-wan] I-D Action: 

Hi,

In Chicago we demonstrated how two type of devices, one Raspberry Pi (with 
full IP stack) and one simple sensor with a microcontroller (with no IP 
stack, UDP, etc.), were able to communicate with a CoAP/UDP/IPv6 Internet 
application by using SCHC rules.

Best,

Juan Carlos

> Subject: [lp-wan] I-D Action:

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Sat, 13 May 2017 22:06:45 +0000

Hi Gengyu,

They were sharing the same CoAP/UDP/IPv6 context. 
One device was compressing/decompressing, and the other one wasn’t.  

Best,

Juan Carlos 

> From: weigengyu [mailto:[email-masked]]
> Sent: May 13, 2017 11:40 AM
> To: Juan Carlos Zuniga <[email-masked]>; [email-masked]
> One node being able to communicate with another one means two nodes
> should share some contexts.
> full IP stack) and one simple sensor with a microcontroller (with no IP stack,
> UDP, etc.), were able to communicate with a CoAP/UDP/IPv6 Internet
> > It is heard that it generally is simple one function device, the port
> > multiplexing is required or not?
> >
> > Regards,
> >
> > Gengyu WEI
> > https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-con
> > text-hc-
> > 03
> >
> > 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.
> >

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Wed, 31 May 2017 13:05:06 +0000

Hi Gengyu,

Indeed, they don't. Microcontroller-based devices would not have an IP stack. 
In our demo it was the SCHC C/D in the Core which regenerated the IP/UDP frame.

Best,

Juan-Carlos

> Sent: May 30, 2017 10:53 PM
> Hi Juan,
> It is not quite clear why the very constrained nodes need the UDP?
> 
> Regards,
> 
> Gengyu WEI
> Sent: Sunday, May 14, 2017 6:06 AM
> > What are they, the IPv6 context, or UDP/IPv6 contexts, or
> > CoAP/UDP/IPv6 contexts.
> >
> > Regards,
> >
> > Gengyu WEI
> > In Chicago we demonstrated how two type of devices, one Raspberry Pi
> > (with full IP stack) and one simple sensor with a microcontroller
> > (with no IP stack, UDP, etc.), were able to communicate with a
> > CoAP/UDP/IPv6 Internet application by using SCHC rules.
> >
> > Best,
> >
> > Juan Carlos
> >
> > > It is heard that it generally is simple one function device, the
> > > port multiplexing is required or not?
> > >
> > > Regards,
> > >
> > > Gengyu WEI
> > > https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-contex
> > > t-
> > > hc/
> > >
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-conte
> > > xt
> > > -hc-03
> > >
> > >