Doc.: IEEE 802.11-05/0606r1



IEEE P802.11

Wireless LANs

|The Wireless Spanning Tree Protocol |

|Date: 2005-06-15 |

|Author(s): |

|Name |Company |Address |Phone |e-mail |

|Shah Rahman |Cisco | |+1 408 5251351 |sharahma@ |

| | | | | |

6.2.3 Introduction

Wireless Spanning Tree Protocol (WSTP) adds 802.11 extensions to the 802.1 Spanning Tree Protocol (STP). The protocol builds upon the proven and standardized tree building algorithms of 802.1d and its enhanced version 802.1w. As 802.1 protocols were originally designed for wired LAN environments, some customization is needed in order to adapt those in multihop, 802.11 mesh networks. As most of the core algorithms and protocols remain intact, this approach builds a powerful mesh routing solution based on existing transparent bridging techniques.

The advantages inherited from 802.1 technologies are:

• An integrated and ISO compliant architecture and proven performance in campus and corporate wired LAN networks

• MAC address based forwarding, self-configuring and self-healing properties

• Flexibility and extensibility of the cost metrics that allows rapid adaptation of 802.11 requirements and scopes

• Fits in seamlessly with 802.1d based LAN segments and makes interworking easy with other 802 LANs as well as higher layer, such as IP

Despite these advantages, 802.1 STP faces some challenges if applied in multihop 802.11 environments natively:

• Path cost metrics are static and of course, not radio aware

• Blocking established wireless links may be inefficient

• Could be slow in detecting dynamic and frequent changes in wireless links and adapting to the changes detected rapidly

• Of course, wired LANs never move and there is no mobility considerations in the core protocol

• Temporary loops can occur due to no/mis-configuration on some bridges/switches in the network

• Traffic may concentrate on some links and adversely affect wireless bandwidth availability

• May fail to take the full advantage of a meshed network by routing packets via the path that has the most available bandwidth and/or better temporal properties as the topology tree attempts to build upon persisting network variables

All of these issues are addressed by the WSTP enhancements of 802.1 STP. A bottom-up approach is taken where a WSTP-based network forms the basic building block of scaling up to larger mesh networks. A similar approach is taken in order to ensure QoS and multicast forwarding capabilities. The complete solution is termed “Bridged Wireless Mesh”.

1. Overview

If native 802.1 STP is used in multihop 802.11 networks, all mesh points would exchange BPDU frames and converge into a tree by selectively designating some links as “forwarding” and by blocking all other links. 802.1 STP cannot work until the low-level links are established and the protocol frames can be exchanged. Hence, radio link establishment and STP processes must work together in such a way that they can choose which links will be participating in the active topology when the tree is first established. This is achieved by:

1. Selecting a Root first - e.g. by self declaration

2. Mapping RF links to logical links and retaining only the best links (throughput/delay) as active links

This process requires broadcasting configuration messages only for each node added or dropped. Local filtering can prune these messages to the minimum needed to maintain the network’s (sub)tree(s). See also 6.2.3.3 etc.

All alternative links are recognized as “backup” and “alternate” links (as specified in 802.1w). These links are established as well, but, in “Sleep” mode. A single “Wakeup” frame wakes up the link for active communication when needed. This approach ensures that there are always standby links to quickly switch to should the active link fail due to interference or any other RF environment change as well as conserves power in low power devices by dozing device links not required in active communication.

The WSTP protocol:

• Makes 802.1 radio aware by adding protocol for neighbor discovery, path cost metrics distribution and (sub)tree definition:

o STP neighbor discovery via active/passive scanning

o Path cost metrics are flexible and can accommodate any metrics, such as QoS, load-balancing, etc.

o Sub-tree helps in facilitating unit or group mobility

• Supports flexible hybrid proactive/reactive routing where mesh points can either explicitly setup “Bridge Table” or defer until communication is needed

• Supports all of unicast, broadcast and multicast forwarding

• Uses Root selection biased towards the Portal by giving it a much higher absolute priority

• Provides path redundancy at all times via the Sleeping links or by maintaining a list of potential links whichever is preferred by a network and/or application

• Is independent of the number of radios available in a mesh point and work with both single or multiple radio designs

A WSTP-based mesh network is shown in Figure 6.2.3.2.

[pic]

Figure 6.2.3.2: A WSTP-based WLAN Mesh

2. WSTP Advertisements

Mesh points signal WSTP capabilities in beacon ‘Capability’ field (e.g. B14) so that WSTP capable devices can identify each other. Encoding BPDU frames into beacons as IEs (e.g. 0x40) helps mesh points discover spanning trees in the vicinity and find the best path to the Root Bridge of the tree prior to establishing radio links with other mesh points. Core STP “hello time”, “forward delay” and “max-age” parameters become factors of beacon interval of the mesh points.

Mesh points can request STP information via the probe-request ‘Request’ field. This helps them to request STP information when they want to join an up-and-running spanning tree, or have lost connection to a spanning tree and need to quickly re-establish it. The mesh points receiving the probe-request for BPDU reply with BPDU IE in probe-responses. The requestor mesh point then establishes an 802.11 link with the mesh point providing the best path to the Root Bridge and rapidly transition the link to the “ forwarding“ state.

Both “passive” and “active” methods avoid temporary loops completely by not allowing any radio links to be established unless explicitly instructed by the WSTP protocol. Note that BPDU IE contains the path cost metric as configured or specified in this document.

3. Root Selection and Topology Tree Creation

Root selection takes the presence of WAN/LAN link in a mesh into account and applies highest priority to it. That means a Portal will almost certainly emerge as the Root Bridge of a WSTP instance. A Portal’s mesh link advertises the highest priority and eventually wins as the Root Bridge. If there are multiple Portals, one of them could form a backup Root Bridge should the current Root fail. A Root switchover can be done quickly using basic 802.1 mechanisms. Alternatively, multiple Root Bridges can be used for more efficient forwarding.

The topology tree creation follows very similar steps as described in 802.1w standard (enhancement from 802.1d) and when the initial topology is created, radio links are established and each established radio link gets its appropriate role. A mesh point not part of an active WSTP instance may advertise itself as Root Bridge with a better path-cost than some other mesh points which are part of the instance. So that mesh points part of an a WSTP instance do not give into such claims, the Root Bridge pushes down a unique WSTP-ID to all its children upon (2*forward-delay) timer expiration when the spanning tree is first established. The WSTP-ID can be the Root Bridge-ID, but every member of the instance must cache this as WSTP-ID. All mesh points under this Root Bridge match BPDU IEs they receive in beacons and probe-responses against this WSTP-ID and filter out all unmatched ones. All mesh points advertise the WSTP-ID in the BPDU IE so that a new or returning mesh point/sub-tree can join the instance quickly rather than going through slower listening and learning states.

4. Topology Tree Maintenance

Once the topology tree is created, it is maintained by periodic BPDU generation by the Root Bridge and propagation throughout the WSTP instance. Usual 802.1 methods are followed; however, each mesh point feeds radio and management information into the WSTP protocol for quick detection of RF environment changes as well as attached station changes. Any such change can trigger a topology tree change, which can be one of two types:

1. WSTP link change: These changes are localized by maintaining alternate/backup links at all times

2. WSTP member change: These changes trigger Bridge Table update messages inbound to Root

In both cases, the tree re-configuration is contained and does not require any macro change in the topology. Note that initial BPDU broadcast rides the beacons and probe responses and thereby, does not require any special reliability or rate-limiting considerations. The periodic BPDUs are multicast and must be rate-limited appropriately. As 802.11 multicast may be unreliable, a suitable reliability mechanisms to avoid loosing BPDU is needed. Sending BPDUs unicast is a possible option. Further, in order not to consume too much wireless bandwidth, BPDU transmissions must be spaced out sufficiently – depending on local conditions. Each mesh point must buffer and deliver BPDUs downstream. All BPDUs are transmitted with highest priority so that they are priority delivered at the times of congestion in the network.

5. Bridge Table Setup and Bridging

Prior to describing how bridge tables are setup and packets are bridged, we need definitions of a few essential operations:

1. Register: Send all children mesh point and station addresses (both hardware and network addresses) as gratuitous ARP messages to ‘add’ to parent Bridge Tables (inbound to Root)

2. Deregister: Same as “Register” with ‘delete’

3. Path-Update: Same as “Deregister” but outbound

Proactive routing is achieved by the Register process with both mesh point and station addresses after a WSTP instance is established initiated by mesh points only. A mesh point can provide “Proxy ARP” services for stations and other mesh points that are unable to participate in ARP. When a station or mesh point first joins the spanning tree, its addresses are registered after a mesh point learns about its address via association. In downstream direction, every mesh point does a Bridge Table lookup and finds the output link for the IP/MAC address of a frame. If an IP/MAC binding is not found in Bridge Table, standard ARP process is followed. In upstream direction, all packets are forwarded inbound until a mesh point finds a Bridge Table entry for the IP/MAC address of a frame and forwards outbound. If the packet reaches the Root Bridge, it forwards the packet on its wired link if a Bridge Table entry is not found and outbound if an entry is found. Note that source learning is disabled in this case.

As proactive routing approach requires all mesh points to maintain a Bridge Table at all times, low-power devices may alternatively follow a reactive approach. In this approach, Register process is not required after the topology tree is created. An unknown packet is first flooded along the tree and all addresses are learned when a packet is first received from a station. The advantage of this approach is that there is no need to learn about a destination unless needed. This comes at the expense of flooded initial discovery. As this flooding is only along the topology tree, this approach is better suited for low-power environments where devices have limited memory and processing capabilities.

Note that a combination of hybrid approach can be followed where both explicit registration and source learning can be used. If a hybrid approach is followed, carefully designing the network with respect to mesh points and Portals can avoid any impact of protocol overhead and storage requirements on devices with limited capabilities.

6. Mobility Support

Note that mobility support is provided by the operations shown in the previous section. We can imagine a Sub-tree as a “military” or “emergency” unit, which may need to move as a unit. WSTP can provide support for mesh point and sub-tree mobility (excluding station mobility) via the following scenarios:

• Mesh point/Sub-tree leave

• Mesh point/Sub-tree join

• Mesh-point/Sub-tree switchover

All of these operation use Register, Deregister and Path-Update to facilitate efficient mobility.

6.2.4 Bridged WLAN Mesh

1. Overview

Although we have defined WSTP as the basic protocol for 802.11 WLAN mesh, we still have not solved the following problems:

• Scaling WSTP for larger mesh networks

• QoS/Stream based route selection

• Efficient multicast forwarding

• Efficient device role change

Using the WSTP-based mesh as the basic building block, we develop a complete WLAN mesh routing/interworking solution. We achieve this by replicating the basic building block suitably. The two fundamental extensions of the basic WSTP which enable this are:

• Lateral multiple trees

• Overlay multiple trees

These extensions meet the remaining requirements. Figures 6.2.4.1(A) and (B) show these two types of extensions. Note that device role change is an implementation issue and can be addresses as long as all mesh devices implement the minimum required set of features of WSTP and its extensions. The actual change in role can be either by configuration or automatic and required typically in military deployments.

[pic]

Figure 6.2.4.1(A): Lateral Multiple Trees

2. Lateral Multiple Trees

Multiple WSTP instances run on a one per- Portal basis where the Portal emerges as the Root Bridge of the spanning tree instance. The mesh interfaces of the Portals have the choice of doing one of the following and forming a backbone of the mesh:

a) Forming a hierarchy and running a backbone WSTP instance; or

