Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg

From: <[email-masked]>
Date: Mon, 2 Aug 2004 22:29:07 -0700

Ok,  This time with the attachment....

-Dorothy

 <<recharter for CAPWAP_06.txt>> 

>  -----Original Message-----
> From: 	Gellert Dorothy (Nokia-ES/MtView)  
> Sent:	Monday, August 02, 2004 10:28 PM
> To:	[email-masked]'
> Cc:	Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens 
> David (Nokia-NET/MtView)
> Subject:	Re-charter proposal text to discuss at CAPWAP WG Mtg
> 
> 
> Attached is the CAPWAP WG Re-charter proposal we will review 
> on Wednesday during the CAPWAP WG meeting.
> Please review and provide comments on the process going 
> forward, deliverables and timeline suggested.
> 
> Most of the WG meeting is dedicated to open discussion on how 
> to re-charter, so bring your comments!
> 
> -Dorothy and Mani

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Aug 2004 11:17:26 -0700

Dorothy,

Thanx for sending out this proposal. I looked through part of the draft and
the proposal, and I have a (somewhat long) comment on the suggested
recharter.

There is an assumption in the recharter that there will be a single CAPWAP
protocol. From the taxonomy document (part of which I briefly skimmed), it
looks to me like there are three basic architectural approaches currently in
the market: 1) the traditional MAC architecture, 2) the SplitMAC
architecture in which the WTPs only implement delay sensitive functions and
the rest are implemented on the ACs, and 3) the RemoteMAC architecture,
where all the MAC functions are implemented in the ACs.

1) seems to me like it would be pretty much out of scope for a recharter,
since there is not any need for additional protocol work on an interoperable
access network protocol in traditional APs (but perhaps I'm missing
something)  because APs from different vendors exist today that
interoperate.

2) and 3), however, seem to be to be two separate and largely incompatible
architectures that represent two classes of products which could benefit
from having an interoperable protocol between products in the class, but
probably wouldn't benefit much from interoperability between classes.

In the cellular world, there are two similar classes of products used for,
for example, UMTS deployment. The best known is the RNC/Node B/UTRAN
solution which is similar to SplitMAC in which a network controller runs a
protocol over the access network that controls radio access points, but
there's another solution, similar to RemoteMAC, in which wCDMA runs over
fiber from what is essentially just a smart antenna doing PHY to PHY
conversion to the controller. This latter solution has benefits in certain
deployment situations, but requires lots of bandwidth on the link between
the smart antenna and the controller, which might not be available in many
cases. As far as I know, the two are really for different incompatible
deployment cases and don't interoperate on the access network between the
base station/access point and the controller.

I would imagine that there are likely to be incompatible deployment
situations in the WLAN world that would benefit more from one or the other
of these solutions too.

I think the recharter discussion needs to make a decision first whether
there is need for interoperability between these two classes of products,
and, if not,  whether there is a need for interoperable protocol work
between products in the same class for both classes, or whether only the
class with the most need for an interoperable protocol should be focussed
on. I have some opinions about this, but I will wait until the discussion
tomorrow to express them.

In addition, I think the WG chairs need to talk with the IESG about the
right Area for this work, should the IESG agree to a recharter, since the
scope of a protocol development effort for an access network control
protocol seems like it might get a bit outside the Ops Area charter.
Personally, I have some doubts about whether a recharter will be approved,
since there may be a significant component of work in actual protocol
development that involves decisions about MAC level functions, but perhaps
we can get enough IEEE involvement to allow the work to proceed in IETF.
It's a tough problem organizationally, because the technology spans both
groups.

                       jak

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, August 02, 2004 10:29 PM
Subject: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg

-Dorothy

> to re-charter, so bring your comments!

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