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

[Wijnen, Bert (Bert) (bwijnen]

Not sure who is confused... probably me...

My understanding was/is that IF we do re-charter for CAPWAP
protocol work, that it is then a NM protocol for 
"Control and Provisioning" and not any of the related stuff 
that moves the data from WTP to AC.

Is everybody in agreement with that understanding.

Thanks,
Bert 

> -----Original Message-----
> From: Yang, Lily L [mailto:lily.l.yang [at] intel.com]
> Sent: maandag 9 augustus 2004 08:14
> To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; capwap [at] frascone.com
> Subject: RE: [Capwap] So many architectures, so little 
> time... - take 2
> 
> 
> I think setting the re-charter scope to develop a single protocol that
> allows interoperability between Local and Split MAC is a reasonable
> tradeoff:
> We exclude remote MAC because the constraint it imposes is very
> different from the rest and the benefit of including it is 
> very little.
> But Local and Split MAC are reasonably close and hence the 
> effort may be
> incremental only. 
> As many people noted, as of today, there is no single clear definition
> of what "Local MAC" and "Split MAC" really means yet. Each vendor has
> different definitions and some debate needs to happen so that 
> the WG can
> reach consensus on what exactly that means, and what kinds of
> flexibility we want to retain within each class of architecture, and
> what kind of differences we can to resolve and agree up front. That
> should also be part of the work items for the new WG -- such agreement
> on the details for each architecture must be documented somewhere, if
> not separately, then as part of the Protocol document.
> 
> -----Original Message-----
> From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] 
> On
> Behalf Of Burbank, Jack L.
> Sent: Thursday, August 05, 2004 12:14 PM
> To: 'Victor Lin '; 'Bob O'Hara '; 'capwap [at] frascone.com '
> Subject: RE: [Capwap] So many architectures, so little 
> time... - take 2
> 
> I think that interoperability between different architectures 
> should be
> a
> requirement, if not the key requirement.  As was mentioned 
> yesterday, a
> goal
> of the IEEE is that they maintain flexibility in terms of how products
> and
> architectures are implemented.  I think we shouldn't do 
> anything that is
> contrary to that goal (or at least we should minimize the impact).  I
> think
> that the goal of CAPWAP should be to retain this type of 
> flexibility by
> designing a protocol that can maintain this implementation flexibility
> but
> enable interoperability between the various architecture 
> implementations
> (that after all is the key problem with the deployment of 
> these various
> architectures - lack of interoperability).  IMO, if we don't 
> design for
> interoperability between the basic architecture types, it is debatable
> if
> something useful would have been accomplished.
> 
> Jack Burbank
> 
> -----Original Message-----
> From: capwap-admin [at] frascone.com
> To: Bob O'Hara; capwap [at] frascone.com
> Sent: 8/5/2004 2:46 PM
> Subject: RE: [Capwap] So many architectures, so little 
> time... - take 2
> 
> 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
_______________________________________________
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