RFI Update Date: 2006-09-19 Authors: September 2006 Month Year doc.: IEEE 802.11-06/1487r0 September 2006 RFI Update Date: 2006-09-19 Authors: 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 <stuart.kerry@philips.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 <patcom@ieee.org>. Guenael Strutt, Motorola Guenael Strutt, Motorola

Month Year doc.: IEEE 802.11-06/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

Month Year doc.: IEEE 802.11-06/1487r0 September 2006 RFI Update The RFI ad hoc team is coordinated by Avinash Joshi (Avinash.Joshi@motorola.com) The team has focussed on four specific topics HWMP normative text 11-06-1110r1 “HWMP Overview” RA-OLSR normative text 11-06-1395r1 “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 11-06-1091r0 “Interworking Considerations” Guenael Strutt, Motorola Guenael Strutt, Motorola

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

HWMP Overview HWMP is a hybrid protocol because Month Year doc.: IEEE 802.11-06/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

HWMP (operation with Root) Month Year doc.: IEEE 802.11-06/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

HWMP – Non Registration mode Month Year doc.: IEEE 802.11-06/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

HWMP – Non Registration mode Month Year doc.: IEEE 802.11-06/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

HWMP – Registration mode Month Year doc.: IEEE 802.11-06/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

HWMP – Registration mode Month Year doc.: IEEE 802.11-06/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

HWMP – Registration mode Month Year doc.: IEEE 802.11-06/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

HWMP – Registration mode Month Year doc.: IEEE 802.11-06/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

HWMP – Registration mode Month Year doc.: IEEE 802.11-06/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

HWMP – Registration mode Month Year doc.: IEEE 802.11-06/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

Month Year doc.: IEEE 802.11-06/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

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

What is the Interworking problem? Month Year doc.: IEEE 802.11-06/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

Solutions that do not impact 802.1D Month Year doc.: IEEE 802.11-06/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

Implications for the standard Month Year doc.: IEEE 802.11-06/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

Month Year doc.: IEEE 802.11-06/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

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

Month Year doc.: IEEE 802.11-06/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 7.3.2 and 7.4.5 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

Month Year doc.: IEEE 802.11-06/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: 11-06-1395r2: To add an RA-OLSR action frame format and IEs 11-06-1464r0: Updates of texts in clause 11A.5 We would like to bring this text to a vote on Wednesday 9/20 during the 1330-1530 TGs session. Guenael Strutt, Motorola Guenael Strutt, Motorola

References IEEE P802.11s Draft D0.03 Month Year doc.: IEEE 802.11-06/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 802.11-06/1395r2. K. Kim et al., “Updated RA-OLSR Texts for Clause 11A.5,” IEEE 802.11-06/1464r0. Guenael Strutt, Motorola Guenael Strutt, Motorola

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

MAC Frame Format Mesh Header September 2006 Month Year doc.: IEEE 802.11-06/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

Usage of Address Fields Month Year doc.: IEEE 802.11-06/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

Month Year doc.: IEEE 802.11-06/1487r0 September 2006 Proposed Changes Changes are proposed in the following clauses (see [6] for details): 7.1.2: Change of Mac frame format 7.1.3.5a: 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

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