Subject: Re: [lp-wan] IPv6 SCHC dispatch header

From: Ana Minaburo <[email-masked]>
Date: Wed, 7 Dec 2016 10:50:23 +0100

Hello Rahul,

I would like to clarify the possible problematic you have raised. I mean I think we have all understood different things, let’s try to see what we are talking about. I think your question is: Does the dispatch header is part of SCHeaC or it is an option in the header compression?
(SCHeaC is the new name of SCHC)

First option: The dispatch information is not part of SCHeaC but it is added by the gateway. If I understand you want to route the SCHeaC packets to the mesh network so the gateway needs to add/remove something in order to route the SCHeaC packets, if this the point I think the possible solution needs to be described in a new document, where the SCHeaC packets are routable to a mesh network. I do not know if this is a milestone of LPWAN, we can submit this work into the 6lo WG. Do we want to solve SCHeaC-6lo dispatch problem solution? Does the gateway will choose which solution be used after the LPWAN network, this means make decompression and dispatch the packet or dispatch the SCHeaC packet? 

Second option: The dispatch information is an option of the header compression as the non-compressed option that also needs to be done. Then as Laurent explain the rules in the SCHeaC header can be adapted, we can create a rule for LPWAN-6lo compression which will be used for some networks to create a transparent connectivity of all the nodes. If this is the point you want to do, in my opinion this cannot be part of the SCHeaC based document, this can be a new document describing this interaction and creating this new rule in the context. I think this new document can be part of LPWAN because SCHeaC is been done in LPWAN

Third option: You want to add routing in the LPWAN solution. If this is your point, I think that for the moment the idea is to solve the star topology problem and the in a second time see how we can adapt this solution to the mesh topology. So for me at this point we can create a document for this solution but I do not thing this will be going on in the LPWAN WG because of time and milestones…

In any case, I think that there are some questions to be solved and we can work together.
Ana

> On 21 Nov 2016, at 15:02, Laurent Toutain <[email-masked]> wrote:
> 
> Hi Rahul,
> 
> On Mon, Nov 21, 2016 at 6:03 AM, Rahul Jadhav <[email-masked] <mailto:[email-masked]>> wrote:
> I think there is some confusion regarding what i intend to say. 
> My intent is to allow a dispatch header for SCHC-IPv6. Using this, a gateway receiving a SCHC-compressed packet or a 6Lo compressed packet or a regular IPv6 packet would be able to differentiate between what its receiving and then processing accordingly.
> 
> @Diego, The dispatch header cannot be clubbed with the SCHC rules i.e. I don't mean that we modify an existing rule to add dispatch header. This would not make sense.
> 
> @Laurent, As you mentioned, i agree that a dispatch is not incompatible with what you proposed. I just meant that it makes sense to define a dispatch header.
> 
> 
> Ok, let's work on it to see how we can put it into a rule definition. 
> Regards,
> Rahul
> 
> 
> On 20 Nov 2016 9:41 p.m., "Prof. Diego Dujovne" <[email-masked] <mailto:[email-masked]>> wrote:
> Laurent, Rahul:
>                        Then creating a new rule with the dispatch header
> is possible using the method explained on the SCHC. Do you mean
> that we have to modify an existing rule to add the dispatch header?
> Regards,
> 
>                                         Diego  
> 
> 2016-11-20 12:26 GMT-03:00 Laurent Toutain <[email-masked] <mailto:[email-masked]>>:
> Hi Rahul,
> 
> A dispatch can be a good idea to mix LPWAN and 6lo and is not incompatible with what we propose. In fact, we don't want to impose global values for coding a rule, since it leads to large identifiers (in some technologies, the rule ID can be few bits long). Since the rule id is a convention between both ends, we can imagine that some values are reserved for this dispatch value.
> 
> Laurent 
> 
> On Sat, Nov 19, 2016 at 1:39 PM, Rahul Jadhav <[email-masked] <mailto:[email-masked]>> wrote:
> Dear SCHC authors,
> 
> During the meet, there was a question whether dispatch header for SCHC would be required for LPWAN.
> And the general mood in the room was to not to have it. 
> Imo it has bigger implications and the primary one been that it wont be possible to have different capability (for e.g. SCHC + 6Lo) devices in the same LPWAN connected to the same gateway on the same wireless interface. 
> While this makes sense for a SIGFOX or LoRaWAN like network, I feel for NB-IoT or Wi-Sun where there is a possibility that different capability nodes connect to the gateway on the same interface, the presence of dispatch header might help.
> 
> My opinion is, a dispatch header defined for SCHC-IPv6 might actually help and the deployment may chose to use it or not.  If the deployment is a pure SCHC based then the dispatch hdr could be omitted (nodes/gw know after it as part of commissioning or something)
> 
> Regards,
> Rahul
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
> 
> 
> 
> 
> -- 
> Laurent Toutain 
> +--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
> | Tel: +33 2 22 06 8156 <tel:%2B33%202%2022%2006%208156>    | Tel: + 33 2 99 12 7026 <tel:%2B%2033%202%2099%2012%207026>                 | Visit :
> | Mob: +33 6 800 75 900    |                                        |
> | Fax: +33 2 22 06 8445 <tel:%2B33%202%2022%2006%208445>    | Fax: +33 2 99 12 7030 <tel:%2B33%202%2099%2012%207030>                  |  http://class.touta.in <http://class.touta.in/>
> | [email-masked]         | [email-masked] <http://ne.eu/>    |
> +--------------------------+----------------------------------------+
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
> 
> 
> 
> 
> -- 
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl/>
> (56 2) 676 8125
> 
> 
> 
> -- 
> 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 <http://class.touta.in/>
> | [email-masked] <mailto:[email-masked]>         | [email-masked] <mailto:[email-masked]>    |
> +--------------------------+----------------------------------------+
> _______________________________________________
> lp-wan mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 9 Dec 2016 16:04:38 +0530

