Am 24.06.2015 um 12:53 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Attached are Section 8 and 12 based on the latest comments...
These can be sent to MANET if you like (I will let someone else do this to
give a chance to check it).
Kind regards,
Vicky.
On Wed, Jun 24, 2015 at 11:14 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Hi Lotte,
On Wed, Jun 24, 2015 at 10:55 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, hi all,
Am 24.06.2015 um 10:39 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte, everyone,
Also in response to Henning's comment about the word "optional" being
included in Section 8... e.g. in this bit:
| TargMetric | PATH_METRIC | MetricType | Metric for the route |
| /MetricType | | (optional) | to TargAddr, using |
| | | | MetricType. |
| ValidityTime | VALIDITY_TIME | 0 | ValidityTime for |
| (optional) | | | route to TargAddr. |
+--------------+---------------+------------+-----------------------+
...If we included the MetricType data element in our AODVv2 message, its not
optional to include it in the RFC5444 representation.
Same for ValidityTime. We've explained which data elements are optional in
Section 7, so should we simplify Section 8 by removing the word "optional"?
Good point! I'd say yes.
One adjacent thing though: Some subsections of Section 8 say:
In the AODVv2 representation, if the message relates to
DEFAULT_METRIC_TYPE, MetricType is not included in the message. The
RFC 5444 representation will set the extension type in the
PATH_METRIC TLV to 0. AODVv2 interprets a MetricType of 0 as
DEFAULT_METRIC_TYPE.
But section 11.4 just says:
+----------------------+----------------------+----------------+
| Name | Default | Description |
+----------------------+----------------------+----------------+
| DEFAULT_METRIC_TYPE | 3 (i.e., Hop Count) | [RFC6551] |
Do we need to adjust the numbers/wording here to make our 0 ->
DEFAULT_METRIC_TYPE trick more clear here?
This is tricky. HopCount is always MetricType 3. But because it's our
default, we can omit it, which means RFC5444 effectively sets MetricType = 0,
and might report MetricType = zero to AODVv2 for a received message, which
AODVv2 needs to interpret as MetricType = DEFAULT_METRIC_TYPE.
Should we say in 11.4...?:
"As described in Section 8, when using DEFAULT_METRIC_TYPE, the MetricType
data element does not need to be included in AODVv2 messages. The absence of
a MetricType data element will be handled by RFC 5444 by reporting a
MetricType of zero. AODVv2 will interpret a MetricType of zero to be
DEFAULT_METRIC_TYPE."
Regards,
Vicky.
And the point about how to set values if you receive a message without
certain TLVs? I think this is covered already in Section 7.
In section 8 we've already explained for MetricType what happens if
MetricType wasnt included in the AODVv2 message. I've also included in each
part of Section 8 "If the prefix length has not been included in the AODVv2
message, it is equal to the address length in bits."
For TargSeqNum in RREQ, ValidityTime, AckReq, PktSource, SeqNumList, do we
need any explanation for what it means if its not included? I think thats
clear enough from section 7.
I agree.
For MetricTypeList, if all metric types are default metric type, we wouldnt
include the PATH_METRIC TLV, but our section 8 seems to indicate that we
would include a PATH_METRIC TLV, and set extension type to 0 to indicate the
default metric. I might change this for the RERR section, to:
"In the AODVv2 representation, if the RERR message includes only routes with
DEFAULT_METRIC_TYPE, MetricType is not included in the message. The RFC
5444 representation does not need to include a PATH_METRIC TLV to indicate
the DEFAULT_METRIC_TYPE. If the RERR message contains a mixture of routes
using DEFAULT_METRIC_TYPE and other metric types, only the routes with
non-default metric type need to be marked with a PATH_METRIC TLV to indicate
the MetricType. AODVv2 interprets an absence of MetricType information as an
indication of DEFAULT_METRIC_TYPE."
What do you think?
Sounds good to me.
Regards,
Lotte
Kind regards,
Vicky.
On Wed, Jun 24, 2015 at 9:34 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Am 24.06.2015 um 09:41 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
done :)
Thanks! :)
As discussed yesterday, I'll send our changes to the MANET list then, okay?
On Tue, Jun 23, 2015 at 9:44 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, hi all,
Am 23.06.2015 um 19:42 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,
Thanks so much Lotte!
I've replaced Section 8 in the draft and updated section 12 based on
Lotte's updates. Attached are the new section 8 and 12. I only had a very
quick proofread so I leave it with you guys.
two quibbles:
In Section 12.3., the Length of the new ADDRESS_TYPE TLV Type is specified
as “depends on contents”... Would it make sense to set this to 1 octet? I'd
be thrilled to see hundreds of different AODVv2 extensions which all need
their own Address Type, but I don't think it's very likely to happen...
Also, I noticed that Table 9 says Length (octets) and Table 10 says Length
(and then octets in the table when necessary), would it make sense to unify
this by moving the “octets” into the row of Table 10?
Regards,
Lotte
Kind regards,
Vicky.
On Tue, Jun 23, 2015 at 6:03 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi all,
Vicky was so kind as to provide me with the pandoc for section 8, so
attached you'll find my modified version.
Additional changes we need to make are:
- 12.3. RFC 5444 Address Block TLV Types: add new entry for ADDRESS_TYPE
- 12.3. RFC 5444 Address Block TLV Types: remove entries for ORIG_SEQ_NUM
and TARG_SEQ_NUM
- add a table for all address type values:
Address Type Value
------------ -----
ADDR_TYPE_ORIG_ADDR 0
ADDR_TYPE_TARG_ADDR 1
ADDR_TYPE_UNREACHABLE 2
ADDR_TYPE_PKT_SRC 3
(I'm not quite happy with the naming, please change at will)
Regards,
Lotte
Am 23.06.2015 um 17:53 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx>:
Hi Vicky,
Am 23.06.2015 um 17:51 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,
After our discussion with Henning, I have one small question - what name
are we going to use for this TLV?
"Address Meaning" isn't the best :) is "Address Type" better?
Sounds good to me, but I'm not a native speaker :)
Regards,
Lotte
Regards,
Vicky.
On Tue, Jun 23, 2015 at 12:41 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Am 22.06.2015 um 18:33 schrieb Ratliff, Stanley <sratliff@xxxxxxxxxxx>:
Yes.
Okay great. As a reminder; I've created the google hangout event for
today, if anyone didn't get an invite but wants to attend please ping me.
Stan
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Victoria
Mercieca
Sent: Monday, June 22, 2015 12:05 PM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: "Address meaning" TLV
Yes :)
Vicky.
On Mon, Jun 22, 2015 at 5:02 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi all,
so Henning said Tuesday or Thursday at 5 our time (i.e. the usual time
of our hangouts) would be fine. I'd suggest meeting tomorrow to get the
issue done as soon as possible. Is everyone who is interested in the
topic okay with this?
Cheers,
Lotte
Am 22.06.2015 um 16:56 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx>:
Am 22.06.2015 um 16:54 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
I have no problem with including Henning (though it is very short
notice now!!)
I know, I thought I'd wait for answers and then totally forgot about
it.. I'll just ping him and see if he responds.
Vicky.
On Mon, Jun 22, 2015 at 3:47 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Am 21.06.2015 um 19:38 schrieb John Dowdell <john.dowdell486@xxxxxxxxx>:
Hmm interesting.
Do we want to invite him to the call tomorrow?
So I'm assuming the answer is no?
John
From: Lotte Steenbrink
Sent: 21/06/2015 15:12
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: "Address meaning" TLV
Hi all,
just FYI: Henning just asked via chat if we wanted his input on the
whole TLV restructuring thing. I told him about Vickys idea for an
Address Meaning TLV, and he thought it was a good idea too– provided we
don't leave the TLV empty anywhere.
Regards,
Lotte
Am 17.06.2015 um 14:29 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,
Thanks for your comment Justin, sorry it took me a while to notice it!
Comments in line:
On Tue, Jun 16, 2015 at 12:32 PM, bebemaster <bebemaster@xxxxxxxxx>
wrote:
Sent on a Virgin Mobile Samsung Galaxy S® III
-------- Original message --------
From: Victoria Mercieca
Date:06/16/2015 3:20 AM (GMT-05:00)
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: "Address meaning" TLV
Hi Lotte,
On Mon, Jun 15, 2015 at 7:01 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky,
wow, that's a lot of e-mails in one afternoon :o Just two quick
comments, then I'll work my way through your tables...
Am 15.06.2015 um 19:13 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi all,
I dont know if you picked up on Chris Dearlove's comment on MANET a
little while ago?
http://www.ietf.org/mail-archive/web/manet/current/msg17669.html He
proposed some sort of TLV specifically used to indicate what the
addresses mean, using the idea in Appendix C2 of RFC5444. If we took
that approach, we could avoid needing separate TLVs for OrigSeqNum and
TargSeqNum, we could even use multi-value TLVs where we would have
included 2 separate TLVs before. We wouldnt need the PktSource TLV
either.
I had a think about this idea... here's what I came up with. I'm sure I
will have made some mistakes so comments are welcome.
The "Address Meaning" TLV would have values defined, e.g. OrigAddr = 1,
TargAddr = 2, PktSource = 3, Unreachable Address = 4. Ideally
"Unreachable Address" would be the default value and we could omit it,
avoiding the extra length in RERR messages (maybe this means it should
have the value 0 instead?).
So for a RREQ, there are 2 addresses in the Address Block, we'd have an
"Address Meaning" TLV with two values as Chris suggested, values being
1 and 2. It doesnt need index values because its providing a list of
values, one for every address in the Address Block.
This could be the compromise we have been looking for... Charlie, What
do you think?
In a RERR, there may be a PktSource address and 'x' Unreachable
Addresses. So the "Address Meaning" TLV would have 1 value (ie value of
3 if using the values defined above) with an index for the PktSource
address. If we make unreachable address the default, we can leave it at
that. Alternatively, if it was necessary to indicate unreachable
addresses explicitly with the "meaning" value defined above, the
message could either have one "Address Meaning" multivalue TLV with a
list of values, 1 value for each address, or it may be more efficient
to have one "Address Meaning" TLV for PktSource, giving the meaning
value and index, and another "Address Meaning" TLV, with the value for
unreachable addresses, with index start and index stop? I guess the
parser would decide which way is more efficient.
I tried to look at how it would compare byte-wise.
TLVs have 1 byte for type, 1 byte for flags, 1 byte for length,
potentially 1 for index, or 2 for index values if giving start and stop
index values + more bytes for the value field, size dependent on TLV
type.
The "Address Meaning" TLV has: type + flags + length (3 bytes) +
potentially 0, 1, or 2 bytes for index values, + 1 byte for each actual
value. The options for total length of this TLV are:
3 + num addresses
or 3 + index + value
or 3 + index start + index stop + value
For RERR, if unreachable address is the default, we could omit the
"Address Meaning" TLV. We would need it if there was a PktSource
address included, and it would need 1 value and an index value for it
(total length = 3 + 1 byte for value + 1 byte for index = 5 bytes).
But wouldn't we be back to the “no addresses without a TLV attached
allowed” discussion then?
That's true, hmm.... re-reading RFC5444 Appendix C2, it looks like we
can omit one value if it's the default, but if that is the only value
we were including, do we still have to include the TLV? Maybe we set no
value in it? Do we need index values?
You can omit a value, the tlv alone can impart positive information. If
the only value us the omitted value the tlv still need be attached to
impart that default information, just without a value field. If all
addresses (in an address block) have a default value no indexes are
needed. So it depends on the values to be attached to the addresses and
how the address block is organized.
So... in the text below, the "Address Meaning" TLV has a total length
of 3 for RERR when there's no PktSource.
All existing seqnum TLVs have total length 6 when we include an index
and a value, or 4 if we just include an index and no value, i.e. if
seqnum is unknown. If we change to use "Address Meaning" TLV, we no
longer need 3 different seqnum TLVs. We can use a generic seqnum TLV
and include multiple values in the one TLV if we know them, rather than
use multiple TLV types to hold one seqNum value each.
To compare the approaches (current = using a variety of TLVs to
identify addresses, proposed = using the "Address Meaning" TLV idea)
and ignoring all unchanged TLVs:
----------------------------------------------
RREQ
----------------------------------------------
current proposed
orig seq num tlv 6
targ seq num tlv 6 or 4
addr meaning tlv 5
seq num tlv (1value) 6 (type, length, flags, index, 2byte value)
seq num tlv (2values) 7 (type, length, flags, 4bytes containing 2
values)
--------------------------------------------------------------------
total
(no TargSeqNum value) 10 11
This could be more likely - if we dont know a previous seqnum for
targaddr of a rreq
(if TargSeqNum value) 12 12
This is the ideal case anyway to help out any nodes doing iRREP
----------------------------------------------
RREP
----------------------------------------------
current proposed
orig seq num tlv (no val) 4
targ seq num tlv 6
addr meaning tlv 5
seq num tlv (1val) 6 (type, length, flags, index, 2 byte value)
----------------------------------------------
total 10 11
Proposed version doesnt need OrigSeqNum TLV to indicate OrigAddr,
doesnt need a SeqNum value for OrigAddr at all.
----------------------------------------------
RERR with PktSource
----------------------------------------------
Assuming we have to identify unreachable addresses with a seqnum TLV,
we would set no value, but need index start and maybe index stop to
identify address(es), this gives 4 or 5 bytes.
current proposed
pktsrc 4 (type, length, flags, index)
seqnum (no val) 4 or 5 (type, length,
flags, index start, (index stop))
addr meaning tlv 5
If unreachable addr is seen as default and omitted, and index is
included only for pktsource.
------------------------------------------------------------------------
total 8 or 9 5
----------------------------------------------
RERR without PktSource
----------------------------------------------
Again, if we have to identify unreachable addresses with a seqnum TLV,
we would set no value, but need index start and maybe index stop to
identify address(es), this gives 4 or 5 bytes.
If only 1 address included, do we still need index?
current proposed
seqnum (no val) 4 or 5 (type flags length
index (index stop?))
0
Don't need an address meaning TLV if we have unreachable address as the
default value and it can be omitted.
We do need the address meaning TLV but it doesnt need value or index
fields. type flags length = 3 bytes
------------------------------------------------------------------------
total 4 or 5 0
For future extensibility, we can define more values for the Address
Meaning TLV. Currently we'd need to define new TLVs (though they might
be necessary anyway depending on what the extension was trying to do).
What do you think? I'm sure I must have made mistakes?
Kind regards,
Vicky.
Regards,
Vicky.
_____________________________________________________
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.
_____________________________________________________
<AODVv2 RFC5444 Representation (Replaces Draft 9 Sections 8 and 12)>
<AODVv2 RFC5444 Representation v2 (Replaces Draft 9 Sections 8 and 12)>
