[aodvv2-discuss] Re: RFC5444 tables

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Thu, 30 Apr 2015 14:10:42 +0100

Hi Lotte,

On Thu, Apr 30, 2015 at 1:48 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:

Hi Vicky,

Am 30.04.2015 um 14:30 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:

Hi Lotte,

Thanks for the translation.

On Thu, Apr 30, 2015 at 12:33 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:

Hi all,
as promised, Hennings feedback, translated. All comments by me are in
square brackets.
(german version below in case you want to run it through google translate
;) )

1. splitting addresses in <head> <mid><tail> and <prefix-length> is too
detailed; it is sufficient to have <address> + <prefix> in the tables.
Then, Henning recommends not having the Address Table at all, but
personally, I prefer Vickys table notation over my squeezing the prefix
into the section name.


I'll use <address> and <prefix> then. It didnt seem right to not have the
address table when we discuss all the other message elements. We want to
show how our AddressList (or OrigAddr and TargAddr) map to the Address
Block.


I agree.




2. a tip: In cases where we don't want to use an extension we can write
extension 0 instead of -- ... this would make it easier to create an IANA
table for the new TLVs.
[Personally, I'm not so happy with this because it requires the reader to
know that an empty exttype is the same as exttype=0, and implementors who
don't know this might set every exttype explicitly to 0, which is just
unnecessary work that should be done by the RFC 5444 reader/writer]


I see what you are saying, but if you are creating RFC5444 messages, you
should have read RFC5444 and you should know that you dont need to
explicitly include the type extension and also set it to zero, i.e. that
you can omit it to give the same result.

What do you think of writing 0 but with a comment? We have space to do
this without making any tables larger. A couple of examples of how it
would look below. Anyone want to vote on this?

+--------------+---------------+------------+-----------------------+
| Data Element | TLV Type | Extension | Value |
| | | Type | |
+--------------+---------------+------------+-----------------------+
| OrigSeqNum | OrigSeqNum | 0 (omit) | Sequence Number of |
| | | | RREQ_Gen, the router |
| | | | which initiated route |
| | | | discovery. |
| ValidityTime | VALIDITY_TIME | 0 (not | ValidityTime |
| (optional) | | included) | guaranteed for route |
| | | | to OrigAddr. |
+--------------+---------------+------------+-----------------------+

+----------------+------------+------------+------------------------+
| Data Element | TLV Type | Extension | Value |
| | | Type | |
+----------------+------------+------------+------------------------+
| TargSeqNum | TargSeqNum | 0 | The last known |
| (optional) | | (omitted) | TargSeqNum for |
| | | | TargAddr. |
+----------------+------------+------------+------------------------+


Mhm... I think that's more confusing than just having a 0 there.

What about just writing "None" instead of "--"?


3. <hoplimit 1> does not need to be included... if there is no hoplimit,
the message will not be forwarded anyway [I think we had this discussion
already anyway, right?]


Would we need to state this for each message type? I guess Henning says
this because of RREP_Ack though?


Yup, that's what I'm assuming too.

I dont know if we came to a decision. We could say in the RREP_Ack section
"There are no data elements in a RREP_Ack." and remove that line about
hop-limit from the RFC5444 section. I'm happy to do this if no-one objects?



4. RREP-message: The PktSource belongs into the Addressblock. [I told him
we were discussing this right now, and that the goal was to first have a
new representation of the current message structure, and then apply any
future modifications to it.]


If we put it in the address block, then instead of having a message TLV,
we need to define an address block TLV we can associate with the address to
mark it as the PktSource. In the address block, we wont need a prefix
length for PktSource, we will assume it is equal to address length.


why so?


Why we dont need a prefix length? Because the RERR is triggered by a packet
that cant be delivered. We dont know the prefix length associated with the
source IP address of that packet, and we don't need to. We want the RERR to
get back to that particular device (i.e. to the router that is responsible
for it) - PktSource's prefix length doesnt matter. So if we dont include a
prefix length, its like saying prefix length = address length, which is not
a problem.


For all other addresses in the RERR, we might have a SeqNum TLV and we
might have a Metric TLV to indicate MetricType. We might have no associated
TLVs. Are we allowed to presume that anything not marked with PktSource
would be a route which is now invalid, or do we have to ensure some kind of
TLV to mark the address as an invalid destination?


We are allowed to, but it comes with a few complications. Charlie and I
had a discussion about this in the “RFC5444 feedback pt. 1” thread... As a
compromise, we could add PktSource to the AddressBlock, mark it with a TLV,
but *not* not mark the other Addresses with a TLV (following the procedure
that has been followed up until now) and then see if there's any feedback
from the working group on this issue once we've published the next draft
update.

Shall we go ahead and do this then?
In the IANA section, we can remove PktSource from the Message TLV section,
define it as an address block TLV, Type 14 (TBD), Length 0 (because it wont
need to contain a value) and reference back to section on RERR messages.
In the RFC5444 section we'd move PktSource into the address block, and in
the address block TLV block, we'd have a section for PktSource, where we
associate the PktSource TLV, with no value or extension type.
In the RERR section, PktSource wont be a data element. I can update that
section to have PktSource added to the AddressList. The text will need a
bit of work in the generation/reception/regeneration sections.

I'll wait until there's consensus!

Regards,
Vicky.

This wouldnt be a HUGE pain, since we can add just one TLV and associate it
with all addresses except PktSource.


I agree. ;)

Regards,
Lotte

Regards,
Vicky.


Cheers,
Lotte

Anfang der weitergeleiteten Nachricht:

*Von: *Henning Rogge <hrogge@xxxxxxxxx>
*Betreff: **Aw: RFC5444 tables*
*Datum: *29. April 2015 18:56:22 MESZ
*An: *Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>

Hi,

ein paar Kommentare:

du kümmerst dich noch um zu viele Details... für AODV2 ist es
irrelevant das RFC5444 die Addressen in "<head> <mid> <tail> and
<prefix-length>" aufspalten kann. Daher würde ich die Tabelle zu den
Addressen komplett jeweils entfernen. Einfach die Liste der Addressen
plus Prefixes reichen.

Wenn du übrigens "keine TLV-Extension" nutzen willst, schreib einfach
"Extension 0"... das macht es einfach ne IANA-Tabelle für den neuen
TLV anzufangen und die Extension 0 kann halt von RFC5444 effizienter
kodiert werden.

<hoplimit 1> brauchst du nicht zu kodieren... etwas das kein Hoplimit
hat wird auch auf jeden Fall nicht geforwarded.

RREP-Message: die PktSource gehört in den Addressblock.

Henning


2015-04-29 18:31 GMT+02:00 Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx>:

Hi henning,
wie gerade besprochen anbei der Teil des neuen Drafts mit den neuen
Tabellen. :)

Viele Grüße,
Lotte





Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 04-2015