On 27 February 2017 at 13:56, Pascal Thubert (pthubert) <[email protected]> wrote:
> Dear Samita : > > > > *From:* Samita Chakrabarti [mailto:[email protected]] > > > > 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 protected] > https://www.ietf.org/mailman/listinfo/6lo > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
