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

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 25 Feb 2005 22:34:14 -0500

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

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 28 Feb 2005 11:05:04 +0800

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

> 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?
> 
> 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
> 
> 
> 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
> 
> 
> 
> 
> 
> [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
> 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Feb 2005 09:44:50 -0800

Emek,

What I meant  by "clearly separated" was that the AC must decide either to
support split MAC or local. Allowing the WTPs attached to one AC to have a
mix would, in my opinion, lead to increased management complexity for very
little gain.

            jak

----- Original Message ----- 
From: "Sadot, Emek (Emek)" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Friday, February 25, 2005 7:34 PM
Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details

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,

            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

Regards,

Emek Sadot

System Architect Group

Avaya Communication

732-852-2367