Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Lorenzo,

Yes. Identification of the IE’s is the first step. How we deliver those IE’s and on what transport we use is a further debate.  It is possible there may be one more than one approach and for all the good reasons.

Also I agree with the state of the art comment. I think we should also make sure we attempt to leverage what is out there and not just define some thing we believe is "state of the art", but it does exactly the same as some thing else.

Regards
Sri



From: Lorenzo Vangelista <[e-mail]<mailto:[e-mail]>>
Date: Friday, May 27, 2016 at 10:14 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: Alexander Pelov <[e-mail]<mailto:[e-mail]>>, "\"Benoît PONSARD (SIGFOX)\"" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Laurent Toutain <[e-mail]<mailto:[e-mail]>>, "Pascal Thubert (pthubert)" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hello Sri,

I think you are focusing on the right item to clarify first: the "information model for RRM”
IMHO, that is really what we need to tackle first and I think the technologies we are going to
consider need to provide us with the status of the art. Then we should abstract and make a
unified one and go on to see whether existing protocols suit the need or something new need
to be invented.

Lorenzo

On 27 May 2016, at 18:17, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Alex,

Regarding your comment on BCP document, I’m trying to understand your goal here. I’m more interested in WG defining a standardized interface/transport and not sure how BCP document gets us there.  Is it more as FYI ? Unfortunately, I don’t get any thing out of that as it is not solving my problem.

> This could be the foundation for the BCP document. One thing I’d like to see us addressed here is the fact that RADIO-GW can be dispersed over a large territory, having vayring link conditions.

The link conditions / operating environment of the radio, and the choice of the protocol (for the interface between the gateway and a controller) may be independent of each other. Certainly, NETCONF, OpenFlow, or CAPWAP are some of the candidates. Also, there is the second part to this problem and it is the information model for RRM, which is radio technology specific; May be just for LoRa; NB-IOT may be out of scope and I’ve no info on SIGFOX to come out with a information model at this time, unless Benoit publishes one.

But,  I’m glad we are discussing these points.

Sri




From: Alexander Pelov <[e-mail]<mailto:[e-mail]>>
Date: Friday, May 27, 2016 at 8:34 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "\"Benoît PONSARD (SIGFOX)\"" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Laurent Toutain <[e-mail]<mailto:[e-mail]>>, "Pascal Thubert (pthubert)" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Dear Sri,

Thanks a lot for pitching in on this! Indeed, having a well-defined protocol between the RADIO-GW and the LPWAN-GW would be useful, and I believe of great interest for the community as a whole. Also, on the network functions and the RADIO-GW manageability. These all would be perfect candidates for a BCP in our group.

Would you be willing to write up a short document to outline the issues that you feel would be most pertinent for your use-case? This could be the foundation for the BCP document. One thing I’d like to see us addressed here is the fact that RADIO-GW can be dispersed over a large territory, having vayring link conditions. Would OpenFlow be better suited? Or simply NETCONF? I’d be very happy to see a couple of scenarios and work on the simplest solution from there.

Also, there should be support from the stakeholders. I don’t want to do work if it will be in conflict with the supporting technologies.

Best,
Alexander



Le 27 mai 2016 à 16:03, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> a écrit :

Hi Alex,

As I was saying in one of my earlier email, the immediate topics of interest are around the transport between the gateway and the network functions, gateway manageability, RRM on the gateways and the related issues. At this point there is no stand interop with most NS vendors providing their own packet fowarding modules for different vendor gateways and that is a real problem. Any thing and everything on compression and with the hope that SDO and the devices will adopt IPv6/CoAP stack is great, but is for long term and for certain things the ship may have already sailed.

Sri

On May 26, 2016, at 9:39 AM, Alexander Pelov <[e-mail]<mailto:[e-mail]>> wrote:

Dear Sri,

Thanks very much for sharing your thoughts on this point!

What would be the problems that you would like to see addressed, specifically for LoRa networks, and maybe more generally for other LPWAs?

Best,
Alexander



Le 26 mai 2016 à 18:14, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> a écrit :

Hi Laurent,

Yes. The transport/packet forwarding is one of the functions that you get for free in addition to so many capabilities.

To your finer point that phase-1 should only be about “compressions and management”,  I’d say if the scope is only compression it is not interesting to me at least, as it not solving any immediate problems. If you say,  “management” then that overlaps with CAPWAP offers and all of this discussion is relevant.


Sri



From: lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Laurent Toutain <[e-mail]<mailto:[e-mail]>>
Date: Thursday, May 26, 2016 at 6:02 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Cc: "Benoît PONSARD (SIGFOX)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Pascal Thubert (pthubert)" <[e-mail]<mailto:[e-mail]>>, Alexander Pelov <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi Sri,

that's may be a good choice. If I understand well the figure


              +-+         wireless frames        +-+
              | |--------------------------------| |
              | |              +-+               | |
              | |--------------| |---------------| |
              | |wireless PHY/ | |     CAPWAP    | |
              | | MAC sublayer | |               | |
              +-+              +-+               +-+
              STA              WTP                AC


