Subject: Re: [6lo] Understanding RFC8025 implementation and page switching

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Mar 2017 09:03:01 +0000

Unsure which format would be best, Samita.

There can be a variety of such questions. So maybe a Q&A in the WiKi could collect this sort of questions when they occur?
At least this thread is now visible.

Take care,

Pascal

From: Samita Chakrabarti [mailto:[email-masked]]
Sent: mercredi 1 mars 2017 02:47
To: [email-masked]
Cc: Pascal Thubert (pthubert) <[email-masked]>; lo <[email-masked]>
Subject: Re: [6lo] Understanding RFC8025 implementation and page switching

Thanks Robert, Pascal and Carsten for clarification and order of pages and mesh/frag headers in the context of paging dispatch.
Is there a way to capture these information and tag that with RFC page? This is not an Errata but the order and explanation would be quite useful for the implementers for future extensions.

Alternatively, updating the 6lo wiki  to contain these information would be useful. Any suggestions ?

Thanks,
-Samita

On Mon, Feb 27, 2017 at 9:46 AM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:

On 27 February 2017 at 13:56, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Samita :

From: Samita Chakrabarti [mailto:[email-masked]<mailto:[email-masked]>]

Hello :

I am trying to decipher the RFC 8025  packet header sequence and bit patterns from reading the document and http://www.iana.org/assignments/_6lowpan-parameters/.

Sorry, I should have asked these questions before, but it is never too late...

* I assume the main purpose is to give the implementor tools to go and parse/interprete additional data carried by original RFC 4944 style packet or not.

[Pascal] Yes, we have a very large space now.

* The document says that the page-switch dispatch type should be always preceded by mesh and fragment header. I would assume that original pg 0 or LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if the following sequences are valid ?

[Pascal] The page 0 switch is implicit and placed before the mesh header, which is defined in that page. There can be a packet without a mesh or a fragment header, so a page switch is not always preceded by one of those. But if one of those headers is present, then it appears before switching to another page.

<RCC>
There is nothing stopping definitions for a mesh header equivalent in pages 2-14 and fragment header equivalent in pages 1-14. However, in the context of RFC 8025, mesh and fragment headers are strictly considered as being in page 0, hence having to precede them with a page 0 dispatch, which as Pascal says is implicit at the beginning of a frame, i.e. at the moment we would have:

[(implicit page 0 dispatch)][MESH][FRAG0][page-switch-to-X][New-dispatch-type from page X][Payload]

In the future, one can envisage alternatives however:

[page-switch-to-2][MESH from page 2][FRAG from page 2][New-dispatch-type from page 2][Payload]
</RCC>

1) [Mesh][page-switch-to-X][New-dispatch-type from page X][Payload]
[Pascal] Valid
2) [ESC][ESC-Bytes][LOWPAN_IPHC][page-switch-to-X][Page-X-dispatch][Payload]
[Pascal] I expect that this could happen with an update of RFC 6282, but with the current spec you cannot since RFC6282 defines the chain all the way to the payload or at least the end of the compressed piece.

3) [LOWPAN-IPHC][Payload][page-switch-toX][Page-X-dispatch][additional-payload]
[Pascal] Then again this could happen but would need new specs

If both 2 and 3 are valid sequences, can you please provide two examples of use-cases ?

[Pascal] It could potentially be used for selectively compressing or signing the payload; but  I’m not aware of anyone trying this.
It could also be used for packaging separate fragments back together or something. I do hope that no one ever specifies this based on what I heard from MP-TCP and middle box games.
The most common sequence involving RFC 8025 would be [page-switch-to-Page1] [6LoRH]* [LOWPAN-IPHC] [IPv6 headers]* [LOWPAN-NHC] [Payload]

I was not sure if we can allow payload with each page and parse multiple payloads with the same packet [ assuming we have large enough frame size].
[Pascal] The paging does not say, but new specs using it would.

Take care,

Pascal

Thanks,
-Samita

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Robert Cragie <[email-masked]>
Date: Wed, 1 Mar 2017 10:00:26 +0000

I don't think the RFC is incorrect as it stands and it is arguable that
future "what if's" shouldn't really be captured in an RFC and it should
represent only the state of the art. Therefore, I think the Wiki would be
the right place to do this.

Robert

