[aodvv2-discuss] Re: packet_sketch.md
- From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Sun, 11 Jan 2015 22:11:24 +0100
Hi Charlie, hi all,
Am 09.01.2015 um 21:31 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
> Hello folks,
>
> A few comments interspersed:
>
>
>> In Honolulu, we talked about having some kind of visual representation of
>> what we want our RFC5444 packets to look like. I promised to post the output
>> of Henning's oonf api in order to show what I implemented. I think this may
>> help to talk about what the RFC5444 packets should actually look like.
>>
>> Here we go: I implemented what I called the “verbose version” in my review.
>> Apparently that was wrong, but anyway-- here's what I came up with. (I
>> disregarded prefixlengths entirely because of my scope limitation, though).
>> The Sketches are basically what falls out of the oonf api when you call the
>> rfc5444_print_direct() function of the oonf api.
>>
>> RREQ
>>
>> ,------------------
>> | PACKET
>> |------------------
>> | * Packet version: 0
>> | * Packet flags: 0x0
>> | ,-------------------
>> | | MESSAGE
>> | |-------------------
>> | | * Message type: 10
>> | | * Message flags: 0x40
>> | | * Address length: 16
>> | | * Hop limit: 18
>> | | ,-------------------
>> | | | Address: fe80::ff:fe00:1fad
>> | | | | - TLV
>> | | | | Flags = 0x50
>> | | | | Type = OrigSeqNum
>> | | | | Value length: 2
>> | | | | 0000: 0100
>> | | | | - TLV
>> | | | | Flags = 0xd0
>> | | | | Type = Metric; Type ext. = DEFAULT_METRIC_TYPE
>> | | | | Value length: 1
>> | | | | 0000: 02
>> | | `-------------------
>> | | ,-------------------
>> | | | Address: fe80::ff:fe00:1fa4
>> | | `-------------------
>> | `-------------------
>> `------------------
>
> It would be straightforward to add an appendix with this style of
> representation.
> The values shown for the flags fields, and some other fields, would require
> more text, but not more than a few hours of work. But, for instance, we have
> been warned against describing which flags to specify, so that makes the idea
> tricky. I look forward to further discussion on this matter...
No, you're completely right, especially since I was always the one complaining
about the flags. I removed them from my suggested illustration in the Appendix
(see packet_sketch-from-master.diff.html), but I didn't update the markdown
file. Will do that now.
>
>
>> The OrigNode Address fe80::ff:fe00:1fad is associated with 2 TLVs:
>> OrigSeqNum_TLV(Type = 0, identifying the Address as an OrigNode Address) and
>> Metric_TLV (Type = 3). The Metric TLV also has an extension type to specify
>> the Type of the Metric whose value is embedded in the TLV (in this case,
>> DEFAULT_METRIC_TYPE, which is 3). If I understand the Draft correctly, it
>> states that an additional TLV devoted to the Metric Type should be added,
>>
>
> The Metric Type TLV is optional, and not needed unless the metric
> type is not the default metric type.
...Or if we use extension types ;)
>
>> IIRC, the draft states that TargNode Addresses of a RREQ do not need to be
>> associated with any TLV at all, so my parser just assumes that an Address in
>> a Message of type RREQ without a TLV is a TargNode Address. This made
>> Henning cringe, I think.
>>
>
> I don't know why...! RFC 5444 was explicitly constructed to enable assignment
> of TLV values to a proper subset of the addresses -- even to one single
> address
> as may be necessary from the protocol design standpoint.
>
IIRC (and that particular conversation happened a long time ago, so I might
not), he said that while this is legal, it is not very explicit. It may lead to
semantically erroneous packets being assumed to be valid and wrong addresses
being interpreted as TargNode addresses. And that this „loophole“ may be
unintuitive for people less experienced with AODVv2, for example when they read
(underdocumented ;) ) code. I do think this makes sense, especially from an
implementor's point of view, but I'm lacking the experience to be able to tell
if this convenience is worth the additional payload size. I short: I won't
start a riot if this is just kept as it is.
Cheers,
Lotte
> Let's decide soon if this style of presentation is helpful to other people.
>
> Regards,
> Charlie P.
Other related posts:
