[Manet-dt] Routing loops in proactive protocols, including OLSR

Teco Boot <teco@inf-net.nl> Fri, 13 April 2007 11:57 UTC

Return-path: <manet-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKPD-0004Bd-5U; Fri, 13 Apr 2007 07:57:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKPB-0004BW-3o for manet-dt@ietf.org; Fri, 13 Apr 2007 07:57:29 -0400
Received: from smtp15.wxs.nl ([195.121.247.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKP7-0004jq-PM for manet-dt@ietf.org; Fri, 13 Apr 2007 07:57:29 -0400
Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp15.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JGF008BMQJLJH@smtp15.wxs.nl> for manet-dt@ietf.org; Fri, 13 Apr 2007 13:57:24 +0200 (CEST)
Date: Fri, 13 Apr 2007 13:58:25 +0200
From: Teco Boot <teco@inf-net.nl>
To: manet-dt@ietf.org
Message-id: <002d01c77dc3$0ec5b080$0202a8c0@Teco>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acd9wwpKzNXpAco1S4G9TC2ybci62Q==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Subject: [Manet-dt] Routing loops in proactive protocols, including OLSR
X-BeenThere: manet-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MANET Design Team <manet-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/manet-dt>
List-Post: <mailto:manet-dt@ietf.org>
List-Help: <mailto:manet-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=subscribe>
Errors-To: manet-dt-bounces@ietf.org

Once more on routing loops. I suggested DPD for unicast, for reducing impact
of a routing loop. I didn't receive any response on it. Perhaps the problem
is not known or impact is not fully understood. Please react on this problem
and suggest next steps.

Loops in unicast routing takes place when interface state changes. When an
interface goes down, the routing table is adjusted quickly for removing
entries with a next hop via this interface. Alternative routes could be used
quickly also. Other router routing tables are updated after routing protocol
activity; this could take milliseconds up to minutes, depending on protocol
and timer settings. During this convergence, routing loops can occur and
packet starvation is handled by TTL mechanism.

On wireless media, using TTL for starvation could have a high impact on
radio resources and spectrum utilization, and IMHO the behavior is
unacceptable. For this reason I suggested using DPD for unicast also.

Scenario with a routing loop problem in MANET topology:

+----+        +----+        +----+
| R1 |--------| R2 |--------| R3 |
+----+        +----+        +----+
   |                          | 
   |    =+=+= obstacle =+=+   |
   |                          |
+----+                      +----+
| R4 |----------------------| R5 |  R5 moves this way --->
+----+                      +----+

I assume a hop-count based metric (although I reject this approach due to
the WPF syndrome problem) and I focus on the link between R1 and R4, for
traffic from R4 to R5. R4 selects R5 as next-hop. Now the link between R4
and R5 breaks:

+----+        +----+        +----+
| R1 |--------| R2 |--------| R3 |
+----+        +----+        +----+
   |                           \ 
   |    =+=+= obstacle =+=+     \
   |                             \
+----+                         +----+
| R4 |                         | R5 |  R5 moves this way --->
+----+                         +----+

R4 and R5 detect the change due to the hello mechanism or L2 triggers. After
R4 is aware of the failure, it immediately adjusts its routing table. It
uses R1 as next hop for traffic to R5. However, R1 is still not aware of the
topology change and uses R4 as next hop for traffic towards R5. Now the
routing loop occurs:

     +----+        +----+        +----+
     | R1 |--------| R2 |--------| R3 |
     +----+        +----+        +----+
      ^ |                           \ 
Loop: | |    =+=+= obstacle =+=+     \
      | v                             \
     +----+                          +----+
     | R4 |                          | R5 |  R5 moved
     +----+                          +----+

The loop is solved as soon as R1 is aware of the new topology. Delay is
caused by routing protocol packet transfer, timers and processing time.
Protocol timers that slow down packet transfer or introduce jitter in SPF
calculation increase loop duration. So jitter introduced by
draft-clausen-manet-jitter emphasizes the routing loop problem.

Teco


_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt