Subject: RE: [Capwap] Data tunneling between WTP <->AC

From: Michael Montemurro <[email-masked]>
Date: Mon, 27 Mar 2006 10:32:31 -0500

Puneet,
 
One issue I see with using 802.3 frames in split-MAC mode is that the WTP
would have to reformat every 802.11 management frame that it exchanges with
the AC. For this reason, I think that it makes sense to use 802.11 frame
formats in split-MAC mode.
 
Cheers,
 
    Mike

  _____  

From: Puneet Agarwal [mailto:[email-masked]] 
Sent: March 23, 2006 1:08 AM
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

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

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

---

From: Darren <[email-masked]>
Date: Mon, 27 Mar 2006 10:00:14 -0700

Regarding the evaluation draft and this item, the intent was to
recommend support for an 802.3 based user data tunnel back to the AC. 
See the eval draft, section 9.1.3.1 for the details.  We did not
specify a breakdown of AC and WTP functions as Puneet has.

Generally I think the definition of Split MAC and Local MAC is not as
clear as it could be in the working group.  The evaluation team
recommended support of 802.3 data tunneling in Local MAC mode.  The
team's general understanding was that Local MAC was defined by where
data is converted from 802.11 frames to 802.3 frames.  But I think
it's not that simple.  :)

Whichever MAC mode we want to call this, I think (please correct me!)
that the major difference in Puneet's proposal from the evaluation
team recommendation is that the 802.11 distribution function should
remain in the AC while doing an 802.3 data tunnel from WTP to AC.

It would be good to hear what the use cases are from Puneet and any
others who want this mode.  Why do we need this mode?  I can think of
a couple reasons myself, but I am not making any hardware or software
in this area anymore.  It would be good to hear about a real need for
this mode from those who are solving real problems out there.

-Darren Loher

PS: The evaluation team recommendations are not requirements.  They
are an interpretation of how well the protocols met the objectives and
recommendations on how to meet them better.  All recommendations are
up to the working group to decide if and when they want to adopt them.

On 3/27/06, Michael Montemurro <[email-masked]> wrote:
>  ________________________________
>             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