Hello Ana,

This figure explains the use-case i wanted to highlight. Allowing SCHC to
coexist with other compressed/uncompressed IPv6 tech in the same network.
As an analogy, 6Lo allows use of uncompressed IPv6 to be used in the same
network by utilizing NALP (4944, sec 5.1) dispatch header. But with the
current specifications on LPWAN, it is not possible to have similar
arrangement on networks using SCHC. Currently SCHC would work on a network
exclusively using SCHC compression.

Pascal made it clear that the documented scope does not need to address
this issue now and hence it was left at that.

Please find my comments inline and consider SCHC=SCHeaC in this mail

On 7 December 2016 at 15:20, Ana Minaburo <[email-masked]> wrote:

> Hello Rahul,
>
> I would like to clarify the possible problematic you have raised. I mean I
> think we have all understood different things, let’s try to see what we are
> talking about. I think your question is: Does the dispatch header is part
> of SCHeaC or it is an option in the header compression?
> First option: The dispatch information is not part of SCHeaC but it is
> added by the gateway. If I understand you want to route the SCHeaC packets
> to the mesh network so the gateway needs to add/remove something in order
> to route the SCHeaC packets, if this the point I think the possible
> solution needs to be described in a new document, where the SCHeaC packets
> are routable to a mesh network. I do not know if this is a milestone of
> LPWAN, we can submit this work into the 6lo WG. Do we want to solve
> SCHeaC-6lo dispatch problem solution? Does the gateway will choose which
> solution be used after the LPWAN network, this means make decompression and
> dispatch the packet or dispatch the SCHeaC packet?
>

You made an interesting point but my intention was not to route SCHeaC
packets to the mesh network. Routing SCHeaC in mesh network would require
encapsulation header and i m not clear of the use-case.
My intention was to work out heterogenous IPv6 compression for star
topologies (like the example above). Not all LPWAN technologies (for e.g.
NB-IoT) are so MTU constrained that it needs pure SCHC based compression.
NB-IoT can afford to have devices with uncomp IPv6 to retain its
flexibility while at the same time in the same network use SCHeaC for
certain nodes/services for reducing control overhead from these devices.

>
>
> Second option: The dispatch information is an option of the header
> compression as the non-compressed option that also needs to be done. Then
> as Laurent explain the rules in the SCHeaC header can be adapted, we can
> create a rule for LPWAN-6lo compression which will be used for some
> networks to create a transparent connectivity of all the nodes. If this is
> the point you want to do, in my opinion this cannot be part of the SCHeaC
> based document, this can be a new document describing this interaction and
> creating this new rule in the context. I think this new document can be
> part of LPWAN because SCHeaC is been done in LPWAN
>

I understand that the compression of existing 6lo dispatch header can be
achieved by adapting the SCHC rules. But i also didn't mean to say this
when i raised this issue. Advanced scenarios like mix of LPWAN-6Lo
compression at the same time is not what my intention was to address.

>
>
> Third option: You want to add routing in the LPWAN solution. If this is
> your point, I think that for the moment the idea is to solve the star
> topology problem and the in a second time see how we can adapt this
> solution to the mesh topology. So for me at this point we can create a
> document for this solution but I do not thing this will be going on in the
> LPWAN WG because of time and milestones…
>

Absolutely not. I don't intend to add routing to LPWAN solution. I had
followed the long discussion on the ML around that point.

> In any case, I think that there are some questions to be solved and we can

If you think getting in a call would help, I would certainly like to
discuss more about it and if required, work towards it.

> On Mon, Nov 21, 2016 at 6:03 AM, Rahul Jadhav <[email-masked]>
> wrote:
>
>> My intent is to allow a dispatch header for SCHC-IPv6. Using this, a
>> gateway receiving a SCHC-compressed packet or a 6Lo compressed packet or a
>> regular IPv6 packet would be able to differentiate between what its
>> receiving and then processing accordingly.
>>
>> @Diego, The dispatch header cannot be clubbed with the SCHC rules i.e. I
>> don't mean that we modify an existing rule to add dispatch header. This
>> would not make sense.
>>
>> @Laurent, As you mentioned, i agree that a dispatch is not incompatible
>> with what you proposed. I just meant that it makes sense to define a
>> dispatch header.
>>
>
>> On 20 Nov 2016 9:41 p.m., "Prof. Diego Dujovne" <
>> [email-masked]> wrote:
>>
>>> Laurent, Rahul:
>>> 2016-11-20 12:26 GMT-03:00 Laurent Toutain <Laurent.Toutain@
>>> telecom-bretagne.eu>:
>>>
>>>> Hi Rahul,
>>>>
>>>> A dispatch can be a good idea to mix LPWAN and 6lo and is not
>>>> incompatible with what we propose. In fact, we don't want to impose global
>>>> values for coding a rule, since it leads to large identifiers (in some
>>>> technologies, the rule ID can be few bits long). Since the rule id is a
>>>> convention between both ends, we can imagine that some values are reserved
>>>> for this dispatch value.
>>>>
>>>> Laurent
>>>>
>>>> On Sat, Nov 19, 2016 at 1:39 PM, Rahul Jadhav <[email-masked]>
>>>> wrote:
>>>>
>>>>> Dear SCHC authors,
>>>>>
>>>>> Imo it has bigger implications and the primary one been that it wont
>>>>> be possible to have different capability (for e.g. SCHC + 6Lo) devices in
>>>>> the same LPWAN connected to the same gateway on the same wireless
>>>>> interface.
>>>>> While this makes sense for a SIGFOX or LoRaWAN like network, I feel
>>>>> for NB-IoT or Wi-Sun where there is a possibility that different capability
>>>>> nodes connect to the gateway on the same interface, the presence of
>>>>> dispatch header might help.
>>>>>
>>>>> My opinion is, a dispatch header defined for SCHC-IPv6 might actually
>>>>> help and the deployment may chose to use it or not.  If the deployment is a
>>>>> pure SCHC based then the dispatch hdr could be omitted (nodes/gw know after
>>>>> it as part of commissioning or something)
>>>>>
>>>>> Regards,
>>>>> Rahul
>>>>>
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Laurent Toutain
>>>> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
>>>> http://class.touta.in
>>>> | [email-masked] <[email-masked]>         |
>>>> [email-masked]    |
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>>
>>>>
>>>
>>>
>>> --
>>> DIEGO DUJOVNE
>>> Profesor Asociado
>>> www.ingenieria.udp.cl
> | Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
> http://class.touta.in
> | [email-masked] <[email-masked]>         | Laurent.Toutain@Telecom-
> Bretagne.eu <[email-masked]>    |
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>
>