Hello Stan,
I think we should target getting the next draft out this week. If the
Security Considerations is good, then I don't remember any other major
questions after the Metric Type.
There's something about knowing when RREP_Ack timeout occurs. I will
write text for that today.
Regards,
Charlie P.
On 4/18/2016 6:46 AM, Ratliff, Stanley wrote:
It will have to be added to the IANA considerations section as well.
What does this bring our list of to-dos down to? I’m getting **intense** heat.
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *John Dowdell
*Sent:* Monday, April 18, 2016 9:43 AM
*To:* AODVv2 Discuss <aodvv2-discuss@xxxxxxxxxxxxx>
*Subject:* [aodvv2-discuss] Re: Metric type -- no longer citing RFC 6551
On 18 Apr 2016, at 10:30, Victoria Mercieca <vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx>> wrote:
No objection here, and perhaps you might also mention those metric
types in the discussion I started, giving the length of the value
field that is appropriate for each, as I don't know what to say
next! :)
Kind regards,
Vicky.
Happy with that too. It would be good to keep these as separate drafts but at the same time validate the main draft for adding metrics.
On Mon, Apr 18, 2016 at 7:51 AM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello folks,
After extensive discussion with various people, I think there
does not exist today a suitable IETF registry for
protocol-independent link metrics.
In our case, the cure is simple. RFC 6551 was only cited in
section 11.6. That section can be easily modified to lose the
citation. The result is:
11.6. MetricType Allocation
The metric types used by AODVv2 are identified according to
a new
table to be created and maintained by IANA. All
implementations MUST
use these values.
+---------------------+----------+--------------------+
| Name of MetricType | Type | Metric Value Size |
+---------------------+----------+--------------------+
| Unassigned | 0 | Undefined |
| Hop Count | 1 | 1 octet |
| Unallocated | 2 - 254 | TBD |
| Reserved | 255 | Undefined |
+---------------------+----------+--------------------+
Table 7: AODVv2 Metric Types
If there is no objection, I would like to propose this to the
list tomorrow. It's almost guaranteed to be the solution with
the least perturbation to the existing text.
I also have drafts for the following additive cost link metrics:
- Transmission duration per bit
- ETX / ERX (expected retransmission count)
- Received Signal Weakness (allows selection of route with
highest signal strength)
The transmission time per bit is an interesting one; guess this corresponds to more or less complex modulation schemes and therefore likelihood of being successfully received in noisy environments. However, don’t the wireless devices work that out for themselves, and how will you get the modem to notify the modulation scheme back up through the RFC5444 multiplexer mechanism? This is maybe a thing that DLEP can help with; there are a number of extension drafts active for DLEP right now, and all three (or at least the first two) could be candidates.
Regards
John
The last two conform to IEEE 802.15.10 definitions which have
been discussed pretty thoroughly.
I don't propose to make AODVv2 in any way dependent on these
metric documents, but they should be considered for use with
AODVv2. On the other hand, if you folks want them to
supplement hop count, I am totally at your service. I've also
looked at RFC 7185. I think those metrics can easily be
specified to be protocol-neutral.
Longer term, I think there is a good chance that the above
table would be subsumed in a protocol-independent registry,
but we can't wait on that. I have a lot more information
about this if you are interested. I am not the only
interested in creating such a registry. Don't be surprised if
there's a BoF.
Regards,
Charlie P.
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