On 1 March 2017 at 09:03, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> There can be a variety of such questions. So maybe a Q&A in the WiKi could
> collect this sort of questions when they occur?
>
> *From:* Samita Chakrabarti [mailto:[email-masked]]
> *Sent:* mercredi 1 mars 2017 02:47
> *To:* [email-masked]
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; lo <[email-masked]>
> *Subject:* Re: [6lo] Understanding RFC8025 implementation and page
> switching
>
>
>
> Thanks Robert, Pascal and Carsten for clarification and order of pages and
> mesh/frag headers in the context of paging dispatch.
>
> Is there a way to capture these information and tag that with RFC page?
> This is not an Errata but the order and explanation would be quite useful
> for the implementers for future extensions.
>
>
>
> On Mon, Feb 27, 2017 at 9:46 AM, Robert Cragie <
> [email-masked]> wrote:
>
>
>
>
>
> On 27 February 2017 at 13:56, Pascal Thubert (pthubert) <
> [email-masked]> wrote:
>
> Dear Samita :
>
>
>
> *From:* Samita Chakrabarti [mailto:[email-masked]]
>
>
>
> Hello :
>
>
>
> I am trying to decipher the RFC 8025  packet header sequence and bit
> patterns from reading the document and http://www.iana.org/
> assignments/_6lowpan-parameters/.
>
>
>
> * I assume the main purpose is to give the implementor tools to go and
> parse/interprete additional data carried by original RFC 4944 style packet
> or not.
>
>
>
> *[Pascal] Yes, we have a very large space now.*
>
>
>
> * The document says that the page-switch dispatch type should be always
> preceded by mesh and fragment header. I would assume that original pg 0 or
> LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if the
> following sequences are valid ?
>
>
>
> *[Pascal] The page 0 switch is implicit and placed before the mesh header,
> which is defined in that page. There can be a packet without a mesh or a
> fragment header, so a page switch is not always preceded by one of those.
> But if one of those headers is present, then it appears before switching to
> another page.*
>
>
>
> <RCC>
>
> There is nothing stopping definitions for a mesh header equivalent in
> pages 2-14 and fragment header equivalent in pages 1-14. However, in the
> context of RFC 8025, mesh and fragment headers are strictly considered as
> being in page 0, hence having to precede them with a page 0 dispatch, which
> as Pascal says is implicit at the beginning of a frame, i.e. at the moment
> we would have:
>
>
>
> *[Pascal] Valid*
> *[Pascal] I expect that this could happen with an update of RFC 6282, but
> with the current spec you cannot since RFC6282 defines the chain all the
> way to the payload or at least the end of the compressed piece.*
>
>
>
> *[Pascal] Then again this could happen but would need new specs *
>
>
>
>
>
> *[Pascal] It could potentially be used for selectively compressing or
> signing the payload; but  I’m not aware of anyone trying this. *
>
> *It could also be used for packaging separate fragments back together or
> something. I do hope that no one ever specifies this based on what I heard
> from MP-TCP and middle box games.*
>
> *The most common sequence involving RFC 8025 would be *[page-switch-to-Page1]
> [6LoRH]* [LOWPAN-IPHC] [IPv6 headers]* [LOWPAN-NHC] [Payload]
>
>
>
> I was not sure if we can allow payload with each page and parse multiple
> payloads with the same packet [ assuming we have large enough frame size].
>
> *[Pascal] The paging does not say, but new specs using it would.*
>
>
>
> *Take care, *
>
>
>
> *Pascal*
>
>
>
> Thanks,
>
> -Samita
>
>
>
>
> [email-masked]
> [email-masked]

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 1 Mar 2017 09:29:55 -0800

Any volunteers from paging dispatch experts to add a few lines about the
ordering examples and example usage with 6loRH on the 6lo wiki page?
Thanks,
-Samita

On Mar 1, 2017 2:00 AM, "Robert Cragie" <[email-masked]> wrote:

>> There can be a variety of such questions. So maybe a Q&A in the WiKi
>> could collect this sort of questions when they occur?
>>
>> Thanks Robert, Pascal and Carsten for clarification and order of pages
>> and mesh/frag headers in the context of paging dispatch.
>>
>> patterns from reading the document and http://www.iana.org/assign
>> ments/_6lowpan-parameters/.
>>
>>
>>
>> *[Pascal] The page 0 switch is implicit and placed before the mesh
>> header, which is defined in that page. There can be a packet without a mesh
>> or a fragment header, so a page switch is not always preceded by one of
>> those. But if one of those headers is present, then it appears before
>> switching to another page.*
>>
>>
>>
>> <RCC>
>>