Subject: RE: [Capwap] Local MAC

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 2 Sep 2004 05:50:43 -0700

I know of one implementation that decrypts in the WTP and another that decrypts in the AC. There is no definition of where this function occurs in split MAC (or if there is it should say "may occur either in the WTP or in the AC" :)
 
PatC

________________________________

From: Chunduru Rama Krishna Prasad [mailto:[email-masked]]
Sent: Wed 9/1/2004 9:30 PM
To: Bob O'Hara; Pat R. Calhoun; [email-masked]
Subject: RE: [Capwap] Local MAC

What about encryption/decryption of 802.11 packets? In Local MAC, as I understand clearly that 
it is done at the WTP. And I think, that is good thing to do. 
Does split MAC definition allow this operation at WTPs? 

Thanks 
Rama Krishna

At 10:04 AM 9/1/2004 -0700, Bob O'Hara wrote:

	I think the difference can be summed up like this:
	 
	The protocol between an AC and the Local MAC and the Split MAC is semantically identical.  Each uses a different syntax for this protocol.
	
	 -Bob
	  
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat R. Calhoun
	Sent: Wednesday, September 01, 2004 6:32 AM
	To: Chunduru Rama Krishna Prasad; [email-masked]
	Subject: RE: [Capwap] Local MAC
	
	Great question.
	 
	As you observed below, the primary difference (from what I can tell) between
	split and local MAC is that while the former simply sends the frames untouched
	the latter reformulates the 802.11 messages into another format before sending
	them to the AC. So sure the PDUs look different, but in reality they are not really
	that different, right?
	 
	I mean what's the difference between sending a straight association request to the
	AC vs. breaking the association request down into small components and using the
	resulting information to create a message to be sent to the AC?
	 
	One could easily argue that using the straight association request will ensure forward
	compatibility with any new IEEE 802.11 related standard. Let's use 802.11k for instance,
	there are some new extensions that are added to existing MAC mgmt frames. So while
	a protocol that simply forwards the MAC mgmt frames to the AC will be able to handle
	802.11k transparently, the other approach would require that the IETF WG get together
	and define a way to map the new 802.11k extensions into whatever protocol was created.
	Clearly, we cannot afford to have the IETF's protocol lag behind IEEE standards.
	 
	On the data path, what is the difference between sending the straight 802.11 frame
	vs. sending an 802.3 frame with some associated control information that was derived
	from the 802.11 frame to begin with? What happens when protocols like 802.11e change
	the actual format of the frame by inserting 2 bytes in the protocol header? Sending the
	straight 802.11 frame to the AC ensures that whatever solution we've come up with will
	be able to support these future extensions, while a protocol that breaks down the PDU
	into an 802.3 frame will cause these extensions to be lost.
	 
	It's really not like understanding the 802.11 protocol is a complex thing - there are
	plenty of implementations of 802.11 based products, and some of these are even available
	as open source. So I would argue that parsing 802.11 packets is much simpler than 802.3
	with some control information since those stacks are publicly available.
	 
	PatC

________________________________

	From: [email-masked] on behalf of Chunduru Rama Krishna Prasad
	Sent: Tue 8/31/2004 10:52 PM
	To: [email-masked]
	Subject: [Capwap] Local MAC
	
	Hi ,
	
	Please correct if my interpretation of LOCAL MAC is wrong.
	WTP terminates 802.11 control packets and nothing is sent to AC .
	WTP terminates 802.11 mangement frames and corresponding events are sent to
	AC.
	WTP terminates 802.11 data frames, does decryption/encryption based on
	unique keys correspond to wireless stations, extracts 802.3 packet from the
	frame and send the frame across to AC. If needed, it might also send
	some control information along with each 802.3 packet.
	In this case, AC does not have knowledge of 802.11 header. It only needs
	knowledge of
	CAPWAP protocol, 802.1x termination, specific wireless related parameters.
	
	What makes it split MAC? My understanding is that, if AC terminates 802.11
	frames and
	does encyption/decryption and has knowledge of 802.11 frames, then it is
	Split MAC.
	Is this understanding correct?
	
	Thanks
	Rama Krishna

	Ch. Rama Krishna Prasad
	Intoto Software(I) Pvt Ltd,
	Uma Plaza, Nagarjuna circle,
	Panjagutta. Hyderabad, AP
	Tel No:s  2335 8927/8928/8434
	
	_______________________________________________
	Capwap mailing list
	[email-masked]
	http://mail.frascone.com/mailman/listinfo/capwap

Ch. Rama Krishna Prasad
Intoto Software(I) Pvt Ltd,
Uma Plaza, Nagarjuna circle,
Panjagutta. Hyderabad, AP
Tel No:s  2335 8927/8928/8434

---

From: "James Kempf" <[email-masked]>
Date: Thu, 2 Sep 2004 08:30:50 -0700

But for purposes of interoperability (i.e. being able to mix and match WTPs
and ACs between vendors), doesn't this need to be specified? The standard
could either specify where encyption/decryption is done, or it could allow
for some type of negotiation when the WTP and AC first make contact and
connect up.

                jak

----- Original Message ----- 
From: "Pat R. Calhoun" <[email-masked]>
To: "Chunduru Rama Krishna Prasad" <[email-masked]>; "Bob O'Hara"
<[email-masked]>; <[email-masked]>
Sent: Thursday, September 02, 2004 5:50 AM
Subject: RE: [Capwap] Local MAC

I know of one implementation that decrypts in the WTP and another that
decrypts in the AC. There is no definition of where this function occurs in
split MAC (or if there is it should say "may occur either in the WTP or in
the AC" :)

PatC

What about encryption/decryption of 802.11 packets? In Local MAC, as I
understand clearly that
it is done at the WTP. And I think, that is good thing to do.
Does split MAC definition allow this operation at WTPs?

Thanks
Rama Krishna

The protocol between an AC and the Local MAC and the Split MAC is
semantically identical.  Each uses a different syntax for this protocol.

-Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat R. Calhoun
Sent: Wednesday, September 01, 2004 6:32 AM
To: Chunduru Rama Krishna Prasad; [email-masked]
Subject: RE: [Capwap] Local MAC

Great question.

As you observed below, the primary difference (from what I can tell) between
split and local MAC is that while the former simply sends the frames
untouched
the latter reformulates the 802.11 messages into another format before
sending
them to the AC. So sure the PDUs look different, but in reality they are not
really
that different, right?

I mean what's the difference between sending a straight association request
to the
AC vs. breaking the association request down into small components and using
the
resulting information to create a message to be sent to the AC?

One could easily argue that using the straight association request will
ensure forward
compatibility with any new IEEE 802.11 related standard. Let's use 802.11k
for instance,
there are some new extensions that are added to existing MAC mgmt frames. So
while
a protocol that simply forwards the MAC mgmt frames to the AC will be able
to handle
802.11k transparently, the other approach would require that the IETF WG get
together
and define a way to map the new 802.11k extensions into whatever protocol
was created.
Clearly, we cannot afford to have the IETF's protocol lag behind IEEE
standards.

On the data path, what is the difference between sending the straight 802.11
frame
vs. sending an 802.3 frame with some associated control information that was
derived
from the 802.11 frame to begin with? What happens when protocols like
802.11e change
the actual format of the frame by inserting 2 bytes in the protocol header?
Sending the
straight 802.11 frame to the AC ensures that whatever solution we've come up
with will
be able to support these future extensions, while a protocol that breaks
down the PDU
into an 802.3 frame will cause these extensions to be lost.

It's really not like understanding the 802.11 protocol is a complex thing -
there are
plenty of implementations of 802.11 based products, and some of these are
even available
as open source. So I would argue that parsing 802.11 packets is much simpler
than 802.3
with some control information since those stacks are publicly available.

PatC

Hi ,

Thanks
Rama Krishna

Ch. Rama Krishna Prasad

Ch. Rama Krishna Prasad