Subject: [Capwap] RE: So many architectures, so little time... - take 2

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Tue, 3 Aug 2004 20:42:02 -0600

The taxonomy draft analysis leads to such a possibility. The solution
space will likely involve a discovery and negotiation phase

leading to supportability of significant architecture classes.

-mani

  _____  

From: Pat R. Calhoun [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 3:04 PM
To: Yang, Lily L; James Kempf; [email-masked];
[email-masked]
Cc: [email-masked]; Mani, Mahalingam (Mahalingam);
[email-masked]
Subject: 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

---

From: Victor Lin <[email-masked]>
Date: Tue, 3 Aug 2004 22:34:17 -0700

I think single protocol is the easy part. Pat's suggestion definitely works.
But to support interoperability with multiple architectures, I think it is
important to clearly define the functionality of WTP and AC and have a
protocol for AC and WTP to negotiate/advertise their capability.

Victor

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, August 03, 2004 3:04 PM
To: Yang, Lily L; James Kempf; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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
<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

So I do believe that there is a way to address both architectures using a
single protocol.

Thoughts?

PatC

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Wed, 4 Aug 2004 07:36:02 -0700

A fine suggestion.

PatC

-----Original Message-----
From: [email-masked] on behalf of Partha Narasimhan
Sent: Wed 8/4/2004 7:21 AM
To: Inderpreet Singh
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Capwap] So many architectures, so little time... - take 2
 
If we all agree that a common protocol would work for both the local MAC
and the split MAC architectures, then I propose that we work on this as
a joint problem instead of doing one before the other. This avoids
either
 
- having to go back and attempt to change what was done at step 1 while
working on step 2, or
- work completed in step 1 constraining what is possible in step 2. 

Thanks
partha

On Tue, 2004-08-03 at 21:39, Inderpreet Singh wrote:
> 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
> [email-masked]
> Cell: 416-831-3705
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Pat R. Calhoun
> Sent: Tuesday, August 03, 2004 6:04 PM
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: <[email-masked]>
Date: Wed, 4 Aug 2004 11:52:55 -0700

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

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Inderpreet Singh
> Sent: Tuesday, August 03, 2004 9:40 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Kessens David
> (Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView)

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Wed, 4 Aug 2004 17:23:59 -0600

This in itself justifies the need to be able to seek idiosyncracies and
commonalities of "customer" pressure-points and later sit back to
prioritize them.

Of the two requirements the more thought about is the first (and more of
the core challenge). However,...

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Wednesday, August 04, 2004 3:29 PM
To: Shehzad Merchant; [email-masked]
Cc: [email-masked]; Mani, Mahalingam (Mahalingam);
[email-masked]; [email-masked]; 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

[Mani, Mahalingam (Mahalingam)] 
[Mani, Mahalingam (Mahalingam)] the latter is a new, good and
interesting requirement to consider; whether it goes into desirable or
mandatory bucket remains to be seen.

Also - whether it is a coexistence requirement or interoperability
requirement is to be analyzed as well.

-mani

into my network at various places and have them interoperate.

            jak

----- Original Message ----- 
From: "Shehzad Merchant" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Inderpreet Singh"
<[email-masked]>
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
>
[Mani, Mahalingam (Mahalingam)] [...]

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Thu, 5 Aug 2004 11:32:17 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of James Kempf
Sent: Wednesday, August 04, 2004 3:29 PM
To: Shehzad Merchant; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; 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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;

> cover a broad spectrum. As such its important to clearly articulate 
> what aspects
of
> 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.
>
> what particular implementations we are targeting interoperability for.

> If so, ultimately this problem statement could become part of the 
> charter.
>
> -Shehzad
>
>
>
Behalf
> Of [email-masked]
> Sent: Wednesday, August 04, 2004 11:53 AM
> To: [email-masked]; [email-masked]
> 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
>
>
> > 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".
> > 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 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.
> >
> > 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.
> >
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Pat R. Calhoun

> > 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.
> > 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.
> >
> > 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 
> > 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
> > So I do believe that there is a way to address both architectures 
> > using a single protocol.
> >
> > Thoughts?
> >
> > PatC
> >
> > [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
> >
> [email-masked] http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked] http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Bob O'Hara" <[email-masked]>
Date: Thu, 5 Aug 2004 11:43:19 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Abhijit Choudhury
Sent: Thursday, August 05, 2004 11:32 AM
To: James Kempf; Shehzad Merchant; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Inderpreet Singh
Subject: RE: [Capwap] So many architectures, so little time... - take 2

Just my $0.02 ...

Abhijit Choudhury

-----Original Message-----

            jak

----- Original Message ----- 
From: "Shehzad Merchant" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;

of

Behalf

---

From: "Burbank, Jack L." <[email-masked]>
Date: Thu, 5 Aug 2004 15:13:46 -0400

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: [email-masked]
To: Bob O'Hara; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf
Of Bob O'Hara
Sent: Thursday, August 05, 2004 11:43 AM
To: [email-masked]
Subject: RE: [Capwap] So many architectures, so little time... - take 2

 -Bob O'Hara

-----Original Message-----

Just my $0.02 ...

Abhijit Choudhury

-----Original Message-----

            jak

----- Original Message ----- 
From: "Shehzad Merchant" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;

of

Behalf

---

From: Shehzad Merchant <[email-masked]>
Date: Thu, 5 Aug 2004 16:48:45 -0700

To achieve interoperability one needs to define what you are trying to
interopate between. i.e. you need to pick a model or a set of models between
which interopability is guaranteed. Leaving that open ended will probably
make interoperability more difficult and more drawn out. 

As such, I think we need to be explicit as to what architectures or
subarchitectures one is targetting interoperability between and if that is a
TBD, then perhaps the charter should make that a problem statement.  

-Shehzad

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]] 
Sent: Thursday, August 05, 2004 4:18 PM
To: Abhijit Choudhury; James Kempf; Shehzad Merchant; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

> The last thing IETF should do is mandate an implementation.

Why not.  Most IETF standards require two reference implementations that
interoperate.  If this working group is producing multiple non-iteroperable
protocols, it should split into more than one working group.

This working group should pick one approach, or disband.

The current documentation has been a excellent survey, now the working group
needs to move forward to a single 'consensus' solution.

Paul

> [mailto:[email-masked]] On Behalf Of Abhijit Choudhury
> 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.
> 
> 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
> 
> 
> [mailto:[email-masked]] On Behalf Of James Kempf
> 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
> 
> 
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>; "Inderpreet 
> Singh"
> [mailto:[email-masked]] On
> Behalf
> > Subject: RE: [Capwap] So many architectures, so little
> time... - take
> > 2
> >
> [mailto:[email-masked]]On
> [mailto:[email-masked]]

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 6 Aug 2004 15:21:10 +0300

The distinction between local and split is known to a limited group of people.
I would bet that customers need to make a decision to buy AP will not show interest in split versus local architecture. Functionality, price, interoperability will be the customers' criteria.

In my humble opinion the group must strive for interoperability between AC and AP irrespectively to split versus local. CAPWAP should not support any variant on the 0..1 line but 2 to (max) 3 protocols flavors would do the trick.

I would change the "D" to "R"

Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Cheng Hong
Sent: Friday, 06 August, 2004 4:46 AM
To: 'Petros Zerfos'; Mani, Mahalingam (Mahalingam); [email-masked]
Cc: 'Victor Lin'; 'Bob O'Hara'
Subject: RE: [Capwap] So many architectures, so little time... - take 2

Hi Petros,

That is a nice table to start discussion. 

Regarding the interoperability table, please see some comments inline.

<snip>
> Hi all,
> 
> I agree that we need to clarify the notion of 
> interoperability. Specially if we want to include the 
> cross-architecture_family interoperability case, where we 
> actually have (at least) the following combinations:
> 
>                local_MAC  WTP    |  split_MAC WTP
>               -------------------+---------------
> local_MAC AC  |       R          |        D
> 	      |                  |
> split_MAC AC  |       D          |        R
> 
> Legend
> ------
> R = Required
> D = Desirable
> 
> I think that everybody agrees that (local_MAC AC, local_MAC 
> WTP) and (split_MAC AC, split_MAC WTP) interoperability is needed.

Agree. Without this, I don't think the protocol could achieve anything,
unless the group is going towards one single implementation.

> From the previous emails, it seems that the other two (the cross-arch.
> family) types are highly desirable. Do they make sense 
> though, from the implementation point of view? Since I assume 
> we want to avoid the "update the firmware of the WTP (or 
> AC?)", as a solution :)

Not sure about the (Local_MAC AC, Split MAC WTP) case, since it may require
the some architecture change or additional functions in the WT or AC. But
for the (Split_MAC AC, Local_MAC WTP) case, interoperability should be
supported. This does not need to update WTP, and only thing is for the AC to
support a subset of the functions it already has. This doesn't seems like an
irrational requirement.

> Also, deliberately I didn't include the Autonomous_AP case 
> (another arch. family, in the cross-arch._family interop 
> conundrum), since the number of possible combinations would 
> increase. Also, the case between [split_MAC AC <--> local_MAC 
> AC] (and the respective intra-arch._family combos) would 
> extend the matrix.

It may make the matrix not as clean as it is, but including those could
clearly indicate the group's stand on the extra possibilities. If certain
case could not be decided now, we can indicate it with T (TBD) and come back
later. I guess we need a full table in the "Objective" draft in the end.

cheers

Cheng

> Just a first (small) attempt to formalize the interoperability cases.
> 
> Petros
>

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 6 Aug 2004 06:46:16 -0700

I guess it's no surprise that I disagree. Yes, there are functions in split MAC that
typically occur in the AC, while they normally occur in the WTP in local MAC. However,
what you will find is that in Local MAC, the functions really occurs in both places, but
the notification that is sent from the WTP to the AC is not an 802.11 packet, but a
packet that was derived from an 802.11 packet (for instance, the AP breaks apart the 
association request and sends a notification). Frankly, in the end it's nearly the
same thing.

I really don't think that the architecture is that different.

Furthermore, there is a HUGE disadvantage with a local MAC approach (looking at the CTP
protocol for instance, since its the only one that is available). When the IEEE comes up
with some extensions to 802.11 (e.g. 802.11e), there will be a need to get together and
create an extension to the local MAC protocol to pass this information to the AC... so
hierarchical systems will always lag in feature set until the IETF is ready with the
protocol extension - and those could take 12 months.

The split MAC approach ensures that both the WTP and the AC receive the 802.11 packets 
and can therefore instantly support any new IEEE 802.11 extensions.

PatC
-----Original Message-----
From: [email-masked] on behalf of Abhijit Choudhury
Sent: Thu 8/5/2004 11:32 AM
To: James Kempf; Shehzad Merchant; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Inderpreet Singh
Subject: RE: [Capwap] So many architectures, so little time... - take 2

Just my $0.02 ...

Abhijit Choudhury

-----Original Message-----

            jak

----- Original Message ----- 
From: "Shehzad Merchant" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;

of

Behalf

---

From: "Yang, Lily L" <[email-masked]>
Date: Sun, 8 Aug 2004 23:13:30 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Burbank, Jack L.
Sent: Thursday, August 05, 2004 12:14 PM
To: 'Victor Lin '; 'Bob O'Hara '; [email-masked] '
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: [email-masked]
To: Bob O'Hara; [email-masked]
Sent: 8/5/2004 2:46 PM
Subject: RE: [Capwap] So many architectures, so little time... - take 2

Victor

-----Original Message-----

 -Bob O'Hara

-----Original Message-----

Just my $0.02 ...

Abhijit Choudhury

-----Original Message-----

            jak

----- Original Message ----- 
From: "Shehzad Merchant" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;

of

Behalf

---

From: Shehzad Merchant <[email-masked]>
Date: Tue, 10 Aug 2004 11:12:56 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Shankar Narayanaswamy
Sent: Tuesday, August 10, 2004 10:30 AM
To: Abhijit Choudhury
Cc: [email-masked]
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-----
> 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; 
> [email-masked]
> 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
> 
> 
>>From: Yang, Lily L [mailto:[email-masked]]
>>Sent: maandag 9 augustus 2004 08:14
>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ; [email-masked]
>>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.
>>different definitions and some debate needs to happen so that the WG 
>>can reach consensus on what exactly that means, and what kinds of 
>>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 
>>if something useful would have been accomplished.
>>
>>Jack Burbank
>>
>>works all architectures. I think the question to CAPWAP is:
>>
>>It is definitely doable, but I'm not sure if that is the right thing 
>>to do..
>>
>>Victor
>>
>>Behalf Of Bob O'Hara
>>>implementations of the split MAC, i.e. mix and match
>>
>>operation of WTP
>>
>>>what particular implementations we are targeting
>>
>>interoperability for.
>>
>>
>>>I believe this is the consensus, to scope the charter to
>>
>>Centralized
>>
>>>I'll update the charter with this change after the CAPWAP
>>
>>WG Mtg. If
>>
>>>>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
>>
>>
>>>>2. Within Centralized do we focus on all three sub
>>>
>>architectures or
>>
>>>>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.
>>
>>>>prioritizing on a protocol for Local MAC is a no brainer.
>>>
>> So as far
>>
>>>>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
>>
>>>>Subject: [Capwap] So many architectures, so little
>>>
>>time... - take 2
>>
>>>>After reading Lily's response to Jim, I realize that I
>>>
>>fell down the
>>
>>
>>>>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.
>>>>
>>>>main difference (at a high level) between both approaches
>>>
>>is where
>>
>>>associates, the AP breaks the message apart and creates an new 
>>>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.
>>>

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

---

From: <[email-masked]>
Date: Tue, 10 Aug 2004 11:47:59 -0700

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

Thanks,
Dorothy

> Behalf Of ext Shehzad Merchant
> Sent: Tuesday, August 10, 2004 11:13 AM
> To: Shankar Narayanaswamy; Abhijit Choudhury
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf
> Of Shankar Narayanaswamy
> packets and
> >>Subject: Re: [Capwap] So many architectures, so little 
> time... - take 
> >>2
> >>
> >>

---

From: "Sudhanshu Jain" <[email-masked]>
Date: Tue, 10 Aug 2004 11:54:42 -0700

I fully agree with Shehzad. We need to separate the control and data
plane. Control plane should provide the framework to use one of several
tunneling protocol. 

On data plane, if we need to define a new layer2/layer3 level tunneling
protocol, it should be separate work from control protocol work. 

-Suds

-----Original Message-----
Behalf Of Shehzad Merchant

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-----

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.

-s

---

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 10 Aug 2004 18:12:36 -0700

The question in my mind is: Can data plane and control plane be cleanly
separated for Split MAC? I know it is feasible for Local MAC, but not
sure about Split MAC. 
Any insight?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sudhanshu Jain
Sent: Tuesday, August 10, 2004 11:55 AM
To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury
Cc: [email-masked]
Subject: RE: [Capwap] So many architectures, so little time... - take 2

-Suds

-----Original Message-----

-S

-----Original Message-----

-s

---

From: "Sudhanshu Jain" <[email-masked]>
Date: Tue, 10 Aug 2004 19:19:24 -0700

Problem we have to solve can be classified into three categories.

* Control & Management of WTP
* Control & Management of STA
* 802.11 Data

Since different functionalities has different requirements, it is
possible to address them with separate sets of mechanism. 

First version of CAPWAP control protocol should address first
functionality with provision to communicate 
* Tunneling mechanism
* Information about MAC implementation (Local/Split/Centralized) etc.

-Suds

-----Original Message-----
From: Yang, Lily L [mailto:[email-masked]] 
Sent: Tuesday, August 10, 2004 6:13 PM
To: Sudhanshu Jain; Shehzad Merchant; Shankar Narayanaswamy; Abhijit
Choudhury
Cc: [email-masked]

-----Original Message-----

-Suds

-----Original Message-----

-S

-----Original Message-----

-s

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 27 Aug 2004 08:31:32 -0700

Well, the local MAC implementations that I am aware of also tunnel traffic to the AC.
 
So I believe that there is some mis-understanding on what split vs. local means. Frankly,
the differences are quite small. Where split sends up the MAC frames for access control
processing on the AC, local MAC terminates the MAC on the AP but then creates some
control message that includes all of the data that was in the MAC message.
 
So in my  opinion, local MAC increases the protocol design work because one needs to
in essence "recreate"  the 802.11 MAC mgmt protocol. Further, it's not clear how the IETF
would deal with new IEEE extensions (e.g. 802.11k) because these recreated messages
would have to include new information that isn't known today - so a CAPWAP solution
would always be behind.
 
Split MAC does not suffer from this approach.
 
PatC

________________________________

From: [email-masked] on behalf of Saravanan Govindan
Sent: Wed 8/11/2004 7:23 AM
To: 'Abhijit Choudhury'; [email-masked]
Subject: RE: [Capwap] So many architectures, so little time... - take 2

Given the various sides to the discussion on where MAC frames are handled, I 
suggest making this a configuration aspect of the CAPWAP protocol. So, the 
choice of which MAC frames are processed where can be left till the time of 
initializing APs. 

For example, when a controller initializes a local-MAC AP, it configures one 
instance of the CAPWAP protocol so as NOT to receive any MAC frames from the 
AP. Rather, the protocol instance expects to receive explicit CAPWAP 
messages/signals from the local-MAC AP. 

On the other hand, while initializing a split-MAC AP, another instance of 
the protocol is configured to receive 'some' MAC frames and 'other' 
remaining CAPWAP messages/signals. The 'some' and 'other' parts refer to 
particular split-MAC variations. The specifics of these parts can be left 
for refinement based on the analyses from the Architecture Taxonomy. 

The CAPWAP protocol can then be made to work on both raw MAC frames and 
abstracted CAPWAP messages/signals. This way, true interoperability is 
achieved, while at the same time allowing for different designs and 
implementations. 

Comments? Suggestions? 

Saravanan 

________________________________ 

        From: [email-masked] [mailto:[email-masked]] 
On Behalf Of Abhijit Choudhury 
        Sent: Wednesday, August 11, 2004 2:18 PM 
        To: [email-masked] 
        Subject: FW: [Capwap] So many architectures, so little time... - 
take 2 

        One key objective that has been discussed in this group 
        is INTEROPERABILITY.  It's not clear how you achieve 
        interoperability between a WTP from vendor X and an AC 
        from vendor Y, if you don't support the same protocols on 
        all three categories that you have pointed out.  Sure you can 
        achieve interoperability between the two, if you support the 
        superset of all possible encapsulations, but then you are no 
        better off than you are currently.  That is why there is need 
        for a standard.   And it's easier to implement in hardware or 
software 
        if there is one standard protocol instead of three. 
         
        We really should strive towards a unified tunneling protocol for 
control 
        and data, although you can have separate connections 
        for each, and different security on each. 
         
        But if this group stays away from specifying a common 
        protocol for control/mgmt and data between the WTP 
        and AC, or specifies one and not the other, 
        there cannot be true interoperability even within 
        the split-MAC architecture family. 
         
        Abhijit 

________________________________ 

        From: Sudhanshu Jain 
        Sent: Tue 8/10/2004 7:19 PM 
        To: 'Yang, Lily L'; Shehzad Merchant; Shankar Narayanaswamy; Abhijit 
Choudhury 
        Cc: [email-masked] 
        Subject: RE: [Capwap] So many architectures, so little time... - 
take 2 

        First version of CAPWAP control protocol should address first 
functionality with provision to communicate 
        * Tunneling mechanism 
        * Information about MAC implementation (Local/Split/Centralized) 
etc. 

        -Suds

---

From: [email-masked]
Date: Mon, 30 Aug 2004 15:19:09 -0700

Hi Pat,

  Just to clarify one point from your note to others:

  Your interpretation on the "Local MAC" can be true but not necessarily
the only way to interpret/deploy/implement it.

  According to Section 4.6 of draft-ietf-capwap-arch-05.txt, in a Local MAC
deployment:
both data plane and control plane should be terminated at WTP, but the
802.3 & 802.11 bridging
"can be part of either the AC or WTP in the Local MAC".

   What you mentioned was correct, meanwhile, I am aware of another vendor
who uses
an AC (switch, not router) to manage/control APs (and STAs) but all data
traffic is plain 802.3 traffic
to the AC (i.e. no tunneling for data traffic).
Whatever we want to call it, this kind of implementation does exist and
makes sense (as others) technically.
Yes extension to IEEE802.11 (such as TGk) may cause more complication in
the future.
Hopefully the protocol CAPWAP is going to adopt can allow flexibility if
"Local MAC" is addressed.

  One thing obvious is the definitions of "local/split/remot" MAC may not
have been detailed enough to
cleanly seperate all possibilities into 3 categories. This might be a good
starting point for the CAPWAP protocol
design discussion, before people diving into proposing various solutions.

---Tyan-Shu Jou

                                      ================                     

                                                                           

                                       Well, the local MAC implementations 
                                       that I am aware of also tunnel      
                                       traffic to the AC.                  
                                                                           
                                       So I believe that there is some     
                                       mis-understanding on what split vs. 
                                       local means. Frankly,               
                                       the differences are quite small.    
                                       Where split sends up the MAC frames 
                                       for access control                  
                                       processing on the AC, local MAC     
                                       terminates the MAC on the AP but    
                                       then creates some                   
                                       control message that includes all   
                                       of the data that was in the MAC     
                                       message.                            
                                                                           
                                       So in my  opinion, local MAC        
                                       increases the protocol design work  
                                       because one needs to                
                                       in essence "recreate"  the 802.11   
                                       MAC mgmt protocol. Further, it's    
                                       not clear how the IETF              
                                       would deal with new IEEE extensions 
                                       (e.g. 802.11k) because these        
                                       recreated messages                  
                                       would have to include new           
                                       information that isn't known today  
                                       - so a CAPWAP solution              
                                       would always be behind.             
                                                                           
                                       Split MAC does not suffer from this 
                                       approach.                           
                                                                           
                                       PatC                                
                                                                           
                                       From: [email-masked] on  
                                       behalf of Saravanan Govindan        
                                       Sent: Wed 8/11/2004 7:23 AM         
                                       To: 'Abhijit Choudhury';            
                                       [email-masked]                 
                                       Subject: RE: [Capwap] So many       
                                       architectures, so little time... -  
                                       take 2                              

                                       Given the various sides to the      
                                       discussion on where MAC frames are  
                                       handled, I                          
                                       suggest making this a configuration 
                                       aspect of the CAPWAP protocol. So,  
                                       the                                 
                                       choice of which MAC frames are      
                                       processed where can be left till    
                                       the time of                         
                                       initializing APs.                   

                                       For example, when a controller      
                                       initializes a local-MAC AP, it      
                                       configures one                      
                                       instance of the CAPWAP protocol so  
                                       as NOT to receive any MAC frames    
                                       from the                            
                                       AP. Rather, the protocol instance   
                                       expects to receive explicit CAPWAP  
                                       messages/signals from the local-MAC 
                                       AP.                                 

                                       On the other hand, while            
                                       initializing a split-MAC AP,        
                                       another instance of                 
                                       the protocol is configured to       
                                       receive 'some' MAC frames and       
                                       'other'                             
                                       remaining CAPWAP messages/signals.  
                                       The 'some' and 'other' parts refer  
                                       to                                  
                                       particular split-MAC variations.    
                                       The specifics of these parts can be 
                                       left                                
                                       for refinement based on the         
                                       analyses from the Architecture      
                                       Taxonomy.                           

                                       The CAPWAP protocol can then be     
                                       made to work on both raw MAC frames 
                                       and                                 
                                       abstracted CAPWAP messages/signals. 
                                       This way, true interoperability is  
                                       achieved, while at the same time    
                                       allowing for different designs and  
                                       implementations.                    

                                       Comments? Suggestions?              

                                       Saravanan                           

                                               From:                       
                                       [email-masked] [         
                                       ?mod=compose&To=capwap-admin@frasco 
                                       ne.com]                             
                                       On Behalf Of Abhijit Choudhury      
                                               Sent: Wednesday, August 11, 
                                       2004 2:18 PM                        
                                               To: [email-masked]     
                                               Subject: FW: [Capwap] So    
                                       many architectures, so little       
                                       time... -                           
                                       take 2                              

                                               One key objective that has  
                                       been discussed in this group        
                                               is INTEROPERABILITY.  It's  
                                       not clear how you achieve           
                                               interoperability between a  
                                       WTP from vendor X and an AC         
                                               from vendor Y, if you don't 
                                       support the same protocols on       
                                               all three categories that   
                                       you have pointed out.  Sure you can 
                                                                           
                                               achieve interoperability    
                                       between the two, if you support the 
                                                                           
                                               superset of all possible    
                                       encapsulations, but then you are no 
                                                                           
                                               better off than you are     
                                       currently.  That is why there is    
                                       need                                
                                               for a standard.   And it's  
                                       easier to implement in hardware or  
                                       software                            
                                               if there is one standard    
                                       protocol instead of three.          
                                                                           
                                               We really should strive     
                                       towards a unified tunneling         
                                       protocol for                        
                                       control                             
                                               and data, although you can  
                                       have separate connections           
                                               for each, and different     
                                       security on each.                   
                                                                           
                                               But if this group stays     
                                       away from specifying a common       
                                               protocol for control/mgmt   
                                       and data between the WTP            
                                               and AC, or specifies one    
                                       and not the other,                  
                                               there cannot be true        
                                       interoperability even within        
                                               the split-MAC architecture  
                                       family.                             
                                                                           
                                               Abhijit                     

                                               From: Sudhanshu Jain        
                                                                           
                                               To: 'Yang, Lily L'; Shehzad 
                                       Merchant; Shankar Narayanaswamy;    
                                       Abhijit                             
                                       Choudhury                           
                                               Cc: [email-masked]     
                                               Subject: RE: [Capwap] So    
                                       many architectures, so little       
                                       time... -                           
                                       take 2                              

                                                                           
                                               Problem we have to solve    
                                       can be classified into three        
                                       categories.                         

                                               * Control & Management of   
                                       WTP                                 
                                               * Control & Management of   
                                       STA                                 
                                               * 802.11 Data               

                                               Since different             
                                       functionalities has different       
                                       requirements, it is                 
                                       possible to address them with       
                                       separate sets of mechanism.         

                                               First version of CAPWAP     
                                       control protocol should address     
                                       first                               
                                       functionality with provision to     
                                       communicate                         
                                               * Tunneling mechanism       
                                               * Information about MAC     
                                       implementation                      
                                       (Local/Split/Centralized)           
                                       etc.                                

                                               -Suds

---

From: [email-masked]
Date: Mon, 30 Aug 2004 18:03:39 -0700

Hi Pat,

  I have no strong opinion on the naming convention.
Since "Local MAC" belongs to "Centralized WLAN Architecture" (vs.
Autonomous
WLAN Arch), I guess some config/management/control functions should be done
in the AC.

  My understanding is the categorization in the Architecture Taxonomy
document is based
more on the control and management, rather than on the data path.
In fact, there could be a case that the AC handles all data but partial
MAC,
whereas in the other case AC handles no data but all
control/management. It might be difficult to categorize them all correctly.

  As for the reference I used in my previous mail, I believe a few of the
"Local MAC" examples described in the document could have utilized
similar fashion. Yes data do not even need to pass through the AC (so the
AC is more
like a station as you mentioned) if it really doesn't touch/monitor data
traffic.
I know some vendors provide extra filtering/policy in the switch/router
in this case, while leave all data traffic is in pure 802.3 format in/out
of the AC.

  Another reason to have above architecture is it allows existing
Ethernet switch vendors to jump onto the "wireless switch" bandwagon
without
major change on existing products. Like it or not, the force to go for this
direction
can be strong.

  Yes PoE for APs could be the other reason.

  Thanks.
  Regards,

--Tyan-Shu Jou

                    "Pat R.                                                                         
                    Calhoun"             To:     <[email-masked]>, <[email-masked]>         
                    <pcalhoun@aire       cc:                                                        
                    space.com>           Subject:     RE: [Capwap] So many architectures, so little 
                                          time... - take 2                                          
                    08/30/2004                                                                      
                    03:43 PM                                                                        

Interesting.

I would submit that if an implementation has an AC that provides some form
of access control, then it participates in the mac management in some form,
and therefore should fall under a split MAC category. Regardless of whether
the signalling used happens to smell and taste like 802.11 mac mgmt, or
whether
it is another payload format that includes essentially the same items.

The one case you are referring to is one where the AC does very little on
the data
path, and I would then ask why bother sending packets through the AC? This
architecture would obviously only work for WTPs directly connected to the
AC,
presumably for PoE purposes. Does this architecture/implementation that you
are referring to have centralized access control? It seems to me that in
this case
the AC is really nothing more than a management station, no?

PatC

From: [email-masked] on behalf of [email-masked]
Sent: Mon 8/30/2004 3:19 PM
To: [email-masked]
Subject: RE: [Capwap] So many architectures, so little time... - take 2

Hi Pat,

deployment:

---Tyan-Shu Jou

                                      ================

                                       PatC

                                       On the other hand, while

                                       Comments? Suggestions?

                                       Saravanan

                                               From:

                                               achieve interoperability

                                               superset of all possible

                                               better off than you are

                                               We really should strive

                                               But if this group stays

                                               Abhijit

                                               From: Sudhanshu Jain

                                               Problem we have to solve

                                               Since different

                                               First version of CAPWAP

                                               -Suds