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

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Thu, 24 Feb 2005 22:42:18 -0500

"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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 25 Feb 2005 09:46:24 -0800

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

Regards,

Emek Sadot

System Architect Group

Avaya Communication

732-852-2367

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