May 2004 doc IEEE 802 11 040602 r

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 ESS-Mesh: Things That Make Me Go Hmm Thomas Maufer NVIDIA Corporation 10– 14 May 2004 Submission 1 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Motivation • Wanted to find any “boundaries” for our work in the base spec – Definitions – MAC behaviors – etc. • Wanted to understand how an unmodified STA might interact with a real ESS (mesh or otherwise) Submission 2 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Some Initial Questions • What is an ESS? – How is an ESS-Mesh different than a “legacy ESS”? • What is a mesh. AP? – Is it different from a “legacy AP”? • If so, why? – Does there need to be any coordination of Beacon generation when operating in an ESS-Mesh? • IEEE 802. 11 MAC leaves a lot to the reader’s imagination when describing ESS behavior. – IEEE 802. 11 r and IEEE 802. 11 s are both doing work in the same area – it’s possible that they will “interfere” with each other. . . Submission 3 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 What is an ESS? • I think of an ESS-Mesh as a kind of “zeroconfig ESS”. – This assumes we’ll be successful. • Doubters may leave now. • What if there is significant BSS overlap in part of the ESS? – I think this is inevitable, given that the mesh. APs are [weakly] mobile. Submission 4 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Isn’t an ESS-Mesh just an ESS? • I’d like to keep the definition of ESS unchanged. – From IEEE 802. 11 -1999 (R 2003): • 3. 25 extended service set (ESS): A set of one or more interconnected basic service sets (BSSs) and integrated local area networks (LANs) that appears as a single BSS to the logical link control (LLC) layer at any station associated with one of those BSSs. • Proposed working definition: – “A collection of BSSs, each controlled by a single mesh. AP, under one [E]SSID. ” Submission 5 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 ESS-Mesh Differences • How is an ESS-Mesh different than a “legacy ESS”? – “Smart Bridging” across the WDS • Can potentially optimize unicast and multicast delivery to minimize bandwidth demands. Submission 6 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 ESS-Mesh Differences? (cont. ) • How else is an ESS-Mesh different than a “legacy ESS”? – Overlapping BSSs can cause unintended behaviors. . . • STAs associate with the AP that they prefer (strongest signal, whatever). – Not much of a problem. • Overlapping BSS’s can become synchronized in their timing. – Could be problematic if Beacons interfered with each other! – Infrastructure mode Beacon timing doesn’t appear to cleanly allow for multiple co-located APs needing to send Beacons at the same time. • Should mesh. APs use contention to send Beacons, similar to the way Beacons are sent in IBSS mode? Maybe so. . . Submission 7 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 What about Overlapping BSSs? • What if the TBTTs in multiple BSS’s become synchronized? Multiple Beacons could need to be generated at the same time. – In-progress frame exchanges in overlapping BSS’s could cause CCA failures in a different [overlapping] BSS when its TBTT happens. – Should mesh. APs use a contention mechanism to send Beacons, similar to the way they are sent in IBSS mode? • Beacon MMPDUs should be treated as exceptions, and not flooded across the ESS, right? Submission 8 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 What is a Mesh. AP? • Is it different in any way than a “legacy” IEEE 802. 11 AP? – I don’t think so. . . except that it will support some set of mesh routing protocols in addition to its currently defined AP duties. – If a mesh. AP is a real AP. . . • Does it send its own Beacons? – Almost certainly yes. • What is its BSSID? – Its own MAC address, as usual. Submission 9 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 What is a Mesh. AP? (cont. ) • Mesh. APs are semi-mobile APs – Not only can STAs can move relative to APs, but the APs can also move relative to their associated STAs. – Makes overlapping BSSs a much more likely situation. • What if a mesh. AP overlaps with another mesh. AP on the same channel? – Group-addressed traffic from each mesh. AP self-interferes (sort of) – even if multicast forwarding uses a tree. Submission 10 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Implications for Multicast • If two STAs are associated to two different APs, at least broadcast MPDUs or MMPDUs will be duplicated across the portions of the BSSs that overlap. – In fact, they must be, since STAs will reject group-addressed traffic unless the BSSID in the frame matches the MAC address of the AP to which it is currently associated. Submission 11 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Implications for Multicast (cont. ) • This is a waste of bandwidth. – Is it unavoidable? • Yes. . . I don’t see how it can be avoided. – The best we can hope for is to make sure multicast traffic only crosses the “mesh backbone” once. • What the heck is a “mesh backbone”? – Meaningless. . . every mesh. AP can have associated STAs • We can’t presume that some mesh. APs are only for use in the infrastructure – that would be a very constraining assumption! • Every mesh. AP will have to do up to two things: 1) “unicast” a multicast frame along the tree, and 2) deliver the multicast locally in its BSS, if it has at least one associated STA. Submission 12 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 STA/ESS Interactions • Shall we assume that this is identical to STA/BSS interactions? – I think that’s reasonable. . . • Associating with only a single AP makes each STA’s behavior safe. – Note that a presentation yesterday in IEEE 802. 11 r suggested that since all APs are attached to Ethernets, it’s “safe” to have multiple associations. Yikes! • Here’s a place where relaxing an assumption actually causes unintended constraints, since the WDS is a shared medium. • We don’t want to assume that all APs are connected to Ethernet switches (don’t want to assume that they’re not, either!). Submission 13 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Common Triggers • Need to define how a STA moves throughout an ESS – Probably just adding detail to what is already defined in IEEE 802. 11 -1999 (R 2003) • Must identify which clauses will need work ASAP! • As in IEEE 802. 11 r, inter-AP roaming (formally known as “BSS-Transition”) is triggered by Reassociation messages. – 802. 11 r is really focused on the problem from the inter-AP perspective – In our case, inter-AP roaming is likely to be better named as “intra. ESS roaming” • The focus of IEEE 802. 11 s is the intra-ESS perspective – Perhaps that distinction means we won’t be interfering with each others’ work too badly. Submission 14 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Be Wary – Dependencies on. 11 r • 5. 4. 2. 3 Reassociation – Association is sufficient for no-transition message delivery between IEEE 802. 11 stations. Additional functionality is needed to support BSS-transition mobility. The additional required functionality is provided by the reassociation service. Reassociation is a DSS. The reassociation service is invoked to move a current association from one AP to another. This keeps the DS informed of the current mapping between AP and STA as the station moves from BSS to BSS within an ESS. Reassociation also enables changing association attributes of an established association while the STA remains associated with the same AP. Reassociation is always initiated by the mobile STA. Submission 15 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Process (Proposed) • My opinion is that if we can define an ESS in the context of IEEE 802. 11, then there is no need to limit ourselves to just one routing protocol. – But we should define at least one mandatory-toimplement routing protocol. • My preference is something basic but extensible that meets all the PAR’s requirements. – i. e. , unicast, multicast, etc. • Think about the IP world: – Unicast routing: RIP, RIPv 2, RIPng, OSPFv 2, OSPFv 3, BGP, etc. – Multicast routing: DVMRP, MOSPF, PIM-DM, PIM-SM, etc. Submission 16 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Carts and Horses • By obsessing over “use cases” I think we risk distracting ourselves. That’s just my opinion. – No successful technology is ever used the way the designers intended. • For example, Pringles® cans. – My preference would be to define “operational requirements” and then decide if the proposed mesh solutions meet those stated requirements. • Convergence time • PAR requirements – Multicast, unicast routing, 32 nodes, etc. Submission 17 Thomas Maufer NVIDIA Corporation

May 2004 doc. : IEEE 802. 11 -04/0602 r 01 Maybe Next Time. . . • I actually have a proposal on mesh routing. – I think this is actually not a hard problem • My proposal is scalable and simple (perhaps too naïvely so!), and covers – PAR requirements – Secures the mesh routing protocol itself – But leaves STA-to-AP security in place • as specified in IEEE 802. 11 i – In general leaves STA behavior unchanged. • We’ll see where this process takes us. – Be gentle! Submission 18 Thomas Maufer NVIDIA Corporation