[aodvv2-discuss] Re: metric comments
- From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Fri, 20 Mar 2015 19:59:33 +0100
Hi Victoria,
Am 19.03.2015 um 11:39 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
> Hi both,
>
> I think the way Lotte has written it looks good. We still refer to a
> MetricType data element as part of AODVv2, but in Section 10 it now maps to
> the extension byte of the Metric Address Block TLV. We could shift the order
> around in Section 9 for RREQ and RREP, so that the MetricType element is next
> to the Metric data element? And put the numbered steps in matching order. The
> current text is still correct:
> "If MetricType is not DEFAULT_METRIC_TYPE, include the MetricType data
> element and set the type accordingly."
> Then the AODVv2->RFC5444 mapping puts that info in the RFC5444 formatted
> message in the type extension instead of the MetricType message TLV.
>
> When you say 0x0a and 0x0a05 and 0x0a03, do you mean than the 0a represents
> the TLV type value of 10 (for Metric), and the 05 or 03 (or lack of value)
> represents the metric type?
> I was looking at RFC5444 again and as far as I understand it, we're looking
> at this one from Section D6 - for a non-default metric?:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type |1|0|0|1|0|M|Rsv| Type Ext | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> | Value |
> | |
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> +-+-+-+-+-+-+-+-+
>
> For RERR, either we have (in Section 10) two things that our MetricType data
> element can map to (both the type extension and the MetricType Message TLV we
> already defined), or, would it be sensible to omit the MetricType message TLV
> and include a Metric Address Block TLV in the RERR instead, with the
> extension type as necessary, omit the metric value itself, and have this TLV
> apply to all addresses included in the AddressBlock?
I think that's an excellent idea. If I remember it correctly, RFC5444 actually
does this by default: If all addresses of an Address block are associated with
a TLV t_i, and all t_i are similar to each other, a RFC5444 builder will
automagically only append one TLV to the Address block and specify that it is
associated with the entire range of the Address Block.
> More like this example, also from D6 in RFC5444?:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type |1|0|0|0|0|0|Rsv| Type Ext |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Regards,
> Vicky.
>
> On Wed, Mar 18, 2015 at 8:31 PM, Charlie Perkins
> <charles.perkins@xxxxxxxxxxxxx> wrote:
> Hello Lotte,
>
> As I understand it the new proposal was to do away with the MetricType
> TLV in RREQ and RREP messages, because the information is included as
> part of the extension byte to the Metric Address Block TLV.
>
> To save the trouble of searching RFC 5444, here is the relevant
> text:
>
>
> +-----------+------------+--------------+---------------------------+
> | thasvalue | thasextlen | <length> | <value> |
> +-----------+------------+--------------+---------------------------+
> | 0 | 0 | not included | not included |
> | 1 | 0 | 8 bits | included unless <length> |
> | | | | is zero |
> | 1 | 1 | 16 bits | included unless <length> |
> | | | | is zero |
> +-----------+------------+--------------+---------------------------+
>
> Table 4: Interpretation of the thasvalue and thasextlen flags
>
> <tlv-type-ext> is an 8-bit unsigned integer field, specifying an
> extension of the TLV Type, specific to the TLV Type and kind
> (i.e., Packet TLV, Message TLV, or Address Block TLV).
>
> tlv-type-ext is a variable, defined to equal <tlv-type-ext>, if
> present, or 0 otherwise.
>
>
> So, let's say that IANA allocates type 10 to the Metric Address Block TLV.
> If the flag thasextlen is 0, then a type 10 Address Block TLV (i.e., Metric)
> means that the metric type to be used is DEFAULT_METRIC_TYPE (i.e., HopCount).
>
> If thasextlen is 1, then the extension byte contains the Metric Type, as
> tabulated in RFC 6551. HopCount, by the way is type 3 in RFC 6551.
>
> So, we would have 0x0a to mean HopCount, and 0x0a05 to be Link Latency.
> In the first case thasextlen==0 and in the second case thasextlen==1.
> Also 0x0a03 means HopCount with thasextlen==1.
>
> We still need to have MetricType Message TLV to describe what the Metric
> Type is for the broken routes.
>
> I have made updates to the specification according to the above. There are
> interesting questions, though. For RREQ and RREP, the MetricType data
> element is to be translated into an extension byte for the Metric Address
> Block TLV. I don't know how to specify this without exhibiting internal
> knowledge of RFC 5444 in the AODVv2 specification.
>
> For RERR, the MetricType data element translates into the MetricType
> Message TLV (not into anything related to the Metric Address Block TLV).
>
> Is this O.K.?
>
> Regards,
> Charlie P.
>
>
>
>
> On 3/16/2015 1:56 PM, Lotte Steenbrink wrote:
>> Hi all,
>>
>> Am 04.03.2015 um 15:54 schrieb Lotte Steenbrink
>> <lotte.steenbrink@xxxxxxxxxxxxxx>:
>>
>>> Am 04.03.2015 um 15:50 schrieb Charlie Perkins
>>> <charles.perkins@xxxxxxxxxxxxx>:
>>>
>>>> Hello Lotte,
>>>>
>>>> Small follow-up below...
>>>>
>>>> On 3/4/2015 3:10 AM, Lotte Steenbrink wrote:
>>>>>> I will respond to this. I am O.K. with having the metric type be an
>>>>>> extension
>>>>>> type for the Metric.
>>>> So let's do this...
>>>>
>>>>> Well, when we're talking IoT, we're talking environments in which Hop
>>>>> Count has been shown to deliver suboptimal results, if I remember the
>>>>> research right. So IoT deployments most likely need other (new,
>>>>> experimental?) metrics. By forcing them to add an additional MetricType
>>>>> TLV, we're essentially penalizing environments which very much rely on
>>>>> having smaller packets...
>>>> What if in general we use Metric + extension type, but for HopCount we
>>>> just use Metric?
>>> That could be a compromise.. Let me think about that.
>>>
>>>>> Nope, there wasn't but I could start one ;)
>>>> Please do...
>>> Will do :)
>>>
>> So, after this has been done and has even spawned some feedback (yay!), I've
>> put together a suggestion to incorporate extension types, as well as having
>> DEFAULT_METRIC_TYPE be of value 0 and always set, as suggested by Henning.
>> Since most of the draft is not 5444-specific, I mostly had to update section
>> 10 and the algorithms. Before I post anything to the list, I thought I'd
>> share with you folks in case I messed up something in the algorithms section
>> or anything is unclear.
>> I know Dallas is close, but in case somebody can find some time...
>>
>> Cheers,
>> Lotte
>>
>>
>>
>>
>>>> but I will go ahead and issue revision 7 without this
>>>> feature. The deadline is coming very soon.
>>> Of course!
>>>
>>>> If the discussion is
>>>> smooth, we can issue a revision 8 before the actual meeting.
>>>>
>>>> Regards,
>>>> Charlie P.
>>>>
>
>
Other related posts:
