Evading the Frame Reordering Trap

 	How to avoid debate, delay, and aggravation over frame reordering by the 802.11 MAC – WITHOUT compromising power management functionality.
 	
Michael Fischer
Digital Ocean, Inc.

May 6, 1996

Summary of the Impasse
 	The recent identification of a conflict between higher–layer assumptions about frame ordering between MAC service entities and the behavior of the 802.11 MAC has created a “lose/lose” situation:
•	If strict frame ordering must be maintained to achieve ratification of the standard, the power management functions in the current draft may need to be removed.  Doing so renders the result useless for mobile applications, which represent a substantial portion of the target usage.
•	If the only way to obtain approval of the power management functions is to convince 802.1 (and/or ISO) to modify their functional requirements due to the unique characteristics of wireless networks, there is a likelihood (certainty?) of lengthy delays, which could render this standard irrelevant.
 	HOWEVER, there is another approach . . .
Service Classes to Indentify Reordability
	The alternative is to have TWO asynchronous service classes:
•	“Reorderable {asynchronous} Service”
Frames passed down from LLC requesting Reorderable Service may be buffered by MAC entities {APs} due to the power management state of the destination station, or due to grouping of broadcast/multicast traffic after DTIMs.  This is the default service, and operates as specified in D3.1.
•	“Strictly Ordered {asynchronous} Service”
Frames passed down from LLC requesting Strictly Ordered Service shall be handled by MAC entities in the order received, without regard for power management states, nor broadcast/multicast destination addresses.  This service provides the behavior expected by certain higher layer protocols (LAT, NETBIOS, etc.), but is only usable by stations operating in Active {power management} state.
The Proposed Mechanism
 	1) Allow “Reorderable” and “Strictly_Ordered” service classs in the MA-UNITDATA.request.
–	A request for “Strictly_Ordered” at a station associated with a BSS not providing this service, shall be rejected with “unavailable service class” MA-UNITDATA-STATUS.indication.
–	A request for “Reorderable” at a station associated with a BSS only providing Strictly_Ordered service may be accepted, with “Strictly_Ordered” as the “provided service class” or rejected, due to “unavailable service class” based on a MIB setting.
 	2) Convey service class information in the MAC header of each MSDU.
–	There are several places we could put the “do not reorder” bit.
I recommend the “reserved” bit in the Frame Control field.
 	3) At the destination, the service class used for the MSDU is reported in the MA_UNITDATA.indication, permitting an LLC entity which cannot tolerate reordering to discard potentially–reordered MSDUs.
–	The potential of reordering exists only for MSDUs with a group destination address.
The Proposed Mechanism (cont.)
 	4) “Do not reorder” is tested in each MSDU received by a MAC entity:
–	Upon acceptance of a unicast MSDU from the WM or DSM with “do not reorder” set (=1), the MAC entity enqueues the MSDU for transfer, without regard for the power management state of the addressed destination.
–	The MAC entity handles a multicast MSDU with “do not reorder” set (=1) identically as a unicast MSDU, and does not indicate its existence in the DTIM.
 	5) MSDUs entering the DSM via a portal can be marked as reorderable or strictly ordered.  To the extent that portal behavior is defined in the standard (or may be defined in the future), a managed object (GET–REPLACE) can control the reorderability of inbound MSDUs on a per–portal basis.
Recommendation to resolve this issue
Recommendation:
	To avoid a prolonged debate over frame reorderability, and to avoid functional compromises in the area of power management and point coordination functions, 802.11 should provide an alternate, “strictly ordered” service in addition to the “reorderable” service implicit in D3.1.
Motion:
	A formal motion is not possible because the text is not yet available. (I only thought of this approach on May 3.)  If this approach is of interest to the MAC group, the author of this submission volunteers to have text changes available no later than Thursday morning (May 9).