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.
Regards,
Vicky.
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.
------------------------------------------------------------------------
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.
