[aodvv2-discuss] Re: metric comments
- From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Wed, 18 Mar 2015 13:31:39 -0700
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 casethasextlen==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:
