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

[Dorothy.Gellert (Dorothy.Gellert]

Our charter is limited to control and management, not data tunneling.  Lets 
stay focused on our chartered goal, control and management.

Thanks,
Dorothy

> -----Original Message-----
> From: capwap-admin [at] frascone.com [mailto:capwap-admin [at] frascone.com]On
> Behalf Of ext Shehzad Merchant
> Sent: Tuesday, August 10, 2004 11:13 AM
> To: Shankar Narayanaswamy; Abhijit Choudhury
> Cc: capwap [at] frascone.com
> Subject: RE: [Capwap] So many architectures, so little 
> time... - take 2
> 
> 
> Additionally, for data tunneling one needs a lightweight 
> mechanism that may
> not necessarily have the same requirements as that for control and
> management. For example, one would want to limit the tunneling and
> processing overhead on data packets to a minimum. Control and 
> management may
> be more tolerant of tunneling/security/etc. overhead. 
> Besides, there are
> plenty of standards in place for data tunneling. We may 
> potentially be able
> to leverage off that work itself without having to invent yet another
> tunneling mechanism for data. 
> 
> -S
> 
> 
> -----Original Message-----
> From: capwap-admin [at] frascone.com 
> [mailto:capwap-admin [at] frascone.com] On Behalf
> Of Shankar Narayanaswamy
> Sent: Tuesday, August 10, 2004 10:30 AM
> To: Abhijit Choudhury
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] So many architectures, so little 
> time... - take 2
> 
> On the first point: not necessarily. If data packets are encapsulated
> 802.11 data frames, then there is no need to protect them on 
> the wire any
> more than they were encrypted over the air.
> 
> But control and management packets will need protection over the wired
> network and therefore possibly a different tunneling protocol.
> 
> On the second point (standard way of packet exchange): yes!
> 
> -s
> 
> Abhijit Choudhury wrote:
> > 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
> _______________________________________________
> Capwap mailing list
> Capwap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap


--
Shankar Narayanaswamy, Ph.D.
wireless [at] shankar.org            Mobile: +1 650-387-4593
http://www.shankar.org          E-Fax: +1 253-498-8372

_______________________________________________
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