Hi Charlie,
great, thanks! I was a bit tired when I read that thread, so I wanted to make
sure someone who knows what’s going on has a look at the fix too :D We also
need to add a reference to RFC 7779, don’t we? And do we need some text about
loopfree() etc with this metric?
And does Thomas’ recent E-Mail change anything? I’m thinking that his „the
protocol shouldn’t care what the metric is, as long as it’s additive and within
a certain range“ is an appealing point (I’ve been a fan of that idea for quite
a while now), but that would clash with our loopfree() thing, right?
Best regards,
Lotte
Am 20.04.2016 um 03:11 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
Hello Lotte,
The DAT metric can be allocated as Metric Type 2.
The IANA Considerations counterpart (describing how IANA should allocate the
table) should list something as the reference for it.
How's this:
+---------------------+----------+--------------------+
| Name of MetricType | Type | Metric Value Size |
+---------------------+----------+--------------------+
| Unassigned | 0 | Undefined |
| Hop Count | 1 | 1 octet |
| DAT metric | 2 | 4 octets |
| Unallocated | 3 - 254 | TBD |
| Reserved | 255 | Undefined |
+---------------------+----------+--------------------+
If it's not 32 bits, please make the appropriate modification.
Regards,
Charlie P.
PS. I will be back a little later and tackle the rest of the email tonight.
On 4/19/2016 3:21 PM, Lotte Steenbrink wrote:
Hi Charlie, hi all,
thanks for figuring all of this out! I’ve read the E-Mails in this thread
and on [manet] and it seems to me that you’ve found a solution that
everyone’s happy with. However, I’m afraid you’ve lost me at some point– can
you tell me which modifications other than the ones written down by Charlie
in the E-Mail below I’ll have to make? If I understood it correctly, we need
to allocate some (generic?) space for the DAT metric as well, right?
Best regards,
Lotte
Am 18.04.2016 um 08:51 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
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 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.
