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

[Abhijit Choudhury (Abhijit]

The same tunneling protocol that moves control and management
packets from the WTP to the AC should be used to tunnel data
packets as well.  We would specify message exchanges to do
control, provisioning and capability advertisement between WTPs
and the AC.  But all of this would be within the unified CAPWAP
protocol that moves all packets including data between the WTP
and AC.  Vendors currently use LWAPP, GRE, IP and
some proprietary encapsulations to achieve this.  This group
would come up with a "standard" way of doing this exchange.

At least that was my understanding....

Regards,
Abhijit 

-----Original Mssage-----
From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com] On
Behalf Of Wijnen, Bert (Bert)
Sent: Monday, August 09, 2004 6:14 AM
To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara;
capwap [at] frascone.com
Subject: RE: [Capwap] So many architectures, so little time... - take 2


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