Satoru, I understand better now, excuse me, that I made some confusion about local mac and split mac, exactly, we have done some work before, below are analysze:
there are 3 of them defined: 1) functions Distribution Service Integration Service Beacon Generation Probe Response Generation Power Mgmt/Packet Buffering Fragmentation/Defragmentation Assoc/Disassoc/Reassoc 2)QoS Classifying Scheduling Queuing 3) RSN (WPA2) IEEE 802.1X/EAP RSNA Key Management IEEE 802.11 Encryption/Decryption The problem is both split and local mac don't have precise definition where to do this work, some of them are done in AP, others are done in AC. like: Distribution service, Fragmentation, Scheduling, Encryption. For this reason it is not good for interoperation between AP and AC. we had survey already, depends on survey company about 48 percentage of them support Local MAC, others are supporting Split MAC, what we want to propose is to define a hybrid -mac model which has precise requirement about all of the functions, if you are interested in this, we welcome to on board. thanks a lot for the discussion Best regards, -Hui 2012/10/22 Satoru Matsushima <[email protected]> > Hui, > > On 2012/10/21, at 22:47, Hui Deng wrote: > > > For the difference of split mac and Local Mac, it's all of matter of > either 802.11 or 802.3 over CAPWAP Ctrl/Data Tunnel. > > > > For Local Mac, all functions will be based on AC, because 802.11 will be > terminated at AC other than AP. This is the reason in our current PS draft > to only define Split MAC function scope. > > > > Most of above has been stated by previous CAPWAP RFCs. > > I think you meant that the remote-mac terminated _all_ 802.11 frame at AC > other than AP. Yes, RFC4118, which you might cite in a further draft, has > described well CAPWAP models like as follow. > > > > > +--------------+--- +---------------+--- +--------------+--- > > | CAPWAP | | CAPWAP | | CAPWAP | > > | functions |AC | functions |AC | functions | > > |==============|=== |---------------| |--------------| > > | | | non RT MAC | | |AC > > | 802.11 MAC | |===============|=== | 802.11 MAC | > > | |WTP | Realtime MAC | | | > > |--------------| |---------------|WTP |==============|=== > > | 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP > > +--------------+--- +---------------+--- +--------------+--- > > > > (a) "Local MAC" (b) "Split MAC" (c) "Remote MAC" > > > > > > > > > For us, we have both of them deployed, it depends on the operators's > strategy. > > > > I do understand that. We also operate wifi service too. > > > > If there is a problem about how Local MAC has Interop issue, this PS > draft would be happy to include them, the draft is still open. > > I am think that AP pass all 802.11 to ACs, it may not have an issue, > because 802.11 is a standard. > > > > Other problems described in current PS draft are not tighted with either > Split MAC or Local MAC. > > > > So you mean that local-mac and remote-mac doesn't have interoperability > issues in your experience but split-mac does have that. I think it would be > nice if the draft describe well why the IETF need to revisit CAPWAP for > split-mac interoperability as you requested even other two could be > interoperable. I guess that those would be to make much better AP hand-over > experience, scalability and rich control functions which the current CAPWAP > doesn't have. > > > > thanks a lot for your review and discussion. > > Best regards, > > You are welcome, hope that helps you. > --satoru > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
