Subject: RE: [Capwap] Local MAC

From: Chunduru Rama Krishna Prasad <[email-masked]>
Date: Thu, 02 Sep 2004 10:00:02 +0530

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