1. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 1 [HWMP Routing Loops] 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, 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 stuart@ok-brit.com 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.http:// ieee802.org/guides/bylaws/sb-bylaws.pdf stuart@ok-brit.compatcom@ieee.org Date: 2006-12-04 Authors:

2. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 2 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.

3. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 3 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.

4. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 4 Problem Example: RREQ #1 At time T1, node S sends a RREQ –Follows green path until time T4, when destination T receives it. –Links without an arrow did not succeed in transmitting the frame. A D C T B S 1 2 3 4

5. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 5 Problem Example: RREP path Node T sends RREP –At time T5, T-C –At time T6, C-B Node S sends RREQ #2 –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]. A D C T B S 1 6 Unicast path to S 5 RREP to RREQ #1 RREQ #2 7

6. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 6 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-D- A. In both cases, the unicast path to S from RREQ #2 will supersede the path from RREQ #1.

7. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 7 Problem Example: Crossing paths Node B has queue delays. RREQ #2 –Propagates C-D-A in times T8 and T9 and is then lost on A-T. New unicast path to S shown in blue. A D C T B S Unicast path to S RREP to RREQ #1 RREQ #2 7 8 9 Unicast path to T

8. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 8 Problem Example: Forming loop RREP now finishes –At T10, node B releases RREP to finish propagating along unicast path to S. Issue at node C –Obviously, the path length increased at T12 while the DSN remained the same. A D C T B S Unicast path to S RREP to RREQ #1 RREQ #2 Unicast path to T 10 1112 13

9. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 9 Problem Example: Final path RREQ path is loop- free –The route to S has always been loop-free. RREP path has loop –S-C-D-A-B-C A D C T B S Unicast path to S RREP to RREQ #1 RREQ #2 Unicast path to T

10. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 10 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.

11. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 11 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.

12. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 12 Caveats We have not considered RANN in the previous solution options.

13. doc.: IEEE 802.11-06/1893r0 Submission December 2006 Marc Mosko, PARCSlide 13 References [HWMP] HWMP Specification, IEEE 802.11- 06/1778r1, Nov. 2006. [LDR] Garcia-Luna-Aceves, Mosko, Perkins, “A new approach to on-demand loop free routing in ad hoc networks,” PODC 2003.