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

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

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

---

From: <[email-masked]>
Date: Tue, 3 Aug 2004 15:05:54 -0700

I think these are good points and we need to re-charter to discuss and solve them.

The proposed charter has an Objectives phase where we can discuss requirements such as these, and the protocol proposed are intended to meet the objectives.  

In drafting the objectives, we will take these issues to the WG list for consensus and roll them into the Ojectives draft.    

In addition to the list, anyone is free to write an internet-draft to document issues in greater detail, and then discuss it on the WG list.

Thanks,
Dorohty

> -----Original Message-----
> From: ext Yang, Lily L [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2004 1:32 PM
> To: James Kempf; 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
> 
> 
> I agree that there is an important decision to be made when 
> we recharter
> the group, to decide what kind of interoperability we want across what
> architecture variants. 
> 
> But I believe James's summary of the architecture taxonomy is not
> completely correct. The taxonomy classified the existing/emerging
> architecture spectrum as the following:
>                  +----------------+
>                  |Autonomous      |
>      +---------->|Architecture    |
>      |           |Family          |
>      |           +----------------+
>      |                                     +--------------+
>      |                                     |Local         |
>      |                               +---->|MAC           |
>      |                               |     |Architecture  |
>      |                               |     +--------------+
>      |                               |
>      |           +----------------+  |     +--------------+
>      |           |Centralized     |  |     |Split         |
>      +---------->|Architecture    |--+---->|MAC           |
>      |           |Family          |  |     |Architecture  |
>      |           +----------------+  |     +--------------+
>      |                               |
>      |                               |     +--------------+
>      |                               |     |Remote        |
>      |                               +---->|MAC           |
>      |                                     |Architecture  |
>      |                                     +--------------+
>      |           +----------------+
>      |           |Distributed Mesh|
>      +---------->|Architecture    |
>                  |Family          |
>                  +----------------+
> 
> So we have to explicitly decide what kind of interoperability 
> we want to
> achieve in this picture. It seems like a relatively easier decision at
> the first level. Autonomous Architecture doesn't need any further
> protocol. One example of the Distributed Architecture -- 
> 802.11 mesh --
> is being developed by IEEE 802.11 TGs, and it is not yet 
> clear how much
> of the control/config aspect will be included in that effort.
> Centralized architecture is where we hear the interoperability demand
> the most. 
> Now within the Centralized architecture, there is a harder question to
> answer: what kind of interoperability we want? Across all 3
> sub-categories with one protocol? Does that make sense, eps. If
> different sub-category suits for different deployment scenarios? Is it
> technically feasible to have one fit all?
> Or is it acceptable to have only interoperability within each
> sub-category?
> Should this group work on all 3? Or 1? 2?
> 
> One option for the WG is to only draw the scope boundary around
> Centralized Architecture, but not dictating whether or not we should
> develop one solution for all, or separate solution for each one. If
> people can come up with solutions/proposals to solve interoperability
> across 3, I don't see why we shouldn't allow them to try. On the other
> hand, if people have strong proposals for each individual 
> sub-category,
> that should be allowed too. The WG can evaluate all the 
> options and then
> decide.
> 
> Another option is to decide on the exact extend of 
> interoperability now,
> and only accept proposals that work for it.
> 
> I am not advocating any particular option in this email, but just want
> to point out that these are the questions we need to ponder 
> upon when we
> discuss rechartering.
> 
> Lily
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James Kempf
> Sent: Tuesday, August 03, 2004 11:17 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> 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
> 
> 
> 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.
> >

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Tue, 3 Aug 2004 17:40:09 -0600

James,

Thanks for the comments.
To add a few more points to Dorothy's response:

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 11:17 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Mani, Mahalingam (Mahalingam);
[email-masked]
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
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.
[Mani, Mahalingam (Mahalingam)] the question of traditional APs
interoperating from different vendors is debatable. Sure - that happened
to be one of the motivations of IAPP but the latter itself has been
ill-adopted. Within the scope that there needed little context to be
transferred and BSS transitions within an ESS did not call on higher
layer synchronizations inside the AP; interoperability is a trivial if
not non-issue. The taxonomy deals with this case for the sake of
completeness. That said, the 'traditional' AP vendors have also sought
to provide glues to have a centralized control of sorts to manage the
APs to various degrees.

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.
[Mani, Mahalingam (Mahalingam)] that is a valid point. The pre-CAPWAP
version of architecture draft tended to dwell on such - perhaps a little
too early - where, one approach is to discover/negotiate the class
(capability discovery) and subsequently stay within the class. However,
this is up for WG discussion - as a very probable manifestation of the
single CAPWAP protocol that is suggested.

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

[Mani, Mahalingam (Mahalingam)] the intent of the proposed charter
itself is to motivate discussions of such issues up front in the session
and the on the list; not necessarily constrain the scope without
consensus.

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.
[Mani, Mahalingam (Mahalingam)] As for interoperation enough has been
said and done to lay the groundwork to ensure the proposed recharter (or
otherwise) interworks with a parallel AP functions architecture study /
task initiated, approved and started in IEEE 802.11 WLAN WG. (I will
leave it to Dorothy Stanley to expand on that during the meeting). The
degree of coupling required to continue this meaningfully in parallel to
keep CAPWAP protocol work in sync. is something to be revisited. It is
outlined in the milestone but needs more articulation later if the
proposed effort is approved.

                       jak

[Mani, Mahalingam (Mahalingam)] 
-mani
----- 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
[Mani, Mahalingam (Mahalingam)] [...]

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Wed, 4 Aug 2004 07:34:57 -0700

But you get Autonomous interoperability by default, no?

PatC
-----Original Message-----
From: [email-masked] on behalf of Peyush AGARWAL
Sent: Wed 8/4/2004 7:00 AM
To: 'Yang, Lily L'; 'James Kempf'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG Mtg
 
A bit of suggestion:
We can target to achieve interoperability between Autonomous & Centralized
Architecture family in the initial stages of the draft!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yang, Lily L
Sent: Wednesday, August 04, 2004 2:02 AM
To: James Kempf; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG
Mtg

I agree that there is an important decision to be made when we recharter the
group, to decide what kind of interoperability we want across what
architecture variants. 

But I believe James's summary of the architecture taxonomy is not completely
correct. The taxonomy classified the existing/emerging architecture spectrum
as the following:
                 +----------------+
                 |Autonomous      |
     +---------->|Architecture    |
     |           |Family          |
     |           +----------------+
     |                                     +--------------+
     |                                     |Local         |
     |                               +---->|MAC           |
     |                               |     |Architecture  |
     |                               |     +--------------+
     |                               |
     |           +----------------+  |     +--------------+
     |           |Centralized     |  |     |Split         |
     +---------->|Architecture    |--+---->|MAC           |
     |           |Family          |  |     |Architecture  |
     |           +----------------+  |     +--------------+
     |                               |
     |                               |     +--------------+
     |                               |     |Remote        |
     |                               +---->|MAC           |
     |                                     |Architecture  |
     |                                     +--------------+
     |           +----------------+
     |           |Distributed Mesh|
     +---------->|Architecture    |
                 |Family          |
                 +----------------+

So we have to explicitly decide what kind of interoperability we want to
achieve in this picture. It seems like a relatively easier decision at the
first level. Autonomous Architecture doesn't need any further protocol. One
example of the Distributed Architecture -- 802.11 mesh -- is being developed
by IEEE 802.11 TGs, and it is not yet clear how much of the control/config
aspect will be included in that effort. Centralized architecture is where we
hear the interoperability demand the most. 
Now within the Centralized architecture, there is a harder question to
answer: what kind of interoperability we want? Across all 3 sub-categories
with one protocol? Does that make sense, eps. If different sub-category
suits for different deployment scenarios? Is it technically feasible to have
one fit all? Or is it acceptable to have only interoperability within each
sub-category? Should this group work on all 3? Or 1? 2?

One option for the WG is to only draw the scope boundary around Centralized
Architecture, but not dictating whether or not we should develop one
solution for all, or separate solution for each one. If people can come up
with solutions/proposals to solve interoperability across 3, I don't see why
we shouldn't allow them to try. On the other hand, if people have strong
proposals for each individual sub-category, that should be allowed too. The
WG can evaluate all the options and then decide.

Another option is to decide on the exact extend of interoperability now, and
only accept proposals that work for it.

I am not advocating any particular option in this email, but just want to
point out that these are the questions we need to ponder upon when we
discuss rechartering.

Lily

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James Kempf
Sent: Tuesday, August 03, 2004 11:17 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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
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

> Cc: Bert Wijnen (E-mail); Mani Mahalingam (E-mail); Kessens David 
> (Nokia-NET/MtView)
> 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.
>

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