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 protected]> wrote: > 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 protected]> > wrote: > >> 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 protected]] >> *Sent:* mercredi 1 mars 2017 02:47 >> *To:* [email protected] >> *Cc:* Pascal Thubert (pthubert) <[email protected]>; lo <[email protected]> >> *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 protected]> wrote: >> >> >> >> >> >> 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/assign >> ments/_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][add >> itional-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 >> >> >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