b) Remaining flat with all WSTP instances and connect using 802.1s or MST protocol

c) Do (b) and use an L3 routing protocol to connect WSTP instances

A SMB mesh network may run (b) only. A campus mesh network may want to run a separate backbone spanning tree for traffic aggregation purposes. A community mesh network may remain flat as far as spanning tree is concerned and then use L3 routing protocols on the backbone in order to scale the network better and provide separate domains for service providers if needed. The last method may be further useful if there were multiple mesh networks interconnected via mesh-mesh portals.

It is possible for mesh points to hear beacons with BPDU IE from multiple spanning trees (each advertising that they have connectivity to different Portals). In such cases, the path-cost metric alone may not be enough to determine which WSTP is better. Hence, it must consider its local-link radio signal parameters, regularity of beacon arrivals and QoS parameters to finally choose a WSTP instance to join. Note that proper administrative boundaries can be built to make sure that mesh points can only join the WSTP instances they are allowed to via MESH-ID or ESSID.

A mesh point may hear sporadic beacons with better path-cost in the BPDU IE from another mesh point while it either hears regular beacons with worse path-cost a third mesh point or already has a link with another mesh point. A similar “Local-link Comparison Algorithm” (as above paragraph) is used to take a mesh point’s immediate neighborhood into account for eventually selecting which parent would be better. This hysteresis ensures stability of co-existing WSTP instances and helps avoid “ping-pong” or “gold-rush” effects.

[pic]

Figure 6.2.4.1(B): Overlay Multiple Trees

3. Overlay Multiple Trees

Overlay multiple WSTP instances run with the same Portal as the Root Bridge for all WSTP instances, but different tree structures are built. Mesh points are required to have only the ability to process 802.1Q VLAN tags (which should small in number) in BPDUs and data frames. One WSTP instance runs per-VLAN to segregate traffic into classes similar as 802.11e: Voice, Video, Best Effort, and Background. In this case, there can be up to 4 WSTP instances overlaid. Alternatively, Best Effort and Background traffic can be combined into a single tree instance and have 3 trees only. The number of trees to run and traffic classes to tie them are completely flexible. The formation of different trees can use different path-cost metrics in order build the most efficient tree for the traffic class to be transported over that tree. These path-cost metrics should be selected experimentally using real-life RF information as well as requirements of the traffic class in question. Each mesh point looks up the Bridge Table to determine which WSTP/VLAN a packet belongs to before forwarding it. The 802.1Q VLAN tags are inserted/removed into/from 802.11 frames by the first-hop mesh point starting with the end station.

4. Overlay Trees and QoS

Introducing the slim VLAN support with WSTP is powerful. Now user desired stream priorities can be encoded inside the 802.1Q VLAN tag of frames. This priority information can be carried from the end-user, through all the hops in between the end-user and Portal and to the Portal. Each intermediate mesh point can map this priority information to its 802.11e queues, access classes, EDCA parameters, etc. and achieve appropriate levels of QoS for the traffic class. This method ensures end-to-end QoS and WSTP instances can be run with different path cost metrics to setup trees for different applications each of them receiving appropriate levels of QoS. Traffic should no longer concentrate adversely on some links.

To support enhanced QoS, a new IE is embedded into BPDUs for QoS purposes. The “Per-Access Class Capacity IE or PC IE” is proposed. The PC IE has two fields:

a) The Access Category (AC)

b) The Available Admission Capacity (AAC in terms of medium time available per second)

An AAC of ‘0’ would mean that the link is not available for that AC. The PC IE in BPDUs further qualifies the BPDUs to be applicable to a particular access category. For example, a BPDU associated with PC IE that has Access Category field value of 3 (Voice) means that the BPDU is trying to advertise a path suitable for Voice. Note that this is one of the ways of building different WSTP instances. Further, the AAC in the PC IE is also expressing the amount of capacity available for Voice AC. This number can also be used as part of path-metric calculations of theWSTP algorithm. This approach can potentially avoid using VLANs for running multiple spanning trees and rather build separate WSTP instances for different traffic classes. We call such an instance “Traffic Routing Tree”. Note that this approach should be followed if VLAN support is not available in some mesh devices.

5. Overlay Trees and Multicast

Overlay structure of multiple spanning trees using VLANs has further benefits in multicast forwarding. Mesh points can use GVRP protocol is selectively choose on which VLANs they would like to receive multicast traffic from their parents recursively until the Root Bridge. Further, as VLANs are tied to traffic classes now, different types of multicast traffic are necessarily segregated to different WSTP instances. This implies that the Video tree will now transport Video streaming multicast traffic only and this tree is optimized with QoS on every mesh point in the network for Video. Note that it is possible to further categorize Video and Video multicast into different trees if needed.

As far as multicast protocol is concerned, there is no need to devise any new protocol. 802.1 and IGMP protocols should work quite well in WSTP-based mesh networks. Most applications are likely to use downstream multicast with sources outside the mesh network. Simple extension of existing L2 multicasting can allow efficient multicast routing if the source is inside the mesh. The WSTP approach aids these types of extensions quite effectively.

6.7 Interworking Support in a WLAN Mesh

With WSTP, interworking should be trivial. All of the following requirements are automatically met by the protocol and there is no extra work required except the Portals to recognize the dissimilar 802.1 LANs co-existing on them. As far as data forwarding is concerned, interworking is completely transparent:

• Appearing to higher layers as a current style 802 LAN (vertical interworking)

• Connecting to other 802 LANs using 802.1D (horizontal interworking)

• Be compatible with IP routing (of course it is)

• Efficient utilization of multiple mesh Portals: This is already achieved by running a single WSTP per Portal. If there is a single WSTP and multiple Portals, they are either used in a active/standby fashion or multi-Root load-balancing fashion

Moreover, each WSTP instance can be a LAN segment, which is granularity beyond what is expected by 802.11 TGs. In summary, seamless interworking is achieved by letting 802.1D to penetrate into WLAN mesh networks. However, wired STP and WSTP should not merge and remain as separate entities on Portals.

Figure 6.7 captures the idea.

[pic]

Figure 6.7: Interworking with WSTP-based WLAN Mesh

Additional Supporting Material

|Number |Name |Definition |Coverage |Notes |References |

| | | |(Yes/No) | | |

|AD1 |Reference submissions |A list of IEEE 802 submissions |Yes | |05/606 |

| | |related to the proposal, both | | |05/607 |

| | |documents and presentations. | | | |

|AD2 |Simulation and/or |Any proposal submission that includes|No | | |

| |experimental |simulation results must include a | | | |

| |methodology |description of the simulation | | | |

| | |methodology used for mesh | | | |

| | |simulations. The simulation | | | |

| | |methodology documentation should | | | |

| | |provide enough information to, in | | | |

| | |principle, reproduce the simulation | | | |

| | |(e.g., including node positions, | | | |

| | |traffic and propagation model | | | |

| | |(including PHY assumptions), packet | | | |

| | |sizes, etc.). | | | |

Coverage of Minimum Functional Requirements

|Number |Category |Name |Coverage |Notes |References |

| | | |(Complete / Partial / | | |

| | | |None) | | |

|FR1 |TOPO_RT_FWD |Mesh Topology Discovery |Partial | | |

|FR2 |TOPO_RT_FWD |Mesh Routing Protocol |Complete | | |

|FR3 |TOPO_RT_FWD |Extensible Mesh Routing |Complete | | |

| | |Architecture | | | |

|FR4 |TOPO_RT_FWD |Mesh Broadcast Data |Complete | | |

| | |Delivery | | | |

|FR5 |TOPO_RT_FWD |Mesh Unicast Data Delivery |Complete | | |

| FR6 |TOPO_RT_FWD |Support for Single and |Complete | | |

| | |Multiple Radios | | | |

|FR7 |TOPO_RT_FWD |Mesh Network Size |Complete |Focused on small to | |

| | | | |medium meshes | |

|FR8 |SECURITY |Mesh Security |Partial | | |

|FR9 |MEAS |Radio-Aware Routing Metrics|Complete | | |

|FR10 |SERV_CMP |Backwards compatibility |Complete | | |

| | |with legacy BSS and STA | | | |

|FR11 |SERV_CMP |Use of WDS 4-Addr Frame or |Partial | | |

| | |Extension | | | |

|FR12 |DISC_ASSOC |Discovery and Association |Partial | | |

| | |with a WLAN Mesh | | | |

|FR13 |MMAC |Amendment to MAC with no |Complete | | |

| | |PHY changes required | | | |

|FR14 |INTRWRK |Compatibility with |Complete | | |

| | |higher-layer protocols | | | |

Coverage of In-Scope Functions (Informative)

|Number |Name |Coverage |Notes |References |

| | |Yes / No / N/A | | |

|Mesh Topology Learning, Routing, and Forwarding (TOPO_RT_FWD) |

|TOPO_RT_FWD_SCP1 |Mesh topology discovery, including Mesh | | | |

| |Point neighbor discovery within a WLAN Mesh | | | |

|TOPO_RT_FWD_SCP2 |MAC address-based mesh routing protocols and| | | |

| |algorithms | | | |

|TOPO_RT_FWD_SCP3 |MAC-layer mesh broadcast/multicast and | | | |

| |unicast data delivery | | | |

|TOPO_RT_FWD_SCP4 |Architecture to support alternative routing | | | |

| |protocols and metrics | | | |

|TOPO_RT_FWD_SCP5 |Mesh routing with single-radio devices | | | |

|TOPO_RT_FWD_SCP6 |Mesh routing with multiple-radio devices | | | |

|TOPO_RT_FWD_SCP7 |Use of radio-aware route selection metrics | | | |

|TOPO_RT_FWD_SCP8 |QoS-based route selection | | | |

|TOPO_RT_FWD_SCP9 |Proactive routing | | | |

|TOPO_RT_FWD_SCP10 |On-demand routing | | | |

|TOPO_RT_FWD_SCP11 |Hybrid routing | | | |

|TOPO_RT_FWD_SCP12 |Mesh Point neighbor discovery within a WLAN | | | |

| |Mesh via passive scanning | | | |

|TOPO_RT_FWD_SCP13 |Mesh Point neighbor discovery within a WLAN | | | |

| |Mesh via active scanning | | | |

|TOPO_RT_FWD_SCP14 |Mesh routing in the presence of low-power | | | |

| |(e.g. battery-powered) Mesh Points | | | |

|TOPO_RT_FWD_SCP15 |Support for WLAN Mesh network configurations| | | |

| |with more than 32 Mesh Points. | | | |

|TOPO_RT_FWD_SCP16 |Ability to recognize changes in the topology| | | |

| |within a bounded time | | | |

|TOPO_RT_FWD_SCP17 |Ability to reconfigure the routing scheme | | | |

| |within a bounded time in response to | | | |

| |detected changes | | | |

|TOPO_RT_FWD_SCP18 |SAP interfaces and management primitives to | | | |

| |provide support to enable higher-layer | | | |

| |(e.g., Layer 2.5 and Layer 3) routing | | | |

| |protocols | | | |

|TOPO_RT_FWD_SCP_Other | | | | |

| |

|SECURITY_SCP1 |Secure association of Mesh Points to a WLAN | | | |

| |Mesh | | | |

|SECURITY_SCP2 |Securing a WLAN Mesh in which all of the | | | |

| |Mesh Points are controlled by a single | | | |

| |logical administrative entity for security. | | | |

|SECURITY_SCP3 |Secure data message exchange between Mesh | | | |

| |Points over mesh links | | | |

|SECURITY_SCP4 |Secure management message exchange between | | | |

| |Mesh Points over mesh links | | | |

|SECURITY_SCP5 |Secure topology and routing information | | | |

| |exchange between Mesh Points over mesh links| | | |

|SECURITY_SCP6 |Centralized authentication and key | | | |

| |management | | | |

|SECURITY_SCP7 |Distributed authentication and key | | | |

| |management | | | |

|SECURITY_SCP8 |Hybrid authentication and key management | | | |

|SECURITY_SCP9 |Static key support | | | |

|SECURITY_SCP10 |Dynamic key support | | | |

|SECURITY_SCP11 |Extension of IEEE 802.11i security | | | |

| |mechanisms for mesh | | | |

|SECURITY_SCP_Other | | | | |

| |

|MEAS_SCP1 |Specification of radio-aware metrics for use| | | |

| |by mesh routing protocols | | | |

|MEAS_SCP2 |Specification of radio-aware metrics for use| | | |

| |by mesh medium access coordination | | | |

|MEAS_SCP3 |Mesh link quality measurements | | | |

|MEAS_SCP4 |Mesh path quality measurements | | | |

|MEAS_SCP5 |Measurements to support the use of various | | | |

| |types of antennas in a mesh network | | | |

|MEAS_SCP6 |Mesh related measurements to aid STAs in | | | |

| |making roaming decisions, e.g., WDS capacity| | | |

| |currently available for traffic forwarding. | | | |

|MEAS_SCP_Other | | | | |

| |

|DISC_ASSOC_SCP1 |Protocols to allow Mesh Points to discover | | | |

| |WLAN Mesh networks | | | |

|DISC_ASSOC_SCP2 |Protocols to allow Mesh Points to associate | | | |

| |and disassociate with a WLAN Mesh network | | | |

|DISC_ASSOC_SCP3 |Protocols to allow Mesh Points to associate | | | |

| |and disassociate with other Mesh Points | | | |

| |within a WLAN Mesh | | | |

|DISC_ASSOC_SCP_Other | | | | |

| |

| MMAC_SCP1 |Mitigate performance degradation caused by | | | |

| |hidden nodes | | | |

|MMAC_SCP2 |Mitigate performance degradation caused by | | | |

| |exposed nodes | | | |

|MMAC_SCP3 |Flow control over multi-hop paths to avoid | | | |

| |performance degradation and/or meet QoS | | | |

| |goals. | | | |

|MMAC_SCP4 |Coordinating channel access across multiple | | | |

| |nodes to avoid performance degradation | | | |

| |and/or meet QoS goals in the multi-hop | | | |

| |network. | | | |

|MMAC_SCP5 |Traffic prioritization within a WLAN Mesh | | | |

|MMAC_SCP6 |Enhancements to make the MAC work well | | | |

| |across a range of different network sizes, | | | |

| |usage models, etc. | | | |

|MMAC_SCP7 |Mesh link communication coordination | | | |

|MMAC_SCP8 |Support for admission control to determine | | | |

| |if a particular flow can be admitted into | | | |

| |the mesh network based on the availability | | | |

| |of resources and existing usages. | | | |

|MMAC_SCP9 |Mangement of multiple classes of traffic, | | | |

| |for example when both BSS traffic and mesh | | | |

| |forwarding traffic are present in one device| | | |

| |(e.g. in a Mesh AP). | | | |

|MMAC_SCP10 |Rate control enhancements for efficient | | | |

| |multicasting and broadcasting in a mesh | | | |

| |network. | | | |

|MMAC_SCP11 |Improving spatial reuse in a mesh network. | | | |

|MMAC_SCP_Other | | | | |

| |

|SERV_CMP_SCP1 |Mesh Point DS Services (DSS) Integration | | | |

|SERV_CMP_SCP2 |WLAN Mesh compatibility with STA | | | |

| |mobility/roaming | | | |

|SERV_CMP_SCP3 |Techniques to allow WLAN Mesh to meet | | | |

| |802.11r system requirements | | | |

|SERV_CMP_SCP4 |Dissemination of STA-to- destination MeshAP | | | |

| |or STA-to-destination Mesh Portal routing | | | |

| |information in the WLAN Mesh. | | | |

|SERV_CMP_Other | | | | |

|Mesh Interworking (INTRWRK) |

| INTRWRK_SCP1 |Allow a WLAN Mesh to interface with higher | | | |

| |layer protocols | | | |

|INTRWRK_SCP2 |Interfacing a WLAN Mesh with other IEEE 802 | | | |

| |LANs | | | |

|INTRWRK_SCP3 |Support for interfacing a WLAN Mesh with | | | |

| |other IEEE 802 LANs using 802.1D | | | |

|INTRWRK_SCP4 |Support for efficient utilization of | | | |

| |multiple Mesh Portals in a single WLAN Mesh.| | | |

|INTRWRK_SCP_Other | | | | |

|Mesh Configuration and Management (CFG_MGMT) |

|CFG_MGMT_SCP1 |Protocol extensions to support | | | |

| |self-configuring formation of a WLAN Mesh | | | |

| |network | | | |

|CFG_MGMT_SCP2 |Interfaces to support 802.11h DFS compliancy| | | |

|CFG_MGMT_SCP3 |Interfaces and parameter exchange to enable | | | |

| |RF auto configuration support | | | |

|CFG_MGMT_SCP4 |Support for managed network management model| | | |

|CFG_MGMT_SCP5 |Support for unmanaged network management | | | |

| |model | | | |

|CFG_MGMT_SCP6 |Interfaces and parameter exchange to | | | |

| |exchange information about the capabilities | | | |

| |of Mesh Point devices | | | |

|CFG_MGMT_SCP7 |Mesh network channel selection | | | |

|CFG_MGMT_SCP8 |Mesh network Tx power control | | | |

|CFG_MGMT_SCP9 |QoS policy and management | | | |

|CFG_MGMT_SCP10 |Support for time synchronization of Mesh | | | |

| |Points if required by mesh services | | | |

|CFG_MGMT_SCP_Other | | | | |

Applicability to Usage Scenarios

|Number |Name |Definition |Data Included? |Notes |References |

| | | |Yes/No | | |

|UM1 |Residential |Include a description of how| | | |

| | |the proposal is applicable | | | |

| | |to residential usage | | | |

| | |scenarios, as described in | | | |

| | |[3]. | | | |

|UM2 |Office |Include a description of how| | | |

| | |the proposal is applicable | | | |

| | |to office usage scenarios, | | | |

| | |as described in [3]. | | | |

|UM3 |Campus/Community/Publi|Include a description of how| | | |

| |c Access Networks |the proposal is applicable | | | |

| | |to campus/community/public | | | |

| | |access usage scenarios, as | | | |

| | |described in [3]. | | | |

|UM4 |Public Safety |Include a description of how| | | |

| | |the proposal is applicable | | | |

| | |to public safety usage | | | |

| | |scenarios, as described in | | | |

| | |[3]. | | | |

|UM5 |Military |Include a description of how| | | |

| | |the proposal is applicable | | | |

| | |to military usage scenarios,| | | |

| | |as described in [3]. | | | |

-----------------------

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 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 .

Abstract

This submission introduces WSTP, which is an STP variant optimised for wireless mesh applications.

The submission respresents a partial proposal for technology to be standardised by 802.11 TGs

WSTP active links

WSTP alternate/backup links

Root Bridge

Root Bridge

WSTP_1

Root Bridge

WSTP_2

Root Bridge

WSTP_4

Root Bridge

WSTP_3

WSTP

/MST

Data WSTP links

Voice WSTP links

Root Bridge

PHY

LLC/MAC

IP routing

TCP

PHY

PHY

LLC/MAC

Boring

MAC bridging

LLC/MAC

802.11s

802.11s

802 LAN

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download