STA is the equivalent of Node-F/End Point,
the WTP the Node-R Base Station and
the AC the Node-G/Network Server

For me, CAPWAP is the equivalent of the LoRa Packet Forwarder which encapsulates frames to be sent/received on radio, for instance:

{"rxpk":[{"tmst":14274150,"time":"2016-01-08T14:23:44.889110Z","chan":8,"rfch":0,"freq":870.000000,"stat":1,"modu":"LORA","datr":"SF7BW250","codr":"4/7","lsnr":9.2,"rssi":-85,"size":40,"data":"IjYB+rAAAAAAAAUAAEEBap9iPQNlcHNpbG9uLnQuZXUub3Jng2x1bQ=="}]}

You are right that CAPWAP may be more flexible, more secure, but for my point of view this should not be the first priority of the working group which should be compression and management.

Laurent

On Thu, May 26, 2016 at 12:17 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> wrote:
I very much look forward to this presentation from Benoit as well. Unless SIGFOX opens up the specs (at a protocol messaging level), this is a closed system and I'm not sure how much we can discuss about that access in IETF, both from legal and from guidelines point of view. We already know NB-IOT's own path and that mainly leaves LoRa which is yet to adopt IP and every single item here is tied to that.  In this sense and for broader applicability of this work, I hope to see SIGFOX specs.

Sri

Sent from my iPad

On May 25, 2016, at 10:32 PM, Alexander Pelov <[e-mail]<mailto:[e-mail]>> wrote:

Yes, indeed!

Thanks, Benoit, for the formal confirmation of your participation. You have the first slot on our technology list for the charter! :)

We could probably take the architecture description in its own draft, independent of CoSOL.

Best,
Alexander


Le 26 mai 2016 à 06:58, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> a écrit :

Fantastic news Benoit!

Defining abstract architecture elements is really useful to enable multiple technologies, as long as the mapping to the actual protocol elements is straightforward.

It will be good that the mapping is explicitly documented to avoid recurring questions.

Regards,

Pascal

Le 26 mai 2016 à 06:32, Benoît PONSARD (SIGFOX) <[e-mail]<mailto:[e-mail]>> a écrit :

Hi all,

I've just seen Laurent's email on architecture elements. I think his definition of the architecture elements is compatible with what Sigfox is doing (see the overall architecture attached). Names are different but main features seem to be quite equivalent.

I'm taking the opportunity of this email to confirm that Sigfox will attend the Berlin meeting and is ready to present its technology. I also confirm that, after the Berlin's meeting, we have in mind to allocate some human resources to contribute to the 6LPWA work, more actively that I'm currently doing up to now !

BR

BPS



2016-05-25 11:26 GMT+02:00 Laurent Toutain <[e-mail]<mailto:[e-mail]>>:
Hi,


I agree for the radio gateway (aka BTS) but there is other gateways in the system. We need to have a precise definition of the gateway  otherwise it will lead to a lot of confusion on the mailing list.

In draft draft-pelov-core-cosol-01 we propose the following definition:


 We can identify three types of entities in a typical LP-WAN.  These
   are:

   o  Node-F: far-reachable node, e.g. the end-point, object, device.

   o  Node-R: radio relay, bridging the LP-WAN radio technology to a
      different medium (often a LAN or cellular WAN).

   o  Node-G: gateway node, interconnection between the radio-relay node
      and the Internet.

   +--------+                      +--------+            +--------+
   | Node-F | <-- LP-WAN radio --> | Node-R | <-- IP --> | Node-G |
   +--------+                      +--------+            +--------+

In LoRa point of view, node-G will be the network server.

Can we agree on the mailist list to a reference architecture with a common name associated to each componments ?

Thanks

Laurent

On Wed, May 25, 2016 at 10:52 AM, Ver Steeg, William (Contractor) <[e-mail]<mailto:[e-mail]>> wrote:
We need to be sure to remember that one of the huge advantages to several of these network types (for instance LoRaWan) is the fact that the Gateway is very nearly stateless. This allows the operator to deploy in a very lightweight, cost effective manner. There is no session established between the end node (which I generally think of as a sensor) and the gateway, end nodes come and go (as seen by the Gateway), and ideally there is no end node state kept on the Gateway.

Bill VerSteeg

P.S. sorry for being late to the thread - I have been heads-down on a LoRaWan project and just now popped up for air.....
________________________________
From: lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of weigengyu <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 24, 2016 10:39 PM
To: Laurent Toutain; Pascal Thubert (pthubert)

Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi,

Probably, a basic problem is whether the smart object is treated as a independent IP node logically?

If yes, each smart node should have a IPv6 address no matter the address is kept in Gateway or in the node itself,
no matter the address is compressed or not.


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Laurent Toutain<mailto:[e-mail]>
Sent: Tuesday, May 24, 2016 10:32 PM
To: Pascal Thubert (pthubert)<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [lp-wan] The compression problem: protocol dependant? if so, which protocol(s)?

Hi pascal,

Thanks for asking those questions.

On Mon, May 23, 2016 at 11:24 AM, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
Dear all:

In the most simplistic approach, which so far we have referred to as the remote I/O, our new protocol would instruct the LPWAN AP/GW to literally tunnel traffic from a certain device to another, inserting IPv6, UDP and COAP over the MAC and APP protocols that are present in the air. In that simplistic model, a simple source MAC is all we have to determine a flow and at the extreme, the MAC packet could be transported (even in its in is encrypted form) as a CoAP payload. This could be compared with CAPWAP, which tunnels the 802.11 frame to a controller which completes the .11 MAC process and bridges to Ethernet.

If I understand well we have the following architecture

    Object ~~~~~~ RADIO GW ======= LPWAN GW ======== LPWAN AP

For me CAPWAP is, in a sense, the equivalent of Packet Forwarder in LoRa. The LPWAN GW is in charge of the MAC protocol, the radio gateway is transparent in a way that it sends on the radio everything the LPWAN GW sends with meta information indicating the channel to use, the coding,...

If I'm right, what you are talking about is more between the LPWAN AP and the LPWAN GW.


OTOH, a lot more may we achieved if the flow can be determined with a granularity beyond the simple MAC address of the device.
Ideally, the flow would also be determined some other mac (aka network) layer elements, and, to be determined, some app layer elements; the insertion process would depend on all these elements.
This is quite important considering that when the expanded packet is placed over an IP network, all the resulting processing by the routing fabric – e.g. the Internet- will be determined from the inserted headers.

In my views the LPWAN AP is aware of the LPWAN network and so can adapt what are sent on the network and can use some specific protocols to signal information to the LPWAN GW.

The question becomes what can be signaled in the air protocol, when the frame is encoded natively as app over mac:
-        Which keys can the AP/GW access (none, MAC/Network only?, do we cover the case where the GW is also an app level GW with the app keys?)

The LPWAN GW does not have to get the key for app. which means that only the LPWAN can compress IPv6/UDP/ULP. In fact what we proposed in https://datatracker.ietf.org/doc/draft-toutain-lp-wan-compression-context/?include_text=1 is to use a SHIM to refer to a compressed stack. The SHIM can be carried by L3 or by L2 to optimize, which means that the LPWAN will have to send it separately to allow the LPWAN GW to insert it into L2 frame.
-        What in the air protocol is signed vs. encrypted

depends of MAC, it is not IETF business.
-        Taking the reasonable assumption the AP/GW is not an app level GW, is there room in the MAC format to store a app level (opaque to the MAC) flow ID that the AP/GW can leverage for its insertion work?

That's why the SHIM may be important. The SHIM can be carried in Layer 3 protocol or Layer 2 protocol, so the 6LPWA working group can work on something  generic. Then when you instantiate for 6LPWA other foo.
-        Taking that assumption, can we live with a simple flow ID? What becomes of CoAP’s Message ID and Token?

The capabilities that we can achieve depend on the answers to these fundamental questions, which in turn may depend on the protocols that we work on.

We can start guessing, playing the “what if?” game. But in truth, we’re pretty much stuck till we complete the protocol selection process.

We have cross-participated for a long while now; people from IETF and LPWANs have exchanged and read specs, and the IETF has published a candidate charter.

Now is a good time for candidate LPWANs to come out and so we all kick off the work. And studying the questions above for the selected protocols would be a great start.

Pascal







_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan




--
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: [phone]<tel:%2B33%202%2022%2006%208156>    | Tel: + 33 2 99 12 7026<tel:%2B%2033%202%2099%2012%207026>                 | Visit :
| Mob: [phone]    |                                        |
| Fax: [phone]<tel:%2B33%202%2022%2006%208445>    | Fax: [phone]<tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in<http://class.touta.in/>
| [e-mail]<mailto:[e-mail]>         | [e-mail]<mailto:[e-mail]>    |
+--------------------------+----------------------------------------+

________________________________
_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan



--
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: [phone]<tel:%2B33%202%2022%2006%208156>    | Tel: + 33 2 99 12 7026<tel:%2B%2033%202%2099%2012%207026>                 | Visit :
| Mob: [phone]    |                                        |
| Fax: [phone]<tel:%2B33%202%2022%2006%208445>    | Fax: [phone]<tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in<http://class.touta.in/>
| [e-mail]<mailto:[e-mail]>         | [e-mail]<mailto:[e-mail]>    |
+--------------------------+----------------------------------------+

_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan




--
Benoît PONSARD
Director of Standardization
Mobile : [phone]<tel:%2B33%20%280%296%2084%2074%2070%2071>
www.sigfox.com<http://www.sigfox.com/>

<Capture d’écran 2016-05-25 à 05.03.08.png>
_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan
_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan




--
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: [phone]    | Tel: + 33 2 99 12 7026                 | Visit :
| Mob: [phone]    |                                        |
| Fax: [phone]    | Fax: [phone]                  |  http://class.touta.in<http://class.touta.in/>
| [e-mail]<mailto:[e-mail]>         | [e-mail]<mailto:[e-mail]>    |
+--------------------------+----------------------------------------+
_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan