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

From: "manet issue tracker" <[email-masked]>
Date: Tue, 30 Dec 2014 22:17:31 -0000

#33: RFC 5444 processing constraint

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 On 5/28/2014 3:26 PM, Charles E. Perkins wrote:
 > 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.

 ------------------------------------------------------------------------------

 On 5/28/2014 4:41 PM, Christopher Dearlove wrote:
 > 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.

 ---------------------------------------------------------------------------------------

 The description of AODV protocol elements has been changed to use the term
 "message" instead of "packet" where applicable.  The other suggested
 changes have also been made, and so this issue can reasonably be
 considered as closed.

-- 
-----------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  aodvv2                 |     Version:
 Severity:  Active WG Document     |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/33#comment:2>
manet <http://tools.ietf.org/manet/>