Capwap Mailing List: RE: So many architectures, so little time... - take 2

[Abhijit Choudhury (Abhijit]

It may be possible to achieve such interoperability
within the split-MAC family or within the local-MAC
family.  It would sbe very hard to achieve 
that between local and split MAC families.

For example, if vendor X's WTP terminates 802.11 ctrl/mgmt
packets and vendor Y's AC expects the 802.11 mgmt packets
to come to it, there's no way you can be interoperable.

Or are we planning to specify ONE architecture ?
The last thing IETF should do is mandate an implementation.

I think a modest and reasonable goal is to come up 
with a protocol that allows sufficient flexbility so
that vendors with splitMAC architectures can transfer
most of the information they care about between the WTP and AC.

Just my $0.02 ...


Abhijit Choudhury


-----Original Message-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On
Behalf Of James Kempf
Sent: Wednesday, August 04, 2004 3:29 PM
To: Shehzad Merchant; capwap [at] frascone.com
Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; david.kessens [at] nokia.com;
Dorothy.Gellert [at] nokia.com; Inderpreet Singh
Subject: Re: [Capwap] So many architectures, so little time... - take 2


As a potential customer, let me put it concretely. I want to be able to
buy my access points from Vendor X and my switch from Vendor Y and plug
the two together and have them work without any configuration. Also, I'd
like to be able to buy switches from Vendor Y and Vendor Z and be able
to plug them into my network at various places and have them
interoperate.

            jak


----- Original Message ----- 
From: "Shehzad Merchant" <smerchant [at] extremenetworks.com>
To: <capwap [at] frascone.com>
Cc: <bwijnen [at] lucent.com>; <mmani [at] avaya.com>; <david.kessens [at] 
nokia.com>;
<Dorothy.Gellert [at] nokia.com>; "Inderpreet Singh"
<isingh [at] chantrynetworks.com>
Sent: Wednesday, August 04, 2004 3:19 PM
Subject: RE: [Capwap] So many architectures, so little time... - take 2


> I think the implementation variations even with the split MAC may 
> cover a broad spectrum. As such its important to clearly articulate 
> what aspects
of
> interoperability we are targetting. Is it truly just 
> control/management or is it interoperability between disparate 
> implementations of the split MAC, i.e. mix and match operation of WTP 
> and ACs of all variants within this category.
>
> I suspect for the latter we may have to arrive at some consensus on 
> what particular implementations we are targeting interoperability for.

> If so, ultimately this problem statement could become part of the 
> charter.
>
> -Shehzad
>
>
>
> -----Original Message-----
> From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] 
> On
Behalf
> Of Dorothy.Gellert [at] nokia.com
> Sent: Wednesday, August 04, 2004 11:53 AM
> To: isingh [at] chantrynetworks.com; capwap [at] frascone.com
> Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; david.kessens [at] 
> nokia.com
> Subject: RE: [Capwap] So many architectures, so little time... - take 
> 2
>
> I believe this is the consensus, to scope the charter to Centralized 
> Architecture and LocalMAC and Split MAC.
>
> I'll update the charter with this change after the CAPWAP WG Mtg. If 
> there is resistance to this idea, please post to the list.
>
> Regards
> Dorothy
>
>
> > -----Original Message-----
> > From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] 
> > frascone.com]On
> > Behalf Of ext Inderpreet Singh
> > Sent: Tuesday, August 03, 2004 9:40 PM
> > To: capwap [at] frascone.com
> > Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; Kessens David 
> > (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView)
> > Subject: RE: [Capwap] So many architectures, so little time... - 
> > take 2
> >
> >
> > The issue(s) at hand and my opinions are:
> >
> > 1. Do we explicitly state in the re-charter which architecture the 
> > WG should consider? I think yes.  I propose Centralized architecture

> > only. Autonomous and Distributed should be out of scope based on the

> > same reasons as per prior postings.
> >
> > 2. Within Centralized do we focus on all three sub architectures or 
> > a subset? Remote MAC should be excluded because if I am not 
> > mistaken, the connectivity constraint between the WTP and the AC is 
> > "direct connect".
> > That being the case and that no IP layer is involved, it doesn't
seem
> > clear what kind of protocol would help with interoperability.
> > I am concerned about the impact, dependencies and interaction with
> > the recently constituted IEEE Study group on AP functionality on the
> > Split MAC architectures.  Furthermore, there are some pretty drastic
> > differences on how the vendors have chosen to split the mac.  Those
> > differences will need to be worked out before designing a protocol.
> > So, if the low hanging fruit strategy (as James suggested) for
> > protocol development and progress is the way to go, then I think
> > prioritizing on a protocol for Local MAC is a no brainer.  So as far
> > as focus, I feel we should do Local and Split and in that order.
> >
> > 3. This is not a re-chartering issue but is a response to Pat's 
> > suggestion that a protocol that just sends the 802.11 MAC frames 
> > from the AP to the AC would work.  I think possibly, yes.  But again

> > the complications of splitting the MAC in an interoperable way will 
> > be an issue.  Also, you may note in the draft to which you refer, we

> > included a capabilities exchange phase.  I had thought of including 
> > in the capability exchange such things as "AP supports Local MAC" 
> > and "AP supports Split MAC", but didn't put it in because the 
> > Taxonomy work was still in progress.  Now that it is pretty much 
> > done we could surely include that.  But again...let's recharter 
> > first.
> >
> > Thanks.  Do people agree with 1 & 2?
> >
> > ---
> > Inderpreet Singh
> > Chantry Networks
> > isingh [at] chantrynetworks.com
> > Cell: 416-831-3705
> >
> > -----Original Message-----
> > From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] 
> > frascone.com] 
> > On Behalf Of Pat R. Calhoun
> > Sent: Tuesday, August 03, 2004 6:04 PM
> > To: Yang, Lily L; James Kempf; Dorothy.Gellert [at] nokia.com; 
> > capwap [at] frascone.com
> > Cc: bwijnen [at] lucent.com; mmani [at] avaya.com; david.kessens [at] 
> > nokia.com
> > Subject: [Capwap] So many architectures, so little time... - take 2
> >
> > After reading Lily's response to Jim, I realize that I fell down the

> > same trap. Local MAC is also a centralized approach, and so my 
> > previous response was not complete. I believe the real question, in 
> > my mind, is whether we need to address either the Local or the Split

> > MAC architecture.
> >
> > Just looking at the Architecture Consideration tables (7 and
> > 10) in the
> > specification, the
> > main difference (at a high level) between both approaches is where 
> > the 802.11 management terminates. For Local MAC, it's in the WTP, 
> > while for SPlit MAC, it's in the AC.
> >
> > However, looking at table 8, most Local MAC approaches share STA 
> > state between both the WTP and the AC. So clearly there is some 
> > signalling protocol between both the WTP and the AC.
> >
> > Looking at one example of a Local MAC protocol (see 
> > http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt),
> > there is a protocol message
> > that corresponds for every 802.11 MAC management event. So when a 
> > STA associates, the AP breaks the message apart and creates an new 
> > protocol PDU, which contains components found in the association 
> > request. I suspect that most Local MAC approaches do something very 
> > similar.
> >
> > So if a protocol simply tunnels the 802.11 MAC management frames 
> > from the WTP to the AC, it allows supports both approaches. For 
> > Local MAC, they get what they want via the 802.11 frame, and this
> > also works fine for Split MAC, which needs access to the MAC
> > management frame. What would be required in such a protocol is a way
> > for the AP to communicate whether it will be providing very specific
> > functions - basically a capabilities negotiation approach.
> >
> > So I do believe that there is a way to address both architectures 
> > using a single protocol.
> >
> > Thoughts?
> >
> > PatC
> >
> > _______________________________________________
> > Capwap mailing list
> > Capwap [at] frascone.com http://mail.frascone.com/mailman/listinfo/capwap
> >
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com http://mail.frascone.com/mailman/listinfo/capwap
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap


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