[aodvv2-discuss] Re: metric comments
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Thu, 19 Mar 2015 10:39:21 +0000
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? 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> <lotte.steenbrink@xxxxxxxxxxxxxx>:
>
>
> Am 04.03.2015 um 15:50 schrieb Charlie Perkins
> <charles.perkins@xxxxxxxxxxxxx> <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:
