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

[Victor Lin (VLin]

I agree that we can design a protocol and implement the product that works
all architectures. I think the question to CAPWAP is:

Should we make it a requirement in CAPWAP protocol to achieve
interoperability between different architectures? 

It is definitely doable, but I'm not sure if that is the right thing to do..

Victor

-----Original Message-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On 
Behalf
Of Bob O'Hara
Sent: Thursday, August 05, 2004 11:43 AM
To: capwap [at] frascone.com
Subject: RE: [Capwap] So many architectures, so little time... - take 2

I think that interoperability will depend on two things.  First, it will
depend on how we define the protocol and the flexibility for supported
architectures it incorporates.  Second, it will depend on what
manufacturers implement, i.e., the flexibility they build into their
products.  

I believe that it is possible to design the protocol for the required
flexibility.  I know it is possible to implement a product with the
required flexibility.

 -Bob O'Hara
 

-----Original Message-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On
Behalf Of Abhijit Choudhury
Sent: Thursday, August 05, 2004 11:32 AM
To: James Kempf; 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


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