Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft

From: Satoru Matsushima <[email-masked]>
Date: Sat, 20 Oct 2012 18:40:57 +0900

Zhen, Rong,

On Fri, Oct 19, 2012 at 6:47 PM,  <[email-masked]> wrote:
>
> Hello Satoru,
>
> If you kind help to start the survey, we can support you as well.
>

I think I can help you anything what I can do. But if you want to
achieve your goal, you need much more support from the community. I
believe that the first step should be more clear problem statement.
One of my idea as ToC of the PS doc is following:

1. Why CAPWAP
2. What is Split-MAC and Local-MAC in CAPWAP
3. A clarification of use case of both Split-MAC and Local-MAC
4. Problem statement
5. A survey of current implementation of CAPWAP
    4.1. Supported mode and function
    4.2. Interoperability
    4.3. Scalability
6. Goal of CAPWAP improvement

> By the way, network architecture of AP-AC-AAA has been proved good for wifi
> handover performance,
>

I think that you may answer in the document for how much improved
performance should be your target.

cheers,
--satoru

---

From: Hui Deng <[email-masked]>
Date: Sun, 21 Oct 2012 21:47:01 +0800

Hi Satoru,

Thanks a lot for your review and proposal.

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.

For us, we have both of them deployed, it depends on the operators's
strategy.

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.

thanks a lot for your review and discussion.
Best regards,

-Hui
2012/10/20 Satoru Matsushima <[email-masked]>

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 22 Oct 2012 10:56:49 +0900

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

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.

You are welcome, hope that helps you.
--satoru

---

From: Hui Deng <[email-masked]>
Date: Mon, 22 Oct 2012 13:58:46 +0800

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-masked]>

> > 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.
> >
> terminated at AC other than AP. This is the reason in our current PS draft
> to only define Split MAC function scope.
> >
> 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.
>
> >
> > 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.
> 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.
>
>