[aodvv2-discuss] Re: RFC5444 changes towards >= 1 TLV per address

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Thu, 11 Jun 2015 16:07:27 +0100

Hi,

I'm not sure if Charlie made any changes to the files after I sent the
pandoc stuff out. I'm happy to continue editing though.

On Thu, Jun 11, 2015 at 9:27 AM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:

Hi all,
I'm not sure who has the editorial pen right now, but I thought I'd
suggest changes to the draft which implement the RFC5444 message changes we
discussed this week. As soon as we've added them to the draft, I'd like to
send our changes to the MANET list, too (or even before?).

Since we have this nifty generic AODVv2 message format, all we have to
change is the translation to RFC5444:

(side note: Imo, “The following sections show the TLVs that apply to each
address.” is a bit misleading, could we change this to “The following
sections discuss show the TLVs that apply to the specific addresses of the
Address Block.” or something in that direction to make clear that “all” is
meant per-address here?)

First, we'll have to remove the “(optional)” for TargSeqNum and specify
that the TLV shouldn't contain any value (as advised by chris here:
http://www.ietf.org/mail-archive/web/manet/current/msg17665.html) if the
last TargSeqNum is unknown.


We will have to slightly adjust the message sections since they say
TargSeqNum is optional for RREQ, and I dont think they mention OrigSeqNum
for RREP.

Did you also see my reply to that email? The idea of having a TLV
specifically to describe the meaning of the addresses? Then we wouldnt need
3 separate SeqNum TLVs and also wouldnt need the PktSource TLV. I'll send a
separate email with my thoughts for this and we can compare.


8.1.4.2. Address Block TLVs for TargAddr

+----------------+--------------+------------+----------------------+
| Data Element | TLV Type | Extension | Value |
| | | Type | |
+----------------+--------------+------------+----------------------+
| TargSeqNum | TARG_SEQ_NUM | 0 | The last known |
| | | | TargSeqNum for |
| | | | TargAddr, if |
| | | | available, |
| | | | None otherwise |
+----------------+--------------+------------+----------------------+

Similarly, 8.2.4.1. Address Block TLVs for OrigAddr needs to be changed
from

No Address Block TLVs apply to OrigAddr in a RREP.

to:

+--------------+---------------+------------+-----------------------+
| Data Element | TLV Type | Extension | Value |
| | | Type | |
+--------------+---------------+------------+-----------------------+
| OrigSeqNum | ORIG_SEQ_NUM | 0 | None |
+--------------+---------------+------------+-----------------------+

Then, we need to either introduce a new TLV type for all Addresses of a
RERR which are not PktSource or recycle one of the optional ones (i.e. make
them non-optional, but empty if no value for them exist). For the sake of
economicalness, I opted for the latter and made SeqNum mandatory:

8.4.4.2. Address Block TLVs for Unreachable Addresses

+----------------+-------------+------------+-----------------------+
| Data Element | TLV Type | Extension | Value |
| | | Type | |
+----------------+-------------+------------+-----------------------+
| SeqNumList | SEQ_NUM | 0 | Sequence Number |
| | | | associated with |
| | | | invalid route to the |
| | | | unreachable address |
| | | | if available, |
| | | | None otherwise. |
| MetricTypeList | PATH_METRIC | MetricType | None. Extension Type |
| (optional) | | | set to MetricType of |
| | | | the route to the |
| | | | unreachable address. |
+----------------+-------------+------------+-----------------------+

(Also, I'm not quite sure why Value for MetricTypeList says “None.”?)


Erm, that was because we need to use the metric TLV, to use the type
extension to indicate metric type, though there will be no metric values in
this TLV.

Regards,
Vicky.


And that should be about it!

Regards,
Lotte


Other related posts: