Hi Kris Sure works as an encoding technique; but I have issues with using the flow label for 6LoWPAN encoding:
The flow label was initially defined to flag flows that require specific routing/forwading, and such needs might be present in sensors. For instance, ISA has states in forwarding nodes that are indexed by the flow label. Note that ISA100.11a does not use context so allowing flow label to also index the context would not be an issue for that specific standard. Since 2460, there have been a number of attempts to define the flow label to do this or that. This seems to boil down to packet classification with RFC 3697, which specifies to use different flow labels for unrelated transport connections. The format of the flow label is not adapted to the task. We discussed that 16 was a fair number, though some people wanted less than that. 20 bits is certainly a waste, we can't use them all. Now we could structure the flow label and impose that to the future generations bit do we really need that? What I think is that the flow label belongs to the endpoints upper layers, not 6LoWPAN. Th eendpoint stack should not have to worry whether there is a 6LoWPAN hop on the way to figure out how to use the flow label. At the moment, we defined an octet that belongs to 6LoWPAN for 6LoWPAN use in 6LoWPAN headers. I think it is a cleaner layered approach. What do you think? Pascal ________________________________________ From: Kris Pister [mailto:[EMAIL PROTECTED] Sent: samedi 29 novembre 2008 23:12 To: Pascal Thubert (pthubert) Cc: Carsten Bormann; 6lowpan Subject: Re: [6lowpan] context information Pascal - I think that all of the text below works if we add "flow label" to the last sentence of the first paragraph. The index is encoded with either 4 bits or a 20 bit flow label. ksjp Pascal Thubert (pthubert) wrote: Hi Carsten: Since we seem to agree that what we need to define is the interface to the context as opposed to the context content or management, let me propose this change: 2.1.2. Context Identifier Extension This specification expects that an abstract set of states called contexts is shared between the node that compresses a packet and the node(s) that need to expand it. The specification enables to transport an opaque index that is used to lookup the abstract context database. The index in encoded with 4 bits enabling to address up to 16 contexts. This specification requires that services associated to the abstract context database implement an interface to the 6LoWPAN compressor to help compress and uncompress an address based on the parameters passed by the compressor and the information in the abstract context database. The interface MUST provide the methods to lookup a context ID from a prefix and a prefix length for encoding, and reversely lookup a prefix and a prefix length from a context ID for decoding. How the contexts are shared and maintained is out of scope. The actual context information is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. The interface might be extended to allow for further stateful compression, for instance for SAC = 11, additional context information might be used to store the full IPv6 address using the Link layer Address as an additional index. What do you think? Pascal -----Original Message----- From: Carsten Bormann [mailto:[EMAIL PROTECTED] Sent: mercredi 26 novembre 2008 10:37 To: Pascal Thubert (pthubert) Cc: Carsten Bormann; 6lowpan Subject: Re: [6lowpan] context information Second, "What the context information is is out of scope" will only work insofar as HC is not concerned. HC needs 16 byte strings, indexed by a number from 0 to 15. This clearly defines "What the context information is" to a certain extent. I disagree that the specification can only extract 16 values. The specification can only pass 16 context IDs but the parameters in interface do not have to be limited to the context ID. We have short addresses, long addresses, network interface ID, etc... OK, let's try to put this slightly more precisely: My view: The context provides a function f(CID: 0..15) -> byte-string(0..16) Your view: The context provides a function f(CID: 0..15, unspecified stuff) -> byte-string(0..16) While this sure can be made to work, my "interoperability nightmare" bell just went on. But in any case, there *is* a defined interface, except that your version has this additional set of unspecified parameters. Can you explain what you would use it for? How do you make sure "unspecified stuff" is the same at compressor and decompressor? Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
