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

[Shehzad Merchant (smerchant]

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