Hello Vicky,
We should keep Loop_Free() because it exactly states what is needed. It
also allows for non-additive cost metrics that may require different
criteria to assure loop freedom.
Regards,
Charlie P.
On 4/20/2016 1:43 AM, Victoria Mercieca wrote:
Well, our LoopFree expression applies to all additive strictly increasing (or whatever that phrase was) metrics, so maybe it doesn't need extra text.
But I quite like Thomas' idea that maybe we dont need to refer to a specific metric type at all. In which case we could probably remove the text about "what you need to define to add a new metric type"? Just making sure that we state this draft definitely only works for additive strictly increasing metric types. Makes it clean and simple and more like OLSRv2!
Kind regards,
Vicky.
On 20 Apr 2016 09:08, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
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
<mailto: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
<mailto: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.
>>
>>
