Subject: Re: [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC mode

From: "Puneet Agarwal" <[email-masked]>
Date: Tue, 23 May 2006 19:03:15 -0700

Hi Pat,

Your recollection is correct. There is need to support Split MAC with
802.3 payload.

I have cut and pasted the text from the original email on this subject.
As you can see from the description, the 802.11 MAC functions are being
distributed between the WTP and the AC (hence Split MAC) with the caveat
that the Integration service is being done at the WTP.

"**********************CUT and PASTE START
*****************************************
From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Thursday, March 23, 2006 2:08 PM
To: [email-masked]
Subject: [Capwap] Data tunneling between WTP <->AC

Hi All,

One of the recommendations of the evaluation team was to have a mode to
tunnel 802.3 frames between WTP and AC. It seems that that requirement
was interpreted as tunneling 802.3 frames for local MAC. However after
talking to various folks at IETF 65 (dallas), it seems the intent was to
tunnel 802.3 frames in the split MAC (and not local MAC).

Hence I would propose the following:

(a) Delete the tunneling of 802.3 frames between AC<->WTP for Local MAC
and replace it with (b).

(b) Add tunneling 802.3 frames between AC <-> WTP for Split MAC.
Following the notation in section 11.1.1, a new variant of Split MAC
should be defined (based on recommendation of the eval team) as follows.
I have marked the changes wrt the draft-00's section 11.1.1 with *
(note: section 11.1.1 remains unchanged - this proposal is an addition
to and not a replacement for section 11.1.1):

        Function                               Location

        -------------                               -------------
            Distribution Service                       AC
            Integration Service                       *WTP*
            Beacon Generation                       WTP
            Probe Response                           WTP
            Power Mgmt/Packet Buffering        WTP
            Fragmentation/Defragmentation      WTP
            Assoc/Disassoc/Reassoc              AC

       802.11e
            Classifying                               AC
            Scheduling                               *WTP* (I don't
understand why section 11.1.1 shows .11e scheduling at AC)
            Queuing                                   WTP

       802.11i
            802.1X/EAP                                AC
            Key Management                        AC
            802.11 Encryption/Decryption      *WTP*

Thanks.

-Puneet

********************CUT and PASTE END
***************************************" 

Thanks.

-Puneet

-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Tuesday, May 23, 2006 1:43 PM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: Re: [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC
mode

Pat Calhoun (pacalhou) wrote:
> All,
>  
> I'd like to re-open the discussion around the use of 802.3 tunneling.
> When the original proponents of encapsulating 802.3 came forth, they 
> requested that local MAC support both local bridging and 802.3.
> Consequently, the split MAC mode only supports the native frame format

> (e.g., IEEE 802.11 supports 802.11 frame formats).
> 
> Puneet raised an issue that he believes that Split MAC must support
> 802.3 as well, and not to support any tunneling in local MAC mode.
> Puneet, correct me if I am incorrect here.
> 
> Well, the issue here is that including an 802.3 frame in CAPWAP is NOT

> split MAC. Many fields are lost in the translation (e.g., four address

> field, 802.11e UP field). From memory, the folks that are asking for 
> the optional BSSID in the CAPWAP header to be optional also appears to

> be the ones that are favoring this issue (90). However, if one removes

> the BSSID field, how would the AC even know which BSSID an 802.1X is 
> being run against? The AC would lose all such information, and it's 
> not clear how we could support multiple SSIDs per WTP. Also not clear 
> how IAPP frame formats would be handled, as these would also lose 
> their BSSID context, which is important.
> 

802.1X frames come after the station has been associated. Therefore the
station mac address is know at the AC along with its BSSID mapping.
The source address of the 802.1X frame is used to map the frame to the
SSID.

Thanks,

Jim

> With that I would like to reopen this conversation.
>  
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit Cisco Systems 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap