Capwap Mailing List

View Index by: Date - Thread - Author
Re: So many architectures, so little time... - take 2
From: Shankar Narayanaswamy (wirelessshankar.org)
Date: Tue, 10 Aug 2004 13:15:44 -0400 (EDT)
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


Results generated by Tiger Technologies using MHonArc.