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

From: <[email-masked]>
Date: Tue, 3 Aug 2004 13:08:24 -0700

Hi James-

Good comments.  You have been an great advisor to us since the BOF.  Are you available/interested to get more involved with CAPWAP over the next year?  It would be good to have your expertise in any way possible.

Response in line.

Thanks,
Dorothy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext James Kempf
> Sent: Tuesday, August 03, 2004 11:17 AM
> To: Gellert Dorothy (Nokia-ES/MtView); [email-masked]
> Cc: [email-masked]; [email-masked]; Kessens David
> (Nokia-NET/MtView)
> Subject: Re: [Capwap] RE: Re-charter proposal text to discuss 
> at CAPWAP
> WG Mtg
> 
> 
> 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

True.  I didn't explicitly call this out because I thought that the Objective document would address which architecture approach(s) out of the taxonomy document we would pursue.    The Objective draft is based off of the taxonomy work, so the analysis (and experience gained) in that document
would be of significant value.  

In addition, the evaluation draft is also a place where we could stress 2 approaches/protocols to the solution.   

> 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'm familiar with the UMTS deployment scenario, since I've been involved in CDMA.  The RNC/PDSN architecture feels very similar to what we are doing here, and I admit I use this experience in evaluating these architectures.   I'm not as familiar with wCDMA, but I would like to hear more about this benefits of this, as I'm sure would the group.  

Bernard Aboba has advised us also to stress performance criteria, so the low/high bandwidth distinction makes sense.   We have it as part of the protocol, but it should also be called out in the Objectives phase.  I believe we should be aware of the applications expected to run over this network to assure we don't create something that essentially prevents VOIP or other bandwidth sensitive applications.

> 
> 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.

We did get the IEEE to charter a study group to define the AP functions better so we can effective distribute them as necessary.   I believe Dorothy Stanley has been elected the chair of this group and she is also our liaison.  I think we have set a good foundation for success in working out issues with the IEEE.     This is still a new model of cooperation between IETF and other SDOs, but I think the time is upon us to work in collaboration with each other to meet the mobility demands of the market.

> 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
> 
> 
> 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
> 
> 
> _______________________________________________
> 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: "James Kempf" <[email-masked]>
Date: Tue, 3 Aug 2004 14:34:59 -0700

Dorothy,

Good comments.  You have been an great advisor to us since the BOF.  Are you
available/interested to get more involved with CAPWAP over the next year?
It would be good to have your expertise in any way possible.

jak>> I can help, premised of course on the IESG approving the charter.

True.  I didn't explicitly call this out because I thought that the
Objective document would address which architecture approach(s) out of the
taxonomy document we would pursue.    The Objective draft is based off of
the taxonomy work, so the analysis (and experience gained) in that document
would be of significant value.

In addition, the evaluation draft is also a place where we could stress 2
approaches/protocols to the solution.

jak>> Personally, I believe the charter should not include this kind of
open-ended discussion decision making about what the WG will do. I think
that discussion should be done prior to chartering, and the charter itself
should constrain work sufficiently that the WG has a liklihood getting
something useful done in a reasonable amount of time (3 years for example).
If the WG argues about what it will do for the first year, there will be
even less liklihood that something useful will result. We tried this in
Seamoby and, take my word for it, it did not work. The kind of constraint I
would like to see is something like "The WG will develop a protocol for
interoperability between ACs and WTPs of different vendors that are
implemented according to architecture XXX of the CAPWAP architectural
taxonomy". There may be more than one such statement, but they need to be
priortized if so.

Bernard Aboba has advised us also to stress performance criteria, so the
low/high bandwidth distinction makes sense.   We have it as part of the
protocol, but it should also be called out in the Objectives phase.  I
believe we should be aware of the applications expected to run over this
network to assure we don't create something that essentially prevents VOIP
or other bandwidth sensitive applications.

jak>> Performance should be a major decision criteria, but I think other
critera should be how willing vendors are to work together to develop the
concensus needed for a standard (rather than push proprietary solutions) and
how desparate network operators are for interoperable products. One
alternative for prioritization would be picking the lowest hanging fruit-
which class has the least work involved to standardize an interoperable
protocol - and standardize that first. The other would be to take the class
needing the most work first. We should talk about this at the meeting.

We did get the IEEE to charter a study group to define the AP functions
better so we can effective distribute them as necessary.   I believe Dorothy
Stanley has been elected the chair of this group and she is also our
liaison.  I think we have set a good foundation for success in working out
issues with the IEEE.     This is still a new model of cooperation between
IETF and other SDOs, but I think the time is upon us to work in
collaboration with each other to meet the mobility demands of the market.

jak>> This sounds very promising, I think this kind of structure increases
the chances of success.

                      jak