Subject: RE: [Capwap] Local MAC

From: [email-masked]
Date: Wed, 1 Sep 2004 12:47:26 -0700

Hi Bob and Pat,

  Agree with your interpretation on the difference between Local MAC and
Split MAC. Thanks.

  As to what is the best mechanism, I believe this is still open for
debate. Maybe the opinion  regarding the future protocol should be flexible
(mentioned by Suds Jain in a different note) may not be a bad idea after
all.

  I myself have not been convinced one way is better than the other. Since
Pat has listed the merits of transmitting the full 802.11 frame between WTP
and AC, I am listing the chanllenges below to balance the viewpoints to
extend the discussion.

  For control and management messages, we all agree most information on
802.11 header will be needed in the AC. Some extra information may be
needed as well. Hence, yes transmitting the original 802.11 header (may
have to be encapsulated inside a CAPWAP header anyway) is straightforward.
On the other hand, I didn't see much wrong if the new protocol header is
defined flexible enough to include all the needed information. The merit of
the latter is simply potentially smaller frame overhead.

  For data traffic, if WTP simply sends the full 802.11 frame to AC inside
a L3 CAPWAP tunnel the frame may look like:

802.3 header + IP + UDP + CAPWAP header + 802.11 header + MSDU (say,
ip+tcp+ftp ...)

  If the 802.11 & 802.3 bridging function is performed in WTP (one way to
implement Local MAC), and some smartness (filtering, QoS...) can be set up
in the AC via the control/management messages in advance, maybe we can get
rid of the necessity for every single frame to carry the information (AC
can differentiate the frames according to the L2 or L3 source address). In
this case, the AC can forward the MSDU as a normal switch/router would do.
Using above example, the frame can look like a normal 802.3 frame:

802.3 header + MSDU (say, ip+tcp+ftp...)

or, if L3 cloud is between WTP and AC:

802.3 header + IP tunnel header + MSUD (day, ip+tcp+ftp)

The advantage is not only the smaller frame overhead, but also the easiness
of accelerated processing by hardware.

Comments?

--Tyan-Shu Jou

                    "Bob O'Hara"                                                                  
                    <bob@airespace.       To:     "Pat R. Calhoun" <[email-masked]>,      
                    com>                   "Chunduru Rama Krishna Prasad" <[email-masked]>,       
                    Sent by:               <[email-masked]>                                  
                    capwap-admin@fr       cc:                                                     
                    ascone.com            Subject:     RE: [Capwap] Local MAC                     

                    09/01/2004                                                                    
                    10:04 AM                                                                      

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

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap