Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 May 2014 15:26:24 -0700

I did not find the specification within RFC5444 mandating the
limitation as stated below.   In fact, RFC 5444 has the following text:

=============================================================
    o  <msg-hop-limit> field, if present, contains the number of hops on
       which the packet is allowed to travel before being discarded by a
       MANET router.    ....

    o  <msg-hop-count> field, if present, contains the number of hops on
       which the packet has traveled across the MANET.      ....
==============================================================

which many people would interpret to indicate that a packet might
traverse multiple hops.

Anyway, I will do the following:
a) make it clear that AODV multicast packets traverse only a single
      hop and
b) remove the unnecessary passages from the relevant text cited below
     in section 5.4.

On 4/3/2014 2:31 PM, manet issue tracker wrote:
> #33: RFC 5444 processing constraint
>
>   (Thomas Clausen)
>   I have a general concern about how this protocol imposes constraints
>   on RFC5444 usage, which precludes co-existence with other RFC5444
>   protocols running on the same device.
>
>   Let me give an example hereof, from Section 5.4:
>
>
>   {{{
>                   When multiple messages are aggregated into a single packet
>                   according to RFC 5444 formatting, and the aggregation of
>                   messages is also authenticated (e.g., with IPsec), and the
>                   IP destination is multiple hops away, it becomes
>   infeasible
>                   to delete individual messages.  In such cases, instead of
>                   deleting individual messages, they are maintained in the
>                   aggregation of messages, but simply ignored for further
>                   processing.  In such cases where individual messages
>   cannot
>                   be deleted, in this document "disregarded" means
>   "ignored".
>                   Otherwise, any such "disregarded" AODVv2 messages SHOULD
>   be
>                   deleted from the aggregated messages in the RFC 5444
>   packet.
>   }}}
>
>   An RFC5444 packet is *never* to be sent more than one hop.
>   ... A router receives an RFC5444 packet, decapsulates
>   it, process each message (if appropriate), the owner process of each
>   message identifies which messages are to be forwarded (if appropriate),
>   hands those off to the appropriate "message multiplexing engine" which
>   packs those messages up in a new RFC5444 packet, and transmits that
>   new RFC5444 packet.

Check.

>
>   Also, in RFC5444 messages, addresses are contained in address blocks.
>   There is no semantics associated with an address being in one address
>   block, or in another (in fact, (re-)organising addresses into address
>   blocks is one of the tricks to use to obtain more compact messages).
>   Likewise, there is no semantics associated with an address being first,
>   last, or in any other position in an address block: the ordering of
>   addresses in an address block carries no semantics.
>
>   Therefore, writing something like this:
>
>
>   {{{
>                   RteMsg.Address[i] denotes the [i]th address in an RFC 5444
>                   AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the
>                   associated prefix length for RteMsg.Address[i], and
>                   RteMsg.{field} denotes the corresponding value in the
>   named
>                   AddrTLV block associated with RteMsg.Address[i].
>   }}}
>
>
>   makes no sense whatsoever (aside from the fact that I do not understand
>   the notation !RteMsg.{field} - that would indicate a "field" in a
>   message, not in an attribute associated with an address).

I don't think this is still an issue in the current draft.  However, it
is notable that certain ordering constraints must be associated with
addresses and associated TLVs.  For instance, the [i]th element of an
array of values in a TLV must be associated with the [i]th address.

>
>   Let me give one more example, from section 9:
>
>
>   {{{
>              If a message with an unknown type is received, the message is
>              disregarded.
>   }}}
>
>
>   An implementation of this specification will (according to RFC5444)
>   "own", and therefore get messages that this protocol has gotten
>   assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK.  Messages of any
>   other Message Types will not (again, according to RFC5444) be
>   delivered to an implementation of this protocol.
>
>   Therefore, this protocol <should not>
>   specify discarding any message types other than those than it "owns".

Well, O.K. if we are going to agree that it's impossible for AODVv2
to receive a message of an unknown type, the text is redundant and
can be removed.  It boils down to having RFC 5444 enforce the type
checking instead of AODVv2.  Sounds less than robust to me.

-- 
Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 29 May 2014 00:33:26 +0200

> On 29 mai 2014, at 00:26, "Charles E. Perkins" <[email-masked]> wrote:
> 

Packet != message

Thomas

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 29 May 2014 00:48:37 +0200

Or to be more specific...

> limitation as stated below.   In fact, RFC 5444 has the following text:

What you quote is from Appendix B, and you quote selectively... Here are the bullets in full:

  o  <msg-hop-limit> field, if present, contains the number of hops on
      which the packet is allowed to travel before being discarded by a
      MANET router.  The <msg-hop-limit> is set by the message
      originator and is used to prevent messages from endlessly
      circulating in a MANET.  When forwarding a message, a MANET router
      should decrease the <msg-hop-limit> by 1, and the message should
      be discarded when <msg-hop-limit> reaches 0.

   o  <msg-hop-count> field, if present, contains the number of hops on
      which the packet has traveled across the MANET.  The <msg-hop-
      count> is set to 0 by the message originator and is used to
      prevent messages from endlessly circulating in a MANET.  When
      forwarding a message, a MANET router should increase <msg-hop-
      count> by 1 and should discard the message when <msg-hop-count>
      reaches 255.

   o  If the <msg-hop-limit> and <msg-hop-count> fields are both
      present, then the Message Header provides the information to make
      forwarding decisions for scope-limited flooding.  This may be by
      any appropriate flooding mechanism specified by a protocol using
      this specification.

Please refer to section 5.2 in RFC5444 - which is normative, and which therefore takes precedence. 

Also please note that the parts that you conveniently didn't quote from these two bullet points (as well as the text preceding the bulleted list) correctly talk about messages - which many people would use as an indicator that the first use of "packet" in these bullet points is in error.

(It might be appropriate to file an errata against Appendix B to correct "packet" to "message" in these two occurrences)

Thomas

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 29 May 2014 01:00:44 +0100

Charlie

Thanks for pointing that out. That is text in a non-normative appendix and is an error. The normative text in Section 5.2 refers to messages, and so should this appendix. I will put in an erratum to correct that.

But your (a) is incorrect. There are no such things as AODV packets. Packets are owned by the 5444/5498 multiplexing process. Only messages are owned by AODVv2.

Christopher

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 29 May 2014 09:53:35 +0000

I have submitted the appropriate erratum to RFC 5444. (I also checked through 5444 and didn't find any other uses of packet that should be message. That isn't a guarantee though.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Christopher Dearlove
Sent: 29 May 2014 01:01
To: Charles E.Perkins
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Charlie

Christopher

On 28 May 2014, at 23:26, Charles E. Perkins wrote:

>>                 Otherwise, any such "disregarded" AODVv2 messages 
>> SHOULD be
>> ... A router receives an RFC5444 packet, decapsulates it, process 
>> each message (if appropriate), the owner process of each message 
>> identifies which messages are to be forwarded (if appropriate), hands 
>> those off to the appropriate "message multiplexing engine" which 
>> Likewise, there is no semantics associated with an address being 
>> first, last, or in any other position in an address block: the 
>> ordering of addresses in an address block carries no semantics.
>> 
>> makes no sense whatsoever (aside from the fact that I do not 
>> understand the notation !RteMsg.{field} - that would indicate a 
>> "field" in a message, not in an attribute associated with an address).
> 
> I don't think this is still an issue in the current draft.  However, 
> it is notable that certain ordering constraints must be associated 
> with addresses and associated TLVs.  For instance, the [i]th element 
> of an array of values in a TLV must be associated with the [i]th address.
> 
>> 
>> Therefore, this protocol <should not> specify discarding any message 
>> types other than those than it "owns".
> 
> Well, O.K. if we are going to agree that it's impossible for AODVv2 to 
> receive a message of an unknown type, the text is redundant and can be 
> removed.  It boils down to having RFC 5444 enforce the type checking 
> instead of AODVv2.  Sounds less than robust to me.
> 
> --
> Regards,
> Charlie P.
> 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 29 May 2014 15:52:23 +0100

On Thu, May 29, 2014 at 1:00 AM, Christopher Dearlove <
[email-masked]> wrote:

> ....... There are no such things as AODV packets. Packets are owned by the
> 5444/5498 multiplexing process. Only messages are owned by AODVv2.
>
>From RFC5444 alone I think any protocol using it can specify its packets,
but if we are using same multiplexing within the MANET then your routing
protocol needs to follow 5444/5498.

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 29 May 2014 17:10:50 +0100

And you have to use that multiplexing if using the manet UDP port or IP protocol. RFC 5498.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 29 May 2014, at 15:52, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
> 
>> On Thu, May 29, 2014 at 1:00 AM, Christopher Dearlove <[email-masked]> wrote:
>> ....... There are no such things as AODV packets. Packets are owned by the 5444/5498 multiplexing process. Only messages are owned by AODVv2.
> From RFC5444 alone I think any protocol using it can specify its packets, but if we are using same multiplexing within the MANET then your routing protocol needs to follow 5444/5498.
>  
> AB
>  
>