December 2006
doc.: IEEE 802.11-06/1893r0
[HWMP Routing Loops]
Date: 2006-12-04
Authors:
Name
Company
Address
Marc Mosko
PARC
3333 Coyote Hill
650-812-4405
Road, Palo Alto, CA
94304
Phone
email
[email protected]
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in
this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE
Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement
"IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is
essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
[email protected] as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being
developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.
Submission
Slide 1
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Abstract
HWMP, as specified in the November 2006 “HWMP
Specification” (IEEE 802.11-06/1778r1) [HWMP], may
loop routing tables.
The method for handling RREPs may cause routing table
loops if the unicast past to the RREQ origin changes
while a RREP is in flight.
Proposed fixes to this problem are (a) to only send RREPs
along the corresponding RREQ reverse path, or (b) to
use a similar feasibility criterion for RREPs as for
RREQs, or (c) to use a strong ordering for RREP
DSNs.
Submission
Slide 2
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Problem statement
• The problem
– A RREP forward path may loop if the unicast path to the RREP
destination (RREQ origin) changes during the RREP lifetime.
• Cause
– RREP paths are only weakly ordered on the invariant that the RREP DSN
>= stored DSN [HWMP, 11A.4.6.4.1].
– The rules for updating forwarding information [HWMP, 11A.4.3.6, item
4] allow for larger path metrics with no further tests.
– The rules for relaying a RREP [HWMP, 11A.4.6.3, case B] state that the
destination address for the RREP IE is the unicast next hop towards the
RREQ Originator.
– It is possible that the unicast path to the originator changes during the
RREP lifetime such that the RREP forward path loops. The changing
RREQ originator paths are loop-free.
Submission
Slide 3
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Problem Example: RREQ #1
S
• At time T1, node S
sends a RREQ
1
B
– Follows green path until
time T4, when destination
T receives it.
– Links without an arrow
did not succeed in
transmitting the frame.
Submission
A
C
3
2
D
4
T
Slide 4
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Problem Example: RREP path
S
• Node T sends RREP
1
– At time T5, T-C
– At time T6, C-B
B
A
• Node S sends RREQ #2
C
6
D
– At time T7, RREQ goes
S-C, but is lost on S-A.
– RREQ could be for some
other node Z
– DSN of RREQ #2 >
RREQ #1 [11A.4.5.3 case
A].
Submission
7
5
T
Unicast path to S
RREP to RREQ #1
RREQ #2
Slide 5
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
A node on RREQ #2
• We will assume one of these two cases for RREQ #2
– Larger DSN
• It may be that RREQ #2 is generated after
HWMP_RT_NETDIAMETER_TRAVERSAL_TIME, in which case
DSN #2 > DSN #1.
– Equal DSN, shorter path
• If RREQ #2 is generated sooner, it MAY be the case that DSN #2 =
DSN #1. In such a case, let us assume the path distance S-A > S-C-DA.
• In both cases, the unicast path to S from RREQ #2 will
supersede the path from RREQ #1.
Submission
Slide 6
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Problem Example: Crossing paths
S
• Node B has queue
delays.
• RREQ #2
7
B
A
– Propagates C-D-A in
times T8 and T9 and is
then lost on A-T.
8
9
C
D
T
• New unicast path to S
shown in blue.
Unicast path to S
RREP to RREQ #1
RREQ #2
Unicast path to T
Submission
Slide 7
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Problem Example: Forming loop
S
• RREP now finishes
13
– At T10, node B releases
RREP to finish
propagating along unicast
path to S.
10
A
B
11
C
12
D
• Issue at node C
T
– Obviously, the path
length increased at T12
while the DSN remained
the same.
Unicast path to S
RREP to RREQ #1
RREQ #2
Unicast path to T
Submission
Slide 8
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Problem Example: Final path
S
• RREQ path is loopfree
B
– The route to S has always
been loop-free.
C
A
D
• RREP path has loop
– S-C-D-A-B-C
T
Unicast path to S
RREP to RREQ #1
RREQ #2
Unicast path to T
Submission
Slide 9
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Possible solutions I
• Option 1: Use RREQ path
– As in LDR [LDR] protocol, if RREP carries the corresponding RREQ ID,
it is possible for a RREP to follow the loop-free RREQ path. This may
lead to asymetric routes. However, as the RREQ reverse path is shortest
distance for the same RREQ ID, this would lead to an optimal forward
route.
• Option 2: Use distance
– If the RREP acceptance criterion [11A.4.6.4.2] includes distance, similar
to the RREP criterion [11A.4.5.4.1], then the loop would not be formed at
node C in the previous example.
– It is our understanding that the “previous path metric” in 11A.4.5.4.1 is
the stale, cached distance, not a dynamically changing distance based on
the instantaneous link metric. This is a necessary condition for
11A.4.5.4.1 to be loop-free.
Submission
Slide 10
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Possible Solutions II
• Option 3: Strongly order RREP DSNs
– The solution in Option 2 would strongly order RREPs while
keeping the <= condition on DSNs.
– Option 3 suggests that if the DSN is strongly ordererd <, then one
does not need to consider the distance metric.
– This option is possible, because [11A.4.3.2] says that a node must
increase its DSN before issuing an IE (i.e. RREP). So long as the
Originator of a RREQ sets the DO flag, new paths will satisfy a
strong DSN ordering.
Submission
Slide 11
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
Caveats
• We have not considered RANN in the previous solution
options.
Submission
Slide 12
Marc Mosko, PARC
December 2006
doc.: IEEE 802.11-06/1893r0
References
• [HWMP] HWMP Specification, IEEE 802.1106/1778r1, Nov. 2006.
• [LDR] Garcia-Luna-Aceves, Mosko, Perkins, “A new
approach to on-demand loop free routing in ad hoc
networks,” PODC 2003.
Submission
Slide 13
Marc Mosko, PARC