Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Tue, 1 Mar 2005 15:51:09 -0500

Cheng,
Don't get me wrong, I think such an objective should be present while at
the same time we should be limit the possible permutations. The APF AHC
will/should not split the functionality between WTP and AC rather name
and define atomic components/functionality that could reside at the WTP
(or AC).

Let take an (extreme) example, as part of the arch/protocol do we intend
to allow the 802.1x authenticator component to reside at the WTP? Should
an AC support such configuration? I would say no, but according to the
objective document it's allowed.

Jak,
I share your concern, however I believe we should not call for one arch
over the other, rather let the market/vendors solidified (or not) on
one. In my mind, political hurdles - vendors already support different
architectures - supported by technical merits for each arch will make it
impossible to set up such an objective.

Emek

-----Original Message-----
From: Cheng Hong [mailto:[email-masked]] 
Sent: Sunday, February 27, 2005 10:05 PM
To: Sadot, Emek (Emek); 'James Kempf'; [email-masked]
Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details

Hi Emek,

I think the issue is not on whether we should have the objective,
rather, it is on how far we want to go. You are right that to support
every possible split implementation permutation is almost impossible.
However, the situation here should be better than that :) 

Looking at the CAPWAP case, the maximum set of functions to be provided
by AC is clearly defined by the IEEE802.11. (anything beyond that
probably is out of scope of CAPWAP) Hopefully, the APF AHC will have a
clean definition of possible splits. Anyway, there are only 9 types of
services defined in 11. The complexity is still manageable.  

Also, (assumable) everyone has participated in the taxonomy survey and
review. We don't see hundreds of permutation defined there :) I guess
that draft contains almost all the permutations we may see on the
market. If that is still too much, we can modify the charter to clearly
state which types of architecture should be in scope of CAPWAP (and
forget about all the other permutations). 

Back to the objective, to support different permutation is basically to
design the CAPWAP protocol so that protocol components/messages
supporting these different splits are as modular and independent as
possible. The negotiation will allow AC to decide which protocol
components should be involved. This definitely requires some in-depth
understanding of the 11 MAC. Maybe that is a good reason to keep the APF
AHC alive in IEEE802.11, and have the CAPWAP protocol reviewed there.

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
> Sent: Saturday, February 26, 2005 11:34 AM
> To: James Kempf; [email-masked]
> Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective 
> Details
> 
> 
> The other side of the coin is the question how many permutations would

> the protocol allows within each group - Split and Local. E.g. does the

> protocol allows the existent of several distinct Split WTPs each with 
> different (APF) set of components?
> 
> My concern lies at the AC side and the complexity involved.
> 
> Emek
> 
> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, February 25, 2005 12:46 PM
> To: Sadot, Emek (Emek); [email-masked]
> Subject: Re: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective 
> Details
> 
> Emek/All,
> 
> Thanx for bringing this up. This objective is something I have been 
> wondering about.
> 
> From a service provider perspective, having support for both local and

> split MAC does not seem to be such a good idea. It makes both the AC 
> and WTP more complicated, complicating the configuration and 
> management. I know that the vendors are basically not in agreement 
> about the right technical solution, and that some vendors are 
> providing split MAC while others are providing local, so I'm afraid 
> any attempt at an objective discussion on this will degenerate into 
> both sides supporting their particular product offering with material 
> from their respective marketing departments. The other problem with 
> trying to choose is that I can think of good technical reasons in 
> support of both alternatives. I can also think of good nontechnical 
> reasons to choose one or the other.
> 
> One way we could solve this problem is to structure the protocol such 
> that the two choices are clearly separate and let the market decide 
> which way to go.That way, if CAPWAP is progressed to Draft Standard, 
> if one or the other fails to achieve widespread deployment, the 
> alternative that is not deployed can be EOLed.
> 
> There are other possible ways to cleanly separate the two, but they 
> involve making some kind of value judgement that, I'm sure, one side 
> or the other will object to based on the perceived impact of that 
> judgement on their market capture potential.
> 
>             jak
> 
> 
> ----- Original Message -----
> From: "Sadot, Emek (Emek)" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, February 24, 2005 7:42 PM
> Subject: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details
> 
> 
> "5.1.1  Objective Details
> 
> 
>    This objective for the CAPWAP protocol is to ensure that WTPs of 
> both
>    local MAC and split MAC architecture designs are capable of
>    interoperation within a single WLAN.  Consequently, a single WLAN
>    controller will be capable of controlling both types of WTPs using 
> a
>    single CAPWAP protocol.  Integral support for these designs 
> comprises
>    a number of protocol aspects.
> i. Functionality negotiations between WLAN controller and WTPs Local 
> MAC and split MAC designs differ in the degree of IEEE 802.11 MAC 
> functionalities that each type of WTP realizes. The CAPWAP protocol 
> should allow WLAN controllers to determine the functionalities of 
> different WTPs as a first step in controlling them." "determine the 
> functionalities of different WTPs" - we should not assume that all 
> Local and Split WTP vendors will select the same set of atomic 
> components, t.b.d. by the APF WG - result in one instance of Local and

> one per Split WTP. On the other hand we should be careful allowing any

> permutation of the atomic APF components which could lead into 
> hundreds (ok, ok, so I am exaggerating a bit) of instances per each 
> group (Local and Split).
> 
> 
> Regards,
> 
> Emek Sadot
> 
> System Architect Group
> 
> Avaya Communication
> 
> 732-852-2367
> 
> 
> 
> 
> 
> _______________________________________________
> Capwap mailing list
> [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
> 
> 
> 

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

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 2 Mar 2005 10:49:24 +0800

Hi Emek,

<Snip>
> Don't get me wrong, I think such an objective should be 
> present while at the same time we should be limit the 
> possible permutations. The APF AHC will/should not split the 
> functionality between WTP and AC rather name and define 
> atomic components/functionality that could reside at the WTP (or AC).
> 
> Let take an (extreme) example, as part of the arch/protocol 
> do we intend to allow the 802.1x authenticator component to 
> reside at the WTP? Should an AC support such configuration? I 
> would say no, but according to the objective document it's allowed.

Yes. I agree that the possible permutations to be supported by the CAPWAP
should be limited.  

As for the example above, I guess that is a valid question to the whole
group. Do we want to preclude certain implementation possibilities
explicitly? Maybe we should make use of the taxonomy draft as the guideline?
As mentioned by Jak, before market settle down, we probably need to support
both. 

cheers

Cheng Hong

> Jak,
> I share your concern, however I believe we should not call 
> for one arch over the other, rather let the market/vendors 
> solidified (or not) on one. In my mind, political hurdles - 
> vendors already support different architectures - supported 
> by technical merits for each arch will make it impossible to 
> set up such an objective.
> 
> Emek
> 
> I think the issue is not on whether we should have the 
> objective, rather, it is on how far we want to go. You are 
> right that to support every possible split implementation 
> permutation is almost impossible. However, the situation here 
> should be better than that :) 
> 
> Looking at the CAPWAP case, the maximum set of functions to 
> be provided by AC is clearly defined by the IEEE802.11. 
> (anything beyond that probably is out of scope of CAPWAP) 
> Hopefully, the APF AHC will have a clean definition of 
> possible splits. Anyway, there are only 9 types of services 
> defined in 11. The complexity is still manageable.  
> 
> Also, (assumable) everyone has participated in the taxonomy 
> survey and review. We don't see hundreds of permutation 
> defined there :) I guess that draft contains almost all the 
> permutations we may see on the market. If that is still too 
> much, we can modify the charter to clearly state which types 
> of architecture should be in scope of CAPWAP (and forget 
> about all the other permutations). 
> 
> Back to the objective, to support different permutation is 
> basically to design the CAPWAP protocol so that protocol 
> components/messages supporting these different splits are as 
> modular and independent as possible. The negotiation will 
> allow AC to decide which protocol components should be 
> involved. This definitely requires some in-depth 
> understanding of the 11 MAC. Maybe that is a good reason to 
> keep the APF AHC alive in IEEE802.11, and have the CAPWAP 
> protocol reviewed there.
> 
> cheers
> 
> Cheng Hong
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Mar 2005 09:38:34 -0800

>As mentioned by Jak, before market settle down, we probably need to support

As mentioned, I don't think it is possible to remove certain implementation
possibilities due to market realities. But I think the standard needs to
limit the possible deployment permutations to reduce the complexity of
network management. In particular, I think there are likely to be some
deployment configurations that provide marginal or no advantages over
others. Of course, if a particular deployment configuration provides clearly
definable advantages, then it should be included. Therefore, it might help
when deciding whether to support a particular combination of local and split
MAC to weigh the deployment advantages and complexities of the combination
and make a decision based on that.

            jak