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

[Partha Narasimhan (partha]

Since many of the AP functions are split between the WTP and the AC in
most of the split-MAC or local-MAC submissions, this requires that a
mechanism for transporting data frames (and some mgmt frames in the
split MAC architecture) between the WTP and the AC be defined for a
multi-vendor solution that works. So the transfer of data frames between
the WTP and the AC is not a problem that we can ignore. Ideally, we
should come up with a mechanism that works for both architectures (since
there are differences) and for both data and mgmt frames. 

Thanks
partha 

On Mon, 2004-08-09 at 06:13, Wijnen, Bert (Bert) wrote:
> 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
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap