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
