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

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 3 Aug 2004 13:31:38 -0700

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.
>
> 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:17:56 -0700

Lily,

Thanx for the clarification. I did not distinguish between the distributed
and centralized architecture.

My opinion is that the new WG charter should concentrate on wired access
network architecures, and, in that case, that access network control
protocols for multihop/ad hoc access networks in the distributed class
should be out of scope.

Within the centralized class, I think the WG should make a decision about
whether there is any need for IETF work on an interoperability protocol
between all three classes. Personally, I don't believe there is such a need.
I believe having products interoperate within a particular class is
sufficient, because each class is likely to address a particular collection
of deployment scenarios that don't overlap much, if at all. Given that IETF
has limited resources, I think the WG should determine whether there is
really any need for an interoperable IP level protocol between products in
each of the classes, and should select one class (initially, maybe later the
others if the need is there) where the need for interoperability is
greatest.

That's my 0.02 yen.

                jak

----- Original Message ----- 
From: "Yang, Lily L" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 03, 2004 1:31 PM
Subject: RE: [Capwap] RE: Re-charter proposal text to discuss at CAPWAP WG
Mtg

Lily

-----Original Message-----

Dorothy,

                       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

---

From: Peyush AGARWAL <[email-masked]>
Date: Wed, 4 Aug 2004 19:30:09 +0530

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