Subject: RE: [Capwap] Local MAC

From: Shehzad Merchant <[email-masked]>
Date: Fri, 3 Sep 2004 11:07:52 -0700

If you want to guarantee interoperability i.e. take WTP from vendor X, plug
it into a network that has an AC from vendor Y and expect it to just work, I
don't see how you can get there without a minimum set of functionality that
is mandated and specified, both on the control/management plane as well as
data plane. (there can always be capabilities beyond the minimum set that
are optional and negotiable). 
 
I do agree that the mechanisms for control/management do not necessarily
have to be the same as data plane i.e. one could specify the
control/management protocol independently from the data plane, but I think
to achieve full interoperability, a minimum set of both need to be
specified.
 
-S

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cheng Hong
Sent: Friday, September 03, 2004 12:18 AM
To: 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru Rama Krishna
Prasad'; 'Bob O'Hara'; [email-masked]
Subject: RE: [Capwap] Local MAC

CAPWAP is not about how that is implemented. The protocol only needs to be
generic to support different implementations choices and provides
negotiation methods. I don't think the group has to mandate a "single
approach" of implementation.
 
cheers
 
Cheng 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Lambert
Sent: Friday, September 03, 2004 5:23 AM
To: Pat R. Calhoun; James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara;
[email-masked]
Subject: RE: [Capwap] Local MAC

>I'd suggest negotiation
 
Even with negotiation, to ensure interoperability there must be a mandated
set of capabilites.  So, the working group will still have to pick a single
perferred implementation approach.
 
Paul

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat R. Calhoun
Sent: Thursday, September 02, 2004 1:27 PM
To: James Kempf; Chunduru Rama Krishna Prasad; Bob O'Hara;
[email-masked]
Subject: RE: [Capwap] Local MAC

I'd suggest negotiation

PatC

-----Original Message-----
From: James Kempf [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara;
[email-masked]
Subject: Re: [Capwap] Local MAC

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

________________________________

From: Chunduru Rama Krishna Prasad [mailto:[email-masked]
<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]
<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

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 6 Sep 2004 10:51:36 +0800

I don't object the idea of mandate or specifying the functionality set, but
I don't think the group should "pick a single perferred implementation
approach" 
 
Whether we need to specify a minimum set of functions for WTP and AC is
another issue. This depends on the objective we set for the CAPWAP. If we
set the target as: any WTP and AC with a CAPWAP lebel should be able to work
happily  together and provide service, then the minimum functions should be
set. If the target is to provide a protocol for a WTP and AC to work
together if they can, the minimum function required would be for the
negotiation and function discovery.
 
Even for the first case, a negotiation function is necessary, since WTP and
AC could provide redundent functions, and they need to negotiate who to
excute which part.
 
cheers
 
Cheng

-----Original Message-----
From: Shehzad Merchant [mailto:[email-masked]] 
Sent: Saturday, September 04, 2004 2:08 AM
To: Cheng Hong; 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru
Rama Krishna Prasad'; 'Bob O'Hara'; [email-masked]
Subject: RE: [Capwap] Local MAC

 
-S

  _____  

 
cheers
 
Cheng 

-----Original Message-----

 
Paul

  _____  

I'd suggest negotiation

PatC

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara;
[email-masked]

                jak

----- Original Message -----
From: "Pat R. Calhoun" <[email-masked]>
To: "Chunduru Rama Krishna Prasad" <[email-masked]>; "Bob O'Hara"

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

Thanks
Rama Krishna

-Bob

-----Original Message-----

Great question.

PatC

Hi ,

Thanks
Rama Krishna

Ch. Rama Krishna Prasad

Ch. Rama Krishna Prasad

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 6 Sep 2004 10:52:17 +0800

cheers
 
Cheng

-----Original Message-----
From: Shehzad Merchant [mailto:[email-masked]] 
Sent: Saturday, September 04, 2004 2:08 AM
To: Cheng Hong; 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru

 
-S

  _____  

 
cheers
 
Cheng 

-----Original Message-----

 
Paul

  _____  

I'd suggest negotiation

PatC

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara;
[email-masked]

                jak

----- Original Message -----
From: "Pat R. Calhoun" <[email-masked]>
To: "Chunduru Rama Krishna Prasad" <[email-masked]>; "Bob O'Hara"

PatC

Thanks
Rama Krishna

-Bob

-----Original Message-----

Great question.

PatC

Hi ,

Thanks
Rama Krishna

Ch. Rama Krishna Prasad

Ch. Rama Krishna Prasad

---

From: "James Kempf" <[email-masked]>
Date: Tue, 7 Sep 2004 09:39:45 -0700

My goal for CAPWAP is that I can buy a WTP from one vendor and a AC from
another, connect them together, and have them work together with no
configuration. Hopefully, this basic goal (complete interoperability) is
shared by others. How to achieve this from a technical standpoint is what is
at issue.

On the one hand, one could specify a particular set of tunneling
functionality (or the absence thereof) and limit it to that.

On the other, one could specify a negotiation protocol so that the WTP and
AC can negotiate a tunneling protocol dynamically (or the absence thereof).

In either case, the standard must specify a minimum set of "required to
implement" tunneling functionality (or absence thereof). The difference is
that, in the first case, the functionality is limited to one choice, whereas
in the second, it is limited to a few. Whether or not the second choice
allows more tunneling options to be added beyond the minimum "required to
implement" is a separate issue, and depends on whether the CAPWAP protocol
provides extensibility for tunneling functionality. For example, the
protocol could specify a few tunneling options ( for example: none, GRE,
ESP) and not allow any further extensibility.

Since vendors currently take different approaches about how to do data plane
transport from the WTP to the AC, I think it may be hard, from a politicial
standpoint, to achieve concensus on this issue. Perhaps someone could
enumerate the current approaches? I don't recall having seen that in the
architecture document.

            jak

----- Original Message ----- 
From: "Cheng Hong" <[email-masked]>
To: "'Shehzad Merchant'" <[email-masked]>; "'Paul Lambert'"
<[email-masked]>; "'Pat R. Calhoun'"
<[email-masked]>; "'James Kempf'" <[email-masked]>;
"'Chunduru Rama Krishna Prasad'" <[email-masked]>; "'Bob O'Hara'"
<[email-masked]>; <[email-masked]>
Cc: "'Saravanan Govindan'" <[email-masked]>
Sent: Sunday, September 05, 2004 7:51 PM
Subject: RE: [Capwap] Local MAC

cheers

Cheng

-----Original Message-----
From: Shehzad Merchant [mailto:[email-masked]]
Sent: Saturday, September 04, 2004 2:08 AM
To: Cheng Hong; 'Paul Lambert'; 'Pat R. Calhoun'; 'James Kempf'; 'Chunduru

-S

  _____

cheers

Cheng

-----Original Message-----

Paul

  _____

I'd suggest negotiation

PatC

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thu 9/2/2004 8:30 AM
To: Pat R. Calhoun; Chunduru Rama Krishna Prasad; Bob O'Hara;
[email-masked]

                jak

----- Original Message -----
From: "Pat R. Calhoun" <[email-masked]>
To: "Chunduru Rama Krishna Prasad" <[email-masked]>; "Bob O'Hara"

PatC

Thanks
Rama Krishna

-Bob

-----Original Message-----

Great question.

PatC

Hi ,

Thanks
Rama Krishna

Ch. Rama Krishna Prasad

Ch. Rama Krishna Prasad