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

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Thu, 5 Aug 2004 15:25:10 -0600

I am all ears to sense WG consensus on 'interoperability' between
different architectures. Also keen to understand why it is not the right
thing to do.

Besides, one may also want to qualify what constitutes
'interoperability' between different architectures beyond discovery of
WTP<->AC mutual compatibility. That's a matter of detail.

In principle I have so far heard the feasibility of a single protocol
that can help speak cross-arch. It is the capability of end-entity
implementations (AC, WTP) that will eventually drive its benefit.

In actuality - I also see this as providing output which is useful input
for AP functions interfaces.

Further - I would also urge us to think about this in the perspective of
the scope of interoperability - broadly on the control, provisioning/
configuration, monitoring/alerting aspects.

If the data-plane (fast-path) can be cleanly separated out of
consideration (as a side-effect that does not bring dependencies on the
core aspects of control, provisioning/configuration) - it goes a long
way in clarifying the protocol problem space and leaves much of the
architectural complexity that *seemingly* clouds the control-plane
realization.

Regards,
-mani
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Victor Lin
Sent: Thursday, August 05, 2004 11:46 AM
To: Bob O'Hara; [email-masked]
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

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

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]>;
<[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
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of [email-masked]
> Sent: Wednesday, August 04, 2004 11:53 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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: [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)
> > 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
> > [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
> > 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),
> > 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
> > [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

_______________________________________________
Capwap mailing list
[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
_______________________________________________
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: Petros Zerfos <[email-masked]>
Date: Thu, 5 Aug 2004 15:51:13 -0700 (PDT)

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.

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

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.

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

Petros

--
Petros Th. Zerfos
UCLA - Computer Science Department
email : [email-masked]
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 6 Aug 2004 09:46:28 +0800

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

> 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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 6 Aug 2004 08:57:49 -0700

I think interoperability is only necessary between architectures which
address roughly the same deployment niche. For example, I think split and
local MAC address roughly the same deployment niche. For Inderjeet's
benefit: there are probably some scenerios where one or the other does a
better job, so there is not complete overlap, but there is enough overlap
that having interoperable hardware will provide a significant benefit to
customers. As  I customer, I see local/split as largely an attempt at market
segmentation, and while such tactics typically provide some short term
benefit to the promoting vendors, in the long term, they typically tend to
inhibit overall market growth and thus also inhibit the promoting vendors'
bottom line.

Autonomous poses a question, however, since one could argue that it
currently addresses all deployment niches. I suppose I see the autonomous
architecture becoming primarily a SOHO/home solution in the future, that is,
it's niche contracts to a specific deployment scenario where it is best
suited, as the benefits of centralized architectues for larger deployments
become realized. Therefore, I feel there's less of a need for
interoperability, though perhaps there are some issues (as was  pointed by
someone out in a previous email) which could be addressed.

I don't see any need for having interoperability with remote and
distributed, since I think the deployment scenerios are likely to be quite
different than for local/split MAC and also I believe it would technically
quite challenging to come up with a protocol that would integrate
distributed, remote, and local/split MAC, essentially a research task.

I'm basically trying to approach this from the standpoint of what my company
might buy for an enterprise deployment that we as a sevice provider would
support (unlike the US, there are some companies in Japan who contract some
parts of their wireless IT support to service providers), and also for
possible public access hotspot service (we already have a public access
hotspot service, called MZone, in Japan). It's difficult to predict, but I
think the current situation - with various noninteroperable but excellent
centralized architecture products and lots of roughly interoperable
autonomous architecture products - is not very promising for providing large
scale, high quality WiFi service at a reasonable capital and system
management cost.

                jak

----- Original Message ----- 
From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
To: "Victor Lin" <[email-masked]>; "Bob O'Hara"
<[email-masked]>; <[email-masked]>
Sent: Thursday, August 05, 2004 2:25 PM
Subject: RE: [Capwap] So many architectures, so little time... - take 2

Regards,
-mani
-----Original Message-----

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

seem