Subject: [manet] #42 (aodvv2): What happens if Active routes exceed RERR packet size?

From: "manet issue tracker" <[email-masked]>
Date: Wed, 16 Jul 2014 17:11:39 -0000

#42: What happens if Active routes exceed RERR packet size?

 Section 8.3.2. states that

 {{{
         After the Active Routes using
         the broken link have all been included as UnreachableNodes, Idle
         routes MAY also be included, if allowed by the setting of
         ENABLE_IDLE_UNREACHABLE, as long as the packet size of the RERR
 does
         not exceed the MTU (interface "Maximum Transfer Unit") of the
         physical medium.
 }}}

 However, it is not specified what happens if the listing of all ''Active''
 routes already exceeds the packet size. In a large-scale network using
 IEEE 802.15.4., this is not unlikely to happen, and I think it should be
 defined how to handle this situation.

-- 
-------------------------------------+-------------------------------------
 Reporter:  lotte.steenbrink@fu-     |      Owner:  draft-ietf-manet-
  berlin.de                          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  aodvv2                   |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/42>
manet <http://tools.ietf.org/manet/>

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 20 Jul 2014 21:08:20 -0700

Hello Lotte,

I can indeed imagine it happening, but I am not sure what the
proper resolution should be.  While it is true that many routes
*might* be active in a large network, I suspect that the problem
would only arise in a few nodes that are situated as the main
point of connectivity between two subgraphs.

Anyway, the problem needs a solution.  It seems that the active
routes SHOULD be reported as broken, and that the order of
reporting SHOULD be in order of time of use.  I don't think the
ordering should be mandated, because some implementations
might not want to do the extra code, and it wouldn't affect
interoperability.  Performance might be adversely affected in
the rare cases where there are many active routes in service.

A node would report the overflow active routes by creating
another RERR message and putting in as many active routes
as possible.

If this is acceptable, I think it will be quite straightforward
to revise the draft accordingly.  Maybe the text should go into
a new subsection.

Comments?

Regards,
Charlie P.

---

From: Lotte Steenbrink <[email-masked]>
Date: Mon, 21 Jul 2014 22:14:08 +0200

Hello Charlie,

> another RERR message and putting in as many active routes

That sounds reasonable to me.

> to revise the draft accordingly.  Maybe the text should go into

I'm not entirely sure that's necessary. I'd imagine something along the lines of this:

For each such Active Route, Route.Dest is added to the set of 
Unreachable Nodes. If the size of the set of Unreachable Nodes 
exceeds the packet size of the RERR, additional RERR packets 
are created until all Active broken routes have been reported. 
The order of reporting SHOULD be in order of time of use. 

After the Active Routes using the broken link have all been included 
as UnreachableNodes, Idle routes MAY also be included, ... etc etc

Cheers,
Lotte

---

From: "manet issue tracker" <[email-masked]>
Date: Tue, 22 Jul 2014 18:09:33 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

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

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