[aodvv2-discuss] Metric type -- no longer citing RFC 6551

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Sun, 17 Apr 2016 23:51:52 -0700


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.







Other related posts: