Hi Lotte,
+1 for publishing without this update finished.
The minimum change in this topic is to remove any reference to 6551. The
table can stay as is but with the text above it changed to remove 6551.
Kind regards,
Vicky.
On Wed, Apr 20, 2016 at 4:54 PM, Ratliff, Stanley <sratliff@xxxxxxxxxxx>
wrote:
Lotte,
If there are open questions, we will need to post, then ask as you
suggest. Unfortunately, our deadline is hard.
Regards,
Stan
*From:* aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:
aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Lotte Steenbrink
*Sent:* Wednesday, April 20, 2016 11:53 AM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] Re: Metric type -- no longer citing RFC 6551
Hi,
So I’ve been going through the draft to make the appropriate changes, but
I think this is going to take more time than I estimated…I’ve got some open
questions and I don’t think I’ll be able to make it until 12 EST. Shall we
publish without and run a suggestion by the WG (in the metrics thread) by
Friday?
Am 20.04.2016 um 10:43 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
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>
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>:
the table) should list something as the reference for it.
Hello Lotte,
The DAT metric can be allocated as Metric Type 2.
The IANA Considerations counterpart (describing how IANA should allocate
tonight.
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
thread and on [manet] and it seems to me that you’ve found a solution that
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
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?
charles.perkins@xxxxxxxxxxxxx>:
Best regards,
Lotte
Am 18.04.2016 um 08:51 schrieb Charlie Perkins <
exist today a suitable IETF registry for protocol-independent link metrics.
Hello folks,
After extensive discussion with various people, I think there does not
11.6. That section can be easily modified to lose the citation. The result
In our case, the cure is simple. RFC 6551 was only cited in section
is:
tomorrow. It's almost guaranteed to be the solution with the least
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
perturbation to the existing text.
signal strength)
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
discussed pretty thoroughly.
The last two conform to IEEE 802.15.10 definitions which have been
documents, but they should be considered for use with AODVv2. On the other
I don't propose to make AODVv2 in any way dependent on these metric
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.
be subsumed in a protocol-independent registry, but we can't wait on that.
Longer term, I think there is a good chance that the above table would
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.
_____________________________________________________
