[ Sorry for cross-post but given how this is about ANIMA GRASP, a CBOR
protocol, i think its the best/fastest way to converge. ]
In GRASP (RFC8990] we define the GRASP message structure as follows:
message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option]
MESSAGE_TYPE = 0..255
session-id = 0..4294967295 ; up to 32 bits
grasp-option = any
Then we've defined a few MESSAGE_TYPEs of which the one we are primarily
interested in now is:
flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]]
(its also the most difficult one).
objective = [ objective-name, objective-flags, loop-count, ?objective-value ]
objective-name = text
objective-value = any
[ Not official GRASP language, but i always think of the objective to be the
payload and the rest of the message to be the GRASP header. ]
The M_FLOOD message is already something special because all other GRASP
message types we have only have at most one objective, but because M_FLOOD
multicasts the message, we wanted the optimization to send fewer multicast
packets by coalescing them (good for low-power IoT devices).
So now the question is how we want to generically as possible extend the header.
Our specific first goal is a signature extension, but hopefully we don't
need to discuss this here (in this thread), as its not a CBOR/CDDL encoding
question.
Brians suggestion, if i understand him right would be something like this:
EXTENSION_TYPE = 0..255
grasp-extension = [ EXTENSION_TYPE, *any ]
grasp-option /= grasp-extension
flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])], *grasp-option ]
Lets look at three different messages:
A) [M_FLOOD, session-id, initiator, ttl,
[ [ "objective1", ...] , locator-option ], [ [ "objective2",
...], locator-option ] ]
(A1) (A2) (A3) (A4)
B) [M_FLOOD, session-id, initiator, ttl,
[ ["objective1", ...], locator-option ], [ 115, whatever ]]
(B1) (B2) (B3) (B4)
C) [M_FLOOD, session-id, initiator, ttl,
[ ["objective1", ...], locator-option ], somethingelse, [ 115,
whatever ]]
(C1) (C2) (C3) (C4) (C5)
When receiving message A, and looking after ttl, the next element in the array,
(A1)
is itself an array, AND the first element of that array is also an array, so
this can only be an objective. Likewise logic for (A3), (A4).
When receiving B), same logic for (B1), (B2), then after (B3) the check is that
the first
element of the array is of type numeric (B4) instead of array, so this must be a
grasp-extension.
When receiving C), same logic for (C1), (C2), but then at (C3) the array
element is
not of type array itself, so it can't contain an objective nor can it be a
grasp-extension.
But it is still matching the any of grasp-option, so its still a valid M_FLOOD
grasp
messages and simply needs to be ignored (maybe we later on come up with
additional stuff
that wouldn't be an array... And then at (C4), (C5) the logic to recognize a
grasp-extension.
Questions:
- Is it ok. to expect the analysis to have to do two steps (e.g.: A1, A2 or B3,
B4)
to decide whats' next (i called that lookahead in another mail thread).
- does "grasp-option /= grasp-extension" work. I ask because previously
grasp-option
was "any", so logically i am not sure if CDDL expect to pick the alternative
that
is more specific, so that we can ensure that grasp-extension is always the
option
that MUST be used if it matches - instead of any.
- So everything ok ? or any other concerns ?
Cheers
toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
