I'm not sure what you mean by Establishment?
The way the context gets to the node. I.e., distribution for all
likely kinds of CEP.
I had in mind that the
context is there by untold magic and ND had to Distribute it. If the
"Context Distribution Protocol" is part of ND then we have to
specify it
there but I'd not expect ND to tell how the context is built in the
first place.
I think the way the context state gets built in the first place (i.e.,
before it is distributed in the area) is a local matter.
It seems to me we agree here.
I can agree that traditional RA might not be the right way, be it only
for reasons of size. OTOH, a node might reactively read the white
board
to get the value of a context entry whenever it needs it so it would
not
need a table but a cache.
Strikes me as a bad strategy; how do you manage your buffer space in
this case?
But it's not ruled out by what I have in mind.
RAs could carry a checksum of the entries;
also, failure to compute the right checksum for a packet could
indicate
that the cache is obsolete.
Internet checksums are rather weak, so this should only be an unlikely
last resort, or we will have regular cases of bad context not being
detected.
What you called an area and I called a scope could be simple if we
agree
it's the subnet.
I just didn't want to make that decision in my message, which was
trying to separate HC and the CEP and focus on HC.
I agree this is the obvious thing to do.
The subnet is the set on which we already do DAD and ND
lookup. A node is free to move within its subnet without renumbering.
Maybe mapping the area to a subnet limits number of contexts but for
sure it keeps things simple and cleanly at L3, as opposed to using
concepts like PAN ID .
Anyway we seem to agree that 16 contexts is a good number.
Two other numbers could be considered:
8 (needs 2x3 bits)
11 (needs 7 bits and a division, maybe not so great; leaves 7 patterns
for special cases).
Also, the number could be 16-n if we reserve n bit patterns for
specific purposes (e.g., indicating link-local, no context; useful if
we want to get rid of DDF).
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
