Subject: [Capwap] RE: CAPWAP Objectives rev00 - 5.1.1 Objective Details (Zhonghui Yao)

From: Yao Zhong Hui <[email-masked]>
Date: Tue, 22 Feb 2005 18:03:20 +0800

Hello Jak, Emek and all,

It is very valuable if we can manage both split and local WTPs in one network with uniform approach. Local WTPs have the largest amount in the market and Split WTPs have been growing quickly, So it is a factual requirement that Local WTPs and Split WTPs co-exist in one network. 

In fact, the difference of WTPs is not only between SPIT and LOCAL, but also among Split WTPs from different vendors. So, following the objectives should be the CAPWAP functions definition. I think we can summarize the CAPWAP functions into two groups:

(1) Wireless MAC/PHY-layer related management and control
 This group functions may include such as BEACON parameter setting, MAC-layer management frame transfer etc.

(2) Wireless MAC/PHY-layer independent management and control 
This group functions may include firmware management, data plane management, User Authentication and Key distribution, etc.

Thanks,

Zhonghui Yao
Huawei

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Sunday, February 27, 2005 1:00 AM
Subject: Capwap digest, Vol 1 #342 - 2 msgs

> Send Capwap mailing list submissions to
> [email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.frascone.com/mailman/listinfo/capwap
> or, via email, send a message with subject or body 'help' to
> [email-masked]
> 
> You can reach the person managing the list at
> [email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Capwap digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: CAPWAP Objectives rev00 - 5.1.1  Objective Details (James Kempf)
>    2. RE: CAPWAP Objectives rev00 - 5.1.1  Objective Details (Sadot, Emek (Emek))
> 
> --__--__--
> 
> Message: 1
> From: "James Kempf" <[email-masked]>
> To: "Sadot, Emek (Emek)" <[email-masked]>, <[email-masked]>
> Subject: Re: [Capwap] CAPWAP Objectives rev00 - 5.1.1  Objective Details
> 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
> 
> 
>    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
> 
> 
> 
> 
> 
> --__--__--
> 
> Message: 2
> Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1  Objective Details
> Date: Fri, 25 Feb 2005 22:34:14 -0500
> From: "Sadot, Emek (Emek)" <[email-masked]>
> To: "James Kempf" <[email-masked]>, <[email-masked]>
> 
> 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]]=20
> 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
> 
> 
> End of Capwap Digest
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

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

Yao,

> In fact, the difference of WTPs is not only between SPIT and LOCAL, but
also among Split WTPs from different vendors. So, following the objectives
should be the CAPWAP functions definition. I think we can summarize the
CAPWAP functions into two groups:

I would think that the point of a standard protocol should be to eliminate
gratuitous inter-vendor differences. The protocol might include a "vendor
specific" option, such as Radius has, if there are good reasons why vendors
need to extend it.

> This group functions may include firmware management, data plane
management, User Authentication and Key distribution, etc.

Are you proposing that the protocol might be designed in such a way as to
have a common set of operations between split and local MAC for the second
set of operations, and that they would only differ on the first set?

        jak