| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 ARC Reflector ---
HI, Joe, 1) No good reason, except it fit atheistically. I thought having two Mesh Gates got too crowded. But, having exactly one of everything felt somehow “sterile”, but also didn’t make it clear that the Portal is different (there is only one of them). So, it’s a compromise. I’m happy to adjust if there is sufficient desire (and direction). 2) Again, because it just got too complicated. I wanted the Portal on the far right, so the 802.3 physical medium was “set aside” from the 802.11 WMs. That meant that putting a Mesh STA in picture would mean it wasn’t adjacent to the Mesh Gate that it would be (presumably) paired to. The best option to do this seem to be to switch the Mesh Gate and the Portal, and add a Mesh STA off the right. But, this also begs the question of why there isn’t a Mesh STA not directly paired with a Mesh Gate, but paired with the other Mesh STA only. And, we quickly start to ask where do we stop? Again, I’m happy to adjust if there is sufficient desire and direction from the group. So, on both of those, others should please consider, and bring opinions to the ARC session on Monday. 1) Good point. (By the way, it could be “to the MAC SAP or to the DSAF” or “to the MAC SAP or to the DS via the DSAF”. Which do you think is more clear?) Any suggestions on how to find all (enough) of these? I’ll add this one to the document, but as you say, there may be more… 2) I think the “role specific behavior box” in 5.1.5.3 _is_ the DSAF, actually. And the box in 5.1.5.5 needs to have mesh and DSAF functions separated (although, again, the DSAF is still part of the role-specific behavior box, I believe). However, see also discussion in 11-15/540, which is modifying these boxes and text anyway. I think it’s best to leave it alone here (in 11-15/555) and fix it in 11-15/540. 3) I don’t think I agree, but let’s discuss. The first half the sentence, “destined for the DS” is still accurate. We could add “via the DSAF” here, but it’s not needed. The second half is talking about sending a frame to the 802.1X PAE, which I think is still correct, as is. (Although, we could argue whether the PAE is “in” the AP – but this is a new topic and a bit out of scope for this discussion.) Yes, I agree that in general these type of corrections/enhancements should be made. The tough part is finding the time to ferret them all out. I encourage everyone to do what they can (myself included). Mark From: *** 802.11 Architecture Standing Committee *** [mailto:STDS-802-11-ARC@xxxxxxxx] On Behalf Of Levy, Joseph S --- This message came from the IEEE 802.11 ARC Reflector --- Hi Mark and All, Overall, I agree that the current proposed changes should be incorporated into REVmc and that it will enhance the 802.11 standard to make these changes. So I support this document. I do however have two questions related to the proposed Figure R-1: 1. Why are two APs included in the figure? It seems to me that one would be adequate to define where the DS SAP is on the AP. (Though the old diagram did have ellipsis between the two APs and the two mesh gates to show that numerous APs and mesh gates could be connected to the DS. But, I think this is clear from other architecture diagrams.) 2. Why is there no mesh STA (non-Mesh Gate STA) in the figure? The figure clearly shows that non-AP STAs do not have DS SAPs, but the same is not shown for mesh STAs. Should we add a mesh STA to the DS architecture diagram? Also I am concerned that there may be references in the specification outside of sections 3 and 4 that will need to be updated. For example: 1. in 5.1.5.1 the following text is present: “During reception, a received Data frame goes through processes of possible A-MPDU deaggregation, MPDU header and cyclic redundancy code (CRC) validation, duplicate removal, possible reordering if the block ack mechanism is used, decryption, defragmentation, integrity checking, and replay detection. After replay detection (or defragmentation if security is not used), possible A-MSDU deaggregation, and possible MSDU rate limiting, one or more MSDUs are, delivered to the MAC SAP or to the DS.” 2. The switching function as described in 5.1.5.3 AP role and 5.1.5.5 Mesh gate role, should probably be updated so that it is a function of the DSAF. 3. In 8.2.4.1.4 To DS and From DS fields, the meaning of the To DS/From DS values are described: “A Data frame destined for the DS or being sent by a STA associated with an AP to the Port Access Entity in that AP.” Given the new DSAF definition it should probably read: “…. with an AP to the DSAF.” There are probably more places that need to be updated, but I haven’t’ done complete search. Do people agree that these type of corrections/enhancements should be made? Regards, Joseph From: *** 802.11 Architecture Standing Committee *** [mailto:STDS-802-11-ARC@xxxxxxxx] On Behalf Of Mark Hamilton --- This message came from the IEEE 802.11 ARC Reflector --- All, In July, I presented what I think is a final version of the proposal for text changes to make the DS-SAP normative text (primarily by moving Annex R into a new clause, probably clause 7). This proposal is in: https://mentor.ieee.org/802.11/dcn/15/11-15-0555-04-0arc-normative-ds-sap-proposal.docx. At the end of the July REVmc session, we left things as (per the minutes), “Would expect to bring to the September and have ARC final review and motion in REVmc”. We ran out of time to consider this in Bangkok, in September. Thus, I am planning to have ARC re-confirm the document at the November meeting in Dallas, and then bring it to REVmc for a motion, also during the Dallas meeting. If anyone has any comments on the document, those would be very welcome – before the Dallas REVmc session and motion, if possible! ;) Thanks. Mark |