1. RFI Update Date: 2006-09-19 Authors: September 2006 Month Year
doc.: IEEE /1487r0
September 2006
RFI Update
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Guenael Strutt, Motorola
Guenael Strutt, Motorola

2. Month Year
doc.: IEEE /1487r0
September 2006
Abstract
The TGs RFI ad hoc group has held weekly teleconferences since the San Diego meeting. This presentation summarizes progress made since then.
Guenael Strutt, Motorola
Guenael Strutt, Motorola

3. Month Year
doc.: IEEE /1487r0
September 2006
RFI Update
The RFI ad hoc team is coordinated by Avinash Joshi
The team has focussed on four specific topics
HWMP normative text
r1 “HWMP Overview”
RA-OLSR normative text
r1 “RA-OLSR Information Elements”
11-06/1481r0 “RA-OLSR Clause 11A.5”
6-address scheme normative text
11-06/0841r5 “Extension to 6-Address Scheme”
11-06/1464r0 “6-Address Scheme”
Interworking strategy
r0 “Interworking Considerations”
Guenael Strutt, Motorola
Guenael Strutt, Motorola

4. Hybrid Wireless Mesh Protocol
Month Year
doc.: IEEE /1487r0
September 2006
Hybrid Wireless Mesh Protocol
Guenael Strutt, Motorola
Guenael Strutt, Motorola

5. HWMP Overview HWMP is a hybrid protocol because
Month Year
doc.: IEEE /1487r0
September 2006
HWMP Overview
HWMP is a hybrid protocol because
It can set up routes in an on-demand manner, without the use of specialized infrastructure
It can set up routes proactively by using specialized infrastructure
HWMP has three “modes” of operation
On-demand mode: destinations are discovered by broadcasting a Route Request
Proactive non-registration mode: roots broadcast Root Announcements to create unidirectional routes
Proactive registration mode: nodes create routes to root nodes by unicasting Route Requests based on received Root Announcement broadcasts
HWMP modes are not exclusive
Roots in different modes can be set up in the same network
All modes utilize the same routing Information Elements (RREQ, RREP, RERR)
Guenael Strutt, Motorola
Guenael Strutt, Motorola

6. HWMP (operation with Root)
Month Year
doc.: IEEE /1487r0
September 2006
HWMP (operation with Root)
Process starts at Root
Root sends a Root Announcement Message (and keeps on sending it at a regular interval)
Root Announcement message contains
Registration Flag
Hopcount / TTL
Root MAC address
Destination Sequence number
Lifetime
Metric
Root 3 1 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

7. HWMP – Non Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Non Registration mode
The Root Announcement message is received by the neighbors of the root (nodes 1 and 3 in this case)
Nodes receiving this message update their routing table according to the AODV rules
Root 3 1 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

8. HWMP – Non Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Non Registration mode
The nodes broadcast the Root Announcement after updating the metric field.
The Root Announcement will eventually be received by all nodes in the network
All nodes will update their routes to the root according to the AODV metrics/sequence number rules
Eventually a unidirectional tree will be formed in the mesh
Root 3 1 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

9. HWMP – Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Registration mode
The Root Announcement message is received by the neighbors of the Root (nodes 1 and 3 in this case)
Nodes receiving this message update their “uplink table” shown in the following slide
Root 3 1 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

10. HWMP – Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Registration mode
Uplink Table
DSN
MAC Address of the neighbor
Metrics to the Neighbor
Cumulative Metrics to the Root
This table is only for illustration purpose. It can be implemented in any data structure or combined with other tables or structures.
Guenael Strutt, Motorola
Guenael Strutt, Motorola

11. HWMP – Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Registration mode
If the nodes find that this new announcement message provides the best metric (after hysteresis) to the Root so far (based on the uplink table) they send a unicast RREQ message (destined to the root node) to the neighbor sending the Root Announcement message
In this example nodes 1 and 3 will send a unicast RREQ to the Root as it is their direct neighbor
Root
Unicast
RREQ 3 1 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

12. HWMP – Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Registration mode
The Root node will process the unicast RREQ and create a route entry for nodes 1 and 3.
It will also send a Route Reply back to the nodes in response to the RREQ message received.
Nodes 1 and 3, on receiving the RREP message, will create a route entry for the Root node
All the above steps will follow normal AODV processing rules for RREQ and RREP messages
At this point the Root and its one hop neighbors have valid routes to each other
Root
RREP
Unicast RREQ 3 1 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

13. HWMP – Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Registration mode
Nodes 1 and 3 will now start advertising their route to the Root in their Root Announcement message which can be sent after a delay or periodically.
Nodes receiving the message will follow the same procedure and update their uplink table
Root 3 1 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

14. HWMP – Registration mode
Month Year
doc.: IEEE /1487r0
September 2006
HWMP – Registration mode
Once the recipient node picks the best neighbor to reach the Root it sends a unicast RREQ (destined to the root node) to this neighbor
The node receiving the unicast RREQ will either forward it towards the root
Eventually a bi-directional tree will be created in the mesh rooted at the Root node
Root 3 1
Unicast
RREQ 2 4 5 12 7 6 8 9 10 11 13
Guenael Strutt, Motorola
Guenael Strutt, Motorola

15. Month Year
doc.: IEEE /1487r0
September 2006
Conclusion
The new HWMP procedure fulfils the same functionality as the text in D0.03
The new HWMP text uses a common set of messages and processing rules
The new text avoids repetition and attempts to avoid interpretation
Guenael Strutt, Motorola
Guenael Strutt, Motorola

16. Interworking September 2006 Month Year doc.: IEEE 802.11-06/1487r0
Guenael Strutt, Motorola
Guenael Strutt, Motorola

17. What is the Interworking problem?
Month Year
doc.: IEEE /1487r0
September 2006
What is the Interworking problem?
Multiple portals on the same or on connected LAN segments
Broadcast loops/storms
Portal shutdown by 802.1D because there are multiple paths to the same node
Guenael Strutt, Motorola
Guenael Strutt, Motorola

18. Solutions that do not impact 802.1D
Month Year
doc.: IEEE /1487r0
September 2006
Solutions that do not impact 802.1D
Configure only one mesh portal per LAN segment
Not acceptable as a general solution – if only because of back up considerations
Portal solution - allow multiple mesh portals per LAN segment to be configured and provide protocol to select one of them as the active portal
Requires a portal arbitration protocol for connected portals
MP solution: allow multiple mesh portals per LAN segment but partition the mesh such that there is no mesh connection between the partitions (=broadcast domains)
Requires that MPs make use of only one connected portal
Means only one portal per broadcast domain at any time
Guenael Strutt, Motorola
Guenael Strutt, Motorola

19. Implications for the standard
Month Year
doc.: IEEE /1487r0
September 2006
Implications for the standard
For 2. : Define protocol for active portal/root portal selection
Add Portal Type/LAN Segment identifiers
Connected / LAN Segment ID
Not Connected
For 3. : Define “portal domain identifier” and how it is used
Allows MPs to ignore broadcasts from outside their “broadcast domain”
Guenael Strutt, Motorola
Guenael Strutt, Motorola

20. Month Year
doc.: IEEE /1487r0
September 2006
Straw poll
Partition the mesh such that there is one portal per “portal domain”
Requires domain identification in broadcast e.g. Portal (MAC) Address
Provides means for improving broadcast efficiency, albeit with appropriate configuration
For:
Against:
Abstain:
Guenael Strutt, Motorola
Guenael Strutt, Motorola

21. Radio-Aware Optimized Link State Routing
Month Year
doc.: IEEE /1487r0
September 2006
Radio-Aware Optimized Link State Routing
Guenael Strutt, Motorola
Guenael Strutt, Motorola

22. Month Year
doc.: IEEE /1487r0
September 2006
RA-OLSR
We provide an action frame format and information elements (IE) specifications for RA-OLSR protocol, which are missing in Clauses and of the current draft (D0.03).
We also provide updated RA-OLSR texts for Clause 11A.5 based on the new action frame format and IE specifications.
Guenael Strutt, Motorola
Guenael Strutt, Motorola

23. Month Year
doc.: IEEE /1487r0
September 2006
Text Modification
The RFI ad hoc team recommends that changes be made to P802.11s/D0.03 according to the following submissions:
r2: To add an RA-OLSR action frame format and IEs
r0: Updates of texts in clause 11A.5
We would like to bring this text to a vote on Wednesday 9/20 during the TGs session.
Guenael Strutt, Motorola
Guenael Strutt, Motorola

24. References IEEE P802.11s Draft D0.03
Month Year
doc.: IEEE /1487r0
September 2006
References
IEEE P802.11s Draft D0.03
K. Kim et al., “Action Frame Format and Information Elements Specifications for RA-OLSR,” IEEE /1395r2.
K. Kim et al., “Updated RA-OLSR Texts for Clause 11A.5,” IEEE /1464r0.
Guenael Strutt, Motorola
Guenael Strutt, Motorola

25. Mesh Address Extension (Based on 6-Address Scheme)
Month Year
doc.: IEEE /1487r0
September 2006
Mesh Address Extension (Based on 6-Address Scheme)
Guenael Strutt, Motorola
Guenael Strutt, Motorola

26. MAC Frame Format Mesh Header September 2006
Month Year
doc.: IEEE /1487r0
September 2006
MAC Frame Format
Octets:2 2 6 6 6 2 6 2
4~16
0-tbd 4
FCS
Frame Control
Dur
Address 1 RA
Address 2 TA
Address 3 DA
Seq Control
Address 4 SA
Qos Control
Mesh Header
Payload
Octets: 1
Mesh E2E Seq Number 2
Time To Live 1 12
Mesh Flags
(Optional) Mesh Addressing
Bit 0: Address Extension (AE)
Bits 1-7: Reserved for future use
Address 5 (6 octets)
Address 6 (6 octets)
These fields are always present in mesh frames.
Mesh Header
Guenael Strutt, Motorola
Guenael Strutt, Motorola

27. Usage of Address Fields
Month Year
doc.: IEEE /1487r0
September 2006
Usage of Address Fields
To DS
From DS
AE Flag
Address 1
Address 2
Address 3
Address 4
Address 5
Address 6
RA=DA
TA=SA
BSSID
N/A
N/P*
N/P 1
TA=BSSID SA
RA=BSSID DA RA TA
Mesh DA
Mesh SA
* N/P = Not Present
11s MAC Header (up to Mesh TTL field)
Address 5
Address 6
Frame Body
FCS
When the AE flag = 0, all fields have their existing meaning, and there exist no “Address 5” and “Address 6” fields – this assures compatibility with existing hardware and/or firmware.
Guenael Strutt, Motorola
Guenael Strutt, Motorola

28. Month Year
doc.: IEEE /1487r0
September 2006
Proposed Changes
Changes are proposed in the following clauses (see [6] for details):
7.1.2: Change of Mac frame format
a: Descriptions of the new “Mesh Header” field
11A.4.4: Update of the descriptions of data message forwarding based on mesh forwarding extension
Guenael Strutt, Motorola
Guenael Strutt, Motorola

29. Month Year
doc.: IEEE /1487r0
September 2006
References
L. Chu et al., “ST+UCLA TGs Mesh Network Proposal,” IEEE /0379r0.
H. Gossain et al., “Packet Forwarding for Non-routable Devices in Multi-hop Wireless Mesh,” IEEE /0661r0.
J. Kruys and S. Rahman, “Mesh Encapsulation”, Rev. 3.
D. Engwer, “’WDS’ Clarifications,” IEEE /0710r0.
IEEE P802.11s/D0.03
K. Kim et al., “Proposed Texts for TGs Comment Resolution,” IEEE /1464r1.
Guenael Strutt, Motorola
Guenael Strutt, Motorola