[aodvv2-discuss] Re: Review of 07k

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Mon, 02 Mar 2015 15:32:02 -0800

Hello folks,

Message TLVs and Address Block TLVs are taken from two different
numbering spaces.  It might be pleasing to have those two number
spaces lining up for TargSeqNum, but since the alignment would not
happen for other TLVs, it won't be much of a help.

Regards,
Charlie P.


On 3/2/2015 3:02 PM, Victoria Mercieca wrote:

Hi Lotte,
Thats a very good question. In our section 14 they are in sub-sections where we separate message TLVs and address block TLVs. I interpreted this to mean that TargSeqNum was only an Address Block TLV. I might well be wrong!
I noted the TargSeqNumber List to Charlie already - I think he's updated it for the next version :-) 

Regards,
Vicky
On Monday, March 2, 2015, Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx <mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote: 

    Hi Vicky,

    Am 01.03.2015 um 19:35 schrieb Victoria Mercieca
    <vmercieca0@xxxxxxxxx
    <javascript:_e(%7B%7D,'cvml','vmercieca0@xxxxxxxxx');>>:


    Hi Charlie,

    Good point, because there's no address block, so there's no
    address block TLVs, so we can't use the already defined
    TargSeqNum TLV.



    Stupid question: why not? If I understand it correctly, TargSeqNum
    at the end of the day only represents a TLV of type 13. Whether
    the context of this TLV is that it's a messae or an Address TLV
    should be made obvious by the 5444 parser/builder... Or am I
    missing something here?

    (quick note: while looking this up in 07j, I found one instance of
    “TargSeqNumber List” instead of “Targseqnum List”, is this
    intentional? I'm not sure where my email client buried the more
    recent versions that you cent around so I'm not sure if this is
    fixed and I'm unnecessarily going on your nerves either.. :/ )


    I have two points on SeqNum in RREP_Ack:

    1. The SeqNum in the RREP_Ack may not be enough.
    E.g. If we have a RREP for TargAddr A with SeqNum 1, and another
    RREP for TargAddr B with SeqNum 1, and both require an ack, when
    the RREP_Ack comes back with SeqNum 1, how do we know which RREP
    it corresponds to? To really match a RREP_Ack to an RREP, do we
    need to include the TargAddr? In which case we can use address
    block and address block TLVs already defined.
    Also another question here: if we send one message with AckReq,
    should we avoid sending a second to the same neighbour, at least
    while the first timeout is active?

    2. Alternatively, we could say that the SeqNum isn't necessary at
    all.
    E.g. if any ack or any AODVv2 message, or any other message in
    fact, is received in the time window expected, from the node it's
    expected from, is that good enough?
    Another question: Say two RREPs with AckReq were sent to the same
    router, and only one RREP_Ack came back, should the router be
    blacklisted?

    What do you think?

    Regards,
    Vicky.


    On Sunday, March 1, 2015, Charlie Perkins
    <charles.perkins@xxxxxxxxxxxxx
    <javascript:_e(%7B%7D,'cvml','charles.perkins@xxxxxxxxxxxxx');>>
    wrote:

        Hello folks,

        I reckon that, if the RFC 5444 representation of RREP_Ack
        is to include TargSeqNum, then we have to define a new
        RFC 5444 Message TLC for TargSeqNum.  Similarly, if we
        were to define any sort of transaction ID for RREP_Ack
        (or indeed any future message).

        Bleahhh.

        Does anyone want to argue for getting rid of TargSeqNum
        in RREP_Ack?

        Regards,
        Charlie P.


        On 3/1/2015 9:00 AM, Charlie Perkins wrote:


        Hello Vicky,

        Follow up below...


        On 2/28/2015 8:04 AM, Victoria Mercieca wrote:

        Thanks for all the hard work you put in last night!


        Thanks -- and likewise for these comments!



        6.4 - I noticed a space has gone missing in
        "DSDV[Perkins94]" - was that intentional?
        6.5 - we should change "OrigNode Sequence Number" to
        OrigSeqNum, and "TargNode Sequence Number" to TargSeqNum...
        because later when we talk about checking for redundancy
        (8.6) we look at seqnum for orig*addr*/targ*addr* rather
        than seqnum for the node.
        9.1.1 - 2nd paragraph - TargSeqNum, ValidityTime,
        MetricType and PrefixLengthList should be optional, using
        same structure as in 9.2.1
        9.1.1 - step 4 - "Address List" to "AddressList"
        9.1.1 - step 6 - should probably say:
        "For the sequence numbers:
             * Increment the SeqNum as specified in Section 6.4.
             * Set OrigSeqNum to the new value of SeqNum.
             * If an Invalid route exists matching TargAddr using
        longest prefix matching, include TargSeqNum and set it to
        the sequence number on the Invalid route. Otherwise omit
        TargSeqNum."
        9.1.3 - step 4 - change VALIDITY_TIME to ValidityTime
        9.2 - in the diagram, the PrefixLengthList line is missing
        the "}"
        9.2.1 - change TargSeqNumber List to TargSeqNum
        9.2.1 - step 5 - "Address List" to "AddressList"
        9.2.1 - step 7 should say:
        "For the TargSeqNum:
               *  RREP_Gen increments its SeqNum as specified in
        Section 6.4.
               *  Set TargSeqNum to the new value of SeqNum."
        9.2.3 - step 6 - change VALIDITY_TIME to ValidityTime
        9.3.1 - paragraph 4 - change "Address List" to
        "AddressList" and "Metric List" to "MetricList"
        9.3.1 - step 6 - "SeqNum List" to "SeqNumList" (twice)


        All fixed.


        Section 10 - where it says "see section 14.2" and "see
        section 14.3" - is it more correct to remove AODVv2 in
        these sentences? the message TLVs and address block TLVs
        are owned by rfc5444.


        Here I am not sure.  The TLVs are owned by RFC 5444 but
        specified by AODVv2.


        Section 10 - the paragraph before the table needs the first
        sentence rewording, maybe to "The following table shows how
        AODVv2 data elements are represented in RFC 5444 messages."


        Done.




        Questions:

        I wondered if the references to TLVs should be removed from
        everywhere except section 10 and appendices. If so,
        6.2 - "AckReq Message TLV" should be "AckReq data element"
        (occurs twice in 6.2)
        7 - "MetricType TLV" to "MetricType data element"
        9.1.1 - step 3 - "MetricType TLV" to "MetricType data element"
        9.1.1 - step 8 - "ValidityTime Address Block TLV" to
        "ValidityTime data element"
        9.1.2 - step 4 - "MetricType TLV" to "MetricType data element"
        9.2.1 - step 3 - "AckReq TLV" to "AckReq data element"
        9.2.1 - step 4 - "MetricType TLV" to "MetricType data element"
        9.2.2 - step 3 - "MetricType TLV" to "MetricType data element"
        9.2.2 - step 6 - "AckReq TLV" to "AckReq data element"
        9.2.3 - step 5 - "AckReq TLV" to "AckReq data element"
        9.3.1 - step 2 - "PktSource TLV" to "PktSource data element"
        9.3.1 - step 3 - "MetricType TLV" to "MetricType data
        element" and remove "in the TLV" from the end of the sentence.
        9.3.2 - step 2 - "MetricType TLV" to "MetricType data element"
        9.3.3 - step 2 - "PktSource TLV" to "PktSource data element"
        9.3.3 - step 3 - "MetricType TLV" to "MetricType data element"
        9.3.3 - paragraph after step 6 - "PktSource TLV" to
        "PktSource data element"
        9.4.1 - "AckReq message TLV" to "AckReq data element"
        A.5.1 - "AckReq TLV" to "AckReq data element"


        All done.



        We could change from ValidityTimeList to ValidityTime
        throughout? I think the current way is OK, but it seems
        like ValidityTime is more similar to OrigSeqNum than to
        MetricList and should be handled without a list. (It's my
        fault its in there as ValidityTimeList so I'll find all the
        bits to adjust if you think this is worth doing)


        I'm not sure about this.  Notably, in the specification
        right now, only one
        address ever has an associated ValidityTime in any AODVv2
        message.
        I'll send another email shortly with more discussion.



        Do we need UnreachableAddressList? Can we just use
        AddressList and put one or more UnreachableAddresses in it?
        Again, not a pressing issue


        I really like this idea.  But I encountered a logistical
        problem in Table 3.
        I created "RteMsg AddressList" and "RERR AddressList" for
        the purpose.
        Now, the section of that table looks as follows:

            | RteMsg AddressList     | RFC 5444 Address Block                   
|
            | -   OrigAddr           |                                          
|
            | -   TargAddr           |                                          
|
            | -   PrefixLengthList   |                                          
|
            | RERR AddressList       | RFC 5444 Address Block                   
|
            | -   UnreachableAddress |                                          
|
            | -   PrefixLengthList   |                                          
|



        Do we need to add OrigSeqNum, OrigAddrMetric,
        TargAddrMetric and TargSeqNum in the terminology section?
        They are in section 3 but someone might expect them to be
        in with all the other terminology too. AckReq, PktSource too?


        As far as Terminology goes, the more definitions the
        merrier, as long as they are used
        in the document.  Another possibility would be to enlarge
        some of the definitions in the
        Terminology section to indicate which of the terms are
        "official" AODVv2 data elements.



        I think you have enough text in there already to understand
        the RFC5444 multi-value address block TLVs - I just hadn't
        read it properly. However, it is in section 10, so the
        reader could get confused by section 9 before getting to
        it. Since Section 3 and Section 10 have so many
        similarities, is it worth relocating section 10 to
        immediately after section 3?


        Section 10 seems to be a "late-document" kind of section.  Maybe
        it should be moved right after section 13?




        Suggested text in relation to recent emails:

        In section 2
        SeqNumList
             The list of Sequence Numbers associated with addresses
        in an
              AddressList. Used in RERR messages.
        In Section 3
        SeqNumList
            A list of SeqNums, included in RERR messages.


        Done.




        Apologies for the length of the email again, I hope this is
        all useful and I'm not just being a GIANT pain in the ass!



        This is super useful, and since I have in the past met
        people who really are a giant pain in the ass I can state
        with confidence that you bear no resemblance.

        Regards,
        Charlie P.

Other related posts:

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