Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames.

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 6 Jun 2006 07:55:43 -0700

I prefer that 802.11 management frames be carried as CAPWAP data frames,
as the protocol defines today. So I would propose rejecting a change to
encapsulate these as CAPWAP control packets.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Michael Montemurro [mailto:[email-masked]] 
	Sent: Sunday, June 04, 2006 5:22 PM
	To: Abhijit Choudhury
	Cc: capwap
	Subject: Re: [Capwap] Proposed resolution for issue 100.
Treatment ofwirelessmanagement frames.

	Actually, I need to make one clarification. If we decide to use
CAPWAP data encapsulation, IEEE 802.11 management frames passed from the
WTP to the AC in local MAC mode. That would mean there would be three
possible forms of processing at the WTP: 
	data frames - bridge locally or tunneled to the AC - CAPWAP data
	802.11 management frames - encapulated as CAPWAP data and
transmitted to the AC
	CAPWAP control frames.
	 
	I think it sounds cleaner to encapsulate management frames and
transmit them from the WTP to the AC as control frames. But I'm willing
to go whichever way the group decides.
	 
	Cheers,
	 
	Mike

	On 6/3/06, Michael Montemurro <[email-masked]>
wrote: 

		Is there consensus that radio techology specific
management frames should be carried as CAPWAP data frames?
		 
		Thanks,
		 
		Mike

		On 6/3/06, Abhijit Choudhury <[email-masked] >
wrote: 

			Mike,
			I'm not sure this make sense.
			 
			The CAPWAP control channel is for "control and
			provisioning" messages between the AC and the
WTP.
			Per-client information arriving at the WTP
should
			be sent in the data channel as it is all data to
			the AC, and has nothing to do with "control and
			provisioning" of the WTP.  
			 
			There could be radio technology specific
information 
			(e.g. RSSI/SNR) that are collected on a
per-client 
			basis at the AC, and separating out some of the 
			messages into a separate channel will lead to
either
			erroneous accounting or more complicated logic
that 
			looks at both channels on a packet-by-packet
basis. 
			All packets sent by a client should come up
			the same channel (the data channel).
			 
			As for security for management frames, 802.11w
			should take care of that.
			 
			Thanks,
			
			   Abhijit

				-----Original Message-----
				From: Michael Montemurro [mailto:
[email-masked] <mailto:[email-masked]> ] 
				Sent: Saturday, June 03, 2006 12:39 PM
				To: capwap
				Subject: [Capwap] Proposed resolution
for issue 100. Treatment of wirelessmanagement frames.

				Here is my proposed resolution to issue
100:

				- Fix the default priority settings in
section 11.6 to the values used in section 4.3.3.

				- Change the last paragraph in section
4.3 to state that radio technology specific management frames are
treated as CAPWAP control messages. It makes sense because control
frames are protected.

				Does this make sense?

				Cheers,

				Mike

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

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

---

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 6 Jun 2006 11:03:54 -0400

Cool. I'll ensure that -02 is updated in this manner.

Mike

On 6/6/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>  ------------------------------
>  *From:* Michael Montemurro [mailto:[email-masked]]
> *Sent:* Sunday, June 04, 2006 5:22 PM
>
> *To:* Abhijit Choudhury
> *Cc:* capwap
> *Subject:* Re: [Capwap] Proposed resolution for issue 100. Treatment
> ofwirelessmanagement frames.
>
>
>
>  Actually, I need to make one clarification. If we decide to use CAPWAP
> data encapsulation, IEEE 802.11 management frames passed from the WTP to
> the AC in local MAC mode. That would mean there would be three possible
> forms of processing at the WTP:
> 802.11 management frames - encapulated as CAPWAP data and transmitted to
> the AC
> CAPWAP control frames.
>
> I think it sounds cleaner to encapsulate management frames and transmit
> them from the WTP to the AC as control frames. But I'm willing to go
> whichever way the group decides.
>
> Cheers,
>
> Mike
>
>
> On 6/3/06, Michael Montemurro <[email-masked]> wrote:
> >
> >  Is there consensus that radio techology specific management frames
> > should be carried as CAPWAP data frames?
> >
> > Thanks,
> >
> > Mike
> >
> >
> >  On 6/3/06, Abhijit Choudhury <[email-masked] > wrote:
> > >
> > >  Mike,
> > > provisioning" messages between the AC and the WTP.
> > > Per-client information arriving at the WTP should
> > > There could be radio technology specific information
> > > (e.g. RSSI/SNR) that are collected on a per-client
> > > messages into a separate channel will lead to either
> > > erroneous accounting or more complicated logic that
> > > looks at both channels on a packet-by-packet basis.
> > > *From:* Michael Montemurro [mailto: [email-masked]]
> > > *Sent:* Saturday, June 03, 2006 12:39 PM
> > > *To:* capwap
> > > *Subject:* [Capwap] Proposed resolution for issue 100. Treatment of
> > > wirelessmanagement frames.
> > >
> > > Here is my proposed resolution to issue 100:
> > >
> > > - Fix the default priority settings in section 11.6 to the values used
> > > in section 4.3.3.
> > >
> > > - Change the last paragraph in section 4.3 to state that radio
> > > technology specific management frames are treated as CAPWAP control
> > > messages. It makes sense because control frames are protected.
> > >
> > > Does this make sense?
> > >
> > > Cheers,
> > >
> > > Mike
> > >
> > >
> > >
> > >
> >
>